CinderDalmatianPTGSummary

Introduction

The Ninth virtual PTG for the 2024.2 (Dalmatian) cycle of Cinder was conducted from Tuesday, 9th April, 2024 to Friday, 12th April, 2024, 4 hours each day (1300-1700 UTC). This page will provide a summary of all the topics discussed throughout the PTG.

Cinder 2024.2 (Dalmatian) Virtual PTG 10 April 2024

This document aims to give a summary of each session. More information is available on the cinder 2024.2 Dalmatian PTG etherpad:

• https://etherpad.opendev.org/p/dalmatian-ptg-cinder

The sessions were recorded, so to get all the details of any discussion, you can watch/listen to the recording. Links to the recordings for each day are below their respective day's heading.

Tuesday 9 April

TODO

Wednesday 10 April

TODO

Thursday 11 April

Add Active-Active support for NetApp iSCSI/FCP drivers

• As part of this release, we will implement active-active support for NetApp iSCSI and FCP drivers. This will allow users to configure NetApp iSCSI/FCP backends in cinder clustered environments.
• failover and failover_completed methods will be implemented as proposed in this spec https://specs.openstack.org/openstack/cinder-specs/specs/ocata/ha-aa-replication.html
• geguileo: Sounds good, and they already have experience since they did it for the NFS driver
• Mind the release schedule and deadlines (feature freeze)

Discuss bug https://bugs.launchpad.net/cinder/+bug/2060830

• create volume from volume/snapshot creates a lock with delete_volume
• operations are serialized due to single lock for clone operations
• lock prevents source volume from being deleted during operation (same for snapshots)
• other operations managed by status field to handle this
• why do we use a shared lock for this particilar one?
• we could update the status as with other operations
• problem: no reference counting for nested operations, no way to reach original state
• gorka empathizes
• a read-write lock would be quite approproate for this case
• tooz makes this ^ complicated
• consensus growing around cinder-specific solution using the DB to implement a rw-lock
• DB will be mysql/mariadb as it's the one we officially support
• alternative is to set status field and implement ref counts, not ideal but consistent with code base
• #action: revisit in upstream meeting if anyone interested can assemble a solution using db locking semantics

Volume encryption with user defined keys

• Spec: https://review.opendev.org/c/openstack/cinder-specs/+/914513/1
• Cinder currently lags support the API to create a volume with a predefined (e.g. already stored in Barbican) encryption key.
• Meeting Notes:
  • The idea is to create volumes from pre-existing keys from barbican
  • The preferred way is to ask cinder to create an encrypted volume and cinder communicates with barbican to create the key
  • Cinder creates the passphrase by converting the barbican key into a hex value (binascii.hexlify())
  • The user will not be able to decrypt the volume with their keys in barbican since they need to mimic cinder's procedure for encryption using the custom passphrase as long as Cinder strictly transforms it using binascii.hexlify() like it does currently
  • here's the info about the secret types:
    • https://docs.openstack.org/barbican/latest/api/reference/secret_types.html
    • https://docs.openstack.org/cinder/latest/contributor/contributing.html (it outlines how we work and the role of specs, etc)
  • The proposal is to have the development in parallel of
    • 1. API change to allow creating volumes with pre-existing secret in barbican
      • implement passing Barbican secret ids during volume creation API call and skip secret order create done by Cinder internally
      • but check received secrets in regards to their metadata (cipher, mode, bit length) to be compatible with the volume type's encryption specification
        • (which Cinder didn't need to do before since it always created secrets itself in a closed ecosystem)
    • 2. support for "passphrase" secret types from Barbican which will circumvent Cinder's binascii.hexlify() conversion and used as passphrases as-is in Cinder
      • currently only "symmetric" is supported, which is transformed using binascii.hexlify() by Cinder before passing it to LUKS
  • need to review the documentation around this, particularly, what an encryption type is and what the fields are used for (admin facing), and also what needs to be supplied as end user facing docs

Review CI updates

https://review.opendev.org/q/topic:%22dalmatian-ci-update%22

Friday 12 April

TODO