Update CRDs to include latest fields for VM live migration (#909)

Signed-off-by: Alexander Wels <awels@redhat.com>

deploy/olm-catalog/bundle/manifests/migration.openshift.io_directimagestreammigrations.yaml

@@ -39,29 +39,30 @@ spec:
               of DirectImageStreamMigration
             properties:
               destMigClusterRef:
-                description: 'ObjectReference contains enough information to let you
+                description: "ObjectReference contains enough information to let you
                   inspect or modify the referred object. --- New uses of this type
                   are discouraged because of difficulty describing its usage when
                   embedded in APIs. 1. Ignored fields.  It includes many fields which
                   are not generally honored.  For instance, ResourceVersion and FieldPath
-                  are both very rarely valid in actual usage. 2. Invalid usage help.  It
-                  is impossible to add specific help for individual usage.  In most
-                  embedded usages, there are particular restrictions like, "must refer
-                  only to types A and B" or "UID not honored" or "name must be restricted".
-                  Those cannot be well described when embedded. 3. Inconsistent validation.  Because
-                  the usages are different, the validation rules are different by
-                  usage, which makes it hard for users to predict what will happen.
-                  4. The fields are both imprecise and overly precise.  Kind is not
-                  a precise mapping to a URL. This can produce ambiguity during interpretation
-                  and require a REST mapping.  In most cases, the dependency is on
-                  the group,resource tuple and the version of the actual struct is
-                  irrelevant. 5. We cannot easily change it.  Because this type is
-                  embedded in many locations, updates to this type will affect numerous
-                  schemas.  Don''t make new APIs embed an underspecified API type
-                  they do not control. Instead of using this type, create a locally
-                  provided and used type that is well-focused on your reference. For
-                  example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                  .'
+                  are both very rarely valid in actual usage. 2. Invalid usage help.
+                  \ It is impossible to add specific help for individual usage.  In
+                  most embedded usages, there are particular restrictions like, \"must
+                  refer only to types A and B\" or \"UID not honored\" or \"name must
+                  be restricted\". Those cannot be well described when embedded. 3.
+                  Inconsistent validation.  Because the usages are different, the
+                  validation rules are different by usage, which makes it hard for
+                  users to predict what will happen. 4. The fields are both imprecise
+                  and overly precise.  Kind is not a precise mapping to a URL. This
+                  can produce ambiguity during interpretation and require a REST mapping.
+                  \ In most cases, the dependency is on the group,resource tuple and
+                  the version of the actual struct is irrelevant. 5. We cannot easily
+                  change it.  Because this type is embedded in many locations, updates
+                  to this type will affect numerous schemas.  Don't make new APIs
+                  embed an underspecified API type they do not control. \n Instead
+                  of using this type, create a locally provided and used type that
+                  is well-focused on your reference. For example, ServiceReferences
+                  for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                  ."
                 properties:
                   apiVersion:
                     description: API version of the referent.
@@ -102,29 +103,30 @@ spec:
                   where imagestreams should be migrated.
                 type: string
               imageStreamRef:
-                description: 'ObjectReference contains enough information to let you
+                description: "ObjectReference contains enough information to let you
                   inspect or modify the referred object. --- New uses of this type
                   are discouraged because of difficulty describing its usage when
                   embedded in APIs. 1. Ignored fields.  It includes many fields which
                   are not generally honored.  For instance, ResourceVersion and FieldPath
-                  are both very rarely valid in actual usage. 2. Invalid usage help.  It
-                  is impossible to add specific help for individual usage.  In most
-                  embedded usages, there are particular restrictions like, "must refer
-                  only to types A and B" or "UID not honored" or "name must be restricted".
-                  Those cannot be well described when embedded. 3. Inconsistent validation.  Because
-                  the usages are different, the validation rules are different by
-                  usage, which makes it hard for users to predict what will happen.
-                  4. The fields are both imprecise and overly precise.  Kind is not
-                  a precise mapping to a URL. This can produce ambiguity during interpretation
-                  and require a REST mapping.  In most cases, the dependency is on
-                  the group,resource tuple and the version of the actual struct is
-                  irrelevant. 5. We cannot easily change it.  Because this type is
-                  embedded in many locations, updates to this type will affect numerous
-                  schemas.  Don''t make new APIs embed an underspecified API type
-                  they do not control. Instead of using this type, create a locally
-                  provided and used type that is well-focused on your reference. For
-                  example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                  .'
+                  are both very rarely valid in actual usage. 2. Invalid usage help.
+                  \ It is impossible to add specific help for individual usage.  In
+                  most embedded usages, there are particular restrictions like, \"must
+                  refer only to types A and B\" or \"UID not honored\" or \"name must
+                  be restricted\". Those cannot be well described when embedded. 3.
+                  Inconsistent validation.  Because the usages are different, the
+                  validation rules are different by usage, which makes it hard for
+                  users to predict what will happen. 4. The fields are both imprecise
+                  and overly precise.  Kind is not a precise mapping to a URL. This
+                  can produce ambiguity during interpretation and require a REST mapping.
+                  \ In most cases, the dependency is on the group,resource tuple and
+                  the version of the actual struct is irrelevant. 5. We cannot easily
+                  change it.  Because this type is embedded in many locations, updates
+                  to this type will affect numerous schemas.  Don't make new APIs
+                  embed an underspecified API type they do not control. \n Instead
+                  of using this type, create a locally provided and used type that
+                  is well-focused on your reference. For example, ServiceReferences
+                  for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                  ."
                 properties:
                   apiVersion:
                     description: API version of the referent.
@@ -161,29 +163,30 @@ spec:
                 type: object
                 x-kubernetes-map-type: atomic
               srcMigClusterRef:
-                description: 'ObjectReference contains enough information to let you
+                description: "ObjectReference contains enough information to let you
                   inspect or modify the referred object. --- New uses of this type
                   are discouraged because of difficulty describing its usage when
                   embedded in APIs. 1. Ignored fields.  It includes many fields which
                   are not generally honored.  For instance, ResourceVersion and FieldPath
-                  are both very rarely valid in actual usage. 2. Invalid usage help.  It
-                  is impossible to add specific help for individual usage.  In most
-                  embedded usages, there are particular restrictions like, "must refer
-                  only to types A and B" or "UID not honored" or "name must be restricted".
-                  Those cannot be well described when embedded. 3. Inconsistent validation.  Because
-                  the usages are different, the validation rules are different by
-                  usage, which makes it hard for users to predict what will happen.
-                  4. The fields are both imprecise and overly precise.  Kind is not
-                  a precise mapping to a URL. This can produce ambiguity during interpretation
-                  and require a REST mapping.  In most cases, the dependency is on
-                  the group,resource tuple and the version of the actual struct is
-                  irrelevant. 5. We cannot easily change it.  Because this type is
-                  embedded in many locations, updates to this type will affect numerous
-                  schemas.  Don''t make new APIs embed an underspecified API type
-                  they do not control. Instead of using this type, create a locally
-                  provided and used type that is well-focused on your reference. For
-                  example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                  .'
+                  are both very rarely valid in actual usage. 2. Invalid usage help.
+                  \ It is impossible to add specific help for individual usage.  In
+                  most embedded usages, there are particular restrictions like, \"must
+                  refer only to types A and B\" or \"UID not honored\" or \"name must
+                  be restricted\". Those cannot be well described when embedded. 3.
+                  Inconsistent validation.  Because the usages are different, the
+                  validation rules are different by usage, which makes it hard for
+                  users to predict what will happen. 4. The fields are both imprecise
+                  and overly precise.  Kind is not a precise mapping to a URL. This
+                  can produce ambiguity during interpretation and require a REST mapping.
+                  \ In most cases, the dependency is on the group,resource tuple and
+                  the version of the actual struct is irrelevant. 5. We cannot easily
+                  change it.  Because this type is embedded in many locations, updates
+                  to this type will affect numerous schemas.  Don't make new APIs
+                  embed an underspecified API type they do not control. \n Instead
+                  of using this type, create a locally provided and used type that
+                  is well-focused on your reference. For example, ServiceReferences
+                  for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                  ."
                 properties:
                   apiVersion:
                     description: API version of the referent.

deploy/olm-catalog/bundle/manifests/migration.openshift.io_directvolumemigrationprogresses.yaml

@@ -58,29 +58,30 @@ spec:
               of DirectVolumeMigrationProgress
             properties:
               clusterRef:
-                description: 'ObjectReference contains enough information to let you
+                description: "ObjectReference contains enough information to let you
                   inspect or modify the referred object. --- New uses of this type
                   are discouraged because of difficulty describing its usage when
                   embedded in APIs. 1. Ignored fields.  It includes many fields which
                   are not generally honored.  For instance, ResourceVersion and FieldPath
-                  are both very rarely valid in actual usage. 2. Invalid usage help.  It
-                  is impossible to add specific help for individual usage.  In most
-                  embedded usages, there are particular restrictions like, "must refer
-                  only to types A and B" or "UID not honored" or "name must be restricted".
-                  Those cannot be well described when embedded. 3. Inconsistent validation.  Because
-                  the usages are different, the validation rules are different by
-                  usage, which makes it hard for users to predict what will happen.
-                  4. The fields are both imprecise and overly precise.  Kind is not
-                  a precise mapping to a URL. This can produce ambiguity during interpretation
-                  and require a REST mapping.  In most cases, the dependency is on
-                  the group,resource tuple and the version of the actual struct is
-                  irrelevant. 5. We cannot easily change it.  Because this type is
-                  embedded in many locations, updates to this type will affect numerous
-                  schemas.  Don''t make new APIs embed an underspecified API type
-                  they do not control. Instead of using this type, create a locally
-                  provided and used type that is well-focused on your reference. For
-                  example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                  .'
+                  are both very rarely valid in actual usage. 2. Invalid usage help.
+                  \ It is impossible to add specific help for individual usage.  In
+                  most embedded usages, there are particular restrictions like, \"must
+                  refer only to types A and B\" or \"UID not honored\" or \"name must
+                  be restricted\". Those cannot be well described when embedded. 3.
+                  Inconsistent validation.  Because the usages are different, the
+                  validation rules are different by usage, which makes it hard for
+                  users to predict what will happen. 4. The fields are both imprecise
+                  and overly precise.  Kind is not a precise mapping to a URL. This
+                  can produce ambiguity during interpretation and require a REST mapping.
+                  \ In most cases, the dependency is on the group,resource tuple and
+                  the version of the actual struct is irrelevant. 5. We cannot easily
+                  change it.  Because this type is embedded in many locations, updates
+                  to this type will affect numerous schemas.  Don't make new APIs
+                  embed an underspecified API type they do not control. \n Instead
+                  of using this type, create a locally provided and used type that
+                  is well-focused on your reference. For example, ServiceReferences
+                  for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                  ."
                 properties:
                   apiVersion:
                     description: API version of the referent.
@@ -119,29 +120,30 @@ spec:
               podNamespace:
                 type: string
               podRef:
-                description: 'ObjectReference contains enough information to let you
+                description: "ObjectReference contains enough information to let you
                   inspect or modify the referred object. --- New uses of this type
                   are discouraged because of difficulty describing its usage when
                   embedded in APIs. 1. Ignored fields.  It includes many fields which
                   are not generally honored.  For instance, ResourceVersion and FieldPath
-                  are both very rarely valid in actual usage. 2. Invalid usage help.  It
-                  is impossible to add specific help for individual usage.  In most
-                  embedded usages, there are particular restrictions like, "must refer
-                  only to types A and B" or "UID not honored" or "name must be restricted".
-                  Those cannot be well described when embedded. 3. Inconsistent validation.  Because
-                  the usages are different, the validation rules are different by
-                  usage, which makes it hard for users to predict what will happen.
-                  4. The fields are both imprecise and overly precise.  Kind is not
-                  a precise mapping to a URL. This can produce ambiguity during interpretation
-                  and require a REST mapping.  In most cases, the dependency is on
-                  the group,resource tuple and the version of the actual struct is
-                  irrelevant. 5. We cannot easily change it.  Because this type is
-                  embedded in many locations, updates to this type will affect numerous
-                  schemas.  Don''t make new APIs embed an underspecified API type
-                  they do not control. Instead of using this type, create a locally
-                  provided and used type that is well-focused on your reference. For
-                  example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                  .'
+                  are both very rarely valid in actual usage. 2. Invalid usage help.
+                  \ It is impossible to add specific help for individual usage.  In
+                  most embedded usages, there are particular restrictions like, \"must
+                  refer only to types A and B\" or \"UID not honored\" or \"name must
+                  be restricted\". Those cannot be well described when embedded. 3.
+                  Inconsistent validation.  Because the usages are different, the
+                  validation rules are different by usage, which makes it hard for
+                  users to predict what will happen. 4. The fields are both imprecise
+                  and overly precise.  Kind is not a precise mapping to a URL. This
+                  can produce ambiguity during interpretation and require a REST mapping.
+                  \ In most cases, the dependency is on the group,resource tuple and
+                  the version of the actual struct is irrelevant. 5. We cannot easily
+                  change it.  Because this type is embedded in many locations, updates
+                  to this type will affect numerous schemas.  Don't make new APIs
+                  embed an underspecified API type they do not control. \n Instead
+                  of using this type, create a locally provided and used type that
+                  is well-focused on your reference. For example, ServiceReferences
+                  for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                  ."
                 properties:
                   apiVersion:
                     description: API version of the referent.