<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 20, 2018 at 1:09 PM Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I wanted to float something that we talked about in the public cloud SIG <br>
meeting today [1] which is the concept of making the lock API more <br>
granular to lock on a list of actions rather than globally locking all <br>
actions that can be performed on a server.<br>
<br>
The primary use case we discussed was around a pre-paid pricing model <br>
for servers. A user can pre-pay resources at a discount if let's say <br>
they are going to use them for a month at a fixed rate. However, once <br>
they do, they can't resize those servers without going through some kind <br>
of approval (billing) process to resize up. With this, the provider <br>
could lock the user from performing the resize action on the server but <br>
the user could do other things like stop/start/reboot/snapshot/etc.<br>
<br>
The pricing model sounds similar to pre-emptible instances for getting a <br>
discount but the scenario is different in that these servers couldn't be <br>
pre-empted (they are definitely more non-cloudy pets than cattle).<br>
<br>
An alternative solution for that locked resize issue is using granular <br>
policy rules such that pre-paid servers have some other kind of role <br>
attached to them so by policy you could restrict users from performing <br>
actions on those servers (but the admin could override). In reality I'm <br>
not sure how feasible that is in a public cloud with several thousand <br>
projects. The issue I see with policy controlling this is the role is <br>
attached to the project, not the resource (the server), so if you did <br>
this would users have to have separate projects for on-demand vs <br>
pre-paid resources? I believe that's what CERN and StackHPC are doing <br>
with pre-emptible instances (you have different projects with different <br>
quota models for pre-emptible resources).<br></blockquote><div><br></div><div>One way you might be able to do this is by shoveling off the policy check using oslo.policy's http_check functionality [0]. But, it still doesn't fix the problem that users have roles on projects, and that's the standard for relaying information from keystone to services today.</div><div><br></div><div>Hypothetically, the external policy system *could* be an API that allows operators to associate users to different policies that are more granular than what OpenStack offers today (I could POST to this policy system that a specific user can do everything but resize up this *specific* instance). When nova parses a policy check, it hands control to oslo.policy, which shuffles it off to this external system for enforcement. This external policy system evaluates the policies based on what information nova passes it, which would require the policy check string, context of the request like the user, and the resource they are trying operate on (the instance in this case). The external policy system could query it's own policy database for any policies matching that data, run the decisions, and return the enforcement decision per the oslo.limit API.</div><div><br></div><div>Conversely, you'll have a performance hit since the policy decision and policy enforcement points are no longer oslo.policy *within* nova, but some external system being called by oslo.policy...</div><div><br></div><div>Might not be the best idea, but food for thought based on the architecture we have today.</div><div><br></div><div>[0] <a href="https://docs.openstack.org/oslo.policy/latest/user/plugins.html">https://docs.openstack.org/oslo.policy/latest/user/plugins.html</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I believe there are probably other use cases for granular locks on <br>
servers for things like service VMs (trove creates some service VMs to <br>
run a database cluster and puts locks on those servers). Again, <br>
definitely a pet scenario but it's one I've heard before.<br>
<br>
Would people be generally in favor of this or opposed, or just meh?<br>
<br>
[1] <a href="https://etherpad.openstack.org/p/publiccloud-wg" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/publiccloud-wg</a><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
<br>
</blockquote></div></div></div>