New Actions CRD in Odigos (What you need to know)
Actions are moving to a new, centralized Kubernetes resource.
If you currently use Actions directly with Kubernetes manifests (i.e., YAML files), then this change affects you!
Starting in v1.4.0, Odigos will no longer use individual Custom Resources (CRDs) for each type of Action. Instead,
all types of Actions can now be defined through a single, generic object, simply called Action
This object will live under the odigos.io API (migrated from the legacy actions.odigos.io).
For example, if you previously defined an AddClusterInfo action with the following:
apiVersion: actions.odigos.io/v1alpha1
kind: AddClusterInfo
metadata:
name: insert-cluster-name
namespace: odigos-system
spec:
actionName: insert-cluster-name
clusterAttributes:
- attributeName: k8s.cluster.name
attributeStringValue: my-cluster
signals:
- TRACES
- METRICS
- LOGS
The equivalent resource will now be:
apiVersion: odigos.io/v1alpha1
kind: Action
metadata:
name: insert-cluster-name
namespace: odigos-system
spec:
actionName: insert-cluster-name
signals:
- TRACES
- METRICS
- LOGS
addClusterInfo:
clusterAttributes:
- attributeName: k8s.cluster.name
attributeStringValue: my-cluster
See our docs on Actions for examples of all types.
Action you do not need to take
If you do not deploy or modify any Actions through YAML manifests or the Kubernetes client, then there is nothing that you need to do. Odigos will automatically migrate any Actions created through the UI to the new resource type and begin using it as if nothing changed.
Action you need to take
If you are deploying YAML manifests for your Actions (such as through CI/CD, Helm, GitOps, etc), or modify Actions through Kubernetes clients, you should migrate your manifests to the new structure.
Odigos will automatically perform a one-way migration of any legacy Actions to the new format. The migrated objects
will have the same name as the detected legacy object with a migrated-legacy- prefix. For example, the
insert-cluster-name object above will be turned into a generic Action called migrated-legacy-insert-cluster-name.
Importantly, changes to the legacy object will not have any effect after this migration. This means you must update any scripts or tools you have developed to make changes via the new object. All Odigos components will automatically use the new object.
In addition, the migrated object will be added as an OwnerReference on the legacy object as part of the migration. This allows the migrated object to be deleted via the Odigos UI (which will also delete the legacy object, and prevent a hot loop of migration).
You can confirm that the migration has taken place on your legacy objects by verifying:
- The presence of a matching
migrated-legacy-*Action in the Odigos system namespace. - The presence of an OwnerReference in the legacy object.
- The Autoscaler logs confirming which objects have been migrated.
Future removal
Currently, Odigos will not remove any existing legacy Action objects. However, in a future version these objects will be removed and the Custom Resource Definition associated with them will no longer be supported. It is therefore critical to migrate any manifests or tools that rely on the legacy API immediately.
More from the blog.
Bring us the question your stack can’t answer.
Our own eBPF. Nothing enters your process.


