Wednesday, 2020-06-17

openstackgerritMerged zuul/zuul master: Add ensure-pip to quick-start job  https://review.opendev.org/73590500:19
openstackgerritIan Wienand proposed zuul/zuul-jobs master: ensure-virtualenv: call ensure-pip for Xenial  https://review.opendev.org/73606700:23
*** wuchunyang has quit IRC00:38
openstackgerritIan Wienand proposed zuul/zuul-jobs master: ensure-virtualenv: call ensure-pip for Xenial  https://review.opendev.org/73606700:38
openstackgerritIan Wienand proposed zuul/zuul-jobs master: ensure-pip: remove Xenial venv workaround  https://review.opendev.org/73606800:38
*** wuchunyang has joined #zuul00:39
*** wuchunyang has quit IRC00:51
openstackgerritIan Wienand proposed zuul/zuul-jobs master: ensure-virtualenv: call ensure-pip for Xenial  https://review.opendev.org/73606700:53
openstackgerritIan Wienand proposed zuul/zuul-jobs master: ensure-pip: remove Xenial venv workaround  https://review.opendev.org/73606800:53
openstackgerritIan Wienand proposed zuul/zuul-jobs master: ensure-pip: install from EPEL for Python 2  https://review.opendev.org/73607000:53
*** Goneri has joined #zuul00:54
*** olaph has quit IRC01:14
*** wuchunyang has joined #zuul01:20
*** wuchunyang has quit IRC01:31
*** wuchunyang has joined #zuul01:48
openstackgerritIan Wienand proposed zuul/zuul-jobs master: Remove the -plain job variants  https://review.opendev.org/73577401:48
*** Goneri has quit IRC01:48
*** swest has quit IRC01:52
*** swest has joined #zuul02:06
*** wxy has quit IRC02:21
*** wuchunyang has quit IRC02:21
*** wuchunyang has joined #zuul02:35
*** wuchunyang has quit IRC02:41
*** wuchunyang has joined #zuul02:41
*** bhavikdbavishi has joined #zuul02:55
*** wuchunyang has quit IRC03:00
*** bhavikdbavishi1 has joined #zuul03:06
*** bhavikdbavishi has quit IRC03:08
*** bhavikdbavishi1 is now known as bhavikdbavishi03:08
*** wuchunyang has joined #zuul03:16
*** wuchunyang has quit IRC03:19
*** ysandeep|away is now known as ysandeep03:55
*** bhavikdbavishi has quit IRC04:20
*** bhavikdbavishi has joined #zuul04:21
*** evrardjp has quit IRC04:33
*** evrardjp has joined #zuul04:33
*** wuchunyang has joined #zuul04:38
openstackgerritMerged zuul/zuul-jobs master: Remove the -plain job variants  https://review.opendev.org/73577404:48
*** wuchunyang has quit IRC04:52
openstackgerritMerged zuul/zuul-jobs master: ensure-pip: install from EPEL for Python 2  https://review.opendev.org/73607004:53
openstackgerritMerged zuul/zuul-jobs master: ensure-virtualenv: call ensure-pip for Xenial  https://review.opendev.org/73606704:53
*** felixedel has joined #zuul05:22
openstackgerritMerged zuul/nodepool master: Add ensure-tox to k8s and openshift jobs  https://review.opendev.org/73590605:23
*** threestrands has joined #zuul05:27
*** wuchunyang has joined #zuul05:31
*** threestrands has quit IRC05:33
*** wuchunyang has quit IRC05:35
*** bhavikdbavishi has quit IRC05:41
openstackgerritMerged zuul/nodepool master: Implement an Azure driver  https://review.opendev.org/55443205:46
*** felixedel has quit IRC06:00
*** bhavikdbavishi has joined #zuul06:04
*** wuchunyang has joined #zuul06:12
*** felixedel has joined #zuul06:36
openstackgerritMerged zuul/zuul-jobs master: ensure-pip: remove Xenial venv workaround  https://review.opendev.org/73606806:37
*** rpittau|afk is now known as rpittau06:56
*** jcapitao has joined #zuul07:01
*** bhavikdbavishi has quit IRC07:14
openstackgerritGuillaume Chauvel proposed zuul/zuul master: tutorial: Rework quick-start and prepare for other tutorials  https://review.opendev.org/73206607:17
*** bhavikdbavishi has joined #zuul07:30
*** wuchunyang has quit IRC07:33
openstackgerritMatthieu Huin proposed zuul/zuul master: REST API, Web UI: implement nodes filtering  https://review.opendev.org/73604207:36
*** tosky has joined #zuul07:36
openstackgerritMatthieu Huin proposed zuul/zuul master: zuul-web: support OPTIONS for protected endpoints  https://review.opendev.org/73413407:38
openstackgerritMatthieu Huin proposed zuul/zuul master: zuul-web: refactor auth token handling code  https://review.opendev.org/73413907:38
openstackgerritMatthieu Huin proposed zuul/zuul master: CLI: Fix errors with the REST client  https://review.opendev.org/72806107:44
openstackgerritMatthieu Huin proposed zuul/zuul master: REST API: fix discrepancies between RPC and REST outputs for autohold  https://review.opendev.org/72807307:44
*** jpena|off is now known as jpena07:55
*** nils has joined #zuul08:23
openstackgerritSimon Westphahl proposed zuul/zuul master: Add optional support for circular dependencies  https://review.opendev.org/68535408:23
openstackgerritGuillaume Chauvel proposed zuul/zuul master: tutorial: Add "gate your first patch"  https://review.opendev.org/73206708:26
openstackgerritGuillaume Chauvel proposed zuul/zuul master: tutorial: Add "Use zuul jobs"  https://review.opendev.org/73206808:26
openstackgerritGuillaume Chauvel proposed zuul/zuul master: tutorial: Add "gate pipeline"  https://review.opendev.org/73206908:27
openstackgerritGuillaume Chauvel proposed zuul/zuul master: tutorial: Add "job secrets"  https://review.opendev.org/73207008:27
openstackgerritGuillaume Chauvel proposed zuul/zuul master: tutorial: Add "job dependencies"  https://review.opendev.org/73207108:27
*** felixedel has quit IRC08:35
*** sgw1 has quit IRC09:06
sshnaidmfolks, I'd appreciate your review on https://review.opendev.org/#/c/730360/ thanks09:18
sshnaidmcan we merge this? https://review.opendev.org/#/c/728073 fix discrepancies between RPC and REST outputs for autohold09:22
mhusshnaidm, it's part of a patch chain, a few need to be merged first09:24
sshnaidmmhu, ack09:25
mhubut all the patches prior to this one are ready to be merged IMO09:25
mhuat least ready for review09:25
*** ysandeep is now known as ysandeep|afk09:26
*** wxy has joined #zuul09:31
*** bhavikdbavishi has quit IRC09:34
*** bhavikdbavishi has joined #zuul09:35
*** bhavikdbavishi1 has joined #zuul09:54
*** ysandeep|afk is now known as ysandeep09:54
*** bhavikdbavishi has quit IRC09:56
*** bhavikdbavishi1 is now known as bhavikdbavishi09:56
openstackgerritMatthieu Huin proposed zuul/zuul master: REST API, Web UI: implement nodes filtering  https://review.opendev.org/73604209:58
openstackgerritMatthieu Huin proposed zuul/zuul master: Add simple testing for Zuul CLI & REST API  https://review.opendev.org/72809810:01
*** jcapitao is now known as jcapitao_lunch10:15
*** rpittau is now known as rpittau|bbl10:18
*** bhavikdbavishi has quit IRC10:25
*** bhavikdbavishi has joined #zuul10:26
*** bhavikdbavishi has quit IRC10:42
jktwhat is Zuul going to do when I already have a .zuul.yaml in some feature-branch, and I upload a merge commit from this feature-branch to master, where master did not have any .zuul.yaml?10:56
jktbecause right now what I seem to be getting with a managed Zuul from vexxhost, is that this build briefly shows up in the status page, and then it disappears without conducting any builds10:57
jktOTOH, after adding a noop job to check in master's .zuul.yaml and submitting/merging that change, it seems to work10:58
jktI'm surprised by this because I would have thought that whatever jobs are defined in the change in question should take precedence, and therefore also override the "no config here" in my old master10:59
*** jpena is now known as jpena|lunch11:30
*** sshnaidm_ has joined #zuul11:32
*** sshnaidm has quit IRC11:33
*** sshnaidm_ is now known as sshnaidm11:35
*** rfolco|rover has joined #zuul11:36
*** tosky has quit IRC11:56
*** tosky has joined #zuul11:59
*** bhavikdbavishi has joined #zuul12:02
*** bhavikdbavishi1 has joined #zuul12:05
*** rpittau|bbl is now known as rpittau12:06
*** bhavikdbavishi has quit IRC12:06
*** bhavikdbavishi1 is now known as bhavikdbavishi12:06
*** jcapitao_lunch is now known as jcapitao12:10
*** felixedel has joined #zuul12:12
openstackgerritMerged zuul/zuul-jobs master: Record artifact checksums and signatures to stdout  https://review.opendev.org/73592912:15
*** hashar has joined #zuul12:18
zbrrecent regression on build-python-release role: no longer works w/o sudo12:19
zbrmainly it now requires sudo  on "Install wheel"12:19
AJaegerzbr, yes - see my comment on https://review.opendev.org/#/c/73600112:21
zbrtristanC: mordred: mainly https://review.opendev.org/#/c/736001/ broke the role,12:21
AJaegerfixes welcome12:22
zbri would revert it until we fix it, another change made w/o tests around it12:22
zbrwhen can we introduce a rule not to allow touching or roles w/o tests covering them?12:22
openstackgerritSorin Sbarnea (zbr) proposed zuul/zuul-jobs master: Revert "Make sure wheel is installed for python releases"  https://review.opendev.org/73618312:25
zbrAJaeger: tristanC mordred ^12:25
tristanCzbr: could you please share a console log with the sudo issue?12:27
tristanCoh i see AJaeger comment12:28
tristanCAJaeger: iiuc without 736001 python-release was no longer working in opendev (cc mordred), would revert do any good?12:29
fbo@zuul-maint is an alternative to cherrypy has been considered. The cheroot pinning is problematic as upstream is not really keen on merging the supposed fix https://github.com/cherrypy/cheroot/pull/27712:30
openstackgerritSorin Sbarnea (zbr) proposed zuul/zuul-jobs master: Avoid become on build-python-release  https://review.opendev.org/73618512:32
zbrtristanC: clearly a revert will fix breakage made to zuul.ansible.com instance12:34
zbrwriting it with tests will take few hours and I am not happy to prevent others from merging their changes due to this12:35
*** jpena|lunch is now known as jpena12:37
AJaegersorry, need to look at other things and can't help here further...12:45
swesttobiash: any plans to merge https://review.opendev.org/#/q/status:open+project:zuul/zuul+branch:master+topic:change-queues soon? ;)12:48
openstackgerritSorin Sbarnea (zbr) proposed zuul/zuul-jobs master: WIP: Avoid become on build-python-release  https://review.opendev.org/73618512:52
tobiashswest: that needs a non-me review ;)12:54
webknjaz@fbo: I can merge that fix once it doesn't break tests...12:54
tobiashmordred, tristanC ^12:54
corvuszbr: thanks for the fix! two things: can you rebase that on the revert, since i've approved it?  and also i left 2 comments inline.13:02
*** sgw1 has joined #zuul13:02
fbowebknjaz: I have no clue how to fix it btw. Who have ?13:05
webknjazonly the-allanc, I guess. but he only appears on GH occasionally13:06
openstackgerritSorin Sbarnea (zbr) proposed zuul/zuul-jobs master: WIP: Avoid become on build-python-release  https://review.opendev.org/73618513:06
webknjazI'll try to figure out what I can do meanwhile13:06
fbowebknjaz: thanks a lot that would be nice.13:08
corvuswebknjaz: is the issue the travis build?  https://github.com/cherrypy/cheroot/pull/277/checks?check_run_id=590442991   it says the jobs were 'canceled'  ?13:09
openstackgerritMerged zuul/zuul-jobs master: Revert "Make sure wheel is installed for python releases"  https://review.opendev.org/73618313:10
AJaegerzbr: thanks for digging into this!13:11
openstackgerritSorin Sbarnea (zbr) proposed zuul/zuul-jobs master: WIP: Avoid become on build-python-release  https://review.opendev.org/73618513:12
webknjaz@corvus: there's multiple stages, failure in linting stage fails the build and the  next ones don't go further. But there's also GHA jobs that mostly duplicate envs and the failures are visible there13:15
corvuswebknjaz: ah, i can't see those since i'm not logged in to github :(13:16
webknjazoh13:16
corvusi can see it failed, but i can't see the error13:16
corvusjust "X Test with tox"13:16
webknjazit should be clickable and show the console output13:17
corvusyeah there's i thing that says "Sign in for the full log view"13:17
webknjazmostly the problem seems to be that it (or the previous commit in PR) fails in "slow" envs like macos13:17
corvuswebknjaz: but the gha aren't running on macos, right?  so it's failing at least some on other platforms?\13:18
webknjazGHA has ubuntu/macos/windows jobs in the matrix13:18
corvusbut "Test suite / tests (3.7, ubuntu-latest, python)" is one of the failures, right?13:19
webknjazyeah, I think it wasn't failing everywhere w/o a few last commits in that branch13:19
webknjazwithout the last experimental commit it's greener: https://github.com/cherrypy/cheroot/pull/277/checks?check_run_id=58506671613:20
webknjazonly macos failures + one flaky windows that can probably be ignored in the context of that PR13:20
webknjazyeah, that's a TLS test and testing SSL stuff is PITA13:21
corvusokay, i logged in, and i now see the test failing on ubuntu, and it's failing keepalive-related tests13:22
zbrcorvus: good to know about the simple role importer tick. sadly, it will not help us, as we need to run at least ensure-pip before,13:25
zbras pip is missing from some platforms13:25
webknjaz@corvus see the last link, ubuntu is green there13:26
corvuszbr: in that case, a new playbook is warranted.  should we think about making an ensure-wheel role, so this could be put in a pre-run playbook?13:27
corvuswebknjaz: oh i think i understand now -- you're saying to ignore the most recent results because they're just an experiment, the real problems we need to fix are shown in https://github.com/cherrypy/cheroot/pull/277/checks?check_run_id=58506671613:28
webknjazyeah13:28
corvuswebknjaz: sorry i missed that, it's obvious now :)13:28
zbrhow about an ensure-double-shot-latte? there is no end to the ensure-* part.13:28
zbri am more inclined to have a more intelligent role where we can specify what we want, in the end wheel is just a wheel like any other.13:29
fbocorvus: webknjaz I've experimented in that PR (with some additional commit) but w/o success https://github.com/cherrypy/cheroot/pull/28713:29
corvuszbr: sure, but you can't split the installation into a pre-playbook without a separate role13:30
corvuszbr: and the ensure roles are all there so that we can do that, so if there's a momentary network problem installing wheel, then it's resolved.13:30
zbrin fact the the correct approach is to include ensure-pip as part of this role13:30
zbransible is smart and does not include role twice.13:31
webknjaz@fbo @corvus I think the slow workers influence the test in a way that timeouts appear more often in that env13:31
corvuszbr: well, ensure-pip would normally be in a different playbook, so it'll actually get run twice in produciton.13:31
mordredcorvus: can I jump in on helping with the wheel issue?13:34
openstackgerritSorin Sbarnea (zbr) proposed zuul/zuul-jobs master: WIP: Avoid become on build-python-release  https://review.opendev.org/73618513:35
corvusmordred: we reverted the change, and zbr has a proposed improvement ^13:35
zbrfew extra eyes would not hurt here, i keep uncovering extra issues13:36
mordredcool, yeah. I see the conversation about splitting out an ensure-wheel and a second playbook - zbr are you working on that, I can if you're not13:36
zbrfor example pyenv suite of jobs is triggered when in fact it should not13:36
* mordred almost did that yesterday, should have13:36
corvuszbr: you can drop the files matchers from there13:37
corvuszbr: that may have predated the job-self-change detection13:37
zbrcorvus: so, in general there is no need to mention the file where a job is defined as zuul will know to auto include a job if its definition is touched by the change13:38
zbrthat is indeed a very useful thing13:39
corvusmordred: no, in fact, it didn't predate the self-change detection; i think you may have just been a little overzealous in adding a files matcher to that job?13:39
*** rpittau is now known as rpittau|brb13:39
corvuszbr: correct13:39
openstackgerritSorin Sbarnea (zbr) proposed zuul/zuul-jobs master: WIP: Avoid become on build-python-release  https://review.opendev.org/73618513:40
corvusmordred, zbr: oh!  we want at least one file matcher though13:40
corvusotherwise it'll run all the time13:41
corvuszbr, mordred: we should change that file matcher to "roles/ensure-python"13:41
*** rlandy is now known as rlandy|mtg13:41
zbrokey13:42
corvusand test-playbooks/ensure-python-pyenv.yaml13:42
openstackgerritSorin Sbarnea (zbr) proposed zuul/zuul-jobs master: WIP: Avoid become on build-python-release  https://review.opendev.org/73618513:44
zbrprobably it would have being easier to use .*foo.* patterns for these13:45
openstackgerritSorin Sbarnea (zbr) proposed zuul/zuul-jobs master: WIP: Avoid become on build-python-release  https://review.opendev.org/73618513:45
*** rpittau|brb is now known as rpittau13:53
*** bhavikdbavishi has quit IRC13:54
corvusregexes are fine14:01
openstackgerritFelix Edel proposed zuul/zuul master: WIP: Introduce Patternfly 4  https://review.opendev.org/73622514:06
mhufelixedel, woah I was just thinking about that, but I'm glad someone else is tackling this :p14:07
*** ysandeep is now known as ysandeep|brb14:07
felixedelmhu: Nice to hear that :)14:08
AJaegercorvus, do you want https://review.opendev.org/736226 to fix the configuration errors for the Zuul tenant?14:09
openstackgerritSorin Sbarnea (zbr) proposed zuul/zuul-jobs master: WIP: Avoid become on build-python-release  https://review.opendev.org/73618514:09
mhufelixedel, how hard would the migration to PF4 be?14:09
mhufor example I think query filters are handled differently in PF414:10
felixedelmhu: To be honest, I have no idea. I was hoping that somebody in this community is more familiar with this CSS framework and the transition.14:10
mhufelixedel, ahah my hope exactly14:11
mhuwe really need to catch a few frontend devs and entrap them14:11
felixedel:D14:12
felixedelI wanted to check in which way PF3 and PF4 could be used together, so one could migrate one component after the other. So far, it looks like this might work. The most noticeable change is the larger font size and the new font type.14:13
felixedelApart from that everything seems to look like before. Which should be a good starting point for a migration :)14:15
*** felixedel has quit IRC14:23
*** felixedel has joined #zuul14:24
*** felixedel has quit IRC14:38
*** rlandy|mtg is now known as rlandy14:39
clarkbjkt: I'm not sure you got an answer but I would expect the .zuul.yaml to apply to master if it was merged there. The exception to that behavior is if the project is a trusted project then you need to merge the change before config will apply14:48
avassmordred, corvus, zbr: looks like I missed a lot, can I get a tl;dr?14:52
corvusavass: we thought the build-python-release role was tested, but it wasn't, and it broke when used with revoke-sudo.  we reverted, and zbr is working on a second attempt in https://review.opendev.org/73618514:53
corvushttps://review.opendev.org/736001 was the breaking change14:54
avassah, because it was always running with super-user privileges?14:56
*** Goneri has joined #zuul14:57
corvusavass: i think it almost never runs that way; the initial problem was that opendev removed 'wheel' from its images14:58
corvusthough i guess in opendev, we ran it without revoke-sudo, because we were able to run the job after that change merged15:00
corvusso i guess opendev runs it without revoke-sudo, but other installs do use revoke-sudo15:00
AJaegercorvus: we were not able to run the job15:00
mordredyeah- I checked the job in opendev and saw it wasn't running with revoke-sudo15:00
mordredAJaeger: oh, we weren't? my bad then15:00
AJaeger https://zuul.opendev.org/t/openstack/build/af6e45cad84245e7bdad1e4034ce505d15:00
corvusmordred, AJaeger: i thought https://review.opendev.org/735905 was the change that needed mordreds fix15:00
corvusAJaeger: key part of my sentence from 15:00 "after that change merged" -- where "that change" refers to https://review.opendev.org/73600115:01
corvusonce more from the top: build-python-release was broken by opendev's image changes, as illustrated by https://review.opendev.org/735905 so mordred wrote https://review.opendev.org/736001 to fix that, and it worked in opendev and https://review.opendev.org/735905 merged, but that broke ansible's zuul because they use revoke-sudo in their version of that job.  so we reverted mordred's fix in15:04
corvushttps://review.opendev.org/736183 meaning opendev is broken again now, and are looking to fix it for everyone in https://review.opendev.org/73618515:04
*** ysandeep|brb is now known as ysandeep15:04
avassI left some comments on that, I don't think it should need 'become: true' when it's installing wheel for the user15:07
AJaegercorvus: Oh, what a cascade...15:08
clarkbavass: zbr also does installing a package with --user make it available when we later run "{{ release_python }} setup.py sdist bdist_wheel {{ bdist_wheel_xargs }}" ? I would expect those to be two different execution contexts15:09
clarkbsince --user is basically a virtualenv isn't it?15:09
clarkbfungi: ^ you probably know15:09
corvusi think that's why mordred was thinking of using a venv for the whole role15:09
zbrclarkb: it is not15:09
fungi--user isn't quite a virtualenv15:10
fungiit's more like an additional tree added to the import path15:11
fungiso it acts sort of like a virtualenv with --system-site-packages but one which you don't need to explicitly add/activate... but it's not that similar really15:12
clarkbhuh TIL15:12
clarkbI guess the only major issue then is the one avass points out?15:12
clarkbthen we could switch to doing it all in a virtualenv as a followon?15:12
*** harrymichal has joined #zuul15:12
fungiyou would at least have to make sure the same python interpreter which was tied to the pip which installed wheel was also the one used to invoke something importing it15:14
avassclarkb: yeah, the package should be available as long as it's run with the same user and interpreter.15:15
fungioh, right, same user too obviously ;)15:15
avassand become: true installs it for root, so that wouldn't work :)15:15
fungiso say you have a job which needs to create separate wheels for different python versions, you'd need to separately install wheel for each of those15:16
*** sshnaidm is now known as sshnaidm|bbl15:17
openstackgerritSorin Sbarnea (zbr) proposed zuul/zuul-jobs master: WIP: Avoid become on build-python-release  https://review.opendev.org/73618515:19
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Update guideline docs for os specific tasks  https://review.opendev.org/73160615:24
avasswe should merge the policy update ^15:25
corvusavass: done (that was a trivial change so i think we can consider AJaeger's vote sticky)15:26
avass:)15:26
avasscorvus: also, if you have time you might want to take a look at: https://review.opendev.org/#/c/735402/ it adds tests for upload-docker-image, I'm thinking about extending that for buildx as well15:38
avassmordred: you might also be interested ^15:38
*** hashar has quit IRC15:38
openstackgerritMerged zuul/zuul-jobs master: Update guideline docs for os specific tasks  https://review.opendev.org/73160615:40
*** dennis_effa has joined #zuul15:53
zbravass: corvus mordred AJaeger: please look again at https://review.opendev.org/#/c/736185/10 -- now is green, so i will wait for last comments before updating commit message.16:06
zbri think it would be a good idea to add a new param "sudoless" to the generic role tester playbook, to tell it to remove sudo before including the role. Very useful for testing that some roles work without sudo (and we do not add regressions accidentally)16:08
zbrbut that would be another change16:08
corvuszbr: do we call an ensure-* role like that in any other situation?16:09
avasscorvus: I believe we do, but cannot recall where16:09
zbra grep returned lots of include_roles, and I was expecting it16:10
zbrvery few roles are effectively standalone16:11
corvuslooks like ensure-tox is one similar example16:11
corvuszbr: should we be changing the default python in this change without an announcement?16:12
zbrwell... the change does not have a title yet, we just found one.16:12
corvuszbr: i mean that everything else in the change should not change any behavior (at least, for anyone other than opendev); but changing the default python version may be a behavior change for folks, so we may want to make that a standalone change and send an announcement to zuul-announce16:14
zbrbut because we didn't have any tests we didn't know that this role was broken on any modern platform (afaik all use python3 exec)16:14
zbrthe symlink for "python" being optional16:14
corvusi don't think we can assume that we have no users where python=python216:15
*** rpittau is now known as rpittau|afk16:17
openstackgerritSorin Sbarnea (zbr) proposed zuul/zuul-jobs master: Make build-python-release use python3  https://review.opendev.org/73618516:19
zbrin fact python -> python2 for >95% of the cases, as PSF guidelines where very strict on this aspect and most distros respected that.16:21
zbrif someone wants to switch to defaulting to ansible interpreter, i am ok with that too.16:21
zbrin fact ansible interpreter python is the only python interpreter that we are sure to exist :D16:22
mordredzbr: actually, defaulting to ansible interpreter is very incorrect for us adn we should definitely not do that16:23
corvuszbr: sorry, my question about python3 is a -1 level thing; i didn't manage to post a review before you updated16:27
corvusafaik, no one is broken by the python/python3 thing, so let's make that a separate change16:27
zbrcorvus: false: nobody knows is broken because we have no tests. let me prove it.16:28
openstackgerritSorin Sbarnea (zbr) proposed zuul/zuul-jobs master: POC: test build-python-release using python  https://review.opendev.org/73629316:29
corvuszbr: i think you misunderstood me.  i'm saying that as far as i know, no production systems are broken because that defaults to 'python' right now.  that means that what you're proposing could be a behavior change that could break some people, and we should announce it in advance.16:30
corvuszbr: i don't doubt that there are theoretical systems where it may not work as written.16:31
mordredyeah - and we should definitely fix that - same as the sphinx role16:31
mordredin fact - we could send that in the same announcement16:31
corvus++16:31
corvusthat's https://review.opendev.org/73592316:31
* mordred hasnt' sent the sphinx announcmeent yet16:31
corvusi -1d that for the same reason16:31
zbri am not against any announcement, or waiting bit more before merging.16:32
mordredwell - I think we need to merge the rest of your patch immediately :)16:32
corvuszbr: cool, then if you can split that part out, we can merge the more urgent fix soon16:32
mordredyeah16:32
zbrbetter to put a -W and a +2 on it, to make it clear you support the change but not merging it.16:32
mordredzbr: I don't support the patch as written - it needs to remove the python change. for that it's a -1. Once the python change is split into a follow up patch, it'll be +2 with a -W on the followup patch16:33
mordredzbr: that said - I have a question ...16:33
mordredyou said to smcginnis that we expect ensure-pip to be a no-op in production, is that right in opendev? I've honestly lost track16:34
zbri have no pressure to fix this, the only reason i raised this patch was because the earlier merge we reverted affected my "daily productivity" ;)16:35
mordredzbr: ok. would you mind if I take over the patch then? because I do have a pressure to fix this, as the job is broken in opendev16:35
zbrmordred: not at all, feel free to do anything with it16:35
zbris already late here16:36
mordredzbr: cool - thanks for the help!!16:36
tristanCi thought the `ensure-*` roles were not meant to be used in `run` phase16:36
zbrin general i do not mind if others are taking my chages16:36
*** ysandeep is now known as ysandeep|away16:36
mordredtristanC: correct. I expect them to run in pre16:36
corvustristanC: this is my understanding16:36
zbrfyi, that expectation are something fully undocumented, not clear for average user. if we really want to avoid confusions we may have to add pre_ and run_ prefixed to these roles.16:37
zbr(not supporting this myself)16:38
corvusbuild-python-release is defined in zuul-jobs, so if we want something run in a pre-playbook, we should add a pre-playbook to that job16:38
tristanCok good to know, then this is a good candidate for a custome ansible-lint rule16:38
corvusso perhaps we should put ensure-pip and ensure-wheel in a pre-run playbook for that job16:39
mordredcorvus: yeah16:40
avasswe don't need an ensure-wheel since it doesn't need sudo16:40
corvusbut there's some ambiguity here, in that the tox role includes ensure-pip16:41
corvuswe should probably figure out if we want to handle missing things gracefully like that (and install them in the run phase) or just have the roles error and document that they have pre-requisites16:41
corvusi think the latter is what we have traditionally done16:41
zbrone more note before i go offline for the day: i prefer for the roles to be self-aware of their requirements, mainly to call roles that ensure their requirements instead of failing in confusing ways. this would make them much easier to use by other users, users that may not know (or have time/curiosity to learn) about the entire dependency tree.16:42
corvusavass: i don't think the ensure- roles are just for things that need sudo; they're for getting pre-requisites in place for other roles; they're separate so they can be in a pre-run playbook so they are subject to retries16:42
tristanCavass: do you think such `ZuulJobsPreEnsure` rule to prevent ensure-* role usage in non-pre run is possible to implement using an AnsibleLintRule object?16:42
avasstristanC: absolutely16:43
corvustristanC: we can't know kind what playbook a role will be used in16:43
corvustristanC: we can't know what kind of playbook a role will be used in16:43
avasscorvus: right, since it's not part of the test and it fails it should try again somewhere else16:43
avasscorvus: we can check if the role is included from another ensure-* role, but yeah I guess that's it16:43
tristanCcorvus: arg good point, what if we only check direct `pre-run` inclusion?16:44
corvuszbr: that's reasonable; but if we choose not to do that, then we would document the pre-requisites in the role.  so for example, in this case we would configure the job to have all of the necessary ensure- roles in a pre-playbook.  but if a user chose to use the build-release role on its own, they would need to read the documentation to know it needs pip and wheel.16:44
corvusthere is a good argument to be made for that approach because it means that we're doing more setup work in a pre-run playbook, and then we're not spending extra time re-running some of the same tasks in the run playbook.16:45
corvustristanC: i think before we make a linter rule, we probably need to agree on an approach.16:46
corvusit seems we're of two minds about whether execution roles should perform setup tasks if things are missing16:46
tristanCcorvus: some container user might have images with all the tools pre-installed (and validated), for example we have a python-f32 image with twine, wheel, setuptools, tox, ..., we would like to run just the `build wheel` and `publish to pypi` tasks, and simply skip all the ensure-* role16:47
corvusoh you know what, i think i'm somewhat wrong about that16:48
corvustristanC: i agree you should be able to do that16:48
corvusnow that i look more closely, it looks like while we do have some 'ensure' roles calling other ensure roles, the only execution role we have that calls an ensure role is 'js-package-manager'16:48
corvusso we are actually pretty close to being consistent about not having execution roles perform setup tasks16:49
corvuswhich means the most consistent way to implement this would be not to change the build-python-release *role* at all, but instead, write an 'ensure-wheel' role, have 'ensure-wheel' call 'ensure-pip', and then add a pre-run playbook to the build-python-release *job* that calls ensure-wheel16:50
corvuswhat do folks think about that ^?16:50
avassI can agree to that16:51
tristanCcorvus: that sounds ideal16:51
corvusi think that gets us to our goal of "the job just works for everyone" and if you want to use the roles standalone, you can (you can make a custom version of the job without the pre-run playbook if you know your image has the pre-reqs)16:51
tristanCcorvus: not sure how easy or interesting it would be to make `custom version of the job without the pre-run playbook`16:52
corvustristanC: it's definitely easy; it's a 4 line job and a 4 line playbook.  it's probably not interesting.  :)16:54
tristanCi'd rather see a skip tag vars or something that could be used to disable the play that does setup action, but that's maybe premature optimisation16:54
corvusso ideally, the pre-run playbook should noop quickly.16:54
corvustristanC: i think the big hit is going to be running the playbook at all16:55
tristanCcorvus: yeah, that's what we observe most of the time16:55
avassmaybe we should start using gather_facts: false whenever a playbook doesn't use facts? that's usualy a big speedup16:55
mordredcorvus: yes. I just did that locally fwiw16:56
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Ensure wheel exists for build-release-python  https://review.opendev.org/73618516:56
mordredcorvus: there is ensure-wheel in a pre playbook16:56
avassI don't know how common that is though16:56
mordredavass: we should have facts cached16:57
mordredby nodepool16:57
avassah16:57
corvusmordred: by nodepool?16:58
corvuszuul caches facts in its setup playbook i think16:59
corvusoh, heh, i had an old copy of zuul-jobs and didn't realize we already just added a pre-playbook to that job :)17:01
corvusmordred: cool, i think that matches what we just talked about :)17:02
mordredcorvus: it's a little ugly due to the variable passing17:03
mordredcorvus: I kind of think it might be nice to introduce a general variable that can be used by different things to select the python they want to use17:03
mordredcorvus: but I don't know that my brain can handle that atm17:04
*** jpena is now known as jpena|off17:06
avassmordred: you mean like how we use zuul_work_dir ?17:07
corvusmordred: yeah, we've done similar -- however, it was really useful to have "sphinx_python" be different.... so.... maybe have "sphinx_python" default to "cool_name_for_general_python" which defaults to "python3".  same for wheel_python.17:07
mordredcorvus: yeah17:08
mordredavass: and yeah17:09
*** jcapitao has quit IRC17:11
*** sugaar1 has quit IRC17:29
*** paulalbertella has joined #zuul17:32
*** reiterative has quit IRC17:32
corvusomg omg omg omg we have tags!  https://hub.docker.com/r/zuul/zuul-web/tags18:19
corvusmordred, tobiash: ^ 3.x dockerhub tags for zuul are up18:20
corvusi will restore the release jobs now, and start work on nodepool18:20
tobiashawesome :)18:20
openstackgerritJames E. Blair proposed zuul/zuul master: Restore release jobs  https://review.opendev.org/73632718:21
corvusmugsie, tristanC, tobiash: azure merged!  awesome!  thanks :)18:23
avassnice! :)18:23
mordredcorvus: \o/18:25
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Add option to install tox into a path location  https://review.opendev.org/73633018:28
*** hashar has joined #zuul18:29
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Add option to install tox into a path location  https://review.opendev.org/73633018:33
openstackgerritJames E. Blair proposed zuul/nodepool master: Run upload-docker-image on release  https://review.opendev.org/73633318:36
corvusmordred, tobiash: ^ that should be the next step18:36
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Add option to install tox into a path location  https://review.opendev.org/73633018:37
mordredcorvus, fungi: ^^ that should be good now18:37
mordredavass: we had an idea related to an issue opendev was having with some jobs ^^18:37
mordredcorvus: I feel like your release tag list thing could eventually be a  base feature of the image jobs18:39
corvusmordred: yeah, i'm mulling over how universally applicable it is18:39
mordredI think it's a reasonably common pattern people do18:40
avassmordred: lgmt18:44
avassI guess the problem is if tox is for some reason already present at /usr/bin/tox but there's another tox detected somewhere else earlier18:45
fungiyeah, ensure-tox short-circuits if there's already a tox installed that it can find, right?18:45
avassI mean if for some reason there's a tox in bot /bin/tox and /usr/bin/tox and ensure-tox detects /bin/tox then it will remove the /usr/bin/tox and replace it with a symlink to /bin/tox18:46
avassor something like that :)18:47
*** jamesmcarthur has joined #zuul18:47
fungiavass: maybe it needs to add "when: tox_preinstalled.rc != 0" then?18:47
fungior move into the "Install tox to local env" block?18:48
mordredwell - I mean it'll just symlink it to /usr/local18:48
mordredso the result of having /usr/bin/tox is that it would make a symlink from /usr/local/bin/tox to /usr/bin/tox18:49
mordredbut in that case the user probably didn't need to set the variable, yeah?18:49
fungiyeah, that's true18:49
fungiprobably results in no actual difference in behavior for the user either way18:50
avassmordred: sorry, I meant /usr/local/bin/tox18:50
avassso if there's a tox in something like /usr/bin/tox and /usr/local/bin/tox then it will probably fail because /usr/local/bin/tox is probably not writeable by the user18:51
mordredavass: oh - thanks. sorry - this is missing a become18:52
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Add option to install tox into a path location  https://review.opendev.org/73633018:52
mordred(this is really only useful in cases where the job _does_ have root access available so the work to avoid doing things as root is making things harder for their content)18:53
fungimordred: i guess we should call that out in the readme too then?18:54
fungilike noting that option requires sudo access or something18:54
corvus++18:54
*** jamesmcarthur has quit IRC18:54
fungiotherwise it might be non-obvious and result in confusing errors18:55
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Add option to install tox into a path location  https://review.opendev.org/73633018:55
mordred++18:55
mordreddone18:55
*** jamesmcarthur has joined #zuul18:55
avasswell, it will still remove a tox executable, but I don't know if those could point to different tox versions or if it would ever matter18:57
mordredavass: yeah - I think the user shouldn't set the flag then18:58
fungiavass: what will it remove? there's a check in there to not overwrite (when: ... tox_executable != '/usr/local/bin/tox')18:59
*** jamesmcarthur_ has joined #zuul18:59
avassfungi: the edge case is if it detects tox_executable == /usr/bin/tox (or somewhere else earlier in PATH) and there's also a /usr/local/bin/tox19:00
*** jamesmcarthur has quit IRC19:01
fungiavass: oh! right, got iy19:01
*** rlandy is now known as rlandy|brb19:01
fungidoesn't check whether /usr/local/bin/tox already exists, only that /usr/local/bin/tox isn't the first one it found19:02
avassyeah19:02
fungithough i suppose if its search algorithm looked for /usr/local/bin/tox first that would never happen19:02
*** sshnaidm|bbl is now known as sshnaidm19:09
avassI wonder if we could add something like /zuul/bin that's always added to PATH by the forked command and shell modules19:09
avassmordred: It's probably fine, but -1 for docs :)19:09
mordredwow. also - that failed some tests pretty spectacularly19:13
mordredfungi: I feel like you might have this paged in - can you suggest what's wrong here: https://zuul.opendev.org/t/zuul/build/9df0b90f523244e1842fb02245a30a8d ?19:14
fungilooking19:17
fungiwow, i bet this is the first time we've touched that role/triggered that job since the image changes19:17
fungiit assumes pip will be present so it can use it to uninstall things pip installed19:18
avassmordred: that looks unrelated19:18
fungii wonder if we could skip all the pip uninstall calls if pip dne19:18
fungilike is it sane to assume there are no pip-installed packages in the system context if there's no pip in the execution path?19:19
fungioh ,though some of those may be nonfatal19:19
fungithe failure to import setuptools/pkg_resources is likely also related to not preinstalling19:20
fungiianw did a workaround yesterday for ubuntu xenial. i think debian stretch needs it too19:21
fungithey are of a similar vintage after all19:21
* fungi finds19:22
mordredfungi: also centos 7 is having a sed too19:22
fungiit whould have an awk instead19:22
mordredhah19:22
mordreds/sed/sad/19:22
fungineither of us can type today19:22
mordredfungi: centos-7 same thing - pkg_resources missing19:22
clarkbI think the fix for that is ensure-pio?19:23
clarkbat least for ubuntu it was and I think ianw was looking at centos7 yesterday19:23
fungioh, maybe19:23
fungithe fix i was misremembering is https://review.opendev.org/72478819:23
fungiwhich uses a backported pip on xenial from a ppa, so not generally extended to other distros without a lot of work19:24
mordredclarkb: this role uses ensire-pip19:24
clarkbmordred: ya I think there is a bug ianw was fixing19:24
mordredall of his patches seem to have landed for zuul-jobs19:25
clarkbhrm maybe he didnt get to it then19:25
mordredmaybe if I say his name three times he'll appear ... ianw ianw ianw19:25
clarkbhe definitely mentioned the centos7 python2 case had a problem19:25
clarkbinstalling virtualenv under python3 might fix it there19:26
*** rlandy|brb is now known as rlandy19:26
fungioh, right, it's the related https://review.opendev.org/736067 i was thinking of19:26
mordredwell - in this case I don't know that we're installing virtualenv at all19:28
mordredbut maybe that's the issue19:28
mordredmaybe we need to have ensure-tox call ensure-virtualenv19:28
mordredensure-tox is calling ensure-pip already ... but I think then it's installing tox into a puython -m venv19:29
mordredoh - except it can't19:29
clarkbI would expect that to work as its the newer python3 toolchain19:29
mordredbecause ensure-virtualenv installs virtualenv for package19:29
mordredand ensure-tox expects to be able to work without root19:30
clarkbah19:30
mordredbut - let's ignore that ... I'm guessing something is wrong on stretch where something is missing  ... oh wiait - isn't it that stretch needs python3-pkg-resources for pip to work in python3 -m venv?19:30
clarkbfungi: ^19:31
* mordred is checking in a container19:31
mordredworks for me in a stretch container :(19:32
corvusis it too late for me to chime in with an "awkward" joke about sed?19:32
mordredcorvus: hah19:32
mnaserlets just create our own base testing os :)19:33
mnaserzuulos19:33
fungicorvus: it's never too late, that joke is a true perl19:33
mordredmnaser: don't tempt me19:33
mnaserbecause if people werent confused enough about zuul and openstack19:33
mnaserzuulos will really drive that confusion19:33
mordredmnaser: maybe oszuul instead19:34
fungiit's a ci system, no it's a linux distro... stop--you're both right!19:34
mordredbut seriously ... WHY IS THIS TEST FAILING *headdesk*19:34
clarkbtime to hold a node?19:34
corvusmordred: which change are you looking at?19:34
corvusyou're looking at 330, right?19:35
mordredFailed to import the required Python library (setuptools) on debian-stretch-rax-ord-0017203635's Python /usr/bin/python.19:35
mordredcorvus: yes19:36
mordredcorvus: the stretch job19:36
corvushttps://review.opendev.org/736185 failed more spectacularly  :(19:36
mordredthat failure message ^^19:36
corvusthat's the build-release-python change19:36
mordredindicates that it's not using python319:36
corvusi'll take a look at 18519:37
fungiokay, so it's trying to run something like `/usr/bin/python3 -m venv /home/zuul/.local/tox` which is what's raising the error about failing to import setuptools with /usr/bin/python (not /usr/bin/python3)19:37
fungiWEIRD19:37
fungioh! specifically it's /tmp/ansible_pip_payload_PoyajU/ansible_pip_payload.zip/ansible/modules/packaging/language/pip.py which is trying to import pkg_resources19:38
clarkbah its the ansible pip module19:38
fungiso that's the pip module in ansible19:39
fungiyep19:39
mordredI have a really good solution to that19:39
fungiit's a "pip" action in the task, according to the console19:39
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Add option to install tox into a path location  https://review.opendev.org/73633019:40
mordredlet's just remove the use of the pip module19:40
mordredno added value19:40
mordredcorvus: I'm now joining yo on 18519:41
mordredcorvus: the ubuntu-bionic failure seems fun with unicode19:43
avassansible installs it's own pip module??19:43
corvusmordred: is it the case that the setup/distutils stuff we have just doesn't work under python2?  so maybe our test jobs should just run under python3?19:43
mordredcorvus: it would not surprise me at all19:43
mordredavass: well, it has a pip module for use in playbooks that tries to do pip things in python19:44
corvusmordred: i'm working on a patch19:44
avassmordred: sorry, I meant it installs it's onw pip when you use the pip module... strange19:44
corvusmordred: (that seems to jive what what zbr says, but it's possible someone is using this under python2 with some kind of local workaround, so i think we should stick with the announcement plan for changing the default)19:45
mordredavass: no, I don't think so - it's just expecting a global pip to work ... but if we don't hav eone19:45
*** jamesmcarthur_ has quit IRC19:45
mordredcorvus: I agree - as long as we can fix our jobs to work :)19:45
clarkbmordred: avass ya its using global pip even if operating in a virtualenv19:45
clarkbbut since we have a virtuaelnv and possibly no global pip we should explicitly operate in the venv instead19:46
mordredyeah19:46
avassmordred: oh yeah, I think I got confused since the pip modules name is literally 'pip.py'19:46
mordredavass: you and me both19:46
*** jamesmcarthur has joined #zuul19:46
openstackgerritJames E. Blair proposed zuul/zuul-jobs master: Ensure wheel exists for build-release-python  https://review.opendev.org/73618519:46
corvusmordred: take a look at that interpatchset diff and let me know if that looks good19:46
mordredclarkb: do we need the chmod? I think that's a thing that the pip install should handle, no?19:46
clarkbmordred: we may for the dirs above it but I don't thnk its a regression hence my +219:47
mordredcorvus: ++19:47
clarkbmordred: basically if /home/zuul is 700 or /home/zuul/.local is 700 we'd break19:47
clarkbmordred: the executable itself should be fine19:47
clarkbbut I think thats a followon cleanup since we were already doing the in venv install19:47
mordredclarkb: ++19:47
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Add option to install tox into a path location  https://review.opendev.org/73633019:47
* mordred fix whitespace issue that the linter gods will be displeased with19:48
mordredclarkb: mind re:+2ing19:48
clarkbdoine19:48
*** nils has quit IRC19:58
corvusmordred: can you +2 https://review.opendev.org/736327  and tobiash can you +2 https://review.opendev.org/736333 ?19:59
mordredcorvus: yes - but it's red19:59
corvusi can get those approved once the release jobs are fixed19:59
clarkbcorvus: if you're just looking for extra reviews I'm happy to review too20:00
corvusyeah, we're not landing anything until   https://review.opendev.org/736185 merges20:00
corvusclarkb: that'd be great thx20:00
corvusi figured if we can get the +2s lined up there, i can continue pushing that through20:01
openstackgerritTristan Cacqueray proposed zuul/zuul-jobs master: Add ensure pre-run policy to ansible-lint  https://review.opendev.org/73636720:01
mordredcorvus: also - if you're bored, https://review.opendev.org/#/c/73591020:01
corvusmordred: cool +2; i didn't bother +3ing; we should wait until the release job is fixed20:02
corvusi'm going to afk this afternoon; i'll check back in during the evening20:02
clarkbcorvus: done20:03
mordredclarkb: ++20:03
mordredcorvus: ++20:03
*** dennis_effa has quit IRC20:09
*** rlandy_ has joined #zuul20:09
*** decimuscorvinus_ has joined #zuul20:10
*** webknjaz_ has joined #zuul20:11
openstackgerritTristan Cacqueray proposed zuul/zuul-jobs master: phoronix-test-suite: extract ensure- role from run playbook  https://review.opendev.org/73636820:11
*** tobberydberg_ has joined #zuul20:12
*** tosky_ has joined #zuul20:12
*** tosky has quit IRC20:13
*** tosky_ is now known as tosky20:13
*** irclogbot_0 has quit IRC20:14
jktclarkb: this is on mnaser's Zuul instance where I don't have access to the logs. Anyway, I suspect something is fishy somewhere, for example I'm also not getting any jobs for an annotated tag pushed to refs/tags/, etc20:17
clarkbmordred: corvus (and all other zuulians) the community update on the 25th that is running on a more apac friendly schedule (7pm pacific I think thtas like 0200 UTC) is actually being done in english and we are being asked if we hvae any volunteers to do that one. I've told the foundation I can do it if we don't have non staff volunteers20:17
*** tobberydberg has quit IRC20:18
*** rlandy has quit IRC20:18
*** decimuscorvinus has quit IRC20:18
*** webknjaz has quit IRC20:18
*** mgoddard has quit IRC20:18
*** mrcirca has quit IRC20:18
*** rlandy__ has joined #zuul20:18
*** webknjaz_ is now known as webknjaz20:18
fungijkt: the usual triggers for tags only fire on signed tags20:19
*** rlandy_ has quit IRC20:19
avasstristanC: fiy, I added tests to the linting rules in test-playbooks/ansible-lint-rules20:20
fungijkt: might be how it's set up there too20:20
*** mgoddard has joined #zuul20:21
mnaseroh20:21
mnaserinteresting20:21
mnaserAttributeError: 'Tag' object has no attribute 'number'20:21
jktmnaser: we're using the "v" prefix20:22
*** irclogbot_3 has joined #zuul20:22
jktfungi: that's... undocumented as far as I can tell20:22
mnaserhttps://www.irccloud.com/pastebin/YYfyoZQr/20:22
clarkbjkt: fungi: it depends entirely on how the pipeline is configured20:23
clarkbmnaser: ya tags don't have a change number they are just refs20:23
clarkbmnaser: jkt can you share the pipeline config?20:23
mnaseri mean, i guess it still shouldn't throw a traceback but20:23
mnaserlet me pull it out20:23
clarkbmnaser: well its probably misocnfigured20:23
clarkbmy hunch is you're using change attributes on the pipeline config20:24
clarkband so its a mismatch between expected input and asserted config20:24
clarkb(I remember this happening a bit way back in the gozer days)20:24
jktit would be nice if Zuul made the tenant config available over its API20:24
tristanCavass: nice, i'll have a look. in the meantime there are some non pre- playbooks that include ensure-* roles we need to fix if we want the rule to be valid.20:24
jktuse case: a managed service where I don't have access to that20:25
mnaserhttps://www.irccloud.com/pastebin/9JRXPcrD/20:25
clarkbjkt: I think the intent is that the configs should be public (secrets are encrypted), but I agree that could be helpful20:25
jktmnaser: it's using "dependent" pipeline manager, is there a reason for that?20:25
avasstristanC: and you might want to do ZUUL0003, I'll try to finish https://review.opendev.org/#/c/727642/1020:25
clarkbmnaser: the manager is the problem I think20:26
clarkbdependent implies merging because it wants to sequence things in sepculative fashion20:26
jktmakes sense20:26
mnaserprobalby an oversight here.  is there a way we can user-friendl-ify this inside zuul?20:27
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Add linting rule to enforce no-same-owner policy  https://review.opendev.org/72764220:27
clarkbmnaser: we could probably have some heuristics to emit warnings, but I don't think we can make it foolproof without making the gerrit (and github etc) input types way more strict in their semantics20:28
mnaseryeah given its event based it's probably hard to detect20:28
clarkbmnaser: ya its an external input and zuul does its best to accomodate them as they change over time20:29
mnaserjkt: you're good, changed the manager20:29
*** jamesmcarthur has quit IRC20:31
*** jamesmcarthur has joined #zuul20:32
jktclarkb: can you imagine a use case where "dependent" is used along ref-updated gerrit trigger?20:34
*** dcastellani has quit IRC20:35
clarkbjkt: not with gerrit at least.20:36
clarkbbut refs don't have to be tags20:36
clarkbso it could be a thing in some system20:37
*** jamesmcarthur has quit IRC20:37
jktI think this should be an easy diagnostics -- apparently "dependent" likes changes in gerrit, PRs in github, etc20:37
jktlet me sort out our project's releae piepeline first and then propose a diagnostics for this one20:38
clarkbya dependent wants pre merge input however that is expressed by the driver20:39
*** rlandy__ is now known as rlandy20:39
*** iamweswilson has quit IRC20:40
*** iamweswilson has joined #zuul20:40
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Add option to install tox into a path location  https://review.opendev.org/73633020:42
mordredclarkb, avass: doh. had to update the test playbook too20:42
mordredclarkb: didn't we purposefully set up a dependent post-merge pipeline in opendev?20:42
mordredbefore the serial manager existed?20:43
*** webknjaz has quit IRC20:43
clarkbmordred: supercedent?20:43
mordredclarkb: I think I might be hallucinating20:44
*** iamweswilson has quit IRC20:44
*** webknjaz has joined #zuul20:46
*** iamweswilson has joined #zuul20:46
*** PrinzElvis has quit IRC20:49
*** webknjaz has quit IRC20:51
*** PrinzElvis has joined #zuul20:53
*** webknjaz has joined #zuul20:57
*** PrinzElvis has quit IRC20:57
*** iamweswilson has quit IRC21:01
*** jamesmcarthur has joined #zuul21:04
*** webknjaz has quit IRC21:06
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Add linting rule to enforce no-same-owner policy  https://review.opendev.org/72764221:07
*** rfolco|rover has quit IRC21:12
*** noonedeadpunk has quit IRC21:12
*** jamesmcarthur has quit IRC21:13
jktmnaser: can you please check if there was something wrong with my recent push of v2.2a3? I've fixed some config errors on my side, these were reported as CONFIG_ERROR, that's OK, but I don't have any result for this one, and it also wasn't visible in the status UI21:14
openstackgerritAhmad Mahmoudi proposed zuul/zuul-jobs master: (fix) Changed pip to pip3  https://review.opendev.org/73637921:16
openstackgerritTristan Cacqueray proposed zuul/zuul-jobs master: Add ensure pre-run policy to ansible-lint  https://review.opendev.org/73636721:19
mnaserjkt: probably best to take them to a support ticket for now as i have to run out in a sec21:19
jktmnaser: ok, will do. Thanks for your quick fix!21:21
*** harrymichal has quit IRC21:28
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Add option to install tox into a path location  https://review.opendev.org/73633021:31
mordredclarkb, fungi: sorry - syntax error21:31
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Fix ansible-lint rules tests  https://review.opendev.org/73638721:34
avassmordred: todays not your day :)21:34
*** PrinzElvis has joined #zuul21:35
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Add linting rule to enforce no-same-owner policy  https://review.opendev.org/72764221:35
mordredavass: it's really not21:36
mordredavass: stupid indentation21:36
fungi"this end should point toward the ground if you want to go to space. if it starts pointing toward space you are having a bad problem and will not go to space today"21:36
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Fix ansible-lint rules tests  https://review.opendev.org/73638721:37
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Add linting rule to enforce no-same-owner policy  https://review.opendev.org/72764221:37
*** dcastellani has joined #zuul21:37
avassalso, I noticed that the tests for the linting rules that was supposed to fail were failing but not the way we want to https://review.opendev.org/73638721:38
openstackgerritGuillaume Chauvel proposed zuul/zuul master: tutorial: Add "gate your first patch"  https://review.opendev.org/73206721:39
openstackgerritGuillaume Chauvel proposed zuul/zuul master: tutorial: Add "Use zuul jobs"  https://review.opendev.org/73206821:39
openstackgerritGuillaume Chauvel proposed zuul/zuul master: tutorial: Add "gate pipeline"  https://review.opendev.org/73206921:39
openstackgerritGuillaume Chauvel proposed zuul/zuul master: tutorial: Add "job secrets"  https://review.opendev.org/73207021:39
openstackgerritGuillaume Chauvel proposed zuul/zuul master: tutorial: Add "job dependencies"  https://review.opendev.org/73207121:39
*** iamweswilson has joined #zuul21:40
*** webknjaz has joined #zuul21:40
mordredfungi: ++21:50
*** jamesmcarthur has joined #zuul21:50
*** hashar has quit IRC21:52
mordredfungi, clarkb, avass, corvus: https://review.opendev.org/#/c/736185/ is still failing. investigating21:52
*** sanjayu_ has quit IRC21:52
mordredfungi: I think perhaps when we install wheel, we should also install setuptools21:53
mordredfungi: https://zuul.opendev.org/t/zuul/build/20152d87d3b342cbb738f98acf7eea45/log/job-output.txt#29621:53
mordredoh - well - I mean21:54
mordredsigh21:54
*** jamesmcarthur has quit IRC21:54
mordredwe need to run the setup role in a pre playbook if the role test is supposed to work21:55
avass:)21:55
avassmordred: also, shouldn't ensure-wheel default to 'python' and not python3 if that's the way build-python-release works?21:55
*** tosky has quit IRC21:56
*** tosky has joined #zuul21:56
mordredavass: probably so, yes21:57
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Fix ansible-lint rules tests  https://review.opendev.org/73638721:58
mordredavass: oh - no, because in the playbook when we're using it for build-python-release we set the value to default to release_python21:58
mordredso that it'll behave like build-python-release ... but so that we can also add the new role correctly defaulting to python321:59
*** rlandy is now known as rlandy|bbl21:59
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Ensure wheel exists for build-release-python  https://review.opendev.org/73618521:59
mordredI think this should fix it21:59
avassmordred: oh... yeah that's slightly confusing :)22:00
mordredavass: yeah ... it's not awesome. hopefully we'll get that default changed soon22:00
openstackgerritMerged zuul/zuul-jobs master: Add option to install tox into a path location  https://review.opendev.org/73633022:05
mordredwoot22:11
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Fix ansible-lint rules tests  https://review.opendev.org/73638722:13
*** armstrongs has joined #zuul22:21
mordredavass, clarkb, fungi, corvus: https://review.opendev.org/#/c/736185/ is green! please to approving22:24
openstackgerritAlbin Vass proposed zuul/zuul-jobs master: Add linting rule to enforce no-same-owner policy  https://review.opendev.org/72764222:29
*** armstrongs has quit IRC22:30
avassmordred: lgtm, but it's getting late so I'll let someone else approve it in case I missed something obvious22:30
mordredavass: tyty22:31
ianwmordred: sorry, i got a bit lost in scrollback, is there something i need to look at wrt ensure-pip etc madness?22:31
mordredianw: I think it's under control - but ...22:32
mordredianw: if you get a minute - it would be good to have you look at a few just to make sure we didn't miss something obvious22:32
ianwok i have to do school run and will pull everything up in about 15 mins22:32
mordredianw: https://review.opendev.org/736185 https://review.opendev.org/73633022:33
mordredianw: those are the two biggies22:33
mordredianw: https://review.opendev.org/#/c/736334 is the motivation for 736330 - there were release jobs that needed tox inside of scripts22:33
mordredanyway - I think that should all be in good shape22:34
fungiscripts which were all like, "hey i'll just run tox... why isn't there a tox in my path?"22:34
fungisurprising how entirely not simple "i just want to run tox" turns out to be sometimes ;)22:35
*** _erlon_ has joined #zuul22:40
avasscan we merge https://review.opendev.org/#/c/736387/ ? the tests for the custom ansible-lint rules has been failing since we upgraded ansible-lint22:45
clarkbavass: looking22:46
clarkblgtm22:46
openstackgerritMerged zuul/zuul-jobs master: Ensure wheel exists for build-release-python  https://review.opendev.org/73618522:48
*** tosky has quit IRC23:09
ianwmordred: why did we choose not to install the packages for wheel?23:16
ianwtbh i would have considered it a pretty reasonable thing to just add to the package list for ensure-pip and skip separate roles23:17
fungithe ensure-wheel role seems like it wants to possibly install without root privs, not sure if that had anything to do with it23:23
fungigranted the original https://review.opendev.org/736001 also used pip, but the reason it got reverted is that it needed root access23:25
fungimaybe putting the distro package addition into a pre play would have sufficed though23:26
ianwi thought we decided that "ensure" roles could install stuff with root as required, but should not need sudo on the no-op path23:42
ianwwe have a mix of things installing packages, installing into user areas, installing into user areas and creating a /usr/local/bin/ symlink as root23:44
fungiit's a good question. as things stabilize we can rework stuff for better consistency23:47
fungiwe're also finding that some of our actual roles relied on ansible's pip module, which doesn't work if setuptools (or at least pkg_resources) isn't already installed23:49
fungis/actual/existing/23:49
clarkb*isn't already installed in the global pip23:49
clarkbit was there in the virtualenv we were trying to operate in23:49
clarkbbut it uses global pip to operate in virtuaelnvs23:49
ianwright, that's why "ensure-pip" says that it installs everything required to run the ansible "pip:" module ...23:50
clarkbianw: I think that didn't happen in this case23:50
clarkbbut I could be wrong about that23:50
ianwclarkb: right, well i'd consider it a bug ... "This role is intended install the requirements for the pip module on hosts." is the first line of the README :)23:51
clarkbianw: 19:29:16*         mordred | ensure-tox is calling ensure-pip already ... but I think then it's installing tox into a puython -m venv23:51
clarkbya could be the more proper fix was to fix ensure-pip if it indeed failed to make pip module function23:52
ianwensure-tox was another one of these that was installing --user23:52
ianwthat breaks in situations such as system-config running testinfra where we want tox as root23:52
ianwi can see an argument that there's much less likelyhood of needing to run "wheel" in a root/non-zuul user context23:53
fungiwell, except insofar as pip installing an sdist these days uses the wheel module to first build a wheel from the sdist and then install the resulting wheel23:54
ianw... why i think that that probably adding wheel to "ensure-pip" isn't overreach of the role, they're pretty closely linked23:55
fungiyeah23:56

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