| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-12-06 | |||
| 14:35:06 | sean-k-mooney | baiscally i want to minimise the amount of rpc callses we need and reuse the ones we already have currently | |
| 14:36:51 | bauzas | sean-k-mooney: tbc, I tried to do like for other features | |
| 14:36:57 | opendevreview | Merged openstack/nova-specs master: resubmit per-process-healthchecks spec for 2024.1 https://review.opendev.org/c/openstack/nova-specs/+/897225 | |
| 14:37:17 | bauzas | I thought it would be nice to check the types by the conductor | |
| 14:37:31 | bauzas | because operators couldn't use traits or something else | |
| 14:37:38 | bauzas | say custom rcs | |
| 14:37:53 | sean-k-mooney | well if they are using traits ro customer reousces | |
| 14:37:55 | bauzas | we could do this in pre-live-migrate for sure, after the conductor | |
| 14:37:59 | sean-k-mooney | then the type is checked by placment | |
| 14:38:09 | bauzas | sean-k-mooney: yeah indeed, but that's optional | |
| 14:38:19 | sean-k-mooney | right i think that shoudl be requried | |
| 14:38:29 | bauzas | I don't think so | |
| 14:38:33 | sean-k-mooney | i know | |
| 14:38:44 | bauzas | some operators just want to provide VGPUs | |
| 14:38:52 | sean-k-mooney | so i think the conductor check could be doen but im worried it will be somewhat expensive | |
| 14:38:53 | bauzas | given every new GPU has specific types | |
| 14:39:11 | bauzas | sean-k-mooney: shouldn't be that expensive as we already have the calls | |
| 14:39:33 | sean-k-mooney | so what i can do is try and reivew the code and that section again | |
| 14:39:49 | sean-k-mooney | when i got to your spec i was starting tot get review burn out | |
| 14:40:28 | bauzas | no worries | |
| 14:40:41 | bauzas | this is somehow an implementation question | |
| 14:40:59 | bauzas | I mean, testing the types is a design point | |
| 14:41:11 | bauzas | but where can be something related to the implementation | |
| 14:41:32 | bauzas | I can modify my spec accordingly | |
| 14:42:01 | sean-k-mooney | so you plan ot extend https://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L359-L362 | |
| 14:42:43 | sean-k-mooney | if check_can_live_migrate_destination was passed the currnt mdev type and uuid touple | |
| 14:42:55 | sean-k-mooney | and did the claim and populated it in migrate_data | |
| 14:43:00 | sean-k-mooney | i would be happy with that | |
| 14:43:18 | sean-k-mooney | that would be like how sriov works | |
| 14:43:42 | sean-k-mooney | what i didnt really liek about your proposal is it was only checking the types | |
| 14:45:17 | sean-k-mooney | we currntly call into the driver here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L8537-L8539 | |
| 14:45:32 | opendevreview | Merged openstack/nova-specs master: Re-propose "Add maxphysaddr support for Libvirt" for 2024.1 Caracal https://review.opendev.org/c/openstack/nova-specs/+/895135 | |
| 14:46:19 | sean-k-mooney | so you could update the in memory dict and pass back the uuids there | |
| 14:47:00 | sean-k-mooney | for sriov we do the claim here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L8563-L8565 but that is not in the driver specific section since the pci_tracker is driver independent | |
| 14:47:07 | bauzas | yeah I saw your optimization point | |
| 14:47:26 | bauzas | and yeah I saw for SRIOV | |
| 14:47:29 | sean-k-mooney | its not just optimisztion | |
| 14:47:48 | sean-k-mooney | what im hoping to prevent is racing for the same mdev betwen boots and live migrations | |
| 14:48:10 | sean-k-mooney | so if we can atomically allocate the mdev that will be used in check_can_live_migrate_destination | |
| 14:48:40 | sean-k-mooney | then i think that helps prevent a subset of possibel issues | |
| 14:48:54 | sean-k-mooney | perhaps im wrong but that was part of the motivation | |
| 14:49:09 | bauzas | oh | |
| 14:49:12 | bauzas | I see | |
| 14:49:17 | sean-k-mooney | doiong only the tyep check here seams wasteful but if we also selefct the mdev here | |
| 14:49:20 | sean-k-mooney | then im all for it | |
| 14:49:20 | bauzas | I need to remember | |
| 14:49:30 | bauzas | because I cared about the races indeed | |
| 14:49:42 | bauzas | and I wanted to reserve the mdev as close as we claim | |
| 14:50:02 | sean-k-mooney | for sriov it slight diffent as we have 3 states avaiable claimed and allocated | |
| 14:50:04 | bauzas | that's why I added the 'claim' in post_claim_migrate_data() | |
| 14:50:20 | bauzas | as it was literally just after the claim | |
| 14:50:30 | sean-k-mooney | the diffent between the later too is cliamed means the vm is not running on the node yet and allcoated is after it is | |
| 14:50:31 | bauzas | we could 'claim' those mdevs a bit ealier | |
| 14:51:09 | bauzas | but that means we would claim by check_can_live_migrate_destination() | |
| 14:51:18 | sean-k-mooney | yes | |
| 14:51:23 | sean-k-mooney | so i would like to do that | |
| 14:51:48 | bauzas | wfm | |
| 14:52:00 | bauzas | so we would return the tuple like you said | |
| 14:52:06 | bauzas | sounds good to me | |
| 14:52:08 | sean-k-mooney | ok care to update that in the spec and im happy to review | |
| 14:52:15 | bauzas | yeah, I'll try | |
| 14:52:25 | bauzas | I'm also packed with meetings the day along :) | |
| 14:52:45 | sean-k-mooney | the one i was in finished early so i had a break | |
| 14:52:52 | bauzas | happy you | |
| 14:53:14 | bauzas | next one sounds optional to me | |
| 14:53:23 | bauzas | so I'll probably have time | |
| 15:15:17 | gibi | Is it me or we don't have vTPM tempest tests? Would it be possible to run a simple server create with vTPM in the gate? | |
| 15:47:05 | bauzas | can't tell | |
| 15:48:43 | bauzas | gibi: I guess we need to use barbican for this, right? | |
| 15:48:59 | bauzas | so it would be a specific job | |
| 15:49:08 | bauzas | enabling both vTPM and barbican | |
| 15:49:20 | gibi | right it needs barbican | |
| 15:49:42 | bauzas | https://github.com/openstack/nova/blob/master/.zuul.yaml#L897C37-L897C37 | |
| 15:50:10 | bauzas | gibi: ^ | |
| 15:53:42 | bauzas | I just see barbican but without vTPM https://opendev.org/openstack/barbican-tempest-plugin/src/branch/master/.zuul.yaml#L23-L59 | |
| 15:54:40 | gibi | OK, so our default jobs does not have barbican, but we have a separate job with barbican | |
| 15:55:26 | bauzas | correct, but we run barbican jobs on our check pipeline | |
| 15:55:45 | bauzas | https://zuul.opendev.org/t/openstack/builds?job_name=barbican-tempest-plugin-simple-crypto&skip=0 | |
| 15:56:01 | bauzas | (n-v) | |
| 15:56:23 | bauzas | but I'm not able to see a single job definition setting vtpm | |
| 16:10:08 | gibi | s/doc/job/ | |
| 16:10:08 | gibi | I will try to put together a simple tempest test that boot a VM with vtpm, and put it behind a tempest feature flag. Then we can try to enable that flag in our barbican doc | |
| 16:32:52 | bauzas | sean-k-mooney: I now remember why I needed to do the claim in post_claim_migrate_data() and not in one lockstep by check_can_live_migrate_destination() | |
| 16:33:28 | bauzas | tl;dr: when we call check_can_live_migrate_destination(), we don't know neither the used mdev from the guest nor its type | |
| 16:33:38 | bauzas | we just have an instance object | |
| 16:34:06 | bauzas | so we need this kind of tic-tac-toe between dest>src>dest | |
| 16:34:39 | bauzas | call it TCP handshake :p | |
| 16:43:42 | artom | gibi, we have vTPM tests in whitebox | |
| 16:45:10 | artom | gibi, example run: https://70d77d1b8efad238ddf5-24c1b4d0bad6f112f42872ab6905686e.ssl.cf5.rackcdn.com/824772/32/check/whitebox-devstack-multinode/2a8b9df/testr_results.html | |
| 16:45:15 | gibi | nice | |
| 16:45:15 | artom | (expand the last line) | |
| 16:45:16 | gibi | thanks | |
| 16:45:45 | gibi | now I just need to figure out if we have whitebox available in our tempest container used in openstack-k8s-operators testing... | |
| 16:46:24 | artom | Out of the box? I suspect not, but hopefully they have the framework in place to add arbitrary tempest plugins | |
| 16:56:00 | gibi | artom: we will see shortly https://github.com/openstack-k8s-operators/openstack-operator/pull/589 :D | |
| 17:07:39 | sean-k-mooney | bauzas: i see. thats less then ideal but if you can docuemnt it in the spec i guess i can live with that for now | |
| 17:07:51 | sean-k-mooney | im not really sure how to adress that otherwize | |
| 17:08:16 | sean-k-mooney | im not sure we reallly need to do the mdev type check at the conducor level | |
| 17:08:27 | sean-k-mooney | but if you think it helps then ok | |
| 17:08:43 | bauzas | sean-k-mooney: I can write something indeed explaining more the ping-pong | |