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

Adam Harwell flux.adam at gmail.com
Tue Oct 18 17:07:26 UTC 2016


For the record, it might help if people actually look at how we're
proposing to use the gunicorn python module (remember, this code is
executing inside a *service VM*, not on the main control plane):
https://review.openstack.org/#/c/386758/12/octavia/cmd/agent.py


On Wed, Oct 19, 2016 at 2:05 AM Adam Harwell <flux.adam at gmail.com> wrote:

> Inline comments.
>
> On Wed, Oct 19, 2016 at 1:38 AM Thomas Goirand <zigo at debian.org> wrote:
>
> On 10/18/2016 02:37 AM, Ian Cordasco wrote:
> > On Oct 17, 2016 7:27 PM, "Thomas Goirand" <zigo at debian.org
> > <mailto: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?
>
> What if operating systems would be the same?
>
> We still want to install from pypi, because we still want deployers to
> build images for their cloud using our DIB elements. There is absolutely no
> situation in which I can imagine we'd want to install a binary packaged
> version of this. There's a VERY high chance we will soon be using a distro
> that isn't even a supported OpenStack deploy target...
>
>
> As a Debian package maintainer, I really prefer if the underlying images
> can also be Debian (and preferably Debian stable everywhere).
>
> Sure, I love Debian too, but we're investigating things like Alpine and
> Cirros as our base image, and there's pretty much zero chance anyone will
> package ANY of our deps for those distros. Cirros doesn't even have a
> package manager AFAIK.
>
>
> > 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.
>
> The issue isn't co-instability, but the fact that downstream
> distribution vendors will only package *ONE* version of a given python
> module. If we have Octavia with version X, and another component of
> OpenStack with version Y, then we're stuck with Octavia not being
> packageable in downstream distros.
>
> Octavia will not use gunicorn for its main OpenStack API layer. It will
> continue to be packagable regardless of whether gunicorn is available.
> Gunicorn is used for our *amphora image*, which is not part of the main
> deployment layer. It is part of our *dataplane*. It is unrelated to any
> part of Octavia that is deployed as part of the main service layer of
> Openstack. In fact, in production, deployers may completely ignore gunicorn
> altogether and use a different solution, that is up to the way they build
> their amphora image (which, again, is not part of the main deployment). We
> just use gunicorn in the image we use for our gate tests.
>
>
> > 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.
>
> Do you understand now? :)
>
> I see what you are saying, but I assert it does not apply to our case at
> all. Do you see how our case is different?
>
>
> Cheers,
>
> Thomas
>
>
> __________________________________________________________________________
> 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/b49589d0/attachment-0001.html>


More information about the OpenStack-dev mailing list