YAML to Mux: syntax shortcut to naming the current node

[clebergnu]

The most common use case for the YAML to Mux files is to, of course, multiplex/multiply nodes under a node with a !mux tag.

For instance:

distro: !mux
   centos:
      name: centos
   version: !mux
      8:
         version: 8
      7:
         version:7
   cirros:
...
architecture: !mux
  arm:
    arch: arm
  x86_64:
    arch: x86_64

Which generates variants such as:

Variant run-architecture-x86_64-distro-centos-version-8-5def:    /run/distro/centos/version/8, /run/architecture/x86_64
    /run/architecture/x86_64:arch        => x86_64
    /run/distro/centos/version/8:version => 8
    /run/distro/centos:name              => centos

It means that tests using these variants are able to do:

self.params.get('arch') # returns 'x86_64'
self.params.get('version') # returns '8'
self.params.get('name') # returns 'centos'

It's easy to see that there's a repetitive and inefficient pattern when creating nodes for multiplication purposes that also need to carry a simple value to be used as a parameter. A syntax such as the following could be an usability improvement:

distro: !mux
   centos: !value
   version: !mux
      8: !value
      7: !value
   cirros: !value
...
architecture: !mux
  arm: !value
  x86_64: !value

The goal would be to have a variant like the following created:

Variant run-architecture-x86_64-distro-centos-version-8-a910:    /run/distro/centos/version/8, /run/architecture/x86_64
    /run/architecture       => x86_64
    /run/distro/centos/version => 8
    /run/distro              => centos

Or, alternatively, if we decide to keep the current representation with keys always preceded by a :name, a variant like the following would be printed:

Variant run-architecture-x86_64-distro-centos-version-8-a910:    /run/distro/centos/version/8, /run/architecture/x86_64
    /run/architecture:architecture       => x86_64
    /run/distro/centos/version:version => 8
    /run/distro:distro              => centos

The result is that a test using this structure would be able to do:

self.params.get('architecture') # returns 'x86_64'
self.params.get('version') # returns '8'
self.params.get('distro') # returns 'centos'

@harish-24 @sathnaga @richtja does this sound like something that would be useful? Can you spot any shortcomings?

[sathnaga]

@clebergnu This will work and will be useful for a variants name is same as the variable name or variants with just one variable defined, which is true in this case.

Only concern I have is the backward compatibility with this, if we are fine to float around both the representation for a while and let users naturally shift towards the new representation as an benefit, it will be good.

Apart from the cleaner yaml and usability aspects, do you see any additional functional improvements, which will help to advertise and bring people on board.

[narasimhan-v]

@clebergnu Does this mean we support both ways of yaml representation ?
Reason being, The value need not always be the variant name.

architecture: !mux
  arm:
    arch: arm
  x86_64:
    arch: x86_64
  powerpc:
    arch: ppc64

So, does it mean we will support a combination of both formats, like below:

architecture: !mux
  arm: !value
  x86_64: !value
  powerpc:
    arch: ppc64

[harish-24]

@clebergnu One additional point I want to clarify here is whether the datatype of the value can be preserved. Does it have any impact with the new format?

distro: !mux
   centos: !value
   version: !mux
      8: !value
      7: !value

keys always used to be a string in old format. Now that we define only values, Are we going to treat the values based on the merit of it? i.e 8 as int and centos as str. And also can we define null values ? (as the existing format may have some issue there #4010)

As others already discussed, backward compatibility may also provide answer to this as well.