Posted	Nick	Remark
#openstack-nova - 2017-10-24
15:47:50	mriedem	so how do people find it?
15:48:03	edleafe	efried: no, that's what nested RPs should be doing
15:48:05	mriedem	or is that wip?
15:48:07	efried	bauzas And then [something TBD] tells virt which types you want to create.
15:48:21	dansmith	efried: well, you can't do that if it has a limited number of each type it can provide
15:48:25	efried	edleafe Nested only applies if you want to pre-create the vGPUs of a specific type.
15:48:29	stephenfin	mriedem: That's WIP. sdague, asettle and I have been working through some ideas on how to structure that
15:48:32	dansmith	efried: in that case you'd need to expose two sets of inventory (i.e. be two providers)
15:48:41	bauzas	yeah, that's my point
15:48:41	stephenfin	I do think I have a patch up to resolve just that though
15:48:42	efried	edleafe or if you want to limit the number of each type you can create on the fly.
15:48:48	bauzas	it's not an easy answer to me
15:49:05	bauzas	we should only have nested RPs if we need more than one inventory for a single resource provider
15:49:05	mriedem	stephenfin: ok i'm moving some missing stuff from the old user guide, and was wondering if i should put it in the user index or in the main index - guessing the user index since the main index will point htere
15:49:20	efried	dansmith bauzas I'm thinking of the case where the vGPUs are created on the fly, and they can be of any type, and that type gets determined at boot.
15:49:25	bauzas	that's a tautology, I assume, but that would mean we would need to track consumption of those resources separately
15:49:27	edleafe	efried: bauzas asked: 10:45 < bauzas>| then, I guess I'd use the nested RP model, and have a RP per type?
15:49:43	dansmith	efried: yeah, if it's just a configuration thing, then that's fine
15:50:06	stephenfin	mriedem: That would be my thinking yes pages in '/X' belong in '/X/index'
15:50:09	edleafe	efried: if there is only one type, then nested isn't needed, of course
15:50:15	stephenfin	*yes. Pages
15:50:37	mriedem	sure, as long as someone can eventually find /X/index :)
15:51:03	efried	edleafe Even if there's multiple possible types - if you determine which type at boot time, and one type is as good as another, then you still don't need nested to represent this.
15:51:07	stephenfin	mriedem: One request: if you do pull brand new pages in, can you rename anything with underscore to use hyphens? It's one of my OCD things ;)
15:51:17	efried	dansmith And at some point we'll have to talk about the mechanism by which you "configure" the thing you requested.
15:51:23	mriedem	stephenfin: you mean the actual rst filename?
15:51:27	stephenfin	mriedem: Yup, we've got work to do there. Try to find the SR-IOV docs at the moment
15:51:32	dansmith	efried: that'd be virt specific
15:51:34	stephenfin	Yup - that filename is reflected in the URL
15:51:37	bauzas	yup
15:51:38	mriedem	stephenfin: those are in the networking guide aren't they?
15:51:44	dansmith	efried: unless you're talking about things like ironic raid layouts
15:51:58	stephenfin	oops
15:52:11	efried	dansmith Well, my understanding is that ironic is going to do such things via templates, and they'll represent a single template as a custom trait.
15:52:13	dansmith	efried: what I meant was some quirk of the vgpu that allowed you to configure it one way or the other that didn't affect its resource usage
15:52:40	dansmith	efried: right
15:52:49	edleafe	efried: are you saying that a pGPU that is capable of multiple types, it cannot be configured to provide some of one, and some of another? IOW, does it always have to be all one type at boot?
15:52:53	efried	dansmith ++. I don't really know how VGPUs are "deployed" so I'm kinda thinking of it like VFs.
15:53:17	efried	edleafe That's what I don't know, specifically about VGPUs.
15:53:20	dansmith	efried: there are some things you can do when you carve off a vgpu on some of the devices, like decide whether it gets a framebuffer or is just for compute, etc
15:53:45	bauzas	edleafe: that's what we agreed in the spec
15:54:08	edleafe	bauzas: just one type at boot?
15:54:32	bauzas	I'm just having a testbox now that shows me for a single pGPU that I can have 11 different types
15:54:42	bauzas	multiple that by 4 pGPUs
15:54:50	bauzas	fortunately, all of them share the same types
15:54:53	efried	bauzas edleafe Are you saying the pGPU sits there capable of whatever, but the first time you carve off a vGPU of a specific type, you lock the pGPU into only being able to supply that one type?
15:55:12	bauzas	efried: again, that's what we agreed in the spec, no new news
15:55:16	dansmith	yep
15:55:22	efried	that's... interesting.
15:55:25	openstackgerrit	Matt Riedemann proposed openstack/nova master: Import the config drive docs from openstack-manuals https://review.openstack.org/514723
15:55:26	mriedem	stephenfin: ok here it is ^ - note i plan on backporting that to pike; when i do i'll have to remove the user/index part since that didn't exist in pike
15:55:33	bauzas	anyway, you'll see my proposal
15:55:36	efried	If that's the case, you better remove the other types' traits during that first boot.
15:55:45	bauzas	definitely rushing for uploading the first try
15:55:52	dansmith	efried: no, I think what we should do is require them to be configured once at boot,
15:56:01	dansmith	efried: so we expose traits on how it is configured and don't change
15:56:13	efried	dansmith "boot" meaning compute startup, not "boot" meaning instance spawn
15:56:19	dansmith	efried: otherwise we have to embed that logic into the scheduler, and we can't since it's virt specific
15:56:20	stephenfin	mriedem: I wonder if the patch that landed user/index should be backported instead?
15:56:21	dansmith	efried: right
15:56:21	edleafe	efried: I was thinking more of the case where it could be configure to run half type A, and half type B
15:56:24	efried	got it.
15:56:24	bauzas	efried: here is a single pGPU http://paste.openstack.org/show/624497/
15:56:31	mriedem	stephenfin: it's not used, so i don't see the point
15:56:34	mriedem	to backport that is
15:56:55	stephenfin	It's not? I thought the index pages were linked to from docs.o.o?
15:57:03	stephenfin	But I could be wrong. idk for sure
15:57:20	mriedem	https://docs.openstack.org/pike/user/ ?
15:57:22	mriedem	don't see compute in there
15:57:31	openstackgerrit	Ed Leafe proposed openstack/nova master: Only filter/weigh hosts once if scheduling a single instance https://review.openstack.org/513931
15:57:32	openstackgerrit	Ed Leafe proposed openstack/nova master: Add Selection objects https://review.openstack.org/499239
15:57:33	openstackgerrit	Ed Leafe proposed openstack/nova master: Return Selection objects from the scheduler driver https://review.openstack.org/495854
15:57:33	openstackgerrit	Ed Leafe proposed openstack/nova master: Change RPC for select_destinations() https://review.openstack.org/510159
15:57:33	openstackgerrit	Ed Leafe proposed openstack/nova master: Move the claim_resources method to scheduler utils https://review.openstack.org/511357
15:57:34	openstackgerrit	Ed Leafe proposed openstack/nova master: Make conductor pass and use host_lists https://review.openstack.org/511358
15:58:07	efried	bauzas So there's your answer. The pGPU is your RP, and by the time you set it up as an RP with inventory & traits in placement, you've locked it into providing a single type of vGPU.
15:58:16	stephenfin	mriedem: dhellmann isn't about to confirm, but I think that's automatically generated based on whether the index pages exist or not
15:58:20	stephenfin	We add the page, it appears there
15:58:23	efried	bauzas And if you want two different types, you'd better have two different pGPUs that provide those types.
15:58:32	bauzas	efried: no, because we agreed on supporting multiple types
15:58:37	bauzas	anyway
15:58:38	efried	bauzas And you'll have to use numbered syntax to specify them.
15:58:44	stephenfin	But I should run that by AJaeger or dhellmann first
15:58:46	mriedem	stephenfin: ah you're right https://docs.openstack.org/queens/user/
15:58:46	efried	s/specify/request/
15:59:16	mriedem	stephenfin: yeah ok so i'll backport the user/index in-tree page before https://review.openstack.org/514723 when i do the backports
15:59:22	stephenfin	(y)
16:00:02	stephenfin	mriedem: I do realize I said I'd do that doc and the other ones too. I'll get them done soon as the summit is behind us
16:01:53	efried	bauzas e.g. ?resources1=VGPU:1&required1=VGPU_TYPE_GRID_M10_0B&resources2=VGPU_1&required2=VGPU_TYPE_GRID_M10_8Q
16:05:51	edleafe	I will take that ^^ as an opportunity to reiterate my request for multiple 'request=' qs params
16:07:02	mriedem	stephenfin: why doesn't user/index include the links to the API stuff we have in the main index?
16:07:09	mriedem	shouldn't a user guide care about end users of the API?
16:07:22	efried	edleafe We still need the so-called "unnumbered" group.
16:07:31	mriedem	stephenfin: looks like user/index is more for operators
16:08:20	jmccarthy	Hmm are permissions like this ok for the console.log ? root qemu 0 Oct 24 15:46 console.log (nothing logged)
16:08:35	stephenfin	mriedem: To be honest, I'm still confused by the divide between 'user' and 'admin'. The lines are blurred
16:08:54	stephenfin	I think the API is documented in the developer section, whatever that's called
16:09:02	sdague	stephenfin: user == "only have access to the API, not the physical machines"
16:09:13	sdague	admin == "people with access to the machines"
16:09:20	efried	edleafe Hm, I guess you could get away with not doing that if we changed the semantic for resources= to always be "same RP"; then you would have to split up all of your resource requests that you didn't need to be in the same RP.

Earlier   Later