<div dir="ltr">Dmitry<div><br></div><div>You can fix it by declaring that developer should use particular pypi mirror.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 15, 2015 at 2:46 PM, Dmitry Pyzhov <span dir="ltr"><<a href="mailto:dpyzhov@mirantis.com" target="_blank">dpyzhov@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">Vladimir,<div><br></div><div>We do break developer's workflow in stable branches if we force them to use our local mirrors. Yes, we can hardcode mirror url in tox.ini or something like that. But it looks like a hack for me.</div><div><br></div><div>Packaging systems were created in order to add ability to set up predictable environment with exact versions of every piece. So if we want to have a predictable environment for stable branches we have one production ready option. We should have a package for every moving part. None of our stable/* jobs on jenkins should use anything except locally cached packages. I think this is the only way to do it right.</div><div><br></div><div>Tests for master jobs are an open question. I think we can continue using pypi here for now. Because it works.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 13, 2015 at 11:56 AM, Vladimir Kuklin <span dir="ltr"><<a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@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">Dima<div><br></div><div>You have a very valid point, but the is a problem here - by doing it this way we are breaking developers' workflow which is based on using such repositories as pypi, rubygem, etc.</div><div>If you convince developers (and I guess not only Fuel ones as we are moving towards community engagement) to switch their workflow - I have no objections.</div><div><br></div><div>Bartek</div><div><br></div><div><div>Actually, what we are doing is that we are freezing almost all the packages (except for upstream linux maintenance updates that should not change ABIs) thus having this drift at least constrained somehow. And this is how you control your upper bounds - you just do not push anything new into it.</div></div><div><br></div><div><br></div><div>Let me provide an example why your suggestion does not work.</div><div><br></div><div>Imagine, we have Debian Sid repository configured for our installations (or use some other 3rd party not strictly controlled mirror). It will work fine until you push new oslo package which is conflicting with your stuff like keystone, for example. And what is more important - you have already released this keystone and you CANNOT control requirements of it, you were not able to set them when you were working on the release because there is actually no time machine. This means that you need either to disable this 3rd party repo or to freeze in some state or you will have the same problem as with eggs.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>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></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><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.<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.<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.<span><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div>BP<br></div></font></span></div>
<br></div></div><span>__________________________________________________________________________<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><span><br><br clear="all"><div><br></div>-- <br><div><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>
</span></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></div>
</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>