-
Notifications
You must be signed in to change notification settings - Fork 66
Description
This change is unrelated to either the OpenShift or Kubernetes API Conventions and is focused on ensuring that fields are logically grouped and that these logical groupings are valid as our feature set and API is expanded post-v1.0.0.
Building on #1088 , the RFC proposed a structure similar to:
type ClusterExtensionSpec struct {
Source SourceConfig `json:"resolution"`
Install InstallationConfig `json:"install"`
}
type InstallationConfig struct {
Namespace string `json:"namespace"`
ServiceAccount ServiceAccountReference `json:"serviceAccount"`
Preflight *PreflightConfig `json:"preflight,omitempty"`
}
An example of a ClusterExtension, in YAML, with these changes (and building on top of the discriminated union changes):
apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
name: argocd
spec:
resolution:
type: Catalog
catalog:
packageName: argocd-operator
version: 0.6.0
install:
namespace: argocd
serviceAccount:
name: argocd-installer
Additionally, the ClusterExtension.Status
should be updated to have logically grouped status information as well:
type ClusterExtensionStatus struct {
Install *InstallStatus `json:"install,omitempty"`
Resolution *ResolutionStatus `json:"resolution,omitempty"`
Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type" protobuf:"bytes,1,rep,name=conditions"`
}
type InstallStatus struct {
Bundle *BundleMetadata `json:"bundle,omitempty"`
}
type ResolutionStatus struct {
Bundle *BundleMetadata `json:"bundle,omitempty"`
}
Having these distinct, logical sections in both the ClusterExtension.Spec
and the ClusterExtension.Status
allows for logical expansion of fields. For example, if we wanted to add the ClusterCatalog
that the bundle we resolved to was from in the status, it would be a straightforward update to add a new field to the ResolutionStatus
struct above.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status