| === 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 | ||
| ggoodman | 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 |
|---|---|---|
| ggoodman | 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 |
| ubottu | Pull 834 in canonical/cloud-init "Allow user control over update events" [Merged] | 15:01 |
| === bahamat_ is now known as bahamat | ||
| ggoodman | 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. | 16:44 |
| akutz | Will Bionic and Focal backports patches be made available the same day Impish is scheduled to drop (Oct 14th)? | 18:07 |
| akutz | falcojr: Do you happen to know the answer regarding the backports question above? Thanks! | 20:12 |
| falcojr | 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:28 |
| falcojr | 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 |
| falcojr | akutz: if you're asking about the VMware DS, that should be backported as of yesterday | 20:29 |
| ggoodman | 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 |
| falcojr | cloud-init SRU schedule doesn't follow the standard Ubuntu schedule, and we just finished backporting our 21.3 release yesterday | 20:30 |
| ggoodman | @falcojr is there a preferred bin for this channel? | 20:32 |
| ggoodman | 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 |
| falcojr | paste.ubuntu.com | 20:33 |
| falcojr | Ooto but I'll check when I'm back | 20:34 |
| ggoodman | @falcojr appreciated! Logs can be found here: https://paste.ubuntu.com/p/88mRKBhc36/ | 20:36 |
| akutz | falcojr: Holy snickers, really? That is awesome! | 20:44 |
| akutz | 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:46 |
| akutz | Also, it looks like 21.3 is in the updates channel for those releases, not backports. Which is honestly better :) | 20:56 |
| === EvaSDK_ is now known as EvaSDK | ||
| ggoodman | @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) | 22:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!