| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-19 | |||
| 08:20:34 | openstackgerrit | jichenjc proposed openstack/nova master: check query param for service's index function https://review.openstack.org/489492 | |
| 08:59:00 | openstackgerrit | jichenjc proposed openstack/nova master: check query param for server groups function https://review.openstack.org/500347 | |
| 09:24:15 | openstackgerrit | Merged openstack/nova master: doc: Further cleanup of doc contributor guide https://review.openstack.org/504456 | |
| 10:08:54 | kashyap | kaisers: Ah, will look. Buried in something else | |
| 10:40:15 | openstackgerrit | Elod Illes proposed openstack/nova stable/ocata: Functional test for regression bug #1713783 https://review.openstack.org/505160 | |
| 10:40:17 | openstack | bug 1713783 in OpenStack Compute (nova) pike "After failed evacuation the recovered source compute tries to delete the instance" [High,In progress] https://launchpad.net/bugs/1713783 - Assigned to Matt Riedemann (mriedem) | |
| 10:45:42 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove dead code of api.fault notification sending https://review.openstack.org/505164 | |
| 11:07:22 | openstackgerrit | Murali Annamneni proposed openstack/nova master: Enables MySQL Cluster Support for Nova https://review.openstack.org/446643 | |
| 11:40:21 | kaisers | kashyap: ok, thanks already :) | |
| 11:50:05 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove dead code of api.fault notification sending https://review.openstack.org/505164 | |
| 12:00:12 | stephenfin | sdague: Fancy taking a look at this https://review.openstack.org/#/c/502017/ ? Final +2 needed | |
| 12:00:49 | sdague | +A | |
| 12:16:12 | openstackgerrit | Sean Dague proposed openstack/nova master: use unicode in tests to avoid SQLA warning https://review.openstack.org/505198 | |
| 12:19:48 | openstackgerrit | Sean Dague proposed openstack/nova master: Enable custom certificates for keystone communication https://review.openstack.org/485121 | |
| 12:21:33 | openstackgerrit | Lajos Katona proposed openstack/nova master: Change live_migrate tests to use fakedriver https://review.openstack.org/505202 | |
| 12:35:47 | openstackgerrit | Sean Dague proposed openstack/nova master: Change livesnapshot to true by default https://review.openstack.org/454323 | |
| 12:48:21 | openstackgerrit | Ed Leafe proposed openstack/nova-specs master: Re-propose nested resource providers spec https://review.openstack.org/505209 | |
| 12:48:38 | edleafe | mriedem1: ^^ | |
| 13:11:42 | mriedem | need one more core on this https://review.openstack.org/#/c/503601/ | |
| 13:15:40 | liliars | Morning everyone. I have a question regarding the LXC hypervisor (if this is not the place to ask, please lmk). Outside OpenStack, when using LXC containers, I can add devices to the given container by doing "lxc config device add..". I'm trying to reproduce this process now using OpenStack. Can I do this at all? If yes, is there a way I can do it during the creation of my instance? I'm running OpenStack Ansible, ocata release. | |
| 13:15:56 | mriedem | avolkov: this was the osc placement plugin change i was talking about yesterday https://review.openstack.org/#/c/457532/ - i've done some review on it and it just needs updating. shouldn't be too hard. | |
| 13:16:26 | mriedem | liliars: i don't think that's possible with the lxc backend in nova | |
| 13:16:38 | mriedem | the lxc support in nova is really limited, not tested and not really maintained | |
| 13:17:31 | mriedem | what you're describing sounds like attaching a block device to an existing guest and i'm pretty sure that's not supported with the nova driver | |
| 13:23:19 | openstackgerrit | Merged openstack/nova master: Fix the ocata config-reference URLs https://review.openstack.org/502017 | |
| 13:26:44 | liliars | mriedem: that's exactly what I want. so it is not supported, but lets say I want to change the code to allow me to do this. I looked at nova/virt/libvirt/driver.py and saw a block_device_info parameter in some methods regarding lxc. Even if initially the change was pretty hard coded, would it be possible? I'm happy to spend some time on this, but if it's not possible at all, I'll try and think of a different approach. | |
| 13:31:57 | mriedem | liliars: it's possible but i'm not sure what's needed to attach the block device to the lxc guest, maybe it's just running 'lxc config device add' | |
| 13:32:10 | mriedem | you're free to tinker of course | |
| 13:34:21 | mriedem | alex_xu: comment inline on your traits API spec https://review.openstack.org/#/c/497713/ - pretty small ones though | |
| 13:38:24 | liliars | mriedem: I have a compute dedicated to LXC in my current installation, and I need to attach to the containers a device that is installed there. so maybe it's just running this command but I can't do it from my host, which complicates things. anyways, thank you! knowing a bit more about the limitations does help (: | |
| 13:38:31 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI for resource providers https://review.openstack.org/457532 | |
| 13:38:32 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI for allocations https://review.openstack.org/457534 | |
| 13:38:32 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI for inventories https://review.openstack.org/457533 | |
| 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 | |