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):
On Wed, Oct 19, 2016 at 2:05 AM Adam Harwell <flux.a...@gmail.com> wrote:
> Inline comments.
> On Wed, Oct 19, 2016 at 1:38 AM Thomas Goirand <z...@debian.org> wrote:
> On 10/18/2016 02:37 AM, Ian Cordasco wrote:
> > On Oct 17, 2016 7:27 PM, "Thomas Goirand" <z...@debian.org
> > <mailto:z...@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
> >> > 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
> 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?
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
OpenStack Development Mailing List (not for usage questions)