Skip to content

Improve job hostname detection on Windows#448

Merged
nikita-tkachenko-datadog merged 3 commits into
masterfrom
nikita-tkachenko/improve-hostname-detection-windows
Sep 20, 2024
Merged

Improve job hostname detection on Windows#448
nikita-tkachenko-datadog merged 3 commits into
masterfrom
nikita-tkachenko/improve-hostname-detection-windows

Conversation

@nikita-tkachenko-datadog

Copy link
Copy Markdown
Collaborator

Requirements for Contributing to this repository

  • Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
  • The pull request must only fix one issue at the time.
  • The pull request must update the test suite to demonstrate the changed functionality.
  • After you create the pull request, all status checks must be pass before a maintainer reviews your contribution. For more details, please see CONTRIBUTING.

What does this PR do?

Improves job hostname detection logic:

  • environment variables associated with the job's Computer are examined to see if manually set hostname is provided
  • hostname shell command is executed remotely (now for Windows machines too, as Windows shell support this command)

Description of the Change

Alternate Designs

Possible Drawbacks

Verification Process

Additional Notes

Release Notes

Review checklist (to be filled by reviewers)

  • Feature or bug fix MUST have appropriate tests (unit, integration, etc...)
  • PR title must be written as a CHANGELOG entry (see why)
  • Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
  • PR must have one changelog/ label attached. If applicable it should have the backward-incompatible label attached.
  • PR should not have do-not-merge/ label attached.
  • If Applicable, issue must have kind/ and severity/ labels attached at least.

@nikita-tkachenko-datadog nikita-tkachenko-datadog added the changelog/Fixed Fixed features results into a bug fix version bump label Sep 16, 2024
@nikita-tkachenko-datadog
nikita-tkachenko-datadog marked this pull request as ready for review September 18, 2024 09:12

@drodriguezhdez drodriguezhdez left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dropped some comments

return hostname;
if (computer != null) {
try {
EnvVars computerEnvironment = computer.getEnvironment();

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the difference between EnvVars coming as the method parameter and the EnvVars coming from the Computer object? Are those not the same?

Also, how do we know the "computer" envvars have prevalence over "global?" envvars?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ones coming from the computer are relevant for that specific node (could be either the controller or a worker node). The ones coming as method parameter are the ones associated with the job. Debugging shows they're different.

Comment on lines +730 to +734
String envVarsHostname = getNodeHostname(envVars);
if (isValidHostname(envVarsHostname)) {
return envVarsHostname;
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems we're duplicating this piece of logic with computer EnvVars and other EnvVars.

Have we considered the following approach to avoid this duplicated code?

EnvVars finalEnvVars = computer != null ? compute.getEnvironment() : envVars
...
String envVarsHostname = getNodeHostname(envVars);
if (isValidHostname(envVarsHostname)) {
     return envVarsHostname;
}

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to examine both, as I couldn't find a clear definition of what the "job-level" vars are: I suspect they might include whatever's being set in the Job config UI or in the pipeline DSL. The computer-level ones, however, include variables set externally on the worker node that executes the job.

if (isUnix(rootPath)) {
command = new String[]{"hostname", "-f"};
} else {
command = new String[]{"hostname"};

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this command work in all Windows environments? If not, what would happen in that case? Would it throw an exception?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about every possible version, but it does seem to be a standard command. If it doesn't work an exception will be thrown, then caught in this method and logged. null hostname will be returned. Given that this is the last possible fallback, seems like an acceptable outcome

@nikita-tkachenko-datadog
nikita-tkachenko-datadog merged commit e531de4 into master Sep 20, 2024
@nikita-tkachenko-datadog
nikita-tkachenko-datadog deleted the nikita-tkachenko/improve-hostname-detection-windows branch September 20, 2024 09:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

changelog/Fixed Fixed features results into a bug fix version bump

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants