Changes between Version 14 and Version 15 of FeddAbout

Timestamp:

May 5, 2014 2:06:15 PM (11 years ago)

Author:

faber

Comment:

--

FeddAbout

@@ -134 +134 @@
 
 
-= Experiments =
+= Experiment Layouts =
 
-A federated experiment combines resources from multiple independently administered testbeds into a cohesive environment for experimentation.  How much the independent testbeds preserve their internal configurations is a matter of policy and experiment controller requests.  Most of the existing access controllers will allow a master testbed to export user and filesystem information into all segments when that is consistent with policy.  Local access controllers can configure their resources as they noremally would as well.
+A federated experiment combines resources from multiple independently administered testbeds into a cohesive environment for experimentation.  How much the independent testbeds preserve their internal configurations is a matter of policy and experiment controller requests.  Most of the existing access controllers will allow a master testbed to export user and filesystem information into all segments when that is consistent with policy.  Local access controllers can configure their resources as they normally would as well.
 
-Currently experiments can be described in the same ns2 syntax that DETER
-uses. Most users will specify experiments in this format, initially. 
-Fedd also understands experiments expressed in the [FeddPluginArchitecture#TopologyDescriptionLanguage topdl] language that it uses to communicate with facilities.
+Because federants may have very different resource models, the DFA describes experiment layouts in general terms.  Resources used to compute, sense, or manipulate are described along with their communications interconnections with other resources.  Connectivity is generally described in terms of which resources can send and receive messages from others. 
 
-An experimenter creates an experiment by presenting it to an experiment controller that knows him or her - usually the DETER experiment contoller or one on their local testbed. That controller will map the local user into the global (testbed, project, user) namespace and acquire and configure resources to create the experiment.  An experiment controller may try different mappings of the experimenter into the global namespace in order to acquire all the resources.  For example a local experimenter may be a member of several local DETER projects that different access controllers will accept.
+An experimenter creates an experiment layout by presenting a description of it to an experiment controller that knows him or her - usually the DETER experiment controller or one on their local testbed. That controller will map the local user into the global (testbed, project, user) namespace and acquire and configure resources to create the layout.  An experiment controller may try different mappings of the layout into the global namespace in order to acquire all the resources.  For example a local experimenter may be a member of several local DETER projects that different access controllers will accept.
 
 While an experiment exists, experimenters can access the nodes directly
@@ -148 +146 @@
 experiment's topology from the experiment controller.  
 
-=== Experiment Descriptions ===
+=== Layout Descriptions ===
 
-An experiment description is currently given in a slightly extended version of the [https://users.emulab.net/trac/emulab/wiki/nscommands ns2 dialect that is used for an DETER experiment description.] Specifically, the `tb-set-node-testbed` command has been added.  Its syntax is:
+Currently layouts can be described in the same [https://users.emulab.net/trac/emulab/wiki/nscommands ns2 syntax that DETER
+uses]. Most users will specify experiments in this format, initially. 
+Fedd also understands layouts expressed in the [FeddPluginArchitecture#TopologyDescriptionLanguage topdl] language that it uses to communicate with facilities.  There are [NsTopdlExtensions ns2 extensions] that allow users to specify the various topdl constructs from within an ns2 file.
+
+The key attribute for resources in a federated layout is the ''testbed'' attribute that determines which federant will supply the resource.  In topdl this is given as an attribute on the elements.  In ns2, the `tb-set-node-testbed` command is used.  Its syntax is:
 
 {{{
@@ -156 +158 @@
 }}}
 
-The `node_reference` is the tcl variable containing the node and the `testbed_string` is a name meaningful to the `fedd` creating the experiment.  The experiment creation interface has a mechanism that a requester can use to supply translations from testbed names to the URIs needed to contact that testbed's `fedd` for access.
+  The `node_reference` is the tcl variable containing the node and the `testbed_string` is a name meaningful to the `fedd` creating the experiment.  The experiment creation interface has a mechanism that a requester can use to supply translations from testbed names to the URIs needed to contact that testbed's `fedd` for access.
 
 Multiple segments of a federerated experiment can be embedded on the same testbed specifying the testbed_name as ''name''/''subname''.  In that syntax, ''name'' is the identifier of the testbed on which to embed the node and ''subname'' is a unique identifier within the federated experiment.  All the nodes assigned to '''deter/attack''' will be in the same sub-experiment and that will be a different sub-experiment from nodes in '''deter/defend'''.
 
-In addition, `fedd` understands the `tb-set-default-failure-action` command.  This sets the default failure action for nodes in the experiment to one of '''fatal''', '''nonfatal''', or '''ignore'''.  Those values have the same meaning as in standard Emulabs. Nodes that do not have their failure mode reset by the `tb-set-node-failure-action` command will user the explicit default.  If no default is set, '''fatal''' is used.
 
 = Attribute-Based Access Control (ABAC) =