Tuesday, 2020-03-24

*** tosky has quit IRC00:01
*** zxiiro has quit IRC00:10
*** jamesmcarthur has joined #zuul00:27
*** mattw4 has quit IRC00:28
*** jamesmcarthur has quit IRC00:33
*** sugaar has quit IRC01:02
*** reiterative has quit IRC01:03
*** sugaar has joined #zuul01:05
*** reiterative has joined #zuul01:06
*** mattw4 has joined #zuul01:13
*** Goneri has quit IRC01:13
*** mattw4 has quit IRC01:18
*** rlandy has quit IRC01:21
y2kennyIs node-attributes only applicable to openstack driver?01:53
*** jamesmcarthur has joined #zuul02:03
*** swest has quit IRC02:57
*** jamesmcarthur has quit IRC03:02
*** jamesmcarthur has joined #zuul03:03
*** jamesmcarthur has quit IRC03:06
*** jamesmcarthur_ has joined #zuul03:06
*** bhavikdbavishi has joined #zuul03:11
*** swest has joined #zuul03:12
SpamapSy2kenny: yes.03:15
*** bhavikdbavishi has quit IRC03:19
*** bhavikdbavishi has joined #zuul03:28
*** jamesmcarthur_ has quit IRC03:47
*** jamesmcarthur has joined #zuul03:49
*** jamesmcarthur has quit IRC03:54
*** jamesmcarthur has joined #zuul04:18
*** jamesmcarthur has quit IRC04:25
*** bhavikdbavishi has quit IRC04:43
*** jamesmcarthur has joined #zuul04:44
*** bhavikdbavishi has joined #zuul04:47
*** jamesmcarthur has quit IRC05:06
*** sgw has quit IRC05:25
*** bhavikdbavishi has quit IRC05:26
*** bhavikdbavishi has joined #zuul05:26
*** evrardjp has quit IRC05:36
*** evrardjp has joined #zuul05:36
*** y2kenny has quit IRC05:40
*** saneax has joined #zuul06:20
*** jamesmcarthur has joined #zuul07:08
*** bhavikdbavishi has quit IRC07:09
*** jamesmcarthur has quit IRC07:12
*** dpawlik has joined #zuul07:16
*** bhavikdbavishi has joined #zuul07:56
*** jcapitao has joined #zuul07:57
*** avass has joined #zuul08:27
*** tosky has joined #zuul08:41
*** sshnaidm|pto is now known as sshnaidm08:48
*** jpena|off is now known as jpena09:04
*** bolg has joined #zuul09:10
*** harrymichal has joined #zuul09:17
*** panda|off is now known as panda09:21
*** bolg has quit IRC09:34
*** bolg has joined #zuul09:36
*** bolg has quit IRC09:36
openstackgerritJan Kubovy proposed zuul/zuul master: WIP: Store unparsed branch config in Zookeeper  https://review.opendev.org/70571610:25
*** avass has quit IRC10:41
*** avass has joined #zuul11:10
*** dpawlik has quit IRC11:33
*** dpawlik has joined #zuul11:34
*** rlandy has joined #zuul11:40
*** bhavikdbavishi has quit IRC11:58
*** jcapitao is now known as jcapitao_lunch11:59
*** jpena is now known as jpena|lunch11:59
*** rfolco has joined #zuul12:02
*** bolg has joined #zuul12:28
*** bhavikdbavishi has joined #zuul12:41
*** jpena|lunch is now known as jpena13:01
*** sgw has joined #zuul13:04
*** hashar has joined #zuul13:05
zbrdo we have any reason not to continue with https://review.opendev.org/#/c/677971/ ?13:12
*** jcapitao_lunch is now known as jcapitao13:25
mordredzbr: just left comments13:31
*** avass has quit IRC13:34
zbrmordred: thanks, so mostly not against it.13:36
mordredno - just think there's some things we can do/update to make it work more better13:36
zbrtbh, the python version is not so important but distro + ansible version used by zuul are, because these can have a relevant impact on how it behaves13:36
zbrsometimes people forget that zuul may run a different ansible version that they usually do13:37
*** hashar has quit IRC13:37
mordredtotally - although I think ansible version is already there. is there a behavior difference people should know about related to the executor distro though?13:37
zbrprobably not, let me clean it and have another look at it.13:42
*** harrymichal has quit IRC13:44
*** y2kenny has joined #zuul13:55
*** Goneri has joined #zuul13:57
*** bhavikdbavishi has quit IRC13:59
y2kennyI just want to double confirm, is node-attributes only applicable to openstack nodepool driver?  If that's the case, it explains my observation of the scheduler using the wrong executor to reach a node.14:01
y2kenny(the node I created was using static driver)14:02
*** bolg has quit IRC14:11
Shrewsy2kenny: yes, openstack driver only14:13
y2kennyShrews: Are there any plans to expand that as a general thing?  Without this, the executor zone concept wouldn't work for other drivers14:15
y2kenny(as far as I understand.)14:16
*** hashar has joined #zuul14:16
*** bolg has joined #zuul14:18
*** harrymichal has joined #zuul14:21
*** jamesmcarthur has joined #zuul14:23
Shrewsy2kenny: no current plans that i'm aware of. i don't see any immediate reason to not support that in all drivers14:24
Shrewsi suppose at the time we added it, we only needed it for openstack14:24
mordredyeah - it seems like a good thing to support everywhere14:26
Shrewsi think i could code something up fairly quickly. lemme see how much effort that is14:27
Shrewsoh, i smartly made it a common attribute. each driver just needs to read it from the config. this should be easy14:34
mordredShrews: good job!14:41
Shrewsof course, the static driver has to be difficult b/c it's so different14:54
Shrewsugh14:54
mordredShrews: day drinking?14:55
*** y2kenny has quit IRC14:59
Shrewsmordred: i wish15:06
openstackgerritDavid Shrewsbury proposed zuul/nodepool master: Support node-attributes in static driver  https://review.opendev.org/71467215:08
Shrewsaaaaaand y2kenny is gone15:08
Shrewsmordred: but there it is ^^^15:08
Shrewsoh, that's missing something15:09
*** mattw4 has joined #zuul15:10
Shrewsoh, nope. i think that's right15:12
Shrewsmordred: also, i think node-attributes is already supported in all the other drivers, we just don't have it documented. i need to verify that first, though15:14
Shrewsbut that can be done separately15:14
clarkbwhat do the node attributes do?15:15
clarkbare they inventory host vars in the end?15:15
fungisounds like they're used for zoning executors/nodes?15:15
Shrewsjust arbitrary data we set in the node zk data that zuul can do whatever it wants with. right now i think it's just used for zones15:16
Shrewsi wanted something flexible for similar new zuul features that didn't require updating nodepool to support15:16
Shrewsi don't think any of it is passed through at all15:17
Shrews(as host vars, that is)15:18
clarkbgotcha15:18
*** bhavikdbavishi has joined #zuul15:24
tobiashI just found a funny way of leaking jobs in the executor. Restarting the scheduler will leak all paused jobs in the executors (not nodes) if not all executors are restarted as well.15:33
corvustobiash: i would think that we would lose the gearman job and that should take care of it15:34
tobiashcorvus: that doesn't seem to be the case. The executor just sits there and waits for the resume that will never happen.15:36
tobiashhowever that's not a huge problem15:36
corvusthere's a chain: scheduler -> gearman server -> executor, and if that's broken, the job should abort15:36
tobiashexcept for our graceful draining script that will wait forever15:36
tobiashdoes the executor get an event from gearman about that? (actually it disconnects and reconnects gearman if the scheduler restarts)15:37
tobiashif that's possible we could react on a gearman disconnect in the executor and just drop all jobs15:38
corvustobiash: hrm, i may be remembering incorrectly; the worker may not get notified on a client disconnect, which means it will only discover that it's gone when it tries to send more data, which a paused job won't do15:42
corvusthat would explain the behavior15:42
tobiashyes15:43
corvustobiash: we could have the executor send a "still paused" data packet every 5 minutes :)15:44
tobiashcorvus: we could react on https://opendev.org/zuul/zuul/src/branch/master/zuul/lib/gearworker.py#L9615:44
tobiashand throw away all jobs in this case (as we loose every job on a disconnect)15:44
corvustobiash: but that's only if the executor disconnects15:45
tobiashright, which only covers some scheduler restarts15:45
corvusi thought this was in the case that the scheduler only disconnects15:45
*** zxiiro has joined #zuul15:46
tobiashthen the only way I see is the "still paused" heartbeat15:46
tobiashin our case the gearman server is started together with the scheduler15:46
corvus(opendev uses the embedded gear server, so *everything* disconnects when we restart the scheduler, which is probably why we don't see this; but iirc, you run a separate geard)15:46
corvustobiash: wait, do you restart your gear server when you restart your scheduler?15:46
tobiashyes15:46
corvusoh, that's different.  1 sec.15:46
corvustobiash: there's a handleDisconnect callback that the worker should get15:47
tobiashthat's not handled in the executor :)15:47
tobiashI guess we handle that nowhere in zuul15:48
corvustobiash: at least not anymore15:48
corvusit looks like we lost it somewhere between 2.5 and now15:49
*** jamesmcarthur has quit IRC15:49
tobiashI'll see if I can re-plumb that through15:49
corvusoh, it may only ever have been on the client side15:49
corvuswe may never have had it on the server side15:49
corvustobiash: take a look at ZuulGearmanClient in executor/client.py15:50
tobiashyes, just saw it on merge and execute client15:50
corvusi think we'll need a subclass of Text/BinaryWorker like that for the executor (though it'll be a little trickier there because of the way the classes are set up)15:50
tobiashcorvus: hrm, seems like handleDisconnect is not part of the inheritance chain of TextWorker15:56
tobiashhandleDisconnect is defined in Client, but TextWorker only contains BaseClient15:57
*** jamesmcarthur has joined #zuul15:58
corvustobiash: weird -- because this should be in the hierarchy: https://opendev.org/opendev/gear/src/branch/master/gear/__init__.py#L84216:00
tobiashyeah I just saw it's called, but not down there defined in the hierarchy16:02
tobiashI guess this will just throw an exception16:02
tobiashbut it also means that adding it should work16:02
*** jcapitao is now known as jcapitao_afk16:07
*** jamesmcarthur has quit IRC16:09
*** mattw4 has quit IRC16:18
*** mattw4 has joined #zuul16:19
*** jamesmcarthur has joined #zuul16:21
*** armstrongs has joined #zuul16:25
*** jamesmcarthur has quit IRC16:26
*** jcapitao_afk is now known as jcapitao16:32
*** harrymichal has quit IRC16:37
*** armstrongs has quit IRC16:38
*** tflink has quit IRC16:43
*** tflink has joined #zuul16:43
tobiashcorvus: I think that sould move it into the right place: https://review.opendev.org/714709 Move handleDisconnect into BaseClientServer16:48
*** tflink has quit IRC16:49
*** tflink has joined #zuul16:50
*** y2kenny has joined #zuul16:51
y2kennyShrews: sorry I had to head to the office to get some equipments.  Thanks for the quick patch.16:54
y2kennyper the documentation here, I need to set the node-attributes if I am to use the zone feature.  For example,  if I have a nodepool inside a private cluster (no external IP for the nodes) and an executor in this private cluster, I would want the scheduler only use the private-cluster executor to talk to the nodes.16:57
*** mattw4 has quit IRC16:57
*** mattw4 has joined #zuul16:58
y2kennyI tried this feature by manually launching a single node in the private cluster and have the nodepool provide it via a static driver16:58
y2kenny(sorry... the document here: https://zuul-ci.org/docs/zuul/discussion/components.html#executor)16:59
y2kennywhat I noticed is that the scheduler tries to reach the node in the private cluster via another executor I have outside of the private cluster and the node is unreachable16:59
y2kennyShrews: does a similar patch needs to be applied for the Kubernetes driver as well for the k8s driver to support zone?17:03
y2kennyShrews: also, should I go and vote as an interested user for the patch you just made?17:12
*** sshnaidm is now known as sshnaidm|afk17:13
fungiy2kenny: absolutely! and if you get a chance to skim the implementation and spot possible bugs or things which you think might work better another way, please leave a comment and point them out17:21
y2kennyfungi: ok, will do.17:22
fungiopendev's code review platform is configured to allow anyone to vote and comment on changes, because we host projects which want users who provide feedback ;)17:23
y2kennyopendev looks pretty awesome.  I didn't come across it until diving into Zuul.17:24
y2kennyI think it's a pretty good alternative to GitHub and looks like it uses all open source components.17:24
openstackgerritTobias Henkel proposed zuul/zuul master: Stop jobs on gearman disconnect  https://review.opendev.org/71472217:25
tobiashcorvus: I think this should fix it, but no idea how to test that yet ^17:25
clarkbtobiash: could have a job that starts a process that sits and waits, then disconnect gearman and check ps to see the processes are cleaned up?17:27
clarkb(or will that not properly check the state in the executor itself?17:27
tobiashclarkb: I guess I'd have to shutdown the gearman server during the test17:27
clarkbtobiash: likely es17:28
fungiy2kenny: it's a work in progress, but the idea is that open source projects who value relynig on open source tools for their contributor workflows but lack the resources to run all those services themselves can collaborate with other like-minded projects to operate a platform which meets their collective needs17:28
tobiashit's gonna be interesting if it's possible to stop the gear server without breaking the test case :)17:28
*** hashar has quit IRC17:29
*** evrardjp has quit IRC17:36
*** evrardjp has joined #zuul17:36
*** ianychoi has quit IRC17:45
*** yolanda has quit IRC17:45
*** mgoddard has quit IRC17:45
*** openstackstatus has quit IRC17:45
*** dmsimard|off has quit IRC17:45
*** ianychoi has joined #zuul17:46
*** yolanda has joined #zuul17:46
*** irclogbot_3 has quit IRC17:47
*** openstackstatus has joined #zuul17:48
*** ChanServ sets mode: +v openstackstatus17:48
Shrewsy2kenny: Well, like I said in the scrollback, I believe node-attributes should already work with the rest of the drivers. I'll be putting up a change shortly that validates that and also updates the docs to reflect it.17:48
y2kennyShrews: Thanks!17:48
*** mgoddard has joined #zuul17:49
Shrewsy2kenny: it didn't work for the static driver because it's a different beast from the other drivers17:49
*** irclogbot_2 has joined #zuul17:49
y2kennyShrews: ah ok.  I have no idea how the drivers work under the hood (I assumed they are all somewhat the same until I read what you said about pre-launching having different behaviour.)17:51
y2kennyQuick question, do you guys have some stats on Zuul usage around the OpenStack project?  (I am trying to pitch my management.)  I tried to find the slides from the Gerrit User Summit but looks like it's not posted yet.17:57
clarkby2kenny: ya we publish things occasionally. I think soem official numbers may have ended up in the OSF annual report17:58
clarkby2kenny: let me see ifI can find a link17:58
y2kennysome numbers on number of tests and nodes for size and scale would be very useful.17:58
clarkby2kenny: https://www.openstack.org/foundation/2019-openstack-foundation-annual-report grep for "Zuul Project Update"17:59
clarkby2kenny: there is a small blurb in there about openstack's use of zuul and leboncoin's17:59
clarkby2kenny: also the articles linked from https://zuul-ci.org/users.html18:00
clarkbwe can dig up more specifics if it helps too, just let us know18:00
clarkb(its usually a matter of running queries against graphite, which you can do too)18:00
fungiy2kenny: but also we maintain some real-time graphs like http://grafana.openstack.org/d/T6vSHcSik/zuul-status?orgId=118:01
y2kennyunfortunately I am not familiar with graphite.18:01
y2kennyCan you provide a few of these figures?18:02
y2kenny1) number of components server by OpenStack's CI18:03
y2kenny2) number of build nodes18:03
y2kenny3) number of test nodes18:03
y2kenny4) number of build per week18:03
y2kenny5) number of tests per week18:03
*** jcapitao has quit IRC18:03
fungiahh, so more of a sizing thing18:04
y2kenny6) active developers contributing to the workload18:04
y2kennyI think Monty has some of those figures in his slides18:04
fungiwe peak at a little over 1k job nodes at the moment18:04
y2kennyI just can't find the slides :)18:04
fungiin use simultaneously18:04
*** jamesmcarthur has joined #zuul18:04
clarkbmordred: ^ you have those someplace you can share easily from?18:04
fungiwe have 12 executors and 8 additional mergers to support those18:05
fungibuild nodes and test nodes are indistinguishable for opendev at least, i'm not sure how you're differentiating those terms18:05
y2kennyfungi: understood... I think that make sense for your use case.  I differentiate them mostly for my usecase.18:06
fungiy2kenny: well, my point was more that i don't know what you mean by those terms18:06
corvusy2kenny: for 1 do you mean git repos?18:06
openstackgerritMerged zuul/zuul-jobs master: Trim whitespace from uri password for docker promote  https://review.opendev.org/71450618:06
y2kennyfungi: i.e., we generally wouldn't want a baremetal node with GPUs for testing to spend time on compiling things.  That's the reason we differentiate.18:07
fungii took #1 to be how many separate zuul service instances (executors and mergers) we were running18:07
clarkbhttps://graphite01.opendev.org/render/?title=Build%20Nodes%20Used%20Per%20Day&from=20200101&until=now&target=alias(summarize(sumSeries(stats.gauges.nodepool.label.*.nodes.in-use),%20%271d%27),%20%27Nodes%20In%20Use%27)&height=800&width=1280 is an example graphite query that answers 2/3 on a daily basis18:07
clarkbnote you can change the date range there and also ask for json output for hard numbes18:07
y2kennycorvus: for 1, I meant openstack components that interact with each other (it's been awhile sense I did openstack, but I would say Nova is a component and cinder is another?)18:08
fungiy2kenny: oh, i see, you're saying you plan to have some nodes which do "builds" and some nodes which run "tests" and they're separate. we consider tests to also be a kind of "build" so don't really have a means of separating statistics around them, at least not which i can think of18:08
mordredy2kenny, clarkb: https://opendev.org/inaugust/inaugust.com/src/branch/master/src/zuulv3/gus2019.rst was what I did at Gerrit Summit18:08
corvusy2kenny: that's a hard question to answer, it's a little fuzzy.  depending on how you count, there are between 6 and a few hundred of those, but opendev's zuul supports 2,000 git repos.18:09
corvushttps://www.openstack.org/software/project-navigator/openstack-components#openstack-services18:10
mordredmaybe it might make sense to think of opendev buildsets for the "builds" number and opendev builds for the "Tests" number18:10
corvusthat's some of the different ways of counting them18:10
y2kennycorvus: the idea behind that question is to talk about the complexity of the project.  The counter example would be typical webapp where it's really one component with a single button deploy and release.  Another definition for component may be individually versioned projects (Can nova and cinder get release independently?... I forgot... I vaguely18:11
y2kennyremember you guys do release train.)18:11
*** jpena is now known as jpena|off18:12
y2kennycorvus: the 2000 git repo is a good number :)18:13
corvusy2kenny: the full set of repos under openstack project governance is 694 -- that represents the set of git repos that coordinate release activity and follow the same testing standards, etc.18:14
corvusmany others are associated but have looser requirements.18:15
corvusas fungi said, i think 2 and 3 are the same for us, and that's 1,000 right now.18:15
y2kennyso the 694 is under one tennant?18:16
y2kennythese are all very good numbers.  Thanks guys.18:16
mordredfor 6 we're at a lower point right now - but the system has managed in the 2500 active devs number18:16
corvusy2kenny: even more under one tenant, close to the full 2000, because we haven't gotten around to moving the others out yet18:17
mordred(we have fewer devs today - but that doesn't mean that this zuul hasn't taken care of more in the not too distant past)18:17
corvusy2kenny: based on clark's graph, i'd estimate #4 and #5 (again, the same for us) at about 90,000 per week18:18
mordredthere was a point where we were doing 2k per hour at peak load18:18
y2kennymordred: Understood.  I have some more politically minded people challenging my CI capacity by asking about utilization during lunch time :)18:18
mordredy2kenny: how friendly :)18:19
*** jamesmcarthur has quit IRC18:19
*** jamesmcarthur has joined #zuul18:19
clarkbone of the great things about zuul is it has been designed to scale up with your needs18:19
corvusyeah, our peak load has probably been more like 150,000 to 200,000 per week18:19
clarkbif you need to run more jobs you add more cloud capacity and more executors18:20
mordredyeah - but even that is only that low because devs go to sleep - if the 2k jobs per hour held, that would make our estimated peak weekly load 336k jobs / week18:20
mordreddepending on what it is we're wanting to comunicate :)18:20
*** bhavikdbavishi has quit IRC18:24
fungiit's a matter of capacity vs utilization18:25
fungiwe have capacity to run 336k/wk, we run fewer because utilization fluctuates with waking hours of developers interacting with our code review system18:26
Shrewscorvus: umm, did we not add nodepool tests for the gce driver?18:27
corvusShrews: maybe not.  i think we have some very limited testing for aws, we could probably add something similar.18:29
openstackgerritDavid Shrewsbury proposed zuul/nodepool master: Update tests for node-attributes  https://review.opendev.org/71473818:31
Shrewscorvus: note the frowny face in 714738   :(18:31
Shrewsy2kenny: it seems node-attributes was broken in the openshift drivers, but works for k8s. 714738 should update the docs for us. Thanks for helping us find that.18:33
y2kennyShrews: thanks for the quick response!18:34
*** saneax has quit IRC18:39
*** mattw4 has quit IRC18:46
*** dpawlik has quit IRC18:53
openstackgerritTobias Henkel proposed zuul/zuul master: Stop jobs on gearman disconnect  https://review.opendev.org/71472218:58
tobiashcorvus, clarkb: the initial version didn't work, so yay tests :)18:59
*** avass has joined #zuul19:19
*** avass has quit IRC19:30
Shrewszuul-maint: fyi, something has broken the nodepool-zuul-functional test in nodepool while also removing that job from zuul's suite of tests19:36
Shrewsoh, nm on the zuul side. user error, but still broken  :/19:41
*** avass has joined #zuul19:41
mordredShrews: I didn't do it19:42
Shrews:)  attempting to trace it back19:42
*** hashar has joined #zuul19:43
Shrewshttps://zuul.opendev.org/t/zuul/build/dc97ec7941eb490a937569a2f11de947/log/nodepool/log/nodepool-builder.log#1919:45
Shrewspossibly something with the container builds?19:45
Shrewsi don't see any nodepool or zuul repo merges relevant to that19:46
mordredShrews: maybe ianw knows ^^19:48
corvusi don't think that should have anything to do with containers19:52
corvusis it saying it can't execute that program?19:52
Shrewsthat's how i read it19:58
ianwumm, did the config interitance changes merge?  i did update fake dib in that ... i certainly didn't mean to change permissions or anything20:08
ianwhasn't merged anyway20:08
Shrewsianw: no, i checked that20:10
ianwhow bizarre, not much merged in zuul that looks related either20:13
Shrewsyeah, this is a difficult one20:18
ianwjust grabbing some breakfast ... will look after20:24
Shrewsaccording to https://zuul.opendev.org/t/zuul/builds?job_name=nodepool-zuul-functional it broke sometime between 2020-03-19T22:36:07 and 2020-03-21T17:20:5520:24
Shrewsi guess 2020-03-22T13:07:26 is the real first failure20:31
*** y2kenny has quit IRC20:31
Shrewsianw: could this change have caused some unintended side effect?  https://review.opendev.org/#/c/713759/1/playbooks/group_vars/nodepool-builder_opendev.yaml20:40
Shrewsseems unlikely, but grasping at straws rn20:41
ianwShrews: i don't think so ... let's put a node on hold, i'll set that up now20:43
Shrewsyeah, i think that's the next course of action now20:44
Shrewsianw: you can use https://review.opendev.org/714672 if you like20:45
ianwcool,next run should hold20:47
*** jamesmcarthur has quit IRC20:51
*** jamesmcarthur has joined #zuul20:52
*** jamesmcarthur has quit IRC20:56
ianw-rw-r--r-- 1 root staff 2294 Mar 24 20:58 /usr/local/lib/python3.6/dist-packages/nodepool/../nodepool/tests/fake-image-create21:07
ianwit must be something in setuptools, etc?21:07
*** hashar has quit IRC21:08
corvussomething that now mutates the permissions when installing it?21:10
ianwyeah how weird.  it's correct in zuul's checkout in /home/zuul/opendev ...21:11
ianwit's not explicitly listed in setup.cfg or anything like that21:11
ianw"root staff" seems odd ... "staff"?21:12
*** rfolco has quit IRC21:12
fungistaff is standardized as gid 50 on debian and derivatives21:14
*** jamesmcarthur has joined #zuul21:14
fungigets used for a lot of stuff which would traditionally have been the "wheel" or "admin" group21:15
*** jamesmcarthur has quit IRC21:15
fungisomething in a parent directory could be setgid?21:15
*** jamesmcarthur has joined #zuul21:16
ianwdrwxr-sr-x 6 root staff 4096 Mar 24 20:58 /usr/local/lib/python3.6/dist-packages/nodepool/21:16
fungiyep, setgid staff there21:16
ianwsomehow a umask has changed?  or the way we install has changed?21:18
fungiare any parents of that also setgid staff? maybe all the way down to /usr itself?21:19
fungiwhat distro is it?21:20
corvusi don't think the staff part is important21:20
corvusit's the lack of execute21:20
ianwhttps://opendev.org/zuul/nodepool/src/branch/master/roles/nodepool-zuul-functional/tasks/main.yaml#L321:20
ianwcmd: sudo pip3 install .21:21
ianwi feel like maybe we changed sudo lately?21:21
ianw2020-03-24 20:59:04.240633 | TASK [revoke-sudo : Remove sudo access for zuul user.] ... no that all happens after, nothing there21:22
ianw# pip3 --version21:24
ianwpip 20.0.2 from /usr/local/lib/python3.6/dist-packages/pip (python 3.6)21:24
corvusianw, /win 1121:24
corvussorry21:24
fungiit would be odd for umask to mask out setting exec bit, so i don't think itS that either21:24
corvusi figure we have 2 approaches: either figure out what changed and see if we can revert or work around it; or change the approach to not have the functional test run that command out of the install dir (instead, run it out of the git checkout)21:25
mordredcorvus, tristanC: I just noticed: http://zuul.opendev.org/t/openstack/status/change/714763,1 <-- if someone gives you a link and you open it - there is no indication which pipeline that is :)21:26
corvusi agree and i agree that could be improved21:27
mordred(it's not a sequence of actions I think I've ever taken before now)21:27
corvusre nodepool; i sort of think the approach of just changing the path for the funtional test config may be the way to go21:28
corvusit's clearly not a test that runs outside of ci very often21:28
corvusso just update its config file to set dib-cmd to /home/zuul/....;  or if we really wanted to do it right, update the playbook to template that out21:29
ianwor perhaps pip install -e21:32
corvusianw: yeah, it's probably worth throwing a change up to do that and see if it works21:40
corvusmordred: i'm trying to debug that behavior from earlier, and this command doesn't seem to work: zuul enqueue --tenant openstack --pipeline third-party-check --project ansible/ansible --change 68122,8de92b45b3ea7576912ce7686381618456189ab921:41
corvusi get zuul.rpcclient.RPCFailure: Invalid change: 68122,8de92b45b3ea7576912ce7686381618456189ab921:41
corvuswhich i find really confusing21:41
corvusit's still open, and that looks like the right commit in that pr21:42
mordredcorvus: yeah. that's not some issue with there being a 3pci check still on there?21:43
fungiwhat were the details of the event which triggered it? i recall looking at the pr and it was closed and reopened and some labels removed and added and a new commit pushed all around the time the build occurred21:46
corvusi don't think there was a new commit?21:46
corvusbut lots of closing/opening happened afterwords21:46
mordredyeah - he was trying to retrigger ci runs21:46
corvusbut i don't think any of that should impact zuul being able to load the change...21:47
corvusmordred: did anything change with respect to the opendev zuul app installation?21:47
mordredcorvus: not to my knowledge?21:48
mordredcorvus: let me go check though21:48
mordredcorvus: I may not know how to check that21:54
fungii've heard github is intuitive, can't you just... intuit it?21:55
corvusi'm trying to set up a local zuul with a github connection to see if i can debug this22:01
*** jamesmcarthur has quit IRC22:03
*** jamesmcarthur has joined #zuul22:04
ianwso it looks the file in the wheel is : -rw-r--r--  2.0 unx     2294 b- defN 20-Mar-24 20:55 nodepool/tests/fake-image-create22:05
*** jamesmcarthur has quit IRC22:05
*** jamesmcarthur has joined #zuul22:05
ianwso it's not so much extraction of it, as it's going into the wheel wrong22:05
corvusmordred: wow, all that work into setting up a local zuul to test it, and it worked fine22:10
corvusmordred: like, i can enqueue it into a local zuul with an anonymous github connection without error22:11
corvusbut the same action on opendev's zuul gets me an "invalid change"22:11
corvuswhich means either there's some state in opendev's zuul that's wedged, or something about using the authenticated app installation is breaking it22:11
mordredcorvus: wow.22:14
mordredcorvus: well, I pinged gundalow to see if anyhting changed permissions-wise22:16
corvusmordred: switching to #opendev22:18
openstackgerritIan Wienand proposed zuul/nodepool master: nodepool-zuul-functional: switch to editable install  https://review.opendev.org/71478822:51
*** jamesmcarthur has quit IRC23:12
*** jamesmcarthur has joined #zuul23:50
*** jamesmcarthur has quit IRC23:57
*** rlandy has quit IRC23:57

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