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: affinity label selector overriden by namespace selector #1609

Merged
merged 1 commit into from
Apr 3, 2024

Conversation

rohantmp
Copy link
Contributor

  • chore: go mod tidy && go mod vendor
  • fix: affinity label selector overriden by namespace selector

What issue type does this pull request address? (keep at least one, remove the others)
/kind bugfix

What does this pull request do? Which issues does it resolve? (use resolves #<issue_number> if possible)
part-of ENG-2759
fixes #1484

Please provide a short message that should be published in the vcluster release notes
Fixed an issue where vcluster mistranslated affinity terms.

What else do we need to know?

Copy link

netlify bot commented Mar 19, 2024

Deploy Preview for vcluster-docs canceled.

Built without sensitive environment variables

Name Link
🔨 Latest commit 4104a9c
🔍 Latest deploy log https://app.netlify.com/sites/vcluster-docs/deploys/660d1bc12a544c00085804ff

@rohantmp
Copy link
Contributor Author

Will rebase on master, the base is currently 19 (should be fine, but will test rebased on master)

@rohantmp rohantmp marked this pull request as draft March 19, 2024 08:17
@rohantmp rohantmp marked this pull request as ready for review March 19, 2024 09:30
@rohantmp rohantmp requested a review from facchettos April 1, 2024 05:44
@FabianKramm
Copy link
Member

Hey @rohantmp! Can you explain how this solves the problem?

@rohantmp
Copy link
Contributor Author

rohantmp commented Apr 2, 2024

Since we translate into a single namespace, the namespace selector was being translated into a labelselector based on the vcluster namespace labels, so it would override any translated labelselectors. Now this merges the translated label selector and the translated namespace selector into labelselectors

@rohantmp rohantmp closed this Apr 2, 2024
@rohantmp rohantmp reopened this Apr 2, 2024
@rohantmp
Copy link
Contributor Author

rohantmp commented Apr 2, 2024

verified the behavior locally too

Comment on lines 143 to 154
isFocused := false
for _, testCase := range testCases {
if testCase.focus {
isFocused = true
break
}
}

for _, testCase := range testCases {
if isFocused && !testCase.focus {
continue
}
Copy link
Contributor

Choose a reason for hiding this comment

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

what is this for? selecting only a subset of tests to be run when developing?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yup, it fails at the end if any tests are focused.

Copy link
Contributor

Choose a reason for hiding this comment

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

not sure I am a fan of this :D what's wrong with go test -v or something similar?
I think the issue here is that it's not using table driven test properly, because you'd have a proper breakdown of what tests failed with something like this

func Test(t *testing.T) {
	testCases := []struct {
		desc	string
		
	}{
		{
			desc: "",
			
		},
	}
	for _, tC := range testCases {
		t.Run(tC.desc, func(t *testing.T) {
			
		})
	}
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So the use-case here was comparing the behaviors of each testcase with the new/old functionality alternatingly commented out. Also useful for using the debugger to step through specific tests. The current behavior does already does make it clear which case failed. While I agree t.Run is more canonical, I don't think it replaces this functionality. I mean now that I'm done fiddling with it, this code doesn't do anything till the next person has to fiddle with the tests. Also, sometimes you can't get to the test case you're trying to game out until you make the previous ones pass. It's not critical, but it makes the tests much more useful to me :)

Copy link
Contributor

Choose a reason for hiding this comment

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

what do you mean? Also, sometimes you can't get to the test case you're trying to game out until you make the previous ones pass
You can absolutely do that with t.Run

this code doesn't do anything till the next person has to fiddle with the tests so it's essentially dead code no? And you can also use go test -v -run Test/subtest (with $ if you have subtest, subtest_something, etc so it only runs a complete match)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ahh, right. Didn't know you could use -run Test/subtest removing :)

@@ -150,13 +173,17 @@ func TestPodAffinityTermsTranslation(t *testing.T) {

assert.Assert(t, cmp.DeepEqual(events, testCase.expectedEvents), "Unexpected Event in the '%s' test case", testCase.name)
}

assert.Assert(t, !isFocused, "test should not be focused, but if you've hit this, focused tests pass!")
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Signed-off-by: Rohan CJ <rohantmp@gmail.com>
@FabianKramm FabianKramm merged commit f1df002 into loft-sh:main Apr 3, 2024
71 checks passed
@rohantmp rohantmp deleted the fixAntiAffinitySelector branch April 3, 2024 09:47
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.

anti affinity missing on synced pod if namespace selector matches all namespaces
3 participants