Open Stack

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 <vkuklin at 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 <ogelbukh at mirantis.com>
> wrote:
>
>> 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
>>> 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-request at 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-request at 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
> vkuklin at mirantis.com
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150713/2cd3260b/attachment.html>