On 10/02/2021 09:36, Ales Musil wrote:
It seems like it might be a bug in nmstate would you be willing to try:
dnf -y copr enable packit/nmstate-nmstate-1508
dnf -y update nmstate

reboot the host and then redeploy?
I think it is looking better. There were some other updates dnf pulled in. So, short & incomplete list of rpms:

cockpit-ovirt-dashboard-0.14.20-0.0.master.20210207161806.git6ee9bc3.el8.noarch
ovirt-ansible-collection-1.3.1-0.1.master.20210128112414.el8.noarch
ovirt-engine-appliance-4.4-20210208183902.1.el8.x86_64
ovirt-host-4.4.6-0.0.20210127122119.gitef84c5a.el8.x86_64
ovirt-host-dependencies-4.4.6-0.0.20210127122119.gitef84c5a.el8.x86_64
ovirt-hosted-engine-ha-2.4.7-0.0.master.20210203134854.20210203134846.git7d297c2.el8.noarch
ovirt-hosted-engine-setup-2.5.0-0.0.master.20201216174101.git2a94b06.el8.noarch
ovirt-imageio-client-2.2.0-0.202102041750.git98b0a36.el8.x86_64
ovirt-imageio-common-2.2.0-0.202102041750.git98b0a36.el8.x86_64
ovirt-imageio-daemon-2.2.0-0.202102041750.git98b0a36.el8.x86_64
ovirt-openvswitch-2.11-0.2020061801.el8.noarch
ovirt-openvswitch-ovn-2.11-0.2020061801.el8.noarch
ovirt-openvswitch-ovn-common-2.11-0.2020061801.el8.noarch
ovirt-openvswitch-ovn-host-2.11-0.2020061801.el8.noarch
ovirt-provider-ovn-driver-1.2.34-0.20201207083749.git75016ed.el8.noarch
ovirt-python-openvswitch-2.11-0.2020061801.el8.noarch
ovirt-release-master-4.4.5-0.0.master.20210208011114.git6d17342.el8.noarch
ovirt-vmconsole-1.0.9-1.20201130191550.git0bf874a.el8.noarch
ovirt-vmconsole-host-1.0.9-1.20201130191550.git0bf874a.el8.noarch
python3-ovirt-engine-sdk4-4.4.10-1.20210208.gita10779e.el8.x86_64
python3-ovirt-setup-lib-1.3.3-0.0.master.20200727063144.git90cd6d9.el8.noarch

-> $ rpm -qa \*nmst\* | sort
nmstate-1.0.2-0.20210208061141616978.pr1508.13.gfcaaacf.el8.noarch
nmstate-plugin-ovsdb-1.0.2-0.20210208061141616978.pr1508.13.gfcaaacf.el8.noarch
python3-libnmstate-1.0.2-0.20210208061141616978.pr1508.13.gfcaaacf.el8.noarch

I hit now what's below. It might not relate to the original issue but just in case and so I can report back that "deployment" was 100% successful.
Here:
...
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Add NFS storage domain]
[ INFO  ] skipping: [localhost]
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Add glusterfs storage domain] [ ERROR ] Verify permission settings on the specified storage path.]". HTTP response code is 400. [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Fault reason is \"Operation Failed\". Fault detail is \"[Permission settings on the specified path do not allow access to the storage.\nVerify permission settings on the specified storage path.]\". HTTP response code is 400."}           Please specify the storage you would like to use (glusterfs, iscsi, fc, nfs)[nfs]: glusterfs           Please specify the full shared storage connection path to use (example: host:/path): 10.1.1.201:/oVirt           If needed, specify additional mount options for the connection to the hosted-engine storagedomain (example: rsize=32768,wsize=32768) []:
[ INFO  ] Creating Storage Domain
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Execute just a specific set of steps]
[ INFO  ] ok: [localhost]
...

And it loops around that stage.
I have no clue what it is saying. I can say though that I can mount & use that same glusterfs vol from the deploying host with no problems.

regards, L.
_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XHQHVRVHIU4A5ECM7TJBALLBJSFCNN3Z/

Reply via email to