The idea is to enable support for connecting multiple Hubs into a single one.
Currently, we have an entity called vendorhttps://github.com/capactio/capact/blob/main/ocf-spec/0.0.1/README.md#vendor
Remote Public Hub repositories can be mounted under the vendor sub-tree in the local repository.
Vendor manifest stores connection details of the external OCH, such as URI of the repository (base path) or federation strategy.
This concept needs to be refined.
Features:
support private hubs
authorization/authentication
Signature-based
Take into account future plans: external IDPs - makes sense to use ORY stack with multiple authenticators
caching
support different sources, not only git or Public Hub API. We can try to reuse the same concept developed for the delegated storage.
content synchronization (periodic/hooks). Make it configurable.
In the first round, we should think how to enable Public Hub federation. In the future, the Local Hubs could also reuse the same implementation.
Reason
In the current approach, all content that is loaded to Public Hub requires to be defined in a single repository. There is no easy way to split it e.g. extract test content to separate och repository which can be optionally enabled.
This pattern doesn't scale well. We should be able to split repository per vendor (e.g. Google, Microsoft, RedHat etc.) and per use-cases e.g. private used for commercial use-cases, incubator, open-source manifests etc.
Description
The idea is to enable support for connecting multiple Hubs into a single one.
Currently, we have an entity called
vendor
https://github.com/capactio/capact/blob/main/ocf-spec/0.0.1/README.md#vendor Remote Public Hub repositories can be mounted under the vendor sub-tree in the local repository. Vendor manifest stores connection details of the external OCH, such as URI of the repository (base path) or federation strategy.This concept needs to be refined.
Features:
In the first round, we should think how to enable Public Hub federation. In the future, the Local Hubs could also reuse the same implementation.
Reason
In the current approach, all content that is loaded to Public Hub requires to be defined in a single repository. There is no easy way to split it e.g. extract test content to separate och repository which can be optionally enabled.
This pattern doesn't scale well. We should be able to split repository per vendor (e.g. Google, Microsoft, RedHat etc.) and per use-cases e.g. private used for commercial use-cases, incubator, open-source manifests etc.