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

feat(targets): Addition of egress and ingress worker filters #2654

Merged
merged 5 commits into from
Nov 30, 2022

Conversation

irenarindos
Copy link
Collaborator

@irenarindos irenarindos commented Nov 28, 2022

@irenarindos irenarindos changed the title initial commit feat(targets): Addition of egress and ingress worker filters Nov 28, 2022
@irenarindos irenarindos marked this pull request as ready for review November 29, 2022 14:24
Copy link
Collaborator

@talanknight talanknight left a comment

Choose a reason for hiding this comment

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

2 minor comments that I'd like to discuss, but Approved it since I already had previously and it still looks good.

Comment on lines +128 to +132
// Update the old worker filter
newWorkerFilter := "bar==foo"
result.SetWorkerFilter(newWorkerFilter)
result, _, _, _, err = testRepo.UpdateTarget(ctx, result, result.GetVersion(), []string{"WorkerFilter"})
require.Equal(t, newWorkerFilter, result.GetWorkerFilter())
Copy link
Collaborator

Choose a reason for hiding this comment

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

I like grouping these cases like this. Consider using t.Run("Update the old worker filter", func(t testing.T) {... instead of using comments so what is being tested can be surfaced in the test logs and users don't have to go code diving to see which assertions are failing.

Comment on lines +30 to +31
if new.worker_filter = old.worker_filter then
new.worker_filter = null;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think we've discussed this in the past but I just want to make sure the decision was made that we would clear the old worker_filter for the user instead of making them clear it manually.

This is potentially surprising behavior since they did not explicitly say they wanted it cleared. Alternatively if they have to explicitly clear it they would have a 2 step migration process of clearing worker_filter and then removing the clearing of the worker_filter, which may or may not be better.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We went back and forth on it but decided to clear the old filter instead of making them clear it manually, some of that discussion is in the thread here: https://hashicorp.slack.com/archives/C038L63F67L/p1667242927405219

@irenarindos irenarindos merged commit 834a2a8 into main Nov 30, 2022
@irenarindos irenarindos deleted the irindos-worker-filters branch November 30, 2022 20:23
@@ -64,7 +64,7 @@ func TestTargets(t *testing.T) {
},
SessionMaxSeconds: &wrapperspb.UInt32Value{Value: 0},
SessionConnectionLimit: &wrapperspb.Int32Value{Value: 0},
WorkerFilter: &wrapperspb.StringValue{Value: "worker-filter"},
EgressWorkerFilter: &wrapperspb.StringValue{Value: "egress-worker-filter"},
Copy link
Member

Choose a reason for hiding this comment

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

Do we actually want to remove WorkerFilter? Aren't we still returning that for a while?

@irenarindos irenarindos added this to the 0.12.x milestone Jan 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants