| minimal | Just been trying to test the network hotplug stuff - I created a ConfigDrive iso as that "appears" to support hotplug and booted a VM fine on QEMU, then I used the QEMU Monitor to add a 2nd ethernet interface to the machine and the cloud-init.log showed that hotplug was not enabled for the ConfigDrive DataSource.....am confused :-) | 12:14 |
|---|---|---|
| falcojr | minimal: did you include hotplug in the userdata too? {'updates': {'network': {'when': ['hotplug']}}} ? | 12:58 |
| minimal | falcojr: nope, I wasn't aware it needed to be there. Is that documented somewhere? | 13:13 |
| minimal | ah, found a reference to it on readthedocs. Can this go in /etc/cloud.cfg or does it have to be in user-data? | 13:14 |
| falcojr | of the top of my head, I can't think of a reason it wouldn't work in /etc/cloud.cfg, but I haven't done it myself | 13:15 |
| minimal | ok, I'll try it. I'm also not sure how network hotplug is supposed to work with ConfigDrive - if I put details of the 2nd network interface in the ISO's network_data.json then it will be read anyway at 1st boot, but if I don't put that detail in it and then add the 2nd interface where will cloud-init get the config details for the 2nd interface from? | 13:18 |
| minimal | its different from a metadata-server based approach where I expect the Cloud Provider will automatically update the network data with new interface details | 13:19 |
| falcojr | yeah, it doesn't really make much sense for a static metadata source. For testing, I was able to update the metadata in a seed dir of a NoCloud datasource, but that doesn't seem like it'd be a real-world use case | 13:21 |
| minimal | falcojr: didn't think NoCloud supported hotplug - didn't see it mentioned in the DS code | 13:22 |
| minimal | though only Ec2, Openstack, and ConfigDrive did currently - that's why I'm testing ConfigDrive, I normally use NoCloud for local servers | 13:23 |
| falcojr | Ah, right. That was a local change I did while doing development. Virtual devices weren't detected correctly within containers so I wasn't able to test end-to-end and eventually turned it off | 13:26 |
| minimal | so would it be safe to have the above "when: hotplug" entry in /etc/cloud.cfg regardless of which DS is being used? I'm assuming it is as if the DS itself does not enable hotplug then there's no ill effect | 13:27 |
| falcojr | yes, it shouldn't hurt anything to do that. Each datasource now has supported update events and default update events. Specifying events through userdata will override the default update events, but won't enable events that aren't supported | 13:30 |
| falcojr | only issue you might run into is some DSes will update metadata every boot by default, so if that isn't specified, you won't get that behavior anymore | 13:30 |
| minimal | you mean I should specify "when: ['boot','hotplug']" in all cases and the relevant DS will act appropriately? | 13:32 |
| falcojr | not entirely. When you specify that 'when', you're overriding the default behavior. Most DSes probably support 'boot', but won't have it enabled by default, but some (one or two if I remember correctly) do. Specifying it always won't hurt anything, but it'll increase boot times as it'll cause a re-fetch of the metadata every boot | 13:56 |
| minimal | ok, so in the case where multiple DS are enabled, some of which may support this and some do not, then how should cloud-init be configured to 'out of the box' (i.e. in a preconfigured VM) handle this without having to rely on user-data (which is not under the control of the person providing the VM)? | 14:04 |
| minimal | thinking of this with my Alpine package maintainer hat on :-) | 14:04 |
| minimal | VM == VM image | 14:04 |
| falcojr | the intent was to allow the datasource to define it, but the user to override it as necessary. Why are you wanting to enable it by default at the distro level? | 14:06 |
| minimal | I'm thinking of, example, an OS image designed to work with AWS & Azure & GCE, where only AWS currently supports network hotplug. | 14:08 |
| minimal | its "hard" to get end-users to read the docs so they would invariably not add the hotplug entry to the user-data for AWS | 14:09 |
| holmanb | It appears that the VyOS project (an open source network OS) is maintaining a fork of cloud-init that enables router configuration on startup (as well as some other features). Have there been any discussions regarding up streaming their work? I don't see any mentions of it in the canonical GitHub PR history. | 14:14 |
| holmanb | (just curious) | 14:14 |
| falcojr | minimal: it's not meant to be turned on by default, so I would say "don't do that". Over time, I'm guessing certain datasources will have hotplug enabled by default, but if not, I want users to have to search out docs to be able to make it happen | 14:15 |
| falcojr | holmanb: I'm not aware of that project, but we're always open to upstreaming work that'd be beneficial to everybody | 14:16 |
| holmanb | falcojr: understand, thanks | 14:17 |
| minimal | falcojr: ok. I'm just finishing up the Alpine package for 21.3 - as part of that I've written a init.d script for hotplug and a simple daemon in Shell to provide the equivalent of the systemd service and socket files. I'll be working on PRs for those changes to cloud-init shortly | 14:27 |
| falcojr | minimal: great, thanks! | 14:27 |
| minimal | falcojr: final question - would PRs for mdev support (udev alternative) on Linux be welcome or unwelcome? | 14:30 |
| falcojr | I know nothing about mdev, so probably depends on how intrusive the change is. If it's just some additional ifs in a template or some packing code that specifies different files to lay down, I think it would be fine | 14:33 |
| minimal | well it would replace calls to things like "udevadm" in things like cc_disk_setup.py and the network stuff (which create a udev rule file) | 14:34 |
| minimal | trying to work out if its worth me adding mdev to cloud-init on Alpine as, if upstream PRs don't get merged, then I might be left maintaining patches for Alpine forever more lol | 14:36 |
| falcojr | ah, right, so that'd require some refactoring to get it to work. We've been open to big-ish refactors in the past to be more accommodating of various distros. I see no reason why that wouldn't apply here | 14:39 |
| falcojr | you'd have to drive it though | 14:39 |
| andrewbogott | thx for the merge falcojr -- will make my first-boot logic much simpler! | 14:52 |
| falcojr | yeah, I can see the usefulness of it | 14:52 |
| minimal | falcojr: thanks for the answers | 14:57 |
| minimal | falcojr: sorry, further question after looking at various DS code: what about 'boot-new-instance' and 'boot-legacy'? I'd assume these are also overrriden by user-data/cloud.cfg entry so would need to specify those too for relevant DS(es)? | 15:19 |
| falcojr | first instance boot will fetch metadata regardless of the update settings, so not specifying it in the userdata won't affect anything | 15:37 |
| minimal | ok, and legacy? | 15:38 |
| falcojr | boot-legacy is likely not necessary ever. It's similar to boot but applies networking twice per boot. We were worried about introducing a regression by changing the behavior so left the legacy option. If you override it with boot you'll likely be fine, but there is some risk there | 15:41 |
| minimal | ok, saw just looking at the default_update_events values for various DSes when I noticed legacy | 15:43 |
| minimal | thanks again | 15:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!