| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-01-24 | |||
| 18:59:17 | ade_lee__ | sean-k-mooney, abishop and eharney are still investigating the failures | |
| 18:59:30 | ade_lee__ | sean-k-mooney, there is something going on with cryptsetup and fips | |
| 18:59:42 | sean-k-mooney | i see well right now the generic fips env is running https://github.com/openstack/tempest/blob/master/tox.ini#L101-L113 | |
| 18:59:44 | ade_lee__ | even in the luks case | |
| 19:00:52 | sean-k-mooney | the fips jobs seam to be all using the singel node node sets is that intentinal | |
| 19:02:49 | ade_lee__ | sean-k-mooney, no - not intentional - thats what we had defeined for nova while testing | |
| 19:03:01 | sean-k-mooney | gmann: actully looking at how those run it proably does not make sense to use a tox target | |
| 19:03:14 | ade_lee__ | sean-k-mooney, we can change if needed | |
| 19:03:19 | sean-k-mooney | ade_lee__: for nova we would want multi node for live migration and colde migration coverage | |
| 19:04:53 | ade_lee__ | sean-k-mooney, ack - so do we want to change in the generic job as defined here - or define a new job? gmann ^^? | |
| 19:05:03 | sean-k-mooney | gmann: we will need to exclude non fips compatible test but we need to include tests form the tempest plugins for ceph ectra | |
| 19:05:41 | sean-k-mooney | so doing that in the job configuation actully proable makes more sense then backing it into a bunch of tox envs | |
| 19:06:45 | sean-k-mooney | ade_lee__: porbaly have both so just inhirt form the current jobs and defien the nodeset to be a multi node variant | |
| 19:07:07 | sean-k-mooney | then the porject can decided which one they want to included | |
| 19:07:57 | ade_lee__ | sean-k-mooney, sounds reasonable to me | |
| 19:08:22 | gmann | sean-k-mooney: ade_lee__ ok, so for multinode case we can inherit from tempest-multinode-full-py3 https://github.com/openstack/tempest/blob/master/zuul.d/integrated-gate.yaml#L230 | |
| 19:08:55 | sean-k-mooney | that also works | |
| 19:09:26 | sean-k-mooney | i was thinking of just inhirting form tempest-centos8-stream-fips and setting the nodeset | |
| 19:09:41 | sean-k-mooney | so you dont have to redfiene the fips specific things in two places | |
| 19:10:33 | ade_lee__ | sean-k-mooney, though presumably you have to refine all the multinode things .. | |
| 19:10:39 | sean-k-mooney | no | |
| 19:10:49 | sean-k-mooney | all the devstack jobs inhrit form multinode | |
| 19:11:06 | sean-k-mooney | so a single node job is a multi node jobs without a second node defiend | |
| 19:11:41 | ade_lee__ | sean-k-mooney, I meant all the things in https://github.com/openstack/tempest/blob/master/zuul.d/integrated-gate.yaml#L232-L242 | |
| 19:12:14 | gmann | ade_lee__: you do not need USE_PYTHON3 as it is default to true in devstack now | |
| 19:12:40 | sean-k-mooney | ade_lee__ none of that is relevent to multi node | |
| 19:13:00 | gmann | ade_lee__: sean-k-mooney so you are saying two jobs 1. existing tempest-centos8-stream-fips 2. new multinode one ? | |
| 19:13:15 | sean-k-mooney | what we need to do is https://github.com/openstack/devstack/blob/master/.zuul.yaml#L179-L207 | |
| 19:13:18 | sean-k-mooney | for centos | |
| 19:13:27 | gmann | if so why not converting the existing one to multinode | |
| 19:13:41 | sean-k-mooney | gmann: we could convert it to multinode | |
| 19:13:58 | sean-k-mooney | but we still need to override the nodeset to use centos-8-stream | |
| 19:14:04 | sean-k-mooney | since the current jobs assumes that | |
| 19:14:24 | gmann | yeah | |
| 19:14:52 | sean-k-mooney | so either in devstack or in tempest we need a openstack-two-node-centos-8-stream nodeset | |
| 19:15:25 | gmann | we need to define that in devstack | |
| 19:15:27 | sean-k-mooney | gmann: i was assumign it would be simpler to get the fips jobs stable single node then add multi node | |
| 19:15:48 | sean-k-mooney | gmann: by convention yes. althoguh its not required by zuul | |
| 19:16:23 | ade_lee__ | sean-k-mooney, we should probably stick with convention .. | |
| 19:16:24 | gmann | sean-k-mooney: we can see what all test fails and if that is multinode related or not. if so then we can separate the efforty | |
| 19:16:40 | sean-k-mooney | ack | |
| 19:16:58 | sean-k-mooney | ok im going to go cook dinner so ill let ye figure out the best way forward | |
| 19:17:18 | ade_lee__ | sean-k-mooney, gmann -- so , as I understand the plan | |
| 19:17:19 | gmann | sean-k-mooney: have a good one. lunch time for me too | |
| 19:17:23 | gmann | ade_lee__: thanks | |
| 19:17:52 | ade_lee__ | 1. merge current patches for single-node (assuming all tests pass, as I suspect they will) | |
| 19:18:03 | ade_lee__ | 2. add nodeset definition to devstack | |
| 19:18:34 | ade_lee__ | 3. add multinode job to tempest with that nodeset -- basically same as single + new nodeset | |
| 19:19:01 | ade_lee__ | 4. add to nova jobs / replace existing job | |
| 19:20:00 | ade_lee__ | thats it .. I think .. | |
| 19:20:01 | gmann | ade_lee__: in 3rd and 4th - let's modify existing job tempest-centos8-stream-fips to use multinode nodeset | |
| 19:20:04 | sean-k-mooney | ya that sounds resonable to me i suspect say keystone wont care about multi node so having both makes sense to me but 3 could be "update single node job to multi node " too as an alternitive | |
| 19:20:27 | ade_lee__ | jinx :) | |
| 19:20:33 | sean-k-mooney | gmann: im ok with either option so ill defer to your preferocne on one job or two | |
| 19:21:24 | ade_lee__ | deferring to ya'll - but I think its likely other projects may not care about multinode too | |
| 19:21:39 | gmann | sean-k-mooney: ade_lee__ let's start with multinode and if things fails more or so then we can have single node and then multinode separate jobs | |
| 19:22:19 | gmann | ade_lee__: sean-k-mooney you mean keystone only right? other projects anyways need to define the new jobs to include their tempest tests from their plugin | |
| 19:23:22 | ade_lee__ | gmann, I'm just thinking that given that we have a common place for fips jobs, other projects might want to use or inherit from them | |
| 19:23:37 | gmann | ade_lee__: ok, inherit is good point. | |
| 19:24:01 | gmann | ok. let's define both in that case. | |
| 19:24:07 | ade_lee__ | cool | |
| 19:24:27 | sean-k-mooney | gmann: i picked keystone at randmon bascially because noting in keystone should affect cold/live migration so keystone proabley dont want to waste ci resouces testing multi node | |
| 19:24:34 | sean-k-mooney | same for glance swift ectra | |
| 19:24:49 | gmann | yeah and even it can be treated as base for other tempest plugin jobs too | |
| 19:25:10 | gmann | so single and multinode jobs as separate sounds good | |
| 19:25:28 | ade_lee__ | cool - sounds like a plan ! thanks ya'll | |
| 19:25:40 | ade_lee__ | go eat! | |
| 19:25:42 | gmann | thanks | |
| 19:25:44 | gmann | :) | |
| 19:26:39 | sean-k-mooney | o/ | |
| #openstack-nova - 2022-01-25 | |||
| 00:37:21 | opendevreview | Merged openstack/nova master: Add service version check workaround for FFU https://review.opendev.org/c/openstack/nova/+/826097 | |
| 00:48:07 | opendevreview | Merged openstack/nova master: block_device: Ignore VolumeAttachmentNotFound during detach https://review.opendev.org/c/openstack/nova/+/812127 | |
| 01:34:57 | opendevreview | Merged openstack/nova master: Add check job for FIPS https://review.opendev.org/c/openstack/nova/+/790519 | |
| 08:39:41 | plibeau | hello, sean-k-mooney thx for the review, lyarwood if you have time to review: https://review.opendev.org/c/openstack/nova/+/820531 | |
| 10:12:17 | bauzas | sean-k-mooney: gibi: when you're around, I'm about working on a specific implementation detail for https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/boot-vm-with-unaddressed-port.html | |
| 10:12:55 | bauzas | sean-k-mooney: gibi: in https://review.opendev.org/c/openstack/nova/+/669411/2/nova/network/neutron.py stephenfin said we should verify the l2 connectivity for the port binding | |
| 10:13:53 | bauzas | sean-k-mooney: gibi: I can do it in https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L3546 | |
| 10:14:24 | bauzas | sean-k-mooney: gibi: but what kind of exception should I provide if it's not cool ? | |
| 10:14:38 | bauzas | exception.PortUpdateFailed I guess? | |
| 10:14:53 | gibi | hm, | |
| 10:15:34 | gibi | the faulty case is when a port has ip_allocation=none but when it is bound neutron sets connectivity to other than l2 | |
| 10:15:46 | gibi | but this should be a neutron error, isn't it? | |
| 10:15:52 | gibi | I mean such port has no sense | |
| 10:16:27 | bauzas | gibi: this is correct iiuc | |
| 10:16:48 | gibi | could neutron detect this and fail the binding? | |
| 10:16:57 | gibi | that would be a cleaner approach | |
| 10:17:10 | bauzas | gibi: well, I don't know | |
| 10:17:16 | gibi | sean-k-mooney: ^^ ? | |
| 10:17:48 | bauzas | stephenfin: if you're around, I'd like to understand why you wanted to verify the l2 connectivity with https://review.opendev.org/c/openstack/nova/+/669411/2/nova/network/neutron.py | |
| 10:18:09 | bauzas | thanks | |
| 10:18:14 | bauzas | context : unaddressed ports | |
| 10:18:35 | bauzas | we haven't discussed it in the spec | |
| 10:22:31 | stephenfin | Ah, so ralonsoh is really the person to ask. He told me to do that :) If I were to guess, it's because deferred IP allocation obviously only makes sense for L2 ports (you must have an IP to operate at layer 3) but that's a guess | |
| 10:22:49 | bauzas | stephenfin: yeah, I understand why | |
| 10:23:05 | bauzas | I mean the "why we should verify" | |
| 10:23:21 | bauzas | but gibi had concerns with "where we should do it" | |
| 10:23:36 | bauzas | and I'm quite able with him | |
| 10:23:40 | ralonsoh | bauzas, there are some backends that don't allow to have IP-less ports | |
| 10:23:41 | stephenfin | ah, yes, I didn't read all the conversation | |
| 10:23:50 | ralonsoh | this is why we introduced this parameter | |