Open Stack

Dmitry

You can fix it by declaring that developer should use particular pypi
mirror.

On Wed, Jul 15, 2015 at 2:46 PM, Dmitry Pyzhov <dpyzhov at mirantis.com> wrote:

> Vladimir,
>
> 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>
> wrote:
>
>> Dima
>>
>> 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
>> objections.
>>
>> Bartek
>>
>> 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
>>> 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.
>>>
>>> > 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.
>>>
>>> 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
>>>
>>>
>>
>>
>> --
>> 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
>>
>>
>
> __________________________________________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150715/4c01c492/attachment.html>