cloud-init support in snf-image
75 views
Skip to first unread message
Nikos Skalkotos
Aug 29, 2017, 7:54:17 AM8/29/17
to gan...@googlegroups.com
Hello all,
I'm pleased to announce that snf-image 0.22.x has cloud-init support. In
conjunction with snf-image-creator 0.11.1 you may use this functionality
to create VM's out of official OpenStack images.
In order to accomplish this we had to introduced 2 new OS parameters
(cloud_userdata, inst_properties) and the new image property CLOUD_INIT
which must be set in order for snf-image to perform cloud-init aware
deployment during the instance creation.
The cloud_userdata OS parameter expects a base64 encoded content and may
be used to inject user-data to the instance to be consumed by
cloud-init. The inst_properties OS parameter has the same format as the
img_properties parameter and can be used to overwrite image properties
that get invalidated due to the injected user-data. For example, if you
add user-data to create a new user in the instance, you'll need to
update the USERS image property in order for snf-image to apply the
password to this user. This can be done by direct changing the
img_properties OS parameter in the instance creation command line, but,
in many cases, it's easier to have the img_properties OS parameter
stored in an variant file under /etc/ganeti/snf-image and only update
specific properties using the newly introduced OS parameter.
As an example I'll demonstrate how to use a Debian Stretch openstack
image:
Obtain the original qcow2 image:
# wget
https://cdimage.debian.org/cdimage/openstack/current-9/debian-9-openstack-amd64.qcow2
Create an snf-image friendly image out of it:
# snf-mkimage -o debian-9-openstack-amd64.diskdump
debian-9-openstack-amd64.qcow2
snf-image-creator 0.11.1
========================
Examining source media `debian-9-openstack-amd64.qcow2' ... looks like
an image file
Snapshotting media source ... done
Enabling recovery process ... done
Launching helper VM (may take a while) ... done
Inspecting Operating System ... debian
Collecting image metadata ... Warning: No passworded users found!
done
Running OS inspection:
Checking if the media contains logical volumes (LVM)... no
Preparing system for image creation:
Mounting the media read-write ... done
(1/14) Removing sensitive user data
(2/14) Removing files under /tmp and /var/tmp
(3/14) Disabling predictable network interface naming
(4/14) Clearing local machine ID configuration file
(5/14) Removing swap entry from fstab
(6/14) Cleaning up password & locking all user accounts
(7/14) Removing files under /var/cache
(8/14) Disabling IPv6 privacy extensions
(9/14) Change boot menu timeout to 10 seconds
(10/14) Emptying all files under /var/log
(11/14) Removing persistent network interface names
(12/14) Replacing fstab & grub non-persistent device references
(13/14) Fixing acpid powerdown action
Warning: No acpid event directory found
Umounting the media ... done
(14/14) Shrinking image (may take a while)
Image size is 1232MB
Calculating md5sum ...
4eca65f478faa099ef73ede0042373a7
Dumping image file ... image file debian-9-openstack-amd64.diskdump was
successfully created
Dumping metadata file ... done
Dumping md5sum file ... done
Dumping variant file ... done
cleaning up ...
snf-image-creator exited without errors
The output of this command is 4 files:
# ls -1 debian-9-openstack-amd64.diskdump*
debian-9-openstack-amd64.diskdump
debian-9-openstack-amd64.diskdump.meta
debian-9-openstack-amd64.diskdump.md5sum
debian-9-openstack-amd64.diskdump.variant
The actual image file, the meta file that can be used to register the
image with synnefo, a checksum file and a variant that can be used to
create an snf-image variant:
# cat debian-9-openstack-amd64.diskdump.variant
IMG_FORMAT='diskdump'
IMG_ID='debian-9-openstack-amd64.diskdump'
IMG_PROPERTIES='{"PARTITION_TABLE": "msdos", "KERNEL": "4.9.0-3-amd64",
"OSFAMILY": "linux", "DESCRIPTION": "9.1", "REMOTE_CONNECTION":
"ssh:port=22", "GUI": "No GUI", "BOOTSTRAP": "grub2",
"CLOUD_INIT_DEFAULT_USER": "debian", "SORTORDER": "7700901",
"ROOT_PARTITION": "1", "OS": "debian", "CLOUD_INIT": "yes", "USERS":
"debian"}'
As you can see, snf-image-creator detected that there is a default
cloud-init user defined (CLOUD_INIT_DEFAULT_USER) and is activated by
cloud-init (USERS).
We may then copy the diskdump file to the snf-image IMAGE_DIR location:
# cp debian-9-openstack-amd64.diskdump
/srv/image-test/debian-9-openstack-amd64.diskdump /var/lib/snf-image/
Add the variant file to the variants location:
# cp debian-9-openstack-amd64.diskdump.variant
/etc/ganeti/snf-image/variants/stretch.conf
# echo stretch >> /etc/ganeti/snf-image/variants.list
And then create an instance. For demonstration purposes we'll add those
user-data to be executed at the first boot:
$ cat first_boot.sh
#!/bin/sh
touch /etc/testme
The instance creation command follows:
#gnt-instance add -o snf-image+stretch --os-parameters
img_passwd=just_a_password,auth_keys="$(cat
/home/skalkoto/.ssh/authorized_keys)",cloud_userdata="$(base64 -w 0
/tmp/first_boot.sh)" -t plain --disk 0:size=20G --no-name-check
--no-ip-check -B minmem=2G,maxmem=2G --net 0:ip=pool,network=nat stretch
This command will change the password of user "debian" to
"just_a_password", will inject the keys found under
"/home/skalkoto/.ssh/authorized_keys" in the host system to the
authorized keys file of the "debian" user and will make sure the command
"touch /etc/testme" is executed during the first boot.
Cloud-init userdata can be tricky. If the first line starts with "#!",
they are treated as a script that should run during the first boot. If
it starts with "#cloud-config", they are treated as cloud-init
configuration. You may also specify more complex user-data by providing a
Mime Multi Part Archive. Find more info in the cloud-init Formats
section [1].
Also, some stuff found in the cloud-init documentation [2] may not work
with your image. This documentation is for the latest version. Most
images get shipped with older versions of the software. When we were
working on adding cloud-init support to snf-image, we tried to use a
minimal subset of the mature cloud-init options to make it work for the
vast majority of the images. If you care to learn about how the
cloud-init support was implemented, please consult the corresponding
design doc [3]. As a future work, we are planning to expose this
functionality to synnefo[4] too.
As always, Debian packages for snf-image and snf-image creator can be
found in our apt repo [5]. For more details check the official
documentation of snf-image [6] andsnf-image-creator [7].
On behalf of the GRNET Development Team,
Nikos Skalkotos
[1] https://cloudinit.readthedocs.io/en/latest/topics/format.html
[2] https://cloudinit.readthedocs.io/en/latest/index.html
[3] https://www.synnefo.org/docs/snf-image/latest/design/cloud-init.html
[4] https://www.synnefo.org/
[5] https://apt.dev.grnet.gr/
[6] https://www.synnefo.org/docs/snf-image/latest/
[7] https://www.synnefo.org/docs/snf-image-creator/latest/
I'm pleased to announce that snf-image 0.22.x has cloud-init support. In
conjunction with snf-image-creator 0.11.1 you may use this functionality
to create VM's out of official OpenStack images.
In order to accomplish this we had to introduced 2 new OS parameters
(cloud_userdata, inst_properties) and the new image property CLOUD_INIT
which must be set in order for snf-image to perform cloud-init aware
deployment during the instance creation.
The cloud_userdata OS parameter expects a base64 encoded content and may
be used to inject user-data to the instance to be consumed by
cloud-init. The inst_properties OS parameter has the same format as the
img_properties parameter and can be used to overwrite image properties
that get invalidated due to the injected user-data. For example, if you
add user-data to create a new user in the instance, you'll need to
update the USERS image property in order for snf-image to apply the
password to this user. This can be done by direct changing the
img_properties OS parameter in the instance creation command line, but,
in many cases, it's easier to have the img_properties OS parameter
stored in an variant file under /etc/ganeti/snf-image and only update
specific properties using the newly introduced OS parameter.
As an example I'll demonstrate how to use a Debian Stretch openstack
image:
Obtain the original qcow2 image:
# wget
https://cdimage.debian.org/cdimage/openstack/current-9/debian-9-openstack-amd64.qcow2
Create an snf-image friendly image out of it:
# snf-mkimage -o debian-9-openstack-amd64.diskdump
debian-9-openstack-amd64.qcow2
snf-image-creator 0.11.1
========================
Examining source media `debian-9-openstack-amd64.qcow2' ... looks like
an image file
Snapshotting media source ... done
Enabling recovery process ... done
Launching helper VM (may take a while) ... done
Inspecting Operating System ... debian
Collecting image metadata ... Warning: No passworded users found!
done
Running OS inspection:
Checking if the media contains logical volumes (LVM)... no
Preparing system for image creation:
Mounting the media read-write ... done
(1/14) Removing sensitive user data
(2/14) Removing files under /tmp and /var/tmp
(3/14) Disabling predictable network interface naming
(4/14) Clearing local machine ID configuration file
(5/14) Removing swap entry from fstab
(6/14) Cleaning up password & locking all user accounts
(7/14) Removing files under /var/cache
(8/14) Disabling IPv6 privacy extensions
(9/14) Change boot menu timeout to 10 seconds
(10/14) Emptying all files under /var/log
(11/14) Removing persistent network interface names
(12/14) Replacing fstab & grub non-persistent device references
(13/14) Fixing acpid powerdown action
Warning: No acpid event directory found
Umounting the media ... done
(14/14) Shrinking image (may take a while)
Image size is 1232MB
Calculating md5sum ...
4eca65f478faa099ef73ede0042373a7
Dumping image file ... image file debian-9-openstack-amd64.diskdump was
successfully created
Dumping metadata file ... done
Dumping md5sum file ... done
Dumping variant file ... done
cleaning up ...
snf-image-creator exited without errors
The output of this command is 4 files:
# ls -1 debian-9-openstack-amd64.diskdump*
debian-9-openstack-amd64.diskdump
debian-9-openstack-amd64.diskdump.meta
debian-9-openstack-amd64.diskdump.md5sum
debian-9-openstack-amd64.diskdump.variant
The actual image file, the meta file that can be used to register the
image with synnefo, a checksum file and a variant that can be used to
create an snf-image variant:
# cat debian-9-openstack-amd64.diskdump.variant
IMG_FORMAT='diskdump'
IMG_ID='debian-9-openstack-amd64.diskdump'
IMG_PROPERTIES='{"PARTITION_TABLE": "msdos", "KERNEL": "4.9.0-3-amd64",
"OSFAMILY": "linux", "DESCRIPTION": "9.1", "REMOTE_CONNECTION":
"ssh:port=22", "GUI": "No GUI", "BOOTSTRAP": "grub2",
"CLOUD_INIT_DEFAULT_USER": "debian", "SORTORDER": "7700901",
"ROOT_PARTITION": "1", "OS": "debian", "CLOUD_INIT": "yes", "USERS":
"debian"}'
As you can see, snf-image-creator detected that there is a default
cloud-init user defined (CLOUD_INIT_DEFAULT_USER) and is activated by
cloud-init (USERS).
We may then copy the diskdump file to the snf-image IMAGE_DIR location:
# cp debian-9-openstack-amd64.diskdump
/srv/image-test/debian-9-openstack-amd64.diskdump /var/lib/snf-image/
Add the variant file to the variants location:
# cp debian-9-openstack-amd64.diskdump.variant
/etc/ganeti/snf-image/variants/stretch.conf
# echo stretch >> /etc/ganeti/snf-image/variants.list
And then create an instance. For demonstration purposes we'll add those
user-data to be executed at the first boot:
$ cat first_boot.sh
#!/bin/sh
touch /etc/testme
The instance creation command follows:
#gnt-instance add -o snf-image+stretch --os-parameters
img_passwd=just_a_password,auth_keys="$(cat
/home/skalkoto/.ssh/authorized_keys)",cloud_userdata="$(base64 -w 0
/tmp/first_boot.sh)" -t plain --disk 0:size=20G --no-name-check
--no-ip-check -B minmem=2G,maxmem=2G --net 0:ip=pool,network=nat stretch
This command will change the password of user "debian" to
"just_a_password", will inject the keys found under
"/home/skalkoto/.ssh/authorized_keys" in the host system to the
authorized keys file of the "debian" user and will make sure the command
"touch /etc/testme" is executed during the first boot.
Cloud-init userdata can be tricky. If the first line starts with "#!",
they are treated as a script that should run during the first boot. If
it starts with "#cloud-config", they are treated as cloud-init
configuration. You may also specify more complex user-data by providing a
Mime Multi Part Archive. Find more info in the cloud-init Formats
section [1].
Also, some stuff found in the cloud-init documentation [2] may not work
with your image. This documentation is for the latest version. Most
images get shipped with older versions of the software. When we were
working on adding cloud-init support to snf-image, we tried to use a
minimal subset of the mature cloud-init options to make it work for the
vast majority of the images. If you care to learn about how the
cloud-init support was implemented, please consult the corresponding
design doc [3]. As a future work, we are planning to expose this
functionality to synnefo[4] too.
As always, Debian packages for snf-image and snf-image creator can be
found in our apt repo [5]. For more details check the official
documentation of snf-image [6] andsnf-image-creator [7].
On behalf of the GRNET Development Team,
Nikos Skalkotos
[1] https://cloudinit.readthedocs.io/en/latest/topics/format.html
[2] https://cloudinit.readthedocs.io/en/latest/index.html
[3] https://www.synnefo.org/docs/snf-image/latest/design/cloud-init.html
[4] https://www.synnefo.org/
[5] https://apt.dev.grnet.gr/
[6] https://www.synnefo.org/docs/snf-image/latest/
[7] https://www.synnefo.org/docs/snf-image-creator/latest/
candlerb
Sep 21, 2018, 6:16:12 AM9/21/18
to ganeti
I just tried this under Ubuntu 16.04, using snf-image-creator from the ppa. Note: it installed 0.11-1~trusty, even though this is the xenial ppa.
root@wrn-vm1:~# head /etc/apt/sources.list.d/grnet*.list
==> /etc/apt/sources.list.d/grnet.list <==
deb http://apt.dev.grnet.gr xenial/
deb-src http://apt.dev.grnet.gr xenial/
==> /etc/apt/sources.list.d/grnet-noc.list <==
deb http://repo.noc.grnet.gr/ wheezy main
==> /etc/apt/sources.list.d/grnet-ubuntu-synnefo-xenial.list <==
deb http://ppa.launchpad.net/grnet/synnefo/ubuntu xenial main
# deb-src http://ppa.launchpad.net/grnet/synnefo/ubuntu xenial main
root@wrn-vm1:~# dpkg-query -l | grep snf
ii snf-image 0.22.3-1~xenial all Image Based Ganeti OS Provider
ii snf-image-creator 0.11-1~trusty all Synnefo Image Creator
I tried to convert the Ubuntu 16.04 cloud image, and it appeared to be successful:
root@wrn-vm1:~# snf-mkimage -o ubuntu-16.04-server-cloudimg-amd64-disk1.diskdump ubuntu-16.04-server-cloudimg-amd64-disk1.img
snf-image-creator 0.11
======================
Examining source media `ubuntu-16.04-server-cloudimg-amd64-disk1.img' ... looks like an image file
Snapshotting media source ... done
Enabling recovery process ... done
Launching helper VM (may take a while) ... done
Inspecting Operating System ... ubuntu
Collecting image metadata ... Warning: No passworded users found!
done
Running OS inspection:
Checking if the media contains logical volumes (LVM)... no
Preparing system for image creation:
Mounting the media read-write ... done
(1/14) Removing sensitive user data
(2/14) Removing files under /tmp and /var/tmp
(3/14) Disabling predictable network interface naming
(4/14) Clearing local machine ID configuration file
(5/14) Removing swap entry from fstab
(6/14) Cleaning up password & locking all user accounts
(7/14) Removing files under /var/cache
(8/14) Disabling IPv6 privacy extensions
(9/14) Change boot menu timeout to 10 seconds
(10/14) Emptying all files under /var/log
(11/14) Removing persistent network interface names
(12/14) Replacing fstab & grub non-persistent device references
(13/14) Fixing acpid powerdown action
Umounting the media ... done
(14/14) Shrinking image (may take a while)
Image size is 1394MB
Calculating md5sum ... ecbac7421eb7d69614f9eb228bca3f9c
Dumping image file ... image file ubuntu-16.04-server-cloudimg-amd64-disk1.diskdump was successfully created
Dumping metadata file ... done
Dumping md5sum file ... done
cleaning up ...
snf-image-creator exited without errors
root@wrn-vm1:~#
However, it didn't create a "variant" file:
root@wrn-vm1:~# ls -lh ubuntu-16.04-server-cloudimg-amd64-disk1.*
-rw-r--r-- 1 root root 1.4G Sep 21 11:02 ubuntu-16.04-server-cloudimg-amd64-disk1.diskdump
-rw-r--r-- 1 root root 83 Sep 21 11:02 ubuntu-16.04-server-cloudimg-amd64-disk1.diskdump.md5sum
-rw-r--r-- 1 root root 373 Sep 21 11:02 ubuntu-16.04-server-cloudimg-amd64-disk1.diskdump.meta
-rw-r--r-- 1 root root 284M Sep 12 15:47 ubuntu-16.04-server-cloudimg-amd64-disk1.img
Also, it didn't appear to compress it very well, given that it has gone from 300M to 1.4GB.
Checking in git, it seems that the feature to write the variants file was added in snf-image-creator 0.11.1, but the version in the ppa is 0.11. (There's also a 0.11.2 available now)
Would it be possible to release a newer Ubuntu version please?
Thanks,
Brian.
candlerb
Sep 21, 2018, 6:51:33 AM9/21/18
to ganeti
Correction: I'm not sure what I saw that made me think there was a 0.11.2 hotfix, but I can't find it now. Looks like 0.11.1 is latest tagged version in git.
Reply all
Reply to author
Forward
0 new messages