Mattew, main reason is global-requirements.txt It defines that your app should work with kombu v2.4.8 and upper
On Wed, Apr 9, 2014 at 3:38 PM, Matthew Mosesohn <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> >> 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 >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
