| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-10 | |||
| 12:34:45 | sean-k-mooney | yep | |
| 12:34:52 | sean-k-mooney | so we allow shelve now https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4169 | |
| 12:35:15 | sean-k-mooney | if the compute service version is new enough | |
| 12:36:34 | sean-k-mooney | alex_xu: ok what we can do is proceed as it is | |
| 12:37:08 | sean-k-mooney | and when i submit the patch to block shelve for sriov instance with a workaoutnd config option i can include cyborg too | |
| 12:37:51 | sean-k-mooney | infact it will do it for both automaticlly | |
| 12:37:59 | alex_xu | ok, so we want a explictly block for shelve instance? | |
| 12:38:13 | sean-k-mooney | i was just going to check if any of the port vnic types were in VNIC_TYPES_DIRECT_PASSTHROUGH which the cyborg ones are | |
| 12:38:53 | sean-k-mooney | yes becuse a vm form one tenatn can break another tenat by unshelving | |
| 12:39:37 | sean-k-mooney | so like numa migration i want to block shelve for all instance using neutron sriov port with a [workaround]/allow_unsafe_shelve to renable it and backprot that | |
| 12:39:44 | sean-k-mooney | then i plan to fix it as a bug | |
| 12:40:06 | sean-k-mooney | so we can fix shleve for both sriov and cybrog by ensuring the port profile si updated for the new arq | |
| 12:40:33 | sean-k-mooney | so i planned to return a 403 permission deined | |
| 12:41:11 | sean-k-mooney | unless you had [workaround]/allow_unsafe_shelve=true or you had a fixed verion of nova | |
| 12:41:34 | sean-k-mooney | alex_xu: does that sound resaonable? | |
| 12:41:50 | sean-k-mooney | gmann: ^ that should be ok form the api point of view yes? | |
| 12:42:19 | sean-k-mooney | gmann: the exisitng issue for sriov ports is a long term bug so i dont want to have to make an api micorverion bump for that | |
| 12:42:50 | sean-k-mooney | 403 can be retruned form this already and i think that should be valid? | |
| 12:43:50 | alex_xu | sean-k-mooney: or we have a check whether instance have a port with device profile? then we needn't an workaround option | |
| 12:43:57 | sean-k-mooney | gmann: the current block we have uses https://github.com/openstack/nova/blob/ab07507e5cfce6232fef373d07ff92ea704541da/nova/exception.py#L158-L159 | |
| 12:44:27 | sean-k-mooney | alex_xu: i want the workaound for people that are using this with sriov today | |
| 12:44:47 | sean-k-mooney | alex_xu: i know that it currenlty does the wrong thing and you can end up using the wrong device | |
| 12:44:53 | sean-k-mooney | which is why i want to blcok it | |
| 12:45:16 | sean-k-mooney | but we have had custoemr manually update the port profile and hard reboot the instace to match the claimed device | |
| 12:45:31 | sean-k-mooney | its a horable hack but they really wanted to keep shelve | |
| 12:45:47 | alex_xu | sean-k-mooney: ok, got it | |
| 12:45:55 | sean-k-mooney | so if they want to shoot them selves in the foot then that is what the workaroudn is for | |
| 12:46:25 | alex_xu | ok | |
| 12:47:03 | sean-k-mooney | alex_xu: if your ok with handeling the shelve issue this way i guess im ok with using the requeted_networks for now | |
| 12:47:11 | sean-k-mooney | and the port profile | |
| 12:47:16 | alex_xu | sean-k-mooney: yes, I'm ok with that | |
| 12:47:49 | alex_xu | then we need to wait yonglihe back, he is going to take his boy back from school :) | |
| 12:49:09 | sean-k-mooney | ill go link this converation to the gerrit review | |
| 12:49:32 | alex_xu | cool | |
| 12:50:58 | sean-k-mooney | im more or less ok with the patch other then that but still want to see if gibi is ok with defining the constanct before they are need | |
| 12:51:52 | alex_xu | yea, definitely need gibi's feedback | |
| 12:51:55 | sean-k-mooney | we may also need some extra test coverage for the vnic_types i havent fully review the last patch | |
| 13:07:21 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP zuul: Replace grenade and nova-grenade-multinode with grenade-multinode https://review.opendev.org/c/openstack/nova/+/778885 | |
| 13:18:55 | sean-k-mooney | artom: so since your pci socket policy patch conflit with both my port numa patch and vdpa series we proably should set them up in a chain | |
| 13:19:28 | artom | sean-k-mooney, sure. Which one of yours is more likely to land at this point? | |
| 13:19:36 | artom | I guess put that one on top of my socket stuff? | |
| 13:19:37 | sean-k-mooney | vdpa obviously goes at the end since that is the lesast likely to be ready | |
| 13:19:45 | artom | Yeah, what I thought :) | |
| 13:19:51 | sean-k-mooney | ya the port numa one | |
| 13:20:15 | artom | I'm in the process of adding some patches to my series, I'll let you know when it's pushed? | |
| 13:20:54 | sean-k-mooney | would you be oke putting your patch on top of the port numa one? if i rebase it on top of master to pic up the patches of your that already merged | |
| 13:21:45 | sean-k-mooney | hum i guess yours already had 2 +2s buyt you need to change it for the multi socket thing | |
| 13:22:16 | sean-k-mooney | i dont think there are outstanding quesion left for mine. | |
| 13:22:24 | artom | sean-k-mooney, mind linking your series? | |
| 13:22:45 | sean-k-mooney | its one patch or the prot numa polices https://review.opendev.org/c/openstack/nova/+/773792 | |
| 13:22:47 | artom | Ah, there's only the one? https://review.opendev.org/c/openstack/nova/+/773792 | |
| 13:23:12 | sean-k-mooney | ya i should have a second for numa vswitch but i wont get to that until next cycle so just one for sriov | |
| 13:23:43 | artom | There aren't serious conflicts there, though | |
| 13:23:44 | sean-k-mooney | i was going to say maybe defer to stephenfin and gibi for order | |
| 13:23:57 | artom | Maybe some trivial "context code" in the tests | |
| 13:23:58 | sean-k-mooney | correct its minor | |
| 13:24:09 | sean-k-mooney | just dont wnat them to fight in the gate | |
| 13:24:21 | sean-k-mooney | sicne one of the two will merge first | |
| 13:24:30 | sean-k-mooney | and the other need to be respun | |
| 13:24:46 | artom | sean-k-mooney, lemme drop the kids off | |
| 13:24:51 | artom | Back in ~1 hour | |
| 13:26:09 | sean-k-mooney | sure ill wait for stephenfin or gibi to comment and ill do whatever they say | |
| 13:26:36 | sean-k-mooney | if they say put user first ill rebase on top of https://review.opendev.org/c/openstack/nova/+/772779 | |
| 13:43:03 | stephenfin | sean-k-mooney: what's the question? | |
| 13:44:47 | sean-k-mooney | stephenfin: artoms socket patch conflict with both my port numa and vdpa patches so i thin we need to stack them | |
| 13:45:05 | sean-k-mooney | stephenfin: question is port numa first or socket | |
| 13:45:11 | sean-k-mooney | with vpda last | |
| 13:45:21 | stephenfin | socket | |
| 13:45:23 | stephenfin | it's closest to merge | |
| 13:45:27 | stephenfin | in fact it's approved | |
| 13:45:40 | sean-k-mooney | right but ig cant merge since it broken | |
| 13:46:03 | stephenfin | huh? | |
| 13:46:04 | sean-k-mooney | artom need to fix suport form multipel socekt on one numa node | |
| 13:46:17 | sean-k-mooney | by making it a list and taking the first socket | |
| 13:46:26 | sean-k-mooney | to make it work in the gate vms | |
| 13:46:31 | stephenfin | can't that be a follow-up? | |
| 13:46:48 | stephenfin | as it's an edge condition | |
| 13:46:54 | sean-k-mooney | i gues but i also am not happy with the numa topology object being passed as a copy to the pci tracker | |
| 13:46:59 | stephenfin | is there real hardware with that design, out of curiosity? | |
| 13:47:11 | sean-k-mooney | we should have passed a dict of numa:socket | |
| 13:47:16 | stephenfin | yeah, neither was I but I couldn't find a better way | |
| 13:47:21 | stephenfin | that not much better | |
| 13:47:30 | sean-k-mooney | well we should have passed it to the function | |
| 13:47:31 | stephenfin | it's still information that can get out of sync | |
| 13:47:39 | sean-k-mooney | that cant | |
| 13:47:57 | sean-k-mooney | we dont supprot memory hotplug on the compute host | |
| 13:48:00 | stephenfin | and the NUMATopology can, for what we need? | |
| 13:48:09 | sean-k-mooney | so the numa node to sockt mapping wont get out of daty | |
| 13:48:13 | stephenfin | *what we need it for there? | |
| 13:48:24 | sean-k-mooney | stephenfin: its a copy so the pinned cpus and mempages wil be out of date | |
| 13:48:34 | stephenfin | but we don't use that, right? | |
| 13:48:56 | stephenfin | so we're simply passing too much information, some of which will get out-of-date | |
| 13:48:59 | sean-k-mooney | right but we dont have any comment stating that it will be incorrect and if we started trying to use it it could break | |
| 13:49:07 | sean-k-mooney | stephenfin: yep | |
| 13:49:14 | stephenfin | okay, fair | |
| 13:49:33 | stephenfin | I'm happy to look at alternatives so | |
| 13:49:47 | sean-k-mooney | i would have prefered not to store it in the class too and pass it to the filter evne if that involed passing it donw the layres but the too mugh datat it my main concnern | |
| 13:49:48 | stephenfin | but I wouldn't block on it, because of how close feature freeze is | |
| 13:50:07 | stephenfin | yeah, artom and I went over that in the review | |
| 13:50:12 | sean-k-mooney | ya so we coudl reduce the amount of data we pass in a folowup | |