Epic Goal

Creation of Knowledge Graphs for Advanced Cluster Management to share details of relationships between resources for the benefit of internal and eventually external teams. This should reduce the hours people spend to troubleshoot ACM. Eventually this library will also feed into the work being done in RedHat with Foundation Models. And/or this can be queried by Machines. BTW there is nothing in this proposal that cannot be extended to other areas of Red Hat.

DDR for this EPIC: https://docs.google.com/document/d/13ZFoMNXEkuYInjZtQDKa61EW3b-Ixjm60wFU2jpu_OA/edit 

Why is this important?

ACM is a complex product that is split into many components.  Many components are optional and need to be installed separately.  While we have a lot of good documentation, there are plenty of areas where additional value can be obtained from graph data that may be hard to document or would require detailed diagrams.  Here are some ways it could help:

• Development: If I am working on API X, what is dependent on my changes?
• Support: How does a metric / alert get from the managed cluster into grafana?
• Customer: How do I install Gatekeeper/VolSync/etc and use it with ACM?
• Product Security: Show me the APIs and associated controllers.  Show me the routes. Etc

The goal for the knowledge graph is to provide specific product insights that eliminate the need to go to the experts directly.

• Reduce the number of times I am asked the same question about how something in ACM works.
• Reduce the number of places where I am asked for the same information about components in ACM.

Scenarios

Creation of the KGs.

Define the depth/details that must be included

Acceptance Criteria

Must have a way to validate and check for duplication

Dependencies (internal and external)

1. See DDR

Previous Work (Optional):

1. See DDR

Open questions:

See the DDR

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub
  Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub
  Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>