Jump to: navigation, search

Difference between revisions of "CinderWallabyMidCycleSummary"

m (Block Storage API v2 removal)
m (Block Storage API v2 removal)
Line 59: Line 59:
 
======actions======
 
======actions======
 
* rosmaita - general announcement to the ML
 
* rosmaita - general announcement to the ML
 +
====how much v2 code must be removed from Cinder in Wallaby?====
 +
* We need to remove the v2 endpoint.
 +
* v3 uses a lot of v2 classes, which we'll eventually want to refactor.  Before doing this, though, we need to verify that there is good v3 test coverage.
 +
* documentation
 +
** remove the v2 api-ref
 +
** refactor the api-ref functional tests to handle only v3
 +
** make sure the general documentation does not contain references to any v2-specific stuff
 +
====cinder-tempest-plugin====
 +
=====actions=====
 +
rosmaita - tag if necessary and then patch to make sure it only runs v3
 +
====python-cinderclient====
 +
We already announced on the ML that we'd be removing v2 support in Wallaby:
 +
* http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018531.html
 +
* http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018697.html
 +
* http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018876.html
 +
 +
 +
This has to happen before the client library freeze, which is the week of 8 March.
 +
 +
The cinderclient is structured similar to the Block Storage API in that a lot of v2 classes are reused for v3 functionality.  This may make removing v2 functionality from the CLI tricky.
 +
=====actions=====
 +
somebody - needs to dig in and see what needs to happen
  
 
===consistent and secure policies===
 
===consistent and secure policies===

Revision as of 02:54, 10 December 2020

Introduction

At the Wallaby Virtual PTG we decided to hold two mid-cycle meetings, each two hours long. The first meeting would be before the Cinder Spec Freeze, and the second would be around the New Feature Status Checkpoint. So the mid-cycle meetings will be the week of R-18 and the week of R-9.

Session One: R-18: 9 December 2020

We met in BlueJeans from 1400 to 1600 UTC.
etherpad: https://etherpad.openstack.org/p/cinder-wallaby-mid-cycles
recording: https://www.youtube.com/watch?v=rKmlpBTIDGA

Cinder Project Updates

upcoming deadlines

  • 18 December - spec freeze
  • 21 January - Wallaby Milestone-2 and new driver merge deadline
  • 1 March - os-brick wallaby release
  • 8 March - python-cinderclient wallaby release

stable releases

Our current release cadence on the stable branches is (roughly) every two months. We've recently released:

  • os-brick: 4.1.0 (wallaby), 3.0.4 (ussuri)
  • cinder: 17.0.1 (victoria), 16.2.1 (ussuri), 15.4.1 (train)

We managed to slip a critical fix past the Train gate, but three or four other patches that had been approved and targeted for 15.4.1 are stuck in the gate. Once we get the Train gate sorted out, we'll most likely do an extra release from stable/train out of cadence.

end of year meetings

The last meeting of the year will be 23 December. Being also the last meeting of the month, it will be held in videoconference. We won't meet on 30 December.

requirements/lower-constraints update

The lower-constraints job was broken recently by a pip update that included a new dependencies resolver that is apparently more strict than the old one, and as a result, it was detecting incompatible constraints from cinder specifying a lower constraint for some libraries than its dependencies allowed as a minimum. We started to change the values in lower-constraints.txt one by one, and it became pretty obvious that a larger change was needed. So we merged this patch yesterday: https://review.opendev.org/c/openstack/cinder/+/766085

That patch raised the minimums in requirements.txt to the versions in a pip freeze of a recent py38 testenv and raised the values in lower-constraints.txt accordingly. This included some big jumps in major versions for some libraries, but it does bring our lower-constraints.txt much closer to reality. The lower-constraints job just uses the lower-constraints.txt as constraints and basically checks to make sure the requirements can be satisfied and runs unit tests. Since functional and tempest tests and the third party CIs are using versions of libraries much closer to the openstack upper-constraints, that left a big gap between what we were claiming as lower constraints and what was actually being tested.

actions
  • rosmaita - look into what exactly is the function of lower-constraints; it was supposed to be a guideline for packagers, but we need to keep a balance between what's claimed and what's actually being tested
  • driver maintainers - check the values in setup.cfg for dependencies used by your driver and make sure that the minimum isn't too low; also make sure the values in driver-requirements.txt are consistent with setup.cfg (setup.cfg is what's actually used; the driver-requirements.txt is a legacy convenience file for packagers)

Block Storage API v2 removal

The goal of this session was to make a list of task/owner/completion dates so we can move this along and get it done during this cycle. Ivan (e0ne) is acting as v2 removal coordinator.

other projects using v2

tempest

Whether tempest uses v2 or not is controlled by a variable. Tempest has a tempest-cinder-v2-api job: https://opendev.org/openstack/tempest/src/commit/dd84940a81316129bb6adccf7ae4b5cdcbb37382/zuul.d/project.yaml#L123 At some point during Wallaby, tempest will no longer be able to run this job against cinder master.

action
  • rosmaita - talk to gmann about this and figure out how he wants to handle the change
grenade
action
  • e0ne - is looking into this
devstack
actions
other services

Ivan pointed out that when we removed the v1 API, several other services broke even though all the cinder tests were passing. So we need to test horizon, nova, glance, and heat gates when v2 is disabled.

actions
openstackclient, openstackSDK

Give them a heads-up that if they plan to continue Block Storage API v2 support, they'll have to make arrangements to test against an older cinder release.

actions
  • rosmaita - contact [osc][sdk] on the ML
others?
actions
  • rosmaita - general announcement to the ML

how much v2 code must be removed from Cinder in Wallaby?

  • We need to remove the v2 endpoint.
  • v3 uses a lot of v2 classes, which we'll eventually want to refactor. Before doing this, though, we need to verify that there is good v3 test coverage.
  • documentation
    • remove the v2 api-ref
    • refactor the api-ref functional tests to handle only v3
    • make sure the general documentation does not contain references to any v2-specific stuff

cinder-tempest-plugin

actions

rosmaita - tag if necessary and then patch to make sure it only runs v3

python-cinderclient

We already announced on the ML that we'd be removing v2 support in Wallaby:


This has to happen before the client library freeze, which is the week of 8 March.

The cinderclient is structured similar to the Block Storage API in that a lot of v2 classes are reused for v3 functionality. This may make removing v2 functionality from the CLI tricky.

actions

somebody - needs to dig in and see what needs to happen

consistent and secure policies

Windows RBD os-brick connector

review of proposed specs