<p dir="ltr"></p>
<p dir="ltr">On Oct 18, 2016 8:09 AM, "Adam Harwell" <<a href="mailto:flux.adam@gmail.com">flux.adam@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> 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.</p>
<p dir="ltr">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). </p>
<p dir="ltr">Cheers,<br>
Ian</p>