We literally install every other dependency from pypi with requirements.txt, so I'm struggling understand why all the sudden we need to install this one as a binary, for our devstack specific script, when we are planning a move to a distro that doesn't even support binary packages? Should we switch our entire requirements file to bindep? If not, what makes this different?
On Wed, Oct 19, 2016, 22:56 Davanum Srinivas <dava...@gmail.com> wrote: > 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 >
__________________________________________________________________________ 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