Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-08-31
19:42:17 efried edleafe I thought I could create a separate resource class?
19:42:51 artom It's a purely arbitrary construct though - the spoons can be inventory of RPs with different traits, or there can be one RP with two inventories, one for each kind of spoon
19:43:05 bauzas mriedem: yeah, because we still need to support microversion < 2.29 :)
19:43:06 artom (Right?)
19:43:21 bauzas mriedem: so, like you said, Force=None if so
19:43:25 edleafe efried: sure, but then you wouldn't have "spoons", you'd have dessert_spoon and soup_spoon
19:43:35 efried Right, okay.
19:44:14 efried If we don't have nested resource providers yet
19:44:45 mriedem bauzas: right, it's just confusing
19:44:54 edleafe efried: we still have some work to do with traits and nested providers before any of this will actually work
19:45:19 mriedem looks like our api ref docs also say a host is required in the request when live migrating, which is wrong
19:45:37 dansmith mriedem: so would you kill me if I wasn't around for the nova meeting today?
19:45:48 mriedem i'd like to not be around for the nova meeting today
19:46:28 dansmith is that a joke or are you hoping someone else would run it?
19:46:32 mriedem in 15 minutes i'm going to be knee deep in in-laws
19:46:36 mriedem i'll run it
19:46:39 dansmith okay
19:46:39 mriedem i'm just not happy about it
19:46:58 dansmith having to run a meeting is like the best possible in-law scenario I can think of personally
19:47:49 mriedem holy crap we actually do require that you specify the 'host' parameter in the os-migrateLive action
19:47:55 mriedem but you can pass 'host': None
19:47:56 mriedem dumb
19:50:44 efried dansmith edleafe artom Thanks a bunch for the talk, guys. I have a much better understanding now.
19:52:02 openstackgerrit Matt Riedemann proposed openstack/nova master: api-ref: add warnings about forcing the host for live migrate/evacuate https://review.openstack.org/499769
19:52:03 mriedem bauzas: dansmith: cfriesen_: ^
19:54:10 bauzas mriedem: I'm not sure the comment is really understanding
19:54:33 bauzas mriedem: why did you commented about the over-subscription ?
19:55:34 bauzas mriedem: anyway, commenting the change
19:59:25 mriedem well i was thinking more about failing a resource claim, but that could be removed
19:59:27 mriedem and just generalized
20:02:54 bauzas anyway, I'm bad at wording, so your call
20:03:30 bauzas just providing my thoughts that we should just be commenting at the top-level
20:07:37 openstackgerrit Matt Riedemann proposed openstack/nova master: api-ref: add warnings about forcing the host for live migrate/evacuate https://review.openstack.org/499769
20:10:54 cfriesen_ taking a look
20:12:12 openstackgerrit Ildiko Vancsa proposed openstack/nova-specs master: Add multiattach support to Nova https://review.openstack.org/499777
20:21:19 cfriesen_ mriedem: v2 looks reasonable to me.
20:34:26 efried dansmith edleafe artom Okay, here's a much better example. I can create SR-IOV VFs on the fly. On a given PF (which is a (nested) RP) I can create a maximum of 48 VFs. But each can be assigned a minimum egress bandwidth, let's say as a percentage of the PF's total bandwidth.
20:35:26 efried 1) It would suck for my PF to have to say traits=egress-pct-capable-1,egress-pct-capable-2,...,egress-pct-capable-100
20:36:59 efried 2) Assuming I did the above, I ask for e.g. egress-pct-capable-75, you peel off one of the 48... but I can no longer create 47 more VFs. At a maximum, I can now create 25, assuming they each get 1% of the egress bandwidth.
20:37:03 dansmith efried: that's the same as your gpu >= 10GHz example
20:37:28 efried Yeah. It's just a more convincing case because I've got 100 values instead of like three or four.
20:37:35 efried and it's also a real thing
20:37:47 dansmith efried: you could model bandwidth as a resource amount though
20:38:07 efried Now, I can probably do #2 just by, next time you ask me for get_inventory, I bust my number down to 25 (or blow up my reserved number)
20:38:08 cfriesen_ this is for kind of a weird use-case...is it possible to set up a nova-api with a configuration read from nova.conf such that only a specific user (presumably with admin privileges) can issue requests, and no other users can (even if they're in keystone)?
20:38:16 dansmith efried: no you can't
20:38:29 dansmith efried: inventory doesn't change due to allocation, otherwise you're breaking the other parts of the model
20:38:45 edleafe efried: when you add the inventory, you can set a minimum for a request
20:38:47 efried dansmith Then why is get_inventory called more than once?
20:38:49 artom dansmith, actually your last sentence is problematic for vGPUs
20:39:12 dansmith efried: because you could get more inventory periodically
20:39:18 edleafe artom: why?
20:39:20 efried what, hot-plugging stuff?
20:39:37 dansmith efried: sure
20:40:10 artom edleafe, there's this thing where a GPU can give you different numbers of vGPUs based on how many, err, I think shaders, or cores, each gets
20:40:11 dansmith efried: can we continue this conversation in denver? I think it'll be more productive
20:40:39 dansmith artom: right, but a lot of the existing models for this end up with you carving those resources out into multiple virtual devices,
20:40:41 artom So a GPU with, for example, 12 shaders/cores, can give you 2 vGPUS with 6 each, or 4 with 3 each
20:40:47 dansmith and then those devices can be assigned and de-assigned
20:40:58 dansmith you _could_ do the assignment of shaders completely dynamically,
20:41:00 efried dansmith Well, yeah, what I'm trying to do is compose notes in enough detail - and with enough of the "easy" questions answered - that we can have a productive conversation in Denver (and not devolve into spoon metaphors).
20:41:09 edleafe artom: one of the things that came up in discussions in Austin about CAPI and such was that management of dynamic resources would never be handled by nova
20:41:15 dansmith but in reality, I think most cases will be satisfied by carving up your GPUs into chunks
20:41:34 edleafe so if your resources change, the virt driver has to report that change
20:41:49 artom edleafe, they would, I'm pretty sure
20:41:51 dansmith efried: sure, I know, but it'll go a lot quicker in person I think
20:42:06 artom edleafe, nova would still have to update its inventories though
20:42:37 edleafe artom: it does that periodically, based on what the virt driver tells it
20:42:40 efried Yeah, I'd like to understand more about how it breaks the model for me to change the inventory of something - for whatever reason I see fit.
20:42:45 artom edleafe, ah, we're fine then
20:42:51 efried ^ me == virt driver in this case
20:43:12 cristicalin hy, anyone have an idea why instances libvirt.xml may be missing metadata for user_id / project_id ?
20:43:13 dansmith efried: I said in response to allocation
20:43:14 edleafe efried: I always thought you looked like a virt driver
20:43:33 efried dansmith Well, yeah, it's sort of in response to allocation.
20:43:49 efried I guess I would call it in response to actually doing the virt driver work of satisfying the allocation.
20:43:51 dansmith efried: you should be exposing how much of a thing you have and the allocations come out of that
20:43:57 dansmith efried: you don't expose "available" you expose "total"
20:44:56 efried Hm, so I guess in this scenario I don't expose SRIOV_VF=48; instead I expose SRIOV_VF_EGRESS_PERCENTAGE_POINT=100
20:45:44 efried but that doesn't allow me to model the max #VFs as 48 at the same time. Or two separate VFs in the same claim.
20:46:13 efried ick
20:47:23 dansmith efried: regardless,
20:47:39 dansmith if your NIC has 10G of bandwidth, you can have your provider expose CUSTOM_GIGS=10,
20:47:55 dansmith and have your flavor consume some number of those to avoid over-subscribing
20:50:35 cfriesen_ efried: wouldn't you still say that you have 48 VFs total, and allocate from that?
20:50:56 openstackgerrit Matt Riedemann proposed openstack/nova master: Modernize set_vm_state_and_notify https://review.openstack.org/499799
20:51:07 dansmith presumably if you have 3 VFs left, but no GIGs left, you don't want to allocate any more
20:51:11 cfriesen_ efried: presumably you could also model total bandwidth, and divide it up nonuniformly between the VFs
20:52:16 efried dansmith So the VFs and the GIGs would be separate resource classes sitting next to each other, and you have to claim VF=1,GIG=2 or whatever in your request
20:52:28 efried cfriesen_ Could, but that kills the flexibility
20:52:45 efried cfriesen_ No idea at the outset how the end user is gonna want to split 'em up.
20:52:50 dansmith efried: yeah, so you end up with either one capping the things that can be there
20:53:13 dansmith either you run out of tiny VFs or GIGs from requests with large bandwidth requirements
20:53:19 tonygunk Just upgraded from Ocata to Pike and trying to upgrade nova DB - getting error: "AttributeError: 'module' object has no attribute 'get_rpc_transport'"
20:53:27 tonygunk http://paste.openstack.org/raw/620137/
20:53:28 efried dansmith So in that scenario a claim that specifies VF=1 but doesn't specify GIG would have to fail.
20:53:44 efried I can't default GIG because placement wouldn't know about it.
20:53:48 efried But
20:53:54 efried I would have to fail at compute
20:53:54 dansmith efried: that'd be up to the guy making out the flavors yeah

Earlier   Later