chore: clarify mutate exisitng vs standard mutate policy

[realshuting]

This PR clarifies stand mutate policy VS mutate existing policy. This is from Kyveno Slack:

but how exactly is this different from a standard mutate policy?

[chipzoller]

This is already present in the same doc in the next paragraph:

To define such a policy, trigger resources need to be specified in the match block. The target resources–resources targeted for mutation–are specified in each mutate rule under mutate.targets.

[realshuting]

This is already present in the same doc in the next paragraph:

To define such a policy, trigger resources need to be specified in the match block. The target resources–resources targeted for mutation–are specified in each mutate rule under mutate.targets.

Yes, but I want to distinguish between a mutate existing policy and a standard mutate policy. The current doc doesn't seem to define what is a standard mutate policy. Could you help suggest?

[JimBugwadia]

Yes, I was not clear on the difference as well. It will be good to state explicitly early in the text, when we introduce the concept.

[chipzoller]

The docs for this section state, in the following order:

1. the concept of mutate existing
2. how they function
3. how to author them

If you feel this isn't clear, it should go in the third section which is the paragraph under the "two important implications". Maybe something like:

To define such a policy, trigger resources need to be specified in the match block. The target resources–resources targeted for mutation–are specified in each mutate rule under mutate.targets. Mutate existing rules differ from standard mutate rules when these targets are defined. Note that all target resources within a single rule must share the same definition schema. For example, a mutate existing rule fails if this rule mutates both Pod and Deployment as they do not share the same OpenAPI V3 schema (except metadata).

[realshuting]

The docs for this section state, in the following order:

1. the concept of mutate existing
2. how they function
3. how to author them

If you feel this isn't clear, it should go in the third section which is the paragraph under the "two important implications". Maybe something like:

To define such a policy, trigger resources need to be specified in the match block. The target resources–resources targeted for mutation–are specified in each mutate rule under mutate.targets. Mutate existing rules differ from standard mutate rules when these targets are defined. Note that all target resources within a single rule must share the same definition schema. For example, a mutate existing rule fails if this rule mutates both Pod and Deployment as they do not share the same OpenAPI V3 schema (except metadata).

Updated, please take a look, thanks!