Open Stack

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.

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.

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.

On Sun, Nov 6, 2016 at 6:25 PM, Matt Riedemann <mriedem at linux.vnet.ibm.com>
wrote:

> On 11/4/2016 7:15 PM, Steve Martinelli wrote:
>
>> The keystone team has a new spec being proposed for the Ocata release,
>> it essentially boils down to adding properties / metadata for projects
>> (for now) [1].
>>
>> We have somewhat had support for this, we have an "extras" column
>> defined in our database schema, whatever a user puts in a request that
>> doesn't match up with our API, those key-values are dumped into the
>> "extras" column. It's not a pleasant user experience, since you can't
>> really "unset" the data easily, or grab it, or update it. There's
>> actually been patches to keystoneclient for getting around this, but its
>> rather hacky and hardcodes a lot of values [2] [3]
>>
>> I've added nova and cinder here since the APIs that are being proposed
>> are more or less carbon copies of what is available through their APIs
>> (for server and volumes, respectively). What has been your project's
>> experience with handling metadata / properties? I assume that its been
>> there a while and you can't remove it. If you could go back and redo
>> things, would you do it another way? Would you take a more purist stance
>> and enforce more strict APIs, metadata be damned?
>>
>> I also added horizon because i'm curious about the impact this causes
>> when representing a resource.
>>
>> Personally, I am for the idea, we've had numerous requests from
>> operators about providing this support and I like to make them happy.
>>
>> [1] https://review.openstack.org/#/c/388886/
>> [2] https://review.openstack.org/#/c/375239/
>> [3] https://review.openstack.org/#/c/296246/
>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> 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:
>
> https://specs.openstack.org/openstack/nova-specs/specs/newto
> n/approved/lowercase-metadata-keys.html
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20161108/17c0e380/attachment.html>