Open Stack

Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54 -0600:
> 
> > On Oct 18, 2016, at 5:14 AM, Ian Cordasco <sigmavirus24 at gmail.com> wrote:
> > 
> >  
> > 
> > -----Original Message-----
> > From: Thierry Carrez <thierry at openstack.org <mailto:thierry at openstack.org>>
> > Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org>>
> > Date: October 18, 2016 at 03:55:41
> > To: openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org> <openstack-dev at lists.openstack.org <mailto:openstack-dev at 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-request at lists.openstack.org <mailto:OpenStack-dev-request at 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>