Hide Forgot
The activation of the host may take additional time depending on the configuration. It would be better if the deployment process could be configurable so the host is deployed and remains in the maintenance mode.In case that the host deploy is handled via the ansible. The process sometimes fails due to the activation process. For instance, in case there is an issue with storage connection. The host does not have to be activated immediately.
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