<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 13, 2014 at 9:36 PM, Jamie Lennox <span dir="ltr"><<a href="mailto:jamielennox@redhat.com" target="_blank">jamielennox@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, 2014-01-13 at 10:05 -0500, Doug Hellmann wrote:<br>
><br>
><br>
><br>
><br>
> On Sun, Jan 12, 2014 at 6:33 PM, Jamie Lennox <<a href="mailto:jamielennox@redhat.com">jamielennox@redhat.com</a>><br>
> wrote:<br>
> On Fri, 2014-01-10 at 10:23 -0500, Doug Hellmann wrote:<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On Thu, Jan 9, 2014 at 12:02 AM, Jamie Lennox<br>
> <<a href="mailto:jamielennox@redhat.com">jamielennox@redhat.com</a>><br>
> > wrote:<br>
> > Is there any way to have WSME pass through arbitrary<br>
> > attributes to the created object? There is nothing<br>
> that i can<br>
> > see in the documentation or code that would seem to<br>
> support<br>
> > this.<br>
> ><br>
> > In keystone we have the situation where arbitrary<br>
> data was<br>
> > able to be attached to our resources. For example<br>
> there are a<br>
> > certain number of predefined attributes for a user<br>
> including<br>
> > name, email but if you want to include an address<br>
> you just add<br>
> > an 'address': 'value' to the resource creation and<br>
> it will be<br>
> > saved and returned to you when you request the<br>
> resource.<br>
> ><br>
> > Ignoring whether this is a good idea or not (it's<br>
> done), is<br>
> > the option there that i missed - or is there any<br>
> plans/way to<br>
> > support something like this?<br>
> ><br>
> ><br>
> > There's a change in WSME trunk (I don't think we've released<br>
> it yet)<br>
> > that allows the schema for a type to be changed after the<br>
> class is<br>
> > defined. There isn't any facility for allowing the caller to<br>
> pass<br>
> > arbitrary data, though. Part of the point of WSME is to<br>
> define the<br>
> > inputs and outputs of the API for validation.<br>
> ><br>
> ><br>
> > How are the arbitrary values being stored in keystone? What<br>
> sorts of<br>
> > things can be done with them? Can an API caller query them,<br>
> for<br>
> > example?<br>
> ><br>
> ><br>
> > Doug<br>
><br>
><br>
> So you can't query based on these arbitrary values but they<br>
> are there as<br>
> part of the resource. We have generic middleware that<br>
> interprets the<br>
> incoming json or xml to python dictionaries. Then we extract<br>
> the<br>
> queryable information for storing into database cells. In the<br>
> case of<br>
> User these are: id, name, password, enabled, domain_id,<br>
> default_project_id. Everything else in the dictionary is<br>
> stored in an<br>
> 'extra' column in the database as a JSON dictionary. When we<br>
> reconstruct<br>
> the User object we recreate the extra dictionary and update it<br>
> with the<br>
> known attributes.<br>
><br>
> So there is no restriction on types or depth of objects, and<br>
> whilst you<br>
> can't query from those attributes they will always be present<br>
> if you get<br>
> or list the user.<br>
><br>
> Note that User is probably a bad example in this because of<br>
> LDAP and<br>
> other backends but the idea is the same for all keystone<br>
> resources.<br>
><br>
><br>
> So I don't think that changing the WSME type after definition<br>
> is useful<br>
> in this case. Is it the sort of thing that would be possible<br>
> or accepted<br>
> to add to WSME?<br>
><br>
> From the little bit of looking i've done it appears that WSME<br>
> loops over<br>
> the defined attributes of the class and extracts those from<br>
> the message<br>
> rather than looping over keys in the message which makes this<br>
> more<br>
> difficult. Can WSME be made to decode all values in a purely<br>
> python<br>
> primative way (eg don't decode dates, objects etc, just give<br>
> python<br>
> dictionaries like from a json.loads)?<br>
><br>
><br>
> WSME asserts that APIs should be well and clearly defined, so that<br>
> callers of the API can understand what they are supposed to (or<br>
> required to) pass in, and what they will receive as a response.<br>
> Accepting arbitrary data goes somewhat against this design goal.<br>
><br>
><br>
> I would prefer not to have keystone using yet another<br>
> framework from the<br>
> rest of openstack, but should i just be looking to use<br>
> jsonschema or<br>
> something instead?<br>
><br>
><br>
> What requirement(s) led to keystone supporting this feature?<br>
<br>
</div></div>I completely agree with you/WSME that this is a bad situation. I've got<br>
no idea where the requirement came from however it is something that is<br>
supported now and so not something we can back out of.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Why not? Isn't this a backwards incompatible API change already? :-)</div>
<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't think WSME should advocate the situation, though it will already<br>
ignore additional attributes i'm wondering what would be involved with<br>
just collecting and stashing those additional attributes?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div>
<br></div><div><div class="gmail_default" style="font-size:small">Doug</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
> Doug<br>
><br>
><br>
><br>
><br>
> Jamie<br>
><br>
> ><br>
> ><br>
> ><br>
> > Thanks,<br>
> ><br>
> > Jamie<br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> ><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> ><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>