| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-19 | |||
| 13:38:33 | gibi | mriedem: checked https://review.openstack.org/#/c/503601/ and +W-d it | |
| 13:38:33 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI for usages https://review.openstack.org/457535 | |
| 13:42:51 | avolkov | mriedem: I've already started on that and updated patches right now, will responsd to the comments later | |
| 13:44:55 | mriedem | gibi: thanks | |
| 13:51:53 | openstackgerrit | Pavlo Shchelokovskyy proposed openstack/nova master: Allow shuffling hosts with the same best weight https://review.openstack.org/494136 | |
| 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. |
|
| 14:30:38 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: use already loaded BDM in instance.create https://review.openstack.org/483969 | |
| 14:30:38 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: use already loaded BDM in instance. |
|
| 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 framework for RFB authentication https://review.openstack.org/345397 | |
| 14:39:29 | openstackgerrit | Stephen Finucane proposed openstack/nova master: console: introduce basic framework for security proxying https://review.openstack.org/345396 | |
| 14:39:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: console: provide an RFB security proxy implementation https://review.openstack.org/345399 | |
| 14:39:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: console: introduce the VeNCrypt RFB authentication scheme https://review.openstack.org/345398 | |
| 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 | jianghuaw | not sure. Maybe other resources which requires nested resource provider can follow similar implementation. | |
| 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: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. |
|
| 14:57:14 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: use already loaded BDM in instance. |
|
| 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 object https://review.openstack.org/489408 | |
| 15:06:09 | openstackgerrit | Brianna Poulos proposed openstack/nova master: Add trusted_certs to instance_extra https://review.openstack.org/457711 | |
| 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? | |