Open Stack

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:
> >
> >
> >
> >
> > 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?
>
> I completely agree with you/WSME that this is a bad situation. 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.
>

Why not? Isn't this a backwards incompatible API change already? :-)


I don't think WSME should advocate the situation, though it will already
> ignore additional attributes i'm wondering what would be involved with
> just collecting and stashing those additional attributes?
>

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.

Doug



>
>
> > 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
> >
> >
> >
> > _______________________________________________
> > 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/20140114/8278a9cf/attachment.html>