Changes between Version 11 and Version 12 of FeddDownload

Timestamp:

Jun 5, 2010 10:49:25 AM (14 years ago)

Author:

faber

Comment:

--

FeddDownload

@@ -17 +17 @@
    Responsible for negotiating access to local testbed resources.  It both maps the user into the local access control and manipulates local resources.
 
-Which role a fedd will act in depends on the configuration of the fedd.  A single testbed is likely to run both an access controller to make its resources availabel to others and an experiment controller to create experiments for its local users.  However, there is no requirement that experiment controllers run on testbed infrastructure.  A trusted experiment controller may run on a desktop or elsewhere, as long as there are access controllers are willing to grant resources to [FeddAbout#GlobalIdentifiers:Three-levelNames three-level names] that are anchored to its [FeddAbout#GlobalIdentifiers:Fedids fedid].
+Which role a fedd will act in depends on the configuration of the fedd.  A single testbed is likely to run both an access controller to make its resources available to others and an experiment controller to create experiments for its local users.  However, there is no requirement that experiment controllers run on testbed infrastructure.  A trusted experiment controller may run on a desktop or elsewhere, as long as there are access controllers are willing to grant resources to [FeddAbout#GlobalIdentifiers:Three-levelNames three-level names] that are anchored to its [FeddAbout#GlobalIdentifiers:Fedids fedid].
 
 == What machines should run fedd ==
 
-Under fedd version 2.0, the experiment controller - the fedd that accepts user requests- may run on any machine, though it is often convenient to run it on the users machine of an emulab testbed.  It will be asserting [http://fedd.isi.deterlab.net/trac/wiki/FeddAbout#GlobalIdentifiers:Three-levelNames three-level names] so it is intuitive to colocate a controller that will be asserting identities from a given testbed, but not required.  Any host with a [http://fedd.isi.deterlab.net/trac/wiki/FeddAbout#GlobalIdentifiers:Fedids fedid] can assert them, of course.
+Under fedd version 2.0 or later, the experiment controller - the fedd that accepts user requests- may run on any machine.  It will be asserting [http://fedd.isi.deterlab.net/trac/wiki/FeddAbout#GlobalIdentifiers:Three-levelNames three-level names] so it is intuitive to colocate a controller that will be asserting identities from a given testbed, but not required.  Any host with a [http://fedd.isi.deterlab.net/trac/wiki/FeddAbout#GlobalIdentifiers:Fedids fedid] can assert them, of course.
 
 The following discussion applies to the access controllers running on emulab-style testbeds.
@@ -92 +92 @@
  `/usr/local/bin/fedd.py`::
   fedd itself
+ `/usr/local/bin/fedd_client.py`::
+  legacy fedd command line access
+ `/usr/local/bin/fedd_create.py`::
+  creates federated experiments
+ `/usr/local/bin/fedd_ftopo.py`::
+  returns a general logical to physical mapping
+ `/usr/local/bin/fedd_image.py`::
+  generates images of federated topologies
+ `/usr/local/bin/fedd_info.py`::
+  provides general information about federated experiments
+ `/usr/local/bin/fedd_multiinfo.py`::
+  provides general information about multiple experiments
+ `/usr/local/bin/fedd_multistatus.py`::
+  provides summary information of the status of experiments accessible by this user
+ `/usr/local/bin/fedd_new.py`::
+  gets a new federated experiment reservation without attaching resources to it
+ `/usr/local/bin/fedd_ns2topdl.py`::
+  converts an ns2 representation of an experiment to a topdl one
+ `/usr/local/bin/fedd_spewlog.py`::
+  monitor the process of creating an experiment
+ `/usr/local/bin/fedd_terminate.py`::
+  ends an experiment
  `/usr/local/bin/fedd_client.py`::
   command line tool for accessing fedd services