Investigate and propose package repositories API with similar core interface to packages API.

[absoludity]

As we close in on the basic functionality for the packages API, we'll need to begin investigating and proposing a similar core API for package repositories, so that as a user I can use the Kubeapps UI to interact with AppRepositories (helm and oci) as well as flux sources.

We've recently had contributions for remote components that are conditionally used in different views, which will be something we'll want to begin using (though not remote, restricted to our internal services) both in the packages API as well as the package repositories API, where I assume the UX will be quite different for the various repository types (more so than packages).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[absoludity]

I'm not sure why this is committed: I'd expect it to be prioritised and scheduled to come after #3403 which I'm starting now?

[gfichtenholt]

I am starting work on this now. My plan of action is this: for each operation (CRUD)

1. update design doc https://docs.google.com/document/d/1z03msZRGsRvcRaom-yrvEwIWcEfNy6fSA5Zg28gjYvA/edit?usp=sharing with corresponding messages and rpc func
2. once (1) is reviewed, add corresponding stubs in core packages.proto and each plug-in .proto
3. add implementation for flux plugin and unit tests

Let me know it sounds good or if I missed anything. Thanks

[absoludity]

Great, thanks Greg.

I am starting work on this now. My plan of action is this: for each operation (CRUD)

1. update design doc https://docs.google.com/document/d/1z03msZRGsRvcRaom-yrvEwIWcEfNy6fSA5Zg28gjYvA/edit?usp=sharing with corresponding messages and rpc func

2. once (1) is reviewed, add corresponding stubs in core packages.proto and each plug-in .proto

Sounds good. I wasn't sure whether we'd want this is the packages API or as a separate repositories API which can also be implemented by plugins - that was part of what needs to be thought through. Perhaps it is simpler to just do it in the packages API as you've thought, if each packaging system has its own take on an app repository anyway.

3. add implementation for flux plugin and unit tests

I'm not sure, but thought that implementing the helm plugin may be higher priority since it allows us to switch over the existing frontend code, but no worries if you'd rather leave that for someone else.

[gfichtenholt]

Will need to check with Pepe on this. He did ask me to get started on this monday but did not clarify whether he wanted me to also take care the direct helm implementation of this.

[absoludity]

Yep, fine either way, I more thought that it's important to ensure that the new API satisfies the requirements of the existing helm functionality. It doesn't bother me who does it as long as we work with this in mind.