Top level attribute definition in a devfile

[elsony]

The existing devfile does not have a way to define global attributes. If there are some values that I wanted to reuse in different sections of the devfile, I need to repeat those values in various places within a devfile.

Sample use case:
I wanted to create a couple of maven stacks and all of them have pretty much the same content except that the commands/images will make use of a different version of java. If I can define global attributes in a devfile, I can use the attribute key in places where I need to reference the java version, e.g. image path, commands, etc. Then, I can just have a single parent for those maven stacks and each child devfile of them just override the java version attribute in the devfile to provide the specific java version behaviour in different stacks.

Proposal:

1. Define attributes as a map of implementation-dependent free-form YAML attributes on the top level in a devfile.
2. Use {{attribute-name}} to refer to the attribute with the key attribute-name
3. To the implementation simple and avoiding to the need introducing hierarchy path on attribute reference, only attributes on the top level can be resolved within a devfile. Attributes defined on other levels, e.g. attributes defined under a command, cannot be resolved.

Example:
This example defines a global attribute java version number on the top level and references the value of the variable in the container image field.

schemaVersion: 2.0.0
metadata:
  name: java-maven
  version: 1.1.1
attributes:
  javaVersion: 11
components:
  - name: tools
    container:
      image: quay.io/eclipse/che-java{{javaVersion}}-maven:nightly
...

Note: Using this mechanism, we can also address the requirement #149 where each container can refer to the global attribute value and add the required environment variables in the container definition.

[elsony]

The logic on replacement of the attributes needs to be part of the API implementation.

[scottkurz]

Since a child and a parent could each define a given attribute with a different value, it seems like we'd have to define the order of global attribute substitution vs. child/parent merge. It seems like we might need to do the global attribute substitution in the child first if we need to use the value in order to reference the parent. At that point, when we merge in the parent, we'd need to merge the global attributes of the child + parent (child overriding) to resolve substitutions in content coming from the parent.

[elsony]

The attribute should have the same overriding rule as the rest of the other elements:

1. If a child is declaring an overriding global attribute, i.e. under the parent element, the attribute value will be resolved as the overriding value from the child.
2. If a child tries to define a new global attribute outside of the parent element but the parent devfile also has the same attribute, it will result in a validation error.

If we stick to these generic overriding rules, then we can just merge the parent and child first and then do the attribute substitution on the merged model.

[rkratky]

JIRA: https://issues.redhat.com/browse/RHDEVDOCS-2668

[elsony]

For the record, here is a summary of what we are going to do for the top-level free form attributes, global string variables, and the existing attributes in the metadata: #352 (comment)

[maysunfaisal]

@elsony I think we should rename the issue title, since this logic is for variables. And open one more for top level attributes for a historical perspective?