Open Stack

2016-07-04 16:47 GMT+03:00 Roman Podoliaka <rpodolyaka at mirantis.com>:

> That's exactly what https://github.com/koder-ua/os_api is for: it
> polls status changes in a separate thread and then updates the
> futures, so that you can wait on multiple futures at once.
>
>
This is what i exactly want to avoid - new thread. I'm using event loop
with uvloop policy, so i must stay non-blocked within main thread and don't
mess up with GIL by instantiating new thread. With coroutines concept from
asyncio i can do non-blocking operations relying on EPOLL under the hood.

Kind regards,
Denys Makogon


> On Mon, Jul 4, 2016 at 2:19 PM, Denis Makogon <lildee1991 at gmail.com>
> wrote:
> >
> >
> > 2016-07-04 13:22 GMT+03:00 Roman Podoliaka <rpodolyaka at mirantis.com>:
> >>
> >> Denis,
> >>
> >> >  Major problem
> >> > appears when you trying to provision resource that requires to have
> some
> >> > time to reach ACTIVE/COMPLETED state (like, nova instance, stack,
> trove
> >> > database, etc.) and you have to use polling for status changes and in
> >> > general polling requires to send HTTP requests within specific time
> >> > frame
> >> > defined by number of polling retries and delays between them (almost
> all
> >> > PaaS solutions in OpenStack are doing it that might be the case of
> >> > distributed backend services, but not for async frameworks).
> >>
> >> How would an asynchronous client help you avoid polling here? You'd
> >> need some sort of a streaming API producing events on the server side.
> >>
> >
> > No, it would not help me to get rid of polling, but using async requests
> > will allow to proceed with next independent async tasks while awaiting
> > result on async HTTP request.
> >
> >>
> >> If you are simply looking for a better API around polling in OS
> >> clients, take a look at https://github.com/koder-ua/os_api , which is
> >> based on futures (be aware that HTTP requests are still *synchronous*
> >> under the hood).
> >>
> >> Thanks,
> >> Roman
> >>
> >>
> __________________________________________________________________________
> >> 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
> >
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/46dfbfc8/attachment.html>