-
Feature
-
Resolution: Unresolved
-
Critical
-
None
-
False
-
-
False
-
Not Selected
-
50% To Do, 0% In Progress, 50% Done
Feature Overview
This feature enhances the existing Search Collector to allow users to define additional resource fields and relationships they want indexed by Search. This will give users more control over the data they can search and provide a more comprehensive view of their managed resources.
https://docs.google.com/document/d/1vc9HhGIzGSj8F-hFw0fBgQdAMtHAYpym0TSJQHAdm0E/edit?tab=t.0
Goals
This Section: Provide high-level goal statement, providing user context
and expected user outcome(s) for this feature
- Enable users to define and collect specific resource fields beyond the pre-defined fields currently collected by Search.
- Allow users to define relationships (edges) between these custom resources.
- Ensure the custom configuration can be distributed to all managed clusters.
- Provide clear feedback to the user on the hub cluster regarding any errors or warnings with the configuration on managed clusters.
Requirements
This Section: A list of specific needs or objectives that a Feature must
deliver to satisfy the Feature.. Some requirements will be flagged as MVP.
If an MVP gets shifted, the feature shifts. If a non MVP requirement slips,
it does not shift the feature.
| Requirement | Notes | isMvp? |
|---|---|---|
| The configuration must allow users to define specific resource fields to collect, including data types like string, number, or a list of strings. | YES | |
| The configuration must support defining relationships between resources. | YES | |
| The Search configuration should be distributed to managed clusters automatically. | YES | |
| The configuration must be validated before being applied to prevent disruptions to functionality. | NO | |
| The hub cluster must report the status of the configuration, including warnings and errors from the managed clusters. | YES | |
| Changes to the configuration must take effect dynamically without requiring an application restart. | NO | |
| The feature must support existing Search configurations, such as AllowedResources and DeniedResources, and integrate them into the new customizable configuration. | YES | |
| The console should be able to display the custom fields defined by the user. | NO | |
| Backups must include the Search configuration. | NO | |
| CI - MUST be running successfully with test automation | This is a requirement for ALL features. |
YES |
| Release Technical Enablement | Provide necessary release enablement details and documents. |
YES |
(Optional) Use Cases
This Section:
- Main success scenarios - high-level user stories
- As an ACM admin, I want to configure Search to collect additional data from specific resources.
- As an ACM admin, I want Search to support relationships between resources so I can search across them.
- As an ACM admin, I want to define which namespaces Search collects data from.
- As an ACM user, I want the console to show my custom fields for resources in the search results.
- As an ACM admin, I want to make a change to the search configuration and have it take effect dynamically.
- As an ACM admin, I want to receive validation feedback and error statuses on the hub cluster if my custom search configuration is invalid.
- Alternate flow/scenarios - high-level user stories
- If a user tries to configure a field with a name that conflicts with an existing Search field, the system should log an error message and ignore the custom field.
- If a user-defined field is not found in the resource's YAML, the system should gracefully handle the missing data without erroring out.
Questions to answer
- How will the additional collection be distributed across all of the clusters?
- How do we handle multiple sources of collection configuration? (e.g. Kueue, CNV, Policy, etc all need to separately provide and manage their own search collection configurations)
- ConfigMap vs. CRD?
Out of Scope
- …
Background, and strategic fit
This Section: What does the person writing code, testing, documenting
need to know? What context can be provided to frame this feature?
Currently, Search only collects a pre-defined set of fields from resources. However, adjacent product teams and users have many scenarios where they need specific data fields within a resource's YAML. This feature addresses that need by allowing users to extend the collected data. This enhancement aligns with the goal of making ACM Search a more flexible and powerful tool for administrators and developers. It will allow users to tailor Search to their unique use cases, ultimately providing more valuable and actionable insights into their managed environments.
Assumptions
- ...
Customer Considerations
- Users will be able to perform more granular searches on their resources.
- The ability to define custom relationships will allow users to build more complex queries and understand how their resources are interconnected.
- The initial lack of UI support for custom fields means that users will need to rely on the Search API to access this data at first.
- The validation and error reporting on the hub cluster will simplify troubleshooting for administrators.
Documentation Considerations
Questions to be addressed:
- What educational or reference material is required to support this product feature?
- Yes, for administrators and integration developers.
- Does this feature have a doc impact?
- Yes.
- What concepts do customers need to understand to be successful?
- How to define fields to collect, including JSON paths and data types .
- How to define relationships between resources.
- How to use the search-collector-config ConfigMap.
- How do we expect customers will use the feature?
- To index custom resource fields from third-party operators or applications to enable advanced search queries.
- What reference material might a customer want/need?
- A sample configuration with examples of defining fields and relationships .
- Is there source material that can be used as a reference for the Technical Writer?
- Yes, the provided design document itself, as well as the related GitHub repositories and Jira tickets.
