| -@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand: [zuul/zuul] Add source context to project API return https://review.opendev.org/c/zuul/zuul/+/805746 | 00:02 | |
| -@gerrit:opendev.org- Jiri Podivin proposed: [zuul/zuul-jobs] DNM https://review.opendev.org/c/zuul/zuul-jobs/+/807031 | 08:14 | |
| @tobias.henkel:matrix.org | corvus: looks like the gate jobs in the node request stack are very unstable. This may indicate a problem with the stack. I skimmed through the last few failures in the gate and most of them had NODE_FAILUREs in one test case. | 08:23 |
|---|---|---|
| @tobias.henkel:matrix.org | * corvus: looks like the gate jobs in the node request stack are very unstable. This may indicate a problem with the stack. I skimmed through the last few failures in the gate and most of them had NODE_FAILUREs in one test case (always different test cases). | 08:26 |
| -@gerrit:opendev.org- Zuul merged on behalf of Matthieu Huin https://matrix.to/#/@mhuin:matrix.org: [zuul/zuul] Web UI: add checkbox, selects to filter toolbar https://review.opendev.org/c/zuul/zuul/+/729265 | 08:30 | |
| @lyr:matrix.org | Hi there. We have an "auto merge" pipeline which is basically a gate pipeline, which self approve then merge if the label "auto-merge" is available. It used to work. Now it doesn't. Here' what the log told me | 08:31 |
| ``` | ||
| 2021-09-10 08:26:14,366 DEBUG zuul.Pipeline.local.auto-merge: [e: c279ed70-1210-11ec-8cd9-9e58e8ddaf18] Considering adding change <Change 0x7f37f8257b70 org/zuul-test-job 6,c00eadb3cd298d7ad4b1db42fd3295a4aaed8e16> | ||
| 2021-09-10 08:26:14,367 DEBUG zuul.GithubConnection: [e: c279ed70-1210-11ec-8cd9-9e58e8ddaf18] Change <Change 0x7f37f8257b70 org/zuul-test-job 6,c00eadb3cd298d7ad4b1db42fd3295a4aaed8e16> can not merge because it is not approved | ||
| 2021-09-10 08:26:14,367 DEBUG zuul.Pipeline.local.auto-merge: [e: c279ed70-1210-11ec-8cd9-9e58e8ddaf18] Change <Change 0x7f37f8257b70 org/zuul-test-job 6,c00eadb3cd298d7ad4b1db42fd3295a4aaed8e16> can not merge | ||
| 2021-09-10 08:26:14,367 DEBUG zuul.Pipeline.local.auto-merge: [e: c279ed70-1210-11ec-8cd9-9e58e8ddaf18] Change <Change 0x7f37f8257b70 org/zuul-test-job 6,c00eadb3cd298d7ad4b1db42fd3295a4aaed8e16> is not ready to be enqueued, ignoring | ||
| ``` | ||
| We upgraded from 3.19 to 4.5 recently (software factory 3.5 to 3.6). I tried tweaking the behavior, like "doesn't merge, just approve, and hopefully gate pipeline will follow up", but nothing worked | ||
| @tobias.henkel:matrix.org | corvus: it might be related to the election change (https://review.opendev.org/c/zuul/zuul/+/806653/12) which was the first one where I've seen the node failures in an unstable test case | 08:31 |
| @tobias.henkel:matrix.org | lyr: pipelines that merge will check github branch protection settings if changes could merge (assuming that it sets its own required status check) the pipeline however won't know if the change is going to be approved | 08:33 |
| @tobias.henkel:matrix.org | lyr: an alternative could be to change the auto merge pipeline to independent and only do the approval such that a regular gate will act on that after approval | 08:34 |
| @tobias.henkel:matrix.org | lyr: this is what added checking the review requirements: https://review.opendev.org/c/zuul/zuul/+/749040 | 08:35 |
| @lyr:matrix.org | In which Zuul version was it released ? | 08:36 |
| @tobias.henkel:matrix.org | https://zuul-ci.org/docs/zuul/reference/releasenotes.html#relnotes-4-0-0 | 08:37 |
| @lyr:matrix.org | 'kay, this explain that | 08:38 |
| @lyr:matrix.org | One last question so I can craft a "self-approve" pipeline. Can I not run anything, like an empty `start` ? An equivalent of `return true` I'ld say | 08:39 |
| @tobias.henkel:matrix.org | you approve via the pipeline settings? then adding a `noop` job would do the trick | 08:40 |
| @tobias.henkel:matrix.org | noop is a predefined do-nothing job that immediately succeeds | 08:41 |
| @lyr:matrix.org | I'm thinking about something like that | 08:41 |
| ```yaml | ||
| - pipeline: | ||
| name: self-approve | ||
| description: | | ||
| Changes that have been self-approved (self-approve label) are enqueued | ||
| in order in this pipeline, and if they pass tests, will be | ||
| approved. | ||
| success-message: Build succeeded (self-approve pipeline). | ||
| failure-message: | | ||
| Build failed (self-approve pipeline). | ||
| manager: dependent | ||
| precedence: high | ||
| post-review: True | ||
| require: | ||
| github.com: | ||
| # Require label | ||
| label: self-approve | ||
| status: (?i)^wazo-community-zuul.*:local/check:success$ | ||
| open: True | ||
| current-patchset: True | ||
| trigger: | ||
| github.com: | ||
| - event: pull_request | ||
| action: comment | ||
| comment: (?i)^\s*reapprove\s*$ | ||
| - event: pull_request | ||
| action: status | ||
| status: (?i)^wazo-community-zuul.*:local/check:success$ | ||
| - event: pull_request | ||
| action: labeled | ||
| label: | ||
| - self-approve | ||
| success: | ||
| github.com: | ||
| status: "success" | ||
| merge: false | ||
| comment: false | ||
| review: "approve" | ||
| review-body: "" | ||
| window-floor: 20 | ||
| window-increase-factor: 2 | ||
| ``` | ||
| @tobias.henkel:matrix.org | manager should be `independent` in this case | 08:42 |
| @tobias.henkel:matrix.org | the window config is then also not necessary | 08:42 |
| @tobias.henkel:matrix.org | you can use that pipeline then like | 08:43 |
| ``` | ||
| - project: | ||
| @tobias.henkel:matrix.org | * you can use that pipeline then like | 08:43 |
| ``` | ||
| - project: | ||
| self-approve: | ||
| jobs: | ||
| - noop | ||
| ``` | ||
| @lyr:matrix.org | Ok, cool, will try | 08:44 |
| @gtema:matrix.org | jfyi: zuul approving the PR in GitHub is under circumstances still not considered as a real approval by GH, thus merging will not work | 09:48 |
| @gtema:matrix.org | that was for lyr ^^^ | 09:49 |
| -@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] web UI: add "show retries" toggles on buildset page https://review.opendev.org/c/zuul/zuul/+/806201 | 12:10 | |
| @ssbarnea:matrix.org | two very simple changes that new one ore core review: https://review.opendev.org/c/zuul/zuul-jobs/+/735340/ https://review.opendev.org/c/zuul/zuul-jobs/+/735339/ | 12:52 |
| @jim:acmegating.com | > <@tobias.henkel:matrix.org> corvus: it might be related to the election change (https://review.opendev.org/c/zuul/zuul/+/806653/12) which was the first one where I've seen the node failures in an unstable test case | 13:26 |
| good point, i'll examine them deeply before merging further | ||
| @tristanc_:matrix.org | fungi: Clark I'm trying to follow the issue ssbarnea reported where tox on centos does not behave as he expect... what is the actual status today? | 13:39 |
| @tristanc_:matrix.org | if i understand correctly, running `tox -epy38` on centos does not run the test with python3.8, and that seems like a bug in tox where it should fail with MissingInterpreter | 13:40 |
| @tristanc_:matrix.org | and if that is the case, I'm not sure zuul-jobs should work around that issue, perhaps the main issue is that zuul is missing an option to prevent job from running with some nodeset that are known to be incompatible? | 13:47 |
| @ssbarnea:matrix.org | in fact the problem is not necessarly specific to centos7, the reality is that on other platforms we may have a system version of tox that does not support minversion= or requires=, which are two key elements related to tox. Basicaly ones that help developer declare what version of tox they require, potential plugins. More recent versions of tox know how to bootstrap these without affecting the system/global version. Worst part is that too old version do not say anything about that, ignoring these options. | 13:53 |
| @clarkb:matrix.org | tristanC: ssbarnea I think two different issues are being conflated. ssbarnea would like to update ensure-tox to install tox even if it is already installed. I flagged this as important for tristanC to review because software factory has asked that we try very hard not to do this. | 14:23 |
| @clarkb:matrix.org | The tox -epy38 thing not running with python38 is definitely a tox bug imo but I don't have the energy of trying to convince them of that as everytime I've taken a bug to them its been a huge time sink | 14:23 |
| @clarkb:matrix.org | Instead of installing a newer tox in ensure-tox I have suggested that we emit a warning. I suppose we could also make that behavior configurable, though ideally the people controlling the test systems would address the issue there if it is an issue | 14:24 |
| @clarkb:matrix.org | For example OpenDev doesn't use system tox to avoid these problems | 14:25 |
| @ssbarnea:matrix.org | Clark: i was not able to reproduce this problem with current tox locally but I seen it happening on CI, so i suppose on CI it was an older version that did not had this bug fixed. | 14:25 |
| @ssbarnea:matrix.org | i know for sure what will happen if someone raise a bug with an outdated version of tox, i do not want to annoy the maintainer. | 14:26 |
| @clarkb:matrix.org | > <@ssbarnea:matrix.org> Clark: i was not able to reproduce this problem with current tox locally but I seen it happening on CI, so i suppose on CI it was an older version that did not had this bug fixed. | 14:26 |
| That is good to know. | ||
| @ssbarnea:matrix.org | I hope i explained in description the reasoning for considering 3.2.0 as minimal considered safe to use | 14:27 |
| @ssbarnea:matrix.org | minversion/requires are two key features which make tox kinda future proof, as developer can mention which version they need, and the tool will respect that. | 14:28 |
| @clarkb:matrix.org | ssbarnea: the issue isn't in choosing a version but in overriding installation preferences at runtime. This causes problems for software factory | 14:28 |
| @clarkb:matrix.org | this is why all of the ensure-roles attempt to determine if the software is already present then they stop running if so | 14:29 |
| @ssbarnea:matrix.org | i think i could rewrite the implementation to allow someone to disable that feature | 14:29 |
| @clarkb:matrix.org | This is why I suggested a warning "Consider preinstalling tox>=x.y.z to avoid known bugs" | 14:29 |
| @clarkb:matrix.org | if you do it under a feature flag I think it should be opt in not opt out | 14:29 |
| @ssbarnea:matrix.org | like adding a tox_minversion=3.2.0 variable in defaults, which can be neutered by those that do not want to respect that. | 14:30 |
| @ssbarnea:matrix.org | if is opt-out is useles, it will protect nobody, users may still continue to run tox and believe it works. | 14:30 |
| @clarkb:matrix.org | We've already established a default behavior in the ensure-roles that they will short circuit if the tool is present | 14:30 |
| @clarkb:matrix.org | we shouldn't break that behavior | 14:31 |
| @clarkb:matrix.org | > <@ssbarnea:matrix.org> if is opt-out is useles, it will protect nobody, users may still continue to run tox and believe it works. | 14:31 |
| Yes, this is why I'm suggesting a warning instead | ||
| @ssbarnea:matrix.org | (almost) nobody reads the warnings, especially console ones. Do we have way to warning that is more visible? | 14:32 |
| @clarkb:matrix.org | Does ansible have a not success or fail state that the console log can render? Because they show up in pretty colors | 14:33 |
| @ssbarnea:matrix.org | Clark: as i told you few days ago, that change is not really for myself, we know how to address it locally, Is just to help others avoid the same mistake we observed. Who wants to run CI with wrong python version for an year? | 14:33 |
| @clarkb:matrix.org | I understand but we have an intentional preexisting behavior in those roles to explicitly not do what you are trying to do | 14:34 |
| @ssbarnea:matrix.org | in fact i am afraid that users will not open the suceeded jobs | 14:35 |
| @clarkb:matrix.org | those two goals are in conflict and I think the existing one wins because we know not doing that breaks existing users. | 14:35 |
| @ssbarnea:matrix.org | Clark: how do we define "breaks current users?". AFAIK, tox will still work after this change, on all platforms. Is just that install of skipping installing it, it will install a newer version. Is that worse than running a version of tox that reports successes on stuff that are totally wrong? (misconfigured python version) | 14:37 |
| @clarkb:matrix.org | The process of installing new software breaks users like software factory | 14:38 |
| @clarkb:matrix.org | They preinstall exactly what they want and if something tries to override the job fails | 14:38 |
| @ssbarnea:matrix.org | if they preinstall tox and do not want ensure-tox to mess it, why running ensure-tox at all? ;) | 14:39 |
| @clarkb:matrix.org | Because it sets cars for subsequent roles | 14:40 |
| @clarkb:matrix.org | * Because it sets vars for subsequent roles | 14:40 |
| @clarkb:matrix.org | We did a lot of work to ensure the ensure roles supported that use case. This undoes that hence my concern. | 14:40 |
| @ssbarnea:matrix.org | ahh, but what if we all an new param: "tox_keep_system_version" ? | 14:40 |
| @clarkb:matrix.org | Yes make that opt in not opt out as I said earlier | 14:41 |
| @ssbarnea:matrix.org | yep, and it would be a waste of effort, nobody will benefit from that change. | 14:42 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] Remove unneeded scheduler.zk_nodepool object https://review.opendev.org/c/zuul/zuul/+/808406 | 14:44 | |
| @jim:acmegating.com | Clark, tobiash: ^ i think that's what's going on. i'm 90% confident that's a problem, but can't confirm 100% it's the cause of the errors without extremely verbose logging. | 14:45 |
| @ssbarnea:matrix.org | basically is about: sf-preference vs general befit of zuul users (in generl). AFAIK, sf is the only deployment that has this special preference. | 14:45 |
| @jim:acmegating.com | Clark, tobiash: ^ there is a fairly reasonable chance that bug could hit in production too, especially on a busy system, so i suggest we consider that a high-priority change. i'm running the full test suite locally to try to get ahead of any test failures now; but i think it's ready for review. | 14:49 |
| @clarkb:matrix.org | corvus will review after school drop off | 14:52 |
| @tristanc_:matrix.org | Clark: if i remember correctly, the goal to keep a provided tox was to ensure the job will run in the same environment as the desired target. If the job update tox (or any of the distro packages), then using a centos nodeset is not very useful because the end user will have a different environment. | 14:52 |
| @tristanc_:matrix.org | What is the point of running a tox-py38 job on centos-7 when the end user will likely use the distro provided py36 version? Trying to make such job+nodeset work seems like defeating the point of using such nodeset. | 14:56 |
| @clarkb:matrix.org | > <@tristanc_:matrix.org> Clark: if i remember correctly, the goal to keep a provided tox was to ensure the job will run in the same environment as the desired target. If the job update tox (or any of the distro packages), then using a centos nodeset is not very useful because the end user will have a different environment. | 15:02 |
| More generally I would say if the CI system has elected a version not overriding that is important regardless of what the version is | ||
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] Remove unneeded scheduler.zk_nodepool object https://review.opendev.org/c/zuul/zuul/+/808406 | 15:05 | |
| @jim:acmegating.com | just test framework fixes ^ that should pass now | 15:05 |
| @tristanc_:matrix.org | Clark: I think that should be the expected behavior, thus I'd be in favor of adding a warning (or even a failure) if we can detect when the tox job definition conflict with the nodeset (e.g. tox-py* with old tox). Would that works for you ssbarnea ? | 15:49 |
| @ssbarnea:matrix.org | tristanC: i do not know anything we can do to inform the user without changing default behavior. unless a job will fail people will never know they are running CI jobs with a version of tox that does not do what they expect. | 15:51 |
| @ssbarnea:matrix.org | the only way to make the warning (effectively) visible is to add a comment on the review (gerrrit/github) and that is problematic for other reasons. When jobs are passing (almost) nobody is clicking on the to look for... warnigns, so they will not know about that working. | 15:54 |
| @tristanc_:matrix.org | ssbarnea: we could use https://zuul-ci.org/docs/zuul/reference/jobs.html#leaving-warnings | 15:55 |
| @ssbarnea:matrix.org | tristanC: that would working nicely! no spam and visible enough! | 15:55 |
| @ssbarnea:matrix.org | lets assume I implement that, lets see how it would work: if tox is outdated, a leaving-warning is added mentioning that outdated default tox may produce false positive results and that user should add "tox_upgrade" to his job vars in order to ensure their jobs runs with a recent version of tox? | 15:58 |
| @ssbarnea:matrix.org | how long the warnign should be? should I mention details like missing ability to use minversion/requires from tox.ini? | 15:59 |
| @ssbarnea:matrix.org | in fact with ansible i should even be able to identify if these options are used in tox.ini file, if the repo is already cloned when ensure-tox runs and make the upgrade automatic. | 16:00 |
| @tristanc_:matrix.org | ssbarnea: is there a bug upstream we could reference? | 16:01 |
| @ssbarnea:matrix.org | i know for sure that very old versions of tox like 1.4.2 are clueless about these two options. i do not care about other missing features because any tox.ini maintainer should know to bump minversion/requires when they use different features. | 16:01 |
| @ssbarnea:matrix.org | the hard question is which one, there are multiple bugs/changes involved. i think it would better to reference that documentation section: https://tox.readthedocs.io/en/latest/config.html?highlight=minversion#conf-minversion | 16:04 |
| @ssbarnea:matrix.org | if you read those two you should understand why i want to ensure a recent enough version, as older ones are blind regarding these two options. If they would fail when encountering unknown options it would have being fine, but that is not how tox works. | 16:05 |
| @tristanc_:matrix.org | how about when `tox-py*` doesn't match `python --version` and old tox, then fail with a message explaining that the behavior is undefined? | 16:05 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 16:09 | |
| - [zuul/zuul] Remove unecessary node request cancelation code https://review.opendev.org/c/zuul/zuul/+/806814 | ||
| - [zuul/zuul] Refactor the checkNodeRequest method https://review.opendev.org/c/zuul/zuul/+/806816 | ||
| - [zuul/zuul] Don't store node requests/nodesets on queue items https://review.opendev.org/c/zuul/zuul/+/806821 | ||
| - [zuul/zuul] Remove internal nodepool request cache https://review.opendev.org/c/zuul/zuul/+/807196 | ||
| - [zuul/zuul] Report nodepool resource stats gauges in scheduler https://review.opendev.org/c/zuul/zuul/+/807406 | ||
| - [zuul/zuul] Add ZK session-aware elections https://review.opendev.org/c/zuul/zuul/+/807656 | ||
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed on behalf of Felix Edel: [zuul/zuul] Don't use the AnsibleJob in the nodepool client https://review.opendev.org/c/zuul/zuul/+/807711 | 16:09 | |
| @ssbarnea:matrix.org | that would be quite hard to implement for several reasons: passed envlist is a list and each environment can contain the pyXY as a substring, i would not only have to parse that but also to identigy the version of python on which tox itself was installed which is far from simple, i am not even sure if format of --version changed over time. I would say: hard to do and easy to get it wrong. | 16:09 |
| @ssbarnea:matrix.org | but somehow I kinda like the idea of sneak-peeking on tox.ini file and deciding if newer tox is needed. Can this be done when ensure-tox runs or it runs before cloning is done? | 16:10 |
| @jim:acmegating.com | Clark, tobiash, swest, felixedel: ^ that's the stack rebased on that fix; i went through and checked for usages of getNodeRequest to evaluate whether they should be cached or not. i made one change to a test method in 807196, because it was and should be using the cache. i also updated the final change in the series to fix that merge conflict. | 16:12 |
| @jim:acmegating.com | ssbarnea, tristanC: if there's no bug or other external reference in order to supply long-form information about the warning, you could add a "..note:" to the job description, then hyperlink to the published zuul-jobs documentation in the warning message. | 16:13 |
| @yaniv.levy:matrix.org | hi, is it proper to ask a noob zuul question here? | 16:14 |
| @jim:acmegating.com | Yaniv Levy: you found the right place :) | 16:15 |
| @clarkb:matrix.org | corvus: thanks I'll rereview shortly | 16:15 |
| @clarkb:matrix.org | corvus: Everything but the last change has +2s now. I didn't approve any as I wasn't sure how much double checking of the CI fix you wanted to do. Now I need to properly review the last change as I havne't reviewed that one before | 16:23 |
| @jim:acmegating.com | Clark, tobiash yeah, we could hold approval until check jobs come back for the whole stack; we'll get more results that way (we may still have timeouts, other bugs, ofc) | 16:25 |
| @yaniv.levy:matrix.org | Thanks. I've complete the 'quick start installation and tutorial guide'. nodepool is using a 'static driver' to run the test on a single node. I want this node to execute many same tests concurrently so I set up max-parallel-jobs to 10 (default: 1). I figured out that each running instance of the test must have it's own working directory. reading the documentation, I leaned about the 'prepare-workspace' role. In the 'quick start guide' it is already configured in the base job pre.yaml. But, when I try to add zuul_workspace_root: "{{zuul.build}}" to pre.yaml the syntax check fails. Am I'm the right track? what is the syntax to set the variable zuul_workspace_root? | 16:29 |
| @yaniv.levy:matrix.org | (in my case a single bare-metal node will be used to execute the tests, maybe in the zuul world it is expected to launch an individual container for each test instance?) | 16:30 |
| @clarkb:matrix.org | corvus: I think https://review.opendev.org/c/zuul/zuul/+/807711/4/zuul/executor/server.py line 3901 will fail pep8 checking due to line too long | 16:32 |
| @jim:acmegating.com | Yaniv Levy: probably the best way to do that would be to add it as a job variable on the base job. so add what you have above to a "vars" section in the base job. | 16:32 |
| @jim:acmegating.com | Yaniv Levy: note that you'll need some way to clean up old workspaces. i think the best way to use a static node is not to use max-parallel-jobs, but instead create multiple users, and register each one as a static node (with the same connection info). nodepool will recognize each host/port/user combination as a different node. | 16:33 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed on behalf of Felix Edel: [zuul/zuul] Don't use the AnsibleJob in the nodepool client https://review.opendev.org/c/zuul/zuul/+/807711 | 16:36 | |
| @jim:acmegating.com | Clark: ^ | 16:37 |
| @jim:acmegating.com | Yaniv Levy: to clarify, i mean the base job definition for zuul in `zuul-config/zuul.d/jobs.yaml` (in the quickstart) | 16:37 |
| @yaniv.levy:matrix.org | corvus: Oh. didn't have the literal var:, this solved the issue, thanks. I understand your suggestion re multiple uses, but since I'm on a system that uses centralized authentication, It's better not to create users. | 16:46 |
| @yaniv.levy:matrix.org | corvus: so, since I changed the default value of zuul_workspace_root: "{{zuul.build}}", the built-in cleanups / log / artifact roles will not work? | 16:47 |
| @jim:acmegating.com | I think the log roles should work. There is no workspace cleanup though, you'll need to implement that in order to avoid filling the disk on the static node. | 16:50 |
| @yaniv.levy:matrix.org | ah, ok. that is reasonable. is the 'normal' way of doing things is to spawn a container as node to run test and delete it an the end of the test? | 16:53 |
| @clarkb:matrix.org | Yaniv Levy: either a container or a VM, but ya single use test nodes are very common with nodepool | 16:55 |
| @clarkb:matrix.org | pods are another option too | 16:55 |
| @yaniv.levy:matrix.org | Clark: thank you. | 16:55 |
| @yaniv.levy:matrix.org | Is there a public repo where I can examine various zuul configuration(s)? I find it easier to learn by example. | 16:56 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] Remove unneeded scheduler.zk_nodepool object https://review.opendev.org/c/zuul/zuul/+/808406 | 16:57 | |
| @clarkb:matrix.org | Yaniv Levy: the zuul that hosts zuul has its nodepool configs at https://opendev.org/openstack/project-config/src/branch/master/nodepool and its zuul configs are at https://opendev.org/openstack/project-config/src/branch/master/zuul and https://opendev.org/zuul/project-config/src/branch/master/ and https://opendev.org/opendev/base-jobs/ | 17:00 |
| @clarkb:matrix.org | Its compositiional so things end up in a few places | 17:01 |
| @yaniv.levy:matrix.org | Clark: thank you, this is helpful | 17:01 |
| @yaniv.levy:matrix.org | Thank you for your help. see you. | 17:18 |
| @ssbarnea:matrix.org | few zuul-job changes that should be safe to +W https://review.opendev.org/q/hashtag:%22zj-ready%22+(status:open%20OR%20status:merged) | 17:40 |
| @fungicide:matrix.org | ssbarnea: thanks for the rebase, but that's going to break. you rebased 806612 off the 806621 parent it needs to pass testing | 17:41 |
| @fungicide:matrix.org | those changes were in series for a reason | 17:41 |
| @fungicide:matrix.org | instead, a review of the parent changes would have been preferable | 17:41 |
| @ssbarnea:matrix.org | fungi: oops, i missed that, i supposed it failed to run due to a restart. | 17:41 |
| @fungicide:matrix.org | nope, it hasn't merged because nobody approved the parent changes | 17:43 |
| @ssbarnea:matrix.org | fungi: 806621 is quite interesting, i fail to understand its purpose considering that tox is able to install its own extra deps. | 17:44 |
| @ssbarnea:matrix.org | to me that one makes no sense, that is why tox has the "requires" option. | 17:45 |
| @fungicide:matrix.org | are you sure you're talking about 806621? i can't understand what you're referring to for that change | 17:46 |
| @fungicide:matrix.org | 806621 is entirely about adjusting the tox_install_sibling_packages.py script to be able to deal with --showconfig output which was generated when -vv was also supplied | 17:47 |
| @ssbarnea:matrix.org | fungi: ok, is this about installing other python packages that tox may need during execution? | 17:47 |
| @fungicide:matrix.org | no | 17:47 |
| @fungicide:matrix.org | did you read the commit message? | 17:48 |
| @ssbarnea:matrix.org | ahh, i know that bug. it was fixed in tox v4, but that was not released yet. | 17:49 |
| @ssbarnea:matrix.org | basically --showconfig does not produce parseable output | 17:49 |
| @fungicide:matrix.org | well, that commit solves two things, the first is that -vv spits out additional log lines before the showconfig content so those need to be stripped. the second is that the script assumed if a [tox] section was included in the showconfig output then it was an unfiltered config, but -vv adds a [tox] section to the showconfig output unconditionally so that assumption was no longer valid | 17:50 |
| @ssbarnea:matrix.org | in undid the rebase | 17:50 |
| @fungicide:matrix.org | thanks | 17:51 |
| @fungicide:matrix.org | anyway, the reason the verbose showconfig change is a necessary parent is that we default tox_extra_arge to '-vv' in the ensure-tox role, so it will start being verbose in the showconfig calls as well by default | 17:52 |
| @ssbarnea:matrix.org | but https://review.opendev.org/c/zuul/zuul-jobs/+/806613 looks ok to me, we only need one extra review, maybe from corvus ? | 17:54 |
| @ssbarnea:matrix.org | i never needed something like this myself, but i guess you found one consumer for that weird setup | 17:54 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 17:55 | |
| - [zuul/zuul] Remove internal nodepool request cache https://review.opendev.org/c/zuul/zuul/+/807196 | ||
| - [zuul/zuul] Report nodepool resource stats gauges in scheduler https://review.opendev.org/c/zuul/zuul/+/807406 | ||
| - [zuul/zuul] Add ZK session-aware elections https://review.opendev.org/c/zuul/zuul/+/807656 | ||
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed on behalf of Felix Edel: [zuul/zuul] Don't use the AnsibleJob in the nodepool client https://review.opendev.org/c/zuul/zuul/+/807711 | 17:55 | |
| @jim:acmegating.com | Clark, tobiash: oops, i didn't actually commit that change to 807196; fixed ^ | 17:55 |
| @jim:acmegating.com | Clark, tobiash: i think based on the results so far, i'm inclined to say let's go aheand and approve the stack and let the gate take care of it; i'm pretty sure the one test failure we've seen is due to that omission. | 17:58 |
| @fungicide:matrix.org | ssbarnea: yes, actually both the tox_config_file and tox_extra_args changes were options for solving the same need. starlingx contributors were struggling because they have multiple directories in some repositories with different tox.ini files in then and were attempting to pass a tox_extra_args to the tox role in jobs to pick a particular non-default tox config, but that wasn't behaving as expected because the siblings install was still using the default tox.ini in the repo instead (fairly clearly a bug/incomplete implementation in the role). after looking in codesearch i ran across a number of other opendev users who were trying to do something similar and didn't realize it wasn't doing what they expected. the new tox_config_file rolevar is a clearer way of doing what they wanted, but the bug with tox_extra_args should be fixed regardless | 18:00 |
| @jim:acmegating.com | i need to afk for a bit; i'll check back in this afternoon and consider restarting opendev's zuul either then or tomorrow | 18:01 |
| @ssbarnea:matrix.org | fungi: ok, lets help them. | 18:02 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: | 19:24 | |
| - [zuul/zuul] Remove unecessary node request cancelation code https://review.opendev.org/c/zuul/zuul/+/806814 | ||
| - [zuul/zuul] Refactor the checkNodeRequest method https://review.opendev.org/c/zuul/zuul/+/806816 | ||
| @clarkb:matrix.org | The rest of the stack didn't merge due to timed out unittest jobs on one change. I've rechecked to reenqueue | 22:24 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] Don't store node requests/nodesets on queue items https://review.opendev.org/c/zuul/zuul/+/806821 | 23:37 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] Remove internal nodepool request cache https://review.opendev.org/c/zuul/zuul/+/807196 | 23:51 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!