| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-19 | |||
| 16:33:04 | bauzas | and getting segments from the network are actually a shortcut | |
| 16:33:12 | sean-k-mooney | yep it was | |
| 16:33:20 | sean-k-mooney | but it should have been a valid one | |
| 16:33:42 | bauzas | sean-k-mooney: well, I prefer to stick with one single method in neutron.py and be smarter in the utils module | |
| 16:33:45 | gibi | I don't want to push you into more despair but I also see isses with the actual inventory handling on neutron side. When a port is created in the routed net the segments plugin expected to chang the IP inventory in placement as the port now reserved an ip address. However for some reason when the plugin gets the port created event it sees a port without fixed ip and then decides that this port does | |
| 16:33:51 | gibi | not consume IP | |
| 16:34:29 | sean-k-mooney | https://docs.openstack.org/api-ref/network/v2/?expanded=list-segments-detail#list-segments | |
| 16:34:40 | gibi | it might be due to the fact that nova creates the port with ip_allocation=deferred | |
| 16:34:40 | sean-k-mooney | bauzas: that works for me too | |
| 16:34:54 | bauzas | gibi: call my president and ask him to open the skilift, and then I won't be despressed | |
| 16:35:15 | sean-k-mooney | gibi: i dont think they have implement that yet have they | |
| 16:35:20 | sean-k-mooney | ips in placment | |
| 16:35:28 | gibi | bauzas: sorry, I have no power over France | |
| 16:35:34 | gibi | sean-k-mooney: they did | |
| 16:35:35 | sean-k-mooney | i suggested this a few cycle ago but never saw it get done | |
| 16:35:39 | sean-k-mooney | ok cool | |
| 16:35:42 | gibi | sean-k-mooney: it just not the good way | |
| 16:35:45 | bauzas | gibi: ask your president to invade my country then | |
| 16:35:59 | gibi | bauzas: we are weak | |
| 16:36:05 | gibi | bauzas: you have nukes man | |
| 16:36:18 | sean-k-mooney | gibi: its not adding an ip because its has ip-allocation=defer | |
| 16:36:21 | gibi | sean-k-mooney: they only implemented via inventory handling not allocation handling | |
| 16:36:26 | bauzas | gibi: you were ruling Central Europe for more than 400 years, you can certainly do things | |
| 16:36:33 | sean-k-mooney | so the ip is only consumed when the port is bound | |
| 16:36:48 | gibi | bauzas: a that time we had horses and bows, that does not work well against nukes | |
| 16:36:51 | gibi | :D | |
| 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 | sean-k-mooney | bauzas: a neutron resouce provider with mis_share_via_aggreate in teh segment aggreate | |
| 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: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 | gibi | but it sort of could work | |
| 16:39:35 | sean-k-mooney | ya | |
| 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 | sean-k-mooney | bauzas: it was ment to do both | |
| 16:43:43 | gibi | bauzas: correect | |
| 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 | bauzas | this would prevent extra HTTP roundtrips | |
| 17:00:14 | sean-k-mooney | yes | |
| 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 | |