Open Stack

-----Original Message-----
From: Thierry Carrez <thierry at openstack.org>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: October 18, 2016 at 03:55:41
To: openstack-dev at lists.openstack.org <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?

--  
Ian Cordasco