[openstack-dev] [requirements][lbaas] gunicorn to g-r

Adam Harwell flux.adam at gmail.com
Tue Oct 18 06:29:35 UTC 2016


Right, and this is totally possible (using a different distro). In fact, it
is *likely* that in the future the amphora image will be based on a minimal
distro and not anything like the distro the rest of OpenStack is deployed
to. Also, given that the amphora image build process uses DIB and installs
gunicorn via pypi, I'm not clear on how distro packages are relevant. Pypi
installs are distro agnostic, and each operator really does *need* to build
their own amphora image for their own cloud for various reasons...

Also also, normally people think of gunicorn as a binary runner, but we are
actually using it as a Python module:
http://docs.gunicorn.org/en/stable/custom.html

As for Doug's options, I'm more in favor of option 1 or 2 (since they
actually solve the problem). Option 3 is something we'd like to do, but
doesn't do anything for this particular dilemma. Option 4 is a bit extreme,
and I think the amphora image should still retain ties to OpenStack. :/

   --Adam

On Tue, Oct 18, 2016, 09:42 Ian Cordasco <sigmavirus24 at gmail.com> wrote:

> On Oct 17, 2016 7:27 PM, "Thomas Goirand" <zigo at debian.org> wrote:
> >
> > On 10/17/2016 08:43 PM, Adam Harwell wrote:
> > > Jim, that is exactly my thought -- the main focus of g-r as far as I
> was
> > > aware is to maintain interoperability between project dependencies for
> > > openstack deploys, and since our amphora image is totally separate, it
> > > should not be restricted to g-r requirements.
> >
> > The fact that we have a unified version number of a given lib in all of
> > OpenStack is also because that's a requirement of downstream distros.
> >
> > Imagine that someone would like to build the Octavia image using
> > exclusively packages from <your-favorite-distro-here>...
> >
> > > I brought this up, but
> > > others thought it would be prudent to go the g-r route anyway.
> >
> > It is, and IMO you should go this route.
>
> I'm not convinced by your arguments here, Thomas. If the distributor were
> packaging Octavia for X but the image is using some other operating system,
> say Y, why are X's packages relevant? I would think that if this is
> something inside an image going to be launched by Octavia that
> co-installibilty wouldn't really be an issue.
>
> I don't lean either way right now, so I'd really like to understand your
> point of view, especially since right now it isn't making much sense to me.
> __________________________________________________________________________
> 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/eb5fd93b/attachment.html>


More information about the OpenStack-dev mailing list