Kameleon Page

From WikiOAR

Revision as of 13:20, 14 February 2011 by Neyron (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


This is the Kameleon GSOC 2009 page. Also check the main page here: http://oar.imag.fr/archive/wiki-oar/index.php/Kameleon

See original proposal here


Student, please read carefully this page...


Student: Darko Ilic

Mentor: Yiannis Georgiou

Co-Mentors: Bruno Bzeznik, Yiannis Georgiou, Joseph Emeras


Contents

Student: Things to do before starting

How to start the project

  • 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)

May's 19 Brainstorming

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.
  • ...


Project's specifications

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


Implementation Ideas

http://oar.imag.fr/archive/wiki-oar/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:

Image:spec.png

Directory structure

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
                        |_/...
                  |_/...

The recipe file

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

The macrosteps files

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

Microsteps commands

  • 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 and error handling

  • 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...)

Changelog/todo

  • 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)

Initial Workplan

Roadmap (and Timeline)

TODO list

Mentor

  • Construct the Grid5000 image used for the project
  • 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) ... (Bruno):well, fedora, or even better Scientific Linux, CentOS or Suse

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


Links

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

Videos

Retrieved from "http://oar.imag.fr/archive/wiki-oar/index.php/Kameleon_Page"
Personal tools