May 2020 - openstack-discuss - lists.openstack.org

[qa][tempest-plugins] Tempest plugins guide for release, stable branch support, testing etc
by Ghanshyam Mann 08 May '20

08 May '20

Hello Everyone, This is one of the pending items, Tempest team wanted to do. Tempest has more than 70 plugins and 57 are active and in running state. Tempest and its plugins have similar use cases for testing upstream CI/CD as well as the production cloud. There are always question on how we can coordinate and make release, stable branches testing more consistent among all the plugins. To do that, I have documented the policy all plugins can follow along with Tempest. - https://docs.openstack.org/tempest/latest/plugins/index.html The above document includes the plugin creation, releases for start the support for new release or end of support for Extended Maintenance branches, testing the supported stable etc. I will be working on a few of those policy implementations on plugins. One thing I already started is to add the supported stable branch job on plugins master gate. Few plugins like neutron, ironic, heat, Octavia already doing this but not all. - https://review.opendev.org/#/q/topic:stable-testing-tempest-plugins+(status… This document will be improved with more items and more best practices we can use for writing tests among all the plugins. One of the pending items I can think is to make the plugins service clients stable interface for other plugins so that integrated testing among plugins can be done in a more consistent and reliable way. All the plugins can register their service clients in Tempest and other plugins can detect them from Tempest itself. Tempest already provide the central framework to do that. -gmann

1 0

[tc] ptg etherpad
by Mohammed Naser 08 May '20

08 May '20

Hi everyone, Please have a look at the following Etherpad and try to fill it out with any suggested topics as well as attendance in order to gauge how much time we will need at the PTG: https://etherpad.opendev.org/p/tc-victoria-ptg Thank you, Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 1

[Tempest][Restack]Call for help on 2020:06 Certificaion
by prakash RAMCHANDRAN 08 May '20

08 May '20

Hi all, Appreciate all your inputs in mail and one-on-one conversations I had with few of you. Like to set proper expectations before we deal with extending our goals. First we must deliver on continuity of Refstack, while we evaluate the value it adds to end users through survey. I. Every Release - There is a new criterion for Certification - Do we have one for 2020.06? - Who has volunteered or would like to volunteer for this effort? II. Can we have previous WG Chair or anyone can brief us (by call or by email ) as what the process was and how it was managed. |||. Who were last release OSF Reviewers? Can they volunteer for 2020:06 release definition for Refstack - https://opendev.org/openstack/refstack/ VI. Given the circumstances (CoViD-19) will it be possible to deliver Refstack in June /July 2020? (Need some estimates from TC or others who managed this in past years) V. Is Zun - ?, Magnum -? Are both OCI and/or CNI compliant? - Can they be tested using Tempest and add those two or any other container projects to refstack core? For Survey (suggest any specifics Questions to ask- may be few questions to - Customer / Vendors/ new feedback Q1-Value of Certification , Q2. How Often customers ask for it in RFP or sales cycle?, Q3. What additional Tests, process, frequency etc will add value for them?Q4. Do you think we should continue the efforts of Refstack?) Let me know through email and have added this to TC meeting for Thursday April 2.https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting ThanksPrakash Sent from Yahoo Mail on Android

2 1

[tripleo] TripleO CI Summary: Unified Sprint 26
by Rafael Folco 08 May '20

08 May '20

Greetings, The TripleO CI team has just completed **Unified Sprint 26** (Apr 17 thru May 06). The following is a summary of completed work during this sprint cycle [1]: - Ussuri branching prep work: container/image builds, job definitions and shifted periodic pipelines. - Contributed for TripleO-Operator-Ansible. - Initial design for the internal component pipeline prep work: resolved dependencies and requirements to build the pipeline. Successfully built RHEL8 OSP containers. - Started migrating promoter jobs to CentOS8. Converted molecule delegated jobs to run on tox environment (WIP - code needs a few fixes and consolidation). - Resumed work on an upstream standalone TLS job. - Resumed work to validate ansible 2.9 and the latest ceph-ansible. - Ruck/Rover recorded notes [2]. The planned work for the next sprint [3] extends the work started in the previous sprint and focuses on the following: - Stable branching work (ussuri). - TripleO-Operator-Ansible: contribute w/ code, docs, tests and zuul jobs. - Internal component pipeline: create basic standalone and baremetal jobs. - Continue vexxhost migration and zuul reproducer (on-going) work. - Fix promoter tests on CentOS8 and build an internal promoter server. - TripleO IPA multinode job merge. - Build CentOS8 train full promotion pipeline and a job to upgrade from train to ussuri. The Ruck and Rover for this sprint are Rafael Folco (rfolco) and Bhagyashri Shewale (bhagyashris). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes to be tracked in etherpad [4]. Thanks, rfolco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-26 [2] https://hackmd.io/1pY-KQB_QwOe-a-5oEXTRg [3] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-27 [4] https://hackmd.io/2MdkNAUuT7aBcM0Yck4xnw

1 0

[TripleO][Manila] 'DEFAULT/network_plugin_ipv6_enabled' parameter - why is it not simply enabled by default?
by Harald Jensås 08 May '20

08 May '20

Hi, I'm working on a change to remove some parameters related to IPv6 in TripleO. This is to simplify/automate the process for operators, and reduce failures due to user error. See: https://review.opendev.org/723898 I'm not sure what to do about the 'ManilaIPv6' parameter in TripleO. It control's the *DEFAULT/network_plugin_ipv6_enabled* parameter as well as *${share_backend_name}/network_plugin_ipv6_enabled* for some backends. Dockstrings [2] and [3] in the puppet module for these backends says the same as the Manila doc[1]. A note in Manilla doc[1] reading: """ The ip version of the share network is defined by the flags of network_plugin_ipv4_enabled and network_plugin_ipv6_enabled in the manila.conf configuration since Pike. The network_plugin_ipv4_enabled default value is set to True. The network_plugin_ipv6_enabled default value is set to False. If network_plugin_ipv6_enabled option is True, the value of network_plugin_ipv4_enabled will be ignored, it means to support both IPv4 and IPv6 share network. """ Is there a downside in simply enabling IPv6 by default in Manila? Why is this option present at all? [1] https://docs.openstack.org/manila/latest/admin/shared-file-systems-network-… [2] https://opendev.org/openstack/puppet-manila/src/branch/master/manifests/bac… [3] https://opendev.org/openstack/puppet-manila/src/branch/master/manifests/bac… -- Harald Jensås

2 2

[cinder] RC-3 released
by Brian Rosmaita 08 May '20

08 May '20

Just for awareness: we cut a RC-3 yesterday in order to include a backport of Corey Bryant's eventlet fix [0]. So the official Ussuri release of cinder will be based on RC-3. (I'm only mentioning this because at the weekly meeting, it looked like the release would be based on RC-2.) [0] https://review.opendev.org/#/c/725797/

1 0

[openstack/requirements] Horizon image works abnormal because of the conflict bewteen mysqlclient and Django
by YuChengDe 08 May '20

08 May '20

Hello: I have built a horizon image in ussuri version, but it works abnormal due to package mismatch problem. According to Django===2.2.12 from latest upper-constraint.txt, it is not compatible with mysqlclient. Using old version Django===2.1.5 can fix the problem. Could you help me to check the mismatch problem. Many thanks. -- ————————————————————————————— 九州云信息科技有限公司 99CLOUD Inc. 于成德产品开发部邮箱(Email): yu.chengde(a)99cloud.net 手机(Mobile): 13816965096 地址(Addr): 上海市局门路427号1号楼206 Room 206, Bldg 1, No.427 JuMen Road, ShangHai, China 网址(Site): http://www.99cloud.net

2 2

rabbitmq api query
by Satish Patel 07 May '20

07 May '20

Folks, I am just playing with API and getting strange result, may be i am doing something wrong please correct me. [root@aio1-rabbit-mq-container-5233d3c3 root]# rabbitmqctl list_vhosts Listing vhosts ... name /neutron /designate /keystone /aodh / /nova /glance /ceilometer and i have configured monitoring user to query data from API Following works and i am getting data #curl -s http://172.29.239.29:15672/api/vhosts --user monitoring:de4a28d10da980077cea | jq now try to query specific vhosts like nova getting error # curl -s http://172.29.239.29:15672/api/vhosts/nova --user monitoring:de4a28d10da980077cea | jq { "error": "not_authorised", "reason": "Not administrator user" } Even i set full permission, getting same error no_authorised, what i am missing? # rabbitmqctl set_permissions monitoring -p /nova "" "" ""

3 6

[keystone] Core group changes
by Colleen Murphy 07 May '20

07 May '20

Hi team, I'm very pleased to say that Vishakha Agarwal has joined the python-keystoneclient core team! Vishakha has gained a lot of knowledge of the clients in the last few months and this change will help empower her to continue to drive our goals of ensuring all of the clients fully support keystone's APIs. Thanks for taking this on, Vishakha! I also must announce that I've removed Dave Chen from the core list. Dave's responsibilities at his company have not been related to keystone for some time, and although we've been very grateful for the occasional review he gives from time to time, he's let me know he believes it's time to be formally removed. As with every core removal, if life brings him back to keystone we'll gladly welcome him back to the core team. Thanks, Dave, for all your hard work on keystone! Colleen

4 3

[OSSA-2020-005] Keystone: OAuth1 request token authorize silently ignores roles parameter (CVE PENDING)
by Gage Hugo 07 May '20

07 May '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================== OSSA-2020-005: OAuth1 request token authorize silently ignores roles parameter ============================================================================== :Date: May 06, 2020 :CVE: Pending Affects ~~~~~~~ - - Keystone: <15.0.1, ==16.0.0 Description ~~~~~~~~~~~ kay reported a vulnerability in Keystone's OAuth1 Token API. The list of roles provided for an OAuth1 access token are ignored, so when an OAuth1 access token is used to request a keystone token, the keystone token will contain every role assignment the creator had for the project instead of the provided subset of roles. This results in the provided keystone token having more role assignments than the creator intended, possibly giving unintended escalated access. Patches ~~~~~~~ - - https://review.opendev.org/725894 (Rocky) - - https://review.opendev.org/725892 (Stein) - - https://review.opendev.org/725890 (Train) - - https://review.opendev.org/725887 (Ussuri) - - https://review.opendev.org/725885 (Victoria) Credits ~~~~~~~ - - kay (CVE Pending) References ~~~~~~~~~~ - - https://launchpad.net/bugs/1873290 - - http://cve.mitre.org/cgi-bin/cvename.cgi?name=Pending Notes ~~~~~ - - The stable/rocky branch is under extended maintenance and will receive no new point releases, but a patch for it is provided as a courtesy. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEWa125cLHIuv6ekof56j9K3b+vREFAl6zFWsACgkQ56j9K3b+ vRFDnhAArgXdQUnCyckPQciBvxMxQvqhCEhzGH0aQNAmMLaImYUwFhFVVO0DlcNb kt/ynLQLdyi3YnCz1x4VhUXaCh4Rhi9pYkU4LKa/tvJj6anrCSLHmuDD52idkZeB sFslgkh/BGfdM4HcuPLhs4SSaZpI53ASitiOhyjBIN/DmpLUbZgmJ1iz3FfQ3cTB wtjYI4jGCCMq+4POSozWMzeYdL3JzR264jBCRrCw1ErIPjpF4KSOFaH5vqakBnzw Ot7KR7s7FmIwU7LhCuvjgLW3rxwE1g5bz+Qd/97rC1bTx/iPHklQjMP5SoGwmjta Kx1prUaQqFys5Bw93e0cj1Fwn0zNHUjqLs4LZscNbyGRyAZCPREeg2quwBxVUNk9 D6jxW3J2LYIu+ictVV5fnBQd4/+NtxM8ofLDM03QZouUpkNfCHAmW81BYqd2+Pii VbJi5Litz+DHLrAyh0O4zD/PBc5+5zxB2EXEDVEJitqaxQWfogJwJzGe89ULom0I VXMuYOvqaLV9f2JIG6SEBiKrfaUhSgoHTrmznt82KOlsOBMamQUaj5iTqDoDzPD2 LVB2WLABj1cFZsnTFAec1qKwEPXuT0p3Dsb7eyvwsq5aJYS5I2bjK6Q1WcCcqzJF 1b+v0iqW0Qu+Hk4fwvcrqqQMDZ7Q982tT+B7sU8xV4jYBtFLseQ= =iEFE -----END PGP SIGNATURE-----

1 1