| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-04 | |||
| 15:49:47 | bauzas | which could fail | |
| 15:50:17 | bauzas | and for most of the cases where operators would want to see the IPs, those would be for networking debugging | |
| 15:50:20 | sean-k-mooney | which neutron event? network-vif-unplugged? | |
| 15:50:29 | bauzas | yeah | |
| 15:50:36 | sean-k-mooney | we dont need to wait for that | |
| 15:50:37 | bauzas | sean-k-mooney: see the patch https://review.opendev.org/c/openstack/nova/+/750552 | |
| 15:50:45 | sean-k-mooney | we can but we dont need too. | |
| 15:51:12 | sean-k-mooney | once we detach it form libvirt its detacted form the vm | |
| 15:51:40 | sean-k-mooney | what could fail is removing the device owner(vm uuid) form the port | |
| 15:53:37 | bauzas | sean-k-mooney: sean-k-mooney: but then the IP would still be assigned to the instance, right? | |
| 15:53:44 | sean-k-mooney | this is the only place we use network-vif-unplugged i belvie https://opendev.org/openstack/nova/src/branch/master/nova/compute/manager.py#L10079-L10083 | |
| 15:54:06 | sean-k-mooney | bauzas: the ip is assigned to the port | |
| 15:54:31 | sean-k-mooney | if the port is not attached to the vm anymroe then even if nueton still thinks the port has teh ip packet wont get to the vm | |
| 15:54:48 | bauzas | sean-k-mooney: the comment is confusing here https://review.opendev.org/c/openstack/nova/+/750552/8/nova/virt/libvirt/driver.py#2329 | |
| 15:55:04 | bauzas | we have some internal object that awaits a neutron callback | |
| 15:55:09 | gibi | bauzas: ack, I will check | |
| 15:55:33 | sean-k-mooney | bauzas: the network info cache wont be update until neutron sees the port is removed | |
| 15:55:38 | gibi | but nova meeting starts in 4 minutes on #openstack-meeting-3 | |
| 15:55:40 | sean-k-mooney | i belive that is what it is refering too | |
| 15:56:05 | sean-k-mooney | the filter however will remove it from the network info when generating the metadata | |
| 15:56:14 | sean-k-mooney | network_info = list(filter(lambda info: info['id'] != vif['id'], | |
| 15:56:16 | sean-k-mooney | instance.get_network_info())) | |
| 15:56:49 | sean-k-mooney | so regardless of if neutron has sent the event or not to cause the info cache to be refreshed the copy we pass to generate the data has it removed | |
| 15:58:37 | bauzas | sean-k-mooney: my concern is not the fact it filters | |
| 15:58:51 | bauzas | he wrote the filter for a good reason | |
| 15:59:17 | bauzas | my concern is that we remove this information from the metadate while we could still need it | |
| 15:59:57 | bauzas | actually, the question is more, who is the source of truth ? nova or neutron ? | |
| 16:00:15 | bauzas | the IP address is bound to a port, which itself is attached to an instance | |
| 16:00:32 | bauzas | what if the detach event fails in the meantime ? | |
| 16:00:49 | sean-k-mooney | we remove it after libvirt has finished detaching the interface so why would we need it | |
| 16:01:04 | gibi | bauzas: if this info is in the domain xml then I would say that what matters is what the VM sees. so if the vif was removed from the VM then we can remove the metadata too | |
| 16:01:34 | bauzas | gibi: in this case, I could understand this | |
| 16:01:47 | sean-k-mooney | the sequencing is we remove the interface form the domain | |
| 16:02:00 | sean-k-mooney | then we unplug the vif form the backend | |
| 16:02:07 | sean-k-mooney | then we remove it form the metadata | |
| 16:02:46 | gibi | that sequence is OK to me | |
| 16:02:48 | sean-k-mooney | then after that i belive the compute manger update the neutron port and remvoed the device owner | |
| 16:04:17 | sean-k-mooney | by the way we cannot unconditionally wait for network-vif-unplugged here as not all backend will send it if im not mistaken | |
| 16:04:26 | sean-k-mooney | ml2/ovs will | |
| 16:04:41 | sean-k-mooney | after we do self.vif_driver.unplug(instance, vif) | |
| 16:04:55 | sean-k-mooney | but i doint think al backend will | |
| 16:07:11 | sean-k-mooney | yep https://github.com/openstack/nova/blob/788035add9b32fa841389d906a0e307c231456ba/nova/compute/manager.py#L7779-L7794 | |
| 16:07:23 | sean-k-mooney | we tell the dirver to detach which is what is being modified | |
| 16:07:36 | sean-k-mooney | and then if we dont raise an exceptio we do _deallocate_port_for_instance | |
| 16:09:06 | sean-k-mooney | that is what does the neutron port update/delete https://github.com/openstack/nova/blob/788035add9b32fa841389d906a0e307c231456ba/nova/network/neutron.py#L1710-L1714 | |
| 16:11:27 | sean-k-mooney | bauzas: hopefully ^ that makes sense | |
| 16:11:47 | bauzas | sean-k-mooney: on the nova meeting, catching up | |
| 16:13:43 | bauzas | sean-k-mooney: well, gibi's point sounds reasonable to me | |
| 16:14:00 | bauzas | from a VM perspective, the nic is detached | |
| 16:14:18 | sean-k-mooney | yep before we ever touch the xml to update the metadta | |
| 16:14:30 | sean-k-mooney | so its consitent with novas/libvirt view | |
| 16:14:45 | bauzas | ok, so I'll comment but I'll leave my -1 for other nits | |
| 16:14:54 | sean-k-mooney | cool | |
| 16:16:18 | bauzas | humm, eavesdrop is lagging 15 mins behind, can't just provide a link yet | |
| 16:25:29 | sean-k-mooney | ya it can | |
| 16:26:15 | sean-k-mooney | bauzas: its up to date now | |
| 16:26:32 | bauzas | yup, commented 5 mins before | |
| 16:26:41 | sean-k-mooney | so you did | |
| 16:26:45 | bauzas | it just updated straight while it was lagging | |
| 16:27:00 | bauzas | I guess there are crons behind eavesdrop | |
| 16:27:32 | bauzas | unless it's event-based, which would surprise me | |
| 16:27:58 | sean-k-mooney | i think its a chron/periodic sync ya | |
| 16:28:56 | sean-k-mooney | its rare that it get more then a few minutes out of date | |
| 17:06:19 | lyarwood | stephenfin: mind if I address a nit in https://review.opendev.org/c/openstack/nova/+/751367/2 and rebase the series for you? | |
| 17:06:46 | stephenfin | lyarwood: for sure | |
| 17:06:49 | stephenfin | go for it | |
| 17:07:17 | stephenfin | I missed the AR | |
| 17:08:50 | lyarwood | stephenfin: np and apologies for missing this series in train for so long | |
| 17:14:10 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: Only allow one scheduler service in tests https://review.opendev.org/c/openstack/nova/+/751362 | |
| 17:14:11 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: func tests: move _run_periodics() into base class https://review.opendev.org/c/openstack/nova/+/751363 | |
| 17:14:12 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: Helper to start computes with different HostInfos https://review.opendev.org/c/openstack/nova/+/751364 | |
| 17:14:14 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: Add generic reproducer for bug #1879878 https://review.opendev.org/c/openstack/nova/+/751366 | |
| 17:14:14 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: tests: Add reproducer for bug #1879878 https://review.opendev.org/c/openstack/nova/+/751365 | |
| 17:14:15 | openstack | bug 1879878 in OpenStack Compute (nova) train "VM become Error after confirming resize with Error info CPUUnpinningInvalid on source node " [Undecided,In progress] https://launchpad.net/bugs/1879878 - Assigned to Stephen Finucane (stephenfinucane) | |
| 17:14:15 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: Don't unset Instance.old_flavor, new_flavor until necessary https://review.opendev.org/c/openstack/nova/+/751367 | |
| 17:14:16 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: Move confirm resize under semaphore https://review.opendev.org/c/openstack/nova/+/751368 | |
| 17:14:17 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: Move revert resize under semaphore https://review.opendev.org/c/openstack/nova/+/751369 | |
| 18:11:14 | sean-k-mooney | dansmith: regarding ci resouces. one thing that i have tought about from time to time was spliting check into check and fast check with check dependt on fast check | |
| 18:11:40 | sean-k-mooney | now we said we dont want to make them dependent because we want all the result at once | |
| 18:12:07 | sean-k-mooney | but if we had two pipelines liek that we might be abel to run only the logner jobs if the patch did not have -w | |
| 18:12:21 | sean-k-mooney | im not sure if that would save much resouces | |
| 18:12:49 | sean-k-mooney | but sometimes im torn between pushing code to gerrit to have a backup or make shareing ti between multiple servers simpler | |
| 18:12:55 | sean-k-mooney | and wasting gate resouces | |
| 18:13:21 | sean-k-mooney | if we had a way to say dont run the jobs yet that might help with early verions | |
| 18:14:25 | sean-k-mooney | in the grand scheme of things its proably not going to be large but it might be worth exploring having a ready-for-ci lable or something | |
| 18:16:07 | sean-k-mooney | i did that for my third party ci https://github.com/SeanMooney/ci-sean-mooney/blob/main/zuul.d/pipelines.yaml#L53-L56 | |
| 18:16:27 | sean-k-mooney | and its how the intel nfv ci used to run to save capsity | |
| 18:16:58 | sean-k-mooney | althogh it was not night and day or anything | |
| 18:29:02 | dansmith | sean-k-mooney: yeah I'm not sure if that's really doable, but I would love to get *some* results before others, that would help a lot | |
| 18:29:32 | sean-k-mooney | what i suggested before was ll the non tempest ones first then the rest | |
| 18:29:48 | sean-k-mooney | granted you can run those simpley locally | |
| 18:31:18 | sean-k-mooney | its too bad zuul cant report back as each job finishes but when i realy want that i do go to zuul.openstack.org | |
| 18:31:31 | sean-k-mooney | and just get teh results from there instead of waiting | |
| 18:32:16 | sean-k-mooney | the results are avaiable in zuul once the indivuatl job finsihes just not in gerrit | |
| 18:46:54 | dansmith | sean-k-mooney: yeah I'd like to have one tempest job and the easy ones in the first go I think | |
| 18:47:04 | dansmith | worker counts being lower would make that still go faster I think | |
| 18:47:14 | sean-k-mooney | yep you could do that | |
| 18:47:26 | sean-k-mooney | choose one of the faster ones | |
| 18:47:32 | dansmith | but I think zuul lacks some persistence required to split up the job and still know when it can gate | |
| 18:47:33 | dansmith | so not sure that's really an option | |