Open Stack

On Tue, Feb 25, 2014 at 3:47 PM, Sylvain Bauza <sylvain.bauza at gmail.com>wrote:

> Well, I agreed with the fact I switched some way the use of this feature
> to match my needs, but then let me ask you a quick question : how can
> handle WSME variable request body ?
>
> The first glance I have is that WSME is requiring a static API in terms of
> inputs, could you then confirm ?
>

Yes, that's correct.



> Do you have any idea on how I could get my goal, ie. having a static input
> plus some extra variable inputs ? I was also thinking about playing with
> __getattr__ and __setattr__ but I'm not sure the Registry could handle that.
>

Why don't you know what the data is going to look like before you receive
it?

One last important point, this API endpoint (Host) is admin-only in case of
> you mention the potential security issues it could lead.
>

My issue with this sort of API isn't security, it's that describing how to
use it for an end user is more difficult than having a clearly defined
static set of inputs and outputs.

Doug



>
> Thanks for your help,
> -Sylvain
>
>
> 2014-02-25 18:55 GMT+01:00 Doug Hellmann <doug.hellmann at dreamhost.com>:
>
> OK, that's not how that feature is meant to be used.
>>
>> The idea is that on application startup plugins or extensions will be
>> loaded that configure the extra attributes for the class. That happens one
>> time, and the configuration does not depend on data that appears in the
>> request itself.
>>
>> Doug
>>
>>
>> On Tue, Feb 25, 2014 at 9:07 AM, Sylvain Bauza <sylvain.bauza at gmail.com>wrote:
>>
>>> Let me give you a bit of code then, that's currently WIP with heavy
>>> rewrites planned on the Controller side thanks to Pecan hooks [1]
>>>
>>> So, L102 (GET request) the convert() method is passing the result dict
>>> as kwargs, where the Host.__init__() method is adding dynamic attributes.
>>> That does work :-)
>>>
>>> L108, I'm specifying that my body string is basically an Host object.
>>> Unfortunately, I can provide extra keys to that where I expect to be extra
>>> attributes. WSME will then convert the body into an Host [2], but as the
>>> Host class doesn't yet know which extra attributes are allowed, none of my
>>> extra keys are taken.
>>> As a result, the 'host' (instance of Host) argument of the post() method
>>> is not containing the extra attributes and thus, not passed for creation to
>>> my Manager.
>>>
>>> As said, I can still get the request body using Pecan directly within
>>> the post() method, but I then would have to manage the mimetype, and do the
>>> adding of the extra attributes there. That's pretty ugly IMHO.
>>>
>>> Thanks,
>>> -Sylvain
>>>
>>> [1] http://paste.openstack.org/show/69418/
>>>
>>> [2] https://github.com/stackforge/wsme/blob/master/wsmeext/pecan.py#L71
>>>
>>>
>>> 2014-02-25 14:39 GMT+01:00 Doug Hellmann <doug.hellmann at dreamhost.com>:
>>>
>>>
>>>>
>>>>
>>>> On Tue, Feb 25, 2014 at 6:55 AM, Sylvain Bauza <sylvain.bauza at gmail.com
>>>> > wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Thanks to WSME 0.6, there is now possibility to add extra attributes
>>>>> to a Dynamic basetype.
>>>>> I successfully ended up showing my extra attributes from a dict to a
>>>>> DynamicType using add_attributes() but I'm now stuck with POST requests
>>>>> having dynamic body data.
>>>>>
>>>>> Although I'm declaring in wsexpose() my DynamicType, I can't say to
>>>>> WSME to map the pecan.request.body dict with my wsattrs and create new
>>>>> attributes if none matched.
>>>>>
>>>>> Any idea on how to do this ? I looked at WSME and the type is
>>>>> registered at API startup, not when being called, so the get_arg() method
>>>>> fails to fill in the gaps.
>>>>>
>>>>> I can possibly do a workaround within my post function, where I could
>>>>> introspect pecan.request.body and add extra attributes, so it sounds a bit
>>>>> crappy as I have to handle the mimetype already managed by WSME.
>>>>>
>>>>
>>>> I'm not sure I understand the question. Are you saying that the dynamic
>>>> type feature works for GET arguments but not POST body content?
>>>>
>>>> Doug
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>> -Sylvain
>>>>>
>>>>> _______________________________________________
>>>>> 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/20140225/dc55d86e/attachment.html>