At the moment, the path "/api/updates_info/openapi" is about PE:

curl -s https://api.openshift.com/api/upgrades_info/openapi | jq -r .info.title
OpenShift Cincinnati Policy-Engine 

With GB exposing "/api/upgrades_info/graph-data", "/api/updates_info/openapi" should include that information too.

DoD:

"/api/updates_info/openapi" returns the API specs including every path exposed by OSUS that is public available.

For grooming:

Currently, the path is served by PE after manipulating PE's openapiv3.json.

Since it is not only about PE any more, it should be served by a higher level component.

A simple solution could be a new container (in its own pod ? to avoid messing up with the cincinnati pod) running a NGINX server to serve the static API spec file.

The manipulation is to rewrite the path with a prefix from app's configuration. We can set it up in the API spec directly because we know what the prefix is for the production.

Moreover, we should set up servers.url instead of "paths".

Consider to switch to `yaml` from `json`.
Json is more a machine thing while yaml is more human friendly and we have set up yamllint already in cincinnati CI.