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

2016-10-19 Thread Davanum Srinivas
;>>>>> <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
>>> >> &g

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

2016-10-19 Thread Adam Harwell
elopment 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> 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
> >> >>>&

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

2016-10-19 Thread Adam Harwell
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=nope=bindep.txt=
>
> 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>
> >> >>>>>&

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

2016-10-19 Thread Ian Cordasco
-Original Message-
From: Adam Harwell <flux.a...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: October 19, 2016 at 08:44:31
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

> 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

I'm still not clear as to why Tony isn't in favor of this. No one really has 
clear technical objects to gunicorn itself. It's maintained, up-to-date, and 
reliable (even if not the de facto OpenStack choice for running an OpenSack 
service ... which you're not doing).

I would agree that having it in g-r and in your requirements.txt makes the most 
sense. Especially since Monty did an excellent job explaining why not everyone 
will want to use pip+Aline/cirros. In my opinion, we just need to understand 
why people are still opposed to this being in g-r and your requirements.txt so 
that you can move along.
--  
Ian Cordasco


__
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


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

2016-10-19 Thread Davanum Srinivas
Adam,

Have you see this yet?

http://docs.openstack.org/infra/bindep/readme.html#writing-requirements-files
http://codesearch.openstack.org/?q=platform=nope=bindep.txt=

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
>

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

2016-10-19 Thread Adam Harwell
To reply more directly and clearly:

On Wed, Oct 19, 2016 at 9:30 PM Tony Breeds  wrote:

> On Wed, Oct 19, 2016 at 08:41:16AM +, Adam Harwell wrote:
> > I wonder if maybe it is not clear -- for us, gunicorn is a runtime
> > dependency for our gate jobs to work, not a deploy dependency.
>
> Okay then frankly I'm deeply confused.
>
> Can we see the code that uses it? to understand why the deployer can't
> build a
> custom service VM using an alternative to gunicorn?
>
A deployer is perfectly free to use an alternative to gunicorn. Gunicorn is
built into our devstack plugin code, not the main agent application
(agent.py is just the runner we created for devstack -- you could run
octavia.amphorae.backends.agent.api_server with any WSGI runner you want in
a real deployment). We just have to use SOMETHING in devstack for our gate
scenario tests to run...

>
> Yours Tony.
> __
> 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


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

2016-10-19 Thread Adam Harwell
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  sigmaviru...@gmail.com>>> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> -Original Message-
> >>>>>>>> From: Thierry Carrez <thie...@openstack.org  thie...@openstack.org> <mailto:thie...@openstack.org  thie...@openstack.org>> <mailto:thie...@openstack.org  thie...@openstack.org> <mailto:thie...@openstack.org  thie...@openstack.org>>>>
> >>>>>>>> Reply: OpenStack Development Mailing List (not for usage
> questions) <openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>  openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>>  openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>  openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>>>>
> >>>>>>>> Date: October 18, 2016 at 03:55:41
> >>>>>>>> To: openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>  openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>>  openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>  openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>>> <openstack-dev@lists.openstack.org
> <mailto:openstack-dev@lists.openstack.org> openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>>  openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org>  openstack-dev@lists.openstack.org  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

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

2016-10-19 Thread Hayes, Graham
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
>>>>>>>>>&g

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

2016-10-19 Thread Thomas Goirand
On 10/18/2016 08:25 PM, Monty Taylor wrote:
> On 10/18/2016 12:05 PM, Adam Harwell wrote:
>> Inline comments.
>>
>> On Wed, Oct 19, 2016 at 1:38 AM Thomas Goirand > > wrote:
>>
>> On 10/18/2016 02:37 AM, Ian Cordasco wrote:
>> > On Oct 17, 2016 7:27 PM, "Thomas Goirand" > 
>> > >> wrote:
>> >>
>> >> On 10/17/2016 08:43 PM, Adam Harwell wrote:
>> >> > Jim, that is exactly my thought -- the main focus of g-r as far
>> as I was
>> >> > aware is to maintain interoperability between project
>> dependencies for
>> >> > openstack deploys, and since our amphora image is totally
>> separate, it
>> >> > should not be restricted to g-r requirements.
>> >>
>> >> The fact that we have a unified version number of a given lib in
>> all of
>> >> OpenStack is also because that's a requirement of downstream distros.
>> >>
>> >> Imagine that someone would like to build the Octavia image using
>> >> exclusively packages from ...
>> >>
>> >> > I brought this up, but
>> >> > others thought it would be prudent to go the g-r route anyway.
>> >>
>> >> It is, and IMO you should go this route.
>> >
>> > I'm not convinced by your arguments here, Thomas. If the distributor
>> > were packaging Octavia for X but the image is using some other
>> operating
>> > system, say Y, why are X's packages relevant?
>>
>> What if operating systems would be the same?
>>
>> We still want to install from pypi, because we still want deployers to
>> build images for their cloud using our DIB elements. There is absolutely
>> no situation in which I can imagine we'd want to install a binary
>> packaged version of this. There's a VERY high chance we will soon be
>> using a distro that isn't even a supported OpenStack deploy target...
>>
>>
>> As a Debian package maintainer, I really prefer if the underlying images
>> can also be Debian (and preferably Debian stable everywhere).
>>
>> Sure, I love Debian too, but we're investigating things like Alpine and
>> Cirros as our base image, and there's pretty much zero chance anyone
>> will package ANY of our deps for those distros. Cirros doesn't even have
>> a package manager AFAIK. 
>>
>>
>> > I would think that if this
>> > is something inside an image going to be launched by Octavia that
>> > co-installibilty wouldn't really be an issue.
>>
>> The issue isn't co-instability, but the fact that downstream
>> distribution vendors will only package *ONE* version of a given python
>> module. If we have Octavia with version X, and another component of
>> OpenStack with version Y, then we're stuck with Octavia not being
>> packageable in downstream distros.
>>
>> Octavia will not use gunicorn for its main OpenStack API layer. It will
>> continue to be packagable regardless of whether gunicorn is available.
>> Gunicorn is used for our *amphora image*, which is not part of the main
>> deployment layer. It is part of our *dataplane*. It is unrelated to any
>> part of Octavia that is deployed as part of the main service layer of
>> Openstack. In fact, in production, deployers may completely ignore
>> gunicorn altogether and use a different solution, that is up to the way
>> they build their amphora image (which, again, is not part of the main
>> deployment). We just use gunicorn in the image we use for our gate tests.
>>
>>
>> > I don't lean either way right now, so I'd really like to
>> understand your
>> > point of view, especially since right now it isn't making much
>> sense to me.
>>
>> Do you understand now? :)
>>
>> I see what you are saying, but I assert it does not apply to our case at
>> all. Do you see how our case is different? 
> 
> I totally understand, and I can see why it would seem very different.
> Consider a few things though:
> 
> - OpenStack tries its best to not pick favorites for OS, and I think the
> same applies to guest VMs, even if they just seem like appliances. While
> we as upstream may be looking at using something like alpine as the base
> OS for the service VM appliance, that does not necessarily imply that
> all deployers _must_ use Alpine in their service VM, for exactly the
> reason you mention (you intend for them to run diskimage-builder themselves)
> 
> - If a deployer happens to have a strong preference for a given OS (I
> know I've been on customer calls where an OpenStack product having a tie
> to a particular OS that is not the one that is in the vetted choice
> otherwise at that customer was an issue) - then the use of dib by the
> deployer allows them to choose to base their service VM on the OS of
> their choice. That's pretty awesome.
> 
> - If that deployer similarly has an aversion to deploying any software
> that didn't come from distro packages, one could 

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

2016-10-19 Thread Thomas Goirand
On 10/18/2016 07:05 PM, Adam Harwell wrote:
> What if operating systems would be the same?
> 
> We still want to install from pypi, because we still want deployers to
> build images for their cloud using our DIB elements. There is absolutely
> no situation in which I can imagine we'd want to install a binary
> packaged version of this. There's a VERY high chance we will soon be
> using a distro that isn't even a supported OpenStack deploy target...
> 
> 
> As a Debian package maintainer, I really prefer if the underlying images
> can also be Debian (and preferably Debian stable everywhere).
> 
> Sure, I love Debian too, but we're investigating things like Alpine and
> Cirros as our base image, and there's pretty much zero chance anyone
> will package ANY of our deps for those distros. Cirros doesn't even have
> a package manager AFAIK. 

YOUR preference may not be the same as the ones deploying. For example,
if I was to deploy, I'd prefer if all components where from a single
distribution vendor, even if the image gets bigger at the end. It is
easier to address security vulnerabilities this way (ie: you only need
to watch for a single vendor updates).

Cheers,

Thomas Goirand (zigo)


__
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


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

2016-10-19 Thread Tony Breeds
On Wed, Oct 19, 2016 at 11:26:51PM +1100, Tony Breeds wrote:
> On Wed, Oct 19, 2016 at 08:41:16AM +, Adam Harwell wrote:
> > I wonder if maybe it is not clear -- for us, gunicorn is a runtime
> > dependency for our gate jobs to work, not a deploy dependency.
> 
> Okay then frankly I'm deeply confused.
> 
> Can we see the code that uses it? to understand why the deployer can't build a
> custom service VM using an alternative to gunicorn?

And then of course I'm pointed at https://review.openstack.org/#/c/386758

Yours Tony.


signature.asc
Description: PGP signature
__
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


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

2016-10-19 Thread Tony Breeds
On Wed, Oct 19, 2016 at 08:41:16AM +, Adam Harwell wrote:
> I wonder if maybe it is not clear -- for us, gunicorn is a runtime
> dependency for our gate jobs to work, not a deploy dependency.

Okay then frankly I'm deeply confused.

Can we see the code that uses it? to understand why the deployer can't build a
custom service VM using an alternative to gunicorn?

Yours Tony.


signature.asc
Description: PGP signature
__
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


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

2016-10-19 Thread Adam Harwell
I wonder if maybe it is not clear -- for us, gunicorn is a runtime
dependency for our gate jobs to work, not a deploy dependency.

On Wed, Oct 19, 2016, 11:16 Tony Breeds  wrote:

> On Mon, Oct 17, 2016 at 08:12:45PM -0600, Doug Wiegley wrote:
>
> > Right, so, we’re dancing around the common problem in openstack lately:
> what
> > the heck is openstack?
>
> Sorry to get here so late.
>
> > This came up because service VMs/data plane implementations, which this
> is,
> > have different requirements than API services. Paths forward:
> >
> > 1. Add gunicorn to global requirements.
>
> I'd rather avoid this.  Other have done a great job explaining the runtime
> vs
> deploy dependencies.
>
> > 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.
>
> Actually Options 2 and 3 are functionally the same (from my POV).  We'd
> need a
> specific job to update your *requirements.txt files.  I feel like a
> separate
> repo is slightly neater but it has the most impact on the Octavia team.
>
> So I'd suggest you go with one of 2 or 3 and we can work together to make
> the
> tools work with you.
>
> > 4. Boot the backend out of OpenStack entirely.
>
> :(  I really hope this was a joke suggestion.  If it isn't then we have
> some
> problems in our community / tools :(
>
> Yours Tony.
> __
> 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


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

2016-10-18 Thread Tony Breeds
On Mon, Oct 17, 2016 at 08:12:45PM -0600, Doug Wiegley wrote:

> Right, so, we’re dancing around the common problem in openstack lately: what
> the heck is openstack?

Sorry to get here so late.

> This came up because service VMs/data plane implementations, which this is,
> have different requirements than API services. Paths forward:
> 
> 1. Add gunicorn to global requirements.

I'd rather avoid this.  Other have done a great job explaining the runtime vs
deploy dependencies.

> 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.

Actually Options 2 and 3 are functionally the same (from my POV).  We'd need a
specific job to update your *requirements.txt files.  I feel like a separate
repo is slightly neater but it has the most impact on the Octavia team.

So I'd suggest you go with one of 2 or 3 and we can work together to make the
tools work with you.

> 4. Boot the backend out of OpenStack entirely.

:(  I really hope this was a joke suggestion.  If it isn't then we have some
problems in our community / tools :(

Yours Tony.


signature.asc
Description: PGP signature
__
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


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

2016-10-18 Thread Tom Barron


On 10/18/2016 03:56 PM, Doug Hellmann wrote:
> Excerpts from Doug Wiegley's message of 2016-10-18 12:53:18 -0600:
>>
>>> On Oct 18, 2016, at 12:42 PM, Doug Hellmann  wrote:
>>>
>>> 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?
> 
> You hit the main ones I was thinking of. Maybe also Sahara and Magnum?

Manila

> 
> 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


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

2016-10-18 Thread Doug Hellmann
Excerpts from Doug Wiegley's message of 2016-10-18 12:53:18 -0600:
> 
> > On Oct 18, 2016, at 12:42 PM, Doug Hellmann  wrote:
> >
> > 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?

You hit the main ones I was thinking of. Maybe also Sahara and Magnum?

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


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

2016-10-18 Thread Doug Wiegley

> 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.
>>>>>>>> 

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

2016-10-18 Thread Doug Hellmann
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
>

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

2016-10-18 Thread Adam Harwell
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 <doug...@parksidesoftware.com>
wrote:

> 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> 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 <sigmaviru...@gmail.com>>> wrote:
>
>
>
> -Original Message-
> From: Thierry Carrez <thie...@openstack.org <mailto:thie...@openstack.org
> <thie...@openstack.org>> <mailto:thie...@openstack.org
> <thie...@openstack.org> <mailto:thie...@openstack.org
> <thie...@openstack.org>>>>
> Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org <
> mailto:openstack-dev@lists.openstack.org
> <openstack-dev@lists.openstack.org>> <
> mailto:openstack-dev@lists.openstack.org
> <openstack-dev@lists.openstack.org> <
> mailto:openstack-dev@lists.openstack.org
> <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
> <openstack-dev@lists.openstack.org>> <
> mailto:openstack-dev@lists.openstack.org
> <openstack-dev@lists.openstack.org> <
> mailto:openstack-dev@lists.openstack.org
> <openstack-dev@lists.openstack.org>>> <openstack-dev@lists.openstack.org<
> mailto:openstack-dev@lists.openstack.org
> <openstack-dev@lists.openstack.org>> <
> mailto:openstack-dev@lists.openstack.org
> <openstack-dev@lists.openstack.org> <
> mailto:openstack-dev@lists.openstack.org
> <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 endpoi

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

2016-10-18 Thread Monty Taylor
On 10/18/2016 12:05 PM, Adam Harwell wrote:
> Inline comments.
> 
> On Wed, Oct 19, 2016 at 1:38 AM Thomas Goirand  > wrote:
> 
> On 10/18/2016 02:37 AM, Ian Cordasco wrote:
> > On Oct 17, 2016 7:27 PM, "Thomas Goirand"  
> > >> wrote:
> >>
> >> On 10/17/2016 08:43 PM, Adam Harwell wrote:
> >> > Jim, that is exactly my thought -- the main focus of g-r as far
> as I was
> >> > aware is to maintain interoperability between project
> dependencies for
> >> > openstack deploys, and since our amphora image is totally
> separate, it
> >> > should not be restricted to g-r requirements.
> >>
> >> The fact that we have a unified version number of a given lib in
> all of
> >> OpenStack is also because that's a requirement of downstream distros.
> >>
> >> Imagine that someone would like to build the Octavia image using
> >> exclusively packages from ...
> >>
> >> > I brought this up, but
> >> > others thought it would be prudent to go the g-r route anyway.
> >>
> >> It is, and IMO you should go this route.
> >
> > I'm not convinced by your arguments here, Thomas. If the distributor
> > were packaging Octavia for X but the image is using some other
> operating
> > system, say Y, why are X's packages relevant?
> 
> What if operating systems would be the same?
> 
> We still want to install from pypi, because we still want deployers to
> build images for their cloud using our DIB elements. There is absolutely
> no situation in which I can imagine we'd want to install a binary
> packaged version of this. There's a VERY high chance we will soon be
> using a distro that isn't even a supported OpenStack deploy target...
> 
> 
> As a Debian package maintainer, I really prefer if the underlying images
> can also be Debian (and preferably Debian stable everywhere).
> 
> Sure, I love Debian too, but we're investigating things like Alpine and
> Cirros as our base image, and there's pretty much zero chance anyone
> will package ANY of our deps for those distros. Cirros doesn't even have
> a package manager AFAIK. 
> 
> 
> > I would think that if this
> > is something inside an image going to be launched by Octavia that
> > co-installibilty wouldn't really be an issue.
> 
> The issue isn't co-instability, but the fact that downstream
> distribution vendors will only package *ONE* version of a given python
> module. If we have Octavia with version X, and another component of
> OpenStack with version Y, then we're stuck with Octavia not being
> packageable in downstream distros.
> 
> Octavia will not use gunicorn for its main OpenStack API layer. It will
> continue to be packagable regardless of whether gunicorn is available.
> Gunicorn is used for our *amphora image*, which is not part of the main
> deployment layer. It is part of our *dataplane*. It is unrelated to any
> part of Octavia that is deployed as part of the main service layer of
> Openstack. In fact, in production, deployers may completely ignore
> gunicorn altogether and use a different solution, that is up to the way
> they build their amphora image (which, again, is not part of the main
> deployment). We just use gunicorn in the image we use for our gate tests.
> 
> 
> > I don't lean either way right now, so I'd really like to
> understand your
> > point of view, especially since right now it isn't making much
> sense to me.
> 
> Do you understand now? :)
> 
> I see what you are saying, but I assert it does not apply to our case at
> all. Do you see how our case is different? 

I totally understand, and I can see why it would seem very different.
Consider a few things though:

- OpenStack tries its best to not pick favorites for OS, and I think the
same applies to guest VMs, even if they just seem like appliances. While
we as upstream may be looking at using something like alpine as the base
OS for the service VM appliance, that does not necessarily imply that
all deployers _must_ use Alpine in their service VM, for exactly the
reason you mention (you intend for them to run diskimage-builder themselves)

- If a deployer happens to have a strong preference for a given OS (I
know I've been on customer calls where an OpenStack product having a tie
to a particular OS that is not the one that is in the vetted choice
otherwise at that customer was an issue) - then the use of dib by the
deployer allows them to choose to base their service VM on the OS of
their choice. That's pretty awesome.

- If that deployer similarly has an aversion to deploying any software
that didn't come from distro packages, one could imagine that they would
want their diskimage-builder run to install the python code not from pip
but instead from apt/dnf/zypper. There is obviously nothing 

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

2016-10-18 Thread Doug Wiegley

> 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 abo

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

2016-10-18 Thread Doug Hellmann
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> 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>> wrote:
> >>> 
> >>> 
> >>> 
> >>> -Original Message-
> >>> From: Thierry Carrez <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>>>
> >>> 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>> 
> >>> <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 “dep

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

2016-10-18 Thread Doug Wiegley

> On Oct 18, 2016, at 11:30 AM, Doug Hellmann <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>> wrote:
>>> 
>>> 
>>> 
>>> -Original Message-
>>> From: Thierry Carrez <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>>>
>>> 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>> 
>>> <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

> 
> Doug
> 
>> 
>> Thanks,
>> doug
>> 
>>> 
>>> --  
>>> Ian Cordasco
>>> 
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@

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

2016-10-18 Thread Doug Hellmann
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> wrote:
> > 
> >  
> > 
> > -Original Message-
> > From: Thierry Carrez <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>>
> > Date: October 18, 2016 at 03:55:41
> > To: openstack-dev@lists.openstack.org 
> > <mailto:openstack-dev@lists.openstack.org> 
> > <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.

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>?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


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

2016-10-18 Thread Adam Harwell
For the record, it might help if people actually look at how we're
proposing to use the gunicorn python module (remember, this code is
executing inside a *service VM*, not on the main control plane):
https://review.openstack.org/#/c/386758/12/octavia/cmd/agent.py


On Wed, Oct 19, 2016 at 2:05 AM Adam Harwell  wrote:

> Inline comments.
>
> On Wed, Oct 19, 2016 at 1:38 AM Thomas Goirand  wrote:
>
> On 10/18/2016 02:37 AM, Ian Cordasco wrote:
> > On Oct 17, 2016 7:27 PM, "Thomas Goirand"  > > wrote:
> >>
> >> On 10/17/2016 08:43 PM, Adam Harwell wrote:
> >> > Jim, that is exactly my thought -- the main focus of g-r as far as I
> was
> >> > aware is to maintain interoperability between project dependencies for
> >> > openstack deploys, and since our amphora image is totally separate, it
> >> > should not be restricted to g-r requirements.
> >>
> >> The fact that we have a unified version number of a given lib in all of
> >> OpenStack is also because that's a requirement of downstream distros.
> >>
> >> Imagine that someone would like to build the Octavia image using
> >> exclusively packages from ...
> >>
> >> > I brought this up, but
> >> > others thought it would be prudent to go the g-r route anyway.
> >>
> >> It is, and IMO you should go this route.
> >
> > I'm not convinced by your arguments here, Thomas. If the distributor
> > were packaging Octavia for X but the image is using some other operating
> > system, say Y, why are X's packages relevant?
>
> What if operating systems would be the same?
>
> We still want to install from pypi, because we still want deployers to
> build images for their cloud using our DIB elements. There is absolutely no
> situation in which I can imagine we'd want to install a binary packaged
> version of this. There's a VERY high chance we will soon be using a distro
> that isn't even a supported OpenStack deploy target...
>
>
> As a Debian package maintainer, I really prefer if the underlying images
> can also be Debian (and preferably Debian stable everywhere).
>
> Sure, I love Debian too, but we're investigating things like Alpine and
> Cirros as our base image, and there's pretty much zero chance anyone will
> package ANY of our deps for those distros. Cirros doesn't even have a
> package manager AFAIK.
>
>
> > I would think that if this
> > is something inside an image going to be launched by Octavia that
> > co-installibilty wouldn't really be an issue.
>
> The issue isn't co-instability, but the fact that downstream
> distribution vendors will only package *ONE* version of a given python
> module. If we have Octavia with version X, and another component of
> OpenStack with version Y, then we're stuck with Octavia not being
> packageable in downstream distros.
>
> Octavia will not use gunicorn for its main OpenStack API layer. It will
> continue to be packagable regardless of whether gunicorn is available.
> Gunicorn is used for our *amphora image*, which is not part of the main
> deployment layer. It is part of our *dataplane*. It is unrelated to any
> part of Octavia that is deployed as part of the main service layer of
> Openstack. In fact, in production, deployers may completely ignore gunicorn
> altogether and use a different solution, that is up to the way they build
> their amphora image (which, again, is not part of the main deployment). We
> just use gunicorn in the image we use for our gate tests.
>
>
> > I don't lean either way right now, so I'd really like to understand your
> > point of view, especially since right now it isn't making much sense to
> me.
>
> Do you understand now? :)
>
> I see what you are saying, but I assert it does not apply to our case at
> all. Do you see how our case is different?
>
>
> Cheers,
>
> Thomas
>
>
> __
> 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


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

2016-10-18 Thread Adam Harwell
Inline comments.

On Wed, Oct 19, 2016 at 1:38 AM Thomas Goirand  wrote:

> On 10/18/2016 02:37 AM, Ian Cordasco wrote:
> > On Oct 17, 2016 7:27 PM, "Thomas Goirand"  > > wrote:
> >>
> >> On 10/17/2016 08:43 PM, Adam Harwell wrote:
> >> > Jim, that is exactly my thought -- the main focus of g-r as far as I
> was
> >> > aware is to maintain interoperability between project dependencies for
> >> > openstack deploys, and since our amphora image is totally separate, it
> >> > should not be restricted to g-r requirements.
> >>
> >> The fact that we have a unified version number of a given lib in all of
> >> OpenStack is also because that's a requirement of downstream distros.
> >>
> >> Imagine that someone would like to build the Octavia image using
> >> exclusively packages from ...
> >>
> >> > I brought this up, but
> >> > others thought it would be prudent to go the g-r route anyway.
> >>
> >> It is, and IMO you should go this route.
> >
> > I'm not convinced by your arguments here, Thomas. If the distributor
> > were packaging Octavia for X but the image is using some other operating
> > system, say Y, why are X's packages relevant?
>
> What if operating systems would be the same?
>
We still want to install from pypi, because we still want deployers to
build images for their cloud using our DIB elements. There is absolutely no
situation in which I can imagine we'd want to install a binary packaged
version of this. There's a VERY high chance we will soon be using a distro
that isn't even a supported OpenStack deploy target...

>
> As a Debian package maintainer, I really prefer if the underlying images
> can also be Debian (and preferably Debian stable everywhere).
>
Sure, I love Debian too, but we're investigating things like Alpine and
Cirros as our base image, and there's pretty much zero chance anyone will
package ANY of our deps for those distros. Cirros doesn't even have a
package manager AFAIK.

>
> > I would think that if this
> > is something inside an image going to be launched by Octavia that
> > co-installibilty wouldn't really be an issue.
>
> The issue isn't co-instability, but the fact that downstream
> distribution vendors will only package *ONE* version of a given python
> module. If we have Octavia with version X, and another component of
> OpenStack with version Y, then we're stuck with Octavia not being
> packageable in downstream distros.
>
Octavia will not use gunicorn for its main OpenStack API layer. It will
continue to be packagable regardless of whether gunicorn is available.
Gunicorn is used for our *amphora image*, which is not part of the main
deployment layer. It is part of our *dataplane*. It is unrelated to any
part of Octavia that is deployed as part of the main service layer of
Openstack. In fact, in production, deployers may completely ignore gunicorn
altogether and use a different solution, that is up to the way they build
their amphora image (which, again, is not part of the main deployment). We
just use gunicorn in the image we use for our gate tests.

>
> > I don't lean either way right now, so I'd really like to understand your
> > point of view, especially since right now it isn't making much sense to
> me.
>
> Do you understand now? :)
>
I see what you are saying, but I assert it does not apply to our case at
all. Do you see how our case is different?

>
> Cheers,
>
> Thomas
>
>
> __
> 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


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

2016-10-18 Thread Doug Wiegley

> On Oct 18, 2016, at 10:41 AM, Thomas Goirand  wrote:
> 
> On 10/18/2016 02:44 AM, Morgan Fainberg wrote:
>> For the record uwsgi was not (at least at one point) allowed in g-r as
>> it was not a "runtime dependency" it was to be installed more like
>> apache mod_wsgi at the time. Gunicorn could fall into the same category,
>> it is meant to be used in conjunction with the runtime but not be a hard
>> requirement for the runtime itself.
> 
> Except that it can be used as a python module.
> 
> If it's only a "binary runner", then I don't think we even need to care,
> as we could replace it by apache or uwsgi, and it's an implementation
> detail that could even be left to package maintainers (I don't know the
> exact details of Octavia here though…).

This is for Octavia’s service VM image, not it’s mainline API service (which 
uses pecan and all the normal stuff.)

It’s true that packagers can create their own service VM images, and run 
whatever they like, but we must do something for the ref implementation that 
runs in the gate. And at present, we’ve chosen gunicorn, because the built-in 
server in flask is flaky in our CI tests.

doug


> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> 
> __
> 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


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

2016-10-18 Thread Chris Dent

On Tue, 18 Oct 2016, Matthew Thode wrote:


On 10/18/2016 11:25 AM, Adam Harwell wrote:

We really don't want bindep IMO -- it's much safer to use the
non-packaged version from pypi for our purposes, since we may not be
running on a system that packages things like this. Again, our use case
may be strange though, as we're really using the python module and not
the binaries.

--Adam


Is there a reason you are not using pecan?


There seems to be some confusion here. pecan is a WSGI application
framework (that uses object dispatch as its conceptual model).
gunicorn is a WSGI server.

One could, if one wanted, hosted a pecan based application with
gunicorn. Or uwsgi. Or apache+mod_wsgi. Or nginx+uwsgi. Or a bunch
of other stuff.

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
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


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

2016-10-18 Thread Thomas Goirand
On 10/18/2016 02:44 AM, Morgan Fainberg wrote:
> For the record uwsgi was not (at least at one point) allowed in g-r as
> it was not a "runtime dependency" it was to be installed more like
> apache mod_wsgi at the time. Gunicorn could fall into the same category,
> it is meant to be used in conjunction with the runtime but not be a hard
> requirement for the runtime itself.

Except that it can be used as a python module.

If it's only a "binary runner", then I don't think we even need to care,
as we could replace it by apache or uwsgi, and it's an implementation
detail that could even be left to package maintainers (I don't know the
exact details of Octavia here though...).

Cheers,

Thomas Goirand (zigo)


__
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


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

2016-10-18 Thread Doug Wiegley

> On Oct 18, 2016, at 10:39 AM, Matthew Thode  wrote:
> 
> On 10/18/2016 11:25 AM, Adam Harwell wrote:
>> We really don't want bindep IMO -- it's much safer to use the
>> non-packaged version from pypi for our purposes, since we may not be
>> running on a system that packages things like this. Again, our use case
>> may be strange though, as we're really using the python module and not
>> the binaries.
>> 
>> --Adam
> 
> Is there a reason you are not using pecan?

Seems a bit heavy for a microservice inside a service VM.

doug


> 
> -- 
> -- Matthew Thode (prometheanfire)
> 
> __
> 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


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

2016-10-18 Thread Matthew Thode
On 10/18/2016 11:25 AM, Adam Harwell wrote:
> We really don't want bindep IMO -- it's much safer to use the
> non-packaged version from pypi for our purposes, since we may not be
> running on a system that packages things like this. Again, our use case
> may be strange though, as we're really using the python module and not
> the binaries.
> 
> --Adam

Is there a reason you are not using pecan?

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature
__
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


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

2016-10-18 Thread Matthew Thode
On 10/18/2016 11:35 AM, Thomas Goirand wrote:
> The issue isn't co-instability, but the fact that downstream
> distribution vendors will only package *ONE* version of a given python
> module. If we have Octavia with version X, and another component of
> OpenStack with version Y, then we're stuck with Octavia not being
> packageable in downstream distros.

That's not quite true for but is certainly true for most :P

* www-servers/gunicorn
 Available versions:  19.1.1 ~19.3.0 ~19.4.5 {doc examples test
 PYTHON_TARGETS="pypy python2_7 python3_3 python3_4 python3_5"}

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature
__
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


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

2016-10-18 Thread Thomas Goirand
On 10/18/2016 02:37 AM, Ian Cordasco wrote:
> On Oct 17, 2016 7:27 PM, "Thomas Goirand"  > wrote:
>>
>> On 10/17/2016 08:43 PM, Adam Harwell wrote:
>> > Jim, that is exactly my thought -- the main focus of g-r as far as I was
>> > aware is to maintain interoperability between project dependencies for
>> > openstack deploys, and since our amphora image is totally separate, it
>> > should not be restricted to g-r requirements.
>>
>> The fact that we have a unified version number of a given lib in all of
>> OpenStack is also because that's a requirement of downstream distros.
>>
>> Imagine that someone would like to build the Octavia image using
>> exclusively packages from ...
>>
>> > I brought this up, but
>> > others thought it would be prudent to go the g-r route anyway.
>>
>> It is, and IMO you should go this route.
> 
> I'm not convinced by your arguments here, Thomas. If the distributor
> were packaging Octavia for X but the image is using some other operating
> system, say Y, why are X's packages relevant?

What if operating systems would be the same?

As a Debian package maintainer, I really prefer if the underlying images
can also be Debian (and preferably Debian stable everywhere).

> I would think that if this
> is something inside an image going to be launched by Octavia that
> co-installibilty wouldn't really be an issue.

The issue isn't co-instability, but the fact that downstream
distribution vendors will only package *ONE* version of a given python
module. If we have Octavia with version X, and another component of
OpenStack with version Y, then we're stuck with Octavia not being
packageable in downstream distros.

> I don't lean either way right now, so I'd really like to understand your
> point of view, especially since right now it isn't making much sense to me.

Do you understand now? :)

Cheers,

Thomas


__
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


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

2016-10-18 Thread Adam Harwell
We really don't want bindep IMO -- it's much safer to use the non-packaged
version from pypi for our purposes, since we may not be running on a system
that packages things like this. Again, our use case may be strange though,
as we're really using the python module and not the binaries.

--Adam

On Wed, Oct 19, 2016 at 1:07 AM Doug Wiegley <doug...@parksidesoftware.com>
wrote:

> On Oct 18, 2016, at 5:14 AM, Ian Cordasco <sigmaviru...@gmail.com> wrote:
>
>
>
> -Original Message-
> From: Thierry Carrez <thie...@openstack.org>
> Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Date: October 18, 2016 at 03:55:41
> To: openstack-dev@lists.openstack.org <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.
>
> Thanks,
> doug
>
>
> --
> Ian Cordasco
>
>
> __
> 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


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

2016-10-18 Thread Doug Wiegley

> On Oct 18, 2016, at 5:14 AM, Ian Cordasco <sigmaviru...@gmail.com> wrote:
> 
>  
> 
> -Original Message-
> From: Thierry Carrez <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>>
> Date: October 18, 2016 at 03:55:41
> To: openstack-dev@lists.openstack.org 
> <mailto:openstack-dev@lists.openstack.org> <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.

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>?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


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

2016-10-18 Thread Matthew Thode
On 10/18/2016 08:07 AM, Adam Harwell wrote:
> If there's no objection to us using gunicorn without it being present in
> g-r, then I don't know if I want to argue strongly for adding it -- the
> only benefit I see to tracking g-r at all is that it lets us continue to
> get free version tracking for our amphora dependencies as they are
> updated in g-r without having to manually tweak them. Once we go away
> from using g-r for our amphora-requirements, our project team has to
> track these dependencies manually. Tweaking the requirements bot to look
> at amphora-requirements.txt as Doug mentioned won't actually do much,
> since the whole point here is that we're including things that aren't in
> g-r so there's no source to update them from.
> 
> So, does everyone at least agree that it's ok for us to *use* gunicorn
> internally on our service-vm image? If so, I'm happy to move forward
> with option #2 if it looks like that'll be the path of least resistance.
> As I said, options 3 and 4 are not really good solutions to this
> particular problem, so in my view we should do whichever is most likely
> to be accepted of options 1 or 2.
> 
> --Adam

Personally I'm happy with it being in gr, it's not the perfect place
though.  (bindep would probably be better I feel, it's packaged on my
distro)

Do you need a specific version (bindep can't handle versions)?

As a packager I'd rather not force the type of server on my users.

-- 
Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature
__
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


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

2016-10-18 Thread Ian Cordasco
On Oct 18, 2016 8:09 AM, "Adam Harwell"  wrote:
>
> If there's no objection to us using gunicorn without it being present in
g-r, then I don't know if I want to argue strongly for adding it -- the
only benefit I see to tracking g-r at all is that it lets us continue to
get free version tracking for our amphora dependencies as they are updated
in g-r without having to manually tweak them. Once we go away from using
g-r for our amphora-requirements, our project team has to track these
dependencies manually. Tweaking the requirements bot to look at
amphora-requirements.txt as Doug mentioned won't actually do much, since
the whole point here is that we're including things that aren't in g-r so
there's no source to update them from.
>
> So, does everyone at least agree that it's ok for us to *use* gunicorn
internally on our service-vm image? If so, I'm happy to move forward with
option #2 if it looks like that'll be the path of least resistance. As I
said, options 3 and 4 are not really good solutions to this particular
problem, so in my view we should do whichever is most likely to be accepted
of options 1 or 2.

I don't think any of us are qualified to tell you not to use it in that
image. I also see the benefit clearly for Octavia, I was hoping to
understand the benefits to others (other projects/teams, packagers, and
users).

Cheers,
Ian
__
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


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

2016-10-18 Thread Adam Harwell
If there's no objection to us using gunicorn without it being present in
g-r, then I don't know if I want to argue strongly for adding it -- the
only benefit I see to tracking g-r at all is that it lets us continue to
get free version tracking for our amphora dependencies as they are updated
in g-r without having to manually tweak them. Once we go away from using
g-r for our amphora-requirements, our project team has to track these
dependencies manually. Tweaking the requirements bot to look at
amphora-requirements.txt as Doug mentioned won't actually do much, since
the whole point here is that we're including things that aren't in g-r so
there's no source to update them from.

So, does everyone at least agree that it's ok for us to *use* gunicorn
internally on our service-vm image? If so, I'm happy to move forward with
option #2 if it looks like that'll be the path of least resistance. As I
said, options 3 and 4 are not really good solutions to this particular
problem, so in my view we should do whichever is most likely to be accepted
of options 1 or 2.

--Adam

On Tue, Oct 18, 2016 at 8:18 PM Ian Cordasco <sigmaviru...@gmail.com> wrote:

>
>
> -Original Message-
> From: Thierry Carrez <thie...@openstack.org>
> Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Date: October 18, 2016 at 03:55:41
> To: openstack-dev@lists.openstack.org <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?
>
> --
> Ian Cordasco
>
>
> __
> 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


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

2016-10-18 Thread Ian Cordasco
 

-Original Message-
From: Thierry Carrez <thie...@openstack.org>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: October 18, 2016 at 03:55:41
To: openstack-dev@lists.openstack.org <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?

--  
Ian Cordasco


__
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


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

2016-10-18 Thread Thierry Carrez
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) ?

-- 
Thierry Carrez (ttx)

__
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


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

2016-10-18 Thread Adam Harwell
Right, and this is totally possible (using a different distro). In fact, it
is *likely* that in the future the amphora image will be based on a minimal
distro and not anything like the distro the rest of OpenStack is deployed
to. Also, given that the amphora image build process uses DIB and installs
gunicorn via pypi, I'm not clear on how distro packages are relevant. Pypi
installs are distro agnostic, and each operator really does *need* to build
their own amphora image for their own cloud for various reasons...

Also also, normally people think of gunicorn as a binary runner, but we are
actually using it as a Python module:
http://docs.gunicorn.org/en/stable/custom.html

As for Doug's options, I'm more in favor of option 1 or 2 (since they
actually solve the problem). Option 3 is something we'd like to do, but
doesn't do anything for this particular dilemma. Option 4 is a bit extreme,
and I think the amphora image should still retain ties to OpenStack. :/

   --Adam

On Tue, Oct 18, 2016, 09:42 Ian Cordasco  wrote:

> On Oct 17, 2016 7:27 PM, "Thomas Goirand"  wrote:
> >
> > On 10/17/2016 08:43 PM, Adam Harwell wrote:
> > > Jim, that is exactly my thought -- the main focus of g-r as far as I
> was
> > > aware is to maintain interoperability between project dependencies for
> > > openstack deploys, and since our amphora image is totally separate, it
> > > should not be restricted to g-r requirements.
> >
> > The fact that we have a unified version number of a given lib in all of
> > OpenStack is also because that's a requirement of downstream distros.
> >
> > Imagine that someone would like to build the Octavia image using
> > exclusively packages from ...
> >
> > > I brought this up, but
> > > others thought it would be prudent to go the g-r route anyway.
> >
> > It is, and IMO you should go this route.
>
> I'm not convinced by your arguments here, Thomas. If the distributor were
> packaging Octavia for X but the image is using some other operating system,
> say Y, why are X's packages relevant? I would think that if this is
> something inside an image going to be launched by Octavia that
> co-installibilty wouldn't really be an issue.
>
> I don't lean either way right now, so I'd really like to understand your
> point of view, especially since right now it isn't making much sense to me.
> __
> 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


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

2016-10-17 Thread Doug Wiegley
On Oct 17, 2016, at 6:44 PM, Morgan Fainberg  wrote:
> 
> 
> On Oct 17, 2016 17:32, "Thomas Goirand"  > wrote:
> >
> > On 10/17/2016 08:43 PM, Adam Harwell wrote:
> > > Jim, that is exactly my thought -- the main focus of g-r as far as I was
> > > aware is to maintain interoperability between project dependencies for
> > > openstack deploys, and since our amphora image is totally separate, it
> > > should not be restricted to g-r requirements.
> >
> > The fact that we have a unified version number of a given lib in all of
> > OpenStack is also because that's a requirement of downstream distros.
> >
> > Imagine that someone would like to build the Octavia image using
> > exclusively packages from ...
> >
Right, so, we’re dancing around the common problem in openstack lately: what 
the heck is openstack?

This came up because service VMs/data plane implementations, which this is, 
have different requirements than API services. 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.

Thanks,
doug


> > > I brought this up, but
> > > others thought it would be prudent to go the g-r route anyway.
> >
> > It is, and IMO you should go this route.
> >
> > Cheers,
> >
> > Thomas Goirand (zigo)
> >
> >
> > __
> > 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 
> > 
> For the record uwsgi was not (at least at one point) allowed in g-r as it was 
> not a "runtime dependency" it was to be installed more like apache mod_wsgi 
> at the time. Gunicorn could fall into the same category, it is meant to be 
> used in conjunction with the runtime but not be a hard requirement for the 
> runtime itself. 
> __
> 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


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

2016-10-17 Thread Morgan Fainberg
On Oct 17, 2016 17:32, "Thomas Goirand"  wrote:
>
> On 10/17/2016 08:43 PM, Adam Harwell wrote:
> > Jim, that is exactly my thought -- the main focus of g-r as far as I was
> > aware is to maintain interoperability between project dependencies for
> > openstack deploys, and since our amphora image is totally separate, it
> > should not be restricted to g-r requirements.
>
> The fact that we have a unified version number of a given lib in all of
> OpenStack is also because that's a requirement of downstream distros.
>
> Imagine that someone would like to build the Octavia image using
> exclusively packages from ...
>
> > I brought this up, but
> > others thought it would be prudent to go the g-r route anyway.
>
> It is, and IMO you should go this route.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
> __
> 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

For the record uwsgi was not (at least at one point) allowed in g-r as it
was not a "runtime dependency" it was to be installed more like apache
mod_wsgi at the time. Gunicorn could fall into the same category, it is
meant to be used in conjunction with the runtime but not be a hard
requirement for the runtime itself.
__
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


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

2016-10-17 Thread Ian Cordasco
On Oct 17, 2016 7:27 PM, "Thomas Goirand"  wrote:
>
> On 10/17/2016 08:43 PM, Adam Harwell wrote:
> > Jim, that is exactly my thought -- the main focus of g-r as far as I was
> > aware is to maintain interoperability between project dependencies for
> > openstack deploys, and since our amphora image is totally separate, it
> > should not be restricted to g-r requirements.
>
> The fact that we have a unified version number of a given lib in all of
> OpenStack is also because that's a requirement of downstream distros.
>
> Imagine that someone would like to build the Octavia image using
> exclusively packages from ...
>
> > I brought this up, but
> > others thought it would be prudent to go the g-r route anyway.
>
> It is, and IMO you should go this route.

I'm not convinced by your arguments here, Thomas. If the distributor were
packaging Octavia for X but the image is using some other operating system,
say Y, why are X's packages relevant? I would think that if this is
something inside an image going to be launched by Octavia that
co-installibilty wouldn't really be an issue.

I don't lean either way right now, so I'd really like to understand your
point of view, especially since right now it isn't making much sense to me.
__
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


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

2016-10-17 Thread Thomas Goirand
On 10/17/2016 08:43 PM, Adam Harwell wrote:
> Jim, that is exactly my thought -- the main focus of g-r as far as I was
> aware is to maintain interoperability between project dependencies for
> openstack deploys, and since our amphora image is totally separate, it
> should not be restricted to g-r requirements.

The fact that we have a unified version number of a given lib in all of
OpenStack is also because that's a requirement of downstream distros.

Imagine that someone would like to build the Octavia image using
exclusively packages from ...

> I brought this up, but
> others thought it would be prudent to go the g-r route anyway.

It is, and IMO you should go this route.

Cheers,

Thomas Goirand (zigo)


__
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


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

2016-10-17 Thread Adam Harwell
Jim, that is exactly my thought -- the main focus of g-r as far as I was
aware is to maintain interoperability between project dependencies for
openstack deploys, and since our amphora image is totally separate, it
should not be restricted to g-r requirements. I brought this up, but others
thought it would be prudent to go the g-r route anyway. So, I don't really
care what g-r says in this case, but I am aware my personality tends a bit
towards anarchistic, so I ceded the argument in an attempt to play nice. :)
If others also agree that g-r should not apply in cases like these, we can
re-evaluate our choice to add gunicorn to our main requirements file, and
install it via alternate mechanisms.

--Adam

On Tue, Oct 18, 2016 at 3:16 AM Doug Wiegley 
wrote:

> On Oct 17, 2016, at 12:02 PM, Jim Rollenhagen 
> wrote:
> >
> > On Mon, Oct 17, 2016 at 1:33 PM, Doug Wiegley
> >  wrote:
> >> Hi,
> >>
> >> On a review to add gunicorn to global requirements[1], we were asked to
> send a notice to the ML. In this particular application, it’s for use
> inside a service VM for Octavia. Objections/comments/other?
> >
> > global-requirements is meant to ensure co-installability between
> > OpenStack services.
> > Is it safe to assume that software running in service VMs does not need
> to be
> > co-installable with other OpenStack services, since it's separated
> > from the control
> > plane?
> >
>
> In this particular case, yes, that’s not a concern, but if added to g-r,
> it might proliferate elsewhere over time.
>
> Thanks,
> doug
>
> > // jim
> >
> >
> __
> > 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


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

2016-10-17 Thread Doug Wiegley
On Oct 17, 2016, at 12:02 PM, Jim Rollenhagen  wrote:
> 
> On Mon, Oct 17, 2016 at 1:33 PM, Doug Wiegley
>  wrote:
>> Hi,
>> 
>> On a review to add gunicorn to global requirements[1], we were asked to send 
>> a notice to the ML. In this particular application, it’s for use inside a 
>> service VM for Octavia. Objections/comments/other?
> 
> global-requirements is meant to ensure co-installability between
> OpenStack services.
> Is it safe to assume that software running in service VMs does not need to be
> co-installable with other OpenStack services, since it's separated
> from the control
> plane?
> 

In this particular case, yes, that’s not a concern, but if added to g-r, it 
might proliferate elsewhere over time.

Thanks,
doug

> // jim
> 
> __
> 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


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

2016-10-17 Thread Jim Rollenhagen
On Mon, Oct 17, 2016 at 1:33 PM, Doug Wiegley
 wrote:
> Hi,
>
> On a review to add gunicorn to global requirements[1], we were asked to send 
> a notice to the ML. In this particular application, it’s for use inside a 
> service VM for Octavia. Objections/comments/other?

global-requirements is meant to ensure co-installability between
OpenStack services.
Is it safe to assume that software running in service VMs does not need to be
co-installable with other OpenStack services, since it's separated
from the control
plane?

// jim

__
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