Bug 1561539

though i think should be possible to achieve it today (https://docs.ansible.com/ansible/latest/modules/ovirt_hosts_module.html#ovirt-hosts-module state: maintenance), I hjust appen to think that it shouldn't be the way to go, since if something is wrong, we should see it, fix it, rerun playbook..

any reason not to use ovirt-ansible-infra role for tackling this use case?
https://github.com/oVirt/ovirt-ansible-infra/blob/master/README.md
should cover RHV configuration end to end.

*** Bug 1546058 has been marked as a duplicate of this bug. ***

(In reply to Moran Goldboim from comment #2)
> though i think should be possible to achieve it today
> (https://docs.ansible.com/ansible/latest/modules/ovirt_hosts_module.
> html#ovirt-hosts-module state: maintenance), I hjust appen to think that it
> shouldn't be the way to go, since if something is wrong, we should see it,
> fix it, rerun playbook..
It actually cannot:

...
  tasks:                                                                         
    - name: add host                                                             
      ovirt_hosts:                                                               
        auth: "{{ ovirt_auth }}"                                                 
        cluster: Default                                                         
        name: rhel-h7-42-01
        address: rhel-h7-42-01
        override_iptables: false                                                 
        power_management_enabled: false                                          
        password: secret
        state: maintenance                                                       
...

ansible-playbook -u root -i inv addHost.yaml 

PLAY [add host to cluster] ***************************

TASK [Login to RHV] ******************************************************
ok: [rhvm.example.com]

TASK [add host] **************************
fatal: [rhvm.example.com]: FAILED! => {"changed": false, "msg": "Entity not found, can't run action 'deactivate'."}
	to retry, use: --limit @/home/user/Downloads/addHost.retry

PLAY RECAP ****************************
rhvm.example.com: ok=1    changed=0    unreachable=0    failed=1   


> 
> any reason not to use ovirt-ansible-infra role for tackling this use case?
> https://github.com/oVirt/ovirt-ansible-infra/blob/master/README.md
> should cover RHV configuration end to end.

Good point, It is hard to find the roles.

Moving back to MODIFIED as RESTAPI verification requires new model as mentioned in http://gerrit.ovirt.org/96948

Tested on ovirt-engine-4.3.0.2-0.1.el7.noarch

This feature works for adding host with either REST API and UI.
This also works for reinstalling the host through UI.

However this does not work when reinstalling the host through REST API, in that case it doesn't care about activate and always leaves the host in maintenance.

I'm running:
curl -v -u "admin@internal:password" -H "Content-type: application/xml" --insecure -X POST https://engine/ovirt-engine/api/hosts/host_id/install -d "<action><activate>true</activate><root_password>password</root_password></action>"

In the engine logs you can find first test with activate true, then activate not set and then set to false, in either case host stays in maintenance.

Activating the host on reinstall actually works when I specify it in the URL as '...host_id/install?activate=true'.
However as the default value is supposed to be true there is still an issue with that, as it is actually false
And I think it should be possible to supply activate inside the action as data, because in the apidoc it is on the same level as e.g. root password which is supplied through data.

Not blocking ovirt-4.3.0 on this, moving to 4.3.1

Hi Petr, I'll try to address your concerns in Comment 12.

About the default value of 'activate' - in case of install it is supposed to be 'false'. This is because the host can only be reinstalled when it is in maintenance mode, and since maintenance is the initial state we would expect the host to return to maintenance when installation completes. This was the behavior previously as well, unless I am mistaken.

About the reason why 'activate' is provided as a URL parameter - this is because it's needed both when adding a host and when installing a host. When installing a host we provide an 'action' object and I agree that 'activate' would fit naturally in it: 

  POST  .../api/hosts/xxx/install 
  
  <action>
    <activate>true</activate>
  </action>

But when creating a host we are providing a host object and 'activate' is not a property of the host, it's not a natural part of the host representation: 


  POST .../api/hosts

  <host>
     <name>some_host</name>
     <activate>true</activate>   #(not good)
  </host>

Providing activate in the URL in one scenario (add) and in the body in another scenario (install) is inconsistent, so I decided to have them both in the URL. Maybe this wasn't the right decision because I understand why you got confused. Perhaps in case of install we could allow both - meaning 'activate' may be provided in the URL or in the body of the request, in the 'action' object, although there could always be that annoying user that does:

  POST  .../api/hosts/xxx/install;activate=false
  
  <action>
    <activate>true</activate>
  </action>

What do you think?

I've enabled providing 'activate' in the body of the request for install host and approve host: 

  https://gerrit.ovirt.org/#/c/97530/

About the default behavior when installing a host using the API - I've verified again by looking at the code. The host is indeed left in maintenance by default. So nothing changed here and there is no problem; same behavior as before. 

It's true that 'Activate host after install' checkbox in the WebAdmin is checked by default when installing a host. But I don't see that as an inconsistency and I don't think this requires a change. 

So to summarize could you please check this again once  https://gerrit.ovirt.org/#/c/97530/ is merged and this time you should see that providing <activate>true</activate> in the body of the request for install and approve should work as well, then we can close this bug

Sure, I'll just reverify with activate in action body.
And if you don't think the defaults are an inconsistency then I'm OK with that as it keeps the previous behaviour.

Thanks. https://gerrit.ovirt.org/#/c/97530/ has just been approved and merged

Verified on ovirt-engine-4.3.1.1-0.1.el7.noarch

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:1085

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days