Open Stack

>> Hi Brian,
>>
>> Firstly, thanks for all your great work here!
>>
>> Some feedback:
>>
>> 1) Is there a clash with existing user properties?
>>
>> For currently deployed systems a user may have an existing property 'foo:
>> bar'.
>> If we restrict property access (by virtue of allowing only owner_xxx)
>> can the user update this previously existing property?
>>
>
> 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.

I understand that you think this functionality will not typically be used
but I wonder if such a migration comes uncomfortably close to breaking
the API (much more so than any standard policy change): eg any scripts
that update/read arbitrary metadata keys routinely would require modification.
Should users really have to fear their metadata moving at the whim of their
provider?

I'm not sure "completely isolating" users' properties to a prefix is
achieved here: nova will still require writing outside the prefix from user context when
snapshotting (eg for the 'architecture' property) so some exceptions would
have to be added (and the migration would be a bit messier since some user
properties would be moved and some would remain).

>
>>
>> 2) "A nice feature of this scheme is that the cloud provider can pick an
>> arbitrary
>> informal namespace for this purpose and educate users appropriately."
>>
>> How about having the user properties area be always the same?
>> It would be more consistent/predictable -- is there a down side?
>
>
> 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.
>
>
>> 3) we could potentially link roles to the regex
>>
>> eg this could allow role1_xxx to be writable only if you have 'role1'.
>> By assigning appropriate roles (com.provider/com.partner/**nova?) you
>> could provide the ability to write to that prefix without config file
>> changes.
>>
>> Thanks,
>>
>> -Stuart
>>
>>  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!
>>>
>>> The blueprint: https://blueprints.launchpad.**net/glance/+spec/api-v2-**
>>> property-protection<https://blueprints.launchpad.net/glance/+spec/api-v2-property-protection>
>>>
>>> The full specification: https://wiki.openstack.org/**
>>> wiki/Glance-property-**protections<https://wiki.openstack.org/wiki/Glance-property-protections>
>>>   (it's got a Prior Discussion section with links to the discussion
>>> etherpads)
>>>
>>> A "product" approach to describing the feature:
>>> https://wiki.openstack.org/**wiki/Glance-property-**protections-product<https://wiki.openstack.org/wiki/Glance-property-protections-product>
>>>
>>> cheers,
>>> brian
>>>
>>
>> ______________________________**_________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<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/20130726/727c10e5/attachment-0001.html>
>
> ------------------------------
>