Feature: event handler for irreconcilable (k8s) clusters

[adammccartney]

Description

There are situations where a kubernetes cluster administrator may use the UI to
create / update a cluster that is beyond the scope of the underlying cloud
infrastructure. Such a request may be considered "irreconcilable". Like certain
types of romantic poetry, it is full of subtle longing for things that will
likely never come to pass.
One such situation is where the user submits a request to update the cluster,
and in doing so specifies a set of resources that exceed the given quota for the
tenancy where the cluster is deployed. After such a request has been issued, the
update button for that cluster becomes unusable and the only ways to get back to
a good state is to resolve the issue on the openstack side, delete the
cluster, or intervene using the azimuth cli.
Note that the k8s cluster under management and the applications it runs remain
functional during this blip.

Desired behaviour

The user has the option to roll back to a previously valid cluster configuration after a timeout.
For instance, after the timeout has been exceeded, the user would be presented with a modal
that gives a choice of either to continue to wait or to revert the cluster to the last known good state.

One possible Implementation suggestion

• Add a representation for "previously good k8s cluster form state" to the store
• Also add a state to represent "irreconcilable k8s cluster"
• Modify KubernetesClusterModalForm and useKubernetesClusterFormState to
  use a "copy-on-write" style pattern to store the result of
  initialState(kubernetesCluster) before attempting the update.
• In the case that we enter the "irreconcilable k8s cluster", allow the user to
  re-apply the stored "previously good k8s cluster form state"