Open Stack

Yes, this feature is used in real deployments just as Yuriy described. I
really want to avoid a new API version since we're just now getting solidly
into V3 being used more extensively.  Is it unreasonable to have wsme allow
"extra values" in some manner? (I think that is the crux, is it something
that can even be expected)

--Morgan

On Saturday, January 18, 2014, Yuriy Taraday
<yorik.sar at gmail.com<javascript:_e({}, 'cvml',
'yorik.sar at gmail.com');>>
wrote:

>
> On Tue, Jan 14, 2014 at 6:09 PM, Doug Hellmann <
> doug.hellmann at dreamhost.com> wrote:
>>
>> On Mon, Jan 13, 2014 at 9:36 PM, Jamie Lennox <jamielennox at redhat.com>wrote:
>>
>>> On Mon, 2014-01-13 at 10:05 -0500, Doug Hellmann wrote:
>>> > What requirement(s) led to keystone supporting this feature?
>>>
>>> I've got no idea where the requirement came from however it is something
>>> that is
>>> supported now and so not something we can back out of.
>>>
>>
>> If it's truly a requirement, we can look into how to make that work. The
>> data is obviously present in the request, so we would just need to preserve
>> it.
>>
>
> We've seen a use case for arbitrary attributes in Keystone objects. Cloud
> administrator might want to store some metadata along with a user object.
> For example, customer name/id and couple additional fields for contact
> information. The same might be applied to projects and  domains.
>
> So this is a very nice feature that should be kept around. It might be
> wrapped in some way (like in explicit unchecked "metadata" attribute) in a
> new API version though.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140118/b5f935fb/attachment.html>