Open Stack

Yep, I believe we did this in the past when we first started down this path
with Octavia, but we may have been too early -- maybe now is a better time
to do it. I will be at the summit and more than happy to attend a related
meeting.
But, I agree with Doug that we shouldn't stall this because of that -- can
we go ahead and vote the official OpenStack way: comments and +1/-1 on
https://review.openstack.org/#/c/386790/ ? I also feel like commenting
there is a better way to keep track of this discussion for posterity, as
the ML feels much more ephemeral to me. I can always go look up a CR as
it's directly linked to the commit. :)

--Adam

On Wed, Oct 19, 2016 at 3:24 AM Doug Wiegley <dougwig at parksidesoftware.com>
wrote:

> 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> 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 <sigmavirus24 at gmail.com>>> wrote:
>
>
>
> -----Original Message-----
> From: Thierry Carrez <thierry at openstack.org <mailto:thierry at openstack.org
> <thierry at openstack.org>> <mailto:thierry at openstack.org
> <thierry at openstack.org> <mailto:thierry at openstack.org
> <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
> <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
> <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
> <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
> <openstack-dev at lists.openstack.org>>> <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
> <openstack-dev at lists.openstack.org> <
> mailto:openstack-dev at lists.openstack.org
> <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
>
>
>
> 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
> <OpenStack-dev-request at lists.openstack.org>> <
> mailto:OpenStack-dev-request at lists.openstack.org
> <OpenStack-dev-request at lists.openstack.org> <
> mailto:OpenStack-dev-request at lists.openstack.org
> <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
> <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>
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161018/79c0d597/attachment.html>