Hello, I have Flyte server deployed to EKS clusters in three different environments (dev, beta and prod ). How in Flyte task code to get the environment it’s running in? I am aware of one way that requires to register the workflow in different domains.

os.getenv("FLYTE_INTERNAL_TASK_DOMAIN", "dev")

However, it’s not telling the EKS environment.

Sorry, what do you mean by EKS environment, Frank? Do you not want to fetch the Flyte domain?

I’m pretty sure that Frank has 3 instances of flyte setup in three different aws accounts. @Frank Shen can you use boto to grab the aws account ID and keep a dict mapping AWS ID -> ENV? My intuition says there there is a k8s way to do this by adding default env vars somewhere in the helm charts, but I don’t have the k8s knowledge or flyte context to know for sure.

dict mapping AWS ID -> ENV is an ingenious way Thank you @Evan Sadler!

@Frank Shen unfortunately I am not sure what this is from. It would have been Justin who set that up

Hi @Evan Sadler, Do you know the last name / initial of Justin?

I think is was Justin LaRose

Hi @Evan Sadler, In the Bolt Flyte dev cluster, There are these k8s secrets. 1. flyte-postgresql-manualcopy. Do you remember how this was created? And How do I retrieve the decrypted password?

common:
            ### This secret needs to exist in the flyte namespace prior.
            databaseSecret:
              name: flyte-postgresql-manualcopy

In the example values from Flyte:

databaseSecret:
    name: db-pass
    secretManifest:
      # -- Leave it empty if your secret already exists
      # Else you can create your own secret object. You can use Kubernetes secrets, else you can configure external secrets
      # For external secrets please install Necessary dependencies, like, of your choice
      # - <https://github.com/hashicorp/vault>
      # - <https://github.com/godaddy/kubernetes-external-secrets>
      apiVersion: v1
      kind: Secret
      metadata:
        name: db-pass
      type: Opaque
      stringData:
        # -- If using plain text you can provide the password here
        pass.txt: "{{ .Values.userSettings.dbPassword }}"

2. flyte-secret-auth, how was this secret created? and how was the additional FLYTE_DATABRICKS_API_TOKEN got added?

kubectl get secret -n flyte flyte-secret-auth -o json
{
    "apiVersion": "v1",
    "data": {
        "FLYTE_DATABRICKS_API_TOKEN": "ZGFwaTkwZWUzMzkzMjA2YzdmNDk2NmJjYWQwZjM4ODdiOTli",
        "client_secret": "Zm9vYmFyCg=="
    },
    "kind": "Secret",

The example values:

secrets:
  adminOauthClientCredentials:
    # -- If enabled is true, helm will create and manage `flyte-secret-auth` and populate it with `clientSecret`.
    # If enabled is false, it's up to the user to create `flyte-secret-auth` as described in
    # <https://docs.flyte.org/en/latest/deployment/cluster_config/auth_setup.html#oauth2-authorization-server>
    enabled: true
    clientSecret: foobar
    clientId: flytepropeller

If it’s created automatically by Flyte as described above (setting enabled: true) , then what was the decrypted clientSecret value? In the dev cluster’s overriding values:

secrets:
            adminOauthClientCredentials:
              enabled: false
              clientId: 0oa3op8ubeMDXDCcC697

How come the clientId got changed from the default value ‘flytepropeller’? Thank you very much if you can provide any useful history of the secrets!