/srv/irclogs.ubuntu.com/2020/11/17/#cloud-init.txt

vijayendrarharper, I have updated couple of more tests related to openstack and OVF, https://github.com/canonical/cloud-init/pull/647#05:58
=== ItsAGeekThing6 is now known as ItsAGeekThing
=== vrubiolo1 is now known as vrubiolo
otubosmoser: how are the plans for a new release before end of year? Just wanted to plan a new rebase for Fedora Rawhide.11:16
=== vrubiolo1 is now known as vrubiolo
Odd_Blokepowersj: otubo: I'll raise 20.4 in stand-up today. :)14:48
=== vrubiolo1 is now known as vrubiolo
smoserthanks Odd_Bloke .15:19
otuboOdd_Bloke: powersj thanks guys! Will get the logs tomorrow morning :)15:40
=== blackboxsw changed the topic of #cloud-init to: pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next Office Hours: Nov 17 16:15 UTC | 20.3 (Aug 25) | https://bugs.launchpad.net/cloud-init/+filebug
meenait's Tuesday isn't it, huh?16:58
blackboxswcommunity-notice: updated topic for a status meeting today, will be generating a discourse post now to capture high-level discussions and notifications.17:00
blackboxswmeena: 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:02
=== blackboxsw changed the topic of #cloud-init to: pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next Office Hours: Nov 17 17:15 UTC | 20.3 (Aug 25) | https://bugs.launchpad.net/cloud-init/+filebug
blackboxswsince 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:04
blackboxswfun. Will be pushing an async post to discourse so folks cen review at leisure.17:06
AnhVoMSFTis there a way to have IRC display the timestamp of the messages17:15
AnhVoMSFTI just popped in - when is the "10 minutes from now" starting?17:16
meenaAnhVoMSFT: now17:16
blackboxswAnhVoMSFT: sorry that was me about 10 mins ago as I missed the 16:15 UTC :/17:16
blackboxswI'm going to kick this off shortly as I'm about to publish commits/notice to discourse.17:17
meenaso, 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
meenanever mind,falcojr just posted17:20
blackboxswok sorry about that folks:17:22
blackboxswmeena: 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:24
blackboxsw#startmeeting cloud-init status meeting  && office hours17:25
meetingologyMeeting started Tue Nov 17 17:25:00 2020 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.17:25
meetingologyAvailable commands: action commands idea info link nick17:25
blackboxswcommunity-notice: hi folks just starting up an our cloud-init satus update and office hours community meeting.17:25
blackboxswAs 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
blackboxswI've just finished posting a status update for cloud-init upstream to https://discourse.ubuntu.com/t/cloud-init-statue-11-17-20/1939117:26
blackboxsw#link https://discourse.ubuntu.com/t/cloud-init-statue-11-17-20/1939117:26
blackboxsw#chairs rharper smoser Odd_Bloke17:27
rharpero/17:28
blackboxswGenerally I think this status meeting can be used as a platform for communication and discussion with the community.17:28
blackboxswfor 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:29
blackboxswThe 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:30
meenaso, i just responded to falcojr's email17:31
blackboxswThe 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 year17:32
meenahttps://github.com/canonical/cloud-init/pull/655 i'd love this too get merged, so we don't have to carry the patch on ports17:32
blackboxswthanks meena there  https://github.com/canonical/cloud-init/pull/655  ahh I'm too late17:33
blackboxswSo, 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/65517:34
blackboxswrharper or smoser are there any concerns with existing PRs that you are aware of that should be destined for this 20.4  release?17:34
meenarharper, i'd also love your historic knowledge on https://github.com/canonical/cloud-init/pull/588 but that can wait until after the release17:35
blackboxswrharper: I wanted to put a solid review on the cached ds handling  today/tomorrow17:36
blackboxsw#link https://github.com/canonical/cloud-init/pull/64717:36
blackboxswI've looked it over a couple times, but wanted to but some investment in the review myself today.17:36
blackboxswAnhVoMSFT: 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:37
AnhVoMSFTI 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 appreciated17:38
AnhVoMSFTit 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 ABC17:39
rharperblackboxsw: I'm not aware of anything critical PR wise; maybe the networking_cls bits; but not sure if that's ready;17:39
meenafrom my understanding, that needs to get in17:40
blackboxswAnhVoMSFT: poking around now on that17:40
rharpermeena: yes; that makes sense; just hadn't looked at the current state of the PR since I last commented;17:41
rharpermeena: re: 588 (genreate_fallback_config); did you have a specific question you wanted some background on?17:42
meenarharper, search for your name17:43
rharperhidden under a "Load more Items"17:44
rharperI'll respond17:44
blackboxswso 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:44
AnhVoMSFTthis is the user password passed in from ovf17:45
blackboxswas that'd be different code paths I think17:45
meenahttps://github.com/canonical/cloud-init/pull/588#pullrequestreview-52995736017:45
AnhVoMSFTin a newly created instance without the existing user, I could see the password getting created during the initial useradd call when the user is created17:46
AnhVoMSFThowever, 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:47
blackboxswAnhVoMSFT: could you provide a paste of redacted userdata from that instance via `sudo cloud-init query userdata`... redacting the specific passwords ?17:48
blackboxswyeah I would have expected a                 log.debug("Changing password for %s:", users) log17:49
AnhVoMSFTlet me run the query17:53
AnhVoMSFTthere's nothing returned (since there's no userdata)17:53
AnhVoMSFTlooks like the ds Azure is adding the user/password information retrieved from OVF to cfg['defuser']17:54
AnhVoMSFThttps://github.com/canonical/cloud-init/blob/eeef783b0322d99840f39a58de052772afefe822/cloudinit/sources/DataSourceAzure.py#L132518:00
AnhVoMSFTif 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:00
Odd_Blokerharper: We are treating the networking_cls PR as critical, and AFA(I/we)K it's pretty much ready to land.18:01
rharperOdd_Bloke: ok, makes sense18:02
smoserblackboxsw: i dont have anything critical.18:06
blackboxswAnhVoMSFT: so normalize_users_groups is what pulls the default_user configuration out of /etc/cloud/cloud.cfg(.d/*)18:06
blackboxswhttps://github.com/canonical/cloud-init/blob/eeef783b0322d99840f39a58de052772afefe822/cloudinit/config/cc_set_passwords.py#L16318:06
blackboxswthat ug_util.extract_default is what should be seeing the passwords set/changed18:07
smoser 18:07
smoser#669 looks reasonable.18:08
blackboxswyet 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#L14318:08
blackboxswthanks smoser for that18:08
blackboxsw#link https://github.com/canonical/cloud-init/pull/66318:08
AnhVoMSFTlet me test it out real quick by setting the cfg['password'] key in the ds azure18:12
blackboxswAnhVoMSFT: 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 ignored18:12
blackboxsw+1 AnhVoMSFT18:12
AnhVoMSFTyep that worked18:13
AnhVoMSFTit's a one liner change, I'll submit a PR asap18:13
blackboxswAnhVoMSFT: good. ok, I wonder if this ever worked (having the password key hung under default_user scope?)18:14
blackboxswas in, I wonder if there was a regression introduced with some of the is_FreeBSD restructuring18:14
AnhVoMSFTI don't think so. customer reported this issue in cloud-init 18.5 and I repro-ed it in master18:15
blackboxswok, ok. good thanks for that context18:15
blackboxswand checking the recent BSD change it looking completely unrelated18:15
blackboxswok AnhVoMSFT when the PR is submitted. let's get that queued for this upstream 20.4  if we can18:17
blackboxswdo 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:18
blackboxswjust for more public tracking/transparency. not sure if that's helpful or just needless process?18:19
blackboxswdo 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
AnhVoMSFTI think that would be helpful, yes18:23
blackboxswok, 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 communication18:25
blackboxswalso added pickling upgrade test validation PR18:30
blackboxsw#link https://github.com/canonical/cloud-init/pull/65918:30
blackboxswok, 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:31
blackboxswmy 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/1939118:33
blackboxswthe following will list prs we hope to work toward landing this week18:34
blackboxsw#link https://github.com/canonical/cloud-init/pulls?q=is%3Apr+is%3Aopen+label%3A%22release+20.4%2218:34
blackboxswthanks again for the discussion and suggestions folks. Have a good one!18:35
blackboxsw#endmeeting18:35
meetingologyMeeting ended Tue Nov 17 18:35:12 2020 UTC.18:35
meetingologyMinutes:        http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-11-17-17.25.moin.txt18:35
=== ijohnson is now known as ijohnson|lunch
AnhVoMSFT@blackboxsw https://github.com/canonical/cloud-init/pull/67119:06
AnhVoMSFTlet's try the custom label for this one19:06
=== ijohnson|lunch is now known as ijohnson
Odd_Blokefalcojr: https://github.com/canonical/cloud-init/pull/672 <-- this is the CI mark PR I mentioned earlier :)21:11
blackboxswOdd_Bloke: I'm almost out of the way on https://github.com/canonical/cloud-init/pull/65921:11
blackboxsw+1 AnhVoMSFT21:12
johnsonshiJust cleared up bandwidth and will address the PR comments I've received from Odd_Bloke and blackboxsw.21:15
blackboxswOdd_Bloke: approved with nit https://github.com/canonical/cloud-init/pull/659#discussion_r52552915221:18
blackboxswjohnsonshi: thanks! reading now21:19
blackboxswohh johnsonshi right. thanks. just ping here or click the re-request review button on the PR when ready21:20
johnsonshiblackboxsw: Addressing those PR comments over this afternoon. Changes requested should be in by tomorrow morning.21:20
blackboxsw+121:20
Odd_Blokeblackboxsw: Ack, thanks!  I'll land that and propose a follow-up to address the testing gap.21:27
Odd_Blokeblackboxsw: https://github.com/canonical/cloud-init/pull/67321:41
blackboxswmerged https://github.com/canonical/cloud-init/pull/67321:56
blackboxswthanks21:56
Odd_BlokeThanks!21:58
blackboxswOdd_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-L11723:03
falcojrblackboxsw yes, a mark should be the way to go23:05
blackboxswok might have a proposal to point at tomorrow. thx23:06
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:09
blackboxswuser217_: can you `grep "Applying network config" /var/log/cloud-init.log`23:10
blackboxswon the affected system23:10
blackboxswthat log should tell you what cloud-init is seeing23:10
blackboxswI'd be curious about the paste of your /etc/cloud/cloud.cfg.d/<some_network_config_file> you have provided too23:12
user217_config : https://paste.ubuntu.com/p/r7yVv4RDnZ/23:13
blackboxswand 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:13
blackboxswuser217_: I think your top line is commented out23:14
blackboxsw#network23:14
blackboxswso your yaml isn't being read as something that is "network" config23:14
user217_log: https://paste.ubuntu.com/p/6Mkm2MnTGT/23:15
user217_blackboxsw, I try both cases23:16
blackboxswuser217_: 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
blackboxswsounds good23: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
blackboxswok  so it processed the userdata properly with a version I think.23:16
user217_blackboxsw, I try with ".cfg" also23:16
blackboxswchecking against your original paste of content23:17
user217_now I get : "[FAILED] Failed to start Initial cloud-init job (pre-networking).23:17
user217_"23:17
user217_http://i.imgur.com/iGN1Vf3.png23:18
user217_is this config should be ok ? https://paste.ubuntu.com/p/ZJsTXxBBtG/23:22
blackboxswuser217_: in your pasted yaml https://paste.ubuntu.com/p/r7yVv4RDnZ/  there doesn't appear to be an indent on lines 3, 6 or 1723:22
blackboxswahh thanks for the updated paste. looking now23:22
blackboxswuser217_: one way to test this on your cloud-init deployed system if you had access:23:23
blackboxswcloud-init devel net-convert --output-kind=netplan --directory /out.d --network-data=test.yaml --kind=yaml23:23
blackboxswthat would try to process your network config yaml and render network files into /out.d so you could look23:23
blackboxswor error quickly as the case may be23:23
user217_blackboxsw, looks like when I use : "network:" I get error: "RuntimeError: Unknown network config version: None"23:29
user217_but if use this type of config : https://paste.ubuntu.com/p/Nbn8KHpYwj/23:31
user217_I get some long timeout and23:32
user217_"[FAILED] Failed to start Wait for Network to be Configured.23:33
user217_"23:33
blackboxswinteresting, as when I run net-convert tool it processes your file fine on cloud-init v 20.323:35
blackboxswuser217_: you are on Ubuntu bionic right?23:36
blackboxswbionic/18.0423:36
user217_and also I have some progress with this config : https://paste.ubuntu.com/p/dyRQVrdWFK/23:36
user217_blackboxsw, yep23:37
user217_ubuntu-cloud23:37
user217_but with last config that I posted I get defined ip, but cant define hostnames23:37
user217_so I can ping ip's, but cant hostnames23:38
blackboxswso, 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:38
user217_hm.. looks like I get best progress for now with this config : https://paste.ubuntu.com/p/fqgtBjgFJ5/23:43
user217_I get IP, and can ping 8.8.8.8 , but still cant ping google.com23:44
blackboxswprobably, 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
blackboxswuser217_: is the only diff between your last two yamls that you moved version to the end?23:44
blackboxswI'd not expect that to make a difference one way or another.23:45
user217_I just need to create brige in same pool that my host :(23:52
user217_and looks like I stuck(23:52
blackboxswI 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 in23:56
blackboxswyour config is what you think it should be processing `egrep -i '[Aa]pplying net' /var/log/cloud-init.log`23:56
blackboxswsome other examples of bridge setup w/ net config version 2 could be helpful here https://netplan.io/examples/23:58
blackboxswI have to head out folks.23:58
blackboxswhave a good one. user217_  sorry we didn't quite get there23:59
blackboxswif need be, please file a bug with details23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!