valitydev/salt
14
0
Fork 0
mirror of https://github.com/valitydev/salt.git synced 2024-11-07 00:55:19 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Move old cloud syntax to "Legacy" cloud config doc

Browse Source
This commit is contained in:
rallytime 2015-04-07 18:41:21 -06:00
parent ade247443d
commit 9b5318fe71
2 changed files with 384 additions and 401 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

488
doc/topics/cloud/config.rst
View File

@ -6,8 +6,9 @@ A number of core configuration options and some options that are global to the
VM profiles can be set in the cloud configuration file. By default this file is
located at ``/etc/salt/cloud``.
Thread Pool Size
====================
================
When salt cloud is operating in parallel mode via the ``-P`` argument, you can
control the thread pool size by specifying the ``pool_size`` parameter with
@ -32,230 +33,23 @@ be used here.
.. code-block:: yaml
minion:
master: saltmaster.example.com
master: saltmaster.example.com
In particular, this is the location to specify the location of the salt master
and its listening port, if the port is not set to the default.
New Cloud Configuration Syntax
==============================
Cloud Configuration Syntax
==========================
The data specific to interacting with public clouds is set up here.
**ATTENTION**: Since version 0.8.7 a new cloud provider configuration syntax
was implemented. It will allow for multiple configurations of the same cloud
provider where only minor details can change, for example, the region for an
EC2 instance. While the old format is still supported and automatically
migrated every time salt-cloud configuration is parsed, a choice was made to
warn the user or even exit with an error if both formats are mixed.
Migrating Configurations
------------------------
If you wish to migrate, there are several alternatives. Since the old syntax
was mainly done on the main cloud configuration file, see the next before and
after migration example.
* Before migration in ``/etc/salt/cloud``:
.. code-block:: yaml
AWS.id: HJGRYCILJLKJYG
AWS.key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
AWS.keyname: test
AWS.securitygroup: quick-start
AWS.private_key: /root/test.pem
* After migration in ``/etc/salt/cloud``:
.. code-block:: yaml
providers:
my-aws-migrated-config:
id: HJGRYCILJLKJYG
key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
keyname: test
securitygroup: quick-start
private_key: /root/test.pem
provider: aws
Notice that it's no longer required to name a cloud provider's configuration
after its provider; it can be an alias, though an additional configuration
key is added, ``provider``. This allows for multiple configuration for the same
cloud provider to coexist.
While moving towards an improved and extensible configuration handling
regarding the cloud providers, ``--providers-config``, which defaults to
``/etc/salt/cloud.providers``, was added to the cli parser. It allows for the
cloud providers configuration to be provided in a different file, and/or even
any matching file on a sub-directory, ``cloud.providers.d/*.conf`` which is
relative to the providers configuration file(with the above configuration file
as an example, ``/etc/salt/cloud.providers.d/*.conf``).
So, using the example configuration above, after migration in
``/etc/salt/cloud.providers`` or
``/etc/salt/cloud.providers.d/aws-migrated.conf``:
.. code-block:: yaml
my-aws-migrated-config:
id: HJGRYCILJLKJYG
key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
keyname: test
securitygroup: quick-start
private_key: /root/test.pem
provider: aws
Notice that on this last migrated example, it **no longer** includes the
``providers`` starting key.
While migrating the cloud providers configuration, if the provider alias (from
the above example ``my-aws-migrated-config``) changes from what you had (from
the above example ``aws``), you will also need to change the ``provider``
configuration key in the defined profiles.
* From:
.. code-block:: yaml
rhel_aws:
provider: aws
image: ami-e565ba8c
size: Micro Instance
* To:
.. code-block:: yaml
rhel_aws:
provider: my-aws-migrated-config
image: ami-e565ba8c
size: Micro Instance
This new configuration syntax even allows you to have multiple cloud
configurations under the same alias, for example:
.. code-block:: yaml
production-config:
- id: HJGRYCILJLKJYG
key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
keyname: test
securitygroup: quick-start
private_key: /root/test.pem
- user: example_user
apikey: 123984bjjas87034
provider: rackspace
**Notice the dash and indentation on the above example.**
Having multiple entries for a configuration alias also makes the ``provider``
key on any defined profile to change, see the example:
.. code-block:: yaml
rhel_aws_dev:
provider: production-config:aws
image: ami-e565ba8c
size: Micro Instance
rhel_aws_prod:
provider: production-config:aws
image: ami-e565ba8c
size: High-CPU Extra Large Instance
database_prod:
provider: production-config:rackspace
image: Ubuntu 12.04 LTS
size: 256 server
Notice that because of the multiple entries, one has to be explicit about the
provider alias and name, from the above example, ``production-config:aws``.
This new syntax also changes the interaction with the ``salt-cloud`` binary.
``--list-location``, ``--list-images`` and ``--list-sizes`` which needs a cloud
provider as an argument. Since 0.8.7 the argument used should be the configured
cloud provider alias. If the provider alias only has a single entry, use
``<provider-alias>``. If it has multiple entries,
``<provider-alias>:<provider-name>`` should be used.
Pillar Configuration
====================
It is possible to configure cloud providers using pillars. This is only used
when inside the cloud module. You can setup a variable called ``clouds`` that
contains your profile and provider to pass that information to the cloud
servers instead of having to copy the full configuration to every minion.
In your pillar file, you would use something like this.
.. code-block:: yaml
cloud:
ssh_key_name: saltstack
ssh_key_file: /root/.ssh/id_rsa
update_cachedir: True
diff_cache_events: True
change_password: True
providers:
my-nova:
identity_url: https://identity.api.rackspacecloud.com/v2.0/
compute_region: IAD
user: myuser
api_key: apikey
tenant: 123456
provider: nova
my-openstack:
identity_url: https://identity.api.rackspacecloud.com/v2.0/tokens
user: user2
apikey: apikey2
tenant: 654321
compute_region: DFW
provider: openstack
compute_name: cloudServersOpenStack
profiles:
ubuntu-nova:
provider: my-nova
size: performance1-8
image: bb02b1a3-bc77-4d17-ab5b-421d89850fca
script_args: git develop
flush_mine_on_destroy: True
ubuntu-openstack:
provider: my-openstack
size: performance1-8
image: bb02b1a3-bc77-4d17-ab5b-421d89850fca
script_args: git develop
flush_mine_on_destroy: True
**NOTE**: This is only valid in the cloud module, so also in the cloud state.
This does not work with the salt-cloud binary.
**ATTENTION**: In Salt-Cloud version 0.8.7, a new cloud provider configuration
syntax was implemented. This new configuration syntax is the standard cloud
configuration syntax that is documented here. For information regarding the old
cloud provider configuration syntax, please see the
:ref:Salt Cloud Legacy Configuration <salt-cloud-legacy-configuration> documentation.
Cloud Configurations
@ -264,49 +58,26 @@ Cloud Configurations
Rackspace
---------
Rackspace cloud requires two configuration options:
* Using the old format:
.. code-block:: yaml
RACKSPACE.user: example_user
RACKSPACE.apikey: 123984bjjas87034
* Using the new configuration format:
Rackspace cloud requires two configuration options; a ``user`` and an ``apikey``:
.. code-block:: yaml
my-rackspace-config:
user: example_user
apikey: 123984bjjas87034
provider: rackspace
provider: rackspace-config
.. note::
**NOTE**: With the new providers configuration syntax you would have ``provider:
rackspace-config`` instead of ``provider: rackspace`` on a profile
configuration.
In the cloud profile that uses this provider configuration, the syntax for the
``provider`` required field would be ``provider: my-rackspace-config``.
Amazon AWS
----------
A number of configuration options are required for Amazon AWS:
* Using the old format:
.. code-block:: yaml
AWS.id: HJGRYCILJLKJYG
AWS.key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
AWS.keyname: test
AWS.securitygroup: quick-start
AWS.private_key: /root/test.pem
* Using the new configuration format:
A number of configuration options are required for Amazon AWS including ``id``,
``key``, ``keyname``, ``sercuritygroup``, and ``private_key``:
.. code-block:: yaml
@ -326,10 +97,11 @@ A number of configuration options are required for Amazon AWS:
private_key: /root/test.pem
provider: aws
.. note::
**NOTE**: With the new providers configuration syntax you would have
``provider: my-aws-quick-start`` or ``provider: my-aws-default`` instead of
``provider: aws`` on a profile configuration.
In the cloud profile that uses this provider configuration, the syntax for the
``provider`` required field would be either ``provider: my-aws-quick-start``
or ``provider: my-aws-default``.
Linode
@ -338,16 +110,6 @@ Linode
Linode requires a single API key, but the default root password also needs to
be set:
* Using the old format:
.. code-block:: yaml
LINODE.apikey: asldkgfakl;sdfjsjaslfjaklsdjf;askldjfaaklsjdfhasldsadfghdkf
LINODE.password: F00barbaz
* Using the new configuration format:
.. code-block:: yaml
my-linode-config:
@ -355,68 +117,47 @@ be set:
password: F00barbaz
provider: linode
**NOTE**: With the new providers configuration syntax you would have
``provider: my-linode-config`` instead of ``provider: linode`` on a profile
configuration.
The password needs to be 8 characters and contain lowercase, uppercase and
numbers.
.. note::
In the cloud profile that uses this provider configuration, the syntax for the
``provider`` required field would be ``provider: my-linode-config``
Joyent Cloud
------------
The Joyent cloud requires three configuration parameters. The username and
password that are used to log into the Joyent system, and the location of the
private SSH key associated with the Joyent account. The SSH key is needed to
send the provisioning commands up to the freshly created virtual machine.
* Using the old format:
.. code-block:: yaml
JOYENT.user: fred
JOYENT.password: saltybacon
JOYENT.private_key: /root/joyent.pem
* Using the new configuration format:
The Joyent cloud requires three configuration parameters: The username and
password that are used to log into the Joyent system, as well as the location
of the private SSH key associated with the Joyent account. The SSH key is needed
to send the provisioning commands up to the freshly created virtual machine.
.. code-block:: yaml
my-joyent-config:
user: fred
password: saltybacon
private_key: /root/joyent.pem
provider: joyent
user: fred
password: saltybacon
private_key: /root/joyent.pem
provider: joyent
.. note::
**NOTE**: With the new providers configuration syntax you would have
``provider: my-joyent-config`` instead of ``provider: joyent`` on a profile
configuration.
In the cloud profile that uses this provider configuration, the syntax for the
``provider`` required field would be ``provider: my-joyent-config``
GoGrid
------
To use Salt Cloud with GoGrid log into the GoGrid web interface and create an
To use Salt Cloud with GoGrid, log into the GoGrid web interface and create an
API key. Do this by clicking on "My Account" and then going to the API Keys
tab.
The GOGRID.apikey and the GOGRID.sharedsecret configuration parameters need to
The ``apikey`` and the ``sharedsecret`` configuration parameters need to
be set in the configuration file to enable interfacing with GoGrid:
* Using the old format:
.. code-block:: yaml
GOGRID.apikey: asdff7896asdh789
GOGRID.sharedsecret: saltybacon
* Using the new configuration format:
.. code-block:: yaml
my-gogrid-config:
@ -424,10 +165,10 @@ be set in the configuration file to enable interfacing with GoGrid:
sharedsecret: saltybacon
provider: gogrid
.. note::
**NOTE**: With the new providers configuration syntax you would have
``provider: my-gogrid-config`` instead of ``provider: gogrid`` on a profile
configuration.
In the cloud profile that uses this provider configuration, the syntax for the
``provider`` required field would be ``provider: my-gogrid-config``.
OpenStack
@ -438,41 +179,6 @@ options need to be specified. This module has been officially tested against
the HP and the Rackspace implementations, and some examples are provided for
both.
* Using the old format:
.. code-block:: yaml
# For HP
OPENSTACK.identity_url: 'https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/'
OPENSTACK.compute_name: Compute
OPENSTACK.compute_region: 'az-1.region-a.geo-1'
OPENSTACK.tenant: myuser-tenant1
OPENSTACK.user: myuser
OPENSTACK.ssh_key_name: mykey
OPENSTACK.ssh_key_file: '/etc/salt/hpcloud/mykey.pem'
OPENSTACK.password: mypass
# For Rackspace
OPENSTACK.identity_url: 'https://identity.api.rackspacecloud.com/v2.0/tokens'
OPENSTACK.compute_name: cloudServersOpenStack
OPENSTACK.protocol: ipv4
OPENSTACK.compute_region: DFW
OPENSTACK.protocol: ipv4
OPENSTACK.user: myuser
OPENSTACK.tenant: 5555555
OPENSTACK.password: mypass
If you have an API key for your provider, it may be specified instead of a
password:
.. code-block:: yaml
OPENSTACK.apikey: 901d3f579h23c8v73q9
* Using the new configuration format:
.. code-block:: yaml
# For HP
@ -512,62 +218,40 @@ password:
my-openstack-rackspace-config:
apikey: 901d3f579h23c8v73q9
.. note::
**NOTE**: With the new providers configuration syntax you would have
``provider: my-openstack-hp-config`` or ``provider:
my-openstack-rackspace-config`` instead of ``provider: openstack`` on a profile
configuration.
In the cloud profile that uses this provider configuration, the syntax for the
``provider`` required field would be either ``provider: my-openstack-hp-config``
or ``provider: my-openstack-rackspace-config``.
You will certainly need to configure the ``user``, ``tenant`` and either
``password`` or ``apikey``.
If your OpenStack instances only have private IP addresses and a CIDR range of
private addresses are not reachable from the salt-master, you may set your
preference to have Salt ignore it. Using the old could configurations syntax:
.. code-block:: yaml
OPENSTACK.ignore_cidr: 192.168.0.0/16
Using the new syntax:
preference to have Salt ignore it:
.. code-block:: yaml
my-openstack-config:
ignore_cidr: 192.168.0.0/16
For in-house OpenStack Essex installation, libcloud needs the service_type :
.. code-block:: yaml
my-openstack-config:
identity_url: 'http://control.openstack.example.org:5000/v2.0/'
compute_name : Compute Service
service_type : compute
my-openstack-config:
identity_url: 'http://control.openstack.example.org:5000/v2.0/'
compute_name : Compute Service
service_type : compute
DigitalOcean
-------------
Using Salt for DigitalOcean requires a client_key and an api_key. These can be
found in the DigitalOcean web interface, in the "My Settings" section, under
the API Access tab.
* Using the old format:
.. code-block:: yaml
DIGITAL_OCEAN.client_key: wFGEwgregeqw3435gDger
DIGITAL_OCEAN.api_key: GDE43t43REGTrkilg43934t34qT43t4dgegerGEgg
* Using the new configuration format:
------------
Using Salt for DigitalOcean requires a ``client_key`` and an ``api_key``. These
can be found in the DigitalOcean web interface, in the "My Settings" section,
under the API Access tab.
.. code-block:: yaml
my-digitalocean-config:
@ -576,28 +260,17 @@ the API Access tab.
api_key: GDE43t43REGTrkilg43934t34qT43t4dgegerGEgg
location: New York 1
.. note::
**NOTE**: With the new providers configuration syntax you would have
``provider: my-digitalocean-config`` instead of ``provider: digital_ocean`` on a
profile configuration.
In the cloud profile that uses this provider configuration, the syntax for the
``provider`` required field would be ``provider: my-digital-ocean-config``.
Parallels
---------
Using Salt with Parallels requires a user, password and URL. These can be
obtained from your cloud provider.
* Using the old format:
.. code-block:: yaml
PARALLELS.user: myuser
PARALLELS.password: xyzzy
PARALLELS.url: https://api.cloud.xmission.com:4465/paci/v1.0/
* Using the new configuration format:
Using Salt with Parallels requires a ``user``, ``password`` and ``URL``. These
can be obtained from your cloud provider.
.. code-block:: yaml
@ -607,19 +280,18 @@ obtained from your cloud provider.
url: https://api.cloud.xmission.com:4465/paci/v1.0/
provider: parallels
.. note::
In the cloud profile that uses this provider configuration, the syntax for the
``provider`` required field would be ``provider: my-parallels-config``.
**NOTE**: With the new providers configuration syntax you would have
``provider: my-parallels-config`` instead of ``provider: parallels`` on a
profile configuration.
Proxmox
---------
-------
Using Salt with Proxmox requires a user, password and URL. These can be
Using Salt with Proxmox requires a ``user``, ``password``, and ``URL``. These can be
obtained from your cloud provider. Both PAM and PVE users can be used.
* Using the new configuration format:
.. code-block:: yaml
my-proxmox-config:
@ -627,15 +299,19 @@ obtained from your cloud provider. Both PAM and PVE users can be used.
user: saltcloud@pve
password: xyzzy
url: your.proxmox.host
lxc
.. note::
In the cloud profile that uses this provider configuration, the syntax for the
``provider`` required field would be ``provider: my-proxmox-config``.
LXC
---
The lxc driver is a new, experimental driver for installing Salt on
newly provisioned (via saltcloud) lxc containers. It will in turn use saltify to install
salt an rattach the lxc container as a new lxc minion.
As soon as we can, we manage baremetal operation over SSH.
You can also destroy those containers via this driver.
The lxc driver uses saltify to install salt and attach the lxc container as a new lxc
minion. As soon as we can, we manage baremetal operation over SSH. You can also destroy
those containers via this driver.
.. code-block:: yaml
@ -660,6 +336,11 @@ And in the map file:
lxc_conf:
- lxc.utsname: superlxc
.. note::
In the cloud profile that uses this provider configuration, the syntax for the
``provider`` required field would be ``provdier: devhost10-lxc`.
.. _config_saltify:
Saltify
@ -690,6 +371,11 @@ And in the map file:
ssh_keyfile: '/etc/salt/mysshkey.pem'
sudo: True
.. note::
In the cloud profile that uses this provider configuration, the syntax for the
``provider`` required field would be ``provider: make_salty``.
Extending Profiles and Cloud Providers Configuration
====================================================

297
doc/topics/cloud/config_legacy.rst Normal file
View File

@ -0,0 +1,297 @@
.. _salt-cloud-legacy-configuration:
===============================
Salt Cloud Legacy Configuration
===============================
Starting in Salt-Cloud version 0.8.7, a new cloud provider configuration syntax was
introduced. The new provider configuration allows for multiple configurations of the
same cloud provider where only minor details may change such as the region for an
EC2 instance. The old, legacy format, as documented here, is still supported and
automatically migrated every time a salt-cloud configuration is parsed. However,
the user is warned or salt-cloud will even exit with an error if the legacy cloud
configuration format is mixed with the new, standard cloud configuration format.
Migrating Configurations
========================
If you wish to migrate, there are several alternatives. Since the old syntax
was mainly done on the main cloud configuration file, ``/etc/salt/cloud``, the next
before and after migration examples are helpful to understand the migration.
* Before migration in ``/etc/salt/cloud``:
.. code-block:: yaml
AWS.id: HJGRYCILJLKJYG
AWS.key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
AWS.keyname: test
AWS.securitygroup: quick-start
AWS.private_key: /root/test.pem
* After migration in ``/etc/salt/cloud``:
.. code-block:: yaml
providers:
my-aws-migrated-config:
id: HJGRYCILJLKJYG
key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
keyname: test
securitygroup: quick-start
private_key: /root/test.pem
provider: aws
Notice that it's no longer required to name a cloud provider's configuration
after its provider; it can be an alias, though an additional configuration
key is added, ``provider``. This allows for multiple configuration for the same
cloud provider to coexist.
While moving towards an improved and extensible configuration handling
regarding the cloud providers, ``--providers-config``, which defaults to
``/etc/salt/cloud.providers``, was added to the cli parser. It allows for the
cloud providers configuration to be provided in a different file, and/or even
any matching file on a sub-directory, ``cloud.providers.d/*.conf`` which is
relative to the providers configuration file(with the above configuration file
as an example, ``/etc/salt/cloud.providers.d/*.conf``).
So, using the example configuration above, after migration in
``/etc/salt/cloud.providers`` or
``/etc/salt/cloud.providers.d/aws-migrated.conf``:
.. code-block:: yaml
my-aws-migrated-config:
id: HJGRYCILJLKJYG
key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
keyname: test
securitygroup: quick-start
private_key: /root/test.pem
provider: aws
Notice that on this last migrated example, it **no longer** includes the
``providers`` starting key.
While migrating the cloud providers configuration, if the provider alias (from
the above example ``my-aws-migrated-config``) changes from what you had (from
the above example ``aws``), you will also need to change the ``provider``
configuration key in the defined profiles.
* From:
.. code-block:: yaml
rhel_aws:
provider: aws
image: ami-e565ba8c
size: Micro Instance
* To:
.. code-block:: yaml
rhel_aws:
provider: my-aws-migrated-config
image: ami-e565ba8c
size: Micro Instance
This new configuration syntax even allows you to have multiple cloud
configurations under the same alias, for example:
.. code-block:: yaml
production-config:
- id: HJGRYCILJLKJYG
key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
keyname: test
securitygroup: quick-start
private_key: /root/test.pem
- user: example_user
apikey: 123984bjjas87034
provider: rackspace
**Notice the dash and indentation on the above example.**
Having multiple entries for a configuration alias also makes the ``provider``
key on any defined profile to change, see the example:
.. code-block:: yaml
rhel_aws_dev:
provider: production-config:aws
image: ami-e565ba8c
size: Micro Instance
rhel_aws_prod:
provider: production-config:aws
image: ami-e565ba8c
size: High-CPU Extra Large Instance
database_prod:
provider: production-config:rackspace
image: Ubuntu 12.04 LTS
size: 256 server
Notice that because of the multiple entries, one has to be explicit about the
provider alias and name, from the above example, ``production-config:aws``.
This new syntax also changes the interaction with the ``salt-cloud`` binary.
``--list-location``, ``--list-images`` and ``--list-sizes`` which needs a cloud
provider as an argument. Since 0.8.7 the argument used should be the configured
cloud provider alias. If the provider alias only has a single entry, use
``<provider-alias>``. If it has multiple entries,
``<provider-alias>: <provider-name>`` should be used.
Legacy Cloud Configurations
===========================
Rackspace
---------
Rackspace cloud requires two configuration options; a ``user`` and an ``apikey``:
.. code-block:: yaml
RACKSPACE.user: example_user
RACKSPACE.apikey: 123984bjjas87034
Amazon AWS
----------
A number of configuration options are required for Amazon AWS including ``id``,
``key``, ``keyname``, ``sercuritygroup``, and ``private_key``:
.. code-block:: yaml
AWS.id: HJGRYCILJLKJYG
AWS.key: 'kdjgfsgm;woormgl/aserigjksjdhasdfgn'
AWS.keyname: test
AWS.securitygroup: quick-start
AWS.private_key: /root/test.pem
Linode
------
Linode requires a single API key, but the default root password also needs to
be set:
.. code-block:: yaml
LINODE.apikey: asldkgfakl;sdfjsjaslfjaklsdjf;askldjfaaklsjdfhasldsadfghdkf
LINODE.password: F00barbaz
Joyent Cloud
------------
The Joyent cloud requires three configuration parameters: The username and
password that are used to log into the Joyent system, as well as the location
of the private SSH key associated with the Joyent account. The SSH key is needed
to send the provisioning commands up to the freshly created virtual machine.
.. code-block:: yaml
JOYENT.user: fred
JOYENT.password: saltybacon
JOYENT.private_key: /root/joyent.pem
GoGrid
------
To use Salt Cloud with GoGrid, log into the GoGrid web interface and create an
API key. Do this by clicking on "My Account" and then going to the API Keys
tab.
The ``GOGRID.apikey`` and the ``GOGRID.sharedsecret`` configuration parameters
need to be set in the cloud provider configuration file to enable interfacing
with GoGrid:
.. code-block:: yaml
GOGRID.apikey: asdff7896asdh789
GOGRID.sharedsecret: saltybacon
OpenStack
---------
OpenStack configuration differs between providers, and at the moment several
options need to be specified. This module has been officially tested against
the HP and the Rackspace implementations, and some examples are provided for
both.
.. code-block:: yaml
# For HP
OPENSTACK.identity_url: 'https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/'
OPENSTACK.compute_name: Compute
OPENSTACK.compute_region: 'az-1.region-a.geo-1'
OPENSTACK.tenant: myuser-tenant1
OPENSTACK.user: myuser
OPENSTACK.ssh_key_name: mykey
OPENSTACK.ssh_key_file: '/etc/salt/hpcloud/mykey.pem'
OPENSTACK.password: mypass
# For Rackspace
OPENSTACK.identity_url: 'https://identity.api.rackspacecloud.com/v2.0/tokens'
OPENSTACK.compute_name: cloudServersOpenStack
OPENSTACK.protocol: ipv4
OPENSTACK.compute_region: DFW
OPENSTACK.protocol: ipv4
OPENSTACK.user: myuser
OPENSTACK.tenant: 5555555
OPENSTACK.password: mypass
If you have an API key for your provider, it may be specified instead of a
password:
.. code-block:: yaml
OPENSTACK.apikey: 901d3f579h23c8v73q9
If your OpenStack instances only have private IP addresses and a CIDR range of
private addresses are not reachable from the salt-master, you may set your
preference to have Salt ignore it:
.. code-block:: yaml
OPENSTACK.ignore_cidr: 192.168.0.0/16
DigitalOcean
------------
Using Salt for DigitalOcean requires a ``client_key`` and an ``api_key``. These
can be found in the DigitalOcean web interface, in the "My Settings" section,
under the API Access tab.
.. code-block:: yaml
DIGITAL_OCEAN.client_key: wFGEwgregeqw3435gDger
DIGITAL_OCEAN.api_key: GDE43t43REGTrkilg43934t34qT43t4dgegerGEgg
Parallels
---------
Using Salt with Parallels requires a ``user``, ``password`` and ``URL``. These
can be obtained from your cloud provider.
.. code-block:: yaml
PARALLELS.user: myuser
PARALLELS.password: xyzzy
PARALLELS.url: https://api.cloud.xmission.com:4465/paci/v1.0/