Flip inheritance to allow yaml to override parent

[Vlatombe]

The current inheritance is counter intuitive (as indicated in the test I changed). I think the yaml fragment should always override the parent definition.

cc @carlossg wdyt?

[jglick]

cascadingDelete timeout, probably unrelated?

[jglick]

Do not understand the implications well enough to review.

[carlossg]

It makes sense, but is the parent yaml merged with the child yaml?
otherwise parent yaml would override children UI config

[Vlatombe]

Fair point, I guess it could happen if parent defines yaml but children doesn't. But I believe the current 'yaml merge strategy' already provides enough control as one could easily provide a bogus yaml kind: Pod using override strategy.

The scenario where I encounter problems with the current implementation is Defaults Provider Template Name points to a pod template that defines a jnlp image, and this prevents a pod template defined by yaml (with podTemplate step) to use another jnlp image.

[jglick]

Breaks cascadingDelete, not yet sure why. Somehow combine does not work correctly on serviceAccountName.

[jglick]

A flake in the last build, to be diagnosed by jenkinsci/jenkins#4226.

[kerogers-cloudbees]

I think this would resolve the issue found trying to run a windows container which was having its image replaced by the default jnlp alpine image.

[jglick]

combine does not work correctly on serviceAccountName

Because the combination logic currently pays attention only to the deprecated serviceAccount. We need to map these to serviceAccountName automatically, or something like that.

[Vlatombe]

I don't think this can be merged because of backward compatibility concerns.

[jglick]

Agreed. We could deprecate the current inheritance attributes and introduce replacements that work more naturally; or just discourage users from relying on this feature, using libraries or whatever else to prepare YAML and pass it as a complete literal.