Jump to: navigation, search

Difference between revisions of "CinderCaracalMidCycleSummary"

(→‎Session Two: R-7: 14 February 2024)
(→‎Session Two: R-7: 14 February 2024)
Line 47: Line 47:
 
** #action: continue the discussion on the mailing list and eventually write a spec mentioning all details
 
** #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==
 
==Session One: R-17: 06 December 2023==

Revision as of 23:11, 14 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

  • Recording for Midcycle 2 (YouTube):


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=184383"