Changes between Version 2 and Version 3 of FeddConfig

Timestamp:

Dec 10, 2008 4:04:30 PM (16 years ago)

Author:

faber

Comment:

--

FeddConfig

@@ -103 +103 @@
  '''allocation_level'''::
   This option defines what `fedd` will try to do to grant access.  The following are valid choices:
-
-
-   '''dynamic_projects'''::
-    Add new projects and users to the local Emulab in response to requests.  What users and projects and who may successfully request them is a function of the access DB below.  The access component decides what projects and users to add and the allocation component does the work.
-   '''dynamic_keys'''::
-    No projects or users are added to the local Emulab, but addtional keys may be granted access to user accounts and projects may have their access rights expanded.  Again the access component decides which users and projects to expand and the allocation system does so.
-   '''confirm_keys''':
-    The local Emulab is never changed, but the allocating `fedd` confirms that the users specified may be accessed by the given keys.  In effect, it confirms that the if the changes were requested, they would succeed.
+   * '''dynamic_projects''' - Add new projects and users to the local Emulab in response to requests.  What users and projects and who may successfully request them is a function of the access DB below.  The access component decides what projects and users to add and the allocation component does the work.
+ '''allocation_state'''::
+  Name of the file where current allocation state is saved.  This state includes
+  the project and user changes made to support each federated experiment request.  That state is used to decide
+  what to release and when.  Must be specified for allocation decisions to survive
+  fedd failures or node reboots.  A file in `/var/db/fedd` is often used.
+   * '''dynamic_keys''' - No projects or users are added to the local Emulab, but addtional keys may be granted access to user accounts and projects may have their access rights expanded.  Again the access component decides which users and projects to expand and the allocation system does so.
+   * '''confirm_keys''' - The local Emulab is never changed, but the allocating `fedd` confirms that the users specified may be accessed by the given keys.  In effect, it confirms that the if the changes were requested, they would succeed.
+   * '''none''' - The local Emulab is never changed, and no parameters are checked.  This makes allocation a no-op.
  '''addpubkey'''::
   Path to the `addpubkey` Emulab command.  Only useful for local allocation.  The default of `/usr/testbed/sbin/addpubkey` is usually insufficient.  See the instructions in [FeddDownload installing] for information on how to construct and install the `taddpubkey` version, and set this option to point at it.  Note that if you are not dynamically allocating resources, you need not create the new script nor set this option.
@@ -121 +122 @@
  '''grantnodetype'''::
   Path to the `grantnodetype` Emulab command.  Only useful for local allocation.  The default of `/usr/testbed/sbin/grantnodetype` is usually insufficient.  See the instructions in [FeddDownload installing] for information on how to construct and install the `tgrantnodetype` version, and set this option to point at it.  Note that if you are not dynamically allocating resources, you need not create the new script nor set this option.
+ '''log_level'''::
+  The level of logging to produce from this component.  One of `debug`, `info`, `warning`, `critical`, and `error`.  See the [http://www.python.org/doc/current/library/logging.html standard python logging system] for details.
  '''mkproj'''::
   Path to the `mkproj` Emulab command.  Only useful for local allocation.  The default of `/usr/testbed/sbin/mkproj` is usually correct.