| *** rlandy is now known as rlandy|out | 02:48 | |
| *** akahat is now known as akahat|ruck | 07:01 | |
| *** akahat|ruck is now known as akahat|rover | 07:01 | |
| *** blarnath is now known as d34dh0r53 | 07:22 | |
| *** bhagyashris|ruck is now known as bhagyashris | 07:47 | |
| *** jpena|off is now known as jpena | 08:43 | |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Change tox environment to py3 instead of py38 https://review.opendev.org/c/openstack/ci-log-processing/+/871974 | 10:31 |
|---|---|---|
| *** rlandy|out is now known as rlandy | 11:12 | |
| *** tosky_ is now known as tosky | 12:55 | |
| ade_lee | clarkb, fungi hey - do you guys have some time to brainstorm on the fips jobs. I'd like to have a consensus on the best way to move forward so I can put up the next patch | 13:49 |
| ade_lee | the last we left it - I would create a job in project-config called fips or some such that would call a registration pre playbook . Then in zuul-jobs, multinode-fips would inherit from fips | 13:53 |
| fungi | not quite, because job definitions in zuul-jobs can't have explicit parents outside zuul-jobs (remember that's the upstream zuul project's "standard library" basically) | 13:55 |
| fungi | the role which does the fips setup and registers with ua can reside in zuul-jobs, but the playbook which uses that role needs to be in project-config | 13:56 |
| fungi | and then devstack-base needs to depend either directly or indirectly on the job in project-config which uses that playbook | 13:57 |
| fungi | which means we can't use the multinode-fips job from zuul-jobs, but we could put a copy of it with our own altered parentage in openstack-zuul-jobs | 13:58 |
| ade_lee | fungi, ok - so then openstack-multinode-fips (which is the job in project-config will need to call all the roles for fips setup and registration and multinode) | 13:58 |
| ade_lee | ok - sucks to have to duplicate all the multinode stuff, but I don't see another way around it | 13:59 |
| fungi | yes. if the role which does ua registration is the same one which installs the fips packages and does the reboot, then we probably just need to forklift the whole multinode-fips job definition from zuul-jobs to project-config | 14:00 |
| fungi | if most of the logic were in roles rather than tasks directly in playbooks, you wouldn't have to duplicate much (the roles don't need to be forked, just the playbooks which use them) | 14:00 |
| ade_lee | fungi, yup - makes sense -- there is just a single playbook there that calls roles - so I just need to duplicate that | 14:01 |
| *** dasm|off is now known as dasm | 14:01 | |
| ade_lee | fungi, ok - I should have something up for review later today | 14:02 |
| fungi | ade_lee: one thing to keep in mind, which i had suggested early on, you could split up the ua registration into a separate role from the fips stuff. ua registration is the only part that needs the secret, so therefore the only part which needs to happen from a trusted config context. that would reduce the footprint of stuff which happens in project-config and can't safely be | 14:05 |
| fungi | speculatively executed, allowing whatever's calling the fips setup role to be in an untrusted project like openstack-zuul-jobs where changes to it can actually be exercised before they're merged | 14:05 |
| fungi | for that matter, the fips setup role could maybe just be added to the devstack-base job | 14:06 |
| fungi | no need to make the job ancestry unnecessarily longer | 14:06 |
| ade_lee | fungi, ack - yeah - I plan to put all the ua registration logic in project-config and leave the fips stuff in zuul-jobs | 14:08 |
| ade_lee | fungi, as for the fips role, its also used in non-devstack jobs (like tripleo) | 14:09 |
| ade_lee | but maybe yeah | 14:09 |
| fungi | well, if it's really just "include the fips-setup role" then that part may not need an extra job of its own, it's about as much work adding that line as changing the job parents | 14:10 |
| ade_lee | fungi, sorry - maybe I'm confused - but I think we have to change the parent of the devstack-base job because we need the fips setup playbook to run before the multinode playbook. | 14:13 |
| fungi | ade_lee: looking at the current parentage, the part which probably requires the most duplication is the "multinode" job from zuul-jobs. devstack-base parents to that, and we'll want our own version of it so that we can parent it to the ua registration job in project-config | 14:13 |
| fungi | so i guess we could forklift https://opendev.org/zuul/zuul-jobs/src/branch/master/playbooks/multinode/pre.yaml into openstack-zuul-jobs and mash the fips setup role inclusion into it, then parent it on the project-config job that does the ua setup | 14:15 |
| fungi | also clarkb may have different suggestions once the sun touches his side of the rock | 14:17 |
| ade_lee | fungi, yup - thats what I was thinking - but we could even just put the role that does the registration in the pre.yaml for openstack-zuul-jobs - and just have that as the parent | 14:18 |
| ade_lee | fungi, where is clarkb ? pst? | 14:19 |
| fungi | yeah | 14:19 |
| fungi | ade_lee: the ua registration role needs the key though, right? so either it has to be called from a playbook in project-config to be allowed access to the secret, or we need to write it to disk from a playbook in project-config (less ideal) | 14:20 |
| fungi | and when i say "less ideal" i mean because that makes it trivial for a proposed change to echo the unencrypted version out to a job log or something | 14:21 |
| ade_lee | sorry - I confused myself for a sec there -- you had mentioned forklifting all the multinode stuff into openstack-zuul-jobs (and I transposed project-config) . Yes, in this case, the parent needs to be in project-config and call the registration role there. | 14:23 |
| ade_lee | ok - this makes sense now | 14:24 |
| ade_lee | fungi, so as I understand it then -- this is the plan -- https://paste.openstack.org/show/bNExctYcnyjydM7rztDW/ | 14:44 |
| *** dviroel|out is now known as dviroel|ruck | 15:08 | |
| fungi | ade_lee: the ua-registration role could go in zuul-jobs, just needs to be used directly by a job in project-config since that's what's handling the secret | 15:22 |
| ade_lee | fungi, ok | 15:27 |
| clarkb | fungi: ade_lee: my suggestion was to look at the docker images and they basically implement the jobs in a trusted repo using roles for reuse | 16:22 |
| clarkb | since they have a similar set of constraints | 16:22 |
| fungi | yeah, i think that's the plan described above? | 17:18 |
| fungi | or am i missing some subtle difference in what you're suggesting? | 17:18 |
| clarkb | no I think thats he same I was just agreeing | 17:26 |
| fungi | oh, perfect thanks! | 17:33 |
| *** jpena is now known as jpena|off | 17:35 | |
| *** dviroel|ruck is now known as dviroel|ruck|afk | 20:53 | |
| *** dasm is now known as dasm|off | 21:35 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!