<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Oct 17, 2016, at 6:44 PM, Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com" class="">morgan.fainberg@gmail.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div class=""><br class="webkit-block-placeholder"></div><p dir="ltr" class="">On Oct 17, 2016 17:32, "Thomas Goirand" <<a href="mailto:zigo@debian.org" class="">zigo@debian.org</a>> wrote:<br class="">
><br class="">
> On 10/17/2016 08:43 PM, Adam Harwell wrote:<br class="">
> > Jim, that is exactly my thought -- the main focus of g-r as far as I was<br class="">
> > aware is to maintain interoperability between project dependencies for<br class="">
> > openstack deploys, and since our amphora image is totally separate, it<br class="">
> > should not be restricted to g-r requirements.<br class="">
><br class="">
> The fact that we have a unified version number of a given lib in all of<br class="">
> OpenStack is also because that's a requirement of downstream distros.<br class="">
><br class="">
> Imagine that someone would like to build the Octavia image using<br class="">
> exclusively packages from <your-favorite-distro-here>...<br class="">
><br class="">
</p></div></blockquote><div>Right, so, we’re dancing around the common problem in openstack lately: what the heck is openstack?</div><div><br class=""></div><div>This came up because service VMs/data plane implementations, which this is, have different requirements than API services. Paths forward:</div><div><br class=""></div><div>1. Add gunicorn to global requirements.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>4. Boot the backend out of OpenStack entirely.</div><div><br class=""></div><div>Thanks,</div><div>doug</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">> > I brought this up, but<br class="">
> > others thought it would be prudent to go the g-r route anyway.<br class="">
><br class="">
> It is, and IMO you should go this route.<br class="">
><br class="">
> Cheers,<br class="">
><br class="">
> Thomas Goirand (zigo)<br class="">
><br class="">
><br class="">
> __________________________________________________________________________<br class="">
> OpenStack Development Mailing List (not for usage questions)<br class="">
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="">
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></p><p dir="ltr" class="">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. <br class="">
</p>
__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></body></html>