Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor the kubernetes provider to be provider-agnostic #3213

Open
shawnh2 opened this issue Apr 17, 2024 · 6 comments
Open

refactor the kubernetes provider to be provider-agnostic #3213

shawnh2 opened this issue Apr 17, 2024 · 6 comments
Assignees

Comments

@shawnh2
Copy link
Contributor

shawnh2 commented Apr 17, 2024

Description:

For now, all the resources related process method in k8s provider are coupling deeply with k8s client, we should free these method from it.

func (r *gatewayAPIReconciler) processGateways(ctx context.Context, managedGC *gwapiv1.GatewayClass, resourceMap *resourceMappings, resourceTree *gatewayapi.Resources) error {

So I propose a refactor: the basic idea is to separate how we process resources and how we retrieve resources.

By defining Operations interface and ResourceProcessor structure, each provider can maintain their own implemention of Operations, and different provider can share the same ResourceProcessor.

type Operations interface {
    ListGateways()
    ListHTTPRoutes()
    FindReferenceGrant()
    ...
}

type ResourceProcessor struct {
    Operations
}

func (r *ResourceProcessor) ProcessGateways() {
    // use r.ListGateways() to retrieve all Gateway resources
}
func (r *ResourceProcessor) ProcessHTTPRoutes() {}
func (r *ResourceProcessor) findReferenceGrant() {}
...

we can

  • let k8s provider only foucs on how to retrieve resources, so does file provider
  • the k8s and file provider can share the same process logic for resources, and we don't need to maintain two places of code for each provider type

[optional Relevant Links:]

Any extra documentation required to understand the issue.

@shawnh2 shawnh2 added kind/decision A record of a decision made by the community. area/provider kind/refactor labels Apr 17, 2024
@shawnh2 shawnh2 changed the title refactor the kubernetes provider to be provider-insensitive refactor the kubernetes provider to be provider-agnostic Apr 23, 2024
@Xunzhuo
Copy link
Member

Xunzhuo commented May 14, 2024

Make sense to me, it helps for multi-provider support.

@shawnh2 shawnh2 added kind/enhancement New feature or request kind/feature new feature and removed kind/decision A record of a decision made by the community. labels May 16, 2024
@shawnh2
Copy link
Contributor Author

shawnh2 commented May 16, 2024

will try to first refactor the current existing k8s provider, and then implement for the new coming file provider.

@shawnh2 shawnh2 self-assigned this May 16, 2024
Copy link

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

@sky92zwq
Copy link

Is it possible with this refactoring that part of the gateway resources come from k8s and another part from files ( Gateway api related)?

@github-actions github-actions bot removed the stale label Aug 27, 2024
@arkodg
Copy link
Contributor

arkodg commented Aug 27, 2024

hey @sky92zwq we'll need to update the Custom provider API and add a Aggregate ish resource provider to handle the case you highlighted

Copy link

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

@github-actions github-actions bot added the stale label Sep 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants