If there's no objection to us using gunicorn without it being present in
g-r, then I don't know if I want to argue strongly for adding it -- the
only benefit I see to tracking g-r at all is that it lets us continue to
get free version tracking for our amphora dependencies as they are updated
in g-r without having to manually tweak them. Once we go away from using
g-r for our amphora-requirements, our project team has to track these
dependencies manually. Tweaking the requirements bot to look at
amphora-requirements.txt as Doug mentioned won't actually do much, since
the whole point here is that we're including things that aren't in g-r so
there's no source to update them from.
So, does everyone at least agree that it's ok for us to *use* gunicorn
internally on our service-vm image? If so, I'm happy to move forward with
option #2 if it looks like that'll be the path of least resistance. As I
said, options 3 and 4 are not really good solutions to this particular
problem, so in my view we should do whichever is most likely to be accepted
of options 1 or 2.
--Adam
On Tue, Oct 18, 2016 at 8:18 PM Ian Cordasco <sigmaviru...@gmail.com> wrote:
>
>
> -----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
>
__________________________________________________________________________
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
