The initial assumption was that the Red-Hat-hosted Cincinnati would be:

1. Fetching graph-data information from GitHub (OTA-832).
2. Fetching signatures for releases it knew about from the canonical signature stores (OTA-911).
3. Smushing the signatures and GitHub graph-data information together to form a single tarball (OTA-912, OTA-913).
4. Serving that tarball to oc-mirror on POST or similar requests to the graph-data endpoint (OTA-912, OTA-914).

However, discussing with pratikam and lmohanty@redhat.com, an alternative approach would have oc-mirror:

1. Use the existing graph-data GET to get the originally-GitHub graph-data content from the Red-Hat-hosted Cincinnati (OTA-831).
2. Use the new single-signature API to request signatures from the Red-Hat-hosted Cincinnati for releases being mirrored (OTA-909).
3. Smushing the signatures and GitHub graph-data information together to form a single tarball in the graph-data container it builds for mirroring.

Basically, will the signatures be smushed together with GitHub graph-data information by Red-Hat-hosted Cincinnati, or by oc-mirror?

Trade-offs between these options seem fairly slim, but include:

• Mutability:
  • Cincinnati-side smushing is a service we host and can patch as needed, e.g. if we need to adjust the canonical mirror location or format configured in OTA-911. oc-mirror is released code we ship to customers and then need to support for years, so it's harder to adjust.
• Resource distrubution:
  • Cincinnati-side smushing requires dynamic processing on hardware we pay for. oc-mirror-side smushing offloads that effort to hardware the customer pays for. But appending to a tarball is not all that much effort, and the frequency of "customer requests a dynamic tarball with Cincinnati-side signature smushing" is expected to be a handful per day outside of denial-of-service type attacks. Depending on TLS overhead, oc-mirror-side smushing's multiple separate signature requests may or may not consume more resources than Cincinnati-side smushing.
• Urgency of cache support:
  • OTA-926's caching seems important to avoid Cincinnati-side smushing needing to make multiple requests to canonical signature stores in order to respond to a single (OTA-912, OTA-914) oc-mirror request for a tarball with multiple signatures. With oc-mirror-side smushing, it seems more tenable to have Cincinnati make synchronous requests to canonical signature stores before replying to each oc-mirror request. However, deferring OTA-926 caching and using synchronous requests with either approach would increase Red-Hat-hosted Cincinnati resource consumption, and may not be something we'd ship without, regardless of which approach we end up using. And if there is a need to ship something customer-usable quickly, even if it was resource-hungry, OTA-926 might conceivably be punted, regardless of which approach we end up using, although the uncached Cincinnati implementation would probably be more straightforward to code and review with the single-signature-needed-per-request oc-mirror-side smushing.
• Other trade-offs?