Code_BleuI 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 unavailable03:20
Code_BleuI 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.03:21
=== vrubiolo1 is now known as vrubiolo
hackersso what's with this init systemn? I dn't quite gget its main reson to live11:57
meenahackers: cloud-init isn't an init system. it's a provisioning systems for cloud servers. actually, *the* provisioning system12:39
meenaI'm not aware of any others12:39
otubosmoser: 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:23
otubosmoser: this might have all the info you were wondering on the email: https://pastebin.com/Q1C1sBZg14:25
otubosmoser: 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:27
smoserotubo: so cloud-init will have to somehow realize that / filesystem is on rootvg-rootlv14:28
smoserand then realize that rootvg-rootlv is part of VG 'rootvg'14:28
smoserand *then* that rootvg contains PV sdb214:29
smoserand 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:29
otubosmoser: don't we need to actually grow /dev/mapper/rootvg-rootlv after we grow the whole /dev/sdb2?14:30
smosergrowpart just grows part14:30
smoserits not obviuos what the "right thing to do" is in your scenario14:32
smoserwell, maybe its obvious there... but with lvm, the change in the PV needs to happen.14:32
smoserand then you could use that extra space with any of the LVs on rootvg14:33
smoser(or create a new lv)14:33
smoserits not obvious that the right thing is "extend the rootlv to use all the space available"14:33
smoserthat lsblk is good though. thanks for providing that.14:34
otubosmoser: 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:37
smoserotubo: i just hit 'update branch'14:40
smoserit has to run test14:40
smoserthen if i'm still here and remember, i'll hit 'merge'14:40
smoseror Odd_Bloke  or someone else can. (odd_bloke already ACK'd)14:40
otubosmoser: thanks a lot :)14:42
otubosmoser: 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
otuboIt will probably need to be treated a little different, using LVM tools to enlarge, etc.14:48
smoseri would thin it would be odd to partition a logical volume14:49
smoserit is possible14:49
smoseri 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:50
otubosmoser: 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:53
otuboDoes it make sense to think that way?14:54
otuboI mean you'll probably need to call LVM stuff anyways, no matter the scenario.15:00
otubosmoser: 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:40
Odd_Blokefalcojr: 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:42
falcojrI'll take a look15:44
smoserotubo: 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
ubot5bug 1799953 in cloud-init "growpart does not work for lvm" [Medium,Triaged] https://launchpad.net/bugs/179995315:55
smoserthat *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:56
smoserone 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.15:57
=== ijohnson is now known as ijohnson|lunch
blackboxswSorry folks, it took me a while to get cloud-init status notes together.....18:51
blackboxsw#startmeeting cloud-init status meeting && office hours18:54
meetingologyMeeting started Tue Dec  1 18:54:54 2020 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.18:54
meetingologyAvailable commands: action commands idea info link nick18:54
blackboxswcommunity-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/1960418:57
blackboxsw#link https://discourse.ubuntu.com/t/cloud-init-status-12-01-20/1960418:57
blackboxswThis 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:00
blackboxswThe 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:01
blackboxswWe 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/190559919:02
ubot5Ubuntu 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/190559919:02
blackboxswSRU 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 at19:04
blackboxsw#link https://trello.com/b/hP1KfPeU/sru-cloud-init-20419:04
blackboxswOur specific verification work items are listed in this trello card19:06
blackboxsw#link https://trello.com/c/cw8YUo1o/35-preliminary-write-integration-tests-for-commits-in-sru19:06
blackboxswwe 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:07
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 validate19:09
meenahow is the SRU going so far, blackboxsw?19:23
blackboxswmeena: 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-sru19:29
blackboxswfalcojr 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 series19:33
blackboxswso plan is finish that upload today, at which point we are going to work in parallel on cloud-init verification integration test tasks.19:34
Odd_BlokeI've been diverted into writing some integration test framework support for the test I'm working on.19:47
blackboxswOdd_Bloke: or falcojr minor tweak to the bionic upload, I found a bug in log2dch https://github.com/canonical/cloud-init/pull/70319:49
blackboxswbdmurray has rejected bionic so we can get this changelog fix.19:50
blackboxswonce approved I can re-queue the bionic upload19:50
=== cpaelzer__ is now known as cpaelzer
blackboxswfalcojr: 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 190559920:42
ubot5bug 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/190559920:42
blackboxswI've pushed up https://github.com/blackboxsw/cloud-init/tree/ubuntu/groovy as reference for my output20:46
blackboxswrharper: smoser: Odd_Bloke: falcojr, I'm looking for input on how best to resolve this issue.20:49
blackboxswI 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
blackboxswand I pushed the upstream/ubuntu/groovy20:50
blackboxswdaily build recipe built that and uploaded to cloud-init-daily for groovy20:50
blackboxswwe ultimately only want to SRU 20.4.0 to groovy20:50
blackboxswwhich is what we are doing for X, B and F (20.4.0~XX.YY)20:51
* 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
blackboxswand it's naughty to force push to the ubuntu/groovy branch.... but the only consumer is the daily build recipe20:53
blackboxswwell, 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-issue20:56
blackboxswbecause it doesn't actually rely on the debian/changelog 20.4.3 version name20:57
meetingologyMeeting ended Tue Dec  1 21:00:19 2020 UTC.21:00
meetingologyMinutes:        http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-12-01-18.54.moin.txt21:00
blackboxswforgot to close that out earlier21:00
falcojrblackboxsw: I still have diffs compared to yours21:04
falcojrI did the git reset, but looks like mine is still further ahead?21:05
blackboxswfalcojr: right, IRC separated my command suggestion: did your new-upstream-snapshot call end with 47f4229ebcef9f83df8b549bb869a2dbf6dff17c ?21:06
blackboxswfalcojr:  and did you also checkout/refresh  https://github.com/canonical/uss-tableflip/pull/68.21:07
blackboxswto get the new-upstream-snapshot and log2dch fixes?21:07
falcojrderp, it was the first suggestion...I'll have another go at it :)21:08
falcojrhmmmm, same result21:13
blackboxswfalcojr: 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
falcojrit seems to be going beyond the 47f4229 commit21:16
blackboxswhrm. and it seems your commit log is > endpoint21:16
falcojrI ran new-upstream-snapshot --first-sru --sru-bug 1905599 47f4229ebcef9f83df8b549bb869a2dbf6dff17c21:16
ubot5bug 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/190559921:16
rharperblackboxsw: 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:21
blackboxswrharper: +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 deb21:26
blackboxswfalcojr: I'm surprise that your debian/changelog header is saying "New upstream snapshot" instead of "New upstream release"21:26
blackboxswI'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
Odd_Blokeblackboxsw: 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:48
Odd_BlokeIf 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/groovy21:50
Odd_BlokeAt which point 20.4-2678-* will supersede both of those.21:50
Odd_BlokeRevno won't update with your reset, so builds will break temporarily, I think.21:51
blackboxswright, 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_BlokeNope, only until the next master commit.21:51
blackboxswahhhhhhhh TIL (I was wondering how revno was gen'd )21:52
blackboxswok I thought it was an offset within the specific ubuntu/groovy branch, not related to upstream21:52
blackboxsw /master21:52
Odd_BlokeWhen 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:52
blackboxswwell that sounds awesome. so I should review your integration test changes you are saying :) ?21:53
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"21:56
smoserare you dealing with the auto version numbers on recipes ?22:02
smoseryou can just delete the bad ones from the daily archive i'm pretty sure.22:02
smoserand then be patient22:02
Odd_Blokefalcojr: 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.22:17

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!