this requisite passes a __prerequired__ kwarg so these need to support
**kwargs for that reason.
This also changes the comment for salt.function in test mode because
it's inaccurate and doesn't make sense.
Conflicts:
- salt/states/test.py
Since "pchanges" was never supported in the state compiler, and
"changes" is what these reqs always used, replacing "pchanges" with
"changes" will allow those requisites to work in test mode.
Conflicts:
- salt/states/file.py
- salt/states/linux_acl.py
- salt/utils/napalm.py
- tests/integration/modules/test_state.py
- tests/unit/states/test_file.py
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)
