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.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 > 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-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