-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Create doc for ec2_imdsv2_transition_payload_enabled #27666
base: master
Are you sure you want to change the base?
Conversation
Preview links (active after the
|
I made some edits for compliance with our docs styleguide. I also removed the "What's New" section, because this is a page about IMDSv2 enablement by default—not the new Agent version. I hope the description of what happens to displayed hostname is clearer now. Let me know if you're ready to merge. |
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.
@louis-cqrl Left some comments. Mainly we need to refocus to the appropriate target audience for this page and add more details about the possible effects that they may notice.
Co-authored-by: Srdjan Grubor <[email protected]>
Co-authored-by: cecilia saixue watt <[email protected]>
Co-authored-by: cecilia saixue watt <[email protected]>
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.
Just some styleguide edits. After these are resolved, this should be ready.
content/en/integrations/guide/aws-integration-troubleshooting.md
Outdated
Show resolved
Hide resolved
content/en/integrations/guide/aws-integration-troubleshooting.md
Outdated
Show resolved
Hide resolved
Co-authored-by: cecilia saixue watt <[email protected]>
Co-authored-by: cecilia saixue watt <[email protected]>
Co-authored-by: cecilia saixue watt <[email protected]>
Co-authored-by: cecilia saixue watt <[email protected]>
Co-authored-by: cecilia saixue watt <[email protected]>
Co-authored-by: cecilia saixue watt <[email protected]>
Co-authored-by: cecilia saixue watt <[email protected]>
### Canonical Hostname | ||
|
||
The hostname picked to tag metrics is named the `canonical hostname`, this hostname is the unique ID used to identify your host. Even if your hostname change after upgrading to v7.64.0+, the `canonical hostname` of your host will not change, you can continue to refer to the previous one as before. | ||
Nonetheless you can force the update of your `canonical hostnames` with the `sobotka_allow_override_canonical_name` feature flag. |
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.
Are we sure we want to document this publicly? I haven't really seen us talk about feature flags in the documentation before.
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 may also lean that we only provide this if necessary. We want to track the hosts with instance IDs where possible.
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.
done
### Canonical Hostname | ||
|
||
The hostname picked to tag metrics is named the `canonical hostname`, this hostname is the unique ID used to identify your host. Even if your hostname change after upgrading to v7.64.0+, the `canonical hostname` of your host will not change, you can continue to refer to the previous one as before. | ||
Nonetheless you can force the update of your `canonical hostnames` with the `sobotka_allow_override_canonical_name` feature flag. |
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 may also lean that we only provide this if necessary. We want to track the hosts with instance IDs where possible.
content/en/integrations/guide/aws-integration-troubleshooting.md
Outdated
Show resolved
Hide resolved
content/en/integrations/guide/aws-integration-troubleshooting.md
Outdated
Show resolved
Hide resolved
content/en/integrations/guide/aws-integration-troubleshooting.md
Outdated
Show resolved
Hide resolved
a5334c5
to
d1cffa7
Compare
@louis-cqrl thanks for sharing. Couple minor comments:
|
Thx @vignesh for taking a look 🙇🏻
The idea is to tell to customers is that their host will now be shown with their instance ID in the app
I do not really know how to express it in a general way since according to various Agent and instance configurations we might fall in very various different hostname shapes (for example for aws linux instances with the hostname Maybe adding a more detailed guide on that would more fit in docs.datadoghq.com/integrations/guide/aws-integration-troubleshooting like a section
Sure |
Thanks LGTM, with one minor edit to: Let's update to mention that "Datadog ensures that displayed hostnames will refer to instance IDs rather than other detected hostnames in Fleet Automation and on the Infrastructure list." TO "Datadog ensures that displayed hostnames will refer to instance IDs" |
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 directly committed some formatting/grammar fixes as well as Vignesh's suggestion. Approving again!
What does this PR do? What is the motivation?
Create doc for ec2_imdsv2_transition_payload_enabled (related to: DataDog/datadog-agent#33861)
Merge instructions
Merge readiness:
Merge queue is enabled in this repo. To have it automatically merged after it receives the required reviews, create the PR (from a branch that follows the
<yourname>/description
naming convention) and then add the following PR comment:Additional notes