Open Stack

Hi,

mod_wsgi has some limitations so making order for WSGI services. Reloading
and restarting processes is well documented at [1]. Creating ordering is a
problem. There are several options:
1. Use uwsgi instead of mod_wsgi
2. Use several apache instances (one instance for one service)
3. Ignore ordering as processes start quite fast

[1] https://code.google.com/p/modwsgi/wiki/ReloadingSourceCode

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Wed, Nov 4, 2015 at 4:31 PM, Jason Guiditta <jguiditt at redhat.com> wrote:

> On 14/08/15 09:45 -0400, Emilien Macchi wrote:
>
>> So far we have WSGI support for puppet-keystone & pupper-ceilometer.
>> I'm currently working on other components to easily deploy OpenStack
>> running API services using apache/wsgi instead of eventlet.
>>
>> I would like to propose some change in our beaker tests:
>>
>> stable/kilo:
>> * puppet-{ceilometer,keystone}: test both cases so we validate the
>> upgrade with beaker
>> * puppet-*: no wsgi support now, but eventually could be backported from
>> master (liberty) once pushed.
>>
>> master (future stable/liberty):
>> * puppet-{ceilometer,keystone}: keep only WSGI scenario
>> * puppet-*: push WSGI support in manifests, test them in beaker,
>> eventually backport them to stable/kilo, and if on time (before
>> stable/libery), drop non-WSGI scenario.
>>
>> The goal here is to:
>> * test upgrade from non-WSGI to WSGI setup in stable/kilo for a maximum
>> of modules
>> * keep WSGI scenario only for Liberty
>>
>> Thoughts?
>> --
>> Emilien Macchi
>>
>> Sorry for the late reply, but I am wondering if anyone knows how we
> (via puppet, pacemaker, or whatever else - even the services
> themselves, within apache) would handle start order if all these
> services become wsgi apps running under apache?  In other words, for
> an HA deployment, as an example, we typically set ceilometer-central
> to start _after_ keystone.  If they are both in apache, how could this
> be done?  Is it truly not needed? If not, is this something new, or
> have those of us working on deployments with the pacemaker
> architecture been misinformed all this time?
>
> -j
>
>
>
> __________________________________________________________________________
> 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/20151104/66ef6918/attachment.html>