| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-11 | |||
| 09:58:28 | lyarwood | gibi / melwitt ; we can try increasing the initial wait again but that's another hackaround | |
| 09:59:22 | lyarwood | gibi / melwitt ; the ultimate fix for this is waiting for libvirtd to emit events when detaching devices https://review.opendev.org/c/openstack/nova/+/749929 | |
| 10:00:56 | gibi | lyarwood: could I help with ^^ somehow? | |
| 10:01:29 | openstackgerrit | Brin Zhang proposed openstack/python-novaclient master: Microversion 2.88: Replace tenant* with project* in limits commands https://review.opendev.org/c/openstack/python-novaclient/+/770065 | |
| 10:01:52 | lyarwood | gibi: I don't have any cycles to spend on it at the moment, feel free to take a look if you do, that's only a PoC change I was using to work out how to tap into the event framework within the libvirt driver | |
| 10:02:39 | gibi | lyarwood: ack, I might need more context but I will take a look at that patch | |
| 10:03:39 | lyarwood | gibi: https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainEventID & https://libvirt.org/html/libvirt-libvirt-domain.html#virConnectDomainEventDeviceRemovedCallback for the libvirt specific docs | |
| 10:21:29 | gibi | lyarwood: was this https://review.opendev.org/c/openstack/nova/+/749827 superseeded by https://review.opendev.org/c/openstack/nova/+/755799 ? | |
| 10:22:51 | lyarwood | gibi: yeah sorry I'm not sure why I eneded up with a different change there | |
| 10:23:01 | gibi | lyarwood: OK I will drop that | |
| 10:24:30 | lyarwood | gibi: one thing I've just noticed, there's a 5 second gap between the first and second device_del request in libvirtd, my change was supposed to add a 10 second delay | |
| 10:25:41 | gibi | I think on master we have inc_sleep_time=10 | |
| 10:26:26 | lyarwood | yeah I think the retry decorator only uses that for the second wait, ./me checks | |
| 10:31:32 | gibi | it seem so | |
| 10:32:02 | openstackgerrit | Lucas Alvares Gomes proposed openstack/nova master: DO NOT REVIEW: Test OVN devstack module https://review.opendev.org/c/openstack/nova/+/748226 | |
| 10:32:50 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: WIP/DNM libvirt: Start emitting DeviceRemovedEvent and DeviceRemovalFailedEvent events https://review.opendev.org/c/openstack/nova/+/749929 | |
| 10:37:34 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: WIP/DNM libvirt: Start emitting DeviceRemovedEvent and DeviceRemovalFailedEvent events https://review.opendev.org/c/openstack/nova/+/749929 | |
| 10:40:44 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: WIP/DNM libvirt: Start emitting DeviceRemovedEvent and DeviceRemovalFailedEvent events https://review.opendev.org/c/openstack/nova/+/749929 | |
| 11:44:24 | stephenfin | gibi: Could you re +2 this, please? https://review.opendev.org/c/openstack/nova/+/769520/ | |
| 11:46:22 | gibi | stephenfin: oops I missed that, done noew | |
| 11:46:23 | gibi | now | |
| 11:46:35 | stephenfin | Also, gibi, lyarwood, sean-k-mooney: I addressed your concerns on that OSC change, I think https://review.opendev.org/c/openstack/python-openstackclient/+/762396/ | |
| 11:46:59 | stephenfin | gibi++ thanks | |
| 11:48:55 | gibi | I'm +1 on the osc patch too | |
| 11:49:04 | stephenfin | hurrah | |
| 11:55:03 | gibi | gmann: I still see tempest failing with "Multiple possible networks found, use a Network ID to be more specific." on master. e.g.: https://74ab9f21dcdd2e895607-6eadae60e9a1b03c6789f42d51c17d3a.ssl.cf2.rackcdn.com/756894/5/check/nova-next/1fb33ef/testr_results.html | |
| 11:56:38 | gibi | dansmith: I have two tempest failures in test_glance_direct_import_image_to_specific_stores[id-82fb131a-dd2b-11ea-aec7-340286b6c574] I tried to create a logstash signature for it but I failed | |
| 11:56:46 | gibi | 1) https://zuul.opendev.org/t/openstack/build/4a78ba5901474187a3bdc49cacf84b47/logs | |
| 11:56:52 | gibi | 2) https://zuul.opendev.org/t/openstack/build/9488788b59904e6f9bc1280f13fc0a6b/logs | |
| 11:57:09 | gibi | dansmith: is this the timeout failure you mentioned on the last week's meeting? | |
| 11:57:36 | sean-k-mooney | stephenfin: +1 also | |
| 12:02:11 | gibi | dansmith: I also see a full nova-ceph-multistore job timeout here https://zuul.opendev.org/t/openstack/build/8807547b038b4dd983fd7e0bb4cb4b40 it might be related too | |
| 13:45:32 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Refactor ResourceRequest constructor https://review.opendev.org/c/openstack/nova/+/769720 | |
| 13:46:56 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support interface attach with QoS ports https://review.opendev.org/c/openstack/nova/+/756530 | |
| 13:48:23 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Enable mypy on scheduler/report.py https://review.opendev.org/c/openstack/nova/+/765152 | |
| 13:48:51 | gibi | stephenfin: fix your comment in the qos series ^^ | |
| 14:05:12 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/victoria: Add upgrade check about old computes https://review.opendev.org/c/openstack/nova/+/761924 | |
| 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 | bauzas | hmmm | |
| 14:16:24 | sean-k-mooney | you cant change segments on any move operation | |
| 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 | 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 | |