[openstack-dev] [kolla][release][requirements] providing constraints for transitive dependencies

Steven Dake (stdake) stdake at cisco.com
Mon Nov 28 08:15:17 UTC 2016


Are you indicating that all transitive dependencies (e.g. nova depends on x depends on y, y = version of dep we want to specify) are in global-requirements.txt?


-----Original Message-----
From: Tony Breeds <tony at bakeyournoodle.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Sunday, November 27, 2016 at 9:42 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [kolla][release][requirements] providing constraints for transitive dependencies

    On Mon, Nov 28, 2016 at 02:41:08AM +0000, Steven Dake (stdake) wrote:
    > Hey folks,
    > I get a lot of requests for variance reduction of transitive dependencies in
    > Kolla’s containers.  As an example, we build from source nova.  Nova itself
    > we can specify a version to install in the containers during build time.
    > Nova’s python dependencies, not so much.
    I'm not certain I follow.  You're using upper-constraints for install time
    consistent version selection, and that applies to *all* dependencies no matter
    how many levels down they are.  You *could* extract and manipulate the upper-constraints
    file for each container, and assuming 1 container 1 service that will probably
    give you want you want.  The only trick is for data that is passed over the RPC
    between services.  For example having different versions of oslo.context in the
    nova conductor and nova-compute containers would be a bad thing.
    Is that kinda what you're asking?
    If not a more concrete example would be very helpful.
    > Is there a best practice for doing such in the python ecosystem?
    Nope.  in the python eco-system you more or less get what you ask for and it;s
    up to you to find a spot on the prescriptive <-> flexible line.
    Yours Tony.

More information about the OpenStack-dev mailing list