[03:51] <punkgeek> Is there any way to config vms without iso, such as using python libvirt?
=== hjensas is now known as hjensas|afk
=== hjensas|afk is now known as hjensas
=== tds3 is now known as tds
[13:36] <Odd_Bloke> punkgeek: How would you want to use libvirt to configure them?
[15:27] <blackboxsw> Odd_Bloke: per https://github.com/canonical/cloud-init/pull/314/files pytest fixtures. do you think we need to worry about xenial/bionic support of capsys/caplog as we did with ua-client?
[15:27] <blackboxsw> I forgot if I asked this question yesterday
[15:27] <Odd_Bloke> blackboxsw: What do you mean by "worry about"?
[15:27] <Odd_Bloke> (I did comment on your PR with a comment about caplog.)
[15:27] <punkgeek> Odd_Bloke: I saw a sample in ovirt that import cloud-init configuration. But I want this tool in python libvirt https://red.ht/2K1gBkn
[15:27] <Odd_Bloke> And `capsys` is available in xenial.
[15:29] <Odd_Bloke> punkgeek: Have you tried using that example?  Does it fail for you?  (This isn't an area I'm familiar with, apologies in advance for dumb questions. :)
[15:30] <Odd_Bloke> blackboxsw: Sorry to expand on my previous comment: we should discuss caplog (and potentially using the separate python3-pytest-catchlog package on xenial), but I think that's orthogonal to documenting the current state of matters.
[15:30]  * blackboxsw just reads the responses on my schema PR. I was wondering if we had shortcomings we'd have to be concerned with given that caplog wasn't available on xenial. but you've answered that for me. we can use pytest-catchlog potentially 
[15:31] <blackboxsw> Odd_Bloke: sorry, was just reading the other context. and agreed it is orthogonal.
[15:31] <blackboxsw> ~30 until cloud-init status meeting
[15:50] <otubo> Anyone can review this oneliner PR really quick? https://github.com/canonical/cloud-init/pull/315
[15:51] <otubo> Really sorry for the hard ping on this, it's a super silly fix that was breaking on our tests and I need to backport it by tomorrow EOD :-D
[15:51] <otubo> blackboxsw, Odd_Bloke ^^
[15:51] <blackboxsw> otubo: sure. so what is that whitespace?
[15:52] <blackboxsw> ohh shuffling placement
[15:52] <blackboxsw> ok looking
[15:52] <blackboxsw> reviewing
[15:52] <Odd_Bloke> I'm about to be AFK for a while, but I'd like us to add a test that would have caught this.
[15:53] <Odd_Bloke> (Not necessarily as part of the PR that fixes it, as you have time pressure on that.)
[15:53] <otubo> Odd_Bloke, sure! I'd be glad to include a test for that, like the day after tomorrow :-)
[15:53] <Odd_Bloke> ^_^
[15:57] <blackboxsw> otubo: whats the redhat bugzilla for this bug here? https://bugzilla.redhat.com/show_bug.cgi?id=1794664
[15:57] <ubot5> bugzilla.redhat.com bug 1794664 in cloud-init "[RHEL8] swapon fails with "swapfile has holes" when created on a xfs filesystem by cloud-init" [High,Assigned]
[15:58] <blackboxsw> I'm just wondering as I want to cross reference it in the commit message that we land when merging
[15:58] <otubo> blackboxsw, yeah, I was just thinking about that.
[15:59] <otubo> blackboxsw, can you add the BZ (that's the one, BTW) upon merge? Or I should do something else, like a v2?
[16:00] <blackboxsw> otubo: I can set the squash merged commit message at merge time
[16:00] <blackboxsw> so no need for a fix on your end
[16:00] <blackboxsw> rharper: do you recall what prefix we use in the footer for RH bugzillas?  I'm not seeing any RH: <BUG_ID> in commit messages, but I though we had something.
[16:00] <blackboxsw> at least for Suse
[16:00] <otubo> blackboxsw, actually the correct BZ is 1772505
[16:00] <blackboxsw> ahh thanks otubo
[16:01] <otubo> that one was for RHEL8, but the fix is actually for RHEL7
[16:01] <rharper> blackboxsw: we can use whatever is useful for otubo  ... I don't think we have any convention
[16:01] <otubo> rharper, blackboxsw nothing special for me, BZ#<number> is normally what we do internally
[16:01] <rharper> blackboxsw: sometimes there's an LP bug which has a mirror link to an downstream bz
[16:02] <rharper> bug #1781781
[16:02] <ubot5> bug 1781781 in curtin "/swap.img w/fallocate has holes" [Medium,Confirmed] https://launchpad.net/bugs/1781781
[16:10] <otubo> blackboxsw, do we need Odd_Bloke for that or we can have a review/merge from rharper ? :-)
[16:10] <blackboxsw> otubo: no I'll merge
[16:10] <blackboxsw> otubo: this commit message ok with you?https://paste.ubuntu.com/p/RDXMwXxMmt/
[16:10] <blackboxsw> RBZ: prefix for redhat bugzilla?
[16:11] <otubo> blackboxsw, RHBZ is better I guess
[16:11] <blackboxsw> +1
[16:11] <otubo> blackboxsw, that's actually my fault. I got to the bottom of my backlog and found out this issue due to tomorrow.
[16:12] <blackboxsw> no worries otubo, do you want to spend time adding the unit test today or land it and propose the unit test changes  in a separate PR?
[16:12] <otubo> blackboxsw, and thank you very much for the commit :-) If we ever have a cloud-init summit this year, remember me to pay you a beer :-)
[16:13] <otubo> blackboxsw, can I add the test once I get this out? Like tomorrow would probably be ok.
[16:16] <blackboxsw> merged otubo . ok will fast track a unit test PR once available.
[16:16] <blackboxsw> thanks
[16:17] <otubo> blackboxsw, thanks a lot :)
[16:17] <blackboxsw> no problemo
[16:17] <blackboxsw> #startmeeting cloud-init status meeting
[16:17] <meetingology> Meeting started Tue Apr 14 16:17:46 2020 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:17] <meetingology> Available commands: action commands idea info link nick
[16:18] <blackboxsw> hey folks, time for cloud-init community status meeting
[16:19] <powersj> \o/
[16:19] <otubo> Right on time :-)
[16:20] <blackboxsw> welcome again to our bi-weekly status meeting feel free to interject comments, questions, suggestions during this status meeting. Generally it is an opportunity for upstream to provide a frequent platform communication and drop-in discussion when a couple of upstream devs are available.
[16:20] <blackboxsw> #chair Odd_Bloke smoser rharper powers
[16:20] <meetingology> Warning: Nick not in channel: powers
[16:20] <meetingology> Current chairs: Odd_Bloke blackboxsw powers rharper smoser
[16:20] <blackboxsw> #chair powersj
[16:20] <meetingology> Current chairs: Odd_Bloke blackboxsw powers powersj rharper smoser
[16:20] <blackboxsw> our IRC channel topic carries the next planned status meeting for those that wish to participate. All are welcome to interject or drive converstation topics here
[16:21] <blackboxsw> any objections to same time on Apr 28th?
[16:21] <powersj> nah that's a good day given we want to cut 20.2 then
=== blackboxsw changed the topic of #cloud-init to: pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting April 28 16:15 UTC | 20.1 (Feb 18) | 20.2 (Apr 28) | https://bugs.launchpad.net/cloud-init/+filebug
[16:21] <blackboxsw> ok topic set for next meetin
[16:22] <blackboxsw> our last meeting minutes can be found on github at
[16:22] <blackboxsw> #link https://cloud-init.github.io/status-2020-03-31.html#status-2020-03-31
[16:23] <blackboxsw> The topics we generally cover in this meeting are the following: Previous Actions, Recent Changes, In-progress Development, Community Charter, Upcoming Meetings, Office Hours (~30 mins).
[16:23] <blackboxsw>  #topic Previous Actions
[16:23] <blackboxsw> none listed from last meeting
[16:23] <blackboxsw> #topic Recent Changes
[16:24] <blackboxsw> git commits landed in tip since Mar 31: https://paste.ubuntu.com/p/VptqRBfVfJ/  found by git log --since 03-31-2020
[16:26] <blackboxsw> changes sport doc updates, otubo's cc_mount fix , better url handling for regions which  contain underscores in their name  and openbsd fixes from Goneri for passwd locks.
[16:27] <blackboxsw> thanks for the contributions this round folks!
[16:27] <blackboxsw> #topic In-progress Development
[16:30] <blackboxsw> upstream is currently focused on getting in bug fixes, dropping remnants of py2 in tooling  reviewing active PRs to get cloud-init in shape for the upcoming 20.2 release
[16:31] <blackboxsw> community notice: as mentioned in the channel topic, Apr 28th is our upstream release date for 20.2
[16:31] <blackboxsw> community notice: we ask that pull requests or bugs that need resolution for 20.2 be up for review by Friday April 24th so there is time to review and merge those fixes.
[16:32] <blackboxsw> active pulls indended for the release should be up in github at https://github.com/canonical/cloud-init/pulls
[16:32] <blackboxsw> *intended* rather
[16:32] <blackboxsw>  #topic Community Charter
[16:33] <blackboxsw> his section is generally reserved to discuss any general community goals for cloud-init, at last cloud-init summit  we defined those goals as:
[16:33] <blackboxsw> - datasource doc fixes
[16:33] <blackboxsw> - json schema validation for each cloudinit/config/cc_*py modules
[16:34] <blackboxsw> there are feature bugs created for these tasks at https://bugs.launchpad.net/cloud-init/+bugs?field.tag=bitesize
[16:34] <blackboxsw> #topic Office hours (next ~30 mins)
[16:35] <blackboxsw> During office hours a couple of upstream devs will have eyes on this channel. Any questions, comments, branch reviews are fair game for discussion.
[16:36] <blackboxsw> In leiu of active discussions, developers will be grooming the active pull request review queue  to unblock branch authors.
[16:37] <punkgeek> Odd_Bloke: No it doesn't work. why there is no way to config cloud-init in kvm virtualization rather than iso, like vm xml file?
[16:37] <blackboxsw> I'm getting through a belated review on https://github.com/canonical/cloud-init/pull/298
[16:42] <blackboxsw> punkgeek: like seeding ovf-env.xml? https://github.com/canonical/cloud-init/blob/master/doc/sources/ovf/README
[16:46] <rharper> punkgeek: you might want to look at virt-install , they recently have added support for providing cloud-config to VMs;  virt-install is a wrapper around creating VMs utilizing libvirt as a backend, https://athinapl.home.blog/2019/08/25/gsoc-2019-cloud-init-configuration-for-virt-manager-virt-install/
[16:54] <Goneri> punkgeek, or you can take a look at virt-lightning
[16:54] <Goneri> punkgeek, it's basically a CLI to use libvirt+cloud-init
[17:03] <blackboxsw> Goneri: review done. sorry for the delay on such a minor set of change requests https://github.com/canonical/cloud-init/pull/298/files#
[17:09] <blackboxsw> https://github.com/CanonicalLtd/uss-tableflip/pull/45 I think comments are resolved
[17:11] <blackboxsw> I think we are at about the turn of the hour for cloud-init status. I'm going to review https://github.com/canonical/cloud-init/pull/305 next
[17:11] <blackboxsw> thanks all for tuning in. see you next time
[17:12] <blackboxsw> #endmeeting
[17:12] <meetingology> Meeting ended Tue Apr 14 17:12:01 2020 UTC.
[17:12] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-04-14-16.17.moin.txt
[17:25] <meena> it's tuesday?
[17:25] <meena> i can't believe it's tuesday, when every day feels like tuesday
[17:27] <blackboxsw> hahaha!
[17:27] <blackboxsw> heya meena , welcome. :)
[17:28] <blackboxsw> just completed another review for goneri https://github.com/canonical/cloud-init/pull/305/files#diff-1708fc6fbf7cc4ca958a7adab7ad615eR23
[17:41] <Odd_Bloke> meena: Thanks for the review on that doc PR!
[17:42] <blackboxsw> rharper: and json schema PR is good for followup review https://github.com/canonical/cloud-init/pull/152
[17:42] <blackboxsw> yes meena thx for all the reviews on nearly every PR that is up.
[20:20] <blackboxsw> rharper: this looks like bogus network configuration from a dhcp server lease response doesn't it?
[20:20] <blackboxsw> 2020-04-07 02:51:55,948 - dhcp.py[DEBUG]: Received dhcp lease on eth0 for 10.54.62.43/255.255.255.255
[20:20] <blackboxsw> 2020-04-07 02:51:55,949 - __init__.py[DEBUG]: Attempting setup of ephemeral network on eth0 with 10.54.62.43/32 brd 10.54.62.127
[20:20] <rharper>  no
[20:20] <rharper> do you have the full lease dump ?
[20:21] <blackboxsw> how can eth0 access broadcast  addr  10.54.62.127 if subnet netmask is /32?
[20:21] <rharper> I don't need to broadcast;  typically you'll also have a static route set
[20:21] <blackboxsw> rharper: I don't just logs @ https://launchpadlibrarian.net/473747419/cloud-init.log
[20:22] <rharper> we dump the lease parts though I thought
[20:22] <blackboxsw> it's ephermeral dhcp response constructs/log messages as it parses tmp dhclient lease during initial setup.
[20:22] <blackboxsw> per the openstack bug from a few days ago
[20:22] <blackboxsw> https://bugs.launchpad.net/cloud-init/+bug/1871323
[20:22] <ubot5> Ubuntu bug 1871323 in cloud-init "cloud-init fails to add default route during _bringup_static_routes" [Undecided,Incomplete]
[20:23] <rharper> can we ask for the lease file?  either it's a bogus lease; (I'm not sure about that) or we're parsing it in correctly
[20:24] <blackboxsw> seeing statements like this from cloud-init seem invalid : Running command ['ip', '-family', 'inet', 'addr', 'add', '10.54.62.43/32', 'broadcast', '10.54.62.127', 'dev', 'eth0']
[20:24] <blackboxsw> yeah I can  get that.
[20:25] <blackboxsw> will request the tmp lease and provide reproducible instructions to ge tit
[20:25] <blackboxsw> I think it's a bogus dhcp config on their network... but just guessing here
[20:28] <rharper> blackboxsw: well, let's confirm we're parsing it correctly, we could be putting the /32 on there ourselves
[20:28] <rharper> is this recent cloud-init or older release on non-Ubuntu ?
[20:28] <rharper> we added a redhat dhclient rfc parser last fall
[20:29] <rharper> blackboxsw the lease is there
[20:29] <rharper> option rfc3442-classless-static-routes 32,10,54,62,1,0,0,0,0,32,169,254,169,254,10,54,62,1,0,10,54,62,1
[20:30] <blackboxsw> 19.4.33, so latest xenial I think.
[20:31] <blackboxsw> ohh right the lease is there in the initial bug file.
[20:31] <blackboxsw> which specifies:
[20:31] <blackboxsw>   fixed-address 10.54.62.43;
[20:31] <blackboxsw>   option subnet-mask 255.255.255.255;
[20:31] <blackboxsw> is that invalid given that the router is at    option routers 10.54.62.1;
[20:32] <blackboxsw> as subnet-mask should be something like 255.255.255.0 or .128 or something to give it visibility to the router right?
[20:56] <blackboxsw> specifically, if their router is 10.54.62.1 the smallest possible subnet-netmask they can have is /26 to allow 10.54.62.43 to contact 10.54.62.1. so a netmask of 255.255.255.192
[20:56] <blackboxsw> will pose the question on the bug and see if I'm bungling  something there
[21:37] <powersj> otubo, have you seen the comments on this https://github.com/canonical/cloud-init/pull/70#pullrequestreview-393312656