Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-09-19
14:06:58 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Migration from ``ip`` commands to ``pyroute2`` https://review.openstack.org/484386
14:11:49 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Add @targets_cell for live_migrate_instance method in conductor https://review.openstack.org/505285
14:13:28 mriedem sdague: there are two open changes in pike that could use review https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike - once those are merged, i'm going to cut a stable/pike release
14:13:33 mriedem claudiub: ^
14:14:15 claudiub ack
14:22:05 tonyb mriedem: we can't release right now due to zuulv3 issues
14:22:54 sdague mriedem: I see 5 changes there?
14:26:45 tonyb Looks liek there will be a race to see who +W's the last one ;P
14:30:37 openstackgerrit Balazs Gibizer proposed openstack/nova master: use already loaded BDM in instance. https://review.openstack.org/483324
14:30:38 openstackgerrit Balazs Gibizer proposed openstack/nova master: use already loaded BDM in instance. (2) https://review.openstack.org/483955
14:30:38 openstackgerrit Balazs Gibizer proposed openstack/nova master: use already loaded BDM in instance.create https://review.openstack.org/483969
14:32:06 mriedem sdague: 1 is already approved, 2 are -W
14:32:09 mriedem that leaves 2 "open"
14:32:11 gibi mriedem: I think I have proposed everything that is needed for bp additional-notification-fields-for-searchlight-queens
14:32:55 jianghuaw sahid, the real purpose for adding enabled_vgpu_types is to ensure only one vGPU type is enabled for each pGPU.
14:33:10 mriedem gibi: link? i'm not seeing the blueprint
14:33:35 gibi mriedem: https://review.openstack.org/#/q/topic:bp/additional-notification-fields-for-searchlight-queens
14:33:54 jianghuaw otherwise we need resolve the issue that multiple resource providers sharing the same resource when one pGPU support multiple types of VGPUs.
14:33:57 mriedem gibi: oh https://blueprints.launchpad.net/nova/+spec/additional-notification-fields-for-searchlight-queens
14:34:10 gibi mriedem: yepp
14:34:12 mriedem gibi: i think we could probably just close https://blueprints.launchpad.net/nova/+spec/additional-notification-fields-for-searchlight-queens and track the bdm perf fixes as a bug
14:34:23 gibi mriedem: that also works for me
14:35:02 gibi mriedem: then I will open a bug and update the series
14:35:48 mriedem thanks
14:35:59 jianghuaw sahid, see here libvirt need resolve filter basing on enable vGPU types also; as even mdev also will "enumerates all the supported mdev types":https://github.com/eskultety/libvirt/commit/d3a8fa3a0562791b8bfdf080da0bde5442cf2368#diff-facf5f0822fdb91d7ddc4e56537a8ac0R185
14:36:54 jianghuaw sahid, are you around?
14:38:12 sahid jianghuaw: yes but on call, can you comment on the review so i will reply to you after it
14:38:40 jianghuaw sahid, sure. I will. thanks.
14:39:29 openstackgerrit Stephen Finucane proposed openstack/nova master: console: introduce basic framework for security proxying https://review.openstack.org/345396
14:39:29 openstackgerrit Stephen Finucane proposed openstack/nova master: console: introduce framework for RFB authentication https://review.openstack.org/345397
14:39:30 openstackgerrit Stephen Finucane proposed openstack/nova master: console: introduce the VeNCrypt RFB authentication scheme https://review.openstack.org/345398
14:39:30 openstackgerrit Stephen Finucane proposed openstack/nova master: console: provide an RFB security proxy implementation https://review.openstack.org/345399
14:39:31 openstackgerrit Stephen Finucane proposed openstack/nova master: doc: Document TLS security setup for noVNC proxy https://review.openstack.org/500544
14:42:04 sahid jianghuaw: you mean that we should use the type id or the name to discover the device ?
14:42:12 sahid not sure to have understand your question
14:44:21 sahid jianghuaw: my point is that we are probably going to reuse the same code to handle PCI related devices based SRIOV
14:44:32 jianghuaw sahid, an example: NVIDIA GRID K1 support five different vgpu types:K180Q | K160Q | K140Q | K120Q | K100; But we need only expose one vPU type to nova for the resources for each pGPU.
14:44:35 sahid and probably also passthought
14:45:18 sahid jianghuaw: yes that is the point of that config you want to introduce, no?
14:45:20 jianghuaw ok. I see your point.
14:46:06 jianghuaw the problem is that xenserver won't expose vgpu as pci device. actually I attempted to use fake pci device before.
14:46:59 sahid jianghuaw: yes libvirt either
14:47:01 jianghuaw But that's thought be bad.
14:47:18 sahid i just think we should try to be more general and avoid to have specific options referenced by a name like gpu or something
14:48:01 jianghuaw The existing PCI code can't handle the case for vgpu.
14:48:22 jianghuaw There was a long discussion.
14:49:01 sahid i know that (well actually it could but anyway) basically the code you are going to build to handle vgpu is at some point going to also handle ethernet, right?
14:52:26 sahid jianghuaw: they are just devices using different kernel framework mdev/sriov ... at the end it's exposed to the guest as a pci device, i just want to be sure that the code you are going to implement is not too specific for gpu since it should handle any kind of devices
14:52:26 jianghuaw not sure. Maybe other resources which requires nested resource provider can follow similar implementation.
14:53:30 gibi mriedem: here is the optimization of BDM in notifications bug https://bugs.launchpad.net/nova/+bug/1718226
14:53:32 openstack Launchpad bug 1718226 in OpenStack Compute (nova) "bdm is wastefully loaded for versioned instance notifications" [Undecided,New]
14:53:37 sahid i don't think so we should have only one implementation
14:54:47 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Re-propose nested resource providers spec https://review.openstack.org/505209
14:57:14 openstackgerrit Balazs Gibizer proposed openstack/nova master: use already loaded BDM in instance. https://review.openstack.org/483324
14:57:14 openstackgerrit Balazs Gibizer proposed openstack/nova master: use already loaded BDM in instance. (2) https://review.openstack.org/483955
14:57:15 openstackgerrit Balazs Gibizer proposed openstack/nova master: use already loaded BDM in instance.create https://review.openstack.org/483969
14:57:34 gibi mriedem: and here is the updated patch series ^^
14:58:54 jianghuaw sahid, The spec is focusing on how to populate the resource providers and their inventory for vGPU. And as there is problem to handle multiple vGPU types; so added a new option to restrict one resource provider can only supply one type of resources. So are you suggesting to make the implementation on the restriction be common; so it can be re-used for future similar features?
15:03:40 sahid jianghuaw: yes since that option looks really similair to the requierements for other kind of devices (sriov..) i think we could have just one, and have one implementation to parse it
15:06:09 openstackgerrit Brianna Poulos proposed openstack/nova master: Add trusted_certs to instance_extra https://review.openstack.org/457711
15:06:09 openstackgerrit Brianna Poulos proposed openstack/nova master: Add trusted_certs to Instance object https://review.openstack.org/489408
15:06:10 openstackgerrit Brianna Poulos proposed openstack/nova master: Add trusted_certificates to REST API https://review.openstack.org/486204
15:06:42 jianghuaw sahid, I thought the problem to be resolved by this option is specific for vGPU. One pGPU can support different sized vGPUs. different capacity for different size. If created one size/type of vGPU on a pGPU, it can't create other size/type of vGPUs.
15:06:55 jianghuaw For other devices, is there similar issue?
15:11:10 sahid jianghuaw: hum... operators are going to creates some kind (size/type) vGPUs, but then that is not dynamic so the option is just about to parse which vCPUs we want to expose to Nova, no?
15:12:42 jianghuaw yes, the option is to make the vGPU type be static on one compute node.
15:12:50 sahid so even if a pGPU support different kinds, we want first to "allocate" the kind we want and bzsically create a pool of media which will be exposed to Nova
15:13:07 sahid jianghuaw: yes so basically it's what we have for sriov
15:15:04 sahid jianghuaw: just put your thinking on the review and let see what other contributors think... my point is just to implement one thing which could work for mdev/sriov
15:15:19 jianghuaw It will pre-restrict the type; and only create a resource provider for this specific type.
15:15:35 mriedem gibi: ack
15:16:03 jianghuaw Sure. if that's true a common thing, we can consider to make it general. Thanks sahid.
15:17:00 openstackgerrit Merged openstack/nova master: use unicode in tests to avoid SQLA warning https://review.openstack.org/505198
15:21:48 tasker mriedem: it looks like https://bugs.launchpad.net/nova/pike/+bug/1717365 affects several different code paths in addition to just the one identified previously.
15:21:49 openstack Launchpad bug 1717365 in OpenStack Compute (nova) "binding:profile is None breaks migration" [Medium,In progress] - Assigned to Matt Riedemann (mriedem)
15:22:23 mriedem tasker: want to point those out in the review then?
15:22:30 tasker sure can.
15:22:54 tasker I'm going to be a bit blind ( not understanding all of nova ), but I'll identify all of the lines that could result in the same problem.
15:23:04 mriedem there was one other place i saw that it was not checked but i didn't think we could have a failure in the other location if we fixed the one spot you hit properly
15:23:55 tasker I just hit it in _update_port_binding_for_instance() during post-migration tasks.
15:26:20 mriedem tasker: here? https://review.openstack.org/#/c/504260/2/nova/network/neutronv2/api.py@2509
15:29:47 ratailor melwitt, Could you please have a look on https://review.openstack.org/#/c/504885/
15:31:57 melwitt ratailor: yeah, that's an old issue and I'm not sure where things landed as far as how to fix it. I don't remember us wanting to change the collation type of the column or if there was a reason we shouldn't. sdague might be able to recall past discussion on that
15:32:37 ratailor melwitt, Thanks, I will try to catch him tomorrow.
15:51:12 gibi mriedem: Is it OK to have the following small notification addition as a specless BP? https://blueprints.launchpad.net/nova/+spec/emit-service-create-notification
15:55:35 gibi cdent: have you seen my question in https://review.openstack.org/#/c/502155/5/nova/tests/functional/db/test_resource_provider.py@1522 ? I'm eager to approve your patch series
16:00:12 tasker mriedem: yes.
16:00:53 ratailor sdague, Could you please have a look on https://review.openstack.org/#/c/504885/
16:03:10 openstackgerrit Merged openstack/nova stable/pike: Set error state after failed evacuation https://review.openstack.org/504979
16:05:01 openstackgerrit Eric Fried proposed openstack/nova master: Nix warning about protocol-less glance api_servers https://review.openstack.org/505317
16:05:04 efried sdague ^
16:09:03 tasker mriedem: I'm having some browser troubles intercepting the "ctrl+s" to save the comment. is there another way to commit my comment?
16:10:26 tasker mriedem: I think that https://review.openstack.org/#/c/504260/2/nova/network/neutronv2/api.py@263 needs to be guarded as well, but I can't get the comment to apply on the page.
16:12:48 efried tasker What's your gerrit ID?
16:13:43 tasker efried: my launchpad ID is egrh3. is that the same thing?
16:15:06 efried tasker Was trying to find other things you've commented on in the past. Go to the front page of that change set, click the "Add Reviewer" button (little person icon to the right on the "Reviewers" line) and punch "Add Me".
16:16:15 efried tasker gotcha. So what's happening when you try to submit a comment?
16:17:02 tasker I highlight the line, press 'c', write my comment, press [save] or "ctrl+s" and the box collapses and says "draft".
16:17:08 tasker but I don't know what to do beyond that.
16:18:11 efried tasker Ah, okay. You go back to the front page of the change and hit the Reply button. Vote if you like (or not) and hit the Post button.

Earlier   Later