[10:50] <Goneri> hi, could you take a look at https://code.launchpad.net/~goneri/cloud-init/+git/cloud-init/+merge/368507 and https://code.launchpad.net/~goneri/cloud-init/+git/cloud-init/+merge/365641
[10:51] <Goneri> I built images that include the two patches: http://bsd-cloud-image.org/
[12:30] <schlitzer> hello, is there a guide on how to write a custom plugin for cloud-init?
[13:28] <Odd_Bloke> rharper: Is there a way for a user (or metadata source on an ISO) to change network configuration to happen on every boot?  Or is that only configurable on the DataSource in the code?
[14:52] <tribaal> Odd_Bloke: vaguely related: I'm trying to do the opposite (modify the list in cloud_config_modules in the conf from our datasource). I'm not sure I understand how it works - what reads that config key? I can change the behavior manually just fine (by playing with conf files), but I don't understand where/how to do the same programatically
[14:54] <tribaal> I'm not sure another datasource does anything similar (nothing I could find seems to tweak that particular set of entries). But if I knew where it's read it would already help me quite a bit :)
[16:27] <tribaal> Odd_Bloke: nevermind, enough digging yield the answer - for the record, the solution is that the datasource's self.extra_config is "util.mergemanydicts" 'd with the conf. So adding my config tweak to the datasource's extra_config does what I want. \o/
[17:14] <Odd_Bloke> tribaal: Great!
[18:46] <rharper> Odd_Bloke: (updating network-config on each boot is an event type that we've sent in a few datasources) however, in the hotplug branch; I've changes that allow user-data to opt-in to changes for each boot;  that is, for datasources which allow per-boot events; users can opt-in or out of what boot events to respond to;
[18:50] <Odd_Bloke> Thanks!
[18:50] <Odd_Bloke> This was for triage, and I wasn't even entirely sure that's what they were asking about, so I left a more general message in the end.
[18:51] <rharper> for ConfigDrive, or NoCloud; we'd need to update the datasources to allow EventType.BOOT (we default to EventType.BOOT_NEW_INSTANCE); and then user data could add the update_events: config to opt-in to that
[18:51] <rharper> Odd_Bloke: I think I know which one you're talking about; we have had general questions about allowing an updated iso or configdrive/nocloud to be applied on each boot
[18:52] <rharper> so once a rebased hotplug branch lands, we can update other datasources to accept EventType.BOOT as well
[18:52] <Odd_Bloke> Yeah, I think that would be a nice enhancement.
[18:52] <rharper> effectively, any datasource which has a network_config property could allow users to opt-in
[19:29] <AnhVoMSFT> hey folks if I have a simple cloud-config with packages/write_files/runcmd, is there anyway to quickly test it on an already-provisioned VM ?
[20:12] <Odd_Bloke> rharper: https://bugs.launchpad.net/cloud-init/+bug/1834875 is feeling more and more like it's a fundamental enough bug in {kernel,systemd,?} that we can't just workaround it from our perspective.
[20:12] <ubot5> Ubuntu bug 1834875 in cloud-init "cloud-init growpart race with udev" [Medium,In progress]
[20:13]  * rharper reads the update
[20:15] <rharper> Odd_Bloke: can we vary to a previous image which older kernel ?
[20:15] <rharper> or possible boot generic kernel instead?
[20:15] <rharper> that might help point to kernel regression
[20:15] <rharper> I agree it appears to be out of our hands
[20:16] <Odd_Bloke> rharper: Yeah, though the report is cosmic and later.
[20:16] <Odd_Bloke> Oh, right, but on Azure that may mean less with the custom kernel.
[20:50] <Odd_Bloke> rharper: Hmph, cosmic and bionic look to me like they had the same linux-azure version (because HWE), which suggests it isn't the kernel.
[20:51] <rharper> Odd_Bloke: surely we've had updates to the linux-azure kernel
[20:51] <rharper> like security fixes or other refreshes?
[20:51] <rharper> and we can still test a generic kernel to see if it reproduces
[20:52] <rharper> something underneath the instances may have changed which exposes the issue
[20:52] <Odd_Bloke> rharper: The issue is reported as present in cosmic and not in bionic.
[20:52] <Odd_Bloke> And cosmic and bionic were on the same linux-azure until cosmic EOL'd.
[20:54] <Odd_Bloke> I've looked at the udev diff from bionic to cosmic and it was fairly minimal, though.
[20:54] <Odd_Bloke> So I'll ask for a linux-generic run and see if that turns up anything interesting.
[20:56] <rharper> well, what about Disco or E
[20:56] <rharper> as cosmic os EOL
[21:00] <Odd_Bloke> My thinking was that as we started seeing this in cosmic, changes that weren't present in cosmic are unlikely to be the cause.
[21:03] <Odd_Bloke> (I mean, I also haven't ever really looked at the udev source before, so I could very easily be missing an important change that I don't understand.)
[21:03] <rharper> right, systemd-udev is userspace; but the event order is coming from the kernel
[21:04] <Odd_Bloke> The kernel event order is the same on failure and passing, I think.
[21:04] <Odd_Bloke> Let me double check that.
[21:07] <Odd_Bloke> Yes, the kernel emits (sda, sda1, sda14, sda15) in that order in both cases.
[21:09] <Odd_Bloke> Uh, sorry, the kernel emits change events for (sda, sda1, sda14, sda15) and then the add/remove for sda14 (from the partx call).
[21:09] <Odd_Bloke> But the same order on both hosts.
[21:10] <Odd_Bloke> And udev on the passing instance processes (sda, sda15, sda14, sda14, sda14, sda1), whereas on the failing instance it's (sda, sda15, sda1, sda14, sda14, sda14).
[21:10] <Odd_Bloke> (In both cases, the three sda14 events are in the order (change, remove, add).)
[21:12] <Odd_Bloke> So my intuition is that the kernel emits the sda1 event while the partition changes are still in flux somehow, and we fail if udev processes the sda1 event early enough to hit that "in flux" period.