Wednesday, 2020-02-12

ianwi'm not really seeing the error in https://zuul.opendev.org/t/openstack/build/4526f76400124cc3929afc3dd2210463/log/job-output.txt#209900:00
clarkbianw: its the warnings below00:02
clarkbhttps://zuul.opendev.org/t/openstack/build/4526f76400124cc3929afc3dd2210463/log/job-output.txt#2100-211700:02
clarkbwe have to remove the :: prefix because in puppet4 its redundant and the linter decided to stop allowing it because rewriting things like that is fun?!00:03
ianwthat's a bunch of unrelated files, this job must have not run on this code since it was updated00:04
clarkbya and its a relatively new linter things (within the last month iirc)00:04
*** sreejithp_ has quit IRC00:05
*** rcernin has joined #openstack-infra00:07
*** artom has quit IRC00:10
*** slaweq has joined #openstack-infra00:11
openstackgerritIan Wienand proposed opendev/puppet-askbot master: Stop using python::virtualenv  https://review.opendev.org/70725500:12
openstackgerritIan Wienand proposed opendev/puppet-askbot master: Remove ::'s that linter now complians about  https://review.opendev.org/70727600:12
ianwif that lints, i think we force-merge both00:13
ianwrechecking 705670 if it was an in-flight change00:13
*** artom has joined #openstack-infra00:14
ianwyeah, it's running00:15
*** artom has quit IRC00:15
*** artom has joined #openstack-infra00:15
*** slaweq has quit IRC00:16
ianwi have no idea why afsmon has "Babel!=2.4.0,>=2.3.4 # BSD" ... but guess what version of babel is packaged in bionic00:19
clarkbha00:20
clarkbwhen it rains it pours00:20
ianwthere aren't even any docs in afsmon, i have no idea why i included it00:24
clarkbbabel is for translations?00:24
clarkbmaybe it just got pulled in via some templated thing?00:24
ianwor pbr?00:25
clarkbI thought pbr avoided runtime deps00:27
openstackgerritIan Wienand proposed opendev/afsmon master: Remove Babel requirement  https://review.opendev.org/70727700:31
clarkb+200:31
fungipbr does end up depending on pkg_resources, but lazy-loaded i think00:32
clarkbya setuptools too00:32
clarkb(but it runs via setuptools so thats sort of an assumed dep)00:32
fungisure00:34
fungihonestly, pip has more deps than pbr, though it vendors them00:34
*** tosky has quit IRC00:38
ianwsigh, now flake8, presumably a newer version, fails on afsmon00:41
*** armax has joined #openstack-infra00:43
openstackgerritIan Wienand proposed opendev/afsmon master: Remove Babel requirement  https://review.opendev.org/70727700:47
openstackgerritIan Wienand proposed opendev/afsmon master: flake8 regex fixes  https://review.opendev.org/70728100:47
*** rf0lc0 has quit IRC00:50
*** rcernin has quit IRC00:55
*** rcernin has joined #openstack-infra00:55
ianw705670 still isn't quite happy, although i wonder if it has actually correctly deployed all the code from the depends-on00:57
ianwhttps://zuul.opendev.org/t/openstack/build/6a7ebef337af4a948dceb4250d6ce4da/log/applytest/puppetapplytest46.final.out.FAILED00:58
ianwhttps://zuul.opendev.org/t/openstack/build/6a7ebef337af4a948dceb4250d6ce4da/log/applytest/puppetapplytest47.final.out.FAILED00:58
ianwarrgh, no, i've stuffed up 707255 fixing the lint issues01:01
openstackgerritIan Wienand proposed opendev/puppet-askbot master: Stop using python::virtualenv  https://review.opendev.org/70725501:03
ianwthis time for sure01:04
openstackgerritMerged opendev/afsmon master: flake8 regex fixes  https://review.opendev.org/70728101:05
openstackgerritMerged opendev/afsmon master: Remove Babel requirement  https://review.opendev.org/70727701:05
*** masayukig is now known as migawa|AFK01:08
*** migawa|AFK is now known as migawa01:09
openstackgerritIan Wienand proposed opendev/system-config master: Move afsmon to mirror-update.opendev.org  https://review.opendev.org/70726701:10
*** slaweq has joined #openstack-infra01:11
*** jamesmcarthur has joined #openstack-infra01:12
*** slaweq has quit IRC01:16
*** rlandy has quit IRC01:17
*** jamesmcarthur has quit IRC01:23
*** stevebaker has quit IRC01:24
*** stevebaker has joined #openstack-infra01:26
*** sgw has quit IRC01:26
*** jamesmcarthur has joined #openstack-infra01:36
openstackgerritIan Wienand proposed opendev/puppet-askbot master: Stop using python::virtualenv  https://review.opendev.org/70725501:46
*** yamamoto has joined #openstack-infra01:57
ianwgoing afk for a little for lunch, then i think i can sort out getting the system-config gate up again02:00
*** slaweq has joined #openstack-infra02:11
*** yamamoto has quit IRC02:12
*** yamamoto has joined #openstack-infra02:13
*** slaweq has quit IRC02:16
*** yamamoto has quit IRC02:17
*** ricolin has joined #openstack-infra02:19
*** roman_g has quit IRC02:34
*** jamesmcarthur has quit IRC02:38
*** yamamoto has joined #openstack-infra02:40
*** jamesmcarthur has joined #openstack-infra02:53
*** yamamoto has quit IRC03:01
*** yamamoto has joined #openstack-infra03:03
*** rcernin has quit IRC03:06
*** slaweq has joined #openstack-infra03:11
ianwok, so 707255 now only has one puppet failure, which is the afsmon virtualenv deployment.  this is the circular dependency.  so i am going to force  merge  707276 (lint changes) & 70725503:12
openstackgerritMerged opendev/puppet-askbot master: Remove ::'s that linter now complians about  https://review.opendev.org/70727603:15
openstackgerritMerged opendev/puppet-askbot master: Stop using python::virtualenv  https://review.opendev.org/70725503:16
*** slaweq has quit IRC03:16
ianwwith the 1.2 release of afsmon, pip doesn't pull any non-deb-packaged dependencies in -> https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_6ec/707267/3/check/system-config-run-mirror-update/6ec965c/bridge.openstack.org/ara-report/result/52902a76-329c-440b-8dc3-f1c82f627a78/03:17
ianwrechecking https://review.opendev.org/#/c/707267/ which should now pass zuul03:18
ianwand removed myself from bootstrappers03:18
*** sgw has joined #openstack-infra03:21
*** psachin has joined #openstack-infra03:21
*** rcernin has joined #openstack-infra03:22
*** pcrews has joined #openstack-infra03:23
openstackgerritIan Wienand proposed opendev/system-config master: Move afsmon to mirror-update.opendev.org  https://review.opendev.org/70726703:39
*** jamesmcarthur has quit IRC03:55
*** udesale has joined #openstack-infra04:05
*** gyee has quit IRC04:08
*** ramishra has joined #openstack-infra04:09
*** slaweq has joined #openstack-infra04:11
*** slaweq has quit IRC04:16
*** rcernin has quit IRC04:16
*** rcernin has joined #openstack-infra04:16
*** dSrinivas has quit IRC04:32
*** ramishra has quit IRC04:32
*** psachin has quit IRC04:33
*** artom has quit IRC04:35
weshayianw, hey buddy.. have an issue blocking container builds in tripleo.. getting an error re: blacklist on https://review.opendev.org/#/c/707204/04:39
weshayhttps://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_50e/707204/4/check/openstack-tox-validate/50e08c4/job-output.txt04:40
weshayany idea what's going on there?04:40
prometheanfireweshay: hi :D04:43
weshayhowdy04:43
*** dave-mccowan has quit IRC04:43
prometheanfirepython-ironicclient!=2.5.2,!=2.7.1,!=3.0.0,>=2.3.0;python_version>='3.5'04:44
weshayis the issue >=2.3.004:44
prometheanfirethat doesn't need the minimum specified04:44
weshayand needs to be 2.3.1?04:44
prometheanfiresame for the line above actually04:44
prometheanfiresee how I'm doing https://review.opendev.org/70726104:45
weshayk.. the error did indicate that.. /me looks04:45
prometheanfireadd the cap for py27 and specifiy an uncapped line (same as before) for py304:46
*** ramishra has joined #openstack-infra04:46
* weshay looking04:46
prometheanfireand you py_version should be >=3.6, not 3.504:46
prometheanfirehttps://github.com/openstack/python-ironicclient/blob/4.0.0/setup.cfg specifies 3.6/3.7 only04:47
prometheanfireshould really have a cap on python_version, but that'd just be annoying, and python is forward compat right? :D04:47
weshayk.. hearing slightly different things from diff folks.. so it goes :)04:47
* prometheanfire stares at py3904:47
weshayaye04:47
weshaylolz04:47
* prometheanfire is ptl of the reqs project if it helps04:48
prometheanfirealso #openstack-requirements04:48
weshaythat always does :)04:48
weshaythanks for the assist04:48
weshayk.. let's see if I grok this.. making a change04:48
prometheanfirenp, was trawling through the channels04:48
*** migawa is now known as migawa|lunch|AFK04:50
weshayso..04:51
weshaypython-ironicclient!=2.5.2,!=2.7.1,!=3.0.0,>=2.3.1,<4.0.0;python_version=='2.7'  # Apache-2.004:51
weshaypython-ironicclient!=2.5.2,!=2.7.1,!=3.0.0,>=2.3.1;python_version>='3.6'  # Apache-2.004:51
weshaypy27 is capped <4.0.004:51
weshaypy3.6+ is not capped but retains the excludes certain versions04:51
prometheanfireyou are still specifying the min version04:51
weshayk04:51
prometheanfire(you shouldn't be)04:52
weshaypython-ironicclient!=2.5.2,!=2.7.1,!=3.0.0,>=2.3.1,<4.0.0;python_version=='2.7'  # Apache-2.004:52
weshaypython-ironicclient!=2.5.2,!=2.7.1,!=3.0.0;python_version>='3.6'  # Apache-2.004:52
prometheanfirelooks about right, submit it and I'll look at the diff in gertty04:52
prometheanfiremight want to fix the commit message too (spacing) :D04:54
weshayprometheanfire, last question.. when we were running tests locally against the requirements for tripleo-common.. change https://review.opendev.org/#/c/707054/04:54
openstackgerritMerged opendev/system-config master: Move afsmon to mirror-update.opendev.org  https://review.opendev.org/70726704:54
* prometheanfire now knows why kevin was interested in the review04:54
weshayit seemed we had to match exactly what was in global requirements or the requirements-check job failed04:55
prometheanfireyou are allowed to define minimums in your project's configs, but we don't define them globally04:55
weshayah.. k.. that's probably what we did.. copy from tc to global04:55
prometheanfirewhat you had to match for the minimum was a lower-constraints file04:55
weshayk.. makes sense04:56
weshayk04:56
weshaythanks for the help :)04:56
weshayprometheanfire++04:56
prometheanfireeach project might specify a diferent minimum (swift likes to keep things nice and ancient), but they all must work with whatever is in upper-constraints04:56
prometheanfirenp04:56
*** ykarel|away is now known as ykarel04:58
prometheanfireonemore change :P04:58
weshayoh both mins k04:59
weshayyou can lead a horse04:59
*** rcernin is now known as rcernin|lunch05:01
weshayshould be fixed now05:01
prometheanfirethat one looks good05:01
weshayman.. my brain understood and fingers are too anxious to type05:01
prometheanfire:D05:02
weshay\0/05:08
*** slaweq has joined #openstack-infra05:11
*** slaweq has quit IRC05:16
*** migawa|lunch|AFK is now known as migawa|lunch05:18
timburke"ancient", "stable" -- to-may-to, to-mah-to05:25
prometheanfiretimburke: vulnerable?  I'm sure there's something somewhere...05:30
*** evrardjp has quit IRC05:34
*** evrardjp has joined #openstack-infra05:34
timburkei don't feel like it's my decision to make. that's on distros, vendors, and deployers -- when it comes down to it, operators and their risk tolerances05:36
timburkeultimately, dropping support for older versions of my dependencies only increases upgrade friction05:36
ianw"Unable to find any of pip3 to use.  pip needs to be installed." ... i feel like this is the same thing mordred saw05:37
prometheanfiretimburke: sure, I'm just poking fun05:39
openstackgerritIan Wienand proposed opendev/system-config master: afsmon: install python3-pip  https://review.opendev.org/70731305:39
*** jamesmcarthur has joined #openstack-infra05:57
*** goldyfruit has quit IRC05:58
*** goldyfruit has joined #openstack-infra05:58
*** jamesmcarthur has quit IRC06:01
*** slaweq has joined #openstack-infra06:11
*** slaweq has quit IRC06:16
openstackgerritMerged opendev/system-config master: afs-release: run every 5 minutes  https://review.opendev.org/70706006:19
*** goldyfruit has quit IRC06:30
*** goldyfruit has joined #openstack-infra06:30
*** lmiccini has joined #openstack-infra06:36
*** jtomasek has joined #openstack-infra06:51
*** slaweq has joined #openstack-infra07:08
*** slaweq has quit IRC07:15
*** ysastri has joined #openstack-infra07:15
*** cshen has joined #openstack-infra07:18
ysastriHello my zuul checks failed for the 3rd time with same error ERROR: not a btrfs filesystem: /var/lib/lxc. This time in TASK [haproxy_server : Ensure haproxy_hatop_download_path exists]. I don't have any idea how to proceed. https://zuul.opendev.org/t/openstack/build/553ab6b3936c4215b902fbfd3fd3d1d207:19
*** pgaxatte has joined #openstack-infra07:19
*** rpittau|afk is now known as rpittau07:21
*** pgaxatte has quit IRC07:24
*** pgaxatte has joined #openstack-infra07:24
*** yoctozepto has quit IRC07:28
*** raukadah is now known as chkumar|rover07:28
*** yoctozepto has joined #openstack-infra07:28
*** lpetrut has joined #openstack-infra07:31
*** stevebaker has quit IRC07:31
*** yoctozepto has quit IRC07:33
*** ysastri has quit IRC07:35
*** iurygregory has joined #openstack-infra07:35
*** kopecmartin|afk is now known as kopecmartin07:44
*** ianychoi has joined #openstack-infra07:46
*** slaweq has joined #openstack-infra07:51
*** imacdonn has quit IRC07:54
*** imacdonn has joined #openstack-infra07:54
*** ykarel is now known as ykarel|lunch07:55
*** slaweq has quit IRC07:57
*** slaweq has joined #openstack-infra07:59
*** yoctozepto has joined #openstack-infra07:59
*** xek_ has joined #openstack-infra08:09
*** tkajinam has quit IRC08:10
*** dchen has quit IRC08:16
*** tosky has joined #openstack-infra08:22
*** ccamacho has joined #openstack-infra08:27
openstackgerritTobias Henkel proposed zuul/zuul master: Support pausing merge jobs  https://review.opendev.org/70719208:28
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: ensure-tox: include tox-venv plugin  https://review.opendev.org/70723708:29
*** yamamoto has quit IRC08:30
*** roman_g has joined #openstack-infra08:31
*** pkopec has joined #openstack-infra08:36
*** ralonsoh has joined #openstack-infra08:38
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: WIP: ensure-tox to verify module calling  https://review.opendev.org/70733508:42
*** yamamoto has joined #openstack-infra08:44
*** dtantsur|afk is now known as dtantsur08:45
*** jpena|off is now known as jpena08:50
openstackgerritMatthieu Huin proposed zuul/zuul master: Authorization rules: add templating  https://review.opendev.org/70519308:52
*** gfidente|afk is now known as gfidente08:58
openstackgerritNoam Angel proposed openstack/diskimage-builder master: fix iscsi-boot element exiting build even if dracut-regenerate used  https://review.opendev.org/70734009:00
*** ysastri has joined #openstack-infra09:03
*** lucasagomes has joined #openstack-infra09:06
openstackgerritNoam Angel proposed openstack/diskimage-builder master: fix iscsi-boot element exiting build even if dracut-regenerate used  https://review.opendev.org/70734009:09
*** cshen has quit IRC09:17
jpenahi! It looks like https://review.opendev.org/707199 has broken dib images for centos 8, since the "--seeder=pip" command line option is not supported by virtualenv 15.1.009:21
*** iurygregory has quit IRC09:21
jpenathat is the version packaged by rhel/centos 8, and we can only install it from package09:21
*** tetsuro has joined #openstack-infra09:27
*** cshen has joined #openstack-infra09:33
*** pkopec has quit IRC09:37
*** cshen has quit IRC09:37
openstackgerritMerged opendev/system-config master: afsmon: install python3-pip  https://review.opendev.org/70731309:38
*** pkopec has joined #openstack-infra09:39
*** iurygregory has joined #openstack-infra09:39
openstackgerritAlfredo Moralejo proposed openstack/project-config master: Revert "Use virtualenv --seeder=pip so that libs are accessible"  https://review.opendev.org/70734609:39
*** ykarel|lunch is now known as ykarel09:41
openstackgerritAlfredo Moralejo proposed openstack/project-config master: Revert "Use virtualenv --seeder=pip so that libs are accessible"  https://review.opendev.org/70734609:41
openstackgerritAlfredo Moralejo proposed openstack/project-config master: Revert "Use virtualenv --seeder=pip so that libs are accessible"  https://review.opendev.org/70734609:42
*** amoralej has joined #openstack-infra09:46
*** cshen has joined #openstack-infra09:56
*** ociuhandu has joined #openstack-infra09:56
*** derekh has joined #openstack-infra10:13
*** rcernin|lunch has quit IRC10:22
*** kaisers has quit IRC10:27
*** kaisers has joined #openstack-infra10:35
*** rcernin|lunch has joined #openstack-infra10:36
*** cshen has quit IRC10:46
*** pkopec has quit IRC10:47
openstackgerritNeil Jerram proposed openstack/project-config master: Remove networking-calico from infrastructure systems  https://review.opendev.org/70736010:47
*** sshnaidm_ has joined #openstack-infra10:49
*** sshnaidm has quit IRC10:49
*** sshnaidm_ is now known as sshnaidm10:49
*** pkopec has joined #openstack-infra10:56
*** Nizars has joined #openstack-infra11:03
*** cshen has joined #openstack-infra11:03
*** cshen has quit IRC11:05
*** udesale has quit IRC11:06
*** cshen has joined #openstack-infra11:08
*** zxiiro has quit IRC11:13
*** armax has quit IRC11:14
ysastriZuul check failed again now 4th time starting from yesterday. https://zuul.opendev.org/t/openstack/build/3aa56b53f7c24f87b442608e9688df5111:16
*** armax has joined #openstack-infra11:19
*** Lucas_Gray has joined #openstack-infra11:27
amoralejmay i get attention on https://review.opendev.org/#/c/707346/ ?11:29
amoralejcentos jobs are currently broken, i expect that to help11:30
*** rpittau is now known as rpittau|bbl11:33
*** armax has quit IRC11:44
*** ysastri has quit IRC11:47
mnasiadkaamoralej: I don't know if there's any infra-root in european timezone...11:53
amoralejack11:54
amoralejthx mnasiadka11:54
mnasiadkaalthough I can confirm that virtualenv 20.0.2 works with six 1.14.011:54
*** jaosorior has joined #openstack-infra12:01
*** nicolasbock has joined #openstack-infra12:06
*** ysastri has joined #openstack-infra12:06
*** ociuhandu has quit IRC12:09
*** ociuhandu has joined #openstack-infra12:10
*** rfolco has joined #openstack-infra12:10
*** sshnaidm has quit IRC12:20
*** ianychoi has quit IRC12:25
*** rfolco has quit IRC12:26
*** rfolco has joined #openstack-infra12:26
*** sshnaidm has joined #openstack-infra12:27
*** sshnaidm has quit IRC12:31
*** udesale has joined #openstack-infra12:34
*** sshnaidm has joined #openstack-infra12:41
*** jpena is now known as jpena|lunch12:49
*** amoralej is now known as amoralej|lunch12:56
*** rlandy has joined #openstack-infra12:57
*** sshnaidm has quit IRC13:02
*** rpittau|bbl is now known as rpittau13:05
*** jamesmcarthur has joined #openstack-infra13:09
*** ociuhandu has quit IRC13:11
*** ykarel is now known as ykarel|afk13:14
AJaeger_ysastri: infra images don't have btrfs, if you need that , you need to set it up. I wonder whether this is a new requirement due to an updated lxc package - or your setup is broken. Best ask on the #openstack-ansible channel13:16
*** sshnaidm has joined #openstack-infra13:17
*** sshnaidm has quit IRC13:18
AJaeger_ amoralej|lunch, sorry missing context to review that - this was done yesterday by some US based team members, let's wait for them13:18
*** sshnaidm has joined #openstack-infra13:18
*** dave-mccowan has joined #openstack-infra13:19
jrosserAJaeger_: its just noisy logging - if there were a btrfs filesystem it would print some info, the code is not smart enough to be quiet when there is no btrfs13:24
jrosserit's not actually what is failing the job at all13:24
*** dave-mccowan has quit IRC13:26
*** sshnaidm has quit IRC13:28
*** sshnaidm has joined #openstack-infra13:29
*** derekh has quit IRC13:30
*** Lucas_Gray has quit IRC13:31
fungiyeah, i'm catching up, looks like ianw got some of the blockers for system-config solved overnight while i was in low-power standby mode13:33
*** jpena|lunch is now known as jpena13:33
*** Lucas_Gray has joined #openstack-infra13:34
*** jamesmcarthur has quit IRC13:35
AJaeger_jrosser: thanks for explanation, let's tell ysastri about it ^13:37
*** rh-jelabarre has joined #openstack-infra13:39
fungiysastri: i don't think that error message has anything to do with your job failure. you're probably better off asking in #openstack-ansible but i suspect the problem is missing selinux module for python: https://zuul.opendev.org/t/openstack/build/553ab6b3936c4215b902fbfd3fd3d1d2/log/job-output.txt#1261213:40
zbrcan we add a six>1.14.0 to https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-tox/tasks/main.yaml#L11 ?13:41
zbrsomehow this line bring incompatible virtualenv with it13:42
zbrpersonally I would cap the virtualenv to <20, but based on what I seen around, this would not be popular.13:42
* AJaeger_ is back offline - too bad internet during a train ride ;(13:43
*** nicolasbock has quit IRC13:43
zbrthe reality is that this simple line brings incompatible virtualenv-six mix13:43
fungijpena: amoralej|lunch: change 707346 would revert changes we made to how we invoke virtualenv when building centos-8 images, not to how jobs run the virtualenv command on centos-8 images. i agree the revert should be safe now, but a link to a job failure would be good so we can see what's actually breaking13:44
fungias i doubt that particular revert is going to solve whatever job problems you're seeing13:45
*** jamesmcarthur has joined #openstack-infra13:45
jpenafungi: it's not just a job, it's diskimage-buider failing to build images. See https://softwarefactory-project.io/nodepool-log/upstream-centos-8-0000006898.log for an example13:46
jpena"venv: error: unrecognized arguments: --seeder=pip"13:46
fungijpena: okay, thanks, so it's not a job failure at all13:46
fungithen i agree, we ought to be able to just revert13:46
jpenathanks!13:47
fungithough i find it interesting that software factory is utilizing elements from our project-config repo13:47
fungii don't think this change broke *our* image building13:47
fungibecause we install virtualenv from pypi on our images13:47
*** nicolasbock has joined #openstack-infra13:47
jpenafungi: we are building a centos-8 iamges using the same elements as upstream, for use by tripleo 3rd party ci13:48
*** ociuhandu has joined #openstack-infra13:48
fungii strongly recommend not reusing our project-config dib elements out of context. they're tuned for our ci environment and make a lot of assumptions about how we build our opendev images13:48
jpenafungi: I think the opendev centos-8 image must be broken too, since centos8/rhel8 always installs virtualenv from package (as per diskimage-builder)13:48
fungi"venv: error: unrecognized arguments: --seeder=pip" https://nb01.openstack.org/centos-8-0000066750.log13:50
fungiyep13:50
fungiwe didn't do a good enough job of making sure we replaced the system package13:50
*** rcernin|lunch has quit IRC13:50
fungianyway, i approved the revert, we should hopefully have new centos-8 images once that lands13:51
jpenaack, thanks!13:51
fungi(and then they build and get uploaded to our providers anyway)13:51
*** ociuhandu has quit IRC13:52
*** eharney has quit IRC13:55
ysastriAJaeger_: Thanks I added the question in #openstack-ansible . I don't have any requirement for btrfs.13:56
fungiysastri: but also, it looks like the error is earlier in the log, about missing python-libselinux13:57
*** amoralej|lunch is now known as amoralej13:58
fungijpena: amoralej|lunch: in fact, the problem has nothing to do with how virtualenv is installed *in* the images because we're running virtualenv from outside the image chroot entirely. it broke all our image builds because the version of virtualenv installed system-wide on our nodepool builders is too old to understand the --seeder option: https://nb01.openstack.org/ubuntu-bionic-0000098357.log13:58
openstackgerritMerged openstack/project-config master: Revert "Use virtualenv --seeder=pip so that libs are accessible"  https://review.opendev.org/70734614:00
*** lbragstad has quit IRC14:02
*** lbragstad has joined #openstack-infra14:02
*** ociuhandu has joined #openstack-infra14:04
fungijpena: amoralej: okay, now i've convinced myself we're running the virtualenv installed inside the images, but that the version we're invoking even within the context of ubuntu-bionic images is still too old to support the --seeder option14:05
fungianyway, thanks for catching that and pushing the revert14:05
*** derekh has joined #openstack-infra14:05
*** ykarel|afk is now known as ykarel14:06
fungii still have concerns about software factory reusing opendev's custom dib elements directly from openstack/project-config, but that's worth a separate discussion14:06
*** wissamsawah47 has joined #openstack-infra14:06
*** lbragstad has quit IRC14:08
*** jamesmcarthur has quit IRC14:11
*** jamesmcarthur has joined #openstack-infra14:12
*** wissamsawah47 has quit IRC14:12
*** pgaxatte has quit IRC14:12
openstackgerritZygimantas Matonis proposed openstack/diskimage-builder master: Add Docker CE engine DIB element  https://review.opendev.org/70739114:12
fungimordred: 705671 and its children need rebases now due to an outdated parent (705670)14:14
*** pgaxatte has joined #openstack-infra14:14
*** ociuhandu has quit IRC14:15
*** ian-pittwood has joined #openstack-infra14:16
*** jamesmcarthur has quit IRC14:17
*** tesseract has quit IRC14:20
ian-pittwoodHello, all. I have been working on helping transition airship/airshipctl to use GitHub Issues from Jira Cloud. As part of this transition, I realized that the project still had OpenStack Storyboard enabled. I created this patchset (https://review.opendev.org/#/c/707262/1) to disable Storyboard and I found in this document14:23
ian-pittwood(https://docs.openstack.org/infra/system-config/jeepyb.html) that it seems like we can indicate our use of GitHub Issues using the "has-issues" option. Unfortunately, the build for my change failed with an error that "has-issues" isn't a valid option. Does anyone know if projects have the ability to set "has-issues"? Am I doing something wrong?14:23
fungiian-pittwood: i think the has-issues option is specifically for toggling the pull-request closer, though i don't know if unsetting that been exercised in a very long time14:26
fungilemme go digging in the jeepyb source code14:26
ian-pittwoodThanks, fungi14:26
*** Nizars has quit IRC14:27
fungiregardless, we're not going to set up opendev integration into proprietary issue trackers, so you'll be best off mentioning the location in your readme files14:27
zbri am trying a tox fix, but we cannot really rely on it https://github.com/tox-dev/tox/pull/1519/files14:28
ian-pittwoodWell it's not supposed to be proprietary. Do you just mean external issue trackers?14:29
fungigithub is not free/libre open source software14:29
ian-pittwoodWell that's a fair point14:30
fungiian-pittwood: so the has-issues toggle is used in manage_projects.py for a (deprecated) github project autocreation feature (so that we could turn off github issues on the autocreated mirror repos), nowhere else that i can find14:31
ian-pittwoodOk, well thanks for taking a look. I'll just remove it and put a link in the README as you suggested.14:31
zbrfungi: what counts as  free/libre open source? can we be more specific?14:31
fungizbr: osi-approved licenses14:31
fungisoftware distributed under them14:32
ian-pittwoodIn that same vein, is it possible to make per project gerrit hooks? I think the answer is probably no, but I thought I'd ask14:32
*** jaosorior has quit IRC14:32
fungizbr: github doesn't even publish the source code for their services as far as i know, much less do so under an osi-approved free/libre open source license14:32
*** jaosorior has joined #openstack-infra14:32
zbri asked as I was curious if jira would be acceptable, as the source is available.14:33
fungiian-pittwood: we also want to get rid of the gerrit hook scripts, generally everything they do could be replaced by zuul jobs14:33
openstackgerritDaniel Bengtsson proposed openstack/cookiecutter master: Update the minversion parameter.  https://review.opendev.org/70739714:33
ian-pittwoodAh, I see. I'll look into that instead. Thanks, fungi.14:34
dulekFolks, can you freeze a gate VM for me an my debugging? Talking about this thing: https://review.opendev.org/#/c/706529/. My SSH key is at https://github.com/dulek.keys.14:34
*** sgw has quit IRC14:34
dulekIt's a classic - works locally, but doesn't on the gate due to some networking weirdness.14:34
fungizbr: atlassian distributes the source code for jira (and confluence) under a proprietary license, last i looked14:34
*** Lucas_Gray has quit IRC14:35
zbrfungi: yep (if nothing changes recently). so if someone wants to integrate with any SaaS service that is not OSI, they would have to write a proxy that OSI.14:35
*** dSrinivas has joined #openstack-infra14:36
dSrinivasianw: Hi, I am unbale to create  the Node in jenkins using this code https://opendev.org/zuul/nodepool/src/tag/0.3.1/nodepool/myjenkins.py#L13214:37
dSrinivasand it is failing with http://paste.openstack.org/show/789424/14:37
fungidulek: sudo zuul autohold --tenant openstack --project openstack/kuryr-kubernetes --job kuryr-kubernetes-tempest-containerized-ipv6 --change 706529 --reason "dulek investigating timeouts in new devstack ipv6 job" --count 114:37
fungidulek: once you recheck and the job fails, any infra-root should be able to ssh in and add your ssh key14:37
dSrinivasianw: Can you please help me to find out the issue. Thank you.14:37
fungii need to disappear for a tax appointment now, but should be back in a few hours14:38
dulekfungi: Thanks!14:38
fungiys!14:38
fungier, you're welcome!14:38
openstackgerritMonty Taylor proposed opendev/system-config master: Remove review-dev01.openstack.org  https://review.opendev.org/70567114:40
openstackgerritMonty Taylor proposed opendev/system-config master: Use LE certs for Apache  https://review.opendev.org/70569014:40
openstackgerritMonty Taylor proposed opendev/system-config master: Update letsencrypt_gid documentation  https://review.opendev.org/70587814:40
openstackgerritIan Pittwood proposed openstack/project-config master: [WIP] Use GitHub Issues for airshipctl  https://review.opendev.org/70726214:41
openstackgerritIan Pittwood proposed openstack/project-config master: [WIP] Use GitHub Issues for airshipctl  https://review.opendev.org/70726214:41
*** eharney has joined #openstack-infra14:41
openstackgerritMonty Taylor proposed opendev/system-config master: Make small tweaks to launch node README  https://review.opendev.org/70567314:42
*** jamesmcarthur has joined #openstack-infra14:42
dSrinivasfungi: Hi, Can you please help with the issue which i posted previously14:43
*** jamesmcarthur has quit IRC14:47
openstackgerritIan Pittwood proposed openstack/project-config master: Disable Storyboard for airshipctl  https://review.opendev.org/70726214:52
*** ociuhandu has joined #openstack-infra14:53
*** jaosorior has quit IRC14:54
*** ociuhandu has quit IRC14:58
*** jamesmcarthur has joined #openstack-infra15:00
*** weshay is now known as weshay|ruck15:02
*** chkumar|rover is now known as raukadah15:02
*** sgw has joined #openstack-infra15:04
*** artom has joined #openstack-infra15:11
clarkbdSrinivas: it hasbeen along time since we interacted with jenkins. It is possible the jenkins api haschanged and is no longer compatible with that library15:13
clarkbhowever, I would start with double checking your authentication. Also consider zuulv3 whoch doesnt need jenkins15:14
*** priteau has joined #openstack-infra15:15
*** lbragstad has joined #openstack-infra15:15
*** sreejithp has joined #openstack-infra15:16
*** jamesmcarthur has quit IRC15:16
*** dtantsur is now known as dtantsur|brb15:18
*** jtomasek has quit IRC15:22
openstackgerritMonty Taylor proposed opendev/system-config master: Use LE certs for Apache  https://review.opendev.org/70569015:23
openstackgerritMonty Taylor proposed opendev/system-config master: Update letsencrypt_gid documentation  https://review.opendev.org/70587815:23
mordredcorvus, clarkb: our "install-kubectl" role in system-config installs via snaps - which seem to break a non-zero number of times. we installed kubectl in the zuul images by just installing oc from the tarballs - maybe we should consider that for system-config too to make it simpler?15:23
*** lpetrut has quit IRC15:24
fricklermordred: do you know why it did break, is it when downloading the snap? is there a way we could mirror those like we mirror repos?15:25
*** ociuhandu has joined #openstack-infra15:25
mordredfrickler: yeah - it's ... one sec, let me get a link15:26
mordredbut yes, I'm sure we could do - but we use snaps for almost nothing, so I really wonder if it's worth the effort to add another mirror system15:26
mordredfrickler: https://zuul.opendev.org/t/openstack/build/8f67d7f8346b4cc9bde59bf2749dc9a2/log/job-output.txt#954215:27
mordredfrickler: doesn't even seem to be a download error as much as just snap derping15:27
mordredoh - no, there it is - store server returned 40015:27
fricklerit might get used in more locations once we move to focal, I'm not sure about the effort involved, just wondering whether that would be a possible option at all15:27
mordredfrickler: nod. it's a good question - especially if it's going to be the new hotness in the future15:28
openstackgerritMerged opendev/system-config master: Make small tweaks to launch node README  https://review.opendev.org/70567315:28
fricklerjamespage or coreycb might know15:28
*** jamesmcarthur has joined #openstack-infra15:31
*** rpittau is now known as rpittau|afk15:31
fricklerthis one doesn't make me too optimistic, though https://forum.snapcraft.io/t/local-mirror-for-snaps/1903 . we might consider installing a specific version locally, but possibly still see the upgrade issue15:31
jrosseris there a short answer to where we are regarding infra images and yesterdays virtualenv 20 problems15:31
clarkbjrosser: I'm not fully caught up yet butimage rebuilds yesterday as well as mordreds base job workaround shouldve fixed most infra side issues15:32
clarkbthe 20.0.2 release should also just fix it in general going forward so we can revert fixes carefully now15:33
*** ysastri has quit IRC15:33
jrosseri was trying to decide if it was worth diving in to fix * OSA jobs being broken, or just to hold off for other stuff to land first15:33
fricklerjrosser: do you still see broken jobs currently? or are those broken in different ways?15:35
clarkbthe 20.0.2 release doesnt fix issues woth sox version conflicts or --version output format changes though15:36
clarkb*with six"15:36
*** ian-pittwood has quit IRC15:37
jrosserfrickler: heres a patch where the virtualenv stuff broke after PS1 https://review.opendev.org/#/c/706874/15:38
jrosserand it's pretty much a bonfire after that15:38
jrosserand a lot of breakage like this https://zuul.opendev.org/t/openstack/build/73b4a388ffb4454a9354f51bc2cbae73/log/job-output.txt#1554515:39
jamespagefrickler: what's the question? snap mirrors?15:39
*** cshen has quit IRC15:39
fricklerjamespage: yes, is there a way to do that by now?15:40
jamespagefrickler: there is something - lemme find out15:41
fricklerjrosser: oh, that last one looks like it may be similar to our puppet-venv issue. afaik the version output has changed, leading to errors parsing it15:41
jamespagenot my area of expertise tbh15:41
clarkbjrosser: if that comes from parsing of `vitualenv --version` you'll need to fix that on your end15:41
openstackgerritMonty Taylor proposed opendev/system-config master: Install kubectl via openshift client tools  https://review.opendev.org/70741215:41
clarkbfrickler: yes, exactly re venv version15:42
mordredfrickler, clarkb: ^^ that's just sake of argument - although I'm also interested in learning about snap mirrors15:42
jrosserclarkb: yes seems i need to look at this https://opendev.org/openstack/ansible-role-python_venv_build/src/branch/master/tasks/python_venv_preflight.yml#L24-L4115:43
*** armax has joined #openstack-infra15:45
mordredfrickler, jamespage: it seems like mirrors are not supported. there is an "enterprise snap store proxy" - but it is "free for up to five devices" which makes it sound like something not for us15:46
fungi"enterprise" anything makes me shudder15:47
fricklermordred: is downloading from github actually more stable, though?15:47
* fungi is back from his annual tax beating15:47
fungiclarkb: turns out the image fixes yesterday never happened (and are reverted as of an hour or so ago)15:48
fungithe version of virtualenv we're installing, even in ubuntu-bionic chroots, is too old to support --seeder15:48
mordredfrickler: it's what we're doing for this in the zuul images - but if we wanted we could probably pre-download/cache a thing if we need to15:48
fungiclarkb: so image builds all failed on an unrecognized option15:49
mordredfrickler: but I honestly don't know - this is me thinking out loud :)15:49
*** ykarel is now known as ykarel|afk15:49
mordredfungi: why are we getting such an old virtualenv?15:49
mordred(also, at this point virtualenv 20.0.2 should also be solid)15:50
fungimordred: that's a good question, and one i did not have time to look into yet15:50
fungihttps://nb01.openstack.org/ubuntu-bionic-0000098357.log15:50
fungiwhich has now rotated out i guess15:51
fungithat's a 40415:51
mordredit's because we're using pip-and-virtualenv which installs from packages15:51
mordredwow - I *so* thought we'd switched to installing via get-pip15:51
mordredoh15:52
mordredwe do get-pip on not-ubuntu15:52
fungihttps://nb01.openstack.org/ubuntu-bionic-0000098359.log shows "venv: error: unrecognized arguments: --seeder=pip" though it's from 14:28z so started before the revert landed15:52
mordredhow about we change that element to do the get-pip logic _everywhere_15:52
fungii want to say we landed changes not long ago to switch to system-packaged pip on ubuntu because it was "new enough"15:53
mordredthat's a bit crazy that we have ubuntu packages vs get-pip15:53
mordredugh15:53
fungimaybe check git history around there15:53
mordredI will15:53
mordredI really think it's an ongoing source of strife to attempt to use distro pip and virtualenv ... but ignoring that, doing it differently on ubuntu vs non-ubuntu makes reasoning about issues like yesterday much harder15:54
mordredso I'm going to suggest we back that out for whatever reason we did it so that we can have consistency across our images15:54
fungipart of the friction also seems to be that software factory want to directly reuse our custom dib elements from project-config but at the same time install everything from distro packages (they're the ones which brought the image build failures to our attention earlier today)15:55
fricklerif I read the log correctly, we install virtualenv==20.0.2 into py2, but the call to "python3 -m venv" is what fails later, maybe we need to run "pip install -U --force-reinstall virtualenv" also with pip3?15:56
clarkbfungi: how did jobs break on that then?15:56
*** pgaxatte has quit IRC15:56
fungijobs did not break on that15:57
mordredclarkb: jobs only broke on centos15:57
clarkbI see so one subset of image was getting new virtualenv15:57
fungisoftware factory's nodepool image builds started failing because they use our project-config infra-needs dib elements15:57
mordredfungi: nod. well - fwiw, pip-and-virtualenv element is in dib directly, not in project-config15:57
* frickler will be back later15:58
clarkbdid centos rebuild at least?15:58
fungiyeah, but what we patched was our bindep and similar virtualenv builds in infra-needs15:58
clarkbwe can revert worlarounds in base if so15:58
mordredbut - at this point I kind of think we should make an opendev version of it - and it should be opinionated for opendev15:58
fungiclarkb: centos-8 images were failing on the same error. virtualenv too old to support --seeder15:59
fungii haven't looked to see if centos-7 updated15:59
mordredfungi: we do not override the pip and virtualenv installation in infra-needs15:59
fungimordred: we call virtualenv in infra-needs15:59
fungiand we changed how we call it to add --seeder=pip15:59
mordredwe also install from pacakges on centos815:59
clarkbfungi: it was 7 that had broken jobs15:59
mordredfungi: yes. sorry - I'm talking about a differen thing - I agree with you on that16:00
fungiand software factory uses our infra-needs element in their nodepool config16:00
mordredwhat I'm saying is that we install virtualenv from distro packages for centos8 and ubuntu but not for centos716:00
fungiahh, yep16:00
mordredand I'm suggesting that we stop trying to install virtualenv and pip from distro packages anywhere16:00
mordredand just use get-pip everywhere since we have to use it on some of our images16:01
mordredso that we'll be consistent everywhere16:01
mordredbecause yesterday NONE of us knew we had a packages vs get-pip split in how this is installed16:01
fungii don't contest that. but i think dib used to install virtualenv and pip from pypi everywhere and recently changed to use system packages on platforms which were deemed "new enough" so we should make sure we understand why they did that before proposing a revert of it16:01
mordredagree16:01
*** udesale has quit IRC16:02
clarkbalso sf shouldnt use our infra elements16:02
clarkbor at least we dont make that an api16:02
fungiclarkb: yeah, i mentioned that a few times16:02
*** udesale has joined #openstack-infra16:02
*** tesseract has joined #openstack-infra16:02
fungiwhether or not we think using that is a good idea, the bug they ran into was one we were also breaking on and just hadn't spotted yet16:02
mordredfungi: the package-installs file in pip-and-virtualenv element hasn't changed in this regard since 201616:03
*** jamesmcarthur_ has joined #openstack-infra16:03
fungihuh, interesting16:03
mordredit's possible what you're saying is right - but is just happened a LONG time ago16:03
fungiso maybe we've been installing it from packages since xenial16:03
mordredor maybe we swtiched to using upsream pip-and-virtualenv16:03
mordredand had a fork previously?16:03
fungialso possible16:03
mordredok. so ...16:05
clarkbfungi: right and in this specific case we had planned to revert anyway once 20.0.2 happened. The problem is if we "fix" this by being consistent we'll break them again because tehy want distro packages16:06
*** jamesmcarthur has quit IRC16:06
fungiwe could also consider transitioning to not preinstalling virtualenv (or maybe even pip for that matter) in images and instead do it at job runtime, but that's a deeper change likely to break a bunch of existing assumptions16:06
jrosserfrom my pov it has been a big surprise to find that in CI jobs i am not testing what end users will encounter on an actual deployment of say, bionic16:06
mordredI retract my earlier statement16:06
mordredjrosser: you mean that we instal from pip vs from packages?16:06
jrosserabsolutely16:06
jrosserfor things like devstack i can see that can be argued as a non issue16:07
clarkbfungi: the reason it is preinstalled is to avoid building out bindep venv in particular at runtime. I don't know what the cost is of that but it is possible its small enoguh that a runtime hit is fine16:07
jrosserbut for deployment projects its a fairly scary thing16:07
clarkbI don't think the os-testr venv is used anymore but that is the other one we have16:07
mordredjrosser: the deployment projects that use packages use packages in the gate16:07
mordredto my knowledge16:07
fungiclarkb: in those cases we could consider either installing virtualenv to an alternative path and calling it directly there, or just uninstalling it when we're done using it within the chroot16:08
jrosserbut for OSA, which deploys from source, into venvs, our world is not package centric16:08
mordredyeah. that's right16:08
jrosserand normalising and dealing with the actual differences between distros is the value add that we bring16:08
mordredosa isn't package based, so it _is_ testing what people are going ot be deploying in the real world16:08
fungipython3 -m venv /tmp/bootstrap && /tmp/bootstrap/bin/pip install virtualenv && /tmp/bootstrap/bin/virtualenv /usr/venv/bindep && /usr/venv/bindep/bin/pip install bindep16:09
fungior whatever16:09
clarkbfungi: right but then you have to install python-venv16:09
clarkbwhich potentially brings its own conflicts16:09
fungialternatively `/tmp/bootstrap/bin/virtualenv -p python2.7 /usr/venv/bindep`16:09
fungiyeah, python-venv could also be uninstalled, possibly more cleanly16:10
fungior python3-venv really16:10
mordredbtw - I said wrong thingns earlier - we do pip install virtualenv everywhere16:10
mordredwe just install the distro packages FIRST - then we pip install over top of it16:10
clarkband don't force -U?16:10
mordredwe -U16:10
fungithat makes an even bigger mess since pip is going to invalidate a bunch of assumptions from the underlying package manager as well16:10
mordredso I don't know why we didn't have 20.0.216:11
clarkbfungi: except that doesn't seem to have happened because we didn't update virtualenv16:11
fungimordred: are we installing virtualenv under python2 and then invoking the system-packaged version for python3?16:11
clarkb(otherwise --seeder=pip would've worked fine)16:11
mordredbut yeah - the comments say we do this so that if someone does "$PKG_MGR install python-virtualenv later it doesn't step on the pip instal"16:11
mordredfungi: we are doing distro versions for both - the pip installing both over top16:11
mordredthis is one of the most complex things I've seen in a while16:12
fungiexcept that apparently folks want to step on the pip install and use distro-packaged versions in some cases16:12
mordredpeople explicity want to use distro-packaged virtualenv?16:12
fungithat's what they're saying16:12
mordredwow16:12
mordredI can't even16:12
fungijrosser above makes the point that his users in production are going to install python3-virtualenv from ubuntu's packages on their servers16:13
mordredoh - THAT was the distro comment - got it16:13
fungiand so testing against newer virtualenv invalidates the project's assumptions16:13
mordredI mean16:13
mordredI think those users shouldn't do that16:13
jrosserwe take whatever the distro has, as there is no choice about that16:13
mordredbut I get it :)16:13
clarkbjrosser: well there is a choice :)16:13
jrosserthat is a starting point to build something sensible16:13
jrosserbut we never *ever* attempt to mess with the system python with pip16:14
jrossertoo many bad times trying to do that16:14
fungiubuntu ostensibly provides security patches for their python3-virtualenv package and has features built in to apply those updates automatically without sysadmin intervention. i expect some people see that as an indispensable feature16:14
mordredI take the other route and never EVER install python packages from distro packages - but I can respect your approach16:14
clarkbfungi: yup, but also break stdlib venv :/ tehre are definitely trade offs there and which work best for your use case will differ depending on use case likely16:15
mordredshrug. we're not going to agree on this point ... but I can see and understand what the use case is16:15
mordredI honestly do not know how we can possibly support all of our current use cases16:15
fungii take a middle of the road approach and always install packages from pypi into virtual environments and always call them directly from there so that system packages and pypi packages can coexist in entirely separate contexts16:15
mordredexcept by ceasing to pre-install pip and virtualenv at all16:15
fungi(and i use system packages to bootstrap the venvs)16:15
clarkbmordred: we can't we have to either support none of them or choose the one that aligns with our needs and ask others to manage16:16
jrosser^ this is the OSA approach too16:16
mordredclarkb: right. I think I'm on none of them16:16
clarkbfungi: jrosser I use system package to bootstrap a utility venv and then I install virtualenv in that16:16
fungiyep, same here16:16
mordredbecause the thing we're doing now is super complicated and at the same time is undermining people's testing16:16
jrosserwell anyway it's been bothering me a lot realising that bionic != bionic16:17
jrosseri don't know what the answer is though16:17
fungii basically add a .../lib/virtualenv/bin/virtualenv explicitly to my path and keep it out of the way of the distro's version that way16:17
clarkbfungi: yup same here16:17
clarkbI symlink in #HOME/bin which is in path16:17
mordredjrosser: I think we need to make a plan to stop pre-installing - make a zuul role that does the install in a pre playbook for things like tox that need it16:18
mordredand figure out a plan for our system virtualenvs16:18
clarkbmordred: well we'd still preinstall but then probably uninstall16:18
clarkb(or we'd have to bootstrap bindep from scratch on every job)16:18
mordredyeah - that's fine16:18
mordredI thnik y'all were suggesting using distro virtualenv to get the bindep virtualenv16:19
mordredthen distro removing it16:19
mordredyeah?16:19
clarkbthat is probably the simplest way to remove things since apt/yum/etc will be good at it16:19
mordredthat seems workable16:19
mordredclarkb: same with glean, yeah?16:19
mordredhave we figured if anything uses that os-testr venv?16:20
clarkbmordred: I think glean is directly installed16:20
clarkbmordred: I can look into the os-testr venv16:20
clarkb(still unsure on that one)16:20
fungiit would be good to keep in mind that there are two basic classes of virtualenv users for us. those who need virtualenv as part of the test framework, and those whose software uses virtualenv for some function. the former are much less likely to care where virtualenv is coming from16:20
clarkbfungi: fwiw its ^ these changes that are likely to break sf16:20
mordredfungi: yes. I completely agree16:21
mordredfungi: I believe by and large we've focused on the former16:21
fungibut the latter use case can this way be addressed by adding virtualenv to bindep.txt or requirements.txt16:21
mordredbut I can see how the results of that would be disturbing to the latter16:21
fungiand having jobs pull in the version they're expecting16:21
mordredfungi: I mean - not if we've overwritten virtualenv with pip already - we do some xargs rm stuff in pip-and-virtualenv :)16:22
mordredwe seem to do a LOT of work to prevent people from distro installing virtualenv later and getting distro virtualenv16:22
fungioh, right, i'm thinking if the pip-and-virtualenv element went away entirely16:22
mordredoh -yeah - TOTALLY16:22
mordred++16:22
fungiwe could find a way to build the extra virtualenvs we need in our image chroots but still clean up after ourselves so there is no preinstalled pip or virtualenv on those images unless the platform itself would normally provide them16:23
clarkba surprising amount of stuff uses os-testr-env. http://codesearch.openstack.org/?q=os-testr-env&i=nope&files=&repos= seems like mordred may have tried to start cleaning this up already though: https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/fetch-subunit-output/files/find-subunit2html.sh#L39-L4316:24
clarkbI think for a first pass on this we'll want to keep that venv16:24
fungiso that folks whose software relies on virtualenv can declare python3-virtualenv in their bindep.txt, perhaps (as long as they're calling our preinstalled /usr/venv/bindep/bin/bindep or whatever) and that provides accurate testing of what they also tell their users to install on that platform16:24
*** zxiiro has joined #openstack-infra16:24
clarkbwe also preinstall tox16:24
clarkbwhich will pull in virtualenv iirc16:25
clarkbmy hunch is that this is significantly large that we probably don't awnt to just start tackling it16:25
clarkband instead fix the images we've got so that bindep works including on centos-716:25
fungiright, i think we *can* safely preinstall pip, virtualenv, tox, et cetera to places outside the execution path and the python library import path for bootstrapping purposes16:25
clarkbthen have a longer term plan to cleaning this up16:25
clarkbfungi: but then how do jobs find them?16:26
mordredfungi: so install tox into a virtualenv and make a /usr/local/bin/tox symlink?16:26
mordredtox is the big one here16:26
clarkbmordred: if we make the symlink then we still potentially break assumptions about "I'm not using pip stuff"16:26
fungiif people want to use those preinstalled copies they can symlink into their path or call them directly. otherwise they can install a system-wide copy however they'd install other software in their jobs16:26
mordredthe other options is just to stop preinstalling bindep or tox and let the zuul pre playbooks handle it16:26
fungii said up front, this is likely to be disruptive and break a lot of existing assumptions in jobs16:27
clarkbfungi: not only that but the way ansible deals with PATH makes that really painful16:27
clarkbas mnaser recently discovered16:27
mordredyup16:27
clarkbbecause command doesn't evaluate rc or profile stuff16:27
mnaserhi what did I discover16:27
mnaserah yes16:27
fungiright, adjusting the path envvar isn't likely a good way to go about it, which is why i suggested jobs could symlink into their path or call them directly16:28
mordredmnaser: we're just revelling in the hell that is pip vs. distro packaging16:28
fungifor example, we already don't put our preinstalled bindep into the system default execution path16:28
clarkba good first step is likely to make the venvs we do have independent of a longer lived virtualenv install. Then if tox reinstalls virtualenv we can clean that up next16:28
cmurphyi'm seeing "ERROR:root:ImportError: cannot import name ensure_text" virtualenv problems on rocky branches, is that what you guys are working on or is this something else?16:29
mordredclarkb: yeah16:29
mordredcmurphy: yup. that's part of the hell16:29
fungicmurphy: that one is too-old six with to-new virtualenv16:29
clarkbcmurphy: that is related to six versioning. is this a devstack job? if so frickler has fixes up16:29
cmurphyyay16:29
clarkbcmurphy: https://review.opendev.org/#/c/707109/ rocky devstack fix16:29
cmurphyclarkb: yes devstack https://zuul.opendev.org/t/openstack/build/4cb21274651344d68f3cf81a600008f7/log/job-output.txt16:29
clarkbcmurphy: I think if you recheck it will be good now since that chagne above is merged16:30
cmurphygreat so i can rechekc16:30
cmurphykk16:30
cmurphyty16:30
jrosserfungi: you made a good observation that there were two classes of virtualenv users earlier16:32
jrosserwould one answer be to create a more distro centric version of the images whilst leaving the exsiting one just as is16:32
clarkbwe've done split images in the past and it is pain. Also distro centric images can't boot on all clouds16:33
jrosserright, i'm sure this is all a road already trodden :)16:33
clarkbI have very little interest in doubling the number of images we have to maintain and debugging why two different sets of init systems fail to init on other clouds16:33
mordredclarkb, fungi: I have an alternate suggestion16:34
mordredwe keep our current system of pre-installing pip, virtualenv and tox via pip for our users who are just using those as a happenstance (which is the larger audience) ... BUT ...16:35
*** raukadah has left #openstack-infra16:35
mordredwe simplify it and remove all of the "also install distro packages and then overwrite things to amke it hard for people to install from distro packages later" stuff ... AND ...16:35
*** sgw has quit IRC16:36
fungimordred: that seems like a good first step regardless, sure16:36
mordredwe make a cleanup screipt, since it's now easy to cleanup - that would delete the relevant pip/virtualenv/tox installs from where pip installed them - that folks like OSA can run in a pre playbook in zuul - that would result ina . clean system into which they can apt-get install python-virtualenv and they will get what they are expecting16:36
mordredthat way we don't have to try to figure out every assumption people have out there based on our current pattern of pre-providing - but we provide jrosser and crew a *solid* way to get back to a clean system16:37
clarkbjrosser: as a side note, I don't think we are providing the virtualenv>=20.0.0 that is breaking your jobs because our image builds failed when trying to use --seeder=pip16:37
clarkbjrosser: so the cleanup mordred describes may not actually fix this for your jobs16:38
clarkb(and you may want to take a look at the jobs to see where that newer virtualenv comes from if you don't intend to have it)16:38
mordredif people are ok with considering the concept - I can make some WIP patches for us to discuss16:38
zbrmordred: clarkb: https://review.opendev.org/#/c/706371/ please.16:38
*** priteau has quit IRC16:38
jrosserclarkb: ok i will double check that, i think we did test the same (as far as you can outside zuul) thing in a standard cloud-image16:39
*** priteau has joined #openstack-infra16:39
clarkbI've confirmed that the centos-7 image did build and has uploaded16:42
clarkbI think we can revert mordred's workaround16:42
*** Sundar has joined #openstack-infra16:43
Sundargmann: Hello, please ping me when you have a moment.16:43
gmannSundar: hi16:44
mordredclarkb: \o/16:44
openstackgerritClark Boylan proposed zuul/zuul master: Simplify virtualenv install and execution  https://review.opendev.org/70742816:45
Sundargmann: Thanks for pinging back. We had an issue where the py37 and py38 Zuul jobs for Cyborg would time out. Normally, they take only a few min, so it dodn;t seem like increasing the time would help. After some investigating, we found that this patch https://review.opendev.org/#/c/706911/ fixes the problem. It essentially reverts an earlier patch16:46
Sundarthat set ignore base python conflict flag.16:46
Sundargmann: What is not clear is, why this 'ignore base python conflict' flag should cause timeouts. Hope you can throw some light on it.16:47
*** lucasagomes has quit IRC16:47
fungiSundar: do you have a log from one of the timed-out builds?16:49
*** ramishra has quit IRC16:49
gmannSundar: 'ignore base python conflict'  should not cause timeout. it is flag to avoid the version conflict in case of basepython on common place. for example if you keep basepython-py3 in testenv then, running the tox env with default py version env can conflict.16:49
SundarYes, there is nothing in the logs indictaing which tests timed out. The tests mentioned in the logs all passed.16:49
gmannit is warning by tox as of now and than if this flag is not used it might be error when they turn warning to errorr16:49
fungiit's likely that ignore base python conflict resulted in you running the requested version of python, and that your tests actually time out on that version of python16:50
clarkbSundar: https://tox.readthedocs.io/en/latest/config.html#conf-ignore_basepython_conflict16:50
clarkbSundar: you have basepython set to python316:50
Sundarfungi: Example patch https://review.opendev.org/#/c/698846/10 . Example log: https://cd11bacc403da694b347-14879265802d142fe2b972960013518d.ssl.cf2.rackcdn.com/698846/4/check/openstack-tox-py37/1dcf585/16:51
clarkbSundar: that means when you run py37 but python3 is actually python3.6 it will ignore that error and run under python3 anyway16:51
*** udesale has quit IRC16:51
clarkbI think you've fixed this by not running against the expected version of python16:51
clarkb(and the expected version cause sthe timeouts somehow)16:51
*** priteau has quit IRC16:51
*** udesale has joined #openstack-infra16:52
*** gyee has joined #openstack-infra16:52
Sundarclarkb, gmann: I also would not have suspected this change. But, since reverting it, we haven't had any timeouts. Adding it as a base patch before another failing patch would make the latter pass.16:52
gmannSundar: that patch passing jobs . any failed one16:52
fungigmann: here's the zuul build page for the failed build log Sundar linked: https://zuul.opendev.org/t/openstack/build/1dcf58536e1f4c89aec287651c5321d8/16:53
Sundargmann: Older version of the same patch failed repeatedly, until we rebased it over this reverting patch.16:53
*** sgw has joined #openstack-infra16:53
fungithe log in that example goes silent between 2020-01-18 16:40:31.438574 and 2020-01-18 17:17:28.89559816:54
clarkbhttps://zuul.opendev.org/t/openstack/build/98532e50f3bc4f79b4e5574d1f177b48/log/job-output.txt#803 shows that the passing job is using python3.6 as I suspected16:55
clarkbthe failing jobs are using the expected python3 that is newer and timeout16:55
clarkbit is passing because it isn't testing what you intend to test16:55
fungiyep, what i also said. basically you have a timeout when testing under python 3.7 and so unsetting that tox option is masking the failure by testing with python3.7 in your 3.7 job16:55
fungier, by testing with python 3.6 in your 3.7 job16:56
Sundarclarkb, fungi: I see. How would we start debugging the issue with Py 3.7? We don;t know which tests are failing. We have tried doin 'stestr --serial' in tox.ini, but that didn't help.16:57
fungii suspect you have a unit test in a livelock of some sort under 3.7 but since the job times out before testr can report, it's hard to say16:57
clarkbSundar: did it still timeout when run serially?16:57
Sundarclarkb: Yes16:58
AJaeger_config-core, a couple of less exciting changes to review: https://review.opendev.org/706271 https://review.opendev.org/707086 https://review.opendev.org/70721016:58
*** iurygregory has quit IRC16:58
fungidid you try it on a system which actually has python3.7 installed?16:58
fungiSundar: ^16:58
clarkbSundar: ok, then you should be able to see which test is running when it stops. Then work backward from that test16:58
clarkbSundar: step 0 is identify where it hangs. Then next is run that test alone with no other tests. See if it hangs or not. If it does great that is probably easier to debug16:59
clarkband basically work backward from there16:59
fungiunless the job timeout was too short for serialized testing and so got cut short before it reached the spinning test16:59
SundarI am having trouble installing Py3.7 in my CentOS VMs. Somebody is bringing up an Ubuntu VM with only Py3.7. SO, I haven't tested it locally.16:59
gmannlogs seem py3.7 was used this and test running on - https://zuul.opendev.org/t/openstack/build/1dcf58536e1f4c89aec287651c5321d8/log/job-output.txt#45916:59
AJaeger_config-core, and some more reviews for zuul-jobs: https://review.opendev.org/706404 https://review.opendev.org/681882 https://review.opendev.org/681603 https://review.opendev.org/70441416:59
clarkbgmann: you can't use the venv name16:59
clarkbgmann: the venv name will always show the tox target name16:59
clarkbyou need to look at the python that was installed in that venv16:59
fungitox names the venv based on whatever you called it16:59
AJaeger_config-core, and final review request: https://review.opendev.org/706733 and https://review.opendev.org/706319 https://review.opendev.org/706070 - please help reviewing17:00
gmannnot name the version installed in lib/17:00
clarkbgmann: https://zuul.opendev.org/t/openstack/build/1dcf58536e1f4c89aec287651c5321d8/log/job-output.txt#859 shows it was python3.7 and that job timed out17:00
fungiclarkb: gmann: but yes, that's the failure example17:00
fungilook at the "passing" version from the patch which turns off conflict ignoring17:01
fungiit winds up using python3.6 in a virtualenv named py3717:01
*** lmiccini has quit IRC17:01
openstackgerritMerged zuul/zuul-jobs master: Add an ensure-tox test job  https://review.opendev.org/70637117:02
gmannSundar: let me try py3.7 env locally and run serially. I will be able to do after finishing heat-tempest-plugin issue17:02
clarkbSundar: gmann another option is to run each test independently17:03
clarkb(that might be really slow depending on the number of tests but is doable and would help pinpoint if a specific test or group of tests are to blame)17:03
fungior bisect them17:03
Sundarclarkb: "you should be able to see which test is running when it stops" -- this is with '--serial' right?17:03
openstackgerritIan Pittwood proposed openstack/project-config master: Disable Storyboard for airshipctl  https://review.opendev.org/70726217:03
fungiSundar: yes17:03
clarkbSundar: no I mean in entirely separate test runs17:03
clarkbtox -epy37 --test1 ; tox -epy37 -- test2; and so on17:03
clarkbI would start with serially first and see if you can identify the cause that way. It will be fast17:04
fungithough if you run serially with a long timeout and it eventually hangs on one test, that's likely the culprit17:04
clarkb*faster17:04
gmannclarkb: ok. but both case stestr should log failed test at least17:04
clarkbgmann: not necessarily if the test is hanging17:04
fungiyeah, if control never returns to the caller then you never get a report17:04
clarkbyou might not get anything logged (and so have to use subtraction of what was logged against a complete list to narrow the filed) or simply that a test started and has never finished17:05
Sundarclarkb, fungi, gmann: Got it. We will try both (a) using a local env with py37 and running individual tests, and (b) running with -serial and seeing what was the last failing test.17:06
SundarThanks a lot to all of you!17:06
fungiSundar: you're welcome, let us know if you run into any other questions and we're happy to help17:07
clarkbSundar: remember to run your testing on code that doesn't have the "fix"17:07
*** udesale has quit IRC17:08
clarkbthe good news is it hangs when run serially17:09
SundarSure, will do17:09
clarkbso probably isn't an inter test process conflict (those are a pain to debug)17:09
openstackgerritThierry Carrez proposed openstack/project-config master: check-release-approval: log Gerrit data on error  https://review.opendev.org/70743217:11
*** igordc has joined #openstack-infra17:17
clarkbAJaeger_: I've pulled up those changes. Will review over breakfast. THanks17:18
*** tesseract has quit IRC17:32
*** ociuhandu_ has joined #openstack-infra17:32
openstackgerritTristan Cacqueray proposed zuul/zuul master: Gitlab - bootstrap the driver structure + Webhook support  https://review.opendev.org/68568217:33
*** evrardjp has quit IRC17:34
*** evrardjp has joined #openstack-infra17:34
*** ociuhandu has quit IRC17:36
*** ociuhandu_ has quit IRC17:37
*** iurygregory has joined #openstack-infra17:40
openstackgerritJames E. Blair proposed zuul/gcp-authdaemon master: Initial commit  https://review.opendev.org/70743817:41
*** xek__ has joined #openstack-infra17:42
*** dkehn has quit IRC17:42
jrosserclarkb: this is a trivial debug for where virtualenv is coming from in an OSA job http://paste.openstack.org/show/789480/17:43
jrosserand also likley explains the later failure when parsing the version due to the extra stuff after the version number17:44
*** xek_ has quit IRC17:44
clarkbjrosser: right but what installs taht since apparently our image builds install 3.6.something17:45
clarkb(on bionic)17:45
clarkbI'm guessing some pre-run playbook maybe?17:45
jrosseri have no idea :/17:45
openstackgerritThierry Carrez proposed openstack/project-config master: check-release-approval: log Gerrit data on error  https://review.opendev.org/70743217:46
openstackgerritClark Boylan proposed zuul/zuul master: Simplify virtualenv install and execution  https://review.opendev.org/70742817:47
*** jamesmcarthur_ has quit IRC17:47
clarkbI guess what I'm trying to get at is we could do all this work to "fix" the images but then the job side will still do what is unexpected so we need to understand that side too17:48
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: WIP: Make ensure-tox pass cross-platform  https://review.opendev.org/70743917:48
fungimordred: see review comment on https://review.opendev.org/705690 you've got something going wrong in the vhost config, looks like17:49
noonedeadpunkactually on pure bionic images no issues arise for OSA and correct virtualenv get's installed (which is provided by system packages)17:50
clarkbnoonedeadpunk: we don't have those in the gate though and you aren't running all the zuul prerun playbooks I expect17:51
jrosserwe are, but not that do any modifications to installations of things on the host17:52
clarkbnoonedeadpunk: jrosser https://zuul.opendev.org/t/openstack/build/73b4a388ffb4454a9354f51bc2cbae73/log/job-output.txt#13842 at that point the version is still old I think beacuse your fact worked17:52
jrosserno thats different17:53
jrosserthats running in an lxc machine container, so is "proper bionic" environment17:53
clarkbI see so different fs context17:53
jrosserthe one that fails is running against "aio1" which is the host17:53
clarkbjrosser: I understand that your jobs may not change virtualenv17:53
clarkbbut you inherit from other jobs that may17:53
openstackgerritGhanshyam Mann proposed openstack/devstack-gate master: Cap virtualenv to a version < 20  https://review.opendev.org/70744117:53
clarkbsomething is clearly switchign form distro install to latest from pip between when we build virtualenvs in the image and when your job fails17:54
clarkbI am saying we need to understand that. Can we stop arguing that this is happenign because it is clearly happening17:54
clarkbI don't understand why it is happening just that we need to understand it17:54
clarkbotherwise changing the image may not have the effect you want17:55
openstackgerritMerged zuul/zuul-jobs master: Add tox env for update-test-platforms  https://review.opendev.org/70640417:55
noonedeadpunkYeah. I just kinda checked zuul pre gate jobs and didn't find anything related... But, according to https://6c99932face18597ac21-e78425eb2af28756e9f2701e93cfe670.ssl.cf1.rackcdn.com/707212/2/check/openstack-ansible-deploy-aio_metal-ubuntu-bionic/abaa5d2/logs/ara-report/result/79ca9049-ba7f-4b75-b4a5-e08be03ffcd8/ it's preinstalled before our gre-gate script17:58
clarkbjrosser: noonedeadpunk is this virtualenv https://zuul.opendev.org/t/openstack/build/73b4a388ffb4454a9354f51bc2cbae73/log/job-output.txt#3519 the one with the new version?17:58
openstackgerritMonty Taylor proposed openstack/project-config master: WIP Install pip and virtualenv only from get-pip  https://review.opendev.org/70744217:59
clarkbI'm not sure where https://zuul.opendev.org/t/openstack/build/73b4a388ffb4454a9354f51bc2cbae73/log/job-output.txt#15544 is being evaluated17:59
jrosserit's here https://opendev.org/openstack/ansible-role-python_venv_build/src/branch/master/tasks/python_venv_preflight.yml#L4118:00
noonedeadpunkor wait...18:00
jrosserand i think that the ansible version test chokes on the extra stuff on --version18:01
*** derekh has quit IRC18:01
clarkbjrosser: noonedeadpunk right that seems to run against aio1 and I'm not sure what that is18:02
mordredclarkb: ^^ there's a sake-of-argument WIP patch doing the thing I think we want18:02
clarkbwhere virtualenv seems to be happy early in the job is against "ubuntu-bionic"18:02
clarkb"ubuntu-bionic" is what I expect to be our test VM18:02
clarkbbut I don't know what aio1 is18:02
openstackgerritGhanshyam Mann proposed openstack/devstack-gate master: Cap virtualenv to a version < 20  https://review.opendev.org/70744118:03
noonedeadpunkOk, just to short the list of search - at this point virtualenv is already 20.0.1 https://zuul.opendev.org/t/openstack/build/abaa5d23dfb44caeb0220d8f82550624/log/job-output.txt#497218:03
clarkbis aio1 an alias for ubuntu-bionic in the ansible inventory?18:03
jrosserit is here https://github.com/openstack/openstack-ansible/blob/master/tests/roles/bootstrap-host/tasks/prepare_hostname.yml#L3618:04
jrosserand then used in the inventory of the embedded ansible18:05
clarkbok so it is effectively an alias (localhost has been renamed to aio1)18:05
clarkbmordred: fungi: is it possible the image build is using old virtualenv to install bindep env and friends, but then upgrading virtualenv after the fact?18:06
clarkbthat could explain the confusion around "we thought it was always updating"18:06
*** igordc has quit IRC18:08
clarkbjrosser: noonedeadpunk out of curiousity, it seems like the osa job installs virtualenv in a virtualenv18:08
clarkbis that mostly just to be ignored?18:08
mordredclarkb: yes.18:09
noonedeadpunkhum? can you kindly point to that?18:09
mordredclarkb: both because that's likely, and because what's going on has grown so baroque that literally anything is possible at this point18:09
clarkbnoonedeadpunk: https://zuul.opendev.org/t/openstack/build/73b4a388ffb4454a9354f51bc2cbae73/log/job-output.txt#3754 installs virtualenv at https://zuul.opendev.org/t/openstack/build/73b4a388ffb4454a9354f51bc2cbae73/log/job-output.txt#400518:10
*** jpena is now known as jpena|off18:11
clarkbits weird to me that you'd be relying on system virtualenv if you explictly pull it in (opensatck-ansible has it as a dep)18:11
clarkbbut that doesn't explain why the system level virtualenv is unexpectedly new18:11
clarkbI'm going to look at image build logs now18:12
mordredclarkb: my biggest hunch would be that somthing installs tox somewhere18:12
openstackgerritMerged opendev/system-config master: Get LE certs for review.o.o  https://review.opendev.org/70567018:12
openstackgerritMerged opendev/system-config master: Remove review-dev01.openstack.org  https://review.opendev.org/70567118:12
mordredclarkb: yeah - infra-packge-needs pip installs tox18:13
cmurphynew issue? ":stderr: ERROR: Package 'stackviz' requires a different Python: 3.5.2 not in '>=3.6'"  https://zuul.opendev.org/t/openstack/build/ba16721308514130819d1fdd7c2cb82118:13
mordredclarkb: which is highly likely to pull in virtualenv - especially if virtualenv is only installed via system packages at that point18:13
mordredclarkb: (obviously verifying that from build logs is a good idea)18:14
clarkbmordred: ya the image logs show it installing 2018:14
clarkbmordred: now I'm trying to sorto ut why bindep-env didn't work given ^18:14
clarkb2020-02-12 17:18:46.606 | Successfully installed appdirs-1.4.3 configparser-4.0.2 contextlib2-0.6.0.post1 distlib-0.3.0 filelock-3.0.12 importlib-metadata-1.5.0 importlib-resources-1.0.2 pathlib2-2.3.5 scandir-1.10.0 six-1.14.0 typing-3.7.4.1 virtualenv-20.0.3 zipp-1.1.018:14
mordredyeah - that's weid - tox is installed before bindep18:14
clarkb2020-02-12 17:18:55.507 | + /usr/bin/python3 -m venv /usr/bindep-env18:15
mordredso bindep-env should be new18:15
clarkbthat solves the mystery18:15
mordredyup18:15
clarkbugh18:15
clarkbits because we don't use virtualenv to make those venvs on all hosts18:15
clarkbmordred: I think that maybe changes the calculus of the above stuff slightly18:15
mordredyeah18:15
*** Sundar has quit IRC18:15
clarkbcmurphy: I think that is different, and probably related to ypthon3 chagnes not virtualenv18:16
mordredlike - I think we should focus on removing divergence as a step 018:16
mordredbecause it is *impossible* to keep all this in ones head18:16
clarkbcmurphy: I think stackviz might require older python3 and so pip refuses to install it18:16
clarkbmordred: yes I think we should make things consistent as much as possible, then we can sort out how to make them different18:16
openstackgerritJeremy Stanley proposed zuul/zuul master: Flesh out the glossary significantly  https://review.opendev.org/70439118:16
clarkbfungi: ^ not sure if you caught that but the reason seeder=pip didn't work is because we use python3 -mvenv not virtualenv18:17
clarkbnot because virtualenv was too old18:17
clarkbvirtualenv was plenty new and would have worked if we used virtualenv18:17
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: ensure-tox: include tox-venv plugin  https://review.opendev.org/70723718:17
*** jamesmcarthur has joined #openstack-infra18:18
mordredclarkb: the dib element does python3 -m venv for python3 and -m virtualenv for python218:18
noonedeadpunkclarkb: that's a good point actually18:18
clarkbmordred: that makes sense beacuse no -m venv on python218:18
*** eharney has quit IRC18:18
openstackgerritMonty Taylor proposed openstack/project-config master: WIP Install pip and virtualenv only from get-pip  https://review.opendev.org/70744218:19
mordredclarkb: ^^ that adds the environment setting for DIB_PYTHON_VIRTUALENV but hardcodes it to python3 -m virtualenv18:19
fungiclarkb: got it, so we weren't actually using virtualenv as our virtualenv command18:19
clarkbfungi: correct18:19
mordredclarkb: we have no images without python3 available right?18:19
fungithat makes perfect sense, in a twisted sort of way18:19
clarkbmordred: centos7 is quasi available18:20
mordredclarkb: yeah. there's the epel repo which is where it comes from18:20
clarkbmordred: no its in actual centos 7 now, no epel18:20
mordredoh yeah? NEAT18:20
clarkbbut I don't know that it is installed by default18:20
mordredclarkb: that's ok - I've got package-installs.yaml for that18:21
mordredclarkb: also - I tested in a container - but it seems liek get-pip is installing into /usr/local on fedora18:21
clarkboh neat they must've changed that on fedora then18:21
mordredyup. same on f2718:22
mordredmakes the cleanup script idea easier18:22
clarkbwhat about centos 8?18:23
*** gfidente is now known as gfidente|afk18:23
clarkbpretty sure it doesn't do that on centos 718:23
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: bindep:  use venv when possible  https://review.opendev.org/70707818:23
*** ijw has joined #openstack-infra18:23
*** igordc has joined #openstack-infra18:23
clarkbI really dislike that debuntu decided to remove venv from stdlib18:24
ijwCould someone +A https://review.opendev.org/#/c/706790/ for me?18:24
openstackgerritMonty Taylor proposed openstack/project-config master: WIP Install pip and virtualenv only from get-pip  https://review.opendev.org/70744218:25
mordredclarkb: checking centos7 now18:25
clarkbmordred: in ^ the rhel stuff installed python2 then 3 in that order which was important accoprding to the comments but now you've gone the other way18:26
ijwThanks clarkb18:26
clarkbmordred: I think because `pip` will be which ever version installs second18:26
clarkbugh18:27
fungithe underlying reason for debian separating venv out of the stdlib package is that it depends on ensurepip which is also separated out18:27
zbrwhy we are not using ansible_python.executable to decide which python to use?18:27
clarkbzbr: because that is compeltely orthogonal18:27
clarkbzbr: all of this happens long before ansible is on the scene18:27
*** eernst has joined #openstack-infra18:28
clarkbmordred: fungi: now that I'ev got more of this mapped into my head. I think we should use python3 -m venv to create all virtualenvs that we create (and this should be possible on centos 7 now with python3)18:29
zbri missed the context, i was referring to roles from zuul-roles.18:29
clarkbthen we are consistent, use stdlib version and don't have to track virtualenv development18:29
clarkbzbr: this is image building18:29
mordredclarkb: /usr/local18:30
clarkbmordred: oh wow18:30
clarkbthen for pip, pip3, and pip2 I think we should probably do python3 then python2 on centos7 and xenial. But can do python2 then python3 on everything else?18:30
clarkbI think that will roughly preserve the python2 defautl of those platforms18:31
clarkbwhile using python3 on newer systems18:31
*** jamesmcarthur has quit IRC18:31
*** jamesmcarthur has joined #openstack-infra18:31
mordredclarkb: oh. wow. this gets funner18:32
mordredclarkb: so - for 3 it all works like we want18:32
mordredclarkb: for 2 - on centos7 - it seems to be installing into /usr/ still18:32
clarkbmordred: probably because the python3 comes from centos818:32
zbrprefering python2 on centos7, but prefering python3 on 8.18:33
mordredclarkb: yeah18:33
fungiyeah, red hat's pip2 wants to install into the same path as its rpms18:33
fungifor $reasons18:33
clarkbfungi: re venv on debuntu you don't have to install a bunch of other stdlib that relies on extra packages separately though18:33
fungilong-standing disagreement with the direction debian went with a sieve for dist-packages and site-packages18:33
mordredbut ... luckily - python2 on centos7 does not force-bring in python2-pip ... so we can still clean out /usr/bin/pip safely on the cleanup script18:33
clarkbthings like curses and readline are just there18:33
clarkbthey might be separately packaged but I don't have to think about them because if I install python I get them18:34
zbryep, rpm systems do not have the luxury found on deb ones, where pip installs to different location than system packages.18:34
fungiclarkb: well, technically you do, but they flag it as important18:34
mordredzbr: they do on centos818:34
mordredit works properly for python3 on centos818:34
zbryeah? i did not know that, that is clearly a positive change.18:35
mordredscuse me - it works properly for python318:35
mordredzbr: yah! I'm thrilled!18:35
fungiclarkb: the interpreter is in a separate python-minimal package which doesn't include stdlib18:35
mordredI guess python3 gave people the chance to walk back from the previous thing18:35
clarkbfungi: right but why doesnt' installing `python` including venv?18:35
clarkbit includes readline and curses etc18:35
fungiclarkb: because venv needs ensurepip to install things into the venv18:35
clarkbI guess the problem is in dependency lists18:35
fungiand ensurepip is separated out18:35
clarkbfungi: right and readline needs readline and curses curses18:36
clarkband so on18:36
clarkbyou can still have those dependencies18:36
clarkbeven if separately packaged18:36
fungisure, but the python package depends on those18:36
*** amoralej is now known as amoralej|off18:36
clarkbright I guess I'm suggesting the `python` package should depend on its stdlib packages18:37
clarkb(and those packages on their deps)18:37
fungiit doesn't depend on pip because the python packagers for debian have a fundamental disconnect when it comes to installing another package manager as part of the base stdlib18:37
fungiso pip and any other modules which need pip are separated from the stdlib package18:37
clarkbmordred: I'm now trying top puzzle through how we can make this transition a bit more gracefully. I thinkwe can probably do the python3 -mvenv switch first (adding in centos7 python3)18:38
*** ykarel|afk is now known as ykarel|away18:39
clarkboh wait does what fungi say mean if we install python3-venv it will install system pip?18:39
AJaeger_thanks for reviewing, clarkb18:39
clarkbin that case we may not want to use python -m venv as it would conflict with that leave system alone and make cleanup early plan18:39
clarkbAJaeger_: I'm slowly getting through themn18:39
clarkb(really slowly)18:39
clarkbfungi: mordred if that is the case then maybe just dealing with `virtualenv` is the best thing to keep the system cleanable18:40
fungihttps://packages.ubuntu.com/bionic-updates/python3.6-venv shows it depends on python-pip-whl18:40
fungisee https://packages.ubuntu.com/bionic-updates/all/python-pip-whl/filelist for what that drags in18:41
fungithe argument there has some legitimacy18:41
openstackgerritMonty Taylor proposed openstack/project-config master: WIP Install pip and virtualenv only from get-pip  https://review.opendev.org/70744218:41
openstackgerritMerged openstack/project-config master: Remove networking-vpp entry  https://review.opendev.org/70679018:41
clarkbhuh so it isn't really installing those packages as much as installing package files that venv can isntall18:42
clarkbneat18:42
mordredclarkb, fungi: ok - I think that version might be solidish - as well as the cleanup script18:42
*** jamesmcarthur has quit IRC18:42
AJaeger_clarkb: as time permits - otherwise do them tomorrow ;)18:42
*** AJaeger_ is now known as AJaeger18:42
mordredbut yeah - I think for the sake of sanity and cleanability - we want to just use virtualenv18:42
fungiclarkb: yeah, so you don't wind up with them in your system context at least18:43
mordredmuch as I approve of fungi and ianw's position of switching to venv :)18:43
*** ahosam has joined #openstack-infra18:43
clarkbmordred: it has the pip2 vs pip3 as `pip` problem as well as pulling in python-venv may pollute things (though not too bad according to the file list above)18:43
*** jamesmcarthur has joined #openstack-infra18:43
clarkbmordred: also does that install python3 on centos7?18:43
mordredyup18:43
clarkbI still don't understand how that works if so18:43
mordredit just works18:43
mordredyum install python3 works on centos718:43
clarkboh ok18:44
clarkbso we don't need package mapping or anything18:44
clarkbmordred: does the empty map for python3 on centos mean use the original value or "does not exist"?18:44
clarkbmordred: line 10 https://review.opendev.org/#/c/707442/4/nodepool/elements/simple-pip/pkg-map18:44
fungibasically the problem is that venv needs to get pip from somewhere, and pip in turn has a bunch of dependencies (including things like requests), and in order to satisfy the dissident test et cetera you need to be able to make a venv without any network connectivity at all, so python-pip-whl ships built wheels of pip and all its dependency chain, in theory built from the corresponding source packages18:45
fungiin the archive for each of those python librarues18:45
fungilibraries18:45
*** eernst has quit IRC18:45
fungiso that the security team doesn't have to patch separate copies of them18:46
fungibut it's ugly enough that they didn't want to make the python stdlib package depend on all that mess18:46
openstackgerritMonty Taylor proposed openstack/project-config master: WIP Install pip and virtualenv only from get-pip  https://review.opendev.org/70744218:46
mordredclarkb: it means skip18:46
*** stevebaker has joined #openstack-infra18:46
clarkbok then I'm confused at how we install pytho3n again :)18:47
mordredclarkb: I just realized we need to not try to uinstall python2-pip on rh - it's hard-required18:47
*** tosky has quit IRC18:47
mordredclarkb: I just cleaned some things up18:47
fungiyes, you can't uninstall it on rhel/centos/fedora because it's part of the system required set18:47
*** jamesmcarthur has quit IRC18:48
zbrso who is against venv? https://review.opendev.org/#/c/707078/18:49
clarkbzbr: well that change doesn't ensure venv is present18:49
mordredyah - but it's ok really. oh - you know - maybe we should not get-pip for the python2 on centos7 case and just let system pip be pip2 - might be the cleanest18:49
clarkbwhich we would need to do on debuntu18:50
clarkbzbr: I don't think anyone is against it so much as we're discovering just how complicated all of this is18:50
mordredzbr: also - I think we're discovering that as nice as venv is it opens up a giant can of worms18:50
mordredyeah18:50
mordredI think I'm now officially against it18:50
mordredbecause of the complexity18:50
mordredsadly18:50
zbrthat is weird because venv is considered part of stdlib, so it should be preffered to anything outside the stdlib, like virtualenv.18:51
clarkbzbr: right but it isn't included on many distros (because debian doesn't include it)18:51
clarkbits still packaged but python3 doesn't imply venv is there18:51
clarkbyou have to install it separately18:51
clarkbfungi and I just has a large converstaion about it a few minutes ago in scrollback18:52
zbrwe can easily do "python -m venv ... || python -m virtualenv ..."18:52
clarkbright, butif we have to cover virtualenv anyway, and it works with all python versions maybe we are better off just doing that for consistency18:53
clarkbthen we avoid the extremely confusing situation we found ourselves in where --seeder=pip didn't work on some images but did on others18:53
*** ijw has quit IRC18:53
clarkbin this case  Ithink consistency is actually really helpful18:53
clarkband venv makes it hard to be consistent ebcause it can't python218:53
zbrvirtualenv>20 will not work on centos 7 and 8, without messing system package python[3]-six, that is known.18:54
clarkbon 8 too?18:54
zbrtoo18:54
*** jamesmcarthur has joined #openstack-infra18:54
clarkbfwiw I think centos7 + virtualenv20 worked fine on our images18:54
clarkbthe key is you have to install six too18:54
zbrit works only if you upgrade six18:54
zbrthat was the main issue, and I really do not like overriding six.18:55
openstackgerritMonty Taylor proposed openstack/project-config master: WIP Install pip and virtualenv only from get-pip  https://review.opendev.org/70744218:55
mordredclarkb: how's that read in the install script ?18:55
zbrwhile there could be hope for a newer six in centos 8.x I have serious doubts it will ever happen for 718:55
clarkbok, I'm going to argue for consistency here beacuse none of us understood the inconsistent behavior having mixed venv and virtualenv18:55
clarkband it created a lot of confusion18:55
clarkbI don't think venv allows us to be consistent18:55
clarkbvirtualenv does18:56
zbrmainly due to support policy18:56
mordredclarkb: I agree18:56
clarkbonce python2 goes away (which won't happen any time soon) we can use venv18:56
zbrand the new feature introduce by virtualenv 20, counts as "consistency", for sure. :D18:56
clarkbzbr: consistency of behavior across platforms18:56
mordredzbr: we're not arguing virtualenv is better ... just simply that we can consistently at least install it across platforms18:56
mordredfor sure18:56
clarkbif virtualenv updates it will potentially break but the break will be consistent18:56
clarkband when we fix it we won't spend a day simply understanding the system18:57
mordredyup. and we won't spend 2 days trying to figure out why it's broken only on e a subset of things in one way and a different subset in a different way18:57
*** jamesmcarthur has quit IRC18:57
*** jamesmcarthur has joined #openstack-infra18:58
zbri think a lot of pain comes from the decision to bake images with stuff that break the support-contract of the OS. I know well why we do it, but also this makes very hard to blame/coerce the distro to fix a problem. Hacks should be possible but not pre-baked.19:00
clarkbwe might also wnat to have an ad hoc meeting with ianw once his day starts as ianw has been involved on the dib side of this19:00
clarkbzbr: ya its a balancing act between doing too much and doing enough that jobs are quick and reliable19:01
clarkbI'm not sure we've managed to correct balance here, but those are the forces pulling in different directions19:01
fungiwell, none of the images we make have any os support contract, we don't even start from their published images, we build them up from scratch and a list of packages19:01
clarkbI do think not caching anything (like bindep) would be a step backwards19:01
mordredyup. and I think we're putting together a plan to get closer19:01
*** yamamoto has quit IRC19:03
* fungi loves it when a plan comes together19:04
*** ralonsoh has quit IRC19:04
clarkbfrom the infrastructure side I think the goals are reasonable consistency so that we can understand behavior even across different distros. Also a reasonable amount of precaching so that tools that are used in most (all) jobs are present and don't put unnecessary load on the mirrors19:05
clarkbFrom the testing side I agree that not providing an all together different experience is useful. However, we've got to accept that to run on certain clouds there will be differences19:05
openstackgerritTristan Cacqueray proposed zuul/zuul master: Gitlab - bootstrap the driver structure + Webhook support  https://review.opendev.org/68568219:05
openstackgerritTristan Cacqueray proposed zuul/zuul master: Gitlab - Basic handling of merge_requests event  https://review.opendev.org/68599019:05
clarkband that requires us to balance those forces against each other19:06
fungiwe might ought to transcribe some of that into https://docs.openstack.org/infra/manual/testing.html too19:07
clarkbunfortauntely this is also an area that doesn't get a lot of attention. Its difficult to test, slow going, and really not shiny19:07
clarkbthat means there is like a grand total of 4 people that poke at this and our biases are likely to leak through19:07
*** jamesmcarthur has quit IRC19:08
*** jamesmcarthur has joined #openstack-infra19:09
openstackgerritMerged zuul/zuul master: Simplify virtualenv install and execution  https://review.opendev.org/70742819:09
clarkbfungi: probably a good idea, though we may want to get some resolution on this particular topic first as we may invalidate the current setup shortly19:10
fungiyep, i meant once we figure out what we should be saying, of course ;)19:11
*** jamesmcarthur has quit IRC19:13
clarkbThinking about base requirements for a second. We need python to be present for glean at the very least19:14
clarkbIf we want to precache bindep venvs then we need pip/virtualenv/etc available at image build time to do that. But don't necessarily need them at image runtime?19:15
clarkbmordred's change approximates ^ by making it possible to clean up the extra tools at runtime19:15
clarkbThat certainly makes it simpler for the image builds as we can do a transition bit by bit19:15
clarkbbut maybe the eventual goal is to remove those tools by default at build time using a similar method?19:16
*** eharney has joined #openstack-infra19:17
mordredclarkb: I think tox pre-installed is the biggie - since that's a requirement for a giant number of our tests and for the most part people just want it to be there and don't care where it came from19:19
clarkbmordred: ya19:20
mordredthat's why I think we need pip/virtualenv/etc available in the images - because otherwise we're installing tox 10k times a day which is a waste if we can remove the parts where it's an imposition on clean test environments for some fokls19:20
clarkbmordred: looking at the WIP change again I feel like I'm getting lost a bit and may need to take a break and come back to it with fresh eyes. However I'm still not quite sure https://review.opendev.org/#/c/707442/3..6/nodepool/elements/simple-pip/install.d/04-install-pip is correct as `pip` will be pip3 on older distros19:20
mordredit's dense - definitely good to take a break19:21
clarkbmordred: I think this was a major bit of what the old code was trying to do. Ensureing that pip and pip3 and pip2 were all mapped approprioately to the correct version19:21
mordredI believe the outcome of that should be that pip is NEVER pip319:21
fungiit's possible to install tox in a virtualenv and link it from /usr/local/bin19:21
clarkband I think in simplifying that we may be inadverdently forcing more things to pip319:21
fungithen we could do a flag day where we drop the symlink19:21
clarkbfungi: it is, but that doesn't solve the case that jrosser and friends have where they use the tool without specifying a path and it is the "wrong" version19:21
mordredclarkb: rm -f /usr/local/bin/{pip,wheel,virtualenv} should remove the bare pip from /usr/local19:22
fungiit would solve it by eventually having the tool not be in the path at all unless their job installed/linked it somehow19:22
clarkbmordred: won't get-pip.py install pip as pip3 if run under python3?19:22
clarkbfungi: well /usr/local/bin is in your path by default19:22
clarkbat least on debuntu19:22
clarkbor are you saying add that link at runtime19:22
mordredclarkb: yes. but that's what we do first19:23
fungihence my suggestion of a flag day where we remove that pre-installed symlink19:23
mordredI don't know what that's trying to solve19:23
clarkbmordred: ah yup the rm is what I'm missing19:23
mordredcould we state the problem that installing tox in a virtualenv and symlinking then one day not symlinking would be solving? my brain may be too fried to follow or infer that one19:24
clarkbmordred: if we symlink into path then users just running `tox` will get an unexpected version not the version from the distro that they may have installed19:24
clarkbmordred: its basically the same issue we have with virtualenv today, except that we've tidied up the installation into a virtualenv19:24
fungimordred: solving 1. the python dependencies for tox getting installed system-wide and so polluting the default execution path/python lib import path, and 2. the possibility that folks want to specify their own means of obtaining tox19:25
mordredyeah. I would like to say I do not accept a desire for distro tox as valid19:25
mordredlike, I'm a hard -2 on that19:25
mordredtox is a test runner abstraction tool - it does not should not and must not matter to zuul users how tox got installed19:25
mordred1) is a valid thing to strive for19:25
fungidistro tox may not be valid, but not polluting the system with pypi tox's dependencies by sticking it in a virtualenv is more the pint19:26
fungipoint19:26
mordredyes - this is a goal I can get behind in general19:26
clarkbya putting it in a virtualenv is likely desireable either way19:26
clarkbI'm just trying to reconcile the fact that virtualenv causes all this trouble because it updated and tox can do the same thing19:26
clarkb(though it has been a long time since tox decided to break everyone on release019:26
clarkbmordred: new question on https://review.opendev.org/#/c/707442/3..6/nodepool/elements/simple-pip/install.d/04-install-pip that is going to make `pip` always python2 right?19:27
fungialso if we make it widely known that we provide a convenience symlink at /usr/bin/tox to /usr/venv/tox/bin/tox then folks who do care about distro tox can just add a role which does `rm /usr/bin/tox`19:27
clarkbmordred: I think that is a chagne in behavior for bionic and centos-819:27
fungier, at /usr/local/bin/tox i mean19:27
clarkb(this is where consistency and trying to do the right thing for the platform becomes tricky, btu  Ibelieve this is what ianw aimed to ahcived in the dib pip stuff)19:28
clarkbmaybe the thing to do here is take a break. Get ianw's thoughts on it and see where we end up then19:28
clarkband then try and break whatever we end up with into as many bite size chunks as possible19:29
mordredclarkb: oh is it? I thought the contract was pip == python2 and pip3 == python3 but that people shoudl stop using pip directly and instead use pythonX -m pip to be sure19:29
mordredclarkb: ++19:29
mordredI think that's a GREAT idea19:29
mordredbecause it's been a dense morning and my brain hurts19:29
clarkbfungi: we should symlink bindep simiarly too19:30
clarkb(going back to consistency, if we are going to do virtuaelnvs for utilties and have them accessible by jobs lets get them in PATH consistently too)19:30
fungiclarkb: if that's a pattern we want to retain anyway. right now we expect jobs to know where to find bindep (or install it themselves) because we don't link it into the path19:30
*** jamesmcarthur has joined #openstack-infra19:30
clarkbya, we could transition away from that.19:31
clarkbThat way we don't have to remember these things operate differenlty :)19:31
fungii was considering the symlink for tox as a transitional step to just expecting jobs to know where we install the tox entrypoint19:31
*** jamesmcarthur_ has joined #openstack-infra19:31
fungiat which point we could drop the symlink for it19:31
mordredI'm not crazy about expecting jobs to know where we install the entrypoint19:31
clarkbhrm19:31
clarkbya I think that makes generic roles in zuul-jobs a bit tricky19:31
mordredI think that's complexity for not a lot of value19:31
mordredespecially for things like tox19:32
fungibut i agree with clarkb, if we want to provide tox in the path by default, then we should do it for tools like bindep as well19:32
mordred++19:32
fungione or the other19:32
mordredI like the symlinking-into-path idea19:32
mordredwell - that said ...19:33
fungiat least if we do them as a single simlink, then jobs which do care to override them only need to delete the symlink19:33
mordredthere's the case to be made that jobs are already supporting variables like tox_executable because of the case where tox isn't pre-installed and the role installs it into ~/.local and we can't update ansible's path19:33
mordredand we're trying to make the job also able to work without root because people find that important19:33
mordredso - this may be one of those collect all the use cases things19:34
clarkbhttps://etherpad.openstack.org/p/pTFF4U9Klz I'm starting to take notes there to try and wrap my head around all of this19:34
mordredit's possible fungi's idea of symlinking as a transition is the right one19:34
*** jamesmcarthur has quit IRC19:35
mordredamusingly - this is a discussion we used to have back at MySQL in the 00s ... do we make the packages shipped by MySQL Inc all behave the same so that the experience of a user installing software "from MySQL" the same - or do we make each one behave like things "are supposed to" on each given platform, making things behave like a user of that platform expects but potentially divergent from other19:35
mordredupstream MySQL installs19:35
mordredit turns out there is not a good right answer, sadly19:36
fungimy main concern is to not break jobs which currently expect us to provide tox in the image's default exec path because we've done so since the dawn of openstack ci19:36
mordredyup19:37
fungibut it does seem tractable to wean our jobs off that expectation19:37
mordredit's gonna be a high bar to convince me to break that in the near future :)19:37
*** yamamoto has joined #openstack-infra19:39
fungiwell, we used to preinstall piles of stuff in our images, as i'm sure you remember, and we (eventually) were able to stop19:41
mordredyes- thank heavens :)19:44
*** stevebaker has quit IRC19:50
*** smarcet has joined #openstack-infra19:51
*** dtantsur|brb is now known as dtantsur|afk19:51
*** stevebaker has joined #openstack-infra19:51
*** yamamoto has quit IRC19:52
*** jamesmcarthur_ has quit IRC19:54
*** ahosam has quit IRC19:54
*** ahosam has joined #openstack-infra19:55
*** smarcet has quit IRC19:57
*** igordc has quit IRC19:58
fungimordred: see updated comment on 705690, it looks like you maybe copied erb from a puppet template into that j2 template for the vhost19:58
fungitemplating language context switch19:59
clarkbok I think https://etherpad.openstack.org/p/pTFF4U9Klz is fairly complete with what I managed to keep paged in19:59
clarkbothers that have been involved feel free to update19:59
clarkbzbr: fungi mordred jrosser noonedeadpunk ^19:59
clarkbmordred: fungi I'm kind of thinking maybe we can have pip be top level but then have everything else in some set of virtualenvs and symlinked into path as necessary20:00
clarkbmordred: that slightly changes your WIP change as virtualenv wouldn't need to be installed system wide20:00
*** auristor has quit IRC20:01
clarkbmordred: I think it simplifies the cleanup process (rm pip things and symlinks), while still allowing jobs that need to create a virtualenv or use tox without caring about what version they get20:01
*** ahosam has quit IRC20:01
*** ahosam has joined #openstack-infra20:01
*** auristor has joined #openstack-infra20:02
mordredclarkb: maybe ... I think we should double check jobs using virtualenv20:04
clarkbmordred: virtualenv will happily make a new virtualenv elsewhere even against different python (if you -p)20:04
openstackgerritMerged openstack/project-config master: check-release-approval: log Gerrit data on error  https://review.opendev.org/70743220:04
clarkbthough we should test that on a variety of sytstem as it may differ20:05
*** ahosam has quit IRC20:05
mordredoh - yeah - I get what you're saying20:05
mordredyeah - totally20:05
*** ahosam has joined #openstack-infra20:06
* mordred has to run to lunch - will fix 705690 and do another pass on the image patch when he returns20:06
clarkbI'm on parenting duty again this afternoon fwiw. Will be taking them to swim class20:06
openstackgerritTristan Cacqueray proposed zuul/zuul master: Gitlab - bootstrap the driver structure + Webhook support  https://review.opendev.org/68568220:16
openstackgerritTristan Cacqueray proposed zuul/zuul master: Gitlab - Basic handling of merge_requests event  https://review.opendev.org/68599020:16
fungiclarkb: mordred: i noted in the pad too, but running pip from a virtualenv really only breaks system-wide `sudo pip install ...`20:19
fungi`pip install --user ...` works fine from a virtualenv pip20:20
fungiand installs into your ~/.local rather than the virtualenv20:20
fungigranted, we likely have a ton of `sudo pip install ...` going on, even beyond devstack20:21
fungithough --root or --prefix could be used to work around that20:26
*** armax has quit IRC20:45
*** armax has joined #openstack-infra20:48
*** ChanServ has quit IRC20:50
ianwjust catching up ...21:00
ianwi'm happy to expunge the pip-and-virtualenv element completely ... maybe whatever that breaks is no worse than whatever is broken now21:01
clarkbianw: I've tried to distill things in https://etherpad.openstack.org/p/pTFF4U9Klz21:02
ianwok, will read in a sec21:03
openstackgerritTristan Cacqueray proposed zuul/zuul master: Gitlab - bootstrap the driver structure + Webhook support  https://review.opendev.org/68568221:10
openstackgerritTristan Cacqueray proposed zuul/zuul master: Gitlab - Basic handling of merge_requests event  https://review.opendev.org/68599021:10
*** artom has quit IRC21:12
*** ChanServ has joined #openstack-infra21:13
*** orwell.freenode.net sets mode: +o ChanServ21:13
ianwclarkb: one bit of context i'm missing is why virtualenv/bindep matters for a tool that is supposed to be run basically as a command like bindep/glean?21:15
ianwsorry, virtualenv/venv i mean21:15
*** rfolco has quit IRC21:18
*** rcernin has joined #openstack-infra21:18
clarkbianw: because the change to fix virtualenv yesterday was only needed on centos7 where we use actual virtualenv and broke everything else. Its mostly about creating consistency where possible yo avoid unexpectedbehaviors21:18
clarkb*to avoid21:18
fungiheading out for an early dinner, but will check back soon21:21
TheJuliaout of curiosity, has anyone seen odd spikes in wait time on test vms?21:24
TheJuliarecently21:24
mordredclarkb: back - so - can you tell me what you think the update to what Iv'e got should be? we should put tox and virtualenv pip each into virtualenvs - what makes those virtualenvs?21:29
mordredalso - morning ianw!21:32
mordredclarkb: I think - from reading the summary in the etherpad - that for those steps to make sense, we still need the WIP patch as a baseline - that is "be able to install consistent pip / virtualenv in such a way that it can then be cleaned up"21:34
mordredbut maybe ... maybe that means installing it from distro packages, using that to make the utility venvs, then distro package uninstalling21:35
mordredwhich - I think dib makes easy, since we can put in a finalize.d step to remove python-virtualenv again, yeah?21:35
ianwi feel like venv's are the right thing for utilities?  (not virtualenvs?)21:36
mordredk. that makes sense to me and I can work on it21:36
openstackgerritTobias Henkel proposed zuul/zuul master: Report retried builds in a build set via mqtt.  https://review.opendev.org/63272721:36
ianwespecially on centos8, where you want to install them under the "system python" which has venv but not virtualenv?21:36
mordredianw: except we need python2 as well21:36
mordredsince we need a pip221:36
*** ociuhandu has joined #openstack-infra21:37
mordredso I think just yum install python2-virtualenv python3-virtualenv ; # make virtualenvs ; yum remove python2-virtualenv python3-virtualenv should be fine21:37
ianwwhat do we need a pip2 for?21:38
ianwsorry i have to do a school run, bib21:38
mordredthe idea from clark above is to not have pip or virtualenv installed at the system level at all21:38
mordredbut instead to install them into virtualenvs and make symlinks into /usr/local/bin21:38
mordredso that if people (like OSA) don't want to use them, we can just remove the symlinks and it's all good21:39
ianwohhh, right, sorry i thought we were talking about glean/bindep installs21:39
mordred(this is the extreme version - and might not work because of sudo pip install globally)21:39
mordredianw: it's probably a better step to just start with those :)21:39
mordredand I agree - we can just use venv for those while we get our feet wet with this21:39
ianwi think we are, right?21:40
mordredif we switch all the way to providing pip2 via a virtualenv and symlink - we'll want to change those21:40
mordredno - we do them differently depending on os21:40
ianwwell, only on centos721:40
mordredit's venv in some places, virtualenv on others21:40
mordredright - that's differently based on os21:40
ianwhttps://opendev.org/openstack/diskimage-builder/src/branch/master/diskimage_builder/elements/pip-and-virtualenv/README.rst#environment-variables21:40
openstackgerritMonty Taylor proposed opendev/system-config master: Use LE certs for Apache  https://review.opendev.org/70569021:44
openstackgerritMonty Taylor proposed opendev/system-config master: Update letsencrypt_gid documentation  https://review.opendev.org/70587821:44
mordredfungi: thanks - that should fix that one hopes21:45
*** ociuhandu has quit IRC21:48
*** ociuhandu has joined #openstack-infra21:49
clarkbmordred: ya I think whatever is easy to install then u install21:52
*** ociuhandu has quit IRC21:52
clarkbTheJulia: no I dont think so21:53
openstackgerritMerged zuul/zuul master: Don't run jobs if only their file matchers are updated  https://review.opendev.org/70639921:53
clarkbTheJulia: it will vary based on demand and cloud error rate (as we retry per cloud 3 times)21:53
openstackgerritTobias Henkel proposed zuul/zuul master: Report retried builds in a build set via mqtt.  https://review.opendev.org/63272721:54
TheJuliaclarkb: okay, I'm just looking at some logs and seeing neutron freaking out on message bus messages not responded suddenly correlating to a spike in wait time on the cpu but there really is no way to be sure :(21:55
clarkboh cpu wait time21:56
clarkbnot wait time for atest node21:56
mordredclarkb: ok. I think that sounds good - but I think it's maybe a followup21:56
clarkbmordred: ya I definitely think tackling this in small chunks is the way to go21:56
mordredprimarily since we need to be careful with global pip installs21:56
openstackgerritJames E. Blair proposed zuul/zuul master: Don't report enqueue of non-live item  https://review.opendev.org/70747922:01
clarkbTheJulia: for cpu wait time I think we've found some clouds are worse than others for that and I think jobs swapping may have an impact on that (at least as our own noisy nieghbor)22:01
*** pkopec has quit IRC22:03
ianwinfra-root: if i could get one more eye on https://review.opendev.org/#/c/706731/ i will monitor the migrated release process today22:04
openstackgerritMerged zuul/zuul master: Gerrit: add polling support for refs  https://review.opendev.org/70613822:06
TheJuliaclarkb: sadly, only about 60M in swap, and tons of free ram, but things did start going sideways right as memory pressure increased22:08
clarkbianw: done22:08
JayFTheJulia: that makes me wonder if the cloud it's running on is doing ram overcommits, but that's a shot in the dark22:10
JayFTheJulia: (i.e.: it's swapping you on the hyp even if not in the VM)22:10
TheJuliaJayF: That could distinctly be the issue, Basically see just enough io wait that messages don't make it across the message bus in time and neutron has a small freakout22:11
TheJuliaand then things recover22:11
clarkbJayF: TheJulia it can also be other jobs swapping hard as we are often the only users of the hypervisors22:13
clarkbregular tempest jobs do swap a fair bit22:13
JayFI was just looking at her corrolation between memory pressure and things going upside-down22:13
clarkbits really hard for us to correlate that info though (but theoretically possible as we have nova hostids)22:14
clarkbah ya that could be22:14
TheJuliayup, this happens to be our standalone job and we have some extra network booting which is super sensitive to neutron just... kind of getting delayed or slightly locked up22:14
* TheJulia wonders if the headache of the single test is wroth it22:15
TheJuliaworth22:15
mordredclarkb: pip can uninstall itself22:15
ianwfungi: i started at having a look at migrating reprepro ... i guess gpg key import is step 0.  ansible has a apt_gpg thing, but not a generic gpg key import22:16
*** dSrinivas has quit IRC22:16
*** sshnaidm has quit IRC22:17
*** sshnaidm has joined #openstack-infra22:18
*** jamesmcarthur has joined #openstack-infra22:20
openstackgerritMonty Taylor proposed openstack/project-config master: Install pip and virtualenv only from get-pip  https://review.opendev.org/70744222:24
*** jamesmcarthur has quit IRC22:24
clarkbmordred: neat22:24
mordredclarkb: ok ^^ check that out now22:24
*** jamesmcarthur has joined #openstack-infra22:25
prometheanfireshould a notice be sent to all channels that gate is broken (to stop the rechecks)?22:25
clarkbprometheanfire: is it broken? I think we've largely fixed things22:26
mordredprometheanfire: it's broken?22:26
mordredyeah - same question22:26
prometheanfireoh, I was under the impression we needed https://review.opendev.org/#/c/70744122:26
*** slaweq has quit IRC22:26
mordredprometheanfire: nope. issues have been fixed in upstream virtualenv22:27
prometheanfireall the reqs grenade checks have failed for the last few hours22:27
prometheanfireso good to recheck?22:27
clarkboh grenade is a d-g thing22:27
clarkband only applies to jobs on xenial aiui22:27
mordredclarkb: is xenial still broken and we missed it?22:28
clarkbmordred: itsbecauseof the six thing22:28
clarkbor something like that22:28
mordredoh. blerg. is somethign instaling old python-six distro packages?22:28
clarkbnot the symlinks22:28
mordredoh - or we're pinning six probably22:29
mordredsomething something22:29
mordred?22:29
prometheanfireit is pinned in constraints22:29
clarkbya or virtualenv doesnt set the lower bound properly and we fail to update22:29
prometheanfireso if you are using that22:29
clarkbah ok constraints. that would do it I think22:29
prometheanfireheh22:29
mordredhere's a recent fail https://zuul.opendev.org/t/openstack/build/2c509d93d10442e1a8765a957e9ef8bd22:29
prometheanfiredepends, a surprising amount of stuff in gate doesn't use constraints22:29
mordredclarkb: "./safe-devstack-vm-gate-wrap.sh: line 508: /tmp/ansible/bin/pip3: No such file or directory"22:31
mordredJOY22:31
prometheanfiresounds familiar22:31
clarkbya that is what 441 aims to fix22:31
clarkbI think it does fix it but I havent double checked an old branch run22:32
openstackgerritTristan Cacqueray proposed zuul/zuul master: Gitlab - Add zuul_event_id and set use get_annotated_logger  https://review.opendev.org/69279922:32
ianwmordred: how does 707442 interact with the extant pip-and-virtualenv package?22:32
clarkbits d-g specific though22:32
mordredthat's going to need an -U22:33
openstackgerritTristan Cacqueray proposed zuul/zuul master: Gitlab - Minimal reporter ables to comment on MR  https://review.opendev.org/69434622:33
clarkbnon legacy jobs should be ok I think22:33
openstackgerritTristan Cacqueray proposed zuul/zuul master: Gitlab - Implement the note event and the comment trigger action  https://review.opendev.org/69896422:33
mordredianw: it replaces it - or tries to22:33
ianwmordred: ahh, yeah, i don't think that's going to purge it because simple-init will still bring it in as a dependency22:33
clarkb(because devstack is managing it directly now)22:33
mordredianw: headdesk22:35
ianwthe only other potential big users of this during dib i can think of is ironic-python-agent22:36
clarkbdoes anyone else have trouble resuming from suspend with newer kernels?22:38
ianwclarkb: that's why i upgrade laptops about once every 10 years, 3 years after getting a laptop it generally starts to suspend, and then you've got about 4 years of it working, and then it will break again :)22:40
clarkbianw: I'm in the break again trough. This is a thinkpad x240 that is almost 6 years old22:40
openstackgerritMerged opendev/system-config master: Migrate AFS publishing to mirror-update.opendev.org  https://review.opendev.org/70673122:40
clarkbmordred: it seems to work without -U if you hard set the version https://zuul.opendev.org/t/openstack/build/19807b442cfc44cd9b871ace9c0cc1e7/log/job-output.txt#303222:41
ianwmordred: maybe if we attack this from the "how are we going to install glean" side first?22:41
clarkbit semes like if I close lid again and wait for it to sleep then try resume again I have a high rate of success22:42
fungiokay, back from dinner22:42
clarkbprometheanfire: do you know if grenade jobs are failed to changes against master?22:43
mordredclarkb: neat22:43
clarkbprometheanfire: if so then I think this problem is different than we thought22:43
fungicatching up on all the chatty22:43
clarkbbut if stable branch specific then ya I'm fairly certain it is the six thing22:43
mordredianw: well - we could do that, but I don't think that's the problem22:44
prometheanfireclarkb: I can check some recent stuff, how far back should I look?22:44
prometheanfirehttps://review.opendev.org/707218 failed an hour ago22:44
clarkbprometheanfire: since this morning. Maybe last 8 hours or so22:44
mordredianw: while there are _many_ use cases, I think the two fundamental problems are a) what is getting installed or not installed right now is super confusing b) we have users with legit use cases for wanting to not have pip installed virtualenv be the virtualenv they get22:45
clarkbhrm that is a bionic job against master22:45
clarkbdid virtualenv regress furhter?22:45
mordredthere is a 20.0.322:45
clarkbor is six 1.14.0 https://zuul.opendev.org/t/openstack/build/60f3cddb8c6449f8b5e1271bd5e9652c/log/job-output.txt#2980 not actually new enough22:45
clarkb1.14.0 is latest22:46
mordredianw: I think maybe what we shoudl do is migrate that patch to be one that adds a new element to dib - then make a virtual element that both pip-and-virtualenv and simple-pip provide22:46
prometheanfireya, that matches UC22:46
clarkboh22:46
clarkbI betcha it doesn't install a pip322:46
* clarkb checks22:46
prometheanfireheh22:46
*** eernst has joined #openstack-infra22:46
mordredjust . pip?22:46
mordredI mean - if we're calling the pip in a virtualenv, there is only one python in that virtualenv, it's safe to call it pip22:47
clarkbmordred: ya22:47
mordredclarkb: you want me to do the patch?22:47
clarkbmordred: let me confirm really quickly then sure22:47
clarkbif you can patch ready I'll work on confirming behavior22:47
openstackgerritMonty Taylor proposed openstack/devstack-gate master: Just use the pip from the virtualenv  https://review.opendev.org/70749022:48
clarkbmordred: confirmed, you get a pip2 but no pip322:49
mordredis that doing a python2 virtualenv then?22:49
clarkband pip2 installs against python322:49
mordredwat?22:49
clarkbno I set -p and confirmed bin/python --version and bin/python3 --version22:49
ianwmordred: zero disagreement there about it being confusing and crufty.  that was why dropped all installations on centos822:49
clarkbya I think this is a new bug22:49
mordredclarkb: wow22:50
clarkbor new as of virtualenv 2022:50
mordredwell - the patch above will "fix" it22:50
mordredsince we already asked for a python version - so just plain pip in the venv pathwill be the rightone22:50
mordredianw: I mean - I'm *very* impressed by the levels of interwoven use cases the existing code is solving :)22:50
clarkbmordred: yup22:50
clarkband we can revert gmann's change if it passes testing22:51
mordredclarkb: so that's a python2 virtualenv with -p python3 ?22:52
clarkbmordred: no its a python3 virtualenv with a `pip2`22:52
clarkbI've confirmed this behavior does not exist on virtualenv 16.7.522:52
clarkbmordred: run `virtualenv -p python3 foo` and check foo/bin22:53
mordredclarkb: right - but what I mean is - it's a virtualenv installed with python222:53
clarkbthen do it again for old virtualenv22:53
mordredthen that virtualenv was used with --python322:53
clarkbmordred: oh maybe. Let me check that22:53
mordredI just reprodiuced it in that case22:53
clarkbok yup me too22:53
clarkblet me try with a python3 virtualenv22:53
mordredI did - got pip322:54
*** tkajinam has joined #openstack-infra22:54
mordredso I thnik that's a new bug - it's matching the pip suffix to the version of python from virtualenv, not the version of python installed IN the virtualenv22:54
clarkbyup agreed22:54
mordredit's in 20.0.2 too22:55
clarkband also reproduced here22:55
mordredconfirmed in 16.7.9 it does what's expected22:55
mordredI'l go file a bug22:55
clarkbwhat I don't understadn in the d-g case is that should be a python3 installed virtualenv creating a python3 virtualenv22:56
clarkbhowever, I'm probably wrong about ^ as it explains the failures22:56
*** sgw has quit IRC22:59
mordredvirtualenv in the images is python223:01
mordredacross the board - that's one of the things in the README for pip-and-virtualenv23:02
clarkbgotcha23:02
clarkband really it shouldnt matter because -p23:02
mordredit's an explicit choice - I think because changing the python it's installed with changes some defaults for tox23:02
clarkbbut new bugs :)23:02
mordredyah23:02
*** jamesmcarthur has quit IRC23:02
mordredwoohoo - I got a round-numbered issue: https://github.com/pypa/virtualenv/issues/160023:03
prometheanfirelol23:03
prometheanfiremight want to edit it though23:03
prometheanfirethe pip commands installed in the virtualenv are pip and pip3 rather than pip and pip323:04
*** rh-jelabarre has quit IRC23:04
fungithat last statement confuses me23:04
clarkbfungi: its quoted from the issue23:04
fungishould one pip3 be a pip2?23:04
clarkbit should be are pip and pip2 rather than pip and pip323:04
fungigot it23:04
prometheanfire:D23:04
clarkbI think mordred has to edit it as the filer23:04
fungiand now i23:05
fungi'm caught up23:05
fungiianw: i'll be honest, i know nothing about possible ansible plugins/extensions/modules for gnupg/openpgp key management23:06
mordredfixed23:06
prometheanfiresubscribed23:06
mordredprometheanfire: also, https://review.opendev.org/#/c/707490/ should fix you23:06
prometheanfiresubscribed23:07
clarkbas will the change from gmann (bceause old virtualenv works)23:07
clarkbI think we land both then push a revert for gmann's change23:07
clarkband if the revert passes testing we can land the revert23:07
mordred++23:07
mordredalso - it's interesting that we install virtualenv in devstack-gate23:07
clarkbmordred: I think for third party ci23:08
clarkbsince we don't control the images they run on23:08
*** xek__ has quit IRC23:08
*** eernst has quit IRC23:08
clarkbI bet a git log search will show we broke some third party ci assuming virtualenv was present :)23:08
*** eernst has joined #openstack-infra23:08
mordredclarkb: ah  - nod23:08
ianwmordred: i know a) other fires and b) probably been through this but i'm trying to see there's a path with some notes at end of https://etherpad.openstack.org/p/pTFF4U9Klz23:10
ianwdid we find any issues with clarkb's "provide latest virtualenv from a virtualenv" idea?23:11
ianwthat's something i'd not considered before, but strikes me as a good way to provide the latest tools without taking over the system, and thus avoiding all this package pinning which has been a constant pain for people23:12
clarkbianw: we'd still need to be able to install that virtualenv to install virtualenv but in theory we can clean that up at build time so that at job time its less dirty23:12
clarkband I think it should work because its how I've been using virtualenv locally for a while23:13
clarkb(but my use cases are likely far less diverse than our CI systems)23:13
ianwclarkb: yep, i think that's what i'm getting at -- during the dib build, we have a way to make utility environments (which is forked, but by necessity -- virtualenv on centos7, system-python venv on centos8, python-venv package on debuntu)23:14
mordredyeah - we still have to do the bootstrap stage, and we still need to be able to clean up the bootstrap items23:14
ianwyep, the key is *only* use system packaged virtual environment tools for the utility envs23:15
ianwand then remove them23:15
clarkbya  Ithink that could work23:15
mordredthe reason I'm pushing back on the forked thing so hard is that we'll have to develop similarly forked cleanup ... but - if you think that'll be easier I can be totally on board with that23:15
mordredthe bigger issue would be pip itself23:15
mordredI don't think that one is workable23:15
clarkbmordred: maybe we punt on pip to start23:16
mordredI think we hav eto23:16
clarkbI agree, I just mean lets not worry about it either23:16
mordredwe have too many things (looks at devstack-gate) that assume pip exists and works globally23:16
clarkbwe can improve the other tools separately23:16
mordredno - I mean - I agree we have to punt23:16
ianwbut we could install the latest pip in a virtualenv and symlink it to /usr/local/bin right?23:17
mordredI still think it's gonna be harder to think about though - although I agree things in venvs will totally work23:17
mordredno23:18
mordredthat doesn't work - a pip inside of a virtualenv will install things into that virtualenv23:18
clarkband then things won't end up in $PATH as expected23:18
ianwahhhh23:18
clarkbit would probably mostly work if we didn't have to worry about paths23:18
mordredyup23:18
ianwof course23:18
mordredbut - I kind think once things are broken via needing non-distro pip - it's cleaner to do no distro virtualenv23:19
mordredbeceause it's honestly really easy to clean up from23:19
clarkbfwiw I also don't think this is an emergency. we can take our time to think this through and sleep on it (a few times if necessary)23:19
*** Adri2000 has quit IRC23:19
mordredOH TOTALLY23:19
ianwright ... the only problem with non-distro pip is bugs23:19
mordredianw: if I just put an element-provides in that simple-pip element that said "pip-and-virtualenv" - wouldn't that cause dep resolution to not pull in pip-and-virtualenv?23:20
mordredianw: I thnik you meant s/non-distro//23:20
mordred;)23:20
mordred(if simple-pip was in the list, that is)23:21
ianwmordred: umm, maybe?  i'm not sure if the ordering would get that right23:21
mordredI guess that's ordering specific23:21
mordredyeah23:21
gmannclarkb: mordred: ack.23:21
clarkbmordred: ianw: we could create a new simpler-init23:21
clarkbforklift to avoid unexpected conflicts23:22
ianwmordred: certainly we could do something to make it more deterministic and add the element's own element-provides last23:22
ianwclarkb: i think though, even if glean goes out of the picture as a python dependency, you still have other things23:22
openstackgerritMonty Taylor proposed openstack/diskimage-builder master: Add simple-pip element  https://review.opendev.org/70749923:23
ianwmordred: yeah, distro pip.  that's always been the problem; some pip/setuptools bug manifests and blocks all progress, and we can't wait for distros to fix it23:23
clarkbianw: ya that is a good point23:24
mordredianw: there's a dib repo based option23:24
ianwok have to think about that, but it should be fully gate testable in dib23:25
mordredwith that - I think we can then do glean, bindep and tox in virtualenvs pretty easily - the cleanup script will remove pip and virtualenv installed by pip from the system for people like OSA ... and putting it in dib we can adjust the simple-init depends23:25
mordredyeah23:25
mordredalso - it's possible it's garbage :)23:25
*** rlandy is now known as rlandy|bbl23:26
ianwmy inclination is that if we can have "get-pip.py" not involved at all, it's still better; i.e. use distro packages.  i understand the point about divergence of tools -- although if we can see a future without centos7 it then really comes down to "install python-venv on debuntu"23:28
clarkbI suppose we could also do python3.6 on centos723:29
clarkbdo we expect that will cause problems?23:29
clarkb(I'm imagining that delta might also cause jobs to be unhappy for reasons I can't comprehend)23:29
ianwyeah, we could.  my only problem is people basing devstack jobs on epel python3 as RDO does not support that and it just seems like a house built on sand.  but in terms of, say, having glean running from python3 on centos7 hosts, i don't have issues23:31
clarkbits also no epel anymore23:32
clarkbits in the main distro23:32
*** dchen has joined #openstack-infra23:32
mordredianw: heh. I think this is just where we have different povs -- my inclination would be if we could never touch distro packages of pip or virtualenv the world would be much better23:33
mordredbecause the versions of those things are so wildly different23:34
clarkbmordred: I htink ianw's point is that it should be sufficient for boostrapping those tools in a virtuaelnv though23:34
clarkband we can probably do that consistently?23:34
mordredI understand23:34
mordredbut it's just such a complex complex complex thing23:34
mordredand the benefit it gets us over just doing get-pip.py everywhere with no divergence anywhere is fleeting23:34
*** eernst has quit IRC23:35
clarkbya I think the complexity is my concern as well. Since now we are managing two systems rather than one that might be clunky in some cases23:35
clarkbI guess that is the tradeoff23:35
ianwi think though, we might be in a position that everywhere we care about has venv?  which is a package install on debuntu23:35
mordred"on this platform on this verison of python we use this module but not this odule and on this other platform we hav eto install this othe rthing first"23:35
mordredianw: nope. becaues python223:35
ianwbut for our utility virtualenv's we don't need to care about that?23:35
*** sgw has joined #openstack-infra23:36
mordredwe need to have python2 installed virtualenv on the systems23:36
clarkbcan -m venv make a python2 venv?23:36
mordredoh - that's an interesting point23:36
mordredI mean - I still just don't understand the appeal23:36
mordredbut if that's what y'all like23:36
mordredthe thing I want is for every thing we've got to be identical and to not need to know that on centos7 virtualenv is actually in a box in the corner23:37
clarkbI'm reading docs and I don't see that it can23:37
clarkbI think its implied the venv is the same python running the module23:37
ianwmordred: as in /usr/local/bin/virtualenv creates a python2 virtualenv?23:37
mordredianw: no -as in /usr/local/bin/virtualenv is itself installed with python223:37
*** xek has joined #openstack-infra23:37
mordredthat is a current system assumption as to what unqualified virtualenv is - and it's one that was purposefully made23:38
ianwif virtualenv were installed in a venv in /opt, and /usr/local/bin/virtualenv was a script "#!/bin/bash /opt/virtualenv-env/bin/virtualenv -p python2" wouldn't that suffice?23:38
ianw(good god the levels of venv, virtualenv, and virtualenv in venv)23:39
mordredyeah. it might - but _why_23:39
mordredthat's so complex23:39
clarkbif the last -p wins it might work, but ya it starts to get really complicated23:39
fungiianw: clarkb: if it helps, on my local systems i symlink ~/bin/virtualenv to ~/lib/virtualenv/bin/virtualenv (after a `python3 -m venv ~/lib/virtualenv`) so this is a thing which works generally23:40
ianwi don't really see it as that complex.  the latest virtualenv is installed in /opt/virtualenv-env ... that's it23:40
mordredianw: on your system it's ok for virtualenv to have been installed with python323:40
fungimordred: ianw: pip run from a virtualenv will install into the virtualenv *by default* but can be overridden with command-line options23:40
mordredyes. but those command line options will not be the command line options someone who just runs pip is going to iuse23:41
* fungi tried to capture some of this in the etherpad23:41
clarkbright this is about preserving enough behavior that we don't make things worse23:41
*** sgw has quit IRC23:41
ianwfungi: so in a similar way, possibly /usr/local/bin/pip could be "#!/bin/bash /opt/virtualenv-env/bin/pip --some-option-to-break-venv" ?23:41
mordredother than ickiness from folks with distro backgrounds, what is the issue with using get-pip?23:42
mordredlike, what use case does it break? and in what way is it complex?23:42
clarkbmy concern would be that it pollutes its deps (I don't know that it does)23:42
ianwthe problem has always seem to be that installing distro packages then wipes out get-pip23:42
ianwinstalled stuff.23:42
clarkbbut say requests would be from pypi instead of distro potentially23:42
mordredYES .. but that's why we're adding a cleanup script23:42
mordredit is ABSOLUTELY unacceptable to install python-pip over top of get-pip installed pip23:43
mordredthat will ALWAYS break23:43
clarkbright and I think the cleanup script addresses ianw's concern too23:43
mordredyeah23:43
mordredclarkb: could you say more words around "pollutes its deps"?23:44
fungisomeone should probably just boot an ubuntu-bionic minimal image and run get-pip.py and then look at the result of `pip list23:44
fungibut pip has runtime dependencies on other python libs like requests23:44
clarkbmordred: python-requests and so on. Does get-pip.py pull those in as normal deps or are they all fully vendored23:44
*** sreejithp has quit IRC23:45
*** goldyfruit has quit IRC23:45
clarkbmordred: I think the cleanup scrip addresses this too fwiw, but you have latest requests because pip pulled it in, but expected the 2 year old distro requests instead23:45
fungialso do the "vendored" libs wind up in the normal python interpreter import search path23:45
clarkbfungi: right that23:45
prometheanfirethis is why we restrict pip from installing system libs, pyenv exists as well if we wanted23:45
*** goldyfruit has joined #openstack-infra23:45
mordredclarkb: they're all fully vendored23:45
clarkbprometheanfire: the problem is we can't just say tomorrow everyone needs to use pyenv23:45
fungiprometheanfire: again, th etrick is making sure that gets called by people who don't know where it's installed23:46
clarkbprometheanfire: we need to have a graceful transition23:46
mordredsorry - I shoudl have mentioned - I did exactly what fungi mentioned on ubuntu and fedora and centos earlier today23:46
prometheanfireagreed, that is a longer term thing23:46
fungimordred: ooh! details?23:46
clarkbmordred: ok if they are all fully vendored then I think having get-pip installed pip is fine if we say "use the cleanup script if you don't want it"23:46
mordredI installed get-pip directly on a clean install - both with and without python-pip installed, and I looked at the actual overlap23:46
mordredthe list of packages in the cleanup script is exactly what get installed - and to the best of my abilities it seems as if the cleanup script commands completely clean them up23:47
timburkehi -infra! i've been seeing a bunch of swift failures in the last day or so: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22AttributeError%3A%20'Namespace'%20object%20has%20no%20attribute%20'with_traceback'%5C%22 (you'll want to change the time period to last two days or so)23:47
timburkeit seems to be fixed by virtualenv 20.0.3 -- i was just wondering how often those base images get rebuilt (ie, when i can start rechecking jobs so they'd have the new virtualenv)23:47
ianwmordred: why do we need to *use* the latest/non-distro pip?  yes we want to *provide* it, but what do we need to run it for?23:47
mordredit's _entirely_ possible I derped that - but I was basing all of that element on doing stuff in clean containers of each distro to double check23:47
mordredianw: I want to use it because I want pip to be identical across all of our nodes23:48
clarkbtimburke: daily, can you link to a specific job example logs so that we can cross check with known virtualenv fallout?23:48
mordredbecuase I dont;' want to be tracking down issues with pip v14 when something derps because some distro decided to patch it because they don't like pip or something23:48
mordredalso - we've used latest pip for forever - so I don't understand the value of going to distro pop23:49
ianwmordred: so you feel strongly that glean should be installed with the latest pip?  see i feel like that's a very separate thing to what nodes use during CI23:49
timburkeclarkb, https://zuul.opendev.org/t/openstack/build/3eef852dfacf4a639500e09534090933 for example23:49
mordredianw: oh - I don't care about what glean gets installed with23:49
*** yamamoto has joined #openstack-infra23:49
mordredianw: I care that we have latest pip available for our users to use on their test nodes in tox and whatnot23:49
mordredbut I agree - what glean gets installed with is completely separate23:50
ianwmordred: right, we totally agree on that.  what i'm concerned about is during the dib build, we install pip with get-pip.py, and then something comes and install a system package, and then we have a big mess23:50
clarkbtimburke: and you've confirmed that 20.0.3 fixes that?23:50
mordredianw: that's already the case - and why we're adding the cleanup script for them to use23:51
ianwthat's why i'm trying to think through making the dib build *only* use system packages -- but provide the latest stuff via links, etc23:51
mordredright now what happens is they install distro pip and they don't get it23:51
clarkbtimburke: I think 20.0.3 is starting to end up on our images https://zuul.opendev.org/t/openstack/build/19807b442cfc44cd9b871ace9c0cc1e7/log/job-output.txt#3030 shows it was there then we downgrade it due to https://github.com/pypa/virtualenv/issues/160023:51
timburkeclarkb, sure seems like it would be fixed by https://github.com/pypa/virtualenv/commit/77f0dd80a12105864d8475abb6609dfd693ef5ac#diff-79b6454ee141f415b84cfbe2e037cc6023:51
clarkbtimburke: I think that means you should start to see it getting better23:51
ianwmordred: sort of -- the pip-and-virtualenv element prevents this by pinning the distro packages23:51
mordredyeah - which is actually problematic for OSA23:52
mordredwho use virtualenv as a part of their production deploy but who expect to use distro virtualenv and have no way to get it23:52
clarkbmordred: sort of, they explicitly dep on virtualenv from pypi and install it, then don't use it ...23:52
ianwright, but your proposed element doesn't.  so from a generic dib POV, if someone uses it, it install pip from get-pip.py, but then their stuff could pull in system pip, and ... urgh23:52
clarkbI'm not sure which side of that they will end up deciding is a bug, but ya23:52
mordredianw: right - but they MUST use the cleanup script first them23:53
clarkbianw: oh that is a good point23:53
mordredthat is why it's there - it is for their use case23:53
ianwmoredred: in a dib element?23:53
timburke👍 thanks, clarkb!23:53
mordredoh - generic dib23:53
mordredyeah - sorry - that's why this was in project-config to start :)23:53
mordredit's a very good point from a generic dib perspective23:53
mordredI'm purely thinking about infra nodes23:54
*** yamamoto has quit IRC23:54
timburkei'll probably wait a little longer then kick off some rechecks before i sign off for the day23:54
fungitimburke: why do today what can be put off 'til tomorrow?23:55
* fungi has a collection of witticisms obtained from thrift store tee-shirts23:56
mordredianw: ok. it's dinner time for me - I'm sure we'll be back on this topic tomorrow - since it's a largely sisyphiean problem ;)23:56
ianwmordred: that's why i'm sort of thinking that we a) make sure venv is setup from system packages b) dib elements use DIB_PYTHON_VIRTUALENV and know, basically, they'll get a environment to install stuff c) purge the packages d) setup links/scripts so that /usr/local/bin/{virtualenv|pip} do what people think23:56
ianwmordred: yep, thanks for the back and forth.  i like that this is getting attention as it's been a pain point that needed this discussion for a while23:56
mordred++23:57
mordredit's also SUCH a dense topic . - sometimes it takes days like this for us all to page it all in23:57
fungii do think that making sure `python -m venv` works for the available python3 interpreters is a no-brainer, since we install the interpreters from system packages and venv is *supposed* to be part of stdlib... except that same argument doesn't seem to work for pip23:57
fungiin all honesty, it's a pain point which has needed addressing since before openstack23:58
fungiit's just gotten worse over time23:58
mordredwe could always return to openstack circa 2010, ditch pip and do everything from deb packages23:59

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