backend(proposal): adding proposal to extend and unify storage layer

[nsingla]

Description of your changes:

Checklist:

• You have signed off your commits
• The title for your pull request (PR) should follow our title convention. Learn more about the pull request title convention used in this repository.

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign zazulam for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Amr-Shams]

i read the proposal, admired the idea and i have a genuine question,

go CDK already has a URL-based mux that dispatches by scheme, so why would adding another custom layer to register? while can be done with the custom url by go CDK?

[nsingla]

i read the proposal, admired the idea and i have a genuine question,

go CDK already has a URL-based mux that dispatches by scheme, so why would adding another custom layer to register? while can be done with the custom url by go CDK?

That's a good question that I probably should address in the proposal as well, but to answer your question:

The custom registry exists because Go CDK's URL mux is designed for stateless, environment-driven credential resolution, while KFP's credential model is request-scoped and depends on Kubernetes API calls that require injected runtime objects. The URL mux is still used as the fallback for the simpler FromEnv case.
Also, the intent of the change is to make the change with the least possible code change with no regression, and Go CDK provides that layer that is required to support this, but in order to do that, we need to bypass its mux to continue to use our own.