Goal

Make a plan to incorporate the functionality of relations-api directly into the inventory-api codebase and deploy the new combined inventory-api service to production.

This should be done in such a way that external consuming services, such as rbac and SPs, experience no interruption of service or regressions.

Requirements

1. A documented plan is produced that can be reviewed by the team.
2. The plan will involve creating a code-level merge PR (see RHCLOUD-45308) and the timing of when it should be merged.
3. Any direct clients of relations-api (aside from inventory-api) must be identified and must be provided with a suitable interface in inventory-api. 
   • This may involve building the new interface(s) in inventory-api prior to merging the above PR. (See expand and contract pattern.)
4. Any other dependencies and/or factors that could impact delivery should be identified.
   • e.g. In-flight changes like inventory-api redesign.
5. The plan should outline the timings and sequence of steps involved in the cutover from the dual service configuration to the new single service configuration. Beyond code changes, concerns include:
   • Code level regression test plan.
   • Changes in deployment templates in app-interface and locally within inventory-api.
   • Review of resource requirements/requests for new service.
   • Changes in existing documentation.
   • Operational regression test plan (i.e. in stage) – testing that the operational configuration is functionally equivalent (and no less performant) than the previous configuration.
6. Any operational risks to the smooth running of the kessel service as a whole should be identified and mitigated as part of the plan.

Definition of done

A document, probably a KSL, outlining the above is produced and is approved by the team.