Earlier  
Posted Nick Remark
#openstack-nova - 2018-06-06
02:55:37 openstackgerrit Merged openstack/nova master: Add granular policy rules for resource providers inventories https://review.openstack.org/568666
02:55:44 openstackgerrit Merged openstack/nova master: Add granular policy rules for usages https://review.openstack.org/568706
03:42:43 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Abort live migration in queue (1/2). https://review.openstack.org/568542
03:59:07 openstackgerrit Merged openstack/python-novaclient master: Revert "Fix listing of instances above API max_limit" https://review.openstack.org/572539
04:25:13 pvc hi
04:25:17 pvc how can i hide kvm for gpu ?
04:25:23 pvc so i can test it
04:28:24 pvc gibi
04:28:28 pvc how can i hide the hypervisor
04:28:30 pvc ?
04:34:46 melwitt mriedem_away: fyi I just added your neutron new port binding API to a runway. I skipped "report CPU features as traits" because the last -1 was 7 days ago with no response from the author
04:35:09 melwitt naichuans: fyi your blueprint xenapi-image-handler-option-improvement has been added to a runway again
04:36:15 melwitt naichuans: also, feel free to add feedback about your experience with vgpu-rocky in runway at L186 https://etherpad.openstack.org/p/nova-runways-rocky as it's been moved out of a runway
04:38:54 pvc gibi
05:46:08 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Fix nits in nested provider allocation candidates https://review.openstack.org/572673
06:54:11 openstackgerrit jichenjc proposed openstack/nova master: Fix doc nit https://review.openstack.org/572682
07:16:14 openstackgerrit Bhagyashri Shewale proposed openstack/nova master: libvirt: Don't report DISK_GB if sharing https://review.openstack.org/560459
07:18:16 openstackgerrit Merged openstack/nova master: Return nested providers in get_by_request https://review.openstack.org/567113
07:21:21 naichuans melwitt: got it, thank you very much for the reminder
07:43:52 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: Update launch-from-volume doc to latest version. https://review.openstack.org/572241
07:58:24 openstackgerrit Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766
07:58:25 openstackgerrit Chris Dent proposed openstack/nova master: Isolate placement database config https://review.openstack.org/541435
07:58:27 openstackgerrit Chris Dent proposed openstack/nova master: Ensure that os-traits sync is attempted only at start of process https://review.openstack.org/553857
07:59:08 openstackgerrit Chris Dent proposed openstack/nova master: Add PLACEMENT_DB_ENABLED=True to the nova-next job https://review.openstack.org/564067
08:30:27 openstackgerrit sahid proposed openstack/nova master: libvirt: remove unused get_ovs_interfaceid() https://review.openstack.org/572699
08:40:09 pvc i have an instance with GPU on it but my hypervisor is always restarting and i dont know why
08:48:28 openstackgerrit Merged openstack/nova master: api-ref: mention that you can't re-parent a resource provider https://review.openstack.org/572501
08:48:35 openstackgerrit Merged openstack/nova master: Fix some inconsistencies in doc https://review.openstack.org/570407
08:52:43 pvc can anyone help me
09:01:15 mdbooth Can anybody remind me which repo the ci job definitions are in?
09:05:18 kashyap mdbooth: "project-config", IIRC
09:06:18 kashyap Maybe it's this, since upstream has moved to Zuul a while ago: https://github.com/openstack-infra/openstack-zuul-jobs
09:08:24 kashyap mdbooth: Yes, the above is the repo. From its description:
09:08:25 kashyap edit these files to make configuration changes to OpenStack
09:08:25 kashyap project-template definitions for the OpenStack project. You should
09:08:25 kashyap OpenStack project CI system Zuul. It also contains job and
09:08:25 kashyap This repo contains a set of ansible playbooks which are used by the
09:08:27 kashyap Infrastructure CI.
09:08:52 mdbooth kashyap: Thanks. I'll take a look.
09:14:39 lyarwood kashyap: http://logs.openstack.org/33/571433/2/gate/legacy-tempest-dsvm-neutron-full/a007290/logs/screen-n-cpu.txt.gz?#_2018-06-06_04_56_16_327 - if you have anytime this morning would you mind looking over this cold snapshot failure, appears we can't resume the paused/saved domain but I can't see a clear reason why in the libvirtd logs.
09:15:00 lyarwood kashyap: https://review.openstack.org/#/c/571433/2 is the change FWIW
09:15:44 kashyap lyarwood: Hi, will look
09:29:38 jangutter sahid: Thanks for taking a look at https://review.openstack.org/567148 . I agree that there's "duplicate" info passed through for VIFHostDevice, but at least it's consistent with other VIF's. I think it has to do with the distinction between the VIF objects and the VIFPortProfile objects.
09:31:31 jangutter sahid: The os-vif VIF describes "how to wire it into the VM". The os-vif port-profile describes "how to wire it into the datapath". Because the distinction is not particularly clear with libvirt, there's some muddy overlap.
09:33:47 openstackgerrit Bhagyashri Shewale proposed openstack/python-novaclient master: Modify novaclient to support basic attributes https://review.openstack.org/572285
09:38:11 kashyap lyarwood: Meta comment: The libvirt debug log on the URL is supposedly: 3.2M. But my download of it is still running beyond 7MB
09:38:38 kashyap Maybe `wget` extracts it downloads
09:40:59 kashyap The full download (on a remote machine) was: 47M :-)
09:46:57 mdbooth kashyap: I'm looking at the libvirt logs from this multiattach job: http://logs.openstack.org/58/567258/5/check/nova-multiattach/d23fad8/logs/libvirt/libvirtd.txt.gz
09:47:25 mdbooth Specifically I'm trying to see what goes on during the successful multiattach swap volume test
09:49:23 mdbooth It looks like the drive of interest is added around 2018-06-04 10:56:57.865+0000
09:49:55 kashyap Can you tell the drive ID?
09:50:09 mdbooth drive-virtio-1
09:50:09 kashyap Is it? 'drive-virtio-disk1'
09:50:38 mdbooth I'm slightly confused, because I don't see shared in the 'human-monitor-command'
09:51:02 kashyap I don't see a "drive-virtio-1". Did you mean: 'drive-virtio-disk1'?
09:51:21 mdbooth But there is "share-rw":"on" in what seems to be sent to qemu
09:51:23 mdbooth kashyap: Yeah
09:51:27 kashyap libvirt uses QMP (the JSON RPC) with QEMU. Not HMP. (only rarely)
09:51:49 kashyap 2018-06-04 11:13:18.158+0000: 32308: debug : qemuMonitorJSONCommandWithFd:301 : Send command '{"execute":"device_add","arguments":{"driver":"virtio-blk-pci","scsi":"off","bus":"pci.0","addr"
09:51:49 kashyap Yes:
09:51:53 kashyap :"0x6","share-rw":"on","drive":"drive-virtio-disk1","id":"virtio-disk1"},"id":"libvirt-20"}' for write with FD -1
09:52:16 mdbooth Right, so that's 'shared', right?
09:52:25 kashyap mdbooth: Yes. And libvirt will _not_ migrate it.
09:52:28 mdbooth i.e. it's multiattach
09:52:36 kashyap Here is the libvirt source itself saying as such:
09:52:37 kashyap 291 !virStorageSourceIsEmpty(disk->src);
09:52:37 kashyap 290 return !disk->src->shared && !disk->src->readonly &&
09:52:37 kashyap 289 * with source */
09:52:37 kashyap 288 /* Default is to migrate only non-shared non-readonly disks
09:52:39 kashyap 292 }
09:52:42 kashyap 293
09:52:51 mdbooth kashyap: Except that it does
09:53:12 mdbooth Keep searching down on that disk id
09:53:49 mdbooth 2018-06-04 10:57:05.201+0000
09:53:53 mdbooth It does a drive mirror
09:54:18 mdbooth This isn't live migration, btw
09:54:24 mdbooth This is volume migration
09:54:52 mdbooth So the data in volume a is moved to volume b and a is seamlessly substituted for b in the domain
09:55:26 kashyap mdbooth: Hang on --
09:55:29 mdbooth So it looks like this version of qemu/libvirt at least does permit drive mirror of a shared disk
09:55:36 kashyap The `drive-mirror` is done fir 'disk0'
09:55:39 kashyap s/fir/for/
09:55:50 kashyap 2018-06-04 10:59:30.956+0000: 32306: debug : qemuMonitorJSONCommandWithFd:301 : Send command '{"execute":"drive-mirror","arguments":{"device":"drive-virtio-disk0","target":"/opt/stack/data/n
09:55:55 kashyap ova/instances/snapshots/tmpQeWSxD/8d2e75dbf0a4466fb31f11ca06a21a96.delta","sync":"top","mode":"existing","format":"qcow2"},"id":"libvirt-28"}' for write with FD -1
09:56:16 mdbooth kashyap: That's much later
09:56:21 mdbooth Different operation
09:56:27 mdbooth Look at 2018-06-04 10:57:05.201+0000
09:57:02 kashyap mdbooth: Okay, I seem to have misread the code :-(
09:57:07 kashyap mdbooth: libvirt _doesn't_ forbid
09:58:50 pvc hi
09:59:32 kashyap mdbooth: So libvirt should _not_ forbid because, the said shared disk might be in use at any given point.
09:59:45 kashyap But probably that's what you were trying to tell me.
10:00:05 mdbooth kashyap: Actually I think it *should* forbid it, but doesn't
10:00:11 pvc kashyap
10:00:25 pvc can help me with gpu instnace?
10:00:26 kashyap mdbooth: libvirt developer says the above reason is why it shouldn't forbid it
10:00:27 mdbooth Although... meh it should probably give us the rope to hang ourselves with
10:00:48 kashyap pvc: Hi, in the middle of something. Please ask such questions to the operators list or ask.openstack.org
10:01:09 kashyap (And I don't know the answer to it, top off my head)

Earlier   Later