Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-27
07:26:20 openstackgerrit Takashi NATSUME proposed openstack/nova-specs master: Change a validation in creating a server group https://review.openstack.org/546484
07:41:58 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Filter allocation candidates by forbidden traits in db https://review.openstack.org/556660
07:44:44 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Consider nested RPs in get_all_with_shared https://review.openstack.org/556450
07:44:44 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Support shared and nested allocation candidates https://review.openstack.org/556514
07:47:29 bauzas good morning Stackers
07:47:37 bauzas remember, today is a specs review day
07:53:37 openstackgerrit Konstantinos Samaras-Tsakiris proposed openstack/nova master: Add `hide_hypervisor_id` flavor extra_spec https://review.openstack.org/555861
07:56:26 openstackgerrit Naichuan Sun proposed openstack/nova master: (WIP)xenapi(N-R-P): Add API to support compute node resource provider update and create https://review.openstack.org/521041
07:57:35 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Noauth should also use request_id from compute_req_id.py https://review.openstack.org/555266
07:58:30 openstackgerrit Naichuan Sun proposed openstack/nova master: (WIP)xenapi(N-R-P): Add API to support compute node resource provider update and create https://review.openstack.org/521041
08:01:28 kholkina jichen, hi! could you please take a look at https://review.openstack.org/#/c/547964/
08:02:09 jichen kholkina: ok, right now
08:03:38 bauzas jianghuaw_: naichuans: around ?
08:07:31 openstackgerrit Takashi NATSUME proposed openstack/nova master: api-ref: Parameter verification for servers.inc (1/3) https://review.openstack.org/528201
08:14:19 openstackgerrit jichenjc proposed openstack/nova master: z/VM Driver: Initial change set of z/VM driver https://review.openstack.org/523387
08:14:20 openstackgerrit jichenjc proposed openstack/nova master: z/VM Driver: Spawn and destroy function of z/VM driver https://review.openstack.org/527658
08:14:20 openstackgerrit jichenjc proposed openstack/nova master: z/VM Driver: add snapshot function https://review.openstack.org/534240
08:14:21 openstackgerrit jichenjc proposed openstack/nova master: z/VM Driver: add power actions https://review.openstack.org/543340
08:14:21 openstackgerrit jichenjc proposed openstack/nova master: z/VM Driver: add get console output https://review.openstack.org/543344
08:15:20 jichen hi sahid, can you take a look at https://review.openstack.org/#/c/523387 and see whether it's what you want? thanks
08:23:11 openstackgerrit jichenjc proposed openstack/nova master: WIP: remove ec2 in service and cmd https://review.openstack.org/556778
08:24:48 sahid jichen: hello, yes, thanks that looks what i had in my head i will check that deeper soon
08:25:26 jichen sahid: thanks for thorough review and appreciate your further comments, thanks
08:27:01 sahid jichen: i made a simple request
08:27:35 sahid why you did not have moved zVMconnectorRequestHandler code in Hypervisor?
08:29:49 gibi bauzas: I read you discussion about matching the specific NUMA node selected by placement to the one that will be selected by the virt driver
08:30:39 gibi bauzas: and it sounds very similar to what I have with network RP selected by the placement vs. network selected by neutron agent on the physical level
08:31:55 jianghuaw_ bauzas, hi.
08:33:31 jianghuaw_ bauzas, what's up?
08:33:33 gibi bauzas: in the neturon case we think about communicating the RP selection to neutron during the port binding to ensure neutron has the necessary information
08:33:51 bauzas gibi: for the moment, we agreed on not having a problem
08:34:02 bauzas gibi: because the NUMA filter would get the same resources
08:35:22 bauzas jianghuaw_: just a question about vGPUs
08:36:05 bauzas jianghuaw_: given each pGPU is having multiple types and given each type is having specific vGPU number, I think using nested RPs for us would be something like :
08:36:07 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: Record the host info in EventReporter https://review.openstack.org/556746
08:36:27 bauzas jianghuaw_: root RP(compute) -> child RP (pGPU) -> child RP (GPU type)
08:36:38 bauzas jianghuaw_: WDYF ?
08:37:28 jianghuaw_ I think we still have to restrict each pGPU only support one vGPU type.
08:37:33 openstackgerrit Silvan Kaiser proposed openstack/nova master: Exec systemd-run with privileges in Quobyte driver https://review.openstack.org/554195
08:37:44 gibi bauzas: OK, then good for you
08:37:46 jianghuaw_ so root RP(compute) -> child RP (pGPU)<vgpu inventory>
08:38:14 bauzas jianghuaw_: if so, we should be asking operators to say which type for each PCI device, right?
08:38:28 bauzas if we want to support multiple types
08:38:51 jianghuaw_ I guess yes.
08:38:56 bauzas and also, I'm not sure that Intel has the same problem than nVidia where only one type is possible for each pGPU
08:39:11 jianghuaw_ For xen, it's root RP(compute) -> child RP (pGPU group)<vgpu inventory>
08:39:40 bauzas but each group is only having one type, right?
08:39:52 bauzas if so, how do you say which type for each group ?
08:41:08 jianghuaw_ all of the same type PGPUs will be put into the same group.
08:41:27 bauzas not sure I understand
08:41:50 bauzas each physical device is having multiple possible types
08:41:54 jianghuaw_ so still depending the configure option to restrict each grpu only has one type enabled.
08:42:32 jianghuaw_ But if there are multiple types of PGPUs exists in single compute. it can support different types.
08:43:05 bauzas say I'm doing enabled_vgpu_types=nvidia-1,nvidia-2
08:43:12 bauzas (or the name you use in Xen)
08:43:31 bauzas if I have 2 pGPUs, each one supporting both types, what Xen will have ?
08:43:39 bauzas two pGPU groups ?
08:43:42 jianghuaw_ Also we can ask operators to customize the pGPU groups. Then we can put some pgpus into group1 and then other others be group2.
08:43:52 jianghuaw_ and each can enable different vGPU types.
08:45:45 jianghuaw_ switching to a meeting.
08:47:35 jichen sahid: sorry for delay, I replied in the patch and saw your question here
08:47:48 bauzas jianghuaw_: mmmm, not sure I like that
08:55:26 kashyap melwitt: When you're back: the ListOpt() trick works -- https://review.openstack.org/#/c/534384/
09:04:11 openstackgerrit Theodoros Tsioutsias proposed openstack/nova-specs master: Add PENDING vm state https://review.openstack.org/554212
09:10:30 openstackgerrit Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA topology with RPs https://review.openstack.org/552924
09:18:56 openstackgerrit Konstantinos Samaras-Tsakiris proposed openstack/nova master: Add `hide_hypervisor_id` flavor extra_spec https://review.openstack.org/555861
09:24:01 ktibi Hi, how can I disable the compatibility check for live migration ? because I have two CPU model : Nehalem & Nehalem-IBRS and migration fail :/
09:36:49 openstackgerrit Tetiana Lashchova proposed openstack/nova-specs master: Allow modification of user-data via the server update https://review.openstack.org/547964
09:41:06 jianghuaw_ bauzas, came back from a call meeting. I understood your concern. The problem is that we can't handle the dynamically changing vGPU capacities.
09:41:22 openstackgerrit Bhagyashri Shewale proposed openstack/nova-specs master: Disallow rotation parameter 0 for 'createBackup' API https://review.openstack.org/511825
09:41:42 jianghuaw_ I mean the available vGPUs for one type will be impacted by other types belongs to the same pGPU.
09:42:15 jianghuaw_ that's why we have to keep the restriction that each PGPU (or pgpu group) can only expose one vGPU type.
09:42:24 kaisers1 mikal: I'm not sure which direction to go in https://review.openstack.org/#/c/554195/ , could you pls review regarding Stephens comments?
09:43:27 bauzas jianghuaw_: sure but I don't think it's a problem
09:44:17 bauzas jianghuaw_: at least for libvirt, what I know is that if I'm providing multiple inventories, then when I'll create the first mdev, it'll automatically update the inventories of the other types to be total=0
09:45:34 jianghuaw_ bauzas, will it cause conflict?
09:46:36 jianghuaw_ in the case multiple vGPUs have been allocated from multiple inventories
09:47:53 jianghuaw_ Before create the first mdev, all inventories will have >0 vGPUs available. Right?
09:48:39 jianghuaw_ If yes, it's possible to allocate vGPUs from different inventories.
09:49:31 jianghuaw_ Then the first mdev creation will result into the other inventories' total be 0. the allocatoin for the other vGPUs will fail. right?
09:50:43 openstackgerrit Matthew Booth proposed openstack/nova-specs master: Add serial numbers for local disks https://review.openstack.org/556565
09:52:37 openstackgerrit Silvan Kaiser proposed openstack/nova master: Exec systemd-run with privileges in Quobyte driver https://review.openstack.org/554195
09:55:28 stephenfin kashyap: This of any interest? Abandoning if not https://review.openstack.org/#/c/348394/
09:56:52 kashyap stephenfin: That's another piecemeal way of fixing the current mess of handling different OVMF binaries
09:57:15 kashyap stephenfin: Can be abandoned, IMHO. And we should handle it globally for all distributions
09:57:50 kashyap https://review.openstack.org/#/c/506720/
09:58:16 kashyap stephenfin: Which is in turn a bit predicated on this RFC I started for libvirt and QEMU: [RFC] Defining firmware (OVMF, et al) metadata format & file
09:58:19 kashyap https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg01978.html
09:58:20 stephenfin kashyap: Cool, done
10:01:01 stephenfin sahid: Any chance you could abandon these, now that bauzas' vGPU series has merged? https://review.openstack.org/#/q/topic:pci-mdev-support-compaq+(status:open+OR+status:merged)
10:15:40 sahid stephenfin: i'm expecting gerrit to abandon them automatically at some point
10:16:22 stephenfin Ah, it doesn't do that. Someone (typically sdague in the past) had to run a script or something
10:27:51 kashyap stephenfin: Question for you here: https://review.openstack.org/#/c/530924/
10:28:49 kashyap Also, sigh (existing fault), naming nuisance: 'disk_cachemodes' (should be 'disk_cache_modes')
10:29:30 kashyap Changing such things at this point would be futile (for OCD's sake), as it might break scripts, & other tools, etc :-(
10:56:52 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Filter resource providers by forbidden traits in db https://review.openstack.org/556472
10:56:52 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Filter allocation candidates by forbidden traits in db https://review.openstack.org/556660
10:56:53 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Parse forbidden traits in query strings https://review.openstack.org/556819
10:56:53 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Support forbidden traits in API https://review.openstack.org/556820
10:57:25 cdent Okay, with that done, I can brew up to start the spec dive

Earlier   Later