# 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:

    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>` → `<provider-driver>` → `<detailed-output>`. An example is always better. For an `ec2-config` provider alias with an `ec2` driver configured:

    salt-cloud -f show_image ec2-config image=ami-35eb835c

    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.