8:59 a.m.
I am having problems installing a 3-node HCI cluster on machines that used to work
fine.... and on a fresh set of servers, too.
After a series of setbacks on a set of machines with failed installations and potentially
failed clean-ups, I am ssing a fresh set of servers that had never run oVirt before.
Patched to just before today's bigger changes (new kernel..) installation failed
during the setup of the local hosted engine first and when I switched from GUi to script
setup 'hosted-engine --deploy' *without* doing a cleanup this time, it progressed
further to the point where the local VM had actually been teleported onto the (gluster
based) cluster and is running there.
In what seems the absolutely final action before adding the other two hosts, ansible is
doing a finaly inventory of the virtual machine and collects facts or rather information
(that's perhaps the breaking point) about that first VM before I would continue, only
the data structure got renamed between ansible 2.8 and 2.9 according to this:
https://fossies.org/diffs/ansible/2.8.5_vs_2.9.0rc1/lib/ansible/modules/c...
And the resulting error message from the
/var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-*.log file is:
2019-12-04 13:15:19,232+0000 ERROR otopi.ovirt_hosted_engine_setup.ansible_utils
ansible_utils._process_output:107 fatal: [localhost]: FAILED! =>
{"ansible_facts": {"ovirt_vms": [{"affinity_labels": [],
"applications": [], "bios": {"boot_menu":
{"enabled": false}, "type": "i440fx_sea_bios"},
"cdroms": [], "cluster": {"href":
"/ovirt-engine/api/clusters/6616551e-1695-11ea-a86b-00163e34e004",
"id": "6616551e-1695-11ea-a86b-00163e34e004"}, "comment":
"", "cpu": {"architecture": "x86_64",
"topology": {"cores": 1, "sockets": 4, "threads":
1}}, "cpu_profile": {"href":
"/ovirt-engine/api/cpuprofiles/58ca604e-01a7-003f-01de-000000000250",
"id": "58ca604e-01a7-003f-01de-000000000250"}, "cpu_shares":
0, "creation_time": "2019-12-04 13:01:12.780000+00:00",
"delete_protected": false, "description": "",
"disk_attachments": [], "display": {"address":
"127.0.0.1", "allow_override": false, "certificate":
{"content": "-----BEGIN CERTIFICATE-----(redacted)-----END
CERTIFICATE-----\n", "organization":
"***", "subject": "**"}, "copy_paste_enabled":
true, "disconnect_action": "LOCK_SCREEN",
"file_transfer_enabled": true, "monitors": 1, "port": 5900,
"single_qxl_pci": false, "smartcard_enabled": false, "type":
"vnc"}, "fqdn": "xdrd1001s.priv.atos.fr",
"graphics_consoles": [], "guest_operating_system":
{"architecture": "x86_64", "codename": "",
"distribution": "CentOS Linux", "family": "Linux",
"kernel": {"version": {"build": 0, "full_version":
"3.10.0-1062.4.3.el7.x86_64", "major": 3, "minor": 10,
"revision": 1062}}, "version": {"full_version":
"7", "major": 7}}, "guest_time_zone": {"name":
"GMT", "utc_offset": "+00:00"},
"high_availability": {"enabled": false, "priority": 0},
"host": {"href":
"/ovirt-engine/api/hosts/75d096fd-4a2f-4ba4-b9fb-941f86daf624", "id":
"75d096fd-4a2f-4ba4-b9fb-941f86daf624"}, "host_devices": [],
"href": "/ovirt-engine/api/vms/dee6ec3b-5b4a-4063-ade9-12dece0f5fab",
"id": "dee6ec3b-5b4a-4063-ade9-12dece0f5fab", "io":
{"threads": 1}, "katello_errata": [], "la
rge_icon": {"href":
"/ovirt-engine/api/icons/9588ebfc-865a-4969-9829-d170d3654900", "id":
"9588ebfc-865a-4969-9829-d170d3654900"}, "memory": 17179869184,
"memory_policy": {"guaranteed": 17179869184, "max":
17179869184}, "migration": {"auto_converge": "inherit",
"compressed": "inherit"}, "migration_downtime": -1,
"multi_queues_enabled": true, "name":
"external-HostedEngineLocal", "next_run_configuration_exists": false,
"nics": [], "numa_nodes": [], "numa_tune_mode":
"interleave", "origin": "external",
"original_template": {"href":
"/ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000",
"id": "00000000-0000-0000-0000-000000000000"}, "os":
{"boot": {"devices": ["hd"]}, "type":
"other"}, "permissions": [], "placement_policy":
{"affinity": "migratable"}, "quota": {"id":
"7af18f3a-1695-11ea-ab7e-00163e34e004"}, "reported_devices": [],
"run_once": false, "sessions": [], "small_icon":
{"href":
"/ovirt-engine/api/icons/dec3572e-7465-4527-884b-f7c2eb2ed811", "id":
"dec3572e-7465-4
527-884b-f7c2eb2ed811"}, "snapshots": [], "sso":
{"methods": [{"id": "guest_agent"}]},
"start_paused": false, "stateless": false, "statistics": [],
"status": "unknown", "storage_error_resume_behaviour":
"auto_resume", "tags": [], "template": {"href":
"/ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000",
"id": "00000000-0000-0000-0000-000000000000"}, "time_zone":
{"name": "Etc/GMT"}, "type": "desktop",
"usb": {"enabled": false}, "watchdogs": []}]},
"attempts": 24, "changed": false, "deprecations":
[{"msg": "The 'ovirt_vm_facts' module has been renamed to
'ovirt_vm_info', and the renamed one no longer returns ansible_facts",
"version": "2.13"}]}
If that is the case, wouldn't that imply that there is no test case that covers the
most typical HCI deployment when Ansible is updated?
That would be truly frightening...
2:39 a.m.
New subject: Did a change in Ansible 2.9 in the ovirt_vm_facts module break the hosted-engine-setup?
This seems to be a much bigger generic issue with Ansible 2.9. Here is an excerpt from the
release notes:
"Renaming from _facts to _info
Ansible 2.9 renamed a lot of modules from <something>_facts to
<something>_info, because the modules do not return Ansible facts. Ansible facts
relate to a specific host. For example, the configuration of a network interface, the
operating system on a unix server, and the list of packages installed on a Windows box are
all Ansible facts. The renamed modules return values that are not unique to the host. For
example, account information or region data for a cloud provider. Renaming these modules
should provide more clarity about the types of return values each set of modules
offers."
I guess that means all the oVirt playbooks need to be adapted for Ansible 2.9 and that
evidently didn't happen or not completely.
It would also seem to suggest that there is no automated integration testing before an
oVirt release... which contradicts the opening clause of the opening phrase of the
ovirt.org download page: "oVirt 4.3.7 is intended for production use and is available
for the following platforms..."
5:23 a.m.
New subject: Did a change in Ansible 2.9 in the ovirt_vm_facts module break the hosted-engine-setup?
On Thu, Dec 12, 2019 at 9:40 AM <thomas(a)hoberg.net> wrote:
This seems to be a much bigger generic issue with Ansible 2.9. Here
is an
excerpt from the release notes:
"Renaming from _facts to _info
Ansible 2.9 renamed a lot of modules from <something>_facts to
<something>_info, because the modules do not return Ansible facts. Ansible
facts relate to a specific host. For example, the configuration of a
network interface, the operating system on a unix server, and the list of
packages installed on a Windows box are all Ansible facts. The renamed
modules return values that are not unique to the host. For example, account
information or region data for a cloud provider. Renaming these modules
should provide more clarity about the types of return values each set of
modules offers."
I guess that means all the oVirt playbooks need to be adapted for Ansible
2.9 and that evidently didn't happen or not completely.
We are going to adapt, but this is not a breaking change. Till Ansible 2.11
there is automatic linking between *_facts and *_info, only in 2.12 *_facts
will be removed. There is just deprecation warning about this tissue, but
no breakage.
Also please be aware that we will require Ansible 2.9 as minimum version
for oVirt 4.4.
It would also seem to suggest that there is no automated integration
testing before an oVirt release... which contradicts the opening clause of
the opening phrase of the ovirt.org download page: "oVirt 4.3.7 is
intended for production use and is available for the following platforms..."
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ROWX54XPPIG...
--
Martin Perina
Manager, Software Engineering
Red Hat Czech s.r.o.
10:23 a.m.
New subject: Did a change in Ansible 2.9 in the ovirt_vm_facts module break the hosted-engine-setup?
Thanks Martin, that actually helps a lot, because I was afraid of the implications.
So the error must really be elsewhere. I am having another look at the logs from the
HostedEngineLocal and it seems to complain that no Gluster members are up, not even the
initial one.
I also saw no entries in the Postgres gluster_servers table so I, killed the
HostedEngineLocal VM and am doing another setup run to see if I can find out what's
going wrong.
10:26 a.m.
New subject: Did a change in Ansible 2.9 in the ovirt_vm_facts module break the hosted-engine-setup?
What got me derailed was the "ERROR" tag and the fact that it was the last thing
to happen on the outside ("waiting for engine to be up"), while the
HostedEngineLocal on the inside was looking for Gluster members it couldn't find...
1620
days inactive
1628
days old
4 comments
2 participants
participants (2)
-
Martin Perina -
thomas＠hoberg.net