----- 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. 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. 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. > > > 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? > > > Let us know whether you agree with my assessment, and if there's > > something I missed, including a better format/way to solve the > > original problem. If you read so far, thank you very much for your > > patience! > > I hope you will take into account my concerns and moreover enjoy our > extension. After all, Cartesian configuration is my favorite part of > virt-test :) > > Best, > Plamen > > > > _______________________________________________ > 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
