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....@gmail.com<javascript:_e({}, 'cvml',
'yorik....@gmail.com');>>
wrote:
>
> On Tue, Jan 14, 2014 at 6:09 PM, Doug Hellmann <
> doug.hellm...@dreamhost.com> wrote:
>>
>> On Mon, Jan 13, 2014 at 9:36 PM, Jamie Lennox <jamielen...@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.
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
