[Bug 1201010] New: cloud-init hard requires wicked on Tumbleweed / MicroOS
http://bugzilla.opensuse.org/show_bug.cgi?id=1201010 Bug ID: 1201010 Summary: cloud-init hard requires wicked on Tumbleweed / MicroOS Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Cloud:Tools Assignee: public-cloud-maintainers@suse.de Reporter: fcrozat@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- MicroOS switched to NetworkManager by default, but cloud-init has still a hard-requires on wicked-service, which is causing both stacks to be installed and wicked is being used by default. It would be better to switch it to requires service(network) instead. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1201010 http://bugzilla.opensuse.org/show_bug.cgi?id=1201010#c1 Robert Schweikert <rjschwei@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fcrozat@suse.com, | |rjschwei@suse.com Flags| |needinfo?(fcrozat@suse.com) --- Comment #1 from Robert Schweikert <rjschwei@suse.com> --- It was my impression that the idea of cloud-init in MicroOS was discarded and that we would stick with ignition/combustion/afterburn as initialization code. As such I do not see the relevance of MicroOS switching to NM to the packaging of cloud-init. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1201010 http://bugzilla.opensuse.org/show_bug.cgi?id=1201010#c3 --- Comment #3 from Frederic Crozat <fcrozat@suse.com> --- I have one (personal) usecase which is forcing me to use cloud-init and I'd still want to MicroOS as OS for this. Moreover, ALP is switching to NM and dropping wicked. So, we will need to handle this in the near future. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1201010 http://bugzilla.opensuse.org/show_bug.cgi?id=1201010#c4 --- Comment #4 from Robert Schweikert <rjschwei@suse.com> --- Hold on that doesn't make any sense to me what so ever. NM does not handle the underlying connections, i.e. NM does not make DHCP requests etc. That happens via wicked or via dhcpclient. If we are dropping wicked are we going back to dhcpclient? What happens to our sysconfig layout and the values we set in sysconfig? This is a much bigger topic than a "Require" statement in the spec file. As a side note wicked is required by a lot of packages in the Public Cloud area, we need a running network. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1201010 http://bugzilla.opensuse.org/show_bug.cgi?id=1201010#c6 Frederic Crozat <fcrozat@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fcrozat@suse.com) | --- Comment #6 from Frederic Crozat <fcrozat@suse.com> --- (In reply to Robert Schweikert from comment #4)
Hold on that doesn't make any sense to me what so ever. NM does not handle the underlying connections, i.e. NM does not make DHCP requests etc. That happens via wicked or via dhcpclient.
If we are dropping wicked are we going back to dhcpclient?
no, systemd has its own dhcp client (in fact, import of systemd-networkd code). Or it can use dhcp-client or other dhcp clients.
What happens to our sysconfig layout and the values we set in sysconfig?
It depends which settings you are talking about. BTW, latest version of cloud-init upstream landed NM in May (to handle NM config file natively, as Fedora is moving away from ifcfg files).
As a side note wicked is required by a lot of packages in the Public Cloud area, we need a running network.
and I don't see why you don't get one with NM. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1201010 http://bugzilla.opensuse.org/show_bug.cgi?id=1201010#c7 --- Comment #7 from Robert Schweikert <rjschwei@suse.com> --- Again cloud-nit is not a topic for SLE Micro which is why I have not paid much attention to the topic. I'd much rather use cloud-init than ignition/combustion/afterburn but that brings Python and a number of other dependencies. And everyone raises a red flag every time something that uses Python is needed as i "SLE-Micro is getting too big". Well, where is the spec as to what sysconfig will look like, or are we just adopting what RH does? There is a lot of code in cloud-init that deals with our settings for bridge setup, route configuration files etc. And I still carry a large patch in the package that I have not pushed upstream. If that's all changing for whatever is next that's fine, but then someone better produce a spec to code to. And no changing the Requires in the spec file will not work for cloud-init. cloud-init is heavily distribution dependent. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1201010 http://bugzilla.opensuse.org/show_bug.cgi?id=1201010#c8 --- Comment #8 from Frederic Crozat <fcrozat@suse.com> --- (In reply to Robert Schweikert from comment #7)
Again cloud-nit is not a topic for SLE Micro which is why I have not paid much attention to the topic.
Consider this as a preview of the work to be done for ALP.
I'd much rather use cloud-init than ignition/combustion/afterburn but that brings Python and a number of other dependencies. And everyone raises a red flag every time something that uses Python is needed as i "SLE-Micro is getting too big".
Well, where is the spec as to what sysconfig will look like, or are we just adopting what RH does? There is a lot of code in cloud-init that deals with our settings for bridge setup, route configuration files etc. And I still carry a large patch in the package that I have not pushed upstream.
If that's all changing for whatever is next that's fine, but then someone better produce a spec to code to.
I think you should join the ALP workgroup in Network configuration stack, to discuss this further : https://confluence.suse.com/pages/viewpage.action?pageId=963936740 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1201010 http://bugzilla.opensuse.org/show_bug.cgi?id=1201010#c9 --- Comment #9 from Robert Schweikert <rjschwei@suse.com> --- Sure all in my ample spare time. What I need from the ALP network group is a spec, I do not see the need to participate to influence the direction as to where networking is going. Other people that know much more about networking than I do need to make the decisions what's best. Then give me a spec and I'll figure out how to get it into cloud-init. Until then the version in Cloud:Tools will remain the same as is in SLES. For anything to fiddle with Cloud:Tools:Next is the project to work with. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1201010 http://bugzilla.opensuse.org/show_bug.cgi?id=1201010#c10 --- Comment #10 from Frederic Crozat <fcrozat@suse.com> --- (In reply to Robert Schweikert from comment #9)
Sure all in my ample spare time.
What I need from the ALP network group is a spec, I do not see the need to participate to influence the direction as to where networking is going. Other people that know much more about networking than I do need to make the decisions what's best. Then give me a spec and I'll figure out how to get it into cloud-init. Until then the version in Cloud:Tools will remain the same as is in SLES. For anything to fiddle with Cloud:Tools:Next is the project to work with.
Could you at least state that in the confluence page for this workgroup, so they are aware of it ? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com