Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-09-02
09:39:25 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: Add regression tests for bug #1889108 https://review.opendev.org/749232
09:39:25 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: compute: Don't delete the original attachment during pre LM rollback https://review.opendev.org/749233
09:39:26 openstack bug 1889108 in OpenStack Compute (nova) train "failures during driver.pre_live_migration remove source attachments during rollback" [Undecided,In progress] https://launchpad.net/bugs/1889108 - Assigned to Lee Yarwood (lyarwood)
09:40:30 brinzhang0 alex_xu: please check the dependency package version, is it reasonable?
09:46:08 lyarwood bauzas / elod: would you mind taking a look at https://review.opendev.org/#/c/748496/
09:47:23 suryasingh @jkulik thanks for response and patch link. Did you tested this patch ? And is there any priority from nova-community side for this patch, if you know about it, sorry for asking.
09:56:28 jkulik suryasingh, we're running some version of this patch in production on a queens code-base. I haven't seen any push from the nova-community for this.
09:57:37 bauzas lyarwood: ack
09:58:02 suryasingh @jkulik I see, thanks for info.
10:05:45 openstackgerrit Merged openstack/os-vif master: deprecate ovs-vsctl driver and make native the default https://review.opendev.org/744816
10:27:30 frickler what do I need to do in order to be able to extend an attached RBD volume? https://review.opendev.org/613039 makes me think that this should work since stein, but if I try via cinder, it wants to see an unattached volume. is there some special nova API for this?
10:30:38 lyarwood frickler: isn't that a microversion thing on the c-api side?
10:30:40 lyarwood frickler: https://docs.openstack.org/api-ref/block-storage/v3/index.html?expanded=extend-a-volume-size-detail#volume-actions-volumes-action
10:30:48 lyarwood frickler: Prior to microversion 3.42 the volume status must be available. Starting with microversion 3.42, attached volumes with status in-use may be able to be extended depending on policy and backend volume and compute driver constraints in the cloud. Note that reserved is not a valid state for extend.
10:31:10 frickler lyarwood: ha, I'll try that, thx
10:34:06 elod lyarwood: sure, I'll review those patches today
10:37:04 frickler lyarwood: works like a charm, though seemingly only with the cinder CLI, not OSC, but that's a different topic. thx again
10:37:26 lyarwood frickler: cool np :)
10:37:32 lyarwood elod: awesome thanks!
10:57:03 openstackgerrit Merged openstack/nova master: Add ability to download Glance images into the libvirt image cache via RBD https://review.opendev.org/574301
11:02:18 stephenfin gibi: So, interesting problem. I'm trying to remove those XenAPI-only APIs and need to optionally disable their tests in Tempest on Victoria+. The pattern we have for that is to check if our max API version > the max of the past release, but Victoria's max is the same as Ussuri (we didn't add new microversions this cycle)
11:02:38 stephenfin So i wonder if there are any last minute API changes we want to make/ :-D
11:02:39 stephenfin ?
11:09:47 alex_xu brinzhang: that is better to have luyao to take a look at, but I think that is the version luyao tested
11:40:55 gibi stephenfin: hm, that is an interesting catch
11:41:14 gibi I'm not aware of inflight microversion bumps
11:42:48 gibi yeah, looking through our bp list I don't think we have a version bump https://launchpad.net/nova/+milestone/victoria-3
11:45:18 sean-k-mooney gibi: i think that might be a first for m3 since they were added :)
11:46:06 sean-k-mooney stephenfin: you could just add a microverion for this
11:46:14 gibi I guess it is a definit signal that nova development is slowing down
11:46:42 sean-k-mooney to singal the xenapi apis being removed
11:47:10 sean-k-mooney then use that for tempest
11:50:12 sean-k-mooney gibi: by the way i didnt find any thing broken in your code although there is that latent bug for keeping the vfs in teh db in sync with reality after a vf is detached
11:50:27 sean-k-mooney was there anything in particalar you wanted me to test that i did not
11:50:46 gibi sean-k-mooney: thanks for the tests. I think you covered everything.
11:51:36 gibi sean-k-mooney: regarding the latent bug. when a pf is attached to a guest then the host deletes the vfs from the pf
11:51:46 gibi and then when the pf is freed from the guest
11:51:52 gibi the vfs are not recreated by the host
11:52:06 sean-k-mooney kind of
11:52:19 gibi I did added a bit of configuration to re-create the vfs
11:52:25 gibi I mean host config
11:52:35 sean-k-mooney that is the effect but its not somuch the host deleting the vf as we are unbining the pf from the kernel and the vf are destoyed when that happens
11:53:06 sean-k-mooney basically i allocated the VFs using /sys and echo at run time
11:53:09 gibi how the vfs was created in the first place? I guess by writing under /sys
11:53:13 gibi yeah
11:53:19 gibi so that steps is not persistent
11:53:26 sean-k-mooney but that configurtion info is lost when you allocate teh pf to the vm
11:53:30 gibi yepp
11:53:43 sean-k-mooney then wehn qemu is done it does a functionl level pci reset
11:53:44 gibi I think this is a host configuration task to keep the number of vfs perisitent
11:53:52 gibi persistent
11:53:58 sean-k-mooney it is
11:54:07 gibi so I put
11:54:07 gibi pre-up echo '4' > /sys/class/net/enp129s0f0/device/sriov_numvfs
11:54:08 sean-k-mooney but we could also protect against it eaisly in nova
11:54:23 gibi hm, how?
11:54:39 gibi does nova know what is the number of vfs to be re-created?
11:54:54 sean-k-mooney gibi: when we set teh vfs from unavaiable to avaiable after freeing the PF in the db we chould check with libvirt to make sure the exist
11:55:02 sean-k-mooney if they dont we can delete them in the db
11:55:24 sean-k-mooney or i guess we could count them and recreate them with that echo but deleteing seams simpler
11:55:43 gibi ohh, yes, we could sync our db with reality
11:55:48 sean-k-mooney yep
11:55:55 gibi I don't want to recreate anything host level
11:56:04 sean-k-mooney so syncing with reality shoudl be simple
11:56:08 gibi I see
11:56:40 sean-k-mooney the other thning is that unless your udev rules are correct when you unbind the pf form the vm
11:56:52 sean-k-mooney the pf might not bind back to the netdev vendor driver
11:57:03 sean-k-mooney it can stay bound to vfio-pci
11:57:22 songwenping_ bauzas: hi, i'm test vGPU with VM and meet some problems. I have install nvidia-smi driver and my GPU's already set nvidia driver, but i cannot find mdev_bus at /sys/class path.
11:57:22 sean-k-mooney in that case the vf wont be recreated by a pre-up command
11:57:35 sean-k-mooney but that is definetly out of nova scope
11:57:59 sean-k-mooney songwenping_: what kernel are you using
11:58:10 gibi sean-k-mooney: ack
11:58:20 sean-k-mooney songwenping_: also i dont think that is where it is
11:58:32 bauzas songwenping_: have you installed the nvidia driver in the compute service ?
11:58:58 songwenping_ i use ubuntu 18.04.
11:59:09 songwenping_ my centos env is ok.
11:59:12 sean-k-mooney songwenping_: i think its /sys/bus/mdev not /sys/class/mdev but its only created after you modporbe vfio-mdev
12:00:14 sean-k-mooney yep sean@pop-os:~$ ls /sys/bus/mdev/
12:00:15 sean-k-mooney devices drivers drivers_autoprobe drivers_probe uevent
12:00:20 songwenping_ sean-k-mooney: also not find at /sys/bus/mdev
12:00:45 sean-k-mooney yep you need to do "sudo modprobe vfio-mdev"
12:00:49 sean-k-mooney to create it
12:01:16 sean-k-mooney wait is this a ubuntu 18.04 host
12:01:19 sean-k-mooney or guest
12:01:27 songwenping_ host
12:01:40 sean-k-mooney nvidia annoyingly does not have ubuntu host drivers
12:01:49 sean-k-mooney for virtual gpus
12:02:00 sean-k-mooney they only suppor ubuntu guests
12:03:04 sean-k-mooney so unless you used alien or something to install the rhel rpm on your ubuntu host i dont see how you can install the correct driver and kernel module
12:03:29 sean-k-mooney mdevs will work but not nvidia grid on a ubuntu host
12:04:24 songwenping_ i get nvidia-* last week and create vm with vgpu success with devstack on ubuntu 18.04 host.
12:04:40 openstackgerrit Johannes Kulik proposed openstack/nova master: vmware tests: Support different moref backend representations https://review.opendev.org/749488
12:05:12 bauzas songwenping_: what sean-k-mooney said, nvidia doesn't support ubunutu as a compute OS
12:06:49 jkulik stephenfin, if you find some time, please have a look at https://review.opendev.org/749488 for the first patch for the oslo.vmware SOAP library switch. sorry for the long wait, downstream needed a lot more love than usual ...
12:06:54 songwenping_ i really get the nivida-* is at /sys/class/mdev_bus as centos. but now i cannot get it.
12:13:15 sean-k-mooney songwenping_: i think that class path will only exist if you have mdevs allocated
12:13:38 sean-k-mooney songwenping_: but as i said you cant use ubuntu as a host os for nvida grid
12:14:03 sean-k-mooney i can be the guest os but nvidia does not make the host level driver availabel for ubuntu
12:17:07 songwenping_ sean-k-mooney: yeah, i have allocated mdevs and i reinstall vgpu-kvm package.

Earlier   Later