-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2019.2.0 PR 54196 backport #173
Merged
brejoc
merged 5 commits into
openSUSE:openSUSE-2019.2.0
from
cbosdo:openSUSE-2019.2.0-pr54196
Sep 3, 2019
Merged
2019.2.0 PR 54196 backport #173
brejoc
merged 5 commits into
openSUSE:openSUSE-2019.2.0
from
cbosdo:openSUSE-2019.2.0-pr54196
Sep 3, 2019
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
virt.network_running state calls virt.network_define with vport as a positional argument resulting in an error at runtime. Fix the state to use the vport named argument instead.
virt.pool_running needs the source to be a dictionary, which the documentation was not reflecting. Along the same lines the source hosts need to be a list, adjust the example to show it.
Commit 25b9681 is wrong in assuming the pool build also starts it. The pool needs to be stopped before building it, but we still need to start it after the build: libvirt won't do it automagically for us.
virt.network_infos and virt.pool_infos return the infos as a dictionary with the network or pool name as a key even when there is only one value. Adapt the network_running and pool_running states to this.
vm_state return a dictionary with the VM name as a key. Fix virt.running state and its tests to match this. See issue #53107.
meaksh
pushed a commit
that referenced
this pull request
Oct 1, 2019
* virt.network_define doesn't have vport as positional argument virt.network_running state calls virt.network_define with vport as a positional argument resulting in an error at runtime. Fix the state to use the vport named argument instead. * Fix virt.pool_running state documentation virt.pool_running needs the source to be a dictionary, which the documentation was not reflecting. Along the same lines the source hosts need to be a list, adjust the example to show it. * Get virt.pool_running to start the pool after creating it Commit 25b9681 is wrong in assuming the pool build also starts it. The pool needs to be stopped before building it, but we still need to start it after the build: libvirt won't do it automagically for us. * Fix states to match virt.{network,pool}_infos return virt.network_infos and virt.pool_infos return the infos as a dictionary with the network or pool name as a key even when there is only one value. Adapt the network_running and pool_running states to this. * Fix virt.running use of virt.vm_state vm_state return a dictionary with the VM name as a key. Fix virt.running state and its tests to match this. See issue #53107.
brejoc
pushed a commit
that referenced
this pull request
Nov 15, 2019
* virt.network_define doesn't have vport as positional argument virt.network_running state calls virt.network_define with vport as a positional argument resulting in an error at runtime. Fix the state to use the vport named argument instead. * Fix virt.pool_running state documentation virt.pool_running needs the source to be a dictionary, which the documentation was not reflecting. Along the same lines the source hosts need to be a list, adjust the example to show it. * Get virt.pool_running to start the pool after creating it Commit 25b9681 is wrong in assuming the pool build also starts it. The pool needs to be stopped before building it, but we still need to start it after the build: libvirt won't do it automagically for us. * Fix states to match virt.{network,pool}_infos return virt.network_infos and virt.pool_infos return the infos as a dictionary with the network or pool name as a key even when there is only one value. Adapt the network_running and pool_running states to this. * Fix virt.running use of virt.vm_state vm_state return a dictionary with the VM name as a key. Fix virt.running state and its tests to match this. See issue #53107.
dincamihai
pushed a commit
that referenced
this pull request
Nov 19, 2019
* virt.network_define doesn't have vport as positional argument virt.network_running state calls virt.network_define with vport as a positional argument resulting in an error at runtime. Fix the state to use the vport named argument instead. * Fix virt.pool_running state documentation virt.pool_running needs the source to be a dictionary, which the documentation was not reflecting. Along the same lines the source hosts need to be a list, adjust the example to show it. * Get virt.pool_running to start the pool after creating it Commit 25b9681 is wrong in assuming the pool build also starts it. The pool needs to be stopped before building it, but we still need to start it after the build: libvirt won't do it automagically for us. * Fix states to match virt.{network,pool}_infos return virt.network_infos and virt.pool_infos return the infos as a dictionary with the network or pool name as a key even when there is only one value. Adapt the network_running and pool_running states to this. * Fix virt.running use of virt.vm_state vm_state return a dictionary with the VM name as a key. Fix virt.running state and its tests to match this. See issue #53107.
brejoc
pushed a commit
that referenced
this pull request
Jan 31, 2020
* virt.network_define doesn't have vport as positional argument virt.network_running state calls virt.network_define with vport as a positional argument resulting in an error at runtime. Fix the state to use the vport named argument instead. * Fix virt.pool_running state documentation virt.pool_running needs the source to be a dictionary, which the documentation was not reflecting. Along the same lines the source hosts need to be a list, adjust the example to show it. * Get virt.pool_running to start the pool after creating it Commit 25b9681 is wrong in assuming the pool build also starts it. The pool needs to be stopped before building it, but we still need to start it after the build: libvirt won't do it automagically for us. * Fix states to match virt.{network,pool}_infos return virt.network_infos and virt.pool_infos return the infos as a dictionary with the network or pool name as a key even when there is only one value. Adapt the network_running and pool_running states to this. * Fix virt.running use of virt.vm_state vm_state return a dictionary with the VM name as a key. Fix virt.running state and its tests to match this. See issue #53107.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Fixes various bugs in the virt network and pool states.
What issues does this PR fix or reference?
Backport of PR saltstack/salt#54196