2016-05-16 8:47 GMT+02:00 Ondrej Lichtner <olichtne(a)redhat.com>:
On Fri, Apr 22, 2016 at 10:51:58AM +0200, Jiri Prochazka wrote:
> Hello everyone,
>
> first working draft implementation is completed. Please, read this cover
> letter, check the patches and let me know what you like, what you don't like,
> etc. Please, note, that this is not final implementation.
>
> NOTE - patches are not rebased to current HEAD, if you want to try it,
> please, reset your branch to commit 2398f93.
>
> What doesn't work
> =================
> multi_match - didn't have time and resources to check physical machines,
> on virt setup it works, but ends with exception due to no res value returned
> loopbacks - can't be created
> netem support - not implemented yet
>
> Description of new mechanics
> ============================
> Since we need to run TaskAPI methods to get machine requirements from PyRecipe,
> methods like provision_machines, prepare_network are run after the python recipe
> is executed. Methods add_host and add_interface create machine requirements dict
> in ControllerAPI object. When lnst.match() is called, it runs match algorithm
> with mreq dict and if match is found, it prepares network and binds Machine
> and Interface objects with their HostAPI and InterfaceAPI counterparts.
> When everyting is prepared, execution returns to PyRecipe, where task phase
> of PyRecipe is executed. Task phase is the same like before, only new method
> is breakpoint() which will be useful for debugging, as it allows user to pause
> the execution in whatever part of test.
> TaskAPI is now used right from lnst module, all callable methods are exported
> via __init__.py file from lnst/ dir.
> Folder pyrecipes/ contains few working examples you can try.
>
> TODO
> ====
> * multimatch support
> * config_only mode should be renamed and polished
> * TaskAPI create_ovs() method
> * support for loopbacks
> * NetEm support
> * polishing of the code
>
> Jiri Prochazka (26):
> __init__.py: draft for PyRecipes
> lnst-ctl: draft for PyRecipes
> NetTestController: remove RecipeParser import and related method calls
> NetTestController: add run_mode attribute
> NetTestController: remove obsolete methods
> NetTestController: use mreq dict from PyRecipe
> NetTestController: split provision_machines() in two methods
> NetTestController: cleanup _preapre_interface()
> NetTestController: remove resource sync from _prepare_machine()
> NetTestController: add multi_match attribute ti NetTestController
> NetTestController: don't call abs_path on _recipe_path in __init__
> NetTestController: rework alias handling
> NetTestController: add prepare_test_env()
> NetTestController: rework match_setup(), config_only_recipe(),
> run_recipe(), _run_python_task()
> NetTestController: add init_taskapi()
> NetTestController: use Task name instead of module
> Task: remove deprecated methods
> Task: add default param for get_alias()
> Task: define TaskAPI methods on global level
> Task: add breakpoint()
> Task: add add_host() and init_hosts()
> Task: add interface handling TaskAPI methods
> Task: HostAPI get_id now returns its generated id
> Task: add HostAPI methods required by PyRecipes
> Task: add match() and minor rework of ControllerAPI
> PyRecipes: add example PyRecipes
>
> lnst-ctl | 16 +-
> lnst/Controller/NetTestController.py | 398 ++++++++++-------------------------
> lnst/Controller/Task.py | 240 +++++++++++----------
> lnst/__init__.py | 1 +
> pyrecipes/3_vlans.py | 34 +++
> pyrecipes/example.py | 33 +++
> pyrecipes/ping_flood.py | 48 +++++
> 7 files changed, 363 insertions(+), 407 deletions(-)
> create mode 100644 pyrecipes/3_vlans.py
> create mode 100644 pyrecipes/example.py
> create mode 100644 pyrecipes/ping_flood.py
>
> --
> 2.4.11
> _______________________________________________
> LNST-developers mailing list
> lnst-developers(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/admin/lists/lnst-developers@lists.fedoraho...
Overall, in addition to the small comments that I've sent for the
obvious errors I want to add that I don't like how this patchset is
organized.
Thanks for the remarks Ondrej, appreciated!
It first starts adding some references to code that doesn't exist
yet.
The it removes the old code while the new one isn't there yet. And only
starts adding the rest later, still introducing references to other
still nonexistant parts of the new code.
There's two problems with this approach:
* It makes the patchset very hard to follow and pretty confusing.
* It breaks git bisect functionality
I realize that this is a big feature change and we still need to discuss
how we're going to move forward with it since it completely breaks
backwards compatibility...
I'd propose that we create a new branch in official git repo for
testing purposes,
and when the implementation will be ready, we can merge it to master and release
new version.
But it's exactly because it's such a big change that I think
that the
patchset should be organized in such a way that it's as easy as possible to
understand/follow.
I agree, I'll try to make new version in more organized manner (I was in a hurry
when creating this patchset). I'll wait for comments from jtluka and if someone
from Mellanox wants to review and comment the patches, I'll be more that glad.
> -Ondrej