Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-08-31
15:52:16 gibi that could be
15:52:30 bauzas gibi: we already have pre-filters that add specific aggregates to verify
15:52:30 gibi but the request_level_params object should be on master I think
15:52:45 bauzas so, the problem is not how to ask placement
15:52:59 bauzas but rather, how to pass the networks to the pre-filter
15:53:36 gibi you have to pass in new information so you have to extend an passed object or pass a new object
15:53:37 bauzas gibi: see, https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/scheduler/request_filter.py#L121
15:54:00 bauzas gibi: this way, from the pre-filter, you can pass the list of aggregates to require
15:54:11 bauzas so this is a solved problem
15:54:34 bauzas but since we only have the request spec object that is passed down to the pre-filter, we need to get the networks from it
15:54:43 bauzas my proposal was to use the network metadata info
15:55:02 bauzas but we only provide a list of physnets
15:55:49 gibi so you can extend the NetworkMetadata if you wish, or you can extend the RequestLevelParams of the RequestSpec
15:56:17 bauzas or I could get the info like this https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/objects/request_spec.py#L547
15:56:35 bauzas (from the vif)
15:56:48 gibi do we have the instance info cache populated before reaching the compute?
15:57:27 bauzas no, that's only for a move op
15:57:34 bauzas AFAIK
15:57:43 bauzas anyway, I need to think about the problem more
15:57:45 gibi yeah, for the move you can reach into the info cache
15:58:36 bauzas gibi: I need to balance all the options
15:58:56 bauzas I don't want a pre-filter that would behave different between operations
15:59:16 bauzas so I literrally need to find a way to provide the required information into the request spec object directly
15:59:39 bauzas which would prevent us backports, which is a bit sad unfortunately for my company :/
16:00:36 gibi ohh, so the motivation is backportability
16:03:23 bauzas gibi: not really, I'd say the easier be the better
16:04:00 bauzas I was thinking the physnets be a clean way to do this, but given this TODO, I'm stuck
16:04:21 bauzas so, I'll just provide the networks the best way, and good bye backportability
16:04:29 gibi fixing that TODO would need also an object change I guess, so you would not gain much
16:05:28 sean-k-mooney hi so i was not following due to downstream call
16:05:57 sean-k-mooney bauzas: we cant trust the phsynets in the networking info cache if the network has multiple phsynets
16:06:09 sean-k-mooney unless we fix how we currently do the phsynet lookup
16:06:21 sean-k-mooney so that that is segment aware
16:06:39 bauzas sean-k-mooney: that was gibi's point
16:06:57 bauzas (17:08:49) gibi: bauzas: then I think you have to resolve TODO in the codepath that gather the physnets https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/network/neutron.py#L2020
16:07:02 sean-k-mooney bauzas: the physnet in the nova vif object are only correct when you have 1 phsynet and transitivly 1 segment on the network
16:07:25 bauzas sean-k-mooney: I was just looking up the network metadata
16:07:42 sean-k-mooney bauzas: right so if we resolve that todo we need also consider the inpact on sriov
16:08:11 sean-k-mooney by the way this is the issue i pointed out before. actully supporting the multi_provider_physnet extension
16:08:17 bauzas sean-k-mooney: https://review.opendev.org/#/c/749068/1/nova/scheduler/request_filter.py@286
16:08:37 bauzas sean-k-mooney: but I used the physnets because that was the quickiest path
16:08:44 bauzas since we don't pass the list of networks
16:08:50 bauzas in the request spec
16:08:54 sean-k-mooney ya so that set of phsynets is not correct for routed networks if you have more then 1 segment
16:09:01 bauzas sure
16:09:02 bauzas so
16:09:16 bauzas what I want is just a way to get a list of networks et voila
16:09:44 bauzas which means I have to augment the RequestSpec object or one of its nested children
16:09:50 sean-k-mooney the pshnets are in the segments not in the networks so you need to list the network then query neutron for the segment to get the phsynet
16:10:09 bauzas again, I don't care of the physnets
16:10:16 bauzas I want to get the segments
16:10:33 sean-k-mooney yes but neutron uses physnets to map host to segments
16:10:44 sean-k-mooney but yes you want the segment
16:11:02 bauzas sean-k-mooney: we have a neutron API for getting the segments that are related to either a network or a physnet
16:11:29 bauzas the original proposal from matt was to get the networks and ask neutron to give the segments
16:11:37 sean-k-mooney yes
16:11:38 bauzas this was easy since he wrote that in the conductor
16:11:51 bauzas and then we directly have the requested networks (or ports)
16:12:02 bauzas but here, we want to make it more generic in a pre-filter
16:12:19 bauzas and in my case, I only have the requestspec object this is passed as argument
16:12:29 bauzas good bye networks and ports
16:12:49 bauzas sean-k-mooney: see my problem and why I went using the physnets ?
16:13:12 sean-k-mooney bauzas: yep i know but just to be clear this will only work for existing vms
16:13:21 sean-k-mooney you cant use phsynets for booting new vms
16:13:48 bauzas sean-k-mooney: well, I can see us populating the network metadata object when creating the instance
16:14:21 bauzas https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/network/neutron.py#L2082
16:14:25 bauzas but either way
16:14:39 sean-k-mooney when we create teh port with ip allocation policy deffer it wont be bound to a segment or phsynet yet
16:14:40 bauzas I need a way to pass down the requested networks
16:15:38 sean-k-mooney yes
16:16:35 sean-k-mooney so you eighter need to add the requested networks to the resquest spec or to the network_metadta or just add the instnace object but i know we have said no to the instance in the past
16:16:50 sean-k-mooney or jsut pass the instance to the prefilter
16:18:32 sean-k-mooney we dont actully have the instance object where this is called https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/scheduler/manager.py#L150
16:19:01 bauzas sean-k-mooney: right, because that's in the scheduler
16:19:31 bauzas sean-k-mooney: a simple approach would be to mention the requested networks on the main request spec object
16:19:33 sean-k-mooney sure but the fact we are in schduling means the object exists
16:19:42 sean-k-mooney bauzas: yes
16:19:54 bauzas sean-k-mooney: do you think we would persist those ?
16:20:18 bauzas or should we guess them for a move operation ?
16:20:36 sean-k-mooney the requested networks
16:20:39 bauzas yes
16:20:46 bauzas this is risky
16:20:57 sean-k-mooney if we add them to the request spec and use them we need to update them when we add or remove interfaces
16:21:13 bauzas only when you want a scheduling decision
16:21:13 sean-k-mooney oh
16:21:22 bauzas so, yeah we need to recalculate them
16:21:28 sean-k-mooney is the network info cache populated yet
16:21:36 bauzas no, I don't think
16:21:36 sean-k-mooney we have the instance uuid right
16:21:41 sean-k-mooney damb
16:21:46 bauzas sean-k-mooney: only for the first instance
16:22:14 bauzas sean-k-mooney: but I'd say, just populate this field at boot time based on the base options
16:22:20 sean-k-mooney well select destinations has instance_uuids
16:22:28 bauzas sean-k-mooney: and for a move, just try to get them from the info cach
16:23:00 bauzas sean-k-mooney: I don't want to add a new arg to the filter
16:23:10 bauzas sean-k-mooney: all of this needs to be in the request spec
16:23:13 bauzas but I get your point
16:23:40 sean-k-mooney well we can update the request_spec.instance_uuid field
16:23:48 bauzas we could get the requested networks from the info cache in the scheduler, add them on the fly before calling the pre-filter and wipe them after
16:23:56 bauzas oh please no

Earlier   Later