Skip to content

Logically group fields in the spec #1148

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Tracked by #740
everettraven opened this issue Aug 19, 2024 · 1 comment · Fixed by #1200
Closed
Tracked by #740

Logically group fields in the spec #1148

everettraven opened this issue Aug 19, 2024 · 1 comment · Fixed by #1200
Assignees
Labels
epic/v1-api good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. v1.0 Issues related to the initial stable release of OLMv1
Milestone

Comments

@everettraven
Copy link
Contributor

everettraven commented Aug 19, 2024

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.

@everettraven everettraven added epic/v1-api good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. v1.0 Issues related to the initial stable release of OLMv1 labels Aug 20, 2024
@everettraven everettraven added this to the v1.0.0 milestone Aug 20, 2024
@yashoza19
Copy link
Contributor

/assign

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
epic/v1-api good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. v1.0 Issues related to the initial stable release of OLMv1
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants