[03:06] I reworked ubuntu/xenial patch ordering so it can be done without the rebasre [03:06] I reworked ubuntu/xenial patch ordering so it can be done without the rebase [16:02] blackboxsw: ubuntu/xenial branch approved [16:18] thanks rharper [16:42] rharper: I've pinged in ubuntu-release for both curtin and cloud-init uploads to xenial, bionic, [eoan] and focal [16:50] blackboxsw: nice, thanks! [16:59] lucasmoura and falcojr since uploads are queued for Ubuntu SRU testing to release into Xenial, Bionic, Eoan and Focal. we can start carving out verification tasks for next week for most of the major clouds. [17:00] basically we work from templates here https://github.com/cloud-init/ubuntu-sru [17:01] each cloud to which we have credentials, we run a set of upgrade verification scripts manually, per the examples here: https://github.com/cloud-init/ubuntu-sru/tree/master/sru-templates/manual [17:02] if you both have a cloud preference for your verification run, put your avatar on the related trello card from the SRU cloud-init 20.2 trello board [17:06] blackboxsw done, I will start with aws [17:07] excellent, I've uploaded a deb package for each series to https://launchpad.net/~cloud-init-dev/+archive/ubuntu/proposed [17:07] If the SRU team doesn't approve our pending and queued uploads into xenial|bionic|eoan|focal-proposed until Monday we can work with the 20.2 debs in our proposed PPA [17:08] in a lot of our verification scripts in https://github.com/cloud-init/ubuntu-sru/tree/master/sru-templates you'll see the ability to use our -proposed PPA instead of the official upstream *-proposed debian pocket [17:10] today I'm going to comb through the list of commits involved in this SRU upload to create a chit sheet of each functional change that we should verify separately before we say that cloud-init SRU verification is complete [17:28] hello, i'm add second interface, regenerate cloud-inid and seed.iso ( NoCloud format v1), after boot second interface down, how regenerate guest config? cloud-init clean -r work but wery hard way [18:22] Hi everyone! I'm not sure if cloud-init fits my use case, but here's what I'd like to do to do. I want to read an auth token from a filesystem, then use a HTTP datasource that requires auth (in-url or with 'Authorization' header). Is this possible to achieve without a custom datasource? [18:40] blackboxsw: https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-groovy ; this recipe references ubuntu/groovy (which won't be there until series-h is released, it should be ubuntu/devel ... [18:40] ahh right/correct thx rharper want me to fix it or you? [18:41] octoboar: I think so, the DataSourceMAAS does something similar, in the DataSourceMAAS, it provides an oauth token value, and then hit's the specified URL with the token [18:41] blackboxsw: I can fix [18:41] rharper: also drop ubuntu/daily/groovy [18:41] as that also won't exist until Ubuntu h [18:41] because we have no need until we are cherry-picking [18:41] blackboxsw: we should just delete it [18:41] we already have daily-ubuntu-devel building [18:41] rharper: yep, there is no ubuntu/daily/groovy branch [18:41] ahh right [18:42] right [18:42] delete the job [18:42] ok, I've left it at build-on-request [18:42] recipe rather [18:42] thanks [18:42] we'll need in 5 months [18:42] I'll send a note to paride [18:42] thanks [18:53] rharper: So I guess I could simulate DataSourceMAAS server. I'm going to check out this option. [18:53] Or could I use cloud.cfg: NoCloud: seedfrom: http://datasource/ [18:53] Generally I want to insert a token from a file into the datasource url at boot time, before cloud-init starts doing anything. [18:59] hrm [19:02] octoboar: another option would be to encode the token into a field specified in the smbios table, no file present but you can control the endpoint dynamically (which sounds like what you want more than oauth token) ? [19:03] like so, -smbios type=1,serial=ds=nocloud-net;s=http://10.10.0.1:8000/ -- see https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html [19:24] rharper: My scenario is kinda weird. I want to create an image for 'home lab' bare metal servers. Users would 1) copy the image to a disk, 2) put a personal auth token into a config on a special partition, 3) and then boot from the disk. [19:24] Hmm, so whatever datasource I use I need is to copy the token from my user-accessible config to cloud.cfg. Going to try to do this with systemd before cloud-init runs. === tds5 is now known as tds [22:07] rharper: for monday, we need to address the SRU_BLOCKERS in the current cloud-init SRU xenial: https://github.com/canonical/cloud-init/pull/406 [22:07] I added two quilt patches to properly disable the upstream behavior that we don't want to surface on xenial [22:08] if that looks good I'll quickly reflect those changes via git cherry-pick to bionic and eoan [22:19] blackboxsw: hrm, ok; xenial does not have netplan by default (but there are some exceptions, RAX I believe has netplan/systemd in their image, but I think it also has cloud-config to control the specific renderer; we can follow up) [22:20] rharper: yeah I just wanted to drop any prioritization overrides we were setting as that was focal ++ [22:20] but wondering the best way for us to review such a PR [22:21] do you want manual steps to generate it? or should we review the output diffs and make sure quilt push|pull build-package etc work fine with expected end result [22:21] blackboxsw: let's revisit this on monday; I want to review the commit we landed and the discussion [22:21] sounds good. I'll hold off on bionic and eoan branches [22:21] since we should discuss and bring in falcojr, lucasmoura and Odd_Bloke on that discussion [22:21] yeah