Jenkins Bazel Build failed for commit cff9b1c41a9062b2f7265cc20c224d1a7d8d119b. Full PR test history.

The magic incantation to run this job again is @k8s-bot bazel test this. Please help us cut down flakes by linking to an open flake issue when you hit one in your PR.

Serialization is tested by pkg/api/serialization_test.go - double check that you aren't using a custom fuzzer that hardcodes network-peers / network-ports (fuzzer automatically tests nil, empty slice, and populated slice).

Serialization is tested by pkg/api/serialization_test.go

There are no tests for specific nuances of serialization of specific types?

(fuzzer automatically tests nil, empty slice, and populated slice)

That doesn't seem to be true; pkg/api/testing/fuzzer.go:FuzzerFor() calls fuzz.New().NilChance(.5).NumElements(1, 1), so it either generates nil or a 1-element slice, never a 0-element slice.

Changing it to NumElements(0, 2) (not "1", because of google/gofuzz#20) makes it generate all three possibilities though, and the tests still pass. Although, master passes with the same change, which suggests that it's not testing what we want it to test, since we don't expect both nil and [] to round-trip correctly in NetworkPolicyIngressRule in master.

Jenkins GCE Node e2e failed for commit 89a0bccdfd144bd196aa9356c0acccdd577f8b97. Full PR test history.

The magic incantation to run this job again is @k8s-bot node e2e test this. Please help us cut down flakes by linking to an open flake issue when you hit one in your PR.

Do you have a defaulter in play? Try adding an explicit fuzzer function to
verify.

On Nov 22, 2016, at 12:57 PM, Dan Winship [email protected] wrote:

Serialization is tested by pkg/api/serialization_test.go

There are no tests for specific nuances of serialization of specific types?

(fuzzer automatically tests nil, empty slice, and populated slice)

That doesn't seem to be true; pkg/api/testing/fuzzer.go:FuzzerFor()
calls fuzz.New().NilChance(.5).NumElements(1,
1), so it either generates nil or a 1-element slice, never a 0-element
slice.

Changing it to NumElements(0, 2) (not "1", because of google/gofuzz#20
google/gofuzz#20) makes it generate all three
possibilities though, and the tests still pass. Although, master passes
with the same change, which suggests that it's not testing what we want it
to test, since we don't expect both nil and [] to round-trip correctly in
NetworkPolicyIngressRule in master.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#37289 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_pxS45i-uV-TB1c7TJHjqQyshL63yks5rAy0NgaJpZM4K5i8v
.

ok, pkg/api/serialization_test.go compares the original and serialized-and-deserialized objects using api.Semantic.DeepEqual(), which uses a forked version of reflect.DeepEqual() that considers nil and [] to be equal. So it does not test that this patch works.

I tried adding extra rules to api.Semantic to fix the comparison of NetworkPolicy values, but that creates an import loop between pkg/api and pkg/apis/extensions...

@danwinship @lavalamp ick. We could do something like this:

• if semantic.DeepEqual() finds a T.DeepEqual(T) bool method, call that instead of doing it ourselves
• define a type with this method for these fields

But that feels terrible. Better ideas?

Adding label:do-not-merge because PR changes docs prohibited to auto merge
See http://kubernetes.io/editdocs/ for information about editing docs

We could do something like this:

• if semantic.DeepEqual() finds a T.DeepEqual(T) bool method, call that instead of doing it ourselves
• define a type with this method for these fields

But that feels terrible. Better ideas?

Well, I tried that, and it is terrible. I ended up needing to replace all the existing overrides as well, because otherwise you end up with a weird mix of global and non-global overrides. (In particular, NetworkPolicyIngressRule's override of DeepEqual needs to recursively call whatever.DeepEqual on its subparts, but in order to do that it would have to have a copy of the right "whatever", but the forked DeepEqual code can't just pass it its Equalities object because that's a private unexported type. So I just made the existing overrides also work by making the types implement their own semantic DeepEqual methods as well so I could get rid of "Equalities".) Except that it doesn't work because I apparently did it wrong because reflect is weird and the code doesn't handle types with embedded types with DeepEqual overrides correctly (see commit message). Also, to do it right we probably need to override DeepDerivative separately from DeepEqual...

Anyway, mucking about with all of this just highlighted the fact that we're trying to make NetworkPolicy violate a fundamental norm of kubernetes ("nil and empty slice are the same thing in API objects") and makes me wonder if maybe we should just go back to the original plan of using a pointer-to-slice so we can be more explicit about the difference between unset and set-but-zero-length. (There is still some code generation problem with that approach, where some code [IIRC protobufs] is failing to insert a * in a place where it's needed, but that ought to be resolvable.)

OTOH, while also implementing NetworkPolicy in OpenShift in parallel with all this, I'm feeling more like maybe we should have gone with the "don't actually make any distinction between unset and set-but-zero-length [just like everyone else]" approach. The idea that a 0-length Ports or From array means to allow connections to 0 ports or from 0 namespaces is nice and consistent, but it's completely useless...

Jenkins unit/integration failed for commit bafa502. Full PR test history.

The magic incantation to run this job again is @k8s-bot unit test this. Please help us cut down flakes by linking to an open flake issue when you hit one in your PR.

Jenkins verification failed for commit bafa502. Full PR test history.

The magic incantation to run this job again is @k8s-bot verify test this. Please help us cut down flakes by linking to an open flake issue when you hit one in your PR.

Hmm. If I recall, protobuf was the holdout for pointer-to-slice, wasn't it? Or am I misremembering? Looking at the code that gets generated for pointer-to-slice, there are some obvious problems.

I'm falling into the "cut our losses" camp. We're not in a rush, I guess, but I am somewhat loathe to commit to fixing teh codegen for this very niche case that has relatively low RoI.

The idea that a 0-length Ports or From array means to allow connections to 0 ports or from 0 namespaces is nice and consistent, but it's completely useless.

FWIW, I'm also in the "cut our losses" camp.

Do you want to take a look at Clayton's suggestion - it's a little chintzy but not terrible - or should we cut our losses?

Which suggestion? "The way we fixed optional slices was..." or "just do a specific test and verify that nil and empty are the same"?

Fixing just the test case is easy, but api.Semantic.DeepEqual gets used all over the place so if we don't change how it works then it seems likely that some cache or something elsewhere in kubernetes is going to misinterpret our objects. (In the other case I'm aware of that distinguishes nil and 0-length at deserializing time [DeploymentConfigSpec.Triggers in OpenShift], it distinguishes them only at deserializing time: the defaulting func for DeploymentConfigSpec leaves a 0-length Trigger list as-is, but interprets obj.Triggers == nil as meaning "set Triggers to the default list of triggers". After defaulting happens, there is no longer a distinction between nil and empty.)

The other nice thing about dropping the alleged special behavior for 0-length list is that it just preserves the API we already have in 1.4; right now { "spec": {} } and { "spec": { "ports": [] } } both generate the same NetworkPolicy. Changing things would mean that future releases would interpret those objects differently.

@danwinship PR needs rebase

@eparis points out on IRC that our currently documented distinction between not-present vs present-but-empty matches the definition of LabelSelectors (which may be why we specified it that way?). So we could also do it in a more LabelSelector-like way, having an optional struct containing a slice, instead of an optional slice, so we'd have something like:

# all ports
spec:
  ingress:
  - {}

# some ports
spec:
  ingress:
  - allowPorts:
      ports: [80, 443]

# no ports
spec:
  ingress:
  - allowPorts:
      ports: []

# also no ports
spec:
  ingress:
  - allowPorts: {}

I am running a quick test to see what happens if semantic deepEqual stops conflating nil with []. Only a handful of unit tests fail

make sure to include #37823 in that testing

I'm not against a struct-with-slice member. At least it is not "tricky". Do you want to prototype that to see if the API is really stinky?

See danwinship@de0c4fc. Though of course this would also require changes in third-party implementations of NetworkPolicy as well. And technically I guess we're not supposed to change the v1beta1 definition but would have to add a new API version, and converters, and the like?

what do the implementations think? Is the semantic distinction worth making this change for?

As far as Calico is concerned, it would be easy to support the new semantic distinction. I'd still rather not have to support two code paths just to support a semantic change that AFAICT isn't actually useful and we haven't had anyone complain about.

My guess would be other implementors would feel similarly.

As discussed in the SIG, closing this in favor of #39164 "Move NetworkPolicy to v1"