Earlier  
Posted Nick Remark
#openstack-nova - 2021-03-05
09:35:49 bauzas french universities don't like to have remote mentors
09:36:53 stephenfin this year could be your year
09:36:58 stephenfin it's all remote now :-\
09:37:30 bauzas meh
09:37:38 bauzas it's... difficult, trust me
09:37:43 bauzas even for our company :)
10:09:43 stephenfin gibi: URI qemu:///system does not support events: module 'nova.tests.unit.virt.libvirt.fakelibvirt' has no attribute 'VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED'
10:09:48 stephenfin I'm seeing that in unit tests
10:10:00 stephenfin Looks like you might want to add stuff to fakelibvirt, else mute the warning?
10:44:17 openstackgerrit Lee Yarwood proposed openstack/nova master: nova-next: Start testing the q35 machine type https://review.opendev.org/c/openstack/nova/+/708701
10:44:43 lyarwood ^ gibi / kashyap / stephenfin ; this should be ready for reviews now, just had a quick nit to resolve.
10:45:35 kashyap lyarwood: Thanks for the sustained effort on it; will look today
10:51:02 gibi bauzas, stephenfin: I think we only need to add the wallaby db placeholders at the start of X as in X we need to differentiate between db changes that are X only from db changes that are backported to W
10:52:02 gibi stephenfin: regarding the unit test logs I will look into it
10:53:57 stephenfin lyarwood: cool
10:58:09 kashyap lyarwood: If you're respinning, can you please add the comment I noted in the review? It'll be useful for those who don't dwell on machine types
10:59:49 kashyap I don't insist; just that it avoids some head-scratching; I added my +1 regardless, FWIW.
11:01:33 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Add support for virtio-based input devices https://review.opendev.org/c/openstack/nova/+/756552
11:01:34 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Stop mocking 'nova.virt.libvirt.utils.get_arch' https://review.opendev.org/c/openstack/nova/+/778879
11:02:22 openstackgerrit Merged openstack/nova stable/victoria: Handle instance = None in _local_delete_cleanup https://review.opendev.org/c/openstack/nova/+/777209
11:05:32 stephenfin lyarwood, gibi: Mind taking at look at ^ again? Took a while but I got the mocking nailed down eventually
11:09:34 lyarwood kashyap: ack I did note something about that in the commit but if I respin I'll add a note
11:09:37 lyarwood stephenfin: ack looking
11:12:18 gibi stephenfin: done
11:12:24 stephenfin ty
11:29:21 openstackgerrit Balazs Gibizer proposed openstack/nova master: Replace blind retry with libvirt event waiting in detach https://review.opendev.org/c/openstack/nova/+/770246
11:33:10 kashyap lyarwood: Unless I'm terribly blind, I see that you've added about the SATA bus aspect, but I can't find anything about the PCIe root ports. :) But no prob
11:34:30 stephenfin lyarwood: The patch to add '--block-device' to 'openstack server create' landed and I'm adding functional tests. It seems boot_index is not mandatory
11:35:19 stephenfin If I omit it, I guess it defaults to -1. The guest correctly boots from the image I'm specifying alongside (cirros)
11:36:01 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP zuul: Replace nova-grenade-multinode with grenade-multinode https://review.opendev.org/c/openstack/nova/+/778885
11:36:51 lyarwood stephenfin: are you providing both --image and --block-device?
11:37:07 stephenfin yes
11:37:13 lyarwood stephenfin: I think osc and novaclient fudge things in the past to always boot from the --image you provided
11:37:42 lyarwood stephenfin: in terms of the api behaviour
11:38:02 lyarwood stephenfin: I think n-api also ensures we boot from the image, let me check
11:39:57 stephenfin There's also additional weirdness. I was copying this behaviour https://github.com/openstack/python-novaclient/blob/master/novaclient/v2/servers.py#L775-L779
11:40:30 stephenfin However, that seems broken. nova rejects those requests with 'Block Device Mapping is Invalid: Mapping image to local is not supported.'
11:41:22 stephenfin openstack server create ... --image cirros-0.5.1-x86_64-disk --block-device device_name=vdb,source_type=image,destination_type=volume,uuid=$UUID ...
11:41:47 gibi stephenfin: ooh that image to local error was one of my early nova contribution ;) I0c38134e2aacca83d98ed0b341f15c480afe14f1
11:42:03 stephenfin that works just fine, so I'm going to change it to default destination type to volume when source type is image instead, since that seems more logical/correct
11:42:42 stephenfin gibi: we can't be blamed for the mistakes of our younger selves ;)
11:43:03 gibi indeed
11:43:57 stephenfin ah, wait, I think I misunderstood that code
11:44:14 lyarwood right
11:44:25 lyarwood image to local is valid
11:44:33 lyarwood I'm not sure what we end up doing to hit that
11:44:45 lyarwood do we provide an imageRef *and* image->local bdm?
11:45:00 stephenfin I think that's transforming the '--image' request to a bdm dict
11:45:20 lyarwood yeah it should do and I think that needs to drop the imageRef as a result?
11:46:18 lyarwood with imageRef we end up with an image based local bdm so I'm not sure why we would block this in the API
11:46:28 lyarwood maybe because it skips imageRef
11:46:42 stephenfin http://paste.openstack.org/show/803266/
11:46:55 stephenfin that's what the OSC code currently ends up generating
11:47:24 stephenfin in response to http://paste.openstack.org/show/803267/
11:47:49 lyarwood stephenfin: and n-api rejects that?
11:47:55 stephenfin nope, that's fine
11:48:00 lyarwood oh
11:48:03 lyarwood okay
11:48:06 stephenfin if I add destination_type=local to the '--block-device' arg though
11:48:10 stephenfin the API rejects _that_
11:48:27 lyarwood oh right
11:48:29 lyarwood yeah
11:48:39 lyarwood there can only be one
11:48:42 lyarwood I think
11:49:29 stephenfin Yeah, quite possibly
11:49:33 stephenfin I'm also using the same image twice
11:49:41 stephenfin i don't know if that's an issue or not
11:49:41 stephenfin http://paste.openstack.org/show/803268/
11:49:45 lyarwood https://github.com/openstack/nova/blob/c8a6f8d2e502e139c2212fb20cc0f89de816aeb1/nova/block_device.py#L193-L206
11:49:56 stephenfin plus other differences as you can see
11:51:06 stephenfin okay, so the logic should be...
11:51:33 gibi as far as I remember I blocked image to local mapping as it was not implemented (for other than for a single image)
11:51:36 stephenfin if --image is specified, use destination_type=volume since this is an additional image
11:52:10 lyarwood destination_type shouldn't be optional right?
11:52:32 lyarwood huh it is
11:52:37 lyarwood I thought it wasn't in the API
11:52:46 lyarwood so yeah default to volume if --image is provided
11:52:52 lyarwood and destination_type isn't
11:52:56 stephenfin they're all optional except UUID
11:53:12 lyarwood and reject the use of image as a destination_type if --image is already provided in the cli
11:53:20 stephenfin of local you mean
11:53:25 lyarwood yeah sorry
11:53:27 lyarwood local
11:53:35 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add device event constants to fakelibvirt https://review.opendev.org/c/openstack/nova/+/778887
11:53:45 stephenfin --image + --block-device source_type=image,destination_type=local ==> FAIL
11:54:02 lyarwood I can add a note in the api docs about this
11:54:11 stephenfin actually, for OSC I might just leave this to the server
11:54:16 stephenfin as you suggested in the review
11:54:39 lyarwood ah damn past me
11:54:42 stephenfin simply using a sensible destination_type (volume) would be good
11:54:46 lyarwood but that makes sense
11:54:46 stephenfin enough
11:54:51 lyarwood yeah
12:26:50 openstackgerrit Lee Yarwood proposed openstack/nova master: zuul: Replace grenade and nova-grenade-multinode with grenade-multinode https://review.opendev.org/c/openstack/nova/+/778885
12:27:19 lyarwood ^ tosky / gmann ; I'm not sure what you both think about this approach but it could allow us to finish our move to zuulv3 before M3
12:27:56 lyarwood tl;dr - move everything to grenade-multinode and add coverage for ceph later once that multinode base job is finished
12:55:07 sean-k-mooney lyarwood: that wont actully remove grenade unless we remove it form the integrated-gate-compute template
12:55:42 sean-k-mooney it wil still be added by integrated-gate-compute and it will no longer use the irrelevant-files list
12:56:02 sean-k-mooney so what you really need to do is also remove the integrated-gate-compute template
12:56:51 sean-k-mooney oh never mind

Earlier   Later