This is directory with the Hedeby system installation files. You can find here binaries, installation scripts, libraries, manuals and state files that are used by Installer.

sdm_dist --\
           |
           |-- bin --\
           |         \-- sdmadm
           |         
           |-- util --\
           |          |-- arch
           |          |-- arch_variables
           |          |-- sdmsmf.sh
           |          |-- smf_sdmsvc
           |          |-- supportRc.sh
           |          |
           |          |-- sdmST --\
           |          |           |-- sdm_st
           |          |           \-- st_settings.sh
           |          |
           |          |-- templates --\
           |                          |-- sdm.env.template
           |                          |-- jaas.config.template
           |                          |-- java.policy.template
           |                          |-- sdmsvc
           |                          |-- sdm_template.xml
           |                          |-- sdm_template_masterhost.xml
           |                          |-- start_sh.template
           |                          |-- logging.properties.template
           |                          \-- ge-adapter --\
           |                                           |-- install_execd.conf
           |                                           |-- install_execd.sh
           |                                           |-- uninstall_execd.conf
           |                                           |-- uninstall_execd.sh
           |
           |-- lib --\
           |         |-- ext --\
           |         |         |-- endorsed --\
           |         |         |              \-- *.jar
           |         |         \-- *.jar
           |         |
           |         |-- <PLATFORM_ARCHITECTURE> --\
           |         |                             \-- libplatform.so
           |         |-- sdm-common.jar               
           |         |-- sdm-starter.jar              
           |         |-- sdm-ge-adapter.jar           
           |         |-- sdm-ge-adapter-impl.jar  
           |         |-- sdm-security.jar  
           |         \-- sdm-security-impl.jar
           |
           \-- man --\
                     \-- man1 --\
                                |-- sdmadm.1

Local spool directory has to be specify on the local file system and for each managed host. The localspool directory can be different for each host. In local spool directory information about running componant are stored, but only this which JVMs are on that host, there are also logs from JVMs. This is also place for spooling local data and for security infos like certificates and keystores.

 localSpool --\
              |-- log --\
              |         \-- log files 
              |
              |-- run --\
              |         \-- files with the pids of running components 
              |             on local host
              |
              |-- security --\
              |              |-- ca --\
              |              |        \ (files for Grid Engine CA)
              |              |
              |              |-- deamons --\
              |              |             \-- keystores for JVM`s
              |              |
              |              \-- users --\
              |                          \-- keystores for Hedeby users
              |
              |-- spool --\
              |           \-- cs    spool directory for configuration
              |           \-- ...   spool directories for Hedeby components
              |
              |-- logging.properties
              |
              |
              \-- tmp --\
                        \-- tmp directories for Hedeby components

Inside the JVM configuration it is possible to define the components for this JVM. We have two different types of components:

Example 2.4. Component configuration

<?xml version="1.0" encoding="UTF-8"?>
<global ...>
    <jvm ...>
        <component xsi:type="MultiComponent"
                   name="executor"
                   classname="com.sun.grid.grm....ExecutorImpl">
            <hosts>
                <include>.*</include>
                <exclude>foo.bar</exclude>
            </hosts>
            <config>executor</config>
        </component>
        <component xsi:type="Singleton"
                   name="ge_service"
                   classname="com.sun.grid.grm....GEServiceImpl"
                   host="ge_master">
            <config>ge_service</config>
        </component>
        ...
    </jvm>
    ...
</global>

	This component is a MultiComponent. On each of the hosts of a Hedeby system one instance of the component can exit.
	Each component has a system wide unique name.
	The classname attribute specifies the name of the java class which implements the component. This class must be available in the classpath of the JVMS.
	Not each component will be started on each host. The <hosts> tag defines the hosts where the component will be started. It is possible to include and exclude hosts. The value of the <include> and <exclude> tag can be a java regular expression. The hosts tag is only allowed for MultiComponents.
	Define the path to the configuration of the component With the parameter the component can load the configuration from the config service.
	The component ge_service is a Singleton. It exists only one instance of this component inside of the Hedeby system. The host attribute defines the name of the host where this Singleton is started.

The Configuration Service (CS) is a special component. It is not explicitly defined in a component tag. The Hedeby system detects automatically the JVM which hosts CS. It compares the hostname and the port with the CS URL stored in the preferences. The CS JVM must have a static port.

% sdmadm -s system1 show_configs -f
system  type    host       port   properties
--------------------------------------------
system1 SYSTEM master_host 31006
    spool=/var/spool/hedeby/system1
     dist=/opt/hedeby
     
    <?xml version="1.0" encoding="UTF-8"?>
    <global ...>
    <jvm name="cs_jvm" user="sdm_admin" port="31006">
    </jvm>
    ...
    </global>

	The sdmadm show_config command shows the CS contact information including the hostname of the port of the CS component.
	At the startup of the JVM cs on the master host the Hedeby system automatically dectects that this JVM hosts CS.

The Resource Provider is the main component of the Hedeby system which provides information about resources and processes all information from the managed services. There exists only one Resource Provider in a Hedeby system and it should run in the JVM started as admin user (No root privileges required).

Once the Resource Provider component has been started the command line clients can get information about resources and which resources are assigned to services.

It is necessary to define the following component configurations before the Resource Provider can be started:

A typical component configuration entry in the system configuration file for the Resource Provider looks as follows:

    
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<common:global name="mySystem"
               xmlns:executor="http://hedeby.sunsource.net/hedeby-executor"
               xmlns:reporter="http://hedeby.sunsource.net/hedeby-reporter"
               xmlns:security="http://hedeby.sunsource.net/hedeby-security"
               xmlns:resource_provider="http://hedeby.sunsource.net/hedeby-resource-provider"
               xmlns:common="http://hedeby.sunsource.net/hedeby-common"
               xmlns:ge_adapter="http://hedeby.sunsource.net/hedeby-gridengine-adapter">

    <common:jvm port="0"
                user="root"
                name="rp_vm">
        <common:component xsi:type="common:Singleton"
                          host="foo"
                          autostart="true"
                          classname="com.sun.grid.grm.resource.impl.ResourceProviderImpl"
                          name="resource_provider"
                          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>

        ...
    </common:jvm>
    ...
</common:global>

The Resource Provider component configuration is stored as a component configuration in the config service.

The configuration file is written in XML format. The structure is defined in the xml schema hedeby-resource-provider.xsd.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<common:componentConfig xsi:type="resource_provider:ResourceProviderConfig"
                        xmlns:executor="http://hedeby.sunsource.net/hedeby-executor"
                        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                        xmlns:reporter="http://hedeby.sunsource.net/hedeby-reporter"
                        xmlns:security="http://hedeby.sunsource.net/hedeby-security"
                        xmlns:resource_provider="http://hedeby.sunsource.net/hedeby-resource-provider"
                        xmlns:common="http://hedeby.sunsource.net/hedeby-common"
                        xmlns:ge_adapter="http://hedeby.sunsource.net/hedeby-gridengine-adapter"
    period="60">

    <resource_provider:policies xsi:type="resource_provider:PriorityPolicyManagerConfig"
       defaultPriority="49">
        <resource_provider:priority service="spare_pool"
                                    name="spare_pool_priority">1</resource_provider:priority>
    </resource_provider:policies>    
</common:componentConfig>

	The Resource Provider configuration is special component configuration. the xsi:type attribute defines the real type (must be ResourceProviderConfig for the Resource Provider).
	The polling period at which to reprocess unsatisfied requests. Resource Provider will periodically query the managed Service Containers in search of available resources, until either the needed resources are located, or the Service Container rescinds the resource request.
	The <policies tag defines the configuration for the Policy Engine. Currently only a priority based Policy Engine is defined (xsi:type="resource_provider:PriorityPolicies").
	The <priority> defines the priority of each service. With the priority the urgencies of the services needs are weighted.

Reporter component is a log/monitoring tool for Hedeby.

The role of reporter component is to intercept and gather informations about what is going on in the system. Administrator can sprecify what kinf of data he is interested in. Right now reporter is able to store informations and notifications that comes from Configuration Service, Resource Provider and all services that are installed in the system.

The reporter component is prepared to store data in arco data base. By prepared we mean that, there is a special arco format file created, that stores suitable for Arco data.

The data from Arco file arent so much readable for normal user, thats why Administrator can get and print out on the screen data using CLI commands. The data can be filtered using avaiable filters.

The Reporter component configuration is stored as a component configuration in the config service. The path to the configuration is defined in the <config> tag of the component definition.

The configuration file is written in XML format. The structure is defined in the xml schema hedeby-reporter.xsd.

<?xml version="1.0" encoding="UTF-8"?>
<reporter:reporter 
    xmlns:reporter="http://hedeby.sunsource.net/hedeby-reporter" 
    xmlns:common="http://hedeby.sunsource.net/hedeby-common" 
    filePattern="report-%g.log"
    fileCount="4"
    fileSize="5242880"/>                 
                
               

A Grid Engine service in Hedeby is defined over an entry in the global configuration. Normally it is not necessary to modify this configuration. It is automatically created with the sdmadm add_ge_service. The following samples shows a typical definition of a Grid Engine Service.

Example 2.8. Example for Hedeby service system component configuration

<?xml version="1.0" encoding="UTF-8"?>
<global name="new_hedeby_system"
        xmlns='http://hedeby.sunsource.net/hedeby-common'
        xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
    ...
    <jvm name="ge_jvm" user="grm_admin" port="0">
        <component name="ge_service" 
                   classname="com.sun.grid.grm.service.impl.ge.GEServiceImpl">
            <classpath>
                <pathelement>${GRM_DIST}/lib/sdm-ge-adapter.jar/>
            </classpath>
            <hosts>
                <include>master_host</include>
            </hosts>
            <config>ge_service</config>
        </component>
    </jvm>
    ...
</global>

	Name of the class which implements the service. In the case of the Grid Engine service this is always com.sun.grid.grm.service.impl.ge.GEServiceImpl.
	Necessary classpath for loading the service implementation. The Grid Engine Service needs also jgdi.jar in the classpath. It will be loaded in a extra classloader since it depends on SGE_ROOT (defined in the GEServiceConfig).
	Defines the name of the host where the GE service will run. Normally a service component is only started on one host. A Grid Engine service component runs normally on the host where qmaster is installed.

As all other configurations Grid Engine Service configuration is defined in an xml structure. It can be modified with the sdmadm modify_component -c <component name> command. This command opens the configuration in an editor. The following section describes the configuration of a GEAdapter:

<?xml version="1.0" encoding="UTF-8"?>

<componentConfig xsi:type="ge:GEServiceConfig"
                    xmlns='http://hedeby.sunsource.net/hedeby-common'
                    xmlns:ge='http://hedeby.sunsource.net/hedeby-gridengine-adapter'
                    xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
    
    <slos>
        ...
    </slos>
    
    <ge:connection clusterName="ge"
                   root="/opt/sge" cell="default"
                   masterPort="31002" execdPort="31003" jmxPort="23011" 
                   username="sge_admin" password="secret"
                   keystore="/var/sgeCA/port31002/default/userkeys/sge_admin/keystore"/>
    
    <ge:sloUpdateInterval unit="minutes" value="5"/>
    
    <ge_adapter:jobSuspendPolicy
           suspendMethods="reschedule_jobs_in_rerun_queue
                           reschedule_restartable_jobs
                           suspend_jobs_with_checkpoint">
        <ge_adapter:timeout unit="minutes" value="2"/>
    </ge_adapter:jobSuspendPolicy>
    
    <ge:qmasterReconnectInterval unit="seconds" value="2"/>
    <ge:execdStartupTimeout unit="seconds" value="60"/>
    <ge:execdShutdownTimeout unit="seconds" value="60"/>
    
    <ge:staticHosts>
        <include>foo.bar</include>
    </ge:staticHosts>
    
    
    <!-- Configuration for Solaris execds -->
    <ge:execd adminHost="true"
              submitHost="false" cleanupDefault="false" rcScript="false"
              ignoreFQDN="false" defaultDomain="foo.bar">

       <ge:filter>operatingSystemName = "SunOs" | operatingSystemName = "Solaris" </ge:filter>

       <ge:localSpoolDir>/export/home/sge/execd</ge:localSpoolDir>
       
       <ge_adapter:installTemplate executeOn="exec_host">
            >ge_adapter:maxRuntime value="2" unit="minutes"/>
            <ge_adapter:script>/opt/hedeby/grm_util/templates/ge-adapter/install_execd.sh</ge_adapter:script>
            <ge_adapter:conf>/opt/hedeby/grm_util/templates/ge-adapter/install_execd.conf</ge_adapter:script>
        </ge_adapter:installTemplate>
        <ge_adapter:uninstallTemplate executeOn="exec_host">
            <ge_adapter:script>/opt/hedeby/util/templates/ge-adapter/uninstall_execd.sh</ge_adapter:script>
            <ge_adapter:conf>/opt/hedeby/grm_util/templates/ge-adapter/uninstall_execd.conf</ge_adapter:script>
       </ge_adapter:uninstallTemplate>
       
    <ge:execd>
       
    <-- Default execd install configuration -->
    </ge:execd>
       <ge:localSpoolDir>/usr/local/sge/execd</ge:localSpoolDir>
    <ge:execd mapping="default">

</componentConfig>

	A GEServiceConfiguration is a special component configuration. the <xsi:type> specifies the type. Must be ge:GEServiceConfig for a Grid Engine service.
	In the first section of a GEServiceConfig always defines the list of SLOs (for details see the section called “SLO definition”).
	The <connection> defines the connection parameters to the Grid Engine instance. The following parameters are required: clusterName Name of the cluster. The cluster name for Grid Engine has been introduced with version 6.2. It defines a unique name for the cluster. This parameter is necessary for the execd installation/uninstallation. root Path to root directory of the Grid Engine instance (SGE_ROOT). cell Cell name of the Grid Engine instance (SGE_CELL). masterPort Port where qmaster is listening. Required for installing an execd on a managed host. (SGE_MASTER_PORT). execdPort Port where execd is listening. Required for installing an execd on a managed host. (SGE_EXECD_PORT). jmxPort The Grid Engine Adapter communicates via JMX with qmaster. The jmxPort defines the port where qmasters MBeanServer is listening. username Username for JMX authentication. Must be a valid Grid Engine admin user. password Password for JMX authentication. Storing the password of inside of the GEAdpater configuration is not advisable. If possible a keystore for authentication should be used. keystore Defines the path to the keystore which contains the private key of the admin user. This credential will be used for JMX authentication against qmaster. The keystore can be created with the sge_ca script (included in Grid Engine 6.2 distribution, $SGE_ROOT/util/sgeCA/sge_ca). If the keystore is password protected the credentials can be specified in the password attribute of the connection element.
	The Grid Engine Adapter updates periodially it's SLOs. The sloUpdateInterval defines how often this update is executed. For each update a qstat over the JMX connection is executed. The administrator has to specify the value and the unit of the update interval. Valid values for unit are seconds, minutes and hours.
	Before GEAdapter uninstalls an execd it checks the active jobs on this host. Depending on the job suspend policy configuration it can migrate jobs to different hosts. GEAdapter supports the following jobs suspend methods: reschedule_jobs_in_rerun_queue Any job running in a queue or a queue instance with the rerun flag can be rescheduled. If the reschedule_jobs_in_rerun_queue is specified GEAdapter will reschedule such jobs. reschedule_restartable_jobs Any active job the restart flag (see qstat -j) can be rescheduled. If the reschedule_restartable_jobs is specified GEAdapter will reschedule such jobs. suspend_jobs_with_checkpoint Any active job with an checkpointing environment can be suspended. Grid Engine will automatically reschedule the job on a different execd. If the suspend_jobs_with_checkpoint is specified GEAdapter will suspend jobs with checkpointing environment. If any active job can not be rescheduled or suspended (if a checkpoint environment is defined) the GEAdapter will wait for the end of these jobs. It will wait at least until the timeout of the jobSuspendPolicy occurs.
	If the connection to qmaster breaks down GEAdapter tries periodically a reconnection. The qmasterReconnectInterval parameter defines how ofter the reconnect is executed. The administrator has to specify the value and the unit of the update interval. Valid values for unit are seconds, minutes and hours.
	Whenever GEAdapter installs an execd on a manage host it is waiting for the signal from qmaster that the execd is now running. The execdStartupTimeout element defines how long GEAdapter is waiting for this signal. If this timeout occurs GEAdapter sets the resource into error state.
	Whenever GEAdapter uninstalls an execd from a manage host it is waiting for the signal from qmaster that the execd has been stopped. The execdShutdownTimeout element defines how long GEAdapter will wait for this signal. If this timeout occurs GEAdapter sets the resource into error state.
	In the staticHosts list the administrator defines a list of hosts the Grid Engine Adapter will never give up.
	Defines the parameter for installing/uninstalling an execd on a managed host. The following attributes are defined. adminHost The default value is false. If this attribute is set to true the host will become Grid Engine admin host. If it is set to false the host will only be admin host during the execution of the exec installation script. submitHost If this attibute is set to true assigned host will become Grid Engine submit host. The default value is false. cleanupDefault The default execd installation adds the new host on the Grid Engine side to the @allhost host group and to the all.q cluster queue. If this parameter is set to true GEAdapter will remove this host from the @allhost host group and the all.q cluster queue if after uninstalling the execd. The default value for this attribute is false. rcScript If this parameter is set to true the boot time startup scripts for the execd will be installed/uninstalled for the host. ignoreFQDN If true the execd will ignore the domain names during hostname resolving. If false execd will use the fully qualified domain name. The default value is defaultDomain Name of the default domain of the execd. mapping Name of the used complex to resource property mapping (the section called “Complex to Resource Property Mapping”).
	A Grid Engine Adapter configuration can have serveral execd definitions. The filter element defines which execd settings are used for a specific host. The value of this element must be a valid resource property filter expression (the section called “Filtering”). The order of the execd elements matters. The first element where filter expression against matches against the resource properties of a host resource is used for the exec installation/uninstallation. An execd element without filter element matches against each host resource. Each GEAdapter should have such a element with the default settings at the end of the configuration.
	Defines the local spool directory used for the execd.
	The default installation of an execd is done with the Grid Engine auto install feature. GEAdapter uses some templates and replaces in these templates placesholders with configured values. The Hedeby distribution contains default templates. The administrator can override the pathes in the templates to modify customize installation/uninstallation (Section 2.4.3.3.2, “Execd installation/uninstallation”) . Each template has a script and a configuration. In both files the configured values are replaced. The following templates are available. installTemplate This template is used for creating the script for installing a execd (default script is <dist>/grm_util/templates/ge-adapter/install_execd.sh, default configuration template is <dist>/grm_util/templates/ge-adapter/install_execd.conf). uninstallTemplate This template is used for creating the script for uninstalling a execd (default script is <dist>/grm_util/templates/ge-adapter/uninstall_execd.sh.template, default configuration template is <dist>/grm_util/templates/ge-adapter/uninstall_execd.conf) The executeOn attribute of a install template defines where the scripts generated out of the template will be executed. If executeOn is set to qmaster_host, the script will be executed of the executor component running on Grid Engines qmaster host. If executeOn is set to exec_host, the script will be executed over the executor of the execd host (managed host). In the above example the GEAdapter will create the file install_execd.sh and install_execd.conf in a temporar directory on the managed host. The executor will execute the following command on the managed host: # cd <tmp directory< # ./install_execd.sh install_execd.conf
	With the maxRuntime element the maxiumum runtime of the execd installation or uninstalltion will be limited. If the installation script does not finish within this time it will be interrupted.

SLO definition

<?xml version="1.0" encoding="UTF-8"?>

<componentConfig ...>
    <slos>
        <slo name="<name of SLO>"
             xsi:type="<type of SLO>"
             urgency="13"
             ...>
             <resourceFilter>
                 hardwareCpuArchitecture = "amd64" & operatingSystemName = "Solaris"
             </resourceFilter>
             ...
        </slo>
    </slos>
</componentConfig>

	Each SLO has a service wide unique name.
	Concrete type of the SLO. Valid values for a Grid Engine Adapater are MinResourceSLOConfig, FixedUsageSLOConfig and MaxPendingJobsSLOConfig.
	Depending on the SLO type additional attributes can follow.
	Urgency of this SLO. The urgency is a number between 0 and 99. Each resources which is required by this SLO has a usage which is more or equals to the urgency of the SLO (see also Section 1.1.2.7, “Resource Usage”).
	The request element defines the concrete resource which request once the SLO is not met. The request defines the required properties of a resource to full fill this SLO.
	Depending on the SLO type additional elements can follow.

MinResourceSLO

The MinResourceSLO counts the number of assigned resources of a service which matches to a resource filter. This SLO ensure that the number these resources is not less then the defined minimum.

It further defines that all required resources for this SLO has the at least an usage which is equal or higher then the urgency of the SLO.

<?xml version="1.0" encoding="UTF-8"?>

<componentConfig ...>
    <slos>
        <slo name="minHostResourceSample"
             xsi:type="MinHostResourceSLOConfig"
             urgency="13"
             min="20">
             <request>...</request>
             <resourceFilter>
             <![CDATA[
                 hardwareCpuArchitecture = "amd64" & 
                 operatingSystemName ="Solaris"
             ]]>
             </resourceFilter>
        </slo>
    </slos>
</componentConfig>

	The concrete type is MinResourceSLOConfig.
	The min attribute defines the minimum number of matching resource for a met SLO.
	The MinResourceSLO allows a resourceFilter. This filter defines set of resources which a considered by this SLO. The fiter is applied against the properties if the assigned resource (assigned to the service, see also the section called “Filtering”).

PermanentRequestSLO

The PermanentRequestSLO sends permanent requests, a need for a resource. This SLO is mainly used in spare pools components to gather unused resources. Typicaly it has the lovest urgency set.

It is also possible to define an urgency and resource type that is wanted by the service which is using this SLO.

    <?xml version="1.0" encoding="UTF-8"?>
    
    <common:slos>
        <common:slo xsi:type="common:PermanentRequestSLOConfig
                    urgency="1" 
                    name="PermanentRequestSLO">
            <common:request>type = "host"</common:request>
        </common:slo>
    </common:slos>

	The concrete type is PermanentRequestSLOConfig.
	The urgency parameter defines the urgency for the needs sent by this service
	This element defines the properties that describes a need which is sent by this service. It could be resource type host for example.

FixedUsageSLO

The FixedUsageSLO is a special SLO. It never produces any need. It only ensures the all assigned resources of the service which matches the resourceFilter of this SLO has a usage which is equal or higher then the urgency of the SLO.

<?xml version="1.0" encoding="UTF-8"?>

<componentConfig ...>
    <slos>
        <slo name="fixUsageSample"
             xsi:type="FixedUsageSLOConfig"
             urgency="13">
             <resourceFilter>
             <![CDATA[
                 hardwareCpuArchitecture = "amd64" & 
                 operatingSystemName = "Solaris"
             ]]>
             </resourceFilter>
        </slo>
        ...
    </slos>
    ...
</componentConfig>

	The concrete type is FixedUsageSLOConfig.
	All resources which matches this resourceFilter are considered by the SLO. (the section called “Filtering”)

MaxPendingJobsSLO

The MaxPendingJobsSLO counts the number of pending jobs of a Grid Engine instance which matches a job filter. If the number of jobs is higher then a maximum value a need is produced.

Each host resource which matches the request filter and which runs jobs matching to the job filter will have at least the usage of the MaxPendingJobsSLO.

<?xml version="1.0" encoding="UTF-8"?>

<componentConfig xmlns:ge="http://hedeby.sunsource.net/hedeby-gridengine-adapter"
    ...>
    <slos>
        <slo name="maxPendingJobs"
             xsi:type="ge:MaxPendingJobsSLOConfig"
             urgency="13"
             max="100">
             <resourceFilter>
             <![CDATA[
                 hardwareCpuArchitecture="amd64" & 
                 operatingSystemName="Solaris"
             ]]>
             </resourceFilter>
             <ge:jobFilter> license_1 = "1"</ge:jobFilter>
        </slo>
        ...
    </slos>
    ...
</componentConfig>

	The concrete type is ge:MaxPendingJobsSLOConfig. The configuration of this SLO is defined in a different xml namespace (xmlns:ge="http://hedeby.sunsource.net/hedeby-gridengine-adapter"). The type of the configuration must have a namespace prefix. All elements which are specific to the MaxPendingJobsSLO must also have the prefix.
	If the MaxPendingJobsSLO detects that the cluster has more pending jobs as defined in attribute max it produces a need. The properties of the needed resources are defined in the request element.
	All resources which matches this jobFilter are considered by the SLO. (the section called “Filtering”) The jobFilter allows filtering of pending jobs according to the hard resource requests.

   filter:         orExpr <EOF>
   orExpr:         andExpr ("|" andExpr)*
   andExpr:        expr ("&" expr)*
   expr:           "(" orExpr ")" | "!" orExpr | booleanExpr
   booleanExpr:    compareExpr | matchEpr
   compareExpr:    value ( "<"|"<="|"="|"!="|">="|">" ) value
   matchExpr:      "matches" stringLiteral
   value:          identifier | constant   
   constant:       int_literal | float_literal | string_literal | bool_literal | null_literal
   identifier:     ["a"-"z","A"-"Z","_"] ( ["a"-"z","A"-"Z","_","0"-"9","."] )*  
   int_literal:    integer literal (e.g. 10, 1G, 1g, xFF)
   float_literal:  floating point literal as in java (e.g. 12.0E3G)
   string_literal: string literal as in java (e.g. "a")
   bool_literal:   "true" | "false"
   null_literal:   "null"
    

"a" matches "[a-z]*" => true

% qstat -j 22377
==============================================================
job_number:                 22377
exec_file:                  job_scripts/8
...
hard resource_list:         arch=sol-sparc64, num_proc=2, lic=1
...
               

                   
arch = "sol-amd64" & lic = "1"

               

                   
arch matches "sol-.*"

               

                   
(hardwareCpuArchitecture = amd64 & hardwareCpuCount >= 2)  |
(hardwareCpuArchitecture = sol-sparc64 & hardwareCpuCount >= 4)

               

                   
state != "ERRROR"
                   
               

Complex to Resource Property Mapping

GEAdpater automatically updates the properties of the assigned host resource. With the "Complex to Resource Property Mapping" the administrator can define what complex values are used. After the installation of the first Grid Engine Service the default mapping is installed. It can be displayed with the sdmadm show_ge_complex_mapping command.

For a complex mapping the administrator has to define the name of the complex the value of the complex and the list of resource property which will be used.

<ge:mapping>
    <ge:resource>
        <source name="arch">sol-sparc64</source>
        <target>
            <property name="hardwareCpuArchitecture">sparcv9</property>
            <property name="operatingSystemName">Solaris</property>
        </target>
    </resource>
    <ge:resource>
        <source name="num_procs">*</source>
        <target>
            <property name="hardwareCpuCount">$VALUE</property>
        </target>
    </resource>
</ge:mapping>

	Each host which has the arch complex set to sol-sparc64 is mapped into a host resource with the resource properties hardwareCpuArchitecture=sparcv9, operatingSystemName=Solaris.
	If a host has defined the complex num_proc the value if this complex is transformed into a resource property hardwareCpuCount. The value of the resource property is the same as the value of the complex.

When ever a resource is assigned to a Grid Engine service the Grid Engine Adapter tries to install an exec daemon on the managed host. When ever a resource is removed from an execdaeomon it uninstalls the execd daemon from the managed host. This section describes how install/uninstall is done.

Per default Grid Engine uses Grid Engines auto installation feature to perform an execd installation/uninstallation. The installation is done by executing a install script and with configuration file on the executor of the manged host.

GEAdpater expects the following exit value from the install/uninstall scripts:

The installation script and the configuration file is generated out of templates. The pathes to the templates can be defined in the execd elements of the GEAdapter configuration (see also Example 2.9, “Example for Grid Engine service configuration”). GEAdapter replaces in this templates some placeholder with the installing settings. The following placeholders are used:

BASEDIR=`pwd`
SGE_ROOT="@@@SGE_ROOT@@@"

if [ ! -d "$SGE_ROOT" ]; then
    echo "SGE_ROOT directory $SGE_ROOT does not exists"
    exit 2
fi
if [ ! -f "$SGE_ROOT/inst_sge" ]; then
    echo "inst_sge script in directory $SGE_ROOT not found"
    exit 2
fi

if [ ! -x "$SGE_ROOT/inst_sge" ]; then
    echo "inst_sge script in directory $SGE_ROOT is not executable"
    exit 2
fi

if [ ! -f "$BASEDIR/install_execd.conf" ]; then
    echo "auto config file $BASEDIR/install_execd.conf not found"
    exit 2
fi

cd "$SGE_ROOT"
./inst_sge -x -noremote -auto $BASEDIR/install_execd.conf
res=$?
exit $res

The general overview of Executor component can be found in Section 1.2.1.4, “ Executor ” and Section 1.1.5, “Executor”

The General configuration of Executor component is specified in Java Virtual Machines section For detailed information about specific fields (see Section 2.4.2, “Java Virtual Machines”).

<?xml version="1.0" encoding="UTF-8"?>
<executor:executor 
                 idleTimeout="60"
                 maxPoolSize="10" 
                 corePoolSize="3" 
                 keepFiles="false"
                 xmlns:executor="http://hedeby.sunsource.net/hedeby-executor"
                 xmlns:reporter="http://hedeby.sunsource.net/hedeby-reporter"
                 xmlns:security="http://hedeby.sunsource.net/hedeby-security"
                 xmlns:resource_provider="http://hedeby.sunsource.net/hedeby-resource-provider"
                 xmlns:common="http://hedeby.sunsource.net/hedeby-common"
                 xmlns:ge_adapter="http://hedeby.sunsource.net/hedeby-gridengine-adapter"">                 
   <executor:maxCommandRuntime unit="minutes" value="10"/>
</executor:executor>

	The executor manages a thread pool. Each thread executes and observes a command. The idleTimeout defines how long a thread is kept alive in the thread pool if it is idle.
	Maximum number of threads in the executor thread pool. This parameter limits the number of concurrently executed commands.
	The minimum number of thread in the thread pool. This number of thread is always kept alive, even if they are idle.
	If the keepFiles flag is set the executor does not delete the temporary files of the executed commands. This is helpful for debugging purpose.
	The maxCommandRuntime element allows to limit the maximum runtime of a command executed by this executor. If the runtime is exceeded the executor will interrupt the command. The unit attribute can have the values seconds, minutes or hours. The value attribute specifies the time interval in the given units. The default value is 10 minutes.

    
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<common:global name="mySystem"
               xmlns:executor="http://hedeby.sunsource.net/hedeby-executor"
               xmlns:reporter="http://hedeby.sunsource.net/hedeby-reporter"
               xmlns:security="http://hedeby.sunsource.net/hedeby-security"
               xmlns:resource_provider="http://hedeby.sunsource.net/hedeby-resource-provider"
               xmlns:common="http://hedeby.sunsource.net/hedeby-common"
               xmlns:ge_adapter="http://hedeby.sunsource.net/hedeby-gridengine-adapter">
    <common:jvm port="0"
                user="root"
                name="executor_vm">
        <common:c