<div dir="ltr">This spec was discussed at the keystone meeting today and during the conversation that continued afterwards, an idea of using the keystone configuration to set a list of keys was mentioned.<br><br>The idea is that a cloud admin could define a list of keys that they need for their setup within keystone's configuration file, then only those keys will be valid for storing values in the project properties table.  Then each call would check against the list of valid keys and deny any calls that are sent with an invalid key.<br><br>This idea seems to help with the issue to avoid allowing anyone to throw any arbitrary values into these project properties vs just a set number of values.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 6, 2016 at 6:25 PM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/4/2016 7:15 PM, Steve Martinelli wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The keystone team has a new spec being proposed for the Ocata release,<br>
it essentially boils down to adding properties / metadata for projects<br>
(for now) [1].<br>
<br>
We have somewhat had support for this, we have an "extras" column<br>
defined in our database schema, whatever a user puts in a request that<br>
doesn't match up with our API, those key-values are dumped into the<br>
"extras" column. It's not a pleasant user experience, since you can't<br>
really "unset" the data easily, or grab it, or update it. There's<br>
actually been patches to keystoneclient for getting around this, but its<br>
rather hacky and hardcodes a lot of values [2] [3]<br>
<br>
I've added nova and cinder here since the APIs that are being proposed<br>
are more or less carbon copies of what is available through their APIs<br>
(for server and volumes, respectively). What has been your project's<br>
experience with handling metadata / properties? I assume that its been<br>
there a while and you can't remove it. If you could go back and redo<br>
things, would you do it another way? Would you take a more purist stance<br>
and enforce more strict APIs, metadata be damned?<br>
<br>
I also added horizon because i'm curious about the impact this causes<br>
when representing a resource.<br>
<br>
Personally, I am for the idea, we've had numerous requests from<br>
operators about providing this support and I like to make them happy.<br>
<br>
[1] <a href="https://review.openstack.org/#/c/388886/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/388886/</a><br>
[2] <a href="https://review.openstack.org/#/c/375239/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/375239/</a><br>
[3] <a href="https://review.openstack.org/#/c/296246/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/296246/</a><br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</blockquote>
<br>
If you're going to do it, restrict the case and characters in the keys because if you don't you can get fits in the backend database wrinkles. See this nova spec for details:<br>
<br>
<a href="https://specs.openstack.org/openstack/nova-specs/specs/newton/approved/lowercase-metadata-keys.html" rel="noreferrer" target="_blank">https://specs.openstack.org/op<wbr>enstack/nova-specs/specs/newto<wbr>n/approved/lowercase-metadata-<wbr>keys.html</a><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</font></span></blockquote></div><br></div>