Re: [pve-devel] [PATCH manager 5/5] ceph pools: allow to create erasure code pools

[Aaron Lauterer <a.lauterer@proxmox.com>]

On 4/29/22 09:40, Thomas Lamprecht wrote:
> On 29.04.22 09:33, Aaron Lauterer wrote:
>>
>> On 4/28/22 16:32, Dominik Csapak wrote:
>>> is there a specific reason why you still force the autocreation
>>> of the storage? i don't mind really, but giving a reason
>>> would be nice. if there is no reason, i'd drop that since
>>> the user can specify it anyway and adding one manually
>>> should also not too hard..
>>
>> I guess I could have been more explicit in the commit message. I decided to always create the storage config to have the coupling of ec pool and replicated metadata pool in place. We currently only have the RBD use case for EC pools in PVE itself and otherwise people might forget about it and any RBD image created without the data-pool parameter configured will be placed in the replicated pool.
>>
> 
> IMO still confusing to enforce it, default to true can be Ok, but that's
> something different than hard-enforcing it always, would surely lead to a bug
> report sooner or later.

I am sending a follow up which makes it a default that can be explicitly set
> 
> Oh, and for the CLI I'd like to see this as separate command, i.e.:
> 
> pveceph ec-pool create
> pveceph ec-pool destroy
> 
> That can then have the expanded options format, which can be nicer to use on CLI,
> and also default to add-storage there already.

Okay. One question on how to handle the destroy part. Since we do have 2 pools, 
depending on what the user provides, should we search for the storage name and 
any of the possible pool names and then figure out the missing pools from there 
and destroy both pools?
This way, the user could provide us with any of the 3 possibilities. On the 
other hand, this could be unexpected behavior, and we may rather let the user 
destroy 2 pools.

Or should it be the regular pool destroy, but set the parameters to destroy ec 
profiles?

> 
> 
> small ot/general nit: can you please use a text-width of 80 (or even 100) cc on
> the mailing list, my MTA is configured to show text as is to ensure patches are
> seen correctly, so long replies require horizontal scrolling
> 

Sorry for that. Should be fixed now :)