Skip to content
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

NETOBSERV-1203: Added option to add zones in k8s transform rule #575

Merged
merged 2 commits into from
Jan 25, 2024

Conversation

OlivierCazade
Copy link
Contributor

Description

Zones are added to the flows if the rule is configured with the new addZone bool.

Dependencies

n/a

Checklist

If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.

  • Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist.
  • Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix (in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes).
  • Does this PR require product documentation?
    • If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.
  • Does this PR require a product release notes entry?
    • If so, fill in "Release Note Text" in the JIRA.
  • Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.
    • If so, make sure it is described in the JIRA ticket.
  • QE requirements (check 1 from the list):
    • Standard QE validation, with pre-merge tests unless stated otherwise.
    • Regression tests only (e.g. refactoring with no user-facing change).
    • No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).

@openshift-ci-robot
Copy link
Collaborator

openshift-ci-robot commented Jan 24, 2024

@OlivierCazade: This pull request references NETOBSERV-1203 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set.

In response to this:

Description

Zones are added to the flows if the rule is configured with the new addZone bool.

Dependencies

n/a

Checklist

If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.

  • Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist.
  • Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix (in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes).
  • Does this PR require product documentation?
  • If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.
  • Does this PR require a product release notes entry?
  • If so, fill in "Release Note Text" in the JIRA.
  • Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.
  • If so, make sure it is described in the JIRA ticket.
  • QE requirements (check 1 from the list):
  • Standard QE validation, with pre-merge tests unless stated otherwise.
  • Regression tests only (e.g. refactoring with no user-facing change).
  • No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Copy link

codecov bot commented Jan 24, 2024

Codecov Report

Attention: 35 lines in your changes are missing coverage. Please review.

Comparison is base (40b6948) 65.80% compared to head (420fd7c) 65.54%.

Files Patch % Lines
pkg/pipeline/transform/transform_network.go 20.68% 23 Missing ⚠️
pkg/pipeline/transform/kubernetes/kubernetes.go 0.00% 12 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #575      +/-   ##
==========================================
- Coverage   65.80%   65.54%   -0.26%     
==========================================
  Files         102      102              
  Lines        7445     7483      +38     
==========================================
+ Hits         4899     4905       +6     
- Misses       2256     2288      +32     
  Partials      290      290              
Flag Coverage Δ
unittests 65.54% <14.63%> (-0.26%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@@ -148,6 +148,7 @@ func fillInK8s(outputEntry config.GenericMap, rule api.NetworkTransformRule) {
outputEntry[rule.Output+"_HostName"] = kubeInfo.HostName
}
}
fillInK8sZone(outputEntry, rule, *kubeInfo)
Copy link
Collaborator

Choose a reason for hiding this comment

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

We should also manage the open telemetry case in the else statement below this line.

  • In case of a node we can add k8s.node.zone
  • Other cases k8s.host.zone

Maybe filling the zones directly inside fetchInformers function in kubernetes.go file would actually be better ?
You can pass the rule to it and query the info accordingly.

Then in transform_network.go you conditionally fill the output as same as what's done for HostIP and HostName

WDYT ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought about adding this in fetchInformers, but this mean querying the informer for nodes for each flow even when the feature is disabled.

I prefered keeping it separated for performances reasons.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

About telemetry this is now supported with a uniq tag: k8s.zone

Copy link
Collaborator

Choose a reason for hiding this comment

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

thanks !

@@ -184,6 +185,40 @@ func fillInK8s(outputEntry config.GenericMap, rule api.NetworkTransformRule) {
}
}

const nodeZoneLabelName = "topology.kubernetes.io/zone"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Would this be configurable ? I see topology.kubernetes.io/region & topology.kubernetes.io/zone and I wonder if some clusters have only region for example 🤔

https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesioregion

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Zone and region are not exactly the same thing, generally a region has multiple zones.

In your example us-east-1 vs us-east-1c

Copy link
Collaborator

Choose a reason for hiding this comment

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

so are we sure we always have zones when we have region ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

A region represents a larger domain, made up of one or more zones.

If I understand correctly there is at least one zone for each region. And since they are not exactly the same thing it would be incorrect to tag the region instead of the zone anyway.

If needed we can add a second feature to also tag the region, but I think we should not mix both.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ok sounds legit. Thanks !

case kubernetes.TypeNode:
zone, ok := kubeInfo.Labels[nodeZoneLabelName]
if ok {
outputEntry[rule.Output+"_Zone"] = zone
Copy link
Collaborator

Choose a reason for hiding this comment

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

Since this is node related, I would suggest HostZone for consistency with HostIP & HostName

Suggested change
outputEntry[rule.Output+"_Zone"] = zone
outputEntry[rule.Output+"_HostZone"] = zone

Copy link
Contributor Author

Choose a reason for hiding this comment

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

IMO this is not host related the same way. HostIP and HostName belongs to the host, the pod doest not have this IP or name.

But the container is in the zone, we juste get the information through the node.

if nodeInfo != nil {
zone, ok := nodeInfo.Labels[nodeZoneLabelName]
if ok {
outputEntry[rule.Output+"_Zone"] = zone
Copy link
Collaborator

Choose a reason for hiding this comment

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

Same as previous comm here

Copy link
Collaborator

@jpinsonneau jpinsonneau left a comment

Choose a reason for hiding this comment

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

Looks good, thanks @OlivierCazade !

@OlivierCazade
Copy link
Contributor Author

As discussed in scrum today, this will be tested post merge.

@OlivierCazade OlivierCazade added the no-qe This PR doesn't necessitate QE approval label Jan 25, 2024
@OlivierCazade
Copy link
Contributor Author

/approve

Copy link

openshift-ci bot commented Jan 25, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: OlivierCazade

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-bot openshift-merge-bot bot merged commit 4289f5a into netobserv:main Jan 25, 2024
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved jira/valid-reference lgtm no-qe This PR doesn't necessitate QE approval
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants