Wednesday, 2017-08-23

dmsimardthe network overlay config patch is passing, so yay ? https://review.openstack.org/#/c/435933/00:06
dmsimardI haven't done any other change other than rebasing and addressing comments, I'd get involved in the playbook/role syntax but meh00:07
dmsimardI don't like the mixed style of yaml/ansible where sometimes things are proper yaml dicts and sometimes "=" are used across the same set of things00:07
fungiyamsible01:05
openstackgerritJesse Keating proposed openstack-infra/zuul-jobs master: Role to copy the build ssh key to other users  https://review.openstack.org/49641301:23
dmsimardfungi: hah, yamsible. That should be a thing.01:50
clarkbdmsimard: I think the dvr job which failed is the one that exercises that code the most but I also think its expected to fail for reasons unrelated to devstack-gate :02:07
clarkber :/02:07
*** weshay is now known as weshay_PTO_AM02:37
*** xinliang has joined #zuul02:44
*** xinliang has quit IRC02:44
*** xinliang has joined #zuul02:44
*** bhavik1 has joined #zuul03:56
*** bhavik1 has quit IRC04:39
*** mordred has quit IRC05:02
*** adam_g has quit IRC05:02
*** jtanner has quit IRC05:02
*** mattclay has quit IRC05:02
*** mordred has joined #zuul05:03
*** mattclay has joined #zuul05:03
*** adam_g has joined #zuul05:04
*** jtanner has joined #zuul05:31
*** isaacb has joined #zuul06:19
*** isaacb has quit IRC07:13
*** isaacb has joined #zuul07:22
*** amoralej|off is now known as amoralej07:46
*** openstackgerrit has quit IRC08:03
*** SotK has quit IRC08:48
*** SotK has joined #zuul08:49
*** electrofelix has joined #zuul09:00
*** jkilpatr has quit IRC10:42
*** isaacb has quit IRC10:44
*** jkilpatr has joined #zuul11:19
*** openstackgerrit has joined #zuul11:58
openstackgerritMerged openstack-infra/zuul-jobs master: Install build private key too  https://review.openstack.org/49430211:58
openstackgerritMerged openstack-infra/zuul-jobs master: Add known_hosts generation for multiple nodes  https://review.openstack.org/49470012:00
mordredShrews: what theheck is up with that py35 test?12:08
Shrewsmordred: no clue. timeout somewhere12:08
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Re-enable test_delayed_repo_init  https://review.openstack.org/49365912:10
Shrewsmordred: i've been seeing random timeouts in other places. maybe a slow vm?12:11
Shrewsjeblair's devstack-gate changes look good except for https://review.openstack.org/49642212:13
*** bhavik1 has joined #zuul12:26
Shrewsjeblair: i just left an additional comment on https://review.openstack.org/496422 about the var there. Based on my experience with the shade test ansible roles, I don't think you need to define the devstack_base_dir again. Then again, you're placing it under 'defaults' and shade uses 'vars', so that *might* make a difference as far as scope.12:26
Shrewsansible var scoping is quite confusing  :/12:27
pabelangermorning!12:29
mordredShrews: yah - in this case defaults is more like python keyword arguments12:29
pabelangerShrews: ya, not a fan of it myself. I think puppet does a better job in that case12:30
mordredShrews: it defines the variable for the role if nothing else defines it12:30
mordredShrews: so if someone uses that role without passing a parameter and without first using setup-devstack-log-dir, the value in defaults will hold12:30
mordredShrews: (we should probably switch to using defaults in our shade test roles fwiw)12:31
Shrewsmordred: right. but since those roles are contained to devstack-gate, would we ever have a need to call the fetch role w/o the setup role?12:31
Shrewspre.yaml is always calling setup12:31
Shrewsand post.yaml is always calling fetch12:31
Shrewsi mean, it doesn't hurt to leave it. just wanted to mention it in case jeblair thought it might be worth simplifying it a bit.  :)12:32
mordreddoubtful - I think defining it in defaults is a belt/suspenders/style rather than stricly necessary in this case12:32
mordred++12:32
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Merge branch 'master' into feature/zuulv3  https://review.openstack.org/49669012:35
mordredjeblair, pabelanger: ^^ that's a merge up with master - I null-merged one change but mentioned that in the commit message12:36
dmsimardmordred: had you seen my comment in https://review.openstack.org/#/c/494700/ ?12:38
pabelangermordred: Nice12:39
mordreddmsimard: ah - I missed it, sorry - but the reason we're doing the thing with the module is that we already have the hostkeys and we know that they are valid/accurate12:39
mordreddmsimard: doing keyscan would mean we'd have to just trust what we get over the wire at that moment which we're actually in a position to avoid needing to do in our case12:40
pabelangermordred: left comment12:40
dmsimardmordred: ok, it seemed to me the keys were retrieved by Ansible facts and so wasn't any more reliable12:41
mordreddmsimard: right - but those are retrieved over an ssh connection that we've already validated since we store hostkeys from nodepool into the executors known_hosts - then the executor ssh's into the nodes for gather_facts and collects the host_key over that connection - rather than hitting the ip and fetching the hostkey from that interaction12:42
dmsimardOk, and facts will *always* be gathered ? If so, that's ok :)12:43
mordredthey will in our case - we have fact gathering set up to run once at the top and cache12:44
dmsimardAck12:44
mordredpabelanger: yah - we've been waiting to delete that file until we freeze master to keep it easy to merge12:44
mordredpabelanger: but I'd love to delete that file because it shows up in my git grep for things :)12:44
Shrewsmordred: pabelanger: the last 3 timeout test failures (for nodepool) that I've looked at have all been on rax nodes. any known issues there?12:46
mordredShrews: not that I'm aware of, but I'm not aware of things12:46
Shrewsoh, just hit something on chocolate now. hrm, lots of instability12:47
pabelangerShrews: got log?12:47
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Remove zuul 2.5 specific files  https://review.openstack.org/49669312:47
pabelangerShrews: we are having some networking issues there12:47
mordredpabelanger: but there you go as a followup ^^12:47
Shrewspabelanger: recent chocolate: http://logs.openstack.org/51/496251/1/check/nodepool-coverage-ubuntu-xenial/ba35e9a/12:48
pabelangermordred: +2 to both12:48
Shrewspabelanger: rax: http://logs.openstack.org/51/496251/1/check/gate-nodepool-python35/734cde5/console.html12:48
pabelangerShrews: rax timed out. looks like testr died or was just running slow12:49
pabelangersame with infracloud, but zookeeper maybe died?12:49
* Shrews blames post-eclipse sun particles12:52
*** bhavik1 has quit IRC13:09
Shrewsugh, the py35 job is going to timeout _again_13:09
mordredShrews: jeez13:11
pabelangermordred: okay, so hoping to finish up twine testing this morning. Just waiting for jeblair to review: https://review.openstack.org/496450/ Once landed and testing works, I'll move on to testing with gpg key13:22
pabelangermordred: this afternoon, I guess I'll then move into devstack-gate things13:22
*** amoralej is now known as amoralej|lunch13:27
*** amoralej|lunch is now known as amoralej14:12
dmsimardmordred: I fixed up https://review.openstack.org/#/c/495929 and https://review.openstack.org/#/c/495928 -- they should be good to go14:25
dmsimardclarkb: you're right about that dvr job, it seems like it's just failing all the time and not just on the overlay patch14:26
dmsimardI'll try and rope in an expert14:26
jeblairpabelanger: -1 on 49645014:42
jeblairmordred: are you working on the merge resolution to 254957?14:45
jeblairpabelanger: why is it okay to merge 496690 without a resolution to 254957?14:46
dmsimardclarkb: how would you feel about taking out that dvr job (which is >90% failures http://i.imgur.com/fvTwrfG.png ) and adding "gate-tempest-dsvm-neutron-dvr-ubuntu-xenial" which is voting in tempest ?14:48
dmsimardThe tempest job isn't HA so it's not as good as an exercise but at least it can be relied on14:49
pabelangerjeblair: re: 496450. Okay, I understand your comment, I've had that issue in the pass and I'll refactor common bits into roles. Would you also like a more discriptive playbook name? I've just been defaulting to pre.yaml / run.yaml / post.yaml for filename14:50
jeblairpabelanger: i think naming the playbook for the job is fine if we use it that way.  if we started reusing them like roles, we'd have to make them more descriptive, like roles i think.  but my preference for this would be the role refactor and simple playbooks.14:52
pabelangerjeblair: okay, maybe at PTG we can talk about about reusing playbooks across jobs also. I'll make the changes now to continue moving forward14:54
jeblairpabelanger: i'm not completely -2 on playbook reuse, but i think we have to have good answers to questions like why it makes things easier to use/understand, as compared to roles.  the thing i'm most worried about is ending up with spaghetti.14:58
jeblairpabelanger: so yeah, good topic of conversation.  :)14:58
clarkbdmsimard: we need a dvr + multinode job to test the overlay properly. Is there a non ha dvr multinode job we can use?14:58
dmsimardclarkb: hm, dunno /me looks14:58
clarkbdmsimard: the reason for that is with dvr each instance terminates l3 so we actually get traffic over our overlay14:59
clarkbwithout dvr neutron just backhauls everything on the controller gor itself14:59
dmsimardclarkb: yeah, makes sense15:01
dmsimardclarkb: only other dvr multinode job I see is gate-grenade-dsvm-neutron-dvr-multinode-ubuntu-xenial15:01
dmsimardit's voting in neutron15:01
clarkbif the tempest tests grenade runs ssh into instances I think that job is sufficient15:02
clarkbmtreinish would probably know15:02
dmsimardclarkb: yeah it does, it runs tempest too http://logs.openstack.org/38/496438/2/check/gate-grenade-dsvm-neutron-dvr-multinode-ubuntu-xenial/afee022/logs/stackviz/#/stdin/timeline15:03
openstackgerritJames E. Blair proposed openstack-infra/zuul master: Add .zuul.yaml  https://review.openstack.org/49678815:04
openstackgerritPaul Belanger proposed openstack-infra/zuul-jobs master: Add fetch-python-sdist-output role  https://review.openstack.org/49678915:05
dmsimardclarkb: I'll go ahead and propose a patch to substitute those two jobs15:08
clarkbdmsimard: maybe move the ha job to experimental15:09
dmsimardclarkb: sure15:09
dmsimardclarkb: oh would you look at that15:09
dmsimardclarkb: there's already gate-tempest-dsvm-neutron-dvr-multinode-full-ubuntu-xenial-nv in experimental15:09
pabelangerjeblair: okay, 496450 updated per your comments. Do you mind confirming15:10
jeblairpabelanger: lgtm15:33
jeblairmordred: more missing output: http://logs.openstack.org/42/496442/3/check/devstack-lxc/2533fb0/job-output.txt.gz#_2017-08-23_15_36_37_076438  those two tasks emit output (shows up in json, not text log)15:42
mordredjeblair: that's really weird content to miss15:46
jeblairpabelanger: want to +3 496788?15:48
jeblair(it's a master change)15:49
pabelangerjeblair: done!15:49
pabelangerya, too me a second to see that15:49
openstackgerritMerged openstack-infra/zuul master: Add .zuul.yaml  https://review.openstack.org/49678815:54
SpamapSooooooooooo15:56
SpamapSneat15:56
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Only depend-on open changes  https://review.openstack.org/49680815:58
mordredjeblair: ^^ I think that's it - I thought it was going to be worse than that15:58
jeblairmordred: cool15:59
jeblairmordred: any chance Failure using method (v2_playbook_on_task_start) in callback plugin (<ansible.plugins.callback.zuul_stream.CallbackModule object at 0x7f883755cc50>): 'CallbackModule' object has no attribute 'play'"  is related?15:59
pabelangerhttps://review.openstack.org/496789/ could use a +3 Adds fetch-python-sdist-output role.16:00
mordredjeblair: yah - maybe so16:00
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: The play object is at self._play not self.play  https://review.openstack.org/49681016:03
mordredjeblair: ^^16:03
mordredjeblair: thank you - that would be the issue16:03
openstackgerritMerged openstack-infra/zuul-jobs master: Add fetch-python-sdist-output role  https://review.openstack.org/49678916:03
jeblairmordred: cool, i'm working on a simple test, i'll stack it on that change to verify the fix16:06
mordredjeblair: cool16:07
*** jkilpatr has quit IRC16:08
SpamapSwow.. the OpenSSH auth keys file format is...16:20
SpamapSdiabolically weird16:20
SpamapS"The options field is optional; its presence is determined by whether the line starts with a number or not (the options field never starts with a number)"16:20
SpamapSBut neither do any of the other fields so..... ?16:20
openstackgerritMerged openstack-infra/zuul feature/zuulv3: The play object is at self._play not self.play  https://review.openstack.org/49681016:22
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Add a test to verify basic console output  https://review.openstack.org/49682416:23
jeblairmordred: that did not seem to fix it ^  :(16:24
*** weshay_PTO_AM is now known as weshay16:25
jeblairmordred: (it did fix the warning; but it did not fix the lack of output)16:31
mordredjeblair: ok. I'm about to lunch, I'll dig in to try to find/fix that after lunch16:31
jeblairmordred: cool thx16:32
jeblairmordred: oh, hrm, i wonder if the test is invalid due to lack of zuul_console16:33
pabelangerjeblair: mordred: interested with the following: http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.yaml#n173 playbook/publish/pypi ran first, then python-tarball/post: http://logs.openstack.org/42/91893a0d643e02704ad8c8c6ec86aacfd03bad42/release/release-openstack-python/fbab54c/job-output.txt.gz16:37
pabelangerI would have expected the other way around16:37
jeblairpabelanger: i agree16:38
pabelangerjeblair: do you have an idea where I should look to fix?16:39
pabelangerI can reverse the playbooks for testing too16:39
jeblairpabelanger: don't reverse the playbooks, fix zuul16:40
jeblairpabelanger: that'll be in configloader16:40
pabelangerk, looking now16:40
*** jkilpatr has joined #zuul16:53
*** dkranz has joined #zuul17:01
* SpamapS may have found a doc bug in sshd's AUTHORIZED KEY FILE FORMAT section ....17:12
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Add a test to verify basic console output  https://review.openstack.org/49682417:13
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Add a test to verify basic console output  https://review.openstack.org/49682417:15
jeblairmordred, Shrews: ^ okay, that doesn't do anything to verify streaming output, but it does verify output over localhost.  it also, i think, fixes a bug which was causing us not to see any output from localhost.17:16
* SpamapS finds the bottom of the rathole17:16
openstackgerritPaul Belanger proposed openstack-infra/zuul feature/zuulv3: Ensure post-run playbooks are ordered correctly  https://review.openstack.org/49683317:16
jeblairi can't imagine the bottom of a rathole is pleasant17:16
pabelangerjeblair: ^ I believe that fixes our issue. Review most welcome17:17
jeblairpabelanger: yeah, that looks right to me, assuming the tests agree :)17:18
jeblairSpamapS: ^ agree with pabelanger's change?17:19
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Only depend-on open changes  https://review.openstack.org/49680817:22
mordredjeblair: that looks great17:26
mordredjeblair: (the log one)17:26
jeblairmordred: cool.  i think we could also check the ansible connection method instead of defaulting that to localhost.  <shrug>17:27
mordredjeblair: also, ugh. thank you for the comma17:27
jeblairnp. easier than typing that out :)17:27
SpamapShttps://github.com/ansible/ansible/pull/28449#pullrequestreview-58152542 <-- the bottom of the ssh rathole btw17:27
SpamapSjeblair: looking17:27
jeblairSpamapS: wow yeah that looks like it was "fun"17:29
* mordred hands SpamapS a bundt cake17:29
SpamapSa cake, with a hole in it!17:29
SpamapSso yes I agree with the way the tests turn out in 496833 ...17:30
SpamapSI'm not entirely sure I grasp why reversed() is needed.17:30
SpamapSbut the test shows the result I would expect.17:30
SpamapSshall I +A?17:30
mordredI +Ad17:30
SpamapSyay17:30
SpamapSthe old +6+A17:31
jeblairSpamapS: yeah, i mostly wanted to make sure that matched other folks expectations17:31
mordredjeblair: ok - the backport patch broke all the scheduler tests - I'm gonna say that means there's something wrong with it17:33
jeblairmordred: pyflakes says there's still some problems17:34
jeblairbut yeah, it's starting to look like there's more to it after that17:35
mordredjeblair: I thikn I see it17:36
mordredjeblair: boolean swap when I ported the change17:37
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Only depend-on open changes  https://review.openstack.org/49680817:37
mordredjeblair: it was suposed to go from not dep.is_merged to dep.open - but  it went to not dep.open instead :)17:38
jeblairmordred: aha, of course17:38
jeblairmordred: still need to fix the pyflakes stuff17:38
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Ensure post-run playbooks are ordered correctly  https://review.openstack.org/49683317:38
*** electrofelix has quit IRC17:40
mordredjeblair: fixed17:41
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Only depend-on open changes  https://review.openstack.org/49680817:42
jeblairmordred: lgtm; assuming that passes i'll add 4 points to my review of the merge commit :)17:43
mordredjeblair: \o/17:43
pabelangerjeblair: mordred SpamapS: We'll need restarts for 496833. Do we need anything else?17:47
mordredpabelanger: jeblair's test for logging17:49
jeblairyeah, since it became more than just a test but also a fix17:49
mordredpabelanger: 496824 which has also afunctional fix17:49
SpamapSFYI, update on the python bug, doko rejected my upload to add another SRU patch in another upload. The SRU team should still get to it in the next few days.17:51
mordredSpamapS: thanks17:51
pabelangermordred: lgtm +317:51
pabelangerI wasn't smart enough to figure out attachements for testr17:51
pabelangerit would be cool if we had the job-output.txt there17:52
mordredjeblair: https://review.openstack.org/#/c/496808 came back green17:56
jeblairpabelanger: BaseTestCase.attachLogs has the magic.  but maybe let's spruce that up after ptg.17:57
pabelangerjeblair: ++17:58
jeblairmordred: i +3d the whole stack17:58
mordredjeblair: woot17:58
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Add a test to verify basic console output  https://review.openstack.org/49682417:59
mordredpabelanger: ^^ k. I think we're good to restart things now18:03
pabelangerk, let me confirm puppet updated things18:04
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Merge branch 'master' into feature/zuulv3  https://review.openstack.org/49669018:07
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Remove zuul 2.5 specific files  https://review.openstack.org/49669318:07
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Only depend-on open changes  https://review.openstack.org/49680818:07
pabelangermordred: should we do that for nodepool too?^18:08
jeblairpabelanger: how about i manually update and restart?18:08
pabelangerjeblair: yes please18:08
pabelangerjeblair: mordred: another thing related to nodepool. Will we need to bring more nodepool-launchers online for PTG?18:09
jeblairze01 restarted18:09
dmsimarddo we want to ansibilize fix_disk_layout ? https://github.com/openstack-infra/devstack-gate/blob/a33308eb3b11a0121f69ca4db11e692d999c60fa/functions.sh#L30618:11
jeblairpabelanger: yes, we will want to have the full nodepool system up and running for ptg18:11
jeblairdmsimard: yes -- in fact, that's the next thing we'll need.  i think the way we may want to do that is start by just putting it in a role as a verbatim shell script.  then it can evolve into being more ansible-ish as warranted (though that, or at least large parts of it, may benefit from remaining as shell -- i'm not sure ansible would make that clearer)18:14
dmsimardjeblair: if no one's working on that, I can take a stab at it -- it's in the way of splitting more stuff out ( setup_workspace https://github.com/openstack-infra/devstack-gate/blob/a33308eb3b11a0121f69ca4db11e692d999c60fa/functions.sh#L485 )18:15
jeblairdmsimard: i think that would be swell.  as soon as you do that, we can add it to the nascent devstack job, since that needs to happen basically right at the start18:16
dmsimardokay, on it.18:16
pabelangerjeblair: okay, I've made note of it18:17
pabelangerjeblair: do we need to restart scheduler for 496833?18:26
mordredpabelanger: yah18:27
pabelangerokay18:28
pabelangerokay, zuulv3.o.o restarted18:34
mordred\o/18:34
pabelangermordred: I see this warning for callback pluging: http://paste.openstack.org/show/619210/18:39
dmsimardthat reminds me, it really sucks to troubleshoot callbacks right now -- apparently they've made it better in 2.4 so the actual trace/exception bubbles up18:41
pabelangermordred: also, do you think it make sense to move pip install twine outside of upload-pypi? I have a path issue, and figured do the same logic like the bindep and tox roles, where we expect the executable to be setup before hand18:42
openstackgerritPaul Belanger proposed openstack-infra/zuul-jobs master: Create pypi_twine_executable  https://review.openstack.org/49684318:44
openstackgerritClint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: Re-enable test_merge_conflict_reports  https://review.openstack.org/46867019:00
*** tobiash has quit IRC19:04
*** tobiash has joined #zuul19:11
openstackgerritPaul Belanger proposed openstack-infra/zuul-jobs master: Create pypi_twine_executable  https://review.openstack.org/49684319:22
pabelangerjeblair: mordred: mind looking at https://review.openstack.org/496843/ and https://review.openstack.org/496844/ I am blocked on testing pypi uploads19:22
*** olaph1 has joined #zuul19:41
*** olaph has quit IRC19:41
jeblairpabelanger: why didn't the old twine thing work?19:53
pabelangerjeblair: path issue finding twine19:53
pabelangerwe'd likely need to add ~/.local/bin into PATH variable19:54
jeblairpabelanger: because pip install --user didn't put it into $PATH  gotach19:54
jeblairgotcha19:54
pabelangerya, that is what I am thinking19:54
jeblairokay.  i wonder what --user is for then.  the manpage is no help on the manner "Install using the user scheme".19:55
pabelangeryou mean pip install --user?19:57
jeblairpabelanger: yes19:57
jeblairpabelanger: -1 on 496844 +2 on the other19:57
pabelangerjeblair: I've always thought --user just installs things into the ~/.local path19:57
jlkgood morning again.19:59
jlkwhat's the haps?19:59
pabelangerjeblair: replied with question20:00
jeblairjlk: o/20:00
jeblairpabelanger: i like the install if not installed option.  that lets us easily add it to the executors later for efficiency.20:01
jeblairpabelanger: if that's too hard, always install is fine for now20:01
jeblair(i just thought maybe we had examples we could copypasta)20:02
pabelangerlet me look quick, I don't think we do20:02
jeblairpabelanger: tox?20:02
jlkany high priority changes needing reviews?20:03
pabelangerjeblair: no, it has the same bug too20:03
pabelangerso, we'd need to fix that20:03
pabelangerlet me take a stab20:04
openstackgerritMerged openstack-infra/zuul-jobs master: Role to copy the build ssh key to other users  https://review.openstack.org/49641320:06
openstackgerritMerged openstack-infra/zuul-jobs master: Add support for gzipping static ARA reports  https://review.openstack.org/49555120:07
mordredpabelanger, jeblair: so the --user thing putting into ~/.local is bong because we don't have ~/.local/bin in PATH?20:11
Shrewsmordred: so that random nodepool gate-nodepool-python35 failure... turns out when i run 'tox -epy35' locally, it's actually using 3.6 (i don't have 3.5). I wonder if python version matters here with the failure....20:15
mordredShrews: oh. well ...20:15
clarkbtox should actually fail in that case20:15
mordredShrews: that would be "fun"20:15
clarkband complain that you don't hae the right interpreter available20:16
mordredclarkb: we have "basepython=python3" in the tox.ini testenv ...20:16
clarkboh uh why?20:16
mordredShrews, clarkb: maybe we should remove that and put it in specifically for the pep8 job20:16
clarkbI would put it in eg pep8 but not in base20:16
mordredclarkb: so that pep8 also goes under py320:16
Shrewsalso need it for coverage, but can duplicate it there20:16
clarkbthat way the env specific targets all work as expected20:16
clarkbor you can spell out all the env specific ones and override I guess20:17
mordredI think there might be a way to tell a tox env to be based on another one ... looking real quick20:17
Shrewsoh, well neat. i just got it to hang locally... and zookeeper is definitely running, so can rule that out. i think we have something wonkers in our tests20:18
mordredShrews: woot20:19
pabelangermordred: ya, see remote:   https://review.openstack.org/496844 Set pypi_twine_executable for upload-pypi role now20:20
pabelangerI think that is more complex, but gives use ability to add twine to executors later20:21
mordredcool20:21
pabelangerhopefully that is all we need to test the upload20:22
*** jkilpatr has quit IRC20:22
pabelangereverything else looked good20:22
mordred++20:22
mordredpabelanger: out of curiosity - when you do pre_tasks/post_tasks in project-config playbooks, is that just expediency for doing a thing right now and we can do a role refactor later?20:24
mordredpabelanger: (mostly asking because I'm happy to follow up with some role patches as we go, but don't want to be counter productive)20:24
jlkI think it also causes handlers to trigger20:24
mordredjlk: using pre-tasks vs. roles does?20:24
pabelangermordred: ya, mostly expediency for the moment20:25
mordredpabelanger: kk - wfm20:25
pabelangerbut can turn that into a role20:25
jlkI'm looking to verify, but I think pre-tasks end is a handler barrier, as is roles, and post-tasks.20:25
mordredjlk: do handlers in a rle wait til the end of a listof roles to fire?20:25
jlk"rle" ?20:26
jlkoh sorry20:26
pabelangerya, I also use pre_tasks for things that need to be done before a role20:26
mordredjlk: I would  have expected a role handler to fire at the end of the role - but I could also understand it being at the end of the roles list20:26
Shrewsmordred: oh, this is a race between the image upload threads and shutting down the main thread.  \o/20:26
mordredShrews: yay! it's an actual issue!20:26
jlkhonestly I have to look this up in my book.20:26
mordredjlk: I'm disappointed you don't have the book memorized20:26
pabelangercause, I don't know the ordering of role and task. is it task then role or role then task?20:26
Shrewsmordred: also... are you still out of breath?  :)20:26
jlkLOL20:26
mordredShrews: :)20:26
mordredpabelanger: oh - I think pre_tasks + role is much better than mixing role and task20:27
jlkhandlers notified within pre_tasks, tasks, and post_tasks sections are automatically flushed in the end of section where they were notified;20:27
jlkhandlers notified within roles section are automatically flushed in the end of tasks section, but before any tasks handlers.20:27
jlk(found it on ansible's website)20:27
* Shrews just witnessed the fastest talk by mordred EVER. and it was still long20:27
pabelangermordred: ya20:27
mordredpabelanger: I was mostly wanting to check in if there was a reason for not-role20:27
jlkThere _IS_ an order for tasks vs roles20:27
pabelangermordred: no reason20:28
pabelangermordred: I can make it a role now, and also update bindep and tox to do this20:29
pabelangerbut figured we want twine uploads working first20:29
jlkFYI20:29
jlkthe order is20:29
jlkpre_tasks (handlers), roles, tasks, (role handlers), (task handlers), post_tasks (handlers)20:30
pabelangerya, that lines up with what I thought20:30
*** dkranz has quit IRC20:30
pabelangerzuul gave a -2 for some reason on 49684320:31
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add ensure-twine role that upload-pypi depends on  https://review.openstack.org/49687220:31
mordredjlk, pabelanger: what about that ^^?20:31
* jlk looks20:31
pabelangerrole dependenies, never used them before20:33
jlkwhen roles start depending on more generic roles, it starts to feel a little puppetish. But ¯\_(ツ)_/¯20:33
jlkUrsula used them A LOT20:33
pabelangerhow did it turn out?20:33
mordredjlk: do you think it's a good or bad idea? we can also kill the depend and list both roles in the calling playbook20:33
pabelangermy gut is saying, it might turn into a dependency nightmark20:34
dmsimardI find that meta dependencies are sort of confusing20:34
pabelangerbut, that is from puppet dependency days20:34
mordrednot sure which thing 'feels' better- so definitely interested in past experiences20:34
dmsimardIt's like an implicit dep, you're going to run a role but end up running two (or more)20:34
mordredsounds like in general we're not so crazy about the dependency approach?20:34
dmsimardIt also prevents you from using the super powerful include_role task20:34
dmsimard<3 include_role20:35
pabelangermordred: I think we should maybe try at PTG, but I'd prefer not to use them atm20:35
pabelangerto much of a mental map already20:35
mordredkk20:35
dmsimardFor example, you can use include_role inside a block and then have a rescue to collect logs if the role fails20:35
pabelangerdmsimard: I too like include_role20:35
jlkrole deps kind of go against "least surprise"20:35
dmsimardYou can't do that with the regular role directive, if something fails in a role, you're done20:36
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add ensure-twine role  https://review.openstack.org/49687220:36
mordredremote:   https://review.openstack.org/496873 Use ensure-twine role to ensure twine exists20:36
pabelanger+220:36
jeblairpabelanger: did you look at why it -2d?20:36
jlkwell, you could put the recover IN the role20:36
jlkbut yeah20:36
pabelangerjeblair: sorry, where?20:36
dmsimardjlk: but then you need to put everything in the role in blocks20:37
dmsimardjlk: instead of wrapping it completely20:37
pabelangerjeblair: oh, zuul20:37
pabelangerjeblair: ya, still looking20:37
pabelangerbut POST_FAILURE20:37
pabelangernot much in logs20:37
jlkdmsimard: sure. But it's an interesting thought. Should the recover for the role live WITH the role, or outside of it?20:37
dmsimardjlk: they're not mutually exclusive20:38
dmsimardjlk: you can wrap all your role includes into a rescue that wraps up the job (i.e, log collection) so that uncaught failures/exceptions are still caught20:38
dmsimardand then individually rescue inside your roles on a need basis20:38
jlknod20:39
pabelangerjlk: jeblair: I am going to recheck 496843 and try finger job. debug.log doesn't have anything helpful20:39
dmsimarda failure that is rescued inside a role won't trigger the rescue from the outer block20:39
jlkI think I've shied away from include_role because it's so new, and it was pretty broken last time I looked at it20:39
dmsimardjlk: there was an issue with handlers was the last thing I'm aware of, but the fix landed in 2.3.2 iirc20:40
pabelangerokay, I am seeing POST_FAILURE in check too20:40
pabelangersome something is up20:40
dmsimardjeblair: so I wanted to do something nice for fix_disk_layout but from quick prototyping it looks like it will make it harder to review since the steps are more verbose/broken down, I guess I'll go with the vertabim approach but makes me :(20:41
dmsimardI'm confident I can get 100% the same result with pure ansible but meh20:42
pabelangerlooks like emit-ara-html20:42
jeblairpabelanger: i just approved the gzip ara change20:42
dmsimardpabelanger: the html gzip merged yeah20:42
pabelangerhttp://paste.openstack.org/show/619231/20:42
dmsimardhuh /me looks20:42
jeblairdmsimard: re disk layout -- yeah, at least getting it in there in a self-contained role will let us easily iterate20:43
Shrewsmordred: hrm, i think i was wrong on the race. digger deeper...20:43
Shrewsdigging, even20:43
dmsimardpabelanger, jeblair: okay, that's no good -- ansible wants to create a .gz archive of the ara folder and that's not the intended goal, submitting a fix now20:44
pabelangerk20:45
pabelangerI think we'll need to force merge the fix20:46
openstackgerritDavid Moreau Simard proposed openstack-infra/zuul-jobs master: Don't create a gzipped folder: recursively gzip ARA contents  https://review.openstack.org/49691620:48
dmsimardpabelanger, jeblair ^20:48
dmsimard"gzip --recursive --best {{ zuul.executor.log_root }}/ara" is what devstack-gate uses right now.20:49
pabelangerdmsimard: why didn't you just add dest?20:50
dmsimardpabelanger: it wants to create an ara.gz folder20:50
dmsimardthat's not going to fly for serving it over the web20:50
dmsimardwe want to recursively gzip every html/css/js files in the ara folder20:50
pabelangeroh, you want to compress all files inside the directory20:51
dmsimardright20:51
pabelangeryou could use find / archive tasks. Do we to do this the ansible way?20:53
pabelangerjlk: jeblair: mordred: ^ do you have a preference20:54
jeblairpabelanger: no pref20:55
dmsimardpabelanger: don't want to use find20:58
dmsimardthere's potentially thousands of files in there20:58
dmsimardso you'll end up doing 1000's of archive tasks20:59
openstackgerritMerged openstack-infra/zuul-jobs master: Don't create a gzipped folder: recursively gzip ARA contents  https://review.openstack.org/49691620:59
dmsimardwhich is overkill20:59
pabelangerdmsimard: true20:59
dmsimardI guess we need a test job for zuul-jobs :/21:03
dmsimardsorry about that, I'll go ahead and put something together to try and avoid that from re-ocurring21:04
pabelangerjeblair: mordred: did we just want to squash 496873 and 496844 otherwise 496844 still needs a +2 /+321:05
jeblairpabelanger: lets just merge them all21:08
pabelangerjeblair: thanks21:09
mordreddmsimard, pabelanger: yes - we need a test job for at least the base logging things - I'm going to get annoyed enough any day now and write one21:09
dmsimardmordred: I'll get something up by EOD21:10
openstackgerritMerged openstack-infra/zuul-jobs master: Create pypi_twine_executable  https://review.openstack.org/49684321:11
pabelangermordred: I've started on the ansible-lint across the 4 projects jobs21:13
Shrewssomeone please remind me of the magic incantation to set concurrency=1 with tox....21:18
jeblairShrews: heh "ttrun" ? :)21:19
jeblair(that's all i know how to use anymore)21:19
Shrewsjeblair: yeah, running that now. but wanted to see if testr/subunit related since i see that process hanging21:20
Shrewsif *this is*21:21
jeblairah21:21
Shrewsnot finding ANY output that is helpful so far21:21
dmsimardoh man, fix_disk_layout is one hell of a rabbit hole21:22
jeblairShrews: if you just do "tox -e py35 --concurrency=1" does that work?21:22
Shrewsjeblair: no21:23
Shrewshrm, maybe: tox -epy36 -- --concurrency=121:23
Shrewsyup21:24
dmsimardgoing through fix_disk_layout <- setup_workspace -> setup_project -> ['git_clone_and_cd', 'git_remote_set_url', 'git_remote_update', 'git_prune', 'git_fetch_at_ref', 'git_checkout'] <- git_timed21:24
* Shrews now waits 4x as long for a failure21:24
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Document list of configuration items for include/exclude  https://review.openstack.org/49692821:25
mordredjeblair: ^^ let's see how that feels21:25
jeblairdmsimard: wait, i thought you were just working on fix_disk_layout?21:26
mordreddmsimard: I believe you can assume in fix_disk_layout that setup_workspace and git cloning will all have been done21:26
jeblairwell, moreover, i don't see anything in there that requires that they be done21:26
openstackgerritMerged openstack-infra/zuul-jobs master: Add ensure-twine role  https://review.openstack.org/49687221:27
dmsimardjeblair: yeah, I was looking at where fix_disk_layout was used which is from setup_workspace -- do we need to move setup_workspace too ?21:28
jeblairdmsimard: large parts of setup_workspace are irrelevant, we need to consider it piecemeal21:29
dmsimardack21:29
*** jkilpatr has joined #zuul21:29
Shrewsjeblair: mordred: seems we began seeing the random nodepool py35 job hangs with this change https://review.openstack.org/492219 which seems like a good candidate for causing that kind of problem. Will either find it, or revert the change.21:33
mordredShrews: yes- I agree, that definitely seems like a good candidate for causing that kind of problem21:34
Shrewswhich saddens me, b/c i liked that change21:34
mordredyah21:34
mordredShrews: well, maybe there's an 'easy' fix21:35
mordredShrews: at least you probably found the issue21:35
dmsimardhey, with in-repo .zuul.yaml's, can you inherit from a parent job that lives in another project (if the project is in "required-projects") ?21:44
jeblairdmsimard: you can inherit from any job that has already been defined (project order in tenant configuration matters) regardless of required-projects21:45
jlkI.... I think so? I forget what all the rules are for inheritance. What kind of project can be a parent.21:45
dmsimardjeblair: what is this magic21:45
mordreddmsimard: there is so much magic in v3 you're going to love21:46
jeblair(i'd like to change that to support inheriting from projects after the current one too... but... well, sometime after 13 days from now :)21:46
mordred++21:46
dmsimardSo what prevents a project from using a name that was defined elsewhere ?21:46
dmsimardWouldn't that mess up things ?21:46
jeblairdmsimard: we ask nicely21:46
jlkI believe you get config errors21:46
dmsimardok :)21:46
jlkright?21:47
jeblairdmsimard: first name wins.  "important" projects come early so they usually win.  and yes, if you try to do that, config errors.21:47
clarkbjeblair: thats yaml behavior too right? (first name wins)21:47
dmsimardjeblair: ok so for example your devstack-gate .zuul.yaml has "base" for a parent, but doesn't necessarily declare where base is from21:47
dmsimard(where is base from anyway?)21:47
jeblairclarkb: well, we avoid dict name collisions21:47
mordreddmsimard: openstack-infra/project-config21:48
dmsimardwell there ya go, thanks21:48
dmsimardblack magic I tell you21:48
mordreddmsimard: the main base things in are openstack-infra/project-config:zuul.yaml - and other standard shared things that don't need to do trusted behaviors are in openstack-infra/zuul-jobs21:48
dmsimard(the nice kind of black magic)21:48
jeblair(modulo "shadow" -- we allow zuul-jobs to shadow project-config, so jobs defined in zuul-jobs with names that duplicate project-config won't have a config error, and the definitions in project-config still win)21:48
mordred++21:48
mordredyah- project-config and zuul-jobs are special21:49
mordredbut also mostly define things that should just work for you21:49
mordredjeblair: looking at the d-g .zuul.yaml - do we want a multinode-base job that does the extra bits to set up multi-node things and then have devstack inherit from that even for single-node jobs?21:50
jeblairdmsimard: the "base" in that job definition is actually a noop -- that's the default -- we could omit it.  i mostly put it there to have the TODO to change it to multinode when the multinode parent job exists21:50
dmsimardmordred: so wait, we could just yank devstack-lxc into zuul-jobs to get some minimum amount of coverage ?21:50
mordreddmsimard: coverage from?21:51
dmsimardmordred: from random things bricking the gate21:51
jeblairmordred: that's what that TODO means (that's detailed in the etherpad)21:51
mordredoh - no - well - so we also put devstack-gate high in the list of projects - so it's going to come first and win most of the time21:51
mordredjeblair: cool21:51
dmsimardmordred: I wouldn't redefine the job, but add it to the check gate of zuul-jobs21:51
dmsimardhere, let me try21:52
mordreddmsimard: that's more complex actually21:52
dmsimardmordred: oh ?21:52
mordreddmsimard: the things that would cause us problems currently are in trusted parts of the job config which means they don't update job config speculatively21:52
jeblairdmsimard: zuul-jobs runs the zuul py35 unit tests for that reason; i'm not sure adding devstack-gate to it would cover anything not already covered by that or devstack-gate jobs21:52
mordreddmsimard: so landing changes that affect how the base job does logging don't get self-tested like other changes, because that would open things to attacks exposing secrets and stuff21:53
dmsimardmordred: makes sense21:53
clarkbout of curiousity what is devstack-lxc? a job that installs openstack with lxc compute driver?21:53
jeblairin fact, ara generation is probably the first non-trivial trusted pre/post role that actually *could* be tested on a test node21:54
dmsimardclarkb: jeblair's ongoing work, like https://review.openstack.org/#/c/496864/21:54
jeblairclarkb: yeah, i just picked it as a simple job that used the devstack local_conf macro21:54
clarkbgotcha was wondering where lxc came from that makes sense (re local_conf)21:54
dmsimardjeblair: yeah, I was interested in something that exercised the base/pre/post at a minimum inside zuul-jobs -- right now we just do tox-linters. That's why I thought adding devstack-lxc could have made sense but I'll make something up.21:55
openstackgerritPaul Belanger proposed openstack-infra/zuul-jobs master: Refactor ensure-twine  https://review.openstack.org/49694521:56
pabelangermordred: ^ updates jlk suggested. Also, it didn't work as expected. So now, we condition just on rc value for both21:56
dmsimardjeblair: I think ideally each role would be tested individually somehow ? Otherwise we need to run all of them or something21:56
jeblairdmsimard: we can make a job for roles that need to be specially tested and run them only on changes to that role (file: roles/ara-generation)21:58
pabelangerdmsimard: this is how I tests roles today: http://git.openstack.org/cgit/openstack/ansible-role-bindep/tree/tests/test.yaml we could do the same thing in zuulv3 for some of the more simply roles21:58
pabelangerI like the file: roles/foobar idea too21:59
dmsimardjeblair: oh, from filtering in the layout ?22:00
dmsimardjeblair: that's a good idea too.22:00
mordredpabelanger, jeblair: zuul-jobs has playbooks/base/pre.yaml I don't think that's used for anyhting22:00
mordredand a post-ssh.yaml22:01
mordredam I missing anything?22:01
mordredI thnk those are leftovers22:01
jeblairmordred: they are the "sample" base job22:02
mordredjeblair: but there is no sample base job anymore22:03
jeblairwell there you go22:03
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add multinode base job  https://review.openstack.org/49694822:03
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Remove base playbooks  https://review.openstack.org/49694922:03
mordredremote:   https://review.openstack.org/496951 Use multinode base job for devstack base job22:05
openstackgerritDavid Moreau Simard proposed openstack-infra/zuul-jobs master: Add a no-op job to test that the 'base' parent job works  https://review.openstack.org/49695222:08
dmsimardshould stuff from pre be shown in the console ?22:10
dmsimardcause it's not22:10
dmsimardfrom "pre-run"22:10
jeblairdmsimard: unless there's a bug, there is no way you can cause a change to a role in zuul-jobs used by a playbook in project-config to be used before it merges.22:10
pabelangerjeblair: mordred: do you also mind reviewing: https://review.openstack.org/496945/ update to ensure-twine22:11
dmsimardjeblair: ah, bummer, my brain now assumes there's more black magic than there is :)22:11
dmsimardjeblair: ok, let's test roles individually then.22:12
dmsimardbut hang on, let's take the opportunity to test if that's really true22:12
openstackgerritDavid Moreau Simard proposed openstack-infra/zuul-jobs master: Add a no-op job to test that the 'base' parent job works  https://review.openstack.org/49695222:13
jeblairdmsimard: that spell requires divining the intent of the author, which i haven't mastered yet.  :)  when used by a config project, those roles run in the trusted execution context which means they can cause damage to the executor.  so zuul will use the branch tip to check out those roles in that case.  when the same role is used in the untrusted execution context, it uses the proposed change.  so the python unit test roles are self-testing, but ...22:14
jeblair... log upload roles aren't.22:14
dmsimardmordred: so, the stuff from base's 'pre-run' isn't displaying in the console, is that expected ? It goes from ara's DB initialization to the child job's 'run'22:15
mordreddmsimard: no- I would expect to see logging of pre-run tasks22:15
dmsimardjeblair: I confirm that there's no bug, I re-introduced the archive task bug from earlier and that didn't break it22:16
dmsimardmordred: http://paste.openstack.org/show/619245/22:16
dmsimardmordred: so it kind of "hangs" for a few seconds after ARA's db initialization but I'd assume that base's pre-run is being ran during that time22:16
mordreddmsimard: I am unpleased about that22:16
mordreddmsimard: I see pre-run on this one: http://logs.openstack.org/51/496951/1/check/devstack-lxc/f10e28b/job-output.txt.gz22:17
pabelangerits been some time since I've seen prepare_workspace in job-output.txt22:17
mordredok. we need to dig in to that - we should see all the pre-run tasks22:17
pabelangerYa, I think ARA database is doing something22:18
mordredI'm close to EOD - but I can dig in to that tomorrow if nobody else has22:18
dmsimardmordred: yeah it's missing a bunch of stuff, like mirror config and stuff22:18
mordredI think there's a logging interaction between we need to sort out - I started a patch22:18
pabelangermordred: please https://review.openstack.org/496945/ so I can finish up testing :)22:18
dmsimardmordred: want me to open up a bug or something ?22:18
mordreddmsimard: not unless you really want to22:20
dmsimardok22:20
openstackgerritMerged openstack-infra/zuul-jobs master: Add multinode base job  https://review.openstack.org/49694822:20
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Squelch ara initializing message from log  https://review.openstack.org/49695522:20
openstackgerritMerged openstack-infra/zuul-jobs master: Remove base playbooks  https://review.openstack.org/49694922:20
mordredI maybe never pushed that one up22:20
pabelangerpretty sure it is alembic causing issues with base/pre.yaml22:22
pabelanger2017-08-23 22:22:00,684 DEBUG zuul.AnsibleJob: [build: 073cb03f59ba4b079ecdf8b2565a4560] Ansible output: b'INFO  [alembic.runtime.migration] Context impl SQLiteImpl.'22:22
pabelangerI see that in debug.log22:22
dmsimardpabelanger: that's from ara22:23
mordredyah22:23
dmsimardpabelanger: ara's logging (especially with alembic) is.. deficient22:23
mordredmy working hunch is that we have fighting logging configs22:23
pabelangermordred: yes, I agree22:23
openstackgerritMerged openstack-infra/zuul-jobs master: Refactor ensure-twine  https://review.openstack.org/49694522:24
pabelangerjeblair: should I still be seeing data from gearman in debug.log?22:24
pabelanger'sensative data'22:24
mordredI think we need to add an optional way to set a logging config file (via env var or whatnot) to both ara and zuul_stream and stop using basicConfig22:24
jeblairpabelanger: i don't think so22:24
pabelangerokay, I still do :(22:25
mordreddmsimard: I'll send you some ara patches tomorrow and also ones for zuul_stream22:25
mordredand with that - my laptop is dying and I need to join th ehumans22:25
pabelangerAh, I think I see the issue22:26
jeblairpabelanger: i'll fix it22:26
pabelangerjeblair: okay, thanks22:26
dmsimardjeblair: is there an example of file filtering for controlling job execution ? I'd assume it's not the same as in v2 and I can't find an example, the spec turns up empty on keywords22:26
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove excess debugging from playbook prep  https://review.openstack.org/49695622:29
jeblairpabelanger: ^22:29
jeblairdmsimard: not yet, but here are the docs: https://docs.openstack.org/infra/zuul/feature/zuulv3/user/config.html#attr-job.files22:29
dmsimardjeblair: ah that's a thing, thanks -- bookmarked22:30
* dmsimard was actually poking at configloader right now22:30
jeblairdmsimard: "git grep files: tests" may get you some examples too22:31
jeblairbut it's pretty straightforward22:31
pabelangerWOOT22:38
pabelangerhttps://testpypi.python.org/pypi/sandbox22:38
pabelangerlucky 0.0.1322:39
pabelangerhttp://logs.openstack.org/2a/2fc84b6b8a50a1589b1e3a63e6eac3520f03b42a/release/release-openstack-python/5b7544d/22:39
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Squelch ara initializing message from log  https://review.openstack.org/49695522:39
pabelangerjeblair: mordred: moving onwards to gpg siging next^22:40
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Remove excess debugging from playbook prep  https://review.openstack.org/49695622:48
openstackgerritDavid Moreau Simard proposed openstack-infra/zuul-jobs master: Add a job to test emit-ara-html  https://review.openstack.org/49695222:49
openstackgerritDavid Moreau Simard proposed openstack-infra/zuul-jobs master: Add a job to test emit-ara-html  https://review.openstack.org/49695222:53
dmsimard^ is still a WIP, I'll finish later gotta get off for now22:53
openstackgerritDavid Moreau Simard proposed openstack-infra/zuul-jobs master: WIP: Add a job to test emit-ara-html  https://review.openstack.org/49695222:59
openstackgerritDavid Moreau Simard proposed openstack-infra/zuul-jobs master: WIP: Add a job to test emit-ara-html  https://review.openstack.org/49695223:01
openstackgerritDavid Moreau Simard proposed openstack-infra/zuul-jobs master: WIP: Add a job to test emit-ara-html  https://review.openstack.org/49695223:24
jeblairdmsimard: feedback on 49693523:29
dmsimardAck23:30
jeblairdmsimard: note that's an example of why, when changing the current v2 devstack job, we have to wait for all the jobs to complete and carefully read the test output.  it's very easy to introduce an error that still causes the tests to pass in some cases.23:30
*** lennyb has quit IRC23:31
dmsimardBTW I have no clue why 496952 is failing. I'm assuming the default role path isn't picking up the roles from the roles dir (Ansible defaults to ”{{playbook_dir}}/roles”) but there's nothing in the console showing any hint of an error23:31
jeblairdmsimard: a project's own roles/ directory is automatically added to the role path23:33
jlkmordred: fyi in our modules, we don't have to call subprocess directly, there is an Ansible module util for that.  rc, out, err = module.run_command(blah, check_rc=BOOL)23:34
jeblairdmsimard: why did you use irrelevant-files?23:35
dmsimardjeblair: so that updating readme.rst wouldn't trigger the integration tests ?23:36
jeblairdmsimard: that actually means "don't run this test if the *only* change is to README"23:36
jeblairdmsimard: chances of that are slim23:36
dmsimardOh, huh. Okay.23:37
jeblairdmsimard: let's go ahead and say that the default policy of any project in openstack-infra is not to use "irrelevant-files".  it's confusing, nobody understands it, and none of us like it.  :)23:37
dmsimardDeal23:37
jeblairdmsimard: *files* on the other hand, is okay.  so "files: ^roles/emit-ara-html/.*' would be fine.  at any rate, that can wait for later.23:38
dmsimardYeah the job does trigger so I think that part is fine23:39
jeblairdmsimard: in the ara output for that, i don't see the main playbook run at all.23:39
jeblairdmsimard: i think it's the same error as ansible-lint23:41
jeblair2017-08-23 23:03:07,214 DEBUG zuul.AnsibleJob: [build: 3d0a331f621c4806a684fe6fd4f0d6c7] Ansible output: b"ERROR! 'role' is undefined"23:41
*** lennyb has joined #zuul23:41
jeblairmordred: what's the word on getting ansible parse/syntax errors into the build output?  eg http://paste.openstack.org/show/619246/23:42
dmsimardjeblair: right, I caught that when testing manually and that's why I added "skip_ansible_lint" tags to the tasks but apparently it doesn't work23:43
dmsimardjeblair: I guess I could try removing the role var and hardcode it for the test of isolating that's where the issue is23:44
jeblairdmsimard: ansible is emitting that error23:44
jeblairdmsimard: so i think ansible-lint caught an actual error.  probably shouldn't ignore it?23:44
dmsimardjeblair: the linters don't have the variable set, the var is set inside the integration job23:45
jeblairto be clear, the line i pasted above is output from ansible-playbook logged on the executor23:45
dmsimardI meant to share a single playbook for multiple roles23:45
dmsimardjeblair: is that in the *linters* job? or the integration job ?23:45
pabelangerdmsimard: https://review.openstack.org/495463/ is realivent to unset variables for linting23:45
openstackgerritDavid Moreau Simard proposed openstack-infra/zuul-jobs master: WIP: Add a job to test emit-ara-html  https://review.openstack.org/49695223:45
pabelangernow I solved it23:45
pabelangerhow*23:45
dmsimardneed to afk a bit for food before I digest myself23:46
dmsimardbrb23:46
jeblairdmsimard: it is the ansible-playbook output from the integration job.  the ansible-lint job would not produce output like that from ansible-playbook, its output appears in the build log.23:46
pabelangerare we having executor run role integration, or have executor run ansible-playbook (on node) to then run role23:49

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