<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 26, 2013 at 9:56 AM,  <span dir="ltr"><<a href="mailto:stuart.mclaren@hp.com" target="_blank">stuart.mclaren@hp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Brian,<br>
<br>
Firstly, thanks for all your great work here!<br>
<br>
Some feedback:<br>
<br>
1) Is there a clash with existing user properties?<br>
<br>
For currently deployed systems a user may have an existing property 'foo: bar'.<br>
If we restrict property access (by virtue of allowing only owner_xxx)<br>
can the user update this previously existing property?<br></blockquote><div><br></div><div>No, a user would not be able to update the previously existing property. However, I do not view requiring "owner_" as a prefix for generic metadata properties to be the typical use case, so I am not concerned about this conflict. Those who wish to take on the extra responsibility of completely isolating owner metadata into a prefix may also take on the responsibility of migrating existing general properties to that prefix.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) "A nice feature of this scheme is that the cloud provider can pick an arbitrary<br>
informal namespace for this purpose and educate users appropriately."<br>
<br>
How about having the user properties area be always the same?<br>
It would be more consistent/predictable -- is there a down side?</blockquote><div> </div><div>I'm not sure that the need is great enough--the downside is that this user properties area may not be appropriate for a majority of deployers.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3) we could potentially link roles to the regex<br>
<br>
eg this could allow role1_xxx to be writable only if you have 'role1'.<br>
By assigning appropriate roles (com.provider/com.partner/<u></u>nova?) you<br>
could provide the ability to write to that prefix without config file<br>
changes.<br>
<br>
Thanks,<br>
<br>
-Stuart<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
After lots of discussion, I think we've come to a consensus on what property protections should look like in Glance.  Please reply with comments!<br>
<br>
The blueprint: <a href="https://blueprints.launchpad.net/glance/+spec/api-v2-property-protection" target="_blank">https://blueprints.launchpad.<u></u>net/glance/+spec/api-v2-<u></u>property-protection</a><br>
<br>
The full specification: <a href="https://wiki.openstack.org/wiki/Glance-property-protections" target="_blank">https://wiki.openstack.org/<u></u>wiki/Glance-property-<u></u>protections</a><br>
  (it's got a Prior Discussion section with links to the discussion etherpads)<br>
<br>
A "product" approach to describing the feature: <a href="https://wiki.openstack.org/wiki/Glance-property-protections-product" target="_blank">https://wiki.openstack.org/<u></u>wiki/Glance-property-<u></u>protections-product</a><br>

<br>
cheers,<br>
brian<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br></div></div>