Friday, 2017-06-30

jlkDoes perforce have a code review type system? Proposed changes and reviews and such?00:00
clarkbhttps://www.perforce.com/products/helix-swarm00:01
jlkit has CI hooks, that's good00:04
mordredI think it'll be interesting to figure that out at some point00:15
openstackgerritJamie Lennox proposed openstack-infra/zuul feature/zuulv3: Convert jwt encode to string for github in python3  https://review.openstack.org/47910000:23
jamielennoxjlk: ^00:23
jlkso... when reading the docs changes, it seemed to elude to the gerrit code doing some statsd stuffs, but I'm looking in the tree and not seeing it. Am I not looking in the right place? Are the docs wrong?00:24
jlkwoo!00:25
jamielennoxobvious once you find it, took too long to find00:25
mordredjamielennox: woot!00:36
mordredjlk: it actually all seems to be in the scheduler, connection and manager00:37
jlkthat's what I found00:37
mordredjlk: so - I think you already have statsd reporting for github :)00:37
jlkheh00:38
mordredjlk: that was easy, right?00:39
jamielennoxi figured we'd build out the github statsd when we found things we actually cared about in github stats00:39
jlkmordred: hah, yeah. I was looking for parity with gerrit, but yeah.00:40
mordredyah - it's all pretty much reported at the scheduler event and connection event level currently - but yeah, if you find that's not reporting things that are useful for github, that'll be good learning00:40
mordredthings like: 'zuul.event.{driver}.{event}' and 'zuul.event.{driver}.{connection}.{event}' cover a lot of ground :)00:40
*** xinliang has quit IRC01:07
*** jkilpatr has quit IRC01:11
*** xinliang has joined #zuul01:21
*** xinliang has quit IRC01:21
*** xinliang has joined #zuul01:21
*** jkilpatr has joined #zuul01:24
jamielennoxSpamapS: not sure yet what caused this but thought you might be interested: http://paste.openstack.org/show/614137/01:45
*** jkilpatr has quit IRC02:12
tobiashgetting repeated exception in nodepool http://paste.openstack.org/show/614141/05:13
tobiashhrm, possibly unclean source when building the docker image, will rebuild and check if this happens again :-/05:26
tobiashjeblair, Shrews: I added a second cloud provider to nodepool and am observing a strange behavior now05:41
tobiashjeblair, Shrews: when at quota (cores exceeded, but instances not) it fills up one provider and declines/fails the node requests constantly without trying the second provider (which still has capacity)05:42
clarkbtobiash: you have to size based on instamces with the current scheduler05:55
clarkbif not at max instances then nodepool assumes it has room05:56
tobiashclarkb: I have different sized instances so I cannot calculate a proper instance cound to fill up the cpu quota05:56
tobiashs/cound/count05:57
clarkband this is with zuulv3 right? with 2.5 I think the nodepool acheduler would round robin the requests06:00
tobiashclarkb: yes06:01
clarkbso we may need to add in some sort od round robin to mitigate against this06:01
clarkbpretty sure old.scheduler did this06:01
clarkbactually, current one may attempt it too by only failing the request if all possible providers fail?06:02
tobiashclarkb: I'm trying to craft a test case for this (didn't find one)06:21
jamielennoxdid we change the playbook path?06:44
jamielennoxseeing Unable to find playbook /tmp/df47f0b6d0234431a0c60b94e103a9c3/ansible/pre_playbook_0/github.com/BonnyCI/project-config/base-pre06:45
jamielennoxwhere the file is at project-config/playbooks/base-pre.yaml06:46
tobiashjamielennox: playbooks/ is not defaulted anymore07:07
tobiash(except for main playbook if it's not defined)07:07
jamielennoxtobiash: yea, guessed as much, just hadn't seen it07:07
tobiashjamielennox: https://review.openstack.org/#/c/477672/07:08
*** hashar has joined #zuul07:15
tobiashclarkb: never mind, I fucked up my config... max_servers of the second providers was 0 :-/07:34
* tobiash needs to grab some coffee07:34
openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: Ensure build.start_time is defined  https://review.openstack.org/46673208:11
*** bhavik1 has joined #zuul08:34
mordredtobiash: that would do it! :)09:35
*** pbelamge has joined #zuul10:13
pbelamgeHello All10:14
pbelamgeanybody came across this error when run zuul-server in daemon mode?10:14
pbelamgehttps://thepasteb.in/p/Anhrq5mogngcv10:15
pbelamgeinstalled zuul version is:10:16
pbelamge$ zuul-server --version10:16
pbelamgeZuul version: 2.5.210:16
pbelamgecan anybody through some light on this?10:18
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826510:22
toabctlpbelamge, does https://github.com/openstack/ansible-role-zuul support zuulv3?10:31
toabctleh, I meant pabelanger ^^10:32
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Use versions of jobs from zuul-jobs  https://review.openstack.org/47925310:37
mordredjeblair: see syntax error on first comment of https://review.openstack.org/#/c/479253/10:39
mordredjeblair: three feedbacks10:39
mordredjeblair: a) WOOT - that was a syntax error in openstack-zuul-jobs run speculatively on a change to zuul10:40
mordreds/openstack-zuul-jobs/zuul-jobs/10:40
*** bhavik1 has quit IRC10:41
mordredjeblair: b) it didn't trigger the syntax error on zuul-jobs - before that change there was no job defined for zuul-jobs and the syntax error was actually in defining the job. that's an edge case, but probably one that'll be confusing to debug (and it was caused by a yaml indentation goof, so probably a _likely_ error)10:43
toabctlis there somewhere a zuul.conf example for the v3 version?10:45
mordredjeblair: c) when it was reported, it was reported as being in "<unicode string>" - I know that's a passthrough error - and the message in the commit actually did give me the information I needed - but we may want to ponder if it's feasible to be able to replace "<unicode string>" with .zuul.yaml10:46
mordredtoabctl: we're using: http://git.openstack.org/cgit/openstack-infra/puppet-zuul/tree/templates/zuulv3.conf.erb10:47
mordredtoabctl: I do not know if https://github.com/openstack/ansible-role-zuul has been updated for v3 yet - and pabelanger is on vacation this week10:47
mordredtoabctl: the bonnyci ansible may be helpful: https://github.com/BonnyCI/hoist/blob/master/roles/zuul/templates/etc/zuul/zuul_v3.conf10:48
*** jkilpatr has joined #zuul10:48
toabctlmordred, ok. I'll have a look at these (trying todo a github connected setup currently)10:49
mordredtoabctl: neat - I need to do one of those soon myself :)10:51
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826510:51
mordredjeblair: also - I believe you were talking about this yesterday - but the "run post playbooks if pre-playbooks fail" I think will be super helpful11:04
pbelamgeanybody know why we get this error when run the zuul-server in daemon mode?11:06
pbelamgeIOError: [Errno 9] Bad file descriptor11:06
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826511:09
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826511:14
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826511:14
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826511:20
toabctlmordred, does py34 work? or is really 3.5 required?11:46
toabctlor is it just not tested..11:46
mordredtoabctl: it's definitely not tested - no clue if it works or not11:47
mordredah - yeah - 3.5 is going to be required for at least some portions to work (the websocket log streaming, for instance)11:48
mordredjeblair: vars in job definitions do not seem to be making it into the inventory11:49
*** hashar is now known as hasharAway11:49
mordredjeblair: nevermind. I don't know how to read logs11:52
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826511:56
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826511:59
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826512:06
openstackgerritThomas Bechtold proposed openstack-infra/zuul feature/zuulv3: Fix exception handling in scheduler  https://review.openstack.org/47928312:27
toabctlmordred, is the tenant_config somewhere documented?12:28
*** hasharAway is now known as hashar12:29
pabelangertoabctl: mordred: ohai, just on train heading back down to London from Scotland. ansible-role-zuul is tracking against feature/zuulv3 branch, but hasn't been updated in the last few weeks. So, there may be some changes that need to be made.12:47
toabctlpabelanger, ok. thanks for the info!12:48
pabelangertoabctl: plan to work on updating all the ansible bits when back from PTO on july 10th.12:49
mordredZOMG I JUST SPENT FOREVER TRACKING DOWN AN ANSIBLE SYNTAX ERROR WHICH TURNED OUT TO BE A SINGLE QUOTE IN A COMMENT!!!!!12:59
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826513:00
openstackgerritThomas Bechtold proposed openstack-infra/zuul feature/zuulv3: Fix non-default username for zuul-executor  https://review.openstack.org/47929913:14
mordredjeblair: role path lookup is wrong - if the base job adds roles: openstack-zuul-roles and then the unittest job adds roles: zuul-jobs and both openstack-zuul-roles and zuul-jobs have a role named the same, they the base job roles override13:15
mordredjeblair: /tmp/64686e6e77c54b67aa38bad1db8dfc92/ansible/role_0/trusted/git.op13:15
mordredenstack.org/openstack-zuul-roles/roles:/tmp/64686e6e77c54b67aa38bad1db8dfc92/ans13:15
mordredible/role_1/untrusted/zuul-jobs/roles13:15
*** pbelamge has quit IRC13:16
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Use versions of jobs from zuul-jobs  https://review.openstack.org/47925313:19
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Reverse role list before writing it out  https://review.openstack.org/47930113:19
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826513:21
*** jkilpatr has quit IRC13:22
mordredjeblair: also - if there is a playbook parse error, we're not logging that to the user currently - but we probably should13:23
mordredalthough looking at the code, that's not going to be easy :(13:27
*** jkilpatr has joined #zuul13:35
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Use versions of jobs from zuul-jobs  https://review.openstack.org/47925313:44
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Append ansible yaml parse errors to job log file  https://review.openstack.org/47931213:44
mordredactually - not that bad13:44
tobiashmordred: looking at ^^, doesn't self.proc.stdout already have the stdout of the first ansible run?13:48
mordredtobiash: oh - I guess I could just seek(0) it couldn't I?13:49
mordredtobiash: thank you - that's much smarter :)13:50
tobiashmordred: in line 1320 self.proc is resetted, this would need to be moved below probably13:50
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Append ansible yaml parse errors to job log file  https://review.openstack.org/47931213:53
tobiashmordred: if seek doesn't work you also could append the lines to a list during logging13:53
mordredtobiash: something more like that perhaps?13:53
tobiashlooking13:53
mordredtobiash: yah - I avoided that originally because I was mistakenly thinking I needed to worry about large amounts of output buffering - but we deal with that elsewhere13:53
mordredtobiash: so yes, I think we could also append lines to a list13:53
tobiashmordred: maybe return failed?13:55
tobiashmordred: I think ps2 would trick the result to believe a successful job13:56
jlko/13:58
mordredtobiash: it actually gets processed by the thing that calls the runAnsible method - if you look around 88913:59
mordredtobiash: in runPlaybooks - when job_status is RESULT_NORMAL, the logic there determines success or failure based on return code - and since it's 4 it should show failed14:00
tobiashmordred: ah, you're right14:00
tobiashmissed that one14:00
tobiashmordred: +114:01
mordredtobiash: but good eye!14:01
tobiashthanks14:01
mordredjeblair: woot! do you remember when I made that patch for unicode encoding that log line but didn't have an example of when it broken?14:02
mordred2017-06-30 13:54:50,524 DEBUG zuul.AnsibleJob: [build: d9bb1e7de80f44a5adf3e390bedb694a] Ansible output: b"UnicodeEncodeError: 'ascii' codec can't encode character u'\\u011f' in position 64: ordinal not in range(128)"14:03
*** jkilpatr has quit IRC14:07
*** jkilpatr has joined #zuul14:07
jlktoabctl: if it helps, there's some sample stuff up at https://github.com/j2sol/z8s and at https://github.com/j2sol/project-config14:10
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826514:12
toabctljlk, for the github connection - is the api_token enough? I'm still not sure if I have a working connection...14:12
jlktoabctl: yeah you can do it with an api token14:13
toabctljlk, then the zuul-scheduler should wirte something to the log if I add a comment to a github PR done in a project mentioned in the tenant.yaml, right?14:13
jlktoabctl: we are running into a problem right now where the webhook ingestion is triggering a byte decode bug somewhere in webobject, so your hooks won't necessarily get processed right14:14
jlktoabctl: no, on the github side you have to configure a webhook to send events to your scheduler14:14
toabctljlk, I have no webhook configured. I thought it works also without webhooks. no?14:14
jlkzuul doesn't poll github, it waits for githib to send events.14:14
toabctloh. then that's the problem. I thought it polls.14:14
toabctljlk, so zuul listens on 8001 for hooks?14:15
jlkyeah14:15
*** jkilpatr has quit IRC14:15
toabctljlk, what about the webhook secret? can I share that somehow with zuul?14:17
jlkI believe so, I'm just not using that with my small sample setup I use to test zuul code14:17
jlkthe secret is defined as "webhook_token" in the config14:18
jlkoh and the websecret has to be of type json14:20
jlker webhook14:20
toabctljlk, hm. accessing the webhook url:8001 gives a 40414:22
jlkaccessing it how?14:22
jlkit only accepts certain things in certain paths14:23
toabctljlk, with a browser - http get14:23
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826514:23
jlkWe send to /connection/github/payload   where "github" is the name of hte connection in zuul config14:23
jlk(that's in the github side webhook url14:24
jlkyou should also be able to get status, curl http://localhost:8001/z8s/status   works for me becuase "z8s" is the name of my tenant in etc/zuul/tenant.yaml14:27
toabctljlk, hm. the status curl call returns something14:29
*** jkilpatr has joined #zuul14:29
jlka GET on the webhook URL won't work. It takes POST14:29
toabctljlk, the webhook log says that the last deliver was successful.14:30
jlkalthough what I get back is a 405, not 40414:30
jlktoabctl: I think what it delivers is a ping?14:30
jlkcurl http://localhost:8001/connection/github/payload   just returns back a 40514:30
jlkcurl -H "Content-Type: application/json" -H "X-Github-Event: issue_comment" -X POST -d @file.json    would be how to do it manually14:30
* jlk has to go afk for breakfast14:31
toabctljlk, works now! thanks a lot!!!14:31
*** jkilpatr has quit IRC14:42
*** hashar is now known as hasharAway14:42
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826514:44
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Handle unicode (or high bytes) coming from output  https://review.openstack.org/47482714:44
openstackgerritThomas Bechtold proposed openstack-infra/zuul feature/zuulv3: doc: Mention tenant configuration parameter  https://review.openstack.org/47933814:51
openstackgerritDavid Shrewsbury proposed openstack-infra/zuul feature/zuulv3: Add web-based console log streaming  https://review.openstack.org/46335314:52
mordredShrews: morning sir!14:53
Shrewsg'morn14:54
openstackgerritDavid Shrewsbury proposed openstack-infra/zuul feature/zuulv3: Add web-based console log streaming  https://review.openstack.org/46335314:55
toabctla general question - does anybody care about zuulv3 documentation updates?14:56
mordredtoabctl: yes! there is a big docs stack - (jeblair just did the first chunk of makig it good) - ending here: https://review.openstack.org/#/c/479020/15:05
toabctlmordred, ahh. good to know!15:06
mordredtoabctl: (we need to land that) - so if you want to update the docs based on stuff you've found or experienced, it should stack on top of that - but we very much value such thigns!15:06
mordredShrews: this is a very half-baked patch: https://review.openstack.org/#/c/474827/ here - I don't know 100% of what the deal is - but I *think* that perhaps we've got a mismatch somewhere in the log streaming pipeline WRT utf-8/ascii15:07
mordredShrews: not so much that things don't work normally - but in some cases we seem to be getting the occasional high-byte thing and can't log it15:08
mordredShrews: I'm mentioning it because it might be worthwhile for us to make sure we know, since we're sending stuff over the wire, what we're expecting the encoding to be on both sides of that (like, it's likely I'm not decoding where I should or am assuming one encoding but it's the other but it works because shell output is mostly in the ascii/utf-8 overlap)15:09
Shrewsmordred: ack. will take a peek15:21
tobiashhrm, my nodepool sometimes seems to try to create new nodes and waits for them before handing them back to zuul even if it lists several nodes as ready and unlocked15:50
*** jkilpatr has joined #zuul15:53
tobiashwill have to debug next week15:57
jeblair10:43 < mordred> jeblair: b) it didn't trigger the syntax error on zuul-jobs - before that change there was no job defined for zuul-jobs and the syntax error was actually in defining the job. that's an edge case, but probably one that'll be confusing to debug (and it was caused by a yaml indentation goof, so probably a _likely_ error)16:01
jeblairmordred: yes, that's similar (or maybe the same?) as this story about adding a project to a pipeline: https://storyboard.openstack.org/#!/story/200089816:01
jeblair10:45 < mordred> jeblair: c) when it was reported, it was reported as being in "<unicode string>" - I know that's a passthrough error - and the message in the commit actually did give me the information I needed - but we may want to ponder if it's feasible to be able to replace "<unicode string>" with .zuul.yaml16:01
jeblairmordred: the intent is to have actual files there, and i thought we did. if we lost that we may have introduced a bug16:01
jeblairtoabctl: yes, the tenant configuration is here: http://docs-draft.openstack.org/94/477594/4/check/gate-zuul-docs-ubuntu-xenial/c9e1704//doc/build/html/admin/tenants.html  (that's a pre-rendering based on that big stack of docs patches mordred mentioned)16:02
jeblairmordred: what's going on in this log? http://logs.openstack.org/65/478265/17/check/7a44730/job-output.txt  (that's the port in tox jobs change, and it's a failing run of zuul-tox-linters)16:09
*** jkilpatr has quit IRC16:11
*** jkilpatr has joined #zuul16:11
mordredjeblair: ah! neat - I got further that time16:13
mordredjeblair: I believe that's recursing on a thing I don't need but thought I did because of earlier bugs16:13
mordredjeblair: (I was hitting what wound up being yaml syntax errors before - but was misdiagnosing them)16:14
jeblairoh that's the ' thing16:14
mordredjeblair: well, that and the role path sequencing issue16:14
mordredyah16:14
mordred' in comments == sad yaml16:14
jeblairi guess you have to write ansible-bash like Data -- no contractions.16:15
Shrewsit's sad i know the episode of the show that references16:21
jeblairmordred: i'm not sure about the roles order thing.  if we allow child roles to override base/parent roles, then someone could put a malicious 'upload-logs' role in their repo and our base job would run it (they would have to *land* the change in their repo since we won't run it speculatively, but they could do that)16:22
jeblairmordred: so i think we either need to decide that base roles have precedence, or we're going to need to make a unique ansible config file for every playbook invocation, and track the roles list through inheritance (so each playbook invocation only runs with the roles defined up to that point in the inheritance hierarchy)16:24
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Convert jwt encode to string for github in python3  https://review.openstack.org/47910016:24
mordredjeblair: hrm. I was thinking that the malicious role wouldn't be a problem because the base job would not run with the child jobs roles in place- but that's the second thing you said, so yeah16:25
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Use only project name in github repo creation  https://review.openstack.org/47873416:26
mordredjeblair: it feels like the ubiquitous namespace problem once again - a job defined in a repo that has a role in that repo doesn't want to be magically broken by a role defined in a base repo that it doesn't know about16:27
mordredjeblair: (like if ursula had a local 'run-bindep' role, for instance - it would expect to be using its role, not the CI system's)16:27
mordredjeblair: at least at the moment of invocation of the actual content that is defined in that repo ... altohugh I suppose in that case it's likely the case that they'd have their roles adjacnet to their playbooks, in which case the local roles _would_ take precedence16:28
mordredhowever, if it's like the tobiash case where there is a repo with roles and then some playbooks to test those roles, I would imagine such a job would definitely want to ensure it got the local copies16:29
mordredjeblair: I'm starting to think we need to do the second thing you said  and write an ansible.cfg for at least each level of the inheritance stack - with the roles_path being additive each layer down the onion16:31
Shrewsmordred: that zuul_stream error is weird. looks like we decode the things properly on that code path16:34
mordredShrews: AWESOME16:36
* Shrews rereads the py3 unicode howto16:36
jeblairmordred: okay.  i think we can do that -- i think we create a playbook context object for each playbook, so it'd probably be a matter of freezing the role list and sticking it in there each time we make one.  then, obviously, writing an ansible.cfg file for each invocation.16:39
jeblairmordred: it's worth considering which is the least surprising to users -- should a job which inherits from other jobs have a consistent set of roles for all stages, or should each stage only run with the roles that the author knew about at that stage.16:40
jeblairmordred: we have a N=1 experiment which shows that you expected the latter and were surprised by the former.  :)16:41
jlktoabctl: you aren't seeing any decoding errors when you get webhooks sent to you?16:46
mordredjeblair: yah. I think my argument for the latter is mainly one of encapsulation - as a person building a job using a system provided 'base' job, I would be surprised if I needed to know things about the actual ansible roles the base job used to implement its functionality16:52
mordredjeblair: knowing "the base job does setup including ensuring you have git repos in X and ensures logs you put into logs/ are published" is fair - but knowing it uses the prepare-workspace and upload-logs roles seems weird16:53
jeblairmordred: yeah, i'm starting to think the onion roles approach strikes the right balance between being able to be ignorant ("i don't care if it uses run-bindep") but also being able to build on it ("i know the parent role list includes run-bindep so it will be available for me to use in my child job")16:54
mordred++16:54
tobiash++16:55
jeblair17:03 < openstackgerrit> James E. Blair proposed openstack-infra/project-config master: Zuulv3: Add base-test job  https://review.openstack.org/47909817:03
jeblairmordred: ^17:03
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826517:07
mordredjeblair: cool!17:07
tobiashjeblair: how does that work? Isn't the base job in a trusted repo without speculative execution?17:08
jeblairtobiash: yes -- so with base-test i'm testing out a change i want to make to base.  since i have to actually land it to change it, this way i can break/fix base-test until i get it right, then update base.17:10
tobiashjeblair: so in base-test you're using the same roles/playbooks there like the base job, but with speculative execution?17:11
tobiashah no, I get it17:11
tobiashyou land the changes to base-test, try it out,...17:12
tobiashlike a staging concept17:12
*** hasharAway has quit IRC17:15
*** hashar has joined #zuul17:15
tobiashjeblair: does it make sense being able to mark a job as private (so it cannot be inherited from a different repo)?17:16
tobiashjeblair: use case would be again jobs for export and in the same zuul.yaml jobs for testing the exported jobs (which are not for public use and therefore should not be inherited by anyone except jobs in the same repo)17:17
tobiashjeblair: currently I'm solving this by documenting them as private17:18
jeblairtobiash: yep, like staging.17:19
tobiashjeblair: this just came to my mind reading your comment of the base-test job17:19
tobiash'not for public use' ;)17:19
jeblairtobiash: oh, i think we've got an idea of a 'final' job, i think we just haven't gotten around to exposing that as a job attribute.17:19
tobiashjeblair: I read that in the documentation but the semantics are described differently17:20
tobiashjeblair: ... "A job may inherit from any other job in any project (however, if the other job is marked as final, some attributes may not be overidden)."17:20
jeblair(it's used internally for some stuff already, but there's no reason we can't say "final: True" on a job definition to indicate that it may not be inherited from)17:21
jeblairtobiash: yeah, the things you can override on a final job are just the selectors and failure/success message, etc.  not anything that can actually alter the job behavior.17:22
jeblairtobiash: so you can still say "run this final job on the stable branch of this repo"17:22
tobiashjeblair: ok, that's fine for me17:24
tobiashjeblair: will zuul throw an error if you try to override stuff from a final job or just silently ignore the overides?17:25
jeblairtobiash: error, i believe17:25
tobiash:)17:25
jeblair"Unable to modify final job %s attribute %s=%s with variant%s"17:26
SpamapSjamielennox: Indeeed, the admin protocol functions aren't covered by tests, and that is just a py3 fail.17:26
SpamapSjeblair: http://paste.openstack.org/show/614137/17:26
SpamapSI'll work up some tests and a fix17:26
jeblairSpamapS: thanks!  that will be nice to have working.  :)17:28
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Append ansible yaml parse errors to job log file  https://review.openstack.org/47931217:36
mordredjeblair: ok - there's that ^^17:36
openstackgerritTobias Henkel proposed openstack-infra/zuul feature/zuulv3: Document final jobs  https://review.openstack.org/47937917:38
tobiashjeblair: noticed that final was not part of the job documentation17:39
jeblairtobiash: yes, i don't think it's implemented in the job definition yet either :)  (it just needs to be exposed in configloader.py)17:40
tobiashjeblair: ah ok, thought there was some yaml magic in there17:40
openstackgerritDavid Shrewsbury proposed openstack-infra/zuul feature/zuulv3: Add web-based console log streaming  https://review.openstack.org/46335317:42
Shrewscleaned up the rpclistener code a bit ^^^. the nested loop thing was itching my brain17:42
openstackgerritTobias Henkel proposed openstack-infra/zuul feature/zuulv3: Expose final job attribute  https://review.openstack.org/47938217:46
tobiashjeblair: like this? ^^17:47
tobiashis it really that easy with this simple_attributes list?17:47
jeblairtobiash: should be :)17:48
jeblairwe'll probably want a test for that too; we really don't want to accidentally break that since it has security implications.17:48
tobiashjeblair: of course17:49
mordredjeblair, SpamapS: did we never land "always use bubblewrap"?18:00
SpamapSyes that landed18:00
SpamapSI think?18:00
mordredpiddle. my local checkout is old18:01
jeblairyep it landed18:01
mordredyes. I now I agree with you :)18:02
jeblairi'm afk for a bit18:02
jlkoh that's interesting. Didn't realize I could mouse click in gertty...18:09
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Write secrets into their own file, not into inventory  https://review.openstack.org/47939018:14
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826518:16
mordredSpamapS, jlk, jeblair: ^^ that idea look sane?18:17
jlklooking18:17
*** bhavik1 has joined #zuul18:17
jlkwhich one?18:18
mordredoh - hah - the secrets one18:18
jlkokay that's what I have open18:18
mordredgood - the jobs one is still heavy-iterate18:18
jlkwhen vars live in their own file, and are grabbed by -e @foo.yaml or whatever, it changes the inheritance order, vs them being in the inventory. It probably doesn't matter, but something to be aware of.18:19
SpamapSYou know.. I got to thinkinga bout that lwn article.. and I wonder if you could make zuul work with the pure email/mailing list workflow just by using procmail.18:20
jlkhttp://docs.ansible.com/ansible/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable18:20
jlkSpamapS: OUT18:20
jlkmordred: specifically, one cannot override a variable using set_fact or whatnot if that variable is defined in an "extra vars" file. It's the ULTIMATE IMMUTABLE truth.18:21
* SpamapS hangs head18:26
mordredjlk: that's good to know - do you think that's good or bad in this case?18:27
jlkneutral.18:27
mordredSpamapS: I'm 100% certain we'll be able to implement zuul drivers for the pure email/mailing list workflow - I'm less certain that doing so purely in procmail would cause joy (although it's procmail, you can implement anything in it)18:28
jlkWe just have to document the fact so that if somebody wants to be able to change a secret partway through, they use a placeholder variable rather than the secret variable directly18:28
mordredjlk: ++18:28
jlkI have at one time seen a CI like system implemented via cups18:29
jlk(since it has a scheduler...)18:29
*** Shuo has joined #zuul18:29
clarkbjlk: was it to test printers?18:30
jlkno18:30
jlksoftware18:31
clarkbI wonder if my old printer tester script is still around18:31
SpamapSnice18:31
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826518:31
jlkor maybe it was the build farm, can't remember18:31
tobiashjeblair: hrm, as far as I understand from the code the final attribute is only taken into account during evaluation of the job variants18:31
SpamapSand I didn't really mean procmail.. but.. I mean just by feeding emails into Zuul programattically (and spitting them back out)18:31
tobiashjeblair: when trying that with inheritance there don't seem to be any checks against that18:31
mordredjlk: there was a time in my distant past where I implemented a data-feed processing system primarily in procmail18:31
mordredSpamapS: yes. I'm 100% certain we will implement that18:32
jlkthat kind of work lives on18:32
mordredjlk: if the company hadn't gone bankrupt, I'm sure that script would still be running today18:32
jlkthere's things like mailgun18:32
jeblairSpamapS, mordred: for a treatment on the subject.... :) http://lists.openstack.org/pipermail/openstack-infra/2017-May/005361.html18:32
mordredyup18:33
mordredmaking zuul receive and send email is the easy part - doing the mailing list depends-on syntax there ^^ is there the real fun comes in :)18:33
jeblairand mapping source repos18:34
mordredyup18:34
* mordred is looking forward to making that one of these days- stewart keeps asking for it18:34
SpamapSActually I found out Monday a pair of Xen VMs I set up 7 years ago running tokyotyrant (a memcache protocol backed by tokyocabinet k/v store) just got replaced by MySQL 5.7. They hadn't been rebooted, in fact they were forgotten, for about 7 years.18:36
mordredSpamapS: that's awesome18:36
jeblairmordred: if i'm following correctly, your change incidentally makes secrets trusted-only.  that's a significant change i believe?  secrets are *most* useful in untrusted repos (since those are the repos where people don't have a backchannel way of getting secret info onto the executor).18:36
jeblairmordred: in other words -- shade would no longer be able to have your cloud credentials and go out and perform real-world tests18:37
SpamapSThey served every session request for every logged in user for all the clients of my old employer during that time. :P18:37
mordredjeblair: oh - yah - I'm dumb18:37
mordredjeblair: thank you18:37
mordredSpamapS: heh. with that being the timeframe - that server COULD have been running drizzle18:37
SpamapSso true18:38
SpamapSDrizzle's what got me out of that place ;-)18:38
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Write secrets into their own file, not into inventory  https://review.openstack.org/47939018:38
SpamapSand to be forthcoming and honest.. their traffic has been in a slow, steady decline, since I left ;-)18:38
mordredjeblair: that should be better :)18:38
jeblairmordred: can i trouble you for a commit message fix?18:39
SpamapSBut still kinda proud of the fact that they basically were able to forget those things existed (*mumble mumble security*)18:39
jeblairmordred: i would normally not ask, but this is one where we want the change history to be clear if we have to dig it up.  :)18:39
SpamapSI would gladly merge your patch Tuesday for a commit message edit today, sir.18:39
jeblairi ain't mergin' notin' on tuesday18:39
*** bhavik1 has quit IRC18:40
jeblair'cept maybe some beers18:40
jlkI'll be merging some sunscreen on my skin18:41
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Write secrets into their own file, not into inventory  https://review.openstack.org/47939018:44
jeblairmade my own commit message update.  :)18:44
jeblairmordred: it's still missing the '-' from '-e'.  that's your's to fix.  :)18:47
mordredjeblair: we're frequently getting UnicodeEncodeError: 'ascii' codec can't encode character u'\\u011f' in position 64: ordinal not in range(128)18:47
jeblairmordred: does that mean we can reproduce it?18:48
mordredmaybe - I've got a finger log open right now - waiting to get the corresponding text log to see if we can triangulate18:50
jeblairmordred: looking at 5df57c6ae1a5428299781c9fb3f78675 ?18:50
mordredjeblair: 4f4ec3c72b374278be7506b0ac8fe32218:51
jeblairyou did say often :)18:51
mordredyah18:51
mordredpretty much every job best I can tell18:51
jeblairb"UnicodeEncodeError: 'ascii' codec can't encode character u'\\xe7' in position 3726: ordinal not in range(128)"  shows up as well (different character)18:52
mordredyah18:52
jeblairmordred: oh wait18:53
jeblairthat's running in python2.718:53
jeblairi thought our ansible was running in python318:53
mordredoh. of course it is18:53
jeblair(did i munge up the pip install?  i had to do some pip things a few days ago)18:53
mordredjeblair: yes18:54
jeblairi will fix my mess18:54
mordredkk. well - good to know that it's a python2 issue - which is why the 'fix' patch doesn't make sense :)18:54
jeblairyes!18:54
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Write secrets into their own file, not into inventory  https://review.openstack.org/47939018:56
jeblairokay, should be fixed.  i think we should see the new behavior without a restart.18:56
mordredjeblair: cool. also - maybe we can land https://review.openstack.org/#/c/479312/ and do a restart ?18:56
jeblairShrews: ^ the encoding thing may be due to a sysadmin screwup on my part18:56
mordredSpamapS: you hav ea sec to look at 479390 ?18:57
jeblairi'm going to switch on keep to debug the base-test thing i'm working on (since we don't have run-post-if-pre-fails implemented yet)19:00
mordredjeblair: yes please19:02
mordredjeblair: I've had that on this morning already, fwiw19:03
jeblairmordred: it has a bug and doesn't work :(19:03
mordredjeblair: wait - what?19:03
mordredkeep? I've been totally looking at kept dirs19:04
mordredwe may be using different pronouns19:04
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Append ansible yaml parse errors to job log file  https://review.openstack.org/47931219:04
jeblairmordred: i'm talking about 'zuul-executor keep' which turns on the '--keep-jobdir' option which causes it not to delete the jobdirs at the end of the job, eg, /tmp/af2f6d96f8d2408d9a13913a644774d519:05
mordredyah. I thought I used that earlier - maybe I just got good at getting into the dir before it vanished19:05
jeblairmordred: that might be it :)19:05
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Fix typo in keep/unkeep commands  https://review.openstack.org/47940319:06
jeblairmordred: maybe we can merge that too before we restart? :)19:06
mordredjeblair: ++19:06
mordredjeblair: our jobs that run shell tasks on localhost (adding the ssh key) spin up and tear down a zuul console for it - but obviously localhost is - well - shared19:08
mordredjeblair: the spin up isn't a problem- any zuul_console can serve the stream for any file19:08
*** Shuo has quit IRC19:08
mordredjeblair: but one job can tear down the console while another is using it I believe19:09
mordred(noticed a bunch of console-{uuid}.log files in /tmp19:09
jeblairmordred: do we need to tear down at all?19:10
mordredwe added the kill function so that we wouldnt' leave tons of stuff laying around on re-used static nodes19:11
jeblairmordred: we're just talking about the process, right?19:11
jeblairwe'd only be leaving one process laying around (we could still delete the log file)19:11
mordredyes - but also the log files in /tmp for each of the shell commands19:11
mordredyah - we could just not kill - the startup seems to handle an existing console existing19:12
mordredwe'll need to come up with another log file delete strategy though - the current one won't work for a shared zuul_console19:12
jeblairmordred: what's the role that does that?19:13
mordred(it does a delete on /tmp/zuul_console*log)19:13
mordredjeblair: I believe it's the last thing in the post playbook of the base job19:13
mordredoh - hrm. no it's not19:14
mordredjeblair: ok. we seem to have lost that19:15
mordredjeblair: I'll put it on my list to sort out19:15
jeblairmordred: also https://review.openstack.org/474216 is relevant19:16
mordredjeblair: OOHHHHHHH - yup19:17
mordredso I'm just wrong all the way around :)19:17
jeblairso do we have something creating stray console log files?19:17
mordredthe shell module. so it's just a cleanup thing19:17
jeblaircool19:17
mordred*phew*19:17
jeblairwith that... lunchtime.  :)19:18
mordredjeblair: when your patch lands, I'm going to restart the executors19:18
mordreds/s$//19:18
*** jlk` has joined #zuul19:20
*** jlk has quit IRC19:22
*** timrc has quit IRC19:24
*** timrc has joined #zuul19:25
*** jlk` is now known as jlk19:25
*** jlk has quit IRC19:26
*** jlk has joined #zuul19:26
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Fix typo in keep/unkeep commands  https://review.openstack.org/47940319:28
jeblairmordred: cool;  i think there's still something finicky with the pidfile, so i think 'service zuul-executor stop', followed by 'rm /var/run/zuul-executor/zuul-executor.pid' may be necessary.19:28
mordredjeblair: kk19:31
mordredjeblair: and we're bumping the installed version with pip3 install . yeah?19:32
jeblairmordred: ya19:32
jeblairthat 3 was the source of my recent troubles.19:32
jeblair(i mean puppet will do it, eventually, but we're not patient)19:33
mordredjeblair: I just did the same thing you did19:33
jeblairmordred: you just did 'pip install .'? yay!19:34
jeblairmordred: i think 'pip uninstall zuul ansible'; 'pip3 uninstall zuul ansible'; 'pip3 install /opt/zuul' will repair.19:35
mordredjeblair: sigh. it is not starting, nor is it giving any error19:38
mordredjeblair: if I start it with -d - it happily sits there19:39
jeblairmordred: lemme take a crack19:40
jeblairmordred: systemd thought it was running.  i did 'service zuul-executor stop' and 'service zuul-executor start'19:41
clarkbyou might need systemctl ?19:41
mordredjeblair: it's all yours19:41
clarkbnot sure how service works19:41
* mordred is SO HAPPY that in 2017 we've managed to make starting daemons hard. so much progress.19:42
jeblairmordred: ^ is running19:42
mordredjeblair: I agree19:42
mordredjeblair: what did you do?19:42
jeblairmordred: systemd thought it was running.  i did 'service zuul-executor stop' and 'service zuul-executor start'19:42
mordredah. nod19:42
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826519:51
openstackgerritTobias Henkel proposed openstack-infra/zuul feature/zuulv3: Expose final job attribute  https://review.openstack.org/47938219:52
jeblairokay, i have stuffed my face19:52
mordredjeblair: I believe I have witness a race condition you might want to know about19:53
jeblairi turned on keep19:53
mordredjeblair: /tmp/b86f1bb44c32430a8c7752945fb9f7d9 is the job dir for it - I pushed a new commit to 47826519:53
mordredjeblair: and it seems to have been re-enqueued - except it seems to have re-enqueued v20 of the change, not v2119:54
tobiashmordred: during run of the old change?19:54
tobiashmordred: I also observed that and this was on my list to figure out19:54
tobiashmordred: but didn't yet have time to dig deeper19:55
jeblairmordred, tobiash: noted19:55
mordredtobiash: yes19:56
jeblairmordred: i got this exception when trying to run the ssh keys role: http://paste.openstack.org/show/614218/19:58
jeblairmordred: is that because we're running modules under py3 on the executor (and even though we'd rather not, we haven't found a way to avoid it yet?)20:00
mordredjeblair: hrm. that's a fascinating new error20:01
mordredjeblair: were you running that one by hand?20:01
jeblairmordred: nope20:01
jeblairmordred: /tmp/eff4efb6e2b2483ab09b8bcaf843efd0/work/logs/job-output.txt20:02
jeblairmordred: (i did reformat the error by hand)20:02
jeblairs/hand/emacs/20:02
mordredah - nod20:04
jeblairmordred: i would have expected the 'ssh-add' that we do in log uploads to hit this too...20:05
jeblairmordred: unless..... it *is* also broken, but was masked by running ansible under py27 until recently20:06
mordredjeblair: yah. I betcha that's true20:06
mordredcause we're not getting logs now20:06
jeblairreading http://bugs.python.org/issue1740420:06
tobiashjeblair: seems like inheriting from a final job and overriding vars is not inhibited20:07
tobiashjeblair: https://review.openstack.org/#/c/479382/20:07
tobiashhttp://logs.openstack.org/82/479382/2/check/gate-zuul-python35/d482d9b/testr_results.html.gz20:08
jeblairtobiash: yay tests! :)20:08
tobiashjeblair: but breaking tests :(20:08
mordredjeblair: https://stackoverflow.com/questions/37462011/write-unbuffered-on-python-320:08
mordredjeblair: that does not seem to be complete20:09
jeblairmordred: i'm leaning toward treating it as a utf-8 encoded binary file... whatcha think?20:12
mordredjeblair: I was leaning towards the same thing20:12
jeblairmordred: i'll make a patch20:12
mordredjeblair: I already made one ...20:13
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Write logfile as binary encoded utf-8  https://review.openstack.org/47941320:13
mordredjeblair: I believe that should do it, yeah?20:13
jeblairmordred: almost20:14
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Fix exception handler in command module  https://review.openstack.org/47941420:16
jeblairmordred: ^ that's the other thing from that error20:16
mordredah - good20:16
mordredjeblair: should we also update the streamer code and tell it to open binary and send?20:16
jeblairmordred: see my inline comment on 47941320:16
mordredit would save a decode/encode step20:16
mordredjeblair: gah20:17
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Write logfile as binary encoded utf-8  https://review.openstack.org/47941320:17
jeblairmordred: i think we do string manipulation in the streamer?20:18
mordredoh - we scan for '\n'20:18
mordredwait -that's get_command20:19
mordredno - we just read 4096 bytes at a time and send them over the wire20:19
mordredI'll do that as a followup20:19
tobiashjeblair: I think JobParser.fromYaml should honor the final attribute and raise some exception if there is a violation right?20:19
jeblairmordred: in zuul_stream.py?20:20
mordredjeblair: oh - no - in log_streamer20:20
jeblairmordred: yep, that wfm20:22
jeblairtobiash: probably some of the work we're doing in Job.applyVariant needs to be copied to Job.inheritFrom20:24
jeblairtobiash: it looks like we only implemented final for variants, and need to add it to inheritance.20:24
jeblairtobiash: (in model.py)20:24
tobiashjeblair: I'll check if I can move that into a common function20:25
tobiashjeblair: that should not be implemented twice if not necessary20:25
jeblairtobiash: it's worth thinking about whether we need that though...20:25
tobiashjeblair: but will have to do that next week20:26
tobiashjeblair: because secrets are not moved to different projects anyway?20:26
jeblairtobiash: i'm not sure we gain much by disallowing inheritance, since we can already make secrets not inheritable.  all we really do is make it so that people have to copy a job to achive the same thing.  (i think)20:27
tobiashjeblair: right, I thought that would have had security implications, but when thinking deeper it's not that clear anymore20:28
jeblairtobiash: let's think about it some more over the weekend.  we may still want to do it just for least surprise (after all, 'final' has a meaning in programming... :)20:29
tobiashjeblair: agreed20:30
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Fix exception handler in command module  https://review.openstack.org/47941420:31
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Read the log file as binary in zuul_console  https://review.openstack.org/47941620:32
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Avoid decode/encode in the finger log stream server  https://review.openstack.org/47941720:32
mordredjeblair: ^^ I think we can consider both of those- but I think we should think it through before we dive20:33
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Write logfile as binary encoded utf-8  https://review.openstack.org/47941320:33
mordredjeblair: ok - I'm going to pull those and restart20:33
mordredjeblair: restarted20:37
jeblairmordred: both lgtm.  noted a fun fact on the first one.20:37
mordredjeblair: hah20:38
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Add TenantProjectConfig object  https://review.openstack.org/47907320:44
mordredjeblair: ok - the tox-linters job ran successfully again -so I think we're at least back up and running normally20:49
jeblairyay!20:49
jeblair2017-06-30 20:49:53,076 DEBUG zuul.AnsibleJob: [build: 4173cc29a9da42a2b69c033f781ab247] Ansible output: b' [WARNING]: Failure using method (v2_runner_on_ok) in callback plugin'20:52
jeblair2017-06-30 20:49:53,076 DEBUG zuul.AnsibleJob: [build: 4173cc29a9da42a2b69c033f781ab247] Ansible output: b'(<ansible.plugins.callback.zuul_stream.CallbackModule object at'20:52
jeblair2017-06-30 20:49:53,076 DEBUG zuul.AnsibleJob: [build: 4173cc29a9da42a2b69c033f781ab247] Ansible output: b'0x7f15bd67ee10>): not enough values to unpack (expected 2, got 1)'20:52
jeblairi wish i had a line number :(20:53
*** hashar has quit IRC20:53
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826520:55
jeblairmordred: any chance that error is line 204 of zuul_stream?20:55
mordredlemme look20:55
jeblair                    ts, ln = (x.strip() for x in line.split(' | ', 1))20:55
mordredjeblair: yup. I betcha it is20:55
jeblairi'd love to see that log file20:56
mordredme too20:56
mordredjeblair: OH - you know what...20:57
mordredjeblair: that's reading directly from stdout_lines on the task since it's localhost - which does not have the zuul_console streamer adding prefixes20:57
mordredso that split is never going to be the right thing20:58
jeblairmordred: makes sense20:58
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Don't try to split localhost log lines  https://review.openstack.org/47942520:59
mordredjeblair: ^^20:59
mordredWOOT! I got back to having failures on zuul-tox-linters that make it to the log21:00
jeblairlogs are cool21:00
mordredyah21:01
mordredjeblair: I added this: http://logs.openstack.org/65/478265/22/check/41b90a8/ansible-hostvars.ubuntu-xenial.yaml21:01
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Permit config shadowing  https://review.openstack.org/47908421:03
jeblairmordred: i like that, and moving other similar info out of the log might be nice21:04
mordredjeblair: yah21:04
mordredonce I've got a clean run I'm going to start refactoring :)21:05
mordredbut yah - there'sa bunch of stuff in the log that's very noisy21:05
jeblairmordred: for the 'run post even if pre fails' -- should we run all posts, or only the ones that are siblings with pres that we have attempted to run?21:07
mordredjeblair: I thnk the second21:08
mordredjeblair: sort of like addCleanup21:08
jeblairyeah.  it's harder.  :)21:09
mordred:)21:09
mordredjeblair: we could also run all of them and just make sure we run ALL of them even if one of them fails21:09
mordredso that if one of the inner post playbooks borks because it doesn't have its input - shrug21:09
jeblair(also, if a job adds 3 pre-playbooks, and 1 post playbook -- do we run that one post as long as we got as far as trying to run the first pre?)21:09
mordredyah - maybe just running the post playbooks21:09
mordredall of them - for now21:10
mordredand see how that goes21:10
jeblairyeah, let's give it a shot :)21:10
jeblairthe other is *doable*, just want to make sure we need the complexity it's going to add21:10
mordredagree21:10
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826521:13
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Don't try to split localhost log lines  https://review.openstack.org/47942521:13
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Always run post playbooks  https://review.openstack.org/47942721:15
jlkwow that was too much lunch21:26
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Fix exception handling in scheduler  https://review.openstack.org/47928321:27
mordredjlk: there's never too much lunch21:29
jlkmy gastrointestinal track would disagree with you21:29
SpamapSgive it time21:30
SpamapSit will come around21:30
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Carve out for stat  https://review.openstack.org/47909621:31
mordredjeblair: when your always-run-post patch lands I'd like to do another restart21:33
jeblairmordred: yeah, i bumped that to the top of the list for obvious raisins21:34
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826521:42
openstackgerritTobias Henkel proposed openstack-infra/zuul feature/zuulv3: Fix reenqueue wrong item on new patchset  https://review.openstack.org/47943221:44
tobiashjeblair, mordred: this fixes the reenqueue of the wrong ps ^^21:45
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Always run post playbooks  https://review.openstack.org/47942721:45
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826521:45
mordredtobiash: oh neat!21:45
tobiashso now really edo for me (almost midnight)...21:47
tobiashcya21:47
mordredthat is, in fact, going to bite me again rigth now :)21:47
mordredtobiash: have a good weekend!21:47
tobiashmordred: you too21:47
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Add test for running post playbooks after pre-playbooks fail  https://review.openstack.org/47943621:49
jeblairSpamapS: ^ good call on the tests :)21:50
jeblairmordred: you're going to want to land that ^ before the restart :)21:51
jeblair(meanwhile, i'm reviewing tobiash's change)21:52
mordredjeblair: yah21:53
mordredSpamapS: feel like an easy +A?21:53
jeblairmordred: tobiash's change lgtm.  the test failure is a known race; i rechecked.21:57
jeblairmordred: oh i think i forgot some git adds21:57
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826521:57
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Add test for running post playbooks after pre-playbooks fail  https://review.openstack.org/47943621:58
mordredjeblair: I'm having intermittent failures with log uploading that I don't have an answer for yet22:03
mordredjeblair: the log exists properly in teh right place - and the debug log shows the upload-logs playbook having been successful22:05
mordredjeblair: so - there's a heisenbug somewhere we likely want to keep our eyes out for22:05
jeblairmordred: anything get uploaded?22:06
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Read the log file as binary in zuul_console  https://review.openstack.org/47941622:06
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Avoid decode/encode in the finger log stream server  https://review.openstack.org/47941722:06
mordredjeblair: yup! http://logs.openstack.org/65/478265/26/check/6a4179a/job-output.txt - just the report back to gerrit for that job was zuul-tox-linters finger://ze01.openstack.org/6a4179a7e8ef41439a61cceb2d565600 : POST_FAILURE in 2m 08s22:07
mordredjeblair: (also - the job passed)22:07
SpamapSmordred: sure22:08
mordredSpamapS: ( https://review.openstack.org/#/c/479436/ )22:09
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826522:10
mordredok. that ^^ is going to pass the test22:11
jeblairmordred: it looks like this task failed:22:11
jeblair2017-06-30 22:00:13.831965 | TASK [Collect tox logs. mode=pull, dest=logs/tox, src={{ item.path }}/log/]22:11
jeblairmordred: part of the failure message made it into the executor log, but none of it ended up in the job log22:12
mordredoh. weird22:12
jeblairmordred: grep "failed:" executor-debug.log22:13
jeblairmordred: that's the bit that's in the executor log but not the job output22:13
jeblair(and of course it's truncated)22:13
mordredjeblair: aha22:14
jeblairbut that definitely seems like something that would be good to have in the job output22:14
jlkoh you've got unnamed tasks, so it's trying to put the task arguments into the log name, but it won't expand the jinja22:14
jlkyeah, don't use unnamed tasks22:14
mordredah - good catch22:15
mordredwell - we can do a better job of not completely failing there in the zuul_stream processing I hope22:15
jeblairjlk: where's the unnamed task?22:15
jlkASK [Collect tox logs. mode=pull, dest=logs/tox, src={{ item.path }}/log/]22:16
mordredyah - that's got a name yah?22:16
mordredOH22:16
jlkoh? are we trying to slurp the arguments up somewhere?22:16
mordredok. this is a with_items22:16
mordredI think we're missing something in our callback22:16
jeblair"Collect tox logs." is the name?22:16
jlkoooh maybe it adds the item into the task name output?22:17
mordredthe actual message is coming in as an sub-item to the task and we're clearly not handling it right22:17
mordredwell - items fire a callback too22:17
mordredI _thought_ they would fire the same one - but I'll now look in to that22:17
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Fix reenqueue wrong item on new patchset  https://review.openstack.org/47943222:18
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Add test for running post playbooks after pre-playbooks fail  https://review.openstack.org/47943622:19
SpamapSI seem to recall some good reasons not to reference {{ item }} in task names.22:20
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826522:20
mordredwe're missing v2_runner_item_on_ok v2_runner_item_on_failed and v2_runner_item_on_skipped22:22
mordredI'll work up a patch22:22
mordredSpamapS, jeblair, jlk: WOOT! https://review.openstack.org/#/c/478265/ passed (thanks for finding the issue on the tox dir thing22:23
mordredhttp://logs.openstack.org/65/478265/28/check/2102666/ has the job output, the ansible variables and the tox dir, as expected22:24
* jlk prepares for a long read.22:24
jlkmordred: what's the point of gather_facts true and gather_subset of !all?  Isn't that saying to not gather anything?22:29
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Don't log starting to log messages to build log  https://review.openstack.org/47943922:29
mordredjlk: !all means don't gather any of the extra facts22:29
mordredjlk: so it won't try facter or ec2 or any of that stuff22:30
jlkdo you need any gathered facts?22:30
mordredjlk: why that's "!all" is a mystery to me22:30
jeblairmaybe we only need that for the playbook where we print a bunch of facts?22:30
mordredjlk: that's a good point - I should probably go through and mark as "no" on the ones that don't need them22:31
mordredyah - it'suseful there - I dont' think we need it in most of the rest of the ones we're doing now22:31
jeblairmordred: maybe put a comment in the one(?) playbook that needs it saying why it's there and not to copy pasta it :)22:31
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Don't gather facts when we don't need them  https://review.openstack.org/47944122:35
mordredjlk: ^^22:35
jeblairmordred: can you squash those pls?22:36
jlkreading these, kind of wish the "script" task was used. Easier to have the source of hte script in it's own file than inserted in-line in the YAML22:36
mordredjlk: oh - also, on the long one - the intent is to start with content of the scripts we're running in the current infra jobs, but then to refactor that into real ansible22:36
jlknod22:36
jlkO22:36
jlkI'm trying to ignore the shell :)22:36
mordredyah. it's the best bet22:37
mordredit's a straight copy from the jenkins scripts22:37
* SpamapS really wants highlighting or pretty printing or something in those logs22:37
mordredjeblair: sure!22:37
mordredSpamapS: yup. me too - definitely on the list22:37
jeblairalso, removing some things from them.  :)22:37
mordredyah22:37
SpamapS2017-06-30 22:22:46.611111 | ubuntu-xenial | changed: Results: => {"changed": true, "gid": 1001, "group": "zuul", "mode": "0775", "owner": "zuul", "path": "/tmp/21026668ac2a4e7c98cceb9859ea4786/work/logs/tox", "size": 4096, "state": "directory", "uid": 1001}22:37
jlkleft a -1, you're calling a post-tasks twice and once pointing at a pre task22:37
SpamapSquite the jumble of "is this useful?"22:37
mordredjlk: sweet - thanks for poking your eyes out looking at that22:38
mordredbut yes - getting those logs being pleasing is important22:38
jlkit's a slow friday :)22:38
jeblairSpamapS: i don't really want to see that, however, that particular bit is what ansible outputs so i think we have to keep it there.  but yeah, highlighting can make that better.22:39
jeblairthings we can remove include boilerplate facts, etc, that can go into other files22:39
SpamapSjeblair: I wonder if we could fold those in the HTML-izing of the logs.22:42
SpamapSlike just make the json a little [+]22:42
* SpamapS will noodle on it22:43
SpamapSjust hard to really see what happened.22:43
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Port in tox jobs from openstack-zuul-jobs  https://review.openstack.org/47826522:43
SpamapSbut the part that shows the output of the running things is quite nice compared to usual ansible :)22:44
SpamapSso.. progress.22:44
mordredyup!22:44
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: WIP: pass result data back from ansible  https://review.openstack.org/47944222:45
jeblairSpamapS, mordred: also, probably worth thinking about this after ARA is in the mix too22:46
mordredyah22:46
mordredand where/how os-loganalyze may fit into the picture22:46
mordredtons of options/possibliities - but I'm just happy we're collecting the logs and publishing them!!! :)22:47
jeblairSpamapS, mordred, jlk: ^ that's a start on work to pass data back from ansible to zuul; feedback on the approach while i work on some tests is welcome.22:47
jlkSeems useful22:50
jeblair(i think i'd like to get rid of success-url and failure-url, and just have that be automatic based on something returned from this.  but we can have a transition period where we just use success-url to interpolate a value in result_data)22:50
jlkI have to flee to commute home.22:50
jeblairjlk: have a good commute and holiday!22:50
mordredjeblair: I like it22:50
jlkyah, cheers all!22:50
mordredjlk: have a great weekend!22:51
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: DNM This has a yaml syntax error in a job playbook  https://review.openstack.org/47944622:52
mordredjeblair: ok - the "print things on parse error" worked - but is totes missing newlines22:57
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Add newlines to parse error output  https://review.openstack.org/47944822:59
jeblairmordred: ++23:01
mordredjeblair: I feel like we've got a few patches queued up it would be good to restart with23:07
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Add newlines to parse error output  https://review.openstack.org/47944823:18
jeblairmordred: i'll restart now23:25
jeblairmordred: done23:26
mordred\o/23:33
mordredjeblair: I'm rechecking the syntax error23:33
jeblairmordred: i've got a command which is exiting with rc=1.  i'm pretty sure it should output a line to the log, but it isn't.23:36
jeblairmordred: http://paste.openstack.org/show/614223/23:36
jeblairmordred: the first 3 lines are from a similar command which succeeds, and i see output there23:37
jeblairmordred: but the last 2 are from a failure.23:37
jeblairmordred: i'm about 95% sure i know what the error is, and that it should emit one line of output23:37
jeblairmordred: oh, but i don't know if it's stdout or stderr, lemme check23:37
mordredjeblair: also - is it using with_items?23:38
jeblairmordred: no with_items -- it's here: http://git.openstack.org/cgit/openstack-infra/openstack-zuul-roles/tree/roles/add-build-sshkey/tasks/create-key-and-replace.yaml#n1123:39
jeblairmordred: the line i'm missing *is* going to stderr23:39
mordredoh. are we maybe not combining stdout and stderr when we do the localhost override?23:40
jeblairmordred: starting to look that way23:40
mordredjeblair: hrm I would expect givne the code that we'd be sending stderr to stdout in both cases23:41
mordredjeblair: we don't special case that in the module23:41
jeblairmordred: ok.  i'll try running manually and see if i can find out where its going23:42
mordredjeblair: kk. I'm eod'ing - I'll poke in in the morning and see what you've found23:48
jeblairmordred: okay have a nice weekend!23:48
mordredjeblair: you too!23:49

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