Open Stack

Stuart,

I agree with Mark's comments, wanted to address this:
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.
I like your idea, and I think the config we're proposing would be able to cover this use case.  Since the plan is to allow reference to roles defined in policy.json, it would just be up to the provider to make sure the config file and the policy.json were in sync.  (Not as nice as having it work automatically, but should be doable.)

cheers,
brian

________________________________
From: Mark Washenberger [mark.washenberger at markwash.net]
Sent: Friday, July 26, 2013 2:56 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Glance] property protections -- final call for comments




On Fri, Jul 26, 2013 at 9:56 AM, <stuart.mclaren at hp.com<mailto:stuart.mclaren at hp.com>> wrote:
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.


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

The full specification: 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

cheers,
brian

_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130728/18e64021/attachment.html>