X-Git-Url: http://git.onelab.eu/?p=nepi.git;a=blobdiff_plain;f=doc%2Fuser_manual%2Ffaq.tex;h=68da1129292a2120854f3ba61b258b35dae9ba49;hp=d4e4efc36fa4c44c4c39e44ad616b618d4d303b6;hb=8b8d0779bade89727a816e8dd123bbacb6af9aee;hpb=f9631afb18ea8aae08ebe9604425b6d51cb8c846 diff --git a/doc/user_manual/faq.tex b/doc/user_manual/faq.tex index d4e4efc3..68da1129 100644 --- a/doc/user_manual/faq.tex +++ b/doc/user_manual/faq.tex @@ -26,70 +26,53 @@ NEPI is a Python library that provides classes to describe and run network experiments on different experimentation platforms (e.g. Planetlab, OMF wireless testbeds, network simulators, etc). -Imagine that you want to run an experiment to test a distributed -application you just coded, on the Internet. -You can use NEPI to deploy your application on PlanetLab -nodes, run the experiment, and collect result files -you might have generated during the -experiment (e.g. pcap files from tcpudmps). - -Sure, you could do this by coding your own BASH script, but -it will probably take more time and painful hours of debugging -if you want to do it right. +Imagine that you want to run an experiment to test on the Internet +a distributed application you just implemented. +You can use NEPI to automate deployment of your application on +the PlanetLab testbed, run the experiment, and then collect result files +to your local machine. NEPI aims at providing a re-usable code base to run network -experiments on target experimentation platforms, so to -decrease the time you spend in developing platform specific -scripts or programs, and debugging them. - -In a nut-shell, NEPI is a network experiment -management framework which provides a simple way of -describing network experiments, and the logic to automatically -deploy those experiments on the target experimentation environments. +experiments on target experimentation platforms, and in this +way decrease the time you spend developing platform-specific +scripts and debugging them. + +NEPI is a network experiment management framework that provides a +simple way of describing network experiments, and the logic to +automatically deploy those experiments on the target experimentation +environments. It also provides the means to control the resources used in the experiment (e.g. Nodes, applications, switches, virtual machines, routing table entries, -etc ) during experiment execution, and to collect results generated by +etc) during experiment execution, and to collect results generated by the experiment to a local repository. -The experiment deployment and control is done by the -Experiment Controller (EC) entity, which is responsible for the +The experiment deployment and control are done by the +ExperimentController (EC), which is the entity responsible for the global orchestration of the experiment. The EC knows nothing about how to manage specific resources (e.g. how to configure a network interface in a PlanetLab node), -instead it delegates those tasks to entities called Resource Manager (RM). - -The RMs are responsible of controlling single resources -(e.g. a Linux host, an Open vSwitched on PlanetLab -nodes, etc). Different types of resources will be controlled by -different RMs, specifically adpated to control them. -All RMs implement a same external interface, that the EC uses -to control them in a uniform way. - -NEPI is not magical, it can not control all existing resources +instead it delegates resource management to platform-specific +entities called Resource Manager (RM). +The RMs are responsible for controlling resources +(e.g. Linux hosts, Open vSwitches on PlanetLab +nodes, etc). Different types of resources are be controlled by +specific RMs. +All RMs implement a same API that the EC uses to communicate +with them in a uniform way. + +NEPI can not control all existing resources on all existing experimentation platforms by default. -However, potentially any resource could be controlled by -NEPI if the adequate Resource Manager is implemented for it. -Fortunately, NEPI already provides several Resource Managers for -different resources on a variety of testbeds, and new -Resource Manager classes can be extended from existing ones, -to control new types of resources. - -The idea behind NEPI is to enable runing network experiments on +However, arbitrary resources can be controlled in NEPI if the +corresponding Resource Manager is implemented for it. +Fortunately, NEPI already provides several ResourceManagers to +manage different resources on a variety of testbeds, and new +Resource Manager classes can be extended from existing ones by +the experimenters. +The idea behind NEPI is to support running network experiments on potentially any experimentation platform, using a single -software tool, as opposite to using a dedicated software for -each platform. An additional perk is that you don't have to deal -with a lot of platform-specific gory details of setting up and -configuring the resources (e.g. Creating a TAP device on Planetlab. -If you ever had to do that, you know what I mean). Also, -you could combine resources from different platforms in a same -experiment, using just one script. - -So, 'One ring to rule them all', sorry I meant, 'One tool to -control them all'... or something like that. -We though it was a good idea to abstract platform details -behind a common resource management interface, and let -NEPI deal with the details and give you back the results. - -\section{What does a NEPI script look like ?} +software tool, instead of using a dedicated software for +each platform. + +\section{What does a NEPI script look like?} \label{faq:ping_example} Here is a very simple experiment example, which runs a PING @@ -100,7 +83,7 @@ ssh\_key variables va to run the example. \begin{lstlisting}[language=Python] from nepi.execution.ec import ExperimentController -ec = ExperimentController(exp_id = "myexperiment") +ec = ExperimentController(exp_id="myexperiment") hostname = # Host that can be accessed with an SSH account username = # SSH user account on host @@ -127,17 +110,16 @@ ec.shutdown() \section{What does NEPI stands for?} -It stands for: Network Experiment Programming Interface. +It stands for Network Experiment Programming Interface. \section{Who developed NEPI?} NEPI was developed at INRIA, Sophia Antipolis France. A first prototype was implemented in 2010. Versions 1.0 and 2.0 were released in 2011 and 2012, respectively. -The current version is 3.0, and it was completely redesigned and -rewritten to broaden the scope, and to include several -new features, which will be described in detail in this document. -The following people has contributed to the project: +The current NEPI version is 3.0. + +The following people have contributed to the project: \begin{itemize} \item NEPI version 3.0: Alina Quereilhac, Julien Tribino, Lucia Guevgeozian Odizzio, Alexandros Kouvakas @@ -149,7 +131,7 @@ The following people has contributed to the project: \section{Is it free?} Yes, NEPI is free software. It is free to use, free to modify, free to share. -NEPI v3.0 is licensed under GPL v3, so you can do whatever you want with it, +NEPI v2.0 is licensed under GPL v2, so you can do whatever you want with it, as long as you keep the same license. \section{How can I contribute?} @@ -180,9 +162,9 @@ To report a bug take a look at the NEPI bugzilla page at : \url{http://nepi.inria.fr/bugzilla} \\ -\section{Where can I get more information ?} +\section{Where can I get more information?} -For more information visit NEPI web site at : +For more information visit NEPI web site at: \url{http://nepi.inria.fr} \\