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