| tristanC | clarkb: iiuc, the scheduler did start even though there is a sys.exit(0) in the change: http://logs.openstack.org/35/658935/1/check/zuul-quick-start/9a353f9/container_logs/scheduler.log | 00:00 |
|---|---|---|
| tristanC | clarkb: and the docker images list seems to show images from docker hub: http://logs.openstack.org/35/658935/1/check/zuul-quick-start/9a353f9/ara-report/result/013c21ff-6e33-4bfc-a7ea-ed861e36bea1/ | 00:01 |
| clarkb | ah I was reading the log collection output not the actual compose up output | 00:02 |
| tristanC | clarkb: do you know if the zuul-build-image is supposed to honor depends-on nodepool changes? | 00:02 |
| clarkb | I think it is supposed to for all images it knows about. The buildset registry is started to store all of the inflight source changes | 00:03 |
| clarkb | http://logs.openstack.org/35/658935/1/check/zuul-build-image/6dfa140/job-output.txt.gz#_2019-05-13_23_36_45_373160 for example that zuul-web image is pushed into the buildset registry then quickstart should pull it out (though I agree the logs don't show that hash being used) | 00:03 |
| tristanC | clarkb: for example this zuul change depends-on a nodepool change, but i can't find nodepool image build logs: https://review.opendev.org/658486 | 00:04 |
| tristanC | or is the zuul-build-image registry supposed to also proxy the nodepool-build-image registry? | 00:05 |
| tristanC | but in that case, the nodepool change wasn't live and its registry was gone | 00:05 |
| clarkb | tristanC: the nodepool change should push its built images to the intermediate registry too | 00:06 |
| clarkb | tristanC: so in the case of non live items the image will come from the intermediate registry | 00:06 |
| clarkb | and in the case of the current live item it gets the image from the buildset registry (or at least that is what is supposed to happen) | 00:06 |
| tristanC | where is the intermediate registry located? | 00:07 |
| clarkb | tristanC: we run it in one of our clouds (I forget which one) | 00:07 |
| clarkb | it is a registry backed with swift | 00:07 |
| clarkb | so I think the issue here is our use of latest | 00:07 |
| tristanC | oh i see, it's not managed by zuul pipelines | 00:07 |
| clarkb | tristanC: correct it just exists to support the jobs but isn't managed by them | 00:08 |
| clarkb | when we push to the intermediate and buidlset registries we use the change based tags but I don't think we promote anything to 'latest' until changes merge | 00:08 |
| clarkb | https://opendev.org/zuul/zuul/src/branch/master/doc/source/admin/examples/docker-compose.yaml I think we may need to update that docker compose file to use the appropriate flags when tested with zuul | 00:09 |
| clarkb | (default of latest is probably what we want in the default case for people getting started with zuul) | 00:09 |
| clarkb | https://docs.docker.com/compose/compose-file/#image is the docs for that | 00:12 |
| clarkb | maybe the job can do a simple sed/awk type string replacement before running docker-compose up? | 00:12 |
| *** zbr_ has joined #zuul | 00:12 | |
| clarkb | I've got to run to dinner now | 00:12 |
| *** zbr has quit IRC | 00:14 | |
| *** saneax has quit IRC | 00:49 | |
| corvus | tristanC, clarkb: the images built in the zuul-build-image job should be pushed to the buildset registry with the latest tag, so zuul-build-image should use those instead of the ones from dockerhub | 00:50 |
| corvus | i haven't looked into the logs to see why that isn't the case -- that's just the way it's supposed to work. | 00:50 |
| corvus | tristanC, clarkb: here's where zuul-scheduler:latest was pushed to the buildset registry: http://logs.openstack.org/35/658935/1/check/zuul-build-image/6dfa140/ara-report/result/7e2084b2-f054-44e3-a9ce-e502069100df/ | 00:53 |
| tristanC | corvus: when setting docker-compose --verbose argument, you can see it doesn't try the buildset registry and goes straight to dockerhub | 00:54 |
| corvus | tristanC: do you have a change with --verbose? | 00:55 |
| tristanC | corvus: https://review.opendev.org/#/c/658738/4 | 00:57 |
| tristanC | here is the logs: http://logs.openstack.org/38/658738/2/check/zuul-quick-start/f16c80a/ara-report/result/77e58afb-9f70-4dac-a4d0-1984253901d4/ | 00:57 |
| corvus | tristanC: keep in mind that it's actually the docker daemon which performs the image pulls, and it should be configured to use the buildset registry as a mirror | 00:59 |
| corvus | i'm not that familiar with the output of docker-compose --verbose, but it's conceivable that it would only think that it's instructing the docker daemon to pull an image from dockerhub, and only the docker daemon knows about the buildset registry | 01:00 |
| corvus | perhaps the docker daemon log would shed more light on the issue | 01:01 |
| tristanC | corvus: according to https://review.opendev.org/658738 and https://review.opendev.org/658935, it seems like this is caused by the docker configuration for buildset registry not being set for the user running docker-compose | 01:03 |
| corvus | tristanC: the mirror configuration is set for the daemon in /etc, and the user authentication information is set for the user running docker-compose (zuul) | 01:05 |
| corvus | here's the user auth config: http://logs.openstack.org/35/658935/1/check/zuul-quick-start/9a353f9/ara-report/result/c73d0873-9433-433c-b8c2-9a56671bfcfc/ | 01:05 |
| corvus | and here's the daemon: http://logs.openstack.org/35/658935/1/check/zuul-quick-start/9a353f9/ara-report/ | 01:05 |
| corvus | grr | 01:05 |
| corvus | the daemon: http://logs.openstack.org/35/658935/1/check/zuul-quick-start/9a353f9/ara-report/result/a090481d-2e4d-4039-9ada-bb2c904f4c6a/ | 01:05 |
| corvus | this should be what the daemon is configured with: http://logs.openstack.org/35/658935/1/check/zuul-quick-start/9a353f9/ara-report/result/38dd9fdc-830d-4baa-bfce-50e530b9187d/ and the user config: http://logs.openstack.org/35/658935/1/check/zuul-quick-start/9a353f9/ara-report/result/5055b2dc-607f-47d4-be0f-567a1bacbe9e/ | 01:07 |
| tristanC | corvus: yes, and with https://review.opendev.org/658738 , the docker configuration is set for the right user, resulting in compose image to being pulled from the registry... | 01:08 |
| corvus | tristanC: oh i missed your comment where you pointed out that it is running as root: https://opendev.org/zuul/zuul/src/branch/master/playbooks/quick-start/main.yaml/#L6 | 01:08 |
| corvus | that would be the cause -- the auth information won't be present, and the docker daemon will fail to retrieve the info from the buildset registry and buildset proxy, and so will fetch directly from dockerhub | 01:10 |
| corvus | tristanC: then i think 658738 is correct (or, as you say, we could try removing become:true -- since i thought it was like that already, i clearly don't remember why we thought we needed to be root) | 01:12 |
| corvus | tristanC: +2 on 658738 with comments | 01:14 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: Try running docker-compose as zuul user https://review.opendev.org/658941 | 01:14 |
| tristanC | corvus: let's see how that goes ^ | 01:15 |
| corvus | tristanC: there's an error in that | 01:15 |
| corvus | tristanC: if you want to fix that real quick i can +2 that one too | 01:15 |
| tristanC | corvus: it's a test rebased on the change that should have failed. if that works as expected, i'll drop the become from https://review.opendev.org/658738 | 01:16 |
| corvus | tristanC: oh ok. i'll update my comment then. | 01:17 |
| corvus | tristanC: thanks for fixing this, and sorry i missed https://opendev.org/zuul/zuul/src/branch/master/playbooks/quick-start/main.yaml/#L6 | 01:18 |
| * corvus -> dinner | 01:19 | |
| tristanC | corvus: no worries, you're welcome | 01:19 |
| tristanC | Shrews: there has been discussion in the past to have a generic ansible driver in nodepool to leverage ansible's modules. there is also someone interested in writing a driver based on https://github.com/CentOS-PaaS-SIG/linchpin | 02:00 |
| tristanC | i think that would bring a lot of value to nodepool since ansible can talk to so many provider, but i agree with your concern | 02:01 |
| tristanC | actually, the initial runc driver was using paramiko since we only need a few commands to create a container | 02:02 |
| tristanC | using the ansible-playbook add quite an overhead to nodepool launcher, but perhaps using ansible-runner would enable a suitable api | 02:03 |
| Shrews | tristanC: yeah I remember such discussions. I think we need to fully map out our handling of Ansible though before we add support for it | 02:04 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: zuul-quick-start: run docker-compose as regular user https://review.opendev.org/658738 | 02:12 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: DNM: show zuul-quick-start doesn't test speculative images https://review.opendev.org/658935 | 02:13 |
| *** bhavikdbavishi has joined #zuul | 02:28 | |
| tristanC | tobiash: i'm trying to debug the tox-remote job, would you know why this change doesn't seems to be taken into account: https://review.opendev.org/#/c/657914/10/zuul/ansible/base/library/zuul_console.py@193 | 02:30 |
| tristanC | tobiash: i'd like to debug why some task results in "Log not found" by sending the traceback over the socket, but it seems like the change to this file has no effect | 02:31 |
| tristanC | tobiash: if you look at the testr result, there are "[Zuul] Log not found" but no "[Zuul] LOG NOT FOUND" | 02:32 |
| *** bhavikdbavishi has quit IRC | 02:51 | |
| *** bhavikdbavishi has joined #zuul | 02:52 | |
| *** rlandy|bbl is now known as rlandy | 03:02 | |
| *** bhavikdbavishi has quit IRC | 03:11 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: use-buildset-registry: add registry-1.docker.io https://review.opendev.org/658951 | 03:13 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: DNM: show zuul-quick-start doesn't test speculative images https://review.opendev.org/658935 | 03:15 |
| *** bhavikdbavishi has joined #zuul | 03:17 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: DNM: show zuul-quick-start doesn't test speculative images https://review.opendev.org/658935 | 03:47 |
| *** rlandy has quit IRC | 03:53 | |
| *** bjackman_ has joined #zuul | 03:59 | |
| SpamapS | Still doesn't make sense to me to write a "runc" driver. If it doesn't have an API of some sort, I don't think nodepool should be the way we interact with it. | 04:22 |
| SpamapS | wrapping a local container tool in ssh.. that feels like job content to me. | 04:22 |
| *** pcaruana|afk| has joined #zuul | 04:25 | |
| *** pcaruana|afk| has quit IRC | 04:35 | |
| *** gtema has joined #zuul | 04:47 | |
| *** gtema has quit IRC | 04:52 | |
| *** electrofelix has quit IRC | 05:26 | |
| *** gtema has joined #zuul | 05:36 | |
| *** bjackman__ has joined #zuul | 05:37 | |
| *** bjackman_ has quit IRC | 05:41 | |
| tristanC | SpamapS: we have been using nodepool to start runc service quite succesfully, it enables more efficient usage of a static node to run jobs | 05:49 |
| tristanC | and we don't want to give job access to the host | 05:50 |
| tristanC | but we could move that driver logic to our confmgmt playbook and use the static driver with pre-prepared runc service | 05:51 |
| *** gtema has quit IRC | 05:53 | |
| *** saneax has joined #zuul | 06:01 | |
| *** abraverm has joined #zuul | 06:18 | |
| *** bjackman_ has joined #zuul | 06:18 | |
| *** bjackman__ has quit IRC | 06:21 | |
| *** quiquell|off is now known as quiquell | 06:36 | |
| *** gtema has joined #zuul | 06:43 | |
| *** pcaruana has joined #zuul | 07:12 | |
| *** jesusaur has quit IRC | 07:13 | |
| *** bhavikdbavishi has quit IRC | 07:14 | |
| *** themroc has joined #zuul | 07:16 | |
| *** snapiri has joined #zuul | 07:29 | |
| *** jangutter has joined #zuul | 07:50 | |
| *** jpena|off is now known as jpena | 07:59 | |
| *** bhavikdbavishi has joined #zuul | 08:14 | |
| *** hashar has joined #zuul | 08:35 | |
| *** electrofelix has joined #zuul | 08:54 | |
| *** jesusaur has joined #zuul | 09:28 | |
| *** markwork has joined #zuul | 09:36 | |
| *** yolanda_ has quit IRC | 10:06 | |
| *** yolanda_ has joined #zuul | 10:08 | |
| *** gtema has quit IRC | 10:18 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: web: remove SafeLoader left-over from MappingProxyEncoder https://review.opendev.org/659026 | 10:18 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: web: honor job dependencies in trigger modal https://review.opendev.org/657567 | 10:31 |
| *** jangutter has quit IRC | 10:56 | |
| *** armstrongs has joined #zuul | 11:15 | |
| *** jangutter has joined #zuul | 11:31 | |
| *** jpena is now known as jpena|lunch | 11:41 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: web: remove SafeLoader left-over from ZuulJSONEncoder https://review.opendev.org/659026 | 12:01 |
| *** bhavikdbavishi has quit IRC | 12:06 | |
| *** rlandy has joined #zuul | 12:30 | |
| *** jpena|lunch is now known as jpena | 12:32 | |
| SpamapS | tristanC:I see your point, and I do think it might make sense to be able to say "this static node supports X concurrent jobs using it" and then you can do the entire runc integration in pre/post playbooks. | 12:33 |
| *** jamesmcarthur has joined #zuul | 12:46 | |
| *** gtema has joined #zuul | 12:52 | |
| *** yolanda_ has quit IRC | 12:57 | |
| SpamapS | markwork: bitbucket driver looking good. I noticed a question the other day that you had, and I wanted to clarify. You wondered why reporters merge, and whether that's for "trunk based development". Zuul's whole purpose in life is really to be in charge of merging code for others, so that the build is never broken. Wondering if you've read https://zuul-ci.org/docs/zuul/user/gating.html | 13:00 |
| *** bjackman has joined #zuul | 13:03 | |
| *** bjackman_ has quit IRC | 13:04 | |
| *** dmellado has quit IRC | 13:24 | |
| *** dmellado has joined #zuul | 13:24 | |
| *** bjackman has quit IRC | 13:26 | |
| *** jamesmcarthur has quit IRC | 13:36 | |
| markwork | SpamapS: yes, I've read that, but as far as I understand: Zuul merges and pushes, it usually does not do this via the service API | 13:50 |
| markwork | From what I see, this just looked like they reporters will merge on a successful build, pretty indiscriminately. | 13:52 |
| markwork | I.e. to me this looked like this was some extra feature and not the main path the code would take. | 13:52 |
| SpamapS | markwork: I once made that assumption too. No, Zuul does not push for a number of reasons. | 13:55 |
| SpamapS | Mostly that nobody has had enough reason to go back and change it to do that. | 13:55 |
| SpamapS | It basically "clicks the merge button" | 13:55 |
| *** jamesmcarthur has joined #zuul | 13:56 | |
| markwork | Cool, so that needs to be added to the reporter. That's up next. | 13:56 |
| *** jamesmcarthur has quit IRC | 13:57 | |
| *** jamesmcarthur has joined #zuul | 13:58 | |
| SpamapS | markwork: indeed. | 14:01 |
| *** sshnaidm has joined #zuul | 14:07 | |
| *** sshnaidm is now known as sshnaidm|afk | 14:08 | |
| markwork | SpamapS: I looked at the gerrit reporter and my test installation/zuul-config repo. I think I do now understand how this works. | 14:52 |
| *** gtema has quit IRC | 14:58 | |
| dmsimard | We have about every possible bit of information in the zuul vars except the commit hash :( | 15:00 |
| dmsimard | It looks like https://opendev.org/zuul/zuul/src/branch/master/zuul/executor/client.py#L157 is where we map the variables -- is the commit hash available at that point ? | 15:01 |
| clarkb | dmsimard: I think it may be left out because it is in the git repos themselves | 15:06 |
| clarkb | (so if you need that info, ask the git repo in the job) | 15:06 |
| dmsimard | clarkb: one could argue that there are a lot of information available from the git repos themselves :p | 15:07 |
| dmsimard | I've been doing it "manually" already, fwiw | 15:07 |
| clarkb | sure but that info there is not git info it is code review and zuul info | 15:08 |
| clarkb | the git info can be stored in git (and is) | 15:08 |
| dmsimard | fair | 15:08 |
| *** sshnaidm|afk has quit IRC | 15:25 | |
| *** themroc has quit IRC | 15:26 | |
| *** sshnaidm has joined #zuul | 15:27 | |
| *** sshnaidm is now known as sshnaidm|afk | 15:29 | |
| openstackgerrit | Mark Meyer proposed zuul/zuul master: Create a basic Bitbucket build status reporter https://review.opendev.org/658335 | 15:32 |
| openstackgerrit | Mark Meyer proposed zuul/zuul master: Create a basic Bitbucket event source https://review.opendev.org/658835 | 15:32 |
| markwork | SpamapS: can you have a look at the update: https://review.opendev.org/#/c/658335/ that's the last change I want to get in that commit. | 15:39 |
| *** openstackgerrit has quit IRC | 15:54 | |
| *** bjackman has joined #zuul | 16:07 | |
| *** openstackgerrit has joined #zuul | 16:08 | |
| openstackgerrit | Fabien Boucher proposed zuul/zuul master: Fix dequeue ref not handling the project name https://review.opendev.org/659110 | 16:08 |
| pabelanger | http://logs.openstack.org/38/658738/6/gate/zuul-quick-start/e9fa454/job-output.txt.gz#_2019-05-14_16_00_11_486690 | 16:09 |
| pabelanger | that looks to be a new quickstart auth failure | 16:09 |
| pabelanger | does quickstart use our reverse proxy for docker? | 16:09 |
| pabelanger | or is that hitting it directly | 16:09 |
| clarkb | pabelanger: that issue is existing. What is supposed to happen there is it uses the buildset registry proxy to talk to dockerhub (and that proxy is authenticated), But beause of how docker works if all mirrors fail it talks to dockerhub directly anyway | 16:10 |
| clarkb | pabelanger: and in this case it fails because the authentication credentials are invalid on dockerhub (only valid for the buildset registry) | 16:10 |
| clarkb | pabelanger: It seems to only happen in ipv6 clouds so one thought is that the many:1 nat is failing us when the proxy tries to fetch from dockerhub | 16:11 |
| pabelanger | okay, understand | 16:11 |
| pabelanger | do we have a potential fix in flight? | 16:11 |
| clarkb | pabelanger: the longer term fix for that is to not use the buildset registry proxy if we are running in an environment with region locam mirrors (because those can have floating IPs and 1:1 nat which is far more reliable) | 16:11 |
| clarkb | but before we do that we need to spin up tls on the region mirrors because we are publishing these images too (not just consuming them) | 16:11 |
| clarkb | ianw has been working on the tls of the mirrors bit | 16:11 |
| pabelanger | kk | 16:11 |
| clarkb | https://review.opendev.org/#/c/658281/ is the WIP change for that | 16:12 |
| clarkb | basically all of this would be better and probably just work if dockerhub added AAAA records to dns | 16:12 |
| *** hashar has quit IRC | 16:15 | |
| clarkb | (and yes hub.docker.com is hosted on aws with elb and elb supports ipv6 now) | 16:16 |
| *** bjackman_ has joined #zuul | 16:18 | |
| *** bjackman has quit IRC | 16:20 | |
| *** mgoddard has quit IRC | 16:20 | |
| pabelanger | clarkb: have we asked for a AAAA record on dockerhub? | 16:20 |
| *** mgoddard has joined #zuul | 16:21 | |
| clarkb | no (I wouldn't know who to ask and my experience wit htheir bug trackers is no one responds) | 16:22 |
| pabelanger | k, I'll recheck for now | 16:24 |
| pabelanger | follow up with ianw later | 16:24 |
| *** mgoddard has quit IRC | 16:30 | |
| *** mgoddard has joined #zuul | 16:32 | |
| *** markwork has quit IRC | 16:40 | |
| *** mgoddard has quit IRC | 16:48 | |
| *** mgoddard has joined #zuul | 16:48 | |
| *** jamesmcarthur has quit IRC | 16:50 | |
| *** mattw4 has joined #zuul | 16:53 | |
| *** jamesmcarthur has joined #zuul | 16:56 | |
| *** jamesmcarthur has quit IRC | 17:01 | |
| *** mgoddard has quit IRC | 17:02 | |
| *** mgoddard has joined #zuul | 17:03 | |
| *** jamesmcarthur has joined #zuul | 17:08 | |
| *** jamesmcarthur has quit IRC | 17:11 | |
| *** mgoddard has quit IRC | 17:20 | |
| *** mgoddard has joined #zuul | 17:22 | |
| *** rfolco|ruck is now known as rfolco|dentist | 17:25 | |
| *** jamesmcarthur has joined #zuul | 17:31 | |
| *** armstrongs has quit IRC | 17:33 | |
| *** jpena is now known as jpena|off | 17:41 | |
| *** bjackman_ has quit IRC | 17:44 | |
| *** mattw4 has quit IRC | 17:48 | |
| *** mattw4 has joined #zuul | 17:49 | |
| *** tjgresha has quit IRC | 17:54 | |
| *** jamesmcarthur has quit IRC | 17:55 | |
| *** jamesmcarthur has joined #zuul | 17:56 | |
| *** tjgresha has joined #zuul | 17:57 | |
| *** jamesmcarthur has quit IRC | 18:01 | |
| openstackgerrit | Fabien Boucher proposed zuul/zuul master: Fix dequeue ref not handling the project name https://review.opendev.org/659110 | 18:02 |
| *** hashar has joined #zuul | 18:25 | |
| *** jamesmcarthur has joined #zuul | 18:28 | |
| *** markwork has joined #zuul | 18:43 | |
| *** Armstrongs has joined #zuul | 18:47 | |
| *** jamesmcarthur has quit IRC | 18:48 | |
| *** Armstrongs has quit IRC | 18:56 | |
| *** pcaruana has quit IRC | 19:19 | |
| *** jamesmcarthur has joined #zuul | 19:20 | |
| *** jamesmcarthur has quit IRC | 19:27 | |
| *** jamesmcarthur_ has joined #zuul | 19:28 | |
| *** jamesmcarthur has joined #zuul | 19:29 | |
| *** jamesmcarthur_ has quit IRC | 19:33 | |
| *** rfolco|dentist is now known as rfolco|ruck | 19:39 | |
| SpamapS | dmsimard:the git commit hash is only relevant in ref items, IIRC | 19:46 |
| SpamapS | dmsimard:for change items, the final hash will be something else on merge, so that hash is basically worthless. | 19:47 |
| SpamapS | (except in the promote style pipeline where you trigger on a merged change, but in that case, you can trust the git repo) | 19:47 |
| *** hashar has quit IRC | 20:04 | |
| *** jamesmcarthur has quit IRC | 20:15 | |
| *** jamesmcarthur has joined #zuul | 20:31 | |
| *** jamesmcarthur_ has joined #zuul | 20:37 | |
| *** jamesmcarthur has quit IRC | 20:40 | |
| *** jamesmcarthur_ has quit IRC | 20:41 | |
| *** jamesmcarthur has joined #zuul | 20:47 | |
| *** jamesmcarthur has quit IRC | 20:50 | |
| *** jamesmcarthur has joined #zuul | 20:55 | |
| *** jamesmcarthur has joined #zuul | 20:55 | |
| *** jamesmcarthur has quit IRC | 20:59 | |
| *** markwork has quit IRC | 21:03 | |
| *** markwork has joined #zuul | 21:06 | |
| *** jamesmcarthur has joined #zuul | 21:20 | |
| *** jamesmcarthur has quit IRC | 21:30 | |
| *** jamesmcarthur has joined #zuul | 21:31 | |
| *** jamesmcarthur has quit IRC | 21:36 | |
| *** jamesmcarthur has joined #zuul | 21:40 | |
| *** jamesmcarthur has quit IRC | 21:44 | |
| *** mattw4 has quit IRC | 21:54 | |
| openstackgerrit | Monty Taylor proposed zuul/zuul master: Spec: Add a Kubernetes Operator for Zuul https://review.opendev.org/659180 | 22:26 |
| mordred | SpamapS, tobiash, tristanC: ^^ that's first-stab at my VERY long overdue spec I keep promising. it's written with the expectation that we can discuss/argue/disagree about details and I expect it to morph as we do - as well as grow examples as needed. | 22:28 |
| tristanC | SpamapS: what you suggested about static node usage would be really cool. It seems like the missing piece is the capability for a pre run to change the inventory (to isolate the jobs running an the unique provided static node) right? Or do you know another way of doing this? | 22:28 |
| *** markwork has quit IRC | 22:30 | |
| tristanC | mordred: thanks! | 22:30 |
| mordred | tristanC, SpamapS: I also think "I want to run a small AIO zuul" is potentially well served by a simple non-COE-needing container driver | 22:35 |
| mordred | tristanC: I also owe you a review on the runc patch ... which I might not be able to get to until tomorrow. the short version (and my biggest concern) is that I worry that runc is too low level and we should use something like podman and/or remote docker instead | 22:36 |
| mordred | but there are tons of dragons there | 22:36 |
| mordred | remote docker becomes a problem once you pass the connection info to the executor, because ansible can't use the docker connection plugin if it also needs to jump through something | 22:37 |
| mordred | https://www.projectatomic.io/blog/2018/05/podman-varlink/ exists - but needs a lot of the same scaffolding you've got with the current thing | 22:37 |
| mordred | anyway - I owe you a real review and I'm sorry I haven't gotten to it yet :( | 22:37 |
| tristanC | mordred: SpamapS suggestion is actually better, if the container can be created on an existing static node by a pre run (and the rest of the job be bound to that nested environment), then the job could use any runtime with any image | 22:43 |
| tristanC | which would be better because user could test new image ref as part of the job | 22:44 |
| clarkb | the danger with that is in updating the inventory safely (so that we don't expose the executor)? | 22:44 |
| mordred | tristanC: ooh, good point | 22:44 |
| mordred | but consider me to be waving my arms wildly :) | 22:45 |
| tristanC | clarkb: a job can already use add_host, but we would need to be able to "replace_host" | 22:45 |
| nickx-intel | ~(@___@ )~ mordred | 22:45 |
| mordred | tristanC: I still think there is a valuable use-case for the small-install. I thnik the pre-run use-case like you and SpamapS are talking about could be really good for a zuul like SF.io | 22:45 |
| mordred | because like you say it's more powerful/flexible | 22:46 |
| *** mattw4 has joined #zuul | 22:54 | |
| *** Armstrongs has joined #zuul | 23:01 | |
| *** Armstrongs has quit IRC | 23:11 | |
| *** jamesmcarthur has joined #zuul | 23:17 | |
| *** rlandy is now known as rlandy|bbl | 23:37 | |
| *** irclogbot_0 has quit IRC | 23:45 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/nodepool master: static: add host-key-checking toggle https://review.opendev.org/653679 | 23:46 |
| *** jamesmcarthur has quit IRC | 23:49 | |
| *** irclogbot_3 has joined #zuul | 23:49 | |
| *** jamesmcarthur has joined #zuul | 23:49 | |
| *** jamesmcarthur has quit IRC | 23:54 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!