On 18/10/2016 19:57, Doug Wiegley wrote: > >> On Oct 18, 2016, at 12:42 PM, Doug Hellmann <d...@doughellmann.com> wrote: >> >> Excerpts from Doug Wiegley's message of 2016-10-18 12:21:20 -0600: >>> >>>> 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 >>>>>> <mailto: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> <mailto: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>> <mailto: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>> >>>>>>>> <mailto: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>> >>>>>>>> <mailto: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>> >>>>>>>> <mailto: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 >>>> >>>> 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 >> >> Sure, and I hope I didn't come across as implying that this work should wait. >> >> I expect you could take over a corner of the dev lounge or some >> other space to hold a BoF to at least start the discussion and get >> some interested folks lined up to lead the WG. > > Sounds good. In prep to sending an ML invite, what projects use service VMs? > There’s Octavia, Trove, and Tacker. What else?
It is in our (long term) road map for Designate as well. > Thanks, > doug > >> >> Doug >> >> __________________________________________________________________________ >> 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
