17:25 #startmeeting cloud-init status meeting && office hours 17:25 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 17:25 Available commands: action commands idea info link nick 17:25 community-notice: hi folks just starting up an our cloud-init satus update and office hours community meeting. 17:26 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 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 #link https://discourse.ubuntu.com/t/cloud-init-statue-11-17-20/19391 17:27 #chairs rharper smoser Odd_Bloke 17:28 o/ 17:28 Generally I think this status meeting can be used as a platform for communication and discussion with the community. 17:29 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 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 so, i just responded to falcojr's email 17:32 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 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 thanks meena there https://github.com/canonical/cloud-init/pull/655 ahh I'm too late 17:34 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 #link https://github.com/canonical/cloud-init/pull/655 17:34 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 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 rharper: I wanted to put a solid review on the cached ds handling today/tomorrow 17:36 #link https://github.com/canonical/cloud-init/pull/647 17:36 I've looked it over a couple times, but wanted to but some investment in the review myself today. 17:37 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 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 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 blackboxsw: I'm not aware of anything critical PR wise; maybe the networking_cls bits; but not sure if that's ready; 17:40 from my understanding, that needs to get in 17:40 AnhVoMSFT: poking around now on that 17:41 meena: yes; that makes sense; just hadn't looked at the current state of the PR since I last commented; 17:42 meena: re: 588 (genreate_fallback_config); did you have a specific question you wanted some background on? 17:43 rharper, search for your name 17:44 hidden under a "Load more Items" 17:44 I'll respond 17:44 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 this is the user password passed in from ovf 17:45 as that'd be different code paths I think 17:45 https://github.com/canonical/cloud-init/pull/588#pullrequestreview-529957360 17:46 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 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 AnhVoMSFT: could you provide a paste of redacted userdata from that instance via `sudo cloud-init query userdata`... redacting the specific passwords ? 17:49 yeah I would have expected a log.debug("Changing password for %s:", users) log 17:53 let me run the query 17:53 there's nothing returned (since there's no userdata) 17:54 looks like the ds Azure is adding the user/password information retrieved from OVF to cfg['defuser'] 18:00 https://github.com/canonical/cloud-init/blob/eeef783b0322d99840f39a58de052772afefe822/cloudinit/sources/DataSourceAzure.py#L1325 18:00 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 rharper: We are treating the networking_cls PR as critical, and AFA(I/we)K it's pretty much ready to land. 18:02 Odd_Bloke: ok, makes sense 18:06 blackboxsw: i dont have anything critical. 18:06 AnhVoMSFT: so normalize_users_groups is what pulls the default_user configuration out of /etc/cloud/cloud.cfg(.d/*) 18:06 https://github.com/canonical/cloud-init/blob/eeef783b0322d99840f39a58de052772afefe822/cloudinit/config/cc_set_passwords.py#L163 18:07 that ug_util.extract_default is what should be seeing the passwords set/changed 18:07 18:08 #669 looks reasonable. 18:08 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 thanks smoser for that 18:08 #link https://github.com/canonical/cloud-init/pull/663 18:12 let me test it out real quick by setting the cfg['password'] key in the ds azure 18:12 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 +1 AnhVoMSFT 18:13 yep that worked 18:13 it's a one liner change, I'll submit a PR asap 18:14 AnhVoMSFT: good. ok, I wonder if this ever worked (having the password key hung under default_user scope?) 18:14 as in, I wonder if there was a regression introduced with some of the is_FreeBSD restructuring 18:15 I don't think so. customer reported this issue in cloud-init 18.5 and I repro-ed it in master 18:15 ok, ok. good thanks for that context 18:15 and checking the recent BSD change it looking completely unrelated 18:17 ok AnhVoMSFT when the PR is submitted. let's get that queued for this upstream 20.4 if we can 18:18 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 just for more public tracking/transparency. not sure if that's helpful or just needless process? 18:19 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 I think that would be helpful, yes 18:25 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 also added pickling upgrade test validation PR 18:30 #link https://github.com/canonical/cloud-init/pull/659 18:31 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 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 the following will list prs we hope to work toward landing this week 18:34 #link https://github.com/canonical/cloud-init/pulls?q=is%3Apr+is%3Aopen+label%3A%22release+20.4%22 18:35 thanks again for the discussion and suggestions folks. Have a good one! 18:35 #endmeeting