<div dir="ltr">Oleg<div><br></div><div>The problem here is that you have this code released and it is running in production - how are you going to fix this? Pin requirements and deal with dependency hell?</div><div>Seriously, it is much easier to deal with explicitly frozen mirror which is created by one 'pip install ' run than to play with implicit transitive dependencies.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 13, 2015 at 11:58 AM, Oleg Gelbukh <span dir="ltr"><<a href="mailto:ogelbukh@mirantis.com" target="_blank">ogelbukh@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Some comments inline.</div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Jul 13, 2015 at 9:24 AM, Bartlomiej Piotrowski <span dir="ltr"><<a href="mailto:bpiotrowski@mirantis.com" target="_blank">bpiotrowski@mirantis.com</a>></span> wrote:<br></span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Freezing every moving part is complete overkill and puts a heavy burden on devops<br>team as well as infra itself. The fix couldn't be more simple: just put upper<br>bounds in requirements.<span><br><br>> 1) if there is a new conflicting version, you need to set this upper-bound, thus you need to modify bits which get released<br></span></div><div>It should be done as part of hard code freeze.</div></div></blockquote><div><br></div></span><div>As I understand, in this cases it is not code dependencies that cause misfunction, but dependencies of tests. This can be fixed by pinning test-requirements. We can do this any time, as it does not affect users.</div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span><br><br>> 2) you are actually testing your code by linking it with libraries which are different from those that users are really using when running your code<br></span></div><div>Packages dependencies should reflect these set in requirements.<br></div><span><div><br>> 3) even if you specify an upper bound (or even fix the version) for this particular library, you may still fetch its newer dependency implicitly (by traversing indirect dependencies) with which you will be linking your libraries and which will actually be different from the code that you (and your users) use<br></div></span><div>This can be actually said about anything, including base system Fuel is running. We simply do not support such setups.</div></div></blockquote><div><br></div></span><div>That's why we should run CI and nightly builds on stable branches. It catches exactly this type of issues.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span><br><br>> 4) you may also break production installation if you fix some library version as it may not exist in the code bundle which gets delivered to your users as a set of package<br></span></div><div>See 2.</div></div></blockquote><div> </div></span><div>Again, if something in code deps breaks our stable branch, we must learn it as soon as possible and fix it there. However, in this case it ist the test requirements failure, and it should pinned in 'test-requirements.txt' or in requirements of our test suits.</div><div><br></div><div>--</div><div>Best regards,</div><div>Oleg Gelbukh</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div>BP<br></div></font></span></div><span class="">
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></span></blockquote></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>35bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div>