Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-09
17:43:28 jmlowe cdent: Got a quick question about placement and vgpus
17:43:34 efried cdent: also on a) and b), I am likely to hold off on any further responses until tomorrow. Trying to focus solely on nova spec reviews today (though the gods are conspiring to make that challenging).
17:44:13 cdent a) I clicked on every link on the spec etherpad this morning and left reviews where I felt comfortable. sometimes I did not because my reaction was "oh look, yet more complexity for the five people who care" and didn't think that was too helpful, so moved on to something else, b) cool, c) I'm trying to make sure the etherpad exposes what has thread
17:44:20 cdent jmlowe: hola
17:45:05 cdent jmlowe: I can try to help, but the specifics of how the vgpus are being managed is not much in my wheelhouse
17:47:12 mriedem tssurya: so maybe a question that you don't want to hear right now, but do we really need to expose that locked_by field? it seems to be causing a lot more unnecessary churn on this spec than is needed
17:47:27 mriedem if the point of the spec is just expose a reason field, can we just....do that?
17:48:29 jmlowe cdent: So we got 6 nodes with 4 nvidia v100's each for a total of 24, the thing that's confusing me is that in the docs the example is "openstack flavor set vgpu_1 --property "resources:VGPU=1"", I can slice these 8 ways, how do I manipulate the resources in placement so that I have 4*8 vgpus? Or do I have a GCE when it comes to resources, filter scheduler, and placement?
17:50:56 jmlowe seems like a major omission, how do I tell placement how many of some arbitrary thing I have?
17:51:15 openstackgerrit Surya Seetharaman proposed openstack/nova-specs master: Support adding the reason behind a server lock https://review.openstack.org/638629
17:51:53 cdent jmlowe: what release are you on these days?
17:52:01 jmlowe Rocky
17:52:04 sean-k-mooney jmlowe: bauzas will be able to answer but you should not need too
17:52:22 tssurya mriedem: just saw your comment here :/
17:52:36 mriedem i left them on the spec as well, you can answer whenever
17:52:55 tssurya hmm, ok if we are going to expose "locked" after all then locked_by is not needed
17:53:14 sean-k-mooney jmlowe: there are some limitation in what we currently supprot but as of stien we shoudl now have a nested resoucp provider per phyical gpu
17:53:35 sean-k-mooney each phyical gpu will have an inventory of 8 vGPU reources
17:53:50 jmlowe any chance this is explained in the Stein admin guide?
17:54:15 cdent jmlowe: the issue you've got is that what's possible in Stein is a lot different from what's possible in Rocky
17:54:21 sean-k-mooney jmlowe: in rocky i know we did not support multiple vgpus type on the same host but we might have supported multipel pysical gpus
17:54:45 jmlowe *looking ahead to stein admin guide
17:55:16 sean-k-mooney jmlowe: i think bauzas wrote something up yes but not sure if its in the admin guide
17:55:45 mriedem tssurya: we already expose locked :)
17:56:38 jmlowe ok, this is starting to make more sense now that I understand the limitations of <= Rocky
17:56:46 mriedem https://docs.openstack.org/nova/rocky/admin/virtual-gpu.html
17:56:50 mriedem that's the vgpu admin guide for rocky
17:57:11 mriedem https://docs.openstack.org/nova/stein/admin/virtual-gpu.html#checking-allocations-and-inventories-for-virtual-gpus is new content for stein
17:57:33 mriedem the placement CLI examples in there may or may not be useful to you in rocky
17:57:40 sean-k-mooney ya so in rocky we supporte 1 gpu type per node but i belive we had supported muplip phyical gpus that were reported in 1 inventory on the compute node RP
17:57:46 mriedem the main difference is in stein there are nested providers for VGPU inventory and allocations
17:58:00 sean-k-mooney and in stien we reshap them into child resouce providers
17:58:09 cdent jmlowe: this may be informative: https://docs.openstack.org/nova/latest/admin/virtual-gpu.html#checking-allocations-and-inventories-for-virtual-gpus
17:58:32 cdent oh, sorry, mriedem just did that
17:58:54 cdent was off looking.
18:00:11 cdent Is dinner time
18:02:32 tssurya efried: wait wait I am updating that spec to remove that part which you just commented
18:02:47 efried tssurya: Okay. Don't worry, I wasn't merging it :)
18:02:57 efried you're going to just not display locked_by at all?
18:03:06 efried Sigh, I guess that's one way to skin this cat.
18:03:44 efried And you would know better than I whether a user would want to report on "locked by me" and/or "locked by not-me".
18:03:58 tssurya efried: yea
18:04:06 tssurya I am going to kick locked_by
18:04:13 tssurya that's causing all the confusion
18:04:26 efried And I guess that could be added later, though it would seem like a lot of work to spin a whole new blueprint/spec/microversion just for that.
18:04:43 tssurya efried: yea that's why I had intially added it here
18:04:52 tssurya but I hope nobody would want locked_by ?
18:05:01 efried that's the thing
18:05:38 tssurya when the user tries to unlock they would know if it was "locked by me" or not
18:05:43 efried like I'm doing maintenance, so I lock a bunch of things, and then my maint is done, so I want to unlock the things. But I forgot to keep track of the ones I locked. So I want a report that says "hey, what did I lock?"
18:06:00 dansmith I was told that the way to tell if it's locked by me is to unlock it :P
18:06:15 efried yeah. I could script to unlock "everything" and tolerate the failures ^
18:06:17 dansmith which seems silly to me
18:06:19 efried that's pretty ugly
18:06:41 dansmith because checking policy of an unlock operation during get is not okay for some reason
18:07:13 efried becuase the policy is conditional on the owner of the lock?
18:07:23 efried a thing that can't be determined at policy enforcement time?
18:07:23 dansmith I dunno
18:07:35 dansmith what I want is a boolean that tells me "can I unlock this thing?"
18:07:49 efried locked_by == 'owner'
18:08:06 efried tssurya: Okay, so I'm with dansmith on this. Who's the dissenter? mriedem?
18:08:06 dansmith but if I'm an admin, I can unlock it too
18:08:12 dansmith or if the policy is such that I can unlock..
18:08:34 dansmith efried: just to be clear, I'm fine with not exposing locked_by
18:08:45 mriedem efried: locked_by won't tell you "hey, what did I lock?" anyway
18:08:51 efried Okay,
18:08:51 efried can_I_unlock = am_I_admin or locked_by == 'owner'
18:09:14 mriedem and owner = the instance is in a project that i'm in
18:09:18 dansmith not sure that's enough
18:09:19 mriedem i think...
18:09:40 dansmith can't I write complex policy to allow a role that can unlock things for other projects?
18:10:08 dansmith regardless, I'd really suggest we not get back into this, remove locked_by and let tssurya proceed
18:10:24 tssurya dansmith: thanks :)
18:10:29 tssurya efried you okay with that ?
18:10:51 efried sure
18:11:06 mriedem i also really don't want to think about locked_by anymore, so if the goal is add a reason field, let's do that - making locked_by not suck is a whole other can of worms
18:11:09 mriedem and likely a separate spec
18:11:20 efried I can get on board with that ^
18:11:32 efried I had actually drafted a comment that read a lot like that
18:11:45 tssurya ok thanks everyone I am deleting locked_by from my memory
18:11:55 efried tssurya: you can't delete it from memory.
18:12:09 efried you should put something in Alternatives so we remember we had this conversation.
18:12:11 mriedem not persistent memory anyway https://review.openstack.org/#/c/601596/
18:12:13 mriedem hi-o!!!!
18:12:59 efried tssurya: ...even if it's just a link to the eavesdrop of this conversation
18:13:12 openstackgerrit Surya Seetharaman proposed openstack/nova-specs master: Support adding the reason behind a server lock https://review.openstack.org/638629
18:14:33 mriedem i feel like at this point in my day my time would be better served raking up dead grass outside since it's supposed to dump a foot a snow on us tomorrow
18:14:41 mriedem *of snow
18:24:44 gmann tssurya: mriedem efried dansmith can we remove the locked_by from valid sort/filter key also as that is not going to be exposed anyway.
18:26:17 efried gmann: If it does nothing right now? Then sure, why don't we do that in a totally unrelated patch?
18:27:37 gmann efried: that need microversion bump so doing in unrelated patch need another spec and version bump
18:27:57 efried gmann: So it *does* do something right now?
18:28:14 efried It actually works, you just don't see the locked_by field in your result?
18:28:22 efried or it's ignored, but removing it will cause a 400?
18:28:31 dansmith anybody want to blow their brains out when I'm done with mine?
18:30:09 gmann efried: yeah it does not show locked_by in results so user will just assume it worked well but no confirmation. in code we do consider that.
18:30:26 efried then why remove it?
18:30:52 gmann there is no way for user to know what is valid value of locked_by as nova does not expose that at all
18:30:53 efried rather than put it off until later and fix it properly
18:31:05 ganso Hi efried. Sorry to interrupt. When you have some time, could you please review https://review.openstack.org/#/c/650437/ and https://review.openstack.org/#/c/649421/ ? Thanks in advance

Earlier   Later