| *** rlandy has quit IRC | 00:52 | |
| *** yolanda_ has joined #zuul | 05:27 | |
| *** yolanda has quit IRC | 05:28 | |
| *** CrayZee has joined #zuul | 05:31 | |
| *** swest has quit IRC | 05:47 | |
| *** bhavik1 has joined #zuul | 06:17 | |
| *** bhavik1 has quit IRC | 06:23 | |
| *** threestrands has quit IRC | 06:32 | |
| *** threestrands has joined #zuul | 06:50 | |
| *** threestrands has quit IRC | 06:50 | |
| *** threestrands has joined #zuul | 06:50 | |
| *** threestrands has quit IRC | 07:10 | |
| *** sshnaidm|off is now known as sshnaidm | 07:14 | |
| *** jpena|off is now known as jpena | 07:48 | |
| sshnaidm | can I get http://zuul.openstack.org/builds.html information in json? Is there any docs about it? | 07:48 |
|---|---|---|
| *** yolanda_ has quit IRC | 07:49 | |
| *** swest has joined #zuul | 07:52 | |
| *** electrofelix has joined #zuul | 07:54 | |
| tobiash | sshnaidm: e.g. http://zuul.openstack.org/api/builds?job_name=nova-next | 07:57 |
| sshnaidm | tobiash, yep, are there docs of api? | 07:58 |
| tobiash | I think that api is not really documented yet | 07:58 |
| tobiash | at least I don't find it right now | 07:58 |
| *** yolanda_ has joined #zuul | 08:02 | |
| *** yolanda_ is now known as yolanda | 08:02 | |
| *** hashar has joined #zuul | 08:20 | |
| *** ssbarnea_ has joined #zuul | 08:21 | |
| sshnaidm | tobiash, and maybe you have link to source? | 08:33 |
| tobiash | sshnaidm: http://git.openstack.org/cgit/openstack-infra/zuul/tree/zuul/driver/sql/sqlconnection.py#n174 | 08:41 |
| *** yolanda has quit IRC | 08:48 | |
| *** ianw is now known as ianw_pto | 08:54 | |
| sshnaidm | tobiash, thanks! | 08:59 |
| *** yolanda has joined #zuul | 09:01 | |
| openstackgerrit | Merged openstack-infra/zuul-jobs master: Deploy ssh key as root for non-root users https://review.openstack.org/563584 | 09:15 |
| *** ssbarnea_ has quit IRC | 10:50 | |
| openstackgerrit | Felix Schmidt proposed openstack-infra/zuul master: Add start and end timestamp to task result in zuul_json callback https://review.openstack.org/563888 | 10:56 |
| openstackgerrit | Andrea Frittoli proposed openstack-infra/zuul-jobs master: Run authorized_keys as root https://review.openstack.org/563889 | 10:59 |
| *** ssbarnea_ has joined #zuul | 11:19 | |
| *** andrea06590 has joined #zuul | 11:45 | |
| *** jpena is now known as jpena|lunch | 11:50 | |
| *** LinuxJedi has quit IRC | 12:26 | |
| *** LinuxJedi has joined #zuul | 12:26 | |
| *** mwhahaha has quit IRC | 12:26 | |
| *** mwhahaha has joined #zuul | 12:27 | |
| gundalow | Hi, what's the correct way to disable Zuul from merging PRs? I don't see it documented on https://docs.openstack.org/infra/zuul/user/gating.html or https://docs.openstack.org/infra/zuul/user/config.html though I might be looking for the wrong thing | 12:29 |
| *** dkranz has joined #zuul | 12:31 | |
| *** Guest46098 has quit IRC | 12:32 | |
| *** Guest46098 has joined #zuul | 12:33 | |
| *** jtanner has quit IRC | 12:34 | |
| *** jtanner has joined #zuul | 12:34 | |
| *** rlandy has joined #zuul | 12:35 | |
| Shrews | gundalow: that's sort of contradictory to the purpose of zuul. Are you looking to temporarily disable that for all PRs? Or just one PR? | 12:38 |
| Shrews | the github driver config is discussed here: https://zuul-ci.org/docs/zuul/admin/drivers/github.html | 12:41 |
| Shrews | All: Just FYI, I spent a day last week without power. Looks like I'm spending today without running water. Expecting a plumber soon so availability may be spotty. | 12:42 |
| gundalow | Shrews: all just till we are sure we have the right level of testing in place. We want Zuul to do the merging. Though I want the decision to merge to be made by a human, rather than if Zuul sees green & a shipit | 12:50 |
| gundalow | Though I don't current want to change GitHub repo permissions to require n+ GH approvals before a human can merge | 12:53 |
| tristanC | gundalow: perhaps setting "merge: False" would prevent zuul from actually merging when gate succeed, e.g. here: https://github.com/ansible-network/zuul-config/blob/master/zuul.d/pipelines.yaml#L70 | 12:53 |
| gundalow | wondering if I need gate: something-that-will-fail | 12:53 |
| *** jpena|lunch is now known as jpena | 12:54 | |
| gundalow | tristanC: ah, yes, that looks like what I'm after. Thank you ! | 12:54 |
| *** dkranz has quit IRC | 12:57 | |
| tristanC | (if it works) this should only be used as a temporary measure since zuul is supposed to merge change after a gate success | 12:58 |
| mhu | Hello, does the zuul executor use the host's /etc/ansible.cfg when running playbooks, or does it have its own configuration somewhere? | 12:59 |
| tristanC | mhu: the executor server is generating an ansible.cfg per playbook run, see http://git.openstack.org/cgit/openstack-infra/zuul/tree/zuul/executor/server.py#n1380 | 13:00 |
| mhu | thanks tristanC, looking now | 13:00 |
| *** swest has quit IRC | 13:06 | |
| tobiash | tristanC, gundalow: "merge: False" should be the default | 13:18 |
| tobiash | if you want zuul to merge PRs you explicitly need to set "merge: True" in the pipeline | 13:19 |
| *** swest has joined #zuul | 13:21 | |
| gundalow | ah, OK. I've set "merge: false", so I know where to change it back, and so it's a bit clearer | 13:26 |
| *** swest has quit IRC | 13:29 | |
| *** jbryce has quit IRC | 13:37 | |
| *** jbryce has joined #zuul | 13:37 | |
| tobiash | gundalow: you also can add this if you want zuul to merge but humans to trigger the gate: http://paste.openstack.org/show/719823/ | 13:38 |
| tobiash | we use that as a replacement of the workflow flag in openstack | 13:38 |
| gundalow | tobiash: Oh, I like that. Will swap to use that | 13:42 |
| tobiash | gundalow: for reference, that is the complete gate as we use it: http://paste.openstack.org/show/719827/ | 13:46 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: DNM: test tox-cover https://review.openstack.org/563199 | 13:50 |
| *** sdoran has quit IRC | 13:58 | |
| *** sdoran has joined #zuul | 13:58 | |
| *** andrea06590 has quit IRC | 14:05 | |
| openstackgerrit | Merged openstack-infra/zuul-website-media master: Add simulation video https://review.openstack.org/562001 | 14:26 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Don't try to delete non-existing local refs https://review.openstack.org/563982 | 14:26 |
| *** dkranz has joined #zuul | 14:48 | |
| gundalow | tobiash: Could I please use your expert eye on why https://github.com/ansible-network/network-engine-zuul/pull/14 didn't get merged, related configuration: https://github.com/ansible-network/zuul-config/pull/16/files | 14:53 |
| gundalow | most likely pebkac | 14:54 |
| *** yolanda_ has joined #zuul | 14:55 | |
| *** yolanda has quit IRC | 14:58 | |
| clarkb | tobiash: I left a comment on the project template regex change not sure if you saw it | 14:58 |
| clarkb | gundalow: I'm not the bset person to debug github behavior but it looks like the PR was opened, then mergeit was applied, check testing came back successfully, and the PR was approved. Those are the requirements to enter the gate. I would check if any gate jobs are running and if you have any gate jobs configured | 15:02 |
| corvus | gundalow, clarkb, tobiash: i don't see any gate jobs defined here: https://github.com/ansible-network/network-engine-zuul/blob/devel/.zuul.yaml | 15:14 |
| gundalow | corvus: ah. I'll add | 15:15 |
| corvus | i'm not positive that's the only place i should be looking, but if so, that would explain it. there has to be at least one job defined in order for it to merge. the best practice would be to duplicate the check jobs in gate (though you don't have to have all of them) | 15:16 |
| corvus | (duplicating the jobs helps avoid the situation where a potentially conflicting change merges and invalidates the tests) | 15:16 |
| gundalow | corvus: ah, that answers what I was about to ask (should check == gate) | 15:17 |
| gundalow | :) | 15:17 |
| clarkb | oh good I was on the right track | 15:17 |
| *** spsurya has quit IRC | 15:31 | |
| *** spsurya has joined #zuul | 15:32 | |
| *** sdake has joined #zuul | 15:40 | |
| sshnaidm | does zuul api have paging? for example in http://zuul.openstack.org/api/builds?job_name=nova-next - how can I get next 50? | 15:42 |
| clarkb | sshnaidm: it has rudimentary paging via the skip parameter. So you can do ?skip=$num_requests*number_results_per_request | 15:45 |
| clarkb | sshnaidm: you might still get duplicates if new jobs report | 15:46 |
| gundalow | tristanC: pabelanger Trying to get Zuul gating working. Hoped that https://github.com/ansible-network/network-engine-zuul/pull/14 would be merged according to https://github.com/ansible-network/zuul-config/pull/16/files any ideas what I may be missing? | 15:46 |
| clarkb | (not proper paging) | 15:46 |
| gundalow | I see gate jobs on https://ansible.softwarefactory-project.io/zuul/builds.html | 15:46 |
| gundalow | ah, ignore me it's merged | 15:47 |
| gundalow | clarkb: corvus thanks :) | 15:47 |
| gundalow | woot | 15:47 |
| sshnaidm | clarkb, thanks, works for me | 15:47 |
| tobiash | clarkb: saw it but didn't have time to look at it yet | 15:52 |
| corvus | gundalow: yay! | 15:54 |
| *** hashar is now known as hasharAway | 15:55 | |
| tobiash | This week is my 'deploy new openshift with lessons learned of my past three in-use deployments' week | 15:55 |
| gundalow | Shrews: Merging enabled when people add mergeit GH label, so I think that's a good manual step before automerge from Zuul, so all happy :) | 15:56 |
| Shrews | gundalow: w00t! | 15:57 |
| gundalow | So we have two new jobs ansible-test sanity`, and basic integration tests running now | 15:58 |
| Shrews | gundalow: on which parts of ansible? | 15:58 |
| Shrews | networking only? | 15:59 |
| gundalow | https://github.com/ansible-network/network-engine-zuul | 15:59 |
| gundalow | ^ First Ansible Role for networking | 15:59 |
| gundalow | Next bits are | 16:00 |
| gundalow | * Spinning up Network VMs | 16:00 |
| gundalow | * Building of documentation (hoping to steal most of build-releasenotes from you) | 16:00 |
| kklimonda | I have two zuul schedulers that I have to somehow integrate so that finishing pipeline in zuul #1 triggers a new pipeline in zuul #2 - has anyone been toying with ideas on how to implement that? I feel like what I really want it an external brain that connects to both zuul instances via custom drivers and orchestrate builds using some "manual" pipeline.. | 16:08 |
| clarkb | kklimonda: if we assume gerrit and say a post merge action you could trigger the second zuul off the gerrit event. Another option is to run two tenants in one zuul then they can trigger off the internal zuul events iirc | 16:09 |
| clarkb | but I don't think there is a direct mechanism for that setup yet today | 16:09 |
| kklimonda | clarkb: they are connected to different gerrit instances | 16:09 |
| tobiash | kklimonda: at least the final gating can only be done by one instance | 16:10 |
| clarkb | kklimonda: that is an implementation detail right? they could be connected to the same gerrits? | 16:10 |
| kklimonda | yes, but those are completely separate projects | 16:10 |
| kklimonda | it's just our release takes artifacts created by two zuul pipelines - one public, another one private | 16:10 |
| tobiash | But you can require checks from different instances | 16:10 |
| kklimonda | but public artifacts (container images) are dependencies for private artifacts | 16:11 |
| tobiash | kklimonda: so it's not about gating but buildibg releases? | 16:11 |
| kklimonda | yeah | 16:12 |
| kklimonda | basically it's about the part of zuul that seems to be lacking a bit in tooling :/ | 16:12 |
| tobiash | Tag triggered? | 16:12 |
| kklimonda | ("hey, we need the build aborted and retriggered") | 16:12 |
| kklimonda | no | 16:12 |
| kklimonda | zuul just takes tip of the branch for all the projects and run with it | 16:13 |
| gundalow | Shrews: Once "Spinning up Network VMs" is done for github.com/ansible-network I'll have a think about if we can use the same work for testing of network code in ansible/ansible. Should just work, case of jugling prioritie | 16:13 |
| gundalow | s | 16:13 |
| clarkb | kklimonda: in that case I'd have your private zuul connect to public zuul too | 16:14 |
| clarkb | er public gerrit/github | 16:14 |
| clarkb | then it will get the events from the public side and can trigger the appropriate jobs on the private side | 16:14 |
| kklimonda | clarkb: I don't think zuul reports anything back to gerrit for its "trigger" pipelines? | 16:15 |
| kklimonda | "timer trigger" pipelines | 16:15 |
| clarkb | kklimonda: ya it won't in all cases hrm | 16:16 |
| tobiash | kklimonda: does it have to report back? | 16:16 |
| clarkb | tobiash: it does if we use the public gerrit as the event "proxy" | 16:16 |
| kklimonda | tobiash: I need it to somehow report that the public build has finished, so that the private can start | 16:16 |
| SpamapS | gundalow: FYI, regarding your gating/label thing.. just to add to that.. here at GoDaddy, we have a pipeline that labels things with our version of the 'merge' label whenever approved reviews come in (and remove it when new patches are pushed). Let me know if you're interested in our template for that. | 16:17 |
| clarkb | kklimonda: tobiash the mqtt reporter may actually be a good solution for this thinking about it more | 16:17 |
| tobiash | Maybe | 16:17 |
| SpamapS | Reminds me I need to do the inverse and remove the approved label if a writer requests changes (or dismisses their review) | 16:17 |
| clarkb | I don't think that change comes with a trigger driver but would be possible to add one easily I expect | 16:17 |
| SpamapS | Kind of get tired of making Github work like Gerrit tho. :-P | 16:18 |
| tobiash | kklimonda: what about rerunning the public jobs in the private zuul? | 16:18 |
| kklimonda | @tobiash we could do that but that complicates the setup | 16:18 |
| kklimonda | tobiash: I need to have project in both zuuls, developers must be aware of that, there are two log destinations | 16:19 |
| tobiash | kklimonda: you also could just poll the future artifact location until it's there | 16:19 |
| kklimonda | yes, but again - this is a hack | 16:19 |
| kklimonda | I can poll status.json | 16:19 |
| kklimonda | (although that won't really give me a way to tell if the build succeded) | 16:20 |
| kklimonda | and no easy way to tell the public image tag to use for the private build.. | 16:20 |
| tobiash | kklimonda: the mqtt driver would tell you | 16:21 |
| kklimonda | yeah, that sounds like a nice approach | 16:21 |
| kklimonda | pretty much what I was thinking of using | 16:21 |
| kklimonda | (well, the custom driver, not mqtt specifically) | 16:21 |
| tobiash | For triggering a job you could either use the zuul cli or maybe enhance the mqtt driver with a trigger | 16:23 |
| tobiash | For zuul cli you'd need ssh access to the public scheduler | 16:24 |
| kklimonda | I'd prefer to add this to the driver - can a trigger abort the buildset in progress, or is it done internally by zuul when it sees an event that made the running buildset obsolete? | 16:24 |
| tobiash | kklimonda: the second | 16:25 |
| *** bhavik1 has joined #zuul | 16:25 | |
| kklimonda | does the mqtt driver sends back the content of results.json (what's returned with `zuul_return`)? | 16:26 |
| gundalow | SpamapS: Oh, that's cool. Fine for the moment, though I'll make a note. Thanks for the offer | 16:28 |
| kklimonda | I'll have to read about mqtt, how it works in kind-of untrusted context - our public CI is probably being handed over to the third-party in some capacity, so I wonder what the risks are. | 16:28 |
| corvus | kklimonda: i don't believe it sends zuul_return now, but i suspect it wouldn't be too hard for it to do so. | 16:29 |
| kklimonda | mhm, sending variables the other way would also be nice | 16:30 |
| corvus | also, it's only a reporter at the moment; someone still needs to write a trigger for it. but i think it's a good way to connect up multiple systems like this. | 16:30 |
| kklimonda | yes, it definitely sounds like what I've been looking for | 16:30 |
| corvus | (the trigger shouldn't be too hard either, now that most of the connection infrastructure is there) | 16:30 |
| kklimonda | at least a base to expand | 16:30 |
| corvus | in openstack-infra, we plan on recommending third-party ci systems use mqtt (receiving gerrit events) once it exists, so they don't have to rely on gerrit's ssh connection. | 16:31 |
| kklimonda | I'd probably need to extend TriggerEvent, to somehow push build number from public CI to the private CI, so it can be used in the job. | 16:40 |
| tobiash | corvus: is something blocking +a on the mqtt driver? | 16:40 |
| tobiash | It has 5x +2 | 16:40 |
| kklimonda | and then feed it somehow from the driver | 16:40 |
| corvus | tobiash: check its child change | 16:40 |
| corvus | tobiash: i think folks wanted to see how https://review.openstack.org/563360 fared and maybe merge them together | 16:41 |
| corvus | i guess i should review it and perhaps +3 both :) | 16:41 |
| tobiash | corvus: ah ok | 16:41 |
| clarkb | fwiw I still think we shouldn't have an option there | 16:42 |
| clarkb | just always use the highest available version and call it a day | 16:42 |
| corvus | clarkb: i'll wait for your -1 :) | 16:42 |
| corvus | kklimonda: build number? what's that and what for? | 16:43 |
| clarkb | corvus: done | 16:44 |
| kklimonda | corvus: we tag our builds with an incremental build number - there is a longer story here, but I want this build number made available to the job running in private CI (along with layer sha) so that it knows what to base of. | 16:45 |
| kklimonda | (also, the way we increment the build number is pretty hacky - if I could trigger zuul from outside and pass it this way, that would probably make my life simpler, even if only by a bit) | 16:46 |
| corvus | kklimonda: hrm, that's tricky. there's an intentional disconnect between triggers and what gets enqueued. by the time something ends up in a pipeline, it's just a git ref -- there's no other information about the triggering event. that lets us mix-and-match triggers, sources, and reporters. | 16:47 |
| corvus | kklimonda: so you can say "enqueue this git ref (ie, change, pull request, branch, etc)" and if you have artifacts externally hosted and indexed by that git ref, your jobs can use them. | 16:48 |
| corvus | kklimonda: but there isn't a general-purpose "run this job with a variable parameter" facility | 16:49 |
| kklimonda | right, but that requires me to implement querying some external DB in my jobs to get some shared state (and yes, zuul doesn't seem to like shared state in general ;)) | 16:51 |
| kklimonda | artifacts are externally hosted, but I don't see a nice way of knowing what they are - for time triggered pipelines, I don't seem get much in terms of unique identifier that can be used to distinguish the build, not to mention that I would like to move to running jobs on their own projects, not attached to some fake project to get them all in sync. | 16:53 |
| kklimonda | That's why I started toying with an external brain that orchestrates zuul (meta zuul? :/) and keeps everything in sync (also provides a way for non-admin users to trigger/abort builds and see their progress in one place). But If I can' pass anything to the jobs from outside, that makes it tricky. | 16:58 |
| kklimonda | Hmm, I could implement that all by having some external service that can be queried from inside of the zuul job to retrieve state - it could be that the tuple (zuul, tenant, project, [change, patchset], buildset) and then save the state back. | 17:05 |
| kklimonda | It could be that the tuple [...] is enough to uniquely identify the build* | 17:06 |
| *** jpena is now known as jpena|off | 17:12 | |
| corvus | kklimonda: if you're triggering from the reported version of a build (ie, not intermediate builds that might later be canceled), then project,change,patchset should be enough. i'll note none of those are zuul-generated. | 17:15 |
| kklimonda | corvus: there will be cancelled builds for sure based on the history I know | 17:17 |
| kklimonda | I'll have to take a look at what variables does zuul expose to jobs, and what could I use to match the build in some external state server - that seems doable | 17:18 |
| kklimonda | the builds are cancelled, but the number is then incremented | 17:19 |
| corvus | kklimonda: do you want your second system to trigger on in-progress builds of the first, or wait until the first reports? | 17:19 |
| corvus | (it seems like waiting for the first to report would be ideal) | 17:19 |
| kklimonda | corvus: I'd prefer to wait only for one job from the buildset - it takes ~30 minutes to finish, while the entire build is over 3 hours | 17:20 |
| kklimonda | wow, sorry - let me rephrase that | 17:20 |
| kklimonda | currently, we are running periodic builds for different projects as part of a single buildset - we just attached the jobs to one fake project and that worked in a short term | 17:21 |
| kklimonda | I want to do that properly, by attaching each job to its own project, and then I'll be able to wait for the entire buildset of that project to finish before triggering job on the second zuul. | 17:22 |
| corvus | kklimonda: that second design sounds much cleaner and easier to implement | 17:23 |
| kklimonda | yeah, I completely agree - this is my plan, I'm just looking for a way to synchronize state - I think I can probably do it all from inside of the zuul job by querying some external state server. | 17:24 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Don't try to delete non-existing local refs https://review.openstack.org/563982 | 17:26 |
| tobiash | corvus: that fixes a bug that broke at least two repos on our mergers | 17:26 |
| corvus | kklimonda: got it. if i were to offer any general advice, it would be that zuul never expects to have its intermediate state used outside of itself. it's sort of an 'implementation detail'. so handoffs between systems based on completed/reported entries in a pipeline will be much easier to deal with as that's what it was designed for. ideally the only state you need at that point is fully external to | 17:27 |
| corvus | zuul. | 17:27 |
| kklimonda | mhm, thanks - that helped me clarify the design. | 17:29 |
| kklimonda | and I learnt some new tidbits about zuul internals - that's always useful | 17:29 |
| corvus | tobiash: i feel like i'm missing something. i don't understand why the code there fixes the bug as described. why does "head.name == ref.remote_head" mean it's the case you describe? | 17:31 |
| corvus | (i feel certain this is obvious and i'm just too obtuse to see it today) | 17:32 |
| tobiash | corvus: the merger deletes the local ref, then the remote, in our case the merger was killed in between leaving the remote ref existing and the local ref already deleted | 17:33 |
| tobiash | so the change looks for the matching local ref and deletes it only if it finds it (otherwise it's already gone) | 17:33 |
| corvus | tobiash: and the ref in the case of the test is 'foobar' -- so: ref.remote_head == 'foobar' ? | 17:34 |
| tobiash | yes | 17:35 |
| corvus | tobiash: okay, i think i understand. i think the 'remote_head' attribute was throwing me off :) | 17:36 |
| tobiash | corvus: I'll add a comment | 17:36 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Don't try to delete non-existing local refs https://review.openstack.org/563982 | 17:39 |
| tobiash | corvus: with comment ^ | 17:39 |
| corvus | kklimonda: this reminds me a little bit of what we do for branch-tip tarballs in openstack. we have periodic jobs as well as post-merge jobs which build the branch tip of every project and publish them to, eg, http://tarballs.openstack.org/zuul/ (you can see 'zuul-master.tar.gz' there). that's a simple method where we index the artifacts merely by project-branch. the log server keeps intermediate | 17:40 |
| corvus | builds, so they are indexed by change/patchset/pipeline/job/build. but if we dropped build from that, we'd have an index of "the latest build of this job for this change in check", without an external lookup. maybe that's helpful for your situation. | 17:40 |
| *** bhavik1 has quit IRC | 17:55 | |
| *** electrofelix has quit IRC | 18:07 | |
| *** sshnaidm has quit IRC | 18:32 | |
| Shrews | hrm, i just found an odd merging of code in nodepool that i did not expect | 18:34 |
| openstackgerrit | David Shrewsbury proposed openstack-infra/nodepool master: Fix awkward merging of code https://review.openstack.org/564045 | 18:44 |
| *** xinliang has quit IRC | 18:56 | |
| *** dims has quit IRC | 19:02 | |
| *** dims has joined #zuul | 19:09 | |
| *** xinliang has joined #zuul | 19:11 | |
| *** xinliang has quit IRC | 19:11 | |
| *** xinliang has joined #zuul | 19:11 | |
| *** yolanda__ has joined #zuul | 19:15 | |
| *** sshnaidm has joined #zuul | 19:16 | |
| *** yolanda_ has quit IRC | 19:18 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul-website master: Create a zuul-website gate queue https://review.openstack.org/564053 | 19:31 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul-website-media master: Join the zuul-website queue https://review.openstack.org/564054 | 19:32 |
| openstackgerrit | Merged openstack-infra/zuul-website master: Add simulation video https://review.openstack.org/562005 | 19:33 |
| openstackgerrit | Merged openstack-infra/zuul-website master: Create a zuul-website gate queue https://review.openstack.org/564053 | 19:38 |
| openstackgerrit | Merged openstack-infra/zuul-website-media master: Join the zuul-website queue https://review.openstack.org/564054 | 19:41 |
| fungi | Shrews: like a git merge which picked the wrong conflict resolution? | 19:45 |
| Shrews | fungi: not sure what happened. 564045 shows it | 19:46 |
| Shrews | i guess merge order mattered there. no biggie to fix | 19:46 |
| clarkb | Shrews: fungi this is actually one of the original "why you should use bzr instead of git" arguments iirc | 19:46 |
| *** weshay has quit IRC | 20:05 | |
| *** weshay has joined #zuul | 20:07 | |
| kklimonda | corvus: btw, if I implement triggers over mqtt then everyone will be able to trigger anything, right? I remember discussion on the web admin endpoint where you said you'd rather not add that into zuul. | 20:14 |
| kklimonda | (not add the authorization handling to zuul, and let it be done by some reverse proxy running in front of it) | 20:15 |
| corvus | kklimonda: the zuul admin is still responsible for connecting zuul to the mqtt server, and that server may have access restrictions so that only certain things can send events to it. then beyond that, the pipeline config for the mqtt trigger will let you select which events to listen for. | 20:26 |
| corvus | kklimonda: so if you trust the mqtt server (well, 'broker' is the right word) and the other clients connected to it, then you should be able to trust the events coming from it | 20:27 |
| corvus | kklimonda: of course it's possible to set up an open mqtt broker, and then all bets are off | 20:27 |
| kklimonda | mhm | 20:27 |
| corvus | kklimonda: but as an example, in openstack-infra, anyone is permitted to read from firehose.openstack.org, but only services run by the project infrastructure team can publish events to it. | 20:28 |
| *** gouthamr has quit IRC | 20:38 | |
| *** dmellado has quit IRC | 20:38 | |
| openstackgerrit | Clark Boylan proposed openstack-infra/nodepool master: Fix awkward merging of code https://review.openstack.org/564045 | 20:40 |
| clarkb | Shrews: tobiash ^ there was a minor error in that change so I just fixed it | 20:40 |
| *** gouthamr has joined #zuul | 20:43 | |
| Shrews | clarkb: doh. thx | 20:43 |
| *** dmellado has joined #zuul | 20:43 | |
| clarkb | Shrews: the good news is testing caught it :) | 20:44 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Cache configuration objects in addition to YAML dicts https://review.openstack.org/564061 | 20:48 |
| corvus | okay, that's still stacked on top of some failing changes, and i'm sure it's failing some tests on its own. but -- it works with at least one test, so i figured it's a good checkpoint. | 20:49 |
| corvus | it's actually not that big of a change, i don't think | 20:49 |
| *** sshnaidm is now known as sshnaidm|off | 20:52 | |
| *** dkranz has quit IRC | 20:54 | |
| openstackgerrit | Matthieu Huin proposed openstack-infra/zuul master: [WIP] Toggable colors in job-output.txt https://review.openstack.org/564066 | 21:15 |
| clarkb | corvus: do we want to get tobiash's git merger fix in before restarting everything and beta testing? | 22:06 |
| corvus | clarkb: sounds good | 22:08 |
| *** hasharAway has quit IRC | 22:13 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Remove layout from ParseContext https://review.openstack.org/563695 | 22:17 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Remove 'base' from UnparsedAbideConfig https://review.openstack.org/563757 | 22:18 |
| corvus | wow, in the re-use objects patch, i've managed to make all the jobs fail. | 22:19 |
| corvus | even the doc build | 22:19 |
| corvus | hrm. the py35 failure looks like maybe something related to nodeenv? | 22:24 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Cache configuration objects in addition to YAML dicts https://review.openstack.org/564061 | 22:26 |
| corvus | it's looking like something related to yarn or nodeenv has broken our gate | 22:31 |
| corvus | node 10.0.0 was released today | 22:40 |
| corvus | the error is: error upath@1.0.4: The engine "node" is incompatible with this module. Expected version ">=4 <=9". | 22:40 |
| corvus | there is no later version of upath than 1.0.4, so i don't think we can resolve this by upgrading upath | 22:40 |
| corvus | i think we need to tell nodeenv to install 9.11.1 | 22:42 |
| clarkb | ah | 22:43 |
| *** ssbarnea_ has quit IRC | 22:43 | |
| clarkb | corvus: I think we want 8.x odds are unstable and evens are stable iirc | 22:43 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Pin node to version 9 https://review.openstack.org/564073 | 22:44 |
| corvus | clarkb: oh | 22:44 |
| corvus | i can't tell what the jobs were running before, it doesn't output the version :/ | 22:46 |
| corvus | 8.11.1 looks like the one to use | 22:46 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Pin node to version 8: LTS stable https://review.openstack.org/564073 | 22:47 |
| clarkb | corvus: ^ zuul reports that fixed it | 23:06 |
| corvus | cool -- anyone else around, or should i just +3 it in? | 23:07 |
| clarkb | considering its mechanical and fixes issues I'd just +3 it in | 23:07 |
| clarkb | I already +2'd it | 23:07 |
| corvus | okay, in it goes | 23:08 |
| corvus | but i don't want this to slip by unnoticed... | 23:08 |
| corvus | tristanC, tobiash, SpamapS, mordred: node 10 released and caused issues; see https://review.openstack.org/564073 | 23:09 |
| SpamapS | fun | 23:09 |
| SpamapS | tristanC: were you, btw, the one who made an AWS/EC2 based nodepool driver? Before I go digging in the code/docs, what's the state of that? | 23:19 |
| *** rlandy has quit IRC | 23:25 | |
| fungi | so in the wake of pip 10 breaking things, nodejs devs felt they didn't want to be one-upped? | 23:26 |
| corvus | SpamapS: https://review.openstack.org/535558 | 23:26 |
| corvus | fungi: it's time to work on zuul v10 | 23:26 |
| fungi | first we have to figure out what we want to break! | 23:26 |
| corvus | everything! again! :) | 23:26 |
| fungi | toml here we come | 23:27 |
| corvus | /kick fungi | 23:27 |
| * fungi ducks | 23:27 | |
| openstackgerrit | Merged openstack-infra/zuul master: Pin node to version 8: LTS stable https://review.openstack.org/564073 | 23:27 |
| SpamapS | corvus: oh thanks.. for some reason I thought it had merged. | 23:29 |
| SpamapS | Been thinking a lot about the idea pabelanger first mentioned to me.. making a nodepool 'ansible' driver that just runs configured playbooks. | 23:29 |
| SpamapS | Which would make it a lot easier to write new drivers. | 23:29 |
| SpamapS | though looks like this one did some refactoring that would make them easier to write in python anyway | 23:30 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!