Earlier  
Posted Nick Remark
#openstack-nova - 2017-08-31
19:34:54 edleafe artom: no, but I have an inventory with resource_class == "spoon"
19:34:57 efried (Could it have been Ghostbusters, not Matrix, dansmith?)
19:35:21 dansmith I think I was thinking "there is no try, only do" or whatever
19:35:33 artom That's Star Wars
19:35:43 dansmith yeah, I dunno, I'm not a big enough nerd
19:35:46 efried Yup, and we've reached our limit of three nerd movie franchises.
19:36:02 dansmith yeah,
19:36:17 efried resource_class=SPOON would have a quantity of 8 or whatever
19:36:17 dansmith and eff jay for being on a plane and leaving me with you wolves
19:36:39 efried placement doesn't know about individual spoons
19:36:43 dansmith efried: well, SPOON=8 for consistency but yeah
19:36:45 artom There must always be a core in #openstack-nova
19:36:54 artom (Speaking of wolves)
19:37:36 edleafe er, CUSTOM_SPOON, but whatever
19:37:49 dansmith edleafe: if it's a custom resource yeah
19:38:22 dansmith edleafe: you understand all this, why are you making me squirm alone? :D
19:38:23 efried But if we had soup spoons and dessert spoons, we would either have to make two separate resource classes (SPOON_SOUP, SPOON_DESSERT), or two separate resource providers with traits (CUSTOM_SPOON_SOUP, CUSTOM_SPOON_DESSERT)
19:38:54 edleafe efried: pretty much, yeah
19:38:56 mriedem it'd be a spoon with different traits
19:39:11 efried mriedem The spoon doesn't have traits.
19:39:12 dansmith yeah
19:39:14 edleafe only spoon providers can have traits
19:39:14 efried The resource provider has traits
19:39:18 efried yeah
19:39:19 tbachman there is no spon
19:39:21 tbachman spoon
19:39:22 artom And anyways, there is no
19:39:23 mriedem so the spoon drawer is the provider
19:39:24 artom Dammit!
19:39:28 mriedem that provides spoons
19:39:39 tbachman lol
19:39:40 efried mriedem Right, but you can't have soup spoons and dessert spoons in the same drawer.
19:39:45 dansmith okay so this conversation is over right/
19:39:45 mriedem i do
19:39:54 mriedem i have all sorts of spoons in the same drawer
19:40:05 efried Dude, okay, we're getting meta here, but I'm actually still trying to understand this seriously.
19:40:05 mriedem what psycho separates them
19:40:23 edleafe efried: ok, let me try, using the spoons
19:40:34 mriedem did someone make a soundgarden joke yet?
19:41:01 artom We've only covered Ghostbusters, the Matrix, Star Wars, and GoT
19:41:01 bauzas mriedem: that's correct, before 2.29, when providing a target, we were directly calling the compute service without asking the scheduler to verify it
19:41:11 edleafe if you have a drawer with 2 types of spoons, you have to created nested resource providers with the different traits, and assign the spoons as inventory to each
19:41:31 efried edleafe Okay, so that's yet a third way of doing it.
19:41:38 edleafe the drawer would be the root provider
19:41:54 edleafe efried: that's the only way with just one drawer
19:41:54 efried and the slots in the silverware holder thingy would be the child providers
19:42:04 edleafe efried: yup
19:42:10 mriedem bauzas: yes this always trips me up https://github.com/openstack/nova/blob/2a4ca8bd6aa40ccd26300feaef4267aa71f69abf/nova/compute/api.py#L4017
19:42:16 mriedem because force is None if microversion < 2.29
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

Earlier   Later