)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":9535,"name":"Gorka Eguileor","email":"geguileo@redhat.com","username":"Gorka"},"change_message_id":"04f39bbf5df0e8cf9ba9441975081545c1528b7a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"abcf0dc9_d930abdd","updated":"2024-04-03 14:24:21.000000000","message":"Thanks David for the submission.\n\nI believe the patch still needs some work:\n- It\u0027s missing release notes\n- Should update the RBD driver doc to indicate support for the feature\n- Calls to `copy` should also pass the `data_pool` parameter\n- I believe calls to `copy` also need the parameter.\n- Preferably the backup driver should also include support for this feature to keep both in sync\n\nI also have a couple of questions:\n- Should we check if the pool has the feature enabled or is the resulting error meaningful enough for a system admin to know that Cinder is misconfigured?\n- I know the data_pool parameter was added a very long time ago to the python library, but should we check if the python library version supports it before trying to use it?","commit_id":"c0b2f27cf048afd6f716b638a0156029000ecefe"},{"author":{"_account_id":7130,"name":"David Hill","email":"davidchill@hotmail.com","username":"dhill"},"change_message_id":"23b8cb9f0b120559fe24d3cf41e7b29edef5a607","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"f20f411e_c6778c7a","in_reply_to":"abcf0dc9_d930abdd","updated":"2024-04-03 23:03:44.000000000","message":"With the patch we get:\n2024-04-03 13:32:44.951 11 ERROR cinder.volume.manager rbd.OperationNotSupported: [errno 95] RBD operation not supported (error creating image)\n2024-04-03 13:32:44.951 11 ERROR cinder.volume.manager \n\nbut customer forgot to set rbd_data_pool to the expected value... this means the rbd_data_pool\u003dNone doesn\u0027t appear to work like I expected it to work with librados.\n\n\nWithout the patch, customer\u0027s getting this error:\n     \u0027  File \"rbd.pyx\", line 630, in rbd.RBD.create\\n\u0027, \u0027rbd.InvalidArgument: [errno 22] RBD invalid argument (error creating image)\\n\u0027]","commit_id":"c0b2f27cf048afd6f716b638a0156029000ecefe"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"fb9972432b9865c2f0b437d0f1f9608924909bd7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":13,"id":"91dda53c_251e7494","updated":"2025-05-14 15:05:55.000000000","message":"I\u0027m not really convinced with the IMPACT of the changes and the documentation we have currently.\na. this patch doesn\u0027t mention the use case currently, do we want to save space by keeping RBD images in a data pool (erasure coded) and metadata in volumes pool (replicated), what we will do about the legacy images and how do we migrate them?\nb. erasure coded pools require parity calculation which is CPU intensive so we also need to document the deployment impact on the ceph cluster side.\nIf a storage node hosting OSDs with data pools, we need to allocate more memory and CPUs to it for the parity calculation.\nc. There is no performance calculation i can find, are erasure coded pools really worth the performance drop compared to replicated pools?","commit_id":"13fe212476c0f93f4b0e92719e69fc42a8ad5fbf"},{"author":{"_account_id":16137,"name":"Tobias Urdin","email":"tobias.urdin@binero.com","username":"tobasco"},"change_message_id":"1538db9cca185c8d8de773e52fb974b26c5714a4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":13,"id":"a4b34b7b_a186227c","in_reply_to":"91dda53c_251e7494","updated":"2025-05-15 09:59:46.000000000","message":"a. The use case is straightforward, in Ceph RBD if you want to use an erasure-coded pool for an image you MUST specify that as the data pool for the image, if you try to specify it as the pool for the image you will get an ``Invalid Argument`` error back, the pool on an image MUST be a replicated pool.\n\nThe data pool ONLY holds data, no operations are performed against the pool when managing/doing operations on the image. The pool for the image (where metadata is stored if a data pool is specified) is where you list, retrieve info and perform *all* other operations against the image, so there is no change there.\n\nIn Cinder this is pretty small, pass ``data_pool`` as ``None`` or as the name of a pool when creating, copying, cloning or importing to an image, and some extra logic to save/retrieve the data pool in the location info for a volume.\n\nFor the Ceph backup driver the use case is more obvious, storing large amounts of cold data is better if we can set a data pool and thus use erasure coding to lower storage costs.\n\nb. That is true, using an erasure coded pool comes with more considerations on CPU utilization and also the block.db usage will increase on the Ceph OSD side, but I fail to see how that is relevant for Cinder as that is something the operator of the Ceph cluster should be planning/aware of.\n\nc. Same as above, I don\u0027t see the relevance to Cinder. Do we provide performance charts and recommendations for all drivers somewhere? I can be more clear with a warning/note in the documentation about erasure coding, but a data pool can also be used for other cases than erasure coding (even though I myself don\u0027t see why one would need that).\n\nThis simply bridges a cap in RBD drivers to support the RBD data pool concept that we do not support today, that we support erasure coding by adding that support is a plus.","commit_id":"13fe212476c0f93f4b0e92719e69fc42a8ad5fbf"},{"author":{"_account_id":35789,"name":"Yuta Kambe","email":"yuta.kambe@fujitsu.com","username":"yuta.kambe@fujitsu.com"},"change_message_id":"3b7cde4a91a109e5844d951df181d60686210d39","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":13,"id":"fcfde9bd_79220bd4","in_reply_to":"a4b34b7b_a186227c","updated":"2025-08-01 09:31:09.000000000","message":"@rajatdhasmana@gmail.com\nCould you please let me know if there are any remaining concerns regarding this patch?\n\nWith support for Erasure Coded Pools, users will be able to use a cluster as a backend for Cinder with lower costs, such as for cold storage.\nI believe this would be a positive development for users.\n\nThe Ceph cluster I built, it was initially operated with an Erasure Coded Pool, but due to issues I posted on the mailing list [1], I had to switch to a Replicated Pool.\n\nFor legacy images, if users want to change an existing Replicated Pool to an Erasure Coded Pool, a pool migration will be necessary.\nThe Ceph RBD driver supports Cinder\u0027s Volume migration feature [2], but is this not sufficient?\n\nI would like to move this patch forward.\n\n[1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/CYA234ZWGXEX7HWIZ2YZMEWD64XNRL2R/#CYA234ZWGXEX7HWIZ2YZMEWD64XNRL2R\n[2] https://docs.openstack.org/cinder/latest/admin/volume-migration.html","commit_id":"13fe212476c0f93f4b0e92719e69fc42a8ad5fbf"}]}