On Mon, Nov 16, 2015 at 12:13:14PM +0100, Jiri Prochazka wrote:

​LNST Python Recipe (PyRecipe) Draft

Format of Execution

Option 1) lnst-ctl $OPTS $ARGS Example of execution: lnst-ctl -d -A ipv=ipv4 run ping_test.py netperf_test.py Pros and cons: + easy execution of multiple PyRecipes + parsing of $OPTS remains unchanged + no issues with config files + allowed mixing of XML recipes and PyRecipes - parsing of files from command line will have to be changed - XML and PyRecipes will need different network topology parsing and execution of tasks

My thoughts: This preserves the whole execution format and all it's advantages, such as execution of multiple recipes in one run, parsing of opts, config files, etc. However one big question about this format is, how the PyRecipe would be parsed and run if we want to keep XML recipes (at least for now).

I think for now this is the best option, and adding option 2 might be our next goal. What i definitely want to be able to do is call lnst-ctl on a directory, like this: lnst-ctl run recipes/

which would call all the recipes in the specified directory and should work with both XML recipes and Python recipes and XML recipes with Python tasks. I think we should at least try if this is possible and I think it might be...

My idea here is that we could probably encapsulate the contents of the Python Recipe file into a class separated into a couple of methods which we could detect from the lnst-ctl application and based on that decide if this is a python recipe or just a python task... This could also lead to a solution to our "import common" problem.

Option 2) python recipe.py $OPTS Example of execution: python ping_test.py -d -A ipv=ipv4 or chmod +x ping_test ./ping_test.py -d -A ipv=ipv4 Pros and cons: + cleaner execution format when executing one PyRecipe - parsing of $OPTS will have to be modified to a public method callable both from lnst-ctl (for XML recipes) and PyRecipe file - in fact, the whole lnst-ctl and NetTestController class should be refactorized because running XML recipes would be different from PyRecipes and we want to support both variants - config files will have to be either in default location /etc/ or passed via -c option - for executing of multiple PyRecipes, some wrappers/scripts would have to be created

My thoughts: Although the first idea of using this format seemed nice, overall it looks like a lot of things would have to be changes to make this work and I don't see many pros.

Option 3) support both formats My thoughts: I don't think this is necessary and it would need a ton of work to make it work

My two cents: I would go for option 1. We could go for supporting option 2 as well later, when there is more time and reasons for it. I think that right now, this format suits better our use-case scenarios we use with ENRT. ​ Please, express your opinion on this matter, so we can start working on this ASAP

-- ​Best regards,​

Jiri Prochazka LNST Developer ​| www.lnst-project.org​

+420 532 294 633 | jprochaz@redhat.com Red Hat Czech | Purkyňova 71/99, 612 00 Brno

Overall a nice summary of pros and cons of different approaches.

-Ondrej