Earlier  
Posted Nick Remark
#openstack-nova - 2018-03-27
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
11:03:17 openstackgerrit Surya Seetharaman proposed openstack/nova master: Scheduling Optimization: Remove cell0 from the list of candidates https://review.openstack.org/556821
11:05:45 sean-k-mooney melwitt: not that my vote counts in the actul ballot but i had assumed efried had a +/-1.5 for a while so i'd also be +1 on the proposal to add you to the core team.
11:11:25 kashyap sean-k-mooney: What do you mean 1.5?
11:12:23 kashyap (Also: IMHO, even if your vote doesn't "count" by some measure, active contributors such as you expressing their views is equally important, in my books.)
11:12:28 sean-k-mooney kashyap: that while efried does not have +2 right currently there are some area of the code where his +/- 1 are treated as +/- 2 due to the experience he has demonstrated in that area
11:12:57 kashyap I see. I guessed as much, just wanted to double-confirm.
11:13:42 kashyap sean-k-mooney: Unrelated bait (apologies): I think this is ready: https://review.openstack.org/#/c/534384/
11:13:46 sean-k-mooney kashyap: it does not "count" because the vote is between members of the core team rather then an open vote. but yes i know its still valuble for active memeber to express there support/decent
11:14:01 sean-k-mooney kashyap: oh yes i skimmed it yesterday
11:14:32 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: Record the host info in EventReporter https://review.openstack.org/556746
11:14:43 kashyap sean-k-mooney: Thanks! Tests pass, backport concerns addressed, rel note in place (removed needless verbosity per dansmith's review)
11:15:01 sean-k-mooney i see you got the release nots job passing
11:15:12 kashyap Yep! I got the rST dark magic right
11:15:43 sean-k-mooney ill quickly review again but last time i looked it seamed fine to me
11:16:09 kashyap sean-k-mooney: Thanks, the core change is quite small: I limit the 'choices' keyword arg to one value (PCID)
11:16:12 sean-k-mooney i saw dans comment and kind of aggreed but not strongly enough to ask for a respin
11:16:28 kashyap sean-k-mooney: Yeah; I reworded it, and moved the CPU models info into the config file
11:16:37 kashyap As Operators can assume that it can be applied to all models.
11:16:59 kashyap As we know, some virtual CPU models include it (like the Haswell variants), some don't (Nehalem, etc).
11:19:51 sean-k-mooney item_type=types.String(
11:19:53 sean-k-mooney choices=['pcid']
11:19:55 sean-k-mooney )
11:19:57 sean-k-mooney thats new to me
11:20:23 sean-k-mooney kashyap: is that syntax documented in oslo somewhere?
11:20:45 kashyap sean-k-mooney: Not quote, I found it from stephenfin's use here: https://github.com/openstack/nova/blob/cd15c3d/nova/conf/vnc.py#L226,L232
11:20:50 kashyap s/quote/quite/
11:20:59 kashyap sean-k-mooney: I only skimmed the oslo_config/cfg.py, though
11:21:21 kashyap https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py
11:21:22 sean-k-mooney kashyap: well i have used choice elements for string fields before just never lists
11:21:44 kashyap sean-k-mooney: It's actually documented here: https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py#L52
11:24:09 sean-k-mooney ya so its not that you are using a listOpt that has a choice filed, you are instead create a list of sting enums which have the chioce element
11:24:14 sean-k-mooney but it works
11:24:55 kashyap Exactly :P It's still using the 'String' type
11:26:32 openstackgerrit Elod Illes proposed openstack/nova stable/ocata: WIP: Functional test for regression bug #1713783 https://review.openstack.org/505160
11:26:33 openstack bug 1713783 in OpenStack Compute (nova) ocata "After failed evacuation the recovered source compute tries to delete the instance" [High,In progress] https://launchpad.net/bugs/1713783 - Assigned to Balazs Gibizer (balazs-gibizer)
11:32:14 kashyap sean-k-mooney: Thanks for the review. Much appreciated

Earlier   Later