feat: Add APM to DatadogInstrumentation CRD

[betterengineering]

What does this PR do?

This commit adds the schema required to utilize the DatadogInstrumentation CRD for APM. Relates to #2962

Example

apiVersion: datadoghq.com/v1alpha1
kind: DatadogInstrumentation
metadata:
  name: redis-check
  namespace: cache
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: example-service
  config:
    apm:
      enabled: true
      ddTraceVersions:
        python: "3"
      ddTraceConfigs:
        - name: "DD_PROFILING_ENABLED"
          value: "true"

Motivation

Two relevant RFCs:

• RFC: Datadog Instrumentation CRD
• DatadogInstrumentation CRD for Workload-Scoped Product Enablement

Additional Notes

All this adds is the schema. The consumer of this schema is the Datadog Cluster Agent.

Describe your test plan

Ran:

make generate
make manifests
go test ./api/...
bin/darwin-arm64/operator-sdk bundle validate ./bundle

Also verified make generate && make manifests produces no additional diff after generated files are up to date.

Checklist

• PR has at least one valid label: bug, enhancement, refactoring, documentation, tooling, and/or dependencies
• PR has a milestone or the qa/skip-qa label
• All commits are signed (see: signing commits)

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1ed1d9455e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Update the OLM bundle CRD with the APM schema

This adds spec.config.apm to the generated CRD under config/crd, but the stored OLM bundle CRD was not regenerated: bundle/manifests/datadoghq.com_datadoginstrumentations.yaml still has only config.properties.checks and no apm/ddTraceConfigs entry (verified with rg ddTraceConfigs bundle/manifests/datadoghq.com_datadoginstrumentations.yaml). Because bundle.Dockerfile copies bundle/manifests into the published bundle, installations through the operator bundle will install the old CRD and Kubernetes will prune spec.config.apm, so the Cluster Agent will never see the APM settings for those users.

Useful? React with 👍 / 👎.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 42.05%. Comparing base (d1d2b65) to head (1ed1d94).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2984      +/-   ##
==========================================
+ Coverage   41.39%   42.05%   +0.65%     
==========================================
  Files         331      331              
  Lines       28911    29724     +813     
==========================================
+ Hits        11969    12499     +530     
- Misses      16086    16323     +237     
- Partials      856      902      +46     

Flag	Coverage Δ
unittests	42.05% <ø> (+0.65%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 16 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d1d2b65...1ed1d94. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[datadog-prod-us1-5]

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 42.16% (+1.03%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 1ed1d94 | Docs | Datadog PR Page | Give us feedback!}

[Mathew-Estafanous]

Is an enabled section needed? The APM config already implies this based if the section is added (enabled) or removed (disabled).

[betterengineering]

The other two fields are optional and have default values. So I thought it would be weird if we did something like:

config:
  apm: {}

The current design looks like this, and it's what most users would need to do:

config:
  apm:
    enabled: true

I agree though, this case feels redundent:

config:
  apm:
    enabled: true
    ddTraceVersions:
      python: "3"

Do you think there is a way around this?

[Mathew-Estafanous]

Ahh I see. I can't think of anything better to be honest and apm: {} is definitely not the right choice. I'm good to keep enabled. 👍🏽

[Mathew-Estafanous]

Looks great!