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



---

** [tickets:#2146] log: implement SaLogFilterSetCallbackT**

**Status:** accepted
**Milestone:** 5.2.FC
**Created:** Fri Oct 28, 2016 09:01 AM UTC by Vu Minh Nguyen
**Last Updated:** Thu Dec 01, 2016 09:55 AM UTC
**Owner:** Canh Truong


This ticket is to implement SaLogFilterSetCallbackT which is mentioned at 
section `3.6.5 SaLogFilterSetCallbackT` @ AIS LOG document.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

Reply via email to