| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-11 | |||
| 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 :) | |
| 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 | |
| 14:52:10 | sean-k-mooney | although i kind of feel like lines 17-22 should be under the if on 13 | |
| 14:52:18 | sean-k-mooney | well if/else | |
| 14:52:51 | sean-k-mooney | i mean you dont need to do the if network_id as that will always be true | |
| 14:53:32 | sean-k-mooney | you could keep the if subnet_id but that will only be set if we go to line 14 in which case we know it wont be empty | |
| 14:54:07 | bauzas | yeah, I can improve this | |
| 14:54:14 | sean-k-mooney | so you can put lines 21 and 22 on line 15 and lines 18 and 19 on line 17 | |
| 14:54:29 | sean-k-mooney | but ya the logic looks correct to me | |
| 15:23:22 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/victoria: Reproduce bug 1907522 in functional test https://review.opendev.org/c/openstack/nova/+/769736 | |
| 15:23:24 | openstack | bug 1907522 in OpenStack Compute (nova) "test_*_with_qos_min_bw_allocation fails in the nova-multi-cell job with: nova.exception.MigrationPreCheckError: Migration pre-check error: Failed to create port bindings for host |
|
| 15:24:46 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/victoria: Fallback to same-cell resize with qos ports https://review.opendev.org/c/openstack/nova/+/769727 | |
| 16:10:37 | lyarwood | dansmith: https://review.opendev.org/c/openstack/nova-specs/+/769547 - would you mind hitting PS3 today? Should be good to go now. | |
| 16:11:03 | dansmith | roger | |
| 16:11:30 | lyarwood | cheers | |
| 16:15:07 | openstackgerrit | Dan Smith proposed openstack/nova-specs master: libvirt: Update instance machine type stash spec https://review.opendev.org/c/openstack/nova-specs/+/769547 | |
| 16:38:05 | openstackgerrit | Merged openstack/nova-specs master: libvirt: Update instance machine type stash spec https://review.opendev.org/c/openstack/nova-specs/+/769547 | |
| 16:39:57 | gibi | lyarwood: I'm looking at detach_device_with_retry() codepath detach_device_with_retry | |
| 16:40:26 | gibi | lyarwood: and wondering why we have the code set up in a way that we always call an intial detach then after it a detach in a loop | |
| 16:41:41 | gibi | lyarwood: also, I'm wondering what is the way _do_wait_and_retry_detach() normally exit the tool | |
| 16:41:44 | gibi | loop | |
| 16:42:20 | gibi | is it raises DeviceDetachFailed to signal that the detach is done? | |
| 16:42:49 | lyarwood | gibi: just in a call | |
| 16:43:12 | gibi | no worries, I will drop soon, so we can talk about it tomorrow morning | |
| 16:43:27 | lyarwood | gibi: ack if we could that would be great | |
| 16:46:38 | gibi | OK | |
| 16:48:33 | melwitt | gibi: IIRC it's because the initial detach "should" detach it from persistent + live config but the guest can refuse the live detach as it's an ACPI request. so we retry in case that happens (guest refusal by it's busy). under nominal conditions I think the loop detects it's detached in the first iteration and moves on | |
| 16:48:48 | melwitt | *bc it's busy | |