[Request] Default recording name, or name template interpolation

[grzesuav]

Describe the feature

Would be great if the name of new recording could default to namespace_pod_start_time instead of empty, or even better - to set a default template using labels / cryostat annotations as they are present - {{NAMESPACE}}_{{POD_NAME}}_{{current_time}}

Cryostat annotations

Anything other information?

No response

[andrewazores]

Those labels and annotations are only present/make sense to use in the case that Cryostat is deployed in a Kubernetes environment, and that the target application you're looking at was discovered via its built-in Kubernetes API Endpoints mechanism. Any default name applied here would need to be somehow genericized so that it would either be applicable in all cases (deployed in Docker Swarm, or using the Cryostat Agent where the Namespace annotation would not be present, etc.), or else somehow this default naming scheme needs to be dependent on which of those attributes are actually available at runtime, or dependent on the discovery mechanism that produces this target application record.

Perhaps simply generating a semi-randomized name and instead including these various optional attributes as recording labels could be another solution to this problem?

Related to #41

[grzesuav]

got it, make sense for me. Actually in case of using cryistat agent, what metadata is exposed ? I probably will test this approach soon, I wonder how many metadata we can attach from k8s

[andrewazores]

The Cryostat Agent is also designed to be rather generic and isn't very aware of whether it is running in Kubernetes, or in a container at all for that matter. It does know how to look for a serviceaccount token file that Kubernetes may mount, but that is the extent of its integration to Kubernetes. It doesn't have anything like a Kubernetes client, so it is unable to determine its own Namespace, Pod name, or anything else like that.

When you set up the Cryostat Agent on your application Deployment, you must configure the Agent's Callback URL:

https://cryostat.io/get-started/#using-the-cryostat-agent

            - name: POD_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
            - name: CRYOSTAT_AGENT_CALLBACK
              # This infers the Agent Callback directly from the Pod's IP address using the
              # Kubernetes Downward API. Use this value directly as provided. The port number
              # 9977 can be changed but must match the containerPort below.
              value: "http://$(POD_IP):9977"
              # Replace "abcd1234" with a base64-encoded authentication token. For example,
              # in your terminal, do 'oc whoami -t | base64' to use your user account's
              # token as the token that the Agent will pass to authorize itself with
              # the Cryostat server.

Rather than using the Downward API to expose the POD_IP, you could probably instead inject other Kubernetes Pod DNS values into environment variables, then configure the Callback URL to reference these instead of the raw cluster-internal IP address. This way, when your Agent instances register with Cryostat, the target connection URL could include your pod name and namespace.

[andrewazores]

I filed a separate issue (linked above) to track that idea of allowing some generic configuration option so that as the end user, you can link existing environment variables into the metadata that the Agent publishes about itself to the Cryostat server. This way you could do things like include the Pod Name or Namespace into target labels, which sounds quite useful.

I'm thinking of other solutions for the recording name problem as well. I don't want to change the backend API definition here, but I think it would be reasonable to have the Web UI generate some default name suggestion, and this could include various optional properties about the selected target. What might be really interesting is to allow a limited form of string templating here, almost similar to the Match Expressions used for stored credentials and automated rules matching on the backend,

https://stackoverflow.com/questions/49034218/setting-context-for-es6-template-literal-within-a-function-constructor

so that the expressions you wrote like {{NAMESPACE}}_{{POD_NAME}} could actually be written into the recording name field and the UI would automatically interpolate that for you. I think instead this would look more like ${target.labels.NAMESPACE}_${target.annotations.platform.POD_NAME}, but it's a similar idea.

[andrewazores]

Or, instead of using a frontend string interpolation and having a somewhat different syntax, we could probably create an API endpoint on the backend specifically for doing this kind of interpolation - or else just extend it so that the recording names are interpreted as CEL expressions (same as automated rules or stored credentials' match expressions), and the interpolation can happen there instead.