Re: Request for review [final templates]
hi,
thanks for all your input regarding the Condor templates. For the
record, I'm attaching the current/final state. I will send out a
call for translations shortly.
Michael
--
Michael Hanke
http://mih.voxindeserto.de
Template: condor/title
Type: title
_Description: Condor configuration
Template: condor/wantdebconf
Type: boolean
Default: false
_Description: Manage initial Condor configuration automatically?
The setup for Condor can be handled automatically, asking a few questions
to create an initial configuration appropriate for a machine that is either
a member of an existing pool or a fully functional "Personal Condor
installation". This generated initial configuration can be further extended
later on.
.
Otherwise, Condor will be installed with a default configuration that needs
to be customized manually.
Template: condor/phonehome
Type: boolean
Default: false
_Description: Enable submission of usage statistics?
The Condor authors politely request that each Condor pool sends them periodic
updates with basic information about the status of the pool. Updates include
only the total number of machines, the number of jobs submitted, the number
of machines running jobs, the host name of the central manager, and the name
of the pool. These updates help the Condor Team see how Condor is being used
around the world.
Template: condor/centralmanager
Type: string
_Description: Address of the central manager:
If this machine is intended to join an existing Condor pool, the address of the
central manager machine has to be specified. Any address format supported
by Condor can be used, including macro expressions.
.
Example: condor-manager.example.org
Template: condor/daemons
Type: multiselect
Choices-C: SCHEDD, STARTD, COLLECTOR:NEGOTIATOR
__Choices: Job submission, Job execution, Central manager
Default: SCHEDD, STARTD
_Description: Role of this machine in the Condor pool:
Please specify the intended role or roles of this machine, for which the
corresponding daemons will be started automatically.
.
A machine in a Condor pool can have multiple roles. In general there is one
central manager and multiple nodes that run jobs. Often the central manager
is also the machine from which users submit jobs. However, it is also
possible to have multiple machines available for job submission.
Template: condor/admin
Type: string
Default: root@localhost
_Description: Email address of the local Condor administrator:
The condor administrator will receive error messages if something goes wrong
with Condor on this machine.
Template: condor/uiddomain
Type: string
_Description: user directory domain label:
This label is a string that Condor uses to decide if a submitting
machine and an execute machine share the same directory of user accounts
(that is, whether UID 1000 on one machine is the same person as UID 1000
on the other). If the labels on the two machines match, Condor will run
each job under the UID that submitted the job, and send emails about
them to user@DOMAIN (using this label as the value of DOMAIN). If not,
Condor will run all jobs as user "nobody". Leaving it blank will cause
Condor to run all jobs on this machine as user "nobody".
.
Any domain format supported by Condor can be used, including macro
expressions. Example: $(FULL_HOSTNAME)
Template: condor/filesystemdomain
Type: string
_Description: File system domain label:
This label is an arbitrary string that is used to decide if a submitting
machine and an execute machine share the same file system. In a dedicated
cluster all machines will most likely use a shared file system and hence
should use the same label. If left blank, it will automatically be set to
the fully qualified hostname of the local machine, which will prevent
Condor assuming that any two machines share a file system.
.
Example: my_shared_volume
Template: condor/personal
Type: boolean
Default: true
_Description: Perform a "Personal Condor installation"?
A Personal Condor installation is a fully functional Condor pool on a single
machine. Condor will automatically configure and advertise as many slots as
it detects CPU cores on this machine. Condor daemons will not be available
through external network interfaces.
.
This configuration is not appropriate if this machine is intended to be a
member of a pool.
Template: condor/reservedmemory
Type: string
_Description: Amount of physical memory to withhold from Condor (in MB):
By default, Condor considers all the physical memory of a machine as
available to be used by Condor jobs. If this value is defined,
Condor subtracts it from the amount of memory it advertises as available.
.
Example (to reserve 1 GB): 1024
Template: condor/allowwrite
Type: string
_Description: Machines with write access to this host:
All machines that are to participate in the Condor pool need to be listed
here. This setting can be a plain comma-separated list, a domain with
wildcards, or a macro expression. By default only localhost is allowed to
access Condor daemons on this machine.
.
Example: *.condor-pool.example.org
Template: condor/startpolicy
Type: boolean
Default: false
_Description: Run Condor jobs regardless of other machine activity?
By default Condor only starts jobs when a machine is idle, i.e. no keyboard
activity or CPU load for some time. Moreover, it also suspends jobs whenever
there is console activity and doesn't continue them until the machine becomes
idle again. However, for a dedicated compute node or a Personal Condor
installation it might be desirable to always start jobs as soon as they are
submitted (given that resources are still available), and to run them
continuously regardless of other activity on this machine.
.
If you plan to compose a custom policy it is best to keep Condor's default
here.
Reply to: