Bug 1632257

Hi Ondra,

It looks like the issue is in tasks/cluster_policy.yml, where the previous policy name is remembered, but not the values.

I'd like to help, but my I'm not skilled enough with Ansible.

Can I test or help in some ways?

Hi Nicolas,

I've sent a PR with a fix:

 https://github.com/oVirt/ovirt-ansible-cluster-upgrade/pull/29

If you can verify it, it would be great. Here is RPM with a fix:

 https://jenkins.ovirt.org/job/oVirt_ovirt-ansible-cluster-upgrade_standard-check-pr/40/artifact/check-patch.el7.x86_64/ovirt-ansible-cluster-upgrade-1.1.9-0.1.master.20181019075602.el7.noarch.rpm

Hi Ondra,

Thank you for your PR.
I've just upgraded to 4.2.7, then installed your new RPM, then tried it.

At the end of the run, when the ansible recipe tries to set the parameters back, it fails with the following message :

TASK [oVirt.cluster-upgrade : Set original cluster policy] **********************************************************************************************************************************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Unsupported parameters for (ovirt_clusters) module: custom_scheduling_policy_properties Supported parameters include: auth, ballooning, comment, compatibility_version, cpu_arch, cpu_type, data_center, description, external_network_providers, fence_connectivity_threshold, fence_enabled, fence_skip_if_connectivity_broken, fence_skip_if_sd_active, fetch_nested, gluster, ha_reservation, host_reason, ksm, ksm_numa, mac_pool, memory_policy, migration_auto_converge, migration_bandwidth, migration_bandwidth_limit, migration_compressed, migration_policy, name, nested_attributes, network, poll_interval, resilience_policy, rng_sources, scheduling_policy, scheduling_policy_properties, serial_policy, serial_policy_value, spice_proxy, state, switch_type, threads_as_cores, timeout, trusted_service, virt, vm_reason, wait"}

Right, I wonder how it could work for me, I've fixed it, so if you can re-verify, would be very cool:

https://jenkins.ovirt.org/job/oVirt_ovirt-ansible-cluster-upgrade_standard-check-pr/43/artifact/build-artifacts.el7.x86_64/ovirt-ansible-cluster-upgrade-1.1.9-0.1.master.20181105095815.el7.noarch.rpm

(In reply to Ondra Machacek from comment #4)
> Right, I wonder how it could work for me, I've fixed it, so if you can
> re-verify, would be very cool:
> 
> https://jenkins.ovirt.org/job/oVirt_ovirt-ansible-cluster-upgrade_standard-
> check-pr/43/artifact/build-artifacts.el7.x86_64/ovirt-ansible-cluster-
> upgrade-1.1.9-0.1.master.20181105095815.el7.noarch.rpm

Hello Ondra,

Thank you for this patch.
I've just tested it, and I witness the values are correctly set back, but to be honest, it this point there is no hosts needing any updates.
I'm pretty sure that won't change the behavior of your Ansible recipe, and it will run the same way after having actually updated hosts, but I wanted to be clear.

Before closing this bug, do you prefer to wait for me for further updates in which case I'll run a final test?

Hello Ondra,

This morning my hosts were needing upgrades, so I ran your Ansible script.
The cluster scheduling values were correctly restored.

So you can close this bug.

Thank you for your help.

Have a nice day.

-- 
Nico

Thanks, Nicolas, for your contribution!

This bugzilla is included in oVirt 4.2.8 release, published on January 22nd 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.2.8 release, it has been closed with a resolution of CURRENT RELEASE.

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