2016-07-04 16:47 GMT+03:00 Roman Podoliaka <rpodoly...@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 <lildee1...@gmail.com> > wrote: > > > > > > 2016-07-04 13:22 GMT+03:00 Roman Podoliaka <rpodoly...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev