On 04/29/2014 10:24 AM, Jiri Zupka wrote:
----- Original Message -----
Hi guys,
Since all possible changes in the Cartesian configuration format concern
our tests quite much, I want to share my opinion on some of the point below.
On 04/29/2014 04:55 AM, Lucas Meneghel Rodrigues wrote:
From the feedback gathered so far, the work items are:
1) Complexity
Solution: Implement Paolo's RFC outlined here:
https://www.redhat.com/archives/virt-test-devel/2014-February/msg00073.html
Would be a start
Paolo's proposal is good in the fact that it is an extension of the
currently available functionality. My main concern here is losing the
original meaning of "@" which I find rather useful. I think you will all
agree with me that short names instead of lengthy line-breaking strings
improve readability where desired. Can we perhaps keep the original
meaning of "@" at use another non-reserved character for this purpose?
It would be better than changing its meaning and finding another
character for name shortening for sure since people (and scripts) are
already accustomed to the current meaning. In this way we extend without
harming what we already have which is by no means useless. My second
point here would be that this is not really reduction of complexity,
since the general format is preserved and the only thing we do is even
add more complexity, however I guess for the better good.
There is implemented default variants through variants metadata and through @.
but it allows only one default from variants. Could be easy fixed.
take a look in cartesian_config line 205 more accurately 218
variants virt_system [ default=linux ]:
For enabling default metadata is necessary use generator switch "-d" or by
python function "defaults" parameter.
Interesting, maybe we could go with what is already available.
Paolo's proposal is good too. The Proposal don't need switch -d.
2) Frailty
Solution: Make the parser able to tell people wether they have messed
up their indentation, and be loud and fail instead of silently
ignoring the non-perfectly-aligned data.
I completely agree with this.
I absolutely agree with this,however, it loudly raise exception with wrong
indentation in new implementation, if I'm right. We have to fix lots of
indentation problem when we start using new implementation.
Absolutely. That is the plan, in fact. I'm sure a lot of small errors
would come out of the woodwork so we can kill them :)
It could be replaced by some more robust structure (something like json or
what ever but not XML it so verbose).
3) Inflexibility
Solution: Create a method that expands what the generators created,
and order according to the order the user asked for.
In our custom test suite we already have some considerable advances
here. It would be my pleasure to propose our solution for reviewing by
attaching two documents here or in separate e-mail. Of course only if
you wish so.
Please show us your implementation if it match new implementation goals then
it could be used.
Yes, that is real problem of today implementation, I though about repairing
this problem but it lead to more pass through cart config structure.
It should be repaired.
Fixing this problem leads to generation dictionary over multipass of variants
in today implementation. It is more time expensive.
Paolo suggest use some SAT solver for parsing variants and I have almost
prepared
splitting of cart config lexical parser from generator of final dictionary.
Then could be dictionary generator replaced by something else.
However external SAT solver => dependency on external C code wrapped to python.
It must be considered.
Yep, the external dependencies might not be where we want to be. I'm not
sure.
Do you think saving the list from the generator then ordering the dict
can be considered as a passable workaround? As of today, the size of the
typical test list is in the order of a dozen to a few thousand tests
tops, so it shouldn't be that much of a problem saving and re-ordering.
4) Generate variants from tests
Solution: Well, no idea on this one yet :)
I would generally deprecate such practice as the complexity will be
raised even more. In our experience and developed tests we haven't
encountered a need for some thing like this but I guess this is why I
cannot really prove a point here.
I've never needed use this functionality. Is there anybody who did?
See my answer to Plamen, where I mention Eduardo's feedback.
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
