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

Fix relabeling rules #3146

Merged
merged 1 commit into from
Mar 20, 2020

Conversation

danielBelenky
Copy link

@danielBelenky danielBelenky commented Mar 12, 2020

The labeldrop action requires only regex matcher to be set.

Signed-off-by: Daniel Belenky dbelenky@redhat.com

Fix ServiceMonitor relabel rules

@kubevirt-bot kubevirt-bot added dco-signoff: yes Indicates the PR's author has DCO signed all their commits. do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. size/XS labels Mar 12, 2020
The `labeldrop` action requires only `regex` matcher to be set.

Also, added a test case to ensure that our metrics are not being
relabeled.

Signed-off-by: Daniel Belenky <dbelenky@redhat.com>
Copy link
Contributor

@dhiller dhiller 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, just one question regarding token extraction.


// We need a token from a service account that can view all namespaces in the cluster
By("extracting virt-operator sa token")
token, _, err := tests.ExecuteCommandOnPodV2(virtClient,
Copy link
Contributor

Choose a reason for hiding this comment

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

This looks very sneaky. Isn't there another solution? I.e. can't we just create a test token or something?

Copy link
Author

Choose a reason for hiding this comment

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

we can, but it complicates things.. it will require to create a service account just for the test, extract it's token and then tear it down after the test if over... at first, I implemented it that way but then I thought that it will be better to just reuse the operator service account just like we're using the handler pod to query to metrics.

Copy link
Member

@davidvossel davidvossel left a comment

Choose a reason for hiding this comment

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

interesting. So without this, would the virt-handler namespace be reported on VMI metrics?

"-k",
fmt.Sprintf("https://%s:%d/api/v1/query", promIP, promPort),
"-H",
fmt.Sprintf("Authorization: Bearer %s", token),
Copy link
Member

Choose a reason for hiding this comment

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

you don't actually have to extract the bearer token from the pod do you? Because the right token is already in the pod you're executing this command within.

What would happen if you replaced this line with something line the following instead?

"Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"

Copy link
Author

Choose a reason for hiding this comment

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

It is not that straight forward as it seems at first... I've tried this approach before and the problem is that the execution of a sub-shell does not seem to work as I expected after processed by exec.

Even if I can get it to work, I think that it will have a negative impact on the readability of this test.

@danielBelenky
Copy link
Author

interesting. So without this, would the virt-handler namespace be reported on VMI metrics?

No. virt-handler will set the correct label on the metric, but it will be overwritten during the scraping process at the target level (our service-monitor)

This PR is part of the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1805044

Copy link
Member

@davidvossel davidvossel left a comment

Choose a reason for hiding this comment

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

/lgtm
/approve

@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Mar 18, 2020
@kubevirt-bot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: davidvossel

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

@kubevirt-bot kubevirt-bot added approved Indicates a PR has been approved by an approver from all required OWNERS files. release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. labels Mar 18, 2020
@danielBelenky
Copy link
Author

/retest

@kubevirt-bot kubevirt-bot merged commit eef3549 into kubevirt:master Mar 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. lgtm Indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants