Open Stack

Zhijang,

You have a point a view whereby Kolla is never co-installed with other OpenStack projects.  I agree I have never heard of this happening.  That doesn’t mean it doesn’t happen.

Even given this line of thinking, I have an impossible time rationalizing Kolla as a special snowflake.  Kolla conforms (as best as we know how) to OpenStack wide processes.

Regards
-steve

From: "hu.zhijiang at zte.com.cn" <hu.zhijiang at zte.com.cn>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Wednesday, April 19, 2017 at 11:24 PM
To: "hongbin034 at gmail.com" <hongbin034 at gmail.com>
Cc: "openstack-dev at lists.openstack.org" <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] [daisycloud-core] [requirements][magnum] [oslo] Do we really need to upgrade pbr, docker-py and oslo.utils


Then IMO,  the global requirements process seems against the intention of requirement.txt file. Since requirement.txt is per-project, not global. It is (just for example) Zun that treat docker-py-1.8 as a must. As for Kolla, both 1.6 and 1.8 are OK. Then there is no need to force Kolla to change its requirement from "docker-py ＞=1.6.0" to "docker-py ＞=1.8.0" by the global requirements process, otherwise,  user may think Kolla really need a newer version, kind of easy to be misread.



We know it is valuable to upgrade requirements globally, as it is condusive to early bug detection of the co-installation circumstance. But can we not to do that detection in each project's CI by write it literally in each project's requirement.txt but just upgrade required packages globally in a dedicated CI that tests the projects which really need to be co-installed?



B. R.,

Zhijiang
Original Mail
Sender:  ＜hongbin034 at gmail.com＞;
To:  ＜openstack-dev at lists.openstack.org＞;
Date: 2017/04/20 12:50
Subject: Re: [openstack-dev] [kolla] [daisycloud-core] [requirements][magnum] [oslo] Do we really need to upgrade pbr, docker-py and oslo.utils


Zun required docker-py to be 1.8 or higher because older version of docker-py didn't have the API we need. Sorry if it caused difficulties on your side but I don't think it is feasible to downgrade the version for now since it will affect a ton of other projects.
Best regards,
Hongbin

On Thu, Apr 20, 2017 at 12:15 AM, Steven Dake (stdake) ＜stdake at cisco.com<mailto:stdake at cisco.com>＞ wrote:
Hu,

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:

Pbr: https://github.com/openstack/requirements/blame/stable/ocata/global-requirements.txt#L158
Here is the change: https://github.com/openstack/requirements/commit/74a8e159e3eda7c702a39e38ab96327ba85ced3c
(from the infrastructure team)

Docker-py: https://github.com/openstack/requirements/blame/stable/ocata/global-requirements.txt#L338
Here is the change: https://github.com/openstack/requirements/commit/330139835347a26f435ab1262f16cf9e559f32a6
(from the magnum team)

oslo-utils: https://github.com/openstack/requirements/blame/62383acc175b77fe7f723979cefaaca65a8d12fe/global-requirements.txt#L136
https://github.com/openstack/requirements/commit/510c4092f48a3a9ac7518decc5d3724df8088eb7
(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.

Regards
-steve



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


Hello,



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.



[1] https://github.com/openstack/kolla/commit/2f50beb452918e37dec6edd25c53e407c6e47f53

[2] https://github.com/openstack/kolla/commit/85abee13ba284bb087af587b673f4e44187142da

[3] https://github.com/openstack/kolla/commit/cee89ee8bef92914036189d02745c08894a9955b











B. R.,

Zhijiang

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170420/2271d6e3/attachment.html>