Expose vdoctl functionalities to Openshift via CRD/Config

[asifdxtreme]

Issue/Feature Description:
Currently vdoctl exposes lot of functionality which Users in Openshift is not able to consume if they are using vdoctl.

We need to expose these functionalities to Openshift users either via CRD or Configs.

What type of Issue/Feature is this?
/kind new feature

[jvrahav]

We should introduce a new CRD for compatibility matrix that can not only hold the configuration related to compatibility matrix but can also have the options to

1. choose auto-upgrade,
2. watch url
3. configurations to choose interval for any such watch on url
4. track the status of VDO as the drivers are upgraded

[asifdxtreme]

We can have a rough CRD for compatibility-matrix like below in the vdoconfigs.vdo.vmware.com

              compatibilityMatrix:
                description: CompatibilityMatrix refers to the version mapping of CSI/CPI
                  with K8s and vSphere.
                properties:
                  matrixURL:
                    description: URL to fetch the Compatibility Matrix
                    items:
                      type: string
                    type: object
                  automaticUpdate:
                    description: Whether to update the matrix automatically
                    properties:
                      autoUpdate:
                        type: boolean
                      watchURL:
                        type: string
                      interval:
                        type: int
                    statusMsg:
                      description: Status to display the update status of drivers
                      type: string
                    items:
                      type: object
                    type: object
                type: object

Compatibility Matrix will come on same level as cloudProvider and storageProvider in VDOConfig.
I propose this CRD as a part of vdoconfigs.vdo.vmware.com so that it's easy for the controller to reconcile the state for any change, also by this we will have lesser reconcile loops and lesser objects to watch on.

[jvrahav]

We can have a rough CRD for compatibility-matrix like below in the vdoconfigs.vdo.vmware.com

              compatibilityMatrix:
                description: CompatibilityMatrix refers to the version mapping of CSI/CPI
                  with K8s and vSphere.
                properties:
                  matrixURL:
                    description: URL to fetch the Compatibility Matrix
                    items:
                      type: string
                    type: object
                  automaticUpdate:
                    description: Whether to update the matrix automatically
                    properties:
                      autoUpdate:
                        type: boolean
                      watchURL:
                        type: string
                      interval:
                        type: int
                    statusMsg:
                      description: Status to display the update status of drivers
                      type: string
                    items:
                      type: object
                    type: object
                type: object

Compatibility Matrix will come on same level as cloudProvider and storageProvider in VDOConfig. I propose this CRD as a part of vdoconfigs.vdo.vmware.com so that it's easy for the controller to reconcile the state for any change, also by this we will have lesser reconcile loops and lesser objects to watch on.

with this structure we are tying up two different entities together.
compatiblity matrix is meant to determine the version of drivers to install
vdoConfig is meant to represent the configuration of the drivers.
There can be workflow where the user only wants to modify the compatibility matrix. he should not have to revisit the entire configuration for that.
To your point on added reconcile loops, i believe this to not be a major compute as this is going to be an activity spread sparsely across the lifecycle of the operator. the reconcile is going to be simple and to the point.
If we have all in one CRD, when ever the user just changes compatibility related information, in the vdoconfig controller reconcile we will need to determine what has changed that i would consider compute that can be avoided