Feature request: CRD for Service Definition

[jcogilvie]

The Datadog integrations with Kubernetes already provide a series of CRDs for metrics and monitors as well as the CRDs provided here for the operator. An additional useful resource would be a Service Definition.

It could behave much the same way as creating a Service Definition in Terraform (see here: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/service_definition_yaml) but the yaml would be validated for formatting and stored in the kubernetes cluster alongside the app it describes, while the operator keeps it up to date in the DataDog account.

Storing it in k8s alongside the apps provides unique opportunities for enrichment based on tags, labels, and other data available at the namespace level.

[demolitionmode]

It could behave much the same way as creating a Service Definition in Terraform

Do you think something like the following would be a reasonable manifest? It's essentially the same as the Terraform input

apiVersion: datadoghq.com/v2alpha1
kind: DatadogServiceDefinition
metadata:
  name: foo
spec:
  serviceDefinition: |
    schema-version: v2.2
    dd-service: shopping-cart
    team: e-commerce-team
    ...

and for Backstage-type definition

apiVersion: datadoghq.com/v2alpha1
kind: DatadogServiceDefinition
metadata:
  name: foo
spec:
  serviceDefinition: |
    apiVersion: backstage.io/v1alpha1
    kind: Component
    metadata:
      annotations:
        backstage.io/techdocs-ref: http://a/b/c
        some.annotation: value
      namespace: default
      name: shopping-cart

[jcogilvie]

I believe that would be reasonable as a first pass.

Ultimately since we know the schema ahead of time it would make sense to codify that in the CRD.

For a backstage-derived DatadogServiceDefinition, it might make sense to have a reference like so, assuming the shopping-cart resource is defined in the local cluster:

serviceDefinitionRef:
  apiGroup: backstage.io
  kind: Component
  name: shopping-cart
  namespace: default