> 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)
> <firstname.lastname@example.org <mailto:email@example.com>>
> Date: October 18, 2016 at 03:55:41
> To: firstname.lastname@example.org
> <mailto:email@example.com> <firstname.lastname@example.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.
> Ian Cordasco
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org
OpenStack Development Mailing List (not for usage questions)