Changes between Version 2 and Version 3 of FeddConfig


Ignore:
Timestamp:
Dec 10, 2008 4:04:30 PM (15 years ago)
Author:
faber
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • FeddConfig

    v2 v3  
    103103 '''allocation_level'''::
    104104  This option defines what `fedd` will try to do to grant access.  The following are valid choices:
    105 
    106 
    107    '''dynamic_projects'''::
    108     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.
    109    '''dynamic_keys'''::
    110     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.
    111    '''confirm_keys''':
    112     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.
     105   * '''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.
     106 '''allocation_state'''::
     107  Name of the file where current allocation state is saved.  This state includes
     108  the project and user changes made to support each federated experiment request.  That state is used to decide
     109  what to release and when.  Must be specified for allocation decisions to survive
     110  fedd failures or node reboots.  A file in `/var/db/fedd` is often used.
     111   * '''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.
     112   * '''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.
     113   * '''none''' - The local Emulab is never changed, and no parameters are checked.  This makes allocation a no-op.
    113114 '''addpubkey'''::
    114115  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.
     
    121122 '''grantnodetype'''::
    122123  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.
     124 '''log_level'''::
     125  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.
    123126 '''mkproj'''::
    124127  Path to the `mkproj` Emulab command.  Only useful for local allocation.  The default of `/usr/testbed/sbin/mkproj` is usually correct.