| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-19 | |||
| 16:26:57 | sean-k-mooney | actully we might be miss reading this | |
| 16:27:07 | sean-k-mooney | +--------------------------------------+------+--------------------------------------+--------------+---------+ | |
| 16:27:09 | sean-k-mooney | | ID | Name | Network | Network Type | Segment | | |
| 16:27:11 | sean-k-mooney | +--------------------------------------+------+--------------------------------------+--------------+---------+ | |
| 16:27:13 | sean-k-mooney | | 92924c05-5419-4d7a-a557-dc465a10e26c | None | bcc9a2e3-3b8e-4e4b-a3f9-0072676693d0 | vlan | 103 | | |
| 16:27:15 | sean-k-mooney | +--------------------------------------+------+--------------------------------------+--------------+---------+ | |
| 16:27:22 | sean-k-mooney | so 92924c05-5419-4d7a-a557-dc465a10e26c woudl be the segment_id | |
| 16:27:31 | sean-k-mooney | we set in the subnet | |
| 16:27:42 | sean-k-mooney | and 103 is the provider:segmenation_id | |
| 16:28:06 | sean-k-mooney | i think thats whats happening | |
| 16:28:10 | bauzas | yeah | |
| 16:28:19 | bauzas | I'm horrified | |
| 16:28:34 | bauzas | the whole semantics of a segment is borked | |
| 16:29:03 | sean-k-mooney | well kind of there was ment to be a rest api and then then decided to misuse physnets | |
| 16:29:24 | sean-k-mooney | a segment in neutron terms is very closely realted to a phsynet | |
| 16:29:28 | gibi | here is the raw REST API Call http://paste.openstack.org/show/802834/ | |
| 16:30:17 | sean-k-mooney | gibi: right but again routed networks is a misnomer | |
| 16:30:34 | sean-k-mooney | its the subnets that are routed not the networks | |
| 16:30:39 | bauzas | gibi: /me cries | |
| 16:30:48 | gibi | about the possible solution; if we can also gather the segment ids via the subnets of the network then we would be in sync with the neutron's segments plugin | |
| 16:30:51 | sean-k-mooney | bauzas: lets just avoid this api | |
| 16:31:11 | sean-k-mooney | bauzas: instead look up the subnets for a network then look up each of the segments | |
| 16:31:13 | bauzas | sean-k-mooney: sure, it's not reliable and I thank gibi for catching this weird bug | |
| 16:31:24 | gibi | so instead of list segments --network we can do list subnets --network and the interate the subnets and gather segment_id from each | |
| 16:31:33 | bauzas | yup | |
| 16:31:33 | sean-k-mooney | yep | |
| 16:31:35 | bauzas | on it | |
| 16:31:35 | gibi | sean-k-mooney: exactly | |
| 16:31:42 | sean-k-mooney | that will work just less effecient | |
| 16:31:45 | gibi | yepp | |
| 16:31:53 | sean-k-mooney | and then we can see if neutron can fix the former api | |
| 16:32:15 | bauzas | we would only leave one single method in the network.neutron API | |
| 16:32:23 | bauzas | get_segments_from_subnet() | |
| 16:32:37 | sean-k-mooney | i would keep the network on and just have it delegate | |
| 16:32:55 | bauzas | this is actually error-proof as, as sean-k-mooney said, segments are always related to subnets, not networks | |
| 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 | sean-k-mooney | bauzas: that works for me too | |
| 16:34:40 | gibi | it might be due to the fact that nova creates the port with ip_allocation=deferred | |
| 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 | 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 | |