Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 851847

Summary:

repoStats is reporting delay when domain is blocked on NFS storage

Product:

Red Hat Enterprise Virtualization Manager

Reporter:

Dafna Ron <dron>

Component:

vdsm

Assignee:

Ayal Baron <abaron>

Status:

CLOSED NOTABUG

QA Contact:

Haim <hateya>

Severity:

medium

Docs Contact:

Priority:

medium

Version:

unspecified

CC:

abaron, amureini, bazulay, hateya, iheim, lpeer, yeylon, ykaul

Target Milestone:

---

Target Release:

3.1.0

Hardware:

x86_64

OS:

Linux

Whiteboard:

storage

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2013-04-03 11:41:16 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

Storage

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
log	none

Description Dafna Ron 2012-08-26 13:01:58 UTC

Created attachment 607061 [details]
log

Description of problem:

when blocking domain from host using iptables we are reporting a delay for the domain. 
it would be helpful if we could see that the response is false and not a delay.
after a while we are seeing that repoStats are not getting anything: 

Thread-526::INFO::2012-08-26 14:51:45,535::logUtils::37::dispatcher::(wrapper) Run and protect: repoStats(options=None)
Thread-526::INFO::2012-08-26 14:51:45,536::logUtils::39::dispatcher::(wrapper) Run and protect: repoStats, Return response: {}


Version-Release number of selected component (if applicable):

vdsm-4.9.6-30.0.el6_3.x86_64
si15

How reproducible:

100%

Steps to Reproduce:
1. block connectivity to the NFS storage from your host 
2. 
3.
  
Actual results:

Thread-2319::INFO::2012-08-26 14:35:41,136::logUtils::39::dispatcher::(wrapper) Run and protect: repoStats, Return response: {'2045e517-a65b-437d-8b2b-45018a5aaa23': {'delay': '0.00252914428711', 'lastCheck': 1345980874.140897, 'code': 

after vdsm sends error repoStats show the following:

Thread-526::INFO::2012-08-26 14:51:45,535::logUtils::37::dispatcher::(wrapper) Run and protect: repoStats(options=None)
Thread-526::INFO::2012-08-26 14:51:45,536::logUtils::39::dispatcher::(wrapper) Run and protect: repoStats, Return response: {}


Expected results:

it would be helpful to get a True/False for repoStats (as in domain is responding or not) as trying to locate the exact time we see a problem in the domain is tricky at this point. 

Additional info: logs

Comment 1 RHEL Program Management 2012-12-14 07:26:04 UTC

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 2 Haim 2013-04-03 11:41:16 UTC

(In reply to comment #0)
> Created attachment 607061 [details]
> log
> 
> Description of problem:
> 
> when blocking domain from host using iptables we are reporting a delay for
> the domain. 
> it would be helpful if we could see that the response is false and not a
> delay.
> after a while we are seeing that repoStats are not getting anything: 
> 
> Thread-526::INFO::2012-08-26
> 14:51:45,535::logUtils::37::dispatcher::(wrapper) Run and protect:
> repoStats(options=None)
> Thread-526::INFO::2012-08-26
> 14:51:45,536::logUtils::39::dispatcher::(wrapper) Run and protect:
> repoStats, Return response: {}
> 
> 
> Version-Release number of selected component (if applicable):
> 
> vdsm-4.9.6-30.0.el6_3.x86_64
> si15
> 
> How reproducible:
> 
> 100%
> 
> Steps to Reproduce:
> 1. block connectivity to the NFS storage from your host 
> 2. 
> 3.
>   
> Actual results:
> 
> Thread-2319::INFO::2012-08-26
> 14:35:41,136::logUtils::39::dispatcher::(wrapper) Run and protect:
> repoStats, Return response: {'2045e517-a65b-437d-8b2b-45018a5aaa23':
> {'delay': '0.00252914428711', 'lastCheck': 1345980874.140897, 'code': 
> 
> after vdsm sends error repoStats show the following:
> 
> Thread-526::INFO::2012-08-26
> 14:51:45,535::logUtils::37::dispatcher::(wrapper) Run and protect:
> repoStats(options=None)
> Thread-526::INFO::2012-08-26
> 14:51:45,536::logUtils::39::dispatcher::(wrapper) Run and protect:
> repoStats, Return response: {}
> 
> 
> Expected results:
> 
> it would be helpful to get a True/False for repoStats (as in domain is
> responding or not) as trying to locate the exact time we see a problem in
> the domain is tricky at this point. 
we do provide True\False, but after a given timeout of 60 seconds, I don't think its a bug.