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