| *** dtantsur_ is now known as dtantsur | 02:24 | |
| *** darmach6 is now known as darmach | 08:58 | |
| opendevreview | Jan Gutter proposed zuul/zuul-jobs master: [wip] Fix k8s-crio buildset registry test https://review.opendev.org/c/zuul/zuul-jobs/+/926013 | 09:38 |
|---|---|---|
| opendevreview | Jan Gutter proposed zuul/zuul-jobs master: [wip] Fix k8s-crio buildset registry test https://review.opendev.org/c/zuul/zuul-jobs/+/926013 | 10:13 |
| opendevreview | Jan Gutter proposed zuul/zuul-jobs master: [wip] Fix k8s-crio buildset registry test https://review.opendev.org/c/zuul/zuul-jobs/+/926013 | 10:52 |
| opendevreview | Jan Gutter proposed zuul/zuul-jobs master: [wip] Fix k8s-crio buildset registry test https://review.opendev.org/c/zuul/zuul-jobs/+/926013 | 13:27 |
| opendevreview | Jan Gutter proposed zuul/zuul-jobs master: Fix k8s-crio buildset registry test https://review.opendev.org/c/zuul/zuul-jobs/+/926013 | 14:50 |
| clarkb | infra-root a reminder that I am out tomorrow. I suspect that it may be another skipped meeting day tomorrow. I think that is fine, but there are a couple of topics I wanted to bring up more asynchronously today so that they don't get lost in the shuffle | 15:51 |
| clarkb | First up a reminder that we are in the OpenDev Service Coordinator nomination period until August 20. If you are interested and have questions feel free to reach out and I'll do my best to respond quicky | 15:52 |
| clarkb | Second there is discussion about whether or not we should switch gitea to forgejo on the mailing list: https://lists.opendev.org/archives/list/service-discuss@lists.opendev.org/thread/CWVR5HRTHGWZTKQEFCOOP77GFFVUXBA4/ | 15:53 |
| clarkb | If others have more information / better informed opinions I think it would be great to ensure we've recorded them and make a stronger decision at the end if possible | 15:53 |
| clarkb | Third Etherpad has made a 2.2.2 release that changes how all the js (including plugins) for etherpad is bundled up and loaded into your browser. THis has unfortunately broken with our use of the ep_headings plugin. There is a separate ep_headings2 plugin which I've updated the change to use just to confirm the issue was in the ep_headings plugin and fungi reports the held node | 15:57 |
| clarkb | functions now. The next concern is what happens to existing pads when you switch from ep_headings to ep_headings2. The upstream ep_headings2 project has an old closed issue indicating there might be errors. We probably need to deploy a current version of etherpad with ep_headings then update to ep_headings2 and see what happens to some test pads (or use a prod db loaded onto the test | 15:57 |
| clarkb | node I guess) | 15:57 |
| clarkb | I don't think the etherpad thing is particularly ugent; however, it would be good to try and build a better understanding of the situation. | 15:57 |
| clarkb | I personally probably won't get to that in the near future as I'm out tomorrow and I'm also starting to realize I need to dive into summit preparation as I've presenting on zuul and hosting a forum session | 15:58 |
| clarkb | that is it for my ansynchronous braindump. Feel free to follow up here or if it is easier we can start threads on the mailing list for these topics | 15:58 |
| opendevreview | Jan Gutter proposed zuul/zuul-jobs master: [wip] Update ensure-kubernetes with podman support https://review.opendev.org/c/zuul/zuul-jobs/+/924970 | 16:37 |
| opendevreview | Jan Gutter proposed zuul/zuul-jobs master: [wip] Update ensure-kubernetes with podman support https://review.opendev.org/c/zuul/zuul-jobs/+/924970 | 16:41 |
| opendevreview | Jan Gutter proposed zuul/zuul-jobs master: [wip] Update ensure-kubernetes with podman support https://review.opendev.org/c/zuul/zuul-jobs/+/924970 | 17:35 |
| clarkb | jrosser: noonedeadpunk: it came to my attention that some openstack ansible jobs have relatively complicated scenario selection logic based on job name: https://opendev.org/openstack/openstack-ansible/src/branch/master/zuul.d/playbooks/pre-gate-scenario.yml#L27-L84 You should be able to use job level vars to select the scenario instead which should be much simpler. Have a parent job | 17:40 |
| clarkb | that doesn't do anything by default (can also be abstract) then child job sets a unique name and sets teh var related to that name | 17:40 |
| clarkb | looks like maybe it is already checking for the scenario var anyway so might just be able to delete all that code if you set the value at the job level | 17:40 |
| jrosser | clarkb: unfortunately that will not work outside zuul? | 17:55 |
| clarkb | jrosser: it would if you set the flag in your inventory or otherwise add the ansible var | 17:56 |
| clarkb | but its executing in the context of zuul (its checking the zuul job name) | 17:56 |
| clarkb | generally we recommend against this beacuse it means job names affect the behavior of jobs which is something that is often unexpected to people and leads to confusion if you have to rename things | 17:56 |
| jrosser | we would have to make a job per repo then too? | 17:56 |
| clarkb | I think you would continue to have as many job as you do today. The difference would be explicitly setting the scenario rather than inferring it from the job name | 17:57 |
| jrosser | as the openstack service name (as determined from the repo name) is magically added to the scenario currently | 17:57 |
| clarkb | https://opendev.org/openstack/openstack-ansible/src/branch/master/zuul.d/playbooks/pre-gate-scenario.yml#L40-L55 this section? | 17:58 |
| jrosser | so openstack_ansible_os-ironic will deploy ironic with no specific job or var needed to do that | 17:58 |
| clarkb | jrosser: right but you already hvae an ironic job for that so you can set the appriopriate scenario on that job? | 17:59 |
| jrosser | I think it’s worth remembering that we are the complete opposite of a monorepo, so a lot of this is done to concentrate the job definitions in one place | 17:59 |
| clarkb | in that case it shouldn't add any new jobs to the mix, you just reduce the logic in the job and set the scenario upfront | 17:59 |
| corvus | (also, you can set a job variable on the project-pipeline config for the job (you can also set a job variable at the project level); both are ways of adjusting a job variable for a specific project invocation without creating a new job) | 18:00 |
| clarkb | yes concentrating job definitions is fine. I'm just suggesting that having complicated logic to determine the job behavior at runtime is an anti pattern. | 18:00 |
| clarkb | because you now have to debug that pile of jinja to understand why jobs are doing what they do reather than reading a var | 18:01 |
| jrosser | im still not seeing how that would work with project templates | 18:02 |
| jrosser | which ultimately is what gets specified in most places rather than actual jobs | 18:02 |
| clarkb | (there are other benefits to being explicit too like simpler statistics gathering for pass/fail rates, more accurate job runtime estimates, and so on) | 18:03 |
| corvus | (this is what my 2 examples looks like: https://paste.opendev.org/show/bpPf9PMn4BHMxruwjOKO/ ) | 18:03 |
| corvus | first example works well with templates | 18:05 |
| jrosser | even though we use the same templates across dozens of repos? | 18:08 |
| jrosser | sorry i feel pretty stupid here that i can't see how this does not involve a very large nuber of extra job definitions | 18:09 |
| jrosser | the thing is that in dozens of our repos there are not actually any jobs defined, looking at ironic as an example https://github.com/openstack/openstack-ansible-os_ironic/blob/master/zuul.d/project.yaml | 18:12 |
| corvus | jrosser: from a high-level perspective: it looks like the job is configuring itself based on two pieces of information: the job name, and the repo. instead of encoding information in the job name, you should be able to encode it in the job definition as a variable. that's like the minimal version of the thing clarkb is saying, i think. that's almost axiomatic -- if the data is in the job name, then you can just move it to the job variable | 18:12 |
| corvus | with no other changes. | 18:12 |
| jrosser | but there is no job definition | 18:12 |
| clarkb | jrosser: https://opendev.org/openstack/openstack-ansible/src/branch/master/zuul.d/project-templates.yaml#L170-L185 the jobs are still definied | 18:13 |
| corvus | jrosser: the other bit of information, that's currently being obtained from zuul.project is the project under test. maybe you leave that the same, or maybe you use a project variable to set the scenario for that project. that's a little more distributed configuration, but could still be a net benefit. it's a little less axiomatic that you can just make that change. so it's not as minimal. | 18:13 |
| jrosser | yes, and those cover many many different values of the scenario based on the repo they are used from | 18:13 |
| jrosser | i am pretty reluctant to change this - we only need one place to manage our jobs or add / remove / non-voting an entire OS (for example) across dozens of repos | 18:16 |
| clarkb | At a high level I would probably suggest not doing that bceause it is confusing that job openstack-ansible-deploy-aio_metal_tls-ubuntu-jammy can behave vastly different when run against ansible-role-uwsgi or openstack-ansible-os_ironic. I'm not going to stop you from doing that but it makes comapring last known good runs useless in the naive case (eg the very case I might run into if | 18:17 |
| clarkb | helping to debug a transition in success reliability) | 18:17 |
| clarkb | but as corvus mentions you can still approximate that via project level vars (or just keep that portion of the behavior selection in the jinja block) | 18:18 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: ensure-podman: add tasks to configure socket group https://review.opendev.org/c/zuul/zuul-jobs/+/925916 | 18:19 |
| fungi | clarkb: catching back up on the etherpad upgrade (sorry, just got a few minutes to jack into the net), did you see the same problem i did with numbered lists on the held node? | 18:30 |
| clarkb | fungi: I haven't tested it myself yet. I guess I should. Also makes me wonder if that is an etherpad problem or a plugin problem. Presumably it is an etherpad problem | 18:31 |
| clarkb | fungi: the list you created is all 1.'s but creating new lists in chrome and firefox in incognito tabs works as I expect | 18:33 |
| clarkb | fungi: maybe you need to hard refresh or clear your cache to get the list output to work properly | 18:34 |
| fungi | maybe, or it could be that it relies on some feature client-side that simply doesn't work in the browser i was testing with | 18:37 |
| clarkb | it seems to work for me doing a bit of other testing. I think the main issue is testing the behavior of existing ep_headings pads without that plugin being present anymore. I really hope it just renders some markup and people cna manually convert in pads they still use. But that issue I found makes me worry it will just break | 18:41 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: ensure-podman: add tasks to configure socket group https://review.opendev.org/c/zuul/zuul-jobs/+/925916 | 18:44 |
| fungi | clarkb: what's odd is that this same browser can do numbered lists successfully on the production server (i just tested to confirm), so i wonder what's changed in that regard | 19:27 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: ensure-podman: add tasks to configure socket group https://review.opendev.org/c/zuul/zuul-jobs/+/925916 | 19:43 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: ensure-podman: add tasks to configure socket group https://review.opendev.org/c/zuul/zuul-jobs/+/925916 | 20:13 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: Add ability to exclude a specific platform https://review.opendev.org/c/zuul/zuul-jobs/+/926164 | 20:13 |
| clarkb | fungi: is that with cache claered between trying the different etherpad versions. I just wonder if the old version js is possibly polluting things | 20:17 |
| fungi | same browser and version, but on two different computers | 20:18 |
| fungi | i have a pair of identical netbooks, the one i tested on yesterday is not the one i'm travelling with today. neither had connected to the production etherpad before, but also as these are travel devices i have them configured to not keep any local cache | 20:19 |
| clarkb | huh so possibly browser realted? I used firefox and chrome in my test | 20:20 |
| fungi | this one is chromium/webkit-based | 20:20 |
| fungi | but yeah, seems to be a browser-specific regression in the new etherpad version. not a very widely-used browser though so not a big deal | 20:21 |
| clarkb | for testing ep_headings content under ep_headings2 do you think it is worthwhile restoring from a prod db or should we just use a test pad. I think a test pad is probably sufficient though it won't cover all the possible heading cases | 20:22 |
| clarkb | actually maybe it could at least at small scale since there is a finite number ofthem | 20:22 |
| fungi | we can probably create a test scenario on a held node from the same version as prod and then dump it into the db for the current held node | 20:23 |
| clarkb | There are 8 formats/headings if you include "normal" | 20:26 |
| clarkb | so ya it should be straightforward to generate a pad or a set of pads that cover all 8 and then see what happens when loaded without ep_headings installed and with ep_headings2 installed | 20:26 |
| clarkb | reminder that I won't be around tomorrow and won't chair the meeting. I suspect that skipping is what will happen and we can asynchronously discuss the items above (and any others) until next week. tonyb that means you don't have to wake early :) | 23:27 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!