summaryrefslogtreecommitdiff
path: root/doc/rtd/topics/datasources
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rtd/topics/datasources')
-rw-r--r--doc/rtd/topics/datasources/altcloud.rst23
-rw-r--r--doc/rtd/topics/datasources/azure.rst117
-rw-r--r--doc/rtd/topics/datasources/cloudstack.rst4
-rw-r--r--doc/rtd/topics/datasources/configdrive.rst22
-rw-r--r--doc/rtd/topics/datasources/digitalocean.rst6
-rw-r--r--doc/rtd/topics/datasources/e24cloud.rst9
-rw-r--r--doc/rtd/topics/datasources/ec2.rst22
-rw-r--r--doc/rtd/topics/datasources/exoscale.rst68
-rw-r--r--doc/rtd/topics/datasources/nocloud.rst18
-rw-r--r--doc/rtd/topics/datasources/opennebula.rst30
-rw-r--r--doc/rtd/topics/datasources/openstack.rst3
-rw-r--r--doc/rtd/topics/datasources/oracle.rst25
-rw-r--r--doc/rtd/topics/datasources/rbxcloud.rst25
-rw-r--r--doc/rtd/topics/datasources/smartos.rst12
-rw-r--r--doc/rtd/topics/datasources/zstack.rst37
15 files changed, 298 insertions, 123 deletions
diff --git a/doc/rtd/topics/datasources/altcloud.rst b/doc/rtd/topics/datasources/altcloud.rst
index eeb197f2..9d7e3de1 100644
--- a/doc/rtd/topics/datasources/altcloud.rst
+++ b/doc/rtd/topics/datasources/altcloud.rst
@@ -3,24 +3,25 @@
Alt Cloud
=========
-The datasource altcloud will be used to pick up user data on `RHEVm`_ and `vSphere`_.
+The datasource altcloud will be used to pick up user data on `RHEVm`_ and
+`vSphere`_.
RHEVm
-----
For `RHEVm`_ v3.0 the userdata is injected into the VM using floppy
-injection via the `RHEVm`_ dashboard "Custom Properties".
+injection via the `RHEVm`_ dashboard "Custom Properties".
The format of the Custom Properties entry must be:
::
-
+
floppyinject=user-data.txt:<base64 encoded data>
For example to pass a simple bash script:
.. sourcecode:: sh
-
+
% cat simple_script.bash
#!/bin/bash
echo "Hello Joe!" >> /tmp/JJV_Joe_out.txt
@@ -38,7 +39,7 @@ set the "Custom Properties" when creating the RHEMv v3.0 VM to:
**NOTE:** The prefix with file name must be: ``floppyinject=user-data.txt:``
It is also possible to launch a `RHEVm`_ v3.0 VM and pass optional user
-data to it using the Delta Cloud.
+data to it using the Delta Cloud.
For more information on Delta Cloud see: http://deltacloud.apache.org
@@ -46,12 +47,12 @@ vSphere
-------
For VMWare's `vSphere`_ the userdata is injected into the VM as an ISO
-via the cdrom. This can be done using the `vSphere`_ dashboard
+via the cdrom. This can be done using the `vSphere`_ dashboard
by connecting an ISO image to the CD/DVD drive.
To pass this example script to cloud-init running in a `vSphere`_ VM
set the CD/DVD drive when creating the vSphere VM to point to an
-ISO on the data store.
+ISO on the data store.
**Note:** The ISO must contain the user data.
@@ -61,13 +62,13 @@ Create the ISO
^^^^^^^^^^^^^^
.. sourcecode:: sh
-
+
% mkdir my-iso
NOTE: The file name on the ISO must be: ``user-data.txt``
.. sourcecode:: sh
-
+
% cp simple_script.bash my-iso/user-data.txt
% genisoimage -o user-data.iso -r my-iso
@@ -75,7 +76,7 @@ Verify the ISO
^^^^^^^^^^^^^^
.. sourcecode:: sh
-
+
% sudo mkdir /media/vsphere_iso
% sudo mount -o loop user-data.iso /media/vsphere_iso
% cat /media/vsphere_iso/user-data.txt
@@ -84,7 +85,7 @@ Verify the ISO
Then, launch the `vSphere`_ VM the ISO user-data.iso attached as a CDROM.
It is also possible to launch a `vSphere`_ VM and pass optional user
-data to it using the Delta Cloud.
+data to it using the Delta Cloud.
For more information on Delta Cloud see: http://deltacloud.apache.org
diff --git a/doc/rtd/topics/datasources/azure.rst b/doc/rtd/topics/datasources/azure.rst
index f73c3694..1427fb3d 100644
--- a/doc/rtd/topics/datasources/azure.rst
+++ b/doc/rtd/topics/datasources/azure.rst
@@ -5,9 +5,30 @@ Azure
This datasource finds metadata and user-data from the Azure cloud platform.
-Azure Platform
---------------
-The azure cloud-platform provides initial data to an instance via an attached
+walinuxagent
+------------
+walinuxagent has several functions within images. For cloud-init
+specifically, the relevant functionality it performs is to register the
+instance with the Azure cloud platform at boot so networking will be
+permitted. For more information about the other functionality of
+walinuxagent, see `Azure's documentation
+<https://github.com/Azure/WALinuxAgent#introduction>`_ for more details.
+(Note, however, that only one of walinuxagent's provisioning and cloud-init
+should be used to perform instance customisation.)
+
+If you are configuring walinuxagent yourself, you will want to ensure that you
+have `Provisioning.UseCloudInit
+<https://github.com/Azure/WALinuxAgent#provisioningusecloudinit>`_ set to
+``y``.
+
+
+Builtin Agent
+-------------
+An alternative to using walinuxagent to register to the Azure cloud platform
+is to use the ``__builtin__`` agent command. This section contains more
+background on what that code path does, and how to enable it.
+
+The Azure cloud platform provides initial data to an instance via an attached
CD formatted in UDF. That CD contains a 'ovf-env.xml' file that provides some
information. Additional information is obtained via interaction with the
"endpoint".
@@ -23,44 +44,36 @@ information in json format to /run/cloud-init/dhclient.hook/<interface>.json.
In order for cloud-init to leverage this method to find the endpoint, the
cloud.cfg file must contain:
-datasource:
- Azure:
- set_hostname: False
- agent_command: __builtin__
+.. sourcecode:: yaml
+
+ datasource:
+ Azure:
+ set_hostname: False
+ agent_command: __builtin__
If those files are not available, the fallback is to check the leases file
for the endpoint server (again option 245).
You can define the path to the lease file with the 'dhclient_lease_file'
-configuration. The default value is /var/lib/dhcp/dhclient.eth0.leases.
+configuration.
- dhclient_lease_file: /var/lib/dhcp/dhclient.eth0.leases
-
-walinuxagent
-------------
-In order to operate correctly, cloud-init needs walinuxagent to provide much
-of the interaction with azure. In addition to "provisioning" code, walinux
-does the following on the agent is a long running daemon that handles the
-following things:
-- generate a x509 certificate and send that to the endpoint
-waagent.conf config
-^^^^^^^^^^^^^^^^^^^
-in order to use waagent.conf with cloud-init, the following settings are recommended. Other values can be changed or set to the defaults.
+IMDS
+----
+Azure provides the `instance metadata service (IMDS)
+<https://docs.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service>`_
+which is a REST service on ``169.254.169.254`` providing additional
+configuration information to the instance. Cloud-init uses the IMDS for:
- ::
-
- # disabling provisioning turns off all 'Provisioning.*' function
- Provisioning.Enabled=n
- # this is currently not handled by cloud-init, so let walinuxagent do it.
- ResourceDisk.Format=y
- ResourceDisk.MountPoint=/mnt
+- network configuration for the instance which is applied per boot
+- a preprovisioing gate which blocks instance configuration until Azure fabric
+ is ready to provision
Configuration
-------------
The following configuration can be set for the datasource in system
-configuration (in `/etc/cloud/cloud.cfg` or `/etc/cloud/cloud.cfg.d/`).
+configuration (in ``/etc/cloud/cloud.cfg`` or ``/etc/cloud/cloud.cfg.d/``).
The settings that may be configured are:
@@ -69,20 +82,33 @@ The settings that may be configured are:
provided command to obtain metadata.
* **apply_network_config**: Boolean set to True to use network configuration
described by Azure's IMDS endpoint instead of fallback network config of
- dhcp on eth0. Default is True. For Ubuntu 16.04 or earlier, default is False.
+ dhcp on eth0. Default is True. For Ubuntu 16.04 or earlier, default is
+ False.
* **data_dir**: Path used to read metadata files and write crawled data.
* **dhclient_lease_file**: The fallback lease file to source when looking for
custom DHCP option 245 from Azure fabric.
* **disk_aliases**: A dictionary defining which device paths should be
interpreted as ephemeral images. See cc_disk_setup module for more info.
* **hostname_bounce**: A dictionary Azure hostname bounce behavior to react to
- metadata changes.
+ metadata changes. The '``hostname_bounce: command``' entry can be either
+ the literal string 'builtin' or a command to execute. The command will be
+ invoked after the hostname is set, and will have the 'interface' in its
+ environment. If ``set_hostname`` is not true, then ``hostname_bounce``
+ will be ignored. An example might be:
+
+ ``command: ["sh", "-c", "killall dhclient; dhclient $interface"]``
+
* **hostname_bounce**: A dictionary Azure hostname bounce behavior to react to
metadata changes. Azure will throttle ifup/down in some cases after metadata
has been updated to inform dhcp server about updated hostnames.
* **set_hostname**: Boolean set to True when we want Azure to set the hostname
based on metadata.
+Configuration for the datasource can also be read from a
+``dscfg`` entry in the ``LinuxProvisioningConfigurationSet``. Content in
+dscfg node is expected to be base64 encoded yaml content, and it will be
+merged into the 'datasource: Azure' entry.
+
An example configuration with the default values is provided below:
.. sourcecode:: yaml
@@ -143,37 +169,6 @@ Example:
</LinuxProvisioningConfigurationSet>
</wa:ProvisioningSection>
-Configuration
--------------
-Configuration for the datasource can be read from the system config's or set
-via the `dscfg` entry in the `LinuxProvisioningConfigurationSet`. Content in
-dscfg node is expected to be base64 encoded yaml content, and it will be
-merged into the 'datasource: Azure' entry.
-
-The '``hostname_bounce: command``' entry can be either the literal string
-'builtin' or a command to execute. The command will be invoked after the
-hostname is set, and will have the 'interface' in its environment. If
-``set_hostname`` is not true, then ``hostname_bounce`` will be ignored.
-
-An example might be:
- command: ["sh", "-c", "killall dhclient; dhclient $interface"]
-
-.. code:: yaml
-
- datasource:
- agent_command
- Azure:
- agent_command: [service, walinuxagent, start]
- set_hostname: True
- hostname_bounce:
- # the name of the interface to bounce
- interface: eth0
- # policy can be 'on', 'off' or 'force'
- policy: on
- # the method 'bounce' command.
- command: "builtin"
- hostname_command: "hostname"
-
hostname
--------
When the user launches an instance, they provide a hostname for that instance.
diff --git a/doc/rtd/topics/datasources/cloudstack.rst b/doc/rtd/topics/datasources/cloudstack.rst
index a3101ed7..da183226 100644
--- a/doc/rtd/topics/datasources/cloudstack.rst
+++ b/doc/rtd/topics/datasources/cloudstack.rst
@@ -4,10 +4,10 @@ CloudStack
==========
`Apache CloudStack`_ expose user-data, meta-data, user password and account
-sshkey thru the Virtual-Router. The datasource obtains the VR address via
+SSH key thru the Virtual-Router. The datasource obtains the VR address via
dhcp lease information given to the instance.
For more details on meta-data and user-data,
-refer the `CloudStack Administrator Guide`_.
+refer the `CloudStack Administrator Guide`_.
URLs to access user-data and meta-data from the Virtual Machine. Here 10.1.1.1
is the Virtual Router IP:
diff --git a/doc/rtd/topics/datasources/configdrive.rst b/doc/rtd/topics/datasources/configdrive.rst
index f1a488a2..4fcbccee 100644
--- a/doc/rtd/topics/datasources/configdrive.rst
+++ b/doc/rtd/topics/datasources/configdrive.rst
@@ -6,7 +6,7 @@ Config Drive
The configuration drive datasource supports the `OpenStack`_ configuration
drive disk.
- See `the config drive extension`_ and `introduction`_ in the public
+ See `the config drive extension`_ and `metadata introduction`_ in the public
documentation for more information.
By default, cloud-init does *always* consider this source to be a full-fledged
@@ -64,7 +64,7 @@ The following criteria are required to as a config drive:
::
openstack/
- - 2012-08-10/ or latest/
+ - 2012-08-10/ or latest/
- meta_data.json
- user_data (not mandatory)
- content/
@@ -83,7 +83,7 @@ only) file in the following ways.
::
- dsmode:
+ dsmode:
values: local, net, pass
default: pass
@@ -97,10 +97,10 @@ The difference between 'local' and 'net' is that local will not require
networking to be up before user-data actions (or boothooks) are run.
::
-
+
instance-id:
default: iid-dsconfigdrive
-
+
This is utilized as the metadata's instance-id. It should generally
be unique, as it is what is used to determine "is this a new instance".
@@ -108,24 +108,24 @@ be unique, as it is what is used to determine "is this a new instance".
public-keys:
default: None
-
+
If present, these keys will be used as the public keys for the
instance. This value overrides the content in authorized_keys.
Note: it is likely preferable to provide keys via user-data
::
-
+
user-data:
default: None
-
-This provides cloud-init user-data. See :ref:`examples <yaml_examples>` for
+
+This provides cloud-init user-data. See :ref:`examples <yaml_examples>` for
what all can be present here.
.. _OpenStack: http://www.openstack.org/
-.. _introduction: http://docs.openstack.org/trunk/openstack-compute/admin/content/config-drive.html
+.. _metadata introduction: https://docs.openstack.org/nova/latest/user/metadata.html#config-drives
.. _python-novaclient: https://github.com/openstack/python-novaclient
.. _iso9660: https://en.wikipedia.org/wiki/ISO_9660
.. _vfat: https://en.wikipedia.org/wiki/File_Allocation_Table
-.. _the config drive extension: http://docs.openstack.org/user-guide/content/config-drive.html
+.. _the config drive extension: https://docs.openstack.org/nova/latest/admin/config-drive.html
.. vi: textwidth=78
diff --git a/doc/rtd/topics/datasources/digitalocean.rst b/doc/rtd/topics/datasources/digitalocean.rst
index 938ede89..88f1e5f5 100644
--- a/doc/rtd/topics/datasources/digitalocean.rst
+++ b/doc/rtd/topics/datasources/digitalocean.rst
@@ -20,8 +20,10 @@ DigitalOcean's datasource can be configured as follows:
retries: 3
timeout: 2
-- *retries*: Determines the number of times to attempt to connect to the metadata service
-- *timeout*: Determines the timeout in seconds to wait for a response from the metadata service
+- *retries*: Determines the number of times to attempt to connect to the
+ metadata service
+- *timeout*: Determines the timeout in seconds to wait for a response from the
+ metadata service
.. _DigitalOcean: http://digitalocean.com/
.. _metadata service: https://developers.digitalocean.com/metadata/
diff --git a/doc/rtd/topics/datasources/e24cloud.rst b/doc/rtd/topics/datasources/e24cloud.rst
new file mode 100644
index 00000000..de9a4127
--- /dev/null
+++ b/doc/rtd/topics/datasources/e24cloud.rst
@@ -0,0 +1,9 @@
+.. _datasource_e24cloud:
+
+E24Cloud
+========
+`E24Cloud <https://www.e24cloud.com/en/>` platform provides an AWS Ec2 metadata
+service clone. It identifies itself to guests using the dmi
+system-manufacturer (/sys/class/dmi/id/sys_vendor).
+
+.. vi: textwidth=78
diff --git a/doc/rtd/topics/datasources/ec2.rst b/doc/rtd/topics/datasources/ec2.rst
index 64c325d8..a90f3779 100644
--- a/doc/rtd/topics/datasources/ec2.rst
+++ b/doc/rtd/topics/datasources/ec2.rst
@@ -13,7 +13,7 @@ instance metadata.
Metadata is accessible via the following URL:
::
-
+
GET http://169.254.169.254/2009-04-04/meta-data/
ami-id
ami-launch-index
@@ -34,19 +34,20 @@ Metadata is accessible via the following URL:
Userdata is accessible via the following URL:
::
-
+
GET http://169.254.169.254/2009-04-04/user-data
1234,fred,reboot,true | 4512,jimbo, | 173,,,
Note that there are multiple versions of this data provided, cloud-init
by default uses **2009-04-04** but newer versions can be supported with
relative ease (newer versions have more data exposed, while maintaining
-backward compatibility with the previous versions).
+backward compatibility with the previous versions).
-To see which versions are supported from your cloud provider use the following URL:
+To see which versions are supported from your cloud provider use the following
+URL:
::
-
+
GET http://169.254.169.254/
1.0
2007-01-19
@@ -90,4 +91,15 @@ An example configuration with the default values is provided below:
max_wait: 120
timeout: 50
+Notes
+-----
+ * There are 2 types of EC2 instances network-wise: VPC ones (Virtual Private
+ Cloud) and Classic ones (also known as non-VPC). One major difference
+ between them is that Classic instances have their MAC address changed on
+ stop/restart operations, so cloud-init will recreate the network config
+ file for EC2 Classic instances every boot. On VPC instances this file is
+ generated only in the first boot of the instance.
+ The check for the instance type is performed by is_classic_instance()
+ method.
+
.. vi: textwidth=78
diff --git a/doc/rtd/topics/datasources/exoscale.rst b/doc/rtd/topics/datasources/exoscale.rst
new file mode 100644
index 00000000..9074edc6
--- /dev/null
+++ b/doc/rtd/topics/datasources/exoscale.rst
@@ -0,0 +1,68 @@
+.. _datasource_exoscale:
+
+Exoscale
+========
+
+This datasource supports reading from the metadata server used on the
+`Exoscale platform <https://exoscale.com>`_.
+
+Use of the Exoscale datasource is recommended to benefit from new features of
+the Exoscale platform.
+
+The datasource relies on the availability of a compatible metadata server
+(``http://169.254.169.254`` is used by default) and its companion password
+server, reachable at the same address (by default on port 8080).
+
+Crawling of metadata
+--------------------
+
+The metadata service and password server are crawled slightly differently:
+
+ * The "metadata service" is crawled every boot.
+ * The password server is also crawled every boot (the Exoscale datasource
+ forces the password module to run with "frequency always").
+
+In the password server case, the following rules apply in order to enable the
+"restore instance password" functionality:
+
+ * If a password is returned by the password server, it is then marked "saved"
+ by the cloud-init datasource. Subsequent boots will skip setting the
+ password (the password server will return "saved_password").
+ * When the instance password is reset (via the Exoscale UI), the password
+ server will return the non-empty password at next boot, therefore causing
+ cloud-init to reset the instance's password.
+
+Configuration
+-------------
+
+Users of this datasource are discouraged from changing the default settings
+unless instructed to by Exoscale support.
+
+The following settings are available and can be set for the datasource in
+system configuration (in `/etc/cloud/cloud.cfg.d/`).
+
+The settings available are:
+
+ * **metadata_url**: The URL for the metadata service (defaults to
+ ``http://169.254.169.254``)
+ * **api_version**: The API version path on which to query the instance
+ metadata (defaults to ``1.0``)
+ * **password_server_port**: The port (on the metadata server) on which the
+ password server listens (defaults to ``8080``).
+ * **timeout**: the timeout value provided to urlopen for each individual http
+ request. (defaults to ``10``)
+ * **retries**: The number of retries that should be done for an http request
+ (defaults to ``6``)
+
+
+An example configuration with the default values is provided below:
+
+.. sourcecode:: yaml
+
+ datasource:
+ Exoscale:
+ metadata_url: "http://169.254.169.254"
+ api_version: "1.0"
+ password_server_port: 8080
+ timeout: 10
+ retries: 6
diff --git a/doc/rtd/topics/datasources/nocloud.rst b/doc/rtd/topics/datasources/nocloud.rst
index 08578e86..bc96f7fe 100644
--- a/doc/rtd/topics/datasources/nocloud.rst
+++ b/doc/rtd/topics/datasources/nocloud.rst
@@ -9,7 +9,7 @@ network at all).
You can provide meta-data and user-data to a local vm boot via files on a
`vfat`_ or `iso9660`_ filesystem. The filesystem volume label must be
-``cidata``.
+``cidata`` or ``CIDATA``.
Alternatively, you can provide meta-data via kernel command line or SMBIOS
"serial number" option. The data must be passed in the form of a string:
@@ -57,24 +57,24 @@ Given a disk ubuntu 12.04 cloud image in 'disk.img', you can create a
sufficient disk by following the example below.
::
-
+
## create user-data and meta-data files that will be used
## to modify image on first boot
$ { echo instance-id: iid-local01; echo local-hostname: cloudimg; } > meta-data
-
+
$ printf "#cloud-config\npassword: passw0rd\nchpasswd: { expire: False }\nssh_pwauth: True\n" > user-data
-
+
## create a disk to attach with some user-data and meta-data
$ genisoimage -output seed.iso -volid cidata -joliet -rock user-data meta-data
-
+
## alternatively, create a vfat filesystem with same files
## $ truncate --size 2M seed.img
## $ mkfs.vfat -n cidata seed.img
## $ mcopy -oi seed.img user-data meta-data ::
-
+
## create a new qcow image to boot, backed by your original image
$ qemu-img create -f qcow2 -b disk.img boot-disk.img
-
+
## boot the image and login as 'ubuntu' with password 'passw0rd'
## note, passw0rd was set as password through the user-data above,
## there is no password set on these images.
@@ -88,12 +88,12 @@ to determine if this is "first boot". So if you are making updates to
user-data you will also have to change that, or start the disk fresh.
Also, you can inject an ``/etc/network/interfaces`` file by providing the
-content for that file in the ``network-interfaces`` field of metadata.
+content for that file in the ``network-interfaces`` field of metadata.
Example metadata:
::
-
+
instance-id: iid-abcdefg
network-interfaces: |
iface eth0 inet static
diff --git a/doc/rtd/topics/datasources/opennebula.rst b/doc/rtd/topics/datasources/opennebula.rst
index 7c0367c4..8e7c2558 100644
--- a/doc/rtd/topics/datasources/opennebula.rst
+++ b/doc/rtd/topics/datasources/opennebula.rst
@@ -21,7 +21,7 @@ Datasource configuration
Datasource accepts following configuration options.
::
-
+
dsmode:
values: local, net, disabled
default: net
@@ -30,7 +30,7 @@ Tells if this datasource will be processed in 'local' (pre-networking) or
'net' (post-networking) stage or even completely 'disabled'.
::
-
+
parseuser:
default: nobody
@@ -46,7 +46,7 @@ The following criteria are required:
or have a *filesystem* label of **CONTEXT** or **CDROM**
2. Must contain file *context.sh* with contextualization variables.
File is generated by OpenNebula, it has a KEY='VALUE' format and
- can be easily read by bash
+ can be easily read by bash
Contextualization variables
~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -57,7 +57,7 @@ the OpenNebula documentation. Where multiple similar variables are
specified, only first found is taken.
::
-
+
DSMODE
Datasource mode configuration override. Values: local, net, disabled.
@@ -75,30 +75,30 @@ Datasource mode configuration override. Values: local, net, disabled.
Static `network configuration`_.
::
-
+
HOSTNAME
Instance hostname.
::
-
+
PUBLIC_IP
IP_PUBLIC
ETH0_IP
If no hostname has been specified, cloud-init will try to create hostname
-from instance's IP address in 'local' dsmode. In 'net' dsmode, cloud-init
+from instance's IP address in 'local' dsmode. In 'net' dsmode, cloud-init
tries to resolve one of its IP addresses to get hostname.
::
-
+
SSH_KEY
SSH_PUBLIC_KEY
One or multiple SSH keys (separated by newlines) can be specified.
::
-
+
USER_DATA
USERDATA
@@ -111,7 +111,7 @@ This example cloud-init configuration (*cloud.cfg*) enables
OpenNebula datasource only in 'net' mode.
::
-
+
disable_ec2_metadata: True
datasource_list: ['OpenNebula']
datasource:
@@ -123,17 +123,17 @@ Example VM's context section
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
::
-
+
CONTEXT=[
PUBLIC_IP="$NIC[IP]",
- SSH_KEY="$USER[SSH_KEY]
- $USER[SSH_KEY1]
+ SSH_KEY="$USER[SSH_KEY]
+ $USER[SSH_KEY1]
$USER[SSH_KEY2] ",
USER_DATA="#cloud-config
# see https://help.ubuntu.com/community/CloudInit
-
+
packages: []
-
+
mounts:
- [vdc,none,swap,sw,0,0]
runcmd:
diff --git a/doc/rtd/topics/datasources/openstack.rst b/doc/rtd/topics/datasources/openstack.rst
index 421da08f..8ce2a53d 100644
--- a/doc/rtd/topics/datasources/openstack.rst
+++ b/doc/rtd/topics/datasources/openstack.rst
@@ -78,6 +78,7 @@ upgrade packages and install ``htop`` on all instances:
{"cloud-init": "#cloud-config\npackage_upgrade: True\npackages:\n - htop"}
For more general information about how cloud-init handles vendor data,
-including how it can be disabled by users on instances, see :doc:`/topics/vendordata`.
+including how it can be disabled by users on instances, see
+:doc:`/topics/vendordata`.
.. vi: textwidth=78
diff --git a/doc/rtd/topics/datasources/oracle.rst b/doc/rtd/topics/datasources/oracle.rst
index f2383cee..98c4657c 100644
--- a/doc/rtd/topics/datasources/oracle.rst
+++ b/doc/rtd/topics/datasources/oracle.rst
@@ -8,7 +8,7 @@ This datasource reads metadata, vendor-data and user-data from
Oracle Platform
---------------
-OCI provides bare metal and virtual machines. In both cases,
+OCI provides bare metal and virtual machines. In both cases,
the platform identifies itself via DMI data in the chassis asset tag
with the string 'OracleCloud.com'.
@@ -22,5 +22,28 @@ Cloud-init has a specific datasource for Oracle in order to:
implementation.
+Configuration
+-------------
+
+The following configuration can be set for the datasource in system
+configuration (in ``/etc/cloud/cloud.cfg`` or ``/etc/cloud/cloud.cfg.d/``).
+
+The settings that may be configured are:
+
+* **configure_secondary_nics**: A boolean, defaulting to False. If set
+ to True on an OCI Virtual Machine, cloud-init will fetch networking
+ metadata from Oracle's IMDS and use it to configure the non-primary
+ network interface controllers in the system. If set to True on an
+ OCI Bare Metal Machine, it will have no effect (though this may
+ change in the future).
+
+An example configuration with the default values is provided below:
+
+.. sourcecode:: yaml
+
+ datasource:
+ Oracle:
+ configure_secondary_nics: false
+
.. _Oracle Compute Infrastructure: https://cloud.oracle.com/
.. vi: textwidth=78
diff --git a/doc/rtd/topics/datasources/rbxcloud.rst b/doc/rtd/topics/datasources/rbxcloud.rst
new file mode 100644
index 00000000..52ec02ff
--- /dev/null
+++ b/doc/rtd/topics/datasources/rbxcloud.rst
@@ -0,0 +1,25 @@
+.. _datasource_rbx:
+
+Rbx Cloud
+=========
+
+The Rbx datasource consumes the metadata drive available on platform
+`HyperOne`_ and `Rootbox`_ platform.
+
+Datasource supports, in particular, network configurations, hostname,
+user accounts and user metadata.
+
+Metadata drive
+--------------
+
+Drive metadata is a `FAT`_-formatted partition with the ```CLOUDMD``` label on
+the system disk. Its contents are refreshed each time the virtual machine
+is restarted, if the partition exists. For more information see
+`HyperOne Virtual Machine docs`_.
+
+.. _HyperOne: http://www.hyperone.com/
+.. _Rootbox: https://rootbox.com/
+.. _HyperOne Virtual Machine docs: http://www.hyperone.com/
+.. _FAT: https://en.wikipedia.org/wiki/File_Allocation_Table
+
+.. vi: textwidth=78
diff --git a/doc/rtd/topics/datasources/smartos.rst b/doc/rtd/topics/datasources/smartos.rst
index cb9a128e..be11dfbb 100644
--- a/doc/rtd/topics/datasources/smartos.rst
+++ b/doc/rtd/topics/datasources/smartos.rst
@@ -15,7 +15,8 @@ second serial console. On Linux, this is /dev/ttyS1. The data is a provided
via a simple protocol: something queries for the data, the console responds
responds with the status and if "SUCCESS" returns until a single ".\n".
-New versions of the SmartOS tooling will include support for base64 encoded data.
+New versions of the SmartOS tooling will include support for base64 encoded
+data.
Meta-data channels
------------------
@@ -27,7 +28,7 @@ channels of SmartOS.
- per the spec, user-data is for consumption by the end-user, not
provisioning tools
- - cloud-init entirely ignores this channel other than writting it to disk
+ - cloud-init entirely ignores this channel other than writing it to disk
- removal of the meta-data key means that /var/db/user-data gets removed
- a backup of previous meta-data is maintained as
/var/db/user-data.<timestamp>. <timestamp> is the epoch time when
@@ -42,8 +43,9 @@ channels of SmartOS.
- <timestamp> is the epoch time when cloud-init ran.
- when the 'user-script' meta-data key goes missing, the user-script is
removed from the file system, although a backup is maintained.
- - if the script is not shebanged (i.e. starts with #!<executable>), then
- or is not an executable, cloud-init will add a shebang of "#!/bin/bash"
+ - if the script does not start with a shebang (i.e. starts with
+ #!<executable>), then or is not an executable, cloud-init will add a
+ shebang of "#!/bin/bash"
* cloud-init:user-data is treated like on other Clouds.
@@ -133,7 +135,7 @@ or not to base64 decode something:
* base64_all: Except for excluded keys, attempt to base64 decode
the values. If the value fails to decode properly, it will be
returned in its text
- * base64_keys: A comma deliminated list of which keys are base64 encoded.
+ * base64_keys: A comma delimited list of which keys are base64 encoded.
* b64-<key>:
for any key, if there exists an entry in the metadata for 'b64-<key>'
Then 'b64-<key>' is expected to be a plaintext boolean indicating whether
diff --git a/doc/rtd/topics/datasources/zstack.rst b/doc/rtd/topics/datasources/zstack.rst
new file mode 100644
index 00000000..93a2791c
--- /dev/null
+++ b/doc/rtd/topics/datasources/zstack.rst
@@ -0,0 +1,37 @@
+.. _datasource_zstack:
+
+ZStack
+======
+ZStack platform provides a AWS Ec2 metadata service, but with different
+datasource identity.
+More information about ZStack can be found at `ZStack <https://www.zstack.io>`__.
+
+Discovery
+---------
+To determine whether a vm running on ZStack platform, cloud-init checks DMI
+information by 'dmidecode -s chassis-asset-tag', if the output ends with
+'.zstack.io', it's running on ZStack platform:
+
+
+Metadata
+^^^^^^^^
+Same as EC2, instance metadata can be queried at
+
+::
+
+ GET http://169.254.169.254/2009-04-04/meta-data/
+ instance-id
+ local-hostname
+
+Userdata
+^^^^^^^^
+Same as EC2, instance userdata can be queried at
+
+::
+
+ GET http://169.254.169.254/2009-04-04/user-data/
+ meta_data.json
+ user_data
+ password
+
+.. vi: textwidth=78
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-26 05:07:22 +0000