Cloud-init bi-weekly status

Posted on Tue 17 November 2020 in status-meeting-minutes • 6 min read

Meeting information

#cloud-init: cloud-init status meeting && office hours, 17 Nov at 17:25 — 18:35 UTC
Full logs at [[http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-11-17-17.25.log.html]]

Meeting summary

Vote results

Done items

(none)

People present (lines said)

blackboxsw (48)
AnhVoMSFT (15)
rharper (7)
meena (6)
smoser (3)
meetingology (3)
Odd_Bloke (1)

Full Log

17:25 <blackboxsw> #startmeeting cloud-init status meeting && office hours

17:25 <meetingology> Meeting started Tue Nov 17 17:25:00 2020 UTC. The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.

17:25 <meetingology>

17:25 <meetingology> Available commands: action commands idea info link nick

17:25 <blackboxsw> community-notice: hi folks just starting up an our cloud-init satus update and office hours community meeting.

17:26 <blackboxsw> As of the cloud-init summit, we decided to try to host these primarily async in discourse to allow folks in other timezones to participate as available.

17:26 <blackboxsw> I've just finished posting a status update for cloud-init upstream to https://discourse.ubuntu.com/t/cloud-init-statue-11-17-20/19391

17:26 <blackboxsw> #link https://discourse.ubuntu.com/t/cloud-init-statue-11-17-20/19391

17:27 <blackboxsw> #chairs rharper smoser Odd_Bloke

17:28 <rharper> o/

17:28 <blackboxsw> Generally I think this status meeting can be used as a platform for communication and discussion with the community.

17:29 <blackboxsw> for this week, as brought up by a few folks in the community, is that we are trying to define a "go" date for the next upstream cloud-init release 20.4.

17:30 <blackboxsw> The hope is to target this Friday Nov 20th. as a deadline for requesting specific PRs and reviews that are needed to get features or fixes included in this 20.4 release.

17:31 <meena> so, i just responded to falcojr's email

17:32 <blackboxsw> The goal of this date, from an Ubuntu standpoint, is also to be able to SRU (stable release update) and publish this functionality back to Xenial, Bionic and Focal before the end of the calendar year

17:32 <meena> https://github.com/canonical/cloud-init/pull/655 i'd love this too get merged, so we don't have to carry the patch on ports

17:33 <blackboxsw> thanks meena there https://github.com/canonical/cloud-init/pull/655 ahh I'm too late

17:34 <blackboxsw> So, for those who happen to be on this channel now, let's add links to the meeting log and I'll make sure they are also reflected on the discourse post and PRs that need review assessment and hopefully landing before upstream release cut.

17:34 <blackboxsw> #link https://github.com/canonical/cloud-init/pull/655

17:34 <blackboxsw> rharper or smoser are there any concerns with existing PRs that you are aware of that should be destined for this 20.4 release?

17:35 <meena> rharper, i'd also love your historic knowledge on https://github.com/canonical/cloud-init/pull/588 but that can wait until after the release

17:36 <blackboxsw> rharper: I wanted to put a solid review on the cached ds handling today/tomorrow

17:36 <blackboxsw> #link https://github.com/canonical/cloud-init/pull/647

17:36 <blackboxsw> I've looked it over a couple times, but wanted to but some investment in the review myself today.

17:37 <blackboxsw> AnhVoMSFT: welcome and thanks for peeking in to checkup. If your team also have any hopes for PRs you can pitch us here, discourse or email.

17:38 <AnhVoMSFT> I have a quick question on the cc_set_passwords. I'm still looking through the code but if anyone knows this one well and can point me to the right place to look it would be appreciated

17:39 <AnhVoMSFT> it seems like if we create an image that previously was deployed with password ABC, but during image preparation we don't delete that user, then when we deploy a VM with that image and specifying a new password DEF, it isn't applied. I.e., the user will still have password ABC

17:39 <rharper> blackboxsw: I'm not aware of anything critical PR wise; maybe the networking_cls bits; but not sure if that's ready;

17:40 <meena> from my understanding, that needs to get in

17:40 <blackboxsw> AnhVoMSFT: poking around now on that

17:41 <rharper> meena: yes; that makes sense; just hadn't looked at the current state of the PR since I last commented;

17:42 <rharper> meena: re: 588 (genreate_fallback_config); did you have a specific question you wanted some background on?

17:43 <meena> rharper, search for your name

17:44 <rharper> hidden under a "Load more Items"

17:44 <rharper> I'll respond

17:44 <blackboxsw> so instance-id should have changed on the newly deployed vm, so cc_set_passwords should get retriggered due to https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_set_passwords.py#L49 (the default frequency for cc modules). AnhVoMSFT: what the userdata password field you are using? top-level password or chpasswd?

17:45 <AnhVoMSFT> this is the user password passed in from ovf

17:45 <blackboxsw> as that'd be different code paths I think

17:45 <meena> https://github.com/canonical/cloud-init/pull/588#pullrequestreview-529957360

17:46 <AnhVoMSFT> in a newly created instance without the existing user, I could see the password getting created during the initial useradd call when the user is created

17:47 <AnhVoMSFT> however, if the user existed, that code path isn't invoked. There's some code in cc_set_passwords to change the password for existing user, but I'm unsure when it's invoked (or why it's not invoked in the case of azure)

17:48 <blackboxsw> AnhVoMSFT: could you provide a paste of redacted userdata from that instance via sudo cloud-init query userdata... redacting the specific passwords ?

17:49 <blackboxsw> yeah I would have expected a log.debug("Changing password for %s:", users) log

17:53 <AnhVoMSFT> let me run the query

17:53 <AnhVoMSFT> there's nothing returned (since there's no userdata)

17:54 <AnhVoMSFT> looks like the ds Azure is adding the user/password information retrieved from OVF to cfg['defuser']

18:00 <AnhVoMSFT> https://github.com/canonical/cloud-init/blob/eeef783b0322d99840f39a58de052772afefe822/cloudinit/sources/DataSourceAzure.py#L1325

18:00 <AnhVoMSFT> if I'm reading the code of cc_set_password correctly we will need to add cfg['password'] as well if we want the defuser's password to be changed?

18:01 <Odd_Bloke> rharper: We are treating the networking_cls PR as critical, and AFA(I/we)K it's pretty much ready to land.

18:02 <rharper> Odd_Bloke: ok, makes sense

18:06 <smoser> blackboxsw: i dont have anything critical.

18:06 <blackboxsw> AnhVoMSFT: so normalize_users_groups is what pulls the default_user configuration out of /etc/cloud/cloud.cfg(.d/*)

18:06 <blackboxsw> https://github.com/canonical/cloud-init/blob/eeef783b0322d99840f39a58de052772afefe822/cloudinit/config/cc_set_passwords.py#L163

18:07 <blackboxsw> that ug_util.extract_default is what should be seeing the passwords set/changed

18:07 <smoser>

18:08 <smoser> #669 looks reasonable.

18:08 <blackboxsw> yet interestingly. password referenced there is only set from the top-level "password" value https://github.com/canonical/cloud-init/blob/eeef783b0322d99840f39a58de052772afefe822/cloudinit/config/cc_set_passwords.py#L143

18:08 <blackboxsw> thanks smoser for that

18:08 <blackboxsw> #link https://github.com/canonical/cloud-init/pull/663

18:12 <AnhVoMSFT> let me test it out real quick by setting the cfg['password'] key in the ds azure

18:12 <blackboxsw> AnhVoMSFT: so, I may be mistaken but if a password key is set on the default_user in system_info (which is what it looks like azure does), then that default password is only used if there is no top-level "password" key provided in merged cloud-config, then and the default_user specific password key is ignored

18:12 <blackboxsw> +1 AnhVoMSFT

18:13 <AnhVoMSFT> yep that worked

18:13 <AnhVoMSFT> it's a one liner change, I'll submit a PR asap

18:14 <blackboxsw> AnhVoMSFT: good. ok, I wonder if this ever worked (having the password key hung under default_user scope?)

18:14 <blackboxsw> as in, I wonder if there was a regression introduced with some of the is_FreeBSD restructuring

18:15 <AnhVoMSFT> I don't think so. customer reported this issue in cloud-init 18.5 and I repro-ed it in master

18:15 <blackboxsw> ok, ok. good thanks for that context

18:15 <blackboxsw> and checking the recent BSD change it looking completely unrelated

18:17 <blackboxsw> ok AnhVoMSFT when the PR is submitted. let's get that queued for this upstream 20.4 if we can

18:18 <blackboxsw> do folks have an opinion on whether it helps to add a custom label to active PRs that we intend to land before upstream release like 'upstream-blocker' or 'upstream-release'?

18:19 <blackboxsw> just for more public tracking/transparency. not sure if that's helpful or just needless process?

18:19 <blackboxsw> do folks have an opinion on whether it helps to add a custom label to active PRs that we intend to land before upstream release like 'upstream-blocker' or 'upstream-release'?

18:23 <AnhVoMSFT> I think that would be helpful, yes

18:25 <blackboxsw> ok, let's try it out. let's try specific 'release 20.4' and see how that feels to folks. easy enough to drop if it doesn't improve communication

18:30 <blackboxsw> also added pickling upgrade test validation PR

18:30 <blackboxsw> #link https://github.com/canonical/cloud-init/pull/659

18:31 <blackboxsw> ok, last call for cloud-init status / office hours. Any other takers for discussion at the moment? If not I'll close out the meeting in a few mins and publish minutes.

18:33 <blackboxsw> my plan is still to publish to cloud-init.github.io status meetings and link it from the primary post at https://discourse.ubuntu.com/t/cloud-init-status-11-17-20/19391

18:34 <blackboxsw> the following will list prs we hope to work toward landing this week

18:34 <blackboxsw> #link https://github.com/canonical/cloud-init/pulls?q=is%3Apr+is%3Aopen+label%3A%22release+20.4%22

18:35 <blackboxsw> thanks again for the discussion and suggestions folks. Have a good one!

18:35 <blackboxsw> #endmeeting

Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/meetingology)