Open Stack

The question was never whether it could be made to do it (we'd have to
change it, but it's just code). The question was whether allowing extra
data was a good idea at all. If it's a real requirement, we just need a
patch to WSME to support it.

Doug


On Sat, Jan 18, 2014 at 8:30 PM, Morgan Fainberg <m at metacloud.com> wrote:

> 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> 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.
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> 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/20140123/f061acf1/attachment.html>