-
Notifications
You must be signed in to change notification settings - Fork 1
DiscoveryClient - Add awareness of Discovery Service's Cluster ID environment variable #242
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
Conversation
…ent variable (used by the Discovery Service for initializing its cluster ID) to determine whether the key file exists to indicate an already launched Discovery Service.
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.
Pull Request Overview
This PR adds support for the NIDiscovery_ClusterId environment variable to the DiscoveryClient, enabling it to properly detect and interact with Discovery Services launched with non-default cluster IDs. This enhancement is particularly valuable for testing and demonstration scenarios where multiple Discovery Services need to run independently on the same machine.
Key Changes:
- Added reading of the
NIDiscovery_ClusterIdenvironment variable in_get_discovery_service_address() - The cluster ID is now passed to
_get_key_file_path()to locate the correct key file for the specified cluster
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
What does this Pull Request accomplish?
This set of changes adds awareness of the
NIDiscovery_ClusterIdenvironment variable to the existingDiscoveryClient, allowing theDiscoveryClientto properly detect a Discovery Service that has been launched with the specified cluster ID.If this variable is set in the environment of a launched Discovery Service process, then the Discovery Service will identify itself as having a cluster ID equal to the value of the environment variable, adding a key file on disk that includes that cluster ID in its name. (Note that launching a Discovery Service with a unique cluster allows multiple Discovery Services to run and be interacted with independently on a machine, which is particularly helpful for testing and example/demonstration scenarios.)
Prior to these changes, the
DiscoveryClientwould always look for the key file on disk for the default cluster, despite the fact that if theDiscoveryClientwere to allow the Discovery Service to launch in this scenario (with the environment variable set), it would do so with a different cluster--the one specified in the environment variable that the Discovery Service itself already honors.With these changes, the
DiscoveryClientnow looks for the appropriate key file in both cases:os.environ.get("NIDiscovery_ClusterId")will returnNoneand we will look for the default key file (as we determine whether to launch a new Discovery Service process).os.environ.get("NIDiscovery_ClusterId")will return the cluster ID and we will look for the key file that pertains to that particular cluster (as we determine whether to launch a new Discovery Service process).Why should this Pull Request be merged?
This PR improves support of the
DiscoveryClientwhen used in conjunction with a Discovery Service with a non-default cluster.What testing has been done?
Exercising the modified code in both cases: when the environment variable is set and when it is not set