Restore unique_host_name logic for AppDynamics#884
Merged
dmikusa merged 1 commit intocloudfoundry:mainfrom Jun 11, 2021
mmessmore:main
Merged
Restore unique_host_name logic for AppDynamics#884dmikusa merged 1 commit intocloudfoundry:mainfrom mmessmore:main
dmikusa merged 1 commit intocloudfoundry:mainfrom
mmessmore:main
Conversation
PR #870 reversed the logic overriding the default_unique_host_name with the application_name. This results in problems with AppDynamics where applications running on multiple foundations are unable to add metrics when using the same application name in Cloud Foundry. Really, application_name should never be used. unique_host_name is by definition a unique identifier vs an application_name, which is not guaranteed to be unique. But this restores the previous logic, which was functional and may have handled cases I am not aware of.
|
|
mmessmore
changed the title
Contributor
|
Good catch & thanks for the PR. It was not the intent of #870 to change that behavior. If |
Contributor
Author
|
No worries. Just noticed and wanted to help fix vs complain. Thanks! |
ramonskie
pushed a commit
that referenced
this pull request
Dec 4, 2025
PR #870 reversed the logic overriding the default_unique_host_name with the application_name. This results in problems with AppDynamics where applications running on multiple foundations are unable to add metrics when using the same application name in Cloud Foundry. Really, application_name should never be used. unique_host_name is by definition a unique identifier vs an application_name, which is not guaranteed to be unique. But this restores the previous logic, which was functional and may have handled cases I am not aware of.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
PR #870 reversed the logic overriding the default_unique_host_name with
the application_name. This results in problems with AppDynamics where
applications running on multiple foundations are unable to add metrics
when using the same application name in Cloud Foundry.
Really, application_name should never be used. unique_host_name is
by definition a unique identifier vs an application_name, which is not
guaranteed to be unique.
But this restores the previous logic, which was functional and may have
handled cases I am not aware of.