| @jim:acmegating.com | tristanCtobiash i'd appreciate it if you have a chance to check out the approach in https://review.opendev.org/821137 | 00:02 |
|---|---|---|
| @clarkb:matrix.org | corvus: the terminology in the commit message is a bit confusing. Probably correct but still confusing. Zuul runs a server that serves prometheus metrics that a prometheus server (service) polls. | 00:19 |
| @clarkb:matrix.org | I'm not sure yet where the client lives | 00:19 |
| @clarkb:matrix.org | is that the thing doing the polling? | 00:19 |
| @clarkb:matrix.org | corvus: why move the setup from the cmd/ level into the underlying classes? That means that everytime we create a new underlying class we'll get another prometheus port (which might conflict and fail?) | 00:26 |
| -@gerrit:opendev.org- Ade Lee proposed on behalf of Jiri Podivin: [zuul/zuul-jobs] 807031: DNM enable_fips role for zuul jobs https://review.opendev.org/c/zuul/zuul-jobs/+/807031 | 00:29 | |
| @clarkb:matrix.org | corvus: the general approach makes sense to me. I think my biggest question is the refactor from starting in the cmd class level to the underlying class and whether or not that has singleton implications or other considerations for using those classes now | 00:31 |
| @jim:acmegating.com | > <@clarkb:matrix.org> corvus: the terminology in the commit message is a bit confusing. Probably correct but still confusing. Zuul runs a server that serves prometheus metrics that a prometheus server (service) polls. | 00:35 |
| Yes, the python package called "prometheus-client" which we import as "prometheus_client" is an implementation of an http server. i have no idea why they called it that but i didn't name it, it's not my fault! :) | ||
| @jim:acmegating.com | > <@clarkb:matrix.org> corvus: why move the setup from the cmd/ level into the underlying classes? That means that everytime we create a new underlying class we'll get another prometheus port (which might conflict and fail?) | 00:36 |
| so that we can pass in the component_info which is inside each component. | ||
| @jim:acmegating.com | > <@clarkb:matrix.org> corvus: the general approach makes sense to me. I think my biggest question is the refactor from starting in the cmd class level to the underlying class and whether or not that has singleton implications or other considerations for using those classes now | 00:38 |
| i don't think we ever run more than one component within a single python process (except in the case where we run multiple schedulers in unit tests; but i also removed the implicit creation of the prometheus client in unit tests to be explicit, so that's not going to happen unless we explicitly do it) | ||
| @jim:acmegating.com | my best guess on the server/client thing is that "prometheus server" means the actual prometheus process that stores data and answers queries. and they needed to name this something other than that. why they chose "client" instead of "metrics server" or "endpoint service" or something else... <shrug> | 00:41 |
| @jim:acmegating.com | so the prometheus server polls our prometheus client (which is an http server) | 00:44 |
| @clarkb:matrix.org | corvus: ya the terminology isn't your fault it just ends up being confusing. Re the singleton thing is that true for the merger and executors? we run btoh classes in a single process don't we? | 00:57 |
| @clarkb:matrix.org | otherwise for the scheduler, web, etc I think that is fine | 00:57 |
| @jim:acmegating.com | Clark: i think the executor server is-a merger server | 00:59 |
| @jim:acmegating.com | actually | 01:00 |
| @jim:acmegating.com | it's BaseMergeServer->MergeServer and BaseMergerServer->ExecutorServer | 01:01 |
| @clarkb:matrix.org | it is but the way you've set up the classe are separate | 01:01 |
| @clarkb:matrix.org | ya | 01:01 |
| @clarkb:matrix.org | and they both want to start that httpd which will cause problems with the listen port I think | 01:01 |
| @clarkb:matrix.org | unless the merger srver run by the executor is different? | 01:02 |
| @jim:acmegating.com | i added the prom client to MergeServer and ExecutorServer | 01:02 |
| @jim:acmegating.com | so i don't think there's a conflict | 01:02 |
| @clarkb:matrix.org | I guess the merger stuff the executor does is in the basemergerserver | 01:03 |
| @clarkb:matrix.org | so we avoid conflict? | 01:03 |
| @jim:acmegating.com | a MergeServer ~= a zuul-merger process; and an ExecutorServer ~= a zuul-executor process. and they share a base class for some shared functionality. | 01:03 |
| @jim:acmegating.com | but those classes are designed to be the main process. the cmd stuff is meant to be minimal bootstrapping to start them. | 01:03 |
| @jim:acmegating.com | (and keeping that minimal means better coverage in unit tests, since anything in cmd is effectively not tested) | 01:04 |
| @clarkb:matrix.org | ya I guess the bulk of the testing there is via quickstart | 01:05 |
| @clarkb:matrix.org | ok this all makes sense in my head. Let me reskim it to make sure I didn't miss anything and I can stmap a +2 | 01:05 |
| @jim:acmegating.com | Clark: also, an easy way to double check that i got it right is that the monitoring server always comes right after the component info. if we got component info wrong, then all our executors would show up as mergers in the component list too. :) | 01:06 |
| @jim:acmegating.com | every day around this time i start to wish patternfly had a dark theme | 01:08 |
| @clarkb:matrix.org | corvus: one minor thing I notice on a reskim is that we stop the monitoring server last when stopping a component. This is that we'll serve the change of state briefly? | 01:09 |
| @clarkb:matrix.org | or at least that is possible whereas stopping it first would make it impossible | 01:09 |
| @jim:acmegating.com | Clark: yeah, i thought that keeping it running as long as possible was the best thing for a monitoring service... the current behavior is that it only terminates when the process does (because of daemon threads), but since it's in the components now, we at least need it to stop for the unit tests. | 01:11 |
| @jim:acmegating.com | and that's where the readiness check is useful too -- it will start failing as soon as we set the component state to `stopped`, so that's good. | 01:11 |
| @clarkb:matrix.org | ok +2'd | 01:12 |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 819557: Report total duration when a build set is finished https://review.opendev.org/c/zuul/zuul/+/819557 | 02:12 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: | 02:33 | |
| - [zuul/nodepool] 814226: Add shell-type to Azure driver https://review.opendev.org/c/zuul/nodepool/+/814226 | ||
| - [zuul/nodepool] 814204: Correct host_key setting in statemachine driver https://review.opendev.org/c/zuul/nodepool/+/814204 | ||
| - [zuul/nodepool] 814503: Add user-data/custom-data to Azure driver https://review.opendev.org/c/zuul/nodepool/+/814503 | ||
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/nodepool] 814643: Add missing schema entries for Azure driver https://review.opendev.org/c/zuul/nodepool/+/814643 | 02:41 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 819557: Report total duration when a build set is finished https://review.opendev.org/c/zuul/zuul/+/819557 | 03:31 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 819557: Report total duration when a build set is finished https://review.opendev.org/c/zuul/zuul/+/819557 | 04:24 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 819557: Report total duration when a build set is finished https://review.opendev.org/c/zuul/zuul/+/819557 | 05:03 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 821157: Report overall duration when a build set is finished https://review.opendev.org/c/zuul/zuul/+/821157 | 05:45 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 819557: Report overall duration when a build set is finished https://review.opendev.org/c/zuul/zuul/+/819557 | 05:46 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 819557: Report overall duration when a build set is finished https://review.opendev.org/c/zuul/zuul/+/819557 | 05:50 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 819557: Report overall duration when a build set is finished https://review.opendev.org/c/zuul/zuul/+/819557 | 05:51 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 821159: test build https://review.opendev.org/c/zuul/zuul/+/821159 | 06:25 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 819557: Report overall duration when a build set is finished https://review.opendev.org/c/zuul/zuul/+/819557 | 07:50 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 807464: Add metastatic driver https://review.opendev.org/c/zuul/nodepool/+/807464 | 15:33 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 821137: Add readiness/liveness probes to prometheus server https://review.opendev.org/c/zuul/zuul/+/821137 | 15:37 | |
| @tristanc_:matrix.org | corvus: thanks, that looks great! | 15:39 |
| @tristanc_:matrix.org | Clark: about the zuul-jobs third party ci with ubi8, i'm not sure what is going with the container image, it seems like ansible_user_dir is resolving as `/~zuul/`, thus I removed the jobs for now. | 15:40 |
| @clarkb:matrix.org | Like the ~ isn't getting expanded? Did the shell change to something that won't expand it? | 16:04 |
| @avass:vassast.org | Clark: i think Ansible is normally expanding '~' in the command module even when there is no shell. | 16:12 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 821137: Add readiness/liveness probes to prometheus server https://review.opendev.org/c/zuul/zuul/+/821137 | 17:01 | |
| -@gerrit:opendev.org- Sorin Sbârnea proposed: [zuul/zuul-jobs] 821247: Add tox-py310 job https://review.opendev.org/c/zuul/zuul-jobs/+/821247 | 17:20 | |
| @ssbarnea:matrix.org | hi! Can someone share the status of py310 on zuul (zuul-jobs)? I found `tox-py310` as missing. | 17:24 |
| @clarkb:matrix.org | Zuul itself is held back by the gearman pin. Once gearman is removed from zuul (should be soon, the changes are up and we are close) then Zuul can bump up its python versions | 17:27 |
| @ssbarnea:matrix.org | for some readon zuul reports fedora-35 nodeset as missing. | 17:27 |
| @clarkb:matrix.org | there is no fedora-35 nodeset. Labels != nodeset. This has tripped up a number of people lately. I wonder if we should haev implicit nodesets for each label if not otherwise defined | 17:27 |
| @ssbarnea:matrix.org | maybe i was not clear but my interest was about having a tox-py310 job for others to use, not related to zuul itself. | 17:27 |
| @ssbarnea:matrix.org | that would be a smart move! | 17:28 |
| @ssbarnea:matrix.org | most common use case is to want a single node, so it would make the user experience better. | 17:28 |
| -@gerrit:opendev.org- Sorin Sbârnea proposed: [zuul/zuul-jobs] 821247: Add tox-py310 job https://review.opendev.org/c/zuul/zuul-jobs/+/821247 | 17:29 | |
| @ssbarnea:matrix.org | haha, i did not see that there was a generic `fedora-latest-1vcpu` pointing to 35, i will use that. | 17:29 |
| -@gerrit:opendev.org- Sorin Sbârnea proposed: [zuul/zuul-jobs] 821247: Add tox-py310 job https://review.opendev.org/c/zuul/zuul-jobs/+/821247 | 17:31 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/nodepool] 814644: Azure: correct default tags value for VMs https://review.opendev.org/c/zuul/nodepool/+/814644 | 17:34 | |
| @clarkb:matrix.org | ya I'm not sure how difficult it would be to implement that in Zuul but if a nodeset is requested and doesn't exist but a label with the same name exists we could create a single node nodeset with that label and probably simplify things for people | 17:35 |
| -@gerrit:opendev.org- Sorin Sbârnea proposed: [zuul/zuul-jobs] 821247: Add tox-py310 job https://review.opendev.org/c/zuul/zuul-jobs/+/821247 | 17:35 | |
| @ssbarnea:matrix.org | Clark: apparently zuul does not want to spawn the fedora node. I see it as queued but none listed at https://zuul.opendev.org/t/zuul/nodes | 17:48 |
| @clarkb:matrix.org | They won't show up on the nodes page until a launcher has accepted the request and is processing it | 17:49 |
| @ssbarnea:matrix.org | Have a look at https://review.opendev.org/c/zuul/zuul-jobs/+/821247 -- i hope that once it passed it will be accepted. | 17:51 |
| @tristanc_:matrix.org | Shouldn't the python version be a parameter of a single tox job? | 18:01 |
| @jim:acmegating.com | tristanC: having separate jobs makes it easy for projects to run multiple versions. since you can't run the same job twice in zuul, nova would need "nova-tox-py37" and "nova-tox-py38" regardless. defining them centrally means they don't have to do that and everyone can just use tox-py37 and tox-py38. | 18:03 |
| @jim:acmegating.com | the implementation of tox-py38 should be (and is) very simple though: it just sets that value for the main tox job. | 18:03 |
| @tristanc_:matrix.org | corvus: I see, though it seems like the other languages (e.g. js-build or golang-go) do not specify their version. | 18:09 |
| @jim:acmegating.com | tristanC: to be clear, there is a plain "tox" job that does not specify the version, and tox-py38 is just a thin layer on that. if users typically want to test their programs with multiple versions of a compiler or runtime, then it would be entirely appropriate to add eg, golang-go-17 to zuul-jobs too. | 18:13 |
| @ssbarnea:matrix.org | also keep in mind that is very unlikely to have the full range of python version available on a single operating system, so having specific jobs makes is easy for average user to test with multiple versions. | 18:35 |
| @ssbarnea:matrix.org | i think that python is one of those cases where we want differnt jobs for each version, for other languages is makes more sense to just have a parameter. | 18:35 |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 821275: Add an upgrade release note for delete-state https://review.opendev.org/c/zuul/zuul/+/821275 | 18:35 | |
| @clarkb:matrix.org | corvus: ^ I'm not sure that all of the versions specified in that change are accurate. Feel free to update as necessary or let me know what the actual versions are and I'll fix it | 18:36 |
| @clarkb:matrix.org | now to review the docs change | 18:36 |
| -@gerrit:opendev.org- Sorin Sbârnea proposed: [zuul/zuul-jobs] 821247: Add tox-py310 job https://review.opendev.org/c/zuul/zuul-jobs/+/821247 | 18:39 | |
| @jim:acmegating.com | Clark: we added delete-state in 4.9... but i'm almost inclined to just say "prior versions". we haven't done the investigation to find out when we added the earliest thing we changed | 18:39 |
| @jim:acmegating.com | if we want to put a lower bound, i'd suggest it be the first release that wrote something to /zuul | 18:40 |
| @jim:acmegating.com | but honestly, i like "prior versions" the best :) | 18:40 |
| @clarkb:matrix.org | That works. Basically asy if you are upgrading from any version run the command | 18:41 |
| @clarkb:matrix.org | I'll update shortly | 18:41 |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 821275: Add an upgrade release note for delete-state https://review.opendev.org/c/zuul/zuul/+/821275 | 18:44 | |
| @clarkb:matrix.org | Hopefully that is better | 18:45 |
| @clarkb:matrix.org | corvus: comment on https://review.opendev.org/c/zuul/zuul/+/820593 | 18:57 |
| @clarkb:matrix.org | corvus: I think the docs reorg looks good. I guess we try to get consensus on that and then rebase and merge quickly before it can diverge too much (it has merge conflicts according to gerrit) | 19:01 |
| @jim:acmegating.com | Clark: yeah... i'm pretty happy with the reviews there... might be good to ask fungi to take a look at it. also do we want to generate another redirect map like we did last time? (and by we, i mean fungi) | 19:05 |
| @clarkb:matrix.org | I tend to not hang onto urls myself... google does a good job of indexing | 19:06 |
| @mhuin:matrix.org | Hello zuul-maint, the 3 first patches on this chain got a +2, how about a final, gentle push 🙂 https://review.opendev.org/q/topic:%22web_results_pagination%22 | 19:06 |
| @jim:acmegating.com | Clark: i think part of the motivation was to help google update its index...but i am somewhat ambivalent on it. | 19:07 |
| @clarkb:matrix.org | corvus: comment on https://review.opendev.org/c/zuul/nodepool/+/807464/ too | 19:07 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 807464: Add metastatic driver https://review.opendev.org/c/zuul/nodepool/+/807464 | 19:09 | |
| @jim:acmegating.com | Clark: thx :) | 19:09 |
| @jim:acmegating.com | mhu: thanks; i'd like to look at it, but i may not get to it till tomorrow | 19:10 |
| @mhuin:matrix.org | no rush | 19:10 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: | 19:43 | |
| - [zuul/nodepool] 814837: Add more log messages to azure driver https://review.opendev.org/c/zuul/nodepool/+/814837 | ||
| - [zuul/nodepool] 816757: Azure: add image-id support https://review.opendev.org/c/zuul/nodepool/+/816757 | ||
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: | 19:43 | |
| - [zuul/nodepool] 818030: Add admin password support for Azure driver https://review.opendev.org/c/zuul/nodepool/+/818030 | ||
| - [zuul/nodepool] 819507: Azure: add image filter https://review.opendev.org/c/zuul/nodepool/+/819507 | ||
| @clarkb:matrix.org | Are the ubi8 container images sticking around when centos8 EOLs in a couple of weeks? I assume so since ubi wasn't based on centos | 20:03 |
| -@gerrit:opendev.org- Zuul merged on behalf of Clark Boylan: [zuul/zuul] 821275: Add an upgrade release note for delete-state https://review.opendev.org/c/zuul/zuul/+/821275 | 21:03 | |
| @fungicide:matrix.org | > <@jim:acmegating.com> Clark: yeah... i'm pretty happy with the reviews there... might be good to ask fungi to take a look at it. also do we want to generate another redirect map like we did last time? (and by we, i mean fungi) | 21:05 |
| I pulled the change up yesterday to start looking through (particularly the draft build), but haven't gotten very far. Happy to make an Apache redirect map from the git rename info as well, though I may not be able to get to it until next week at the earliest. I do agree at least that the docs reorg is a great idea for v5. | ||
| @fungicide:matrix.org | and no idea if my message will go thruogh, element is saying "connectivity to the server has been lost" | 21:05 |
| @fungicide:matrix.org | retried just now and it seems to think the messages finally went through | 21:05 |
| @fungicide:matrix.org | the main reason for adding redirects is that there may be references in semi-permanent places like mailing list archives, so still taking people to the right document for most of those can be a bit more friendly, but it's certainly a tradeoff against maintaining those redirects | 21:07 |
| @clarkb:matrix.org | I see your messages now at least | 21:08 |
| @fungicide:matrix.org | thanks for confirming | 21:08 |
| @apevec:matrix.org | re. ubi8 - they are based on RHEL8 | 22:43 |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul-registry] 821336: Update the registry docker image to bullseye https://review.opendev.org/c/zuul/zuul-registry/+/821336 | 23:30 | |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul-client] 821337: Update the zuul client docker image to bullseye https://review.opendev.org/c/zuul/zuul-client/+/821337 | 23:33 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!