Kolla does not manage the global requirements process as it is global to 
OpenStack.  The Kolla core reviewers essentially rubber stamp changes from the 
global requirements bot assuming they pass our gating.  If they don’t pass our 
gating, we work with the committer to sort out a working solution.

Taking a look at the specific issues you raised:

Here is the change:
(from the infrastructure team)

Here is the change:
(from the magnum team)

(I am not sure which team this is – the oslo team perhaps?)

I would recommend taking the changes up with the requirements team or the 
direct authors.


From: "" <>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
Date: Wednesday, April 19, 2017 at 8:45 PM
To: "" <>
Subject: [openstack-dev] [kolla] [daisycloud-core]Do we really need to upgrade 
pbr, docker-py and oslo.utils


As global requirements changed in Ocata, Kolla upgrads pbr>=1.8 [1] ,

docker-py>=1.8.1[2] . Besides, Kolla also starts depending on

oslo.utils>=3.18.0 to use uuidutils.generate_uuid() instead of uuid.uuid4() to

generate UUID.

IMHO, Upgrading of [1] and [2] are actually not what Kolla really need to,

and uuidutils.generate_uuid() is also supported by oslo.utils-3.16. I mean

If we keep Kolla's requirement in Ocata as what it was in Newton, upper layer

user of Kolla like daisycloud-core project can still keep other things unchanged

to upgrade Kolla from stable/newton to stable/ocata. Otherwise, we have to

upgrade from centos-release-openstack-newton to

centos-release-openstack-ocata(we do not use pip since it conflicts with yum

on files installed by same packages). But this kind of upgrade may be too

invasive that may impacts other applications.

I know that there were some discusstions about global requirements update

these days. So if not really need to do these upgrades by Kolla itself, can

we just keep the requirement unchanged as long as possible?

My 2c.




B. R.,

OpenStack Development Mailing List (not for usage questions)

Reply via email to