Model drive configuration as a separate activity.

[jharmison-redhat]

container-storage and wipefs currently require, at run time, some introspection through the oc debug command to generate a small list of things that should be templated into Custom Resources for the Local Storage and OpenShift Container Storage operators. It would be nice to be able to have a configuration file in the Faros data directory that had the mapping from introspection, and all drive-related tasks drew from that configuration.

It would be better if that portion of the configuration didn't live inside the FarosConfig object and templated yaml, though. Because the FarosConfig should be generatable without a running cluster-manager container, we cannot guarantee that we can easily map those configuration changes at the time of generation.

It might make more sense if we include that configuration section as optional, don't force its population on the web application, and if the configuration contains that data at run time we simply use it - otherwise we introspect and offer a way to make selections that will template back into the configuration.

It may also make sense to add a kind field to the FarosConfig yaml file, and have a different kind field for a new configuration model, possibly FarosStorageConfig. I worry, too, though that this will cause the structure to look a lot like a Kubernetes resource manifest, which could cause some confusion as we don't intend for this to be applied to the cluster API itself.

Either way, the configuration for drives should be in an optional optional (file|section), populated by introspection and a user survey ("Which of these drives would you like to have wiped and built into an OCS cluster?"), and reconfigured by the user at wille (Introspection is always done once, then the user can select drives from the introspected results at any time, with an extra option to force re-introspection perhaps).