Re: [RFC] LNST Python Recipe (PyRecipe) Draft

[Ondrej Lichtner]

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​
>  
>  [phone] | jprochaz(a)redhat.com
>  Red Hat Czech | Purkyňova 71/99, 612 00 Brno 
Overall a nice summary of pros and cons of different approaches.

-Ondrej