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.
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
