datadog-agent
datadog-agent copied to clipboard
pkg/trace/api: Upgrade debugger proxy to use logs V2 intake
What does this PR do?
Upgrade the debugger proxy to upload snapshots and probe status using logs intake API V2
Motivation
Ensure we are using the latest API version
Describe how to test/QA your changes
- Testing debugger api endpoint and see messages appear on datadog portal
- Testing on staging to ensure everything works as expected
Reviewer's Checklist
- [ ] If known, an appropriate milestone has been selected; otherwise the
Triagemilestone is set. - [ ] Use the
major_changelabel if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote. - [ ] A release note has been added or the
changelog/no-changeloglabel has been applied. - [ ] Changed code has automated tests for its functionality.
- [ ] Adequate QA/testing plan information is provided if the
qa/skip-qalabel is not applied. - [ ] At least one
team/..label has been applied, indicating the team(s) that should QA this change. - [ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
- [ ] If applicable, the
need-change/operatorandneed-change/helmlabels have been applied. - [ ] If applicable, the
k8s/<min-version>label, indicating the lowest Kubernetes version compatible with this feature. - [ ] If applicable, the config template has been updated.
Can you elaborate a bit on the QA steps here? I'm not very familiar with the debugging parts of the trace-agent. Are there any automated tests, integration or end to end tests that need to be updated as part of this change?
hi @ajgajg1134, we are running e2e test on our backend on staging to verify snapshots get created and can be read from logs. As this API is just a proxy to logs backend we have unit-tests verify the requests get generated as expected. But we are not mocking logs backend.
Do you want to create e2e tests for this proxy? if so, I would love to understand more how those things works.
I think for what the proxy is doing it should not be required to create more elaborate tests. As @shatzi said, we have continuous e2e tests in place in our backend that assert the proxy endpoint is working as expected. There should be no change necessary for QA. Once the RC is deployed to staging our monitoring will notify us if anything isn't working as expected.
That all sounds fine! I just wanted to be aware of what QA / testing existed to ensure this change was as expected / required. I agree that I don't think tests on the proxy itself are strictly necessary.
From DI POV this looks good.
Tried to add the agent version but that broke due to dependency roles between core-agent and tracer-agent.