> 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


> 
> Doug
> 
>> 
>>> 
>>> Doug
>>> 
>>>> 
>>>> Thanks,
>>>> doug
>>>> 
>>>>> 
>>>>> --  
>>>>> Ian Cordasco
>>>>> 
>>>>> 
>>>>> __________________________________________________________________________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
>>>>> <mailto:openstack-dev-requ...@lists.openstack.org> 
>>>>> <mailto:openstack-dev-requ...@lists.openstack.org 
>>>>> <mailto:openstack-dev-requ...@lists.openstack.org>> 
>>>>> <mailto:openstack-dev-requ...@lists.openstack.org 
>>>>> <mailto:openstack-dev-requ...@lists.openstack.org> 
>>>>> <mailto:openstack-dev-requ...@lists.openstack.org 
>>>>> <mailto:openstack-dev-requ...@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>> 
>>>>> <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-requ...@lists.openstack.org 
>>> <mailto:openstack-dev-requ...@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>
> 
> __________________________________________________________________________
> 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