Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-05-31
09:01:52 bauzas naichuans: first, docs https://docs.openstack.org/nova/latest/user/upgrade.html
09:02:31 bauzas naichuans: I mean https://docs.openstack.org/nova/latest/user/upgrade.html#data-migrations
09:03:28 bauzas naichuans: and then code https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L375
09:04:52 naichuans bauzas: will check it, thanks
09:11:17 bauzas naichuans: replied to the thread with a proposal, lemme give you the link
09:12:21 naichuans bauzas: OK
09:12:51 bauzas naichuans: there it is http://lists.openstack.org/pipermail/openstack-dev/2018-May/130955.html
09:13:23 bauzas naichuans: does Xen support vGPU live migration ?
09:13:34 naichuans bauzas: got it~
09:13:58 bauzas because QEMU folks say it's a very difficult thing to implement because there are a huge number of corner cases to consider
09:22:16 kashyap bauzas: Which part is this?
09:22:29 kashyap Ah, Xen
09:22:36 bauzas kashyap: which part of what ?
09:22:49 kashyap Difficulty in implementing in QEMU
09:23:12 bauzas maybe the wording is inappropriate
09:23:40 bauzas it's not "difficult", it's just quite having a lot of cases to consider
09:30:41 naichuans bauzas: sorry, just saw your message about VGPU live migration. XenServer do support live migration
09:44:14 naichuans bauzas: just finish reading your conversation history about n-rp in vGPU. You are using DB online migration to avoid compute service restart, right?
09:49:49 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: libvirt: handle DiskNotFound during update_available_resource https://review.openstack.org/571424
09:49:50 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: libvirt: Skip fetching the virtual size of block devices https://review.openstack.org/571425
09:50:39 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: libvirt: handle DiskNotFound during update_available_resource https://review.openstack.org/571426
09:50:40 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: libvirt: Skip fetching the virtual size of block devices https://review.openstack.org/571427
09:56:36 openstackgerrit Balazs Gibizer proposed openstack/nova master: Reject interface attach with QoS aware port https://review.openstack.org/570078
09:56:37 openstackgerrit Balazs Gibizer proposed openstack/nova master: Reject networks with QoS policy https://review.openstack.org/570079
09:58:21 openstackgerrit wanghongtao proposed openstack/nova master: Fix the metadata re to match the unicode https://review.openstack.org/536236
10:07:31 openstackgerrit Merged openstack/nova master: pci: don't consider case when match tags specs https://review.openstack.org/565808
10:16:40 openstackgerrit Lee Yarwood proposed openstack/nova stable/ocata: libvirt: handle DiskNotFound during update_available_resource https://review.openstack.org/571432
10:16:41 openstackgerrit Lee Yarwood proposed openstack/nova stable/ocata: libvirt: Skip fetching the virtual size of block devices https://review.openstack.org/571433
10:20:27 sahid artom: thanks for what you did on the vf trusted serie :)
10:21:00 artom sahid, oh, hah, I'd just apologized on the downstream channel
10:21:47 sahid artom: yes but, please don't, i have appreciated thanks again
10:22:33 artom sahid, cool, you're welcome :)
10:22:44 artom We *really* need to unfsck the metadata API
10:23:15 artom The fact that we're not using templates, and adding/removing stuff based on ifs...
10:23:21 artom *Versioned* templates, I should say
10:23:38 sahid artom: i see, yes that make sense to have such mech
10:24:08 artom sahid, well the "real" API uses those, I believe
10:27:00 sahid artom: i did not get time to look at your serie about the live migration, i saw that it's still in WIP - my understanding is i could wwait a bit more before to start reviewing it
10:27:11 sahid or do you think we should start to make some reviews?
10:27:17 artom sahid, yeah, no worries, there's not much there yet
10:27:23 artom Well
10:28:07 artom https://review.openstack.org/#/c/566398/7 and https://review.openstack.org/#/c/566723/8 and ready
10:28:23 artom The last one is marked WIP because the one below it is
10:28:35 artom It's like a WIP sandwich
11:27:56 openstackgerrit Hironori Shiina proposed openstack/nova master: virt/ironic: Implement rescue and unrescue https://review.openstack.org/416487
11:51:24 openstackgerrit Hironori Shiina proposed openstack/nova master: WIP: virt/ironic: Implement rescue and unrescue https://review.openstack.org/571450
11:57:43 openstackgerrit Jan Gutter proposed openstack/os-vif master: Add virtio_multiqueue field to InstanceInfo https://review.openstack.org/570959
12:34:01 openstackgerrit Zhenyu Zheng proposed openstack/nova master: WIP abort live migration in queue. https://review.openstack.org/568542
12:36:55 openstackgerrit Zhenyu Zheng proposed openstack/nova master: WIP abort live migration in queue. https://review.openstack.org/568542
12:37:33 openstackgerrit Jan Gutter proposed openstack/nova master: Convert vrouter legacy plugging to os-vif https://review.openstack.org/571325
12:37:34 openstackgerrit Jan Gutter proposed openstack/nova master: Use vif.vif_name in _set_config_VIFGeneric https://review.openstack.org/571461
12:37:35 openstackgerrit Jan Gutter proposed openstack/nova master: Pass virtio multiqueue info to os-vif plugins https://review.openstack.org/571462
12:51:44 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: WIP: Adapt _validate_instance_group_policy to new policy model https://review.openstack.org/571465
13:13:47 openstackgerrit Surya Seetharaman proposed openstack/nova master: Delete orphaned RS and IM records of archived instances https://review.openstack.org/560042
13:14:19 openstackgerrit Chen proposed openstack/nova master: WIP Closes-Bug: #1449221 https://review.openstack.org/571472
13:14:20 openstack bug 1449221 in OpenStack Compute (nova) "Nova doesn't allow cleanup of volumes stuck in 'attaching' or 'detaching' status" [High,Confirmed] https://launchpad.net/bugs/1449221
13:50:29 melwitt nova meeting in 10 minutes
13:53:00 mriedem dansmith: can you get this queens backport? https://review.openstack.org/#/c/571425/
13:54:13 mriedem lyarwood: looks like you have something to fix in this one https://review.openstack.org/#/c/571433/
13:57:02 dansmith hmm, not sure why that depends on the update resource patch
13:57:59 lyarwood mriedem: yeah, couldn't run tox locally for Ocata for some reason, I'll get to it later today
13:58:44 lyarwood dansmith: it just keeps the backport clean, I was already looking to backport the resource patch anyway so...
13:59:24 dansmith hmm, okay
14:00:55 openstackgerrit sahid proposed openstack/os-vif master: Add virtio_multiqueue field to InstanceInfo https://review.openstack.org/570959
14:04:13 openstackgerrit Jay Pipes proposed openstack/nova master: placement: always create consumer records https://review.openstack.org/567678
14:04:14 openstackgerrit Jay Pipes proposed openstack/nova master: add consumers generation field https://review.openstack.org/557958
14:04:15 openstackgerrit Jay Pipes proposed openstack/nova master: placement: Allocation.consumer field https://review.openstack.org/565405
14:04:16 openstackgerrit Jay Pipes proposed openstack/nova master: rework allocation handler _allocations_dict() https://review.openstack.org/565407
14:04:17 openstackgerrit Jay Pipes proposed openstack/nova master: Add a microversion for consumer generation support https://review.openstack.org/565604
14:09:00 jaypipes btw, dansmith, fixed the silly pep8 error in ^
14:09:16 dansmith ack
14:09:18 jaypipes dansmith: let me know if you'd like further tests added for ensure_consumer()
14:09:27 dansmith you know I will
14:09:30 jaypipes :)
14:10:07 mriedem i had some random thoughts about a nova-status upgrade check for the missing consumer stuff,
14:10:14 mriedem but haven't thought about it much
14:10:25 mriedem basically query the api db for allocations w/o a consumer
14:10:36 mriedem but not sure what to do if we find them
14:10:42 jaypipes mriedem: the bottom patch on that series adds an online db migration for "incomplete" consumers.
14:10:46 dansmith you want nova-status to connect directly to the placement database?
14:11:03 mriedem nova-status already connects directly to the nova_api db, which is the placement db today
14:11:09 mriedem jaypipes: yeah i forgot about that
14:11:17 dansmith right, but it muddies the water for a split
14:12:16 mriedem yeah if we have an online data migration i'm not sure we need an upgrade status check thing
14:13:34 mriedem i think i was thinking,
14:13:53 mriedem somehow healing the allocations / creating missing consumers based on the actual instance for the allocation, rather than the config options
14:13:59 mriedem which is what jay's online data migration is using it looks like
14:14:51 dansmith hmm
14:15:17 dansmith I mean, I guess we can do that now, but we won't be able to do things like that past the split, so I would think we should stick to being cleanly separated even before
14:15:42 jaypipes mriedem: your heal_allocations() work would already do that (once the always create consumer patch is merged, of course)
14:16:00 mriedem jaypipes: the heal_allocations CLI won't do anything if the instance already has allocations
14:16:06 mriedem but it doesn't check if the project/user is missing
14:16:17 jaypipes mriedem: ah, yes, true nuf
14:16:41 mriedem https://review.openstack.org/#/c/565886/9/nova/cmd/manage.py@1794
14:21:14 sahid jangutter: i have question for you in the osvif patch
14:21:27 jangutter shoot!
14:21:50 mriedem jaypipes: having said that, we could make heal_allocations look to see if the existing allocations are missing consumer/project and re-post the allocations w/ the consumer/project if so
14:22:40 sahid jangutter: is that could help whether we have that new virtio_multiqueu attribute an integer, so we can pass the exact number of queue enabled?
14:23:35 jangutter sahid: I dunno, this is weird territory for me... literally the only code I could find used iproute2 to enable "multiqueue" and that's it.
14:23:52 jaypipes mriedem: IIRC, that was my original suggestion that I could do that in the online DB migration

Earlier   Later