[WIP] NE-2437: [POC] Install Istio via Helm charts instead of OLM subscription

[gcs278]

Replace OLM-based Istio installation with direct Helm chart installation using sail-operator's ChartManager library. This is currently a POC used to explore the feasibility of Helm-based installations for Istiod in the Ingress Operator.

This POC uses a start-gatewayclass command that runs only the updated gatewayclass controller against a cluster, bypassing the need to deploy and configure the full ingress-operator. This is so that I can quickly iterate inside a kind cluster.

Testing

To test this POC in a local kind cluster:

# Create and configure a kind cluster with Gateway API CRDs
./hack/setup-kind-cluster-for-helm-poc.sh

# Run the isolated gatewayclass controller POC
./ingress-operator start-gatewayclass

# In another terminal, create a GatewayClass to trigger Helm installation
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: openshift-default
spec:
  controllerName: openshift.io/gateway-controller/v1
EOF

# Verify the Helm release and istiod deployment
helm list -A
kubectl get pods -n openshift-ingress

TODO

• Replace OLM-based install with Helm-Base install
• Provide a POC kind-cluster start script
• Add a upgrade POC for migration from OLM-based install to Helm
• Add Watches for Helm Objects (deployments, services, etc...)
• Explore how images will be added to the OCP Payload
• Explore how charts will be added to the OCP Payload
• Clean up/uninstall GatewayClass testing & logic

This POC was developed with assistance from Claude, which helped with code implementation and script development.

[openshift-ci-robot]

@gcs278: This pull request references NE-2437 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Replace OLM-based Istio installation with direct Helm chart installation using sail-operator's ChartManager library. This is currently a POC used to explore the feasiblity of Helm-based installations for Istiod in the Ingress Operator.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@gcs278: This pull request references NE-2437 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Replace OLM-based Istio installation with direct Helm chart installation using sail-operator's ChartManager library. This is currently a POC used to explore the feasiblity of Helm-based installations for Istiod in the Ingress Operator.

Testing

I'm testing in a kind cluster that leverages gwapi.sh to create a kind cluster, deploy the CRDs, and install metalLB.

Then I run:

./ingress-operator start-gatewayclass

TODO

• Replace OLM-based install with Helm-Base install
• Add Watches for Helm Objects (deployments, services, etc...)
• Add a upgrade POC for migration from OLM-based install to Helm
• Provide a POC kind-cluster start script

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@gcs278: This pull request references NE-2437 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Replace OLM-based Istio installation with direct Helm chart installation using sail-operator's ChartManager library. This is currently a POC used to explore the feasibility of Helm-based installations for Istiod in the Ingress Operator.

Testing

I'm testing in a kind cluster that leverages gwapi.sh to create a kind cluster, deploy the CRDs, and install metalLB.

Then I run:

./ingress-operator start-gatewayclass

TODO

• Replace OLM-based install with Helm-Base install
• Add Watches for Helm Objects (deployments, services, etc...)
• Add a upgrade POC for migration from OLM-based install to Helm
• Provide a POC kind-cluster start script
• Explore how images will be added to the OCP Payload
• Explore how charts will be added to the OCP Payload
• Clean up/uninstall GatewayClass testing & logic

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@gcs278: This pull request references NE-2437 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Replace OLM-based Istio installation with direct Helm chart installation using sail-operator's ChartManager library. This is currently a POC used to explore the feasibility of Helm-based installations for Istiod in the Ingress Operator.

This POC uses a start-gatewayclass command that runs only the updated gatewayclass controller against a cluster, bypassing the need to deploy and configure the full ingress-operator. This is so that I can quickly iterate with in a kind cluster.

Testing

I'm testing in a kind cluster that leverages gwapi.sh to create a kind cluster, deploy the CRDs, and install metalLB.

Then I run:

./ingress-operator start-gatewayclass

TODO

• Replace OLM-based install with Helm-Base install
• Add Watches for Helm Objects (deployments, services, etc...)
• Add a upgrade POC for migration from OLM-based install to Helm
• Provide a POC kind-cluster start script
• Explore how images will be added to the OCP Payload
• Explore how charts will be added to the OCP Payload
• Clean up/uninstall GatewayClass testing & logic

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@gcs278: This pull request references NE-2437 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Replace OLM-based Istio installation with direct Helm chart installation using sail-operator's ChartManager library. This is currently a POC used to explore the feasibility of Helm-based installations for Istiod in the Ingress Operator.

This POC uses a start-gatewayclass command that runs only the updated gatewayclass controller against a cluster, bypassing the need to deploy and configure the full ingress-operator. This is so that I can quickly iterate inside a kind cluster.

Testing

I'm testing in a kind cluster that leverages gwapi.sh to create a kind cluster, deploy the CRDs, and install metalLB (I'll provide a quick-launch script later).

Then I run:

./ingress-operator start-gatewayclass

TODO

• Replace OLM-based install with Helm-Base install
• Add Watches for Helm Objects (deployments, services, etc...)
• Add a upgrade POC for migration from OLM-based install to Helm
• Provide a POC kind-cluster start script
• Explore how images will be added to the OCP Payload
• Explore how charts will be added to the OCP Payload
• Clean up/uninstall GatewayClass testing & logic

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@gcs278: This pull request references NE-2437 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Replace OLM-based Istio installation with direct Helm chart installation using sail-operator's ChartManager library. This is currently a POC used to explore the feasibility of Helm-based installations for Istiod in the Ingress Operator.

This POC uses a start-gatewayclass command that runs only the updated gatewayclass controller against a cluster, bypassing the need to deploy and configure the full ingress-operator. This is so that I can quickly iterate inside a kind cluster.

Testing

I'm testing in a kind cluster that leverages gwapi.sh to create a kind cluster, deploy the CRDs, and install metalLB (I'll provide a quick-launch script later).

Then I run:

./ingress-operator start-gatewayclass

TODO

• Replace OLM-based install with Helm-Base install
• Provide a POC kind-cluster start script
• Add Watches for Helm Objects (deployments, services, etc...)
• Add a upgrade POC for migration from OLM-based install to Helm
• Explore how images will be added to the OCP Payload
• Explore how charts will be added to the OCP Payload
• Clean up/uninstall GatewayClass testing & logic

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@gcs278: This pull request references NE-2437 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Replace OLM-based Istio installation with direct Helm chart installation using sail-operator's ChartManager library. This is currently a POC used to explore the feasibility of Helm-based installations for Istiod in the Ingress Operator.

This POC uses a start-gatewayclass command that runs only the updated gatewayclass controller against a cluster, bypassing the need to deploy and configure the full ingress-operator. This is so that I can quickly iterate inside a kind cluster.

Testing

I'm testing in a kind cluster that leverages gwapi.sh to create a kind cluster, deploy the CRDs, and install metalLB (I'll provide a quick-launch script later).

Then I run:

./ingress-operator start-gatewayclass

TODO

• Replace OLM-based install with Helm-Base install
• Provide a POC kind-cluster start script
• Add Watches for Helm Objects (deployments, services, etc...)
• Add a upgrade POC for migration from OLM-based install to Helm
• Explore how images will be added to the OCP Payload
• Explore how charts will be added to the OCP Payload
• Clean up/uninstall GatewayClass testing & logic

Co-Authored-By: Claude Sonnet 4.5 noreply@anthropic.com

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@gcs278: This pull request references NE-2437 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Replace OLM-based Istio installation with direct Helm chart installation using sail-operator's ChartManager library. This is currently a POC used to explore the feasibility of Helm-based installations for Istiod in the Ingress Operator.

This POC uses a start-gatewayclass command that runs only the updated gatewayclass controller against a cluster, bypassing the need to deploy and configure the full ingress-operator. This is so that I can quickly iterate inside a kind cluster.

Testing

I'm testing in a kind cluster that leverages gwapi.sh to create a kind cluster, deploy the CRDs, and install metalLB (I'll provide a quick-launch script later).

Then I run:

./ingress-operator start-gatewayclass

TODO

• Replace OLM-based install with Helm-Base install
• Provide a POC kind-cluster start script
• Add Watches for Helm Objects (deployments, services, etc...)
• Add a upgrade POC for migration from OLM-based install to Helm
• Explore how images will be added to the OCP Payload
• Explore how charts will be added to the OCP Payload
• Clean up/uninstall GatewayClass testing & logic

This POC was developed with assistance from Claude, which helped with code implementation and script development.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[rikatz]

/assign
/cc

[rikatz]

note here is that maybe we may want to start using tagged releases once this approach becomes production ready. So we can tie a version of CIO with a released version of Sail

[rikatz]

I think we should probably not make the GatewayClass own the Helm installation, but something else (maybe the same resource that makes CIO). My concern is: if a user removes a GatewayClass, would it remove the helm chart or make Kubernetes garbage collect the resources?

[gcs278]

My concern is: if a user removes a GatewayClass, would it remove the helm chart or make Kubernetes garbage collect the resources?

yes - it would garbage collect the helm chart and all of the resources it created (including istiod). However, in my testing, the control plane and the data plane are not connected via any finalizers/ownerReferences/etc...so deleting the Istiod control plane does not cascade to deleting the data plane (it just gets orphaned).

Today, if you delete a GatewayClass, the following happens:

1. Since the Istio CR has an ownerRef of the GatewayClass, that get's deleted
2. Since the IstioRevision has an ownerRef of the Istio CR, that get deleted
3. Since the IstioRevision CR has a finalizer added, the Sail Operator will block deletion until it deletes the helm charts
4. The helm charts are deleted

So, effectively, this is the same behavior as today. Delete the GatewayClass, and the Helm chart gets deleted.

[openshift-ci-robot]

@gcs278: This pull request references NE-2437 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Replace OLM-based Istio installation with direct Helm chart installation using sail-operator's ChartManager library. This is currently a POC used to explore the feasibility of Helm-based installations for Istiod in the Ingress Operator.

This POC uses a start-gatewayclass command that runs only the updated gatewayclass controller against a cluster, bypassing the need to deploy and configure the full ingress-operator. This is so that I can quickly iterate inside a kind cluster.

Testing

I'm testing in a kind cluster that leverages gwapi.sh to create a kind cluster, deploy the CRDs, and install metalLB (I'll provide a quick-launch script later).

Then I run:

./ingress-operator start-gatewayclass

TODO

• Replace OLM-based install with Helm-Base install
• Provide a POC kind-cluster start script
• Add a upgrade POC for migration from OLM-based install to Helm
• Add Watches for Helm Objects (deployments, services, etc...)
• Explore how images will be added to the OCP Payload
• Explore how charts will be added to the OCP Payload
• Clean up/uninstall GatewayClass testing & logic

This POC was developed with assistance from Claude, which helped with code implementation and script development.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from rikatz. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci-robot]

@gcs278: This pull request references NE-2437 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Replace OLM-based Istio installation with direct Helm chart installation using sail-operator's ChartManager library. This is currently a POC used to explore the feasibility of Helm-based installations for Istiod in the Ingress Operator.

This POC uses a start-gatewayclass command that runs only the updated gatewayclass controller against a cluster, bypassing the need to deploy and configure the full ingress-operator. This is so that I can quickly iterate inside a kind cluster.

Testing

To test this POC in a local kind cluster:

# Create and configure a kind cluster with Gateway API CRDs
./hack/setup-kind-cluster-for-helm-poc.sh

# Run the isolated gatewayclass controller POC
./ingress-operator start-gatewayclass

# In another terminal, create a GatewayClass to trigger Helm installation
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
 name: openshift-default
spec:
 controllerName: openshift.io/gateway-controller/v1
EOF

# Verify the Helm release and istiod deployment
helm list -A
kubectl get pods -n openshift-ingress

The setup-kind-poc target creates a kind cluster, installs Gateway API CRDs from vendored assets, creates required namespaces, and builds the operator binary.

TODO

• Replace OLM-based install with Helm-Base install
• Provide a POC kind-cluster start script
• Add a upgrade POC for migration from OLM-based install to Helm
• Add Watches for Helm Objects (deployments, services, etc...)
• Explore how images will be added to the OCP Payload
• Explore how charts will be added to the OCP Payload
• Clean up/uninstall GatewayClass testing & logic

This POC was developed with assistance from Claude, which helped with code implementation and script development.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@gcs278: This pull request references NE-2437 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Replace OLM-based Istio installation with direct Helm chart installation using sail-operator's ChartManager library. This is currently a POC used to explore the feasibility of Helm-based installations for Istiod in the Ingress Operator.

This POC uses a start-gatewayclass command that runs only the updated gatewayclass controller against a cluster, bypassing the need to deploy and configure the full ingress-operator. This is so that I can quickly iterate inside a kind cluster.

Testing

To test this POC in a local kind cluster:

# Create and configure a kind cluster with Gateway API CRDs
./hack/setup-kind-cluster-for-helm-poc.sh

# Run the isolated gatewayclass controller POC
./ingress-operator start-gatewayclass

# In another terminal, create a GatewayClass to trigger Helm installation
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
 name: openshift-default
spec:
 controllerName: openshift.io/gateway-controller/v1
EOF

# Verify the Helm release and istiod deployment
helm list -A
kubectl get pods -n openshift-ingress

The setup-kind-poc target creates a kind cluster, installs Gateway API CRDs from vendored assets, creates required namespaces, and builds the operator binary.

TODO

• Replace OLM-based install with Helm-Base install
• Provide a POC kind-cluster start script
• Add a upgrade POC for migration from OLM-based install to Helm
• Add Watches for Helm Objects (deployments, services, etc...)
• Explore how images will be added to the OCP Payload
• Explore how charts will be added to the OCP Payload
• Clean up/uninstall GatewayClass testing & logic

This POC was developed with assistance from Claude, which helped with code implementation and script development.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@gcs278: This pull request references NE-2437 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Replace OLM-based Istio installation with direct Helm chart installation using sail-operator's ChartManager library. This is currently a POC used to explore the feasibility of Helm-based installations for Istiod in the Ingress Operator.

This POC uses a start-gatewayclass command that runs only the updated gatewayclass controller against a cluster, bypassing the need to deploy and configure the full ingress-operator. This is so that I can quickly iterate inside a kind cluster.

Testing

To test this POC in a local kind cluster:

# Create and configure a kind cluster with Gateway API CRDs
./hack/setup-kind-cluster-for-helm-poc.sh

# Run the isolated gatewayclass controller POC
./ingress-operator start-gatewayclass

# In another terminal, create a GatewayClass to trigger Helm installation
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
 name: openshift-default
spec:
 controllerName: openshift.io/gateway-controller/v1
EOF

# Verify the Helm release and istiod deployment
helm list -A
kubectl get pods -n openshift-ingress

TODO

• Replace OLM-based install with Helm-Base install
• Provide a POC kind-cluster start script
• Add a upgrade POC for migration from OLM-based install to Helm
• Add Watches for Helm Objects (deployments, services, etc...)
• Explore how images will be added to the OCP Payload
• Explore how charts will be added to the OCP Payload
• Clean up/uninstall GatewayClass testing & logic

This POC was developed with assistance from Claude, which helped with code implementation and script development.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@gcs278: This pull request references NE-2437 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Replace OLM-based Istio installation with direct Helm chart installation using sail-operator's ChartManager library. This is currently a POC used to explore the feasibility of Helm-based installations for Istiod in the Ingress Operator.

This POC uses a start-gatewayclass command that runs only the updated gatewayclass controller against a cluster, bypassing the need to deploy and configure the full ingress-operator. This is so that I can quickly iterate inside a kind cluster.

Testing

To test this POC in a local kind cluster:

# Create and configure a kind cluster with Gateway API CRDs
./hack/setup-kind-cluster-for-helm-poc.sh

# Run the isolated gatewayclass controller POC
./ingress-operator start-gatewayclass

# In another terminal, create a GatewayClass to trigger Helm installation
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
 name: openshift-default
spec:
 controllerName: openshift.io/gateway-controller/v1
EOF

# Verify the Helm release and istiod deployment
helm list -A
kubectl get pods -n openshift-ingress

TODO

• Replace OLM-based install with Helm-Base install
• Provide a POC kind-cluster start script
• Add a upgrade POC for migration from OLM-based install to Helm
• Add Watches for Helm Objects (deployments, services, etc...)
• Explore how images will be added to the OCP Payload
• Explore how charts will be added to the OCP Payload
• Clean up/uninstall GatewayClass testing & logic

This POC was developed with assistance from Claude, which helped with code implementation and script development.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[gcs278]

closing in favor of the implementation #1354

[openshift-ci]

@gcs278: Closed this PR.

Details

In response to this:

closing in favor of the implementation
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.