> 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>> wrote: >>> >>> >>> >>> -----Original Message----- >>> From: Thierry Carrez <thie...@openstack.org <mailto:thie...@openstack.org> >>> <mailto:thie...@openstack.org <mailto:thie...@openstack.org>>> >>> Reply: OpenStack Development Mailing List (not for usage questions) >>> <openstack-dev@lists.openstack.org >>> <mailto:openstack-dev@lists.openstack.org> >>> <mailto:openstack-dev@lists.openstack.org >>> <mailto: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> >>> <mailto:openstack-dev@lists.openstack.org >>> <mailto:openstack-dev@lists.openstack.org>> >>> <openstack-dev@lists.openstack.org >>> <mailto:openstack-dev@lists.openstack.org> >>> <mailto:openstack-dev@lists.openstack.org >>> <mailto: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 > > 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> >>> <mailto:openstack-dev-requ...@lists.openstack.org >>> <mailto: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>?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
