*** jamesmcarthur has quit IRC | 00:05 | |
*** cloudnull has quit IRC | 00:05 | |
*** cloudnull has joined #zuul | 00:06 | |
*** jamesmcarthur has joined #zuul | 00:18 | |
*** jamesmcarthur has quit IRC | 00:23 | |
*** jamesmcarthur has joined #zuul | 00:37 | |
*** jamesmcarthur has quit IRC | 00:44 | |
*** tosky has quit IRC | 00:53 | |
*** jamesmcarthur has joined #zuul | 00:57 | |
*** jamesmcarthur has quit IRC | 01:03 | |
*** jamesmcarthur has joined #zuul | 01:04 | |
*** jamesmcarthur has quit IRC | 01:06 | |
*** jamesmcarthur has joined #zuul | 01:06 | |
*** jamesmcarthur has quit IRC | 01:10 | |
*** jamesmcarthur has joined #zuul | 01:20 | |
*** dry has quit IRC | 01:52 | |
*** dry has joined #zuul | 01:54 | |
*** fdegir has quit IRC | 02:58 | |
*** ikhan has quit IRC | 03:08 | |
*** ykarel has joined #zuul | 03:14 | |
corvus | mordred: i think i've just about got the bazel cache situation worked out, as well as adding tests for the gerrit build. so i sent a note to repo-discuss suggesting we go ahead and add a checker and then iteratively improve the existing job. | 03:23 |
---|---|---|
corvus | (all the work is in the latest PS of https://gerrit-review.googlesource.com/c/zuul/jobs/+/297362/ -- i'll split it out into multiple changes when we're ready for real) | 03:24 |
*** jamesmcarthur has quit IRC | 03:33 | |
*** jamesmcarthur has joined #zuul | 03:33 | |
*** jamesmcarthur has quit IRC | 03:38 | |
*** ricolin has joined #zuul | 04:02 | |
*** jamesmcarthur has joined #zuul | 04:03 | |
*** vishalmanchanda has joined #zuul | 04:25 | |
*** saneax has joined #zuul | 04:54 | |
*** evrardjp has quit IRC | 05:33 | |
*** evrardjp has joined #zuul | 05:33 | |
*** jfoufas1 has joined #zuul | 06:51 | |
*** hashar has joined #zuul | 07:09 | |
*** piotrowskim has joined #zuul | 07:10 | |
*** guillaumec has quit IRC | 07:34 | |
*** guillaumec has joined #zuul | 07:34 | |
*** hashar has quit IRC | 07:52 | |
*** hashar has joined #zuul | 07:54 | |
*** jcapitao has joined #zuul | 07:59 | |
*** ykarel_ has joined #zuul | 08:30 | |
*** ykarel has quit IRC | 08:33 | |
*** ykarel_ is now known as ykarel | 08:33 | |
*** dry is now known as msuszko | 08:34 | |
*** rpittau|afk is now known as rpittau | 08:34 | |
*** tosky has joined #zuul | 08:43 | |
*** jpena|off is now known as jpena | 08:58 | |
*** ykarel has quit IRC | 09:23 | |
*** jfoufas1 has quit IRC | 09:24 | |
*** harrymichal has joined #zuul | 09:33 | |
*** harrymichal has quit IRC | 09:35 | |
*** ykarel has joined #zuul | 09:38 | |
*** flaper87 has joined #zuul | 09:43 | |
*** flaper87 has quit IRC | 09:43 | |
*** flaper87 has joined #zuul | 09:46 | |
*** flaper87 has quit IRC | 09:47 | |
*** flaper87 has joined #zuul | 09:49 | |
*** flaper87 has joined #zuul | 09:51 | |
*** flaper87 has quit IRC | 09:52 | |
*** flaper87 has joined #zuul | 09:56 | |
*** flaper87 has quit IRC | 09:57 | |
*** flaper87 has joined #zuul | 09:59 | |
*** flaper87 has quit IRC | 10:00 | |
*** flaper87 has joined #zuul | 10:03 | |
*** flaper87 has quit IRC | 10:04 | |
*** flaper87 has joined #zuul | 10:09 | |
*** flaper87 has quit IRC | 10:14 | |
*** flaper87 has joined #zuul | 10:15 | |
*** jpena has left #zuul | 10:18 | |
*** jpena has joined #zuul | 10:18 | |
*** sshnaidm__ is now known as sshnaidm | 10:22 | |
*** ykarel has quit IRC | 10:36 | |
*** jhesketh has quit IRC | 10:37 | |
*** jhesketh has joined #zuul | 10:37 | |
*** flaper87 has quit IRC | 10:41 | |
*** flaper87 has joined #zuul | 10:41 | |
*** flaper87 has quit IRC | 10:42 | |
*** flaper87 has joined #zuul | 10:42 | |
*** ykarel has joined #zuul | 10:42 | |
*** tosky_ has joined #zuul | 10:53 | |
*** tosky has quit IRC | 10:54 | |
*** tosky_ is now known as tosky | 10:54 | |
*** flaper87 has quit IRC | 11:20 | |
*** flaper87 has joined #zuul | 11:21 | |
openstackgerrit | Sorin Sbârnea proposed zuul/zuul-jobs master: Upgrade ansible-lint to 5.0 https://review.opendev.org/c/zuul/zuul-jobs/+/773245 | 11:40 |
*** ikhan has joined #zuul | 11:50 | |
*** hashar is now known as hasharLunch | 11:59 | |
*** jcapitao is now known as jcapitao_lunch | 12:04 | |
*** rlandy has joined #zuul | 12:28 | |
*** jpena is now known as jpena|lunch | 12:31 | |
*** jcapitao_lunch is now known as jcapitao | 13:06 | |
*** iurygregory_ has joined #zuul | 13:14 | |
*** iurygregory has quit IRC | 13:15 | |
*** tosky has quit IRC | 13:18 | |
*** iurygregory_ is now known as iurygregory | 13:24 | |
*** tosky has joined #zuul | 13:24 | |
*** jpena|lunch is now known as jpena | 13:25 | |
*** sduthil has joined #zuul | 13:32 | |
*** aluria_ is now known as aluria | 13:50 | |
*** ykarel has quit IRC | 13:56 | |
*** hasharLunch is now known as hashar | 14:06 | |
*** newbie2020 has joined #zuul | 14:09 | |
newbie2020 | Hi guys, it looks to me that required-projects defined in a child job does not "override" parent's required-projects definition, but rather that the final list is the superset of all the required-projects lists. Is it true? I vaguely remember having read that somewhere but I cannot find it on the doc (probably it is just me, sorry for that) | 14:11 |
corvus | newbie2020: that's correct | 14:13 |
fungi | we make use of that quite extensively in opendev. some users have general purpose jobs with a bunch of required-projects entries, but then want to extend that with one or more additional entries when they add it to a pipeline or make a minor adjustment as a custom version of that | 14:20 |
fungi | having to restate the original required-projects list ever time you wanted to alter it would become a challenge, to keep synchronized, if you ever needed to change the list from the original job | 14:21 |
fungi | of course that comes as the loss of not being able to make custom alterations which remove some of the entries | 14:22 |
mordred | corvus: the bazel cache patch looks great! | 14:23 |
newbie2020 | thanks fungi for explaining the rationale behind it! | 14:27 |
*** tosky has quit IRC | 14:29 | |
*** tosky has joined #zuul | 14:33 | |
mordred | corvus: left a couple of comments - including one that's really just from luca | 14:59 |
corvus | mordred: super weird, i don't see a msg from luca | 15:06 |
*** tosky has quit IRC | 15:15 | |
*** tosky has joined #zuul | 15:15 | |
*** tosky_ has joined #zuul | 15:18 | |
*** tosky is now known as Guest43629 | 15:19 | |
*** tosky_ is now known as tosky | 15:19 | |
*** Guest43629 has quit IRC | 15:21 | |
*** newbie2020 has quit IRC | 15:26 | |
mordred | On the mailing list | 15:49 |
corvus | mordred: i just now got a message from him | 16:01 |
corvus | but i don't see anything relating to the comment you left :/ weird | 16:01 |
clarkb | corvus: are we still on track to make releases today? /me is catcing up on email and don't see any zuul complaints from the weekend | 16:18 |
corvus | clarkb: yes, i'm prparing for that now. | 16:20 |
mordred | corvus: OH - duh. it was from davido | 16:21 |
corvus | oooh ok yeah i saw that one :) | 16:21 |
clarkb | corvus: cool, let me know if I can help | 16:23 |
openstackgerrit | Helena Spease proposed zuul/zuul master: Errors from patch 3 added. https://review.opendev.org/c/zuul/zuul/+/769404 | 16:34 |
*** vishalmanchanda has quit IRC | 16:34 | |
clarkb | david o mentions checks plugin vs checks ui. Anyone know if the checks ui setup is documetned somewhere? Googling it seems to only return results for the checks plugin | 16:36 |
corvus | i thought the stuff was happening in the checks plugin | 16:36 |
clarkb | ah | 16:37 |
*** jcapitao has quit IRC | 16:53 | |
corvus | commit 4c5fa46540e07dfad1d62f069f8e44aa5a330660 (HEAD -> master, tag: 4.0.0, origin/master, gerrit/master, refs/changes/86/776286/15) | 17:09 |
corvus | commit 24405c9c745fe8de14106ef9b53b7ad6de871b09 (HEAD, tag: 4.0.0, refs/changes/49/776249/1) | 17:10 |
corvus | zuul-maint: ^ do those look right? | 17:10 |
corvus | (that's one commit behind master on zuul, but it's just the no-op dockerfile change) | 17:10 |
fungi | lookin' | 17:10 |
clarkb | corvus: the nodepool sha looks correct based on the git log but isn't what you logged on friday for our restart (however the restart on friday should've been for 4c5fa46540e07dfad1d62f069f8e44aa5a330660) | 17:13 |
clarkb | other than that they lgtm | 17:13 |
corvus | clarkb: i agree, it looks like i logged the previous patchset of that; i must have had a dirty tree | 17:13 |
fungi | i agree those commit ids match what i expect | 17:13 |
corvus | clarkb: it's a lot harder to figure out what sha to log with containers | 17:13 |
*** piotrowskim has quit IRC | 17:15 | |
tobiash | corvus: tags lgtm | 17:19 |
*** fbo is now known as fbo|off | 17:23 | |
openstackgerrit | Albin Vass proposed zuul/zuul master: Replace reset_repo_to_head(repo) with GitPython. https://review.opendev.org/c/zuul/zuul/+/775499 | 17:26 |
*** sgw has left #zuul | 17:26 | |
tristanC | corvus: +1 | 17:27 |
openstackgerrit | James E. Blair proposed zuul/zuul master: Use ZooKeeperClient.fromConfig in tests https://review.opendev.org/c/zuul/zuul/+/776838 | 17:30 |
corvus | felixedel: regarding that ^ are you working on a change to switch the test jobs to use tls, or do you want me to? | 17:35 |
corvus | tags pushed | 17:36 |
clarkb | and now we wait for zuul to release itself | 17:37 |
fungi | zuul is actually an ouroboros | 17:41 |
*** tjgresha has joined #zuul | 17:43 | |
avass | with a HA schedulers it might also be able to upgrade itself as well :) | 17:43 |
corvus | avass: i would say that's a near certainty for opendev at least :) | 17:44 |
*** rpittau is now known as rpittau|afk | 17:49 | |
fungi | i'm looking forward to eventually not having to interrupt and reenqueue in-progress builds once v5 arrives | 17:50 |
fungi | a scheduler restart probably costs us around 750-1000 node-hours at peak utilization these days | 17:51 |
clarkb | possibly even more because you lose the results of compelted jobs too (not jsut those that were in progress) | 17:54 |
*** jpena is now known as jpena|off | 17:55 | |
clarkb | zuul appears to be all done now. Pypi and docker hub have the release artifacts. nodepool is stillin progress ( the arm64 cross compile isn't quick() | 18:04 |
fungi | yeah, .75-1k was a conservative estimate | 18:06 |
*** jfoufas1 has joined #zuul | 18:07 | |
*** hashar has quit IRC | 18:07 | |
*** hamalq has joined #zuul | 18:10 | |
*** jfoufas1 has quit IRC | 18:19 | |
openstackgerrit | Oleksandr Kozachenko proposed zuul/zuul-jobs master: Revert "Revert "Update upload-logs roles to support endpoint override"" https://review.opendev.org/c/zuul/zuul-jobs/+/776677 | 18:22 |
Open10K8S | corvus: I made a PS on https://review.opendev.org/c/zuul/zuul-jobs/+/776677 but I don't think I am so clear on your comments | 18:31 |
Open10K8S | So the problem is opendev's "quick-download" link as I understood, but what is quick-download? :) | 18:32 |
Open10K8S | Seems likely I never experienced this | 18:32 |
Open10K8S | is there any chance to explain a little more plz? thank you | 18:33 |
fungi | Open10K8S: it's an example of a consumer of the current url parameter. visit a build result's artifacts like https://zuul.opendev.org/t/openstack/build/ddfd844504ff44ee89990f24bd234933/artifacts and you'll see a link to a script which downloads all logs for that build | 18:34 |
fungi | it relies on the url parameter for that currently | 18:35 |
fungi | it could in theory be spliced together with bits from other variables | 18:35 |
*** jamesmcarthur has quit IRC | 18:35 | |
fungi | i'm not keen on the fact that it encourages people to pipe random scripts from the internet straight to their shell, but the suggestion to have a special log downloading client was deemed too heavyweight for most users | 18:37 |
Open10K8S | aha, I see | 18:38 |
Open10K8S | fungi: then how does that url come to the zuul ui? | 18:39 |
fungi | Open10K8S: the artifact is registered here, for reference: https://opendev.org/opendev/base-jobs/src/branch/master/playbooks/base/post-logs.yaml#L29-L39 | 18:39 |
fungi | so it's being resolved by ansible | 18:39 |
*** tjgresha has quit IRC | 18:39 | |
Open10K8S | hmm... so if we want remove url attribute from upload-log jobs, we need to change all other jobs which are using .url. and even though, we replace all jobs in zuul-jobs repo, maybe users are using it in their own jobs so need to announce it. is this right? | 18:41 |
fungi | yes | 18:41 |
fungi | that's basically it | 18:41 |
fungi | so for example we can keep the url parameter as a legacy value and mark it deprecated, then announce publicly that we'll be removing it at a later date, and encourage users to switch to the new vars | 18:42 |
Open10K8S | sounds reasonable surely. And how about this step? 2) Define a new cacheable fact "zuul_upload_logs_results" which contains url, endpoint, path. Document it in the readme. | 18:43 |
Open10K8S | I think I am not sure about this new fact's purpose | 18:43 |
avass | Open10K8S: mostly to document the behaviour since opendev was using undocumented output variables, as well as making sure they persist across playbooks with cacheable: true | 18:45 |
fungi | Open10K8S: the argument for adding the zuul_upload_logs_results fact is that it can be used by subsequent playbooks which need to know the url where logs are being made available | 18:46 |
fungi | if that's in a zuul variable supplied to ansible for those playbooks, then i suppose it could also work? | 18:47 |
fungi | cacheable facts are simply the primary mechanism i think we've used to communicate values between different playbooks | 18:48 |
corvus | upload-docker-image timed out (?) for nodepool | 18:53 |
corvus | https://zuul.opendev.org/t/zuul/build/ca898dd7dc554cf5b0be90afbaff1957/log/job-output.txt#5854 | 18:55 |
fungi | huh | 18:55 |
corvus | that appears to be during the build phase? | 18:55 |
corvus | on arm64 | 18:55 |
fungi | looks like it was in the middle of pip install? | 18:56 |
fungi | maybe compiling some things from sdist and took too long? | 18:56 |
fungi | yeah, looks like that was the run phase timeout from zuul mere seconds after output was streamed to the console, so the node could have simply been struggling and the build going much slower | 18:58 |
corvus | yeah, that requirement took almost 5 minutes in the previous run: https://zuul.opendev.org/t/zuul/build/50504dba533a4f04aaa15a25f4d637a6/log/job-output.txt#6064 | 18:59 |
fungi | a similar step earlier took almost 7 minutes https://zuul.opendev.org/t/zuul/build/ca898dd7dc554cf5b0be90afbaff1957/log/job-output.txt#5520 | 18:59 |
corvus | seems like cross-compiling image builds just take ~1 hour | 18:59 |
corvus | fungi: what will happen if we run the pypi upload job again? | 19:00 |
corvus | (it succeeded) | 19:00 |
mordred | corvus: zomg https://gerrit-review.googlesource.com/c/zuul/jobs/+/297442 passed | 19:00 |
fungi | it will break because pypi will reject an attempt to upload a file which alreay exists | 19:01 |
corvus | mordred: \o/ any speedup? (btw, now that that's there, we might be able to use multiprocessing to speed up more) | 19:01 |
fungi | we could in theory make the pypi upload role smarter and do a lbyl, i suppose | 19:01 |
corvus | fungi: that's fine -- as long as it isn't going to mess up pypi. | 19:02 |
mordred | corvus: test-gerrit-setup took 3min 8sec | 19:02 |
corvus | mordred: this is when avass's change to print playbook times would be handy | 19:03 |
avass | :) | 19:03 |
corvus | fungi: so i'll re-enqueue the ref. pypi will harmlessly fail and docker will hopefully succeed. in an hour we'll know. | 19:03 |
corvus | fungi: sound right? | 19:03 |
avass | my change only added plays however, playbooks aren't recorded at the moment | 19:03 |
fungi | corvus: yeah, that seems fine | 19:03 |
mordred | corvus: yah - although previous successful runs of that seem to be in the 7-9 minute mark | 19:04 |
fungi | corvus: since they're separate jobs and not dependent, it'll be fine | 19:04 |
corvus | mordred: that sounds like a speedup! | 19:04 |
corvus | zuul enqueue-ref --tenant zuul --trigger gerrit --pipeline release --project zuul/nodepool --ref refs/tags/4.0.0 --newrev e983422fabd34e21143057700ce434a874b5930c | 19:04 |
*** saneax has quit IRC | 19:04 | |
corvus | look right? | 19:04 |
fungi | lgtm, that seems to be the correct id for the tag | 19:05 |
corvus | (i copied the sha from inventory.yaml and it also looks like it matches 'git show-ref 4.0.0.') | 19:05 |
corvus | done | 19:05 |
fungi | corvus: i've been using the script in https://review.opendev.org/613676 to similar ends for reenqueuing failed releases for openstack, maybe something like that could make sense to implement as part of zuul-client | 19:06 |
fungi | basically parse the inventory, call enqueue or enqueue-ref with the parameters therein | 19:07 |
openstackgerrit | James E. Blair proposed zuul/nodepool master: Increase timeout of docker release job https://review.opendev.org/c/zuul/nodepool/+/776986 | 19:07 |
corvus | fungi: sounds good | 19:07 |
corvus | zuul-maint: ^ let's go ahead and merge that so we're ready next time. | 19:08 |
corvus | mordred: i'm running with "--test_tag_filters=-flaky,-elastic,-git-protocol-v2" and it's not looking good; lots of tests timing out :/ | 19:09 |
mordred | :( | 19:09 |
*** jamesmcarthur has joined #zuul | 19:12 | |
mordred | corvus: so, 'passed' might have been a bit misleading | 19:19 |
mordred | corvus: https://ci.gerritcodereview.com/t/gerrit/build/35cf5e26276f4542a77cfd2bff08094c/console#1/0/20/testnode | 19:19 |
Open10K8S | fungi: avass | 19:21 |
Open10K8S | thank you | 19:21 |
openstackgerrit | Oleksandr Kozachenko proposed zuul/zuul-jobs master: Revert "Revert "Update upload-logs roles to support endpoint override"" https://review.opendev.org/c/zuul/zuul-jobs/+/776677 | 19:21 |
corvus | mordred: oof, i also found this old change where i was doing a bunch of stuff to try to get the tests to pass, including running on a huge node: https://gerrit-review.googlesource.com/c/zuul/jobs/+/260275 | 19:22 |
corvus | mordred: how does this look? https://etherpad.opendev.org/p/1BRSLMfR7rc2frbMz9S2 | 19:28 |
*** jamesmcarthur_ has joined #zuul | 19:30 | |
corvus | mordred: i'm kind of at a point of wondering whether it's worth moving on to try to get the tests running (if they timed out after an hour on a large node last year....) or just stop where we are and try to get rbe to work, since it seems the replies pretty much continually mention rbe. | 19:31 |
*** jamesmcarthur has quit IRC | 19:33 | |
*** jamesmcarthur_ has quit IRC | 19:34 | |
mordred | corvus: yeah... maybe figuring our RBE is somehow better? | 19:37 |
corvus | mordred: 2 things: 1 the bazel build with my cache was faster (3m) than luca's (4m). (weird? maybe an old cache? or probably a different environment causing more cache misses based on environmental inputs) | 20:52 |
corvus | mordred: 2 -- i ran a build on a 60G node and it finished, but still failed. the test portion of the build took 37 minutes. | 20:53 |
corvus | i given that it failed and there were a bunch of timed out tests, i don't know if that represents a minimum run time or not. maybe passing tests run faster. | 20:54 |
mordred | corvus: and enabling luca's cache didn't fix the test timeouts | 20:56 |
corvus | apparently not | 20:56 |
corvus | mordred: i updated https://etherpad.opendev.org/p/1BRSLMfR7rc2frbMz9S2 slightly; i think i'm inclined to send that now; what do you think? | 20:59 |
openstackgerrit | Merged zuul/nodepool master: Increase timeout of docker release job https://review.opendev.org/c/zuul/nodepool/+/776986 | 21:00 |
corvus | second timeout on nodepool 4.0.0 docker build job | 21:11 |
corvus | re-re-enqueued | 21:11 |
clarkb | this time it should run with the longer timeout at least | 21:13 |
corvus | yep | 21:14 |
mordred | corvus: yeah - I think that looks good | 21:36 |
corvus | sent | 21:40 |
clarkb | what is RBE? | 21:54 |
corvus | clarkb: bazel remote execution build farm thingy | 21:55 |
clarkb | oh interesting | 21:55 |
corvus | it's self-hostable, or google runs one; gerrit would likely use the google hosted instance. main issue with zuul is credentials, but there may be a possible solution with application default credentials and service account. | 21:56 |
clarkb | is that the sort of thing that might make sense as a nodepool tie in? | 21:59 |
mordred | not really | 21:59 |
clarkb | nodepool provisions some portion of the build farm (maybe that doesn't even make sense) | 21:59 |
corvus | i think in rbe the build farm is expected to be long-lived | 21:59 |
mordred | the rbe is designed to be an existing long-running thing because it incorporates caching and shares build resources across different build jobs | 21:59 |
corvus | and also not exclusive, so i don't think nodepool would need to mediate access (like static nodes) | 21:59 |
clarkb | ya and ansible probably doesn't have an rbe driver to talk to anything that would be provisioned | 22:00 |
corvus | i could see maybe using nodepool to make some kind of limited credential so it could be given to an untrusted job and if it were exposed damage would be limited | 22:00 |
clarkb | but ya something like ^ was what I had in mind | 22:00 |
clarkb | since nodepool is our currently "give me resources in a secure manner" tool | 22:01 |
corvus | but i'd rather have a system where you can't expose the credential in the first place, not one where damage is limited to 1 hour blocks or something. | 22:01 |
mordred | ++ | 22:01 |
corvus | tristanC: i just noticed that if you have a .kube/config file, the openshiftpods driver will try to refresh a token for it, even if nodepool isn't using any k8s drivers at all. (in other words, i left a .kube/config file with a google credential sitting around, started up nodepool-launcher with a config file only for azure, and it failed to start because it tried to load application default creds); we may | 22:42 |
corvus | want to revisit the driver initialization there. | 22:42 |
corvus | (this probably isn't going to affect many people in production, unless they change clouds) | 22:43 |
tristanC | corvus: do you still have the stacktrace? | 22:49 |
corvus | tristanC: yes! http://paste.openstack.org/show/802901/ | 22:52 |
tristanC | i see, let me add an except handler | 22:56 |
corvus | tristanC: do you think we could avoid calling it in the first place? | 22:56 |
corvus | because it's still trying to obtain tokens, etc | 22:57 |
corvus | i think an exception handler would be a step backwards -- if the user doesn't intend to use it, then they're paying an unecessary startup cost. and if they do intend to use it, then it's better for nodepool to break on startup | 22:58 |
*** ikhan has quit IRC | 23:02 | |
tristanC | well we can also lazy load the client | 23:06 |
corvus | that might be a good stopgap | 23:08 |
corvus | zomg the docker upload ran this time. it took 58 mins. :) | 23:12 |
corvus | i think that means that we finally managed to release 4.0 | 23:12 |
corvus | i will work on release announcements now | 23:12 |
fungi | yeesh, just barely scraped through under the timeout | 23:13 |
corvus | the timeout should be higher now, thigh we didn't end up verifying that :) | 23:13 |
fungi | er, yeah, the old timeout | 23:14 |
tristanC | corvus: hmm, this is happening on Driver.reset(), not sure how to indicate a driver is not used and should not be reset | 23:18 |
openstackgerrit | Tristan Cacqueray proposed zuul/nodepool master: kubernetes: refactor client creation to utils_k8s https://review.opendev.org/c/zuul/nodepool/+/777022 | 23:26 |
openstackgerrit | Tristan Cacqueray proposed zuul/nodepool master: drivers: only reset drivers that have been active https://review.opendev.org/c/zuul/nodepool/+/777024 | 23:47 |
tristanC | corvus: not super fan of this solution, but that might work ^ | 23:47 |
openstackgerrit | Tristan Cacqueray proposed zuul/nodepool master: drivers: only reset drivers that have been active https://review.opendev.org/c/zuul/nodepool/+/777024 | 23:48 |
clarkb | tristanC: that code doesn't seem to check if they are active though? it is doing the accounting but then not taking action on it? | 23:59 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!