| Eighth_Doctor | hey falcojr have you had a chance to look at https://github.com/canonical/cloud-init/pull/1224 again? | 14:17 |
|---|---|---|
| ubottu | Pull 1224 in canonical/cloud-init "Add native NetworkManager support" [Open] | 14:17 |
| falcojr | Eighth_Doctor: yep, started taking a look again yesterday. I should get the review in today | 14:18 |
| Eighth_Doctor | awesome | 14:18 |
| Eighth_Doctor | I'm currently shipping it in Fedora's cloud-init package, but I'd like to see this land in cloud-init upstream so I can get the Red Hat folks to ship it in RHEL 9 too | 14:18 |
| Eighth_Doctor | I only have one minor patch myself on top of that patch set, which sets NetworkManager as the renderer preferred above all others: https://src.fedoraproject.org/rpms/cloud-init/blob/rawhide/f/cloud-init-22.1-nm-default.patch | 14:19 |
| Eighth_Doctor | which, seemingly from the conversation in the PR already, will not likely be accepted right now, so I'm carrying it downstream only | 14:20 |
| falcojr | Eighth_Doctor: right, I think we're going to keep it lower upstream to reduce the possibility of regression. "The sysconfig machinery is currently being used with NetworkManager's compat module, When it's present it works, and once it goes away there's no chance of using it accidentally." | 14:21 |
| Eighth_Doctor | well it's not in upstream cloud-init | 14:22 |
| Eighth_Doctor | that's the problem | 14:22 |
| Eighth_Doctor | upstream cloud-init sets NM_CONTROLLED=no | 14:22 |
| Eighth_Doctor | so writing ifcfg-rh files today with upstream cloud-init leads to a broken setup | 14:22 |
| Eighth_Doctor | and starting with F36 and EL9, it'll not work at all, since the ifcfg-rh plugin won't even be shipped on the default install even if you change that behavior | 14:23 |
| Eighth_Doctor | falcojr: https://src.fedoraproject.org/rpms/cloud-init/blob/056ace892593cd9a3b341b9e7ed7ceedb918b15f/f/cloud-init-21.3-nm-controlled.patch | 14:25 |
| falcojr | Eighth_Doctor: I see, so do you think it makes the most sense to set NM_CONTROLLED to True upstream, and older downstream distros can set it to False if they need to? | 14:25 |
| Eighth_Doctor | my understanding is that this was previously discussed upstream and rejected | 14:25 |
| Eighth_Doctor | so I don't know what we should do now | 14:25 |
| Eighth_Doctor | the Red Hat folks have been carrying a downstream patch for the sysconfig module for a long time for it | 14:26 |
| falcojr | Eighth_Doctor: I'm not aware of those discussions (or don't remember them :P ). Do you have any links that could provide more context? | 14:28 |
| Eighth_Doctor | I don't have those either, sorry | 14:28 |
| Eighth_Doctor | I only know them second/third hand | 14:28 |
| Eighth_Doctor | I've only recently started delving into this mess over the last couple of years :) | 14:29 |
| falcojr | no problem, just asking because it seems like a reasonable change right now, but I'm probably missing some additional context | 14:29 |
| Eighth_Doctor | falcojr: my suggestion is to set upstream cloud-init to have the renderer preference of networkmanager -> netplan -> sysconfig -> eni | 14:29 |
| Eighth_Doctor | for the ubuntu renderer of cloud.cfg, I think it sets netplan -> eni | 14:30 |
| Eighth_Doctor | so that should be fine from an upstream and downstream perspective | 14:30 |
| Eighth_Doctor | outside of RHEL and Fedora, nobody tried to use NM with sysconfig in the RH ecosystem | 14:31 |
| Eighth_Doctor | so the potential for breakage is minimal to basically zero | 14:31 |
| Eighth_Doctor | Mageia uses sysconfig with legacy network-scripts, but would switch to networkmanager once the module is in anyway | 14:32 |
| Eighth_Doctor | same for OpenMandriva, ROSA, and others | 14:32 |
| Eighth_Doctor | SUSE uses sysconfig with netconfig or wicked, both of which work with the sysconfig module pretty much as-is | 14:32 |
| Eighth_Doctor | though they've been considering moving to NetworkManager, but NM doesn't support ifcfg-suse, and the blocker for such a consideration is cloud-init supporting NM properly | 14:33 |
| Eighth_Doctor | and networkmanager exists in virtually all Linux distributions, so that will make cloud-init easier to work with for them | 14:36 |
| falcojr | Eighth_Doctor: thanks, that's helpful. I think for this PR we'll keep it as-is, but we can probably submit a follow-on PR and double check with a few other maintainers. Realistically, I think it'd involve moving sysconfig to the bottom of the list rather than network-manager to the top | 14:41 |
| Eighth_Doctor | yeah | 14:42 |
| Eighth_Doctor | I'm happy with a follow-on PR | 14:42 |
| Eighth_Doctor | at the moment, I think we should just get the NM stuff merged | 14:42 |
| Eighth_Doctor | and I can carry the re-order patch downstream for a bit and then maybe propose a better version upstream once I have a better handle on things :) | 14:42 |
| Eighth_Doctor | falcojr: does that sound reasonable to you? | 14:43 |
| falcojr | Eighth_Doctor: yes it does. Thanks for walking me through that | 14:44 |
| Eighth_Doctor | as for why I want to wait on the follow-on PR, I'd like to get a better handle on the cloud-init test suite | 14:44 |
| Eighth_Doctor | I don't fully understand how the tests for renderer backend ordering works, so I want to understand it better before proposing a patch for changing the order upstream | 14:45 |
| Eighth_Doctor | I should probably send a PR indicating that I've signed the Canonical CLA though | 14:45 |
| Eighth_Doctor | I did that years ago for snapd and mir | 14:45 |
| falcojr | Eighth_Doctor: good idea. You can also just include it as part of a normal PR too. It doesn't have to be separate | 14:47 |
| Eighth_Doctor | oh, you don't necessarily do squash merges | 14:48 |
| Eighth_Doctor | the main reason I was thinking of separating them is that it looked like you do squash merges (which I'm not a huge fan of...) | 14:48 |
| Eighth_Doctor | falcojr: I would also appreciate it if you didn't squash merge the NM PR, since lubko went through the trouble of making discrete changesets | 14:50 |
| falcojr | Eighth_Doctor: we do. None of us love it, but the main reason is changelog generation and we need to update our tooling first | 14:51 |
| Eighth_Doctor | ah | 14:51 |
| Eighth_Doctor | yeah, then I probably should send separate PRs | 14:51 |
| falcojr | blackboxsw: do you know where the lxd templates come from? Are they built into the image? | 19:47 |
| falcojr | like if I do `lxc config template list` for one instance, I see a different network config tpl than for another instance | 19:48 |
| blackboxsw | falcojr: yes different instance types come with different metadata tgz to as part of cloud image build process. https://blackboxsw.github.io/2021-11-08-customize-lxd-metadata-templates/#lxd-image-metadata | 19:52 |
| blackboxsw | shameless sharing of sparse blog :/ | 19:52 |
| blackboxsw | generally there is an image build process in canonical-land that generates those network config templates for the jammy-server-cloudimg-amd64-lxd.tar.xz which has templates and metadata components | 19:53 |
| falcojr | thanks | 19:54 |
| blackboxsw | holmanb: thanks again for the PRs for ubuntu uploads https://github.com/canonical/cloud-init/pull/1303 pushed | 22:27 |
| ubottu | Pull 1303 in canonical/cloud-init "New upstream snapshot: Jammy" [Merged] | 22:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!