Open Stack

On Sun, Jan 12, 2014 at 6:33 PM, Jamie Lennox <jamielennox at redhat.com>wrote:

> On Fri, 2014-01-10 at 10:23 -0500, Doug Hellmann wrote:
> >
> >
> >
> >
> > On Thu, Jan 9, 2014 at 12:02 AM, Jamie Lennox <jamielennox at redhat.com>
> > wrote:
> >         Is there any way to have WSME pass through arbitrary
> >         attributes to the created object? There is nothing that i can
> >         see in the documentation or code that would seem to support
> >         this.
> >
> >         In keystone we have the situation where arbitrary data was
> >         able to be attached to our resources. For example there are a
> >         certain number of predefined attributes for a user including
> >         name, email but if you want to include an address you just add
> >         an 'address': 'value' to the resource creation and it will be
> >         saved and returned to you when you request the resource.
> >
> >         Ignoring whether this is a good idea or not (it's done), is
> >         the option there that i missed - or is there any plans/way to
> >         support something like this?
> >
> >
> > There's a change in WSME trunk (I don't think we've released it yet)
> > that allows the schema for a type to be changed after the class is
> > defined. There isn't any facility for allowing the caller to pass
> > arbitrary data, though. Part of the point of WSME is to define the
> > inputs and outputs of the API for validation.
> >
> >
> > How are the arbitrary values being stored in keystone? What sorts of
> > things can be done with them? Can an API caller query them, for
> > example?
> >
> >
> > Doug
>
> So you can't query based on these arbitrary values but they are there as
> part of the resource. We have generic middleware that interprets the
> incoming json or xml to python dictionaries. Then we extract the
> queryable information for storing into database cells. In the case of
> User these are: id, name, password, enabled, domain_id,
> default_project_id. Everything else in the dictionary is stored in an
> 'extra' column in the database as a JSON dictionary. When we reconstruct
> the User object we recreate the extra dictionary and update it with the
> known attributes.
>
> So there is no restriction on types or depth of objects, and whilst you
> can't query from those attributes they will always be present if you get
> or list the user.
>
> Note that User is probably a bad example in this because of LDAP and
> other backends but the idea is the same for all keystone resources.
>
>
> So I don't think that changing the WSME type after definition is useful
> in this case. Is it the sort of thing that would be possible or accepted
> to add to WSME?
>

> From the little bit of looking i've done it appears that WSME loops over
> the defined attributes of the class and extracts those from the message
> rather than looping over keys in the message which makes this more
> difficult. Can WSME be made to decode all values in a purely python
> primative way (eg don't decode dates, objects etc, just give python
> dictionaries like from a json.loads)?
>

WSME asserts that APIs should be well and clearly defined, so that callers
of the API can understand what they are supposed to (or required to) pass
in, and what they will receive as a response. Accepting arbitrary data goes
somewhat against this design goal.

I would prefer not to have keystone using yet another framework from the
> rest of openstack, but should i just be looking to use jsonschema or
> something instead?
>

What requirement(s) led to keystone supporting this feature?

Doug



>
> Jamie
>
> >
> >
> >
> >         Thanks,
> >
> >         Jamie
> >
> >         _______________________________________________
> >         OpenStack-dev mailing list
> >         OpenStack-dev at lists.openstack.org
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> 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/20140113/ac6475a3/attachment.html>