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 <doug...@parksidesoftware.com>
wrote:
> On Oct 17, 2016, at 12:02 PM, Jim Rollenhagen <j...@jimrollenhagen.com>
> wrote:
> >
> > On Mon, Oct 17, 2016 at 1:33 PM, Doug Wiegley
> > <doug...@parksidesoftware.com> 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
