[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Jun. 30 2017
1.ODL L2/L3 Integration 2.Scenario in JJB 3.Documentation task 4.AoB B. R., Zhijiang__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [daisycloud-core] Meeting minutes for IRC meeting 0800UTC May 5 2017
Meeting ended Fri May 5 08:58:39 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://eavesdrop.openstack.org/meetings/daisycloud/2017/daisycloud.2017-05-05-07.59.html Minutes (text): http://eavesdrop.openstack.org/meetings/daisycloud/2017/daisycloud.2017-05-05-07.59.txt Log: http://eavesdrop.openstack.org/meetings/daisycloud/2017/daisycloud.2017-05-05-07.59.log.html B. R., Zhijiang__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa][heat][murano][daisycloud] Removing Heatsupport from Tempest
Hello Andrea, daisycloud no longer uses OrchestrationClient. I will remove the related code. Thanks for the information. B. R., Zhijiang Original Mail Sender: ＜andrea.fritt...@gmail.com＞ To: ＜openstack-dev@lists.openstack.org＞ Date: 2017/04/27 18:28 Subject: [openstack-dev] [qa][heat][murano][daisycloud] Removing Heatsupport from Tempest Dear stackers, starting in the Liberty cycle Tempest has defined a set of projects which are in scope for direct testing in Tempest [0]. The current list includes keystone, nova, glance, swift, cinder and neutron. All other projects can use the same Tempest testing infrastructure (or parts of it) by taking advantage the Tempest plugin and stable interfaces. Tempest currently hosts a set of API tests as well as a service client for the Heat project. The Heat service client is used by the tests in Tempest, which run in Heat gate as part of the grenade job, as well as in the Tempest gate (check pipeline) as part of the layer4 job. According to code search [3] the Heat service client is also used by Murano and Daisycore. I proposed a patch to Tempest to start the deprecation counter for Heat / orchestration related configuration items in Tempest [4], and I would like to make sure that all tests and the service client either find a new home outside of Tempest, or are removed, by the end the Pike cycle at the latest. Heat has in-tree integration tests and Gabbi based API tests, but I don't know if those provide enough coverage to replace the tests on Tempest side. It would propose to move tests and client to a Tempest plugin owned / maintained by the Heat team, so that the Heat team can have full flexibility in consolidating their integration tests. For Murano and Daisycloud - and any other team that may want to use the Heat service client in their tests, even if the client is removed from Tempest, it would still be available via the Heat Tempest plugin. As long as the plugin implements the service client interface, the Heat service client will register automatically in the service client manager and be available for use as today. Andrea Frittoli (andreaf) [0] https://docs.openstack.org/developer/tempest/test_removal.html#tempest-scope [1] https://docs.openstack.org/developer/tempest/plugin.html [2] https://docs.openstack.org/developer/tempest/library.html [3] http://codesearch.openstack.org/?q=self.orchestration_client=nope== [4] https://review.openstack.org/#/c/456843/__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] [daisycloud-core][requirements][magnum] [oslo] Do we really need to upgrade pbr,docker-py and oslo.utils
Steve, Co-installation and global requirements are orthogonal to me: Two projects which can be (or need to be) co-installed do not need to be global requirements aligned, on the flip side, two projects which are global requirements aligned do not need to be tied together for user to use. So I would rather interpret global requirements alignement as a test to see if projects can run together than an updating of each projects requirement.txt. B. R., Zhijiang Original Mail Sender: ＜std...@cisco.com＞ To: ＜openstack-dev@lists.openstack.org＞ ＜hongbin...@gmail.com＞ Date: 2017/04/20 18:08 Subject: Re: [openstack-dev] [kolla] [daisycloud-core][requirements][magnum] [oslo] Do we really need to upgrade pbr,docker-py and oslo.utils 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.zhiji...@zte.com.cn" ＜hu.zhiji...@zte.com.cn＞ Reply-To: "OpenStack Development Mailing List (not for usage questions)" ＜openstack-dev@lists.openstack.org＞ Date: Wednesday, April 19, 2017 at 11:24 PM To: "hongbin...@gmail.com" ＜hongbin...@gmail.com＞ Cc: "openstack-dev@lists.openstack.org" ＜openstack-dev@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: ＜hongbin...@gmail.com＞ To: ＜openstack-dev@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) ＜std...@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.zhiji...@zte.com.cn" ＜hu.zhiji...@zte.com.cn＞ Reply-To: "OpenStack Development Mailing List (not for usage questions)" ＜openstack-dev@lists.openstack.org＞ Date: Wednesday, April 19, 2017 at 8:45 PM To: "openstack-dev@lists.openstack.org" ＜openstack-dev@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
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: ＜hongbin...@gmail.com＞ To: ＜openstack-dev@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) ＜std...@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.zhiji...@zte.com.cn" ＜hu.zhiji...@zte.com.cn＞ Reply-To: "OpenStack Development Mailing List (not for usage questions)" ＜openstack-dev@lists.openstack.org＞ Date: Wednesday, April 19, 2017 at 8:45 PM To: "openstack-dev@lists.openstack.org" ＜openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe
[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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [daisycloud-core] Meeting minutes for IRC meeting 0800UTC April 14 2017
http://eavesdrop.openstack.org/meetings/daisycloud/2017/daisycloud.2017-04-14-08.00.html B. R., Zhijiang__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Mar. 17 2017
1) Roll Call 2) Cinder/Ceph support 3) Daisy as Kolla image version manager 4) OPNFV: VM/BM Deployment & Functest Integration 5) OPNFV: Escalator Support 6) AoB B. R., Zhijiang__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [daisycloud-core] Meeting minutes for IRC meeting 0800UTC Feb. 17 2017
Minutes: http://eavesdrop.openstack.org/meetings/daisycloud/2017/daisycloud.2017-02-17-08.40.html Minutes (text): http://eavesdrop.openstack.org/meetings/daisycloud/2017/daisycloud.2017-02-17-08.40.txt Log: http://eavesdrop.openstack.org/meetings/daisycloud/2017/daisycloud.2017-02-17-08.40.log.html B. R., Zhijiang__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Feb. 10 2017
1) Roll Call 2) OPNFV: Release Postpone Discuss 3) OPNFV: BM/BM Deployment & Functest Integration 4) OpenStack: Core Code Definition Wind Up B. R., Zhijiang__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [daisycloud-core] Weekly meeting 0800UTC Jan. 27 & Feb. 3 cancelled
Hi Team, Weekly meetings on Jan. 27 & Feb. 3 have been cancelled for Chinese New Year vacation. B. R., Zhijiang__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Jan. 20 2017
1) Roll Call 2) OPNFV: Daisy CI Progress 3) OPNFV: Daisy Support Escalator 4) OpenStack: Core Code Definition Wind Up 5) OpenStack: Choose Kolla Image Version To Deploy/Upgrade B. R., Zhijiang__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
