experiment description into a running experiment.
In order to do this the EC needs to know which resources are to be
used, how they should be configured and how resources relate to one another.
-To this pourpose the EC exposes methods to register resources, specify their
+To this purpose the EC exposes methods to register resources, specify their
configuration, and register dependencies between. These methods are part of
the EC design API.
Likewise, in order to deploy and control resources, and collect data,
\subsection{Registering connections}
-In order to describe the experiment set-up, resources need to be
-associated to one another. Through the process of connecting resources
+In order to describe the experiment set-up, a resources need to be
+associated at least to one another. Through the process of connecting resources
the \emph{topology graph} is constructed. A certain application might
need to be configured and executed on a certain node, and this
must be indicated to the EC by connecting the application RM to the node
Attribute values can be retrieved at any moment during the experiment run,
using the \emph{get} method.
-However, not all attributes can de modified after a resource has
+However, not all attributes can be modified after a resource has
been deployed. The possibility of changing the value of a certain attribute
depends strongly on the RM and on the attribute itself.
As an example, once a \emph{hostname} has been specified for a certain Node
Further information about classes and method signatures
can be found using the Python \emph{help} method.
-For this inspection work, we recommend instantiating an
+For this inspection work, we recommend to instantiate an
ExperimentController from an IPython console. This is an
interactive console that allows to dynamically send input
to the python interpreter.
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 ide to abstract platform details
+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{Is it free?}
-Yes, NEPI is free software. It is free to use, free to to modify, free to share.
+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,
as long as you keep the same license.
\section{How can I report a bug ?}
-To report a bug take a look at the NEPI bugzilla page at:
+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 ?}
-For more information visit NEPI web site at
+For more information visit NEPI web site at :
\url{http://nepi.inria.fr} \\
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-NEPI is written in Python, so you will need to install Python before
-before being able to run experiments with NEPI.
+NEPI is written in Python, so you will need to install Python before
+being able to run experiments with NEPI.
NEPI is known to work on Linux (Fedore, Debian, Ubuntu) and Mac (OS X).
\section{Dependencies}
\fontsize{10pt}{12pt}\selectfont
\begin{verbatim}
- $ PYTHONATH=$PYTHONPATH:<path-to-nepi>/src python experiment.py
+ $ PYTHON
PATH=$PYTHONPATH:<path-to-nepi>/src python experiment.py
\end{verbatim}
\endgroup
The method \textit{register\_resource} declares a resource instance to the
Experiment Controller. The method \textit{register\_connection} indicates
-that two resource will interact during the experiment.
+that two resources will interact during the experiment.
Note that invoking \textit{add\_node} or \textit{add\_app} has no effect other
than informing the EC about the resources that will be used during the experiment.
The actual deployment of the experiment requires the method \textit{deploy} to
be invoked.
The Resource Managers (RM) that abstract the concrete resources expose
-configuration attributes. In the LinuxNode RM we set the \emph{hostname}
+some configuration attributes. In the LinuxNode RM we set the \emph{hostname}
and \emph{username} as attributes, while in the LinuxApplication RM
we set the \emph{command} attribute.
-Apart from teh \emph{command} attribute, the \emph{LinuxApplication}
+Apart from the \emph{command} attribute, the \emph{LinuxApplication}
ResourceManager exposed several other attributes
that permit to upload, compile and install arbitrary sources,
to run any application might be needed to run an experiment.
Lets now use these functions to describe the experiment we will run.
Choose a host where you have an account, and can access using SSH
key authentication. Define string variables with the right
-values for the \emph{hostname}, \emph{username} and path to the
-SSH public key in as \emph{ssh\_key}, and then type the following lines.
+values for the \emph{hostname}, \emph{username} and the path to the
+SSH public key in \emph{ssh\_key}, and then type the following lines.
\begin{lstlisting}[language=Python]
another. Indeed, different platforms provide their own mechanisms to
access resources and different tools to conduct experiments.
These tools vary widely, for instance, to run a ns-3 simulation it is
-necessary to write a C++ program, while to conduct and experiment using
+necessary to write a C++ program, while to conduct an experiment using
PlanetLab nodes, one must first provision resources through a special web
service, and then connect to the nodes using SSH to launch any applications
involved in the experiment.
can be a time consuming and difficult task, specially if distributed
resources need to be synchronised to perform the right action at the
right time. Detecting and handling possible errors during experiment
-execution also posses a challenge, even more so when dealing with large size
+execution also posses a challenge, even more when dealing with large size
experiments. Additionally, difficulties related to instrumenting the
experiment and gathering the results must also be considered.
% Challenge
In this context, the challenges that NEPI addresses are manifold.
-Firstly, simplifying the complexity of running network experiments.
-Secondly, simplifying the use of different experimentation platforms,
+Firstly, to simplify the complexity of running network experiments.
+Secondly, to simplify the use of different experimentation platforms,
allowing to easily switch from one to another.
-Thirdly, simplifying the
+Thirdly, to simplify the
use of resources from different platforms at the same time in
a single experiment.
connections. The attributes define the configuration of the resource,
the traces represent the results that can be collected for that resource
during the experiment and the connections represent how a resource relates
-to other resources in th experiment.
+to other resources in the experiment.
\begin{figure}[h]
\centering
\label{fig:intro_resources}
\end{figure}
-Examples of attributes are a linux host host name, an IP address to be
+Examples of attributes are a linux hostname, an IP address to be
assigned to a network interface, a command to run as a remote application.
Examples of traces are the standard output or standard error of a
running application, a tcpdump on a network interface, etc.
an \emph{interactive deployment} mode, where new resources can de
declared and deployed on the fly, according to the experiment needs.
This interactive mode can be useful to run experiments with the
-purpose of exploring a new technology, or to use NEPI as a adaptive
+purpose of exploring a new technology, or to use NEPI as an adaptive
experimentation tool, that could change an experiment according to
-changing external conditions or measurements.
+external conditions or measurements.
\section{Resource Management: The EC \& The RMs}
For each resource that the user registers in the \emph{topology graph}, the EC
will instantiate a RM of a corresponding type. A RM is a resource specific
-controller and different types of resources require a different type of
-RM, specifically adapted to manage them.
+controller and different types of resources require different type of
+RMs, specifically adapted to manage them.
The EC communicates with the RMs through a well defined API that exposes
the necessary methods (actions) to achieve all the state transitions defined by the
git://git.onelab.eu / nepi.git / commitdiff