neulab/tldr huggingface dataset:
Delete firewall Deleting a firewall rule will prevent any previously allowed traffic for the named firewall rule.
salt-cloud -f delete_fwrule gce name=web
Show firewall Use this function to review an existing firewall rule's information.
salt-cloud -f show_fwrule gce name=web
Load Balancer Compute Engine possess a load-balancer feature for splitting traffic across multiple instances. Please reference the documentation for a more complete description.
The load-balancer functionality is slightly different than that described in Google's documentation.  The concept of TargetPool and ForwardingRule are consolidated in salt-cloud/libcloud.  HTTP Health Checks are optional.
HTTP Health Check HTTP Health Checks can be used as a means to toggle load-balancing across instance members, or to detect if an HTTP site is functioning.  A common use-case is to set up a health check URL and if you want to toggle traffic on/off to an instance, you can temporarily have it return a non-200 response.  A non-200 response to the load-balancer's health check will keep the LB from sending any new traffic to the "down" instance. Once the instance's health check URL beings returning 200-responses, the LB will again start to send traffic to it. Review Compute Engine's documentation for allowable parameters.  You can use the following salt-cloud functions to manage your HTTP health checks.
salt-cloud -f create_hc gce name=myhc path=/ port=80 salt-cloud -f delete_hc gce name=myhc salt-cloud -f show_hc gce name=myhc
Load-balancer When creating a new load-balancer, it requires a name, region, port range, and list of members. There are other optional parameters for protocol, and list of health checks. Deleting or showing details about the LB only requires the name.
salt-cloud -f create_lb gce name=lb region=... ports=80 members=w1,w2,w3 salt-cloud -f delete_lb gce name=lb salt-cloud -f show_lb gce name=lb
You can also create a load balancer using a named fixed IP addressby specifying the name of the address.  If the address does not exist yet it will be created.
salt-cloud -f create_lb gce name=my-lb region=us-central1 ports=234 members=s1,s2,s3 address=my-lb-ip
Attach and Detach LB It is possible to attach or detach an instance from an existing load-balancer.  Both the instance and load-balancer must exist before using these functions.
salt-cloud -f attach_lb gce name=lb member=w4 salt-cloud -f detach_lb gce name=lb member=oops
Getting Started With HP Cloud HP Cloud is a major public cloud platform and uses the libcloud openstack driver. The current version of OpenStack that HP Cloud uses is Havana. When an instance is booted, it must have a floating IP added to it in order to connect to it and further below you will see an example that adds context to this statement.
Set up a cloud provider configuration file To use the openstack driver for HP Cloud, set up the cloud provider configuration file as in the example shown below:
/etc/salt/cloud.providers.d/hpcloud.conf:
hpcloud-config: # Set the location of the salt-master # minion: master: saltmaster.example.com
# Configure HP Cloud using the OpenStack plugin # identity_url: https://region-b.geo-1.identity.hpcloudsvc.com:35357/v2.0/tokens compute_name: Compute protocol: ipv4
# Set the compute region: # compute_region: region-b.geo-1
# Configure HP Cloud authentication credentials # user: myname tenant: myname-project1 password: xxxxxxxxx
# keys to allow connection to the instance launched # ssh_key_name: yourkey ssh_key_file: /path/to/key/yourkey.priv
driver: openstack
The subsequent example that follows is using the openstack driver.
Compute Region Originally, HP Cloud, in its OpenStack Essex version (1.0), had 3 availability zones in one region, US West (region-a.geo-1), which each behaved each as a region.
This has since changed, and the current OpenStack Havana version of HP Cloud (1.1) now has simplified this and now has two regions to choose from:
region-a.geo-1 -> US West region-b.geo-1 -> US East
Authentication The user is the same user as is used to log into the HP Cloud management UI. The tenant can be found in the upper left under "Project/Region/Scope".  It is often named the same as user albeit with a -project1 appended.  The password is of course what you created your account with. The management UI also has other information such as being able to select US East or US West.
Set up a cloud profile config file The profile shown below is a know working profile for an Ubuntu instance. The profile configuration file is stored in the following location:
/etc/salt/cloud.profiles.d/hp_ae1_ubuntu.conf:
hp_ae1_ubuntu: provider: hp_ae1 image: 9302692b-b787-4b52-a3a6-daebb79cb498 ignore_cidr: 10.0.0.1/24 networks: - floating: Ext-Net size: standard.small ssh_key_file: /root/keys/test.key ssh_key_name: test ssh_username: ubuntu
Some important things about the example above:
• The image parameter can use either the image name or image ID which you can obtain by running in the example below (this case US East):
# salt-cloud --list-images hp_ae1
• The parameter ignore_cidr specifies a range of addresses to ignore when trying to connect to the instance. In this case, it's the range of IP addresses used for an private IP of the instance.
• The parameter networks is very important to include. In previous versions of Salt Cloud, this is what made it possible for salt-cloud to be able to attach a floating IP to the instance in order to connect to the instance and set up the minion. The current version of salt-cloud doesn't require it, though having it is of no harm either. Newer versions of salt-cloud will use this, and without it, will attempt to find a list of floating IP addresses to use regardless.
• The ssh_key_file and ssh_key_name are the keys that will make it possible to connect to the instance to set up the minion
• The ssh_username parameter, in this case, being that the image used will be ubuntu, will make it possible to not only log in but install the minion
Launch an instance To instantiate a machine based on this profile (example):
# salt-cloud -p hp_ae1_ubuntu ubuntu_instance_1
After several minutes, this will create an instance named ubuntu_instance_1 running in HP Cloud in the US East region and will set up the minion and then return information about the instance once completed.
Manage the instance Once the instance has been created with salt-minion installed, connectivity to it can be verified with Salt:
# salt ubuntu_instance_1 ping
SSH to the instance Additionally, the instance can be accessed via SSH using the floating IP assigned to it
# ssh ubuntu@<floating ip>
Using a private IP Alternatively, in the cloud profile, using the private IP to log into the instance to set up the minion is another option, particularly if salt-cloud is running within the cloud on an instance that is on the same network with all the other instances (minions)
The example below is a modified version of the previous example. Note the use of ssh_interface:
hp_ae1_ubuntu: provider: hp_ae1 image: 9302692b-b787-4b52-a3a6-daebb79cb498 size: standard.small ssh_key_file: /root/keys/test.key ssh_key_name: test ssh_username: ubuntu ssh_interface: private_ips
With this setup, salt-cloud will use the private IP address to ssh into the instance and set up the salt-minion
Getting Started With Joyent Joyent is a public cloud host that supports SmartOS, Linux, FreeBSD, and Windows.
Configuration The Joyent cloud requires three configuration parameters. The user name 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.
my-joyent-config: driver: joyent user: fred password: saltybacon private_key: /root/mykey.pem keyname: mykey
joyent_512: provider: my-joyent-config size: g4-highcpu-512M image: ubuntu-16.04
# salt-cloud --list-sizes my-joyent-config my-joyent-config: ---------- joyent: ---------- g4-highcpu-512M: ---------- default: False description: Compute Optimized 512M RAM - 1 vCPU - 10 GB Disk disk: 10240 group: Compute Optimized id: 14aea8fc-d0f8-11e5-bfe4-a7458dbc6c99 lwps: 4000 memory: 512 name: g4-highcpu-512M swap: 2048 vcpus: 0 version: 1.0.3 ...SNIP...
# salt-cloud --list-images my-joyent-config my-joyent-config: ---------- joyent: ---------- base: ---------- description: A 32-bit SmartOS image with just essential packages installed. Ideal for users who are comfortabl e with setting up their own environment and tools. files: |_ ---------- compression: gzip sha1: b00a77408ddd9aeac85085b68b1cd22a07353956 size: 106918297 homepage: http://wiki.joyent.com/jpc2/Base+Instance id: 00aec452-6e81-11e4-8474-ebfec9a1a911 name: base os: smartos owner: 9dce1460-0c4c-4417-ab8b-25ca478c5a78 public: True published_at: 2014-11-17T17:41:46Z requirements: ---------- state: active type: smartmachine version: 14.3.0
SmartDataCenter This driver can also be used with the Joyent SmartDataCenter project. More details can be found at:
Using SDC requires that an api_host_suffix is set. The default value for this is .api.joyentcloud.com. All characters, including the leading ., should be included:
api_host_suffix: .api.myhostname.com
Miscellaneous Configuration The following configuration items can be set in either provider or profile configuration files.
use_ssl When set to True (the default), attach https:// to any URL that does not already have http:// or https:// included at the beginning. The best practice is to leave the protocol out of the URL, and use this setting to manage it.
verify_ssl When set to True (the default), the underlying web library will verify the SSL certificate. This should only be set to False for debugging.`
Getting Started With Libvirt Libvirt is a toolkit to interact with the virtualization capabilities of recent versions of Linux (and other OSes). This driver Salt cloud provider is currently geared towards libvirt with qemu-kvm.
https://libvirt.org/
Host Dependencies • libvirt >= 1.2.18 (older might work)
Salt-Cloud Dependencies • libvirt-python
Provider Configuration For every KVM host a provider needs to be set up. The provider currently maps to one libvirt daemon (e.g. one KVM host).
Set up the provider cloud configuration file at /etc/salt/cloud.providers or /etc/salt/cloud.providers.d/*.conf.
# Set up a provider with qemu+ssh protocol kvm-via-ssh: driver: libvirt url: qemu+ssh://user@kvm.company.com/system?socket=/var/run/libvirt/libvirt-sock
# Or connect to a local libvirt instance local-kvm: driver: libvirt url: qemu:///system # work around flag for XML validation errors while cloning validate_xml: no
Cloud Profiles Virtual machines get cloned from so called Cloud Profiles. Profiles can be set up at /etc/salt/cloud.profiles or /etc/salt/cloud.profiles.d/*.conf:
• Configure a profile to be used:
centos7: # points back at provider configuration provider: local-kvm base_domain: base-centos7-64 ip_source: ip-learning ssh_username: root password: my-very-secret-password # /tmp is mounted noexec.. do workaround deploy_command: sh /tmp/.saltcloud/deploy.sh script_args: -F # grains to add to the minion grains: clones-are-awesome: true # override minion settings minion: master: 192.168.16.1 master_port: 5506
salt-cloud -p centos7 my-centos7-clone
This will create an instance named my-centos7-clone on the cloud host. Also the minion id will be set to my-centos7-clone.
If the command was executed on the salt-master, its Salt key will automatically be accepted on the master.
salt my-centos7-clone test.version
Required Settings The following settings are always required for libvirt:
centos7: provider: local-kvm # the domain to clone base_domain: base-centos7-64
SSH Key Authentication Instead of specifying a password, an authorized key can be used for the minion setup. Ensure that the ssh user of your base image has the public key you want to use in ~/.ssh/authorized_keys.  If you want to use a non-root user you will likely want to configure salt-cloud to use sudo.
An example using root:
centos7: provider: local-kvm # the domain to clone base_domain: base-centos7-64 ssh_username: root private_key: /path/to/private/key
An example using a non-root user:
centos7: provider: local-kvm # the domain to clone base_domain: base-centos7-64 ssh_username: centos private_key: /path/to/private/key sudo: True sudo_password: "--redacted--"
Optional Settings centos7: # ssh settings # use forwarded agent instead of a local key ssh_agent: True ssh_port: 4910
# credentials ssh_username: root # password will be used for sudo if defined, use sudo_password if using ssh keys password: my-secret-password private_key: /path/to/private/key sudo: True sudo_password: "--redacted--"
# bootstrap options deploy_command: sh /tmp/.saltcloud/deploy.sh script_args: -F
# minion config grains: sushi: more tasty # point at the another master at another port minion: master: 192.168.16.1 master_port: 5506
# libvirt settings # clone_strategy: [ quick | full ] # default is full clone_strategy: quick # ip_source: [ ip-learning | qemu-agent ] # default is ip-learning ip_source: qemu-agent # validate_xml: [ false | true ] # default is true validate_xml: false
The clone_strategy controls how the clone is done. In case of full the disks are copied creating a standalone clone. If quick is used the disks of the base domain are used as backing disks for the clone. This results in nearly instantaneous clones at the expense of slower write performance. The quick strategy has a number of requirements:
• The disks must be of type qcow2
• The base domain must be turned off
• The base domain must not change after creating the clone
The ip_source setting controls how the IP address of the cloned instance is determined.  When using ip-learning the IP is requested from libvirt. This needs a recent libvirt version and may only work for NAT/routed networks where libvirt runs the dhcp server.  Another option is to use qemu-agent this requires that the qemu-agent is installed and configured to run at startup in the base domain.
The validate_xml setting is available to disable xml validation by libvirt when cloning.
See also salt.cloud.clouds.libvirt
Getting Started With Linode Linode is a public cloud host with a focus on Linux instances.
Provider Configuration Configuration Options apikey (Required) The key to use to authenticate with the Linode API.
password (Required) The default password to set on new VMs. Must be 8 characters with at least one lowercase, uppercase, and numeric.
api_version The version of the Linode API to interact with. Defaults to v3.
poll_interval The rate of time in milliseconds to poll the Linode API for changes. Defaults to 500.
ratelimit_sleep The time in seconds to wait before retrying after a ratelimit has been enforced. Defaults to 0.
Example Configuration Set up the provider cloud configuration file at /etc/salt/cloud.providers or /etc/salt/cloud.providers.d/*.conf.
my-linode-provider: driver: linode api_version: v4 apikey: f4ZsmwtB1c7f85Jdu43RgXVDFlNjuJaeIYV8QMftTqKScEB2vSosFSr... password: F00barbaz
For use with APIv3 (deprecated):
my-linode-provider-v3: driver: linode apikey: f4ZsmwtB1c7f85Jdu43RgXVDFlNjuJaeIYV8QMftTqKScEB2vSosFSr... password: F00barbaz
Profile Configuration Configuration Options image  (Required) The image to deploy the boot disk from. This should be an image ID (e.g. linode/ubuntu16.04); official images start with linode/. For APIv3, this would be an image label (i.e. Ubuntu 16.04). See listing images for more options.
location (Required) The location of the VM. This should be a Linode region (e.g. us-east). For APIv3, this would be a datacenter location (e.g. Newark, NJ, USA). See listing locations for more options.
size   (Required) The size of the VM. This should be a Linode instance type ID (e.g. g6-standard-2). For APIv3, this would be a plan ID (e.g. Linode 2GB).  See listing sizes for more options.
password (overrides provider) (*Required) The default password for the VM. Must be provided at the profile or provider level.
assign_private_ip New in version 2016.3.0.
Whether or not to assign a private key to the VM. Defaults to False.
cloneform The name of the Linode to clone from.
disk_size (Deprecated) The amount of disk space to allocate for the OS disk. This has no effect with APIv4; the size of the boot disk will be the remainder of disk space after the swap partition is allocated.
ssh_interface New in version 2016.3.0.
The interface with which to connect over SSH. Valid options are private_ips or public_ips. Defaults to public_ips.
If specifying private_ips, the Linodes must be hosted within the same data center and have the Network Helper enabled on your entire account. The instance that is running the Salt-Cloud provisioning command must also have a private IP assigned to it.
Newer accounts created on Linode have the Network Helper setting enabled by default, account-wide. Legacy accounts do not have this setting enabled by default. To enable the Network Helper on your Linode account, please see Linode's Network Helper documentation.
ssh_pubkey The public key to authorize for SSH with the VM.
swap   The amount of disk space to allocate for the swap partition. Defaults to 256.
Example Configuration Set up a profile configuration in /etc/salt/cloud.profiles.d/:
my-linode-profile: provider: my-linode-provider size: g6-standard-1 image: linode/alpine3.12 location: us-east
The my-linode-profile can be realized now with a salt command:
salt-cloud -p my-linode-profile my-linode-instance
This will create a salt minion instance named my-linode-instance in Linode. If the command was executed on the salt-master, its Salt key will automatically be signed on the master.
salt my-linode-instance test.version
A more advanced configuration utlizing all of the configuration options might look like:
my-linode-profile-advanced: provider: my-linode-provider size: g6-standard-3 image: linode/alpine3.10 location: eu-west password: bogus123X assign_private_ip: true ssh_interface: private_ips ssh_pubkey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQAB... swap_size: 512
A legacy configuration for use with APIv3 might look like:
my-linode-profile-v3: provider: my-linode-provider-v3 size: Nanode 1GB image: Alpine 3.12 location: Fremont, CA, USA
Migrating to APIv4 Linode APIv3 has been deprecated and will be shutdown in the coming months. You can opt-in to using APIv4 by setting the api_version provider configuration option to v4.
When switching to APIv4, you will also need to generate a new token. See here for more information.
Notable Changes Move from label references to ID references. The profile configuration parameters location, size, and image have moved from accepting label based references to IDs. See the profile configuration section for more details.
The ``disk_size`` profile configuration parameter has been deprecated. The parameter will not be taken into account when creating new VMs while targeting APIv4. See the disk_size description under the profile configuration section for more details.
The ``boot`` function no longer requires a ``config_id``. A config can be inferred by the API instead when booting.
The ``clone`` function has renamed parameters to match convention. The old version of these parameters will not be supported when targeting APIv4.  * datacenter_id has been deprecated in favor of location.  * plan_id has been deprecated in favor of size.
The ``get_plan_id`` function has been deprecated and will not be supported by APIv4. IDs are now the only way of referring to a "plan" (or type/size).
Query Utilities Listing Sizes Available sizes can be obtained by running one of:
salt-cloud --list-sizes my-linode-provider
salt-cloud -f avail_sizes my-linode-provider
This will list all Linode sizes/types which can be referenced in VM profiles.
my-linode-config: g6-standard-1: ---------- class: standard disk: 51200 gpus: 0 id: g6-standard-1 label: Linode 2GB memory: 2048 network_out: 2000 price: ---------- hourly: 0.015 monthly: 10.0 successor: None transfer: 2000 vcpus: 1 addons: ---------- backups: ---------- price: ---------- hourly: 0.004 monthly: 2.5 ...SNIP...
Listing Images Available images can be obtained by running one of:
salt-cloud --list-images my-linode-provider
salt-cloud -f avail_images my-linode-provider
This will list all Linode images which can be referenced in VM profiles. Official images are available under the linode namespace.
my-linode-config: ---------- linode: ---------- linode/alpine3.10: ---------- created: 2019-06-20T17:17:11 created_by: linode deprecated: False description: None eol: 2021-05-01T04:00:00 expiry: None id: linode/alpine3.10 is_public: True label: Alpine 3.10 size: 300 type: manual vendor: Alpine ...SNIP...
Listing Locations Available locations can be obtained by running one of:
salt-cloud --list-locations my-linode-provider
salt-cloud -f avail_locations my-linode-provider
This will list all Linode regions which can be referenced in VM profiles.
my-linode-config: ---------- linode: ---------- us-east: ---------- capabilities: - Linodes - NodeBalancers - Block Storage - Object Storage - GPU Linodes - Kubernetes country: us id: us-east status: ok ...SNIP...
Cloning To clone a Linode, add a profile with a clonefrom key, and a script_args: -C.  clonefrom should be the name of the Linode that is the source for the clone.  script_args: -C passes a -C to the salt-bootstrap script, which only configures the minion and doesn't try to install a new copy of salt-minion. This way the minion gets new keys and the keys get pre-seeded on the master, and the /etc/salt/minion file has the right minion 'id:' declaration.
Cloning requires a post 2015-02-01 salt-bootstrap.
It is safest to clone a stopped machine. To stop a machine run
salt-cloud -a stop machine_to_clone
To create a new machine based on another machine, add an entry to your linode cloud profile that looks like this:
li-clone: provider: my-linode-config clonefrom: machine_to_clone script_args: -C -F
Then run salt-cloud as normal, specifying -p li-clone. The profile name can be anything; It doesn't have to be li-clone.
clonefrom: is the name of an existing machine in Linode from which to clone.  Script_args: -C -F is necessary to avoid re-deploying Salt via salt-bootstrap.  -C will just re-deploy keys so the new minion will not have a duplicate key or minion_id on the Master, and -F will force a rewrite of the Minion config file on the new Minion. If -F isn't provided, the new Minion will have the machine_to_clone's Minion ID, instead of its own Minion ID, which can cause problems.
NOTE: Pull Request #733 to the salt-bootstrap repo makes the -F argument non-necessary. Once that change is released into a stable version of the Bootstrap Script, the -C argument will be sufficient for the script_args setting.
If the machine_to_clone does not have Salt installed on it, refrain from using the script_args: -C -F altogether, because the new machine will need to have Salt installed.
Getting Started With LXC The LXC module is designed to install Salt in an LXC container on a controlled and possibly remote minion.
In other words, Salt will connect to a minion, then from that minion:
• Provision and configure a container for networking access
• Use those modules to deploy salt and re-attach to master.
• lxc runner
• lxc module
• seed
Limitations • You can only act on one minion and one provider at a time.
• Listing images must be targeted to a particular LXC provider (nothing will be outputted with all)
Operation Salt's LXC support does use lxc.init via the lxc.cloud_init_interface and seeds the minion via seed.mkconfig.
You can provide to those lxc VMs a profile and a network profile like if you were directly using the minion module.
Order of operation:
• Create the LXC container on the desired minion (clone or template)
• Change LXC config options (if any need to be changed)
• Start container
• Change base passwords if any
• Change base DNS configuration if necessary
• Wait for LXC container to be up and ready for ssh
• Test SSH connection and bailout in error
• Upload deploy script and seeds, then re-attach the minion.
Provider configuration Here is a simple provider configuration:
# Note: This example goes in /etc/salt/cloud.providers or any file in the # /etc/salt/cloud.providers.d/ directory. devhost10-lxc: target: devhost10 driver: lxc
Profile configuration Please read tutorial-lxc before anything else.  And specially tutorial-lxc-profiles.
Here are the options to configure your containers:
target Host minion id to install the lxc Container into
lxc_profile Name of the profile or inline options for the LXC vm creation/cloning, please see tutorial-lxc-profiles-container.
network_profile Name of the profile or inline options for the LXC vm network settings, please see tutorial-lxc-profiles-network.
nic_opts Totally optional.  Per interface new-style configuration options mappings which will override any profile default option:
eth0: {'mac': '00:16:3e:01:29:40', 'gateway': None, (default) 'link': 'br0', (default) 'gateway': None, (default) 'netmask': '', (default) 'ip': '22.1.4.25'}}
password password for root and sysadmin users
dnsservers List of DNS servers to use. This is optional.
minion minion configuration (see Minion Configuration in Salt Cloud)
bootstrap_delay specify the time to wait (in seconds) between container creation and salt bootstrap execution. It is useful to ensure that all essential services have started before the bootstrap script is executed. By default there's no wait time between container creation and bootstrap unless you are on systemd where we wait that the system is no more in starting state.
bootstrap_shell shell for bootstraping script (default: /bin/sh)
script defaults to salt-boostrap
script_args arguments which are given to the bootstrap script.  the {0} placeholder will be replaced by the path which contains the minion config and key files, eg:
script_args="-c {0}"
Using profiles:
# Note: This example would go in /etc/salt/cloud.profiles or any file in the # /etc/salt/cloud.profiles.d/ directory. devhost10-lxc: provider: devhost10-lxc lxc_profile: foo network_profile: bar minion: master: 10.5.0.1 master_port: 4506
Using inline profiles (eg to override the network bridge):
devhost11-lxc: provider: devhost10-lxc lxc_profile: clone_from: foo network_profile: etho: link: lxcbr0 minion: master: 10.5.0.1 master_port: 4506
Using a lxc template instead of a clone:
devhost11-lxc: provider: devhost10-lxc lxc_profile: template: ubuntu # options: #   release: trusty network_profile: etho: link: lxcbr0 minion: master: 10.5.0.1 master_port: 4506
Static ip:
# Note: This example would go in /etc/salt/cloud.profiles or any file in the # /etc/salt/cloud.profiles.d/ directory. devhost10-lxc: provider: devhost10-lxc nic_opts: eth0: ipv4: 10.0.3.9 minion: master: 10.5.0.1 master_port: 4506
DHCP:
# Note: This example would go in /etc/salt/cloud.profiles or any file in the # /etc/salt/cloud.profiles.d/ directory. devhost10-lxc: provider: devhost10-lxc minion: master: 10.5.0.1 master_port: 4506
Driver Support • Container creation
• Image listing (LXC templates)
• Running container information (IP addresses, etc.)
Getting Started With 1and1 1&1 is one of the world’s leading Web hosting providers. 1&1 currently offers a wide range of Web hosting products, including email solutions and high-end servers in 10 different countries including Germany, Spain, Great Britain and the United States.  From domains to 1&1 MyWebsite to eBusiness solutions like Cloud Hosting and Web servers for complex tasks, 1&1 is well placed to deliver a high quality service to its customers. All 1&1 products are hosted in 1&1‘s high-performance, green data centers in the USA and Europe.
Dependencies • 1and1 >= 1.2.0
Configuration • Using the new format, set up the cloud configuration at /etc/salt/cloud.providers or /etc/salt/cloud.providers.d/oneandone.conf:
my-oneandone-config: driver: oneandone
# Set the location of the salt-master # minion: master: saltmaster.example.com
# Configure oneandone authentication credentials # api_token: <api_token> ssh_private_key: /path/to/id_rsa ssh_public_key: /path/to/id_rsa.pub
Authentication The api_key is used for API authorization. This token can be obtained from the CloudPanel in the Management section below Users.
Profiles Here is an example of a profile:
oneandone_fixed_size: provider: my-oneandone-config description: Small instance size server fixed_instance_size: S appliance_id: 8E3BAA98E3DFD37857810E0288DD8FBA
oneandone_custom_size: provider: my-oneandone-config description: Custom size server vcore: 2 cores_per_processor: 2 ram: 8 appliance_id: 8E3BAA98E3DFD37857810E0288DD8FBA hdds: - is_main: true size: 20 - is_main: false size: 20
The following list explains some of the important properties.
fixed_instance_size_id When creating a server, either fixed_instance_size_id or custom hardware params containing vcore, cores_per_processor, ram, and hdds must be provided.  Can be one of the IDs listed among the output of the following command:
salt-cloud --list-sizes oneandone
vcore  Total amount of processors.
cores_per_processor Number of cores per processor.
ram    RAM memory size in GB.
hdds   Hard disks.
appliance_id ID of the image that will be installed on server.  Can be one of the IDs listed in the output of the following command:
salt-cloud --list-images oneandone
datacenter_id ID of the datacenter where the server will be created.  Can be one of the IDs listed in the output of the following command:
salt-cloud --list-locations oneandone
description Description of the server.
password Password of the server. Password must contain more than 8 characters using uppercase letters, numbers and other special symbols.
power_on Power on server after creation. Default is set to true.
firewall_policy_id Firewall policy ID. If it is not provided, the server will assign the best firewall policy, creating a new one if necessary. If the parameter is sent with a 0 value, the server will be created with all ports blocked.
ip_id  IP address ID.
load_balancer_id Load balancer ID.
monitoring_policy_id Monitoring policy ID.
deploy Set to False if Salt should not be installed on the node.
wait_for_timeout The timeout to wait in seconds for provisioning resources such as servers.  The default wait_for_timeout is 15 minutes.
public_key_ids List of public key IDs (ssh key).
Functions • Create an SSH key
sudo salt-cloud -f create_ssh_key my-oneandone-config name='SaltTest' description='SaltTestDescription'
• Create a block storage
sudo salt-cloud -f create_block_storage my-oneandone-config name='SaltTest2' description='SaltTestDescription' size=50 datacenter_id='5091F6D8CBFEF9C26ACE957C652D5D49'
For more information concerning cloud profiles, see here.
Getting Started with OpenNebula OpenNebula is an open-source solution for the comprehensive management of virtualized data centers to enable the mixed use of private, public, and hybrid IaaS clouds.
Dependencies The driver requires Python's lxml library to be installed. It also requires an OpenNebula installation running version 4.12 or greater.
my-opennebula-provider: # Set up the location of the salt master # minion: master: saltmaster.example.com
# Define xml_rpc setting which Salt-Cloud uses to connect to the OpenNebula API. Required. # xml_rpc: http://localhost:2633/RPC2
# Define the OpenNebula access credentials. This can be the main "oneadmin" user that OpenNebula uses as the # OpenNebula main admin, or it can be a user defined in the OpenNebula instance. Required. # user: oneadmin password: JHGhgsayu32jsa
# Define the private key location that is used by OpenNebula to access new VMs. This setting is required if # provisioning new VMs or accessing VMs previously created with the associated public key. # private_key: /path/to/private/key
driver: opennebula
Access Credentials The Salt Cloud driver for OpenNebula was written using OpenNebula's native XML RPC API. Every interaction with OpenNebula's API requires a username and password to make the connection from the machine running Salt Cloud to API running on the OpenNebula instance. Based on the access credentials passed in, OpenNebula filters the commands that the user can perform or the information for which the user can query. For example, the images that a user can view with a --list-images command are the images that the connected user and the connected user's groups can access.
Key Pairs Salt Cloud needs to be able to access a virtual machine in order to install the Salt Minion by using a public/private key pair. The virtual machine will need to be seeded with the public key, which is laid down by the OpenNebula template. Salt Cloud then uses the corresponding private key, provided by the private_key setting in the cloud provider file, to SSH into the new virtual machine.
To seed the virtual machine with the public key, the public key must be added to the OpenNebula template. If using the OpenNebula web interface, navigate to the template, then click Update. Click the Context tab. Under the Network & SSH section, click Add SSH Contextualization and paste the public key in the Public Key box.  Don't forget to save your changes by clicking the green Update button.
NOTE: The key pair must not have a pass-phrase.
Cloud Profiles Set up an initial profile at either /etc/salt/cloud.profiles or the /etc/salt/cloud.profiles.d/ directory.
my-opennebula-profile: provider: my-opennebula-provider image: Ubuntu-14.04
salt-cloud -p my-opennebula-profile my-new-vm
This will create a new instance named my-new-vm in OpenNebula. The minion that is installed on this instance will have a minion id of my-new-vm. If the command was executed on the salt-master, its Salt key will automatically be signed on the master.
salt my-new-vm test.version
OpenNebula uses an image --> template --> virtual machine paradigm where the template draws on the image, or disk, and virtual machines are created from templates. Because of this, there is no need to define a size in the cloud profile. The size of the virtual machine is defined in the template.
Change Disk Size You can now change the size of a VM on creation by cloning an image and expanding the size. You can accomplish this by the following cloud profile settings below.
my-opennebula-profile: provider: my-opennebula-provider image: Ubuntu-14.04 disk: disk0: disk_type: clone size: 8096 image: centos7-base-image-v2 disk1: disk_type: volatile type: swap size: 4096 disk2: disk_type: volatile size: 4096 type: fs format: ext3
There are currently two different disk_types a user can use: volatile and clone. Clone which is required when specifying devices will clone an image in open nebula and will expand it to the size specified in the profile settings. By default this will clone the image attached to the template specified in the profile but a user can add the image argument under the disk definition.
For example the profile below will not use Ubuntu-14.04 for the cloned disk image. It will use the centos7-base-image image:
my-opennebula-profile: provider: my-opennebula-provider image: Ubuntu-14.04 disk: disk0: disk_type: clone size: 8096 image: centos7-base-image
If you want to use the image attached to the template set in the profile you can simply remove the image argument as show below.  The profile below will clone the image Ubuntu-14.04 and expand the disk to 8GB.:
my-opennebula-profile: provider: my-opennebula-provider image: Ubuntu-14.04 disk: disk0: disk_type: clone size: 8096
A user can also currently specify swap or fs disks. Below is an example of this profile setting:
my-opennebula-profile: provider: my-opennebula-provider image: Ubuntu-14.04 disk: disk0: disk_type: clone size: 8096 disk1: disk_type: volatile type: swap size: 4096 disk2: disk_type: volatile size: 4096 type: fs format: ext3
The example above will attach both a swap disk and a ext3 filesystem with a size of 4GB. To note if you define other disks you have to define the image disk to clone because the template will write over the entire 'DISK=[]' template definition on creation.
Required Settings The following settings are always required for OpenNebula:
my-opennebula-config: xml_rpc: http://localhost:26633/RPC2 user: oneadmin password: JHGhgsayu32jsa driver: opennebula
Required Settings for VM Deployment The settings defined in the Required Settings section are required for all interactions with OpenNebula. However, when deploying a virtual machine via Salt Cloud, an additional setting, private_key, is also required:
my-opennebula-config: private_key: /path/to/private/key
Listing Images Images can be queried on OpenNebula by passing the --list-images argument to Salt Cloud:
salt-cloud --list-images opennebula
Listing Locations In OpenNebula, locations are defined as hosts. Locations, or "hosts", can be querried on OpenNebula by passing the --list-locations argument to Salt Cloud:
salt-cloud --list-locations opennebula
Listing Sizes Sizes are defined by templates in OpenNebula. As such, the --list-sizes call returns an empty dictionary since there are no sizes to return.
Additional OpenNebula API Functionality The Salt Cloud driver for OpenNebula was written using OpenNebula's native XML RPC API. As such, many --function and --action calls were added to the OpenNebula driver to enhance support for an OpenNebula infrastructure with additional control from Salt Cloud. See the OpenNebula function definitions for more information.
Access via DNS entry instead of IP Some OpenNebula installations do not assign IP addresses to new VMs, instead they establish the new VM's hostname based on OpenNebula's name of the VM, and then allocate an IP out of DHCP with dynamic DNS attaching the hostname.  This driver supports this behavior by adding the entry fqdn_base to the driver configuration or the OpenNebula profile with a value matching the base fully-qualified domain.  For example:
my-opennebula-provider: [...] fqdn_base: corp.example.com [...]
Getting Started with Openstack See salt.cloud.clouds.openstack
Getting Started With Parallels Parallels Cloud Server is a product by Parallels that delivers a cloud hosting solution. The PARALLELS module for Salt Cloud enables you to manage instances hosted using PCS. Further information can be found at:
http://www.parallels.com/products/pcs/
• Using the old format, set up the cloud configuration at /etc/salt/cloud:
# Set the PARALLELS access credentials (see below) # PARALLELS.user: myuser PARALLELS.password: badpass
# Set the access URL for your PARALLELS host # PARALLELS.url: https://api.cloud.xmission.com:4465/paci/v1.0/
• Using the new format, set up the cloud configuration at /etc/salt/cloud.providers or /etc/salt/cloud.providers.d/parallels.conf:
my-parallels-config: # Set up the location of the salt master # minion: master: saltmaster.example.com
# Set the PARALLELS access credentials (see below) # user: myuser password: badpass
# Set the access URL for your PARALLELS provider # url: https://api.cloud.xmission.com:4465/paci/v1.0/ driver: parallels
Access Credentials The user, password, and url will be provided to you by your cloud host. These are all required in order for the PARALLELS driver to work.
Cloud Profiles Set up an initial profile at /etc/salt/cloud.profiles or /etc/salt/cloud.profiles.d/parallels.conf:
parallels-ubuntu: provider: my-parallels-config image: ubuntu-12.04-x86_64
# salt-cloud -p parallels-ubuntu myubuntu
This will create an instance named myubuntu on the cloud host. The minion that is installed on this instance will have an id of myubuntu.  If the command was executed on the salt-master, its Salt key will automatically be signed on the master.
# salt myubuntu test.version
Required Settings The following settings are always required for PARALLELS:
• Using the old cloud configuration format:
PARALLELS.user: myuser PARALLELS.password: badpass PARALLELS.url: https://api.cloud.xmission.com:4465/paci/v1.0/
• Using the new cloud configuration format:
my-parallels-config: user: myuser password: badpass url: https://api.cloud.xmission.com:4465/paci/v1.0/ driver: parallels
Optional Settings Unlike other cloud providers in Salt Cloud, Parallels does not utilize a size setting. This is because Parallels allows the end-user to specify a more detailed configuration for their instances than is allowed by many other cloud hosts. The following options are available to be used in a profile, with their default settings listed.
# Description of the instance. Defaults to the instance name. desc: <instance_name>
# How many CPU cores, and how fast they are (in MHz) cpu_number: 1 cpu_power: 1000
# How many megabytes of RAM ram: 256
# Bandwidth available, in kbps bandwidth: 100
# How many public IPs will be assigned to this instance ip_num: 1
# Size of the instance disk (in GiB) disk_size: 10
# Username and password ssh_username: root password: <value from PARALLELS.password>
# The name of the image, from ``salt-cloud --list-images parallels`` image: ubuntu-12.04-x86_64
Getting Started With ProfitBricks ProfitBricks provides an enterprise-grade Infrastructure as a Service (IaaS) solution that can be managed through a browser-based "Data Center Designer" (DCD) tool or via an easy to use API. A unique feature of the ProfitBricks platform is that it allows you to define your own settings for cores, memory, and disk size without being tied to a particular server size.
Dependencies • profitbricks >= 4.1.1
Configuration • Using the new format, set up the cloud configuration at /etc/salt/cloud.providers or /etc/salt/cloud.providers.d/profitbricks.conf:
my-profitbricks-config: driver: profitbricks
# Configure ProfitBricks authentication credentials # username: user@domain.com password: 123456 # datacenter is the UUID of a pre-existing virtual data center. datacenter: 9e6709a0-6bf9-4bd6-8692-60349c70ce0e # delete_volumes is forcing a deletion of all volumes attached to a server on a deletion of a server delete_volumes: true # Connect to public LAN ID 1. public_lan: 1 ssh_public_key: /path/to/id_rsa.pub ssh_private_key: /path/to/id_rsa
Virtual Data Center ProfitBricks uses the concept of Virtual Data Centers. These are logically separated from one another and allow you to have a self-contained environment for all servers, volumes, networking, snapshots, and so forth.
A list of existing virtual data centers can be retrieved with the following command:
salt-cloud -f list_datacenters my-profitbricks-config
A new data center can be created with the following command:
salt-cloud -f create_datacenter my-profitbricks-config name=example location=us/las description="my description"
Authentication The username and password are the same as those used to log into the ProfitBricks "Data Center Designer".
profitbricks_staging provider: my-profitbricks-config size: Micro Instance image_alias: 'ubuntu:latest' # image or image_alias must be provided # image: 2f98b678-6e7e-11e5-b680-52540066fee9 cores: 2 ram: 4096 public_lan: 1 private_lan: 2 ssh_public_key: /path/to/id_rsa.pub ssh_private_key: /path/to/id_rsa ssh_interface: private_lan
profitbricks_production: provider: my-profitbricks-config image: Ubuntu-15.10-server-2016-05-01 image_password: MyPassword1 disk_type: SSD disk_size: 40 cores: 8 cpu_family: INTEL_XEON ram: 32768 public_lan: 1 public_ips: - 172.217.18.174 private_lan: 2 private_ips: - 192.168.100.10 public_firewall_rules: Allow SSH: protocol: TCP source_ip: 1.2.3.4 port_range_start: 22 port_range_end: 22 Allow Ping: protocol: ICMP icmp_type: 8 ssh_public_key: /path/to/id_rsa.pub ssh_private_key: /path/to/id_rsa ssh_interface: private_lan volumes: db_data: disk_size: 500 db_log: disk_size: 50 disk_type: SSD
# salt-cloud --list-locations my-profitbricks-config
Images can be obtained using the --list-sizes option for the salt-cloud command:
# salt-cloud --list-images my-profitbricks-config
# salt-cloud --list-sizes my-profitbricks-config
Changed in version 2019.2.0: One or more public IP address can be reserved with the following command:
# salt-cloud -f reserve_ipblock  my-profitbricks-config location='us/ewr' size=1
Profile Specifics: The following list explains some of the important properties.
• size - Can be one of the options listed in the output of the following command:
salt-cloud --list-sizes my-profitbricks-config
• image - Can be one of the options listed in the output of the following command:
salt-cloud --list-images my-profitbricks-config
• image_alias - Can be one of the options listed in the output of the following command:
salt-cloud -f list_images my-profitbricks-config
• disk_size - This option allows you to override the size of the disk as defined by the size. The disk size is set in gigabytes (GB).
• disk_type - This option allow the disk type to be set to HDD or SSD. The default is HDD.
• image_password - A password is set on the image for the "root" or "Administrator" account.  This field may only be set during volume creation.  Only valid with ProfitBricks supplied HDD (not ISO) images. The password must contain at least 8 and no more than 50 characters. Only these characters are allowed: [a-z][A-Z][0-9]
• cores - This option allows you to override the number of CPU cores as defined by the size.
• ram - This option allows you to override the amount of RAM defined by the size. The value must be a multiple of 256, e.g. 256, 512, 768, 1024, and so forth.
• public_lan - This option will connect the server to the specified public LAN. If no LAN exists, then a new public LAN will be created. The value accepts a LAN ID (integer).
• public_ips - Public IPs assigned to the NIC in the public LAN.
• public_firewall_rules - This option allows for a list of firewall rules assigned to the public network interface.
Firewall Rule Name: protocol: <protocol> (TCP, UDP, ICMP) source_mac: <source-mac> source_ip: <source-ip> target_ip: <target-ip> port_range_start: <port-range-start> port_range_end: <port-range-end> icmp_type: <icmp-type> icmp_code: <icmp-code>
• private_lan - This option will connect the server to the specified private LAN. If no LAN exists, then a new private LAN will be created. The value accepts a LAN ID (integer).
• private_ips - Private IPs assigned in the private LAN. NAT setting is ignored when this setting is active.
• private_firewall_rules - This option allows for a list of firewall rules assigned to the private network interface.
• ssh_private_key - Full path to the SSH private key file
• ssh_public_key - Full path to the SSH public key file
• ssh_interface - This option will use the private LAN IP for node connections (such as as bootstrapping the node) instead of the public LAN IP.  The value accepts 'private_lan'.
• cpu_family - This option allow the CPU family to be set to AMD_OPTERON or INTEL_XEON.  The default is AMD_OPTERON.
• volumes - This option allows a list of additional volumes by name that will be created and attached to the server. Each volume requires 'disk_size' and, optionally, 'disk_type'. The default is HDD.
• deploy - Set to False if Salt should not be installed on the node.
• wait_for_timeout - The timeout to wait in seconds for provisioning resources such as servers.  The default wait_for_timeout is 15 minutes.
Getting Started With Proxmox Proxmox Virtual Environment is a complete server virtualization management solution, based on OpenVZ(in Proxmox up to 3.4)/LXC(from Proxmox 4.0 and up) and full virtualization with KVM.  Further information can be found at:
https://www.proxmox.com
Dependencies • IPy >= 0.81
• requests >= 2.2.1
Please note: This module allows you to create OpenVZ/LXC containers and KVM VMs, but installing Salt on it will only be done on containers rather than a KVM virtual machine.
• Set up the cloud configuration at /etc/salt/cloud.providers or /etc/salt/cloud.providers.d/proxmox.conf:
my-proxmox-config: # Set up the location of the salt master # minion: master: saltmaster.example.com
# Set the PROXMOX access credentials (see below) # user: myuser@pve password: badpass
# Set the access URL for your PROXMOX host # url: your.proxmox.host driver: proxmox
Access Credentials The user, password, and url will be provided to you by your cloud host. These are all required in order for the PROXMOX driver to work.
Cloud Profiles Set up an initial profile at /etc/salt/cloud.profiles or /etc/salt/cloud.profiles.d/proxmox.conf:
proxmox-ubuntu: provider: my-proxmox-config image: local:vztmpl/ubuntu-12.04-standard_12.04-1_amd64.tar.gz technology: lxc
# host needs to be set to the configured name of the proxmox host # and not the ip address or FQDN of the server host: myvmhost ip_address: 192.168.100.155 password: topsecret
# salt-cloud -p proxmox-ubuntu myubuntu
This will create an instance named myubuntu on the cloud host. The minion that is installed on this instance will have a hostname of myubuntu.  If the command was executed on the salt-master, its Salt key will automatically be signed on the master.