=== paride0 is now known as paride
[01:56] <Smithx10> Hmm  I am trying to debug a config-mount issue I'm seeing in centos-8
[01:56] <Smithx10> hmmm  built centos8 and centos7 images with the mi-centos-hvm repos and for some reason (still hunting) cloud-init blame shows 15.08800s (modules-config/config-mounts) for centos8 and 00.49400s (modules-config/config-mounts) for centos7  they are on different cloud-init versions
[01:57] <Smithx10> Anyway to see where we spend most of our time in config-mounts?
[06:07] <meena> Smithx10: other than the debug logs? i dunno
=== hjensas|afk is now known as hjensas
=== hjensas is now known as hjensas|afk
[13:59] <Odd_Bloke> meena: Yeah, I wasn't sure how to ask them either.
=== ahosmanMSFT_ is now known as ahosmanMSFT
=== mskalka_ is now known as mskalka
=== andrein_ is now known as andrein
=== logan_ is now known as logan-
=== philroche_ is now known as philroche
=== jdoss_ is now known as jdoss
[14:00] <Odd_Bloke> Smithx10: You can look in /var/log/cloud-init.log as meena suggested, search for "Running module mounts" in there.
[14:03] <meena> Odd_Bloke: we could start with twitter, which is my first choice, when there's no other choice
[14:07] <Odd_Bloke> meena: I won't stop you. ;)
[14:10] <otubo> Odd_Bloke: would you ahve time to take a final look at my PR? https://github.com/canonical/cloud-init/pull/541
[14:10] <otubo> Odd_Bloke: I think it's all fixed by now :)
[14:10] <Odd_Bloke> otubo: Sure thing, looking now!
[14:55] <Odd_Bloke> otubo: Just one small thought left, thanks for all the back and forth!
[15:22] <otubo> Odd_Bloke: I think it's reasonable to change that to INFO. Just pushed the change. Thanks for the review! :-)
=== hjensas|afk is now known as hjensas
[16:00] <Odd_Bloke> otubo: Merged. \o/
[17:03] <meena> Odd_Bloke: https://twitter.com/hirojin/status/1305914616229359619
[17:10] <Odd_Bloke> Now we play the waiting game.
[17:11] <Odd_Bloke> (Thanks!)
[18:48] <meena> Odd_Bloke: isn't that all we ever do? (and then we die)
[19:31] <Odd_Bloke> otubo: I'm looking at https://bugs.launchpad.net/cloud-init/+bug/1894837 and it's not 100% clear to me what the path forward is.  In the Ubuntu world, we use NM for desktops, but not at all for servers, so I don't really have background on how its configured without nm-applet, let alone via sysconfig.  Do you think we should remove that defaulting?  What impact might that have?
[19:31] <ubot5> Ubuntu bug 1894837 in cloud-init "RHEL8 ipv4 IPs not coming up when NM_CONTROLLED=False" [Undecided,New]
=== tds5 is now known as tds
[21:18] <fling> Hello.
[21:20] <fling> What is needed for cloud-init to work for lxd profiles? runcmd and packages and other sub entries of user.user-data in container config/profile
[21:20] <blackboxsw> fling: something like this https://discuss.linuxcontainers.org/t/running-virtual-machines-with-lxd-4-0/7519
[21:21] <blackboxsw> generally you can create a lxd profile locally .... mine currently looks like this
[21:24] <fling> It is just unclear for me what steps need to be performed.
[21:24] <fling> First I install cloud-init on the same host where I have lxd running right?
[21:25] <fling> Then I just add specific entries under 'user.user-data: |' to the config?
[21:25] <fling> Are there any other steps?
[21:26] <Odd_Bloke> fling: cloud-init runs within the container, not outside it; your container image will need to include cloud-init for it to run.
[21:27] <blackboxsw> d'oh I misread lxd --vms in the request fling: https://paste.ubuntu.com/p/N8cDrVj9wq/
[21:27] <Odd_Bloke> Note that many (all?) of the images from the images: remote do not include cloud-init; if you're using Ubuntu then the images from the ubuntu: remote do.
[21:27] <blackboxsw> that's how I setup lxd vm enabled profiles and launch a vm (not lxc) container
[21:27] <Odd_Bloke> Well, it's true that VM images would need cloud-init inside them, it's just more unusual to exclude cloud-init from VM images.
[21:29] <blackboxsw> right and to Odd_Bloke's point, standard/supports cloud-images are available with cloud-init baked into those images. they can be launched with lxc launch ubuntu-daily:<xenial|bionic|focal|etc>....   most images aliases that contain cloud-init would be presented here https://us.images.linuxcontainers.org/
[21:29] <blackboxsw> sorry for not answering the actual question you had above
[21:29] <Odd_Bloke> System container images don't _need_ it because you don't need to configure anything inside the container to be able to gain access (because you generally have direct access to the "hypervisor").
[21:30] <Odd_Bloke> blackboxsw: The ubuntu: remote is preferred for production use cases; the ubuntu-daily: images don't receive any testing before publication.
[21:30] <fling> Then what is needed for cloud init to perform stuff from user.user-data: ?
[21:31] <Odd_Bloke> fling: I believe user.user-data needs to be a string that starts with "#cloud-config", it's not just nested YAML; perhaps that's tripping you up?
[21:31] <fling> Ok, fine.
[21:31] <blackboxsw> correct fling. as long  as cloud-init package is living in the container
[21:32] <blackboxsw> sudo cloud-init query userdata > ud.yaml; cloud-init devel schema -c ud.yaml --annotate;
[21:32] <blackboxsw> ^ perform this cmd inside your container and it'll tell you whether the user-data you provided was valid for cloud-init
[21:32] <Odd_Bloke> We should really just make that a command.
[21:32] <blackboxsw> yeah totally
[21:32] <Odd_Bloke> `cloud-init devel schema --system` or somesuch.
[21:32] <blackboxsw> maybe just `cloud-init devel schema validate`?
[21:32] <blackboxsw> yeah
[21:32] <blackboxsw> even better
[21:33] <blackboxsw> that's a couple liner at nest
[21:33] <blackboxsw> best
[21:33] <fling> How is 'user.user-data:' entry getting to cloud-init from a container config?
[21:33] <Odd_Bloke> fling: lxd writes it into a seed file in the container filesystem before starting the container.
[21:33] <blackboxsw> lxc dumps it in /var/lib/cloud/seed/nocloud-net/user-data
[21:34] <blackboxsw> and cloud-init NoCloud datasource knows how to read that yaml file
[21:34] <fling> so user.user-data is some kind of a special name? :D
[21:34] <blackboxsw> on most cloud platforms it's just user-data.... and each cloud (lxc included) provides that data in an unique location/format
[21:35] <blackboxsw> user-data meta-data and vendor-data are kindof cloud-init special names for different layers of configuration information
[21:35] <blackboxsw> lxc let's you provide your own user.user-data and user.meta-data etc
[21:37] <Odd_Bloke> user.meta-data is appended to the metadata that lxd needs to provide for things to work as it expects (e.g. hostname, instance-id).
[21:37] <fling> meaning lxd just performs this dump when it finds user.user-data: in the config right?
[21:37] <Odd_Bloke> And by "e.g." I guess I mean "those are the two things". :p
[21:38] <Odd_Bloke> Correct, it writes that string to that file; cloud-init runs inside the container, finds that seed and processes it.
[21:38] <fling> Thanks!
[21:38] <blackboxsw> more info here too https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html
[21:38] <blackboxsw> just on data types that cloud-init considers
[22:07] <blackboxsw> ok fine. lies about a couple liner https://paste.ubuntu.com/p/wYn369B9K5/ without unit test fixes.
[22:07] <blackboxsw> brain break over, I might put up that branch tomorrow
[22:08] <blackboxsw> https://paste.ubuntu.com/p/yXfcQVbX2n/
[22:43] <blackboxsw> meh couldn't help it https://github.com/canonical/cloud-init/pull/575
[22:45] <blackboxsw> johnsonshi: if you have time to resolve the minor comments on https://github.com/canonical/cloud-init/pull/549/files we can land that
[22:46] <blackboxsw> (like dropping the unit test and adding a comment about an example vm flavors that exemplifies mlx5_core vs mlx4_core driver
[22:46] <johnsonshi> blackboxsw: Sure! Thanks for the ping!
[22:46] <blackboxsw> no worries