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