Feat: Update management-domains Federated Catalog docs. #1530
Conversation
|
|
||
|  | ||
| ### Deployment Topologies |
There was a problem hiding this comment.
I don't think there is much value in copy-pasting documentation content that is already present in the upstream repo. In particular image material might be copyrighted there, so I'm not sure we even could legally copy it without attribution.
Instead, I would document how to set up a catalog server, i.e. which assets must be added there, how the resulting federated catalog looks like (flattened vs hierarchical), etc.
|
This pull request is stale because it has been open for 7 days with no activity. |
|
This pull request is stale because it has been open for 7 days with no activity. |
|
This pull request is stale because it has been open for 7 days with no activity. |
|
This pull request was closed because it has been inactive for 7 days since being marked as stale. |
|
@jimmarino @paullatzelsperger @ndr-brt can this PR be reopened, please? |
|
|
This pull request is stale because it has been open for 7 days with no activity. |
bmg13
changed the title
|
This pull request is stale because it has been open for 7 days with no activity. |
|
This pull request is stale because it has been open for 7 days with no activity. |
|
This pull request was closed because it has been inactive for 7 days since being marked as stale. |
|
@jimmarino @paullatzelsperger @ndr-brt can this PR be reopened, please? |
|
There was a problem hiding this comment.
To me, the text is quite misleading and IMO does not explain key concepts sufficiently.
I would have expected to see at least the following aspects mentioned:
- the purpose of a catalog server, and what data structures it exposes (i.e. root catalog)
- how to set up a catalog server, i.e. that each sub-catalog is referenced via a
CatalogAssetand how such aCatalogAssetlooks like. This is crucial and should be accompanied by an example. For reference, you can look at this example. - the fact that querying of a catalog server is no different from querying a "normal" catalog endpoint, and what the response looks like
- the fact that contract negotiations etc. do still have to take place with the data-owning connector, not the catalog server
- the fact that the catalog server doesn't actually create a consolidated catalog, i.e. it does not pull back any data, it merely references other connectors' catalog endpoints
- the fact that the crawler lives on the consumer side
- the purpose of a crawler and the fact, that it is the crawler that recursively traverses down a nested catalog
- client-side caching: the crawler pulls back catalogs, stores them in the client-side cache (SQL), which is what the Query API uses
If I'm honest, I'm not 100% convinced that the concept of management domains and federated catalogs has been fully understood yet.
| @@ -41,7 +41,7 @@ special [asset type](https://github.com/eclipse-edc/Connector/blob/main/docs/dev | |||
| was introduced for this purpose. | |||
|
|
|||
| Every target node produces one `Catalog`, so in the end there is a `List<Catalog>` which contains all the assets that | |||
| are available in a particular dataspace. | |||
| are available in a particular dataspace. Like so, after the Federated Catalog Crawler retrieves all catalogs, an aggregation of all is made and one single root catalog is exposed, similar to a Catalog Server without CatalogAssets. | |||
There was a problem hiding this comment.
No, the crawler does not expose anything, least of all a root catalog.
|
@bmg13 |
Following this feedback will close this pr and revisit in the future if opportunity arises. |
WHAT
Suggestion update for Federated Catalog usage documentation.
WHY
To keep Federated Catalog documentation up-to-date.
FURTHER NOTES
Management Deployments Documentation was based in this one https://github.com/eclipse-edc/Connector/blob/main/docs/developer/management-domains/management-domains.md#type-2c-catalog-servercontrol-plane-with-data-plane-runtime
Related with
eclipse-tractusx/sig-release#736
#1585