docs: fix expansion yaml example

[sozercan]

Signed-off-by: Sertac Ozercan sozercan@gmail.com

What this PR does / why we need it:

Which issue(s) this PR fixes (optional, using fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when the PR gets merged):
Fixes #

Special notes for your reviewer:

[davis-haba]

@sozercan Is there a binary or plugin you use to format the YAML like this?

My IDE (Intellij) seems to have different opinions 😞

[maxsmythe]

LGTM

[maxsmythe]

+1 to davis's question, having a linter here could be good if we're trying to be opinionated

[sozercan]

@davis-haba I just used vscode's yaml formatter.
That's a good idea for markdown linter but I am not aware of any linters that do linting/formatting inside code blocks (yaml)

Looks like there is a syntax issue here too, since spec.source and spec.match.origin are not valid.

[sozercan]

@davis-haba i couldn't get this to work with Generated, any ideas?

[davis-haba]

How were you testing it, and what were you expecting to see?

I fed this manifest into gator expand, using source: "Generated", and it produced the expected Pod. Changing the Assign's source to source: "Original" caused the Assign to not be applied, as expected.

w.r.t. the mutator, if you are just looking to test Assign.match.source, then you could try directly creating a Pod (or deployment) and seeing if the side-car gets attached. I just tested this on-cluster and it worked for me (i.e. source: Generated did not add the side-car; but source: Original|All added it)

[sozercan]

I tested on a kind v1.25 cluster. I was expecting to see pod to get injected sidecar and args to be mutated.
Here's a quick recording: https://asciinema.org/a/qEoR30Hl210qL0Tw70ZiOaBwz (this is with same snippet from PR but with source: Generated)

Tested with gator expand too, works there using source: Generated.

[davis-haba]

Since the mutators have source: Generated they will not apply to the real pod that gets created on the cluster. The mutators will only apply to the ephemeral expanded pod, that is used for validating the deployment.

The assumption is the user is using mutators to simulate a controller adding the sidecar, so that their deployments can be properly validated. The controller they are simulating should add the sidecar to the real pod, not the mutators.

[sozercan]

That makes sense. I think what's confusing is we say "When expanded, the above configs will produce the following Pod:" which is not true with source: Generated since the produced Pod does not have these configs.

I'll update with source: All (changes as is in this PR) if that sounds good to you? @davis-haba

[davis-haba]

Yep, I agree that could be confusing. I think changing the example to source: All makes sense.

Thanks!

[sozercan]

same here for modifyset