You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
replace deployment nginx ingress and cert manager with helm chart #254
Proposed implementation plan for branch 0.9.0, pending approval.
The main implementation belongs in apache/openserverless-task:
Introduce two shared tasks to install ingress-nginx and cert-manager with Helm, called by the existing installation commands. Helm is already included in the prerequisites. Use explicit chart versions, the selected kubeconfig, readiness waits and a timeout; installation failures must propagate to the caller.
Keep chart versions and provider configuration under version control. Start by matching the existing component versions and behavior: cert-manager is currently v1.11.0; ingress-nginx is v1.7.0 for Kind, v1.7.1 for EKS and v1.8.1 for AKS/GKE. Validate component upgrades separately from the installation refactoring.
Preserve provider-specific settings: ports and scheduling for Kind, LoadBalancer configuration for AKS/GKE, and AWS NLB annotations for EKS. Keep the existing service names and ingress class. K3s retains Traefik and changes only its cert-manager installation. Preserve components managed by the platform, such as MicroK8s add-ons.
Handle existing installations explicitly. Distinguish OpenServerless-managed resources from externally managed components, compare the rendered chart with existing resources, and define a controlled adoption path. Preserve service addresses, certificates and TLS secrets; do not automatically take ownership of external installations.
Update image discovery and caching before removing the copied manifests. util/freeze/opsfile.yml currently reads setup/docker/ingress-deploy.yaml directly. Image discovery should use the rendered chart with the same pinned version and provider values, including any required hook images, and remain consistent with the preload configuration.
Findings to account for during implementation:
The AKS, EKS and GKE certman tasks currently execute kubectl apply in both branches, including when DEL is set. This is a pre-existing error; define deletion behavior explicitly when implementing the Helm lifecycle.
With cert-manager versions before v1.15, uninstalling a chart that manages CRDs can also remove the associated custom resources. If retaining v1.11, manage the versioned CRDs separately from the Helm release and preserve them during uninstall. See the cert-manager Helm documentation.
apache/openserverless-operator also contains copied manifests used by its development cluster tasks, including clusters/eks.yml and clusters/lks.yml. Removing all repository copies would require a coordinated change there. I did not find calls to the old ingress/cert-manager installation modules in the current main operator flow.
ingress-nginx maintenance ended in March 2026. Moving to Helm addresses manifest duplication, but a migration to a maintained controller also needs to be planned. It should have its own compatibility assessment. See the Kubernetes retirement announcement.
Proposed validation: compare rendered resources for each provider; test a fresh installation, a second run, and migration from the existing manifests; verify HTTP routing and SSO; and verify that externally managed components and certificate resources are preserved. Add a dedicated cert-manager readiness and certificate-issuance check, since the existing SSL test skips Kind.
This comment records the proposal only. Implementation will wait for approval.
Activity
miki3421 commentedon Sep 16, 2026
Proposed implementation plan for branch
0.9.0, pending approval.The main implementation belongs in
apache/openserverless-task:v1.11.0; ingress-nginx isv1.7.0for Kind,v1.7.1for EKS andv1.8.1for AKS/GKE. Validate component upgrades separately from the installation refactoring.util/freeze/opsfile.ymlcurrently readssetup/docker/ingress-deploy.yamldirectly. Image discovery should use the rendered chart with the same pinned version and provider values, including any required hook images, and remain consistent with the preload configuration.Findings to account for during implementation:
certmantasks currently executekubectl applyin both branches, including whenDELis set. This is a pre-existing error; define deletion behavior explicitly when implementing the Helm lifecycle.v1.15, uninstalling a chart that manages CRDs can also remove the associated custom resources. If retainingv1.11, manage the versioned CRDs separately from the Helm release and preserve them during uninstall. See the cert-manager Helm documentation.apache/openserverless-operatoralso contains copied manifests used by its development cluster tasks, includingclusters/eks.ymlandclusters/lks.yml. Removing all repository copies would require a coordinated change there. I did not find calls to the old ingress/cert-manager installation modules in the current main operator flow.Proposed validation: compare rendered resources for each provider; test a fresh installation, a second run, and migration from the existing manifests; verify HTTP routing and SSO; and verify that externally managed components and certificate resources are preserved. Add a dedicated cert-manager readiness and certificate-issuance check, since the existing SSL test skips Kind.
This comment records the proposal only. Implementation will wait for approval.
sciabarracom commentedon Sep 16, 2026
I agree with the plan
sciabarracom commentedon Sep 16, 2026
we should test at least with k3s and kind - at the moment we do not have resources to text on cloud providers