Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(datadog_metrics sink): support and migrate to the
v2
series API endpoint #18761chore(datadog_metrics sink): support and migrate to the
v2
series API endpoint #18761Changes from 14 commits
d8891fd
91ca255
9afbd83
cc9cc2d
597305d
3f9cd72
4e204c5
3a96f18
9923219
4523fcd
a87bf0c
376da18
715cf22
7117d98
5912324
c95a326
d73cfe0
c9c0fbc
2ac5bbf
cb92dc5
96ef122
2de3617
b9181e0
4920c7c
d513eaf
244b9ed
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the goal with all the configurable stuff here? Seems like the intent to move wholesale to the v2 API, since there's nothing exposed to allow staying on/switching back to the v1 API, at least from the user's perspective.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I was going to call this out when I finalized the PR, but I recall chatting with @jszwedko about this (the history of the convo is gone though) . I don't remember the details but I believe the conclusion was we wanted to keep the v1 logic if it wasn't too difficult to do so. We had discussed allowing the api version to be configurable somehow, but felt that wasn't necessary.
So I think it might boil down to us wanting to be able to flip a switch to go back to V1 if there were issues with our rollout of V2.
Another idea I had thrown out was having a non publicized backdoor essentially, that would allow a user to configure to use the v1. Its possible we could do that with the
endpoint
configuration I think. We'd just have to have some uglier logic in the parsing of that for this sink, since it isn't supposed to specify thepath
, just the host/port.TLDR ... Its open for discussion 😆
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I see including the fallback as a risk mitigation measure so that if it does break things, users have a workaround until we fix it. We can weigh the risk against the level of effort to maintain the v1 implementation though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In it's current state, users would have to edit the code and recompile in order to take advantage of that. But, my suggestion here:
, would allow us to give users a workaround that would just entail editing their config. If we did this, could tag it with a TODO and followup GH issue to remove the backdoor and the v1 support altogether, once it had enough soak time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we'd like to expose this to the end user temporarily as we roll out this change, an unpublicized environment variable could be a good option. Something like
VECTOR_TEMP_USE_DD_METRICS_SERIES_V1_API
that clearly denotes that it is a temporary env variable that will be removed.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can get behind a temporary env var.
To clarify- IMO I think we would only want to maintain the v1 implementation for a full release, maybe two. But after its clear there aren't issues, we'd remove it. In my view the maintenance burden of supporting the v1 implementation for a release or two should be very small if not zero.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added the env var in the latest changes and made code comments regarding the temporary support of V1. Since this isn't a user-facing deprecation/change, I dont think we need to follow the formal DEPRECATION policy if I'm not mistaken
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Which I validated works by injecting it in the vdev env vars and seeing the debug logs from the integration tests)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed, I noted this in the DEPRECATIONS file but am holding off on a mention to the upgrade guide as its not a user facing change and is lowish risk