| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-08-18 | |||
| 14:41:56 | gibi | the numa topology filter will be after my change as it calls support_request which will be a_c aware | |
| 14:42:00 | sean-k-mooney | not the ones in any one set of allcoaiton candiates | |
| 14:42:07 | sean-k-mooney | yep | |
| 14:42:13 | gibi | so it has a chance to work :) | |
| 14:42:19 | sean-k-mooney | yep | |
| 14:42:35 | sean-k-mooney | as i said we can ignor that wrinkel for now | |
| 14:42:55 | gibi | as of pool correlation with allocation candidate, I will try to add a list of RP uuids to each pool showing that where the pool gets its devices | |
| 14:43:14 | sean-k-mooney | ack. currently it shoudl be 1:1 | |
| 14:43:25 | sean-k-mooney | each pool shoudl be mapped to a singel RP correct | |
| 14:43:28 | gibi | that would be awesome if pool:RP is 1:! | |
| 14:43:29 | gibi | 1:1 | |
| 14:43:49 | gibi | I thought that VFs from two PFs might be and up in the same pool | |
| 14:43:56 | gibi | end | |
| 14:44:03 | sean-k-mooney | i think they will be two pools | |
| 14:44:07 | gibi | I will check | |
| 14:44:13 | gibi | but this sounds good at least | |
| 14:44:32 | sean-k-mooney | pools are not 1:1 to device_spec entires | |
| 14:44:33 | gibi | then I can driver the pools consumption logic based on the RP uuids in the allocation candidate | |
| 14:44:44 | sean-k-mooney | but i each PF gets its own pool | |
| 14:44:57 | sean-k-mooney | and VFs form differnt PFs are seperate | |
| 14:45:36 | sean-k-mooney | by the way if that is not thet case today i don tsee any reason we cant change it to make it 1:1 | |
| 14:45:59 | gibi | yeah that would have been my next proposal :) | |
| 14:46:52 | sean-k-mooney | the pools are stored in teh pci_stats object in the compute node recored | |
| 14:47:11 | gibi | hehe, I already have a note where to create RequestGroups from flavor https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L534-L540 | |
| 14:48:17 | sean-k-mooney | hehe ya i was expecting it to be in the request_spec object | |
| 14:48:25 | sean-k-mooney | for cpu ectra | |
| 14:48:46 | sean-k-mooney | not the scudler utils | |
| 14:50:21 | gibi | ohh, and I even tried to resolve that todo at some point https://review.opendev.org/c/openstack/nova/+/647396 | |
| 14:51:00 | sean-k-mooney | hehe you have too many commits :P | |
| 14:53:32 | gibi | OK at least the commit message confirms my current view | |
| 14:54:03 | gibi | and adding just the pci alias related groups from the flavor does not seem problematic at that point | |
| 14:55:31 | sean-k-mooney | ya we already require that the alias defienition is the same on the api and the compute nodes | |
| 14:57:50 | sean-k-mooney | actully that does not matter you are not changing the requirement | |
| 14:57:50 | sean-k-mooney | so you should be able to use the alsis form the current config safely | |
| 14:58:07 | gibi | I don't think I depend on the alias on the compute but good to know | |
| 14:58:38 | sean-k-mooney | resize required the alisa to be the same to create the correct pci requests i belive | |
| 14:59:13 | gibi | hm, interesting | |
| 15:00:06 | sean-k-mooney | i have to join a call but we have docs about it | |
| 15:01:05 | sean-k-mooney | https://docs.openstack.org/nova/latest/admin/pci-passthrough.html#configure-nova-api i think we droped the reason form the doc | |
| 15:08:19 | JayF | melwitt: ack; thank you. Assuming you are OK if I want to run with trying to get those landed? | |
| 15:09:20 | melwitt | JayF: yes, please feel free | |
| 15:09:37 | JayF | Anything else vaguely-ironic-related you want to point me at, please do | |
| 15:09:49 | JayF | I'm throwing a backport party and all patches are invited ;) | |
| 15:13:04 | melwitt | ok, can do :) | |
| 15:24:16 | opendevreview | John Garbutt proposed openstack/nova master: Ironic: retry when node not available https://review.opendev.org/c/openstack/nova/+/842478 | |
| 15:27:17 | opendevreview | John Garbutt proposed openstack/nova master: Ironic: retry when node not available https://review.opendev.org/c/openstack/nova/+/842478 | |
| 15:55:33 | opendevreview | Arnaud Morin proposed openstack/nova master: Unbind port when offloading a shelved instance https://review.opendev.org/c/openstack/nova/+/853682 | |
| 15:57:58 | amorin | hello, sean-k-mooney see ^ is a proposal for the shelved instance with bound ports | |
| 15:58:13 | amorin | I can write a unit test for this if it seems good to the team | |
| 16:12:29 | sean-k-mooney | ah you went with the flag approch rather then spliting it | |
| 16:12:39 | sean-k-mooney | ya that shoul work | |
| 16:12:48 | sean-k-mooney | ideally we woudl have both unit and funcitonal test for this | |
| 16:12:57 | sean-k-mooney | but the direction looks fine | |
| 16:13:12 | sean-k-mooney | i guess we can see what ci says | |
| 16:13:15 | sean-k-mooney | and if it breaks anything | |
| 19:11:28 | opendevreview | sean mooney proposed openstack/nova master: fix suspend for non hostdev sriov ports https://review.opendev.org/c/openstack/nova/+/841017 | |
| 19:32:31 | sean-k-mooney | dansmith: got a sec to confirm something. is bumping the compute service version and checking it in pre live migrate sufficent to assert the the source and dest supprot a feture where there are no other rpc changes required | |
| 19:32:55 | dansmith | yeah | |
| 19:33:00 | sean-k-mooney | i belive the answer is yes but just want to check before i add that and add tests | |
| 19:33:02 | sean-k-mooney | ok | |
| 19:33:44 | sean-k-mooney | its for the hot plug migration for vdpa. im addign a conductor check to bail if both host are not at the required compute service version | |
| 19:34:14 | sean-k-mooney | its what we did for sriov migration too | |
| 19:55:40 | dansmith | coo | |
| 19:55:42 | dansmith | l | |
| 19:56:54 | sean-k-mooney | https://github.com/openstack/nova/blob/e6aa6373d98103348a8ee3c59814350ea1556049/nova/objects/service.py#L34 is not where i was expecting that to be set... i was looking in the compute manager | |
| 19:57:58 | sean-k-mooney | is the service version really gobal accross the compute agent/schdluer/api ectra | |
| 19:58:04 | sean-k-mooney | i tough they all had there own version number | |
| 19:58:18 | sean-k-mooney | appart form the rpc version | |
| 19:58:20 | dansmith | it's tied to the object not the service, | |
| 19:58:37 | dansmith | and it's supposed to be global because it's kinda like a git hash.. "the code is up to this level" | |
| 19:58:48 | sean-k-mooney | ok | |
| 19:59:01 | dansmith | but within any given service (and like inside a container) it's always the same value, that's the point | |
| 19:59:20 | sean-k-mooney | ack im just tring to see where i need to bump it | |
| 19:59:33 | dansmith | there, there's only one place | |
| 19:59:42 | sean-k-mooney | cool | |
| 19:59:49 | sean-k-mooney | just making sure | |
| 20:00:04 | dansmith | it's global in the code, but set on the service record in the database when a service updates its live-ness, which is why you can check it per-binary and per-host | |
| 20:00:19 | sean-k-mooney | ah ok | |
| 20:00:54 | sean-k-mooney | so the services intialise them selevs with the current value when the prcoess starts and that is used to set the value in the db | |
| 20:01:13 | sean-k-mooney | so if a node has a differnt value in the db you know if its older or newer | |
| 20:01:33 | sean-k-mooney | i was just expecting to see th constant direcly in teh compute manger | |
| 20:07:36 | dansmith | right, but we can use service versions for any of the other services as well | |
| 20:07:42 | dansmith | so it's per-service not just for compute | |
| 20:08:39 | sean-k-mooney | yep i tought we had a sperate counter per service | |
| 20:08:48 | sean-k-mooney | but i can see why we share one | |
| 20:09:03 | sean-k-mooney | as that way we dont need to check fi schulder is x and conductor is y | |
| 20:10:26 | dansmith | you could still have that situation, of course | |
| 20:10:43 | dansmith | but instead of checking conductor_version=x, you check binary=conductor,version=x | |
| 20:11:21 | sean-k-mooney | ya you could | |
| 20:11:37 | sean-k-mooney | but at least there would be 1 x value for all serviecs for a given feature | |
| 20:13:29 | dansmith | no | |
| 20:13:42 | dansmith | if you have an old conductor and a new conductor, you could have different versions for each | |
| 20:13:54 | dansmith | it's really host=$host,binary=conductor,version=$x | |
| 20:13:54 | sean-k-mooney | that not what i ment | |
| 20:14:06 | dansmith | that's the tuple to get the version of one service on one host | |
| 20:14:16 | sean-k-mooney | i can define 62 to mean we support vdpa hotplug migration | |
| 20:14:40 | sean-k-mooney | and if that needed to be check for the compute or conductor or schduler its still just is that service >= 62 | |
| 20:15:29 | dansmith | yes, for a given host,binary pair, or (all),binary if you want to wait until they're all ready, yes | |
| 20:15:35 | sean-k-mooney | yes each service instance for the conductor might be above or below it but by having a single counter i can corralate that 62 means "support feature X" | |
| 20:15:54 | dansmith | yeah | |