Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54 -0600: > > > On Oct 18, 2016, at 5:14 AM, Ian Cordasco <sigmaviru...@gmail.com> wrote: > > > > > > > > -----Original Message----- > > From: Thierry Carrez <thie...@openstack.org <mailto:thie...@openstack.org>> > > Reply: OpenStack Development Mailing List (not for usage questions) > > <openstack-dev@lists.openstack.org > > <mailto:openstack-dev@lists.openstack.org>> > > Date: October 18, 2016 at 03:55:41 > > To: openstack-dev@lists.openstack.org > > <mailto:openstack-dev@lists.openstack.org> > > <openstack-dev@lists.openstack.org > > <mailto:openstack-dev@lists.openstack.org>> > > Subject: Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r > > > >> Doug Wiegley wrote: > >>> [...] Paths forward: > >>> > >>> 1. Add gunicorn to global requirements. > >>> > >>> 2. Create a project specific “amphora-requirements.txt” file for the > >>> service VM packages (this is actually my preference.) It has been > >>> pointed out that this wouldn’t be kept up-to-date by the bot. We could > >>> modify the bot to include it in some way, or do it manually, or with a > >>> project specific job. > >>> > >>> 3. Split our service VM builds into another repo, to keep a clean > >>> separation between API services and the backend. But, even this new > >>> repo’s standlone requirements.txt file will have the g-r issue from #1. > >>> > >>> 4. Boot the backend out of OpenStack entirely. > >> > >> All those options sound valid to me, so the requirements team should > >> pick what they are the most comfortable with. > >> > >> My 2c: yes g-r is mostly about runtime dependencies and ensuring > >> co-installability. However it also includes test/build-time deps, and > >> generally converging dependencies overall sounds like a valid goal. Is > >> there any drawback in adding gunicorn to g-r (option 1) ? > > > > The drawback (in my mind) is that new projects might start using it giving > > operators yet another thing to learn about when deploying a new component > > (eventlet, gevent, gunicorn, ...). > > > > On the flip, what's the benefit of adding it to g-r? > > The positive benefit is the same as Octavia’s use case: it provides an > alternative for any non-frontline-api service to run a lightweight http/wsgi > service as needed (service VMs, health monitor agents, etc). And something > better than the built-in debug servers in most of the frameworks. > > On the proliferation point, it is certainly a risk, though I’ve personally > heard pretty strong guidance that all main API services in our community > should be trending towards pecan.
Pecan is a way to build WSGI applications. Gunicorn is a way to deploy them. So they're not mutually exclusive. Doug > > Thanks, > doug > > > > > -- > > Ian Cordasco > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org > > <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > <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
