doc/topics/cloud/releases/0.8.9.rst
==============================
Salt Cloud 0.8.9 Release Notes
==============================
Welcome to 0.8.9! It has been a long time since the last release, and we're
excited to get this one out the door!
Documentation
=============
The documentation for Salt Cloud can be found on Read the Docs:
https://salt-cloud.readthedocs.io
Download
========
Salt Cloud can be downloaded and install via pypi:
https://pypi.python.org/packages/source/s/salt-cloud/salt-cloud-0.8.9.tar.gz
Some packages have been made available for salt-cloud and more on their
way. Packages for Arch and FreeBSD are being made available thanks to the
work of Christer Edwards, and packages for RHEL and Fedora are being created
by Clint Savage. The Ubuntu PPA is being managed by Sean Channel. Package
availability will be announced on the salt mailing list.
New Cloudstack Driver
=====================
One of the more impressive stories this release involves the Cloud Stack driver,
written by Sebastien Goasguen. After meeting Thomas Hatch at the LinuxTag
conference, Sebastien went out and wrote a Cloud Stack driver for Salt Cloud, in
less time than it took to compile these release notes. His story is here:
http://sebgoa.blogspot.com/2013/05/the-linuxtag-hack.html
Several people have been asking for this driver, and we are very grateful to
Sebastien for adding it for us!
Updated Joyent Support
======================
Joyent has updated their API, and Salt Cloud has included the updates in this
version. Bob Szabo did the bulk of this work, and we would like to extend a
special thanks to him for his efforts. The Joyent driver has also been
optimized to access the API directly, resulting in faster operations, and
opening up more of Joyent's native API for future use. Some of the features
that have already been added as a result of this pertain to SSH key management,
directly from Salt Cloud. The following functions have been added:
* list_keys
* show_key
* import_key
* delete_key
Mapping Independent Hierarchies
===============================
Salt Cloud 0.8.5 introduced the ability to spin up an instance and install
the salt-master package on it. This functionality has been extended, so that
a map file may now spin up a new master, and its minions, and pre-seed the
master with the minion keys so that they are immediately accepted by the time
the new salt-master starts up, and each minion is started up. A map file that
can accomplish this might look like:
.. code-block:: yaml
Ubuntu-12.04-64bit:
TT_Master:
minion:
retry_dns: 5
make_master: True
TT2:
minion:
retry_dns: 5
TT3:
minion:
retry_dns: 5
This functionality was added by Pedro Algarvio, to spin up hierarchies for
testing purposes, and then remove them when finished. This can be instrumental
to organizations wishing to extend their testing and build environments. We
would like to thank him for this, and the many other contributions that he has
added to this and other releases!
Parallel Creation and Logging
=============================
There have been reports of issues in the past pertaining to screen issues when
running salt-cloud in parallel mode (-P). This mode has been greatly stabilized
in this release. Additionally, parallel logging capabilities have been added,
allowing users to store parallel execution logs. Finally, keyboard interrupts
(such as ^C) are now properly handled.
Internal Data Structure
=======================
On 0.8.7 we unleashed the power of multiple cloud provider profiles, it even
allows multiple profiles for the same cloud provider. That was a much asked
feature and was adopted by users right away. Unfortunately, all that power had
a small point of failure when multiple profiles existed for the same cloud
provider. Only the first was used in most operations.
To fix this small issue, salt-cloud's internal data structure changed quite a
bit. Every action, function, virtual machine creation, etc, is now, **always**
"attached" to a provider alias and the(one of the) cloud drivers defined.
Internally, when loading the configuration, all the defined profiles are
matched to the available providers. If the provider does not exits, the profile
gets removed. The same happens for the defined providers, they all know which
profiles they can manage. This closes that small point of failure.
Data Presentation
=================
With the internal data structure change also came a data presentation change.
Most, unless not applicable, output is now done in an ``<provider-alias>``
|srarr| ``<provider-driver>`` |srarr| ``<detailed-output>``. An example is
always better. For an ``ec2-config`` provider alias with an ``ec2`` driver
configured:
.. code-block:: bash
salt-cloud -f show_image ec2-config image=ami-35eb835c
.. code-block:: yaml
ec2-config:
----------
ec2:
----------
- architecture:
x86_64
- blockDeviceMapping:
----------
item:
----------
deviceName:
/dev/sda
ebs:
----------
deleteOnTermination:
true
snapshotId:
snap-59724004
volumeSize:
8
volumeType:
standard
- description:
OmniOS r151006 Base (Stable)
- hypervisor:
xen
- imageId:
ami-35eb835c
- imageLocation:
182711560792/OmniOS r151006c
- imageOwnerId:
182711560792
- imageState:
available
- imageType:
machine
- isPublic:
true
- kernelId:
aki-b4aa75dd
- name:
OmniOS r151006c
- rootDeviceName:
/dev/sda
- rootDeviceType:
ebs
- virtualizationType:
paravirtual
We're now always aware of what was done using what.
.. include:: <isoamsa.txt>