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:02 |
minimal | in June last year Linode indicated they were working on "Providing support for Cloud Init and a Metadata Service" | 17:03 |
holmanb | minimal: nothing specific to Linode in upstream codebase right now, so it doesn't look like it. | 17:37 |
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:40 |
holmanb | minimal: related - https://www.linode.com/community/questions/10822/does-linode-support-cloud-init-on-linode-creation | 17:42 |
minimal | holmanb: yeah I saw that | 17:43 |
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:55 |
blackboxsw | It's curious enough that it may get me to setup that free acount to poke around | 18:56 |
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:06 |
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:07 |
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:08 |
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:11 |
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:13 |
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:15 |
blackboxsw | bah, that doesn't sound so good at all. :/ stinks when dynamics affect ability of good people | 19:16 |
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:17 |
blackboxsw | yeah that kindof stuff is caustic to open-source projects. They/we need all the help we can get. | 19:30 |
holmanb | minimal: sorry to hear that :( | 19:35 |
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: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 worked | 19: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/* branch | 19:51 |
holmanb | blackboxsw: ack, thanks! | 19:52 |
holmanb | blackboxsw: b3d9acddd352f2 isn't in ubuntu/devel then, so that needs to be added to ubuntu/devel, right? | 19:56 |
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:57 |
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:58 |
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> | 19:59 |
holmanb | @blackboxsw ah I see, thanks for clearing that up | 20:03 |
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:04 |
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 | 20:24 |
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:45 |
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 | 21:48 |
blackboxsw | holmanb: thanks on impish: https://github.com/canonical/cloud-init/pull/1284#pullrequestreview-890454703 | 22:50 |
ubottu | Pull 1284 in canonical/cloud-init "Ubuntu/impish SRU" [Merged] | 22:50 |
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:51 |
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:52 |
holmanb | +1 thanks blackboxsw | 22:53 |
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:54 |
blackboxsw | out/*changes should be an artifact of running `build-package` from your ubuntu/impish branch | 22:55 |
holmanb | blackboxsw: will do | 22:56 |
holmanb | odd that it puts the artifacts outside the directory (in ../out/) | 22:57 |
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. | 22:58 |
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:01 |
blackboxsw | hrm I'm seeing a number of diffs in ubuntu/focal branches. double checking my work | 23:02 |
holmanb | I can't say I'm a fan of that, but I don't care that much - mostly surprised really | 23:03 |
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:27 |
blackboxsw | holmanb: and a question about bionic, do you want to correct formatting in apport-launcher for this PR or separate PR | 23:33 |
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:35 |
blackboxsw | holmanb: looks great. building and testing now | 23:36 |
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:43 |
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:44 |
holmanb | I think I've fixed the various issues, will finish tomorow if needed | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!