| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-25 | |||
| 07:36:06 | openstackgerrit | jichenjc proposed openstack/nova master: Move assertEqual order of test_services.py https://review.openstack.org/507007 | |
| 08:04:15 | openstackgerrit | Takashi NATSUME proposed openstack/nova-specs master: List/show all server migration types https://review.openstack.org/489029 | |
| 09:08:43 | openstackgerrit | Lei Zhang proposed openstack/nova-specs master: Request traits in Nova https://review.openstack.org/468797 | |
| 09:16:42 | openstackgerrit | Merged openstack/nova master: Make 'fault' a valid joined query field for Instance https://review.openstack.org/506774 | |
| 09:18:01 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova-specs master: [WIP] Add ability for OVMF Secure Boot https://review.openstack.org/506720 | |
| 09:20:53 | openstackgerrit | Merged openstack/nova master: Add get_instance_objects_sorted() https://review.openstack.org/505417 | |
| 09:40:00 | openstackgerrit | jichenjc proposed openstack/nova master: check query param for service's index function https://review.openstack.org/489492 | |
| 10:32:48 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: WIP: Support traits in the Ironic driver https://review.openstack.org/507052 | |
| 10:47:20 | openstackgerrit | Merged openstack/nova master: Add datapath type information to OVS vif objects https://review.openstack.org/474892 | |
| 11:02:33 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform aggregate.update_prop notification https://review.openstack.org/462576 | |
| 11:11:03 | openstackgerrit | Lei Zhang proposed openstack/nova master: placement: extract traits from flavor extra spec https://review.openstack.org/492026 | |
| 11:17:41 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform libvirt.error notification https://review.openstack.org/484851 | |
| 11:21:47 | openstackgerrit | Elod Illes proposed openstack/nova master: Add error notification for instance.interface_attach https://review.openstack.org/506643 | |
| 11:29:26 | openstackgerrit | caoyuan proposed openstack/nova master: cleanup test-requirements https://review.openstack.org/507063 | |
| 11:51:42 | openstackgerrit | Elod Illes proposed openstack/nova master: Add error notification for instance.interface_attach https://review.openstack.org/506643 | |
| 12:13:15 | openstackgerrit | Merged openstack/nova master: Add default configuration files to data_files https://review.openstack.org/506188 | |
| 12:25:03 | openstackgerrit | Merged openstack/nova master: Add PowerVM hypervisor configuration doc https://review.openstack.org/505665 | |
| 12:32:11 | sdague | anyone else want to bring this one home - https://review.openstack.org/#/c/454323/ - it enables live snapshot by default | |
| 12:35:46 | cdent | sdague: I approve of your subtle s/Garbage// | |
| 12:46:11 | stephenfin | sdague: Done | |
| 12:46:19 | sdague | stephenfin: thanks! | |
| 12:47:08 | sdague | stephenfin: it would also be cool to get your eyes on this one - https://review.openstack.org/#/c/505673/ - so that we could enable the pike ppa on ubuntu, as we don't work with qemu 2.10 right now | |
| 12:49:35 | stephenfin | sdague: Yup, that was on my list for today. One last question - why 'operator.ge' in [1]? https://review.openstack.org/#/c/505673/5/nova/virt/images.py | |
| 12:49:43 | stephenfin | (More out of curiosity than anything) | |
| 12:52:35 | sdague | stephenfin: that was in mriedem's original patch, it seemed fine to stay. It could be regular operators as well | |
| 12:53:13 | stephenfin | sdague: Figured. It looked good to me anyway so +2d | |
| 12:53:35 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226 | |
| 12:54:00 | efried | jaypipes https://review.openstack.org/#/c/497713/4/specs/queens/approved/add-trait-support-in-allocation-candidates.rst@72 -- Are you suggesting that we be able to model an optional trait as an inventory-less resource class? | |
| 12:57:43 | sdague | stephenfin: ty | |
| 13:19:47 | bauzas | stephenfin: do we have in Pike a config options page that shows what tox -genconfig does ? | |
| 13:19:56 | bauzas | I mean in the docs tree | |
| 13:20:48 | bauzas | stephenfin: nevermind, https://docs.openstack.org/nova/latest/configuration/config.html | |
| 13:20:58 | mriedem | simple change here that unblocks a few other changes https://review.openstack.org/#/c/506104/ | |
| 13:21:43 | mriedem | bauzas: this is more like what the nova.conf.sample would look like https://docs.openstack.org/nova/latest/configuration/sample-config.html | |
| 13:27:12 | jaypipes | efried: err, no... | |
| 13:28:10 | efried | jaypipes I added a comment with an example use case. Generally, curious how that class of use case is supposed to be handled. | |
| 13:28:25 | jianghuaw | bauzas, jaypipes: If don't cover NUMA, is it possible to support vGPU with the approach of resource provider in queens? I understand the nested RP won't be completed in in queens. But maybe we don't need the full functions within nested RP for vGPU. As it's much straight. Only put the vGPU resource provider as the compute's children. | |
| 13:29:29 | mriedem | jianghuaw: we plan on implemented nested resource providers in queens | |
| 13:29:39 | mriedem | but i don't think we plan on focusing on numa use cases | |
| 13:29:49 | bauzas | jianghuaw: I don't think we should worry on NUMA resources now | |
| 13:29:49 | mriedem | *implementing | |
| 13:30:29 | bauzas | jianghuaw: because once compute nodes will report NUMA cells using nested RPs, we'll get both vGPU support and NUMA handling tied together | |
| 13:30:37 | jianghuaw | mriedem, bauzas, thanks. In that case, I believe we will proceed to implement vGPU with resource provider. right? | |
| 13:30:49 | jianghuaw | bauzas, cool. | |
| 13:31:15 | bauzas | jianghuaw: for the moment, I see vGPU resources as just traits and resource classes attached to a specific RP | |
| 13:31:54 | bauzas | if one implements NUMA reporting with nested RPs, that will just mean that vGPU resource classes will be attached to the child RP that is providing the NUMA cell | |
| 13:32:04 | bauzas | if that's a PCI device | |
| 13:32:22 | jianghuaw | yeah, fair enough. | |
| 13:32:52 | bauzas | jianghuaw: I actually raised that point in a comment in your change | |
| 13:33:11 | bauzas | jianghuaw: but I was waiting for jaypipes acking or not that | |
| 13:33:18 | jaypipes | bauzas: ack | |
| 13:33:31 | bauzas | cool then | |
| 13:33:34 | jianghuaw | :-) | |
| 13:33:41 | bauzas | then, no need to wait for NUMA-isms | |
| 13:33:46 | jianghuaw | that's great. | |
| 13:34:06 | bauzas | jianghuaw: I actually owe you a new review of your spec | |
| 13:34:32 | bauzas | and I owe jaypipes a serious review of his nested RP series | |
| 13:34:42 | bauzas | jaypipes: you said you were about to rebase, right? | |
| 13:35:02 | bauzas | mriedem: interesting bug https://bugs.launchpad.net/nova/+bug/1717915 | |
| 13:35:03 | openstack | Launchpad bug 1717915 in oslo.messaging "nova services and transport_url, cannot connect to vhost if specified" [Undecided,New] | |
| 13:35:42 | openstackgerrit | Eric Fried proposed openstack/nova master: Live Migration sequence diagram https://review.openstack.org/506370 | |
| 13:35:49 | efried | alex_xu Like-a-this? ^ | |
| 13:35:50 | jianghuaw | bauzas, Thanks for have reviewed my spec for may rounds and given may useful comments. | |
| 13:35:55 | jaypipes | bauzas: done last week: https://review.openstack.org/#/q/topic:bp/nested-resource-providers | |
| 13:36:09 | bauzas | jaypipes: cool, that's then my top prio | |
| 13:36:23 | jaypipes | efried: answered on spec. | |
| 13:36:27 | efried | thx | |
| 13:36:49 | jianghuaw | bauzas, jaypipes: I do need your help on how to define that options to restrict only one vGPU type is exposed. | |
| 13:37:25 | jaypipes | jianghuaw: sorry, not following you... is this a patch you've proposed? | |
| 13:37:54 | mriedem | bauzas: yes, you'll see i was already triaging it | |
| 13:38:14 | jianghuaw | jaypipes, I mean this patch:https://review.openstack.org/#/c/450122 | |
| 13:39:06 | jianghuaw | sahid suggested to make the option to be general. | |
| 13:39:17 | bauzas | mriedem: yup, I saw hence my ping | |
| 13:39:30 | bauzas | mriedem: it was an implicit 'good call, but what should we do next" ? | |
| 13:39:58 | mriedem | idk, i hoped that the rhops guys would know since you guys run with clustered rabbit | |
| 13:39:59 | bauzas | because looks like it's something that worked in the past but we never officially supported it | |
| 13:40:03 | mriedem | *rhosp | |
| 13:40:33 | bauzas | owalsh: around ? | |
| 13:41:44 | bauzas | jaypipes: the only point that is still concerning me about https://review.openstack.org/#/c/450122 is how we draft the whitelist | |
| 13:42:18 | bauzas | jaypipes: as it can be different for each virt driver | |
| 13:42:18 | jaypipes | bauzas: I had specifically asked jianghuaw to make the config option *not* the pci_passthrough_whitelist | |
| 13:42:26 | jaypipes | bauzas: how so? | |
| 13:42:34 | mriedem | jianghuaw: bauzas: jaypipes: ew, yeah, was just going to ask if this is a new pci whitelist but for gpus | |
| 13:42:51 | jaypipes | mriedem: yes, I asked for that. | |
| 13:43:07 | bauzas | jaypipes: well, jianghuaw made a very explicit pci-tied config option | |
| 13:43:13 | bauzas | I probably missed your point then | |
| 13:43:33 | bauzas | but I'm fine with just a ListOpt containing strings that would match device IDs | |
| 13:43:54 | bauzas | it would be up to the driver to find the right GPU that matches the string | |
| 13:44:16 | jaypipes | bauzas: are you referring to the fact that the proposed enabled_vgpu_types CONF option has vendor_id and product_id keys? | |
| 13:44:27 | bauzas | like enabled_vgpu_types = ['nvidia-11', 'nvidia-10'] | |
| 13:44:38 | bauzas | yeah, that is too specific | |
| 13:45:08 | bauzas | jianghuaw: ^ | |
| 13:45:22 | edleafe | Scheduler subteam meeting in 15 minutes in #openstack-meeting-alt | |
| 13:45:54 | jianghuaw | how about use the vGPU type's name instead of the id? by considering the type name is common from both XenServer and kvm? enabled_vgpu_types = ['GRID K160Q'...] | |
| 13:46:44 | jianghuaw | As I explained in the comment, both virts can get the type name - "GRID K160" | |
| 13:47:09 | jianghuaw | And that's also the name recorded in the user guide. | |
| 13:48:16 | sdague | mriedem: with you and I both with fingers in the qemu 2.10 patch, you want a 4th core to look into it - https://review.openstack.org/#/c/505673/ - or you want to just make sure my update isn't crazy and put it in | |
| 13:48:26 | bauzas | jianghuaw: and what if I have two exact same cards ? | |
| 13:48:49 | sahid | mriedem: did you notice my request, continuing development on /pci and in parallel working on porting virt features on RP | |
| 13:49:01 | mriedem | sdague: i looked at it last week, which is how we went down the paused rabbit hole | |