<div dir="ltr"><div>Clarkb, </div><div><br></div><div>As Robert said, you are missing the point. </div><div><br></div><div>I didn't say that "Rally wants this lib so it should be in global requirements". </div><div><br></div><div>I asked only about python clients of stackforge projects that are regarding all rules: </div><div>(Like py3k support, license, are in projects.txt and so on). From my point of view, if clients are regarding all reules there is no compatibility issues => it is easy to add them to g-r. Am I wrong? </div><div><br></div><div><br></div><div>All, </div><div><br></div><div>Sorry I wasn't able to be on meeting yesterday.</div><div><br></div><div><br></div><div>First of all, we don't have any issues with having Murano/Mistral benchmarks and testing them in gates and supporting them in our tree. (We already have rally-dsvm-murano and rally-dsvm-mistral dsvm jobs that works well) </div><div><br></div><div>The real issue is very bad user & dev experience caused by soft decencies. </div><div><br></div><div>Let's take a look at actions of typical user (running Murano benchamrk): </div><div>1) Try to run tests for Murano </div><div>2) Input validation error: MuranoClient is missing please install it</div><div>3) WTF???</div><div><br></div><div>Let's take a look at actions of end developer (writing Murano benchmark): </div><div>1) Try to make new Murano benchmark</div><div>2) Need to import some exceptions from Murano client</div><div>3) All unit tests are failing..</div><div>4) WTF??? </div><div><br></div><div>Adding extra steps/conditions that are required for using product are adding exponential complexity to it. So having 5 such steps/conditions will make product inconsumable. </div><div><br></div><div>So the only thing that I would like is to remove one "extra step" by adding good python clients to g-r. </div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 21, 2015 at 4:15 AM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 21 January 2015 at 10:21, Clark Boylan <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>> wrote:<br>
...<br>
<div><div class="h5">> This ml thread came up in the TC meeting today and I am responding here<br>
> to catch the thread up with the meeting. The soft update option is the<br>
> suggested fix for non openstack projects that want to have most of their<br>
> requirements managed by global requirements.<br>
><br>
> For the project structure reform opening things up we should consider<br>
> loosening the criteria to get on the list and make it primarily based on<br>
> technical criteria such as py3k support, license compatibility, upstream<br>
> support/activity, and so on (basically the current criteria with less of<br>
> a focus on where the project comes from if it is otherwise healthy).<br>
> Then individual projects would choose the subset they need to depend on.<br>
> This model should be viable with different domains as well if we go that<br>
> route.<br>
><br>
> The following is not from the TC meeting but addressing other portions<br>
> of this conversation:<br>
><br>
> At least one concern with this option is that as the number of total<br>
> requirements goes up is the difficulty in debugging installation<br>
> conflicts becomes more difficult too. I have suggested that we could<br>
> write tools to help with this. Install bisection based on pip logs for<br>
> example, but these tools are still theoretical so I may be<br>
> overestimating their usefulness.<br>
><br>
> To address the community scaling aspect I think you push a lot of work<br>
> back on deployers/users if we don't curate requirements for anything<br>
> that ends up tagged as "production ready" (or whatever the equivalent<br>
> tag becomes). Essentially we are saying "this doesn't scale for us so<br>
> now you deal with the fallout. Have fun", which isn't very friendly to<br>
> people consuming the software. We already have an absurd number of<br>
> requirements and management of them has appeared to scale. I don't<br>
> foresee my workload going up if we open up the list as suggested.<br>
<br>
</div></div>Perhaps I missed something, but the initial request wasn't about<br>
random packages, it was about other stackforge clients - these are<br>
things in the ecosystem! I'm glad we have technical solutions, but it<br>
just seems odd to me that adding them would ever have been<br>
controversial.<br>
<br>
On the pip solver side, joe gordon was working on a thing to install a<br>
fixed set of packages by bypassing the pip resolver... not sure how<br>
thats progressing.<br>
<br>
-Rob<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>