[openstack-dev] [Fuel][Fuel-Packaging][Fuel-CI][Fuel-Infra] How to Deal with CI Failures Induced by Libraries Requirements Drift
ogelbukh at mirantis.com
Mon Jul 13 11:04:59 UTC 2015
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.
On Mon, Jul 13, 2015 at 12:34 PM, Vladimir Kuklin <vkuklin at mirantis.com>
> 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
> 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)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/>
> vkuklin at mirantis.com
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev