Open Stack

Boris,

Move from sync http to something like websocket requires a lot of work and
not directly connected
with API issue. When openstack api servers begin to support
websockets - it would be easy to change implementation of monitoring thread
without breaking compatibility.
At the moment periodical pooling from additional thread looks reasonable
for me
and it creates same amount of http requests as all current implementation.

BP is not about improving performance,
but about providing convenient and common API to handle background tasks.

> So we won't need to retrieve 100500 times information about object.
As I sad before - this API creates same amount of load as any code which we
use to check background task currently.
It even can decrease load due to requests aggregation in some cases (but
there a points to discuss).

> As well this pattern doesn't look great.
> I would prefer to see something like:
> vm = novaclient.servers.create(...., sync=True)

This is completely different pattern. It is blocking call, which don't
allows you to start two(or more) background tasks
and from same thread and make some calculations while they running in
background.





On Mon, Jan 12, 2015 at 1:42 PM, Boris Pavlovic <bpavlovic at mirantis.com>
wrote:

> Konstantin,
>
>
> I believe it's better to work on server side, and use some modern approach
> like web sockets for async operations. So we won't need to retrieve 100500
> times information about object. And then use this feature in clients.
>
>  create_future = novaclient.servers.create_async(....)
>>     .....
>>     vm = create_future.result()
>
>
> As well this pattern doesn't look great.
>
> I would prefer to see something like:
>
>   vm = novaclient.servers.create(...., sync=True)
>
>
> Best regards,
> Boris Pavlovic
>
>
>
>
>
> On Mon, Jan 12, 2015 at 2:30 PM, Konstantin Danilov <kdanilov at mirantis.com
> > wrote:
>
>> Hi all.
>>
>> There a set of openstack api functions which starts background actions
>> and return preliminary results - like 'novaclient.create'. Those functions
>> requires periodically check results and handle timeouts/errors
>> (and often cleanup + restart help to fix an error).
>>
>> Check/retry/cleanup code duplicated over a lot of core projects.
>> As examples - heat, tempest, rally, etc and definitely in many
>> third-party scripts.
>>
>> I propose to provide common higth-level API for such functions, which uses
>> 'futures' (http://en.wikipedia.org/wiki/Futures_and_promises) as a way to
>> present background task.
>>
>> Idea is to add to each background-task-starter function a complimentary
>> call,
>> that returns 'future' object. E.g.
>>
>>     create_future = novaclient.servers.create_async(....)
>>     .....
>>     vm = create_future.result()
>>
>> This allows to unify(and optimize) monitoring cycles, retries, etc.
>> Please found complete BP at
>> https://github.com/koder-ua/os_api/blob/master/README.md
>>
>> Thanks
>> --
>> Kostiantyn Danilov aka koder <http://koder.ua>
>> Principal software engineer, Mirantis
>>
>> skype:koder.ua
>> http://koder-ua.blogspot.com/
>> http://mirantis.com
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kostiantyn Danilov aka koder.ua
Principal software engineer, Mirantis

skype:koder.ua
http://koder-ua.blogspot.com/
http://mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150112/60c69377/attachment.html>