Expose Internal APIs

[bipuladh]

Exposes the following Components:

Hooks

• usePrometheusPoll

Dashboard Related Components

• DashboardGrid
• HealthItem
• AlertItem
• AlertsBody
• PrometheusUtilizationItem
• ResourceInventoryItem
• UtilizationBody
• RecentEventsBody
• OngoingActivityBody
• DashboardCard
• DashboardCardBody
• DashboardCardHeader
• DashboardCardTitle
• DetailsItem
• DetailsBody
• UtilizationItem
• ActivityItem
• ActivityBody

[rawagner]

I have a PRs which are adding types to ListPage and Table and also another ones which are updating the APIs of the components so its easier for consumer to use them.

types for list page
#8792
new list page API
#8827

types for Table
#8756
new Table API
#8829

[bipuladh]

/assign @christianvogt @vojtechszocs

[bipuladh]

I din't make a new object for it. Should I add it to window.provisional instead? @vojtechszocs

[bipuladh]

It looks like there are more components exposed in the PR than listed in the descriptions. Were these needed because they are dependencies of the components we're exposing?

@bipuladh @rawagner How much of the basic dashboard layout like DashboardGrid and DashboardCard can be accomplished with PatternFly components? DashboardCard for instance appears to wrap the PatternFly Card and only adds one or two CSS classes.

IMO all of it can be accomplished from PF. However, exposing these simple components should allow us to maintain similarities across dashboards and changing CSS in the core console would allow us to revamp all the dashboards(wouldn't have to wait for two releases) without changing plugin code.

[bipuladh]

I don't think we want to put PageHeading and HorizontalNav under internalAPI since we'll need these for kubevirt in 4.9 as part of the SDK. I feel like we should look at cleaning up and simplifying these APIs. I'm not sure we want to expose them as-is.

I have created a wrapper for PageHeading #9465 based on the commonly used props. Apparently only a few of the defined are commonly used.
Will do the same for HorizontalNav.

Can we consider having only one hook for polling Prometheus (and always storing the data in Redux if that's needed)?

usePrometheusQuery is tied close to the dashboard. Maybe we could add a prop isDashboard which would trigger Dashboard related Actions else it could work exactly like usePrometheusPoll or just use it internally....?

[rawagner]

Can we consider having only one hook for polling Prometheus (and always storing the data in Redux if that's needed)?

usePrometheusQuery is tied close to the dashboard. Maybe we could add a prop isDashboard which would trigger Dashboard related Actions else it could work exactly like usePrometheusPoll or just use it internally....?

+1 for having one prometheus hook and storing data to redux. I wanted to do it for some time but cannot find the time

[rawagner]

It looks like there are more components exposed in the PR than listed in the descriptions. Were these needed because they are dependencies of the components we're exposing?
@bipuladh @rawagner How much of the basic dashboard layout like DashboardGrid and DashboardCard can be accomplished with PatternFly components? DashboardCard for instance appears to wrap the PatternFly Card and only adds one or two CSS classes.

IMO all of it can be accomplished from PF. However, exposing these simple components should allow us to maintain similarities across dashboards and changing CSS in the core console would allow us to revamp all the dashboards(wouldn't have to wait for two releases) without changing plugin code.

As @bipuladh said. That is the idea behind these simple components.

[christianvogt]

Changes lgtm

We should be working towards promoting these extensions to proper APIs.
I don't want to get into having to maintain backwards compatibility for these APIs. Something we touched on in our meetings but need to further discuss.

[cloudbehl]

/test e2e-gcp-console

[openshift-ci]

@bipuladh: The specified target(s) for /test were not found.
The following commands are available to trigger jobs:

• /test analyze
• /test backend
• /test ceph-storage-plugin
• /test e2e-gcp-console
• /test frontend
• /test images
• /test kubevirt-plugin

Use /test all to run the following jobs:

• pull-ci-openshift-console-master-analyze
• pull-ci-openshift-console-master-backend
• pull-ci-openshift-console-master-e2e-gcp-console
• pull-ci-openshift-console-master-frontend
• pull-ci-openshift-console-master-images

In response to this:

/test tide

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.

[SanjalKatiyar]

Have tested the PR for the following cases:

• Components used by ODF Dashboard:

usePrometheusPoll

HealthItem

RecentEventsBody

DashboardCard, DashboardCardBody, DashboardCardHeader, DashboardCardTitle

---

• Rest of console dashboards working fine with these changes:

[christianvogt]

/lgtm
/hold

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bipuladh, christianvogt

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:

• frontend/OWNERS [christianvogt]

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

[spadgett]

@yapei has given us the OK for development to test the PR.

/label qe-approved

This PR has no user visible changes and has no doc impact. These APIs are internal and can change at any time.

/label px-approved
/label docs-approved

@ahardin-rh @sferich888 FYI

/hold cancel