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 :)
_______________________________________________
pve-devel mailing list
[email protected]
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
