Bug 1868000

Summary:	Investigate and Integrate NetworkManager's nm-cloud-setup for cloud images
Product:	Red Hat Enterprise Linux 8	Reporter:	Thomas Haller <thaller>
Component:	osbuild	Assignee:	Image Builder team <osbuilders>
Status:	CLOSED WONTFIX	QA Contact:	Release Test Team <release-test-team-automation>
Severity:	low	Docs Contact:
Priority:	low
Version:	8.3	CC:	cheshi, eterrell, huzhao, jgreguske, leiwang, linl, nm-team, ribarry, till, tumeya, vkuznets, xiachen, xiliang, yacao, ymao, yuxisun
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-02-11 07:27:13 UTC	Type:	Feature Request
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1623084, 1822853
Bug Blocks:

Description Thomas Haller 2020-08-11 11:36:53 UTC

As part of bug 1623084 we added `nm-cloud-setup` to NetworkManager.

See:

- https://bugzilla.redhat.com/show_bug.cgi?id=1623084#c9

- https://github.com/coreos/fedora-coreos-tracker/issues/320

- https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/message/FSQR6KL4KA37WHTUAXL774SXSWIBSYGI/



What we need now, is to actually start using it :)

Or at least, investigating whether cloud images want to use the tool (and how). If it is then determined that RHEL should not use nm-cloud-setup, then that is a possible outcome.


I assign this bug to cloud-init, but that's probably wrong. Please reassign to a better suited component, that concerns RHEL images in cloud environment. Sorry, and thank you.

Comment 1 Frank Liang 2020-08-11 12:01:32 UTC

Thanks, Thomas
I created a 1822853 request about  installing NetworkManager-cloud-setup into ec2 AMIs before. No progress made yet. I am adding more people to review this change.

Comment 2 Thomas Haller 2020-08-11 12:27:42 UTC

I missed the existence of bug 1822853. Thank you!

The other bug explicitly talks about AWS, while similar tasks could be for GCE and Azure.
Hence, this bug could serve a purpose as a more general tracker bug for this issue.

Comment 3 Rick Barry 2020-08-11 12:44:47 UTC

Eduardo, can you review this BZ? Is this something that should be integrated into cloud-init at some point or handled in a different way for cloud images.

Comment 5 Eduardo Otubo 2020-10-08 13:07:17 UTC

(In reply to Rick Barry from comment #3)
> Eduardo, can you review this BZ? Is this something that should be integrated
> into cloud-init at some point or handled in a different way for cloud images.

If I understand correctly, this is a NetworkManager's new feature that makes it easy to configure interfaces or secondary interfaces with ipv4 on supported platforms. On the pointed links (also searching on Google) I couldn't find a precise documentation on how exact it works. The decision on including support on cloud-init is not mine, it's upstream maintainers'. But if we decide that it makes sense to include on cloud-init I can drive the implementation and submit a pullrequest.

But from a conservative point of view, it's possible it won't make it to RHEL-8.4.

Please point me to a documentation so we can proceed.

Thanks!

Comment 6 Thomas Haller 2020-10-08 15:16:55 UTC

> Please point me to a documentation so we can proceed.

The major point is that nm-cloud-setup is configuration-less. You enable the systemd units nm-cloud-setup.{service,timer} and also opt-in to the supported cloud providers (see `systemctl cat nm-cloud-setup.service` or https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/5b941666e9053348d51113b2fa8dd7e62e01f1ab/clients/cloud-setup/nm-cloud-setup.service.in). Of course, documentation should be improved (bug 1867997), but there isn't really much to configure. Install the package, enable the cloud providers via the systemd unit (Environment=) and enable the .service/.timer units.


Whether this should be integrated with cloud-init is not clear to me.

To my knowledge, if you boot a RHEL image in cloud then secondary IP addresses are not picked up automatically. Contrary to for example Amazon Linux or SUSE (see references at https://bugzilla.redhat.com/show_bug.cgi?id=1623084#c9). If I am wrong about that and RHEL has a satisfying solution already, then please point it out and you may not want to consider nm-cloud-setup.

But nm-cloud-setup was developed to address that. And this bug requests that RHEL (cloud) images work well out-of-the-box in cloud by using it. Whether that should be integrated by cloud-init or achieved somehow differently is up to you (as said in comment 0).



(what of course is also missing is extensive testing of nm-cloud-setup).

Comment 7 Thomas Haller 2021-04-29 07:34:41 UTC

Hi Eduardo,

in the meantime, nm-cloud-setup received a manual page, and it also received more testing (and fixes).

We are still interested in moving this forward. What are your thoughts on this issue in general, and what can we do to move this forward?
-- also, I personally have a lack of knowledge how cloud-init or RHEL cloud images work. So, I would appreciate some thoughts on how nm-cloud-setup could be enabled on RHEL and whether that is via cloud-init or not.

Thanks.

Comment 8 Thomas Haller 2021-04-29 07:43:44 UTC

Ah, I see now that rh#1822853 made progress in the meantime.
And that solution does not directly involve cloud-init.

Comment 9 Huijuan Zhao 2021-11-08 03:18:33 UTC

(In reply to Thomas Haller from comment #8)
> Ah, I see now that rh#1822853 made progress in the meantime.
> And that solution does not directly involve cloud-init.

Yes, rh#1822853 was resolved on AWS, the nm-cloud-setup was also integrated on Azure, both did not directly involve cloud-init. 
Thomas, I think it is better to achieve this from osbuild side after discussion in team, so move to osbuild component for further research and making the BZ move on, please correct me if anything wrong, thanks!

Comment 12 RHEL Program Management 2022-02-11 07:27:13 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.