Jump to: navigation, search

Difference between revisions of "CinderCaracalMidCycleSummary"

(→‎recordings)
(→‎recordings)
Line 81: Line 81:
 
** #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 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
 
** #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

Revision as of 14:42, 27 December 2023

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, 2023 (Wednesday) 1400-1600 UTC


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

Session One: R-17: 06 December 2024

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