Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug 1873192: show empty state in monitoring when no datapoint available #6463

Merged

Conversation

nemesis09
Copy link
Contributor

@nemesis09 nemesis09 commented Aug 27, 2020

Fixes:
https://issues.redhat.com/browse/ODC-4469
https://issues.redhat.com/browse/ODC-3297

Analysis / Root cause:
the monitoring tab shows empty charts when there are no datapoints available
Solution Description:
show empty state when there are no datapoints

Screens:
Before
Screenshot from 2020-08-27 20-30-00
Screenshot from 2020-08-27 20-30-54
Screenshot from 2020-08-27 20-31-26

After
Screenshot from 2020-08-27 20-34-30
Screenshot from 2020-08-27 20-34-49
Screenshot from 2020-08-27 20-33-51

Test Coverage:
NA

Browser Conformance:

  • Firefox
  • Chrome
  • Safari
  • Edge

@openshift-ci-robot openshift-ci-robot added the bugzilla/severity-high Referenced Bugzilla bug's severity is high for the branch this PR is targeting. label Aug 27, 2020
@openshift-ci-robot
Copy link
Contributor

@nemesis09: This pull request references Bugzilla bug 1873192, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (4.6.0) matches configured target release for branch (4.6.0)
  • bug is in the state NEW, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

In response to this:

Bug 1873192: show empty state in monitoring when no datapoint available

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-ci-robot openshift-ci-robot added the bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. label Aug 27, 2020
@openshift-ci-robot openshift-ci-robot added component/core Related to console core functionality component/monitoring Related to monitoring labels Aug 27, 2020
@openshift-ci-robot
Copy link
Contributor

@nemesis09: This pull request references Bugzilla bug 1873192, which is valid.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (4.6.0) matches configured target release for branch (4.6.0)
  • bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

In response to this:

Bug 1873192: show empty state in monitoring when no datapoint available

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@nemesis09
Copy link
Contributor Author

cc @beaumorley @parvathyvr

@@ -673,11 +676,12 @@ const QueryBrowser_: React.FC<QueryBrowserProps> = ({
setXDomain([from, to]);
setSpan(to - from);
};
const isGraphDataEmpty = _.isEmpty(_.flattenDeep(graphData));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should avoid using _.flattenDeep because there can be a large amount of data in graphData and we already have performance concerns.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe

const isGraphDataEmpty = _.isEmpty(graphData) || _.every(graphData, (d) => d.length === 0);

or

const isGraphDataEmpty = !_.some(graphData, (d) => d.length > 0);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could use const isGraphDataEmpty = !graphData || graphData.every((d) => d.length === 0)
since every() always returns true for any condition when array is empty, we could drop the check _.isEmpty
updated the checks. please take a look.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Thanks

@@ -501,6 +501,9 @@ const QueryBrowser_: React.FC<QueryBrowserProps> = ({
tickInterval,
timespan,
}) => {
// Min height for GraphEmpty(empty state)
const EMPTY_GRAPH_MIN_HEIGHT = 310;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this? I think the height should still be reasonable without it. We already have a state where an error message is displayed without a graph and I think the height is OK in that case without forcing a height.

Is there a page that looks bad without EMPTY_GRAPH_MIN_HEIGHT?

Also, I notice that 310 is too much for some places, like the Admin perspective > Monitoring > Metrics page.

Ideally, we wouldn't use EMPTY_GRAPH_MIN_HEIGHT and just fallback to CSS to give a reasonable height.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

QueryBrowser already has a CSS class graph-empty-state which sets min height 310px for empty state
but the GraphEmpty defaults to 180px which made it seem floating towards the top.

Topology Sidebar
Screenshot from 2020-08-28 17-37-48

Dev perspective -> Monitoring
Screenshot from 2020-08-28 17-38-21

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One problem with this is that depending on the page, the graph-empty-state wrapper may contain other content in addition to the empty state message (like the graph controls on the Metrics page), so the 310px actually makes the graph-empty-state taller than 310 pixels.

Not sure if there is an easy CSS fix here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we don't want to set the height then we can do it by using display: table CSS property. WDYT @kyoto?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^ @christianvogt What will be the better way to fix this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately this introduces a bug where the graph controls are now vertically centered while the graph is loading.

screenshot

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the styling needs to be applied more conditionally since it's only necessary when the empty state is shown

Copy link
Contributor Author

@nemesis09 nemesis09 Sep 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added conditional styling @kyoto
Screenshot from 2020-09-15 02-17-44

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, I think this is introducing a different bug on the Metrics page. When the graph is loading, the graph wrapper loses its height, which I think is not what we want since it causes everything below the graph to jump up / down as the graph is loading.

screenshot

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've pushed a fix addressing the css issue. Please take a look

@nemesis09
Copy link
Contributor Author

/retest

@openshift-ci-robot
Copy link
Contributor

@nemesis09: This pull request references Bugzilla bug 1873192, which is valid.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (4.6.0) matches configured target release for branch (4.6.0)
  • bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

In response to this:

Bug 1873192: show empty state in monitoring when no datapoint available

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@nemesis09 nemesis09 force-pushed the fix-monitoring-empty-state branch 2 times, most recently from f176c8b to cc32b9b Compare September 13, 2020 20:15
@nemesis09
Copy link
Contributor Author

/retest

@kyoto
Copy link
Member

kyoto commented Sep 18, 2020

I tested and didn't see any layout issues with this now.

Thanks @nemesis09!

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Sep 18, 2020
@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kyoto, nemesis09

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 18, 2020
@openshift-merge-robot openshift-merge-robot merged commit fecc422 into openshift:master Sep 18, 2020
@openshift-ci-robot
Copy link
Contributor

@nemesis09: All pull requests linked via external trackers have merged:

Bugzilla bug 1873192 has been moved to the MODIFIED state.

In response to this:

Bug 1873192: show empty state in monitoring when no datapoint available

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@spadgett spadgett added this to the v4.6 milestone Oct 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. bugzilla/severity-high Referenced Bugzilla bug's severity is high for the branch this PR is targeting. bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. component/core Related to console core functionality component/monitoring Related to monitoring lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants