Difference between revisions of "CinderAntelopePTGSummary"

Revision as of 16:38, 31 October 2022

Tuesday 18 October

recordings

User survey feedback

https://lists.openstack.org/pipermail/openstack-discuss/2022-October/030843.html https://docs.google.com/spreadsheets/d/1hHC4hg_Zt9FLYYJ7UA9iVomBbExUhhyJd2QpmrriiBQ/edit#gid=0

The user survey feedback comments are summarized in the following 3 sections:

1) Done:

Ceph QoS ==> Done in Zed https://docs.openstack.org/releasenotes/cinder/zed.html (code https://review.opendev.org/c/openstack/cinder/+/820027)
Shared volume ==> Multi-attach (if driver supports it)
"Images deployment" ==> cinder glance_store has been improved over the past few releases; not sure what this means exactly

2) Actionable:

Document HA deployments
Online retyping between different Ceph RBD backends (clusters) ==> Eric will try to look if libvirt supports it now
Improvements on encryption: key rotation, multiple LUKS keys ==> Could explore some ideas

3) Questions:

Real Active/Active ==> What does this mean specifically?
Live migration with Pure iSCSI ==> This should work in new OpenStack releases
Error management:
Better attach/detach cleanup on failure ==> For example not leaving volumes on reserved/detaching?
Better error handling when failed to create/mount/delete ==> User Messages?
Better support for cinder-backup services- especially the filesystem drivers. ==> Bug in driver?
Volume Group expansion ==> Extend volumes? Or more operations (which)?

User survey question review

The details provided by operators in the user survey feedback were vague and the team agreed to revise the questions to yield more useful information in the feedback.

The team proposed some good ideas as follows:

Ask them to provide driver along with protocol
Revise the list to mention driver with protocol for operators to select like NetApp iSCSI, HPE3PAR FC etc
Alphabetical ordering would be good and easy to find relevant driver-protocol combination
Be specific about the feedback, provide release, launchpad bug link if there is an issue

Based on the points, we've revised the user survey feedback questions in the following etherpad.

https://etherpad.opendev.org/p/antelope-ptg-cinder-user-survey-current-questions

SLURP release cadence

The concept of SLURP (Skip Level Upgrade Release Process) was introduced because six month upgrades are difficult infeasible, or undesirable for operators. 2023.1 Antelope will the the first SLURP release of OpenStack. following are some of the details to keep in mind with respect to SLURP and not SLURP releases.

every other release will be considered to be a “SLURP (Skip Level Upgrade Release Process)” release
Upgrades will be supported between “SLURP” releases, in addition to between adjacent major releases
Deployments wishing to move to a one year upgrade cycle will synchronize on a “SLURP” release, and then skip the following “not-SLURP” release
Testing: test upgrade between SLURP releases
Deprecations: deprecation, waiting, and removal can only happen in “SLURP” releases
Data migrations: Part of supporting “SLURP to SLURP” upgrades involves keeping a stable (read “compatible” not “unchanging”) database schema from “SLURP to SLURP”
Releasenotes: https://review.opendev.org/c/openstack/project-team-guide/+/843457

For detailed info: https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html

Cinder well know Encryption Problem

Presentation: https://docs.google.com/presentation/d/1HOHnO9T3BD1KO5uk_y34aWhMs_A5i9ANPn6zIujQxCk/edit

This has been a complex issue to handle and is being discussed since multiple PTGs. There was another topic discussed, "Allocation size vs requested size for specific storage provider like Dell PowerFlex", which had work items that would act as a initial base for the encryption work having the following work items:

Keep two DB fields for the user size and actual size
- requested size -> user size
- allocated size -> real size
Partition the volume and only the partition with user size should be visible inside the VM

The encryption work will follow up on this initial work to implement the following:

Calculate encryption header size to know how much user visible size is in the volume
start encrypting the volume on creation instead of doing it on first attachment

conclusions

action: Sofia to work on the encryption work after the initial base work is completed

Revision as of 16:36, 31 October 2022 (view source) Rajatdhasmana (talk \| contribs) (→‎Cinder well know Encryption Problem) ← Older edit		Revision as of 16:38, 31 October 2022 (view source) Rajatdhasmana (talk \| contribs) (→‎Cinder well know Encryption Problem) Newer edit →
Line 99:		Line 99:

	action: Sofia to work on the encryption work after the initial base work is completed		action: Sofia to work on the encryption work after the initial base work is completed
		+
		+	===Operator hour===