• <s>ASAP: get an account on grid5000: https://www.grid5000.fr/mediawiki/index.php/Grid5000:Get_an_account</s>
• Create a valid user report for grid5000 platform

• play with installing and configuring OAR using DEB / RPM packages upon grid5000 image
• start using OAR live CD on laptop or grid5000
• modify script for construction of OAR live CD to support:
  • the fetch of a debian image using debootstrap (for the moment it uses a minimal debian customized image stored locally)
  • the activation of cpusets
  • the automatic detection of resources using the script oar_resources_init and detect_resources that we use for the configuration upon grid5000
• to check the initialization script used in SysrescueCD and see how they choose the keyboard language… it has to continue with a default value after a specific timeout..the same thing for the launch of server X… it could even be used to choose if we want a server or a node…–Ygeorgiou 15:57, 29 April 2009 (UTC)

Meeting between Olivier, Bruno and Yiannis

• Tried to conceptualize the project
• Has to be general enough so that it can be modular and extensible.
• We have to define the different steps of the procedure.
• Initial Idea based on a main Kameleon Engine along with description files composed by Macrosteps and microsteps, with the engine implemented in Ruby and the description files in Yaml.
• The user will be able to provide the MacroStep he wants to start from.
• Each macrostep will be composed by various microsteps.
• We have to anticipate for debugging options.
• The macrosteps and microsteps have to collect the error codes of the commands executed and treat them.
• …

In the context of the latest trends related with 'virtualization', 'cluster in a box' and 'cloud computing' in this project we are interested in providing a tool (named Kameleon) that will be able to construct an OAR iso image or appliance (VMWare, Xen, Grid5000) which will be used for automatic installation and configuration of a virtual OAR cluster. The created iso image/appliance will be useful in various cases like:

• to test/debug OAR latest version or bugfix on your laptop.
• to try and play with OAR resource management system and its features, before actually installing it.
• to create a virtual cluster and use it
• …

The goal of the project is to create the mechanism of the automatic construction of an iso image and appliances with OAR installed. The created iso image/appliance, once it is deployed, it will be able to autoconfigure a virtual cluster according to the initial specifications of the user. We would like to give as input values like:

• distribution (debian lenny, centos 5,…)
• kernel
• output type (iso, cow, tgz,…)
• packages (libraries(openmpi,mpich,…), benchmarks(linpack,nas), …)
• …

and taking as an output the specified type of image ready for installation/autoconfiguration

http://wiki-oar.imag.fr/index.php/Image:WhiteBoardKameleonSnapshot.jpg

According to our Brainstorming we tried to define an implementation description.

• The main Kameleon engine will be programmed in Ruby
• The architecture will be based on Yaml description/configuration files
• The description files will be composed by macrosteps and microsteps

The architecture can look like this:

spec.png

All the configuration files are in a data directory, for example /var/lib/kameleon. We can have:

 /var/lib/kameleon
             |_/recipes
             |     |_/debian-lenny-x86_64-oar-2.4-iso.yaml
             |     |_/centos-5.2-x86_64-oar-2.4-xen.yaml
             |     |_/...
             |_/steps
                   |_/common    #(includes)
                         |_/oar_resources_setup.yaml
                         |_/...
                   |_/debian-lenny-x86_64
                         |_/bootstrap.yaml
                         |_/...
                   |_/...

This file is a configuration file. It has a global part configuring some variables and a steps part listing all the steps (macrosteps composed of microsteps) that have to be executed in the given order. In the global part, some variables are mandatory and others may be custom variables used into microsteps. In the steps part, if no microsteps are given, then it means that all the microsteps are executed in the order they have been defined into the corresponding macrostep file.

Example:

 #/var/lib/kameleon/recipes/debian-lenny-oar-2.4.yaml
 #example of a recipe
 global:
  distrib: debian-lenny-x86_64
  type: iso
  initial_appliance: file://var/tmp/base_debian-lenny.tgz
  workdir_base: /var/tmp/
  distrib-repository: ftp://debian.ftp.fr/deb/
  packages: file://./svn/build-area/
 steps:
  - bootstrap
  - minimal_packages_installation
  - system_configuration
  - oar_install
  - oar_init:
    - config_oar_key
    - stop_host_mysql
    - stop_oar_server
    - start_appliance_mysql
    - init_mysql_db
    - init_oar_db
    - create_oar_resources
    - stop_appliance_mysql
  - kernel_install
  - image_create
  - clean

Example:

 #/var/lib/kameleon/steps/debian-lenny-x86_64/oar_install.yaml
 #macrostep oar_install for debian lenny 64 bits
 oar_install:
  - init_repo:
    - check_cmd:       dpkg-scanpackages
    - exec_chroot:     mkdir -p /var/lib/debs
    - exec_appliance:  cp $$packages/*.deb ./var/lib/debs/
    - exec_appliance:  cd ./var/lib && dpkg-scanpackages debs /dev/null | gzip > debs/Packages.gz
  - config_apt_local:
    - append_file:
      - /etc/apt/sources.lists
      - deb file:/var debs/
    - exec_chroot:     apt-get update -q
  - oar_install:
    - exec_chroot: |
                   DEBIAN_FRONTEND=noninteractive apt-get -q install -y --force-yes oar-server oar-user  oar-node oar-doc oar-admin oar-web-status
                   DEBIAN_FRONTEND=noninteractive apt-get -q install -y --force-yes oar-api || true
  - oar_add_online_repo:
    - append_file:
      - /etc/apt/sources.lists
      - |
        deb http://ftp.fr.debian.org/debian lenny main
        deb http://security.debian.org/ lenny/updates main
        deb http://oar.imag.fr/debian/unstable/2.4/ ./
 #/var/lib/kameleon/steps/common/oar_init.yaml                                                 
  - config_oar_key:                                                                            
    - exec_chroot:      perl -pi -e 's/^/environment="OAR_KEY=1" /' ~oar/.ssh/authorized_keys  
  - stop_host_mysql:                                                                           
    - exec_current: |                                                                          
                    RC=0                                                                       
                    /etc/init.d/mysql status > /dev/null || RC=$?                              
                    if [[|"$RC" = "0" ]]                                                         
                    then
                      /etc/init.d/mysql stop
                      MYSQL_STARTED=1
                    fi
  - init_mysql_db:
    - write_file:
      - /tmp/init.sql
      - |
        CREATE DATABASE IF NOT EXISTS oar;
        CONNECT mysql;
        INSERT INTO user (Host,User,Password) VALUES('localhost','oar',PASSWORD('oar'));
        INSERT INTO user (Host,User,Password) VALUES('%','oar',PASSWORD('oar'));
        INSERT INTO db  (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv, Create_priv,Drop_priv)
          VALUES
          ('localhost','oar','oar','Y','Y','Y','Y','Y','Y');
        INSERT INTO db  (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv, Create_priv,Drop_priv)
          VALUES
          ('%','oar','oar','Y','Y','Y','Y','Y','Y');
        FLUSH PRIVILEGES;
        GRANT ALL ON oar.* TO oar@localhost;
        GRANT ALL ON oar.* TO oar@"%";
        GRANT SELECT ON oar.* TO oarreader@localhost;
        GRANT SELECT ON oar.* TO oarreader@"%";
        FLUSH PRIVILEGES;
    - exec_chroot: mysql < /tmp/init.sql
  - init_oar_db:
    - exec_chroot: |
                   mysql oar < /usr/lib/oar/mysql_structure.sql
                   mysql oar < /usr/lib/oar/mysql_default_admission_rules.sql
                   mysql oar < /usr/lib/oar/default_data.sql || true
  - create_oar_resources:
    - exec_chroot: |
                   oarproperty -a core
                   oarproperty -a cpu
                   oarnodesetting -a -h node1 -p cpu=0 =p core=0
                   oarnodesetting -a -h node1 -p cpu=0 =p core=1
                   oarnodesetting -a -h node1 -p cpu=1 =p core=0
                   oarnodesetting -a -h node1 -p cpu=1 =p core=1
                   oarnodesetting -a -h node2 -p cpu=0 =p core=0
                   oarnodesetting -a -h node2 -p cpu=0 =p core=1
                   oarnodesetting -a -h node2 -p cpu=1 =p core=0
                   oarnodesetting -a -h node2 -p cpu=1 =p core=1
 #/var/lib/kameleon/steps/debian-lenny-x86_64/oar_init.yaml
 oar_init:
  - include: /var/lib/kameleon/steps/common/oar_init.yaml
  - start_appliance_mysql:
    - exec_chroot: /etc/init.d/mysql start
  - stop_oar_server:
    - exec_chroot: |
                   /etc/init.d/oar-server stop || true
                   /etc/init.d/oar-node stop || true
  - stop_appliance_mysql:
    - exec_chroot: sleep 2; /etc/init.d/mysql stop

• Each macrostep will produce a bash script that will be executed
• Each bash script has to store the environment variables somewhere so that the next macrostep can collect them
• Each microstep definition is an array of commands. Each command is a {key ⇒ value} pair. The key is the name of the command, and the value is the argument. It will result in a part of the bash script, automatically generated by the kameleon engine.
• The value may contain macro variables: they start with $$ and are filled by the global section of the recipe file.
• A special macro variable $$workdir gives the path of the temporary directory used for the currently built appliance
• When there's a microstep named include, it means that the content of another file must be inserted

• check_cmd

Raise an error if the specified command does not exist on the host system

• check_appliance_cmd

Raise an error if the specified command does not exist inside a chroot in tha appliance system

• exec_current

Execute the given bash scriptlet on the host system from the current directory (the one from which kameleon has been run)

• exec_appliance

Execute the given bash scriptlet on the host system from the root of the appliance directory

• exec_chroot

Execute the given bash scriptlet inside a chroot of the appliance directory

• append_file

Append a content to a file of the appliance (relative to the root of the appliance). This commands takes an array of 2 elements as an argument: the first element is the name of the file and the second one is the content to be appended to the file.

• write_file

Write a content into a file of the appliance. If the file already exists, erase it. Else, create it. This commands takes an array of 2 elements as an argument: the first element is the name of the file and the second one is the content to be writed into the file.

• set_var

Set up a bash variable that may be used by latter microsteps. The argument is a 2 element array (name of the variable, value of the variable)

• include

Not a microstep command, but may be found in place of a microstep name. It means that the given argument is a name of a file to be included

• …

• Breakpoints

The kameleon engine should provide a way to specify macrostep/microstep breakpoints. For example, the user may want to stop kameleon just before the “oar_init/init_oar_db” step. Similarily, we may want to start at a specified step. For this last feature, it may be necessary to find a way for the user to provide the name of the working directory, maybe given by a previous breakpoint.

• Error handling

We want the engine to raise formated errors when a bash scriptlet crashes, with the name of the macrostep and microstep where the error occured. But, we don't want the engine to execute each scriptlet separatelly and return to ruby between each microstep as it may result in performance drawbacks. The engine should generate a script for each macrostep and execute it as a whole. So, to know from which microstep an error occured, it may be necessary to had some kind of labels inside the generated script, for example a trap between each microstep that will force the script to exit with a given status code corresponding to a microstep (limiting the number of microsteps to 255 per macrosteps, by the way…)

• Not finished…more details will come…–Ygeorgiou 11:03, 20 May 2009 (UTC)
• Details added. Still need to continue examples and definitions of microsteps commands –Bzizou 15:05, 10 June 2009 (UTC)
• YAML examples have been syntax checked with ruby. I hope the specifications are ok for coding the engine now! –Bzizou 14:35, 11 June 2009 (UTC)
• Maybe missing: examples of what scriptlet should produce the microsteps commands (resulting script of the provided oar_install and oar_init examples) –Bzizou 16:20, 11 June 2009 (UTC)

• <s>Construct the Grid5000 image used for the project</s>
• Write a wiki page for explanations on how to configure an OAR cluster upon Grid5000 …the configuration process used upon grid5000 will be quite similar (but simpler) with that used for the case of cluster of liveCDs or appliances…
• check about the lvm partitions used in the case of images with xen
• finish the construction of the lenny-xen image upon Grid5000
  • install OAR upon it
  • configure it to work with lvm partitions
• construct the fedora liveCD from RPMs (first simple construction from Bruno) … <i>(Bruno):well, fedora, or even better Scientific Linux, CentOS or Suse</i>

–Ygeorgiou 15:57, 29 April 2009 (UTC)

• Febootstrap, a debootstrap equivalent for Fedora. http://et.redhat.com/~rjones/febootstrap/ –Bzizou 16:00, 29 April 2009 (UTC)
• rpmstrap, unfortunately no package for lenny?? http://packages.debian.org/etch/rpmstrap –Bzizou 16:00, 29 April 2009 (UTC)
• CenOS bootstraping not very complicated: http://lists.centos.org/pipermail/centos/2005-September/009506.html (I think we should do the same thing, but with patterns in place of the version numbers of each package) –Bzizou 6:10, 30 April 2009 (UTC)
• Rinse PROMISING!!! http://packages.debian.org/fr/sid/rinse Use the sid version (lenny one is broken for centos5 bootstraping) –Bzizou 06:40, 30 April 2009 (UTC)

Note: amd64 for x64_64: rinse –distribution centos-5 –directory ./centos-oar-appliance –arch amd64 –Bzizou 12:33, 30 April 2009 (UTC)

• CAOS Linux a linux distribution specialized for clusters with SLURM or Torque as options for resource management, http://wiki.caoslinux.org/Main_Page and http://wiki.caoslinux.org/Main_Page and an article for its installation : http://www.linux-mag.com/id/7239/2/ –Ygeorgiou 10:04, 16 May 2009 (UTC)
• kpartx: for hdd image creation (Qemu appliance): http://pwet.fr/man/linux/administration_systeme/kpartx –Bzizou 13:51, 19 May 2009 (UTC)
• kiwi: Image system :http://kiwi.berlios.de/
• Fedora appliance tools:https://fedoraproject.org/wiki/Features/ApplianceTools
• Ubuntu JeOS:http://www.ubuntu.com/products/whatisubuntu/serveredition/jeos
• Chef: http://wiki.opscode.com/display/chef/Home –Bzizou 16:45, 6 November 2009 (UTC)
• KVM-NBD: http://wiki-oar.imag.fr/index.php/Dealing_with_Grub_on_KVM_images –Bzizou 14:22, 10 February 2010 (UTC)

• kameleon video !!! :http://www.youtube.com/watch?v=KMT1FLzEn9I –Ygeorgiou 14:55, 15 May 2009 (UTC)
  • Waou, with such a chameleon, our kameleon should be able to make a mid-debian/mid-centos appliance, it's going to be very hard –Bzizou 10:48, 20 May 2009 (UTC)