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

Hayes, Graham graham.hayes at hpe.com
Wed Oct 19 13:14:19 UTC 2016


On 18/10/2016 19:57, Doug Wiegley wrote:
>
>> On Oct 18, 2016, at 12:42 PM, Doug Hellmann <doug at 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 <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.
>
> Sounds good. In prep to sending an ML invite, what projects use service VMs?   There’s Octavia, Trove, and Tacker.  What else?

It is in our (long term) road map for Designate as well.

> Thanks,
> doug
>
>>
>> Doug
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>




More information about the OpenStack-dev mailing list