Il 16/05/2014 17:42, Ademar Reis ha scritto:
I believe this lack of structure is the root cause of many of the
problems or dislikes we have with the system.
I agree.
It might be better to explain the concept with an hypothetic
example:
## reference tree ##
* virtio_net
- filter: "only guest->os->linux" # meaning: only
# the linux leave
# of guest->os will
# be used
Interesting. Why a string that has to be parsed, and not something like
- filter-only: "guest->os->linux"
or even (similarly, "conflicts" for Cartesian config "no")?
- requires: "guest->os->linux"
- nic_model = virtio
- enable_msix_vectors = yes
* tests
- filter: "no tests" # we don't want to multiplex test
# variables from different tests, so we
# filter out the entire branch
I don't get this. :)
* sync_test
- filter: "only guest->os->linux" # we don't want to
# multiplex other OSes here
- filter: "only hardware->disks" # self-explanatory
Do you mean that leaves other than hardware->disks will get the default
values from say hardware->network? So it would be, more precisely:
* network
- nic_model = none
* rtl_8139
- nic_model = rtl8139
* e1000
- nic_model = e1000
which seems to work for network.
But then you have a problem for disks, where "none" is not really a
possibility. Here you have:
* ping_test
- filter: "only guest->os->linux" # we don't want to
# multiplex other OSes here
- filter: "only hardware->network" # self-explanatory
This would mean that hardware->disks would not be expanded. You would have:
* hardware
* disks
- drive_format = ?!? # some machines have default ide,
# others have virtio... how to
# express this?
* ide
- drive_format = ide
* scsi
- drive_format = scsi
* virtio
- drive_format = virtio
But then how can an ARM variant say what the default is? If you do this:
* arm
* virt
- filter: "only hardware->disks->virtio"
It would conflict with the "only hardware->disks" in the tests.
Perhaps this could work:
* arm
- default: { key: "hardware->disks", value: "virtio" }
- default: { key: "hardware->network", value: "virtio" }
...
* ping_test
- filter: "only guest->os->linux" # requires suggested :)
- expand: "hardware/network"
So by default neither hardware/disks nor hardware/network are expanded,
because there is a "default" clause somewhere. However, tests can
choose to expand other branches. The user can also choose to expand a
branch.
Conflicting defaults are an error. Perhaps user defaults could be
allowed to override system defaults, though...
## multiple files, namespaces ##
We have one single tree, but we can use multiple files to declare
the variants.
This is brilliant. The current directory system could be allowed too.
* synctest.cfg:
"""
filter: "no env->host"
filter: "no env->guest"
"""
* $ avocado --multiplex=file.mplx synctest
* --> using the config file above, this will multiplex only
the env variables, resulting in two variants: production
and debug.
This is similar to what you wrote as "only hardware->disks". I think
there is some confusion here.
Would you try rewriting your example in terms of
expand/default/requires/conflicts and see if it works out right?
Paolo
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
