Dne 26.11.2014 v 19:35 Lukáš Doktor napsal(a):
Dne 26.11.2014 v 18:54 Paolo Bonzini napsal(a):
On 26/11/2014 18:01, Lucas Meneghel Rodrigues wrote:
[sni[
Very nice. Is "@prod" YAML though? What about something like this...
The @ was remain from when I started writing the email. Actually because
of the params hooks, default should not be needed. (see below)
I renamed "variant" to "mux-choice", and also filter-only/filter-out to
mux-only/mux-no for brevity. I also introduced mux-group, to distinguish
them from variables; finally, I'm using YAML tags to distinguish
groups and
choices from variables.
Nice, I like `mux-...`, quicker to compare. Yes, everything needs to be
turned into YAML custom types, the previous email was just an example.
I hope I have not destroyed Lukas's idea too much... the idea was to
*keep*
them rather than destroy them.
- foo:
123 #
variable
- bar:
[1,2,3] #
variable
- !mux-group
hw: # choices
below are automatically prefixed by /hw
- !mux-choice
cpu: # /hw/cpu can be
intel, amd, arm
- intel:
- mux-default: true
- cpu:
'SandyBridge' # variable
- amd:
- cpu:
'Opteron_G1' # variable
- arm:
- mux-only: { '/env': 'debug', '/os': 'linux' }
- mux-no: { '/hw/net/nic_model' : [ 'e1000', 'rtl8139' ] }
- cpu: 'cortex-a15
' # variable
- !mux-choice
disk: # /hw/disk can be
scsi, virtio
- scsi:
# Code can use params.get('/hw/disk'), so no need
for variables
- virtio:
- mux-default: true
- mux-only: { '/os' : 'linux' }
- !mux-group
net: # choices below
are automatically prefixed by /hw/net
- !mux-choice
backend: # /hw/net/backend
- vhost:
- mux-default: true
- tap:
- user:
- !mux-choice
nic_model: # /hw/net/nic_model
can be virtio, rtl8139, e1000
# Code can use params.get('/hw/net/nic_model'), so
no need for variables
# but it doesn't hurt to specify them!
- virtio:
- mux-default: true
- nic_model: virtio
- rtl8139:
- nic_model: rtl8139
- e1000:
- nic_model: e1000
- !mux-choice
os: # /os can be
linux, win
- linux:
- dev-tools: 'gcc'
- !mux-choice
distro # /os/distro can be
fedora, mint
# if /os is linux
- fedora:
- mux-default: true
- package-manager: 'yum'
- init: 'systemd'
- !mux-choice
version # /os/distro/version can
be 13
13: # if /os is linux
and /os/distro is fedora
- mint:
- package-manager: 'apt-get'
- init: 'init'
- !mux-choice
version # /os/distro/version can
be 7
7: # if /os is linux
and /os/distro is mint
- win:
- bsod: true
- !mux-choice
dev-tools: # /os/dev-tools can
be cygwin, mingw, vs
# if /os is win
-
cygwin: # if no
mux-default, first wins
- dev-tools: Cygwin
- mingw:
- dev-tools: MinGW
- vs:
- dev-tools: VisualStudio
- !mux-choice
version: # /os/version can
be win7 or win8
# if /os is win
- win7:
- win8:
- bsod: false
- !mux-choice
env: # /env can
be debug or prod
- debug:
- mux-only: {'/os/distro': 'fedora'
} # also filters out /os:win
# because it has no /os/distro
- prod:
- mux-default: true
- !mux-choice tests:
- ping_test:
- mux-expand: [ '/hw/net'
] # ignore mux-default under
/hw/net, can still be
# restricted by user-supplied mux-only/mux-no
This looks amazing and should be doable in YAML. The `mux-default`
should not be needed. Let me explain the idea here. Do you remember the
ways to execute test from my email:
1) default variant
2) full test
3) all related
4) multiplex all
And the places where variants are stored:
A) yaml file added on cmdline (/hw, /os, ...)
B) each test's associated file (/tests/$name/duration,
/test/$name/function, ...)
Let me add another place (Z) for default variables (new idea), let's say
`avocado.yaml` which would be 1 level yaml with all default variables
(image: "Fedora", passwd: "123456", ...)
BTW the (Z) is new idea and was not part of the original RFC. There are
multiple ways:
1) we can hardcode defaults (and hooks would take care of arch/sw
dependent keys).
2) Use the (Z) defaults file
3) We can use `!mux-default` (requires always parsing the tree)
When you execute test as 1), it'd take default values from Z) and than
get only first level values from B)
In case you execute 2), it'd again get default values from Z) and then
it'd parse the B) tree.
The 3) would need to parse Z), A) and B) and multiplex only mux-groups
specified in the B).
The 4) would parse Z), A) and B) and multiplex everything what is not
filtered out.
######################################################################
Lucas also pointed out, that I didn't explain the hooks sufficiently. So
how the params.get() should look like:
def get(key, default):
raw_value = super(Params, self).get(key, default)
if key in self.hooks:
return self.hooks[key](raw_value, default)
else:
return raw_value
where hook could eg. means:
def arch_hook(raw_value, default):
# params.get("/hw/arch")
if not raw_value:
if default:
return default
else:
return arch.get_supported_archs()[0]
elif raw_value not in arch.get_supported_archs():
if default:
return default
else:
raise TestNAError("Architecture ... not supported")
else:
return raw_value
Similarly you can handle -device support, default drive format, ...
Anyway I'll take a deeper look at the mux domains you proposed, it's
named version of what I had in mind (and better supported in yaml).
Thank you for your response,
Lukáš
I'm not 100% sure this is valid YAML, but should be close.
Thanks,
Paolo
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
