| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-11 | |||
| 14:06:59 | stephenfin | gibi: Done. Think I'm +2 on that whole series. I'll leave it to you to find another reviewer | |
| 14:07:25 | stephenfin | sean-k-mooney would probably be good to have reviewing it since I think they're re-using part of it for another spec? | |
| 14:07:32 | gibi | stephenfin: thanks | |
| 14:12:23 | sean-k-mooney | stephenfin: am the routed networks stuff bauzas is doing? | |
| 14:12:45 | stephenfin | sean-k-mooney: no, gibi's "attach ports with QoS policies" series | |
| 14:12:49 | sean-k-mooney | stephenfin: the only part im reusing form that is the network info in the requst spec | |
| 14:13:06 | stephenfin | oh, it's something from bauzas' series you're reusing. nvm so | |
| 14:13:12 | sean-k-mooney | oh no i dont need that for anything as far as i am aware but i can review it in anycase | |
| 14:13:27 | bauzas | atm working on adding UTs for the WIP patch, btw. ;) | |
| 14:13:44 | sean-k-mooney | bauzas: did you see my comments on it | |
| 14:13:58 | sean-k-mooney | the functional tests are asserting incorrect behavior | |
| 14:14:42 | bauzas | sean-k-mooney: err, no | |
| 14:15:04 | sean-k-mooney | look at the move operation tests https://review.opendev.org/c/openstack/nova/+/749068/6/nova/tests/functional/test_servers.py | |
| 14:15:21 | sean-k-mooney | the test have 3 host and 2 segments | |
| 14:15:33 | sean-k-mooney | the first host is not on any segemnt and the other two are on one each | |
| 14:15:58 | sean-k-mooney | so the migrate live migrate and evacuate test should not pass | |
| 14:15:59 | bauzas | yup | |
| 14:16:07 | bauzas | what? | |
| 14:16:10 | sean-k-mooney | since there is not another host on the same segment | |
| 14:16:24 | sean-k-mooney | you cant change segments on any move operation | |
| 14:16:24 | bauzas | hmmm | |
| 14:16:36 | bauzas | then the implementation is not good | |
| 14:16:46 | bauzas | I asked for it last month | |
| 14:16:54 | sean-k-mooney | unfortunetly it appears so | |
| 14:17:07 | bauzas | and I thought we were supporting to move to other segments if they are in the same networks | |
| 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 | bauzas | sean-k-mooney: I don't think we need to call Neutron for this | |
| 14:25:46 | sean-k-mooney | https://docs.openstack.org/api-ref/network/v2/index.html?expanded=list-subnets-detail#id263 | |
| 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 :) | |