Ensure clustered backend pools are created and not left in pending state

[edlerd]

Done

• adding tests to ensure creating a storage pool on a clustered backend in created state. This would previously be a pending state for the pool, leaving it not fully usable.
• fixing pool creation for the cluster use case

QA

1. Run the LXD-UI:
   • On the demo server via the link posted by @webteam-app below. This is only available for PRs created by collaborators of the repo. Ask @lorumic or @edlerd for access.
   • With a local copy of this branch, run as described here.
2. Perform the following QA steps:
   • create a pool in a clustered backend (for the ZFS driver to work, the clustered test backend must not use containers, but VMs)
   • edit a pool in a clustered backend

[webteam-app]

Demo starting at https://lxd-ui-513.demos.haus

[lorumic]

I think this change needs more work.

When I try to create with a size value, I get this error:

The error is shown on the creation page, without any navigation, but the storage pool is actually created and has the "Pending" state. However, since no navigation happens, the user thinks that they can retry by just removing the size value, but that would fail, because a storage pool with that name already exists, resulting in only more frustration.

This needs UX improvement:

• Disable the size field, if it's not possible to set a fixed size because it's cluster member specific.
• Disable ZFS driver option if the cluster is not VM-based - I don't know if this is feasible, but it's better than getting a postponed feedback, so it would be good to investigate a way to do it.

[edlerd]

When I try to create with a size value, I get this error:

Did you run the cluster nodes as containers or as VMs when testing?

• Disable the size field, if it's not possible to set a fixed size because it's cluster member specific.

It should be possible. Did you review the code yet? Under the hood we are triggering requests for each cluster member to create a local pool with all fields. Afterwards one request to create the cluster wide pool. It could be the last request must not include a size though.

• Disable ZFS driver option if the cluster is not VM-based - I don't know if this is feasible, but it's better than getting a postponed feedback, so it would be good to investigate a way to do it.

That is a good idea. Will try to find a way to know if the cluster nodes are running as container. If not, I am not sure about the relevance, it might be very uncommon to run a cluster on containers and its just us using this as a testing backend.

[lorumic]

Did you run the cluster nodes as containers or as VMs when testing?

VMs.

Did you review the code yet? Under the hood we are triggering requests for each cluster member to create a local pool with all fields. Afterwards one request to create the cluster wide pool. It could be the last request must not include a size though.

Yes, I had already seen and understood the 3 changes in the code. And still, I'm always getting that error for a local cluster made of 3 VMs created following the guide in the wiki.

[edlerd]

Yes, I had already seen and understood the 3 changes in the code. And still, I'm always getting that error for a local cluster made of 3 VMs created following the guide in the wiki.

I see, thanks for providing the details. I think we have to strip the size (and likely other node specific properties) from the last request triggering the cluster-wide storage pool creation.

[edlerd]

Adjusted the storage creation for clustered backends. It omits node-specific config for the cluster storage. Also updated the edit storage, which needs to also update the cluster wide pool and needs the same adjustment.

[lorumic]

All good, just one tiny question about a function name.