[05:58] <vijayendra> rharper, I have updated couple of more tests related to openstack and OVF, https://github.com/canonical/cloud-init/pull/647#
[11:16] <otubo> smoser: how are the plans for a new release before end of year? Just wanted to plan a new rebase for Fedora Rawhide.
[14:48] <Odd_Bloke> powersj: otubo: I'll raise 20.4 in stand-up today. :)
[15:19] <smoser> thanks Odd_Bloke .
[15:40] <otubo> Odd_Bloke: powersj thanks guys! Will get the logs tomorrow morning :)
[16:58] <meena> it's Tuesday isn't it, huh?
[17:00] <blackboxsw> community-notice: updated topic for a status meeting today, will be generating a discourse post now to capture high-level discussions and notifications.
[17:02] <blackboxsw> meena: sure enough... I have forgotten to recognize Tuesdays for a little bit.... turns out it's a bigger event than just taking my trash out to the curbside. :/
[17:04] <blackboxsw> since I've missed the boat in general. even the typical 16:15 status meeting time. Let's try 10 mins from now. should have the captured discussion topics by then.
[17:04]  * meena looks over to her daughter who's bouncing on the trampoline, not sure I'll be able to participate in an hour…
[17:06] <blackboxsw> fun. Will be pushing an async post to discourse so folks cen review at leisure.
[17:15] <AnhVoMSFT> is there a way to have IRC display the timestamp of the messages
[17:16] <AnhVoMSFT> I just popped in - when is the "10 minutes from now" starting?
[17:16] <meena> AnhVoMSFT: now
[17:16] <blackboxsw> AnhVoMSFT: sorry that was me about 10 mins ago as I missed the 16:15 UTC :/
[17:17] <blackboxsw> I'm going to kick this off shortly as I'm about to publish commits/notice to discourse.
[17:20] <meena> so, given the silence in this channel recently, i assume y'all are either working on an SRU (normal release) or on a security hit fix…
[17:20] <meena> never mind,falcojr just posted
[17:22] <blackboxsw> ok sorry about that folks:
[17:24] <blackboxsw> meena: my specific silence has just been due to being significantly committed on another project at the moment. the other bits of silence are probably due to working on integration test framework for cloud-init (which ends up being a bit of pycloudlib work)
[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> 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
[18:35] <meetingology> Meeting ended Tue Nov 17 18:35:12 2020 UTC.
[18:35] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-11-17-17.25.moin.txt
[19:06] <AnhVoMSFT> @blackboxsw https://github.com/canonical/cloud-init/pull/671
[19:06] <AnhVoMSFT> let's try the custom label for this one
[21:11] <Odd_Bloke> falcojr: https://github.com/canonical/cloud-init/pull/672 <-- this is the CI mark PR I mentioned earlier :)
[21:11] <blackboxsw> Odd_Bloke: I'm almost out of the way on https://github.com/canonical/cloud-init/pull/659
[21:12] <blackboxsw> +1 AnhVoMSFT
[21:15] <johnsonshi> Just cleared up bandwidth and will address the PR comments I've received from Odd_Bloke and blackboxsw.
[21:18] <blackboxsw> Odd_Bloke: approved with nit https://github.com/canonical/cloud-init/pull/659#discussion_r525529152
[21:19] <blackboxsw> johnsonshi: thanks! reading now
[21:20] <blackboxsw> ohh johnsonshi right. thanks. just ping here or click the re-request review button on the PR when ready
[21:20] <johnsonshi> blackboxsw: Addressing those PR comments over this afternoon. Changes requested should be in by tomorrow morning.
[21:20] <blackboxsw> +1
[21:27] <Odd_Bloke> blackboxsw: Ack, thanks!  I'll land that and propose a follow-up to address the testing gap.
[21:41] <Odd_Bloke> blackboxsw: https://github.com/canonical/cloud-init/pull/673
[21:56] <blackboxsw> merged https://github.com/canonical/cloud-init/pull/673
[21:56] <blackboxsw> thanks
[21:58] <Odd_Bloke> Thanks!
[23:03] <blackboxsw> Odd_Bloke: falcojr if I want to write an integration test that'll inject launch_kwargs into the test's launch, do we imagine we'd need to grow a new pytest mark.launch_kwargs marker as we do with user_data instance_name etc? https://github.com/canonical/cloud-init/blob/master/tests/integration_tests/conftest.py#L105-L117
[23:05] <falcojr> blackboxsw yes, a mark should be the way to go
[23:06] <blackboxsw> ok might have a proposal to point at tomorrow. thx
[23:09] <user217_> hello I get error : "Unknown network config version: None" when lanch my vps (but in cloud-config I define version)
[23:09] <user217_> is any fix for this ?
[23:10] <blackboxsw> user217_: can you `grep "Applying network config" /var/log/cloud-init.log`
[23:10] <blackboxsw> on the affected system
[23:10] <blackboxsw> that log should tell you what cloud-init is seeing
[23:12] <blackboxsw> I'd be curious about the paste of your /etc/cloud/cloud.cfg.d/<some_network_config_file> you have provided too
[23:13] <user217_> config : https://paste.ubuntu.com/p/r7yVv4RDnZ/
[23:13] <blackboxsw> and a `sudo cloud-init query merged_cfg` might be interesting as that should contain your network definition (be wary check this command output to make sure you don't expose any 'password' values)
[23:14] <blackboxsw> user217_: I think your top line is commented out
[23:14] <blackboxsw> #network
[23:14] <blackboxsw> so your yaml isn't being read as something that is "network" config
[23:15] <user217_> log: https://paste.ubuntu.com/p/6Mkm2MnTGT/
[23:16] <user217_> blackboxsw, I try both cases
[23:16] <blackboxsw> user217_: also the test.yaml as the filename I assume was just for your test, as the only files read under /etc/cloud/cloud.cfg.d/ are files ending in ".cfg"
[23:16] <blackboxsw> sounds good
[23:16] <blackboxsw>  {'version': 2, 'ethernets': {'enp2': {'match': {'macaddress': '00:11:22:33:44:55'}, 'addresses': ['192.168.88.162/24'], 'gateway4': '192.168.88.1', 'nameservers': {'search': ['foo.local', 'bar.local'], 'addresses': ['8.8.8.8']}}}, 'bridges': {'br1': {'interfaces': ['enp2']}}}
[23:16] <blackboxsw> ok  so it processed the userdata properly with a version I think.
[23:16] <user217_> blackboxsw, I try with ".cfg" also
[23:17] <blackboxsw> checking against your original paste of content
[23:17] <user217_> now I get : "[FAILED] Failed to start Initial cloud-init job (pre-networking).
[23:17] <user217_> "
[23:18] <user217_> http://i.imgur.com/iGN1Vf3.png
[23:22] <user217_> is this config should be ok ? https://paste.ubuntu.com/p/ZJsTXxBBtG/
[23:22] <blackboxsw> user217_: in your pasted yaml https://paste.ubuntu.com/p/r7yVv4RDnZ/  there doesn't appear to be an indent on lines 3, 6 or 17
[23:22] <blackboxsw> ahh thanks for the updated paste. looking now
[23:23] <blackboxsw> user217_: one way to test this on your cloud-init deployed system if you had access:
[23:23] <blackboxsw> cloud-init devel net-convert --output-kind=netplan --directory /out.d --network-data=test.yaml --kind=yaml
[23:23] <blackboxsw> that would try to process your network config yaml and render network files into /out.d so you could look
[23:23] <blackboxsw> or error quickly as the case may be
[23:29] <user217_> blackboxsw, looks like when I use : "network:" I get error: "RuntimeError: Unknown network config version: None"
[23:31] <user217_> but if use this type of config : https://paste.ubuntu.com/p/Nbn8KHpYwj/
[23:32] <user217_> I get some long timeout and
[23:33] <user217_> "[FAILED] Failed to start Wait for Network to be Configured.
[23:33] <user217_> "
[23:35] <blackboxsw> interesting, as when I run net-convert tool it processes your file fine on cloud-init v 20.3
[23:36] <blackboxsw> user217_: you are on Ubuntu bionic right?
[23:36] <blackboxsw> bionic/18.04
[23:36] <user217_> and also I have some progress with this config : https://paste.ubuntu.com/p/dyRQVrdWFK/
[23:37] <user217_> blackboxsw, yep
[23:37] <user217_> ubuntu-cloud
[23:37] <user217_> but with last config that I posted I get defined ip, but cant define hostnames
[23:38] <user217_> so I can ping ip's, but cant hostnames
[23:38] <blackboxsw> so, I'm not certain why I can't see that traceback/error from your cloud-init logs posted at https://paste.ubuntu.com/p/6Mkm2MnTGT/
[23:38] <user217_> so its looks like that I miss something my configuration :(
[23:43] <user217_> hm.. looks like I get best progress for now with this config : https://paste.ubuntu.com/p/fqgtBjgFJ5/
[23:44] <user217_> I get IP, and can ping 8.8.8.8 , but still cant ping google.com
[23:44] <blackboxsw> probably, it may be easier to iterate using that cloud-init devel net-convert utility to see when you get the right network configuration output you expect given your environment.
[23:44] <blackboxsw> user217_: is the only diff between your last two yamls that you moved version to the end?
[23:45] <blackboxsw> I'd not expect that to make a difference one way or another.
[23:52] <user217_> I just need to create brige in same pool that my host :(
[23:52] <user217_> and looks like I stuck(
[23:56] <blackboxsw> I think maybe the paste of the /var/log/cloud-init.log file  doesn't really seem like it's representative of the envioronment you booted.    It seems like you are making some progress toward that goal. I'd just suggest that if you are changing network config files in /etc/cloud/cloud.cfg.d/*.cfg attempt to cloud-init clean --logs before rebooting or re-running cloud-init to confirm that what cloud init sees in
[23:56] <blackboxsw> your config is what you think it should be processing `egrep -i '[Aa]pplying net' /var/log/cloud-init.log`
[23:58] <blackboxsw> some other examples of bridge setup w/ net config version 2 could be helpful here https://netplan.io/examples/
[23:58] <blackboxsw> I have to head out folks.
[23:59] <blackboxsw> have a good one. user217_  sorry we didn't quite get there
[23:59] <blackboxsw> if need be, please file a bug with details