Difference between revisions of "Checkdeps"

From PDP/Grid Wiki
Jump to navigationJump to search
 
Line 1: Line 1:
Checkdeps is a tool from the Quattor suite that allows to verify that all package dependencies are satisfied before deploying a new profile. This tool is particularly convenient when preparing the initial installation of a new distribution or middleware type, which typically requires numerous iterations before all dependencies are satisfied. Since every iteration consists of the following steps:
+
Checkdeps is a tool from the Quattor suite that allows to verify that all package dependencies are satisfied before deploying a new profile on the node. This tool is particularly useful when preparing the initial installation of a new OS distribution or type of middleware, which typically requires numerous attmepts before all dependencies are satisfied. Every attempt consists of the following steps:
 
   change templates -> compile -> deploy to node -> SPMA verifies dependencies -> failure, please try again
 
   change templates -> compile -> deploy to node -> SPMA verifies dependencies -> failure, please try again
it is an expensive process to go through and it is certainly not fun! Using checkdeps, the workflow is:
+
This is a boring and slow process to go through and it is certainly not fun!  
 +
 
 +
Using checkdeps, the steps are:
 
   change templates -> compile -> checkdeps verifies dependencies
 
   change templates -> compile -> checkdeps verifies dependencies
 
This worklow not only contains fewer steps, checkdeps can even suggest which lines of Pan code to add to resolve failing depencies (but please, do not discard brain when checkdeps makes suggestions!).
 
This worklow not only contains fewer steps, checkdeps can even suggest which lines of Pan code to add to resolve failing depencies (but please, do not discard brain when checkdeps makes suggestions!).
Line 8: Line 10:
  
  
Server
+
== Server ==
  
 
The server is the host holding the software repositories. Currently, this is also the Quattor server stal.
 
The server is the host holding the software repositories. Currently, this is also the Quattor server stal.
Line 26: Line 28:
  
  
Client
+
== Client ==
  
 
If the server has been prepared, the client can be configured with the file $HOME/.quattor/checkdeps.conf:
 
If the server has been prepared, the client can be configured with the file $HOME/.quattor/checkdeps.conf:
Line 37: Line 39:
 
  match=*.nikhef.nl.xml
 
  match=*.nikhef.nl.xml
 
  match=*.xml
 
  match=*.xml
 
+
 
  [yum]
 
  [yum]
 
  root=/tmp/ronalds/yumroot
 
  root=/tmp/ronalds/yumroot

Revision as of 20:49, 27 November 2009

Checkdeps is a tool from the Quattor suite that allows to verify that all package dependencies are satisfied before deploying a new profile on the node. This tool is particularly useful when preparing the initial installation of a new OS distribution or type of middleware, which typically requires numerous attmepts before all dependencies are satisfied. Every attempt consists of the following steps:

 change templates -> compile -> deploy to node -> SPMA verifies dependencies -> failure, please try again

This is a boring and slow process to go through and it is certainly not fun!

Using checkdeps, the steps are:

 change templates -> compile -> checkdeps verifies dependencies

This worklow not only contains fewer steps, checkdeps can even suggest which lines of Pan code to add to resolve failing depencies (but please, do not discard brain when checkdeps makes suggestions!).

Checkdeps does all magic via calls to the Yum API. That requires Yum repositories on the repository server. The next section describes how to set these up.


Server

The server is the host holding the software repositories. Currently, this is also the Quattor server stal.

All software repositories that can be used by the templates in the configuration database have to prepared so that yum can use them. To create a yum repository in directory /my/repo, execute

 createrepo /my/repo

This will create a new directory /my/repo/repodata which contains the repository contents.

When new packages are added to the repositories, the repository metadata should be updated. That can be done via createrepo --update (only processing the changes) or createrepo -C (rebuilding if anything changed).

We use ~30 repositories, so the update task has been automated:

  • the configuration file /project/quattor/etc/ndpf-yum-repos contains a list of directories that should be updated; 1 directory per line
  • the script /project/quattor/bin/make-yum-repos reads the above configuration file and creates the repositories if needed (using option -C for createrepo).
  • a cron job /etc/cron.d/make-yum-repos runs the above script once per hour in quiet mode

Note: the CentOS distributions already provide repository metadata, but in a different directory than checkdeps would expect. The latter expects to find directory repodata in the directory containing the rpms, whereas the distribution provides it one level higher in the file system hierarchy. Recreating the metadata is time consuming because of the large number of packages, so symlinks have been created in the rpms directory.


Client

If the server has been prepared, the client can be configured with the file $HOME/.quattor/checkdeps.conf:

[config]
generate_repos=False
output_pan=False
debug_level=0
profile_dir=/home/ronalds/src/ndpf-scdb/conf/build/xml
match=*.nikhef.nl.xml
match=*.xml

[yum]
root=/tmp/ronalds/yumroot

Notes:

  • The client needs access to the software repositories. At Nikhef, access to the the management network is required. In practise, that means a VPN tunnel or using the client from stal (either as ordinary user or ndpfmgr).
  • The client code has only been tested at linux clients.
  • The field root point to a local working directory. Ensure that this directory exists before running checkdeps and create it on the local machine, not on an NFS mount (unless you've got plenty of time).

Then run the tool to verify the dependencies. Below is an example of a successful verification of the object tbn17.nikhef.nl:

$ checkdeps -l $L/build/xml -x tbn17.nikhef.nl.xml
checkdeps: 1 profile(s) to check in /user/ronalds/src/ndpf-scdb/conf/build/xml
checkdeps: tbn17.nikhef.nl.xml - starting check
checkdeps: tbn17.nikhef.nl.xml - profile seems OK

The following example shows a missing package and the suggestion that checkdeps gives:

$ checkdeps -l $L/build/xml -x tbn02.nikhef.nl.xml
checkdeps: 1 profile(s) to check in /user/ronalds/src/ndpf-scdb/conf/build/xml
checkdeps: tbn02.nikhef.nl.xml - starting check
checkdeps: tbn02.nikhef.nl.xml - YUM wants to add the following 1 package(s): 

Package                        Version              Arch     Needed by
=================================================================================
apr                            1.2.7-11.el5_3.1     x86_64   apr-util-1.2.7-7.el5_3.2.x86_64


checkdeps: Pan snippet to add missing packages: 

"/software/packages"=pkg_repl("apr","1.2.7-11.el5_3.1","x86_64");

checkdeps: tbn02.nikhef.nl.xml - problem found with profile