Hyperconverged Single Host Glusterfs timing issue
by Glenn Marcy
Now that I've been able to get past my issues with q35 bios I decided to try the hyperconverged install. setting up the storage was no problem and the engine setup went fine until the point where it wanted to use that glusterfs storage. I got the error, pretty quickly I might add, of
2020-06-30 02:17:50,689-0400 DEBUG ansible on_any args <ansible.executor.task_result.TaskResult object at 0x7f83f85b4278> kwargs
2020-06-30 02:17:51,428-0400 INFO ansible task start {'status': 'OK', 'ansible_type': 'task', 'ansible_playbook': '/usr/share/ovirt-hosted-engine-setup/ansible/trigger_role.yml', 'ansible_task': 'ovirt.hosted_engine_setup : Add glusterfs storage domain'}
2020-06-30 02:17:51,428-0400 DEBUG ansible on_any args TASK: ovirt.hosted_engine_setup : Add glusterfs storage domain kwargs is_conditional:False
2020-06-30 02:17:51,429-0400 DEBUG ansible on_any args localhostTASK: ovirt.hosted_engine_setup : Add glusterfs storage domain kwargs
2020-06-30 02:17:53,656-0400 DEBUG var changed: host "localhost" var "otopi_storage_domain_details_gluster" type "<class 'dict'>" value: "{
"changed": false,
"exception": "Traceback (most recent call last):
File \"/tmp/ansible_ovirt_storage_domain_payload_jh42k_ip/ansible_ovirt_storage_domain_payload.zip/ansible/modules/cloud/ovirt/ovirt_storage_domain.py\", line 792, in main
File \"/tmp/ansible_ovirt_storage_domain_payload_jh42k_ip/ansible_ovirt_storage_domain_payload.zip/ansible/module_utils/ovirt.py\", line 623, in create
**kwargs
File \"/usr/lib64/python3.6/site-packages/ovirtsdk4/services.py\", line 26097, in add
return self._internal_add(storage_domain, headers, query, wait)
File \"/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py\", line 232, in _internal_add
return future.wait() if wait else future
File \"/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py\", line 55, in wait
return self._code(response)
File \"/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py\", line 229, in callback
self._check_fault(response)
File \"/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py\", line 132, in _check_fault
self._raise_error(response, body)
File \"/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py\", line 118, in _raise_error
raise error\novirtsdk4.Error: Fault reason is \"Operation Failed\". Fault detail is \"[Failed to fetch Gluster Volume List]\". HTTP response code is 400.\n",
"failed": true,
"msg": "Fault reason is \"Operation Failed\". Fault detail is \"[Failed to fetch Gluster Volume List]\". HTTP response code is 400."
}"
The glusterfs cli worked fine by that point, had no issues with volume list, so I went into the node:6900/ovirt-engine forwarder to the appliance and could see that at the time of that error in the event logs there was a message that it was starting to update things and a few seconds later a message that the volumes were available.
I am thinking that there is need for a retry loop in this step or that something in the path isn't waiting for something internal to complete before issuing the Operation Failed error.
Regards,
Glenn Marcy
1 year, 2 months
OST failing because of modular filtering error
by Parth Dhanjal
Hey!
I am unable to install gluster-ansible-roles on VMs because of an error
from modular filtering
> - conflicting requests
> - package python-six-1.9.0-2.el7.noarch is filtered out by modular
> filtering
> - package python2-cryptography-1.7.2-2.el7.x86_64 is filtered out by
> modular filtering
> - package python2-cryptography-2.1.4-2.el7.x86_64 is filtered out by
> modular filtering
> - package python2-six-1.10.0-9.el7.noarch is filtered out by modular
> filtering
> - package python-six-1.9.0-1.el7.noarch is filtered out by modular
> filtering
>
I tried disabling the modular packages but still facing this issue, can
someone suggest a fix?
Regards
Parth Dhanjal
1 year, 2 months
Why are UI tests failing on ovirt-system-tests_manual ?
by Lucia Jelinkova
Hi all,
If you're running manual OST tests Jenkins job [1] with custom repository
pointing to your ovirt-engine Gerrit check patch job, you most probably
notice that the UI tests are failing with one of the following errors:
basic-suite-master.test-scenarios.100_basic_ui_sanity_pytest.test_left_nav[firefox]
basic-suite-master.test-scenarios.100_basic_ui_sanity_pytest.test_virtual_machines[chrome]
This is due to the fact that the normal check patch job does not always
build GWT (first error) or it does not build GWT for both Firefox and
Chrome (second error). If you want to test your ovirt-engine patch, please
comment "ci build" on the patch, wait for the job to finish and use that
job as a custom repository to run tests.
I know that many devs know this "trick" but it might not be so clear for
people not so long on the project.
If you see any other issue, look into the screenshots or saved html in the
exported artifacts. If you think it is a problem with tests, please contact
me.
Regards,
Lucia
1:
https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-te...
1 year, 2 months
oVirt 2020 online conference
by Sandro Bonazzola
It is our pleasure to invite you to oVirt 2020 online conference. The
conference,organized by oVirt community, will take place online on Monday,
September 7th 2020!
oVirt 2020 is a free conference for oVirt community project users and
contributors coming to a web browser near you!
There is no admission or ticket charge for this event. However, you will be
required to complete a free registration.
Watch https://blogs.ovirt.org/ovirt-2020-online-conference/ for updates
about registration. Talks, presentations and workshops will all be in
English.
We encourage students and new graduates as well as professionals to submit
proposals to oVirt conferences.
We will be looking for talks and discussions across virtualization, and how
oVirt 4.4 can effectively solve user issues around:
- Upgrade flows
- New features
- Integration with other projects
- User stories
The deadline to submit abstracts is July 26th 2020.
To submit your abstract, please click on the following link: submission form
<https://forms.gle/1RDUwPGKobJfKhaYA>
More information are available at
https://blogs.ovirt.org/ovirt-2020-online-conference/
Thanks,
--
Sandro Bonazzola
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo(a)redhat.com
<https://www.redhat.com/>
*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.
<https://mojo.redhat.com/docs/DOC-1199578>*
1 year, 2 months
getVds().getInterfaces() is returning empty list of VdsNetworkInterface everytime
by Prajith Kesava Prasad
Hey Everyone,
what I'm trying to achieve here is to get the list of network interfaces
attached to each host,
and then further get the ipv4Address from the corresponding attached
logical network (as seen in the in the column in the image below).
So i tried to get the list of interfaces of current host by
getVds().getInterfaces() and it is returning an empty list
of List<VdsNetworkInterface>.
even though its showing in the UI.
Could you tell me if I'm missing something?
FYI:- (I'm ran vdsm-cliend Host getCapablities and getNetworkCapablities
and it was returning correctly.)
Regards,
Prajith.
[image: image.png]
1 year, 3 months
Re: Proposing Ales Musil as VDSM network maintainer
by Nir Soffer
On Mon, Jun 22, 2020 at 1:13 PM Marcin Sobczyk <msobczyk(a)redhat.com> wrote:
> On 6/22/20 11:00 AM, Edward Haas wrote:
>
> Hello to all VDSM maintainers,
These discussions should be public.
Adding devel(a)ovirt.org
> I hope I did not miss any active maintainers.
>
> I'd like to nominate Ales Musil to formally take over the vdsm-network vertical as a maintainer
> after acting as such in the last period.
>
> Would you approve adding him to the vdsm-master-maintainers
> https://gerrit.ovirt.org/#/admin/groups/106,members list,
> so he will not be blocked on my availability?
>
> +1
I don't see any problem, so +1.
Let's wait a few days for more feedback on devel.
Nir
1 year, 3 months
Closed bugs / issues rant
by Sandro Bonazzola
Hi,
I want to share some thoughts on bugs and issues currently in closed state
for a target milestone > ovirt-4.4.1
To my perspective:
*Wontfix*
should drop target milestone. The bug won't be fixed in the targeted
milestone. Keeping the target milestone gives the false impression that
starting from targeted milestone it will be magically done.
*Deferred*
should drop target milestone. The bug won't be fixed in the targeted
milestone. Keeping the target milestone gives the false impression that
starting from targeted milestone it will be magically done.
*Duplicate*
should have the same target milestone of the duplicated bug. Having a
bug targeting 4.4.3 duplicated of a bug fixed in 4.4.1 can lead to
impression the bug has been closed by mistake, being a regression appeared
after the real bug has been closed.
*Works for me*
should have a target milestone set to current release. Having a works
for me targeted to 4.4.3 while still working on 4.4.1 doesn't make sense to
me.
*Not a bug*
should have a target milestone set to current release. Having a not a
bug targeted to 4.4.3 while still working on 4.4.1 doesn't make sense to
me. If it's not a bug it's not a bug already right now.
I'm addressing bugs I stumble upon, but please take care of properly
targeting your bugs. It helps a lot understanding what's being fixed and
what not and why.
--
Sandro Bonazzola
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo(a)redhat.com
<https://www.redhat.com/>
*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.
<https://mojo.redhat.com/docs/DOC-1199578>*
1 year, 3 months
Re: [oVirt Jenkins] ovirt-system-tests_he-basic-suite-4.3 - Build # 472 - Failure!
by Yedidyah Bar David
On Sat, Jun 13, 2020 at 5:01 AM <jenkins(a)jenkins.phx.ovirt.org> wrote:
>
> Project: https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-4.3/
> Build: https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-4.3/472/
This failed in:
https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-4.3/474/t...
Fault reason is "Operation Failed". Fault detail is "[Cannot activate
Host. Related operation is currently in progress. Please try again
later.]". HTTP response code is 409.
engine.log has:
https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-4.3/474/a...
2020-06-15 00:00:58,330-04 INFO
[org.ovirt.engine.core.bll.RefreshHostCapabilitiesCommand]
(ForkJoinPool-1-worker-8) [3715b680] Running command:
RefreshHostCapabilitiesCommand internal: true. Entities affected :
ID: e75bc41d-c044-40f6-a645-9a86f2ef2536 Type: VDSAction group
MANIPULATE_HOST with role type ADMIN
2020-06-15 00:00:58,331-04 INFO
[org.ovirt.engine.core.bll.RefreshHostCapabilitiesCommand]
(ForkJoinPool-1-worker-8) [3715b680] Before acquiring lock in order to
prevent monitoring for host 'lago-he-basic-suite-4-3-host-0' from
data-center 'Default'
2020-06-15 00:00:58,332-04 INFO
[org.ovirt.engine.core.bll.lock.InMemoryLockManager]
(ForkJoinPool-1-worker-8) [3715b680] Failed to acquire lock and wait
lock 'HostEngineLock:{exclusiveLocks='[e75bc41d-c044-40f6-a645-9a86f2ef2536=VDS_INIT]',
sharedLocks=''}'
2020-06-15 00:00:58,337-04 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IrsProxy]
(EE-ManagedThreadFactory-engine-Thread-281) [] Clearing cache of pool:
'e186881e-aeb0-11ea-8e5b-5452c0a8c863' for problematic entities of
VDS: 'lago-he-basic-suite-4-3-host-0'.
2020-06-15 00:00:58,337-04 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IrsProxy]
(EE-ManagedThreadFactory-engine-Thread-281) [] Removing vds
'[e75bc41d-c044-40f6-a645-9a86f2ef2536]' from the domain in
maintenance cache
2020-06-15 00:00:58,338-04 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IrsProxy]
(EE-ManagedThreadFactory-engine-Thread-281) [] Removing host(s)
'[e75bc41d-c044-40f6-a645-9a86f2ef2536]' from hosts unseen domain
report cache
2020-06-15 00:00:58,382-04 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStoragePoolVDSCommand]
(EE-ManagedThreadFactory-engineScheduled-Thread-60) [] START,
DisconnectStoragePoolVDSCommand(HostName =
lago-he-basic-suite-4-3-host-0,
DisconnectStoragePoolVDSCommandParameters:{hostId='e75bc41d-c044-40f6-a645-9a86f2ef2536',
storagePoolId='e186881e-aeb0-11ea-8e5b-5452c0a8c863',
vds_spm_id='1'}), log id: e9ba207
2020-06-15 00:00:58,498-04 INFO
[org.ovirt.engine.core.bll.lock.InMemoryLockManager]
(ForkJoinPool-1-worker-8) [3715b680] Failed to acquire lock and wait
lock 'HostEngineLock:{exclusiveLocks='[e75bc41d-c044-40f6-a645-9a86f2ef2536=VDS_INIT]',
sharedLocks=''}'
2020-06-15 00:01:01,657-04 INFO
[org.ovirt.engine.core.bll.lock.InMemoryLockManager]
(ForkJoinPool-1-worker-8) [3715b680] Failed to acquire lock and wait
lock 'HostEngineLock:{exclusiveLocks='[e75bc41d-c044-40f6-a645-9a86f2ef2536=VDS_INIT]',
sharedLocks=''}'
2020-06-15 00:01:03,556-04 INFO
[org.ovirt.engine.core.bll.ActivateVdsCommand] (default task-1)
[e4c7e809-7883-47dc-b7da-3236cc754ebb] Failed to Acquire Lock to
object 'EngineLock:{exclusiveLocks='[e75bc41d-c044-40f6-a645-9a86f2ef2536=VDS]',
sharedLocks=''}'
2020-06-15 00:01:03,585-04 WARN
[org.ovirt.engine.core.bll.ActivateVdsCommand] (default task-1)
[e4c7e809-7883-47dc-b7da-3236cc754ebb] Validation of action
'ActivateVds' failed for user admin@internal-authz. Reasons:
VAR__ACTION__ACTIVATE,VAR__TYPE__HOST,ACTION_TYPE_FAILED_OBJECT_LOCKED
2020-06-15 00:01:03,864-04 ERROR
[org.ovirt.engine.api.restapi.resource.AbstractBackendResource]
(default task-1) [] Operation Failed: [Cannot activate Host. Related
operation is currently in progress. Please try again later.]
Sandro reported about a similar case in the thread:
[ovirt-devel] ovirt-system-tests_he-basic-suite-4.3 fails on storage
domain unreachable
About:
https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-4.3/427/
Can't see there any response.
Can someone please have a look? Thanks.
Best regards,
--
Didi
1 year, 3 months
