Hi Hans,
Comments/answers inline.
Regards
Surya
On Friday 04 April 2014 11:16 AM, Hans Feldt wrote:
> Hi,
> I interpreted your answer such that there are two alternatives:
> 1) rely on mds sub part version but then I need to handle NEW-ACTIVE or
> 2) use message format version instead
>
> Seems like you had a preference for 2?
[Surya] Yes, message format should be used and that is the correct way
to handle this situation.
>
> Any alternative seems to require quite a few more changes in amfnd.
> Alt1 would need add new event event handling in both the mds callback
> and main thread. Alt2 would require to preserve the message format
> version all the way to the event handler.
[Surya] Yes, it is preferred to preserve the message format
version(variable i_msg_fmt_ver) all the way to event handler.
>
> But again the strange thing is that these are not the same formats and
> there is not much explaining what they are.
[Surya] I think i had already explained in my earlier emails, but here
goes the explanation.
MDS Service subpart version is the version of a service with which it
has installed with MDS.
Message format version is the version with which a message was encoded.
Such that on the receiving end,
application uses this message format version and decodes the message
accordingly.
> mds sub part version is 8
> bits, used at MDS install and service discovery (SVC_EVENT callback).
[Surya] Yes you are correct.
> But message format version is 16 bit. Normally (at least in amf)
> message format version seems to get filled with sub part version so 8
> bits of it is unused.
[Surya] Actually there were some limitations with the number of bits
that were available in the TIPC namesequence bind.
So it was limited it to 8 bits for the SVC install.
>
> Thanks,
> Hans
>
> On 3 April 2014 13:13, SuryaNarayana Garlapati
> <suryanarayana.garlap...@oracle.com> wrote:
>> Comments:
>> 1. First of all, the mds sub part version should not be stored/used. You
>> should depend on the message format version as SI rank is being embedded
>> in the new message(which is being sent from AVD).
>> If you have a requirement for usage of message version, you can get it
>> at runtime when you receive a SUSI message etc. Decode the received
>> message and use the message format version.
>> 2. As per patch, Storage of mds version will happen only once for a
>> life time. You need to process the NEW-ACTIVE event of MDS as well
>> which will make sure to store the mds version even after the
>> failover/switchover.
>>
>> Regards
>> Surya
>>
>> On Friday 28 March 2014 06:44 PM, Hans Feldt wrote:
>>> osaf/services/saf/avsv/avd/avd_mds.c | 2 ++
>>> osaf/services/saf/avsv/avnd/avnd_di.c | 1 +
>>> osaf/services/saf/avsv/avnd/avnd_mds.c | 3 +++
>>> osaf/services/saf/avsv/avnd/include/avnd_cb.h | 1 +
>>> osaf/services/saf/avsv/avnd/include/avnd_evt.h | 1 +
>>> 5 files changed, 8 insertions(+), 0 deletions(-)
>>>
>>>
>>> diff --git a/osaf/services/saf/avsv/avd/avd_mds.c
>>> b/osaf/services/saf/avsv/avd/avd_mds.c
>>> --- a/osaf/services/saf/avsv/avd/avd_mds.c
>>> +++ b/osaf/services/saf/avsv/avd/avd_mds.c
>>> @@ -414,6 +414,8 @@ static uint32_t avd_mds_svc_evt(MDS_CALL
>>> break;
>>>
>>> case NCSMDS_SVC_ID_AVND:
>>> + // TODO remove, just for test
>>> + LOG_NO("%s: AVND UP version: %u", __FUNCTION__,
>>> evt_info->i_rem_svc_pvt_ver);
>>> if (evt_info->i_node_id == cb->node_id_avd) {
>>> AVD_EVT *evt = calloc(1, sizeof(AVD_EVT));
>>> osafassert(evt);
>>> diff --git a/osaf/services/saf/avsv/avnd/avnd_di.c
>>> b/osaf/services/saf/avsv/avnd/avnd_di.c
>>> --- a/osaf/services/saf/avsv/avnd/avnd_di.c
>>> +++ b/osaf/services/saf/avsv/avnd/avnd_di.c
>>> @@ -421,6 +421,7 @@ uint32_t avnd_evt_mds_avd_up_evh(AVND_CB
>>>
>>> /* store the AVD MDS address */
>>> cb->avd_dest = evt->info.mds.mds_dest;
>>> + cb->avd_mds_ver = evt->info.mds.rem_svc_pvt_ver;
>>>
>>> avnd_send_node_up_msg();
>>> }
>>> diff --git a/osaf/services/saf/avsv/avnd/avnd_mds.c
>>> b/osaf/services/saf/avsv/avnd/avnd_mds.c
>>> --- a/osaf/services/saf/avsv/avnd/avnd_mds.c
>>> +++ b/osaf/services/saf/avsv/avnd/avnd_mds.c
>>> @@ -594,8 +594,11 @@ uint32_t avnd_mds_svc_evt(AVND_CB *cb, M
>>> case NCSMDS_UP:
>>> switch (evt_info->i_svc_id) {
>>> case NCSMDS_SVC_ID_AVD:
>>> + // TODO remove, just for test
>>> + LOG_NO("%s: AVD UP version: %u", __FUNCTION__,
>>> evt_info->i_rem_svc_pvt_ver);
>>> /* create the mds event */
>>> evt = avnd_evt_create(cb, AVND_EVT_MDS_AVD_UP, 0,
>>> &evt_info->i_dest, 0, 0, 0);
>>> + evt->info.mds.rem_svc_pvt_ver =
>>> evt_info->i_rem_svc_pvt_ver;
>>> break;
>>>
>>> case NCSMDS_SVC_ID_AVA:
>>> diff --git a/osaf/services/saf/avsv/avnd/include/avnd_cb.h
>>> b/osaf/services/saf/avsv/avnd/include/avnd_cb.h
>>> --- a/osaf/services/saf/avsv/avnd/include/avnd_cb.h
>>> +++ b/osaf/services/saf/avsv/avnd/include/avnd_cb.h
>>> @@ -50,6 +50,7 @@ typedef struct avnd_cb_tag {
>>> MDS_DEST avnd_dest; /* AvND mds addr */
>>> MDS_DEST avd_dest; /* AvD mds addr */
>>> bool is_avd_down; /* Temp: Indicates if AvD went down */
>>> + MDS_SVC_PVT_SUB_PART_VER avd_mds_ver; /* Director MDS version */
>>>
>>> /* cb related params */
>>> NCS_LOCK lock; /* cb lock */
>>> diff --git a/osaf/services/saf/avsv/avnd/include/avnd_evt.h
>>> b/osaf/services/saf/avsv/avnd/include/avnd_evt.h
>>> --- a/osaf/services/saf/avsv/avnd/include/avnd_evt.h
>>> +++ b/osaf/services/saf/avsv/avnd/include/avnd_evt.h
>>> @@ -128,6 +128,7 @@ typedef struct avnd_tmr_evt {
>>> typedef struct avnd_mds_evt {
>>> MDS_DEST mds_dest; /* mds address */
>>> NODE_ID node_id;
>>> + MDS_SVC_PVT_SUB_PART_VER rem_svc_pvt_ver;
>>> } AVND_MDS_EVT;
>>>
>>> /* HA STATE change event definition */
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Opensaf-devel mailing list
>>> Opensaf-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Opensaf-devel mailing list
>> Opensaf-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel
------------------------------------------------------------------------------
_______________________________________________
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
