[17:02] <minimal> anyone know about Linode support for cloud-init, specifically if there's a DataSource that currently supports it?
[17:02] <minimal> according to think article: https://www.linode.com/blog/linode/celebrating-18-years/
[17:03] <minimal> in June last year Linode indicated they were working on "Providing support for Cloud Init and a Metadata Service"
[17:37] <holmanb> minimal: nothing specific to Linode in upstream codebase right now, so it doesn't look like it.
[17:40] <minimal> yeah 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 yet
[17:42] <holmanb> minimal: related - https://www.linode.com/community/questions/10822/does-linode-support-cloud-init-on-linode-creation
[17:43] <minimal> holmanb: yeah I saw that
[18:55] <blackboxsw> interesting. 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:56] <blackboxsw> It's curious enough that it may get me to setup that free acount to poke around
[19:06] <minimal> blackboxsw: 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] <minimal> also there's no mention of what /etc/cloud/cloud.cfg contains with regard to enabled DataSources
[19:06] <blackboxsw> right, I was thinking either some images there may come with cloud-init pre-installed. or derivatives from a golden image someone created.
[19:06] <minimal> blackboxsw: I'm the Alpine cloud-init maintainer BTW
[19:07] <blackboxsw> minimal: 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:08] <blackboxsw> minimal: 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 to
[19:08] <minimal> Linode do their own Alpine image AFAIK, just not clear if they, rather than the reporter, has added c-i to the image
[19:08] <blackboxsw> +1
[19:08] <minimal> I 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:11] <blackboxsw> that 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:13] <minimal> I'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 current
[19:13] <blackboxsw> minimal: 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:15] <minimal> blackboxsw: 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] <blackboxsw> Yeah 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 stages
[19:15] <minimal> so I might give up my Alpine cloud-init and cloud-utils maintainership
[19:16] <blackboxsw> bah, that doesn't sound so good at all. :/ stinks when dynamics affect ability of good people
[19:17] <minimal> yeah, 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 community
[19:30] <blackboxsw> yeah that kindof stuff is caustic to open-source projects. They/we need all the help we can get.
[19:35] <holmanb> minimal: sorry to hear that :(
[19:36] <minimal> its 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 it
[19:36] <minimal> s/store/story/
[19:50] <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 worked
[19:51] <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/* branch
[19:52] <holmanb> blackboxsw: ack, thanks!
[19:56] <holmanb> blackboxsw:  b3d9acddd352f2 isn't in ubuntu/devel then, so that needs to be added to ubuntu/devel, right?
[19:57] <holmanb> or did you mean the commit before b3d9acddd352f2?
[19:57] <blackboxsw> holmanb: no sorry for lack of clarity. b3d9acddd352f2 is in upstream/main
[19:57] <blackboxsw> so new-upstream-snapshot we want to pull down from the same commit listed  in main that ubuntu/devel pulled down 
[19:58] <blackboxsw> so 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:59] <blackboxsw> which means for SRU we can only snapshot up until (and including) that commit
[19:59] <blackboxsw> I 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>
[20:03] <holmanb> @blackboxsw ah I see, thanks for clearing that up
[20:04] <blackboxsw> when <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:24] <holmanb> blackboxsw:yep, I was just looking at the wrong branch. b3d9a comes after the release in main, but before the release on ubuntu/devel
[21:45] <blackboxsw> sorry 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:48] <blackboxsw> and 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 way
[22:50] <blackboxsw> holmanb: thanks on impish: https://github.com/canonical/cloud-init/pull/1284#pullrequestreview-890454703
[22:51] <blackboxsw> I 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 good
[22:52] <blackboxsw> I can also see in #ubuntu-release IRC channel "), completed with 4 local objects.
[22:52] <blackboxsw> To github.com:canonical/cloud-init.git
[22:52] <blackboxsw>    c593ed2c..47d75126  HEAD -> ubuntu/impish
[22:52] <blackboxsw>  * [new tag]           ubuntu/22.1-1-gb3d9acdd-0ubuntu1_21.10.1 -> ubuntu/22.1-1-gb3d9acdd-0ubuntu1_21.10.1" 
[22:52] <blackboxsw> stike 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] <blackboxsw> so the ubuntu-release bot says it found our upload
[22:53] <holmanb> +1 thanks blackboxsw
[22:54] <blackboxsw> holmanb: 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:55] <blackboxsw> out/*changes should be an artifact of running `build-package` from your ubuntu/impish branch
[22:56] <holmanb> blackboxsw: will do
[22:57] <holmanb> odd that it puts the artifacts outside the directory (in ../out/)
[22:58] <blackboxsw> after 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 think
[22:58] <blackboxsw> yes the tooling "takes some liberties" with output directories etc.
[23:01] <blackboxsw> the intent is to separate that from your working directory to avoid collisions if your were running other tooling directly during testing etc.
[23:02] <blackboxsw> hrm I'm seeing a number of diffs in ubuntu/focal branches. double checking my work
[23:03] <holmanb> I can't say I'm a fan of that, but I don't care that much - mostly surprised really
[23:27] <blackboxsw> holmanb: sorry I'm seeing extra upstream/main commits in the ubuntu/focal branch that go past `integration tests: fix Azure failures (#1269)`
[23:27] <blackboxsw> I think we need a `new-upstream-snapshot b3d9acddd352f2` for that branch
[23:27] <holmanb> blackboxsw: looking
[23:33] <blackboxsw> holmanb: and a question about bionic, do you want to correct formatting in apport-launcher for this PR or separate PR
[23:35] <holmanb> @blackboxsw I'll do that in this PR.
[23:35] <holmanb> blackboxsw: updated the focal branch with `new-upstream-snapshot b3d9acddd352f2` plus format fixes
[23:36] <blackboxsw> holmanb: looks great. building and testing now
[23:43] <blackboxsw> holmanb: I missed a spelling typo on d/changelog line 90 that cause a lintian warning.
[23:43] <blackboxsw> if you can change that W: cloud-init: spelling-error-in-changelog propery property
[23:44] <blackboxsw> either 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:54] <holmanb> I think I've fixed the various issues, will finish tomorow if needed