feat: implement namespaces list table in infra monitoring

[amlannandy]

Summary

Implement the namespaces list table in Infra Monitoring

Related Issues / PR's

N/A

Screenshots

N/A

Affected Areas and Manually Tested Areas

Infra Monitoring section

---

Important

Implement namespaces list table in Infra Monitoring with new API, UI components, and hooks.

• API:
  • Add getK8sNamespacesList function in getK8sNamespacesList.ts to fetch namespaces list.
  • Define interfaces K8sNamespacesListPayload, K8sNamespacesData, and K8sNamespacesListResponse.
• UI Components:
  • Add K8sNamespacesList component in InfraMonitoringK8s.tsx to display namespaces.
  • Update InfraMonitoringK8s.tsx to include K8sNamespacesList based on selected category.
  • Add K8sHeader component for managing filters and group by options.
• Hooks:
  • Add useGetK8sNamespacesList hook in useGetK8sNamespacesList.ts for fetching data using React Query.
• Utilities:
  • Add utility functions in utils.tsx for formatting data and defining table columns.
  • Update constants.ts to include namespace-related quick filters.

^{This description was created by for 79e07b7. It will automatically update as commits are pushed.}

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>

[ellipsis-dev]

❌ Changes requested. Reviewed everything up to 98e5fe6 in 1 minute and 44 seconds

More details

• Looked at 947 lines of code in 8 files
• Skipped 0 files when reviewing.
• Skipped posting 2 drafted comments based on config settings.

1. frontend/src/api/infraMonitoring/getK8sNamespacesList.ts:53

• Draft comment:
  Use response.status instead of hardcoded 200 for statusCode to ensure it reflects the actual response status.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:
  This is a new API endpoint file. The comment suggests a change that could make the code more dynamic, but there are several issues: 1) This is a success case in the try block, so we know it succeeded 2) Axios successful responses always have status 200 3) The statusCode is part of our own response wrapper, not the HTTP status 4) The suggestion could actually introduce bugs if the backend returns a different 2xx status code.
  Maybe using response.status would be more accurate for non-200 success codes like 201 Created. The current approach might hide important status information.
  This is a GET endpoint that returns a list - it will always be 200 on success. Other status codes would be caught in the catch block and handled by ErrorResponseHandler.
  The comment should be deleted. The hardcoded 200 is correct here as it's in the success path, and using response.status could actually introduce bugs.

2. frontend/src/api/infraMonitoring/getK8sNamespacesList.ts:55

• Draft comment:
  Use response.statusText instead of hardcoded 'Success' for the message to ensure it reflects the actual response message.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:
  The comment is about code style/implementation choice, not a clear bug. Using response.statusText isn't necessarily better - it would make the response message less predictable and consistent. The hardcoded 'Success' is a deliberate choice to provide a consistent response format. HTTP status texts can vary between servers and implementations.
  Maybe using the actual HTTP status text would provide more detailed information about the response. The hardcoded message could hide useful information.
  The purpose of this message field seems to be providing a consistent, predictable success indicator rather than detailed status information. The actual response data is already included in the payload.
  This comment should be deleted as it suggests a change that isn't clearly better and could make the API response less consistent.

Workflow ID: wflow_rotZg7lxf6EgSuYM

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>

[ellipsis-dev]

❌ Changes requested. Incremental review on a0c8bf9 in 1 minute and 3 seconds

More details

• Looked at 757 lines of code in 4 files
• Skipped 0 files when reviewing.
• Skipped posting 1 drafted comments based on config settings.

1. frontend/src/container/InfraMonitoringK8s/InfraMonitoringK8s.tsx:324

• Draft comment:
  Avoid using inline styles in React components. Instead, use external stylesheets, CSS classes, or styled components. This applies to all similar instances in this file.
• Reason this comment was not posted:
  Comment was on unchanged code.

Workflow ID: wflow_UgbcDEXuPKcSMRQY

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

Use design tokens or predefined color constants instead of hardcoding color values in the Tag component.

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>

[ellipsis-dev]

👍 Looks good to me! Incremental review on 384b309 in 25 seconds

More details

• Looked at 111 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 2 drafted comments based on config settings.

1. frontend/src/container/InfraMonitoringK8s/Namespaces/K8sNamespacesList.tsx:325

• Draft comment:
  Ensure that setting showHeader={false} is intentional. Hiding table headers can reduce clarity for users.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The showHeader property is set to false for the Table component, which might not be the intended behavior if headers are needed for clarity.

2. frontend/src/container/InfraMonitoringK8s/Namespaces/utils.tsx:28

• Draft comment:
  Ensure that the renaming of cpuUsage to cpu and memoryUsage to memory is consistent across the codebase. This change is also applicable in K8sNamespacesRowData and columnsConfig.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The cpu and memory fields have been renamed from cpuUsage and memoryUsage. Ensure consistency across the codebase.

Workflow ID: wflow_wV26lGxAs0EeFQm3

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on 79e07b7 in 12 seconds

More details

• Looked at 24 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 2 drafted comments based on config settings.

1. frontend/src/hooks/infraMonitoring/useGetK8sNamespacesList.ts:37

• Draft comment:
  The change from GET_HOST_LIST to GET_NAMESPACE_LIST in the query key is correct and aligns with the new functionality of fetching namespaces.
• Reason this comment was not posted:
  Confidence changes required: 0%
  The change from GET_HOST_LIST to GET_NAMESPACE_LIST in the query key is correct and aligns with the new functionality of fetching namespaces.

2. frontend/src/hooks/infraMonitoring/useGetK8sNamespacesList.ts:37

• Draft comment:
  Ensure that REACT_QUERY_KEY.GET_NAMESPACE_LIST is defined in reactQueryKeys.ts to maintain consistency and avoid hardcoding.
• Reason this comment was not posted:
  Comment did not seem useful.

Workflow ID: wflow_OBlofEjwc5hhz7Da

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>