Repository: ansible-collections/community.vmware

Issue:
Change service startup policy with vmware_host_service_manager without defining service state
<!--- Verify first that your feature was not already discussed on GitHub -->
<!--- Complete *all* sections as described, this form is processed automatically -->

##### SUMMARY
<!--- Describe the new feature/improvement briefly below -->
When setting up the service in vSphere Client, the actions to set startup policy or service state are independent. However, when setting the service startup policy using the `vmware_host_service_manager` module, you have to specify the service state if you don't want to start the service, which is the default behavior.

##### ISSUE TYPE
- Feature Idea

##### COMPONENT NAME
<!--- Write the short name of the module, plugin, task or feature below, use your best guess if unsure -->
`vmware_host_service_manager` in community.vmware v1.11.0

##### ADDITIONAL INFORMATION
<!--- Describe how the feature would be used, why it is needed and what it would solve -->
Using the Ansible module should probably match the vSphere Client management behavior. It is not necessary to know the service state before changing the startup policy. The workaround is to use `vmware_host_service_info` module to first gather the state and then use it (which is kinda complicated way as the output values of the variable `running` from the `vmware_host_service_info` don't match the input values of the variable `state` in `vmware_host_service_manager`).

The `state` value of `unchanged` could be added (and set as default?). The current default is `start`.

Example playbook with the changes implemented:
<!--- Paste example playbooks or commands between quotes below -->
```yaml
- hosts: localhost
  gather_facts: false
  tasks:
    - name: Disabling SSH service
      community.vmware.vmware_host_service_manager:
        esxi_hostname: <esxi_hostname>
        service_name: 'TSM-SSH'
        service_policy: 'off'
        state: 'unchanged'
```

<!--- HINT: You can also paste gist.github.com links for larger files -->



Discussion:
Files identified in the description:
None

If these files are inaccurate, please update the `component name` section of the description or use the `!component` bot command.

[click here for bot help](https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md)
<!--- boilerplate: components_banner --->
@tomasodehnal: Greetings! Thanks for taking the time to open this issue. In order for the community to handle your issue effectively, we need a bit more information.

Here are the items we could not find in your description:
- ansible version

Please set the description of this issue with this template:
https://raw.githubusercontent.com/ansible/ansible/devel/.github/ISSUE_TEMPLATE/bug_report.md

[click here for bot help](https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md)
<!--- boilerplate: issue_missing_data --->
##### ISSUE TYPE
- Feature Idea
I agree that it's a bit weird that you need to know the current state just to change the startup policy. But I don't like your example playbook:

> ```yaml
> - hosts: localhost
>   gather_facts: false
>   tasks:
>     - name: Disabling SSH service
>       community.vmware.vmware_host_service_manager:
>         esxi_hostname: <esxi_hostname>
>         service_name: 'TSM-SSH'
>         service_policy: 'off'
>         state: 'unchanged'
> ```

Personally, I don't like `unchanged` as a new `state`. I think it would be better to make `state` optional. This way, if you don't care about the current state you could just drop this parameter instead of explicitly stating that you don't want to change it.

Unfortunately, removing a default for a parameter is a breaking change. So we won't do this within 1.x, maybe with 2.0. I'll try to prepare the module for this.
Thanks for the response. You are right, I don't like it either, but exactly as you say, I was considering the breaking change.
I don't know how far 2.0 is. If it's not near, it would be great if `unchanged` could be first introduced as an option and later changed to default.

EDIT: Probably not a good idea as it would mean changing the code twice. I haven't taken into account that your proposal is making the parameter optional.
Good point. Maybe we should introduce a new state `unchanged` and, at the same time, announce that this state is deprecated and that the `state` parameter itself won't have a default in a future release.

Resolving patch:
diff --git a/plugins/modules/vmware_host_service_manager.py b/plugins/modules/vmware_host_service_manager.py
--- a/plugins/modules/vmware_host_service_manager.py
+++ b/plugins/modules/vmware_host_service_manager.py
@@ -41,7 +41,8 @@
     - Desired state of service.
     - "State value 'start' and 'present' has same effect."
     - "State value 'stop' and 'absent' has same effect."
-    choices: [ absent, present, restart, start, stop ]
+    - State value C(unchanged) is added in version 1.14.0 to allow defining startup policy without defining or changing service state.
+    choices: [ absent, present, restart, start, stop, unchanged ]
     type: str
     default: 'start'
   service_policy:
@@ -201,7 +202,7 @@ def main():
     argument_spec.update(
         cluster_name=dict(type='str', required=False),
         esxi_hostname=dict(type='str', required=False),
-        state=dict(type='str', default='start', choices=['absent', 'present', 'restart', 'start', 'stop']),
+        state=dict(type='str', default='start', choices=['absent', 'present', 'restart', 'start', 'stop', 'unchanged']),
         service_name=dict(type='str', required=True),
         service_policy=dict(type='str', choices=['automatic', 'off', 'on']),
     )


Test patch: