Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-24
14:44:40 mdbooth https://review.openstack.org/#/c/462521/
14:45:20 cdent mdbooth: thank you!
14:45:44 mdbooth cdent: The 'fix' is really a workaround
14:45:54 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Accept InternalError through the API https://review.openstack.org/514702
14:46:25 mdbooth Because it turns out our datamodel doesn't currently allow us to easily identify when an image in the local image cache is still in use by the destination host of a migration
14:46:25 cdent mdbooth: as is so often the case
14:46:48 mdbooth Fixing the datamodel would be better, but this is also good on its own merits, I think
15:15:47 openstackgerrit sean mooney proposed openstack/os-traits master: add plathform security namespaces https://review.openstack.org/514712
15:15:48 openstackgerrit sean mooney proposed openstack/os-traits master: add firmware (fw) traits namespace https://review.openstack.org/514713
15:28:53 openstackgerrit Elod Illes proposed openstack/nova master: WIP: Transform scheduler.select_destinations notification https://review.openstack.org/508506
15:31:24 openstackgerrit Merged openstack/nova stable/pike: fix nova accepting invalid availability zone name with ':' https://review.openstack.org/509656
15:31:29 openstackgerrit Merged openstack/nova master: Move the idmapshift binary into privsep. https://review.openstack.org/495541
15:41:30 bauzas dansmith: mriedem: do you know if jay is around by those days or just off ?
15:41:44 bauzas I'm just implementing the VGPU series and I'd like to hear some voice
15:41:46 efried bauzas He's doing all his new-hire stuff at his new job.
15:41:50 bauzas ah ok
15:41:58 efried Said he would probably be back tomorrow or the next day.
15:42:22 bauzas so I'll speak out loud, if anyone cares
15:42:36 openstackgerrit Merged openstack/nova master: Move loopback setup and removal to privsep. https://review.openstack.org/495664
15:42:38 efried I'll listen. And maybe even care :)
15:42:53 dansmith I'll care. And maybe even listen.
15:43:08 bauzas given a pGPU can support different types for the same device, we supposingly said in the spec we'll use a whitelist for telling which type to use
15:43:57 bauzas now for Queens it's easy as we said we would only support a single type
15:44:14 bauzas so I'm basically accumulating all the available vGPUs for the same type
15:44:46 bauzas now, my question is more Rocky (but since I'm designing the internal interfaces now, I'd make my model resilient to the changes)
15:45:05 bauzas what if as an operator, I'm asking for 2 types?
15:45:21 bauzas then, I guess I'd use the nested RP model, and have a RP per type?
15:45:30 bauzas that's where I'm confused
15:45:49 mriedem stephenfin: please drop your +2 from this, it's wrong https://review.openstack.org/#/c/507151/
15:45:59 bauzas I mean, it would probably better for me to just upload my current patch so we could discuss
15:46:05 bauzas nevermind the above
15:46:14 bauzas I'll just push something that will create a discussion
15:46:39 efried bauzas This is a good example of where traits != settings.
15:47:21 efried bauzas You would model your pGPU as the RP. It would have inventory of VGPU. And it would have one trait for each vGPU type it supports.
15:47:43 efried bauzas Then when you ask for a vGPU, you would specify as a required trait which type you want to be created.
15:47:47 mriedem stephenfin: docs question - we now have a nova/user/index but nothing links to that from the main index right?
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 stephenfin I do think I have a patch up to resolve just that though
15:48:41 bauzas yeah, that's my point
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 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:05 bauzas we should only have nested RPs if we need more than one inventory for a single resource provider
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 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:21 dansmith efried: right
15:56:24 bauzas efried: here is a single pGPU http://paste.openstack.org/show/624497/
15:56:24 efried got it.
15:56:31 mriedem stephenfin: it's not used, so i don't see the point

Earlier   Later