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 <jguid...@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-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
