<div dir="ltr">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): <a href="https://review.openstack.org/#/c/386758/12/octavia/cmd/agent.py">https://review.openstack.org/#/c/386758/12/octavia/cmd/agent.py</a><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 19, 2016 at 2:05 AM Adam Harwell <<a href="mailto:flux.adam@gmail.com">flux.adam@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Inline comments.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div dir="ltr" class="gmail_msg">On Wed, Oct 19, 2016 at 1:38 AM Thomas Goirand <<a href="mailto:zigo@debian.org" class="gmail_msg" target="_blank">zigo@debian.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/18/2016 02:37 AM, Ian Cordasco wrote:<br class="gmail_msg">
> On Oct 17, 2016 7:27 PM, "Thomas Goirand" <<a href="mailto:zigo@debian.org" class="gmail_msg" target="_blank">zigo@debian.org</a><br class="gmail_msg">
> <mailto:<a href="mailto:zigo@debian.org" class="gmail_msg" target="_blank">zigo@debian.org</a>>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> On 10/17/2016 08:43 PM, Adam Harwell wrote:<br class="gmail_msg">
>> > Jim, that is exactly my thought -- the main focus of g-r as far as I was<br class="gmail_msg">
>> > aware is to maintain interoperability between project dependencies for<br class="gmail_msg">
>> > openstack deploys, and since our amphora image is totally separate, it<br class="gmail_msg">
>> > should not be restricted to g-r requirements.<br class="gmail_msg">
>><br class="gmail_msg">
>> The fact that we have a unified version number of a given lib in all of<br class="gmail_msg">
>> OpenStack is also because that's a requirement of downstream distros.<br class="gmail_msg">
>><br class="gmail_msg">
>> Imagine that someone would like to build the Octavia image using<br class="gmail_msg">
>> exclusively packages from <your-favorite-distro-here>...<br class="gmail_msg">
>><br class="gmail_msg">
>> > I brought this up, but<br class="gmail_msg">
>> > others thought it would be prudent to go the g-r route anyway.<br class="gmail_msg">
>><br class="gmail_msg">
>> It is, and IMO you should go this route.<br class="gmail_msg">
><br class="gmail_msg">
> I'm not convinced by your arguments here, Thomas. If the distributor<br class="gmail_msg">
> were packaging Octavia for X but the image is using some other operating<br class="gmail_msg">
> system, say Y, why are X's packages relevant?<br class="gmail_msg">
<br class="gmail_msg">
What if operating systems would be the same?<br class="gmail_msg"></blockquote></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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...</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
As a Debian package maintainer, I really prefer if the underlying images<br class="gmail_msg">
can also be Debian (and preferably Debian stable everywhere).<br class="gmail_msg"></blockquote></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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. </div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
> I would think that if this<br class="gmail_msg">
> is something inside an image going to be launched by Octavia that<br class="gmail_msg">
> co-installibilty wouldn't really be an issue.<br class="gmail_msg">
<br class="gmail_msg">
The issue isn't co-instability, but the fact that downstream<br class="gmail_msg">
distribution vendors will only package *ONE* version of a given python<br class="gmail_msg">
module. If we have Octavia with version X, and another component of<br class="gmail_msg">
OpenStack with version Y, then we're stuck with Octavia not being<br class="gmail_msg">
packageable in downstream distros.<br class="gmail_msg"></blockquote></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
> I don't lean either way right now, so I'd really like to understand your<br class="gmail_msg">
> point of view, especially since right now it isn't making much sense to me.<br class="gmail_msg">
<br class="gmail_msg">
Do you understand now? :)<br class="gmail_msg"></blockquote></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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? </div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
Cheers,<br class="gmail_msg">
<br class="gmail_msg">
Thomas<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
__________________________________________________________________________<br class="gmail_msg">
OpenStack Development Mailing List (not for usage questions)<br class="gmail_msg">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" class="gmail_msg" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="gmail_msg">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="gmail_msg">
</blockquote></div></div></blockquote></div>