Monday, 2020-07-20

*** irclogbot_1 has quit IRC00:16
*** rlandy has joined #zuul00:18
*** irclogbot_3 has joined #zuul00:21
*** bolg has quit IRC00:27
*** rfolco has quit IRC00:33
*** saneax has joined #zuul02:21
*** bhavikdbavishi has joined #zuul02:35
*** bhavikdbavishi1 has joined #zuul03:10
*** bhavikdbavishi has quit IRC03:12
*** bhavikdbavishi1 is now known as bhavikdbavishi03:12
*** saneax has quit IRC03:58
*** bhavikdbavishi has quit IRC04:20
*** bhavikdbavishi has joined #zuul04:21
*** vishalmanchanda has joined #zuul04:51
*** saneax has joined #zuul05:49
*** bhavikdbavishi1 has joined #zuul06:01
*** bhavikdbavishi has quit IRC06:02
*** bhavikdbavishi1 is now known as bhavikdbavishi06:02
*** marios has joined #zuul06:28
openstackgerritMerged zuul/zuul-jobs master: Remove copy paste from upload-logs-swift  https://review.opendev.org/74184006:41
*** bhavikdbavishi has quit IRC06:41
*** holser has joined #zuul06:53
zbr|ruckreviews needed on https://review.opendev.org/#/c/740733/ and https://review.opendev.org/#/c/739482/07:00
*** bhavikdbavishi has joined #zuul07:07
*** bhavikdbavishi has quit IRC07:13
*** jcapitao has joined #zuul07:16
*** bhavikdbavishi has joined #zuul07:22
*** yolanda has joined #zuul07:31
*** tosky has joined #zuul07:34
*** jpena|off is now known as jpena07:46
*** bhavikdbavishi has quit IRC07:57
*** wuchunyang has joined #zuul08:03
*** bhavikdbavishi has joined #zuul08:07
*** nils has joined #zuul08:09
*** wuchunyang has quit IRC08:31
*** bolg has joined #zuul08:42
openstackgerritJan Kubovy proposed zuul/zuul master: Scheduler's pause/resume functionality  https://review.opendev.org/70973508:50
openstackgerritJan Kubovy proposed zuul/zuul master: Separate connection registries in tests  https://review.opendev.org/71295808:50
openstackgerritFabien Boucher proposed zuul/zuul master: gitlab: support the labels requirement  https://review.opendev.org/74189308:58
openstackgerritJan Kubovy proposed zuul/zuul master: Prepare Zookeeper for scale-out scheduler  https://review.opendev.org/71726909:13
openstackgerritSorin Sbarnea (zbr) proposed zuul/zuul-jobs master: Bump ansible-lint to speed it up  https://review.opendev.org/74189709:27
*** sshnaidm|off is now known as sshnaidm09:27
openstackgerritJan Kubovy proposed zuul/zuul master: Mandatory Zookeeper connection for ZuulWeb in tests  https://review.opendev.org/72125409:30
*** bhavikdbavishi has quit IRC09:45
openstackgerritJan Kubovy proposed zuul/zuul master: Connect merger to Zookeeper  https://review.opendev.org/71622109:46
openstackgerritJan Kubovy proposed zuul/zuul master: Connect fingergw to Zookeeper  https://review.opendev.org/71687509:46
openstackgerritJan Kubovy proposed zuul/zuul master: Connect executor to Zookeeper  https://review.opendev.org/71626209:46
*** bhavikdbavishi has joined #zuul09:48
webknjazFolks, Cheroot needs more eyes on the new regression fix PR10:04
webknjazhttps://github.com/cherrypy/cheroot/pull/30110:04
webknjazIf somebody can run it in their envs and it explodes, plz tell me.10:05
*** tosky has quit IRC10:08
*** holser has quit IRC10:08
*** irclogbot_3 has quit IRC10:08
*** reiterative has quit IRC10:08
*** fdegir has quit IRC10:09
*** decimuscorvinus has quit IRC10:09
*** tosky has joined #zuul10:10
*** holser has joined #zuul10:10
*** irclogbot_3 has joined #zuul10:10
*** reiterative has joined #zuul10:10
*** fdegir has joined #zuul10:10
*** decimuscorvinus has joined #zuul10:10
*** smyers has quit IRC10:14
*** smyers has joined #zuul10:15
openstackgerritJan Kubovy proposed zuul/zuul master: Driver event ingestion  https://review.opendev.org/71729910:32
openstackgerritJan Kubovy proposed zuul/zuul master: WIP: Store unparsed branch config in Zookeeper  https://review.opendev.org/70571610:45
*** bhavikdbavishi has quit IRC10:47
zbr|ruckis anyone working on publishing  zuul-roles as a collection? I would really want to make use of some of them outside zuul10:54
zbr|ruckstuff like ensure-docker are very useful10:54
*** wuchunyang has joined #zuul10:57
*** jcapitao is now known as jcapitao_lunch11:13
*** bhavikdbavishi has joined #zuul11:19
*** wuchunyang has quit IRC11:23
*** bhavikdbavishi has quit IRC11:30
*** bhavikdbavishi has joined #zuul11:34
*** weshay_pto is now known as weshay_11:34
*** jpena is now known as jpena|lunch11:45
*** rfolco has joined #zuul11:59
*** yolanda has quit IRC12:14
*** yolanda has joined #zuul12:15
*** Goneri has joined #zuul12:17
*** jcapitao_lunch is now known as jcapitao12:31
*** jpena|lunch is now known as jpena12:32
tristanCzbr|ruck: what would need to happen to use zuul-jobs roles outside of zuul?12:34
tristanCzbr|ruck: (not sure what you meant by `zuul-roles`12:35
tristanCiirc we talked about publishing the zuul_console and zuul_return action modules, those are currently in zuul source tree12:36
openstackgerritFabien Boucher proposed zuul/zuul master: gitlab: support the merge reported  https://review.opendev.org/74193112:50
openstackgerritFabien Boucher proposed zuul/zuul master: gitlab: support the merge reporter  https://review.opendev.org/74193112:51
*** rlandy has joined #zuul12:52
*** rlandy is now known as rlandy|ruck12:54
fungizbr|ruck: if you mean zuul-jobs, we've previously made choices about that repo on the basis that we would not be publishing it as a collection (disabling certain ansible-lint checks, continuing to use hyphens in role names...)13:01
clarkbhttps://zuul.opendev.org/t/zuul/build/55dcbafa54f04804afd0b073e87fdc27/log/job-output.txt#5305 seems to be breaking nodepool iamge builds. I'm not quite sure yet what layer is missing make but will look into it as I can during the opendev event today (feel free to dig in if you can without interruption)13:21
clarkbI think that is happening in the arm64 builder's assemble call. Likely fallout from building an arm64 python-builder image13:23
clarkbI'm guessing the two images, amd64 and arm64 actually have different sets of preinstalled packages /me working to confirm that now13:24
clarkbbut not sure how to run arm64 container on local machine13:24
fungiyou should be able to do it under qemu, in theory13:26
openstackgerritFabien Boucher proposed zuul/zuul master: gitlab: remove default mutables  https://review.opendev.org/74193813:30
openstackgerritClark Boylan proposed zuul/nodepool master: Install make to build wheels  https://review.opendev.org/74194213:33
clarkbI think ^ will do it (eventually decided just having zuul run the job is probably easiest)13:33
*** saneax has quit IRC13:34
*** saneax has joined #zuul13:35
*** bhavikdbavishi has quit IRC13:43
fungiit's not necessarily the preinstalled packages differing, but that there's a lot more stuff on pypi prebuilt for x86 and not arm, therefore you wind up having to install and build a lot of additional architecture-dependent wheels on the fly from sdist tarballs instead13:44
clarkbah13:45
clarkbya that could explain it, we're actually building wheels on arm but not amd6413:45
openstackgerritFabien Boucher proposed zuul/zuul master: gitlab: update wording patchset to patch_number in getChange  https://review.opendev.org/74050414:05
openstackgerritFabien Boucher proposed zuul/zuul master: gitlab: implement the open pipeline requirement  https://review.opendev.org/74070714:05
openstackgerritFabien Boucher proposed zuul/zuul master: gitlab: implement the merged pipeline requirement  https://review.opendev.org/74070814:05
openstackgerritFabien Boucher proposed zuul/zuul master: gitlab: implement the approval reporter  https://review.opendev.org/74143814:05
openstackgerritFabien Boucher proposed zuul/zuul master: gitlab: update naming in reference pipeline  https://review.opendev.org/74145014:05
openstackgerritFabien Boucher proposed zuul/zuul master: gitlab: support the merge request approval event  https://review.opendev.org/74148314:05
openstackgerritFabien Boucher proposed zuul/zuul master: gitlab: support the approval requirement  https://review.opendev.org/74163714:05
openstackgerritFabien Boucher proposed zuul/zuul master: gitlab: support the labeled event  https://review.opendev.org/74166714:05
openstackgerritFabien Boucher proposed zuul/zuul master: gitlab: support the labels requirement  https://review.opendev.org/74189314:05
openstackgerritFabien Boucher proposed zuul/zuul master: gitlab: support the merge reporter  https://review.opendev.org/74193114:05
openstackgerritFabien Boucher proposed zuul/zuul master: gitlab: remove default mutables  https://review.opendev.org/74193814:05
clarkbI think we've also discovered where arm64 emulation on amd64 VMs is slow: building wheels14:12
corvusclarkb: bummer; before it was like just a few minutes slower, is it much slower now?14:16
corvusi wonder if we could speed that up either with layer caching, or adding a new image that has all our pre-reqs...14:17
corvuslooks like the build took 30m14:17
clarkbcorvus: well it timed out14:18
corvusoh :(14:18
corvusi guess it has a 30m limit?14:18
corvusprevious builds seem to have taken 15-20m14:19
clarkbya, I'm going to bump it to an hour to gather more data14:19
openstackgerritClark Boylan proposed zuul/nodepool master: Install make to build wheels  https://review.opendev.org/74194214:20
clarkbcorvus: we could potentially use some of the wheel cache stuff that ianw and kevinz are working on for testing in the linaro cloud14:21
corvusclarkb: how's that work?14:22
clarkbcorvus: so far just our normal wheel mirrors14:22
fungiwheel build jobs run on arm nodes to natively build arm binary wheels and then we cache those alongside our x86 ones14:22
clarkbI'm not sure what platforms they are planning to build them for yet, but I know debian is one of the images in the linaro cloud so adding it for debian isn't a crazy idea14:23
fungiso i guess the suggestion is to use our prebuilt binary wheelhouse during image builds?14:23
clarkbthen we could have a switch in python-builder's assemble that checks arch and if arm64 adds a pointer to that wheel cache?14:23
fungiwe already use our distro package mirrors during image builds, so this wouldn't be a stretch in opendev i suppose14:24
clarkbfungi: we don't for the containers14:24
fungioh! right, containers14:24
fungimy head was in nodepool image builds, sorry14:24
funginodepool node image builds i mean14:24
corvuswhat decides what wheels get built?14:25
clarkbcorvus: I think it may still be openstack's global requirements list14:25
clarkbbut those pip indexes are additive so we can safely add it and if it has the packages we need we win if it doesn't we build14:25
clarkbunless you have pip814:25
corvusso we'd need to generalize this for opendev by adding new sources14:26
fungithat's been a lingering to do item anyway (make opendev's wheel cache not openstack-specific)14:26
clarkbif that was going to be a long term solution to the problem then ya we'd probably want to have a "this is a list of python things that are generally useful to have wheels for" list14:26
clarkbcryptography and its deps would be high on that list14:26
corvusclarkb: or rather a list of lists?14:27
funginumpy, et cetera14:27
clarkbcorvus: ya I do worry about scaling that particularly for these slow platforms14:27
clarkbit would be easy to have a 48 hour build job14:27
clarkbanother approach could be to work with upstream pacakges to add arm64 wheels to pypi14:27
fungiit can also be parallelized, no reason those all have to be built in a single job14:27
fungibut yeah, getting arm wheels into pypi would help lots of people beyond opendev14:28
zbr|ruckwhile I find a wheel cache very useful,  i need to warn others that the common list is more like >200 packages, and likely a couple of GB in size.14:28
zbr|ruckpackages, not files, multiply by flavours.14:29
clarkbzbr|ruck: yes, we've been running a wheel mirror cache for years14:29
clarkbits just been x86 specific so far14:29
fungizbr|ruck: well, the job in question optimizes by only caching wheels that need to be built, and skips those which are already available on pypi (as pure python or manylinux1 for example)14:29
clarkbI'm not super concerned about the size of the data as much as the cost to produce it, but we can also worry about that as we hit those problems14:30
zbr|ruckarm and ppc is clearly making the issue more complex14:30
clarkbwell we don't need to worry about ppc, at least not yet14:30
clarkb"Building wheels for collected packages: PyYAML, PrettyTable, voluptuous, openshift, bcrypt, cryptography, pynacl, netifaces, dogpile.cache, cffi, MarkupSafe, ruamel.yaml.clib" thats our wheel build list for nodepool on arm64 fwiw14:31
fungiif anybody knows people who work on openshift, maybe they'd be an easy one to get releasing arm wheels on pypi soon14:32
corvusgiven entries like crypto, maybe we would immediately benefit from adding the openstack cache?14:33
clarkbit was processing those in that order and everything before bcrypt was a few seconds. bcrypt took about a minute then cryptography was running for almost 10 minutes when the job timed out14:33
clarkbcorvus: yes, that was my point14:33
clarkbbut it doesn't look like we have the arm64 stuff up and running yet14:33
clarkboh wait I know I have to look at the linaro mirror14:34
corvusi'm guessing bcrypt is transitive from cryptography too14:34
fungithough the wheel build jobs build specific versions pinned in openstack's central constraints list, so might lag behind latest releases of stuff regularly14:34
fungihttps://static.opendev.org/mirror/wheel/debian-10-aarch64/14:35
clarkband I'm guessing the NAT issues there persist because I can't hit the mirror directly14:35
clarkbfungi: thanks14:35
clarkbmaybe we should add the serving of all the wheel caches to all the mirrors even if they dno't directly host that arch in that provider14:36
clarkbsince cross platform builds are a thing (as nodepool is trying to do)14:36
fungiseems reasonable to me. multi-arch clouds are a thing. but probably better to discuss that in #opendev14:37
clarkbcorvus: one potential issue here is we've gnerally build these wheels for distro python. Taking the example we've got here our debian 10 wheel mirror builds for debian python2.7 and debian python3.7. Our python-base images use python on debian (not debian python)14:45
corvusis that a different kind of wheel?14:45
clarkbI don't know if we should expect python3.7 wheels build for debian python to work with python3.7 on debian14:45
clarkbcorvus: not a different kind of wheel, but wheels built for slgihtly different targets14:46
clarkbit may be the case that the targets are similar enough to each other thing things just work14:46
corvusclarkb: ok.  it sounds like we have some steps we can take to experiment, but quick sanity check: is this easier/better than inserting a new image into the stack that just builds nodepool dependencies?14:47
corvuseg nodepool -> nodepool-dependencies -> python-base14:48
clarkbI think the advantage to using a mirror cache like that is we'd keep the build deps reasonably fresh on every build. THe advantage to a new image layer is it is simple with the existing tooling and avoids the target platform mismatch, but we'd not be rebuilding them every time14:48
corvusclarkb: right, but we can rebuild them daily and on-demand14:48
clarkbfor now that is probably fine and have nodepool-dependencies run a daily job to update14:49
corvuswe do have a system for speculative dependency building14:49
clarkbinterestingly my latest image build job has decided to build pynacl before bycrypt. It too is slow14:49
corvus(also, we could still probably build new things in our nodepool image itself if a dependency changed)14:50
clarkbcorvus: that would likely automatically happen, basically if the dep isn't there it would build itb eacuse that is how pip would handle the situation14:50
corvusthen the dependencies layer just becomes a cache14:52
clarkbpynacl is a manylinux wheel. manylinux publishes an aar64 image: https://quay.io/repository/pypa/manylinux2014_aarch64?tab=info I wonder if we could work with pypa to switch their default build tooling/docs to buildx instead of regular docker build then people would start to build arm and ppc wheels by default if using manylinux15:01
clarkbthat is likely way out of scope here, but does point to an advantage of the manylinux system: if it can be convinced to do more we get more out of it15:01
fungii think you're going to find quite a few in that situation15:03
clarkbhttps://github.com/pypa/manylinux/issues/84 raspi to the rescue15:06
clarkbwe could try https://www.piwheels.org/15:06
clarkbthe latest raspi is arm64 and maybe things will work?15:06
fungihah, i was just responding on a piwheels issue over the weekend15:08
clarkbno their pacakges are all 32bit15:08
clarkband no python3.815:08
clarkbhttps://www.piwheels.org/simple/cryptography/ for example15:08
clarkbalso my idea to builx has received a thumbs down: https://github.com/pypa/manylinux/issues/84#issuecomment-514585688 I wish the system made you express why you do't like an idea :/15:09
*** weshay_ is now known as weshay|ruck15:12
fungisomeone mentioned buildx in that issue a year ago15:12
clarkbfungi: ya thats my link above, it got a thumbsdown15:12
clarkbalso pynacl build is approaching 30 minutes15:12
*** zbr|ruck is now known as zbr|rover15:13
fungiahh, yeah i thought you meant you had suggested in that issue it too15:13
clarkbno someone else had the same idea and was given negative feedback with no actual reason for it15:13
clarkbmaybe the issue is it takes 30 minutes or more to build pynacl15:13
*** bhavikdbavishi has joined #zuul15:14
*** hamalq has joined #zuul15:15
zbr|roverclarkb: fungi: need review on cmd: https://review.opendev.org/#/c/740733/ and preferences https://review.opendev.org/#/c/739482/15:16
zbr|roveri updated them over the weekend, hopefully they are ok now.15:16
zbr|roveri wonder if reviewers would appreciate if I include screenshot in review message, to highlight UI area affected.15:26
clarkbzbr|rover: for the cmd change I wonder why make it a tooltip and not just a table filed?15:28
clarkbI wouldn't think to hover for that info but if it said 'cmd: this is the cmd' that would be helpful?15:28
clarkbthe job with the hour timeout timed out building pynacl15:32
clarkbso ya I think probably should start looking at another layer. I'm not sure I'll be able to sort that out in the near future. Distracted by opendev event and have a few things I need to do today15:33
corvusclarkb: should we try using the openstack arm mirrors as well?15:35
fungiwe'd need to switch to python3.7 or get some 3.8 wheel builds going there15:35
clarkbya we could try switching to 3.7 (its easy) and then use the mirror to see how that does15:36
corvuswe can "switch" experimentally right?15:36
clarkbcorvus: yes15:36
fungiright now they're building for debian buster, which doesn't have 3.8 so they're 3.7 wheels15:36
clarkbits just a change of the parent image name15:36
clarkbwe should update our non arm mirrors to serve that content too, but I'll write a change to get it from the arm mirror15:37
*** bhavikdbavishi1 has joined #zuul15:37
corvusk, i can start on a new image in a bit15:37
*** bhavikdbavishi has quit IRC15:39
*** bhavikdbavishi1 is now known as bhavikdbavishi15:39
*** marios is now known as marios|out15:48
*** marios|out has quit IRC15:49
openstackgerritClark Boylan proposed zuul/nodepool master: Test nodepool build with opendev wheel cache  https://review.opendev.org/74197315:51
clarkbI think I got the conditional correct there15:51
corvusclarkb: out of curiosity, do you actually need a conditional?15:53
clarkbcorvus: I don't think so because pip will check the arch types on those wheels and see they are all wrong when running on x86, but I thought it was nice to be explicit. At least until we decide we are comfortable with not being explicit15:54
clarkbI guess for testing it may reduce a rtt15:54
clarkbya I think we can simplify that to just copy the pip.conf always and let pip sort out what wheels are appropraite for the given platform15:55
fungii agree we should probably be relying on the cache/mirror for both arches for consistency15:56
openstackgerritMerged zuul/zuul-jobs master: add-build-sshkey: Ensure .ssh exists, enable admin authorized_keys  https://review.opendev.org/74035015:57
*** sshnaidm is now known as sshnaidm|afk15:57
clarkbI think the risk here is ipv4 has been flaky in that linaro cloud recently15:57
*** armstrongs has joined #zuul15:58
clarkbbut if we get the other mirrors hosting the same content we can point at the mirror local to the job and get better reliability15:58
clarkband then it really shouldn't matter if we just set the values15:58
fungiyeah, i don't see a good reason to make the mirrors architecture-specific there15:58
*** hamalq has quit IRC16:01
*** hamalq has joined #zuul16:01
*** hamalq_ has joined #zuul16:07
*** holser has quit IRC16:07
*** holser has joined #zuul16:08
openstackgerritClark Boylan proposed zuul/nodepool master: Test nodepool build with opendev wheel cache  https://review.opendev.org/74197316:11
*** hamalq has quit IRC16:11
*** holser_ has joined #zuul16:11
*** yoctozepto has quit IRC16:12
*** yoctozepto has joined #zuul16:13
*** holser has quit IRC16:14
*** nils has quit IRC16:21
openstackgerritClark Boylan proposed zuul/nodepool master: Test nodepool build with opendev wheel cache  https://review.opendev.org/74197316:30
zbr|roverclarkb: cmd change is consitent with current implementation of other fields, that is why it does not have a visible label.16:31
zbr|roverit is not really a problem and tbh I do not care much about the tooltip, I care more to about using <pre> to display it.16:31
*** jcapitao has quit IRC16:31
zbr|roverbecause in some cases cmd can be 4-10 multiline bash script.16:31
zbr|roverwe should also try to avoid cluttering the UI with repetitive info that does not add much value, like label.16:33
zbr|rovertooltips are quite an useful way to provide more info16:34
zbr|roverwho was complaining about ansible-lint being slow? https://review.opendev.org/#/c/741897/ makes it 10x faster.16:36
zbr|roverwell, real value is around 9x, but rounded up for marketing purposes :D16:37
*** jlk has quit IRC16:43
*** jpena is now known as jpena|off16:45
*** bhavikdbavishi has quit IRC17:24
*** bhavikdbavishi has joined #zuul17:25
clarkbcorvus: it seems that my change helped, we only needed to build openshift, dogpile.cache and ruamel.yaml.clib wheels. That took just under 7 minutes. However on the python-base side it has decided that it needs to build those packages anyway so something with the wheel caching there isn't working17:31
*** armstrongs4 has joined #zuul17:31
clarkbit fails beacuse there is no gcc on python-base side17:31
corvusclarkb: hrm, why does python-base build stuff?17:32
corvusi thought the idea was to only install previously built things (from python-builder) into python-base17:32
clarkbthat I haven't figured out yet. I'm guessing either we don't copy the arm wheels properly between the builder and base side or we've got the wrong wheel type somehow even though the builder side grabbed them17:32
clarkbhrm I wonder if it is related to the pip.conf? on the x86 side it says  Stored in directory: /output/wheels/wheels/5f/09/cf/2b1aa8371c071fa89518ac0bbda1b8cca4e65b6e2538af4192 for the wheels it is building but I don't see that for arm side17:34
clarkboh wait maybe it does hrm that makes it even more confusing17:35
clarkbCreated wheel for ruamel.yaml.clib: filename=ruamel.yaml.clib-0.2.0-cp37-cp37m-linux_aarch64.whl size=137954 sha256=42e6e1cb1e9ebd5d809244c7b20134212c95f22f096b540e5a18818d48a1202d and Stored in directory: /output/wheels/wheels/fb/6d/cd/41c880c9ec9a01bee4c222b8bda87ea703b35ae591b9c9197517:36
corvusclarkb: can you link to that?  i can't find that line17:36
clarkbcorvus: https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_c80/741973/3/check/nodepool-build-image/c80bc21/job-output.txt that file (buildest hasn't reported yet)17:36
corvusclarkb: thx, i was looking at wrong build :/17:37
clarkbcorvus: reading the log around where it failed it is finding the openshift wheel we built and cached I think17:39
clarkbas well as many wheels that were arch independent from pypi that we cached17:39
clarkbI wonder if it is something about that wheel in particular that it doesn't like for the current platform17:39
clarkbI've got to pop out for a bike ride now otherwise it will be surface of the sun temps when I do it, but this is a curious behavior17:39
corvusclarkb: i agree that it looks like the builder was happy with the downloaded version of cryptography, that wheels were copied over to the base, that the base was happy with the openshift wheel it built, but thought it needed to build cryptography18:11
corvusclarkb: oh -- i have an idea18:11
corvusclarkb: maybe it doesn't copy the wheel into the wheel cache if it downloads it; it only ends up there if it builds?  so maybe we need to add the pip.conf to the base image too?18:12
corvusclarkb: i'll push up a new ps with that18:12
openstackgerritJames E. Blair proposed zuul/nodepool master: Test nodepool build with opendev wheel cache  https://review.opendev.org/74197318:13
fungian alternative might be if you could bindmount a shared wheel cache into each layer18:14
fungier, pip cache i mean18:14
fungi(pip caches things it downloads)18:14
corvusfungi: we could copy the cache from the builder18:35
*** harrymichal has joined #zuul18:41
*** armstrongs has quit IRC18:49
*** armstrongs4 has quit IRC18:49
*** bhavikdbavishi has quit IRC18:51
*** tosky has quit IRC18:57
corvusi'm going to create a 13.x branch in zuul so we can make the 3.x point release19:33
corvusi don't think we need to do the same for nodepool?  i think we can probably just tag master as the next 3.x in nodepool19:33
corvusi'll name it stable/3.x19:34
corvusand use 3.19.0 as the branch point19:35
fungithat seems reasonable, nodepool doesn't have breaking changes on master19:35
fungialso i assume (from subsequent comments) you meand a 3.x branch not 13.x19:37
fungier, meant19:37
corvusyep19:37
fungicool, just making sure19:37
corvusremote:   https://review.opendev.org/742013 Update .gitreview for 3.x branch19:37
corvus(the bot doesn't announce changes on non-master branches for zuul)19:38
corvusremote:   https://review.opendev.org/742015 Require kazoo 2.8.019:39
*** vishalmanchanda has quit IRC19:41
clarkbcorvus: oh interesting idea19:41
corvusclarkb: oh i failed at that change, sorry19:42
openstackgerritJames E. Blair proposed zuul/nodepool master: Test nodepool build with opendev wheel cache  https://review.opendev.org/74197319:45
*** kmalloc has quit IRC20:03
clarkbzuulians https://review.opendev.org/741820 is a small change to our ensure-devstack role to help run it in a more production like manner. Nodepool seems to show it working https://review.opendev.org/74182120:22
clarkbcorvus: your change to also set the mirror in base seems to have failed with the same error20:24
clarkbmaybe we can run it with pip -vvv20:24
clarkbjust thinking that may give us a clue as to why pip is ignoring the cached wheels we copied in20:24
corvusclarkb: i'm confused -- current error still looks like i don't know how to bash20:25
corvusclarkb: https://zuul.opendev.org/t/zuul/build/b1f5c34ac0404239a4d1858434ea079a/log/job-output.txt#5261 ?20:26
clarkbcorvus: https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_3ce/741973/5/check/nodepool-build-image/3ce6cb2/20:26
clarkbI'm looking at the jobs before the buildset reports20:27
corvusclarkb: are we sure that pip.conf was installed?20:27
corvusi guess we should have put an echo in there20:28
clarkboh it may not be20:28
corvusi'm not sure we'd see one way or the other20:28
clarkbits pip.conf.arm64 not pip.conf in /output20:29
clarkbthe -f is failing as a result I think20:29
corvusok, i'll fix once more20:29
clarkbneed to update the cp too20:29
*** y2kenny has joined #zuul20:30
openstackgerritJames E. Blair proposed zuul/nodepool master: Test nodepool build with opendev wheel cache  https://review.opendev.org/74197320:30
corvusclarkb: how's that ?20:30
clarkbya that looks right20:31
openstackgerritMerged zuul/zuul-jobs master: Enable tls-proxy in ensure-devstack  https://review.opendev.org/74182020:49
avassthe s3 log upload role should be ready: https://review.opendev.org/#/c/741809/20:58
corvusavass: is the python module copied from gcs?20:59
corvus(or swift?)21:00
avasscorvus: should be gcs, but I noticed I might have grabbed pieces from both21:01
avassdo they differ a lot?21:02
corvusnope21:02
corvusthey should be pretty close, and identical if you strip out the cloud-specific parts21:02
corvusjust gcs is a simpler starting point21:02
avassI think the python module could be swift and added the path where gcs adds 'index.html' to the index file21:02
*** y2kenny has quit IRC21:02
corvusdo you think we should try symlinking?21:03
avassthat or tobiash idea of trying to combine them into one role21:03
avassI don't know how zuul handles symlinking if a project imports only one of the roles21:03
corvusoh, that's an interesting idea21:03
corvusmaybe we should try to start with that21:04
avasscorvus: yeah, I can take a look at that later. Maybe sticking to zuul_log_container instead of zuul_log_bucket and more generic names is a good idea then :)21:15
avassI'm planning on adding a role for azure as well. it should be possible to test that in ci since microsoft has supplied an azure storage emulator image: https://hub.docker.com/r/microsoft/azure-storage-emulator/21:16
tobiashcorvus: are you aware of https://storyboard.openstack.org/#!/story/2007897 ? I think that might indicate a misunderstanding of gerritci users.21:17
avassoh, and I just found https://github.com/fsouza/fake-gcs-server for testing gcs :)21:18
corvustobiash: no i haven't seen that, thanks21:23
clarkbcorvus: latest failure in the nodepool image build was due to a ppa error before it got to pypi things. I think we need to recheck it once we can21:40
clarkbI need to pop out for a few now but will be back in a bit to continue chekcing on that21:40
openstackgerritJames E. Blair proposed zuul/nodepool master: Test nodepool build with opendev wheel cache.  https://review.opendev.org/74197321:42
corvusclarkb: i just edited commit message to speed that up21:42
*** holser has joined #zuul21:48
*** holser_ has quit IRC21:50
clarkbcorvus: I think it may be working now22:13
clarkbso that was it, the cached wheels incorporate info about their origin22:14
clarkbhttps://zuul.opendev.org/t/zuul/stream/a67e0f3763ee452eb83207bfce7eeda0?logfile=console.log for the live stream22:14
fungiahh, yep, pip's download cache is keyed by url22:19
fungii forgot about that22:20
clarkbour assemble script ends up installing things twice22:30
clarkbI think because we install all the wheels first then the software itself, and when we install the software it uninstalls things then installs for some reason? That may be something we can optimize by streamlining, but I have another very early morning tomorrow so I'll look at that closer tomorrow22:30
clarkbok the ppa thing happened again and it is actually after the installs. I got confused because its nodepool-builder not python-builder but I read it as python-builder and got the relative phase step wrong22:33
clarkbI'm guessing this is related to trying to install the arm package on debian via our ppa, it works installing the x86_64 package via our ppa on debian but maybe something about debian?22:33
clarkbianw: ^ maybe that is familiar to you?22:34
clarkbianw: https://63964e6d65ae1ec0ac34-67674e607a46c69293c37e4affbebdc2.ssl.cf2.rackcdn.com/741973/7/check/nodepool-build-image/a67e0f3/ the ppa vhd-util failure there22:34
ianwumm, interesting, no that's not familiar but possible, i will have a look22:35
ianw2020-07-20 22:32:17.102743 | ubuntu-bionic | #19 37.57 E: Unable to locate package vhd-util22:36
clarkbya I checked earlier and it seemed we had arm64 packages22:36
clarkbbut maybe we need to select the repo more specifically?22:36
clarkblike maybe the ppa add is adding x86?22:37
ianwhrm, maybe i did add arm64 builds for it, not sure i remember doing that though.  however we don't need that for arm64, because we're not building vhd images anyway22:37
ianwwe should probably put it behind a if22:37
ianwyeah, the arm64 has a "X" against it, it didn't build.  maybe i did try (dates are 2019-10 ... seems like ancient history!!!!)22:38
clarkbgenerally I think it would be good for nodepool's arm images to support vhd if that is possible22:39
clarkbsince other users may have it running against a vhd cloud. Though if that isn't practical I can see it being a known limitation22:39
clarkbeg document that the arm image can't build vhd images and live with it22:39
ianwso my notes on 2019-10-16 say i was updating vhdutil for bionic22:41
ianwso that would have been when we were initially looking at cutting over from the older hosts22:41
ianwi must have ticked the arm64 box and it tried when i uploaded the bionic builds, but i have no record of me actually trying to fix it22:42
ianwMissing build dependencies: gcc-multilib22:42
ianwi take that back actually, it's even older22:43
ianwFinished on 2018-02-2022:43
ianwi'll take a look today, see what's up22:44
clarkbthanks! feel free to recheck that change ir update it if necessary22:45
*** holser has quit IRC23:12
*** sgw1 has quit IRC23:16
*** harrymichal has quit IRC23:24
*** sgw1 has joined #zuul23:25
*** holser has joined #zuul23:27
*** rlandy|ruck has quit IRC23:33

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!