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) ?

-- 
Thierry Carrez (ttx)

__________________________________________________________________________
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

Reply via email to