feat: [UIE-7995] DBaaS Monitor GA #11105
Conversation
smans-akamai
requested review from
bnussman-akamai and
abailly-akamai
and removed request for
a team
smans-akamai
force-pushed
the
UIE-7995-dbaas-monitor
branch
from
f2ebf9a to
86173d2
Compare
|
|
||
| export const DatabaseMonitor = ({ database }: Props) => { | ||
| const databaseId = database?.id; | ||
| const dbaasDashboardId = 1; |
There was a problem hiding this comment.
What is this constant here?
There was a problem hiding this comment.
This is the dashboard ID we need to use access data for DBaaS with the CloudPulseDashboardWithFilters component. There was a discussion on the ticket UIE-7995.
It's always supposed to be 1, so I stored in a variable for context, but can remove it and have it in the template instead if that's preferred.
There was a problem hiding this comment.
I can't imagine each service that's onboarded will need to hardcode their dashboard Id, should this be coming from the API? cc: @venkymano-akamai
There was a problem hiding this comment.
@jaalah-akamai Yes!!, we do have an API for listing dashboards, specifically the ACLP */dashboards API, which currently returns multiple dashboard IDs for both standard and custom dashboards. To identify the primary dashboard when there are multiple standard dashboards for a service, we may need to enhance the API to make that distinction.
As of now, for DBaaS, there's only one standard dashboard provisioned, so the team can use the /dashboards API to fetch the dashboard ID without issues. However, if additional standard dashboards are added in the future, this approach may become problematic.
For now, it is acceptable to use a hardcoded dashboard ID, as it will be manually provided during the service onboarding process to ACLP through the ACLP onboarding template.
Alternatively, as a second enhancement option, we could modify the ACLP reusable dashboard component to accept an additional service type parameter. Based on this parameter, the component would automatically fetch the primary dashboard for the specified service type.
Both options require some level of enhancement, and we can decide which approach to take based on product decisions. Thanks for the suggestion.
packages/manager/src/features/Databases/DatabaseDetail/index.tsx
Outdated
Show resolved
Hide resolved
cpathipa
requested review from
cpathipa
and removed request for
bnussman-akamai and
abailly-akamai
smans-akamai
force-pushed
the
UIE-7995-dbaas-monitor
branch
2 times, most recently
from
8bef13f to
ebabf10
Compare
|
Coverage Report: ✅ |
smans-akamai
force-pushed
the
UIE-7995-dbaas-monitor
branch
from
ebabf10 to
7bc29a6
Compare
Cloud Manager E2E
|
||||||||||||||||||||||||
| Project |
Cloud Manager E2E
|
| Run status |
|
| Run duration | 27m 24s |
| Commit |
|
| Committer | smans-akamai |
| View all properties for this run ↗︎ | |
| Test results | |
|---|---|
Failures
|
0
|
Flaky
|
5
|
Pending
|
2
|
Skipped
|
0
|
Passing
|
437
|
Description 📝
Adding Monitor tab to the database details view.
Changes 🔄
List any change relevant to the reviewer.
Target release date 🗓️
10/28/24
Preview 📷
How to test 🧪
Prerequisites
(How to setup test environment)
Verification steps
(How to verify changes)
As an Author I have considered 🤔
Check all that apply
Commit message and pull request title format standards
<commit type>: [JIRA-ticket-number] - <description>Commit Types:
feat: New feature for the user (not a part of the code, or ci, ...).fix: Bugfix for the user (not a fix to build something, ...).change: Modifying an existing visual UI instance. Such as a component or a feature.refactor: Restructuring existing code without changing its external behavior or visual UI. Typically to improve readability, maintainability, and performance.test: New tests or changes to existing tests. Does not change the production code.upcoming: A new feature that is in progress, not visible to users yet, and usually behind a feature flag.Example:
feat: [M3-1234] - Allow user to view their login history