| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-18 | |||
| 15:01:45 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Refactor _claim_pci_device_for_interface_attach to prepare for qos https://review.opendev.org/c/openstack/nova/+/756895 | |
| 15:03:08 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Allow extending an existing instance allocation https://review.opendev.org/c/openstack/nova/+/757109 | |
| 15:04:31 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Make remove allocation symmetric with add allocation https://review.opendev.org/c/openstack/nova/+/757110 | |
| 15:06:22 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Factor out port resource deallocation https://review.opendev.org/c/openstack/nova/+/757111 | |
| 15:08:09 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Refactor update_pci_request_spec_with_allocated_interface_name https://review.opendev.org/c/openstack/nova/+/757614 | |
| 15:09:29 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Enable mypy on scheduler/utils.py https://review.opendev.org/c/openstack/nova/+/769942 | |
| 15:10:51 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Refactor ResourceRequest constructor https://review.opendev.org/c/openstack/nova/+/769720 | |
| 15:12:15 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support interface attach with QoS ports https://review.opendev.org/c/openstack/nova/+/756530 | |
| 15:13:39 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Enable mypy on scheduler/report.py https://review.opendev.org/c/openstack/nova/+/765152 | |
| 15:14:38 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove unused Instance method https://review.opendev.org/c/openstack/nova/+/757615 | |
| 15:15:00 | sean-k-mooney | stephenfin: i intened to reuse the aggreate metadtaa used for the teannt afinity filters | |
| 15:15:15 | sean-k-mooney | we use the same metadat for both the placment prefilter or the post filter | |
| 15:15:37 | sean-k-mooney | the prefilter allwos you to do stict tenant isolation | |
| 15:15:51 | sean-k-mooney | so that only a given tenatn can use member of a give aggreate | |
| 15:18:26 | sean-k-mooney | stephenfin: https://docs.openstack.org/nova/rocky/admin/configuration/schedulers.html#tenant-isolation-with-placement | |
| 15:18:52 | sean-k-mooney | you do openstack aggregate set --property filter_tenant_id=9691591f913949818a514f95286a6b90 myagg | |
| 15:19:00 | sean-k-mooney | to restict the usage | |
| 15:19:12 | sean-k-mooney | stephenfin: so the check you would do is simple. | |
| 15:19:20 | sean-k-mooney | gretrive all aggreate with the current teant id | |
| 15:19:26 | sean-k-mooney | show only host in those aggreates | |
| 15:20:01 | sean-k-mooney | stephenfin: if the list is of aggrates is empty then list all hosts | |
| 15:20:21 | sean-k-mooney | since that tenant is unconfiged | |
| 15:20:53 | stephenfin | makes sense | |
| 15:31:26 | openstackgerrit | Dan Smith proposed openstack/nova master: Do not inherit os_glance properties on snapshot https://review.opendev.org/c/openstack/nova/+/771234 | |
| 15:49:53 | stephenfin | gibi: Could you stick https://review.opendev.org/c/openstack/nova/+/764482/ on your review queue, please? | |
| 15:50:10 | gibi | stephenfin: on it | |
| 15:53:09 | lyarwood | has anyone hit https://bugs.launchpad.net/tempest/+bug/1912178 locally today? | |
| 15:53:10 | openstack | Launchpad bug 1912178 in tempest "Links are not allowed as constraints (pip 20.2.4)" [Undecided,New] | |
| 15:53:27 | stephenfin | not me | |
| 15:53:51 | gibi | lyarwood: yes | |
| 15:53:53 | lyarwood | weird, I'm not sure what is adding the URI to the constraints list | |
| 15:54:02 | lyarwood | oh cool not just me then, cool | |
| 15:54:38 | gibi | lyarwood: I think devstack edits the constraints list based on what repos/libs you asked in the local.conf to be cloned | |
| 15:55:09 | gibi | lyarwood: as far as I understand the issue appears if somehow the pip version gets updated in your devstack vm | |
| 15:55:28 | gibi | lyarwood: for me, in a clean ubuntu 20.04 the first devstack stach.sh works | |
| 15:55:45 | gibi | but subsequnt unstack.sh && stack.sh fails with the above rror | |
| 15:56:47 | lyarwood | gibi: yeah I was about to say I've not touched the version of pip in this env | |
| 15:57:10 | gibi | lyarwood: I suspect that the stach.sh runs some update if it is not in a clean vM | |
| 15:57:14 | gibi | but I have no proof | |
| 16:00: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 | |
| 16:00:50 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Replace blind retry with libvirt event waiting in detach https://review.opendev.org/c/openstack/nova/+/770246 | |
| 16:02:00 | lyarwood | gibi: fun, so I've updated pip and it seems to be working now | |
| 16:02:15 | gibi | hm, interesting | |
| 16:14:28 | stephenfin | bauzas: If you've a chance this week, care to look at https://review.opendev.org/q/topic:bp/compact-db-migrations-wallaby ? dansmith and gibi have already looked through it, so I need a final pair of eyes | |
| 16:14:43 | bauzas | sure, will do | |
| 16:14:56 | stephenfin | you can ignore the apidb series at the bottom for now - I suspect I need to rework some of that | |
| 16:15:01 | stephenfin | cool, thanks | |
| 16:25:13 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Remove 'hypervisor_version' from 'libvirt_info' https://review.opendev.org/c/openstack/nova/+/744199 | |
| 16:29:54 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add generate schemas tool https://review.opendev.org/c/openstack/nova/+/769796 | |
| 16:35:51 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Drop support for Xen https://review.opendev.org/c/openstack/nova/+/743231 | |
| 16:35:52 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION https://review.opendev.org/c/openstack/nova/+/754700 | |
| 16:51:53 | openstackgerrit | Merged openstack/python-novaclient master: Deprecate agent commands and APIs https://review.opendev.org/c/openstack/python-novaclient/+/769068 | |
| 16:52:46 | gibi | lyarwood, kashyap`: back from some testing. If a domain has both a persistent and a live config, then detaching from only the persistent domain first works but does not generate an event. detaching from the live first then detaching from the persistent second does not work none of them generate event (but if the 3rd attempt is live again then that works). | |
| 16:53:10 | kashyap` | gibi: On a call; but reading (as I'm not speaking) ... | |
| 16:53:37 | gibi | so it seems we always need to detach from the persistent first, don't wait for any event, then detach from the live, and wait for event | |
| 16:54:19 | kashyap` | Wait, you're contrasting "persistent" vs. "live" -- my brain was expecting either persistent vs. transient; or live vs offline :-) | |
| 16:54:41 | gibi | the code call them persistent and live | |
| 16:54:57 | gibi | this is where I learned :) | |
| 16:55:39 | gibi | detach from persistent is detach with VIR_DOMAIN_AFFECT_CONFIG | |
| 16:55:49 | gibi | detach from live is detach with VIR_DOMAIN_AFFECT_LIVE flag | |
| 16:56:21 | kashyap` | (Sometimes libvirt terminology gives a damn headache) | |
| 16:56:48 | kashyap` | (For ther record, I was referring to: https://wiki.libvirt.org/page/VM_lifecycle#Transient_guest_domains_vs_Persistent_guest_domains) | |
| 16:57:05 | kashyap` | gibi: Hmm, but I _think_ I see what you mean | |
| 16:57:49 | kashyap` | "live config" often implies it's not persistent (i.e. it is "transient") | |
| 16:57:58 | kashyap` | Either way; back to the original issue | |
| 17:00:09 | gibi | so | |
| 17:00:21 | gibi | I can make it work it just wierdly order dependent | |
| 17:00:34 | kashyap` | gibi: Hmm, so that behaviour of "no event when detaching from live config first" sounds strange and inconsistent. | |
| 17:00:35 | gibi | and also the persistent side does not generate event | |
| 17:00:44 | gibi | kashyap`: yeah | |
| 17:01:04 | kashyap` | gibi: Let me ask Peter; if this is a "bug or a feature" ;-) | |
| 17:03:35 | gibi | kashyap`: could be some kind of complication in my test as well. I try to re-test it with a simpler tempest test as now there is rescue involved as well | |
| 17:05:58 | kashyap` | gibi: I want to phrase the (complex) problem in my own words, so tell me if this is correct: | |
| 17:06:18 | kashyap` | (Because I'm not clear in _which_ combination the event is generated and in which not) | |
| 17:06:48 | kashyap` | - Assume a domain has both a persistent (i.e. inactive) and a live config. | |
| 17:06:51 | kashyap` | - Detach a device from the inactive config first --> detach successful; but does not generate an event | |
| 17:06:54 | kashyap` | - Detach a device from the live config first, then detach it from the persistent config --> the second detach fails; and no event generated in both cases | |
| 17:07:37 | kashyap` | gibi: Is that correct? (With the final point being: if the third attempt in the last step is a live config --> then the detach works) | |
| 17:08:05 | gibi | kashyap`: Detach a device from the live config first, then detach it from the | |
| 17:08:09 | gibi | persistent config | |
| 17:08:40 | gibi | in this case both detach returns without generating event, and the device remains attached (at least in the live config) | |
| 17:09:22 | kashyap` | Aah --> both of them fail (i.e. detach not succesful) and nor do they generate an event? | |
| 17:10:30 | gibi | nova only checks the live config so I can only say that the detach failed from the live config as teh device remains there. | |
| 17:10:40 | gibi | but meanwhile I simplifed the test | |
| 17:10:48 | gibi | and now | |
| 17:11:15 | gibi | I can start with live detach first and it succeeds and generates event as well | |
| 17:11:40 | gibi | so there is some complication my first test scenario that makes the behavior different | |
| 17:11:59 | kashyap` | gibi: The event is _REMOVAL_FAILED, yeah? | |
| 17:12:14 | kashyap` | gibi: If you like, I can start an upstream thread w/ the libvirt folks on libvir-list, and Cc you | |
| 17:13:24 | gibi | kashyap`: when I get event it is VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED | |
| 17:13:36 | gibi | kashyap`: I think I've never seen VIR_DOMAIN_EVENT_ID_DEVICE_REMOVAL_FAILED in my tests ever | |
| 17:13:36 | kashyap` | Err, sorry; it's a succesful removal | |
| 17:13:58 | gibi | kashyap`: let's not rush with that mail, I think I tested too much first | |
| 17:14:16 | kashyap` | gibi: No rush at all :-) Just outlining as an option | |
| 17:14:20 | gibi | and I have to figure out what extra the nova rescue does | |
| 17:14:28 | gibi | that makes the behavior different | |
| 17:14:49 | gibi | because with a simple ACTIVE instance the live first scenario works | |
| 17:14:51 | gibi | as expected | |
| 17:14:58 | gibi | removes the device and generates event | |
| 17:15:16 | kashyap` | Right; gibi - while it's fresh in your mind, do you want to quickly add a note on the scenarios you've tested and the ones that are "weird"? | |