Earlier  
Posted Nick Remark
#openstack-nova - 2021-02-19
16:20:10 sean-k-mooney 0437d333-a597-4d50-867e-d1bee7e4fc59 | None | a75a232f-c1df-4b71-9597-92acc8e83dad | vlan | 103 | <-- this is net3
16:20:12 gibi sean-k-mooney: give me a sec, I put up a full reproduction printouit
16:20:29 bauzas gibi: looks to me the segmentation_id on the network is a VLAN ID
16:20:32 gmann lyarwood: ack, looks ok to me, I will merge that.
16:20:45 bauzas which makes no sense on a L3
16:20:49 bauzas but whatever
16:20:56 sean-k-mooney gibi: provider:segmentation_id is not the same as the segment-id
16:21:01 bauzas my point ^
16:21:04 sean-k-mooney provider:segmentation_id is the vlan id
16:21:08 bauzas \o/
16:21:13 bauzas I'm a network expert !
16:21:14 bauzas :D
16:22:05 bauzas gibi: that being said, does https://review.opendev.org/c/openstack/nova/+/773976/10/nova/network/neutron.py#3510 returns you some segments for net3 ?
16:22:10 bauzas it shouldn't
16:22:33 sean-k-mooney gibi: so ya the neutron plugin is slightly wrong
16:22:35 bauzas gibi: could you actually issue the CLI call against net3 ?
16:22:42 sean-k-mooney but it wont break us
16:22:56 gibi http://paste.openstack.org/show/802832/
16:23:03 sean-k-mooney we are doing the right thing and only looking a subnet segment_ids
16:23:41 sean-k-mooney gibi: yep that is not a routed network
16:23:41 bauzas holy fuck
16:23:50 gibi so in that paste you see that a simple net create and subnet create result in a segment returned by the the segment list command
16:23:51 bauzas sean-k-mooney: but that's not normal
16:24:04 bauzas segment list returns the VLAN ID as segment
16:24:11 bauzas which is horribly wrong
16:24:13 sean-k-mooney ya that proably a bug
16:24:18 sean-k-mooney but we are not using that api
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

Earlier   Later