Epic Goal

• As an OpenShift GitOps user managing Argo CD applications, I want to a way to define custom parent-child relationships for complex resource types, so that I can improve resource visualization to users providing a clearer, more intuitive view of how Git-managed resources relate to their cascading resources

*Why is this important?

• Not all parent-child relationships are defined using the kubernetes standard `metadata.ownerReferences`, they have limitiations like, the relationships cannot span across multiple namespaces.
• Reduce cognitive load when navigating complex application structures
• While most users don't have both parent and subordinate objects in Git, those who do would benefit from improved visibility

Scenarios

1. ...

Other Considerations

• Only parent child relationships needs to be considered.
• A child can have only utmost only one parent.

Definition of Ready

• The epic has been broken down into stories.
• Stories have been scoped.
• The epic has been stack ranked.

Definition of Done

• Code Complete:
  • All code has been written, reviewed, and approved.
• Tested:
  • Unit tests have been written and passed.
  • Integration tests have been completed.
  • System tests have been conducted, and all critical bugs have been fixed.
  • Tested on OpenShift either upstream or downstream on a local build.
• Documentation:
  • User documentation or release notes have been written.
• Build:
  • Code has been successfully built and integrated into the main repository / project.
• Review:
  • Code has been peer-reviewed and meets coding standards.
  • All acceptance criteria defined in the user story have been met.
  • Tested by reviewer on OpenShift.
• Deployment:
  • The feature has been deployed on OpenShift cluster for testing.
• Acceptance:
  • Product Manager or stakeholder has reviewed and accepted the work.