Adam, Have you see this yet?
http://docs.openstack.org/infra/bindep/readme.html#writing-requirements-files http://codesearch.openstack.org/?q=platform&i=nope&files=bindep.txt&repos= Thanks, Dims On Wed, Oct 19, 2016 at 9:40 AM, Adam Harwell <flux.a...@gmail.com> wrote: > Yes, but we need to use SOMETHING for our own devstack gate tests -- maybe > it is easier to think of our devstack code as a "third party setup", and > that it uses gunicorn for its DIB images (but not every deployer needs to). > In this case, how do we include it? Devstack needs it to run our gate jobs, > which means it has to be in our main codebase, but deployers don't > necessarily need it for their deployments (though it is the default option). > Do we include it in global-requirements or not? How do we use it in devstack > if it is not in global-requirements? We don't install it as a binary because > the plan is to stay completely distro-independant (or target a distro that > doesn't even HAVE binary packages like cirros). Originally I just put the > line "pip install gunicorn>=19.0" directly in our DIB script, but was told > that was a dirty hack, and that it should be in requirements.txt like > everything else. I'm not sure I agree, and it seems like maybe others are > suggesting I go back to that method? > > --Adam > > On Wed, Oct 19, 2016 at 10:19 PM Hayes, Graham <graham.ha...@hpe.com> wrote: >> >> On 18/10/2016 19:57, Doug Wiegley wrote: >> > >> >> 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? >> >> 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-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 >> > >> >> >> __________________________________________________________________________ >> 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 > -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ 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
