There is an argument that having to remember the passphrase and the key description used for each pool is a bit unusable.
The pros of having a key description that can be used across multiple pools is largely in the case where a user wants to be able to be able to set a single passphrase in the keyring for multiple pools. In this case, a subset of pools could use the same key description and corresponding passphrase for setup. Only one key set command would need to be issued to bring up all of those pools that share a key description.
The cons are largely that now there are two pieces of information that need to be remembered: passphrase and key description. In version 2 of the metadata, it will become a lot harder to determine the key description stored in the metadata which means it would become a bit unusable to depend on the existing workflow of listing the key description associated with the stopped (locked) pool.
This could largely be rectified by a change to the StartPool command that allows providing a passphrase as input to that method. This would allow the user to not care about what key description is associated with the pool outside of pool creation time. The key description would be automatically pulled from the metadata on pool start.
However, this change has the potential to conflict with this issue. Depending on what gets decided there, there is great potential to allow only one passphrase and multiple Clevis bindings, which could resolve the problems here.
There is an argument that having to remember the passphrase and the key description used for each pool is a bit unusable.
The pros of having a key description that can be used across multiple pools is largely in the case where a user wants to be able to be able to set a single passphrase in the keyring for multiple pools. In this case, a subset of pools could use the same key description and corresponding passphrase for setup. Only one key set command would need to be issued to bring up all of those pools that share a key description.
The cons are largely that now there are two pieces of information that need to be remembered: passphrase and key description. In version 2 of the metadata, it will become a lot harder to determine the key description stored in the metadata which means it would become a bit unusable to depend on the existing workflow of listing the key description associated with the stopped (locked) pool.
This could largely be rectified by a change to the
StartPoolcommand that allows providing a passphrase as input to that method. This would allow the user to not care about what key description is associated with the pool outside of pool creation time. The key description would be automatically pulled from the metadata on pool start.However, this change has the potential to conflict with this issue. Depending on what gets decided there, there is great potential to allow only one passphrase and multiple Clevis bindings, which could resolve the problems here.