Open Stack

> On Oct 18, 2016, at 11:30 AM, Doug Hellmann <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>> 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>>>
>>> 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>>>
>>> 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>> <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

> 
> Doug
> 
>> 
>> Thanks,
>> doug
>> 
>>> 
>>> --  
>>> Ian Cordasco
>>> 
>>> 
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org <mailto:OpenStack-dev-request at lists.openstack.org> <mailto:OpenStack-dev-request at lists.openstack.org <mailto:OpenStack-dev-request at 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-request at lists.openstack.org <mailto:OpenStack-dev-request at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161018/0e573380/attachment.html>