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.

Sign up for GitHub

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

Jump to bottom

Replace use of whitelist with allow/allow list #1132

Merged
merged 1 commit into from
Jun 24, 2020
Merged

Replace use of whitelist with allow/allow list #1132

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions cmd/sonobuoy/app/run.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -80,13 +80,13 @@ func (r *runFlags) Config() (*client.RunConfig, error) {
return runcfg, nil
}

func givenAnyGenConfigFlags(gf *genFlags, whitelistFlagNames []string) bool {
func givenAnyGenConfigFlags(gf *genFlags, allowedFlagNames []string) bool {
changed := false
gf.genflags.Visit(func(f *pflag.Flag) {
if changed {
return
}
if f.Changed && !stringInList(whitelistFlagNames, f.Name) {
if f.Changed && !stringInList(allowedFlagNames, f.Name) {
changed = true
}
})
Expand Down
42 changes: 21 additions & 21 deletions cmd/sonobuoy/app/run_test.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,36 +31,36 @@ func TestGivenAnyGenConfigFlags(t *testing.T) {
}

testCases := []struct {
desc string
inFlags *genFlags
whitelist []string
expect bool
desc string
inFlags *genFlags
allowedFlags []string
expect bool
}{
{
desc: "Nothing changed return true",
inFlags: getSampleFlagsWithChanged(nil),
whitelist: []string{},
expect: false,
desc: "Nothing changed return true",
inFlags: getSampleFlagsWithChanged(nil),
allowedFlags: []string{},
expect: false,
}, {
desc: "One changed flag return true",
inFlags: getSampleFlagsWithChanged([]string{"kubeconfig"}),
whitelist: []string{},
expect: true,
desc: "One changed flag return true",
inFlags: getSampleFlagsWithChanged([]string{"kubeconfig"}),
allowedFlags: []string{},
expect: true,
}, {
desc: "One changed flag return false if in whitelist",
inFlags: getSampleFlagsWithChanged([]string{"kubeconfig"}),
whitelist: []string{"kubeconfig"},
expect: false,
desc: "One changed flag return false if in allowed list",
inFlags: getSampleFlagsWithChanged([]string{"kubeconfig"}),
allowedFlags: []string{"kubeconfig"},
expect: false,
}, {
desc: "One changed flag return true if not in whitelist",
inFlags: getSampleFlagsWithChanged([]string{"e2e-focus"}),
whitelist: []string{"flaga", "flagb", "flagc"},
expect: true,
desc: "One changed flag return true if not in allowed list",
inFlags: getSampleFlagsWithChanged([]string{"e2e-focus"}),
allowedFlags: []string{"flaga", "flagb", "flagc"},
expect: true,
},
}
for _, tc := range testCases {
t.Run(tc.desc, func(t *testing.T) {
out := givenAnyGenConfigFlags(tc.inFlags, tc.whitelist)
out := givenAnyGenConfigFlags(tc.inFlags, tc.allowedFlags)
if out != tc.expect {
t.Errorf("Expected %v but got %v", tc.expect, out)
}
Expand Down
4 changes: 2 additions & 2 deletions site/docs/master/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,9 +90,9 @@ One of the checks that it runs, is checking that all of the nodes are schedulabl
This check deems any nodes with a taint other than the master node taint (`node-role.kubernetes.io/master`) to be unschedulable.
This means that any node with a different taint will not be considered ready for testing and will block the tests from starting.

With the release of Kubernetes v1.17.0, you will be able to whitelist node taints so that any node with a whitelisted taint will be deemed schedulable as part of the pre-test checks.
With the release of Kubernetes v1.17.0, you will be able to provide a list of allowed node taints so that any node with an allowed taint will be deemed schedulable as part of the pre-test checks.
This will ensure that these nodes will not block the tests from starting.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to whitelist using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to allow using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
To find out how to set this flag via Sonobuoy, please refer to our previous answer on how to set test framework options.

This solution does not enable workloads created by the tests to run on these nodes.
Expand Down
4 changes: 2 additions & 2 deletions site/docs/v0.16.5/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,9 +90,9 @@ One of the checks that it runs, is checking that all of the nodes are schedulabl
This check deems any nodes with a taint other than the master node taint (`node-role.kubernetes.io/master`) to be unschedulable.
This means that any node with a different taint will not be considered ready for testing and will block the tests from starting.

With the release of Kubernetes v1.17.0, you will be able to whitelist node taints so that any node with a whitelisted taint will be deemed schedulable as part of the pre-test checks.
With the release of Kubernetes v1.17.0, you will be able to provide a list of allowed node taints so that any node with an allowed taint will be deemed schedulable as part of the pre-test checks.
This will ensure that these nodes will not block the tests from starting.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to whitelist using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to allow using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
To find out how to set this flag via Sonobuoy, please refer to our previous answer on how to set test framework options.

This solution does not enable workloads created by the tests to run on these nodes.
Expand Down
4 changes: 2 additions & 2 deletions site/docs/v0.17.0/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,9 +90,9 @@ One of the checks that it runs, is checking that all of the nodes are schedulabl
This check deems any nodes with a taint other than the master node taint (`node-role.kubernetes.io/master`) to be unschedulable.
This means that any node with a different taint will not be considered ready for testing and will block the tests from starting.

With the release of Kubernetes v1.17.0, you will be able to whitelist node taints so that any node with a whitelisted taint will be deemed schedulable as part of the pre-test checks.
With the release of Kubernetes v1.17.0, you will be able to provide a list of allowed node taints so that any node with an allowed taint will be deemed schedulable as part of the pre-test checks.
This will ensure that these nodes will not block the tests from starting.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to whitelist using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to allow using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
To find out how to set this flag via Sonobuoy, please refer to our previous answer on how to set test framework options.

This solution does not enable workloads created by the tests to run on these nodes.
Expand Down
4 changes: 2 additions & 2 deletions site/docs/v0.17.1/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,9 +90,9 @@ One of the checks that it runs, is checking that all of the nodes are schedulabl
This check deems any nodes with a taint other than the master node taint (`node-role.kubernetes.io/master`) to be unschedulable.
This means that any node with a different taint will not be considered ready for testing and will block the tests from starting.

With the release of Kubernetes v1.17.0, you will be able to whitelist node taints so that any node with a whitelisted taint will be deemed schedulable as part of the pre-test checks.
With the release of Kubernetes v1.17.0, you will be able to provide a list of allowed node taints so that any node with an allowed taint will be deemed schedulable as part of the pre-test checks.
This will ensure that these nodes will not block the tests from starting.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to whitelist using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to allow using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
To find out how to set this flag via Sonobuoy, please refer to our previous answer on how to set test framework options.

This solution does not enable workloads created by the tests to run on these nodes.
Expand Down
4 changes: 2 additions & 2 deletions site/docs/v0.17.2/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,9 +90,9 @@ One of the checks that it runs, is checking that all of the nodes are schedulabl
This check deems any nodes with a taint other than the master node taint (`node-role.kubernetes.io/master`) to be unschedulable.
This means that any node with a different taint will not be considered ready for testing and will block the tests from starting.

With the release of Kubernetes v1.17.0, you will be able to whitelist node taints so that any node with a whitelisted taint will be deemed schedulable as part of the pre-test checks.
With the release of Kubernetes v1.17.0, you will be able to provide a list of allowed node taints so that any node with an allowed taint will be deemed schedulable as part of the pre-test checks.
This will ensure that these nodes will not block the tests from starting.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to whitelist using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to allow using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
To find out how to set this flag via Sonobuoy, please refer to our previous answer on how to set test framework options.

This solution does not enable workloads created by the tests to run on these nodes.
Expand Down
4 changes: 2 additions & 2 deletions site/docs/v0.18.0/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,9 +90,9 @@ One of the checks that it runs, is checking that all of the nodes are schedulabl
This check deems any nodes with a taint other than the master node taint (`node-role.kubernetes.io/master`) to be unschedulable.
This means that any node with a different taint will not be considered ready for testing and will block the tests from starting.

With the release of Kubernetes v1.17.0, you will be able to whitelist node taints so that any node with a whitelisted taint will be deemed schedulable as part of the pre-test checks.
With the release of Kubernetes v1.17.0, you will be able to provide a list of allowed node taints so that any node with an allowed taint will be deemed schedulable as part of the pre-test checks.
This will ensure that these nodes will not block the tests from starting.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to whitelist using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to allow using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
To find out how to set this flag via Sonobuoy, please refer to our previous answer on how to set test framework options.

This solution does not enable workloads created by the tests to run on these nodes.
Expand Down
4 changes: 2 additions & 2 deletions site/docs/v0.18.1/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,9 +90,9 @@ One of the checks that it runs, is checking that all of the nodes are schedulabl
This check deems any nodes with a taint other than the master node taint (`node-role.kubernetes.io/master`) to be unschedulable.
This means that any node with a different taint will not be considered ready for testing and will block the tests from starting.

With the release of Kubernetes v1.17.0, you will be able to whitelist node taints so that any node with a whitelisted taint will be deemed schedulable as part of the pre-test checks.
With the release of Kubernetes v1.17.0, you will be able to provide a list of allowed node taints so that any node with an allowed taint will be deemed schedulable as part of the pre-test checks.
This will ensure that these nodes will not block the tests from starting.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to whitelist using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to allow using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
To find out how to set this flag via Sonobuoy, please refer to our previous answer on how to set test framework options.

This solution does not enable workloads created by the tests to run on these nodes.
Expand Down
4 changes: 2 additions & 2 deletions site/docs/v0.18.2/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,9 +90,9 @@ One of the checks that it runs, is checking that all of the nodes are schedulabl
This check deems any nodes with a taint other than the master node taint (`node-role.kubernetes.io/master`) to be unschedulable.
This means that any node with a different taint will not be considered ready for testing and will block the tests from starting.

With the release of Kubernetes v1.17.0, you will be able to whitelist node taints so that any node with a whitelisted taint will be deemed schedulable as part of the pre-test checks.
With the release of Kubernetes v1.17.0, you will be able to provide a list of allowed node taints so that any node with an allowed taint will be deemed schedulable as part of the pre-test checks.
This will ensure that these nodes will not block the tests from starting.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to whitelist using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to allow using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
To find out how to set this flag via Sonobuoy, please refer to our previous answer on how to set test framework options.

This solution does not enable workloads created by the tests to run on these nodes.
Expand Down
4 changes: 2 additions & 2 deletions site/docs/v0.18.3/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,9 +90,9 @@ One of the checks that it runs, is checking that all of the nodes are schedulabl
This check deems any nodes with a taint other than the master node taint (`node-role.kubernetes.io/master`) to be unschedulable.
This means that any node with a different taint will not be considered ready for testing and will block the tests from starting.

With the release of Kubernetes v1.17.0, you will be able to whitelist node taints so that any node with a whitelisted taint will be deemed schedulable as part of the pre-test checks.
With the release of Kubernetes v1.17.0, you will be able to provide a list of allowed node taints so that any node with an allowed taint will be deemed schedulable as part of the pre-test checks.
This will ensure that these nodes will not block the tests from starting.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to whitelist using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
If you are running Kubernetes v1.17.0 or greater, you will be able to specify the taints to allow using the flag `--non-blocking-taints` which takes a comma-separated list of taints.
To find out how to set this flag via Sonobuoy, please refer to our previous answer on how to set test framework options.

This solution does not enable workloads created by the tests to run on these nodes.
Expand Down