Open Stack

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. 

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?


> 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