Salt Cloud 0.8.9 Release Notes¶

Documentation¶

The documentation for Salt Cloud can be found on Read the Docs: http://salt-cloud.readthedocs.org

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 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.