diff options
| -rw-r--r-- | doc/rtd/topics/datasources.rst | 26 | ||||
| -rw-r--r-- | doc/rtd/topics/datasources/azure.rst | 2 | ||||
| -rw-r--r-- | doc/rtd/topics/dir_layout.rst | 14 | ||||
| -rw-r--r-- | doc/rtd/topics/merging.rst | 4 | ||||
| -rw-r--r-- | doc/rtd/topics/network-config-format-v1.rst | 4 | ||||
| -rw-r--r-- | doc/rtd/topics/network-config.rst | 4 | ||||
| -rw-r--r-- | doc/rtd/topics/tests.rst | 6 | ||||
| -rw-r--r-- | doc/rtd/topics/vendordata.rst | 4 |
8 files changed, 32 insertions, 32 deletions
diff --git a/doc/rtd/topics/datasources.rst b/doc/rtd/topics/datasources.rst index 9acecc53..a60f5eb7 100644 --- a/doc/rtd/topics/datasources.rst +++ b/doc/rtd/topics/datasources.rst @@ -20,7 +20,7 @@ through the typical usage of subclasses. The current interface that a datasource object must provide is the following: .. sourcecode:: python - + # returns a mime multipart message that contains # all the various fully-expanded components that # were found from processing the raw userdata string @@ -28,47 +28,47 @@ The current interface that a datasource object must provide is the following: # this instance id will be returned (or messages with # no instance id) def get_userdata(self, apply_filter=False) - + # returns the raw userdata string (or none) def get_userdata_raw(self) - + # returns a integer (or none) which can be used to identify # this instance in a group of instances which are typically - # created from a single command, thus allowing programatic + # created from a single command, thus allowing programmatic # filtering on this launch index (or other selective actions) @property def launch_index(self) - - # the data sources' config_obj is a cloud-config formated + + # the data sources' config_obj is a cloud-config formatted # object that came to it from ways other than cloud-config # because cloud-config content would be handled elsewhere def get_config_obj(self) - + #returns a list of public ssh keys def get_public_ssh_keys(self) - + # translates a device 'short' name into the actual physical device # fully qualified name (or none if said physical device is not attached # or does not exist) def device_name_to_device(self, name) - + # gets the locale string this instance should be applying # which typically used to adjust the instances locale settings files def get_locale(self) - + @property def availability_zone(self) - + # gets the instance id that was assigned to this instance by the # cloud provider or when said instance id does not exist in the backing # metadata this will return 'iid-datasource' def get_instance_id(self) - + # gets the fully qualified domain name that this host should be using # when configuring network or hostname releated settings, typically # assigned either by the cloud provider or the user creating the vm def get_hostname(self, fqdn=False) - + def get_package_mirror_info(self) diff --git a/doc/rtd/topics/datasources/azure.rst b/doc/rtd/topics/datasources/azure.rst index 4a3735b5..559011ef 100644 --- a/doc/rtd/topics/datasources/azure.rst +++ b/doc/rtd/topics/datasources/azure.rst @@ -8,7 +8,7 @@ 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 -CD formated in UDF. That CD contains a 'ovf-env.xml' file that provides some +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". diff --git a/doc/rtd/topics/dir_layout.rst b/doc/rtd/topics/dir_layout.rst index 3f5aa205..7a6265eb 100644 --- a/doc/rtd/topics/dir_layout.rst +++ b/doc/rtd/topics/dir_layout.rst @@ -41,9 +41,9 @@ Cloudinits's directory structure is somewhat different from a regular applicatio ``data/`` - Contains information releated to instance ids, datasources and hostnames of the previous + Contains information related to instance ids, datasources and hostnames of the previous and current instance if they are different. These can be examined as needed to - determine any information releated to a previous boot (if applicable). + determine any information related to a previous boot (if applicable). ``handlers/`` @@ -59,9 +59,9 @@ Cloudinits's directory structure is somewhat different from a regular applicatio ``instances/`` - All instances that were created using this image end up with instance identifer + All instances that were created using this image end up with instance identifier subdirectories (and corresponding data for each instance). The currently active - instance will be symlinked the the ``instance`` symlink file defined previously. + instance will be symlinked the ``instance`` symlink file defined previously. ``scripts/`` @@ -74,9 +74,9 @@ Cloudinits's directory structure is somewhat different from a regular applicatio ``sem/`` - Cloud-init has a concept of a module sempahore, which basically consists + Cloud-init has a concept of a module semaphore, which basically consists of the module name and its frequency. These files are used to ensure a module - is only ran `per-once`, `per-instance`, `per-always`. This folder contains - sempaphore `files` which are only supposed to run `per-once` (not tied to the instance id). + is only ran `per-once`, `per-instance`, `per-always`. This folder contains + semaphore `files` which are only supposed to run `per-once` (not tied to the instance id). .. vi: textwidth=78 diff --git a/doc/rtd/topics/merging.rst b/doc/rtd/topics/merging.rst index 2f927a47..c75ca59c 100644 --- a/doc/rtd/topics/merging.rst +++ b/doc/rtd/topics/merging.rst @@ -7,7 +7,7 @@ Overview This was implemented because it has been a common feature request that there be a way to specify how cloud-config yaml "dictionaries" provided as user-data are -merged together when there are multiple yamls to merge together (say when +merged together when there are multiple yaml files to merge together (say when performing an #include). Since previously the merging algorithm was very simple and would only overwrite @@ -128,7 +128,7 @@ for your own usage. for, both of which can define the way merging is done (the first header to exist wins). These new headers (in lookup order) are 'Merge-Type' and 'X-Merge-Type'. The value should be a string which will satisfy the new - merging format defintion (see below for this format). + merging format definition (see below for this format). 2. The second way is actually specifying the merge-type in the body of the cloud-config dictionary. There are 2 ways to specify this, either as a diff --git a/doc/rtd/topics/network-config-format-v1.rst b/doc/rtd/topics/network-config-format-v1.rst index 36326b59..ce3a1bde 100644 --- a/doc/rtd/topics/network-config-format-v1.rst +++ b/doc/rtd/topics/network-config-format-v1.rst @@ -246,8 +246,8 @@ Valid keys are: - jumbo0 params: bridge_ageing: 250 - bridge_bridgeprio: 22 - bridge_fd: 1 + bridge_bridgeprio: 22 + bridge_fd: 1 bridge_hello: 1 bridge_maxage: 10 bridge_maxwait: 0 diff --git a/doc/rtd/topics/network-config.rst b/doc/rtd/topics/network-config.rst index 109c86f5..96c1cf59 100644 --- a/doc/rtd/topics/network-config.rst +++ b/doc/rtd/topics/network-config.rst @@ -31,7 +31,7 @@ A ``network:`` entry in /etc/cloud/cloud.cfg.d/* configuration files. ``ip=`` or ``network-config=<YAML config string>`` -User-data cannot change an instance's network configuration. In the absense +User-data cannot change an instance's network configuration. In the absence of network configuration in any of the above sources , `Cloud-init`_ will write out a network configuration that will issue a DHCP request on a "first" network interface. @@ -220,7 +220,7 @@ CLI Interface : --output-kind {eni,netplan,sysconfig}, -ok {eni,netplan,sysconfig} -Example output convertion V2 to sysconfig: +Example output converting V2 to sysconfig: .. code-block:: bash diff --git a/doc/rtd/topics/tests.rst b/doc/rtd/topics/tests.rst index 0663811e..60c63bce 100644 --- a/doc/rtd/topics/tests.rst +++ b/doc/rtd/topics/tests.rst @@ -158,7 +158,7 @@ Development Checklist * Named 'your_test_here.py' * Valid unit tests validating output collected * Passes pylint & pep8 checks - * Placed in the appropriate sub-folder in the testcsaes directory + * Placed in the appropriate sub-folder in the testcases directory * Tested by running the test: .. code-block:: bash @@ -222,7 +222,7 @@ collect can be ran by running: $ python3 -m tests.cloud_tests collect -n xenial -d /tmp/collection \ --deb cloud-init_0.7.8~my_patch_all.deb -The above command will run the collection tests on xenial with the +The above command will run the collection tests on Xenial with the provided deb and place all results into `/tmp/collection`. Verify @@ -249,7 +249,7 @@ configuration users can run the integration tests via tox: $ tox -e citest -- run -v -n zesty --deb=cloud-init_all.deb $ tox -e citest -- run -t module/user_groups.yaml -Users need to invoke the citest enviornment and then pass any additional +Users need to invoke the citest environment and then pass any additional arguments. diff --git a/doc/rtd/topics/vendordata.rst b/doc/rtd/topics/vendordata.rst index 2a94318e..cdb552d0 100644 --- a/doc/rtd/topics/vendordata.rst +++ b/doc/rtd/topics/vendordata.rst @@ -22,7 +22,7 @@ caveats: Users providing cloud-config data can use the '#cloud-config-jsonp' method to more finely control their modifications to the vendor supplied cloud-config. -For example, if both vendor and user have provided 'runcnmd' then the default +For example, if both vendor and user have provided 'runcmd' then the default merge handler will cause the user's runcmd to override the one provided by the vendor. To append to 'runcmd', the user could better provide multipart input with a cloud-config-jsonp part like: @@ -31,7 +31,7 @@ with a cloud-config-jsonp part like: #cloud-config-jsonp [{ "op": "add", "path": "/runcmd", "value": ["my", "command", "here"]}] - + Further, we strongly advise vendors to not 'be evil'. By evil, we mean any action that could compromise a system. Since users trust you, please take care to make sure that any vendordata is safe, |