| opendevreview | Ghanshyam proposed openstack/tempest master: DNM: for test https://review.opendev.org/c/openstack/tempest/+/871019 | 02:17 |
|---|---|---|
| opendevreview | Ghanshyam proposed openstack/tempest master: Fix creation of requested creds within the same project https://review.opendev.org/c/openstack/tempest/+/871018 | 05:56 |
| opendevreview | Ghanshyam proposed openstack/tempest master: Use project_reader in server test https://review.opendev.org/c/openstack/tempest/+/871210 | 05:57 |
| opendevreview | Ghanshyam proposed openstack/tempest master: DNM: for test https://review.opendev.org/c/openstack/tempest/+/871019 | 05:57 |
| *** bhagyashris_ is now known as bhagyashris|ruck | 07:34 | |
| opendevreview | Bence Romsics proposed openstack/devstack master: 'sudo pkill -f' should not match the sudo process https://review.opendev.org/c/openstack/devstack/+/867215 | 10:38 |
| opendevreview | Rodolfo Alonso proposed openstack/devstack master: Remove the neutron bash completion installation https://review.opendev.org/c/openstack/devstack/+/871731 | 13:54 |
| opendevreview | Bas de Bruijne proposed openstack/tempest master: tempest cleanup - don't initialize admin id's https://review.opendev.org/c/openstack/tempest/+/870930 | 14:17 |
| opendevreview | Dan Smith proposed openstack/tempest master: Chunked GET request support https://review.opendev.org/c/openstack/tempest/+/871000 | 14:38 |
| clarkb | The bcrypt, pynacl, cryptogrpahy issue can be seen here: https://zuul.opendev.org/t/openstack/build/7d8793801ff94468a5387294ff7fb679/log/job-output.txt#14932-14955 This appears to be a python3.6 bionic node installing the tempest venv. It finds the sdist for these three packages instead of their wheels. I've only checked bcrypt but it does have a cp36-abi3-manylinux_2_28_x86_64 | 16:25 |
| clarkb | and cp36-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64 wheel one of which should be compatibile with that platform | 16:25 |
| clarkb | My hunch is that the pip ending up in the tempest venv is too old to understand that one of those wheels is valid so it grabs the sdist instead | 16:25 |
| clarkb | its possible this has always been an issue, but the rust dependency is new in 4.x for bcrypt? previously we would've pulled 3.2.x and compiled from source successfully? | 16:26 |
| clarkb | anyway, for wheover ends up debugging this my hunch is thta pip is too old to treat those wheels as valid. Upgrading pip might be the answer? | 16:27 |
| *** gthiemon1e is now known as gthiemonge | 16:40 | |
| fungi | yes you need pip 20.0 or newer to get abi3 support | 16:46 |
| *** jpena is now known as jpena|off | 17:25 | |
| opendevreview | Merged openstack/devstack master: 'sudo pkill -f' should not match the sudo process https://review.opendev.org/c/openstack/devstack/+/867215 | 17:36 |
| opendevreview | Merged openstack/tempest master: Restore IP addresses configuration after spoofing MAC address https://review.opendev.org/c/openstack/tempest/+/871271 | 18:03 |
| dansmith | clarkb: fungi I ran something through the experimental queue, saw it running at one point, but never got a report (and it's out of the queue now) | 18:18 |
| dansmith | is that a known thing, or might it be stuck in some post queue for a long time or something? | 18:19 |
| dansmith | experimental is pretty heavy so I'd hate to recheck for no reason | 18:19 |
| dansmith | filtering the builds by change 863920 shows nothing, so I must be not using that right | 18:27 |
| dansmith | ah, 863920,15 works and everything looks good, so .. I dunno why I don't see it | 18:28 |
| fungi | dansmith: also you can use the builds list in the zuul webui to look it up by job name, project, et cetera. and there's the build history link for a quick way to get there from another build of the same job too | 18:34 |
| fungi | oh, you did that | 18:34 |
| fungi | dansmith: the gerrit comments indicate you commented check experimental on patchset 14, not sure if that makes any difference though | 18:36 |
| clarkb | maybe the event emitted for a comment on an old patchset doesn't match our regex? | 18:37 |
| dansmith | it ran the job because I saw it running in the queue at the time | 18:38 |
| dansmith | and you can see the job reports in the builds tab from this morning | 18:38 |
| fungi | dansmith: https://zuul.opendev.org/t/openstack/builds?pipeline=experimental&change=863920%2C14&skip=0 | 18:38 |
| dansmith | so it clearly ran it today when I asked for it, it just never commented | 18:38 |
| clarkb | I wonder if it didn't comment because it was an old patchset | 18:38 |
| fungi | it's possible zuul won't comment on a patchset it tested if that is no longer the latest patchset | 18:39 |
| clarkb | the link fungi linked shows it ran against the old patchset | 18:39 |
| clarkb | ya | 18:39 |
| dansmith | that would suck that it does all the work but throws it away | 18:39 |
| dansmith | no, it ran on the new one | 18:39 |
| dansmith | https://zuul.opendev.org/t/openstack/builds?change=863920%2C15&skip=0 | 18:39 |
| dansmith | oh wait, maybe I'm confusing the check run and the experimental one | 18:39 |
| clarkb | if you look at the experimental results there it ran on ps 14 not 15 | 18:39 |
| fungi | dansmith: gerrit's comment log says you uploaded patchset 15 and then commented "check experimental" on patchset 14 | 18:40 |
| fungi | remember that newer gerrit has patchset comments, so you have to make sure you're in the new patchset's context when you reply | 18:40 |
| dansmith | fungi: yeah I'm sure I did I just didn't realize that mattered, and until I realized I'm looking at *check* from 15 but *experimental* from 14 I didn't see the difference | 18:40 |
| dansmith | okay, so what's the point of running the job on the old patchset (because the comment was there) but never reporting the results? | 18:41 |
| dansmith | if it's helpful to run on an old patchset, shouldn't it still comment with the results? | 18:41 |
| dansmith | and if it's not, then don't waste the resources doing it? | 18:41 |
| fungi | that's a good question, of course. i think gerrit includes the patchset number in the comment-added event and zuul is obeying that | 18:41 |
| fungi | but maybe it shouldn't | 18:42 |
| clarkb | right you asked to ru nthe jobs on that patchset so it did. | 18:42 |
| dansmith | I can see it both ways | 18:42 |
| clarkb | I'm not sure why it didn't report back though | 18:42 |
| clarkb | it may have actually tried and gerrit told it no? | 18:42 |
| fungi | if it tried to include a vote that would have happened, but experimental doesn't vote | 18:42 |
| clarkb | you cannot vote on old patchsets, but experimental does not vote | 18:42 |
| clarkb | jinx | 18:42 |
| dansmith | tbh, I think that running on an old PS is 99% of the time an accidental use of the web UI (as it was in this case), so if I could argue for a behavior, I'd probably ask for always-on-latest | 18:43 |
| dansmith | if it were to run on 14 and report on 14, especially with experimental, we might think 15 works, but doesn't | 18:44 |
| clarkb | on the other hand that would mean you could never run jobs against old patchses easily | 18:46 |
| dansmith | yeah, for sure, I'm just not sure that's very useful | 18:46 |
| dansmith | versus the incorrect assumption that we tested it when we didn't | 18:46 |
| dansmith | since experimental is always "see if these other one-offs work because this patch has scary in it", it's particularly error-prone here | 18:47 |
| dansmith | but even still, I've literally never though about "hmm, maybe I should recheck this old patchset and see if that works now" | 18:47 |
| dansmith | sometimes maybe, but just pretty rarely I think | 18:48 |
| clarkb | efbb9bf1971543d0911a624cd426bb31 is the zuul event id for the experimental run request | 18:48 |
| clarkb | ERROR zuul.GerritConnection: [e: efbb9bf1971543d0911a624cd426bb31] Error submitting data to gerrit on attempt 1: Received response 404: Not found: None | 18:48 |
| clarkb | it did indeed error when attempting to comment back | 18:49 |
| clarkb | it is POSTING to changes/$changeid/revisions/$change.commit/review | 18:51 |
| clarkb | $changeid would be openstack%2Fnova~master~I595b27a57516cffe1f172cf2fb736e1b11373a1d here. And revision is harder to find on gerrit now I guess (they only show the shortsha?) | 18:55 |
| clarkb | d6e8f55028f577a80c88304b7597d71600f1400b | 18:56 |
| clarkb | I can GET https://review.opendev.org/changes/openstack%2Fnova~master~I595b27a57516cffe1f172cf2fb736e1b11373a1d/revisions/d6e8f55028f577a80c88304b7597d71600f1400b/commit (slightly different endpoint but uses the same identifiers) | 18:56 |
| clarkb | reading https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#set-review I feel like this may be a gerrit bug because this should work | 18:58 |
| clarkb | but it is also possible that maybe the zuul internal state somehow didn't feed it those same parameters | 18:58 |
| clarkb | aha | 18:58 |
| clarkb | POST: https://review.opendev.org/a/changes/openstack%2Fnova~master~I595b27a57516cffe1f172cf2fb736e1b11373a1d/revisions/None/review | 18:58 |
| clarkb | It tried to post to None so ya I think this is a zuul bug when dealing with old patchsets | 18:59 |
| clarkb | I need to run but I'll make note of this in Zuul's matrix room before I go | 18:59 |
| dansmith | bug meaning it should run on the old patchset and report on the old patchset? | 19:00 |
| clarkb | bug meaning None is the revision. I think what it is doing as far as running against the old patchset is technically correct. I'm not sure we can change that behavior easily (remember pipelines are generic constructs in zuul and they don't know about our experimental use case they just know they get events and need torun jobs against the code represented by that event) | 19:02 |
| dansmith | I don't want experimental to be a special case, to be clear | 19:05 |
| dansmith | but the lack of any comment response at all is the _most_ confusing, so if that's fixed then that's better than where we are | 19:05 |
| clarkb | yes I think it is a zuul bug that it tried to post comments to the wrong location and fixing that should get you results back | 19:11 |
| dansmith | clarkb: if I accidentally recheck or check experimental on 14, realize, and then recheck on 15 will it start both or do I have to wait 90 minutes before I can get the current set running? | 20:15 |
| clarkb | I think newer patchsets are supposed to supercede older ones | 20:24 |
| clarkb | so it depends on the order you do it in? | 20:24 |
| dansmith | well, I specified an order | 20:24 |
| clarkb | right in that order I would expect 15 to force 14 out | 20:25 |
| dansmith | okay | 20:25 |
| opendevreview | Ghanshyam proposed openstack/tempest master: Use UPPER_CONSTRAINTS_FILE for stable/wallaby testing https://review.opendev.org/c/openstack/tempest/+/871781 | 20:51 |
| opendevreview | Ghanshyam proposed openstack/devstack stable/wallaby: Pin Tempest to 33.0.0 tag for stable/wallaby testing https://review.opendev.org/c/openstack/devstack/+/871782 | 20:58 |
| opendevreview | Ghanshyam proposed openstack/devstack stable/wallaby: Pin Tempest to 32.0.0 tag for stable/wallaby testing https://review.opendev.org/c/openstack/devstack/+/871782 | 23:50 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!