[RFC] LNST Python Recipe (PyRecipe) Draft

[Jiri Prochazka]

​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
​| www.lnst-project.org​

[phone] | jprochaz(a)redhat.com
Red Hat Czech | Purkyňova 71/99, 612 00 Brno