miki3421 commented on issue #254: URL: https://github.com/apache/openserverless/issues/254#issuecomment-5699021943
Proposed implementation plan for branch `0.9.0`, pending approval. The main implementation belongs in `apache/openserverless-task`: 1. 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. 2. 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. 3. 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. 4. 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. 5. 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](https://cert-manager.io/docs/installation/helm/). - `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](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/). 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
