| | 32 | Each cluster is can be associated with one specific OS version, middleware version or sites by defining the appropriate include path used by pan compiler to locate templates. This include path is defined in the file {{{cluster.build.properties}}} at the top of each cluster hierarchy ({{{cfg/clusters/}}}''cluster-name''). |
| | 33 | |
| | 34 | This file must contain one line defining the property {{{cluster.pan.includes}}} as a list of space separated hierarchy list. The hierarchy is interpreted as afile pattern relative to the {{{cfg}}} directory (or whatever has been specified for {{{cfg}}} property in file {{{quattor.build.xml}}}). It '''must''' end with {{{*}}}. To specify all sub-directories below a given directory, the pattern {{{**/*}}} must be used. |
| | 35 | |
| | 36 | The include path is processed in the order specified. If a template exists in several hierarchies, the first one found according to the include path order is used. '''Conversely, if a template exists in several directories of a hierarchy, the inclusion order is unspecified.''' |
| | 37 | |
| | 38 | A {{{cluster.build.properties}}} example is : |
| | 39 | {{{ |
| | 40 | cluster.pan.includes=sites/lal/**/* sites/grif/**/* grid/lcg-2.7.0/**/* os/sl305-i386/**/* standard/**/* |
| | 41 | }}} |
| | 42 | |
| | 43 | As reflected by this example, standard templates ({{{grid}}}, {{{os}}} and {{{standard}}}) are generally inserted last into the include path, using this relative order. |
| | 44 | |
| | 45 | By definition, standard templates are generic templates and are easily shared. If one site or cluster really requires a specific version of a template, it can be duplicated in the cluster or site hierarchy. |
| | 46 | |
| | 47 | ''Note : there is no implicit hierarchy included, except {{{clusters/cluster-name}}}. In particular, if you want to use {{{standard}}}, you need to explicitly specify it.'' |
| | 48 | |
| | 49 | === Cluster parameters === |
| | 50 | |
| | 51 | For every cluster, it is possible to customize its configuration in template {{{pro_site_cluster_info.tpl}}}. There '''must be''' one such template per cluster. As a general rule, you need to define the following properties for each cluster (value mentionned are just examples) : |
| | 52 | |
| | 53 | {{{ |
| | 54 | # |
| | 55 | # basic site information |
| | 56 | # |
| | 57 | "/system/cluster/name" = "LCG 2.7.0"; |
| | 58 | "/system/cluster/type" = "batch"; |
| | 59 | "/system/state" = "production"; |
| | 60 | "/system/siterelease" = "SL 3.05"; |
| | 61 | "/system/rootmail" = "grid.support@lal.in2p3.fr"; |
| | 62 | }}} |
| | 63 | |
| | 64 | You can also define variable {{{FILESYSTEM_CONFIG_SITE}}} as an alternative template name containing a filesystem layout for the cluster (or node if this is in a machine profile). For example : |
| | 65 | {{{ |
| | 66 | FILESYSTEM_CONFIG_SITE = "pro_lcg2_system_filesystems"; |
| | 67 | }}} |
| | 68 | |
| | 69 | {{{pro_site_cluster_info.tpl}}} is often used to define the default root password in a cluster. This can be done with the following PAN instructions : |
| | 70 | |
| | 71 | {{{ |
| | 72 | # |
| | 73 | # set root password on machines |
| | 74 | # |
| | 75 | include pro_software_component_accounts; |
| | 76 | "/software/components/accounts/rootpwd" = default("$1$57qRuCXe$NPngMkg4BrPBf5hfJzJh21"); |
| | 77 | "/software/components/accounts/shadowpwd" = true; |
| | 78 | }}} |
| | 79 | |
| | 80 | The encrypted password value must be provided. It can be obtained with the following command : |
| | 81 | {{{ |
| | 82 | openssl passwd -1 my_preferred_password |
| | 83 | }}} |
| | 84 | |
| | 85 | === RPM repositories === |
| | 86 | |
| | 87 | Each machine profile must contain the list of RPM repositories used by the profile (cluster). This is not done in any standard template. This should be done last in the machine profile and you should avoid doing this twice as this is a time consuming operation. |
| | 88 | |
| | 89 | This is generally done by one template and, by convention, this template is located in {{{repository}}} directory of cluster hierarchy. Example of such templates are provided as part of QWG templates. After creating the repository list, the template must call the following 2 functions to check the presence of all RPMs required in one of the repository and purge the profile of all the unneeded information : |
| | 90 | {{{ |
| | 91 | # |
| | 92 | # Standard stuff: resolve repository and purge not used entries |
| | 93 | # |
| | 94 | "/software/packages" = resolve_pkg_rep(value("/software/repositories")); |
| | 95 | "/software/repositories" = purge_rep_list(value("/software/packages")); |
| | 96 | }}} |
| | 97 | |
| | 106 | All the template processing needed to build machine profiles is done with {{{ant}}} tools, a Java based equivalent of {{{make}}}. {{{ant}}} brings the advantage of platform independance, allowing to do Quattor management tasks on any platform (Unix, Windows, MacOS). |
| | 107 | |
| | 108 | Specific management tasks (called {{{targets}}}) are passed as a parameter to {{{ant}}} command, in much the same way this is done with {{{make}}}. There are 3 main targets for managing Quattor (other targets are used internally by {{{ant}}}) : |
| | 109 | |
| | 110 | * {{{compile.all}}} : this task recompiles all the machine profiles affected by template changes. This is the default if no target is specified. |
| | 111 | * {{{deploy}}} : this task deploys the new machine profiles on the Quattor server. This can occurs only after successful compilation of all clusters. |
| | 112 | * {{{update.rep.templates}}} : this task updates templates describing RPM repositories contents by scanning each repository associated directory. |
| | 113 | |
| | 114 | |
