[openstack-dev] [Fuel][Fuel-Packaging][Fuel-CI][Fuel-Infra] How to Deal with CI Failures Induced by Libraries Requirements Drift
vkuklin at mirantis.com
Wed Jul 15 12:21:36 UTC 2015
You can fix it by declaring that developer should use particular pypi
On Wed, Jul 15, 2015 at 2:46 PM, Dmitry Pyzhov <dpyzhov at mirantis.com> wrote:
> 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 <vkuklin at mirantis.com>
>> 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
>> 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 <
>> 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.
>>> > 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.
>>> 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)
>> 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