Open Stack

Phil,

We've added additional fields to the "extra" value of the tenant table for
particular tenants in our deployments.  Similar to your example, we've
added a key-value pair called 'regions' that's populated with the list of
regions where the tenant should exist.  In many cases we don't want a
particular tenant to have the ability to use resources across ALL regions
that keystone is configured to know about, just specific ones. Don't know
if this was the best way to do this or not, but this use-case didn't seem
to fit into any existing model already in keystone.

Nate


On Wed, Jan 30, 2013 at 3:46 PM, Day, Phil <philip.day at hp.com> wrote:

>  Hi Folks,****
>
> ** **
>
> I’m looking at couple use cases where I’d really like to have additional
> per-tenant data supplied from keystone.****
>
> ** **
>
> The first case is to make the current quota-classes extension in Nova
> usable – this provides a much better way to manage quotas, but relies on
> the quota_class being set in the context.****
>
> ** **
>
> The second case is to prove a per-tenant default availability zone –
> having a default makes sense in some cases, but having the same default for
> all tenants (which is what the current config option gives) can be an issue
> from a load balancing perspective.****
>
> ** **
>
> I guess I could just do all of this via the roles in current keystone
> (i.e. define a role with a name like “quota_class:xxx” and
> “default_az:az1”), as these seem to be  in effect arbitrary properties of a
> tenant as far as keystone is concerned, but I’m wondering if there
> shouldn’t be some more general way of adding key-value attributes to a
> tenant.****
>
> ** **
>
> Thoughts ?   ****
>
> ** **
>
> Phil****
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130130/afb8f307/attachment.html>