HBASE-28645 Add build information to the REST server version endpoint #6262
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
| optional string osVersion = 3; | ||
| optional string serverVersion = 4; | ||
| optional string jerseyVersion = 5; | ||
| optional string version = 6; |
There was a problem hiding this comment.
Are older clients going to be able to handle this ?
There was a problem hiding this comment.
Many thanks, this is a very good question. I'll investigate this a bit to make sure.
There was a problem hiding this comment.
The short answer is: yes.
The long answer:
Extending a Protocol Buffer
Sooner or later after you release the code that uses your protocol buffer, you will undoubtedly want to “improve” the protocol buffer’s definition. If you want your new buffers to be backwards-compatible, and your old buffers to be forward-compatible – and you almost certainly do want this – then there are some rules you need to follow. In the new version of the protocol buffer:
- you must not change the tag numbers of any existing fields.
- you must not add or delete any required fields.
- you may delete optional or repeated fields.
- you may add new optional or repeated fields but you must use fresh tag numbers (that is, tag numbers that -
were never used in this protocol buffer, not even by deleted fields).
(There are some exceptions to these rules, but they are rarely used.)
If you follow these rules, old code will happily read new messages and simply ignore any new fields. To the old code, optional fields that were deleted will simply have their default value, and deleted repeated fields will be empty. New code will also transparently read old messages. However, keep in mind that new optional fields will not be present in old messages, so you will need to either check explicitly whether they’re set with has_, or provide a reasonable default value in your .proto file with [default = value] after the tag number. If the default value is not specified for an optional element, a type-specific default value is used instead: for strings, the default value is the empty string.
...
Source: https://protobuf.dev/getting-started/javatutorial/#extending-a-protobuf
Besides I tested it like this:
- Took (copied) the Base64 encoded serialized protobuf message which also contains the newly added version and revision fields:
AS_PB = "CgUwLjAuMRInU3VuIE1pY3Jvc3lzdGVtcyBJbmMuIDEuNi4wXzEzLTExLjMtYjAyGi1MaW51eCAyLjYuMTg"
+ "tMTI4LjEuNi5lbDUuY2VudG9zLnBsdXN4ZW4gYW1kNjQiBjYuMS4xNCoIMS4xLjAtZWEyFjQuMC4wLWFscGhhLT"
+ "EtU05BUFNIT1Q6KDUwODVkMjdhYjE3ZDg1NzExOGE5NmFlM2YzN2MwMGI2MGM5MjU0NzE=";- Switched to the
masterbranch (which does not yet have these version and revision fields yet). - In
TestVersionModelI changed the serialized protobuf string to the new one which has the new fields - Run a Maven clean install to make sure the project is clean
- Executed
TestVersionModelunit test which was green (was able to read the protobuf message).
(I also tried out this in a small new Java project.)
--> older clients should read new message and newer clients should read old messages without a problem.
|
In the meantime I found that the Reference Guide on the https://hbase.apache.org/ website also lists the protobuf and XML schemas which needs to be updated: Will do that quickly. |
|
Thank you. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Thanks, good point. 👍 I tested multiple cases now, including the one you mentioned and every case works and there are no errors. Created a small and dirty Java application which calls the rest version REST API endpoint of the HBase REST server component, then parses the response to the
Test results(New version means this branch.) New REST server version - old client (2.5.9)New REST server version - new clientOld REST server version (2.5.9) - new client |
|
I also noticed that that this Should I maybe document it there? |
|
That would be nice |
Hi @PDavid You may want to have a look at https://issues.apache.org/jira/browse/HBASE-20714. Feel free to assign this to youself along with the version endpoint documentation task. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
🎊 +1 overall
This message was automatically generated. |
|
🎊 +1 overall
This message was automatically generated. |
stoty
left a comment
stoty
left a comment
There was a problem hiding this comment.
+1 LGTM
Thanks for thoroughly testing my concerns.
|
Please create a separate PR for branch-2, so that the CI checks can run on that one, too. |
|
Many thanks for both for your feedback. 👍
I created the backport PR here: |
…#6262) Signed-off-by: Nihal Jain <[email protected]> Signed-off-by: Istvan Toth <[email protected]> (cherry picked from commit 64a49a2)
4 participants
https://issues.apache.org/jira/browse/HBASE-28645
Add version and revision fields to the
/version/restendpoint, which reports the build version and Git revision of the REST server component.Version determination
The REST server component determines the version and revision locally (i.e. not from the HBase cluster).
The REST server component uses the
org.apache.hadoop.hbase.util.VersionInfoclass (from thehbase-commonsproject).So when the REST server component (
hbase-rest-*.jar) is running it gets the version and revision fromhbase-commons-*.jaron the classpath.Startup logging
Note: The version and revision is logged already when the REST server component is started and it already uses the same
org.apache.hadoop.hbase.util.VersionInfoclass, so I did not changed this.