| *** jamesmcarthur has quit IRC | 00:24 | |
| *** jamesmcarthur has joined #zuul | 00:25 | |
| *** jamesmcarthur has quit IRC | 00:30 | |
| *** jamesmcarthur has joined #zuul | 00:55 | |
| *** rfolco|bbl has quit IRC | 00:59 | |
| *** jamesmcarthur has quit IRC | 01:02 | |
| *** jamesmcarthur has joined #zuul | 01:19 | |
| *** jamesmcarthur has quit IRC | 01:25 | |
| *** jamesmcarthur has joined #zuul | 01:26 | |
| *** jamesmcarthur has quit IRC | 01:50 | |
| *** jamesmcarthur has joined #zuul | 01:51 | |
| *** jamesmcarthur has quit IRC | 02:00 | |
| *** jamesmcarthur has joined #zuul | 02:00 | |
| *** jamesmcarthur has quit IRC | 02:33 | |
| *** jamesmcarthur has joined #zuul | 02:50 | |
| *** jamesmcarthur has quit IRC | 03:06 | |
| *** jamesmcarthur has joined #zuul | 03:06 | |
| *** jamesmcarthur has quit IRC | 03:17 | |
| *** bhavikdbavishi has joined #zuul | 03:33 | |
| *** bhavikdbavishi1 has joined #zuul | 04:08 | |
| *** bhavikdbavishi has quit IRC | 04:10 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 04:10 | |
| *** bolg has joined #zuul | 04:17 | |
| *** igordc has joined #zuul | 04:19 | |
| *** igordc has quit IRC | 05:22 | |
| *** igordc has joined #zuul | 05:51 | |
| *** AJaeger has quit IRC | 05:53 | |
| *** AJaeger has joined #zuul | 05:59 | |
| *** pcaruana has joined #zuul | 06:22 | |
| *** bolg has quit IRC | 06:50 | |
| *** saneax has joined #zuul | 07:00 | |
| *** tosky has joined #zuul | 07:17 | |
| *** bolg has joined #zuul | 07:35 | |
| *** themroc has joined #zuul | 07:35 | |
| *** jpena|off is now known as jpena | 07:45 | |
| *** igordc has quit IRC | 07:50 | |
| *** avass has joined #zuul | 07:50 | |
| *** hashar has joined #zuul | 08:06 | |
| *** pcaruana has quit IRC | 08:13 | |
| *** pcaruana has joined #zuul | 08:18 | |
| openstackgerrit | Jan Kubovy proposed zuul/zuul master: Include session expired reason in API fetch error message. https://review.opendev.org/686976 | 08:29 |
|---|---|---|
| *** gtema_ has joined #zuul | 08:53 | |
| openstackgerrit | Jan Kubovy proposed zuul/zuul master: Evaluate CODEOWNERS settings during canMerge check https://review.opendev.org/644557 | 08:58 |
| *** gtema_ has quit IRC | 08:59 | |
| *** tobiash has quit IRC | 09:21 | |
| *** tobiash has joined #zuul | 09:23 | |
| *** bhavikdbavishi has quit IRC | 09:49 | |
| *** jangutter has joined #zuul | 09:54 | |
| *** panda|off is now known as panda | 09:54 | |
| openstackgerrit | Jan Kubovy proposed zuul/zuul master: Include session expired reason in API fetch error message. https://review.opendev.org/686976 | 10:17 |
| *** themroc has quit IRC | 10:31 | |
| *** hashar has quit IRC | 10:53 | |
| *** bhavikdbavishi has joined #zuul | 11:05 | |
| *** bhavikdbavishi1 has joined #zuul | 11:08 | |
| *** bhavikdbavishi has quit IRC | 11:09 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 11:09 | |
| *** pcaruana has quit IRC | 11:11 | |
| *** hashar has joined #zuul | 11:16 | |
| *** themroc has joined #zuul | 11:28 | |
| *** saneax has quit IRC | 11:29 | |
| *** saneax has joined #zuul | 11:29 | |
| *** jpena is now known as jpena|lunch | 11:33 | |
| *** pcaruana has joined #zuul | 11:42 | |
| *** avass has quit IRC | 12:00 | |
| *** rfolco|bbl has joined #zuul | 12:07 | |
| *** bhavikdbavishi has quit IRC | 12:07 | |
| *** bhavikdbavishi has joined #zuul | 12:11 | |
| *** rfolco|bbl is now known as rfolco | 12:14 | |
| *** jpena|lunch is now known as jpena | 12:31 | |
| *** bhavikdbavishi has quit IRC | 12:31 | |
| *** rlandy has joined #zuul | 12:32 | |
| *** jamesmcarthur has joined #zuul | 12:49 | |
| *** jamesmcarthur has quit IRC | 12:49 | |
| *** jamesmcarthur has joined #zuul | 12:49 | |
| openstackgerrit | Jan Gutter proposed zuul/nodepool master: Add port-cleanup-interval config option https://review.opendev.org/687024 | 13:04 |
| openstackgerrit | Jan Gutter proposed zuul/nodepool master: Add port-cleanup-interval config option https://review.opendev.org/687024 | 13:18 |
| *** brendangalloway has joined #zuul | 13:29 | |
| *** bolg has quit IRC | 13:30 | |
| brendangalloway | Hello - is there a recommended plugin or workflow to integrate gerrit and github? We found https://gerrit.googlesource.com/plugins/github/+/master/README.md, but some of what is referenced in that doc appears to be obsolete | 13:35 |
| fungi | brendangalloway: what sort of integration are you in search of? | 13:37 |
| openstackgerrit | Jan Gutter proposed zuul/nodepool master: Add port-cleanup-interval config option https://review.opendev.org/687024 | 13:38 |
| fungi | zuul is focused more on being able to interact with both and allow changes in each to reference, depend on and be tested with the other | 13:38 |
| fungi | but if you're looking for ways to copy code review back and forth between multiple platforms, that's not zuul's focus | 13:38 |
| brendangalloway | I might be asking in the wrong place then - we are trying to copy code review back and forth | 13:41 |
| fungi | for me at least, being clear and honest about what patch submission and code review workflow a project uses is better for its ecosystem than doing a mediocre job of accepting patches through multiple code review systems... one is always going to be the primary interface, and so people trying to interact via whichever is the second-class entrance are going to have a poor experience as a result | 13:41 |
| brendangalloway | Agreed - but we have some restrictions about what we can allow outside parties to have access to | 13:43 |
| fungi | the data models and workflows for gerrit and github are quite different, their only real commonality being that they use git as a means of managing source code, so any of the solutions i've seen which can copy back and forth between pull requests/changes for things like comments and test results end up being extremely lossy | 13:43 |
| fungi | you'll either wind up infuriating the contributors who are stuck using the secondary interface, or having to make significant compromises on both primary and secondary interface workflows to only use the nearest common subset of features both can reasonably support | 13:45 |
| tristanC | brendangalloway: have you checked https://github.com/golang/go/wiki/GerritBot ? | 13:46 |
| fungi | yeah, taking that one as an example, anyone submitting a patch via github ends up being directed to gerrit to see review comments and iterate on the corresponding change | 13:47 |
| fungi | so likely a poor experience for contributors who only want to use github and would prefer not to learn/touch gerrit | 13:48 |
| brendangalloway | Thanks for the input. I think one interface is better, and easier to manage, but the team I'm trying to set things up for have some weird workflow requirements. Will feed this back to them and see what they say | 13:51 |
| fungi | if you're looking at a fire-and-forget solution for sucking github pull requests into gerrit it's likely fine, but to me that's not a sustainable way to build a contributor community | 13:51 |
| openstackgerrit | Jan Gutter proposed zuul/nodepool master: Add port-cleanup-interval config option https://review.opendev.org/687024 | 13:54 |
| jangutter | apologies for newbie-spamming the same review. | 13:54 |
| fungi | jangutter: if it's any consolation, our veterans spam the same reviews at least as often, maybe even more ;) | 13:56 |
| Shrews | i purposefully try to spam. i like folks to know i'm here | 13:57 |
| jangutter | I'm trying to run the nodepool unit tests locally - would you recommend centos7 or bionic for the baseline? | 13:57 |
| * Shrews throws a can of Spam at fungi | 13:57 | |
| Shrews | jangutter: either should work, in theory | 13:57 |
| Shrews | i use bionic, personally | 13:58 |
| fungi | i suspect bionic may be easier to set up owing to having newer versions of things and more stuff packaged. certainly if you want to also run zuul unit tests, centos 7 is a bit of a pain to get python 3 working on | 13:59 |
| tristanC | jangutter: fedora also works, once you have the tox env (and zookeeper started), you can run a single test using: ./.tox/py35/bin/stestr run "$test_name" | 13:59 |
| tristanC | fungi: well you can now yum install python3 on centos, but you need zookeeper for zuul/nodepool unit tests | 14:00 |
| jangutter | centos7.7's got python3.6 at least, I seem to be having issues with zookeeper I think... | 14:00 |
| Shrews | jangutter: what issues? | 14:01 |
| tristanC | jangutter: you can get zookeeper using "yum install -y https://softwarefactory-project.io/kojifiles/repos/sf-3.3-el7-release/Mash/zookeeper-lite-3.4.10-3.el7.x86_64.rpm" | 14:01 |
| jangutter | I'm running the tests inside a docker container inside macos so there might be a fair amount of weirdness. | 14:01 |
| Shrews | yeah, docker is weird enough on mac that i just use a bionic vm | 14:05 |
| *** jamesmcarthur has quit IRC | 14:08 | |
| *** saneax has quit IRC | 14:08 | |
| *** saneax has joined #zuul | 14:16 | |
| *** themroc has quit IRC | 14:21 | |
| *** saneax has quit IRC | 14:22 | |
| pabelanger | I use fedora-30 local, like tristanC mentions. But bionic also works well | 14:22 |
| pabelanger | centos7.7 is missing some key python3 things still, IMO. But good to see some python3 support | 14:23 |
| tristanC | pabelanger: what is missing? | 14:24 |
| pabelanger | libselinux-python | 14:24 |
| pabelanger | as example | 14:24 |
| *** saneax has joined #zuul | 14:24 | |
| pabelanger | which makes running ansible hard | 14:24 |
| tristanC | it shouldn't prevent running nodepool test though | 14:25 |
| pabelanger | True, was assuming they would also like to do zuul at some point | 14:26 |
| *** jamesmcarthur has joined #zuul | 14:28 | |
| *** jamesmcarthur has quit IRC | 14:34 | |
| *** jamesmcarthur has joined #zuul | 14:38 | |
| *** bhavikdbavishi has joined #zuul | 14:39 | |
| openstackgerrit | Merged zuul/nodepool master: Do not overwrite image upload ZK data on delete https://review.opendev.org/681857 | 14:42 |
| *** jamesmcarthur has quit IRC | 14:43 | |
| *** jamesmcarthur has joined #zuul | 14:43 | |
| *** saneax has quit IRC | 14:52 | |
| Shrews | that was amazingly difficult to get merged | 14:56 |
| *** bhavikdbavishi has quit IRC | 14:59 | |
| *** jamesmcarthur has quit IRC | 15:00 | |
| clarkb | re zk you can also download the upstream tarball and run it out of there if you have a java install | 15:02 |
| *** jamesmcarthur has joined #zuul | 15:08 | |
| *** bhavikdbavishi has joined #zuul | 15:11 | |
| jangutter | tristanC: looks like adding https://softwarefactory-project.io/kojifiles/repos/sf-3.3-el7-release/Mash/wait4service-0.1-1.el7.noarch.rpm and running systemctl start zookeeper was enough, thanks! | 15:14 |
| *** kerby has joined #zuul | 15:19 | |
| *** bhavikdbavishi has quit IRC | 15:20 | |
| jangutter | Heh, and somehow, running the test in my really weird centos7.7+docker combination makes it pass.... | 15:21 |
| *** mattw4 has joined #zuul | 15:27 | |
| openstackgerrit | Kerby proposed zuul/nodepool master: AWS driver: add ability to determine AMI id using filters https://review.opendev.org/683205 | 15:27 |
| openstackgerrit | Luigi Toscano proposed zuul/zuul-jobs master: fetch-subunit-output: collect additional subunits (2nd try) https://review.opendev.org/674334 | 15:38 |
| tosky | let's see if I understood how to write tests for zuul roles... | 15:38 |
| tosky | (probably not yet :) | 15:39 |
| clarkb | jangutter: looks like that one cleanup port test is the one failing. You can run just it via tox -e py36 -- test_leaked_port_cleanup | 15:46 |
| openstackgerrit | Luigi Toscano proposed zuul/zuul-jobs master: fetch-subunit-output: collect additional subunits (2nd try) https://review.opendev.org/674334 | 15:46 |
| *** hashar has quit IRC | 15:52 | |
| *** chandankumar is now known as raukadah | 15:57 | |
| *** bolg has joined #zuul | 16:02 | |
| openstackgerrit | Luigi Toscano proposed zuul/zuul-jobs master: fetch-subunit-output: collect additional subunits (2nd try) https://review.opendev.org/674334 | 16:05 |
| jangutter | clarkb: and the kicker is, if I run it locally it passes..... | 16:06 |
| *** bolg has quit IRC | 16:06 | |
| jangutter | clarkb: however, I'm running it with zookeeper-lite in a docker, so calling the environment "unique" is an understatement. | 16:07 |
| clarkb | jangutter: ya I just ran it locally myself and it failed. Then I added debug logging and it passed. I'm going to run it a few times to see if i can catch a failure with the debug logging | 16:07 |
| clarkb | jangutter: it looks like the cleanup interval in the test isn't actually updating in the provider | 16:09 |
| clarkb | my debug logging shows it as always 600 when the test fails | 16:09 |
| clarkb | its possible that the provider object is being rebuilt after we update the interval? | 16:09 |
| clarkb | previously this was overridden in the manager which doesn't change when config updates | 16:09 |
| jangutter | clarkb: can I update the provider from a different fixture? | 16:10 |
| clarkb | jangutter: you may want to copy the node.yaml config that the test uses today and create a cleanup-port.yaml config and set the interval there | 16:11 |
| clarkb | then it should always load properly avoiding any races in the test | 16:11 |
| clarkb | basically just straight up copy that file then add the interval setting to it and rename the config in the test case to match your new config file | 16:12 |
| jangutter | clarkb: should I run the entire test with the modified fixture (I think there's some checking that the ports still exist that should be zapped in that case) or can I reconfig the provider in the test? | 16:13 |
| clarkb | I think you can run the whole test with the new config since 2 seconds is long enough that the wait loop should cycle a few times | 16:14 |
| clarkb | heh of course I've tested it and I am wrong :) | 16:20 |
| clarkb | those ports get cleaned up before the assertion there are two down ports :( so ya I think we have to start with the default config then switch over to the new config | 16:20 |
| AJaeger | zuul team, any comments on https://review.opendev.org/686932 - this should fix that "recheck" an approved change will go to gate without extra +A (as currently in Zuul tenant). Alternative is https://review.opendev.org/686933 | 16:20 |
| openstackgerrit | Jan Gutter proposed zuul/nodepool master: Add port-cleanup-interval config option https://review.opendev.org/687024 | 16:21 |
| clarkb | or use a longer interval? | 16:22 |
| jangutter | clarkb: I think I tested it with a cleanup time of 2 seconds and the ports got cleaned up too early ... I set it to 5 seconds, and it seems OK.... | 16:22 |
| fungi | would that still be racey? | 16:22 |
| clarkb | fungi: possibly | 16:22 |
| clarkb | I've just checked with 10 second and ya that works | 16:23 |
| clarkb | I'm looking for an example where we update the config mid test and haven't found one yet | 16:23 |
| clarkb | Shrews: ^ is that a simple thing to do? currently useNodepool takes the config file which I'm not sure we can call multiple times to update a pool | 16:23 |
| jangutter | clarkb, fungi: the check for the two down ports can really be zapped in my opinion. There's an assert later for the zookeeper record that checks whether the ports were cleaned. | 16:23 |
| openstackgerrit | Luigi Toscano proposed zuul/zuul-jobs master: fetch-subunit-output: collect additional subunits (2nd try) https://review.opendev.org/674334 | 16:30 |
| Shrews | clarkb: there is a replace_config() or similar call. i forget the name off hand | 16:35 |
| Shrews | jangutter: that's going to be racey to have two checks for down ports and assuming one will happen before the 5 seconds hits | 16:36 |
| jangutter | Shrews: yeah my opinion is that checking for the down ports is covered by the assert later. | 16:37 |
| Shrews | i disagree | 16:39 |
| jangutter | Shrews how so? I need to double-check but in my reading that stat only gets increased if a leaked port gets cleaned. | 16:41 |
| jangutter | Ah, there's another failure mode here that should be tested, checking that the cleanup interval is actually honoured. | 16:42 |
| *** brendangalloway has quit IRC | 16:43 | |
| jangutter | So, in actual fact, the test should check _how many seconds_ it takes before the ports have been cleaned up, then compare that with an error margin to the config setting. | 16:43 |
| Shrews | jangutter: If you want to only depend on the stat, then you have to add some sort of wait until the stat is reported. You aren't fixing anything, only moving the wait to a different place. Removing the DOWN check before that to get your test to pass (even though it may or may not be redundant) is not the correct thing to do. | 16:49 |
| jangutter | Shrews, sorry, I meant there are two checks -> one checks for 2 DOWN ports. The second check waits until all DOWN ports are gone. | 16:50 |
| Shrews | jangutter: i can help look at why it's failing for you in a little bit, if you like. need to lunch now | 16:50 |
| jangutter | Shrews, it's running now, but it looks like I hit some flakiness. | 16:51 |
| jangutter | Shrews, can check with you tomorrow (I'm in GMT+2 timezone) | 16:51 |
| clarkb | jangutter: if you don't mind I can try pushing up a patchset with the config replace in a few minutes (once I find that config replace call) | 16:51 |
| jangutter | clarkb: I absolutely don't mind in the least! | 16:52 |
| jangutter | also general thank you to the channel for indulgences! | 16:53 |
| clarkb | I think replace_config doesn't actually trigger provider updates | 16:54 |
| clarkb | maybe I'm missing a second call I need to make | 16:54 |
| clarkb | If I can sort it out I'll push the new patchset | 16:55 |
| *** bhavikdbavishi has joined #zuul | 16:56 | |
| *** mgoddard has quit IRC | 16:57 | |
| jangutter | Is the nodepool-functional-k8s a bit flakey? | 16:59 |
| clarkb | jangutter: yes I think it has networking problems on some providers | 17:00 |
| jangutter | clarkb: thanks, unlikely that a change in the openstack provider would knock on it, but one never knows. | 17:00 |
| *** mgoddard has joined #zuul | 17:02 | |
| clarkb | something with the config replacement confuses the test fakes state. The log shows the two ports being removed but listPorts shows the ports still remaining | 17:05 |
| *** jamesmcarthur has quit IRC | 17:06 | |
| openstackgerrit | Luigi Toscano proposed zuul/zuul-jobs master: fetch-subunit-output: collect additional subunits (2nd try) https://review.opendev.org/674334 | 17:06 |
| jangutter | clarkb: alternatively, I was thinking of setting the timeout to be in the order of 15 seconds, and check that the ports are deleted between 10 and 20 seconds later. | 17:08 |
| jangutter | clarkb: since reconfig's not necessarily what we want to test here. | 17:10 |
| *** jpena is now known as jpena|off | 17:11 | |
| clarkb | ya, that just makes for a long test case | 17:14 |
| openstackgerrit | Luigi Toscano proposed zuul/zuul-jobs master: fetch-subunit-output: collect additional subunits (2nd try) https://review.opendev.org/674334 | 17:16 |
| openstackgerrit | Gabor Lekeny proposed zuul/zuul master: Decode k8s ServiceAccount bearer token https://review.opendev.org/687107 | 17:17 |
| *** pcaruana has quit IRC | 17:21 | |
| openstackgerrit | James E. Blair proposed zuul/zuul-registry master: WIP implement shadow proxying https://review.opendev.org/687113 | 17:25 |
| openstackgerrit | Luigi Toscano proposed zuul/zuul-jobs master: fetch-subunit-output: collect additional subunits (2nd try) https://review.opendev.org/674334 | 17:26 |
| *** bhavikdbavishi has quit IRC | 17:28 | |
| corvus | tristanC, clarkb, fungi, Shrews: 687113 is a first pass at the buildset registry portion of zuul-registry -- if we do the steps outlined in the commit message on a test node, we can convince docker to talk to our registry instead of dockerhub, and it con provide both local and upstream content (via proxying) | 17:28 |
| corvus | i've tested that with dockerhub, next is to try quay.io, and gcr.io | 17:28 |
| *** bhavikdbavishi has joined #zuul | 17:29 | |
| clarkb | corvus: and we can't convince the docker daemon to talk to localhost instead of dockerhub due to the weird fallback behavior it has? (thinking that might be better than pretending to be dockerhub?) | 17:30 |
| corvus | clarkb: we can do what we do now, which is use registry-mirrors to do that for dockerhub, but registry-mirrors doesn't support other registries; istr there's a PR for that. so the mitm approach is to try to find something that works the same way for multiple upstream registries (at least until that pr merges) | 17:31 |
| *** jamesmcarthur has joined #zuul | 17:31 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-registry master: Add type annotations https://review.opendev.org/686249 | 17:36 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-registry master: Add hypothesis based test for the storage module https://review.opendev.org/687118 | 17:36 |
| corvus | clarkb: alternatively, maybe we could target only containerd based systems -- i think that backend/client does support mirrors for all registries | 17:37 |
| corvus | that merged in april: https://github.com/containers/image/pull/564 | 17:37 |
| corvus | i'm not sure how hard it would be to do that on a bionic system | 17:38 |
| clarkb | skimming that really quickly it seems that skopeo would be the client side of that? | 17:40 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-registry master: Add hypothesis based test for the storage module https://review.opendev.org/687118 | 17:40 |
| corvus | clarkb: here's the pr i was thinking of: https://github.com/moby/moby/pull/34319 | 17:49 |
| corvus | i would not bet money on that ever being merged | 17:50 |
| AJaeger | corvus: oh, that one - text book example of how not to treat a contributor ;( | 17:50 |
| corvus | (note there's some overlap in personnel in those 2 prs) | 17:50 |
| corvus | AJaeger: yeah, it seems to me that they're dragging their feet on it, likely because it's incompatible with their business goals | 17:52 |
| AJaeger | corvus: air-gap installs are a reality. But if large banks etc are not your customers,... | 17:53 |
| fungi | the rumor mill says docker is crumbling anyway, so maybe there will be no business goals to worry about soon | 17:54 |
| corvus | i'd be more than happy to go all in on the containerd route if there was a story for that on debuntu systems -- maybe we just need a newer release of something with https://github.com/containers/image/pull/564 ? i'm having a little trouble keeping track of which parts of "docker" are which on all the different systems | 17:55 |
| AJaeger | corvus: fungi yeah - example https://www.zdnet.com/article/docker-is-in-deep-trouble/ | 17:55 |
| clarkb | jangutter: Shrews ok I understand what is going on with the earlier patchsets. When we set the value to 2 in the test nodepool notices that differs from the on disk config and reloads the config setting it back to 600 :) | 17:56 |
| clarkb | jangutter: Shrews the problem later with updating the config seems to be that we end up with multiple accounting of the down ports and somewhere the test suite gets confused | 17:56 |
| AJaeger | corvus, fungi, clarkb, any comments on https://review.opendev.org/686932 - this should fix that "recheck" an approved change will only go to gate with an extra +A (as currently in Zuul tenant). Alternative is https://review.opendev.org/686933 | 17:57 |
| clarkb | jangutter: Shrews I think that implies we do need to set the value in config to match what we want in the test (either replacing config or starting with that config directly) | 17:57 |
| corvus | AJaeger: i vote for 686933 -- that's how things used to work until clean check came around. i'd rather not have half of clean check | 17:58 |
| *** pcaruana has joined #zuul | 18:00 | |
| fungi | would a hybrid of the two work? if recheck also enqueued into the gate, then in cases where there was no workflow +1 yet it would be dequeued immediately and only the check instance would remain. in cases where there was already a workflow +1 present the instance enqueued into the gate pipeline would supercede the check pipeline instance which would be dequeued instead | 18:00 |
| corvus | fungi: that theory seems sound and would be fine with me. i'm a little curious about how far zuul would get before gate dequeued check (would it go so far as to request nodes?). but even that shouldn't be a significant problem. | 18:02 |
| corvus | though it does mean you can't choose to recheck something with a W+1 without enqueing it into gate | 18:03 |
| fungi | that's a fair point | 18:03 |
| corvus | i'm okay with that too -- i'm more concerned with the other way around :) | 18:03 |
| fungi | well, unless you set your own wip vote on it or something which would prevent gating | 18:03 |
| fungi | the only thing about 686933 which particularly worries me is institutional knowledge, and folks expecting recheck to work for reattempting gate pipeline jobs, similar to how it does in some other tenants | 18:04 |
| corvus | that does not bother me | 18:04 |
| fungi | but it doesn't worry me enough to oppose it, just means additional learning curve for some | 18:05 |
| corvus | some things are worth unlearning | 18:05 |
| fungi | true | 18:05 |
| AJaeger | what about using "recheck" instead of "reverify" in 933? | 18:05 |
| fungi | that's basically what i was talking about, yeah | 18:06 |
| fungi | or letting 933 support both recheck and reverify | 18:06 |
| AJaeger | I'd like some more consistency between the tenants... | 18:06 |
| AJaeger | fungi: or that | 18:06 |
| fungi | as synonyms | 18:06 |
| fungi | this is getting close to bikeshed territory though, so i'm honestly fine with either approach | 18:07 |
| AJaeger | corvus: any objections to use (recheck|reverify) ? | 18:08 |
| corvus | the reason we made multiple tenants is so that we don't have to be consistent between them | 18:11 |
| corvus | one of the main reasons i'm working on opendev is so that zuul's own zuul can have the best configuration for itself. so that people see that the way openstack's zuul is configured is not the only way to use it. | 18:14 |
| corvus | anyway, there are plenty of other things to consider other than consistency. if we want to try the recheck/supercede thing, maybe "recheck|reverify" is the way to go? | 18:15 |
| openstackgerrit | Luigi Toscano proposed zuul/zuul-jobs master: fetch-subunit-output: collect additional subunits (2nd try) https://review.opendev.org/674334 | 18:24 |
| corvus | 18:27 < clarkb> I think that there will be people out there that want to test image builds with docker and zuul should likely support that | 18:29 |
| corvus | sorry for channel switching; there's a blurry opendev/zuul line on this topic | 18:30 |
| corvus | tristanC, clarkb: ^ if we accept that, then i think we're stuck with mitm until https://github.com/moby/moby/pull/34319 merges (which will probably be after docker, inc runs out of money) | 18:30 |
| tristanC | corvus: alright | 18:32 |
| corvus | (well, i can think of one other option, but i don't love it: we could avoid mitm by having one configuration for docker, which is docker-only, and another configuration for non-docker, which lets you use all the registries) | 18:33 |
| corvus | so basically, if you are using the docker runtime, you get speculative dockerhub images and that's it. if you're using non-docker, you get the whole universe. | 18:34 |
| corvus | maybe that's okay? the thing it would not support is a docker build/test job that speculatively depended on a quay.io hosted image. | 18:35 |
| *** bhavikdbavishi has quit IRC | 18:35 | |
| pabelanger | seems like a win to use non docker in that case | 18:37 |
| pabelanger | interesting, looks like podman-compose has an exmaple for awx: https://github.com/containers/podman-compose/blob/devel/examples/awx3/docker-compose.yml | 18:38 |
| tristanC | corvus: so, podman-compose up on zuul quick start is blocked by what seems like an apt question: http://paste.openstack.org/show/781763/ | 18:40 |
| tristanC | corvus: and trying to s/docker/podman/ in zuul tests, i'm not sure what should be done with regards to the use-buildset-registry role | 18:41 |
| mordred | corvus: ooh - I also don't LOVE that one - but I bet the intersection of "must docker the dockers" and "everything is on dockerhub" is pretty high - and people using non-standard registries might also be more likely be more open to considering the use of podman and friends ... and also just saying "if you use the podman toolchain you get these features" is a nice selling point to communicate the greater power | 18:41 |
| mordred | of not being locked in to docker itself | 18:41 |
| clarkb | tristanC: should add a -y | 18:41 |
| corvus | tristanC: i don't understand what command produced that output? | 18:41 |
| clarkb | corvus: I think it is an apt-get install of libssl | 18:42 |
| corvus | clarkb: in a container? | 18:42 |
| clarkb | corvus: ya | 18:42 |
| clarkb | possibly from bindep? | 18:42 |
| tristanC | corvus: this is happening for podman build -t examples_node -f ./node-Dockerfile --build-arg http_proxy --build-arg https_proxy --build-arg no_proxy=,gerrit ./ | 18:42 |
| corvus | why is that different under podman and docker? | 18:42 |
| clarkb | corvus: it might not be different, could just be timing (libssl just updated and test node images haven't caught up or something) | 18:42 |
| pabelanger | maybe need to pass non-interactive mode? | 18:43 |
| tristanC | clarkb: indeed, and node-Dockerfile is not using "-y" to update | 18:43 |
| corvus | tristanC: re use-buildset-registry -- we could adapt it to podman, but i'd prefer that we leave it as-is for now and focus on zuul-registry. in other words, the answer to "how do we get zuul tests that use use-buildset-registry using non-docker" is "finish zuul-registry and the related roles to use it" | 18:44 |
| corvus | tristanC, clarkb: so "podman build" likely handles stdin differently than "docker build" | 18:44 |
| corvus | docker probably handles it in a way that dpkg knows it's non-interactive | 18:45 |
| corvus | i think "-y" would be fine | 18:45 |
| mordred | ++ | 18:45 |
| corvus | mordred: yeah, if we think the bifurcated option "docker & docker vs containers & everything" is reasonable for the majority of zuul users, i could probably go along with that. it does sort of say "these choices are dictated by the runtime you choose. choose wisely." | 18:46 |
| corvus | also it does not involve mitm. | 18:46 |
| mordred | yeah | 18:47 |
| corvus | clarkb: what do you think about that option? | 18:47 |
| clarkb | corvus: I think that is a reasonable compromise | 18:47 |
| mordred | corvus: also - if anyone gets pissed off about the fact that docker doesn't have multi-registry - we can point them at the PR and suggest they go nag someone about it | 18:48 |
| pabelanger | ++ | 18:48 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: quick-start: ensure apt-get update is ran non-interactively https://review.opendev.org/687134 | 18:51 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: Replace docker by podman for quick-start https://review.opendev.org/687135 | 18:51 |
| fungi | or fork moby | 18:52 |
| fungi | whichever is easier ;) | 18:52 |
| openstackgerrit | Andreas Jaeger proposed zuul/project-config master: Make recheck alias reverify in gate https://review.opendev.org/687136 | 18:54 |
| AJaeger | fungi, corvus, mordred, here's followup to 933 ^ | 18:54 |
| corvus | AJaeger: thanks! | 18:55 |
| corvus | okay, i think i'm getting a posittive vibe for using registry mirrors (with the docker vs non-docker limitations) with zuul-registry instead of the mitm approach. i'll look into that a bit more then. given that i'm probably going to have to (at least) test that out with docker, podman, k8s -- this may take a bit. :) | 19:00 |
| openstackgerrit | Tim Burke proposed zuul/zuul-registry master: Rework the stream_blob/stream_object API https://review.opendev.org/686827 | 19:00 |
| openstackgerrit | Clark Boylan proposed zuul/nodepool master: Add port-cleanup-interval config option https://review.opendev.org/687024 | 19:07 |
| clarkb | jangutter: Shrews ^ the while loop I added to the test turned out to be the important thing | 19:07 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-registry master: Add hypothesis based test for the storage module https://review.opendev.org/687118 | 19:12 |
| tristanC | corvus: i'm investigating this hypothesis library for testing ^, there is an extension (hypothesis-auto) that can generates test case for annotated function types. | 19:15 |
| clarkb | tristanC: one question I had looking at that is if the generated arguments (eg given binary()) is deterministic or not | 19:20 |
| clarkb | it might be difficult to reproduce failures locally if the inputs are truly random | 19:20 |
| clarkb | (maybe we have to log all inputs in that case or maybe the lib already does this?) | 19:21 |
| tristanC | clarkb: it tells you when a case failed: Falsifying example: test_upload(self=<tests.test_storage.TestStorageLayer.test_upload id=0x7f1b6493e850>, chunks=b'') | 19:21 |
| clarkb | tristanC: is there an easy way to rerun the test case with that input? I guess edit the test case and remove the decorator and hard set the parameter value | 19:24 |
| fungi | adding support for something like tox does for a fixed hashseed (and recording the seed value on each invocation) would be nice if it doesn't already exist | 19:25 |
| tristanC | clarkb: actually there is an @example annotation you can commit to ensure the failing test are always run, here is the documentation: https://hypothesis.readthedocs.io/en/latest/reproducing.html | 19:26 |
| clarkb | looks like you can set the seed too | 19:27 |
| clarkb | maybe set that to the python hashseed? | 19:27 |
| clarkb | then we can always set that value to reproduce locally | 19:28 |
| fungi | well, there's always the chance that you miss a bug caused by the two seeds being synchronized i guess, but that seems highly implausible | 19:28 |
| *** pcaruana has quit IRC | 19:32 | |
| tristanC | clarkb: hypothesis prints out the seed (i think it's the id= key from the above example). the doc also says that test data shouldn't be considered random as the goal is to generate any valid data | 19:33 |
| openstackgerrit | Clark Boylan proposed zuul/nodepool master: Use real uuids in fake cloud resource IDs https://review.opendev.org/687144 | 19:34 |
| clarkb | tristanC: ya, the problem then is setting it. If however you set it to some seed that is already changing on every python invocation (like the hash seed) then you can simply set that via the python env var to do so | 19:34 |
| clarkb | tristanC: its a small convenience thing | 19:34 |
| clarkb | Shrews: ^ 687144 is a quality of life change to the test suite to try and disambiguite some of the fakes we've got to make understanding logs easier | 19:35 |
| openstackgerrit | Tim Burke proposed zuul/zuul-registry master: Rework the stream_blob/stream_object API https://review.opendev.org/686827 | 19:41 |
| Shrews | clarkb: *nod* I've been toying with changing the entire Fake driver because there are several things about it that annoy me and make testing difficult | 19:45 |
| Shrews | clarkb: currently experimenting with using zk as the backend rather than in-memory structures so that threads can truly share a provider | 19:47 |
| clarkb | Shrews: ya the next thing I was thinking about was makign the resources global to a test so that they could be operated on my many clients with the same view of the world | 19:48 |
| clarkb | but for debugging that change from jangutter simply updating the uuids was enough so starting there | 19:48 |
| openstackgerrit | David Shrewsbury proposed zuul/nodepool master: WIP: experimenting with using ZK for fake driver https://review.opendev.org/687150 | 19:49 |
| Shrews | clarkb: that's what i have atm ^^, if you're curious | 19:50 |
| *** armstrongs has joined #zuul | 19:50 | |
| Shrews | not sure how this is going to turn out yet, though | 19:50 |
| *** armstrongs has quit IRC | 19:59 | |
| openstackgerrit | Merged zuul/zuul-registry master: Rework the stream_blob/stream_object API https://review.opendev.org/686827 | 20:09 |
| *** igordc has joined #zuul | 20:13 | |
| *** jamesmcarthur has quit IRC | 20:19 | |
| *** hashar has joined #zuul | 20:30 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-registry master: Add hypothesis rule based state machine test and fix path issue https://review.opendev.org/687157 | 20:40 |
| clarkb | tristanC: can you see my comments on ^ and its parent? I think we may be zoomed in on ensuring the individual methods do the right thing and avoid doing proper error handling at a higher level | 21:03 |
| clarkb | for example https://review.opendev.org/#/c/687118/3/zuul_registry/storage.py if metadata is None then that is likely an error right? in which case we should return an error? also we should handle that on the write side too | 21:03 |
| tristanC | clarkb: it's probably an error, and perhaps the method that returns Optional value like get_size should raise an exception to prevent getting into such case where we json.loads(None) | 21:15 |
| *** hashar has quit IRC | 21:27 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-registry master: Add hypothesis based test for the storage module https://review.opendev.org/687118 | 21:43 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-registry master: Add hypothesis rule based state machine test and fix path issue https://review.opendev.org/687157 | 21:43 |
| openstackgerrit | Luigi Toscano proposed zuul/zuul-jobs master: fetch-subunit-output: collect additional subunits (2nd try) https://review.opendev.org/674334 | 22:54 |
| *** saneax has joined #zuul | 22:58 | |
| corvus | tristanC: there is something really weird happening when i set up zuul-registry with a local filestorage, and "docker push" an image into it and then "podman pull" the same image out. i can not see what is different about that yet. i'm sure it's something we can fix though -- "podman push" and "podman pull" work as expected. | 22:59 |
| tristanC | corvus: what happen when "podman pull" a "docker push"'ed image? Are they different? | 23:02 |
| corvus | tristanC: i get this error with "podman image list": ERRO[0000] error checking if image is a parent "f32a97de94e13d29835a19851acd6cbc7979d1d50f703725541e44bb89a1ce91": image not known | 23:03 |
| corvus | tristanC: (it's not a permissions issue, which is what a google search for that will turn up) | 23:03 |
| corvus | tristanC: instead, looking at the local container storage, it looks like it has somehow failed to save the image config json | 23:04 |
| openstackgerrit | Luigi Toscano proposed zuul/zuul-jobs master: fetch-subunit-output: collect additional subunits (2nd try) https://review.opendev.org/674334 | 23:04 |
| tristanC | corvus: it might be because podman manage both oci v1 spec and docker.V2S2 format, we would have to compare the manifest and how podman inspect the one created from docker | 23:05 |
| tristanC | corvus: got to go now, i can have a look tomorrow | 23:05 |
| corvus | tristanC, clarkb: but otherwise, i haven't run into any blockers yet -- the approach we talked about earlier is still looking promising. i'll probably need a few more days to work out details. | 23:05 |
| openstackgerrit | Jeremy Stanley proposed zuul/zuul-website master: Link to instructions on vulnerability reporting https://review.opendev.org/685799 | 23:21 |
| openstackgerrit | Luigi Toscano proposed zuul/zuul-jobs master: fetch-subunit-output: collect additional subunits (2nd try) https://review.opendev.org/674334 | 23:31 |
| *** armstrongs has joined #zuul | 23:32 | |
| *** tosky has quit IRC | 23:40 | |
| *** armstrongs has quit IRC | 23:42 | |
| *** mattw4 has quit IRC | 23:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!