/srv/irclogs.ubuntu.com/2020/02/14/#cloud-init.txt

otuborharper: 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 pinging09:57
otubomhayden: 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/614:33
dustymabeotubo: woot!15:02
dustymabethat's awesome15:02
dustymabeotubo: i'll try to have it reviewed by Monday15:22
otubodustymabe: 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:25
dustymabeotubo: how about we get 19.4 into rawhide and (f32) first15:26
dustymabeand then we leave 19.4 for f32 and go ahead and put 20.1 in rawhide after a month or two15:27
otubodustymabe: yeah, I think perhaps that's better. No need to rush :-) Fedora is in 17.1 for two years now15:29
dustymabeotubo: 👍15:34
smoserwhy does tox environment creation take *so* long16:50
smoseroh.16:51
smoseripv6 messup here.16:51
smosersuck16:51
blackboxswnice email to the list btw Odd_Bloke on pytest17:26
smoserOdd_Bloke: you or i have some difference in lxc18:05
smoserhttp://paste.ubuntu.com/p/SgggZJChqV/18:09
smoserand fwiw.. at least before moving to github (and i think even still) some jenkins c-i runs run-container18:09
smoserto build centos18:10
smoserof course i can't see jenkins so i cant show you that18:10
rharpersmoser:  at least the -proposed runs use run-container18:22
rharperand ctool wrappers run-container I think for the centos build18:22
rharperso we do need to sort those out18:22
rharperOdd_Bloke: ^18:22
blackboxswalso, 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 work18:30
blackboxswand 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-2318:34
blackboxswthat said, run-centos calls run-container anyway, so no big change there18:35
blackboxswI'll put a PR up for jenkins jobs to fix that aspect18:36
blackboxswand we can then drop tools/run-centos18:36
blackboxswbtw 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:48
blackboxswotubo: 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.18:59
blackboxswotubo: question 1, is CentOS 8's PowerTools repo something that is generally public and recommended for access various python development packages?19:00
Odd_Blokesmoser: I see the same output from those lxc commands.19:01
Odd_BlokeOh actually, I'm on a different system now, let me see if I can get run-container to work here.19:02
blackboxswQuestion 2: Is there any way to access python3 rpms on CentOS 7 for httpretty, unittest2 and contextlib219:02
Odd_BlokeOK, it's working on this system, I'll have to dig into the issue on the other system.19:02
Odd_BlokeI've definitely run into issues where the tooling assumes a local lxd remote before.19:03
Odd_BlokeSo maybe it's that.19:03
blackboxswotubo: 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 rawhide19:05
blackboxswthough not sure if CentOS is something you are typically involved in.19:06
blackboxswhere's the patchset I was starting for centos 8  https://paste.ubuntu.com/p/ft3QdgFqX7/19:13
blackboxswagainst Dan's branch19:13
blackboxswbut I think it's still hitting Error: Unable to find a match: python3-httpretty python3-unittest2 python36-PyYAML python3-contextlib2 python-tox19:14
rharperblackboxsw: you have epel enabled ?19:15
blackboxswstrange 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 this19:15
blackboxswrharper: I do19:15
rharperok, it may well be that real py3 on cent7 isn't easily available19:15
blackboxswI'm thinking Cent8 may need that powertools repo too.19:15
rharperI'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 branch19:16
rharperie, py2 support only19:16
rharperand then tip can be py3 cent819:16
blackboxswrharper: 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 forward19:16
blackboxswyep19:16
rharperblackboxsw: unless we build from stable release branch19:16
Odd_BlokeIsn't paride looking at these failures?19:17
rharperwe can update our jenkins jobs / copr build repos19:17
rharperOdd_Bloke: he was19:17
rharperI pointed him at my py3/fedora-build branch19:17
Odd_BlokeLet's make sure we aren't duplicating work here.19:17
rharperblackboxsw: yes19:17
rharperbest to circle with paride next week19:17
blackboxswright https://github.com/canonical/cloud-init/tree/stable-19.419:17
rharperbut I do think cent7 + py3 is not likely to happen19:17
blackboxswI think that too19:17
Odd_BlokeThis isn't urgent by any means, the builds have been broken for a minute.19:17
rharpernope19:17
Odd_BlokeWasn't Cent7 the reason we haven't dropped 3.4 too?19:17
rharperno19:18
rharperSLes19:18
blackboxswsles19:18
blackboxswyeah19:18
Odd_BlokeAh, my bad.19:18
blackboxsw-> lunch19:22
Odd_BlokeOK, so run-container doesn't work at all for CentOS 7 on master.  So my branch definitely doesn't regress it. :p19:23
Odd_BlokeThat 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:23
Odd_Bloke(Which appears to be a step up from master, actually, where I see: /usr/bin/python3: No module named nose)19:24
blackboxswOdd_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 tool19:30
blackboxswI'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:30
blackboxswwhich is, I guess, what you just said19:31
* blackboxsw really goes to make some lunch now19:31
Odd_Bloke:)19:32
Odd_BlokeYep, and I've pushed up a change so we aren't regressing on the pytest change.19:32
meenaanyone fixed all my bugs yet?19:36
meenaactually, just one "bug" networking.19:38
meenawould love to read some …. official thoughts on the mailinglist.19:38
blackboxswmeena ,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.html19:47
meenablackboxsw: in particular, re robjo 's, whos' suggestion is pretty, good, i think.19:59
blackboxswshhh, it'll go to his head ;)20:16
meena¯\(°_o)/¯20:53
johnsonshiIs 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:08
Odd_Blokejohnsonshi: I believe the docs are correct, I'm afraid.21:20
johnsonshiOdd_Bloke: thanks!21:21
rharperOdd_Bloke: hehe21:21
Odd_Blokerharper: We can't even win when they're accurate!21:23
Odd_Bloke;)21:23
rharper=)21:23
rharperlol21:23
blackboxswhaha21:23
meenayou can't win with FLOSS21:33
meenajust, surrender.21:33
meena(and fix all my bugs, please)21:33
blackboxswmeena, 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. In22:04
blackboxsweni'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 ehandled22:04
blackboxsw*on each "flavor"22:05

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