| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-19 | |||
| 16:37:11 | bauzas | back to work, focusing | |
| 16:37:38 | gibi | sean-k-mooney: yepp, but when the port is bound then the segment plugin should detect that and update placement | |
| 16:37:45 | sean-k-mooney | yes | |
| 16:37:50 | gibi | sean-k-mooney: I have to check this codepath ^^ | |
| 16:37:58 | sean-k-mooney | so the inentory of ips is not accurate | |
| 16:38:09 | bauzas | wait | |
| 16:38:13 | sean-k-mooney | although really nova should be including an ip requrest no? | |
| 16:38:15 | bauzas | I'm not used to the placement resources | |
| 16:38:18 | sean-k-mooney | in the placment query | |
| 16:38:24 | sean-k-mooney | i think that is what they are expecting | |
| 16:38:31 | gibi | sean-k-mooney: the proper solution should be IP resource request in the port for nova | |
| 16:38:34 | gibi | sean-k-mooney: but that is missing | |
| 16:38:36 | bauzas | IP addresses are modeled on which RPs ? | |
| 16:38:44 | sean-k-mooney | gibi: yep that is what i was thinking | |
| 16:38:59 | bauzas | gibi: I personnally feel that routed networks never tried to consume things | |
| 16:39:02 | gibi | sean-k-mooney: yes, inventory handling is done in neutron and they update the reserved value on the inventory | |
| 16:39:02 | sean-k-mooney | bauzas: a neutron resouce provider with mis_share_via_aggreate in teh segment aggreate | |
| 16:39:12 | sean-k-mooney | ew | |
| 16:39:22 | gibi | it is not perfect :) | |
| 16:39:31 | gibi | OK, it is a hack | |
| 16:39:35 | sean-k-mooney | ya | |
| 16:39:35 | gibi | but it sort of could work | |
| 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 ... | |