| *** jamesmcarthur has joined #zuul | 01:18 | |
| *** jamesmcarthur has quit IRC | 01:30 | |
| *** jamesmcarthur has joined #zuul | 01:36 | |
| *** jamesmcarthur has quit IRC | 01:51 | |
| *** jamesmcarthur has joined #zuul | 01:57 | |
| *** spsurya has joined #zuul | 02:32 | |
| *** bhavikdbavishi has joined #zuul | 02:49 | |
| *** bhavikdbavishi1 has joined #zuul | 02:52 | |
| *** bhavikdbavishi has quit IRC | 02:53 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 02:53 | |
| *** sgw has quit IRC | 03:06 | |
| *** jamesmcarthur has quit IRC | 03:49 | |
| *** jhesketh has quit IRC | 05:11 | |
| *** AJaeger has quit IRC | 05:54 | |
| *** AJaeger has joined #zuul | 06:04 | |
| *** SpamapS has quit IRC | 06:44 | |
| *** ianychoi has quit IRC | 06:51 | |
| *** ianychoi has joined #zuul | 06:54 | |
| *** SpamapS has joined #zuul | 06:57 | |
| *** saneax has joined #zuul | 07:00 | |
| *** tosky has joined #zuul | 07:14 | |
| *** pcaruana has joined #zuul | 07:16 | |
| *** tosky_ has joined #zuul | 08:15 | |
| *** tosky_ has quit IRC | 08:15 | |
| *** tosky_ has joined #zuul | 08:15 | |
| *** tosky is now known as Guest39640 | 08:16 | |
| *** tosky_ is now known as tosky | 08:16 | |
| *** electrofelix has joined #zuul | 08:35 | |
| *** hashar has joined #zuul | 08:41 | |
| *** jangutter has joined #zuul | 08:42 | |
| *** sgw has joined #zuul | 08:58 | |
| *** openstackgerrit has quit IRC | 09:37 | |
| *** bhavikdbavishi has quit IRC | 09:42 | |
| *** mhu has joined #zuul | 10:11 | |
| *** sgw has quit IRC | 10:30 | |
| *** hashar has quit IRC | 10:37 | |
| *** tflink has quit IRC | 10:49 | |
| *** tflink has joined #zuul | 10:49 | |
| *** saneax has quit IRC | 10:58 | |
| *** saneax has joined #zuul | 10:59 | |
| *** mattymo has quit IRC | 11:02 | |
| *** hashar has joined #zuul | 11:02 | |
| *** bhavikdbavishi has joined #zuul | 11:06 | |
| arxcruz | hey guys, how can I get the results of a zuul job A, and trigger a second job B, and use the artifacts from job A ? | 11:06 |
|---|---|---|
| arxcruz | is that possible? | 11:06 |
| *** bhavikdbavishi1 has joined #zuul | 11:09 | |
| *** bhavikdbavishi has quit IRC | 11:10 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 11:10 | |
| jangutter | arxcruz: Have you seen zuul_return as described here? https://zuul-ci.org/docs/zuul/user/jobs.html#returning-artifact-urls | 11:13 |
| jangutter | arxcruz: I'm not sure how current this post is, but it describes sharing artifacts between jobs: https://blogs.rdoproject.org/2018/01/overview-of-a-ci-cd-workflow-with-zuul/ | 11:14 |
| arxcruz | jangutter: yes, i saw the return artifact, but this is to be used in the same job right ? | 11:14 |
| arxcruz | i want to run a job that will build a rpm, and then be able to trigger a second job that will consume that rpm on a tripleo job | 11:15 |
| jangutter | arxcruz: I've used zuul_return to pass the buildset from one job as the input to another job. Both jobs had the same trigger, but the second one waited for the first one to complete. | 11:17 |
| *** mhu has quit IRC | 11:18 | |
| arxcruz | jangutter: thanks, i'll take a look | 11:20 |
| arxcruz | jangutter: may i bother you later on that? :D | 11:20 |
| arxcruz | i pay a beer :P | 11:20 |
| jangutter | arxcruz: if two jobs are triggered in the same event (say submit-review triggers rpm-build then rpm-test), zuul_return can help you. But if you need to generate a new trigger event, I think you're looking into something more complex. | 11:21 |
| jangutter | arxcruz: I'm very much a noob here, most of my tech-support is based on convincingly lying :-p | 11:21 |
| arxcruz | jangutter: that's a good skill :P | 11:34 |
| *** jangutter has quit IRC | 11:49 | |
| *** jangutter has joined #zuul | 12:02 | |
| *** rfolco|ruck has joined #zuul | 12:04 | |
| *** rfolco|ruck is now known as rfolco|rover | 12:04 | |
| *** themroc has joined #zuul | 12:06 | |
| *** themroc has quit IRC | 12:10 | |
| *** themroc has joined #zuul | 12:11 | |
| *** themr0c has joined #zuul | 12:25 | |
| *** themroc has quit IRC | 12:26 | |
| *** mhu has joined #zuul | 12:50 | |
| *** jamesmcarthur has joined #zuul | 12:54 | |
| *** at_work has joined #zuul | 13:27 | |
| *** jamesmcarthur has quit IRC | 13:30 | |
| *** jamesmcarthur has joined #zuul | 13:31 | |
| *** jamesmcarthur has quit IRC | 13:32 | |
| *** jamesmcarthur_ has joined #zuul | 13:32 | |
| *** jamesmcarthur_ has quit IRC | 13:36 | |
| *** mhu has quit IRC | 13:48 | |
| *** jamesmcarthur has joined #zuul | 13:48 | |
| *** jamesmcarthur has quit IRC | 13:53 | |
| fungi | if anyone has anything they'd like to mention to the osf board of directors about the airship project prior to tomorrow's board meeting to review their request to be confirmed as an open infrastructure project, please add it to https://etherpad.openstack.org/p/zuul-community-airship-confirmation-feedback | 13:58 |
| fungi | see my post to zuul-discuss last week if you need more information: http://lists.zuul-ci.org/pipermail/zuul-discuss/2019-October/001048.html | 13:58 |
| fungi | (or ask me and i'm happy to get answers) | 13:59 |
| Shrews | neat. nodepool-upload-image is failing with "ERROR: Failed building wheel for netifaces" | 14:04 |
| Shrews | yay monday | 14:05 |
| Shrews | missing gcc might be the real error | 14:07 |
| fungi | though odds are netifaces just pushed up a new sdist to pypi | 14:08 |
| fungi | nope, nothing since january | 14:08 |
| fungi | i wonder why we're just now hitting it | 14:08 |
| Shrews | fungi: excellent question | 14:09 |
| fungi | also why would nodepool-upload-image be trying to install anything? | 14:09 |
| Shrews | fungi: it's during the build of the docker images | 14:09 |
| Shrews | so maybe a base image changed | 14:09 |
| Shrews | ? | 14:09 |
| fungi | ahh | 14:10 |
| fungi | nevermind, i was thinking you meant a failure on opendev's nodepool builders when uploading built node images | 14:10 |
| fungi | but yeah, maybe something we're installing added a new dependency (or the c built tools were removed from a base image) | 14:12 |
| fungi | s/built/build/ | 14:12 |
| *** ianychoi has quit IRC | 14:21 | |
| Shrews | confirmed a local docker build fails with the same error :/ | 14:24 |
| *** michael-beaver has joined #zuul | 14:26 | |
| *** dmsimard1 is now known as dmsimard | 14:26 | |
| Shrews | mordred: i see gcc being installed early in the process. odd | 14:28 |
| Shrews | well, didn't mean to ping mordred there, but since i did, and if you're around... | 14:28 |
| *** ianychoi has joined #zuul | 14:29 | |
| *** jamesmcarthur has joined #zuul | 14:30 | |
| *** fdegir has quit IRC | 14:41 | |
| Shrews | ooh, opendevorg/python-base was updated 3 days ago. that seems promising | 14:42 |
| *** fdegir has joined #zuul | 14:42 | |
| Shrews | fungi: umm, stupid question... but which repo controls that image? | 14:44 |
| fungi | it might be a stupid question, but i don't know either ;) | 14:44 |
| fungi | looking it up now | 14:44 |
| Shrews | oh, sys config i think | 14:45 |
| fungi | yeah, there's a system-config-build-image-python-base job defined in it | 14:46 |
| Shrews | opendevorg/python-base does not have gcc installed. since there is no older version available on dockerhub, i cannot confirm if the previous version did | 14:49 |
| clarkb | I know mordred and corvus had recent conversation about that | 14:49 |
| clarkb | I think the idea was add it to our images but then if we switched python-base to some other parent it got it for free? | 14:50 |
| clarkb | if you look at the history of that dockerfile you may see those recent changes | 14:50 |
| Shrews | no gcc related changes that i can see | 14:52 |
| fungi | gcc might have been covered as a dependency, perhaps for a metapackage like build-essential | 14:53 |
| corvus | clarkb, Shrews yeah https://review.opendev.org/689578 is the recent change and should only affect jemalloc, but it means that we got a new debian base image as part of the rebuild, so much unrelated stuff could have changed | 14:54 |
| Shrews | i guess the question i have right now is... do we fix this by having gcc installed in the python-base image, or change nodepool's bindep to include it? | 14:56 |
| corvus | i think it should be installed in python-base -- i think we intended that to be able to install any python module, and some python modules need gcc | 14:56 |
| clarkb | I think the preference is to hvae python-base hold those build deps so that tehy don't end up in the final image | 14:56 |
| corvus | the weird thing is, i thought "python:slim" already had that goal too | 14:57 |
| *** fdegir has quit IRC | 14:57 | |
| *** fdegir has joined #zuul | 14:58 | |
| clarkb | I think it may be python without the :slim ? | 14:58 |
| Shrews | remote: https://review.opendev.org/689813 Make sure gcc is installed on python-base image | 15:00 |
| Shrews | erg... is gcc the right package name? | 15:01 |
| * fungi checks | 15:01 | |
| clarkb | on debuntu I would do build-essential | 15:01 |
| clarkb | (python:slim is a debian image iirc) | 15:01 |
| Shrews | ok | 15:02 |
| fungi | yeah, "gcc" will work, "build-essential" will also pull in gcc but will include stuff like autotools as well | 15:03 |
| fungi | depends on whether you're concerned about the extra deps | 15:03 |
| corvus | wait a sec... | 15:07 |
| corvus | python-builder is what we should be looking at | 15:07 |
| Shrews | corvus: i was wondering about that, but it looks like python-base only grabs content from the /output directory of python-builder | 15:09 |
| corvus | yeah, we should be using python-builder to build nodepool, then install the result in a python-base container | 15:09 |
| clarkb | oh the issue is installing nodepools deps I bet | 15:09 |
| clarkb | and if it doesn't have wheels too then we run into this | 15:09 |
| Shrews | FROM opendevorg/python-base as nodepool | 15:10 |
| Shrews | is that incorrect? | 15:10 |
| corvus | Shrews: there should be multiple from lines | 15:10 |
| corvus | yeah, above that we use the builder image | 15:11 |
| corvus | use the builder image, build nodepool, then use the base image and install nodepool | 15:11 |
| clarkb | fungi: is it possible netifaces deleted their wheel? | 15:12 |
| Shrews | corvus: the odd thing is, the python-builder installs gcc (according to the logs) | 15:12 |
| fungi | oh, i bet i know what happened | 15:13 |
| clarkb | Shrews: ya I think the problem is when we've switched over to the python-base context and are installing nodepool there. We are missing a netifaces wheel | 15:13 |
| fungi | debian buster switched to python3.7 | 15:13 |
| fungi | netifaces has manylinux1 wheels for python3.6 and before | 15:13 |
| clarkb | oh are -builder abd -base disjoint python versions? that could do it | 15:13 |
| clarkb | oh or that | 15:13 |
| fungi | so when it was debian stretch based, tehre was a manylinux1 wheel for the version of python which was installed | 15:14 |
| *** jamesmcarthur has quit IRC | 15:14 | |
| *** jamesmcarthur has joined #zuul | 15:15 | |
| corvus | i guess if we know we need to do it, we could build a netifaces wheel in the builder image and put it in the wheel cache that's added to the base image for installation...? | 15:18 |
| clarkb | corvus: perhaps copy over the entire wheel cache? | 15:19 |
| corvus | i think we do? | 15:19 |
| clarkb | oh if we do then the builder should have built a 3.7 wheel | 15:19 |
| clarkb | perhaps it is also the case the -builder is running 3.6? | 15:19 |
| *** fdegir has quit IRC | 15:19 | |
| corvus | yes that might be it -- because mordred didn't update the builder... | 15:20 |
| *** fdegir has joined #zuul | 15:20 | |
| corvus | so we may just need to rebuild python-builder | 15:20 |
| corvus | (and update the jobs so that both are built in tandem in the future) | 15:20 |
| clarkb | ++ | 15:20 |
| corvus | Shrews: want to push a no-op change to the python-builder dockerfile to get a new build and see if that fixes it? | 15:21 |
| Shrews | corvus: yup | 15:21 |
| *** jamesmcarthur has quit IRC | 15:21 | |
| fungi | that'll be conveniently simple if that's all we ended up needing | 15:21 |
| *** jamesmcarthur has joined #zuul | 15:22 | |
| Shrews | remote: https://review.opendev.org/689819 | 15:25 |
| *** jamesmcarthur has quit IRC | 15:26 | |
| *** mattw4 has joined #zuul | 15:27 | |
| *** igordc has joined #zuul | 15:27 | |
| *** igordc has quit IRC | 15:34 | |
| *** ianychoi has quit IRC | 15:43 | |
| *** ianychoi has joined #zuul | 15:44 | |
| *** openstackgerrit has joined #zuul | 15:45 | |
| openstackgerrit | James E. Blair proposed zuul/zuul-registry master: Handle ":" in passwords https://review.opendev.org/689829 | 15:45 |
| *** jamesmcarthur has joined #zuul | 15:45 | |
| *** hashar has quit IRC | 15:48 | |
| corvus | heh, that ^ is stuck on the netifaces wheel too | 15:56 |
| corvus | fungi, clarkb: want to +3 https://review.opendev.org/689819 ? | 15:57 |
| fungi | yup, sorry, missed it. was in meetings | 15:57 |
| *** themr0c has quit IRC | 16:04 | |
| *** saneax has quit IRC | 16:13 | |
| *** spsurya has quit IRC | 16:40 | |
| openstackgerrit | James E. Blair proposed zuul/zuul-registry master: Disable namespacing https://review.opendev.org/689219 | 16:47 |
| *** electrofelix has quit IRC | 16:56 | |
| *** jangutter has quit IRC | 17:26 | |
| openstackgerrit | Merged zuul/nodepool master: Remove unused functional testing playbooks https://review.opendev.org/689457 | 17:26 |
| openstackgerrit | Merged zuul/nodepool master: Cleanup openshift pre.yaml playbook https://review.opendev.org/689479 | 17:31 |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Test buildset registry with k8s and docker https://review.opendev.org/689280 | 17:31 |
| openstackgerrit | James E. Blair proposed zuul/zuul-registry master: Handle ":" in passwords https://review.opendev.org/689829 | 17:35 |
| openstackgerrit | James E. Blair proposed zuul/zuul-registry master: Collect docker logs in functional test https://review.opendev.org/689851 | 17:35 |
| *** themroc has joined #zuul | 17:37 | |
| *** themroc has quit IRC | 17:46 | |
| *** tosky has quit IRC | 17:50 | |
| mordred | corvus: wow, we didn't build a new builder image the other day? I thought that change triggered *all* of the images | 17:50 |
| clarkb | mordred: I think we need to update the jobs to do that | 17:51 |
| mordred | hrm. it built in check - just not in gate and promote | 17:52 |
| mordred | https://review.opendev.org/#/c/689578/ | 17:52 |
| mordred | oh - wow. I see what happened | 17:54 |
| *** jamesmcarthur has quit IRC | 17:54 | |
| mordred | it built in base because we added the docker mirror url to build-image base job, so the jobs all changed so zuul ran them | 17:55 |
| mordred | but we didn't add the mirror url to upload or promote - so they didn't get triggered - but we did upload python-base because we ALSO made a dockerfile change to it | 17:56 |
| *** bhavikdbavishi has quit IRC | 18:11 | |
| *** jamesmcarthur has joined #zuul | 18:14 | |
| *** jamesmcarthur has quit IRC | 18:17 | |
| *** hashar has joined #zuul | 18:22 | |
| *** saneax has joined #zuul | 18:22 | |
| corvus | mordred, fungi: i think i may be seeing more fallout from the py36->37 update in zuul-registry | 18:27 |
| corvus | i'll let you know what i find | 18:28 |
| mordred | corvus: "awesome" | 18:28 |
| corvus | oh er it's running 3.8 | 18:29 |
| *** jamesmcarthur has joined #zuul | 18:31 | |
| mordred | oh - so it is! | 18:32 |
| corvus | https://zuul.opendev.org/t/zuul/build/0d539a0faef24796a97c272dd0afd7ee/log/docker/functionaltest_registry_1.txt#30 | 18:32 |
| corvus | apparently the internals that rehash uses have changed | 18:32 |
| mordred | corvus: null pointer access, fun | 18:33 |
| mordred | corvus: should we pin base and builder back to 3.7 while the dust settles? | 18:34 |
| corvus | mordred: is there a python:slim-3.7 or something? yeah, that might be good | 18:34 |
| clarkb | did weget 3.7 last week and 3.8 today? | 18:34 |
| corvus | (i'm poking at the rehash thing now to see if 3.8 is a quick fix) | 18:34 |
| fungi | 3.8 was released late last week i think | 18:34 |
| corvus | clarkb: oh i didn't check -- that's possible! | 18:34 |
| mordred | corvus: k. I'll push up an update patch real quick | 18:35 |
| fungi | so entirely possible | 18:35 |
| corvus | ha, our attempt to sync versions could have failed :) | 18:35 |
| mordred | :) | 18:35 |
| mordred | so - maybe we should wait until the sync patch has landed and published then recheck :) | 18:35 |
| fungi | do those images use python from debian or python from source? | 18:35 |
| mordred | from source | 18:35 |
| clarkb | mordred: ++ | 18:35 |
| clarkb | re wait and recheck | 18:36 |
| corvus | that's getting into the weeds pretty fast. i opened an issue: https://github.com/kislyuk/rehash/issues/4 | 18:49 |
| corvus | i say we pin and check back in a bit | 18:49 |
| *** rfolco|rover has quit IRC | 18:59 | |
| openstackgerrit | Andreas Jaeger proposed zuul/zuul-jobs master: fetch_subunit: Change variable https://review.opendev.org/689864 | 19:06 |
| *** sgw has joined #zuul | 19:07 | |
| mordred | fbo: +A of https://review.opendev.org/#/c/687259/1 - but there's an inline comment from corvus | 19:07 |
| openstackgerrit | Andreas Jaeger proposed zuul/zuul-jobs master: fetch_subunit: Change variable https://review.opendev.org/689864 | 19:07 |
| *** rfolco has joined #zuul | 19:11 | |
| *** saneax has quit IRC | 19:15 | |
| *** jamesmcarthur has quit IRC | 19:30 | |
| *** jamesmcarthur has joined #zuul | 19:35 | |
| clarkb | AJaeger: ^ I think you have the +2's you need on that and its parent if you want to approve them together | 19:36 |
| AJaeger | clarkb: ah, thanks! | 19:37 |
| *** jamesmcarthur has quit IRC | 19:39 | |
| *** jamesmcarthur has joined #zuul | 19:44 | |
| openstackgerrit | Merged zuul/zuul-jobs master: fetch-subunit-output: collect additional subunits (2nd try) https://review.opendev.org/674334 | 19:48 |
| mordred | corvus: images built/promoted - I rechecked your first zuul-registry change | 19:50 |
| corvus | mordred: thanks! | 19:51 |
| *** jamesmcarthur has quit IRC | 19:51 | |
| *** jamesmcarthur has joined #zuul | 19:53 | |
| mordred | corvus: green | 19:57 |
| *** Goneri has quit IRC | 19:57 | |
| openstackgerrit | Merged zuul/zuul-jobs master: fetch_subunit: Change variable https://review.opendev.org/689864 | 19:58 |
| *** pcaruana has quit IRC | 20:16 | |
| openstackgerrit | James E. Blair proposed zuul/zuul-registry master: Collect docker logs in functional test https://review.opendev.org/689851 | 20:16 |
| openstackgerrit | James E. Blair proposed zuul/zuul-registry master: Handle ":" in passwords https://review.opendev.org/689829 | 20:17 |
| *** jamesmcarthur has quit IRC | 20:40 | |
| corvus | that ^ is ready to merge (and doing so would be very helpful) | 20:44 |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Use zuul-registry as buildset registry https://review.opendev.org/689238 | 20:44 |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Make the buildset registry port configurable https://review.opendev.org/689240 | 20:45 |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Test buildset registry with k8s and docker https://review.opendev.org/689280 | 20:45 |
| *** jamesmcarthur has joined #zuul | 20:46 | |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Make the buildset registry port configurable https://review.opendev.org/689240 | 20:58 |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Test buildset registry with k8s and docker https://review.opendev.org/689280 | 20:58 |
| *** jamesmcarthur has quit IRC | 21:00 | |
| mnaser | something for discussion: i'm trying to minimize the amount of setup involved to get started with zuul in a multi-tenant environment | 21:01 |
| mnaser | one of the "issues" currently is pipelines, because it's something that you don't just "get out of the box" | 21:02 |
| mnaser | i'm thinking both check/gate for all users/tenant by exposing the same project-config to all tenants | 21:03 |
| mnaser | _and_ config-projects are not exposed to the use, only untrusted-projects | 21:04 |
| corvus | mnaser: yes, sharing a config project is a fine thing to do -- in previous discussions, that's how we've evsinioned it | 21:04 |
| mnaser | i guess something for me to figure out eventually is if a user had a specific set of pipelines they wanted to build out, but i'd put that under 'advanced user' use case | 21:05 |
| corvus | mnaser: and on the other thing: yes also. mordred and i have talked about the potential need for an in-between kind of project -- a "tenant config project" which does not have the extra security access of a config project, but can do things like configure jobs on specific projects and define pipelines. | 21:06 |
| mordred | mnaser: I think especially for an aaS offering - having a standard set of pipelines everyone gets is a great idea - check/gate/post/promote/release | 21:07 |
| mordred | because those are going to handle 95% of people's use cases - and then, like you say, if someone wants to get fancier - awesome - advanced user :) | 21:07 |
| *** jamesmcarthur has joined #zuul | 21:08 | |
| corvus | i think the tenant-config-project idea is doable, but will probably be a fair number of lines of code | 21:08 |
| mordred | yah | 21:08 |
| mnaser | yeah, also i would imagine adding some sort of pipeline parenting would be really useful too (like jobs) | 21:08 |
| mnaser | "i want to redefine 'check' with some changes but not copy paste the whole thing" | 21:08 |
| corvus | interesting idea | 21:08 |
| mnaser | anyways, getting people to bite on zuul has been a little slower because it is a lot of handholding right now | 21:09 |
| mordred | nod | 21:10 |
| mnaser | so i may ask some people to volunteer to try out a zuul-as-a-service offering where it is fully self serve | 21:10 |
| *** tosky has joined #zuul | 21:10 | |
| mnaser | as of now, you just install the github app and then with the magic of code, you get a zuul tenant linked to your account and you're off to the races | 21:10 |
| mnaser | (using oauth with github to determine who owns what, etc) | 21:10 |
| mordred | cool! | 21:11 |
| openstackgerrit | Merged zuul/zuul-registry master: Collect docker logs in functional test https://review.opendev.org/689851 | 21:23 |
| *** jamesmcarthur has quit IRC | 21:26 | |
| *** mgoddard has quit IRC | 21:31 | |
| *** jamesmcarthur has joined #zuul | 21:32 | |
| *** mgoddard has joined #zuul | 21:32 | |
| openstackgerrit | James E. Blair proposed zuul/project-config master: Add gerrit image build job to gerrit checks plugin https://review.opendev.org/689880 | 21:33 |
| corvus | mordred: ^ i think that's the next step for upstream gerrit | 21:33 |
| mordred | corvus: lgtm | 21:34 |
| corvus | we can make sure that's green, then i think maybe we can add a zuul/gerrit integration job and run it there and on changes to zuul (where it would either use a speculative build if we use a depends-on, or will actually fetch the image from dockerhub otherwise). i think we'll also probably want to make sure that gets rebuilt on merged changes to gerrit and/or checks, so i think we'll have to do something in | 21:35 |
| corvus | the opendev tenant for that | 21:35 |
| corvus | weirdly, i think the biggest hurdle there is going to be the lack of a ref-updated event from googlesource | 21:35 |
| fungi | and the fix for that is web hooks? | 21:37 |
| fungi | or what is gerrit's answer to replacing the ssh event stream? | 21:37 |
| corvus | fungi: i think either web hooks, or we may be able to get the equivalent of change-merged with checks plugin | 21:38 |
| clarkb | are web hooks different than the checks api? | 21:40 |
| fungi | what protocol does the checks plugin emit events over? or you mean via polling a queue? | 21:41 |
| clarkb | fungi: you poll via http(s) | 21:42 |
| corvus | fungi: the checks plugin is ... erm... let's call it "delta polling" -- you poll it and it tells you what changes need updated results for your checker | 21:42 |
| corvus | so it's pretty efficient | 21:42 |
| corvus | but it's change oriented, so i don't see a way to replace "post" (ref-updated) pipelines with it. | 21:43 |
| fungi | got it | 21:43 |
| fungi | the events are change-scoped not project-scoped | 21:44 |
| corvus | clarkb: yes -- and i think webhooks are ... imaginary at this point? not 100% sure of the current status. | 21:44 |
| corvus | but i believe that the general answer for "replace the ssh stream" is "webhooks" | 21:44 |
| fungi | sure, i more meant what sort of solution were they looking at | 21:44 |
| openstackgerrit | Merged zuul/zuul-registry master: Handle ":" in passwords https://review.opendev.org/689829 | 21:44 |
| corvus | i think checks is going to be better for changes though -- so i expect the answer is that if all goes well, we will end up using both | 21:45 |
| clarkb | I see. Do they intend on fully removing the event stream then? | 21:45 |
| mordred | corvus: I think the gerrit webhooks plugin isn't imaginary | 21:45 |
| clarkb | (seems like all the laternatives don't quite give you the same data and removing it would be sad) | 21:45 |
| fungi | in theory the replication plugin could replace the remainder | 21:45 |
| mordred | https://gerrit.googlesource.com/plugins/webhooks/ | 21:45 |
| fungi | you just need a receiver which groks git | 21:45 |
| fungi | git push that is | 21:46 |
| *** jamesmcarthur has quit IRC | 21:46 | |
| corvus | fungi: yes, but that's heavy setup cost | 21:46 |
| fungi | i concur | 21:46 |
| corvus | mordred: neat! i love it when dreams come true | 21:46 |
| *** mgoddard has quit IRC | 21:47 | |
| mordred | corvus: should we add that to our master image builds as a forward-looking sort of thing? | 21:47 |
| fungi | also replacing change-merged with polling and ref-updated with a stream means you're likely to get the latter before the former | 21:47 |
| *** mgoddard has joined #zuul | 21:49 | |
| mordred | corvus: hah. we already build the webhooks plugin in our container images | 21:50 |
| mordred | it's almost like we've already thought of this before | 21:50 |
| *** jamesmcarthur has joined #zuul | 21:54 | |
| corvus | fungi: yeah, but i don't think that should cause too many problems -- we don't really try to synchronize post+promote | 21:55 |
| fungi | agreed, not likely a problem in practice | 21:57 |
| clarkb | might make sense to push that back up as feedback for the checks api though? | 21:57 |
| clarkb | "here are the things that a ci system (like ours) is currently triggering off of" | 21:58 |
| clarkb | granted I think most of my concern with webhooks lies in github's poor api forcing our lookups to be slow and isn't inherent to using webhooks | 21:59 |
| fungi | i'd be surprised if that wasn't already enumerated in discussions at the gerrit user summit | 21:59 |
| clarkb | also corps tend to like the connection direction to happen the other way around | 22:00 |
| clarkb | but if gerrit and zuul are in the same org that becomes less of a problem | 22:00 |
| mordred | yeah - there are some nice things about webhooks vs. ssh-stream too - like, ability to more easily load balance webhook receivers | 22:02 |
| clarkb | mordred: I mean more webhook vs checks plugin | 22:02 |
| mordred | oh - I don't think they see things as webhooks vs. checks plugin. they envision a webhook that says "please go check the checks api" | 22:03 |
| mordred | for opendev's zuul - that even will be nearly worthless | 22:03 |
| mordred | event | 22:03 |
| clarkb | if I read corvus correctly that will also be the only way to get a ref updated event? | 22:03 |
| clarkb | saying it would be useful to register with checks api that "I care about ref updated events and whatever else" directly | 22:04 |
| mordred | since by the time we're done wtih an event processing loop, it's almost certain we will have received another "go check the checks api" event | 22:04 |
| corvus | (ot: here's something to keep in the back of your mind -- if tags were to become reviewable objects in gerrit, they could also be subject to the checks api :) | 22:05 |
| mordred | clarkb: I mean - I think that's a webhooks thing - whether or not you want ref-updated events from the webhook plugin | 22:05 |
| mordred | corvus: ++ | 22:05 |
| corvus | clarkb: yes, but that's a very different model than they have designed | 22:05 |
| clarkb | mordred: but then you lose out on all the goodness of the checks api state tracking | 22:05 |
| clarkb | mordred: delta polling as corvus describes it | 22:05 |
| *** jamesmcarthur has quit IRC | 22:05 | |
| mordred | right - but it's delta polling related to what checks have you responded to with a checks response - which is a thing that doesn't make any sense for ref-updated | 22:06 |
| clarkb | mordred: why not? | 22:06 |
| clarkb | one of the responses is "I'm dealing with this" | 22:06 |
| clarkb | which could be very useful for a distributed system | 22:06 |
| corvus | i've lost track of what you're talking about :( | 22:06 |
| mordred | I have too - I thought I was following what clarkb was saying - but I think I am not actually | 22:07 |
| *** openstackgerrit has quit IRC | 22:07 | |
| clarkb | I'm suggesting that a consistent interface for tracking the things CI tools will take action on is a useful thing to have | 22:07 |
| clarkb | rather than having multiple interfaces to "here is the work to be done" with difference of features | 22:07 |
| corvus | clarkb: yes, i agree, but i don't think the checks api was designed with that in mind, and the data storage model is ill-suited to doing things with ref-updated-like events | 22:08 |
| corvus | webhooks, otoh, should be just as flexible as ssh-stream, and that works pretty well | 22:08 |
| fungi | it all started with corvus saying, "weirdly, i think the biggest hurdle there is going to be the lack of a ref-updated event from googlesource" and then me wondering what may come along in new gerrit versions to make something like ref-updated available in ways that google would be willing to expose to external systems | 22:08 |
| clarkb | I'd almost be inclined to just do everything through webhook sin that case | 22:08 |
| clarkb | though I guess you can't get the robot comment ui stuff that way? | 22:09 |
| mordred | clarkb: you don't get the check result matrix | 22:09 |
| corvus | clarkb: i think that will be an option, however, the visualization of results will be what we have today, not the nice separate channel that checks provide. | 22:09 |
| mordred | yah | 22:09 |
| corvus | of course, one could continue to push on david's results plugin. | 22:10 |
| corvus | "verify-status" that's what it's called | 22:11 |
| corvus | so webhooks + verify-status gets you improved ui with a similar event model to ssh (with the TCP direction reversed) | 22:11 |
| *** jhesketh has joined #zuul | 22:12 | |
| mordred | yah - but otoh the checks plugin is more likely to have weight behind it longer terms since it's being pushed by our google friends - and while we won't get deltas for ref-updated - we won't get that with webhooks+verify-status either | 22:13 |
| clarkb | mordred: no but at least when I need to debug why an event wasn't handled its always the same thing to debug | 22:14 |
| corvus | happily, zuul will support all of the above as long as gerrit does | 22:14 |
| clarkb | or when $corp goe sto update firewall rules they don't get fornwed at by the security team | 22:14 |
| mordred | which is why I think that checks + optionally webhooks is likley the best bet for us | 22:14 |
| clarkb | though maybe multiple services all talking http to each other in both directions isn't a weird thin to ask for anymore | 22:15 |
| corvus | fwiw, i vigorously defended the ssh stream api at the user summit, and will continue to :) | 22:15 |
| corvus | it's one of the least breaky thing's i've ever dealt with :) | 22:15 |
| clarkb | ++ | 22:15 |
| mordred | ++ | 22:16 |
| fungi | clearly a reason to replace it then | 22:16 |
| fungi | "this thing has been working far too well for far too long" | 22:16 |
| corvus | yeah, you don't want mbtf outliers | 22:16 |
| mordred | some of the folks there seemed to have had a different experience with it than we have | 22:16 |
| corvus | yep. all points of view were presented :) | 22:17 |
| mordred | with comments about it being completely unreliable and they didn't understand how anyone could use it in production ... which we kind of blinked at :) | 22:17 |
| clarkb | huh | 22:17 |
| *** hashar has quit IRC | 22:17 | |
| mordred | so - I definitely think it was one of those good meeting moments where we were all able to hear that different experiences existed | 22:17 |
| clarkb | I wonder if that comes down to clients | 22:17 |
| clarkb | (we know some clients can make the gerrit sshd sad, paramiko included if connections are not closed properly) | 22:17 |
| clarkb | fwiw I think the webhook system works relatively poorly with the github driver (relative to the ssh events stream). Which is part of my concern that we are getting two different thing sthat are similar to that. But as I mentioned that is more a problem of github's api not being able to lookup PRs by sha easily. And I should just roll with it before worrying we'll get two less good thing we have to use together | 22:19 |
| clarkb | :) | 22:20 |
| clarkb | I've also heard concerns from people about opening their firewalls for github to send http connections into their corp network, thhankfully github does publish source IPs though and with gerrit you run gerrit typically making that less of an issue | 22:20 |
| mordred | ++ | 22:21 |
| corvus | clarkb: i'm really happy to test this all out with gerrit's gerrit before we use it anywhere else :) | 22:21 |
| corvus | maybe we should see if we can get a webhook setup with them | 22:22 |
| corvus | use it to publish those images | 22:22 |
| clarkb | that sounds like a great idea (particularly if that is the only way to get the ref updated events from them today) | 22:22 |
| mordred | ++ | 22:22 |
| *** openstackgerrit has joined #zuul | 22:24 | |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Test buildset registry with k8s and docker https://review.opendev.org/689280 | 22:24 |
| corvus | i think i'm pretty close to the only remaining bug in that series being the ipv6 thing. i've set an autohold for that and am rechecking that series to try to catch a v6 host | 22:24 |
| *** mgoddard has quit IRC | 22:27 | |
| *** mgoddard has joined #zuul | 22:33 | |
| * mordred wishes corvus luck | 22:43 | |
| *** mgoddard has quit IRC | 22:47 | |
| *** ianychoi has quit IRC | 23:00 | |
| *** ianychoi has joined #zuul | 23:00 | |
| *** mattw4 has quit IRC | 23:09 | |
| fungi | who's the pale blue on https://etherpad.openstack.org/p/zuul-community-airship-confirmation-feedback ? | 23:11 |
| fungi | wanting some clarification on the gerrit point so i can accurately represent it in the feedback e-mail message i'm compiling for the public foundation ml | 23:12 |
| clarkb | fungi: me | 23:14 |
| fungi | cool, so is the point you want made that the use of gerrit shapes/lubricates the possible interaction between the projects? | 23:15 |
| fungi | just trying to figure out how to work it in | 23:16 |
| fungi | or was it simply that we should avoid referring to opendev's zuul on its own, lest that appear to be "zuul as a service" rather than ain integrated development platform? | 23:17 |
| clarkb | ya that was more the point | 23:17 |
| clarkb | the second thing | 23:17 |
| fungi | okay, cool, i'll reword the e-mail i'm drafting to that end | 23:18 |
| fungi | thanks!!! | 23:18 |
| fungi | airship uses opendev, which integrates zuul and gerrit for a unified code-review-driven development experience. i'll take that angle | 23:19 |
| mordred | ++ | 23:20 |
| *** ianychoi has quit IRC | 23:24 | |
| *** ianychoi has joined #zuul | 23:26 | |
| fungi | okay, my draft feedback e-mail is at the bottom of https://etherpad.openstack.org/p/zuul-community-airship-confirmation-feedback is anyone wants to proofread or make further suggestions | 23:29 |
| fungi | i'd like to send it in half an hour, as the board meeting is something like 13.5 hours away | 23:29 |
| *** tosky has quit IRC | 23:32 | |
| *** jamesmcarthur has joined #zuul | 23:40 | |
| *** michael-beaver has quit IRC | 23:56 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!