Dmitry You can fix it by declaring that developer should use particular pypi mirror.
On Wed, Jul 15, 2015 at 2:46 PM, Dmitry Pyzhov <dpyz...@mirantis.com> wrote: > Vladimir, > > 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. > > 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. > > Tests for master jobs are an open question. I think we can continue using > pypi here for now. Because it works. > > On Mon, Jul 13, 2015 at 11:56 AM, Vladimir Kuklin <vkuk...@mirantis.com> > wrote: > >> Dima >> >> 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. >> 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. >> >> Bartek >> >> 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. >> >> >> Let me provide an example why your suggestion does not work. >> >> 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. >> >> >> On Mon, Jul 13, 2015 at 9:24 AM, Bartlomiej Piotrowski < >> bpiotrow...@mirantis.com> wrote: >> >>> Freezing every moving part is complete overkill and puts a heavy burden >>> on devops >>> team as well as infra itself. The fix couldn't be more simple: just put >>> upper >>> bounds in requirements. >>> >>> > 1) if there is a new conflicting version, you need to set this >>> upper-bound, thus you need to modify bits which get released >>> It should be done as part of hard code freeze. >>> >>> > 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 >>> Packages dependencies should reflect these set in requirements. >>> >>> > 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 >>> This can be actually said about anything, including base system Fuel is >>> running. We simply do not support such setups. >>> >>> > 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 >>> See 2. >>> >>> BP >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Yours Faithfully, >> Vladimir Kuklin, >> Fuel Library Tech Lead, >> Mirantis, Inc. >> +7 (495) 640-49-04 >> +7 (926) 702-39-68 >> Skype kuklinvv >> 35bk3, Vorontsovskaya Str. >> Moscow, Russia, >> www.mirantis.com <http://www.mirantis.ru/> >> www.mirantis.ru >> vkuk...@mirantis.com >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@mirantis.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev