saltstack/salt
1
0
Fork 0
mirror of https://github.com/saltstack/salt.git synced 2025-04-17 10:10:20 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

Fix some doc build warnings

Browse source
This commit is contained in:
rallytime 2018-09-17 15:45:28 -04:00
parent 907205fe42
commit c274635933
No known key found for this signature in database
GPG key ID: E8F1A4B90D0DEA19
6 changed files with 68 additions and 48 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
doc/ref/roster/all/salt.roster.terraform.rst
View file

@ -1,6 +1,6 @@
===================
=====================
salt.roster.terraform
===================
=====================
.. automodule:: salt.roster.terraform
:members:

4
doc/topics/releases/fluorine.rst
View file

@ -1181,7 +1181,7 @@ instance
Old behavior:
.. code-block:: example user in influxdb
.. code-block:: yaml
influxdb_user.present:
- name: exampleuser
@ -1191,7 +1191,7 @@ Old behavior:
New behavior:
.. code-block:: example user in influxdb
.. code-block:: yaml
influxdb_user.present:
- name: exampleuser

9
doc/topics/releases/version_numbers.rst
View file

@ -54,9 +54,10 @@ code name and the process repeats itself.
Version numbers, Git and salt --version
---------------------------------------
The salt version, for programmers, is based on `git describe` and presented to end-users with `salt --version`.
The salt version, for programmers, is based on ``git describe`` and presented to
end-users with ``salt --version``.
Example arguments for `git checkout`:
Example arguments for ``git checkout``:
+------------+----------------------------------------------------------------------------+
| Argument | Comment |
@ -73,7 +74,7 @@ Example arguments for `git checkout`:
Further reading on `release branch and develop branch
<https://docs.saltstack.com/en/latest/topics/development/contributing.html#which-salt-branch>`_.
Influence of the `git checkout` argument on `git describe`:
Influence of the ``git checkout`` argument on ``git describe``:
+------------+----------------------------+-----------------------------------------------+
| Checkout | Describe | Comment |
@ -87,7 +88,7 @@ Influence of the `git checkout` argument on `git describe`:
| develop | v2016.11.1-1741-g10d5dec | Commit of most recent tag in develop |
+------------+----------------------------+-----------------------------------------------+
Some details of v2016.11.1-220-g9a1550d (from `git describe` after `git checkout 2016.11`):
Some details of v2016.11.1-220-g9a1550d (from ``git describe`` after ``git checkout 2016.11``):
+---------------+-------------------------------------------------------------------------+
| Part | Comment |

4
salt/modules/napalm_formula.py
View file

@ -181,7 +181,7 @@ def defaults(model,
model
The OpenConfig model to apply the defaults to.
defaults_
defaults
The dictionary of defaults. This argument must equally be structured
with respect to the OpenConfig standards.
@ -346,7 +346,7 @@ def render_fields(dictionary,
.. code-block:: jinja
{%- set config={'mtu': 68, 'description': 'Interface description'} %}
{{ salt.napalm_formula.render_fields(config, 'mtu', 'description', quotes=True) %}
{{ salt.napalm_formula.render_fields(config, 'mtu', 'description', quotes=True) }}
The Jinja example above would generate the following configuration:

69
salt/modules/virt.py
View file

@ -2,6 +2,8 @@
'''
Work with virtual machines managed by libvirt
:depends: libvirt Python module
Connection
==========
@ -14,8 +16,8 @@ hypervisor driver will be used. This can be overridden like this:
.. code-block:: yaml
virt:
connection:
uri: lxc:///
connection:
uri: lxc:///
If the connection requires an authentication like for ESXi, this can be defined in the
minion pillar data like this:
@ -23,11 +25,11 @@ minion pillar data like this:
.. code-block:: yaml
virt:
connection:
uri: esx://10.1.1.101/?no_verify=1&auto_answer=1
auth:
username: user
password: secret
connection:
uri: esx://10.1.1.101/?no_verify=1&auto_answer=1
auth:
username: user
password: secret
Connecting with SSH protocol
----------------------------
@ -62,13 +64,10 @@ The calls not using the libvirt connection setup are:
- ``is_*hyper``
- all migration functions
Reference:
- `libvirt ESX URI format <http://libvirt.org/drvesx.html#uriformat>`_
- `libvirt URI format <http://libvirt.org/uri.html#URI_config>`_
- `libvirt authentication configuration <http://libvirt.org/auth.html#Auth_client_config>`_
:depends: libvirt Python module
'''
# Special Thanks to Michael Dehann, many of the concepts, and a few structures
# of his in the virt func module have been used
@ -1282,8 +1281,7 @@ def init(name,
model
One of the disk busses allowed by libvirt (Default: depends on hypervisor)
See `libvirt documentation <https://libvirt.org/formatdomain.html#elementsDisks>`_
for the allowed bus types.
See the libvirt `disk element`_ documentation for the allowed bus types.
image
Path to the image to use for the disk. If no image is provided, an empty disk will be created
@ -1303,8 +1301,7 @@ def init(name,
Graphics type. The possible values are ``none``, ``'spice'``, ``'vnc'`` and other values
allowed as a libvirt graphics type (Default: ``None``)
See `the libvirt documentation <https://libvirt.org/formatdomain.html#elementsGraphics>`_
for more details on the possible types
See the libvirt `graphics element`_ documentation for more details on the possible types.
port
Port to export the graphics on for ``vnc``, ``spice`` and ``rdp`` types.
@ -1336,6 +1333,9 @@ def init(name,
virt:
images: /data/my/vm/images/
.. _disk element: https://libvirt.org/formatdomain.html#elementsDisks
.. _graphics element: https://libvirt.org/formatdomain.html#elementsGraphics
'''
caps = capabilities(**kwargs)
os_types = sorted(set([guest['os_type'] for guest in caps['guests']]))
@ -1647,40 +1647,48 @@ def update(name,
:param mem: Amount of memory to allocate to the virtual machine in MiB.
:param disk_profile: disk profile to use
:param disks:
disks definitions as documented in the :func:`init` function.
Disk definitions as documented in the :func:`init` function.
If neither the profile nor this parameter are defined, the disk devices
will not be changed.
:param nic_profile: network interfaces profile to use
:param interfaces:
network interfaces definitions as documented in the :func:`init` function.
Network interface definitions as documented in the :func:`init` function.
If neither the profile nor this parameter are defined, the interface devices
will not be changed.
:param graphics:
the new graphics definition as defined in :ref:`init-graphics-def`. If not set,
the graphics will not be changed. To remove a graphics device set this parameter
to ``{'type': 'none'}``
The new graphics definition as defined in :ref:`init-graphics-def`. If not set,
the graphics will not be changed. To remove a graphics device, set this parameter
to ``{'type': 'none'}``.
:param live:
``False`` to avoid trying to live update the definition. In such a case, the
new definition is applied at the next start of the virtual machine. If ``True``,
not all aspects of the definition can be live updated, but as much as possible
will be attempted. (Default: ``True``)
:param connection: libvirt connection URI, overriding defaults
:param username: username to connect with, overriding defaults
:param password: password to connect with, overriding defaults
:return:
dictionary indicating the status of what has been done. It is structured in
Returns a dictionary indicating the status of what has been done. It is structured in
the following way:
{
'definition': True,
'cpu': True,
'mem': True,
'disks': {'attached': [list of actually attached disks],
'detached': [list of actually detached disks]},
'nics': {'attached': [list of actually attached nics],
'detached': [list of actually detached nics]},
'errors': ['error messages for failures']
}
.. code-block:: python
{
'definition': True,
'cpu': True,
'mem': True,
'disks': {'attached': [list of actually attached disks],
'detached': [list of actually detached disks]},
'nics': {'attached': [list of actually attached nics],
'detached': [list of actually detached nics]},
'errors': ['error messages for failures']
}
.. versionadded:: Fluorine
@ -1689,6 +1697,7 @@ def update(name,
.. code-block:: bash
salt '*' virt.update domain cpu=2 mem=1024
'''
status = {
'definition': False,

26
salt/roster/terraform.py
View file

@ -3,14 +3,17 @@
Dynamic roster from terraform current state
===========================================
This roster module allows you dynamically generate the roster from the terraform resources defined with `terraform-provider-salt <https://github.com/dmacvicar/terraform-provider-salt>`_.
This roster module allows you dynamically generate the roster from the terraform
resources defined with the `Terraform Salt`_ provider.
It exposes all salt_host resources with the same attributes to the salt-ssh roster, making it completely independent of the type of terraform resource, and providing the integration using terraform constructs with interpolation.
It exposes all salt_host resources with the same attributes to the salt-ssh
roster, making it completely independent of the type of terraform resource, and
providing the integration using terraform constructs with interpolation.
Basic Example
-------------
Given a simple salt-ssh tree with a Saltfile
Given a simple salt-ssh tree with a Saltfile:
.. code-block:: yaml
@ -19,7 +22,7 @@ Given a simple salt-ssh tree with a Saltfile
max_procs: 30
wipe_ssh: True
and etc/salt/master
and ``etc/salt/master``:
.. code-block:: yaml
@ -32,17 +35,24 @@ and etc/salt/master
- srv/pillar
roster: terraform
In the same folder as your `Saltfile`, create terraform file with resources like cloud instances, virtual machines, etc. For every single of those that you want to manage with Salt, create a `salt_host` resource:
In the same folder as your ``Saltfile``, create terraform file with resources
like cloud instances, virtual machines, etc. For every single one of those that
you want to manage with Salt, create a ``salt_host`` resource:
.. code-block:: text
.. code-block:: hcl
resource "salt_host" "dbminion" {
salt_id = "dbserver"
host = "${libvirt_domain.vm-db.network_interface.0.addresses.0}"
user = "root"
passwd = "linux"
}
}
You can use the count attribute to create multiple roster entries with a single definition. Please refer to the `terraform salt provider <https://github.com/dmacvicar/terraform-provider-salt>`_ for more detailed examples.
You can use the count attribute to create multiple roster entries with a single
definition. Please refer to the `Terraform Salt`_ provider for more detailed
examples.
.. _Terraform Salt: https://github.com/dmacvicar/terraform-provider-salt
'''
# Import Python libs
from __future__ import absolute_import, unicode_literals