Hi, I’m trying to deploy a Flyte cluster to GCP following the Opta deployment documenation (https://docs.flyte.org/en/v1.0.0/deployment/gcp/opta.html), however, I’m getting the following error after running `opta apply -c env.yaml`:

Error: unable to build kubernetes objects from release manifest: [resource mapping not found for name: "linkerd-linkerd-control-plane" namespace: "" from "": no matches for kind "PodSecurityPolicy" in version "policy/v1beta1"
│ ensure CRDs are installed first, resource mapping not found for name: "linkerd-heartbeat" namespace: "linkerd" from "": no matches for kind "CronJob" in version "batch/v1beta1"
│ ensure CRDs are installed first]
│
│   with module.k8sbase.helm_release.linkerd[0],
│   on ../../.opta/modules/gcp_k8s_base/tf_module/linkerd.tf line 60, in resource "helm_release" "linkerd":
│   60: resource "helm_release" "linkerd" {

Any ideas how to fix this?

@Raimundo Manterola I'm afraid the Opta files are not in their best shape. For now, the best option would be to follow the manual steps https://docs.flyte.org/en/v1.0.0/deployment/gcp/manual.html We're working on a reference implementation with Terraform for GCP, it will be out soon. Also, current GCP users share information on #flyte-on-gcp Hope it helps

Thank you for the quick response. Is there any intentions to start supporting Opta again sometime soon? I’ll try following the manual deployment steps, but it would be great to have IaC instead of a manual deployment.

The idea is to support IaC in the form of Terraform modules. Right now they are available here for AWS. GCP will also be published there https://github.com/unionai-oss/deploy-flyte

Cool, thanks for sharing. Just out of curiosity (I’m far from being an infrastructure expert), what is the logic behind the decision of deprecating Opta support in favor of raw Terraform modules?

Opta is convenient, but seems to be not very active these days. Plain TF can be more complex but more customizable. The idea is to provide a reference implementation that incorporates known practices that lead to healthy environments for Flyte, but leave space for custom setups. It's close to a fully automated process. I guess this could change in the future, especially considering the direction the TF/OpenTF projects may take. There are other members in the Flyte community who have tried Pulumi and other options to automate the infra setup. But for now, the idea is to use the TF modules to outline a reference impl. Hope it makes sense.