[openstack-dev] [requirements][lbaas] gunicorn to g-r

Doug Hellmann doug at doughellmann.com
Tue Oct 18 18:42:26 UTC 2016


Excerpts from Doug Wiegley's message of 2016-10-18 12:21:20 -0600:
> 
> > On Oct 18, 2016, at 12:10 PM, Doug Hellmann <doug at 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 <doug at doughellmann.com <mailto:doug at 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 <sigmavirus24 at gmail.com <mailto:sigmavirus24 at gmail.com> <mailto:sigmavirus24 at gmail.com <mailto:sigmavirus24 at gmail.com>>> wrote:
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> -----Original Message-----
> >>>>> From: Thierry Carrez <thierry at openstack.org <mailto:thierry at openstack.org> <mailto:thierry at openstack.org <mailto:thierry at openstack.org>> <mailto:thierry at openstack.org <mailto:thierry at openstack.org> <mailto:thierry at openstack.org <mailto:thierry at openstack.org>>>>
> >>>>> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org> <mailto:openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org>> <mailto:openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org> <mailto:openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org>>>>
> >>>>> Date: October 18, 2016 at 03:55:41
> >>>>> To: openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org> <mailto:openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org>> <mailto:openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org> <mailto:openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org>>> <openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org>> <mailto:openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org> <mailto:openstack-dev at lists.openstack.org <mailto:openstack-dev at 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



More information about the OpenStack-dev mailing list