[09:22] Hello. [09:23] Which lxd vm images have cloud init installed? [09:23] I want it to set a password to be able to login. [09:54] fling: might be easier to ask in #lxd [10:02] no [10:16] heh [10:17] i could try to reverse engineer an answer from our integration tests, but i am swamped in work / child care / house work,,, [14:31] rharper, any further commets ----> https://github.com/canonical/cloud-init/pull/647/ [14:34] fling: The official Ubuntu images from the `ubuntu:` remote will have cloud-init installed. One thing to note is that the 16.04 (Xenial Xerus) images there have a kernel too old for LXD's VM agent to work, so if you need xenial images then you should consider using `images:xenial/amd64/cloud`. [14:35] Odd_Bloke: I don't know what version I need. Which one is the best? [14:36] fling: If you don't know which Ubuntu release you want, I would suggest the most recent LTS, 20.04 LTS (Focal Fossa). (So `ubuntu:focal` for your image name.) [14:38] thanks! [14:39] :) [17:20] AnhVoMSFT: thanks for circling pack on https://github.com/canonical/cloud-init/pull/670 and unit tests. I've approve rebased and awaiting CI run and will land the dmesg logging === ijohnson is now known as ijohnson|lunch [18:05] rharper, updated with suggested change ----> https://github.com/canonical/cloud-init/pull/647/ [18:05] vijayendra: looking too at the backlog of conversation on that PR and the previous related caching PR discussion. [18:06] though obviously, I'm late to the party there . [18:07] blackboxsw, sure. Let me know any suggestion on the PR [18:10] Thanks @blackboxsw [18:16] otubo: are you around ? [18:19] rharper, all good from your side? ---> https://github.com/canonical/cloud-init/pull/647/ [18:39] https://github.com/canonical/cloud-init/pull/670 merged. #647 is fairly sensitive, since it potentially changes behavior on all clouds transitioning across init-local -> init-network stage. just want to triple check this behavior context to make sure we aren't exposed on other platforms === ijohnson|lunch is now known as ijohnson [19:46] blackboxsw: re: 647 (fallback DS); I think it's good to go; however; I would not put this in yet; wait till after SRU is cut, then it can bake in -devel before the next release; [19:48] rharper: thanks for that. yeah it feels like there could be a number of corner cases that could cause fallout that we probably don't want to tarnish/impact the imminent upstream release and or SRUs shortly thereafter. [19:49] I don't feel that there are edge cases ... but; I'd rather we test things in -devel before we push it into SRU path; [20:16] Hey all, it's been a while, I was wondering what would be the best way to upgrade to cloud-init 20.3 on debian system? [20:17] ahosmanMSFT, are you looking for a downloadable package? and by debian system do you mean running Debian itself? [20:18] Yes running Debian, we are currently running cloud-init 20.2 [20:18] Yeah Debian seems to only have 20.2 even in sid: https://packages.debian.org/sid/cloud-init [20:18] So it's not possible for now ? [20:18] well you could build the package yourself [20:19] How can I go about doing this [20:19] build the package and testing it [20:20] https://github.com/canonical/cloud-init/blob/master/packages/bddeb [20:21] that script will build a deb from the current tree, so it won't be exactly like what Debian builds, but would get you a good start [20:21] Thanks, I'll let you know how it goes [20:22] Will this build the latest package (ie 20.3) [20:23] if you are trying to test things out, my suggest is to check out master and build that [20:24] which would effectively build what was in at 20.3 + new things in prep for 20.4 [20:26] I see, so if I checkout the master branch then run that script I'll have a package. For testing I'll verify it with our e2e tests from the provisioning team [20:28] that sounds like a good workflow [22:10] I pushed up https://github.com/canonical/cloud-init/pull/679 earlier, which is the first of the integration tests for the coming release/SRU. [22:11] I'd appreciate a review, but also interested to hear what folks think about the pytest mark for the SRU.