Overriding rules for parents and plugins

[davidfestal]

Main concept

We need to formalize and clearly define the mechanism and rules used when overriding parts of the content of the parent devfile, or parts of the content of a plugin component.

The main idea is to use kustomize-like syntax, and so use strategic merge patch mechanism, as described in this document: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md#background

That mainly means that overrides are just fragments using the same syntax as the elements to override.
Overriding rules are easy for simple object fields: A simple field that didn't exist will be added, and a simple field that already existed will be replaced with the value of the new one.

This become less straightforward for lists. Here strategic merge patch allows defining a merge strategy on lists, that will drive the way lists are overridden, as mentioned by the already-mentioned document:

To solve this problem, Strategic Merge Patch uses the go struct tag of the API objects to determine what lists should be merged and which ones should not.

To summarize the overriding behavior for list mainly depends on the patchStrategy and the patchMergeKey json tags on the corresponding GO structures.

In the devfile case, most of the lists, such as container env variables, would be managed with a merge patchStrategyand lists would be merged based on a defined key (patchMergeKey would be name in the case of environment variables).

Actions to be done

• We should be add the appropriate patchMerge json tags on all the lists in the Go sources of the model.
• We should implement a common logic to implement the overriding, available for at least all GO-based tools that will manage devfiles.