openstack team mailing list archive

[Joe Topjian <joe.topjian@xxxxxxxxx>]

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.