this change was introduced to address evidently another bug where
somehow self.opts has no master_uri - but in the process it prioritized
using master_ip over master_uri even when master_uri _is_ there.
providing master_uri as a way of specifiying which msater you would like
to create a channel for is documented used elsewhere in the codebase in
multi-master scenarios (ie, event.send, saltutil.revoke_auth)
this change was introduced to address evidently another bug where
somehow self.opts has no master_uri - but in the process it prioritized
using master_ip over master_uri even when master_uri _is_ there.
providing master_uri as a way of specifiying which msater you would like
to create a channel for is documented used elsewhere in the codebase in
multi-master scenarios (ie, event.send, saltutil.revoke_auth)
Some hypervisors can handle several CPU architectures or have different
virtualization types. This is reflected in libvirt by the OS type (badly
named, indeed) and the arch value. Allow users to set them when creating
a VM using either virt.init or virt.running.
Signed-off-by: Cédric Bosdonnat <cbosdonnat@suse.com>
(cherry picked from commit 2463ebe5a8)
So far virt.running does nothing if the corresponding domain is already
defined. Use the new virt.update function to change the domain
configuration.
(cherry picked from commit 2a5f6ae5d6)
So far only the virt.running state is unit tested. Add tests for the
other states. Deprecated virt states have been purposedly left untested.
(cherry picked from commit fc75872fb6)
virt.running actually calls virt.init if the virtual machine doesn't
exist. Let the user define all the virt.init possible options in his
running states too.
(cherry picked from commit cb00a5f9b4)
Test virt.running when the domain needs to be edited and started. This
will prevent regressions when improving virt.running to handle the new
virt.init parameters.
(cherry picked from commit 495db345a5)
As mentioned in issue 47972, applying the virt.running state doesn't
report any error if the libvirt create call actually failed.
This commit introduces proper handling of the libvirt errors to let
users see the libvirt error in case of failure.
Also add test cases for virt.running to prevent regression.
(cherry picked from commit 451e7da55b)
The release tarball does not contain the `templates` directory.
Therefore `ExtendTestCase` will fail:
```
======================================================================
ERROR: test_run (unit.utils.test_extend.ExtendTestCase)
[CPU:0.0%|MEM:53.9%]
----------------------------------------------------------------------
Traceback (most recent call last):
File "tests/unit/utils/test_extend.py", line 40, in test_run
out = salt.utils.extend.run('test', 'test', 'this description', integration.CODE_DIR, False)
File "salt/utils/extend.py", line 242, in run
MODULE_OPTIONS = _fetch_templates(os.path.join(salt_dir, 'templates'))
File "salt/utils/extend.py", line 76, in _fetch_templates
for item in os.listdir(src):
FileNotFoundError: [Errno 2] No such file or directory: ' templates'
```
Signed-off-by: Benjamin Drung <benjamin.drung@cloud.ionos.com>
The release tarball does not contain `conf/cloud.profiles.d`,
`conf/cloud.providers.d`, and `conf/cloud.maps.d`. Therefore the test
cases will fail:
```
======================================================================
ERROR: test_conf_cloud_maps_d_files_are_commented (unit.test_config.SampleConfTest)
[CPU:0.0%|MEM:53.9%]
----------------------------------------------------------------------
Traceback (most recent call last):
File "tests/unit/test_config.py", line 236, in test_conf_cloud_maps_d_files_are_commented
cloud_sample_files = os.listdir(SAMPLE_CONF_DIR + 'cloud.maps.d/')
FileNotFoundError: [Errno 2] No such file or directory: 'conf/cloud.maps.d/'
======================================================================
ERROR: test_conf_cloud_profiles_d_files_are_commented (unit.test_config.SampleConfTest)
[CPU:0.0%|MEM:53.9%]
----------------------------------------------------------------------
Traceback (most recent call last):
File "tests/unit/test_config.py", line 200, in test_conf_cloud_profiles_d_files_are_commented
cloud_sample_files = os.listdir(SAMPLE_CONF_DIR + 'cloud.profiles.d/')
FileNotFoundError: [Errno 2] No such file or directory: 'conf/cloud.profiles.d/'
======================================================================
ERROR: test_conf_cloud_providers_d_files_are_commented (unit.test_config.SampleConfTest)
[CPU:0.0%|MEM:53.9%]
----------------------------------------------------------------------
Traceback (most recent call last):
File "tests/unit/test_config.py", line 218, in test_conf_cloud_providers_d_files_are_commented
cloud_sample_files = os.listdir(SAMPLE_CONF_DIR + 'cloud.providers.d/')
FileNotFoundError: [Errno 2] No such file or directory: 'conf/cloud.providers.d/'
```
Signed-off-by: Benjamin Drung <benjamin.drung@cloud.ionos.com>
Previously, when using `test=True`, `host.present` would return
`None` always. In Salt we return `True` when there are (or would be)
changes, `False` when there are no changes, and `None` when there
*would* have been changes.
This brings `host.present` in-line with that convention.
Some code in salt._compat which checks if the value is a packed binary
representation of an IPv6 address fails if the value passed is not a
bytestring (i.e. a `unicode` type on PY2 or `str` type on PY3). This
fixes that code when the minion ID is a 16-character string (not a
bytestring). Note that the minion ID will never be a bytestring as of
2018.3.0, so this affects any 16-character minion ID when the minion ID
is checked to see if it is really an IP address.
Make sure that the virtualname is included in the actual filename of
core modules. This will help speed up loading of modules that need to
use the virtualname, so that we hit @depends decorators less.
