/srv/irclogs.ubuntu.com/2022/02/22/#cloud-init.txt

minimalanyone know about Linode support for cloud-init, specifically if there's a DataSource that currently supports it?17:02
minimalaccording to think article: https://www.linode.com/blog/linode/celebrating-18-years/17:02
minimalin June last year Linode indicated they were working on "Providing support for Cloud Init and a Metadata Service"17:03
holmanbminimal: nothing specific to Linode in upstream codebase right now, so it doesn't look like it.17:37
minimalyeah its kind of strange to announce that 8 month ago and there to be no sign of of any code changes beginning to be submitted yet17:40
holmanbminimal: related - https://www.linode.com/community/questions/10822/does-linode-support-cloud-init-on-linode-creation17:42
minimalholmanb: yeah I saw that17:43
blackboxswinteresting. liked the response https://www.linode.com/community/questions/10822/does-linode-support-cloud-init-on-linode-creation#answer-78917   But, given the additional response about Alpine linux falling back to DataSourceNone, I'm thinking this is a not-yet kinda thing.  Writing an IMDS is hard, but I'm suprised their announcement called attention to cloud-init without some artifacts to show for it.18:55
blackboxswIt's curious enough that it may get me to setup that free acount to poke around18:56
minimalblackboxsw: from that article is *sounds* like their Alpine 3.15 image has cloud-init bundled but not 100% clear (its possible the person in question add it to create a derivative image)19:06
minimalalso there's no mention of what /etc/cloud/cloud.cfg contains with regard to enabled DataSources19:06
blackboxswright, I was thinking either some images there may come with cloud-init pre-installed. or derivatives from a golden image someone created.19:06
minimalblackboxsw: I'm the Alpine cloud-init maintainer BTW19:06
blackboxswminimal: totally. on you being Alpine. I was half wondering if it was your last comment in the thread initially then saw username looked nothing like you :)19:07
blackboxswminimal: I was also wondering if you had worked with Linode to help provide some semblance of Alpine images that happened to contain cloud-init that the user there had referred to19:08
minimalLinode do their own Alpine image AFAIK, just not clear if they, rather than the reporter, has added c-i to the image19:08
blackboxsw+119:08
minimalI always found Linode's stackscript approach "weird" (it apparently replaces getty in an OS with their own stuff for 1st boot and then puts the getty back afterwards)19:08
blackboxswthat feels funky. yeah, since I haven't played on that platform, it sounds like a good little play day to poke around and see what's under the hood there.19:11
minimalI've seen someone in the past hack in c-i support by having a stackscript then run c-i but that always seemed like a swimming against the current19:13
blackboxswminimal: BTW thanks for all the effort here for cloud-init. It's been very helpful to have other active devs in channel fielding questions and providing context.19:13
minimalblackboxsw: unfortunately not sure how much I'll be doing that in future, I might be giving up my Alpine involvement (issues with a member of the Alpine community)19:15
blackboxswYeah I think one of the comments aluded to just that. stackscript with base64encoded data that ultimately is a script that installs cloud-init and triggers different boot stages19:15
minimalso I might give up my Alpine cloud-init and cloud-utils maintainership19:15
blackboxswbah, that doesn't sound so good at all. :/ stinks when dynamics affect ability of good people19:16
minimalyeah, even though its only one individual he's callked me out a few times in channels and its ruining my "enjoyment" of participating in Alpine community19:17
blackboxswyeah that kindof stuff is caustic to open-source projects. They/we need all the help we can get.19:30
holmanbminimal: sorry to hear that :(19:35
minimalits not just the store of opensource, its the story of life, I guess its just more annoying/frustrating when its something you're putting you own time/effort into rather getting paid for it19:36
minimals/store/story/19:36
holmanb@blackboxsw: thanks for the ec2 integration test fix, I tested the s/aws/ec2/g PR by rebasing locally on the ec2 integration test fix (PR #1291) and that worked19:50
blackboxsw@holmanb +1 great. I just got you a review on ubuntu/impish. https://github.com/canonical/cloud-init/pull/1284#pullrequestreview-890288686   I think we just need to snapshot the same upstream commitish from each ubuntu/* branch19:51
holmanbblackboxsw: ack, thanks!19:52
holmanbblackboxsw:  b3d9acddd352f2 isn't in ubuntu/devel then, so that needs to be added to ubuntu/devel, right?19:56
holmanbor did you mean the commit before b3d9acddd352f2?19:57
blackboxswholmanb: no sorry for lack of clarity. b3d9acddd352f2 is in upstream/main19:57
blackboxswso new-upstream-snapshot we want to pull down from the same commit listed  in main that ubuntu/devel pulled down 19:57
blackboxswso at the time of us originally calling new-upstream-snapshot when we updated ubuntu/devel, b3d9acddd352f2 was a most recent  commit in tip of main 19:58
blackboxswwhich means for SRU we can only snapshot up until (and including) that commit19:59
blackboxswI basically back into that commitish by looking at most recent upstream commit that was "snapshotted" into ubuntu/devel and find that commit represented in upstream/main and perform new-upstream-snapshot <upstream_commitish_from_main>19:59
holmanb@blackboxsw ah I see, thanks for clearing that up20:03
blackboxswwhen <upstream_commitish_from_main> is omitted, the new-upstream-snapshot script ends up just grabbing whatever the latest cached commit is as seen in your local copy of upstream/main. So if you were working from a stale git remote it'd default to the whatever it thinks is most recent  commit 20:04
holmanbblackboxsw:yep, I was just looking at the wrong branch. b3d9a comes after the release in main, but before the release on ubuntu/devel20:24
blackboxswsorry holmanb I don't quite understand. b3d9a is the last commit that was new-upstream-snapshotted (merged) into ubuntu/devel. When we run `new-upstream-snapshot <commit>` ultimately a `git merge <commit>` is run so all upstream/main commits up until <commit> are then merged into your ubuntu/impish.21:45
blackboxsw We don't want to `new-upstream-snapshot <commit-from-ubuntu/devel>` because that could contain other commits that only relate to jammy 21:45
blackboxswand right, per your "before release on ubuntu/devel" there were a couple of commits you landed to jammy packaging  like debian/changelog changes for that official upload/release. Those commits we don't care about in ubuntu/impish as new-upstream-snapshot will add them for us too. In ubuntu/devel too is your 6dc3b914d045e664325e2379ccf91928794728be too (which we haven't released yet to Jammy any way21:48
blackboxswholmanb: thanks on impish: https://github.com/canonical/cloud-init/pull/1284#pullrequestreview-89045470322:50
ubottuPull 1284 in canonical/cloud-init "Ubuntu/impish SRU" [Merged]22:50
blackboxswI just performed the last dput and tag steps of https://github.com/canonical/uss-tableflip/blob/main/doc/ubuntu_release_process.md#upstream-snapshot-process so should be good22:51
blackboxswI can also see in #ubuntu-release IRC channel "), completed with 4 local objects.22:52
blackboxswTo github.com:canonical/cloud-init.git22:52
blackboxsw   c593ed2c..47d75126  HEAD -> ubuntu/impish22:52
blackboxsw * [new tag]           ubuntu/22.1-1-gb3d9acdd-0ubuntu1_21.10.1 -> ubuntu/22.1-1-gb3d9acdd-0ubuntu1_21.10.1" 22:52
blackboxswstike that:   "Unapproved: cloud-init (impish-proposed/main) [21.4-0ubuntu1~21.10.1 => 22.1-1-gb3d9acdd-0ubuntu1~21.10.1] (core, ubuntu-cloud)"22:52
blackboxswso the ubuntu-release bot says it found our upload22:52
holmanb+1 thanks blackboxsw22:53
blackboxswholmanb: to confirm that you have perms for uploading to our PPA: can you try performing `$ dput ppa:cloud-init-dev/proposed ../out/cloud-init_22.1-1-gb3d9acdd-0ubuntu1~21.10.1_source.changes`22:54
blackboxswout/*changes should be an artifact of running `build-package` from your ubuntu/impish branch22:55
holmanbblackboxsw: will do22:56
holmanbodd that it puts the artifacts outside the directory (in ../out/)22:57
blackboxswafter what appears to be a successful dput on the commandline you'll want to watch your email for a success or failure message from launchpad I think22:58
blackboxswyes the tooling "takes some liberties" with output directories etc.22:58
blackboxswthe intent is to separate that from your working directory to avoid collisions if your were running other tooling directly during testing etc.23:01
blackboxswhrm I'm seeing a number of diffs in ubuntu/focal branches. double checking my work23:02
holmanbI can't say I'm a fan of that, but I don't care that much - mostly surprised really23:03
blackboxswholmanb: sorry I'm seeing extra upstream/main commits in the ubuntu/focal branch that go past `integration tests: fix Azure failures (#1269)`23:27
blackboxswI think we need a `new-upstream-snapshot b3d9acddd352f2` for that branch23:27
holmanbblackboxsw: looking23:27
blackboxswholmanb: and a question about bionic, do you want to correct formatting in apport-launcher for this PR or separate PR23:33
holmanb@blackboxsw I'll do that in this PR.23:35
holmanbblackboxsw: updated the focal branch with `new-upstream-snapshot b3d9acddd352f2` plus format fixes23:35
blackboxswholmanb: looks great. building and testing now23:36
blackboxswholmanb: I missed a spelling typo on d/changelog line 90 that cause a lintian warning.23:43
blackboxswif you can change that W: cloud-init: spelling-error-in-changelog propery property23:43
blackboxsweither rebase and squash that commit on ubunut/focal and ubuntu/bionic and or introduce a separate commit 'update changelog' on those branches that'd be fine.23:44
holmanbI think I've fixed the various issues, will finish tomorow if needed23:54

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