Open Stack

In addition to the installation requirements, we also need to deal with the
code-level changes. For example, when using the eventlet executor eventlet
needs to have been imported very early by the application so it can
monkeypatch the I/O libraries. When not using the eventlet executor, that
monkeypatching should not be done because it will interfere with the
regular I/O. So now we have an operation that needs to happen during code
initialization that is dictated by a configuration option (which executor
is being used) only available after all of the code initialization has
happened.

My first impression is that when we have an executor that works with
asyncio/trollius we will want to drop eventlet entirely, but that's just a
first impression. There may be similar trade-offs with the other libraries.

Victor, what do you think?

Doug


On Mon, Mar 17, 2014 at 9:52 PM, Davanum Srinivas <davanum at gmail.com> wrote:

> Adrian,
>
> We are too close to icehouse release candidates to bump up global
> requirements with new rev of oslo.messaging. So even if we all agree
> and cut a new rev of oslo.messaging it's too late for icehouse as
> release candidates are rolling next week.
>
> I'd definitely support a way to get python33 support via trollius or
> thread-exec that Joshua pointed out very soon. It may be a good idea
> to keep solum's py33 non-voting till we nail down all other other
> dependencies, so +1 for that as well.
>
> -- dims
>
> On Mon, Mar 17, 2014 at 7:29 PM, Adrian Otto <adrian.otto at rackspace.com>
> wrote:
> > Doug Hellmann and Victror Stinner (+ oslo cores),
> >
> > Solum currently depends on a py33 gate. We want to use oslo.messaging,
> but are worried that in the current state, we will be stuck without py33
> support. We hope that by adding the Trollius code[1], and getting a new
> release number, that we can add the oslo.messaging library to our
> requirements and proceed with our async messaging plan.
> >
> > I am seeking guidance from you on when the above might happen. If it's a
> short time, we may just wait for it. If it's a long time, we may need to
> relax our py33 gate to non-voting in order to prevent breakage of our
> Stackforge CI while we work with the oslo.messaging code. We are also
> considering doing an ugly workaround of creating a bunch of worker
> processes on the same messaging topic until we can clear this concern.
> >
> > Thoughts?
> >
> > Thanks,
> >
> > Adrian
> >
> > [1] https://review.openstack.org/70948
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
> _______________________________________________
> 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/20140318/981c4f31/attachment.html>