| *** redrobot2 is now known as redrobot | 05:58 | |
| *** gibi is now known as gibi_pto_back_thu | 06:11 | |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: DNM Initial project commit https://review.opendev.org/c/openstack/ci-log-processing/+/815604 | 08:37 |
|---|---|---|
| dpawlik | ianw: that is an explanation that I was looking for ! (in that PS https://review.opendev.org/c/openstack/ci-log-processing/+/815604 ) | 08:38 |
| ianw | dpawlik: ok good :) all these silly made-up words :) | 09:56 |
| *** jpena|off is now known as jpena | 10:09 | |
| *** rlandy is now known as rlandy|ruck | 10:35 | |
| *** dviroel|out is now known as dviroel|rover | 11:21 | |
| opendevreview | Alfredo Moralejo proposed openstack/project-config master: Add support for CentOS Stream 9 in nodepool elements https://review.opendev.org/c/openstack/project-config/+/811442 | 11:49 |
| opendevreview | Alfredo Moralejo proposed openstack/project-config master: Add centos-9-stream nodepool image https://review.opendev.org/c/openstack/project-config/+/816465 | 11:49 |
| *** anibal is now known as anibalcesar | 11:51 | |
| *** jcapitao is now known as jcapitao_lunch | 11:56 | |
| afaranha_ | ping fungi thanks for the server, the issue ended up being the reboot of the FIPS after mounting the partition, thanks for the help on that with clarkb | 15:22 |
| afaranha_ | the server: centos-8-ovh-gra1-0027003455 | 15:22 |
| *** afaranha_ is now known as afaranha | 15:22 | |
| afaranha | and regarding that, could we talk about this patch https://review.opendev.org/c/zuul/zuul-jobs/+/816385 ? | 15:23 |
| fungi | afaranha: so you're done with that node and we can return it to our pool now? | 15:23 |
| afaranha | yea, after the patch and updating the swift fips patch, it worked :D | 15:23 |
| afaranha | https://review.opendev.org/c/openstack/swift/+/796057/ | 15:24 |
| fungi | thanks! i'll delete it now | 15:24 |
| fungi | clarkb: would multi-inheritance be a cleaner solution to 816385 in order to avoid redefining the existing 8-job-deep inheritance chain? | 15:27 |
| fungi | i'm trying to think through how that would work as far as pre-run playbook order though | 15:28 |
| afaranha | fungi, do we have another way to tell a job to: RUN this before the pre-run? Or just put a "place holder" on the job and define it later? | 15:29 |
| clarkb | fungi: I don't know that multi inheritance would solve the ordering problem without redefining the jobs | 15:39 |
| clarkb | fungi: if you mix in a fips parent downstream its pre-run is still going to happen too late I think | 15:40 |
| fungi | afaranha: that's what i'm trying to figure out. we can tell the job it has two parents, but seems like that wouldn't get the fips mix-in to run early enough | 15:40 |
| clarkb | I think things would still get resolved in order at that point | 15:40 |
| clarkb | so the first parent defined then the second? There isn't a way to say "this parent is actually a great grandparent" | 15:41 |
| afaranha | clarkb, is this an RFE or is it already implemented? | 15:42 |
| afaranha | That'd probably solve the issue, if we say: JOB_A inherits from JOB_B and JOB_C; and if the order is respected, that means JOB_B pre-run runs before JOB_C pre-run, that would solve it | 15:42 |
| clarkb | well zuul allows you to do that by defining a new parent job and parenting to that. The problem here is that the openstack and swift unittest jobs are like 5 layers deep for reasons | 15:43 |
| clarkb | basically you want to do base <- unittest-fips <- openstack-pyXY <- swifth-pyXY or whatever the chain is | 15:44 |
| clarkb | You could also bring up with the other zuul maintainers if they ahve the same concern as I do around polluting the generic jobs with flags like this. They may not care (though I strongly suspect tristanC will object because he likes to keep the jobs as simple as possible to reduce runtime) | 15:45 |
| afaranha | clarkb, I understand the concern, I agree with that, BUT, if the other solution is ctrl c + ctrl v on many jobs, it doesn't smells good as well | 15:47 |
| afaranha | maybe figure out some other way on how to solve it? | 15:47 |
| clarkb | afaranha: right but the problem here is you're making the job worse for all zuul users to address a very specific thing. having a small smell for the very specific thing is better than making everyone else suffer | 15:47 |
| afaranha | because if someone else has the same use case, then more jobs will be duplicated changing only one thing, or just the parent | 15:48 |
| afaranha | clarkb, I'm not really familiar to the zuul, so I may not know the full impact of it. But, as a optional parameter, that defualts to false (fips disabled), how would that impact other users? | 15:49 |
| clarkb | afaranha: you have to run the role too which means there is addtional code executing for every unittest job in all zuul installations | 15:49 |
| afaranha | as I see, they won't even notice that, unless they want to use it. Again, I may not seeing the full impact of it | 15:49 |
| clarkb | for something that basically no one else will care about | 15:50 |
| ade_lee | clarkb, how far up the chain would we need to duplicate? for instance, the job chain right now is -- swift-tox-base < openstack-tox-py27 < openstack-tox < tox < unittests -- could we do this change on openstack-tox for instance? | 15:51 |
| fungi | part of the challenge is that this inheritance chain is not just an inheritance of jobs, but an inheritance of review scope for different teams and communities. it's currently a need for a consumer of some swift functional job, but that depends jobs maintained by the qa team/tact sig, which depends on jobs maintained by the zuul community (which then depends on base jobs maintained by | 15:51 |
| fungi | the opendev sysadmins) | 15:51 |
| afaranha | ow, right, yea, we get to execute the playbook, at least to the "when" part | 15:52 |
| clarkb | ade_lee: you need to run before the unittest job (or replace it) | 15:52 |
| ade_lee | that is openstack-tox -> tox-fips -> unittests-fips .. | 15:52 |
| clarkb | ade_lee: as that is what triggers the executions of tools/test-setup.sh | 15:52 |
| clarkb | I guess you could convert all of openstack over to fips and then toggle with a flag there | 15:53 |
| ade_lee | right | 15:53 |
| clarkb | Another option would be to remount the fs | 15:53 |
| clarkb | or make it survive a reboot | 15:53 |
| ade_lee | clarkb, yeah - but this just happens to be a symptom of this current test setup. It would be good to solve this for all these types of tests | 15:55 |
| ade_lee | basically reboot and run things in fips mode as soon as possible | 15:55 |
| clarkb | yup, I'm just pointing out that it isn't fair to all of the other zuul users to make them run extra unwanted ansible for basic unittesting. I think its fine for openstack to say they don't mind but not ok in a base library job | 15:55 |
| clarkb | (and we've had users complain about stuff like this before so I'm trying to be better about it as a reviewer of those changes) | 15:56 |
| ade_lee | ack -- I'm ok with making the change at the openstack-tox level if thats what you guys decide | 15:56 |
| ade_lee | clarkb, fungi for context, I'm finishing up a draft to propose fips compatibility/compliance as a community goal -- not sure if it will happen - but converting over to being able to do fips at the openstack-zuul-jobs level would be reasonable then. | 15:59 |
| fungi | yeah, i think we'd have to duplicate some of zuul-jobs in openstack-zuul-jobs to make that happen, but might be a reasonable compromise | 16:00 |
| clarkb | ade_lee: ya one concern I mentioend is that we be careful not to suddenly duplicate all the jobs in openstack to get that coverage. Suggesting that instead we maybe default to fips under the assumption non fips would just work if fips works. Or do targetted testing of probably functional behavior since that is likely to have good coverage of the things fips changes | 16:00 |
| clarkb | fungi: ade_lee: and ya duplicating jobs in ozj for specific purposes like this seems reasonable. Those jobs don't change much. | 16:01 |
| clarkb | fungi: https://review.opendev.org/c/openstack/pbr/+/797898 got stephenfin's ACK any chance you want to take a look? I expect that is a very safe change to land now that PBR doesn't rely on it with its own pyproject.toml | 16:02 |
| clarkb | then we might consider a PBR release and the adventurous can give it a go | 16:03 |
| afaranha | I think we won't duplicate under ozj, just on zj, ade_lee right? | 16:03 |
| fungi | yeah, sorry i've been sidetracked but will up my priority on the pep-517 work | 16:03 |
| fungi | afaranha: we'd copy some of what's defined in zj into ozj, i think | 16:03 |
| clarkb | afaranha: you can duplicate on either side. The zuul-jobs side will be a bit more critical of ensuring things are generally reusable and not going to unexpectedly make tristanC's jobs slower :) | 16:03 |
| ade_lee | afaranha, no - I think the idea is to create fips versions below ozj | 16:03 |
| clarkb | if you do it in ozj then you can be all openstack specific and that is fine | 16:04 |
| fungi | having the fips role in zj is not so much a problem, it's job definitions where we need to think about the inheritance | 16:04 |
| fungi | roles can be pretty much anywhere (as long as they don't need secrets) | 16:05 |
| ade_lee | fungi, and when we added the role, the ansible folks indicated that they would end up using it. so we likely want to keep it there | 16:05 |
| afaranha | I thought we would duplicate under zj, like on your patch https://review.opendev.org/c/zuul/zuul-jobs/+/813253/ | 16:06 |
| afaranha | ack, I can start working on that tomorrow | 16:06 |
| ade_lee | clarkb, I agree that eventually we'd likely want to default to fips enabled on openstack jobs (and assume if it works under fips , it will work in non-fips), but we're not there just yet | 16:07 |
| fungi | ade_lee: yeah, that's what i was saying, keeping the fips role in zj is fine, it's job definitions from zj we may need to duplicate in ozj | 16:07 |
| fungi | e.g., unittests | 16:08 |
| clarkb | side note: it is unfortunate that running simple ansible tasks is so costly. But we've apparently appraoched ansible about this and fixing that is difficult :( | 16:08 |
| clarkb | part of the problem is ansible forks new processes for tasks rather than using a pool (in the past it did use a pool and was quicker) which means you incur python startup costs for every task aiui | 16:10 |
| ade_lee | fungi, so it sounds like we have two suggested options here -- adding unittests-fips to zj and tox-fips to zj and having ospenstack-tox depend on tox-fips , or duplicating tox and unittests in ozj | 16:10 |
| ade_lee | fungi, if I understood you correctly .. | 16:10 |
| clarkb | fwiw I'm ok with having -fips jobs in zuul-jobs because then people can opt into the extra runtime cost | 16:11 |
| clarkb | But as fungi points out the review groups might make it simpler to do that in ozj | 16:11 |
| fungi | yeah, i'm also happy to review it in either repo as i straddle both communities there, but have to keep different community priorities in mind when doing so | 16:12 |
| ade_lee | fungi, I guess duplicating in ozj would mean needing to keep track if any changes are made in zj. but I don't suppose these jobs change often. | 16:13 |
| fungi | yep | 16:13 |
| ade_lee | fungi, clarkb -- ok - your choice, guys -- afaranha will implement whatever you prefer | 16:14 |
| afaranha | I think changing in zj would also have this issue, because if the person updating the job doesn't know about fips, we'll need to go and update ourselves | 16:15 |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: DNM Initial project commit https://review.opendev.org/c/openstack/ci-log-processing/+/815604 | 16:19 |
| clarkb | ozj is probably going to get the most reviewers who are up to speed on the goals and system there | 16:29 |
| fungi | clarkb: some minor notes on the pep-517 change, otherwise lgtm | 16:54 |
| clarkb | checking and thanks | 16:56 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Add a PEP517 interface https://review.opendev.org/c/openstack/pbr/+/797898 | 17:06 |
| opendevreview | Clark Boylan proposed openstack/pbr master: PBR package testing improvements https://review.opendev.org/c/openstack/pbr/+/816539 | 17:06 |
| clarkb | fungi: ^ ensuring we don't break existing behavior seems important. So I went ahead and did that update | 17:06 |
| fungi | thanks! | 17:06 |
| fungi | it seemed unlikely those changes would alter pbr's behavior, but didn't want to be surprised by being wrong about it ;) | 17:06 |
| clarkb | ya being careful there is reasonable | 17:07 |
| fungi | and separating test framework changes from test additions is the safest way to go about it so you don't inadvertently bake in behavior changes | 17:08 |
| clarkb | the change of the PBR packge itself is probably the most likely to cause problems. But also having a complex url there isn't useful so if we can simplify that then yay | 17:09 |
| clarkb | fungi: unitests have passed for both changes (the longer running integration jobs are still in progress) that is a good sign | 17:33 |
| fungi | yeah, and they're approved so hopefully we'll see them merge forthwith | 17:40 |
| *** jpena is now known as jpena|off | 17:48 | |
| *** dviroel|rover is now known as dviroel|rover|afk | 19:45 | |
| opendevreview | Merged openstack/pbr master: PBR package testing improvements https://review.opendev.org/c/openstack/pbr/+/816539 | 20:04 |
| opendevreview | Merged openstack/pbr master: Add a PEP517 interface https://review.opendev.org/c/openstack/pbr/+/797898 | 20:29 |
| clarkb | woo | 20:29 |
| clarkb | fungi: I guess the next step is requesting a 5.7.0 release? any objections to that? I'm not sure what other stuff might be in the pipeline for pbr but suspect not much | 20:32 |
| fungi | yeah, should just be able to push a request for the releases repo | 21:00 |
| clarkb | remote: https://review.opendev.org/c/openstack/releases/+/816577 Release PBR 5.7.0 <- done | 21:01 |
| *** dviroel|rover|afk is now known as dviroel|rover | 21:29 | |
| *** rlandy|ruck is now known as rlandy|ruck|afk | 22:00 | |
| *** dviroel|rover is now known as dviroel|rover|out | 22:18 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!