Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-02-19
16:39:40 bauzas I'm lost
16:39:50 sean-k-mooney i think this is next cycles problem
16:40:02 sean-k-mooney bauzas: i think we can ignore that for now
16:40:12 gibi sean-k-mooney: definetly. I don't want to do anything with the resource allocation now
16:40:25 gibi just want to see that the segments plugin works end to end as is today
16:40:50 sean-k-mooney bauzas: tl;dr neuton update reserved value in ip address inventoy instead of adding a resouce request but lets not fix that this cycle
16:41:00 gibi ^^ yes
16:42:15 sean-k-mooney bauzas: so for now i gues the plan is. drop the get segmens by networks funcion in neutorn.py update the utils funciton to look up the subnets then look up the segments
16:42:39 bauzas OK, I'm then on track
16:42:40 sean-k-mooney and preten the neutron api and ip issue are not a thing untill next cycle
16:43:09 bauzas yup, again, routed networks is just a scheduling feature, not a consuming feature
16:43:26 sean-k-mooney gibi: correct me if im wrong but neturon can fix the ip thing entirely on there end right. just stop updated reserved and ask for the ip class in the port resouce request
16:43:28 bauzas meaning, a trick to hack the destination, not a trick to consume resources on the destination
16:43:43 gibi bauzas: correect
16:43:43 sean-k-mooney bauzas: it was ment to do both
16:43:47 sean-k-mooney evenually
16:43:48 gibi for now
16:43:53 bauzas and I know there are those two aspects in placement, but these are separate
16:44:08 sean-k-mooney bauzas: right but both are modeled
16:44:11 bauzas sean-k-mooney: agreed, but with placement, you can do both
16:44:19 bauzas hence the confusion
16:44:33 bauzas and agreed, this is a pure technical limitation
16:44:43 bauzas we could be smarter (c)
16:45:02 gibi sean-k-mooney: about the fix in a future cycle. yes, neutron should include an IP resource request to the port for a port that was expected to consume an ip address.
16:45:07 bauzas and hopefully, can fire the new revision before we all duck out
16:45:20 gibi sean-k-mooney: the question for me how to decide if an ip_allocation=deferred port will consume an ipv4 address or not
16:45:41 gibi it depends on which subnet / segment the port will be bound to
16:45:56 sean-k-mooney gibi: well it will always consume an ip but ipv4 vs v6 is tricky if it has both
16:45:57 gibi but binding is too late, at that point everyting is already consumed in placement
16:46:35 sean-k-mooney for port that are cretaed on a subnet its simper for one created on a netwrok i guess they will have to limit route netwok to one ip class?
16:46:46 sean-k-mooney e.g. ipv4 or ipv6 only
16:46:50 gibi sean-k-mooney: yes, if there are ipv4 subnet on one segment connected to host A and an ipv6 subent on another segment connected to host B then the resource request cannot be decided before the binding
16:47:23 sean-k-mooney gibi: perhaps the port need to have a ip version field as part of the request
16:47:33 sean-k-mooney e.g. when you do the prot create
16:48:01 sean-k-mooney if you want ot ues routed networks and not specify a fix ip or subnet require an ip version to be set
16:48:02 gibi hm, but how to fill that resevation when the port is created by nova?
16:48:18 gibi so the answer is routed nets only work with port :)
16:48:31 sean-k-mooney ya maybe
16:48:50 gibi this would not be the first feature that only works with precreated ports :)
16:48:52 sean-k-mooney i dont know but future us problem not now us problem right :)
16:48:56 gibi sure
16:49:10 sean-k-mooney true sriov/qos
16:49:51 sean-k-mooney gibi: there is alwasy the long awatied "create ports in the conductor" feature
16:50:08 sean-k-mooney although that proably wont help much
16:51:06 gibi it is awaited yes, and it won't help here much yes :)
16:59:31 bauzas sean-k-mooney: I'm tempted to directly get the segments when calling the list of subnets
16:59:44 bauzas since the segment ID can be part of the result
16:59:55 bauzas https://docs.openstack.org/api-ref/network/v2/index.html?expanded=list-subnets-detail#subnets
17:00:14 sean-k-mooney yes
17:00:14 bauzas this would prevent extra HTTP roundtrips
17:00:33 sean-k-mooney that will work if you can filter that by network which i assume you can
17:01:06 sean-k-mooney ya network_id is optional
17:01:13 bauzas technically, one is a query parameter, the other is a result field
17:01:28 bauzas and yeah, we can filter using network_id
17:01:39 sean-k-mooney yep so that works
17:01:55 bauzas so we can say something like list_networks(network_id=myid, fields=['segment_id']
17:02:08 sean-k-mooney you can loop over the subnets in python with a list comprehention and produce a list of segment ids
17:02:09 bauzas this would give us the list of segments the network relates to
17:02:31 bauzas there is the fields param that does me for free :)
17:02:43 sean-k-mooney true
17:03:05 bauzas so this would actually be a rewrite of get_segment_ids_for_network()
17:03:13 bauzas and I would keep the method
17:03:18 bauzas at least its signature
17:03:28 bauzas tempting
17:03:43 sean-k-mooney so really its just GET /subnet?network_id=<id>&fileds=segment_id
17:03:48 bauzas yup
17:03:53 bauzas gibi: opinions on it ?
17:04:22 sean-k-mooney maybe keep both funciton in neutorn.py then
17:04:35 sean-k-mooney just change the url
17:05:23 bauzas yah
17:06:19 sean-k-mooney ok so you just need to update https://review.opendev.org/c/openstack/nova/+/773976/10/nova/network/neutron.py#3510
17:06:29 sean-k-mooney that sound good to me
17:06:53 sean-k-mooney gibi: that is a really good catch by the way
17:07:55 gibi "GET /subnet?network_id=<id>&fileds=segment_id" looks good to me
17:08:18 bauzas gibi: can you please tell me what gives you the segment_id field on a non-configured subnet ?
17:08:32 bauzas the field is empty or unexisting ?
17:08:46 bauzas the API docs is not describing it
17:09:37 gibi bauzas: trying ...
17:09:43 bauzas thanks
17:09:47 bauzas I really need to get some env
17:10:27 sean-k-mooney http://paste.openstack.org/show/802840/
17:11:37 gibi bauzas: the above GET results in http://paste.openstack.org/show/802841/ if the subnet has a segment_id set
17:11:38 sean-k-mooney so it looks like if the extnsion is not there its an error
17:11:48 gibi bauzas: will check the no segment_id case in a sec
17:11:49 sean-k-mooney but we have the check for that so it should be fine
17:12:06 sean-k-mooney gibi: im expecting an empty list
17:12:42 bauzas sean-k-mooney: your paste probably doesn't have the extension
17:12:45 sean-k-mooney so proably {"subnets":[]}
17:12:53 sean-k-mooney bauzas: it does not
17:13:06 sean-k-mooney bauzas:which is why i said we just need to keep the extension test
17:13:13 sean-k-mooney *check
17:13:21 bauzas sean-k-mooney: yup, I just changed one liner
17:13:29 bauzas ie. the Neutron client call
17:13:34 gibi bauzas: and this is the case when the subnet has no segment_id set http://paste.openstack.org/show/802842/
17:13:59 sean-k-mooney oh its null
17:14:10 sean-k-mooney {"subnets":[{"segment_id":null}]}
17:14:12 bauzas perfect
17:14:23 gibi so you get a list of subnets and for each subnet you get a segment_id which is either null or a uuid
17:14:24 bauzas the client will then return None
17:14:35 bauzas right, it's not a list

Earlier   Later