| tristanC | pabelanger: clarkb: shouldn't we sqlreport each RETRY_LIMIT for paul's use case? | 00:01 |
|---|---|---|
| clarkb | tristanC: we report the last failure as retry limit. THe problem is for the earlier failures that may or may not result in a retry limit | 00:01 |
| tristanC | I meant each failure resulting in a retry limit yes | 00:02 |
| clarkb | by default you get 3 attempts. So if the first two fail then the third pass you won't get that information | 00:03 |
| clarkb | with openstack we do sort of get that through the tracking with elasticsearch, but paul doesn't have that | 00:03 |
| tristanC | about elasticsearch, we would like to propose a logstash role as described in this story: https://tree.taiga.io/project/morucci-software-factory/us/2103 | 00:06 |
| tristanC | that is to replace this one we are currently using: https://review.openstack.org/537847 | 00:06 |
| clarkb | tristanC: it would be helpful if we could track those things upstream. I agree having a more "normal" logstash submission role would be useful | 00:08 |
| clarkb | tristanC: I do think thee is merit to the existing system (you don't have to block on it as its fully async in the background is a big one) | 00:08 |
| clarkb | but offering both would be good | 00:08 |
| clarkb | tristanC: maybe make it a toggle on the submit log logstash job role. Default is write to tcp input (or similar) and flag could be to submit gearman job as openstack does | 00:11 |
| clarkb | one issue is there are a lot of logstash input options. but TCP is likely a "safe" one here | 00:11 |
| tristanC | I agree, these could be implemented in a single role | 00:12 |
| clarkb | another option is separate roles which might help avoid confusion | 00:13 |
| clarkb | (why is there this gearman option?) | 00:13 |
| tristanC | another improvement would be to report role usage information. It seems like this is already part of the job-output.json, thus we could anotate logstash event with the role name | 00:20 |
| tristanC | and if the console stream could include that information, we could really prettify the stream web page by grouping the lines per roles | 00:22 |
| clarkb | right now it only has the play and task info right? | 00:23 |
| tristanC | clarkb: there is a role dictionary attached to each task | 00:23 |
| tristanC | granted it doesn't tell you the source context, but that is still useful if we could filter kibana queries with it :) | 00:25 |
| tristanC | e.g. curl http://logs.openstack.org/72/599472/8/check/tox-pep8/91380a0/job-output.json.gz | gzip -d | grep '"role":' -A 3 | grep '"name":' | 00:30 |
| clarkb | ya the info is avaialble but not exposed in the console stream iirc. I do agree that it would be helpful though | 00:31 |
| *** persia has quit IRC | 02:24 | |
| *** persia has joined #zuul | 02:24 | |
| mrhillsman | i got some jobs running that i know 100% the change is not touching anything relevant and i want to kill them | 03:03 |
| SpamapS | hrm.. seeing more weirdness in post jobs | 03:03 |
| mrhillsman | not sure if dequeue is the right command but last time i used it things went haywire | 03:03 |
| SpamapS | in theory dequeue works. | 03:03 |
| mrhillsman | ok, will try it again :) | 03:04 |
| SpamapS | In reality, killing the ansible-playbook process is the one I've used in the past. | 03:04 |
| * mrhillsman crosses fingers | 03:04 | |
| mrhillsman | hrm...not sure i trust client | 03:06 |
| mrhillsman | zuul show fails | 03:06 |
| mrhillsman | guess i'll just let it ride | 03:06 |
| SpamapS | Hm.. not sure I understand how branch matchers work with github push events. | 03:11 |
| SpamapS | Also variants. I have a job with 'branches: master' and another similar job with 'branches: prod' and it seems like the *post* playbook for both branches | 03:12 |
| SpamapS | http://zuullogsgdmnyco.s3-website-us-west-2.amazonaws.com/db/db4d83d8b94528015a66153e910970c98486e3ef/post/gmapidev-post/0905c1c/job-output.txt | 03:12 |
| SpamapS | actually the pre's run that way too | 03:14 |
| SpamapS | but the vars are all from the 'master' version of the job | 03:14 |
| * SpamapS so confused | 03:14 | |
| mrhillsman | not sure i can help being so new to using zuul | 03:22 |
| mrhillsman | nor what you are trying to do that you are not able to | 03:23 |
| mrhillsman | i do not actually see a question in your text but again that could be because i am new and do not have expected context to see/understand | 03:24 |
| *** bhavikdbavishi has joined #zuul | 03:44 | |
| *** sean-k-mooney has quit IRC | 03:57 | |
| *** sean-k-mooney has joined #zuul | 04:04 | |
| *** bhavikdbavishi has quit IRC | 04:47 | |
| *** fbo has quit IRC | 04:54 | |
| *** bhavikdbavishi has joined #zuul | 05:13 | |
| *** bhavikdbavishi has quit IRC | 05:18 | |
| SpamapS | mrhillsman: thanks... I'm mostly just bitching. ;) | 05:21 |
| mrhillsman | hehe ok | 05:21 |
| *** bhavikdbavishi has joined #zuul | 05:52 | |
| *** bhavikdbavishi has quit IRC | 06:04 | |
| *** bhavikdbavishi has joined #zuul | 06:08 | |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool master: Implement an OpenShift resource provider https://review.openstack.org/570667 | 06:41 |
| *** bhavikdbavishi has quit IRC | 07:35 | |
| *** pcaruana has joined #zuul | 08:00 | |
| SpamapS | hrm, this really does just make no sense at all to me. :-P | 08:06 |
| *** bhavikdbavishi has joined #zuul | 08:36 | |
| *** bhavikdbavishi has quit IRC | 09:30 | |
| *** bhavikdbavishi has joined #zuul | 10:58 | |
| *** bhavikdbavishi has quit IRC | 11:34 | |
| *** dkehn has quit IRC | 11:54 | |
| *** bhavikdbavishi has joined #zuul | 12:20 | |
| *** dkehn has joined #zuul | 12:23 | |
| *** goern has quit IRC | 12:44 | |
| *** bhavikdbavishi has quit IRC | 13:28 | |
| *** ssbarnea|rover has quit IRC | 14:28 | |
| *** ssbarnea|rover has joined #zuul | 14:30 | |
| *** bhavikdbavishi has joined #zuul | 15:40 | |
| *** bhavikdbavishi has quit IRC | 15:58 | |
| *** goern has joined #zuul | 16:14 | |
| *** bhavikdbavishi has joined #zuul | 16:34 | |
| *** bhavikdbavishi has quit IRC | 16:46 | |
| SpamapS | So I guess what I'm experiencing has to do with branch matching. I have two identical copies of the job, one in prod, one in master, and as such, both are running against the push to master. So.. do I have to remove the job from the `prod` branch? That seems... very unexpected. | 23:48 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!