Yep, I believe we did this in the past when we first started down this path with Octavia, but we may have been too early -- maybe now is a better time to do it. I will be at the summit and more than happy to attend a related meeting. But, I agree with Doug that we shouldn't stall this because of that -- can we go ahead and vote the official OpenStack way: comments and +1/-1 on https://review.openstack.org/#/c/386790/ ? I also feel like commenting there is a better way to keep track of this discussion for posterity, as the ML feels much more ephemeral to me. I can always go look up a CR as it's directly linked to the commit. :)
--Adam On Wed, Oct 19, 2016 at 3:24 AM Doug Wiegley <doug...@parksidesoftware.com> wrote: > On Oct 18, 2016, at 12:10 PM, Doug Hellmann <d...@doughellmann.com> wrote: > > Excerpts from Doug Wiegley's message of 2016-10-18 12:00:35 -0600: > > > On Oct 18, 2016, at 11:30 AM, Doug Hellmann <d...@doughellmann.com> wrote: > > Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54 -0600: > > > On Oct 18, 2016, at 5:14 AM, Ian Cordasco <sigmaviru...@gmail.com < > mailto:sigmaviru...@gmail.com <sigmaviru...@gmail.com>>> wrote: > > > > -----Original Message----- > From: Thierry Carrez <thie...@openstack.org <mailto:thie...@openstack.org > <thie...@openstack.org>> <mailto:thie...@openstack.org > <thie...@openstack.org> <mailto:thie...@openstack.org > <thie...@openstack.org>>>> > Reply: OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org < > mailto:openstack-dev@lists.openstack.org > <openstack-dev@lists.openstack.org>> < > mailto:openstack-dev@lists.openstack.org > <openstack-dev@lists.openstack.org> < > mailto:openstack-dev@lists.openstack.org > <openstack-dev@lists.openstack.org>>>> > Date: October 18, 2016 at 03:55:41 > To: openstack-dev@lists.openstack.org < > mailto:openstack-dev@lists.openstack.org > <openstack-dev@lists.openstack.org>> < > mailto:openstack-dev@lists.openstack.org > <openstack-dev@lists.openstack.org> < > mailto:openstack-dev@lists.openstack.org > <openstack-dev@lists.openstack.org>>> <openstack-dev@lists.openstack.org< > mailto:openstack-dev@lists.openstack.org > <openstack-dev@lists.openstack.org>> < > mailto:openstack-dev@lists.openstack.org > <openstack-dev@lists.openstack.org> < > mailto:openstack-dev@lists.openstack.org > <openstack-dev@lists.openstack.org>>>> > Subject: Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r > > Doug Wiegley wrote: > > [...] Paths forward: > > 1. Add gunicorn to global requirements. > > 2. Create a project specific “amphora-requirements.txt” file for the > service VM packages (this is actually my preference.) It has been > pointed out that this wouldn’t be kept up-to-date by the bot. We could > modify the bot to include it in some way, or do it manually, or with a > project specific job. > > 3. Split our service VM builds into another repo, to keep a clean > separation between API services and the backend. But, even this new > repo’s standlone requirements.txt file will have the g-r issue from #1. > > 4. Boot the backend out of OpenStack entirely. > > > All those options sound valid to me, so the requirements team should > pick what they are the most comfortable with. > > My 2c: yes g-r is mostly about runtime dependencies and ensuring > co-installability. However it also includes test/build-time deps, and > generally converging dependencies overall sounds like a valid goal. Is > there any drawback in adding gunicorn to g-r (option 1) ? > > > The drawback (in my mind) is that new projects might start using it giving > operators yet another thing to learn about when deploying a new component > (eventlet, gevent, gunicorn, ...). > > On the flip, what's the benefit of adding it to g-r? > > > The positive benefit is the same as Octavia’s use case: it provides an > alternative for any non-frontline-api service to run a lightweight > http/wsgi service as needed (service VMs, health monitor agents, etc). And > something better than the built-in debug servers in most of the frameworks. > > On the proliferation point, it is certainly a risk, though I’ve personally > heard pretty strong guidance that all main API services in our community > should be trending towards pecan. > > > Pecan is a way to build WSGI applications. Gunicorn is a way to deploy > them. So they're not mutually exclusive. > > > Right, agreed. > > What we’re trying to convey here is: > > - The normal way of making a REST endpoint in OpenStack is to use pecan > (or flask or falcon), and let the deployer or packager worry about the > runtime wsgi and/or reverse proxy. > > - This isn't a “normal” OpenStack endpoint, because it’s a microservice > inside a service VM, and thus has different needs, and is much less likely > to be customized by a non-dev, to boot. And it needs to be “deploy ready” > as a simple matter of it being a service VM black box. It’s part of the > data plane, not the control plane. > > Thanks, > doug > > > That all seems reasonable. > > We have a proliferation of these service VMs. It would be good to > get some of the folks involved together to start a working group > to see if there are some commonalities that can lead to shared > processes or tools. > > > That’s a good idea. I wonder if we can organize something in time for next > week. I don’t think we should wait to make forward progress for that, but > there is definitely some commonality we should be defining and striving > towards. > > doug > > > > Doug > > > > Doug > > > Thanks, > doug > > > -- > Ian Cordasco > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org < > mailto:openstack-dev-requ...@lists.openstack.org > <openstack-dev-requ...@lists.openstack.org>> < > mailto:openstack-dev-requ...@lists.openstack.org > <openstack-dev-requ...@lists.openstack.org> < > mailto:openstack-dev-requ...@lists.openstack.org > <openstack-dev-requ...@lists.openstack.org>>>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev < > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> < > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev < > 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 < > mailto:openstack-dev-requ...@lists.openstack.org > <openstack-dev-requ...@lists.openstack.org>>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev < > 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 > > __________________________________________________________________________ > 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
