K8s injector dev first scenario

[robertomonteromiguel]

Motivation

Create the first injector-dev scenario.
As first example we use this injector dev scenario: https://github.com/DataDog/injector-dev/blob/main/tests/helm/single-service/scenario.yaml
In this PR is NOT included the CI execution.
These classes are generated by GitHub Copilot:

• utils/injector_dev/harness.py: Used for perform the test assertions, and we automatically generated from the GO source: tests/helm/single-service/scenario_test.go
• utils/injector_dev/scenario_provision_updater.py: Updates the yaml scenario template injecting the references of the cluster-agent,apm-inject and lib-init images. The resulting file will be in the scenario log folder.

You can run manually this scenario:

./run.sh K8S_INJECTOR_DEV_SINGLE_SERVICE --k8s-library python --k8s-weblog dd-lib-python-init-test-django --k8s-weblog-img ghcr.io/datadog/system-tests/dd-lib-python-init-test-django:latest --k8s-cluster-img gcr.io/datadoghq/cluster-agent:latest --k8s-lib-init-img gcr.io/datadoghq/dd-lib-python-init:latest --k8s-injector-img gcr.io/datadoghq/apm-inject:latest 

./run.sh K8S_INJECTOR_DEV_SINGLE_SERVICE --k8s-library java --k8s-weblog dd-lib-java-init-test-app --k8s-weblog-img ghcr.io/datadog/system-tests/dd-lib-java-init-test-app:latest --k8s-cluster-img gcr.io/datadoghq/cluster-agent:latest --k8s-lib-init-img gcr.io/datadoghq/dd-lib-java-init:latest --k8s-injector-img gcr.io/datadoghq/apm-inject:latest

./run.sh K8S_INJECTOR_DEV_SINGLE_SERVICE --k8s-library nodejs --k8s-weblog sample-app --k8s-weblog-img ghcr.io/datadog/system-tests/sample-app:latest --k8s-cluster-img gcr.io/datadoghq/cluster-agent:latest --k8s-lib-init-img gcr.io/datadoghq/dd-lib-js-init:latest --k8s-injector-img gcr.io/datadoghq/apm-inject:latest


./run.sh K8S_INJECTOR_DEV_SINGLE_SERVICE --k8s-library dotnet --k8s-weblog dd-lib-dotnet-init-test-app --k8s-weblog-img ghcr.io/datadog/system-tests/dd-lib-dotnet-init-test-app:latest --k8s-cluster-img gcr.io/datadoghq/cluster-agent:latest --k8s-lib-init-img gcr.io/datadoghq/dd-lib-dotnet-init:latest --k8s-injector-img gcr.io/datadoghq/apm-inject:latest 


./run.sh K8S_INJECTOR_DEV_SINGLE_SERVICE --k8s-library ruby --k8s-weblog dd-lib-ruby-init-test-rails --k8s-weblog-img ghcr.io/datadog/system-tests/dd-lib-ruby-init-test-rails:latest --k8s-cluster-img gcr.io/datadoghq/cluster-agent:latest --k8s-lib-init-img gcr.io/datadoghq/dd-lib-ruby-init:latest --k8s-injector-img gcr.io/datadoghq/apm-inject:latest


./run.sh K8S_INJECTOR_DEV_SINGLE_SERVICE --k8s-library php --k8s-weblog dd-lib-php-init-test-app --k8s-weblog-img ghcr.io/datadog/system-tests/dd-lib-php-init-test-app:latest --k8s-cluster-img gcr.io/datadoghq/cluster-agent:latest --k8s-lib-init-img gcr.io/datadoghq/dd-lib-php-init:latest --k8s-injector-img gcr.io/datadoghq/apm-inject:latest

Known problems

1. Injector repository param

I’m using the field repository and tag field to point to the apm-injector image. e.g:

  versions:
    agent: "7.64.0"
    cluster_agent: "7.64.0"
    injector:
      repository: ghcr.io/datadog/apm-inject
      tag: latest_snapshot

But I’m getting this failure:
Back-off pulling image "gcr.io/datadoghq/apm-inject:latest_snapshot"
It seems that I’m using the config in a wrong way or there is a bug in the injector-dev, because it’s ignoring the repository value

2. tracerVersion

I would like to parametrize the “tracerVersions” to allow us to point the different lib-init image (latest_snapshot and latest). But it seems that it’s imposible.
This the current config in the injector-dev:

  config:
    datadog:
      apm:
        instrumentation:
          enabled: true
          targets:
            - name: "billing-service"
              podSelector:
                matchLabels:
                  app: "billing-service"
              namespaceSelector:
                matchNames:
                  - "application"
              ddTraceVersions:
                python: "latest"
              ddTraceConfigs:
                - name: "DD_PROFILING_ENABLED"
                  value: "true"

And that is that I would like to do:

  config:
    datadog:
      apm:
        instrumentation:
          enabled: true
          targets:
            - name: "billing-service"
              podSelector:
                matchLabels:
                  app: "billing-service"
              namespaceSelector:
                matchNames:
                  - "application"
              ddTraceVersions:
                python:
                  repository: gcr.io/datadoghq/dd-lib-python-init 
                  tag: latest
              ddTraceConfigs:
                - name: "DD_PROFILING_ENABLED"
                  value: "true"

But I think this is not supported, because I’m getting this error:

> - datadog.apm.instrumentation.targets.0.ddTraceVersions.python: Invalid type. Expected: string, given: object
> 
> INSTALLATION FAILED
> main.newInstallCmd.func2
>       helm.sh/helm/v3/cmd/helm/install.go:127
> github.com/spf13/cobra.(*Command).execute
>       github.com/spf13/[email protected]/command.go:856
> github.com/spf13/cobra.(*Command).ExecuteC
>       github.com/spf13/[email protected]/command.go:974
> github.com/spf13/cobra.(*Command).Execute
>       github.com/spf13/[email protected]/command.go:902
> main.main
>       helm.sh/helm/v3/cmd/helm/helm.go:83
> runtime.main
>       runtime/proc.go:250
> runtime.goexit
>       runtime/asm_arm64.s:1263

Changes

Workflow

1. ⚠️ Create your PR as draft ⚠️
2. Work on you PR until the CI passes (if something not related to your task is failing, you can ignore it)
3. Mark it as ready for review
   • Test logic is modified? -> Get a review from RFC owner. We're working on refining the codeowners file quickly.
   • Framework is modified, or non obvious usage of it -> get a review from R&P team

🚀 Once your PR is reviewed, you can merge it!

🛟 #apm-shared-testing 🛟

Reviewer checklist

• If PR title starts with [<language>], double-check that only <language> is impacted by the change
• No system-tests internal is modified. Otherwise, I have the approval from R&P team
• CI is green, or failing jobs are not related to this change (and you are 100% sure about this statement)
• A docker base image is modified?
  • the relevant build-XXX-image label is present
• A scenario is added (or removed)?
  • Get a review from R&P team