[WIP] deppy catsrc adapter

[ankitathomas]

Implementation of a deppy source adapter that can provide a ListEntities functionality.

This prototype uses a single CatalogSource specified either by its namespaced name or its serving address as a data source. This model necessitates the addition of another controller layer on top of the adapter to create and monitor adapters for all catalogsources and lacks any caching at the adapter side, which may be performance concerns. Some of these issues may be solvable by a cluster-scoped unified data source.

See https://github.com/anik120/rukpak-packageserver

[joelanford]

(I know this is not in the design doc, so this is a design quesiton, not an impl question)...

Do we need a separate constraints field here?

• Properties that are not understood can likely be ignored by deppy
• Constraints that are not understood should probably result in a resolution error (or at least there should be a knob that lets the user decide whether unknown constraints should be failures)

Without a separate constraints field, it seems like deppy will need to have knowledge about how to extract constraints from properties.

[ankitathomas]

Constraints should be something that the layer above the adapter understands, it didn't seem appropriate to assume constraints directly from the catalogsource.

[joelanford]

Was there discussion about what protocol to use for the deppy source API? I'm curious if we revisited tradeoffs of GRPC vs vanilla HTTP/JSON vs something else, etc.

[ankitathomas]

I looked into OpenAPI as an alternative for an HTTP/JSON endpoint, but it didn't make the building out of the API any easier or its definition simpler. There are other options, but GRPC seemed more straightforward for an initial API.

[openshift-merge-robot]

@ankitathomas: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[github-actions]

This PR has become stale because it has been open for 30 days with no activity. Please update this PR or remove the lifecycle/stale label before it is automatically closed in 30 days. Adding the lifecycle/frozen label will cause this PR to ignore lifecycle events.

[github-actions]

This PR has become stale because it has been open for 30 days with no activity. Please update this PR or remove the lifecycle/stale label before it is automatically closed in 30 days. Adding the lifecycle/frozen label will cause this PR to ignore lifecycle events.

[ankitathomas]

Closing in favor of operator-framework/operator-controller#129