Added an implementation of .set_domain_workgroup() that corresponds with .get_domain_workgroup()#51379
Conversation
|
um. wow, let me rebase this.... |
arizvisa
force-pushed
the
win_system-module-set_domain_workgroup
branch
from
db0fd3c to
cec06d1
Compare
…omain_workgroup doesn't return a string.
arizvisa
force-pushed
the
win_system-module-set_domain_workgroup
branch
from
1d90456 to
62bb1e8
Compare
|
Ok. Rebased it. |
twangboy
left a comment
twangboy
left a comment
There was a problem hiding this comment.
A few more things and then I think we're good.
… in test-mode, and to validate whether the name has actually changed or not.
|
A lot of this PR was based on copy-and-paste from other states because it seemed like a quick thing, but it turns out that a lot of it was wrong. Thanks for helping me improve it. But, it seems like the schema for these dictionaries could be consolidated into a single function to construct and validate them on return, right? It would allow for stricter enforcement at the very least (and possibly even allow one to do tricky things such as being able to auto-mock some smoke checks for the states, or checking that there's a 'test' mode implemented). I just don't believe that documentation and clever maintainers (thanks btw) is a strong enough method of validation. Although there's tests and a lot of them, some of the modules aren't really too comprehensive for all of the crazy functionality that you guys support (and some of them require a lot of manual mocking, which for win_system seems to have only been introduced a year ago). Do you guys keep your milestones or goals up for the project's releases anywhere (something like the Project Tab, but more in the future)? |
|
@arizvisa I opened a pull request against your branch. That should fix the failing tests as well as add tests for the new function. |
Fix failing tests
|
@twangboy, thanks sir! |
|
@arizvisa Thanks for the contribution. Welcome to the community! |
…t_domain_workgroup Added an implementation of .set_domain_workgroup() that corresponds with .get_domain_workgroup()
…ernal modules from the master.project states as apparently they were merged by PR saltstack/salt#51379.
4 participants
What does this PR do?
This adds an implementation of
set_domain_workgroup()tosalt.modules.win_system. Thesalt.modules.win_systemmodule includes an implementation ofget_domain_workgroup(), but nothing in the form of actually setting it (other than joining an AD domain which has differing semantics). This was done using the COM api for WMI similar to other functions defined within the module.The
set_hostname()function was also updated to use the COM api as before it was using salt.cmd to executewmicto set the name. On top of these additions, a new state function was added tosalt.states.win_systemasworkgroup()which allows one to manage the workgroup of a windows machine in the same way as the "hostname" and "computer_name".Previous Behavior
There was no way to set the workgroup for a windows machine.
New Behavior
Now it's possible to set the workgroup for a windows machine via the module, or using the state to manage the workgroup. This adds to
salt.states.win_systemandsalt.modules.win_system.