-
Notifications
You must be signed in to change notification settings - Fork 93
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
[Feat]: Scale-out cluster support for independent per-instance storage deployments #2434
Comments
However, the GQL APIs are handled via a GQL server handling auto generated GQL - the implementation of which cannot be changed. extRouter.Methods(allowedMethods...).
Handler(gqlHandler.NewDefaultServer(gql_generated.NewExecutableSchema(resConfig))) One approach might be to look into the Resolver code (resolver.go) and modify the data read to include proxied results before the response is taken for pagination. For example:
This function must ask all other nodes for images having this CVE before returning the TagInfo objects. That logic could be introduced as a wrapper on top of these functions that will do the following:
To facilitate this, there needs to be a new set of API endpoints that return this data without pagination. i.e the same GQL query except without any pagination. Since the request data does not flow to the resolver, there would be a need to bring that logic to the resolver so |
@vrajashkr do you want to start with paginated result (aggregate) of paginated results (fanout)? The second part is what needs to redesigned? Maybe we simply add a pagination=off param. |
Separately, keep an eye on sync as a means to "heal" after a cluster resize. |
GQL Query behaviours: Proxy-once to target member or handle locallyCVEListForImage Fan-out proxy to all other members + localImageListForCVE Depending on meta storage strategyIf the metadata DB is shared, then they can be processed locally, but if the metadata DB is not shared, this request needs to be fanned out: Handler logic change to dynamically query other zot instancesCVEDiffListForImages - the data for each image (subtrahend and minuend) are both available from their respective single zot instances. Depending on where the request lands, there may be 2 requests made to other zot instances (if both repos are not on the current instance), one request (if either of the images are not available locally), or no requests (if both images are available locally). Note: this requires a change in the handler itself as there is no logical way to proxy the incoming request to get the required data. |
Is your feature request related to a problem? Please describe.
The current implementation of scale-out cluster is supported on shared-storage deployments - many instances and one reliable shared storage such as S3.
Currently, some REST APIs will not work for deployments where the image storage for each instance is isolated (for example, one zot instance per VM with independent disk storage).
Describe the solution you'd like
In a scale-out cluster deployment using isolated per-instance storage, APIs such as
/v2/_catalog
as well as GraphQL endpoints will need to fan-out requests to all the members and aggregate the received data before returning results.Describe alternatives you've considered
N/A
Additional context
No response
The text was updated successfully, but these errors were encountered: