Add capacity card

[rawagner]

This PR adds Capacity card to Dashboard Overview page. The card can be extended by replacing the default queries (ie ceph plugin will want to replace the default storage query for their own)

Loaded Capacity card

Capacity card in loading state

Capacity card when prometheus is not available

[openshift-ci-robot]

Hi @rawagner. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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.

[rawagner]

@pcbailey you should reuse these functions for
parsing prometheus response
https://github.com/openshift/console/pull/1723/files#diff-88e28dc4ff9d44327448cee5d1b9a165R13

and
formatting units
https://github.com/openshift/console/pull/1723/files#diff-d2c1fc70e52447f34600d02e3942b1e0R157

in your TopConsumers PR too #1722

[spadgett]

fyi @TheRealJon is looking at transitioning our existing gauge charts to pf4/victory

[spadgett]

/assign @TheRealJon

Jon, can you help review?

[vojtechszocs]

@cloudbehl @spadgett This can be used in ceph-storage-plugin to customize storage related queries.

@jelkosz We must have the ability to gate extensions by feature flags, i.e. use Ceph storage capacity queries only if CEPH feature flag is enabled.

[vojtechszocs]

@rawagner In relation to extension validation (#1708), are there any constraints to replacing the base Prometheus queries?

For example, if plugin A defines custom CAPACITY_QUERY.STORAGE_TOTAL, can plugin B redefine that query again?

@christianvogt Plugins are currently treated as completely independent of each other, including the order in which their extensions are applied, with one exception being that console-app's extensions always come first.

Therefore, I think we should have an extension check which fails if multiple plugins attempt to replace the same query.

[rawagner]

@vojtechszocs I think it makes sense to add such test once #1708 is merged.

[vojtechszocs]

Thanks @rawagner, I'll add that test once the infra PR #1708 is merged.

[vojtechszocs]

@rawagner We should ensure that given queryKey is replaced at most once.

const pluginQueries = {};
plugins.registry.getDashboardsOverviewCapacityQueries().forEach(cq => {
  const queryKey = cq.properties.queryKey;
  if (!pluginQueries[queryKey]) {
    pluginQueries[queryKey] = cq.properties.query;
  }
});
return _.defaults(pluginQueries, defaultQueries);

[rawagner]

changed to using _.defaults . I've also added warn log message when such case happens

[vojtechszocs]

I've also added warn log message when such case happens

Please don't, extension tests introduced in #1708 should catch and report on these issues at test/build time.

Code I've posted above enforces the "query can be replaced at most once" behavior (guarding against e.g. when you disable some tests), but it doesn't log anything on purpose. This keeps the code simple(r) and browser console log clean(er).

[rawagner]

Ok, I removed the log message

[TheRealJon]

@openshift/team-ux-review

[TheRealJon]

@lizsurette

[lizsurette]

FYI @andybraren @mceledonia @rileyhuston

[rawagner]

@vojtechszocs all review comments addressed and rebased on master (which already has #1742)

[rawagner]

since it is assigned to @TheRealJon he is the one who should give us LGTM :)

[TheRealJon]

/lgtm

[rawagner]

@TheRealJon thanks! Still missing approve. Should that be given by you or @spadgett ?

[spadgett]

/approve

But needs rebase :/

[rawagner]

since #1783 is merged and it has migrated gauge to PF4 I've reused it here too.

loaded charts

loading charts

no data available

@spadgett @TheRealJon

[rawagner]

/test e2e-aws-console-olm

[TheRealJon]

@rawagner I found a bug where some of the Area and Bar chart labels are objects instead of strings. I think this comes from the change to the humanize functions in frontend/public/components/utils/units.js. Those functions used to return a string, but now return an object. The following files need to have the formatX and formatY props updated for Bar and Area components:

• frontend/public/components/namespace.jsx (Bar and Area)
• frontend/public/components/build.tsx (Area)
• frontend/public/components/node.tsx (Area)
• frontend/public/components/pod.tsx (Area)

[rawagner]

@TheRealJon thank you again for the commit. I've added one more and it should all be fine now. Please take a look.

[rawagner]

/retest

[rawagner]

/test e2e-aws-console
/test e2e-aws

[rawagner]

/test e2e-aws-console

[TheRealJon]

/lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rawagner, spadgett, TheRealJon, vojtechszocs

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• frontend/OWNERS [spadgett]

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