| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-19 | |||
| 16:24:21 | bauzas | we do | |
| 16:24:22 | sean-k-mooney | so its not an issue | |
| 16:24:33 | bauzas | sean-k-mooney: https://review.opendev.org/c/openstack/nova/+/773976/10/nova/network/neutron.py#3510 | |
| 16:24:36 | gibi | yes nova does use segment list | |
| 16:24:40 | bauzas | we do use segment list | |
| 16:24:51 | sean-k-mooney | oh ... yes i see | |
| 16:24:52 | bauzas | gibi: could you try hitting the API directly? | |
| 16:25:02 | sean-k-mooney | well there is a way to work around it | |
| 16:25:10 | sean-k-mooney | provider:segmentation_id will always be ints | |
| 16:25:10 | gibi | (interestingly the segments plugin in neutron does not relay on the segment list of the network but rely on the segment_id attribute of the subnet only) | |
| 16:25:11 | bauzas | gibi: I'll show you the API call | |
| 16:25:21 | sean-k-mooney | and segment_ids will alwasy be uuids | |
| 16:25:24 | gibi | bauzas: I can do that | |
| 16:25:26 | bauzas | gibi: this is so fucked | |
| 16:25:55 | bauzas | gibi: please issue https://review.opendev.org/c/openstack/nova/+/773976/3/nova/network/neutron.py#3523 | |
| 16:25:59 | sean-k-mooney | gibi: yes so there is a bug in neutron but we can workaround it | |
| 16:26:38 | bauzas | sean-k-mooney: oh surely we can workaround by uuid.isuuid() | |
| 16:26:41 | bauzas | but this is crap | |
| 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 | sean-k-mooney | yep | |
| 16:31:33 | bauzas | yup | |
| 16:31:35 | gibi | sean-k-mooney: exactly | |
| 16:31:35 | bauzas | on it | |
| 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 | 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 | |