| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-11 | |||
| 14:17:20 | sean-k-mooney | no that would change the ip | |
| 14:17:36 | sean-k-mooney | segment are mapped to subnets | |
| 14:17:43 | bauzas | look at https://review.opendev.org/c/openstack/nova/+/749068/6/nova/scheduler/request_filter.py#316 | |
| 14:17:48 | sean-k-mooney | so changing a the segment changes the subnet | |
| 14:17:59 | bauzas | we get the all aggregates for the same network | |
| 14:18:09 | sean-k-mooney | yes that is for boot | |
| 14:18:33 | sean-k-mooney | for move opertation you have to get the aggreate for the current segment | |
| 14:18:37 | bauzas | okay, but then for moves, we should only ask for the existed aggregate then | |
| 14:18:42 | bauzas | hmmmm, ok | |
| 14:18:52 | bauzas | then we need to change this | |
| 14:19:27 | bauzas | there are no ways to have different behaviours for request filters | |
| 14:19:31 | sean-k-mooney | ya sorry for not seeing that before. we allso will need to add a 4th host that is connected to the same segment as host2 | |
| 14:20:15 | sean-k-mooney | bauzas: well if the port has an ip then you know its a move operation or they specified an ip | |
| 14:20:32 | sean-k-mooney | in both cases you need to limit the aggreates to the segment corresponing to that ip | |
| 14:20:36 | bauzas | sean-k-mooney: aaaaaah yeah | |
| 14:20:41 | bauzas | L310 then | |
| 14:20:44 | sean-k-mooney | so that can be your check i belive | |
| 14:20:58 | bauzas | yeah okay | |
| 14:21:11 | bauzas | then I need to know how to get the segment for the port | |
| 14:21:31 | bauzas | lemme look if we have it | |
| 14:21:34 | sean-k-mooney | you get the via the subnet the ip is from | |
| 14:21:42 | sean-k-mooney | then you can get the segment form the subnet | |
| 14:21:46 | bauzas | mmmm | |
| 14:22:03 | sean-k-mooney | i belive the port will have a subnet id in it | |
| 14:22:17 | bauzas | hopefully yeah IIRC | |
| 14:22:41 | gmann | gibi: ack, will check today | |
| 14:22:47 | gibi | thanks | |
| 14:23:33 | gmann | scenario tests should not have this error as Tempest explicitly pass the net id but I will debug if something else causing this or we miss some tests | |
| 14:23:41 | sean-k-mooney | bauzas: let me know if you have any issues with that and i can look into that more closely if needed | |
| 14:25:04 | bauzas | to know whether we can the segment from the subnet | |
| 14:25:21 | bauzas | as we already get the one from the network | |
| 14:25:35 | bauzas | actually wait | |
| 14:25:46 | sean-k-mooney | https://docs.openstack.org/api-ref/network/v2/index.html?expanded=list-subnets-detail#id263 | |
| 14:25:46 | bauzas | sean-k-mooney: I don't think we need to call Neutron for this | |
| 14:26:05 | sean-k-mooney | segment_id is there | |
| 14:26:21 | bauzas | sean-k-mooney: we could just get the network related to the subnet and lookup all the segments in this to match the related subnet | |
| 14:26:44 | bauzas | see my point ? | |
| 14:26:58 | sean-k-mooney | you could but that is more calls to neutron | |
| 14:27:02 | bauzas | no | |
| 14:27:03 | bauzas | https://review.opendev.org/c/openstack/nova/+/749068/6/nova/network/neutron.py | |
| 14:27:12 | bauzas | we already get all the segments | |
| 14:27:49 | sean-k-mooney | ah right | |
| 14:27:54 | bauzas | in https://review.opendev.org/c/openstack/nova/+/749068/6/nova/scheduler/utils.py we ask the network | |
| 14:27:57 | sean-k-mooney | so just filter them | |
| 14:28:01 | bauzas | so we get all the segments | |
| 14:28:05 | bauzas | and then we filter them | |
| 14:28:07 | bauzas | yeah | |
| 14:28:24 | bauzas | okay, I think it's simple to fix then | |
| 14:28:34 | sean-k-mooney | unfortunetly the segment dont have the subnet id | |
| 14:29:28 | bauzas | we have the subnet name | |
| 14:29:39 | bauzas | and the id actually | |
| 14:29:40 | sean-k-mooney | it does not have that eitehr | |
| 14:29:42 | sean-k-mooney | https://docs.openstack.org/api-ref/network/v2/index.html?expanded=show-segment-details-detail#show-segment-details | |
| 14:30:10 | bauzas | https://docs.openstack.org/api-ref/network/v2/index.html?expanded=list-subnets-detail#id264 is what we get | |
| 14:30:25 | bauzas | when calling Neutron for a list of segments related to the network | |
| 14:30:38 | bauzas | and I can see both the name and id fields | |
| 14:30:54 | bauzas | because the object is the subnet, not the segment | |
| 14:31:12 | sean-k-mooney | right but right now we dont list all the subnets | |
| 14:31:20 | sean-k-mooney | we just get all the segment by the network id | |
| 14:31:32 | sean-k-mooney | so we need to have 1 call to get teh subnet | |
| 14:31:39 | sean-k-mooney | it has the segment id in it | |
| 14:32:12 | bauzas | oh shit, you're right | |
| 14:32:14 | sean-k-mooney | so instead of calling _get_segment_ids_for_network | |
| 14:32:22 | bauzas | I was looking at the wrong endpoint | |
| 14:32:33 | sean-k-mooney | we just need get_segment_id_for_port | |
| 14:32:46 | sean-k-mooney | that uses the subnet_id in the port to do a subnet show | |
| 14:32:47 | bauzas | yeah we can't filter | |
| 14:32:49 | sean-k-mooney | and pull out the id | |
| 14:33:10 | bauzas | ok I can try to fix this | |
| 14:33:38 | bauzas | anyway, good catch | |
| 14:33:50 | sean-k-mooney | ya its still just one call to neutron either gettign the segment by network or if it has an ip geting the segment for the current ip | |
| 14:35:29 | sean-k-mooney | bauzas: fyi the subnet in the port is in port[fixed_ips][0]['subnet_id'] | |
| 14:35:47 | sean-k-mooney | well port['fixed_ips'][0]['subnet_id'] for got the '' | |
| 14:36:18 | bauzas | yeah | |
| 14:36:25 | bauzas | I'm literrally hands-on :) | |
| 14:36:38 | bauzas | did a git stash for the UT work I was doing | |
| 14:36:52 | bauzas | and I'll have to change a few things | |
| 14:37:05 | bauzas | fortunately, you pinged me before I went too far | |
| 14:37:58 | bauzas | behavioural-driven-development, that is. | |
| 14:42:52 | bauzas | sean-k-mooney: can we assume a port always have a fixed-ips list with ip addresses in it ? | |
| 14:43:23 | bauzas | I can be conservative and double-check we have a list of IPs, and if not, fallback to getting the network id | |
| 14:43:32 | bauzas | as we could boot with an unbound port | |
| 14:43:43 | bauzas | right ? | |
| 14:45:10 | sean-k-mooney | bauzas: no i t wont have a fix ip if it was a new boot | |
| 14:45:22 | sean-k-mooney | it will if it has an ip e.g. a move operation or they specified one | |
| 14:45:25 | bauzas | okay, so we need to be conservative | |
| 14:45:38 | sean-k-mooney | yep but if it has no fixed ip | |
| 14:45:45 | bauzas | sure, sec | |
| 14:45:48 | sean-k-mooney | then any segment in the network is valid | |
| 14:46:00 | sean-k-mooney | so you can use the lent of the list to determin how to look it up | |
| 14:46:49 | sean-k-mooney | e.g. if port['fixed_ips']: lookup_by_port_subnet else lookup_by_network | |
| 14:48:35 | bauzas | that's exactly what I wrotre | |
| 14:48:37 | bauzas | pasting it | |
| 14:48:53 | bauzas | hmpf, paste.o.o is super slow | |
| 14:50:08 | sean-k-mooney | ya it is weird | |
| 14:50:18 | bauzas | sean-k-mooney: https://pastebin.com/x0g0anRS | |
| 14:50:41 | bauzas | agreed with the logic ? | |
| 14:50:51 | bauzas | if so, adding the new neutron knob | |
| 14:51:18 | bauzas | (nevermind the pep8 indenting issue, fwiw :) ) | |
| 14:51:53 | sean-k-mooney | ya that works | |