Changes between Version 23 and Version 24 of FeddDownload

Timestamp:

Mar 29, 2012 6:20:41 PM (13 years ago)

Author:

faber

Comment:

--

FeddDownload

@@ -18 +18 @@
 
 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 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.
-
-Depending on what sorts of resources you intend to make available to
-others and what modifications you are willing to make to your testbed,
-you may choose to run a fedd access controller in different configurations, with
-functionality partitioned between users and boss.
-
-If you intend to allow an access controller to either create projects from whole cloth,
-or to modify the access rights of projects or keys of users, at least
-some of fedd will have to run on boss.  You can choose to run a fedd
-install on boss only, or run the main instantiation of fedd on users and
-the project manipulation functionality on boss.  This depends on your
-particular comfort level with outside access to boss.  Fedd's local
-accesses are all encrypted and controlled via fedids, and potentially by
-SSL as well.
-
-If you intend to only allow federation through static projects, fedd
-can run entirely on users, and need only be installed there.
-
-Fedd also needs to run a modified ns2 parser to split experiments.
-DETER exports an interface to that parser at
-!https://users.isi.deterlab.net:23235 , and the simplest configuration
-choice is to simply make use of that service.  Should you choose to get
-the patches from us and run your own modified ns2 parser, you would
-probably want to run that service on your ops node.
-
-The [FeddConfigExamples examples page] has a concrete set of example layouts and appropriate configurations.
 
 == Downloading and Installing the tar file ==
@@ -203 +171 @@
 }}}
 
-And from there, install from the tar file in dist, as above.  The build scripts expect the wsdl interface descriptions to be in {{{../wsdl }}} relative to the fedd source directory.  SOAP/Web Services interface code is generated from those files.  When the tarfile is used, the generated files are included, so the {{{wsdl}}} directory is not delivered.
+And from there, install from the [FeddDownload#DownloadingandInstallingthetarfile tar file in dist, as above].  The build scripts expect the wsdl interface descriptions to be in {{{../wsdl }}} relative to the fedd source directory.  SOAP/Web Services interface code is generated from those files.  When the tarfile is used, the generated files are included, so the {{{wsdl}}} directory is not delivered.
 
 You can also browse the source [source:/fedd/trunk on the web].
-
-== Subversion access ==
-'''As of 2010-12-04, we have moved to git'''
-
-Consider any copies of the SVN tree you may have to be archival.