readme.txt
author Paul Tonelli <paul.tonelli@logilab.fr>
Fri, 15 Mar 2013 09:43:42 +0100
changeset 79 07d85619353a
parent 77 921005892859
permissions -rw-r--r--
modified syntax to go from salt['grains.present']('...') to grains['...'] whichi is MUCH cleaner and removed use of vriables to have only grains


Objective
=========

Automatically create variations of virtual machines depending
on configuration files availables in repository :

  http://hg.logilab.fr/users/ptonelli/srv_salt/states/

Present state
=============


The first step is to edit/commit/push the file "variation.sls" so that a:

salt-call state.sls variation.sls 

will create the machine you want.

You can also clone the repository and commit to another hg repo at the
condition that this repository can be reached by http / https.

Then, launch an instance of "ami-creation" on openstack. Use at
least 5Gb of disk (add more if your sls file requires more).

In the userdata, copy something like (if you do not put anything, what will be
used will be the latest revision from the default repo):

====== START =======

ami.hg_rev: 249:9ed741a55f17
ami.hg_address: http://hg.logilab.fr/users/ptonelli/srv_salt
ami.name: my_variation 
ami.type: debian #or ubuntu

### optionnal ###
keystone.user: usearname
keystone.password: password
keystone.tenant: tenant
keystone.tenant_id: 00000000000000000000000000000000
keystone.auth_url: 'http://control.example.com:5000/v2.0'
keystone.insecure: False   #(optional)

### only if you know what you are doing ! ###
kernel_id:a5b900bd-c009-40b2-a763-32b32996b1ee
initrd_id:b953e40a-2605-402b-8663-c8556a5899f2

====== END ========

The kernel_id and initrd_id are used to specify the 

you can add an ip to your instance, ssh to the machine and wait until
everything in /mnt is unmounted. you can then upload what you want to glance
with something like (don't forget to change the ids in the last tim or to
include your credentials by downloading and running openrc.sh):

glance add is_public=false disk_format=aki container_format=aki \
name=variation_kernel < kernel_variation

glance add is_public=false disk_format=ari container_format=ari \
name=variation_ramdisk < ramdisk_variation

glance add disk_format=ami container_format=ami name="variation-amd64" \
kernel_id=278de93c-5276-410f-a221-667cc1443cf8 \
ramdisk_id=b953e40a-2605-402b-8663-c8556a5899f2 < /mnt/variation.img


Files
-----

top.sls : top file for the ami_creator

ami_creator.sls : state file to have a correct ami-builder environment

ami_creator_pre.sls : state file applied before the creation of variation

ami_creator_post.sls : state file applied after the creation of variation for
cleanup

variation.sls : variation file (should be modified depending on requirements)

variation.top.sls : top file for the chroot


Additionnal Documentation
========================

what is being done and where :

in /etc/init.d/ec2-run-ami
--------------------------

If the userdata is not a script and is not compressed content, Add the content
of userdata as salt-grains (version and address from repo...)

in /etc/rc.local
----------------

  salt-call state.highstate
  salt-call state.highstate

(doing it twice is necessary to load new states)

  salt-call vm_create.create_variation 

which contains : 

  salt-call state.sls ami_creator_pre

which mounts a debian image and creates all the necessary files inside. Then
update the chroot:

  salt-call vm_create.update_image /mnt/variation

and run your state file (if necessary, modify /etc/salt/srv/variation.sls which
will be executed inside):

  salt-call vm_create.variate_image /mnt/variation

which runs your variation inside the chroot. Finally run

  salt-call state.sls ami_creator_post

which will extract your image kernel and ramdisk and unmount and resize as necessary

  salt-call vm_create.upload to glance

if the correct userdata is available, this sends the kernel, ramdisk and image
to glance using the glance python client.

glance
------

The salt module from glance does not work in debian as ``glanceclient`` package
is only available in experimental and I did not manage to connect to openstack
essex with it.

nova
----

The salt module is working as intended.

Optimal behavior of this project
================================

3 levels of scripting:

Virtual Instance Launcher
-------------------------

(hooked to modifications of HG repository)
NOTHING DONE

Ami Creator
-----------

An image available on openstack / ec2.

At boot, the user must supply a repository address in user data as
``variation_address`` this information is used by salt at boot to download the
correct revision of files.  it then execute salt-call
vm_create.create_variation which will create a complete ami file and upload it
to glance EC2

Chroot Image
------------

this script should only be a salt state file, and must be run using
salt-highstate before packaging of the ami.