Re: [openstack-dev] [Glance] property protections -- final call for comments
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.washenber...@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.mcla...@hp.commailto:stuart.mcla...@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@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] property protections -- final call for comments
On Fri, Jul 26, 2013 at 9:56 AM, stuart.mcla...@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-protectionhttps://blueprints.launchpad.net/glance/+spec/api-v2-property-protection The full specification: https://wiki.openstack.org/** wiki/Glance-property-**protectionshttps://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-producthttps://wiki.openstack.org/wiki/Glance-property-protections-product cheers, brian __**_ OpenStack-dev mailing list OpenStack-dev@lists.openstack.**org OpenStack-dev@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-devhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Glance] property protections -- final call for comments
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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
