[openstack-dev] [Fuel][Fuel-Packaging][Fuel-CI][Fuel-Infra] How to Deal with CI Failures Induced by Libraries Requirements Drift
vkuklin at mirantis.com
Mon Jul 13 09:34:44 UTC 2015
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
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
On Mon, Jul 13, 2015 at 11:58 AM, Oleg Gelbukh <ogelbukh at mirantis.com>
> Some comments inline.
> On Mon, Jul 13, 2015 at 9:24 AM, Bartlomiej Piotrowski <
> bpiotrowski at 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
>> 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
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
Fuel Library Tech Lead,
+7 (495) 640-49-04
+7 (926) 702-39-68
35bk3, Vorontsovskaya Str.
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev