[openstack-dev] [Fuel] Problem with kombu version.

Matthew Mosesohn mmosesohn at mirantis.com
Wed Apr 9 11:38:54 UTC 2014


Dmitry, I don't think you should drop kombu.five so soon.
We haven't heard directly from Fuel python team, such as Dmitry
Pyzhov, what reason we have to lock kombu at version 2.5.14.
I wrote to him earlier today out of band, so hopefully he will get
back to this message soon.

On Wed, Apr 9, 2014 at 3:27 PM, Dmitry Teselkin <dteselkin at mirantis.com> wrote:
> Hi again,
>
> So there is a reply from the Dmitry Burmistrov which for some reason was
> missed in this thread:
>> Nailgun requires exact version of kombu ( == 2.5.14 ).
>> This is the only reason why we can't update it.
>> I think you should talk to Dmitry P. about this version conflict.
>> I want to take this opportunity to remind everyone that we should
>> adhere to the global-requirements.txt in order to avoid such
>> conflicts.
>
> Hopefully our developers decided to get rid of kombu.five usage what looks
> an easy task.
>
> Thanks, everyone.
>
>
>
> On Mon, Apr 7, 2014 at 8:33 PM, Dmitry Teselkin <dteselkin at mirantis.com>
> wrote:
>>
>> Hello,
>>
>> I'm working on Murano integration into FUEL-5.0, and have faced the
>> following problem: our current implementation depends on 'kombu.five'
>> module, but this module (actually a single file) is available only starting
>> at kombu 3.0. So this means that murano-api component depends on kombu
>> >=3.0. This meets the OpenStack global requirements list, where kombu
>> >=2.4.8 is declared. Unfortunately, this also means that "system-wide"
>> version upgrade is required.
>>
>> So the question is - what is the right way to solve the promblem? I see
>> the following options:
>> 1. change kombu version requirement to >=3.0 for entire FUEL installation
>> - it doesn't break global requirements constraint but some other FUEL
>> components could be affected.
>> 2. replace calls to functions from 'python.kombu' and use existing version
>> - I'm not sure if it's possible, I'm awaiting answer from our developers.
>>
>> Which is the most suitable variant, or are there any other solutions for
>> the problem?
>>
>>
>> --
>> Thanks,
>> Dmitry Teselkin
>> Deployment Engineer
>> Mirantis
>> http://www.mirantis.com
>
>
>
>
> --
> Thanks,
> Dmitry Teselkin
> Deployment Engineer
> Mirantis
> http://www.mirantis.com
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



More information about the OpenStack-dev mailing list