Tuesday, 2020-02-11

*** mattw4 has quit IRC00:08
*** jamesmcarthur has joined #zuul00:14
*** jamesmcarthur has quit IRC00:19
*** jamesmcarthur has joined #zuul00:24
*** jamesmcarthur has quit IRC00:29
tristanCmordred: SF does deploy zuul using distro packages, and for executor ansible version, it's using a fake venv so that all the ansibles share the system libraries01:06
clarkbtristanC: does that mean changing the virtualenv version won't affect you?01:07
tristanCclarkb: it should not01:08
tristanChere is how the sake venv is assembled: https://softwarefactory-project.io/cgit/rpms/zuul-executor-ansible-29/tree/zuul-executor-ansible-29.spec#n5701:08
tristanCfake* venv, turns out python looks for a `pyvenv.cfg` file, that when provided, satisfies the venv property01:09
fungineat01:12
fungii never knew that01:12
tristanCfungi: well, it's not very documented... it may break in future version01:13
tristanCclarkb: more generally, SF is not affected by updates coming from pypi, all the requirements are packaged and their update are gated by zuul01:16
clarkbok, in this case I guess you hvae to worry about virtualenv changing its behavior01:18
clarkbbut you'd control that on your side01:18
*** rfolco has quit IRC01:19
tristanCclarkb: yup, though it's worrysome that doing `pip install zuul` may results in a non working zuul until the requirements cap is tagged and available through pypi...01:20
clarkbtristanC: there is a fix up01:20
clarkb(I think we should probably prefer to tag that over the cap)01:21
tristanCclarkb: i meant, maybe we could freeze the requirements, at least when doing a release. 3.15.0 seems to be currently affected by the cheroot issue too01:24
clarkbtristanC: that has the opposite issue01:25
clarkbsecurity updates won't be delivered01:25
clarkbalso if someone deletes a release on pypi you are broken01:25
webknjaz@fungi @clarkb: FYI Bernat did a nice overview of how various venvs work last summer — https://www.youtube.com/watch?v=o1Vue9CWRxU01:30
tristanCclarkb: well with service like dependabot, it should be possible to update the requirements freeze when needed. but you raised good point, it's hard to tell what is the best strategy for the end-user.01:31
*** wxy-xiyuan has joined #zuul01:52
tristanCclarkb: makes me wonder if we shouldn't deprecate pip installation and promote the container image as the official install method? At least until those recurring issue are affecting pip deployment.01:55
tristanCor perhaps we should indicate that pip user should use the master version because tagged release may need version cap to be usable today01:57
tristanCand for user who needs reproducable deployment, we could document how to gate the container image using zuul itself.01:58
clarkbanother option could be a constraints file and manage the pins separately so they arent hard requirements01:58
clarkbthen you can still install if a release on pypi is deleted01:59
tristanCclarkb: yes, as long as we can somehow control those surprise release effect02:02
tristanCso, could we have a zuul/requirements? should we draft a spec first?02:05
*** jamesmcarthur has joined #zuul02:09
clarkbIm not sure it needs to be a separate repo02:09
*** rlandy has quit IRC02:09
*** zxiiro has quit IRC02:25
*** jamesmcarthur has quit IRC02:28
openstackgerritSteve Baker proposed zuul/zuul master: Scheduler: make autohold hold_list configurable  https://review.opendev.org/63249802:31
*** jamesmcarthur has joined #zuul02:31
*** jamesmcarthur has quit IRC02:42
fungiwhat if each time we tagged a release and/or merged a commit, one of the release artifacts was a constraints file indicating the exact versions of dependencies that commit was tested with?02:47
fungiso rather than having to track a constraints file in git and deal with reviewing auto-proposed updates like openstack does, we did it the other way around02:48
clarkbI like that02:48
fungiit could be terrible, just a random saké-fueled ponderance02:49
*** bhavikdbavishi has joined #zuul03:12
*** fdegir has quit IRC03:14
*** fdegir has joined #zuul03:14
*** bhavikdbavishi1 has joined #zuul03:21
*** bhavikdbavishi has quit IRC03:23
*** bhavikdbavishi1 is now known as bhavikdbavishi03:23
*** sgw has joined #zuul03:38
ianwclarkb / Shrews : so linaro-london got fixed, and everything seems to have just magically cleared up05:01
ianwi don't know what the moral of the story is ... possibly it's just if your cloud is broken you can expect weird things05:03
fungiincluding blocking some image cleanup on other providers for the same builder?05:22
*** raukadah is now known as chkumar|rover05:28
*** evrardjp has quit IRC05:34
*** evrardjp has joined #zuul05:34
*** igordc has joined #zuul05:51
*** saneax has joined #zuul05:54
*** igordc has quit IRC06:00
*** sanjayu_ has joined #zuul06:01
*** saneax has quit IRC06:03
*** marvs has joined #zuul06:05
openstackgerritMerged zuul/zuul master: Install kubectl/oc into executor container image  https://review.opendev.org/70699506:46
openstackgerritFelix Schmidt proposed zuul/zuul master: Implement basic github checks API workflow  https://review.opendev.org/70516807:37
*** NBorg has joined #zuul07:49
NBorgHello. How do you return a link from gerrit to the buildset when a job is finished?07:54
*** Defolos has joined #zuul07:55
*** sanjayu_ has quit IRC07:58
fungiNBorg: i don't entirely understand your question. are you asking how to have zuul comment on a gerrit review with a link to the buildset instead of individual job status links?08:05
tobiashNBorg: do you mean the buildset or build page? Build page is configured in the tenant config: https://zuul-ci.org/docs/zuul/reference/tenants.html#attr-tenant.report-build-page08:05
fungiby default the gerrit reporter will leave a comment with links to the individual build results for each job which was run, per https://zuul-ci.org/docs/zuul/reference/drivers/gerrit.html#attr-pipeline.reporter.%3Cgerrit%20reporter%3E.comment08:06
tobiashNBorg: afaik linking to the buildset page as a result is not possible atm08:08
NBorgYes, sorry, that was a bit unclear. I want the <web>/t/<tenant>/buildset/<buildset> to be a comment in gerrit. If possible, also the individual builds.08:08
NBorgAh, ok.08:08
NBorgI'll look into the report-build-page. That should hopefully be good enough. Thanks!08:10
*** avass has joined #zuul08:11
tobiashNBorg: note that report-build-page currently has unexpected side effects on mqtt reporting if you use that (see https://review.opendev.org/703983 for a wip fix)08:11
*** avass has quit IRC08:16
NBorgWe are currently not using that, so no worries.08:18
*** tosky has joined #zuul08:27
*** carli has joined #zuul08:27
*** avass has joined #zuul08:29
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: WIP: Make bindep role compatible with newer virtualenv  https://review.opendev.org/70707808:30
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: WIP: Make bindep role compatible with newer virtualenv  https://review.opendev.org/70707808:39
*** jpena|off is now known as jpena08:54
*** sanjayu_ has joined #zuul09:08
openstackgerritMerged zuul/zuul master: Extract allow/disallow filter into util function  https://review.opendev.org/70614409:21
*** sshnaidm|afk is now known as sshnaidm09:25
*** mhu has joined #zuul09:29
openstackgerritMatthieu Huin proposed zuul/zuul master: JWT drivers: Deprecate RS256withJWKS, introduce OpenIDConnect  https://review.opendev.org/70197209:30
openstackgerritMatthieu Huin proposed zuul/zuul master: Authorization rules: add templating  https://review.opendev.org/70519309:30
*** avass has quit IRC10:05
tobiashcorvus: it appears that we have a hole in testing gerrit with ssh access. This broke jobs that rely on ssh access to gerrit but passed testing: https://review.opendev.org/70682710:17
tobiashcorvus: do you have an idea how we could test this?10:17
openstackgerritTobias Henkel proposed zuul/zuul master: DNM: Try quickstart with gerrit and pure ssh  https://review.opendev.org/70709210:21
openstackgerritTobias Henkel proposed zuul/zuul master: Offload repo reset to processes  https://review.opendev.org/70682710:22
*** bhavikdbavishi has quit IRC10:24
openstackgerritTobias Henkel proposed zuul/zuul master: DNM: Offload repo reset fixed with ssh  https://review.opendev.org/70709510:33
*** mhu has quit IRC11:00
*** bhavikdbavishi has joined #zuul11:09
*** bhavikdbavishi1 has joined #zuul11:12
*** bhavikdbavishi has quit IRC11:14
*** bhavikdbavishi1 is now known as bhavikdbavishi11:14
*** fungi has quit IRC11:24
openstackgerritMerged zuul/zuul master: JWT drivers: Deprecate RS256withJWKS, introduce OpenIDConnect  https://review.opendev.org/70197211:24
*** wxy-xiyuan has quit IRC11:25
tobiashcorvus: the quickstart test change reveals the error on 706827 and works as expected on 70709511:27
*** fungi has joined #zuul11:27
tobiashcorvus: so the test case works, the question now is should we duplicate/modify quickstart to use ssh or do something completely different?11:28
*** rfolco has joined #zuul12:02
openstackgerritJan Kubovy proposed zuul/zuul master: WIP: Store unparsed branch config in Zookeeper  https://review.opendev.org/70571612:03
*** dpawlik has joined #zuul12:34
*** jpena is now known as jpena|lunch12:38
*** sanjayu__ has joined #zuul12:39
*** sanjayu_ has quit IRC12:41
*** sanjayu_ has joined #zuul12:51
*** rlandy has joined #zuul12:51
*** sanjayu__ has quit IRC12:53
*** carli has quit IRC13:01
*** jamesmcarthur has joined #zuul13:15
*** jamesmcarthur has quit IRC13:24
*** jamesmcarthur has joined #zuul13:25
*** jamesmcarthur has quit IRC13:28
*** jamesmcarthur has joined #zuul13:28
*** jpena|lunch is now known as jpena13:32
*** jamesmcarthur has quit IRC13:35
mordredtristanC, clarkb: I don't think we should overthink/overcomplicate the requirements situation just yet. while I agree 3.15.0 is broken, we've been working on a fix and as soon as the fix is landed we can cut a new release. because of the gate, we should notice pip install zuul breaking pretty quickly. that said - I do get the impression that the container quick-start is the main way people are getting started13:37
mordredanyway13:38
*** jamesmcarthur has joined #zuul13:43
*** sgw has quit IRC13:53
pabelangerI just got hit by virtualenv 2.0.0 break on centos-8: ERROR:root:ImportError: cannot import name 'ensure_text', that's just doing pip3 install tox13:57
pabelangerI know we are working on zuul fix, but is there upstream bug?13:57
mordredpabelanger: dunno about a bug. https://review.opendev.org/#/c/706871/2 is the fix and is winding its way through the gate13:59
pabelangermordred: I wonder how we can expose that into bindep role, because that is where I see breakage14:01
pabelangerfrom pip task14:01
mordredpabelanger: as a workaround until it lands you can pin virtualenv to <20.0.0 - it's an issue with virtualenv now symlinking pip and setuptools and pkg_resources14:01
pabelangerhttps://object-storage-ca-ymq-1.vexxhost.net/v1/a0b4156a37f9453eb4ec7db5422272df/ansible_52/352/859f1378d11b913870dee1a4f99a59a89ef35d90/check/ansible-tox-linters/edfb3af/job-output.html#l37614:01
mordredOH - yeah - that's much more of a pita14:01
mordredthere was discussion of that in -infra - I haven't caught up with the latest thinking14:02
mordredit's a really impressively bad bug though :)14:03
mordredpabelanger: frickler says that issue goes away if you upgrade pip - it's a combo bug - happens with pip<10 and virtualenv>=2014:04
pabelangerthanks, let me look at that. in centos-8 case, we use pip from distro14:04
pabelangerbut, there doesn't seem to be tox rpm package in centos814:04
pabelangerso we pip install14:05
pabelangerwhich is how we open this can of worms14:05
mordredyeah- where is virtualenv coing from?14:05
pabelangerdistro14:05
pabelangerbut, when I pip install to14:05
pabelangertox*14:05
mordredreally? then why is virtualenv 20 even at play?14:05
pabelangerit now pulls 20.0.0 from pypi14:05
pabelangernot sure14:05
pabelangerlooking at tox now14:05
pabelangerit is a mess for sure14:06
mordredpabelanger: I'm also looking at your logs ... it seems like we need to make sure if someone is using pip and virtualenv from distro that we don't pip install things globally14:06
pabelangermordred: yes, that is part of the issue too, we pip3 install tox global, so have tox role work14:07
mordredpabelanger: this: https://object-storage-ca-ymq-1.vexxhost.net/v1/a0b4156a37f9453eb4ec7db5422272df/ansible_52/352/859f1378d11b913870dee1a4f99a59a89ef35d90/check/ansible-tox-linters/edfb3af/job-output.html#l379 is using pip installed virtualenv, not distro installed14:07
pabelangerwhich goes back to same issue last week of pip install tox --user not working14:07
pabelangerso, it is a series of things, that has lead to this failure in zuul.a.c jobs and only on centos-814:07
mordredjeez14:07
*** mhu has joined #zuul14:08
pabelangermordred: yes, that is right but on centos-8 /bin/virtualenv exists, from package14:08
mordredpabelanger: I'm just curious why /usr/local/bin/virtualenv even exists- maybe there's a dib element installing latest virtualenv for you from pip and that's actually what you're using on centos?14:09
pabelangerI believe https://github.com/ansible-network/windmill-config/pull/599 is my fix on centos-814:10
pabelangerbut, I also don't know why pip3 pulls in virtuelenv, if distro exists14:10
pabelangerI guess, something about matching globals pip installs14:10
mordredpabelanger: OH14:12
mordredpabelanger: it's because tox depends on virtualenv and you're pip installing tox14:12
pabelangeryes14:12
pabelangerwe only do, because i cannot find tox RPM14:12
*** Goneri has joined #zuul14:12
pabelangerfor centos-7, it is in epel14:12
mordredpip *never* tries to not install something via pip just if there is a distro version14:12
mordredpabelanger: yes - I think that element change is your best bet14:14
mordredpabelanger: you might want to, for now, since that's an image build - do a similar thing and put a "pip3 install virtualenv<20" into your base job with an "if platform == centos" thing on it14:14
mordredjust to fix things while waiting on that image to build and upload14:15
pabelangeryah, good ide14:15
mordredpabelanger: I *think* you might need a -U for the base job ... if virtualenv is already installed, I don't think pip will care what your version constraint it unless you give is -U14:16
pabelanger++14:16
pabelangerlong term, is fix ensure-tox to install into --user then remove from images14:17
mordredpabelanger: I think that ensure-tox fix then requires switching all tox jobs to calling {{ tox_executable }} right?14:28
pabelangeryah14:28
mordredI really wish there was a good story for adding ~/.local/bin to the path14:28
openstackgerritMerged zuul/zuul master: Uncap virtualenv  https://review.opendev.org/70687114:28
fungii really wish ansible didn't hate shells (or at least replicated their envvar initialization from files on the system)14:31
*** Defolos has quit IRC14:38
*** chkumar|rover is now known as raukadah14:50
tristanCis it me or using `lookup("file", ...)` in zuul job task doesn't work, it's failing with "An unhandled exception occurred while running the lookup plugin 'file'. Error was a <class 'TypeError'>, original message: expected str, bytes or os.PathLike object, not NoneType"14:53
mordredtristanC: oh good14:55
tristanCi also saw this failure mode: "'NoneType' object has no attribute 'startswith'"14:56
*** sgw has joined #zuul14:56
*** michael-beaver has joined #zuul14:56
corvustristanC: is it possible the argument isn't a string?14:57
mordredcorvus, tristanC: is the file in quesiton perhaps one that doesn't exist?14:57
tristanCcorvus: the lookup works when running ansible-playbook locally14:57
mordredwe do: lookupfile = self.find_file_in_search_path()14:57
mordredthen paths._fail_if_unsafe(lookupfile)14:57
mordredperhaps lookupfile is coming back as None?14:57
corvusi have used lookup('file') recently with zuul master in the untrusted context14:57
pabelangerI didn't know you could use it in untrusted14:58
corvusmordred: sounds plausible14:58
tristanCcorvus: is your lookup happening on localhost? the errors i'm seeing is when using it on the test instance14:59
tristanCremote* test instance14:59
openstackgerritMonty Taylor proposed zuul/zuul master: Protect fail if unsafe from None value  https://review.opendev.org/70716715:00
mordredtristanC: that's a *maybe* there ^^ but obviously unproven/untested15:00
corvustristanC: i thought lookups always happened on localhost15:00
mordredyes, lookups always happen on localhost15:01
corvusthat might confirm the missing-file theory15:01
mordredso - that makes me think even more that it's the file not found thing - if you're expecting to read a remote file, it's not gfoing to find it15:01
tristanCoh, then how am i supposed to lookup a remote file? should i keep on registering the output of cat?15:01
mordredyeah15:01
corvustristanC: slurp is one option15:01
pabelangertristanC: slurp15:01
mordredtristanC: slurp15:02
pabelanger:)15:02
corvustristanC: (but be careful, you have to base64decode it)15:02
mordredjust so I didn't not say it15:02
tristanCohhh, thanks, seems like slurp is the solution. i didn't knew about it15:03
tristanCnot sure why should i use it instead of cat command though :)15:06
corvustobiash: i think i can live with the ssh testing hole -- that doesn't change that often, and we can try to live-test changes that touch it.  but if we think we're going to make a lot of changes and we do need testing, then i guess we could add a copy of quickstart as a functional test.  or we could deprecate ssh-only gerrit.15:07
*** sanjayu_ has quit IRC15:09
*** zxiiro has joined #zuul15:10
tristanCmordred: regarding requirements, i'm in favor of deprecating pip install until we have a future proof solution to the issues we keep on having when a requirement release a buggy/incompatible version15:11
mordredtristanC: there is no future proof15:11
mordredthe pip developers will always find new ways to break us15:12
mordredand I do not want to do the pin everything method15:12
tristanCmordred: what's the issue with the constrain thing fungi and clarkb suggested yesterday?15:12
mordredI think it's a horrible experience15:12
corvusthis is a python program.  it sucks, but pip breakage just comes with the territory.  but i don't think we should stop supporting the standard way of installing python programs.15:13
tristanCmordred: then what about documenting that pip install should use the master version, e.g. pip install https://opendev.org/zuul/zuul#egg=zuul15:13
mordredwe either have to do something similar to dependabot (which is gross and misses security updates) - or we have a constraints file that nobody uses15:13
mordredtristanC: I don't think that's what people should do15:13
mordredI think they should pip install zuul15:13
mordredand something that will break15:13
mordredand when it does we'll fix it15:14
corvuss/something/sometimes/ ?15:14
mordredyes15:14
fungitristanC: the constraint suggestion i had was not to constrain our tests, but to publish a constraints list documenting what we tested with15:14
tristanCmordred: then we have to cut a release with things that are not related15:14
fungipossibly in a more directly consumable format than a pip freeze dump buried in some build logs that is15:15
mordredfungi: yeah - but that's just the thing - the pip tooling doesn't really support us doing that15:15
mordredin any way that's consumable for people doiung "pip install zuul"15:15
mordredthey can't do a "pip install --upstream-constraints zuul"15:15
mordredso I doubt anyone would figure out a decent way to use that file15:16
fungiright, it would at best be for people who know something broke and where to find that filter15:16
webknjazpip has `pip install -c constraints.txt`15:16
mordredright. but constraints.txt file has to exist15:16
mordredif the constraints.txt file is inside of the release as a file15:16
mordredpip can't do anything with it15:16
mordredso we can't publish it in any automatically consumable manner15:17
mordredwhich means nobody is going to use it and it's a waste of time15:17
fungiyep, nobody will know where to find that file or the special command to use without rereading zuul's documentation15:17
mordredI mean - we do publish constraints files for openstack and still deployers don't use them15:17
fungimy idea was to publish it as an artifact alongside our wheels and tarballs, but then i forgot nobody consumes the versions we host in opendev because they're all just retrieving them from pypi anyway15:18
fungior pip installing the source from git15:18
mordredyah- I mean, it's not a terrible idea if it was supported by tooling15:19
mordredALTHOUGH - it still suffers from lack of security updates etc15:20
mordredwhich is why I don't like the dependabot version of this15:20
mordredthe number of times we are broken by an upstream thing shifting int his manner that can't be solved trivially by a followup patch are pretty minimal - and I so I don't think we should invent or institute structures to deal with them15:20
corvusspeaking of which, 871 merged, should we cut a release now?15:23
*** jamesmcarthur has quit IRC15:23
mordredcorvus: yeah, I think that's likely a good idea15:25
clarkbI'm not super concerned about it myself. Maybe I'm weord but if pip installing you cant assume it will just work(tm)15:25
corvusshould we do an opendev restart/burn-in, or just go ahead and tag?15:25
*** jamesmcarthur has joined #zuul15:26
clarkbI definitely dont want to prevent users from getting security updates so the hard freeze idea is a no go15:26
corvuslook good?  commit a9eafb572568ecd10d8cdbdc654f9d5bbeac7248 (HEAD -> master, tag: 3.16.0, origin/master, origin/HEAD)15:27
corvusmordred, clarkb, tristanC, tobiash, fungi: ^ release this tag without opendev restart?15:30
corvushttps://zuul-ci.org/docs/zuul/reference/releasenotes.html15:30
mordredcorvus: there's a decent number of changes since 3.15 ... are we still running 3.15 ourselves?15:30
corvusmordred: we're pretty close to 3.15.  i think it's still just 3.15 with the memleak revert15:31
tobiashlgtm15:32
mordredcorvus: most of the substantive changesa re things bmw is already running15:32
clarkbdid my change for opendev to set gerrit auth method land?15:32
clarkbwe'll need that if restarting zuul15:32
corvusclarkb: i think so, but we should double check15:32
tristanCcorvus: sounds good to me, though there is lots of change since 3.1515:32
mordredmost of the changes are docs or CI related - there's a few dashboard changes - then a couple that are meaningful based on things bmw ran in to15:33
corvusyeah.  maybe we should go ahead and cut the release because we're pretty sure it's good, but also restart opendev and we can cut a .1 if any problems show up?15:34
mordredcorvus: ++15:34
tristanCcorvus: +115:34
mordredcorvus: if we cut the release then restart opendev - we'll be running on a tagged release for the first time possibly ever :)15:35
corvushaha15:35
corvuspushed 3.16.015:36
mordred++15:36
tobiashcorvus: do you have any objection about pausing the merger patch as well when pausing the executor? It is currently hard to stop a misbehaving executor from trying to merge things.15:38
tobiashs/patch/path15:38
*** jamesmcarthur has quit IRC15:38
corvustobiash: no objection!  i think i assumed it already worked that way :)15:41
tobiash:), it doesn't (which caused problems today)15:42
corvustobiash: i think pause is important for rolling restarts, so i think everything should support it eventually15:42
corvusmordred: i'm confused about something image related:  i have built a local zuul-web image, but changes to the js web app do not seem to be reflected in it.  can you think of any reason why that would be the case?15:42
tobiash++15:42
mordredcorvus: uh15:44
mordredcorvus: only thing I could think of is if you had stale built artifacts copied in with the source code and yarn decided to not rebuild"15:45
*** jamesmcarthur has joined #zuul15:46
corvusmordred: how could i confirm that?  a shell in the container, or a build log?15:47
corvusor run a yarn build then rebuild the image and see if it works?15:48
mordredcorvus: yeah - I'd do that15:48
corvusk.  i'll try that after restart15:49
mordredcorvus: I wonder if maybe we shouldn't do an explicit yarn build in the dockerfile15:49
corvusmordred: is there a 'yarn clean'?  maybe i should do that instead of a yarn build (and maybe that's what we should do in the dockerfile?)15:50
fungi3.16.0 sounds appropriate for a9eafb5, yes15:51
openstackgerritMonty Taylor proposed zuul/zuul master: Run yarn explicitly in Dockerfile  https://review.opendev.org/70718215:52
mordredcorvus: not sure - let me check15:52
mordredcorvus: there's a stab at an explicit yarn build15:52
*** zbr_ has joined #zuul15:53
*** zbr_ has quit IRC15:53
corvusmordred: i'll just try that change then15:53
mordredno - no yarn clean15:53
tobiashcorvus: would you unregister the merger functions on executor based on the governor or just on pause?15:53
mordredcorvus: one set - path is off15:53
openstackgerritMonty Taylor proposed zuul/zuul master: Run yarn explicitly in Dockerfile  https://review.opendev.org/70718215:54
mordredcorvus: try that version instead15:54
corvustobiash: i think on pause we don't have to worry about registration, we can just stop accepting jobs?  but if it's easy, then unregistering is a way to accomplish that.  actually, unregistering everything would be nice because then the stats reported are more accurate.  maybe we should unregister execute and merge jobs on pause?15:56
fungiall this release talk reminds me, i still need to look into how to add the bits we forgot to include in the new opendev release jobs we switched to, as we're still not publishing release artifacts to anywhere besides pypi currently15:57
tobiashcorvus: the execute jobs are already unregistered on pause (controlled by the governor)15:57
corvustobiash: then let's do the same for merge15:57
corvustobiash: oh i think i just now fully understood your question15:58
tobiashcorvus: yeah, my question was more about pause on pause request or pause triggered by the governor15:58
corvustobiash: you're going to unregister the merge functions on pause.  you're asking should you also unregister them based on the governor.  huh.  i would lean toward "no" -- always have the merger running if it's not paused.15:59
tobiashok15:59
corvustobiash: (the more mergers the better, and it's probably not a huge impact on the system -- though maybe it will be by the time you finish making it super-efficient :)16:00
tobiashyeah, there is still quite some room for improvement :)16:01
tobiashwe also seem to set all refs twice in some cases (reset repo and later restore repo state)16:01
tobiashbut that needs some more thoughts16:01
corvus++16:01
pabelangerfungi: could you share your script again, to generate equeue command for release jobs that failed? I cannot seem to find it16:02
fungihttps://review.opendev.org/61367616:02
pabelangerthanks!16:03
fungipabelanger: if you want to polish that up feel free to take it over, i seem to not have found time to make it more generic16:03
tobiashcorvus: re-registration of functions in gearman is safe is it?16:03
openstackgerritFederico Ressi proposed zuul/zuul-jobs master: Allow to force bindep installation  https://review.opendev.org/70718516:04
corvustobiash: i don't understand16:04
tobiashthe executor registers and unregisters functions in gearman based on the governor, I guess we don't need state handling there to avoid that we send multiple cando packets to gearman?16:05
tobiashat least I don't see an already existing state handling there, but I just wanted to make sure that I understood this correctly16:06
corvustobiash: i think multiple cando is ok16:06
tobiashk, thx16:07
pabelangerfungi: thanks, I'll look to push up more updates16:11
fungiappreciated!16:11
*** rf0lc0 has joined #zuul16:11
*** rfolco has quit IRC16:13
openstackgerritTristan Cacqueray proposed zuul/zuul master: kubernetes-operator: change attribute to camelCase  https://review.opendev.org/70719016:21
openstackgerritTobias Henkel proposed zuul/zuul master: Support pausing merge jobs  https://review.opendev.org/70719216:22
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Update attributes to camelCase  https://review.opendev.org/70719316:24
tristanCpabelanger: mnaser: jhesketh: to review the zuul-operator implementation (topic:zuul-crd) I suggest you start by checkout https://review.opendev.org/#/c/705535/3/CONTRIBUTE.md16:28
tristanCSpamapS: you might be interested by this too ^16:28
*** ysastri has joined #zuul16:37
corvustobiash, pabelanger: we're seeing some errors on the opendev github connection: https://zuul.opendev.org/t/openstack/config-errors16:44
tobiashcorvus: do you have a log from scheduler startup?16:44
tobiashI guess you did a scheduler restart?16:45
corvustobiash: yes and yes16:45
pabelangerwe are still on 3.15.0, and haven't see that yet16:45
corvustobiash: i did a full restart16:45
corvusthat error is from the branch-listing part of the process16:45
corvus2020-02-11 15:57:26,044 ERROR zuul.GithubConnection: No installation ID available for project cherrypy/cherrypy16:46
*** jpena is now known as jpena|brb16:46
tobiashcorvus: how went prime_installation_map?16:46
tobiashour last scheduler update was on feb 3 and we hadn't an issue with this16:47
tobiashchecking git log16:47
corvustobiash: no errors with prime16:47
corvusdo we require installations now?16:47
corvus(because these are repos without a zuul install on them)16:47
SpamapStristanC: I ported all of my stuff to Terraform, and I couldn't be happier. I'm pretty sure Helm and Operators are the devil. ;)16:49
tobiashcorvus: no, we shouldn't16:49
tobiashat least not on purpose16:49
tobiashthis looks most suspicious to me: https://review.opendev.org/70516716:49
tobiashthat might cause that side effect16:50
tristanCSpamapS: right, and I'm looking forward dhall binding for Terraform configuration. I guess what you have can't be easily shared and re-used by other?16:50
tobiashthe old implementation probably just ignores the missing installation and falls back to anonymous access16:50
tobiashwhile the new one might break because it does more stuff there16:51
corvustobiash: yeah, maybe an exception in that strftime ?16:51
tobiashprobably, do you have a trace?16:51
tristanCSpamapS: because that seems to be the main reason for helm and operator; e.g. being able to build higher order configuration16:52
corvustobiash: no, it's hitting the user-level exception handler, so it's masked :(16:52
tobiashoops16:52
corvusmordred: /bin/sh: 1: react-scripts: not found16:53
corvustobiash: should we revert that?16:53
tobiashcorvus: do you want to revert that locally? I can prepare the revert in the meantime16:54
SpamapStristanC: Terraform modules are about as sharable as Ansible roles.16:54
SpamapSWhat I like is the full lifecycle management, and easy integration with other APIs.16:54
corvustobiash: sounds good16:55
openstackgerritTobias Henkel proposed zuul/zuul master: Revert "Fix github app authentication to work with checks API endpoints"  https://review.opendev.org/70720516:56
tobiashcorvus: ^16:56
corvustobiash: thanks.  it's going to be a while since we have releases in progress right now16:58
tobiashoh good timing, is only the zuul tenant affected?16:59
*** ysastri has quit IRC17:00
mordredcorvus: wtf. ok - I'll work on that more17:00
corvustobiash: no, we have github projects in zuul and openstack tenants at least17:01
corvusactually looks like just those 217:02
corvusthe kata tenant has a reall installation id, so it's fine17:02
pabelangersounds like we should hold off on zuul 3.16.0 for the moment. Are we thinking of doing a 3.16.1 release? Should we also add release node to revert17:04
corvustobiash: ^ oh yes please add a reno17:14
corvus(so we don't have a release without a note)17:14
corvuspabelanger: and yeah, i expect to restart with a local patch in maybe 20 mins, then after confirming that fixes the problem, release .1 as soon as that lands17:14
tobiashkk17:15
pabelangerwfm!17:15
*** michael-beaver has quit IRC17:16
openstackgerritTobias Henkel proposed zuul/zuul master: Revert "Fix github app authentication to work with checks API endpoints"  https://review.opendev.org/70720517:17
*** gmann is now known as gmann_afk17:20
mordredassuming that all works, I guess the next step for that patch is to update it to still have the fallback for anonymous repos, yeah?17:24
*** igordc has joined #zuul17:24
*** jpena|brb is now known as jpena17:25
*** mattw4 has joined #zuul17:29
*** evrardjp has quit IRC17:34
*** evrardjp has joined #zuul17:34
*** jamesmcarthur has quit IRC17:40
corvusmordred: yeah, and probably some better exception handling since it's getting complicated :)17:45
mordredyeah17:47
corvustobiash: opendev restart with your patch looks good, i'm approving it and will tag it as .1 after it merges17:48
tobiash:)17:48
*** igordc has quit IRC18:02
*** igordc has joined #zuul18:06
*** bhavikdbavishi has quit IRC18:08
openstackgerritMonty Taylor proposed zuul/zuul master: Run yarn explicitly in Dockerfile  https://review.opendev.org/70718218:21
mordredcorvus: ^^18:21
mordredcorvus: was issing yarn install :)18:21
mordreddouble checking locally - but I'm pretty sure that'll do it18:22
corvusmordred: cool, i kicked off a local build with that too, will check back in a bit18:22
mordredcool18:22
mordredcorvus, clarkb: warning sha.js@2.4.11: Invalid bin entry for "sha.js" (in "sha.js").18:23
mordredTHAT'S a warning you always want to see18:24
clarkbwho checks the checkers18:24
*** bhavikdbavishi has joined #zuul18:25
*** jpena is now known as jpena|off18:36
*** bhavikdbavishi has quit IRC18:45
*** gmann_afk is now known as gmann18:49
*** NBorg has quit IRC18:50
corvusmordred: that worked!18:56
*** Defolos has joined #zuul18:56
mordredcorvus: woot!18:58
SpamapSHas anyone ever considered multi-inheritance for zuul jobs?19:00
clarkbyes, I believe it is possible already? I want to say its used somewhere but I can't remember where19:00
SpamapSWe have several competing interests in our parent jobs, like with-ecr-upload and with-slack-notify and then we have to have with-ecr-upload-and-slack-notify and now we're adding more and it's making a messy matrix.19:01
SpamapShah I hope once again Zuul just changed under me and I can just do this.19:02
corvusSpamapS: sorta -- there's a sneaky way you can do it by having multiple variants each with their own parent.19:02
corvusSpamapS: but we haven't make the "parent" attribute a list.19:02
corvusi think there is growing support for just doing that.19:02
SpamapScool19:03
SpamapSjust had the thought right now, glad it's not an outlier19:03
corvusSpamapS: fwiw, the multiple variants thing *is* intentional -- it has regression tests and everything.  it's just not really advertised because it's so complicated.  so i would say feel free to try that out with confidence that it's not an accidental feature subject to breakage.19:03
SpamapScorvus: is there a good starting place in the docs to figure that out?19:05
SpamapSI'm not sure I actually know all the ways to make a variant.19:05
SpamapSbranches are the only one I'm really familiar with. ;)19:05
corvusSpamapS: no, and unfortunately we reverted our one use of it in opendev so i can't point.  but let me mock up an example real quick19:06
corvusSpamapS: something like this should do: https://etherpad.openstack.org/p/VqP017oWn819:07
corvusSpamapS: and yeah, it's basically just multiple branch variants that match19:07
corvusand you don't change anything in the variant other than parent19:07
corvusSpamapS: if you use that, i'll be very interested in feedback :)19:08
corvus(maybe it's good and we just make 'parent' a list; maybe it's tricky and we tweak something before we make it a first-class feature19:08
pabelangerwe use it in zuul.a.c19:09
corvuspabelanger: ooh cool, maybe you can share a link?19:09
pabelangerhttps://github.com/ansible-network/network_collections_migration/blob/master/.zuul.yaml#L20 and https://github.com/ansible-network/network_collections_migration/blob/master/.zuul.yaml#L219:09
*** bhavikdbavishi has joined #zuul19:09
pabelangerthis is because we want to parent to both propose-github-updates and unittests19:10
pabelangerbut not force unitests for propose-github-updates19:10
corvusi'm pretty sure it's a depth-first traversal without repetition, but that's just off the top of my head, i'm not positive.19:11
*** bhavikdbavishi has quit IRC19:14
mordredcorvus: takea . look at http://zuul.opendev.org/t/openstack/status real quick19:16
mordredcorvus: it's showing 707214 in check twice19:16
mordredcorvus: I think there might be a bug - but I'm worried about capturing appropriate info19:17
mordredcorvus: I've saved a copy of status.json19:17
corvusmordred: anything you can think of interesting about that?  manual enqueue?  extra recheck comment?19:17
corvusoh it's different patchsets19:18
mordredone copy is 707214,1 and one is 707214,219:18
mordredeyah19:18
corvusand the ,1 patchset was in my re-enqueue script19:18
mordredAH19:18
mordredmaybe just a race-condition19:18
corvusso basically, i manually enqueued the ,1 after it was out of date19:18
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: Install tox-venv alongside tox  https://review.opendev.org/70723719:18
corvusyeah, i think it's benign19:18
mordredcorvus: PHEW19:18
corvusthe fix is HA scheduler :)19:18
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: Install tox-venv alongside tox  https://review.opendev.org/70723719:20
openstackgerritJames E. Blair proposed zuul/zuul-jobs master: Add an ensure-tox test job  https://review.opendev.org/70637119:23
corvuszbr: ^ can you rebase on that ?19:23
corvuszbr: (also, feel free to add more testing for your change as appropriate)19:23
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: Install tox-venv alongside tox  https://review.opendev.org/70723719:24
zbrnice sync :)19:24
zbrall this testing does not cover other platforms....19:27
zbrso is not of much use of indicating that the role would work fine on platforms other than ubuntu-bionic19:28
fungifor some reason that gave me a brief vision of zuul as a platformer-style arcade game19:28
zbr:]19:29
openstackgerritJames E. Blair proposed zuul/zuul-jobs master: Run ensure-tox on all platforms  https://review.opendev.org/70723819:30
corvuseasily remedied19:30
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: tox: change default calling as a module  https://review.opendev.org/69005719:34
*** hashar has joined #zuul19:35
webknjaz\19:52
*** Goneri has quit IRC19:53
openstackgerritMerged zuul/zuul master: Extract the watcher from git driver  https://review.opendev.org/70609220:35
mordredtristanC: feel like a +A on https://review.opendev.org/#/c/707182 ?20:40
tristanCmordred: isn't this going to build the web file twice?20:44
tristanCnvm, it seems like the _setup_hook check if it's already built20:46
mordredtristanC: ++20:48
corvusderp, we installed kubectl/oc on the builder image21:01
mordredcorvus: derp21:08
mordredcorvus: it's not useful on the builder image21:08
corvusmordred: this is what i'm finding to be true yes21:09
mordredcorvus: that said - you could do the download in the builder image  and do a copy-from to get the two files and skip the rm step if you wanted to21:09
openstackgerritJames E. Blair proposed zuul/zuul master: Fix kubectl/oc install in container image  https://review.opendev.org/70724921:09
corvusmordred: yep! that's what i was thinking and did21:09
mordredcorvus: I do not know whether that would be better or not - but it's possible if you put the download early that in iterative def it could reduce duplicate fetching21:09
mordredwoot!21:09
corvusbut i also simplied the download a bit using a suggestion from tristanC21:10
corvusoh dear https://review.opendev.org/707205 failed tests?21:11
mordredcorvus: I left a comment - but we can also skip that and just land it as-is if you prefer21:11
mordredoh dear indeed21:11
corvusmordred: sounds good21:12
corvushrm, same test failed on both runs21:13
*** Goneri has joined #zuul21:13
tristanCthe failure doesn't seem related to the change21:14
corvusagreed21:14
corvusoh wait it looks like it has a dep21:15
corvusyep https://review.opendev.org/707192 is failing too21:15
corvusi think that was just a rebase error, i will fix21:15
openstackgerritJames E. Blair proposed zuul/zuul master: Support pausing merge jobs  https://review.opendev.org/70719221:16
corvusderp21:16
openstackgerritJames E. Blair proposed zuul/zuul master: Revert "Fix github app authentication to work with checks API endpoints"  https://review.opendev.org/70720521:16
tristanCcorvus: that looks correct21:17
*** hashar has quit IRC21:21
openstackgerritMonty Taylor proposed zuul/zuul master: Move oc download to before src copy  https://review.opendev.org/70725021:22
mordredcorvus, tristanC: ^^ I +A'd the corvus patch and pushed my suggestion up as a followup21:23
corvuscool, i have a build of my original patch running now, i should be able to confirm it worked soon21:24
corvusyep, it looks good -- kubectl and oc are in /usr/local/bin21:25
mordredcorvus: woot21:35
openstackgerritMerged zuul/zuul master: Run yarn explicitly in Dockerfile  https://review.opendev.org/70718221:47
*** jamesmcarthur has joined #zuul22:06
*** mattw4 has quit IRC22:27
openstackgerritMerged zuul/zuul master: Fix kubectl/oc install in container image  https://review.opendev.org/70724922:40
*** jamesmcarthur has quit IRC22:41
corvusmordred, tristanC: huzzah!  https://gerrit-zuul.inaugust.com/t/gerrit/build/867c84e630244ec4ab06b6126764c9aa/console23:01
corvusk8s config update and scheduler reconfiguration all from the executor23:01
corvus(that's using add_host with kubectl to do the reconfig)23:01
*** jamesmcarthur has joined #zuul23:02
mordredcorvus: SWEET23:03
corvusmordred: i think i'll send a status update to repo-discuss and let folks know that it's running, self-deployed, we're just waiting on a dns name to declare it production-ready, and we can probably start working on some jobs23:04
corvushow does that sound?23:04
mordredcorvus: ++23:04
*** jamesmcarthur_ has joined #zuul23:05
*** jamesmcarthur has quit IRC23:05
*** jamesmcarthur_ has quit IRC23:24
*** jamesmcarthur has joined #zuul23:25
*** jamesmcarthur has joined #zuul23:26
corvusemail sent23:30
*** jamesmcarthur has quit IRC23:32
*** igordc has quit IRC23:46
*** Defolos has quit IRC23:46
openstackgerritMerged zuul/zuul master: Revert "Fix github app authentication to work with checks API endpoints"  https://review.opendev.org/70720523:58

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