[03:20] <Code_Bleu> I have created images using packer and install cloud-init on them because I use the image on vmware and in AWS.  I've recently discovered an issue when rebooting my vmware server that it replaces my /etc/sysconfig/network-scripts/ifcfg-XXXXX file and makes it dhcp and causes the server to be unavailable
[03:21] <Code_Bleu> I was reading about some "cache" feature and was wondering how I can verify that the image has been created correctly?  I feel like its acting like a "first boot" on ever reboot.
[04:04] <Code_Bleu> SYN
=== vrubiolo1 is now known as vrubiolo
[11:43] <hackers> howdy
[11:57] <hackers> so what's with this init systemn? I dn't quite gget its main reson to live
[12:39] <meena> hackers: cloud-init isn't an init system. it's a provisioning systems for cloud servers. actually, *the* provisioning system
[12:39] <meena> I'm not aware of any others
[14:23] <otubo> smoser: do you have time to discuss that bz? Figured out all of it marked as private, but I can share the "non sensitive" information of it.
[14:25] <otubo> smoser: this might have all the info you were wondering on the email: https://pastebin.com/Q1C1sBZg
[14:27] <otubo> smoser: basically /dev/mapper/rootvg-rootlv is failing to be resized (even with cloud-utils-0.32) because cloud-init can't find its part number from sysfs.
[14:28] <smoser> otubo: so cloud-init will have to somehow realize that / filesystem is on rootvg-rootlv
[14:28] <smoser> and then realize that rootvg-rootlv is part of VG 'rootvg'
[14:29] <smoser> and *then* that rootvg contains PV sdb2
[14:29] <smoser> and call `growpart /dev/sdb 2`
[14:29] <smoser> (and really, *should* look at all the PVs that are part of that VG and if they are on partitioned block devices call growpart for each)
[14:30] <otubo> smoser: don't we need to actually grow /dev/mapper/rootvg-rootlv after we grow the whole /dev/sdb2?
[14:30] <otubo> oh
[14:30] <smoser> growpart just grows part
[14:32] <smoser> its not obviuos what the "right thing to do" is in your scenario
[14:32] <smoser> well, maybe its obvious there... but with lvm, the change in the PV needs to happen.
[14:33] <smoser> and then you could use that extra space with any of the LVs on rootvg
[14:33] <smoser> (or create a new lv)
[14:33] <smoser> its not obvious that the right thing is "extend the rootlv to use all the space available"
[14:34] <smoser> that lsblk is good though. thanks for providing that.
[14:37] <otubo> smoser: OK, I think you gave me all the info I needed. Just need to connect the dots here. Thanks! :) Also, not related to that, any chance to merge https://github.com/canonical/cloud-init/pull/685 ?
[14:40] <smoser> otubo: i just hit 'update branch'
[14:40] <smoser> it has to run test
[14:40] <smoser> then if i'm still here and remember, i'll hit 'merge'
[14:40] <smoser> or Odd_Bloke  or someone else can. (odd_bloke already ACK'd)
[14:42] <otubo> smoser: thanks a lot :)
[14:48] <otubo> smoser: just going back really quick on the partition issue, is correct to assume most LV are unpartitioned devices? If I get to identify the rootfs, grow its correspondent /dev/sdbX, even though I can't grow the LV because it doesn't have a part number.
[14:48] <otubo> It will probably need to be treated a little different, using LVM tools to enlarge, etc.
[14:49] <smoser> i would thin it would be odd to partition a logical volume
[14:49] <smoser> it is possible
[14:50] <smoser> i wonder if lvm would recognize or not... if i added an lv, and partitioned that, and added the partition to the VG as a PV.
[14:53] <otubo> smoser: my point here is: If gropart is only to grow part, how can it work on LVM partitions? Growpart will resize the whole /dev/sdbX, but LVM doesn't know anything about it.
[14:54] <otubo> Does it make sense to think that way?
[15:00] <otubo> I mean you'll probably need to call LVM stuff anyways, no matter the scenario.
[15:40] <otubo> smoser: I'll have to leave now, but feel free to leave a message on IRC (by proxy is always up) or respond by email :) Thanks for the help so far!
[15:42] <Odd_Bloke> falcojr: I've just opened https://github.com/canonical/cloud-init/pull/702 to start a conversation about test selection based on OS/release; we need something like this for the SRU, so if you could take a look so we can chat about it today at some point, that'd be great!
[15:44] <falcojr> I'll take a look
[15:55] <smoser> otubo: well.. the change i made under bug 1799953 is for growpart to call 'lvm pvresize' if the partition that it grew is part of a pv.
[15:55] <ubot5> bug 1799953 in cloud-init "growpart does not work for lvm" [Medium,Triaged] https://launchpad.net/bugs/1799953
[15:56] <smoser> that *does* seem the obvious right thing to do.  There was exactly one user of a partition (the PV) and we grew the partition, so it makes sense to let the only user of that partition know about it.
[15:57] <smoser> one could argue that growpart didn't need to do that, as it doesnt call 'resizefs' itself if there is a fs on it, and thus the lvresize should be left to the caller of growpart.  but no one argued that when i added the lvresize.
=== ijohnson is now known as ijohnson|lunch
[18:51] <blackboxsw> Sorry folks, it took me a while to get cloud-init status notes together.....
[18:54] <blackboxsw> #startmeeting cloud-init status meeting && office hours
[18:54] <meetingology> Meeting started Tue Dec  1 18:54:54 2020 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[18:54] <meetingology> Available commands: action commands idea info link nick
[18:57] <blackboxsw> community-notice: cloud-init async status is scheduled for today. delayed a bit as it took a while to create the post for this meeting. Details status updates for cloud-init are available in discourse at https://discourse.ubuntu.com/t/cloud-init-status-12-01-20/19604
[18:57] <blackboxsw> #link https://discourse.ubuntu.com/t/cloud-init-status-12-01-20/19604
[19:00] <blackboxsw> This meeting has moved to an async format, where we basically will host "office hours" and cloud-init devs should be available for questions and discussions for those who are available at this time. For others in timezones that make this meeting time a challenge, we can hold conversations or questions about the status updates on the discourse post above.
[19:01] <blackboxsw> The spotlight for this status meeting is that updates 20.4 was released  Nov 24, and published to Ubuntu 21.04 (Hirsute). It should be in Ubuntu 21.04 cloud-images at the moment.
[19:02] <blackboxsw> We also have just started the SRU process for cloud-init into Ubuntu Xenial, Bionic, Focal and Groovy per this bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1905599
[19:02] <ubot5> Ubuntu bug 1905599 in cloud-init (Ubuntu Groovy) "sru cloud-init (20.3-2 to 20.4-0ubuntu1) Xenial, Bionic, Focal, and Groovy" [Undecided,New]
[19:02] <blackboxsw> #link https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1905599
[19:04] <blackboxsw> SRU verification is a lot of work and we will be working down our verification items by creating cloud-init new tests/integration_tests for a lot of this "manual" verification work. We have made our SRU trello board public which tracks our verification efforts at
[19:04] <blackboxsw> #link https://trello.com/b/hP1KfPeU/sru-cloud-init-204
[19:06] <blackboxsw> Our specific verification work items are listed in this trello card
[19:06] <blackboxsw> #link https://trello.com/c/cw8YUo1o/35-preliminary-write-integration-tests-for-commits-in-sru
[19:07] <blackboxsw> we welcome anyone interested in involvement in SRU verification, if there is  work item, bug or feature that you are interested in from that card, let us know and we can assign that work item to you and help shepherd you through the integration test writing.
[19:09] <blackboxsw> .... thus concludes today's broadcast :). The floor is open for any discussions about features/bugs/life etc. In the absence of discussion, we'll be sorting the SRU upload requests of 20.4 into and writing integration tests for the existing features to validate
[19:23] <meena> how is the SRU going so far, blackboxsw?
[19:29] <blackboxsw> meena: Odd_Bloke and falcojr are chugging away at writing integration tests at the moment for 4 of 19 manual work items here.  https://trello.com/c/cw8YUo1o/35-preliminary-write-integration-tests-for-commits-in-sru
[19:33] <blackboxsw> falcojr and, I need to queue an Ubuntu groovy upload into Ubuntu's groovy-proposed apt-suite to officially allow folks to run against cloud-init 24.0 on each Ubuntu series
[19:34] <blackboxsw> so plan is finish that upload today, at which point we are going to work in parallel on cloud-init verification integration test tasks.
[19:47] <Odd_Bloke> I've been diverted into writing some integration test framework support for the test I'm working on.
[19:49] <blackboxsw> Odd_Bloke: or falcojr minor tweak to the bionic upload, I found a bug in log2dch https://github.com/canonical/cloud-init/pull/703
[19:50] <blackboxsw> bdmurray has rejected bionic so we can get this changelog fix.
[19:50] <blackboxsw> once approved I can re-queue the bionic upload
=== cpaelzer__ is now known as cpaelzer
[20:42] <blackboxsw> falcojr: I've updated https://github.com/canonical/uss-tableflip/pull/68.  So new-upstream-snapshot/log2dch redacts LP: #\d+"  -> LP:\d+ from entries added to debian/changelog. You and I can regenerate ubuntu/groovy PR with the following: git checkout ubuntu/groovy; git reset 7fe46f454cf9b081c30398626954d31103ace764; git checkout .; git clean -fd; new-upstream-snapshot --first-sru --sru-bug 1905599
[20:42] <blackboxsw> 47f4229ebcef9f83df8b549bb869a2dbf6dff17c
[20:42] <ubot5> bug 1905599 in cloud-init (Ubuntu Groovy) "sru cloud-init (20.3-2 to 20.4-0ubuntu1) Xenial, Bionic, Focal, and Groovy" [Undecided,New] https://launchpad.net/bugs/1905599
[20:46] <blackboxsw> I've pushed up https://github.com/blackboxsw/cloud-init/tree/ubuntu/groovy as reference for my output
[20:49] <blackboxsw> rharper: smoser: Odd_Bloke: falcojr, I'm looking for input on how best to resolve this issue.
[20:50] <blackboxsw> I accepted a cloud-init new-upstream-snapshot accidentally for ubuntu/groovy that included two commits past 20.4 release. resulting in 20.4.3 pkg version.
[20:50] <blackboxsw> and I pushed the upstream/ubuntu/groovy
[20:50] <blackboxsw> daily build recipe built that and uploaded to cloud-init-daily for groovy
[20:50] <blackboxsw> we ultimately only want to SRU 20.4.0 to groovy
[20:51] <blackboxsw> which is what we are doing for X, B and F (20.4.0~XX.YY)
[20:52]  * blackboxsw wants to --force push to upstream/ubuntu/groovy with the downrev'd 20.4.0-0ubntu1~20.10. but daily builds for our cloud-init ppa will not actually be able to upload that to the daily PPA because package version will be lower than 20.4.3.
[20:53] <blackboxsw> and it's naughty to force push to the ubuntu/groovy branch.... but the only consumer is the daily build recipe
[20:56] <blackboxsw> well, our build recipe into daily PPA for groovy does encode the commit revno in the builds. https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-groovy so maybe this is a non-issue
[20:57] <blackboxsw> because it doesn't actually rely on the debian/changelog 20.4.3 version name
[21:00] <blackboxsw> #endmeeting
[21:00] <meetingology> Meeting ended Tue Dec  1 21:00:19 2020 UTC.
[21:00] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-12-01-18.54.moin.txt
[21:00] <blackboxsw> forgot to close that out earlier
[21:04] <falcojr> blackboxsw: I still have diffs compared to yours
[21:04] <falcojr> https://paste.ubuntu.com/p/5wg8d3RpBJ/
[21:05] <falcojr> I did the git reset, but looks like mine is still further ahead?
[21:06] <blackboxsw> falcojr: right, IRC separated my command suggestion: did your new-upstream-snapshot call end with 47f4229ebcef9f83df8b549bb869a2dbf6dff17c ?
[21:07] <blackboxsw> falcojr:  and did you also checkout/refresh  https://github.com/canonical/uss-tableflip/pull/68.
[21:07] <blackboxsw> to get the new-upstream-snapshot and log2dch fixes?
[21:08] <falcojr> derp, it was the first suggestion...I'll have another go at it :)
[21:13] <falcojr> hmmmm, same result
[21:16] <blackboxsw> falcojr: in your local branch upstream/ubuntu/groovy  did you `git reset 7fe46f454cf9b081c30398626954d31103ace764; git checkout .; git clean -fd;`  to reset to the previously released version of cloud-init 20.3-15  on that branch?
[21:16] <falcojr> yes
[21:16] <falcojr> it seems to be going beyond the 47f4229 commit
[21:16] <blackboxsw> hrm. and it seems your commit log is > endpoint
[21:16] <blackboxsw> yeah
[21:16] <falcojr> I ran new-upstream-snapshot --first-sru --sru-bug 1905599 47f4229ebcef9f83df8b549bb869a2dbf6dff17c
[21:16] <ubot5> bug 1905599 in cloud-init (Ubuntu Groovy) "sru cloud-init (20.3-2 to 20.4-0ubuntu1) Xenial, Bionic, Focal, and Groovy" [Undecided,New] https://launchpad.net/bugs/1905599
[21:21] <rharper> blackboxsw: yeah, see your ping,  w.r.t ubuntu/groovy being ahead of what's published; that's not a huge deal;   can we just revert the two commits in the ubuntu/groovy branch that's ahead of release?  IMO, it's OK, if daily/groovy isn't working until a new groovy upload;  I don't think anything production consumes daily cloud-init ppa , maybe CI?
[21:26] <blackboxsw> rharper: +1 CI consumes groovy PPA, but the PPA won't break. it just will contain a pkg build that contains the 2 extra commits from master until we SRU again into groovy. the ubunut/groovy branch though would be two commits less than that daily PPA deb
[21:26] <blackboxsw> falcojr: I'm surprise that your debian/changelog header is saying "New upstream snapshot" instead of "New upstream release"
[21:27] <blackboxsw> I'm re-running now. falcojr up for a hangout to sort what might be a config issue on either your or my side?
[21:27] <falcojr> Sure
[21:48] <Odd_Bloke> blackboxsw: I think the PPA versions are based on git info for master, not on the packaging branches.  "# git-build-recipe format 0.4 deb-version {latest-tag}-{revno}-g{git-commit}-0ubuntu1+{revno:ubuntu-pkg}~trunk"
[21:50] <Odd_Bloke> If we reset I _think_ that we'll get `20.4-2677-gf550c876-0ubuntu1+1861~trunk~ubuntu20.10.1` (instead of `20.4-2677-gf550c876-0ubuntu1+1863~trunk~ubuntu20.10.1`) which will break until the next commit to master.
[21:50] <blackboxsw> +1 Odd_Bloke so build recipe revno should update anyway and not be affected by use "decrementing" the debian/changelog entry provided in ubuntu/groovy
[21:50] <Odd_Bloke> At which point 20.4-2678-* will supersede both of those.
[21:51] <Odd_Bloke> Revno won't update with your reset, so builds will break temporarily, I think.
[21:51] <blackboxsw> right, so *if* our reset occurs, the daily PPA  may contain 24.0 + 3 commits from master until the next time we perform a new-upstream-snapshot into ubuntu/groovy.
[21:51] <Odd_Bloke> Nope, only until the next master commit.
[21:52] <blackboxsw> ahhhhhhhh TIL (I was wondering how revno was gen'd )
[21:52] <blackboxsw> ok I thought it was an offset within the specific ubuntu/groovy branch, not related to upstream
[21:52] <blackboxsw>  /master
[21:52] <Odd_Bloke> When you reset ubuntu/groovy the revnos in the version will go from (2677, 1863) to (2677, 1861); this will break.  When the next commit to master happens, the revnos will be (2678, 1861) which is greater than the current (2677, 1863) and so will upload successfully.
[21:53] <blackboxsw> well that sounds awesome. so I should review your integration test changes you are saying :) ?
[21:56] <blackboxsw> "All variables other than time are derived from a particular branch. By default they use the base branch (eg. {revno}), but they can also use a named branch (eg. {revno:packaging}). "   from https://help.launchpad.net/Packaging/SourceBuilds/Recipes  ok. so "base branch == master"
[22:02] <smoser> are you dealing with the auto version numbers on recipes ?
[22:02] <smoser> you can just delete the bad ones from the daily archive i'm pretty sure.
[22:02] <smoser> and then be patient
[22:17] <Odd_Bloke> falcojr: Just pushed up a reworking of https://github.com/canonical/cloud-init/pull/702 based on your feedback; I'm going to go and reply to some of your comments if they still apply.