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

Create endpoint to get Gaffer version #2837

Closed
t92549 opened this issue Dec 2, 2022 · 3 comments · Fixed by #3020
Closed

Create endpoint to get Gaffer version #2837

t92549 opened this issue Dec 2, 2022 · 3 comments · Fixed by #3020
Assignees
Labels
feature A proposed new feature good first issue Small, lower complexity and doesn't require pre-existing Gaffer knowledge rest-api Specific to/touches a part of the REST API
Milestone

Comments

@t92549
Copy link
Contributor

t92549 commented Dec 2, 2022

Describe the new feature you'd like
An endpoint added to the rest api to get the api's Gaffer version

Why do you want this feature?
Swagger does give this information but with the upgrade to swagger version, how to get it is inconsistent. It is important to know what Gaffer version an api is running and therefore it would be better if this was provided by the api.

Additional context
This should probably be added to both the spring-rest and core-rest

@t92549 t92549 added enhancement Improvement to existing functionality/feature good first issue Small, lower complexity and doesn't require pre-existing Gaffer knowledge labels Dec 2, 2022
@t92549 t92549 added this to the post-v2.0_backlog milestone Dec 2, 2022
@GCHQDeveloper314 GCHQDeveloper314 added rest-api Specific to/touches a part of the REST API feature A proposed new feature and removed enhancement Improvement to existing functionality/feature labels Jul 12, 2023
@tb06904 tb06904 self-assigned this Aug 29, 2023
@tb06904 tb06904 linked a pull request Sep 1, 2023 that will close this issue
@GCHQDev404
Copy link
Contributor

GCHQDev404 commented Sep 5, 2023

Its unfortunate but upon inspection of the PR the ticket is not correct.
The version should be accessible and be supported in a Federated System with multiple stores/graphs.

The approach likely should be a Operation and Handler to get the version, which can then be delegated to individual graphs using a normal FederatedOperation

@tb06904
Copy link
Member

tb06904 commented Sep 5, 2023

Its unfortunate but upon inspection of the PR the ticket is not correct. The version should be accessible and be supported in a Federated System with multiple stores/graphs.

The approach likely should be a Operation and Handler to get the version, which can then be delegated to individual graphs using a normal FederatedOperation

Isn't that a separate feature? It seems like from the original ticket its just the API version of what you are interacting with that should be returned which if it was a federated system would still work and just be the version of the graph configured with a federated store.
What you are suggesting with a Federated Operation sounds like a separate feature that could co exist with this to get a list of sub graph versions?

@GCHQDeveloper314
Copy link
Member

An operation to get the Gaffer version is a separate, but related feature. An operation could be federated to a remote graph, which might be running a different version of Gaffer to the version running the REST API a user is directly interacting with. This comment explains further, but for getting the store type.

A GetGafferVersion operation could be created under a separate ticket. It could take the work to create an endpoint and reuse this in an operation which the endpoint would then call. As has been done for the GetTraits endpoint and operation. But this wouldn't be the correct approach for certain stores, see below.

The endpoint will always return the version of Gaffer used by the REST instance. This is less useful than an operation which can be used to determine the version of Gaffer used by remote stores. However, if the endpoint is a Proxy Store, then any operations sent to it will always be processed by the remote store it's connected to. So using only an operation, it wouldn't be possible to get the Gaffer version used by a Proxy Store REST endpoint itself. The situation would be the same for a Federated Store endpoint which federated only to remote graphs.

I think that an operation would also be useful, and an endpoint would not be redundant, they would not have identical functionality.

GCHQDeveloper314 added a commit that referenced this issue Sep 13, 2023
* Add spring endpoint for getting the version

* Create endpoint for jersey API

* update tests to add version validation check via test resource

---------

Co-authored-by: GCHQDeveloper314 <94527357+GCHQDeveloper314@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature A proposed new feature good first issue Small, lower complexity and doesn't require pre-existing Gaffer knowledge rest-api Specific to/touches a part of the REST API
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants