rename readme with proper extension
authorPaul Tonelli <paul.tonelli@logilab.fr>
Thu, 21 Mar 2013 14:57:14 +0100
changeset 87 ed84dcff0f2c
parent 86 ce88c3698ff5
child 88 6d331521b68f
rename readme with proper extension
readme.rst
readme.txt
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/readme.rst	Thu Mar 21 14:57:14 2013 +0100
@@ -0,0 +1,169 @@
+
+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.
--- a/readme.txt	Thu Mar 21 14:05:08 2013 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,169 +0,0 @@
-
-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.