[09:57] <otubo> rharper: Odd_Bloke we don't run unittests for RHELat the moment, but we have plans to run them in a near future for Fedora releases. But since we don't have anything in place right now, I guess we're fine with the changes :-) thanks for pinging
[14:33] <otubo> mhayden: dustymabe the pull-request to rebase to 19.4 for fedora rawhide is open for review :-) https://src.fedoraproject.org/rpms/cloud-init/pull-request/6
[15:02] <dustymabe> otubo: woot!
[15:02] <dustymabe> that's awesome
[15:22] <dustymabe> otubo: i'll try to have it reviewed by Monday
[15:25] <otubo> dustymabe: no worries. Actually I just found out cloud-init upstream will cut 20.1 next 18th of Feb. Perhaps we should wait a couple more days and have the bleeding edge? :-)
[15:26] <dustymabe> otubo: how about we get 19.4 into rawhide and (f32) first
[15:27] <dustymabe> and then we leave 19.4 for f32 and go ahead and put 20.1 in rawhide after a month or two
[15:29] <otubo> dustymabe: yeah, I think perhaps that's better. No need to rush :-) Fedora is in 17.1 for two years now
[15:34] <dustymabe> otubo: 👍
[16:50] <smoser> why does tox environment creation take *so* long
[16:51] <smoser> oh.
[16:51] <smoser> ipv6 messup here.
[16:51] <smoser> suck
[17:26] <blackboxsw> nice email to the list btw Odd_Bloke on pytest
[18:05] <smoser> Odd_Bloke: you or i have some difference in lxc
[18:09] <smoser> http://paste.ubuntu.com/p/SgggZJChqV/
[18:09] <smoser> and fwiw.. at least before moving to github (and i think even still) some jenkins c-i runs run-container
[18:10] <smoser> to build centos
[18:10] <smoser> of course i can't see jenkins so i cant show you that
[18:22] <rharper> smoser:  at least the -proposed runs use run-container
[18:22] <rharper> and ctool wrappers run-container I think for the centos build
[18:22] <rharper> so we do need to sort those out
[18:22] <rharper> Odd_Bloke: ^
[18:30] <blackboxsw> also, in reviewing dan's code, I've found that our run-container centos (which I use during copr-build updates @ SRU time) have mismatched pkg deps for centos/7/8 that previously worked. I'm trying to sort that now as a separate PR from the pytest work
[18:34] <blackboxsw> and our copr build test in jenkins is using run-centos instead of run-container so checking that too as I think we should drop this depreceated tools/run-centos now as it's been deprecated since 2018-05-23
[18:35] <blackboxsw> that said, run-centos calls run-container anyway, so no big change there
[18:36] <blackboxsw> I'll put a PR up for jenkins jobs to fix that aspect
[18:36] <blackboxsw> and we can then drop tools/run-centos
[18:48] <blackboxsw> btw the shift to python3 (and dropping py2 support) looks like it is a significant problem for finding other python3 dependencies in CentOS 7 and 8. our last successful copr-build jenkins job worked when we were still using python2 packages on centos7. now it seems I'm unable to find deps like: python3-httpretty and python3-tox etc on CentOS 7 or 8.
[18:59] <blackboxsw> otubo: do you know offhand what repos I might be missing in our test vm setup to allow centos 8 or 7 vms to find python3-httpretty python3-unittest2 packages?  We generally rely on enabling epel repo. But, I see something about a PowerTools repo for CentOS 8 (not 7) that may contain more rpms cloud-init depends on for testing.
[19:00] <blackboxsw> otubo: question 1, is CentOS 8's PowerTools repo something that is generally public and recommended for access various python development packages?
[19:01] <Odd_Bloke> smoser: I see the same output from those lxc commands.
[19:02] <Odd_Bloke> Oh actually, I'm on a different system now, let me see if I can get run-container to work here.
[19:02] <blackboxsw> Question 2: Is there any way to access python3 rpms on CentOS 7 for httpretty, unittest2 and contextlib2
[19:02] <Odd_Bloke> OK, it's working on this system, I'll have to dig into the issue on the other system.
[19:03] <Odd_Bloke> I've definitely run into issues where the tooling assumes a local lxd remote before.
[19:03] <Odd_Bloke> So maybe it's that.
[19:05] <blackboxsw> otubo: those 2 questions may impact whether you'll have to patch cloud-init 20.1 etc if you are also somehow involved in CentOS updates when you are doing rawhide
[19:06] <blackboxsw> though not sure if CentOS is something you are typically involved in.
[19:13] <blackboxsw> here's the patchset I was starting for centos 8  https://paste.ubuntu.com/p/ft3QdgFqX7/
[19:13] <blackboxsw> against Dan's branch
[19:14] <blackboxsw> but I think it's still hitting Error: Unable to find a match: python3-httpretty python3-unittest2 python36-PyYAML python3-contextlib2 python-tox
[19:15] <rharper> blackboxsw: you have epel enabled ?
[19:15] <blackboxsw> strange is that Cent7 has python36-contextlib2-0.5.1-3.el7.noarch.rpm & python-contextlib2-0.5.1-3.el7.noarch.rpm  but Cent8 has no packages for this
[19:15] <blackboxsw> rharper: I do
[19:15] <rharper> ok, it may well be that real py3 on cent7 isn't easily available
[19:15] <blackboxsw> I'm thinking Cent8 may need that powertools repo too.
[19:16] <rharper> I'm sort of *ok* not producing cent7 py3; we've never done it in the past; and maybe the cent7 build should be done from the 19.4 release branch
[19:16] <rharper> ie, py2 support only
[19:16] <rharper> and then tip can be py3 cent8
[19:16] <blackboxsw> rharper: and yes i'm thinking py3 is only partially supported on Cent7 which means our recent drop of any py2 in Dec 2019  will prevent us from adding more copr builds for cent7 from here on forward
[19:16] <blackboxsw> yep
[19:16] <rharper> blackboxsw: unless we build from stable release branch
[19:17] <Odd_Bloke> Isn't paride looking at these failures?
[19:17] <rharper> we can update our jenkins jobs / copr build repos
[19:17] <rharper> Odd_Bloke: he was
[19:17] <rharper> I pointed him at my py3/fedora-build branch
[19:17] <Odd_Bloke> Let's make sure we aren't duplicating work here.
[19:17] <rharper> blackboxsw: yes
[19:17] <rharper> best to circle with paride next week
[19:17] <blackboxsw> right https://github.com/canonical/cloud-init/tree/stable-19.4
[19:17] <rharper> but I do think cent7 + py3 is not likely to happen
[19:17] <blackboxsw> I think that too
[19:17] <Odd_Bloke> This isn't urgent by any means, the builds have been broken for a minute.
[19:17] <rharper> nope
[19:17] <Odd_Bloke> Wasn't Cent7 the reason we haven't dropped 3.4 too?
[19:18] <rharper> no
[19:18] <rharper> SLes
[19:18] <blackboxsw> sles
[19:18] <blackboxsw> yeah
[19:18] <Odd_Bloke> Ah, my bad.
[19:22] <blackboxsw> -> lunch
[19:23] <Odd_Bloke> OK, so run-container doesn't work at all for CentOS 7 on master.  So my branch definitely doesn't regress it. :p
[19:23] <Odd_Bloke> That said, I've pushed up one change to pkg-deps.json which means that pytest runs and fails, rather than not being found at all.
[19:24] <Odd_Bloke> (Which appears to be a step up from master, actually, where I see: /usr/bin/python3: No module named nose)
[19:30] <blackboxsw> Odd_Bloke: +1 on centos not being related to your branch. I think generally the pkg-deps.json is broken since end of-jan when we  dropped py2 support in that tool
[19:30] <blackboxsw> I'd be fine with us not dealing with the centos deps issues in your branch as long as we are certain we aren't regressing specifically on the pytest package dependency.
[19:31] <blackboxsw> which is, I guess, what you just said
[19:31]  * blackboxsw really goes to make some lunch now
[19:32] <Odd_Bloke> :)
[19:32] <Odd_Bloke> Yep, and I've pushed up a change so we aren't regressing on the pytest change.
[19:36] <meena> anyone fixed all my bugs yet?
[19:38] <meena> actually, just one "bug" networking.
[19:38] <meena> would love to read some …. official thoughts on the mailinglist.
[19:47] <blackboxsw> meena ,is this related to cloudinit.net refactor and potentially blowing up cloudinit.net modules in favor of network-aware distro classes versus keeping cloudinit.net modules/functions a place where the modules themselves know a bit about distro-specific needs? per https://lists.launchpad.net/cloud-init/msg00237.html
[19:59] <meena> blackboxsw: in particular, re robjo 's, whos' suggestion is pretty, good, i think.
[20:16] <blackboxsw> shhh, it'll go to his head ;)
[20:53] <meena> ¯\(°_o)/¯
[21:08] <johnsonshi> Is there currently a way to specify the size of a partition in terms of actual bytes and not as a percentage of disk space using the disk_setup module? From the docs: "The size for partitions is specified in percentage of disk space, not in bytes (e.g. a size of 33 would take up 1/3 of the disk space)."
[21:20] <Odd_Bloke> johnsonshi: I believe the docs are correct, I'm afraid.
[21:21] <johnsonshi> Odd_Bloke: thanks!
[21:21] <rharper> Odd_Bloke: hehe
[21:23] <Odd_Bloke> rharper: We can't even win when they're accurate!
[21:23] <Odd_Bloke> ;)
[21:23] <rharper> =)
[21:23] <rharper> lol
[21:23] <blackboxsw> haha
[21:33] <meena> you can't win with FLOSS
[21:33] <meena> just, surrender.
[21:33] <meena> (and fix all my bugs, please)
[22:04] <blackboxsw> meena, man this cloudinit.net discussion is a tough one. I can see the need for making things distro-specific for sysconfig render cases because rhel and suse differ significantly in how they handle sysconfig options for various needs.  But, from the perspective of eni, freebsd(/etc/rc.conf)  and netplan (/etc/netplan/*) these network renders are specific to the single network backend that they are talking to. In
[22:04] <blackboxsw> eni's case, not much difference between debian and ubuntu. netplan is it's own thing for netplan backend and freebsd renderer is it's own thing for /etc/rc.conf .  Given the netbsd support branch  https://github.com/canonical/cloud-init/pull/62 it doesen't seem like too much difference there in how rc.conf is rendered on ehandled
[22:05] <blackboxsw> *on each "flavor"