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

[neutron] Team meeting on Monday 25.05.2020 cancelled
by Slawek Kaplonski 25 May '20

25 May '20

Hi, As today is the Memorial Day in the USA, and many from team members are on holidays, lets cancel today's team meeting. Next week there is virtual PTG so we will meet there :) -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[swift] Rolling upgrade, any version relationships?
by Mark Kirkwood 24 May '20

24 May '20

Hi, we are looking at upgrading our 2.7.0 Swift cluster. In the past I've modeled this on a dev system by upgrading storage nodes one by one (using 2.17 as the target version). This seemed to work well - I deliberately left the cluster half upgraded for an extended period to test for any cross version weirdness (didn't see any). However I'm wanting to check that I have not missed something important. So my questions are: - If upgrading from 2.7.0 is it safe to just grab the latest version (e.g 2.23)? - If not is there a preferred version to jump to first? - Is it ok for the upgrade to take extended time (e.g weeks) and therefore be running with some new and some old storage nodes for that time? regards Mark

3 5

[keystone][devstack][openstackclient] Problem with Keystone setup in stable/ussuri devstack install
by Neil Jerram 22 May '20

22 May '20

+ ./stack.sh:main:1091 : create_keystone_accounts + lib/keystone:create_keystone_accounts:314 : local admin_project ++ lib/keystone:create_keystone_accounts:315 : oscwrap project show admin -f value -c id WARNING: Failed to import plugin identity. ++ functions-common:oscwrap:2370 : return 2 + lib/keystone:create_keystone_accounts:315 : admin_project='openstack: '\''project show admin -f value -c id'\'' is not an openstack command. See '\''openstack --help'\''. I believe this is a completely mainline Keystone setup by devstack. The top-level stack.sh code is echo_summary "Starting Keystone" if [ "$KEYSTONE_AUTH_HOST" == "$SERVICE_HOST" ]; then init_keystone start_keystone bootstrap_keystone fi create_keystone_accounts ... bootstrap_keystone succeeded but create_keystone_accounts failed as shown above, trying to execute openstack project show "admin" -f value -c id IIUC, the rootmost problem here is "WARNING: Failed to import plugin identity.", indicating that python-openstackclient is failing to import its openstackclient.identity.client module. But I don't know any more about why that would be. Any ideas? Many thanks, Neil

2 3

[all][qa] Gate Status: week 20-21
by Ghanshyam Mann 22 May '20

22 May '20

Hello Everyone, I am highlighting the few of the gate issues we fixed or in-progress recently in case you are facing the same in your projects gate or 3rd party CI. 1. Bug# 1880219. A job using older Tempest (ubuntu xenial node jobs) on stable stein onwards gate or 3rd party CI fail. This is failing the same type of job I reported a few weeks back but with different issues and happening on 3rd party CI as I have not seen such a job or failure on upstream yet. I am reproducing the scenario to test the fixes[1]. Earlier issue[2] was fixed by using the older Tempest. Now it started failing as we use the master constraint on stein and train and master constraints are no more compatible with older Tempest[3]. The solution for this will be to use stable constraints if older Tempest is not used. This fix needs modification on devstack as well as the tempest side. Devstack changes[4] working fine but I need to fix it on the Tempest side also. 2. Bug#1880217. In-tree Tempest plugins python2 jobs on stable/stein or Train failing This might be a rare case but still possible as we do have in-tree plugins for older stable branches. For in-tree plugins (in case it's still present even we migrated most of the tempest plugins into separate repo ), 'all-plugins' tox env which is supposed to detect the system-wide installed plugins will not work now for python2.7 jobs. This is because Tempest is now py3-only and so create py3 venv even on py2 jobs. 'all-plugins' venv which is py3 no longer detect the tempest plugins installed as python2.7 site-packages. Failure example: https://zuul.opendev.org/t/openstack/build/7d3f36f464bb4642bb1647f4b0b8e91f… If you encounter this issue then a quick fix for that will be to install the in-tree plugins in Tempest venv via TEMPEST_PLUGINS and run tests with 'all' tox venv. Example: https://review.opendev.org/#/c/730378/2 3. hacking fix for new flake8 3.8.0 merged in master might need to be backported to stable branches also but not for all projects. But to have a safe guard against future flake8 3.9.0(which can also cause same issue), you can backport the hacking min version fix: - http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014828.html Have a happy weekend and feel free to append more gate bugs here you have encountered or fixed recently. [1] https://review.opendev.org/#/c/729611/3 [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014601.html [3] https://review.opendev.org/#/c/720264/ [4] https://review.opendev.org/#/c/729722/6 -gmann

1 0

[swift] Erasure code hardware offloading
by Mark Kirkwood 22 May '20

22 May '20

Hi, Can Swift make use of an Erasure Code offload card (e.g https://community.mellanox.com/s/article/understanding-erasure-coding-offlo… regards Mark

2 1

[charms] Propose Aurelien Lourot for OpenStack Charms core
by Frode Nordahl 22 May '20

22 May '20

Hello all, I would like to propose adding Aurelien Lourot as core developer for the Charms project. -- Frode Nordahl

4 3

[release] Release countdown for week R-20, May 25 - 29
by Sean McGinnis 22 May '20

22 May '20

Welcome back to the release countdown emails! These will be sent at major points in the Victoria development cycle, which should conclude with a final release on October 16, 2020. Development Focus ----------------- At this stage in the release cycle, focus should be on planning the Victoria development cycle, assessing Victoria community goals and approving Victoria specs. General Information ------------------- Victoria is a 22 week development cycle, which is already underway. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/victoria/schedule.html By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the Ussuri release are continued in the Victoria series with a similar release model. If you intend to drop a deliverable, or modify its release model, please do so before the victoria-1 milestone by proposing a change to the deliverable file at: https://opendev.org/openstack/releases/src/branch/master/deliverables/victo… Upcoming Deadlines & Dates -------------------------- Virtual Victoria PTG: June 1-5 Victoria-1 milestone: June 18

1 0

[neutron][operators]
by Dincer Celik 22 May '20

22 May '20

Hi, You know in public cloud world, most users prefer using VPCs (aka tenant networks for us), and when they need to connect two separate VPC, they have VPC peering functionality. For OpenStack, we have routers, RBACs, static routes and floating IPs, but there is nothing functioning like a real VPC peering. I see this was discussed at Stein PTG[1] under L3 topics but seems there is no progress about it. So I would like to ask what is the most common way to let two separate tenant networks under different accounts talk to each other? Thanks! Dincer [1] https://etherpad.opendev.org/p/neutron-stein-ptg

1 0

[charms] OpenStack Charms 20.05 release is now available
by Peter Matulis 21 May '20

21 May '20

The OpenStack Charms team is happy to announce the 20.05 charms release, introducing support for OpenStack Ussuri and Ceph Octopus on Ubuntu 18.04 LTS and Ubuntu 20.04 LTS. This release also brings several new and valuable features to the existing OpenStack Charms deployments for Queens, Rocky, Stein, Train, Ussuri and many other stable combinations of Ubuntu + OpenStack. Please see the Release Notes for full details: https://docs.openstack.org/charm-guide/latest/2005.html == Highlights == * OpenStack Ussuri OpenStack Ussuri is now supported on Ubuntu 18.04 LTS (via UCA) and Ubuntu 20.04 LTS natively. * Ceph Octopus The Octopus release of Ceph is now supported, starting with OpenStack Ussuri. * New charms: MySQL 8 The MySQL 8 charms (mysql-innodb-cluster and mysql-router) have been promoted to supported status. These charms allow for a completely native cloud database HA cluster (no need for the hacluster charm). The legacy solution (percona-cluster charm) is not supported on Ubuntu 20.04 LTS. Migration documentation is available. * New charms: Masakari The Masakari charms (masakari and masakari-monitors) and the requisite pacemaker-remote charm have been promoted to supported status, starting with OpenStack Stein. Masakari provides automated recovery of OpenStack instances (shared storage required). * New charms: OVN The OVN charms (neutron-api-plugin-ovn, ovn-central, ovn-chassis, and ovn-dedicated-chassis) have been promoted to supported status. OVN provides virtual networking for Open vSwitch and is the preferred default for new deployments of OpenStack Ussuri. * Ceph iSCSI Ceph iSCSI gateway functionality is available as a tech preview. These gateways provide iSCSI targets backed by a Ceph cluster. == OpenStack Charms team == The OpenStack Charms team can be contacted on the #openstack-charms IRC channel on Freenode. == Thank you == Lots of thanks to the below 67 charm contributors who squashed 89 bugs, enabled support for a new release of OpenStack, improved documentation, and added exciting new functionality! James Page Alex Kavanagh Frode Nordahl Liam Young Peter Matulis David Ames Corey Bryant Chris MacNaughton Ghanshyam Mann Aurelien Lourot Sahid Orentino Ferdjaoui Stamatis Katsaounis Ryan Beisner inspurericzhang Tiago Pasqualini Andrew McLeod ShangXiao Edward Hope-Morley Felipe Reyes kangyufei Adam Dyess Andreas Jaeger wangfaxin Xuan Yandong Arif Ali José Pekkarinen Chris Johnston Hemanth Nakkina Alexandros Soumplis Jose Guedez Qitao Tytus Kurek Seyeong Kim Dmitrii Shcherbakov Dongdong Tao Drew Freiberger Haw Loeung Jorge Niedbalski Andrea Ieri Xav Paice Qiu Fossen Yanos Angelopoulos Syed Mohammad Adnan Karim JiaSiRui Sérgio Filipe Marques Manso Vladimir Grevtsev George Kraft Marco Filipe Moutinho da Silva Xiyue Wang Adam Dyess Jose Delarosa Alexander Balderson Facundo Ciccioli Jacek Nykis Eduardo Sousa Thobias Trevisan Rodrigo Barbieri Alejandro Santoyo Gonzalez Sean McGinnis Claudio Pisa Shuo Liu Matus Kosut Stephen Muss Camille Rodriguez zhangboye Aggelos Kolaitis Nicolas Bock -- OpenStack Charms Team

2 1

[neutron] Drivers meeting 22.05.2020
by Slawek Kaplonski 21 May '20

21 May '20

Hi, Due to lack of agenda for the next drivers meeting, lets cancel it this week. See You all next week. BTW. Please maybe check Nate's email [1] - this isn't exactly RFE but something which IMO drivers team should check too :) [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014820.html -- Slawek Kaplonski Senior software engineer Red Hat

1 0