Vladimir, The failures you are referring to is purely test-related failures. They don't affect the code in production in any way, as far as I can see. All the same, production code won't be affected by pinning versions of test-requirements in the stable/* branches of the product and test suits.
-Oleg On Mon, Jul 13, 2015 at 12:34 PM, Vladimir Kuklin <vkuk...@mirantis.com> wrote: > Oleg > > 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? > 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. > > On Mon, Jul 13, 2015 at 11:58 AM, Oleg Gelbukh <ogelb...@mirantis.com> > wrote: > >> Some comments inline. >> >> 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. >>> >> >> 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. >> >>> >>> >>> > 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. >>> >> >> That's why we should run CI and nightly builds on stable branches. It >> catches exactly this type of issues. >> >> >>> >>> >>> > 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. >>> >> >> 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. >> >> -- >> Best regards, >> Oleg Gelbukh >> >> >>> >>> 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 >>> >>> >> >> __________________________________________________________________________ >> 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
