Open Stack

We really don't want bindep IMO -- it's much safer to use the non-packaged
version from pypi for our purposes, since we may not be running on a system
that packages things like this. Again, our use case may be strange though,
as we're really using the python module and not the binaries.

--Adam

On Wed, Oct 19, 2016 at 1:07 AM Doug Wiegley <dougwig at parksidesoftware.com>
wrote:

> On Oct 18, 2016, at 5:14 AM, Ian Cordasco <sigmavirus24 at gmail.com> wrote:
>
>
>
> -----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?
>
>
> 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.
>
> Thanks,
> doug
>
>
> --
> Ian Cordasco
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161018/946d0c8b/attachment.html>