1. In the OCP 4.17 cluster the LVMS Operator automatically started upgrading from 4.17.5 to 4.18.0 and the upgrade is stuck due to the issue in CRD.

2. The operator is failed to upgrade with the below error:
~~~
        message: 'error validating existing CRs against new CRD''s schema for "lvmclusters.lvm.topolvm.io":
          error validating lvm.topolvm.io/v1alpha1, Kind=LVMCluster "openshift-storage/lvmcluster-sample":
          updated validation is too restrictive: [].spec.storage.deviceClasses[0].thinPoolConfig.metadataSizeCalculationPolicy:
          Required value'
~~~

3. Two CSV's are present which are associated with LVM Storage operator from which one is in Replacing state and one is in Pending state.
~~~
openshift-storage                      lvms-operator.v4.17.5                         LVM Storage                                     4.17.5                lvms-operator.v4.17.4                         Replacing
openshift-storage                      lvms-operator.v4.18.0                         LVM Storage                                     4.18.0                lvms-operator.v4.17.5                         Pending
~~~

4. In OCP 4.17 cluster we have 4.17 LVMS operator with the automatic approval type and it tries to automatically upgraded to 4.18 and that upgrade got stuck with the below error message:

~~~
        message: 'error validating existing CRs against new CRD''s schema for "lvmclusters.lvm.topolvm.io":
          error validating lvm.topolvm.io/v1alpha1, Kind=LVMCluster "openshift-storage/lvmcluster-sample":
          updated validation is too restrictive: [].spec.storage.deviceClasses[0].thinPoolConfig.metadataSizeCalculationPolicy:
          Required value'
~~~

5. The issue is solved with the below steps

- Uninstalled the operator by just removing the existing CSV, Subs and all the jobs and configmaps associated with the operator.
~~~
$ oc delete csv <csv_name>
$ oc delete subs <subs_name>
$ oc delete jobs <jobs_name>
$ oc delete cm <cm_name=jobs_name>
~~~

- Again install the operator from OperatorHub, Now this time we were not able to see the 4.18 operator version for the installation and after verification the operator got successfully installed with no error message.

6. Now we need to find the root cause how the operator upgrade is automatically triggered even if there is no channel available for 4.18 upgrade.

No