Re: [Openstack] [OpenStack][Keystone] Blueprint to store quota data in Keystone
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.
Re: [Openstack] [OpenStack][Keystone] Blueprint to store quota data in Keystone
On Fri, May 11, 2012 at 9:07 AM, Joe Topjian joe.topj...@cybera.ca wrote: With regard to your dot notation, couldn't multiple --quota args be used? For example: keystone quota-create --quota nova.ram=102400 --quota nova.instances=20 --quota swift.total=1073741824 tenant-id Hmmmthis would be possible with nargs in the argparse module and it would remove the need to use --quota multiple times. 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. Everett ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack][Keystone] Blueprint to store quota data in Keystone
On May 10, 2012, at 12:55 PM, Everett Toews wrote:
Hi All,
I've started a blueprint and spec to store quota data in Keystone. Please
have a look if you're interested and any feedback is welcome.
Of course, writing up the spec brought up number of questions for me. You can
find more detail in the spec but here they are to get some more exposure.
1. For the keystone CLI I'm proposing using JSON for batch create, update,
and delete of quotas. I don't believe this is done anywhere else in
OpenStack. Good idea? Bad idea?
My plan is to go with the JSON.
If you're going to use json in the CLI for complex operations, I would
recommend reading the json from stdin rather than passing it as a command-line
flag.
This means users could do either:
echo {'key': 'value'} | keystone …
or:
keystone … batch.json
Take care,
Lorin
--
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack][Keystone] Blueprint to store quota data in Keystone
Hi Everett, 1. For the keystone CLI I'm proposing using JSON for batch create, update, and delete of quotas. I don't believe this is done anywhere else in OpenStack. Good idea? Bad idea? My plan is to go with the JSON. IMO, using JSON on the command line is pretty unconventional with regards to classic CLI commands, but I do think it is interesting. With regard to your dot notation, couldn't multiple --quota args be used? For example: keystone quota-create --quota nova.ram=102400 --quota nova.instances=20 --quota swift.total=1073741824 tenant-id This is definitely possible programmatically with Python and the opt-parsing modules, but I was wondering if you chose not to use it as an example for other non-programmatic reasons. 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? 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
[Openstack] [OpenStack][Keystone] Blueprint to store quota data in Keystone
Hi All, I've started a blueprinthttps://blueprints.launchpad.net/keystone/+spec/store-quota-dataand spec http://wiki.openstack.org/KeystoneStoreQuotaData to store quota data in Keystone. Please have a look if you're interested and any feedback is welcome. Of course, writing up the spec brought up number of questions for me. You can find more detail in the spec but here they are to get some more exposure. 1. For the keystone CLI I'm proposing using JSON for batch create, update, and delete of quotas. I don't believe this is done anywhere else in OpenStack. Good idea? Bad idea? My plan is to go with the JSON. 2. For the RESTful API, do we have just one DELETE with details of what to delete in the body of the request? My plan is to go with just one DELETE. 3. For the implementation I'm proposing two options. 1. Store the data in the current metadata table. 2. Store the data in a new metadata_per_tenant table. Thoughts? My plan is to use option 2. 4. If you change the word quota to the word metadata in the User Stories and the Design sections, this becomes a generic mechanism for accessing metadata per tenant. Do we want a generic metadata service for keystone or stick with a service specific to quotas, while keeping the underlying implementation generic? I'm on the fence about this one. On one hand, it's very clear to have a well defined API that's just used for quotas. On the other hand, it's very flexible to have a generic API that can be used for any metadata (although maybe that promotes abuse of the feature). Regards, Everett ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
