| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-09 | |||
| 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 | dansmith | I dunno | |
| 18:07:23 | efried | a thing that can't be determined at policy enforcement time? | |
| 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 | dansmith | but if I'm an admin, I can unlock it too | |
| 18:08:06 | efried | tssurya: Okay, so I'm with dansmith on this. Who's the dissenter? mriedem? | |
| 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 | can_I_unlock = am_I_admin or locked_by == 'owner' | |
| 18:08:51 | efried | Okay, | |
| 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 | |
| 18:31:53 | efried | ganso: Is tomorrow soon enough? I'd like to focus on specs as much as possible today. | |
| 18:32:03 | ganso | efried: sure, thank you! | |
| 18:32:17 | gmann | ok, if we do something with locked_by later then only fix sort/filter too / that is ok for me. | |
| 18:32:18 | efried | ganso: Oh, those are stein. I'm not stable, so I can't really help you :) | |
| 18:32:35 | efried | gmann: Okay, I think that's the plan. | |
| 18:32:46 | ganso | efried: oh, sorry... I'll look for the stable maintainers | |
| 18:32:48 | gmann | +1 | |
| 18:33:01 | efried | gmann: Current bp is going to add sorting/filtering by the locked bool. | |
| 18:33:05 | efried | iiuc | |
| 18:33:16 | efried | but ignore locked_by entirely - not fix it or remove it. | |
| 18:34:29 | mriedem | ganso: https://review.openstack.org/#/admin/groups/540,members | |
| 18:34:38 | mriedem | ganso: but also, those can't merge yet anyway b/c we haven't GA'ed stien | |
| 18:34:38 | gmann | efried: you mean current spec will start ignoring 'locked_by' from sort/filter ? | |
| 18:34:40 | mriedem | *stein | |
| 18:35:04 | ganso | mriedem: oh right! release is friday, correct? | |
| 18:35:05 | gmann | i feel leave it as it is currently. | |
| 18:35:06 | mriedem | hence my -W on the bottom patch | |
| 18:35:11 | mriedem | ganso: tomorrow i think | |
| 18:35:17 | efried | gmann: No, sorry, I mean the current spec will do nothing to change locked_by in any way. | |
| 18:35:29 | mriedem | dansmith: grab a rake | |
| 18:35:41 | gmann | efried: +1 | |