Difference between revisions of "Fedcloud-tf:WorkGroups:Contextualisation"
Line 115: | Line 115: | ||
== Contextualization at the VMs == | == Contextualization at the VMs == | ||
The proposed mixin does not impose any format on the data, thus the VM image creators are free to use this blob as it suites their needs. This task force recommends the use of [https://help.ubuntu.com/community/CloudInit | The proposed mixin does not impose any format on the data, thus the VM image creators are free to use this blob as it suites their needs. This task force recommends the use of [https://help.ubuntu.com/community/CloudInit cloud-init] for handling the data. | ||
=== Using cloud-init === | |||
[https://help.ubuntu.com/community/CloudInit Cloud-init] frees the user from managing the specific ways for handling the contextualization information. Latest versions are supported in debian and redhat based distributions and are able to deal with OpenNebula contextualization mechanisms (EC2/OpenStack was supported since previous versions). | |||
'''PACKAGES IN PREPARATION!''' | |||
=== Contextualization without cloud-init === | |||
==== OpenStack ==== | |||
OpenStack provides the user provided data at the meta-data server available at <tt>http://169.254.169.254</tt> for every instance. | |||
With the EC2 API, user data is available at <tt>http://169.254.169.254/latest/user-data</tt>, it can be fetched with curl: | |||
<pre> | |||
curl http://169.254.169.254/latest/user-data | |||
</pre> | |||
OpenStack API provides the same data at <tt>http://169.254.169.254/openstack/latest/user_data</tt>. | |||
Public keys are available at <tt>http://169.254.169.254/latest/meta-data/public-keys</tt> for EC2 API or <tt>http://169.254.169.254/openstack/latest/meta_data.json</tt>. | |||
For getting OpenSSH key with EC2: | |||
<pre> | |||
curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key | |||
ssh-rsa [...]== xxx@cloud | |||
<pre> | |||
OpenStack API returns a json dictionary with a "public_keys" dictionary inside, where the available keys are stored: | |||
<pre> | |||
curl http://169.254.169.254/openstack/latest/meta_data.json | |||
{... "public_keys": {"enolkey": "ssh-rsa [...]== xxx@cloud\n"}...} | |||
</pre> | |||
See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html and http://docs.openstack.org/user-guide/content/user-data.html for more info. | |||
==== OpenNebula ==== | |||
OpenNebula provides a iso filesystem at <tt>/dev/sr0</tt> where a <tt>context.sh</tt> file contains all the context variables declared in the OpenNebula template. | |||
The <tt>USER_DATA</tt> contains a base64 enconded blob (can be decoded with <tt>base64 -d</tt>) with the data provided by the user with the OCCI client. The <tt>SSH_PUBLIC_KEYS</tt> contain the user public keys. | |||
For using this context just mount the filesystem and source the context file: | |||
<pre> | |||
$ mount -o ro /dev/sr0 /mnt/ | |||
$ cat /mnt/context.sh | |||
# Context variables generated by OpenNebula | |||
DISK_ID='1' | |||
ETH0_BROADCAST='193.144.35.127' | |||
ETH0_DNS='193.144.34.209' | |||
ETH0_GATEWAY='193.144.35.1' | |||
ETH0_IP='193.144.35.111' | |||
ETH0_MASK='255.255.255.128' | |||
ETH0_NETWORK='193.144.35.128' | |||
SSH_PUBLIC_KEY='ssh-rsa [...]== xxx@cloud' | |||
TARGET='hdd' | |||
TYPE='CDROM' | |||
USER_DATA='VGhpcyBpcyBteSB1c2VyIGRhdGEK' | |||
$ . /mnt/context.sh | |||
$ echo $SSH_PUBLIC_KEY | |||
ssh-rsa [...]== xxx@cloud | |||
$ echo $USER_DATA | base64 -d | |||
This is my user data | |||
</pre> | |||
See http://opennebula.org/documentation:archives:rel3.8:cong for more information. |
Revision as of 09:57, 12 November 2013
Main | Roadmap and Innovation | Technology | For Users | For Resource Providers | Media |
Leader: Enol Fernandez
Scope
This workgroup deals with the VM contextualization open issues, namely being able to pass user-defined data to the VM.
Roadmap
- Evaluate mechanisms available in the cloud middleware to provide user-defined data
- Evaluate possible OCCI extensions to pass user-defined data
- Evaluate CIMI as alternative API (already includes user-data features)
- Track implementation of OCCI extensions/CIMI on the cloud middleware
Cloud middleware support
OpenStack
OpenStack provides a meta-data server that provides instance-specific data. Instances can access the metadata service at http://169.254.169.254 using two different interfaces: one EC2-compatible and a proprietary Openstack interface.
The meta-data server provides the user public ssh-keys if included in the VM request and a user_data field that can be used freely by the user. cloud-init uses this field to contextualize machines.
OpenStack also allows file injection into the VM instance. These files can also be used for passing user-defined information to the running instance.
OpenNebula
OpenNebula provides contextualization information through an ISO image that is available in the VM instance. The contents of the ISO image include a context.sh file where a set of variables are defined. The contents of the context.sh are defined in the VM template.
A EC2-compatible meta-data server is also available at https://bitbucket.org/ricardoduarte/opennebula-metadata. It needs to be tested.
Stratuslab
StratusLab supports CloudInit, HEPiX and OpenNebula contextualization.
For HEPiX and OpenNebula contextualization, an ISO CDROM is attached to the VM that supports the file layout for both systems.
CloudInit contextualization handles web-server and disk based contextualization. StratusLab supports the second one. CloudInit only supports disks formatted as VFAT file systems at the moment. More information can be found at CloudInit in StratusLab documentation
Currently, the OpenNebula contextualization is the default. In the upcoming releases, the default will become CloudInit. All three methods for contextualization will be supported for the foreseeable future.
Okeanos/Synefo
Okeanos uses OpenStack API, in particular it supports the file-injection via http://docs.openstack.org/api/openstack-compute/2/content/Server_Personality-d1e2543.html
OCCI extension
OCCI does not include support for passing user-provided data to the instances.
We have identified as a requirement to contextualize images the possibility of passing user provided data to the VM when they are instantiated. Hence there are two things to be defined:
- how to pass data upon VM creation
- how to retrieve those data from the running VM
For passing the data we propose the use of a new mixin that has an attribute to hold the data to pass to the image. We have a working modification of the OCCI-OS implementation that uses such mixin at https://github.com/enolfc/occi-os/tree/occi_user_data. In this case we have defined a mixin:
Category: user_data; scheme="http://schemas.openstack.org/compute/instance#"; class="mixin"
and
org.openstack.compute.user_data
as attribute (base64 encoded), that uses the user_data field of the OpenStack API.
We think a similar mixin could be added to OCCI to allow interoperability between resource providers.
The second part, related to retrieving the data, is more dependent of the back-end implementation. We have identified 3 different methods in the systems in place in FedCloud: - a metadata server (a la EC2), that located in a known URI servers the user-data - attach of an iso image to the VM that can be mounted - injection of a file with the user-data
All of those methods should be allowed and the VM once created should try them in order (the least invasive seems the metadata server, in our tests the file injection may fail with some VM images)
We think that the exact type and format of the data is not relevant. There could be specialized mixins to indicate explicitly that the data conforms to a executable script or to Cloud-init, but free-format data should also be allowed (for example at IFCA we have developed a system to contextualize just passing a JSON dictionary)
CIMI
We have deployed an instance of OpenStack for testing the CIMI implementation from this blueprint. A simple modification adds the support for the `userData` parameter in machine creation.
Sample code for the request (python code with requests package):
headers = {'content-type': 'application/json', 'accept': 'application/json', 'X-Auth-Token': keystone_token} img_body = { 'name': 'cimi-test-server', 'description': 'no desc', 'machineTemplate': { 'machineImage': {'href': image_id}, 'machineConfig': {'href': conf_id}, 'userData': base64.b64encode('this is just a test'), } } r = requests.post(cimi_url + '/machineCollection', headers=headers, data=json.dumps(img_body))
Implementation status
Latest OCCI-OS and rOCCI server implementations support the
Category: user_data; scheme="http://schemas.openstack.org/compute/instance#"; class="mixin"
mixin with the
org.openstack.compute.user_data
attribute. These versions are being gradually deployed at the testbed.
Injection of keys is also possible using the OCCI client using it like this:
occi -e <https://yourendpoint.com:3202/> --auth x509 --user-cred $X509_USER_PROXY --voms \ --action create --resource compute --attributes title="<ContextVM>" \ --mixin <os_tpl#someos> --mixin <resource_tpl#res> \ --context user_data="file://</path/to/file>",public_key="file://</path/to/publickey>"
Contextualization at the VMs
The proposed mixin does not impose any format on the data, thus the VM image creators are free to use this blob as it suites their needs. This task force recommends the use of cloud-init for handling the data.
Using cloud-init
Cloud-init frees the user from managing the specific ways for handling the contextualization information. Latest versions are supported in debian and redhat based distributions and are able to deal with OpenNebula contextualization mechanisms (EC2/OpenStack was supported since previous versions).
PACKAGES IN PREPARATION!
Contextualization without cloud-init
OpenStack
OpenStack provides the user provided data at the meta-data server available at http://169.254.169.254 for every instance. With the EC2 API, user data is available at http://169.254.169.254/latest/user-data, it can be fetched with curl:
curl http://169.254.169.254/latest/user-data
OpenStack API provides the same data at http://169.254.169.254/openstack/latest/user_data.
Public keys are available at http://169.254.169.254/latest/meta-data/public-keys for EC2 API or http://169.254.169.254/openstack/latest/meta_data.json.
For getting OpenSSH key with EC2:
curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key ssh-rsa [...]== xxx@cloud <pre> OpenStack API returns a json dictionary with a "public_keys" dictionary inside, where the available keys are stored: <pre> curl http://169.254.169.254/openstack/latest/meta_data.json {... "public_keys": {"enolkey": "ssh-rsa [...]== xxx@cloud\n"}...}
See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html and http://docs.openstack.org/user-guide/content/user-data.html for more info.
OpenNebula
OpenNebula provides a iso filesystem at /dev/sr0 where a context.sh file contains all the context variables declared in the OpenNebula template. The USER_DATA contains a base64 enconded blob (can be decoded with base64 -d) with the data provided by the user with the OCCI client. The SSH_PUBLIC_KEYS contain the user public keys.
For using this context just mount the filesystem and source the context file:
$ mount -o ro /dev/sr0 /mnt/ $ cat /mnt/context.sh # Context variables generated by OpenNebula DISK_ID='1' ETH0_BROADCAST='193.144.35.127' ETH0_DNS='193.144.34.209' ETH0_GATEWAY='193.144.35.1' ETH0_IP='193.144.35.111' ETH0_MASK='255.255.255.128' ETH0_NETWORK='193.144.35.128' SSH_PUBLIC_KEY='ssh-rsa [...]== xxx@cloud' TARGET='hdd' TYPE='CDROM' USER_DATA='VGhpcyBpcyBteSB1c2VyIGRhdGEK' $ . /mnt/context.sh $ echo $SSH_PUBLIC_KEY ssh-rsa [...]== xxx@cloud $ echo $USER_DATA | base64 -d This is my user data
See http://opennebula.org/documentation:archives:rel3.8:cong for more information.