Open Stack

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 ?
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.

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

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140225/aa8c3bbe/attachment.html>