Jump to: navigation, search

Difference between revisions of "CinderCaracalMidCycleSummary"

(→‎Session One: R-17: 06 December 2024)
(→‎recordings)
 
(11 intermediate revisions by the same user not shown)
Line 14: Line 14:
 
For 2024.2 (Caracal), the Midcycle will happen at:
 
For 2024.2 (Caracal), the Midcycle will happen at:
 
# R-17: 6th December, 2023 (Wednesday) 1400-1600 UTC
 
# R-17: 6th December, 2023 (Wednesday) 1400-1600 UTC
−
# R-7: 14th February, 2023 (Wednesday) 1400-1600 UTC
+
# R-7: 14th February, 2024 (Wednesday) 1400-1600 UTC
  
  
 
Etherpad: https://etherpad.opendev.org/p/cinder-caracal-midcycles
 
Etherpad: https://etherpad.opendev.org/p/cinder-caracal-midcycles
  
−
==Session One: R-17: 06 December 2024==
+
==Session Two: R-7: 14 February 2024==
 +
===recordings===
 +
* Recording for Midcycle 2 (YouTube): https://www.youtube.com/watch?v=kDo4TQ0_heM
 +
<br />
 +
 
 +
We held our second midcycle of the 2024.1 Caracal development cycle on 14th February, 2024 1400-1600 UTC.
 +
 
 +
* Feature reviews
 +
** https://etherpad.opendev.org/p/cinder-2024.1-caracal-features
 +
** We discussed the features are newly proposed to Caracal as well as old ones that couldn't make it into the 2023.2 Bobcat.
 +
** We have a total of 6 features in which 3 of them have dependencies on other patches.
 +
** #action: Review features
 +
 
 +
* os-brick release 22nd Feb, 2024
 +
** Discussed about potential patches that should be focused on for the release
 +
** https://review.opendev.org/c/openstack/os-brick/+/906743
 +
** https://review.opendev.org/c/openstack/os-brick/+/891318
 +
 
 +
* Adding possibility for user facing information in volume types
 +
** Usecase: We want properties like encryption and replication to be user visible
 +
** It is required for some cases where we want to know if the volume created with a particular type, it will be replicated or encrypted
 +
** Currently the user visible extra specs is a way to show it but the properties goes through scheduler so it causes a problem with encryption
 +
*** Handling encryption this way would need code written to make it pass scheduler
 +
** Replication should work when using Cinder replication
 +
*** It is possible that the backend enables replication but doesn't report to cinder about it
 +
** #action: check if anyone using backend encryption?  can we remove it?
 +
** #action: continue the discussion on the mailing list and eventually write a spec mentioning all details
 +
 
 +
* NFS online extend
 +
** Race condition when creating snapshots while extending the volume
 +
** Handled with locks in the generic nfs driver
 +
** need to check if netapp nfs handles this correctly -- NetApp driver team claims that this shouldn't be a problem since snapshots are just a reference copy which is instataneous
 +
 
 +
* Support for "bring your own keys"
 +
** BP: https://blueprints.launchpad.net/cinder/+spec/byok-for-cinder
 +
** Spec: https://review.opendev.org/c/openstack/cinder-specs/+/908750
 +
** The idea is to allow encrypted volume creation with an already existing key in barbican
 +
*** cinder won't be creating the key in this case
 +
** Need to check if this will work correctly with the re-key feature
 +
*** maybe we can tag the volume with byok so we don't re-key in that scenario
 +
** #action: continue discussion on spec
 +
 
 +
* CI compliance check (whoami-rajat)
 +
** http://cinderstats.ivehearditbothways.com/cireport.txt
 +
** Following two things should be correct for the script to generate correct CI reporting information
 +
*** CI name in the volume driver should point to correct wiki page
 +
**** Example of HPE driver: https://opendev.org/openstack/cinder/src/branch/master/cinder/volume/drivers/hpe/hpe_3par_iscsi.py#L140
 +
*** The wiki page should have correct information about CI
 +
**** Example of HPE wiki: https://wiki.openstack.org/wiki/ThirdPartySystems/HPE_Storage_CI
 +
 
 +
* Current gate situation
 +
** Still seeing failures in gate and unstable CI jobs
 +
** zswap support was added in devstack (by default disabled)
 +
*** https://review.opendev.org/c/openstack/devstack/+/890693
 +
*** Doing a query on codesearch, doesn't seem like any job is using it as of now
 +
** nova tracking: https://etherpad.opendev.org/p/nova-ci-failures-minimal
 +
** #action: Rajat to look into opensearch and if we can use it to track our CI failures
 +
 
 +
==Session One: R-17: 06 December 2023==
 
===recordings===
 
===recordings===
 
* Recording for Midcycle 1 (YouTube): https://youtu.be/QSKWA1St97A
 
* Recording for Midcycle 1 (YouTube): https://youtu.be/QSKWA1St97A
Line 27: Line 85:
  
 
* Retiring cinderlib
 
* Retiring cinderlib
 +
** Etherpad: https://etherpad.opendev.org/p/cinderlib-retirement
 +
** Major consumers of Cinderlib are Ember-CSI and oVirt
 +
*** They are happy with old releases of cinderlib and don't require new development work into it
 +
** We will not transition to 2024.1 (Caracal) development
 +
** We will not accept any new patches in cinderlib
 +
** We will support the last 3 stable releases i.e. 2023.2, 2023.1 and Zed (approximately 18 months)
 +
** EM branches will transition to Unmantained (Victoria -> Yoga)
 +
** #action: rosmaita to follow up on work associated with the deprecation
 
* Rework of JovianDSS Driver
 
* Rework of JovianDSS Driver
 +
** Patch: https://review.opendev.org/c/openstack/cinder/+/889284
 +
** Refactoring of an old driver
 +
** #action: Review the patch
 +
 
* NFS online extend
 
* NFS online extend
−
* Two os-brick patches and acceptable usage of `__init__()`
+
** Blueprint: https://blueprints.launchpad.net/cinder/+spec/extend-volume-completion-action
 +
** Patches in order of dependency
 +
*** https://review.opendev.org/c/openstack/cinder/+/873557
 +
**** Add the os-extend-volume-completion volume action
 +
*** https://review.opendev.org/c/openstack/python-cinderclient/+/873558
 +
**** Support the new volume action in python-cinderclient
 +
*** https://review.opendev.org/c/openstack/nova/+/873560
 +
**** Make Nova use the new volume action when handling "volume-extended" events
 +
*** https://review.opendev.org/c/openstack/cinder/+/891602]
 +
**** Make the new feature available for volume drivers
 +
*** https://review.opendev.org/c/openstack/cinder/+/873686
 +
**** Add support in the NFS driver
 +
*** https://review.opendev.org/c/openstack/cinder/+/873889
 +
**** Add support in the Netapp NFS driver
 +
*** https://review.opendev.org/c/openstack/devstack-plugin-nfs/+/896196
 +
**** Enable attached volume extend tests in devstack-plugin-nfs-tempest-full
 +
** Slides to explain the current workflow and the changes going to be made by the feature
 +
*** https://github.com/kgube/cinder-2024.1-midcycle-1/blob/main/nfs_online_resize.pdf
 +
** #action: review the patches (at least ones that are blocking nova side reviews)
 +
 
 +
* acceptable usage of `__init__()` in os-brick
 +
** Patch: https://review.opendev.org/c/openstack/os-brick/+/887576
 +
** Eric's concern is that this code in __init__ shouldn't affect other brick connectors
 +
*** by failing initialization of other connectors
 +
*** by holding the initialization for too long (a heavy weight call to backend)
 +
** The above concerns shouldn't be an issue in this case
 +
** #action: document standards for working on os-brick connectors
 +
 
 
* CI Monitoring
 
* CI Monitoring
 +
** Etherpad: https://etherpad.opendev.org/p/cinder-caracal-ci-tracking
 +
** Lately we have been facing too many CI issues
 +
** There are also issues reported from Nova and Glace team for some cinder related failures
 +
** The actions to fix the CI have mostly been reactive so it would be better to monitor the CI proactively
 +
** Jon Bernard volunteered to actively monitor our CI and integrate it in weekly bug report status
 +
** cinder-tempest-plugin-cbak-s3 history has also been consistently failing
 +
*** https://zuul.opendev.org/t/openstack/builds?job_name=cinder-tempest-plugin-cbak-s3
 +
** swap space increase patch to make gate stable
 +
*** https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/901672
 +
** #action rosmaita - get info from infra team about the nodepool nodes and what kind of control we have over configuration from the zuul side
 +
** #action whoami-rajat: check the blocker for concurrency effort - talk to Luigi as he was working on it some time ago
 +
 
* Supporting AND operation on time comparison filters
 
* Supporting AND operation on time comparison filters
 +
** original spec: https://specs.openstack.org/openstack/cinder-specs/specs/ussuri/query-cinder-resources-filter-by-time-comparison-operators.html
 +
** Patch: https://review.opendev.org/c/openstack/cinder/+/740146
 +
** The change to use AND operator instead of OR seems to be a bug in the original feature fixed by this patch
 +
** Need to verify if any user is not using the OR filter as a feature and we are not breaking backward compatibility
 +
** #action: Verify if the patch has right approach to fix this as a bugfix
 +
** #action: check if this is the case with other APIs (apart from the one mentioned on the ML) like backups, messages etc
 +
 
* Several  patches to the StorPool Cinder driver
 
* Several  patches to the StorPool Cinder driver
 +
** Storpool driver reports multiple pools under one backend
 +
** This can be problematic if we are using image volume cache or cinder as glance backend
 +
** When using the optimized clone path to create a bootable volume from image, we check if the image-volume exists in the same host (host@backend#pool) to clone it from
 +
** The pool part can be different for the image-volume and the new volume to be created skipping the optimized path
 +
** Since storpool driver supports cross pool cloning, it can be reported as a capability which can be leveraged to perform cross pool volume cloning in the optimized path
 +
** The only problem here is this feature shouldn't be added in the support matrix since it might have end users asking other vendors for this feature whereas this feature is a specific case and doesn't provide any benefit in general operations
 +
** #action Review the storpool patch
 +
*** https://review.opendev.org/c/openstack/cinder/+/843277

Latest revision as of 07:43, 15 February 2024

Introduction

Welcome to the Cinder 2024.1 (Caracal) midcycle summary page!

We conduct 2 midcycles between the OpenStack development cycle (6 months) that acts as a checkpoint for the following:

  • Revisiting/following up the topics discussed at PTG
  • Discuss topics that were missed during PTG due to author's unavailability or lack of time or any other reason
  • Status of work items based on the milestone


There could be more reasons but the above highlighted are the major ones.

For 2024.2 (Caracal), the Midcycle will happen at:

  1. R-17: 6th December, 2023 (Wednesday) 1400-1600 UTC
  2. R-7: 14th February, 2024 (Wednesday) 1400-1600 UTC


Etherpad: https://etherpad.opendev.org/p/cinder-caracal-midcycles

Session Two: R-7: 14 February 2024

recordings


We held our second midcycle of the 2024.1 Caracal development cycle on 14th February, 2024 1400-1600 UTC.

  • Feature reviews
  • Adding possibility for user facing information in volume types
    • Usecase: We want properties like encryption and replication to be user visible
    • It is required for some cases where we want to know if the volume created with a particular type, it will be replicated or encrypted
    • Currently the user visible extra specs is a way to show it but the properties goes through scheduler so it causes a problem with encryption
      • Handling encryption this way would need code written to make it pass scheduler
    • Replication should work when using Cinder replication
      • It is possible that the backend enables replication but doesn't report to cinder about it
    • #action: check if anyone using backend encryption? can we remove it?
    • #action: continue the discussion on the mailing list and eventually write a spec mentioning all details
  • NFS online extend
    • Race condition when creating snapshots while extending the volume
    • Handled with locks in the generic nfs driver
    • need to check if netapp nfs handles this correctly -- NetApp driver team claims that this shouldn't be a problem since snapshots are just a reference copy which is instataneous

Session One: R-17: 06 December 2023

recordings


We held our first mid cycle of the 2024.1 (Caracal) development Cycle on 6th December (R-17 week) between 1400-1600 UTC.

  • Retiring cinderlib
    • Etherpad: https://etherpad.opendev.org/p/cinderlib-retirement
    • Major consumers of Cinderlib are Ember-CSI and oVirt
      • They are happy with old releases of cinderlib and don't require new development work into it
    • We will not transition to 2024.1 (Caracal) development
    • We will not accept any new patches in cinderlib
    • We will support the last 3 stable releases i.e. 2023.2, 2023.1 and Zed (approximately 18 months)
    • EM branches will transition to Unmantained (Victoria -> Yoga)
    • #action: rosmaita to follow up on work associated with the deprecation
  • Rework of JovianDSS Driver
  • acceptable usage of `__init__()` in os-brick
    • Patch: https://review.opendev.org/c/openstack/os-brick/+/887576
    • Eric's concern is that this code in __init__ shouldn't affect other brick connectors
      • by failing initialization of other connectors
      • by holding the initialization for too long (a heavy weight call to backend)
    • The above concerns shouldn't be an issue in this case
    • #action: document standards for working on os-brick connectors
  • Several patches to the StorPool Cinder driver
    • Storpool driver reports multiple pools under one backend
    • This can be problematic if we are using image volume cache or cinder as glance backend
    • When using the optimized clone path to create a bootable volume from image, we check if the image-volume exists in the same host (host@backend#pool) to clone it from
    • The pool part can be different for the image-volume and the new volume to be created skipping the optimized path
    • Since storpool driver supports cross pool cloning, it can be reported as a capability which can be leveraged to perform cross pool volume cloning in the optimized path
    • The only problem here is this feature shouldn't be added in the support matrix since it might have end users asking other vendors for this feature whereas this feature is a specific case and doesn't provide any benefit in general operations
    • #action Review the storpool patch
Retrieved from "https://wiki.openstack.org/w/index.php?title=CinderCaracalMidCycleSummary&oldid=184384"