Charts[Gateway] Envoy Gateway Is Not Uninstalled Properly On destroy-gateway-api command

[leninmehedy]

Bill of Materials or CLI Version

No response

Execution Environment

JUnit Extensions

Slf4j Logging Implementation

None

To Reproduce

1. Run make deploy-gateway-api
2. Check that two namespaces are created as envoy-gateway-system and gateway-system
3. Run make destroy-gateway-api
4. Check that gateway-system still exists

Describe the bug

For local development, we deploy envoy-gateway in the cluster manually. Sometimes we also want to clean it up for various ingress testing.

When installing envoy-gateway it creates two namespaces as envoy-gateway-system and gateway-system.

So when we want to uninstall, we need to remove those two namespaces.

Describe the expected behavior

When we run make destroy-gateway-api, two related namespace and resources in envoy-gateway-system and gateway-system namespace should be removed

Whole JUnit/CLI Logs

After running destroy-gateway-api, the pods are still running in gateway-system:

 kubectl get pod --all-namespaces -o wide
                                                                                                                                                             
NAMESPACE              NAME                                            READY   STATUS      RESTARTS   AGE    IP            NODE                NOMINATED NODE   READINESS GATES
envoy-gateway-system   envoy-gateway-6599855d95-xxqlm                  2/2     Running     0          14s    10.244.0.47   fst-control-plane   <none>           <none>
gateway-system         gateway-api-admission-mj5pb                     0/1     Completed   0          119s   10.244.0.42   fst-control-plane   <none>           <none>
gateway-system         gateway-api-admission-patch-tmpvr               0/1     Completed   1          119s   10.244.0.41   fst-control-plane   <none>           <none>
gateway-system         gateway-api-admission-server-57f485f78f-vj2qp   1/1     Running     0          119s   10.244.0.43   fst-control-plane   <none>           <none>
kube-system            coredns-5d78c9869d-48kzz                        1/1     Running     0          24m    10.244.0.3    fst-control-plane   <none>           <none>
kube-system            coredns-5d78c9869d-v847d                        1/1     Running     0          24m    10.244.0.2    fst-control-plane   <none>           <none>
kube-system            etcd-fst-control-plane                          1/1     Running     0          24m    172.18.0.2    fst-control-plane   <none>           <none>
kube-system            kindnet-qct97                                   1/1     Running     0          24m    172.18.0.2    fst-control-plane   <none>           <none>
kube-system            kube-apiserver-fst-control-plane                1/1     Running     0          24m    172.18.0.2    fst-control-plane   <none>           <none>
kube-system            kube-controller-manager-fst-control-plane       1/1     Running     0          24m    172.18.0.2    fst-control-plane   <none>           <none>
kube-system            kube-proxy-slsrb                                1/1     Running     0          24m    172.18.0.2    fst-control-plane   <none>           <none>
kube-system            kube-scheduler-fst-control-plane                1/1     Running     0          24m    172.18.0.2    fst-control-plane   <none>           <none>
local-path-storage     local-path-provisioner-6bc4bddd6b-tgc5k         1/1     Running     0          24m    10.244.0.4    fst-control-plane   <none>           <none>

Additional Context

No response

[swirlds-automation]

🎉 This issue has been resolved in version 0.12.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀