Open Stack

You raise some excellent points here. I've been focused on aligning the CLI
with REST methods one-to-one and staying consistent with the other
subcommands but there's more to consider.

It would really suck to be an admin and have to guess at whether or not a
tenant already had a quota set so you can decide to use quota-create or
quota-update. I suppose quota-update could make a call to the server within
the keystone client to figure it out but that's an extra call that
shouldn't be necessary. The same holds true if an admin were scripting this
and had to script in some error handling for it, it still amounts to an
extra call that shouldn't be necessary.

I think quota-set has merit. In terms of REST methods a PUT can be used for
a create or replace [1] so the semantics are okay there. As for staying
consistent with the other subcommands, this really isn't like the other
subcommands. As you say the quotas/metadata are effectively attributes of
the tenant and are not really their own independent entity so we treat them
a bit differently.

I've updated the spec [2] and revamped the CLI. Instead of quota-create and
quota-update there is quota-set. Instead of quota-list and quota-get there
is just quota-get. I also changed the positioning of the arguments to make
it easier for scriptors to append quota arguments when generating commands.

Since this spec has been out there for a week now (thank you for the
feedback) I came to some decisions about the questions I had. I recorded
those decisions at the end of the spec.

Thanks,
Everett

[1]
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-16#section-7.6
[2] http://wiki.openstack.org/KeystoneStoreQuotaData

On Tue, May 15, 2012 at 8:05 AM, Joe Topjian <joe.topjian at cybera.ca> wrote:

> Hi Everett,
>
>
>>  Secondly, with regard to quota-create and quota-update, is there a huge
>>> difference between the two besides one would ultimately do an "insert" and
>>> one would do an "update"? If that is the only difference, could the two be
>>> combined into a single "quota-set" subcommand?
>>>
>>
>> They're two distinct actions and having both is consistent with the rest
>> of the keystone CLI.
>>
>
> I spent some time thinking about this over the weekend and realized why
> quota-create and quota-update seem like weird actions to me. I apologize
> for the lengthy response.
>
> Let's define a "quota resource" as "swift.total" or "nova.ram".
>
>
> In the design specs, the examples are showing create and update commands
> for the same quota resource:
>
>
> keystone quota-create --quota swift.total=1073741824 <tenant-id>
>
> keystone quota-update --quota swift.total=2147483648 <tenant-id>
>
>
> The specs do not explicitly say if this is allowed or not:
>
>
> keystone quota-create --quota nova.ram=10240 $joe_tenant_id
>
> keystone quota-update --quota nova.instances=20 $joe_tenant_id
>
>
> It might be obvious to some that those two commands are in no way legal,
> but to me, they are. Here's why:
>
>
> Rule 1-1: Let's define a "quota-less tenant" as a tenant that has no quota
> data in a metadata table.
>
> Rule 1-2: Let's define a "quota'd tenant" as a tenant that has at least
> one quota resource in a metadata table.
>
>
> Once a quota-create command is issued on any tenant for any quota
> resource, that tenant is now a "quota'd tenant". Thus, any further updates
> to a "quota'd tenant", regardless of the quota resource, is legal.
>
>
> Conversely:
>
>
> Rule 2-1: Let's define a "quota-less tenant" as a tenant that has no quota
> data of a specific quota resource in a metadata table.
>
> Rule 2-2: Let's define a "quota'd tenant" as a tenant that has a quota set
> for a specific quota resource in a metadata table.
>
>
> Now:
>
>
> keystone quota-create --quota nova.ram=10240 $joe_tenant_id
>
> keystone quota-update --quota nova.instances=20 $joe_tenant_id
>
> Error: quota resource "nova.instances" does not exist for $joe_tenant_id.
> Create it first.
>
>
> quota-create only created the nova.ram quota resource and the tenant is
> only quota'd for that single quota resource. Updates can only be applied to
> resources that are quota'd on that tenant.
>
>
> If Rule 2-1 and Rule 2-2 are how you are designing the Keystone quota
> system, then this all ends here and the below is invalid. But when I first
> read the spec, I got in my head that Rule 1-1 and Rule 1-2 are how it works
> and so here is my thought-trail on why I think quota-set should just be
> used:
>
>
> Let's look at the unix "useradd" command. The only required field is the
> username:
>
>
> useradd jtopjian
>
>
> Once the user is added, "usermod" can be used to modify any user option by
> referencing the username:
>
>
> usermod --uid 1234 jtopjian
>
>
> The same is true with the keystone command. In order to work on quotas,
> the tenant_id must first be created:
>
>
> keystone tenant-create ...
>
>
> Since $joe_tenant_id is specified for each call of "keystone quota-*", it
> makes the quota-* commands more like the "usermod" command.
>
>
> In this way, quotas are just non-required, supplemental attributes to the
> tenant.
>
>
> Now, from an end-user perspective:
>
>
> keystone quota-create --quota nova.ram=10240 $joe_tenant_id
>
> keystone quota-update --quota nova.instances=20 $joe_tenant_id
>
>
> or
>
>
> keystone quota-set --quota nova.ram=10240 $joe_tenant_id
>
> keystone quota-set --quota nova.instances=20 $joe_tenant_id
>
>
> In my mind, I see an "if" statement happening for both sets of commands.
> With the first set of commands, the "if" statement is happening in the
> user's head:
>
>
> if $joe_tenant_id is already quota'd:
>
>   issue keystone quota-update
>
> else:
>
>   issue keystone quota-create
>
>
> In the second set of commands, the "if" statement is happening in the
> "quota-set" function:
>
>
> if $joe_tenant_id is in metadata table:
>
>   update metadata table
>
> else:
>
>   insert into metadata table
>
>
> I feel that the "if" statement should be placed in the quota-set function
> because of the idea that quota-* commands work on non-required attributes
> of the tenant. Why should the end-user have to figure out what non-required
> attributes have already been set?
>
>
> Does that make sense at all? I realize that this is just a ridiculous
> blather of design theory that I'm making more complicated than it should
> be.
>
>
> While writing this out, I thought of the case with the global default nova
> quota where each quota resource is properly defined. If tenants had no
> quota metadata specified, they would use the global quota. But quotas could
> be overridden on a per-resource basis, which would then make each
> overriding action, even the initial override, seem like an update and not a
> create.
>
>
> Or what about the idea that "swift" and "nova" are two distinct quota
> groups. It could then be possible that a tenant can be quota'd for one
> quota group and not another just by having one quota resource of the quota
> group specified. For example, if a tenant has nova.ram specified, the
> tenant is now quota'd for all of nova, but not swift.
>
> Thanks,
> Joe
>
> --
> Joe Topjian
> Systems Administrator
> Cybera Inc.
>
> www.cybera.ca
>
> Cybera is a not-for-profit organization that works to spur and support
> innovation, for the economic benefit of Alberta, through the use
> of cyberinfrastructure.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120515/f4546302/attachment.html>