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

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

Reply via email to