It would have been desirable if it had been possible to inform a client that wants to use filter callback if that feature is available or not. Version handling using minor version could have been used for this if it had been working.
However, there are several problems:
1)
Minor version is not checked and reported back to the client in a “normal way”. If minor version is set to 0 or 1 “legacy” behavior applies. If minor version is set to 2 only CLM nodes are accepted by the log service however highest supported minor version reported back to client is always 1.
2)
The server cannot report its highest supported version back to the agent (not part of the protocol) which means that it is not possible to give the client correct information about highest supported version by the log service.
3)
The log server has an incorrect version check. It will not fail version check also if major version is higher than supported version and minor version can whatever.
A wanted behavior would be for the client to be able to tell the log service that filter callback is wanted by setting minor version to 3 (together with giving a pointer to a callback function) and get confirmation that this is supported. If a client tried to initialize with version 3 and version handling had been correct, a version 2 agent would have been able to report version error and highest supported version 2. If the client had been version 3 but the server version 2 the server could have reported version error and highest supported version 2 to the agent and the agent could then give this information to the client.
Since we have no correct version handling between the agent and the server the protocol cannot be changed for now to include information about highest supported version from server to agent.
The following should be implemented together with the filter callback enhancement:
1.
Filter callback should be given only if initialized with minor version 3
Note: If initilized with version 3 also limitiation to CLM nodes will be activated since this comes with version 2.
2.
Both in agent and server, start checking minor version and return version error if a higher minor version than 3 is set. This will also fix problem 3)
For now, don’t change the server-agent protocol to include information from the server about highest supported version since it cannot be handled in all situations and may cause a segv error.
3.
The agent shall report highest supported version when possible e.g. if not supported by the agent
Version handling “use cases”:
Now version 3 is added:
0 or 1 minor version 1 shall be sent to server
2 minor version 2 shall be sent to server
3 minor version 3 shall be sent to server
4 -> Agent shall detect version error and not send to server
Version error shall be reported to the client
Highest supported version could be set to 3 even if not known if supported by server.
Later when a future version 4 is added:
0 or 1 minor version 1 shall be sent to server
2 minor version 2 shall be sent to server
3 minor version 3 shall be sent to server
4 minor version 4 shall be sent to server
If server support version 3 but not version 4 the server shall reply
to agent with version error. The agent shall report version error
Highest supported version could be set to 3
5 -> Agent shall detect version error and not send to server
Version error shall be reported to the client
Highest supported version could be set to 4 even if not known if supported by server.
The server shall adapt to the given version i.e. handle things as the server of the given version.
If minor version given is > supported version, SA_AIS_ERR_VERSION shall be returned.
Later when all branches in OpenSAF (or maybe OpenSAF has a major update) it could also be allowed to change the agent-server protocol based on minor version
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
changeset: 8610:224db03b3ec0
tag: tip
user: Canh Van Truong canh.v.truong@dektech.com.au
date: Wed Feb 22 15:05:51 2017 +0700
summary: log: implement SaLogFilterSetCallbackT and version handling [#2146]
It would have been desirable if it had been possible to inform a client that wants to use filter callback if that feature is available or not. Version handling using minor version could have been used for this if it had been working.
However, there are several problems:
1)
Minor version is not checked and reported back to the client in a “normal way”. If minor version is set to 0 or 1 “legacy” behavior applies. If minor version is set to 2 only CLM nodes are accepted by the log service however highest supported minor version reported back to client is always 1.
2)
The server cannot report its highest supported version back to the agent (not part of the protocol) which means that it is not possible to give the client correct information about highest supported version by the log service.
3)
The log server has an incorrect version check. It will not fail version check also if major version is higher than supported version and minor version can whatever.
A wanted behavior would be for the client to be able to tell the log service that filter callback is wanted by setting minor version to 3 (together with giving a pointer to a callback function) and get confirmation that this is supported. If a client tried to initialize with version 3 and version handling had been correct, a version 2 agent would have been able to report version error and highest supported version 2. If the client had been version 3 but the server version 2 the server could have reported version error and highest supported version 2 to the agent and the agent could then give this information to the client.
Since we have no correct version handling between the agent and the server the protocol cannot be changed for now to include information about highest supported version from server to agent.
The following should be implemented together with the filter callback enhancement:
1.
Filter callback should be given only if initialized with minor version 3
Note: If initilized with version 3 also limitiation to CLM nodes will be activated since this comes with version 2.
2.
Both in agent and server, start checking minor version and return version error if a higher minor version than 3 is set. This will also fix problem 3)
For now, don’t change the server-agent protocol to include information from the server about highest supported version since it cannot be handled in all situations and may cause a segv error.
3.
The agent shall report highest supported version when possible e.g. if not supported by the agent
Version handling “use cases”:
Now version 3 is added:
0 or 1 minor version 1 shall be sent to server
2 minor version 2 shall be sent to server
3 minor version 3 shall be sent to server
4 -> Agent shall detect version error and not send to server
Version error shall be reported to the client
Highest supported version could be set to 3 even if not known if supported by server.
Later when a future version 4 is added:
0 or 1 minor version 1 shall be sent to server
2 minor version 2 shall be sent to server
3 minor version 3 shall be sent to server
4 minor version 4 shall be sent to server
If server support version 3 but not version 4 the server shall reply
to agent with version error. The agent shall report version error
Highest supported version could be set to 3
5 -> Agent shall detect version error and not send to server
Version error shall be reported to the client
Highest supported version could be set to 4 even if not known if supported by server.
The server shall adapt to the given version i.e. handle things as the server of the given version.
If minor version given is > supported version, SA_AIS_ERR_VERSION shall be returned.
Later when all branches in OpenSAF (or maybe OpenSAF has a major update) it could also be allowed to change the agent-server protocol based on minor version
changeset: 8610:224db03b3ec0
tag: tip
user: Canh Van Truong canh.v.truong@dektech.com.au
date: Wed Feb 22 15:05:51 2017 +0700
summary: log: implement SaLogFilterSetCallbackT and version handling [#2146]
Related
Tickets:
#2146