Systems with conflicting mutators may not converge

[maxsmythe]

If a system has conflicting mutators (i.e. they disagree as to the schema of the resource they're mutating), currently the first mutator to be ingested is recognized and the second is ignored.

In an eventually consistent system with mutiple pods, this is broken and will not converge. If mutators A and B are in conflict and pod 1 recognizes mutator A, while pod 2 recognizes mutator B, the system will not be idempotent... it's answer may change depending on which pod processes the request.

The solution is to disallow all conflicting mutators. Such a rule would lead to convergence regardless of order.

[willbeason]

I can take this

[willbeason]

An example of mutators with conflicting schemas would be:

spec.containers[name: "foo"].bar = "hello"
spec.containers.foo.bar = "hello"

The first assumes spec.containers is a list, and the second assumes spec.containers is an object.

The following class of conflict is considered out of scope for this issue (it is left to the user to prevent this):

spec.containers.azure.bar = "hi"
spec.containers.azure.bar = "hello"

[maxsmythe]

This issue isn't yet closed... #1364 sets the stage for fixing the issue, but we still:

• Accept the first conflicting mutators and reject subsequent ones:

gatekeeper/pkg/mutation/system.go

Lines 53 to 56 in a88df07

	err := s.schemaDB.Upsert(withSchema)
	if err != nil {
	s.schemaDB.Remove(withSchema.ID())
	return errors.Wrapf(err, "Schema upsert caused conflict for %v", m.ID())

• Have no way of reporting conflicting mutators, or that those conflicts have resolved

IIRC those issues were going to be addressed in a follow-on PR