Support Migration Notice: To update migrated JIRA cases click here to open a new case use www.vmware.com/go/sr | vFabric Hyperic 5.7.0 is Now Available

Hyperic HQ

Conversion issue with Bits received/transmitted per second in alert condition

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Deferred
  • Affects Version/s: 3.1.1, 4.2.0
  • Fix Version/s: None
  • Component/s: Alerts
  • Environment:
    QA1, version 3.1.1, build # 473
  • Case Links:
    none
  • Tags:

Description

The alert condition converts absolute value for bit received/transmitted per second to Kb (kilo bits), Mb and Gb, this conversion seems to be wrong. Also when user tries to edit the field the value shows up as converted value with Kb, Mb or Gb unit. Submitting the updated value with keeping the units in the field incorrectly converts the value of the field.

Example:

Select a network interface
Create a bits received per second alert with absolute value set to 30,000
On submitting the form the alert value is converted to 234.4 Kbps, Shouldn't it be 30 Kbps (assuming that it means kilobits and not kilobytes per second)?
Edit the alert condition (Note that the if condition value is set to 234.4 Kbps)
Change the value to 30 Kbps and submit the form
Note that the value is set as 240.0 Kb (which is 30000 bytes), So in this case it seems like the form is expecting the value of kilobytes and not kilobits

In another case,
resubmitting the form with 234.4 Kbps changes the value to 1,875.2 Kb

Activity

Hide
Charles Lee added a comment -

We are actually storing the value in bytes behind the scenes because the value is derived from byte values. So when you input in an absolute value like 30000, it thinks you have put in 30000 bytes. There's not a workaround for that, but code has been modified to accept "30000b" to store the value correctly in bytes.

Show
Charles Lee added a comment - We are actually storing the value in bytes behind the scenes because the value is derived from byte values. So when you input in an absolute value like 30000, it thinks you have put in 30000 bytes. There's not a workaround for that, but code has been modified to accept "30000b" to store the value correctly in bytes.
Hide
Nipuna Bhayani added a comment -

Still the values gets converted into kilo bytes in build 600 release 3.2.0-EE

Show
Nipuna Bhayani added a comment - Still the values gets converted into kilo bytes in build 600 release 3.2.0-EE
Hide
Charles Lee added a comment -

Did you make sure to include the 'b' unit in your value?

Show
Charles Lee added a comment - Did you make sure to include the 'b' unit in your value?
Hide
Charles Lee added a comment -

I retested with a Network Interface. I defined an alert on Bits Received per Second to be greater than 30000b, and the result shows:

Bits Received per Second > 29.3 Kb

Which is correct.

Show
Charles Lee added a comment - I retested with a Network Interface. I defined an alert on Bits Received per Second to be greater than 30000b, and the result shows: Bits Received per Second > 29.3 Kb Which is correct.
Hide
Nipuna Bhayani added a comment -

Works fine in release 3.2.0-EE build 600
Sorry I missed to put b

Show
Nipuna Bhayani added a comment - Works fine in release 3.2.0-EE build 600 Sorry I missed to put b
Hide
Ryan Morgan added a comment -

I can reproduce this on 4.2:

Enter 3000 for "Bits Received per Second" the resulting screen says "Bits Received per Second > 23.4 Kb", which is incorrect.

If you list this alert in HQApi the value is correct:

<AlertCondition required="true" type="1" thresholdValue="3000.0" thresholdComparator=">" thresholdMetric="Bits Received per Second"/>

Using the stated workaround here of adding "b" also does not resolve the issue, it incorrect divides the value by 8 storing the alert condition as:

<AlertCondition required="true" type="1" thresholdValue="375.0" thresholdComparator=">" thresholdMetric="Bits Received per Second"/>

Show
Ryan Morgan added a comment - I can reproduce this on 4.2: Enter 3000 for "Bits Received per Second" the resulting screen says "Bits Received per Second > 23.4 Kb", which is incorrect. If you list this alert in HQApi the value is correct: <AlertCondition required="true" type="1" thresholdValue="3000.0" thresholdComparator=">" thresholdMetric="Bits Received per Second"/> Using the stated workaround here of adding "b" also does not resolve the issue, it incorrect divides the value by 8 storing the alert condition as: <AlertCondition required="true" type="1" thresholdValue="375.0" thresholdComparator=">" thresholdMetric="Bits Received per Second"/>
Hide
Ryan Morgan added a comment -

Assign re-opened bug to Todd for triage.

Show
Ryan Morgan added a comment - Assign re-opened bug to Todd for triage.
Hide
Idan Hod added a comment -

As part of our continuous effort to improve product quality, The Hyperic product team has decided to implement a "zero bug policy" methodology.

Following this methodology, only defects that are planned to be handled in the near future will remain open. Any other defect will be deferred, with the option to be reevaluated if the need arises, or if changes to the Hyperic road-map make such defect a candidate for a fix.

We believe this new process will help create clarity and focus in the Hyperic road-map and ultimately benefit our customer base.

This bug has been deferred as part of the new policy.

We appreciate your cooperation and continues contribution to the improvement of Hyperic.

Show
Idan Hod added a comment - As part of our continuous effort to improve product quality, The Hyperic product team has decided to implement a "zero bug policy" methodology. Following this methodology, only defects that are planned to be handled in the near future will remain open. Any other defect will be deferred, with the option to be reevaluated if the need arises, or if changes to the Hyperic road-map make such defect a candidate for a fix. We believe this new process will help create clarity and focus in the Hyperic road-map and ultimately benefit our customer base. This bug has been deferred as part of the new policy. We appreciate your cooperation and continues contribution to the improvement of Hyperic.

People

Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
    Last comment:
    41 weeks ago