Skip to content

Conversation

@farshad68
Copy link
Contributor

No description provided.

@farshad68 farshad68 requested a review from MichaelRoeder March 18, 2025 12:43
@codacy-production
Copy link

codacy-production bot commented Mar 18, 2025

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation Diff coverage
-0.11% (target: -1.00%) 45.83%
Coverage variation details
Coverable lines Covered lines Coverage
Common ancestor commit (204b80f) 2780 1607 57.81%
Head commit (5d772a4) 2804 (+24) 1618 (+11) 57.70% (-0.11%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details
Coverable lines Covered lines Diff coverage
Pull request (#71) 24 11 45.83%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more

Copy link
Contributor

@MichaelRoeder MichaelRoeder left a comment

Choose a reason for hiding this comment

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

The class looks good but I would suggest to have a more "neutral" usage of terms, i.e., we are not looking for pod names and this is a class that should not only work with kubernetes 😉

} catch (UnknownHostException e) {
// Handle the exception, e.g., log an error or return a default value.
LOGGER.error("Error getting pod IP: " + e.getMessage());
return "unknown"; // Or throw a RuntimeException, etc.
Copy link
Contributor

Choose a reason for hiding this comment

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

Does it make sense to not fail and continue the experiment in this case? While some containers might not need themselves to be addressable, we currently don't have a way to tell this in advance.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

you are right, in this case, it is better to fail (now it will throw an exception in getDnsFriendlyIP ), but anyway the unknown is not reachable and the module will fail in the next step.

Copy link
Contributor

Choose a reason for hiding this comment

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

Do we really need "unknown", here? Wouldn't returning null make more sense? This would also fit very well to the if statement in the other method, that checks for null anyway...

@farshad68
Copy link
Contributor Author

The class looks good but I would suggest to have a more "neutral" usage of terms, i.e., we are not looking for pod names and this is a class that should not only work with kubernetes 😉

I see that this is a Kubernetes-specific helper, similar to how the Docker version exists in the core. Given that, I’m not sure I fully understand your point about making it work beyond Kubernetes. Right now, the client (any module using this) needs to determine whether it's running in a Kubernetes environment. If it is, it would use this helper to get the host.

Do you have a different approach in mind?

@MichaelRoeder
Copy link
Contributor

That is a good question 🙂

From my perspective, we have a program and it simply wants to get the address at which it can be reached. It calls this helper class and the class will give it the information it needs. Note the following implications:

  1. The program that calls this helper class doesn't care in which environment it is running. It just wants to have the name of the node in the network. So the program shouldn't have to ask itself "Am I running on Kubernetes?".
  2. This helper class should take care of it and try to detect based on the environment whether it is running in Kubernetes. Then, it should derive the String, etc.

I even would raise the question whether the "namespace" string is really necessary... shouldn't this be something that the helper class can derive, somehow?

- Introduced dnsHelper to be used by modules.

- Ensures backward compatibility.

- No changes made to the DockerHelper class.
Copy link
Contributor

@MichaelRoeder MichaelRoeder left a comment

Choose a reason for hiding this comment

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

LGTM

} catch (UnknownHostException e) {
// Handle the exception, e.g., log an error or return a default value.
LOGGER.error("Error getting pod IP: " + e.getMessage());
return "unknown"; // Or throw a RuntimeException, etc.
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we really need "unknown", here? Wouldn't returning null make more sense? This would also fit very well to the if statement in the other method, that checks for null anyway...

@farshad68 farshad68 merged commit e23bdae into master Mar 25, 2025
5 of 6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants