<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">+1 for supporting this in a more formal way, since I see a number of implementations that hope to make use of this. <div><br></div><div>My view is that wherever you return a full entity item, you should fish out any stored extra attributes and return them. I think it is an open questions as to whether we group them under something like the "extra" attribute or return them as if they were first class attributes (I know we used to return the "extra" attribute kind of by mistake in Folson, but the current Grizzly code has removed that).<div><br></div><div>Henry<br><div><div>On 30 Jan 2013, at 22:06, Dolph Mathews wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">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.<div>
<br></div><div style="">My question is: how and when do you want to get that data back?</div></div><div class="gmail_extra"><br clear="all"><div><div><br></div>-Dolph</div>
<br><br><div class="gmail_quote">On Wed, Jan 30, 2013 at 3:47 PM, Nathanael Burton <span dir="ltr"><<a href="mailto:nathanael.i.burton@gmail.com" target="_blank">nathanael.i.burton@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>Phil,<br><br></div>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. <br>
<br>Nate<br></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Wed, Jan 30, 2013 at 3:46 PM, Day, Phil <span dir="ltr"><<a href="mailto:philip.day@hp.com" target="_blank">philip.day@hp.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<div link="blue" vlink="purple" lang="EN-GB">
<div><p class="MsoNormal">Hi Folks,<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I’m looking at couple use cases where I’d really like to have additional per-tenant data supplied from keystone.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Thoughts ? <span><font color="#888888"><u></u><u></u></font></span></p><span><font color="#888888"><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Phil<u></u><u></u></p>
</font></span></div>
</div>
<br></div></div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></div></div></body></html>