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-leave@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/
