Open Stack

Having an extra column to hold a set of attributes is not the best 
database structure to use. Rather the attributes should be first class 
citizens in their own right, and each have their own columns

david

On 30/01/2013 22:06, Dolph Mathews wrote:
> The current implementation allows you to add extra attributes to any
> user, tenant, etc (supporting undocumented or proprietary API contracts
> to an extent). In the SQL drivers, we store that data in the 'extra'
> column. The v3 python client and the grizzly release will be a little
> more formal and consistent about this behavior.
>
> My question is: how and when do you want to get that data back?
>
>
> -Dolph
>
>
> On Wed, Jan 30, 2013 at 3:47 PM, Nathanael Burton
> <nathanael.i.burton at gmail.com <mailto:nathanael.i.burton at gmail.com>> wrote:
>
>     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
>     <mailto: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
>         <mailto:OpenStack-dev at lists.openstack.org>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>