Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-07-30
15:17:49 stephenfin sean-k-mooney: oh yeah, I understand and agree with the feature as a whole. It's just this trait bit that's tripping me up
15:18:11 sean-k-mooney stephenfin: right now if we said we want strict affinity we have no way to guarrentee that
15:19:14 sean-k-mooney becasue placment if limit=10 could select 10 allocation candated form host that dont supprot numa affinity
15:19:33 sean-k-mooney the trait is basicaly to make it work in deployment like cerns where they have a really low limit
15:19:47 stephenfin the solution to that is NUMA in placement though, no?
15:19:52 sean-k-mooney no
15:20:12 stephenfin model NUMA nodes as RPs in placement. Say all resources must share the same root RP (NUMA node)
15:20:14 sean-k-mooney numa in placmnet wont advertise which host have numa aware vswitches
15:20:40 sean-k-mooney since we dont model netowrk backend ports as a resouce
15:21:32 sean-k-mooney stephenfin: we would some how have to model the pysnet numa affinity in the rp tree
15:21:58 ralonsoh we have this information in nova
15:22:09 sean-k-mooney yes but we cant model it in plamcnet
15:22:10 ralonsoh more or less: you have the numa nodes of a physnet
15:22:13 stephenfin sean-k-mooney: how does this help?
15:22:26 sean-k-mooney it just allow me to know the host has the feature
15:22:41 sean-k-mooney i guess we could have 3 different tratis.
15:23:02 sean-k-mooney one for numa-vsiwthc, one for sriov and one for numa affinity
15:23:06 sean-k-mooney but that feels messy
15:23:25 stephenfin You mean it has the NUMA-aware vSwitches feature enabled?
15:23:31 sean-k-mooney yes
15:23:40 openstackgerrit Jie Li proposed openstack/nova-specs master: add volume backed server rebuild spec https://review.opendev.org/739349
15:23:56 sean-k-mooney if it was a non sriov port and it asked for strict affinity
15:24:04 sean-k-mooney it need to land on a host with numa aware vswtichs
15:24:08 sean-k-mooney or we shoudl reject it
15:24:31 sean-k-mooney legacy and prefer not require that
15:24:46 sean-k-mooney but strict means we have to guarrente numa affinity or not boot
15:25:13 sean-k-mooney we can do that in the numa toplogy filter proably
15:25:25 sean-k-mooney but then you have the cherry picking problem
15:25:57 stephenfin so you're worried about NUMA-aware vSwitches being configured on some hosts and not others, and you want to makes sure instances never land on the latter
15:26:08 sean-k-mooney yes
15:26:33 stephenfin The concern I have with that is that NUMA-aware vSwitches is a hack, and we knew it was a hack when we implemented it /o\
15:26:55 sean-k-mooney yes we wanted to evnetually move it to placment
15:26:58 stephenfin and I'm concerned about encoding that hack into traits, which we can't ever drop
15:27:17 sean-k-mooney we dont actully need the traits right now
15:27:17 stephenfin couldn't we just solve that particular issue with documentation?
15:27:23 sean-k-mooney so we can defer it
15:27:39 sean-k-mooney i wanted neutron to include the trait in the port resouce request
15:27:51 sean-k-mooney but we can have nova append it in the future if we want
15:27:56 stephenfin i.e. if you really care about NUMA affinity, make sure to configure this on all hosts or use host aggregates to separate from hosts without the config
15:28:24 sean-k-mooney maybe it kind of feells like soemthing that should not need to be manual
15:28:49 stephenfin I agree, but you could say the same about the NUMA-aware vSwitches feature in general
15:29:00 sean-k-mooney we did
15:29:04 stephenfin True :)
15:29:10 sean-k-mooney be we also said we did not want to wait
15:29:13 stephenfin but it was a means to an end
15:29:14 stephenfin yup
15:29:36 stephenfin I don't really want to pile more on top of that shaky foundation though
15:29:48 stephenfin like I said, we're stuck with traits once they're there
15:29:52 sean-k-mooney ralonsoh: stephenfin ok so do we want to put the traits on pause untill we see if we will use them in the nova half of the feature
15:30:08 ralonsoh sean-k-mooney, np
15:30:14 sean-k-mooney ralonsoh: what that means for you is you just dont need to add a trait request to the port
15:30:15 stephenfin if that works for ralonsoh, I'd much rather that
15:30:35 sean-k-mooney and if nova want to use the traits in the futrue we can do it instead of neutorn
15:30:38 ralonsoh sean-k-mooney, but what should I add to the port info?
15:30:39 stephenfin if it turns out we want a way to advertise these capabilities, then I'm all for revisiting
15:30:52 ralonsoh because I don't know how nova is going to read it
15:31:02 sean-k-mooney ralonsoh: neutron need to add the polciy via the new extention
15:31:09 sean-k-mooney but it does not need to add the trait
15:31:26 sean-k-mooney the extenion was adding a new extended atibute to the port anyway right
15:31:26 ralonsoh sean-k-mooney, that means another parameter in the port dict
15:31:27 ralonsoh ok
15:31:41 ralonsoh I'll need to revisit the spec
15:31:42 sean-k-mooney ralonsoh: yes isnt that what the spec says
15:32:36 stephenfin ralonsoh: again, apologies for only getting to this now. I didn't know that this work was as far along as it is. You've been busy :)
15:32:39 sean-k-mooney https://specs.openstack.org/openstack/neutron-specs/specs/victoria/port-numa-affinity-policy.html#rest-api-impact
15:32:48 ralonsoh np at all
15:32:55 ralonsoh I'll revisit the spec and the patches
15:32:59 sean-k-mooney oh its in the resouce attibute
15:33:19 sean-k-mooney sorry no that is just an extend port attibute
15:33:48 sean-k-mooney so im not sure you need to updat ehte spec other then to remove the port_resource['resource_request'] = {
15:33:51 sean-k-mooney 'required': [os_traits.COMPUTE_NUMA_POLICY_REQUIRED]}
15:33:53 sean-k-mooney bit
15:34:14 ralonsoh sean-k-mooney, I need to clean up this part yes
15:34:28 sean-k-mooney nova will just read numa_affinity_policy field form the port and use that
15:34:40 ralonsoh perfect for me
15:34:51 sean-k-mooney ralonsoh: i was worried that you were only going to pass the trait
15:35:10 sean-k-mooney ralonsoh: that would not have been right from a nova point of view
15:48:52 sean-k-mooney stephenfin: by the way you also missed the mix hypervior usecase for the trait
15:49:24 sean-k-mooney but we can cross that bridge if we need too
16:01:05 openstackgerrit Pavlo Shchelokovskyy proposed openstack/nova master: Raise 409 when removing security group from instance https://review.opendev.org/735572
16:06:58 openstackgerrit sean mooney proposed openstack/nova master: Lookup nic feature by PCI address https://review.opendev.org/739131
16:07:53 sean-k-mooney ralonsoh: stephenfin by the way should i drop the funcitonal tests form the coverage job or make a coverage with sudo job for os-vif https://review.opendev.org/#/c/728037/4/.zuul.yaml
16:08:10 stephenfin drop from coverage
16:08:14 stephenfin imo
16:08:26 sean-k-mooney cool i can do that trivially
16:08:37 ralonsoh sean-k-mooney, why do you need to drop them?
16:08:50 sean-k-mooney the openstack-cover-jobs
16:08:55 sean-k-mooney does not allow sudo to be used
16:09:00 ralonsoh right
16:09:06 sean-k-mooney so privsep fails
16:09:33 sean-k-mooney our functional tests actully need elevated right to run
16:09:37 sean-k-mooney becaue they acutlly use ovs
16:09:50 sean-k-mooney which actully is alos not in stalled in that job
16:10:25 sean-k-mooney so ya if i want to run them i need a custom job that has sudo and installs ovs like our custom functional job
16:10:44 ralonsoh sean-k-mooney, you can take the neutron functional base one
16:10:48 ralonsoh if you want
16:11:16 sean-k-mooney no we have a base job for fucntional test
16:11:29 sean-k-mooney openstack-tox-functional-ovs-with-sudo
16:11:39 ralonsoh or this one yes
16:12:05 sean-k-mooney but i either need to inherit form that and chagne the env form functional to cover

Earlier   Later