| *** bhavik1 has joined #zuul | 03:15 | |
| *** bhavik1 has quit IRC | 03:27 | |
| *** bstinson has quit IRC | 04:10 | |
| openstackgerrit | Andreas Jaeger proposed openstack-infra/zuul-jobs master: Silence ansible-lint https://review.openstack.org/515520 | 04:11 |
|---|---|---|
| *** bstinson has joined #zuul | 04:14 | |
| *** pleia2 has quit IRC | 04:21 | |
| *** pleia2 has joined #zuul | 04:22 | |
| *** logan- has quit IRC | 04:38 | |
| *** logan- has joined #zuul | 04:42 | |
| *** maxamillion has quit IRC | 04:51 | |
| *** pleia2 has quit IRC | 04:51 | |
| *** bstinson has quit IRC | 04:51 | |
| *** bhavik1 has joined #zuul | 05:02 | |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul feature/zuulv3: DNM: test ansible crash logging https://review.openstack.org/515470 | 05:04 |
| *** bstinson has joined #zuul | 05:04 | |
| *** maxamillion has joined #zuul | 05:05 | |
| *** pleia2 has joined #zuul | 05:05 | |
| openstackgerrit | Merged openstack-infra/zuul-jobs master: Silence ansible-lint https://review.openstack.org/515520 | 05:10 |
| *** bstinson has quit IRC | 05:19 | |
| openstackgerrit | Andreas Jaeger proposed openstack-infra/zuul-jobs master: WIP: Run ansible-lint on repo https://review.openstack.org/515593 | 05:19 |
| openstackgerrit | Andreas Jaeger proposed openstack-infra/zuul-jobs master: WIP: Run ansible-lint on repo https://review.openstack.org/515593 | 05:19 |
| *** bstinson has joined #zuul | 05:22 | |
| openstackgerrit | Andreas Jaeger proposed openstack-infra/zuul-jobs master: WIP: Run ansible-lint on repo https://review.openstack.org/515593 | 05:39 |
| *** yolanda has joined #zuul | 05:42 | |
| openstackgerrit | Andreas Jaeger proposed openstack-infra/zuul-jobs master: Run ansible-lint on repo https://review.openstack.org/515593 | 05:44 |
| openstackgerrit | Andreas Jaeger proposed openstack-infra/zuul-jobs master: Run ansible-lint on repo https://review.openstack.org/515593 | 05:49 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul feature/zuulv3: DNM: test ansible crash logging https://review.openstack.org/515470 | 05:49 |
| *** yolanda__ has joined #zuul | 06:02 | |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul feature/zuulv3: Do late decoding of log stream buffer https://review.openstack.org/515043 | 06:04 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul feature/zuulv3: Correctly stream the remaining buffer https://review.openstack.org/515470 | 06:04 |
| *** bhavik1 has quit IRC | 06:18 | |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul feature/zuulv3: Correctly stream the remaining buffer https://review.openstack.org/515470 | 06:45 |
| *** yolanda__ has quit IRC | 07:27 | |
| *** hashar has joined #zuul | 08:09 | |
| *** electrofelix has joined #zuul | 08:48 | |
| jkt | SpamapS: that's that part which I like about submodules -- it's one standard implementation of that checking out script, so that I don't have to maintain my owm | 09:32 |
| jkt | SpamapS: a colleague just lost two days of work getting mad at his non-working shell scripts for this purpose :) | 09:32 |
| *** hashar is now known as hasharLunch | 10:13 | |
| *** robcresswell has quit IRC | 11:03 | |
| *** sambetts|afk is now known as sambetts | 11:41 | |
| *** electrofelix has quit IRC | 11:43 | |
| *** electrofelix has joined #zuul | 11:43 | |
| *** hasharLunch is now known as hashar | 11:48 | |
| Shrews | My new phone dies yesterday after only 24 hours of use. I wake up this morning (coldest morning yet of the winter) to no heat. What a wonderful way to end the week. | 12:41 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Move test_model.test_job_inheritance_configloader https://review.openstack.org/509495 | 12:51 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Remove test_job_inheritance https://review.openstack.org/509509 | 12:51 |
| * dmsimard is sad he can't release a new version of ara until monday | 12:51 | |
| *** fdegir has quit IRC | 13:19 | |
| *** fdegir has joined #zuul | 13:19 | |
| dmsimard | Shrews: do you have the URL to that etherpad we had for zuul with ansible 2.4 ? | 13:41 |
| Shrews | dmsimard: there was an etherpad?? | 13:42 |
| Shrews | i guess that's a "no" answer :) | 13:42 |
| dmsimard | Shrews: there was :/ | 13:45 |
| * dmsimard searches logs | 13:45 | |
| dmsimard | Shrews: oh it was with jlk https://etherpad.openstack.org/p/zuul-ansible-2.4 | 13:46 |
| dmsimard | mixed you two you | 13:46 |
| dmsimard | mixed you two up* | 13:46 |
| openstackgerrit | Merged openstack-infra/zuul-jobs master: Run ansible-lint on repo https://review.openstack.org/515593 | 13:59 |
| jeblair | tobiash: responded on 515536 | 14:58 |
| tobiash | jeblair: thanks, now I understand | 14:59 |
| tobiash | :) | 14:59 |
| tobiash | jeblair: I think I'm through your stack | 15:00 |
| SpamapS | jkt: understood, but it's also extremely inflexible, and makes cross-repository testing nearly impossible. I wouldn't say that Zuul will never support them, but I would say you are likely going to need to find submodule fans to design and write the feature, because none of us are submodule fans. ;) | 15:53 |
| SpamapS | jkt: you _might_ be able to get it all done in zuul-jobs actually | 15:54 |
| *** hashar is now known as hasharAway | 16:18 | |
| *** robcresswell has joined #zuul | 16:19 | |
| mnaser | jeblair: i was wondering under what is the issue we discussed (inheritance stuff) is listed under in zuulv3 issues to track it so i dont ping you and i can look at the reviews/updates :) | 16:23 |
| SpamapS | so, today's challenge.. FYI.. is feeding secrets into my zuul job so that it can spin up LBaaS resources that point at the nodes that nodepool spun up. This.. could be tricky. ;) | 16:39 |
| *** sambetts is now known as sambetts|afk | 16:41 | |
| *** hasharAway has quit IRC | 16:41 | |
| SpamapS | also trying to debug why my zuul is dropping the comment config item from the githubreporter | 16:48 |
| jkt | SpamapS: actually, I'm using that (sort of) for "cross-repo testing" -- the submodules are 3rd-party repos that I cannot CI-gate, so I explicitly tie their versions with my code, and I gate that combination | 16:48 |
| jkt | SpamapS: so if I want to update a dep, I update a submodule (and possibly also my code) in one commit, and let Zuul test that combination | 16:49 |
| SpamapS | jkt: yeah if they're public repos and your nodes have good access to them, that is a simple solution. | 16:50 |
| fungi | heads up, the zuul v3 migration thread on the openstack-dev ml is getting hijacked with questions about deploying zuul v3, if anyone here has time to answer: http://lists.openstack.org/pipermail/openstack-dev/2017-October/124048.html | 16:56 |
| *** electrofelix has quit IRC | 16:56 | |
| clarkb | SpamapS: you might be able to just run a task on the executor that looped through each of the nodepool nodes adding them to some load balancer pool. I think because ansible has shade things you can do it all natively too | 17:05 |
| openstackgerrit | Andreas Jaeger proposed openstack-infra/zuul-jobs master: Ansible linting fixes https://review.openstack.org/515778 | 17:05 |
| SpamapS | clarkb: the problem is I have to add them to a pool in the same tenant as nodepool spun the vm up in | 17:12 |
| SpamapS | but that's not so bad | 17:12 |
| SpamapS | and I already have that ansible written. | 17:12 |
| clarkb | wait really? | 17:12 |
| SpamapS | I just have to separate it out from other things, because it has to run trusted. | 17:12 |
| clarkb | its not valid to load balance arbitrary IPs? | 17:13 |
| clarkb | actually I seem to recall this is why lbaas testing is so difficult | 17:13 |
| clarkb | they need actual backends running in a cloud (not great to do with qemu) | 17:13 |
| SpamapS | clarkb: oh actually it is | 17:13 |
| SpamapS | but | 17:14 |
| SpamapS | I have a funky cloud | 17:14 |
| SpamapS | actually no, this might work | 17:14 |
| SpamapS | clarkb: thanks, I can at least try it with a distinct project just for the load balancers. :) | 17:15 |
| Shrews | SpamapS: a funky cloud, with a funky funky style? | 17:16 |
| jeblair | mnaser: i was bad and did not add to etherpad. will do so now. | 17:17 |
| openstackgerrit | Andreas Jaeger proposed openstack-infra/zuul-jobs master: Ansible linting fixes https://review.openstack.org/515778 | 17:18 |
| jeblair | mnaser: the stack starts at https://review.openstack.org/514459 | 17:19 |
| SpamapS | Shrews: this cloud drops beats on the daily | 17:27 |
| SpamapS | hrm | 17:44 |
| SpamapS | I think my theory that 3s is enough for github is actually wrong | 17:45 |
| SpamapS | just hit it with that patch installed | 17:45 |
| SpamapS | looks like Github is just as broken as Gerrit in that regard.. | 17:45 |
| SpamapS | so.. this is weird | 17:49 |
| SpamapS | http://paste.openstack.org/show/624842/ | 17:49 |
| SpamapS | I have a change, which depends on another, which is merged. And the dependent change is failing to go into the gate. | 17:49 |
| SpamapS | 2017-10-27 10:47:33,534 DEBUG zuul.Pipeline.GoDaddy.gate: Change <Change 0x7f64fc0cce80 5,f8a6d40db753e30f0e270ce79dedba17fc906640> in project cloudplatform/godaddy-zuul-jobs does not share a change queue with <Change 0x7f64fc160cf8 144,4c0378812b0d9b2e0b7bbd08e1bbebc1d3d48e93> in project cloudplatform/k8s-ansible | 17:49 |
| SpamapS | 2017-10-27 10:47:33,534 DEBUG zuul.Pipeline.GoDaddy.gate: Failed to enqueue changes ahead of <Change 0x7f64fc160cf8 144,4c0378812b0d9b2e0b7bbd08e1bbebc1d3d48e93> | 17:49 |
| SpamapS | Not sure why it think it needs to enqueue it, when 5,f8a6d40db753e30f0e270ce79dedba17fc906640 is already merged. | 17:50 |
| tobiash | SpamapS: was the dependee merged by zuul itself? | 17:58 |
| tobiash | maybe zuul doesn't know that it's merged | 17:58 |
| SpamapS | tobiash: it was, but zuul should still check with github, since it may have been restarted since then. | 17:59 |
| tobiash | hm, maybe a bug in the cache handling | 18:00 |
| SpamapS | no, the logic I'm reading says that if you depend on something you don't have a shared queue with, you can't ever merge | 18:05 |
| SpamapS | jeblair: ^^ is that intentional or am I reading it wrong? | 18:05 |
| *** harlowja has quit IRC | 18:05 | |
| *** harlowja has joined #zuul | 18:05 | |
| tobiash | SpamapS: that logic sounds broken and needs to be fixed ;) | 18:06 |
| SpamapS | agreed | 18:06 |
| SpamapS | but what I see is that dependent calls enqueueChangesAhead, which checks for needed changes using checkForNeededChanges, which returns false if any needs_change changes don't share a queue with the change being considered. | 18:08 |
| jeblair | SpamapS: a merged change shouldn't show up in the needed changes | 18:15 |
| jeblair | (that's the cutoff so we don't pull in a linked list of every git commit ever :) | 18:15 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: Create fetch-puppet-module-output role https://review.openstack.org/515798 | 18:16 |
| SpamapS | jeblair: hrm, so github driver maybe isn't seeing that it is merged. | 18:19 |
| SpamapS | jeblair: and yeah, in reading the tests, I was thinking the logic that is there is the right logic, and was wondering how this change was still being considered. | 18:20 |
| mnaser | jeblair: thanks for the info | 18:22 |
| SpamapS | so github driver checks the is_merged attribute of the PR | 18:23 |
| SpamapS | I think we may have a cache invalidation issue | 18:27 |
| SpamapS | tobiash: good call | 18:27 |
| tobiash | :) | 18:27 |
| SpamapS | oh whoa | 18:48 |
| SpamapS | maintainConnectionCache is never called? | 18:48 |
| SpamapS | That means we never actually refresh PRs in github. | 18:50 |
| tobiash | SpamapS: I think maintainConnectionCache was initially to clean up the cache | 18:59 |
| tobiash | Not to refresh it | 18:59 |
| tobiash | Since v3 it isn't called anymore | 19:00 |
| jeblair | yeah, it's only in there as a stub until we figure out something better; my weakref change removed it, but that didn't work out. | 19:00 |
| jeblair | (i'd like to look further into that but haven't been able to) | 19:01 |
| SpamapS | Just trying to figure out how things get refreshed. | 19:02 |
| jeblair | SpamapS: but PRs should refresh when any event arrives for them, like the event we (presumably?) get when they are merged | 19:02 |
| jeblair | SpamapS: (see line 190 in githubconnection) | 19:02 |
| SpamapS | jeblair: so maybe I didn't get a webhook when the parent merged. | 19:02 |
| * SpamapS looks for it in logs | 19:03 | |
| jeblair | SpamapS: yeah, if it missed that, it may not recover :/ | 19:03 |
| SpamapS | actually, zuul merged it | 19:03 |
| jeblair | SpamapS: it still wouldn't update the change in memory unless it got an event after merging though | 19:03 |
| SpamapS | kk | 19:03 |
| jeblair | (it doesn't assume it's state change actually took until it can confirm it) | 19:04 |
| SpamapS | hm, zuul also left the status as pending: GoDaddy/gate gate status: pending | 19:04 |
| SpamapS | me thinks there were issues | 19:04 |
| jeblair | SpamapS: posting a comment on the PR might be enough to get it to refresh | 19:04 |
| * SpamapS digs | 19:04 | |
| jeblair | ++ | 19:04 |
| openstackgerrit | Merged openstack-infra/zuul-jobs master: Create fetch-puppet-module-output role https://review.openstack.org/515798 | 19:05 |
| SpamapS | jeblair: I think this is all the "lags behind events" problem | 19:09 |
| SpamapS | jeblair: the PR merges.. webhook fires... API responds is_merged:False for a small window | 19:09 |
| SpamapS | 2017-10-26 16:04:38,486 DEBUG zuul.GithubConnection: Set commit status to success for sha f8a6d40db753e30f0e270ce79dedba17fc906640 on cloudplatform/godaddy-zuul-jobs | 19:10 |
| SpamapS | super weird because it's showing as pending still | 19:10 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Add multi-branch support for project-templates https://review.openstack.org/515805 | 19:12 |
| jeblair | tobiash: ^ if you're still around | 19:13 |
| jeblair | Shrews: ^ you too | 19:15 |
| Shrews | looking | 19:16 |
| SpamapS | OH! | 19:19 |
| SpamapS | the gate is left pending in the PR | 19:19 |
| SpamapS | because the commit that is marked as 'success' is the child | 19:19 |
| SpamapS | https://photos.app.goo.gl/4zYNLu72ytQpEnAf2 | 19:20 |
| SpamapS | jlk: ^ | 19:20 |
| SpamapS | I wonder if we should try and set the status on the merge commit too | 19:20 |
| Shrews | jeblair: wow, that hurts my head. If a project has 2 branches (A and B), each defining the same template, and the 'project' definition in B uses that template, what is supposed to happen? The templates are merged and the jobs from each are run? | 19:22 |
| jeblair | Shrews: the templates are merged and the jobs from each are added to the list of jobs to *possibly* run. however, all of those jobs will now have implied branch matchers, so only the jobs on B will run for changes to B | 19:23 |
| jeblair | oh hrm | 19:24 |
| Shrews | jeblair: then what's the point of merging? | 19:24 |
| jeblair | i think there's a case i haven't thought through yet -- and that's that even if a template and all of its jobs were defined in zuul-jobs and therefore have no branch matchers, if the template is applied only in a stable branch, we need to add implied branch matchers there. so i need to put back some of the project-template branch matcher logic i remove in that change. (and add a test). | 19:25 |
| Shrews | a test might help me see the end result more betterer | 19:26 |
| jeblair | Shrews: the merging is just the method of reconciling multiple config objects with the same name. we have to build the project pipeline definitions at config time, and we lose the templates and their context at that point. | 19:26 |
| jeblair | Shrews: basically, by the time configuration is done, there aren't any templates any more. just a single project definitions with all the jobs that project is supposed to run in the various pipelines. | 19:27 |
| Shrews | *nod* | 19:28 |
| jeblair | i'll wip it until i address the issue above | 19:28 |
| Shrews | SpamapS: i find the "cbyrum committed 2 days ago" text very reassuring | 19:29 |
| Shrews | all locked up, safe and sound | 19:29 |
| jeblair | that explains the facial hair too | 19:29 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Add implied branch matchers on 'master' https://review.openstack.org/514459 | 19:30 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Switch to late-binding inheritance https://review.openstack.org/511352 | 19:33 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Move test_job_auth_inheritance to test_v3 https://review.openstack.org/515249 | 19:33 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Add pragma directive https://review.openstack.org/515483 | 19:33 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Support file extension in playbook path https://review.openstack.org/515535 | 19:33 |
| SpamapS | Shrews: the point of the picture is to show the green check mark next to the commit by me, but the PR cares about the merge commit's status. | 19:33 |
| SpamapS | which is a little weird | 19:33 |
| SpamapS | and likely represents another github mismatch with gating in general | 19:34 |
| Shrews | SpamapS: yep. i was just failing at a bit of humor there. :) | 19:36 |
| SpamapS | Shrews: wasn't sure it was clear enough is all. Glad you value my commitment. | 19:38 |
| SpamapS | looking at the logic of _getChange | 19:38 |
| SpamapS | I think it may be broken | 19:38 |
| SpamapS | https://github.com/openstack-infra/zuul/blob/feature/zuulv3/zuul/driver/github/githubconnection.py#L613-L631 | 19:39 |
| SpamapS | Hrm no, we do run _updateChange which should grab it from the API and update it. | 19:42 |
| SpamapS | ow, so looks like my assumption that 3s was enough for github was wrong | 19:46 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: Increase github delay to 10 seconds https://review.openstack.org/515812 | 19:49 |
| SpamapS | I wonder if we could start tracking the etags and using If-None-Match. Maybe GitHub will actually invalidate its cache if you get a miss there where without one it just returns whatever it has in its cache | 19:58 |
| SpamapS | They also don't count 304's against rate limiting so that seems like a win. | 19:58 |
| * SpamapS is going to try that next | 19:59 | |
| *** hashar has joined #zuul | 20:22 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Add multi-branch support for project-templates https://review.openstack.org/515805 | 20:41 |
| jeblair | Shrews, clarkb: ^ that's updated to fix the thing i was concerned about, and a test case to exercise it | 20:42 |
| jeblair | anyone around to review that ^? i'd love to get it in with the others and restart | 21:27 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Update test fixtures to use explicit run https://review.openstack.org/515536 | 21:30 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Remove implied run https://review.openstack.org/515487 | 21:30 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Validate that a job has a run playbook on freeze https://review.openstack.org/515537 | 21:30 |
| SpamapS | wow... the github3 lib makes this.. hard | 21:31 |
| *** hashar has quit IRC | 21:39 | |
| SpamapS | oh poo, no, we're already doing it | 21:43 |
| SpamapS | wow, Github.. your API.. sucks then. | 21:43 |
| * SpamapS seeing delays > 10s | 21:43 | |
| jeblair | wow, that's pretty messed up | 21:49 |
| jeblair | i mean, we put in the 5s delay for gerrit because, you know, sometimes it was like 1 second behind so 5s seemed really generous. | 21:50 |
| jeblair | (tbh, i don't know how they both ended up with systems that emit events before they are durable, but hey) | 21:51 |
| SpamapS | jeblair: I think they're durable, but there are caches fronting the retrieval that don't get invalidated. | 21:54 |
| SpamapS | which you'd think would, you know, be keyed off the etag. | 21:55 |
| jeblair | i'm going to self-approve 515805 so i can get working on this restart. retro-reviews are welcome. | 22:01 |
| SpamapS | well that's quite a commit message. :-D | 22:09 |
| jeblair | fungi: i replied to the msg on openstack-dev, directing my reply to openstack-infra | 22:18 |
| SpamapS | jeblair: so, secrets usage question. I have a job which runs some ansible against nodes. I'd like to ask the cloud those nodes run in to allocate a loadbalancer using octavia, and point at those nodes.. | 22:45 |
| SpamapS | jeblair: 1) Can I even do that anywhere in a check pipeline safely? | 22:45 |
| SpamapS | jeblair: 2) If so, how? if not.. do you have suggestions how we might test the loadbalancer interactions before gating? | 22:46 |
| SpamapS | to be more clear, I planned on putting secrets in my job definition and having the ansible for the job set up the loadbalancer. | 22:51 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Add multi-branch support for project-templates https://review.openstack.org/515805 | 23:09 |
| jeblair | SpamapS: i think you can make a pre-run playbook to set up the load balancer (and a post-run to destroy it). if you put those playbooks and the job that uses them in a trusted project, it's safe for those playbooks to use secrets. you can then inherit from *that* job and put that child anywhere and have it do anything in any pipeline. | 23:11 |
| jeblair | SpamapS: like this http://paste.openstack.org/show/624857/ | 23:14 |
| jeblair | SpamapS: with more actual correct zuul syntax: http://paste.openstack.org/show/624858/ | 23:15 |
| SpamapS | jeblair: ok, and I can just have the pre leave the details of the LB somewhere on disk for the run to find. | 23:24 |
| SpamapS | (mostly just need the vip of the lb so I can configure things properly and test against the vip) | 23:25 |
| jeblair | SpamapS: ah yep. can drop them in the executor.... i wonder if zuul_return would work... lemme check | 23:25 |
| SpamapS | jeblair: thanks. I was reading the manual and just not sure. It kind of feels, when reading, like you just can't use a post-review job in a pre-review pipeline. | 23:25 |
| jeblair | SpamapS: that is true -- you can't use a post-review job in pre-review. however, a job is only post-review if either a) you set it explicitly, or b) it has secrets attached to it in an untrusted repo. but we're attaching secrets in a *trusted* repo, so it's okay. | 23:27 |
| SpamapS | jeblair: I think we're going to need pictures in the manuals, especially with the inheritance changes (which are awesome btw, I'm about to start running distinct tests per branch here!) | 23:30 |
| SpamapS | like, I ingested all of that at one point | 23:30 |
| SpamapS | but it didn't really sink in until I tried to put it in a zuul.yaml | 23:30 |
| SpamapS | jeblair: thanks for explaining slowly and patiently for me. :) | 23:31 |
| jeblair | SpamapS: no problem | 23:31 |
| jeblair | SpamapS: i don't think you can use zuul_return to ship the data between playbooks... i'll think about whether we could adapt it for that, but i suspect it may be dangerous. so in the mean time, probably just handle that yourself with a private file on the executor. you can stick it in the jobdir/trusted directory if you want to make sure the child jobs can't manipulate it (eg, make the post playbook destroy the wrong load balancer) | 23:33 |
| jeblair | SpamapS: but obviously you'll need at least a copy of the info in jobdir/work for the child job to be able to pick it up | 23:33 |
| SpamapS | jeblair: right, zuul_return seems more like a way to ship things from job -> job not so much from pre->run. | 23:34 |
| jeblair | yep | 23:34 |
| SpamapS | jeblair: and my plan for not letting the run playbook mess with it is that the name of the lbaas is the build UUID which should allow me to find and delete it no matter what happens before pre tries to run. | 23:38 |
| SpamapS | all I really need is that vip | 23:38 |
| jeblair | SpamapS: cool, that sound solid. | 23:56 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!