operator: sensible defaults to allow minimal configuration Jumpstarter resource creation #202
Conversation
WalkthroughAdds CRD defaults for controller and routers (including default images and empty-object defaults), updates bundle CSV examples/timestamp, and introduces runtime endpoint defaulting in the controller that sets/ensures endpoint service types based on Route/Ingress availability before reconciliation. Changes
Sequence Diagram(s)mermaid Reconciler->>EndpointReconciler: ApplyDefaults(&Spec) Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@mangelajo PTAL if this is the right approach. |
deploy/operator/internal/controller/jumpstarter/endpoints/endpoints.go
Outdated
Show resolved
Hide resolved
deploy/operator/internal/controller/jumpstarter/endpoints/endpoints.go
Outdated
Show resolved
Hide resolved
mangelajo
left a comment
mangelajo
left a comment
There was a problem hiding this comment.
some comments, it's looking good
deploy/operator/internal/controller/jumpstarter/endpoints/endpoints.go
Outdated
Show resolved
Hide resolved
deploy/operator/internal/controller/jumpstarter/endpoints/endpoints.go
Outdated
Show resolved
Hide resolved
deploy/operator/internal/controller/jumpstarter/endpoints/endpoints.go
Outdated
Show resolved
Hide resolved
deploy/operator/internal/controller/jumpstarter/endpoints/endpoints.go
Outdated
Show resolved
Hide resolved
mangelajo
left a comment
mangelajo
left a comment
There was a problem hiding this comment.
it looks good, can you check the detail from my comment?
why did we make baseDomain mandatory? will that allow it to be empty?
I would leave baseDomain as it was originally, and we can handle that in another PR for baseDomain detection.
issue is, if we won't make it mandatory, and the user will forget (or won't know) to apply it, an instance of jumpstarter will be created with no errors, but it will not function. in this case the result will be the same as having example.com there, which is what we decided to avoid doing. the addition of baseDomain auto detection in the next PR will just soften this requirement for openshift clusters, but iiuc there should be no use case where a user should be allowed to create a jumpstarter without endpoints at all (either default or explicit) which is what would happen if we lift this requirement. correct me if i'm wrong 🤔 :) |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
deploy/operator/bundle/manifests/jumpstarter-operator.clusterserviceversion.yaml (1)
5-21: Updatealm-examplesto use a valid Jumpstarter specNow that
specandspec.baseDomainare required, thealm-examplesentry with"spec": nullis no longer valid and will generate a non-applying example in OLM; please align this example with the new minimal spec (e.g. including abaseDomainlike in the base CSV).
🧹 Nitpick comments (6)
deploy/operator/api/v1alpha1/jumpstarter_types.go (1)
162-166: Default controller/router images wired via kubebuilder annotationsHard-wiring the default image to
quay.io/jumpstarter-dev/jumpstarter-controller:latestfor both controller and routers keeps CRD defaults, reconciler, and docs aligned; just remember this needs updating on future image/tag changes across all manifests.Also applies to: 197-201
deploy/operator/config/crd/bases/operator.jumpstarter.dev_jumpstarters.yaml (2)
1087-1091: CRD image defaults are consistent with type annotationsThe CRD-level defaults for controller and router images align with the Go kubebuilder defaults and ensure a working deployment out of the box; just keep this in sync with future image/tag changes across Helm and operator manifests.
Also applies to: 1632-1637
1901-1903: Spec and baseDomain now enforced at schema levelRequiring
spec.baseDomainunderspec.requiredandspecunder the rootrequiredlist matches the Go type changes and prevents creation of non-functional Jumpstarter CRs; consider calling this out in release notes for users upgrading existing clusters.Also applies to: 1910-1912
deploy/operator/internal/controller/jumpstarter/endpoints/endpoints.go (1)
63-67: Reconciler.ApplyDefaults cleanly exposes endpoint defaultingExposing
ApplyDefaultson the endpointsReconcilerand delegating toApplyEndpointDefaultswith discovered Route/Ingress availability gives the controller a simple, capability-aware hook for runtime defaults without duplicating logic.deploy/operator/internal/controller/jumpstarter/endpoints/defaults.go (1)
48-85: Endpoint defaulting matches new baseDomain requirement and GRPC semantics
ApplyEndpointDefaults’s behavior—skip whenBaseDomainis empty, otherwise generategrpc.<baseDomain>androuter-$(replica).<baseDomain>gRPC endpoints and ensure all endpoints have at least one service type—fits the new requiredbaseDomainconstraint and provides sensible, cluster-aware defaults for both controller and routers.deploy/operator/bundle/manifests/operator.jumpstarter.dev_jumpstarters.yaml (1)
1086-1091: Consider recommending explicit version tags in documentation.Using
:latestis reasonable for quick-start scenarios, but can lead to unpredictable behavior in production when the underlying image changes. Consider adding documentation guidance that production deployments should override this with a pinned version tag.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
deploy/operator/dist/install.yamlis excluded by!**/dist/**
📒 Files selected for processing (8)
deploy/operator/api/v1alpha1/jumpstarter_types.go(5 hunks)deploy/operator/bundle/manifests/jumpstarter-operator.clusterserviceversion.yaml(1 hunks)deploy/operator/bundle/manifests/operator.jumpstarter.dev_jumpstarters.yaml(5 hunks)deploy/operator/config/crd/bases/operator.jumpstarter.dev_jumpstarters.yaml(5 hunks)deploy/operator/config/manifests/bases/jumpstarter-operator.clusterserviceversion.yaml(1 hunks)deploy/operator/internal/controller/jumpstarter/endpoints/defaults.go(1 hunks)deploy/operator/internal/controller/jumpstarter/endpoints/endpoints.go(1 hunks)deploy/operator/internal/controller/jumpstarter/jumpstarter_controller.go(1 hunks)
🧰 Additional context used
🧠 Learnings (8)
📓 Common learnings
Learnt from: mangelajo
Repo: jumpstarter-dev/jumpstarter-controller PR: 170
File: deploy/operator/internal/controller/jumpstarter/jumpstarter_controller.go:328-333
Timestamp: 2025-10-24T11:57:23.796Z
Learning: In the jumpstarter-controller operator (deploy/operator/), the design allows only one Jumpstarter CR per namespace, which will be enforced by a validation webhook. This constraint eliminates concerns about resource name collisions within a namespace.
Learnt from: NickCao
Repo: jumpstarter-dev/jumpstarter-controller PR: 137
File: hack/deploy_with_helm.sh:26-34
Timestamp: 2025-05-13T19:57:56.811Z
Learning: The jumpstarter project uses a custom kind cluster configuration with an expanded NodePort range (3000-32767) and explicit port mappings for ingress (5080/5443) and gRPC services (30010/30011 mapped to 8082/8083).
Learnt from: NickCao
Repo: jumpstarter-dev/jumpstarter-controller PR: 137
File: hack/deploy_with_helm.sh:26-34
Timestamp: 2025-05-13T19:57:56.811Z
Learning: The jumpstarter-dev repository uses a custom kind cluster configuration that allows NodePort services to use non-standard ports 5080 and 5443, outside the default Kubernetes NodePort range (30000-32767).
Learnt from: mangelajo
Repo: jumpstarter-dev/jumpstarter-controller PR: 190
File: api/v1alpha1/exporter_helpers.go:16-24
Timestamp: 2025-11-14T15:47:36.325Z
Learning: In the jumpstarter-controller project, migration annotations (jumpstarter.dev/migrated-namespace and jumpstarter.dev/migrated-uid) that override namespace and UID values in authentication tokens are acceptable without additional validation webhooks because the security model assumes only administrators have write access to Exporter and Client resources via K8s RBAC.
📚 Learning: 2025-10-24T11:57:23.796Z
Learnt from: mangelajo
Repo: jumpstarter-dev/jumpstarter-controller PR: 170
File: deploy/operator/internal/controller/jumpstarter/jumpstarter_controller.go:328-333
Timestamp: 2025-10-24T11:57:23.796Z
Learning: In the jumpstarter-controller operator (deploy/operator/), the design allows only one Jumpstarter CR per namespace, which will be enforced by a validation webhook. This constraint eliminates concerns about resource name collisions within a namespace.
Applied to files:
deploy/operator/api/v1alpha1/jumpstarter_types.godeploy/operator/internal/controller/jumpstarter/jumpstarter_controller.godeploy/operator/config/manifests/bases/jumpstarter-operator.clusterserviceversion.yamldeploy/operator/config/crd/bases/operator.jumpstarter.dev_jumpstarters.yamldeploy/operator/bundle/manifests/jumpstarter-operator.clusterserviceversion.yamldeploy/operator/bundle/manifests/operator.jumpstarter.dev_jumpstarters.yaml
📚 Learning: 2025-11-14T15:47:36.325Z
Learnt from: mangelajo
Repo: jumpstarter-dev/jumpstarter-controller PR: 190
File: api/v1alpha1/exporter_helpers.go:16-24
Timestamp: 2025-11-14T15:47:36.325Z
Learning: In the jumpstarter-controller project, migration annotations (jumpstarter.dev/migrated-namespace and jumpstarter.dev/migrated-uid) that override namespace and UID values in authentication tokens are acceptable without additional validation webhooks because the security model assumes only administrators have write access to Exporter and Client resources via K8s RBAC.
Applied to files:
deploy/operator/api/v1alpha1/jumpstarter_types.godeploy/operator/config/manifests/bases/jumpstarter-operator.clusterserviceversion.yamldeploy/operator/bundle/manifests/operator.jumpstarter.dev_jumpstarters.yaml
📚 Learning: 2025-05-13T19:56:27.924Z
Learnt from: NickCao
Repo: jumpstarter-dev/jumpstarter-controller PR: 137
File: deploy/helm/jumpstarter/charts/jumpstarter-controller/templates/router-deployment.yaml:23-26
Timestamp: 2025-05-13T19:56:27.924Z
Learning: In the jumpstarter-controller project, the router service uses the same ConfigMap as the controller service (controller-cm.yaml) even though it has been moved to its own separate deployment.
Applied to files:
deploy/operator/api/v1alpha1/jumpstarter_types.godeploy/operator/config/crd/bases/operator.jumpstarter.dev_jumpstarters.yamldeploy/operator/bundle/manifests/operator.jumpstarter.dev_jumpstarters.yaml
📚 Learning: 2025-05-13T19:57:56.811Z
Learnt from: NickCao
Repo: jumpstarter-dev/jumpstarter-controller PR: 137
File: hack/deploy_with_helm.sh:26-34
Timestamp: 2025-05-13T19:57:56.811Z
Learning: The jumpstarter project uses a custom kind cluster configuration with an expanded NodePort range (3000-32767) and explicit port mappings for ingress (5080/5443) and gRPC services (30010/30011 mapped to 8082/8083).
Applied to files:
deploy/operator/api/v1alpha1/jumpstarter_types.godeploy/operator/config/manifests/bases/jumpstarter-operator.clusterserviceversion.yamldeploy/operator/config/crd/bases/operator.jumpstarter.dev_jumpstarters.yamldeploy/operator/bundle/manifests/operator.jumpstarter.dev_jumpstarters.yaml
📚 Learning: 2025-10-24T11:57:13.484Z
Learnt from: mangelajo
Repo: jumpstarter-dev/jumpstarter-controller PR: 170
File: deploy/operator/internal/controller/jumpstarter/rbac.go:193-196
Timestamp: 2025-10-24T11:57:13.484Z
Learning: In the Jumpstarter operator codebase (deploy/operator/internal/controller/jumpstarter/rbac.go), the Role created by `createRole()` defines RBAC permissions for the managed Jumpstarter controller application, not for the operator itself. The managed controller needs delete permissions on secrets for its runtime operations.
Applied to files:
deploy/operator/api/v1alpha1/jumpstarter_types.godeploy/operator/internal/controller/jumpstarter/jumpstarter_controller.godeploy/operator/config/manifests/bases/jumpstarter-operator.clusterserviceversion.yamldeploy/operator/bundle/manifests/jumpstarter-operator.clusterserviceversion.yamldeploy/operator/bundle/manifests/operator.jumpstarter.dev_jumpstarters.yaml
📚 Learning: 2025-05-13T19:57:56.811Z
Learnt from: NickCao
Repo: jumpstarter-dev/jumpstarter-controller PR: 137
File: hack/deploy_with_helm.sh:26-34
Timestamp: 2025-05-13T19:57:56.811Z
Learning: The jumpstarter-dev repository uses a custom kind cluster configuration that allows NodePort services to use non-standard ports 5080 and 5443, outside the default Kubernetes NodePort range (30000-32767).
Applied to files:
deploy/operator/api/v1alpha1/jumpstarter_types.godeploy/operator/config/manifests/bases/jumpstarter-operator.clusterserviceversion.yamldeploy/operator/config/crd/bases/operator.jumpstarter.dev_jumpstarters.yamldeploy/operator/bundle/manifests/operator.jumpstarter.dev_jumpstarters.yaml
📚 Learning: 2025-06-06T17:04:50.040Z
Learnt from: NickCao
Repo: jumpstarter-dev/jumpstarter-controller PR: 144
File: deploy/helm/jumpstarter/charts/jumpstarter-controller/values.schema.json:60-156
Timestamp: 2025-06-06T17:04:50.040Z
Learning: In the jumpstarter controller Helm chart, empty JWT authenticator configuration is valid by design. When the JWT config is empty, the system falls back to using the internal authenticator, which is why all properties in the JWTAuthenticator schema are optional.
Applied to files:
deploy/operator/api/v1alpha1/jumpstarter_types.go
🧬 Code graph analysis (2)
deploy/operator/internal/controller/jumpstarter/endpoints/endpoints.go (2)
deploy/operator/api/v1alpha1/jumpstarter_types.go (1)
JumpstarterSpec(130-157)deploy/operator/internal/controller/jumpstarter/endpoints/defaults.go (1)
ApplyEndpointDefaults(51-85)
deploy/operator/internal/controller/jumpstarter/endpoints/defaults.go (2)
deploy/operator/api/v1alpha1/jumpstarter_types.go (5)
Endpoint(385-419)RouteConfig(422-435)IngressConfig(438-456)ClusterIPConfig(504-516)JumpstarterSpec(130-157)deploy/helm/jumpstarter/charts/jumpstarter-controller/model.py (2)
Route(86-91)Ingress(75-83)
🔇 Additional comments (10)
deploy/operator/api/v1alpha1/jumpstarter_types.go (3)
131-136: BaseDomain required + non-omitempty looks appropriateMaking
BaseDomainrequired with a strict DNS-style pattern and removingomitemptymatches the endpoint-generation semantics and avoids silently broken instances; this is a solid trade-off given Jumpstarter can’t function without a base domain.
144-152: Struct-level defaults for Controller and Routers are consistentUsing
+kubebuilder:default={}onControllerandRoutersensures those nested configs are always present even with minimal specs, which pairs well with the runtime defaulting logic and avoids nil-struct surprises.
533-535: Requiring Spec at the top level matches CRD tighteningMarking
Specas required and droppingomitemptyensures invalidspec: nullCRs are rejected and matches the stricter OpenAPI schema in the CRD; this is a good consistency and UX improvement.deploy/operator/internal/controller/jumpstarter/jumpstarter_controller.go (1)
131-134: Good placement of runtime defaulting before reconcileCalling
r.EndpointReconciler.ApplyDefaults(&jumpstarter.Spec)once after fetch/deletion checks and before all reconcile steps centralizes endpoint defaulting and keeps the rest of the reconciler working on a normalized spec without introducing new nil-pointer risks.deploy/operator/config/manifests/bases/jumpstarter-operator.clusterserviceversion.yaml (1)
5-18: Minimal alm-examples now matches CRD requirementsThe updated
alm-exampleswith a single Jumpstarter instance andspec.baseDomainis aligned with the new required fields and illustrates the minimal valid configuration well.deploy/operator/config/crd/bases/operator.jumpstarter.dev_jumpstarters.yaml (1)
433-434:default: {}for controller/routers matches Go defaultsAdding
default: {}onspec.controllerandspec.routersmirrors the kubebuilderdefault={}markers and guarantees these objects exist for minimal specs, which simplifies controller logic and defaulting.Also applies to: 1373-1374
deploy/operator/internal/controller/jumpstarter/endpoints/defaults.go (1)
25-46: Centralized service-type selection logic looks solid
ensureEndpointServiceTypecorrectly treats “no enabled type” as a cue to auto-pick Route, then Ingress, then ClusterIP, which matches the field docs and keeps this policy in one place instead of scattered across reconcilers.deploy/operator/bundle/manifests/operator.jumpstarter.dev_jumpstarters.yaml (3)
432-433: LGTM: Cascading defaults for controller configuration.The empty object default enables nested field defaults (image, replicas, etc.) to be applied automatically when users omit the controller configuration entirely.
1372-1373: LGTM: Consistent defaulting pattern for routers.Same cascading default approach as the controller configuration.
1901-1911: Verify: PR description mentionsbaseDomaindefault that isn't implemented.The PR description states that
spec.baseDomaindefaults tojumpstarter.example.com, but the CRD schema (lines 425-431) does not define a default value for this field. Combined with therequiredconstraint here, users must explicitly providebaseDomain.Per the PR comments, this appears intentional to prevent non-functional deployments. If so, consider updating the PR description to clarify that
baseDomainis required (not defaulted) to avoid confusion.
|
I have tested temporary removing the requirement for mandatory baseDomain, and indeed this resulted in a unwanted state where a user is allowed to apply which results in the following resource and creates the pods with controller |
mangelajo
left a comment
mangelajo
left a comment
There was a problem hiding this comment.
I understand that this will not work today if the baseDomain is empty, but I expect that to be handled as I describe in the comment, in a follow up PR.
I am ok if you will remove this requirement in the next PR to allow empty base domain. deal? :D
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
deploy/operator/bundle/manifests/operator.jumpstarter.dev_jumpstarters.yaml (2)
1087-1087: Consider pinning to a specific version tag.Using
:latestmakes deployments non-deterministic. While acceptable as a CRD default that users can override, pinning to a specific version (e.g.,v0.8.0) would improve reproducibility.
1632-1632: Verify that routers intentionally use the controller image, and consider pinning to a specific version.Both controller and routers default to the same image (
jumpstarter-controller:latest). While the description mentions "Jumpstarter router," using the controller image might be intentional if they share the same binary with different configurations.Additionally, using
:latestcreates non-deterministic deployments. Consider pinning to a specific version tag for better reproducibility.Run the following to check if there's a separate router image or if they share the same image:
#!/bin/bash # Search for router image references and deployment configurations rg -n -C3 'router.*image|image.*router' --type=yamlBased on learnings, routers use the same ConfigMap as controllers, which may indicate shared infrastructure.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
deploy/operator/dist/install.yamlis excluded by!**/dist/**
📒 Files selected for processing (4)
deploy/operator/api/v1alpha1/jumpstarter_types.go(3 hunks)deploy/operator/bundle/manifests/jumpstarter-operator.clusterserviceversion.yaml(1 hunks)deploy/operator/bundle/manifests/operator.jumpstarter.dev_jumpstarters.yaml(4 hunks)deploy/operator/config/crd/bases/operator.jumpstarter.dev_jumpstarters.yaml(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- deploy/operator/config/crd/bases/operator.jumpstarter.dev_jumpstarters.yaml
- deploy/operator/api/v1alpha1/jumpstarter_types.go
🧰 Additional context used
🧠 Learnings (5)
📓 Common learnings
Learnt from: mangelajo
Repo: jumpstarter-dev/jumpstarter-controller PR: 170
File: deploy/operator/internal/controller/jumpstarter/jumpstarter_controller.go:328-333
Timestamp: 2025-10-24T11:57:23.796Z
Learning: In the jumpstarter-controller operator (deploy/operator/), the design allows only one Jumpstarter CR per namespace, which will be enforced by a validation webhook. This constraint eliminates concerns about resource name collisions within a namespace.
Learnt from: NickCao
Repo: jumpstarter-dev/jumpstarter-controller PR: 137
File: deploy/helm/jumpstarter/charts/jumpstarter-controller/templates/router-deployment.yaml:23-26
Timestamp: 2025-05-13T19:56:27.924Z
Learning: In the jumpstarter-controller project, the router service uses the same ConfigMap as the controller service (controller-cm.yaml) even though it has been moved to its own separate deployment.
📚 Learning: 2025-10-24T11:57:23.796Z
Learnt from: mangelajo
Repo: jumpstarter-dev/jumpstarter-controller PR: 170
File: deploy/operator/internal/controller/jumpstarter/jumpstarter_controller.go:328-333
Timestamp: 2025-10-24T11:57:23.796Z
Learning: In the jumpstarter-controller operator (deploy/operator/), the design allows only one Jumpstarter CR per namespace, which will be enforced by a validation webhook. This constraint eliminates concerns about resource name collisions within a namespace.
Applied to files:
deploy/operator/bundle/manifests/jumpstarter-operator.clusterserviceversion.yamldeploy/operator/bundle/manifests/operator.jumpstarter.dev_jumpstarters.yaml
📚 Learning: 2025-10-24T11:57:13.484Z
Learnt from: mangelajo
Repo: jumpstarter-dev/jumpstarter-controller PR: 170
File: deploy/operator/internal/controller/jumpstarter/rbac.go:193-196
Timestamp: 2025-10-24T11:57:13.484Z
Learning: In the Jumpstarter operator codebase (deploy/operator/internal/controller/jumpstarter/rbac.go), the Role created by `createRole()` defines RBAC permissions for the managed Jumpstarter controller application, not for the operator itself. The managed controller needs delete permissions on secrets for its runtime operations.
Applied to files:
deploy/operator/bundle/manifests/jumpstarter-operator.clusterserviceversion.yamldeploy/operator/bundle/manifests/operator.jumpstarter.dev_jumpstarters.yaml
📚 Learning: 2025-05-13T19:56:27.924Z
Learnt from: NickCao
Repo: jumpstarter-dev/jumpstarter-controller PR: 137
File: deploy/helm/jumpstarter/charts/jumpstarter-controller/templates/router-deployment.yaml:23-26
Timestamp: 2025-05-13T19:56:27.924Z
Learning: In the jumpstarter-controller project, the router service uses the same ConfigMap as the controller service (controller-cm.yaml) even though it has been moved to its own separate deployment.
Applied to files:
deploy/operator/bundle/manifests/operator.jumpstarter.dev_jumpstarters.yaml
📚 Learning: 2025-10-13T09:05:03.088Z
Learnt from: mangelajo
Repo: jumpstarter-dev/jumpstarter-controller PR: 169
File: deploy/operator/config/rbac/leader_election_role_binding.yaml:3-15
Timestamp: 2025-10-13T09:05:03.088Z
Learning: In Kubebuilder-generated Kubernetes operators, RBAC manifests (RoleBindings, Roles, etc.) under config/rbac/ typically do not include explicit `metadata.namespace` fields. The namespace is injected at build time by Kustomize via the `namespace` field in config/default/kustomization.yaml (or whichever kustomization file is used). This is intentional design to keep base manifests namespace-agnostic. Do not flag missing namespaces in such RBAC manifests as issues when they are part of a Kustomize-based operator deployment structure.
Applied to files:
deploy/operator/bundle/manifests/operator.jumpstarter.dev_jumpstarters.yaml
🔇 Additional comments (3)
deploy/operator/bundle/manifests/jumpstarter-operator.clusterserviceversion.yaml (1)
21-21: LGTM!The timestamp update reflects bundle regeneration, which is expected when CRD defaults are added.
deploy/operator/bundle/manifests/operator.jumpstarter.dev_jumpstarters.yaml (2)
433-433: LGTM!The
default: {}marker enables minimal CR configuration by ensuring the controller field is populated with default values when not specified.
1373-1373: LGTM!The
default: {}marker ensures routers are configured with default values when not explicitly specified in the CR.
|
following our agreement lifted the hard requirement in favor of future soft failure at the status level. |
2 participants
Summary
This PR adds kubebuilder defaults to enable minimal Jumpstarter CR configuration.
Changes
Required Fields
specis now required (validation at CRD level)spec.baseDomainis now required (users must provide their cluster's domain)Kubebuilder Defaults
+kubebuilder:default={}onControllerandRoutersstruct fields+kubebuilder:defaultvalues for nested fields (image, replicas, imagePullPolicy, etc.)Dynamic Endpoint Generation
baseDomainunless explicitly specifiedMinimal Valid CR
Summary by CodeRabbit
New Features
Documentation
Refactor
✏️ Tip: You can customize this high-level summary in your review settings.