=== toabctl_ is now known as toabctl === paride7 is now known as paride === meena6 is now known as meena === paride2 is now known as paride === meena6 is now known as meena === djhankb4 is now known as djhankb === bahama- is now known as bahamat === bahamat is now known as bahama- === ubot3 is now known as ubottu === nicolasbock_ is now known as nicolasbock === bahamat_ is now known as bahamat === bahamat is now known as bahamat_ === smoser1 is now known as smoser [15:01] Hi folks. Taking a chance here after seeing the bug tracker empty. We've recently found ourselves pulling in https://github.com/canonical/cloud-init/pull/834 ("Allow user control over update events"). The hosts that are affected are creating and disposing docker containers at a very high rate. A side-effect thereof is that lots of virtual ethernet [15:01] adapters are created and disposed. We see that this is triggering cloud-init events at a high volume, consuming significant CPU. Is there a way that we can disable such events from triggering cloud-init? [15:01] Pull 834 in canonical/cloud-init "Allow user control over update events" [Merged] === bahamat_ is now known as bahamat [16:44] We've done quite a bit more spelunking and the udev hotplug trigger invoking `cloud-init devel hotplug-hook` is what is consuming lots of CPU each time a container is created or disposed. Tweaking the udev rules to exclude veth adapters 'fixes' the issue but doesn't appear to be configurable. [18:07] Will Bionic and Focal backports patches be made available the same day Impish is scheduled to drop (Oct 14th)? [20:12] falcojr: Do you happen to know the answer regarding the backports question above? Thanks! [20:28] ggoodman: that shouldn't be enabled by default. What cloud is this on and has the cloud-init code different from upstream? Regardless, the example here in the user's cloud config should disable it. https://cloudinit.readthedocs.io/en/latest/topics/events.html#apply-network-config-every-boot [20:29] I'd be interested in seeing the /var/log/cloud-init.log if you can produce it. Either a paste bin here or new launchpad bug [20:29] akutz: if you're asking about the VMware DS, that should be backported as of yesterday [20:30] We did try the config suggested in the linked docs and that didn't appear to help at all. Let me see about getting some of the logs. [20:30] cloud-init SRU schedule doesn't follow the standard Ubuntu schedule, and we just finished backporting our 21.3 release yesterday [20:32] @falcojr is there a preferred bin for this channel? [20:33] The log file has reached 299m (and counting) so I'll share the last 100 lines that I believe show several of the complete events. [20:33] paste.ubuntu.com [20:34] Ooto but I'll check when I'm back [20:36] @falcojr appreciated! Logs can be found here: https://paste.ubuntu.com/p/88mRKBhc36/ [20:44] falcojr: Holy snickers, really? That is awesome! [20:46] I was also wondering about the patch releases of the LTS versions that will have CI v21.3 baked into them. Or will they? I thought 18.04.6 and 20.04.3, for example, would have CI 21.3 OOTB, but I'll admit I don't know how the backports work for updates to LTS images. [20:56] Also, it looks like 21.3 is in the updates channel for those releases, not backports. Which is honestly better :) === EvaSDK_ is now known as EvaSDK [22:15] @falcojr also, you asked about which cloud; this is on AWS vanilla EC2 w/ am 18.04.06 upstream AMI (with linux-aws-edge kernel)