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).
    
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 
+420 532 294 633 | jprochaz@redhat.com
Red Hat Czech | Purkyňova 71/99, 612 00 Brno