"Reset PV Discovery" action

[sseago]

We should consider implementing a "reset PV discovery" UI action. Since the controller chooses default storageclasses on the first pass, if the user realizes that there's a missing storageclass on dest (i.e. ceph isn't available, etc.) and adds it post-discovery, the controller won't overwrite the initial default values on the next pass since it has no way of knowing whether it's overwriting user-entered values. Adding a "reset" action, which would result in migplan update that removes the entire persistentVolumes array, would allow PV discovery to start over for the plan, selecting new defaults based on the newly-added storage classes.

[ibolton336]

@sseago could we pass something to the api that would signify that we are rerunning PV discovery? We are using UI state to determine if we are rerunning pv discovery or if it being run for the first time on a mig plan. We could pass this flag to the back end if that could trigger a reset?

[eriknelson]

We've implemented something like this on previous kubernetes controllers with a dedicated field that is a monotonically increasing value who's sole purpose is to force a re-reconcile.

Ex: relistPersistentVolumes: 0. Editing this value to 1 would force a refresh of the data. It can be done from the cli, or from the UI. I think this would be a useful feature as a "force refresh".