subject:"Re\: \[devel\] \[PATCH 1 of 1\] amf\: Support AMF configurations containing more than two OpenSAF 2N SUs \[#79\]"

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

2016-04-08 Thread Anders Widell

Hi!

To re-iterate on the comment regarding addition of new validations: what 
I didn't realise when first commenting on this is that introducing such 
additional restrictions would not be backwards compatible. We could 
introduce additional restrictions like this, but then these new 
restrictions must be configurable and off by default, so that we don't 
risk breaking compatibility.

regards,
Anders Widell

On 04/04/2016 03:02 PM, Anders Widell wrote:
> See comments marked [AndersW].
>
> regards,
> Anders Widell
>
> On 04/04/2016 01:51 PM, praveen malviya wrote:
>> Ack from me with minor comments:
>>
>> -It would be better to rename the variable to 
>> "OSAF_AMF_MIN_CLUSTER_SIZE" to avoid any confusion with CLM cluster.
> [AndersW] Ok, will change the name of the variable.
>> -Also check for minimum cluster size must be added for deletion of MW 
>> 2N and Nored SUs as user may delete SU and node in different CCBs.
> [AndersW] This check was not present in the base code. Can we add it 
> later (after FC)?
>> -Since it is an environment variable, a user can still delete a SC in 
>> a running cluster by configuring a spare controller with less value 
>> and making that spare controller active. Such a problem can only be 
>> fixed by making it unique cluster wide through IMM (without allowing 
>> dynamic modification) and check-pointing it in AMFD.
> [AndersW] Well, I am assuming the setting is the same on all nodes in 
> the cluster. This is always a problem with settings in the *.conf 
> file, and not unique to this particular variable. I am not really sure 
> what you are worried about, though. I can always create a single-node 
> cluster by configuring an extra dummy node that doesn't actually exist.
>>
>> I hope the testing has been done for backward compatibility(e.g. Old 
>> Amfd communicating with new Payload or so on as node type is removed).
> [AndersW] We have been running this feature as a prototype for half a 
> year, so the feature has received a lot of testing. Due to review 
> comments, the patch has changed a bit during the last few days though. 
> If anything shows up as a result of these changes I am sure we can fix 
> them before GA.
>>
>> Also noticed that on spare controllers, directors are becoming 
>> standby in csi set callback and at the same time registering with MDS 
>> and initializing with other service. I did not observe any time out 
>> and try again. Although time out is handled, but in any case it 
>> should not be greater than configured limits of csisetcallbacktimeout.
>> Thanks,
>> Praveen
>>
>>
>> On 04-Apr-16 2:06 AM, Anders Widell wrote:
>>> Here is the latest version of the AMF patch for ticket [#79]. I have 
>>> now
>>> made the policy for the minimum number of system controller nodes
>>> configurable (in amfd.conf; the IMM API is a bit too heavy-weight 
>>> for me
>>> to use this late in the review process, and I leave its implementation
>>> as an exercise for anyone interested).
>>>
>>> Another big change is that the patch is now re-based so that it can be
>>> applied on the default branch after ticket [#1620] was pushed. Apart
>>> from just solving merge conflicts, the patch also contains a few other
>>> modifications needed for ticket [#79] to work properly together with
>>> ticket [#1620].
>>>
>>> Finally, I have put back the code for setting the sync state to "out of
>>> sync" after losing contact with the standby. After some digging in the
>>> archives, it appears the reason for this change was to make sure an
>>> si-swap cannot be performed until the (new) standby is in sync.
>>>
>>> regards,
>>> Anders Widell
>>>
>>> On 04/01/2016 06:13 PM, Mathivanan Naickan Palanivelu wrote:
>>>> I think controlling this behavior at run time should be okay. (I
>>>> didn't intend to say that introducing a build option is the only way,
>>>> And the aim was not for saving memory either :-))
>>>>
>>>> So, to start with let's then introduce a global runtime environment
>>>> variable(?) or IMM attribute - that would
>>>> control this standalone configuration changes to succeed.
>>>>
>>>> We could think of adding restrictions to cluster-size later on 
>>>> perhaps.
>>>>
>>>> Cheers,
>>>> Mathi.
>>>>
>>>>
>>>>> -Original Message-
>>>>> From: Anders Widell [mailto:anders.wid...@ericsson.com]
>>>>>

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

2016-04-04 Thread Anders Widell

See comments marked [AndersW].

regards,
Anders Widell

On 04/04/2016 01:51 PM, praveen malviya wrote:
> Ack from me with minor comments:
>
> -It would be better to rename the variable to 
> "OSAF_AMF_MIN_CLUSTER_SIZE" to avoid any confusion with CLM cluster.
[AndersW] Ok, will change the name of the variable.
> -Also check for minimum cluster size must be added for deletion of MW 
> 2N and Nored SUs as user may delete SU and node in different CCBs.
[AndersW] This check was not present in the base code. Can we add it 
later (after FC)?
> -Since it is an environment variable, a user can still delete a SC in 
> a running cluster by configuring a spare controller with less value 
> and making that spare controller active. Such a problem can only be 
> fixed by making it unique cluster wide through IMM (without allowing 
> dynamic modification) and check-pointing it in AMFD.
[AndersW] Well, I am assuming the setting is the same on all nodes in 
the cluster. This is always a problem with settings in the *.conf file, 
and not unique to this particular variable. I am not really sure what 
you are worried about, though. I can always create a single-node cluster 
by configuring an extra dummy node that doesn't actually exist.
>
> I hope the testing has been done for backward compatibility(e.g. Old 
> Amfd communicating with new Payload or so on as node type is removed).
[AndersW] We have been running this feature as a prototype for half a 
year, so the feature has received a lot of testing. Due to review 
comments, the patch has changed a bit during the last few days though. 
If anything shows up as a result of these changes I am sure we can fix 
them before GA.
>
> Also noticed that on spare controllers, directors are becoming standby 
> in csi set callback and at the same time registering with MDS and 
> initializing with other service. I did not observe any time out and 
> try again. Although time out is handled, but in any case it should not 
> be greater than configured limits of csisetcallbacktimeout.
> Thanks,
> Praveen
>
>
> On 04-Apr-16 2:06 AM, Anders Widell wrote:
>> Here is the latest version of the AMF patch for ticket [#79]. I have now
>> made the policy for the minimum number of system controller nodes
>> configurable (in amfd.conf; the IMM API is a bit too heavy-weight for me
>> to use this late in the review process, and I leave its implementation
>> as an exercise for anyone interested).
>>
>> Another big change is that the patch is now re-based so that it can be
>> applied on the default branch after ticket [#1620] was pushed. Apart
>> from just solving merge conflicts, the patch also contains a few other
>> modifications needed for ticket [#79] to work properly together with
>> ticket [#1620].
>>
>> Finally, I have put back the code for setting the sync state to "out of
>> sync" after losing contact with the standby. After some digging in the
>> archives, it appears the reason for this change was to make sure an
>> si-swap cannot be performed until the (new) standby is in sync.
>>
>> regards,
>> Anders Widell
>>
>> On 04/01/2016 06:13 PM, Mathivanan Naickan Palanivelu wrote:
>>> I think controlling this behavior at run time should be okay. (I
>>> didn't intend to say that introducing a build option is the only way,
>>> And the aim was not for saving memory either :-))
>>>
>>> So, to start with let's then introduce a global runtime environment
>>> variable(?) or IMM attribute - that would
>>> control this standalone configuration changes to succeed.
>>>
>>> We could think of adding restrictions to cluster-size later on perhaps.
>>>
>>> Cheers,
>>> Mathi.
>>>
>>>
>>>> -Original Message-
>>>> From: Anders Widell [mailto:anders.wid...@ericsson.com]
>>>> Sent: Friday, April 01, 2016 7:28 PM
>>>> To: Mathivanan Naickan Palanivelu; Praveen Malviya;
>>>> gary@dektech.com.au; hans.nordeb...@ericsson.com; Nagendra Kumar
>>>> Cc: opensaf-devel@lists.sourceforge.net
>>>> Subject: Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations
>>>> containing more than two OpenSAF 2N SUs [#79]
>>>>
>>>> Now you are talking about the possibility to save some memory on a
>>>> 1-node
>>>> system by e.g. introducing #ifdefs in the code to disable code paths
>>>> that deal
>>>> with redundancy. I can agree that in some very resource-constrained
>>>> embedded system this could make sense, but on the other hand, this is
>>>> not
>>>> good from a test

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

2016-04-04 Thread praveen malviya

Ack from me with minor comments:

-It would be better to rename the variable to 
"OSAF_AMF_MIN_CLUSTER_SIZE" to avoid any confusion with CLM cluster.
-Also check for minimum cluster size must be added for deletion of MW 2N 
and Nored SUs as user may delete SU and node in different CCBs.
-Since it is an environment variable, a user can still delete a SC in a 
running cluster by configuring a spare controller with less value and 
making that spare controller active. Such a problem can only be fixed by 
making it unique cluster wide through IMM (without allowing dynamic 
modification) and check-pointing it in AMFD.

I hope the testing has been done for backward compatibility(e.g. Old 
Amfd communicating with new Payload or so on as node type is removed).

Also noticed that on spare controllers, directors are becoming standby 
in csi set callback and at the same time registering with MDS and 
initializing with other service. I did not observe any time out and try 
again. Although time out is handled, but in any case it should not be 
greater than configured limits of csisetcallbacktimeout.
Thanks,
Praveen


On 04-Apr-16 2:06 AM, Anders Widell wrote:
> Here is the latest version of the AMF patch for ticket [#79]. I have now
> made the policy for the minimum number of system controller nodes
> configurable (in amfd.conf; the IMM API is a bit too heavy-weight for me
> to use this late in the review process, and I leave its implementation
> as an exercise for anyone interested).
>
> Another big change is that the patch is now re-based so that it can be
> applied on the default branch after ticket [#1620] was pushed. Apart
> from just solving merge conflicts, the patch also contains a few other
> modifications needed for ticket [#79] to work properly together with
> ticket [#1620].
>
> Finally, I have put back the code for setting the sync state to "out of
> sync" after losing contact with the standby. After some digging in the
> archives, it appears the reason for this change was to make sure an
> si-swap cannot be performed until the (new) standby is in sync.
>
> regards,
> Anders Widell
>
> On 04/01/2016 06:13 PM, Mathivanan Naickan Palanivelu wrote:
>> I think controlling this behavior at run time should be okay. (I
>> didn't intend to say that introducing a build option is the only way,
>> And the aim was not for saving memory either :-))
>>
>> So, to start with let's then introduce a global runtime environment
>> variable(?) or IMM attribute - that would
>> control this standalone configuration changes to succeed.
>>
>> We could think of adding restrictions to cluster-size later on perhaps.
>>
>> Cheers,
>> Mathi.
>>
>>
>>> -Original Message-
>>> From: Anders Widell [mailto:anders.wid...@ericsson.com]
>>> Sent: Friday, April 01, 2016 7:28 PM
>>> To: Mathivanan Naickan Palanivelu; Praveen Malviya;
>>> gary....@dektech.com.au; hans.nordeb...@ericsson.com; Nagendra Kumar
>>> Cc: opensaf-devel@lists.sourceforge.net
>>> Subject: Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations
>>> containing more than two OpenSAF 2N SUs [#79]
>>>
>>> Now you are talking about the possibility to save some memory on a
>>> 1-node
>>> system by e.g. introducing #ifdefs in the code to disable code paths
>>> that deal
>>> with redundancy. I can agree that in some very resource-constrained
>>> embedded system this could make sense, but on the other hand, this is
>>> not
>>> good from a testing perspective. You would have two separate builds that
>>> needs to be tested. From a developer's perspective, it is not good
>>> either.
>>> #ifdefs will mess up the code, and the developers also need to build
>>> and test
>>> the code twice. And what happens when you get the second feature,
>>> which is
>>> also enabled and disabled using #ifdefs. You will get four possible
>>> builds. With
>>> the third feature, eight possible builds.
>>>
>>> On the other hand, a redundant system must work also on a single node.
>>> Otherwise it wouldn't be redundant - i.e. if you /require/ two nodes
>>> for the
>>> system to operate then you have a 2-node system which is less
>>> available than
>>> just one single node. If any of the two nodes fails then the whole
>>> system fails.
>>> So we must in any case test that we can run on a single node without
>>> problems. Unless we have a very strong use-case for saving those
>>> extra bytes
>>> of code I would not like to introduce a build-time option for disabling
>>>

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

2016-04-03 Thread Anders Widell

Here is the latest version of the AMF patch for ticket [#79]. I have now 
made the policy for the minimum number of system controller nodes 
configurable (in amfd.conf; the IMM API is a bit too heavy-weight for me 
to use this late in the review process, and I leave its implementation 
as an exercise for anyone interested).


Another big change is that the patch is now re-based so that it can be 
applied on the default branch after ticket [#1620] was pushed. Apart 
from just solving merge conflicts, the patch also contains a few other 
modifications needed for ticket [#79] to work properly together with 
ticket [#1620].


Finally, I have put back the code for setting the sync state to "out of 
sync" after losing contact with the standby. After some digging in the 
archives, it appears the reason for this change was to make sure an 
si-swap cannot be performed until the (new) standby is in sync.


regards,
Anders Widell

On 04/01/2016 06:13 PM, Mathivanan Naickan Palanivelu wrote:

I think controlling this behavior at run time should be okay. (I didn't intend 
to say that introducing a build option is the only way,
And the aim was not for saving memory either :-))

So, to start with let's then introduce a global runtime environment variable(?) 
or IMM attribute - that would
control this standalone configuration changes to succeed.

We could think of adding restrictions to cluster-size later on perhaps.

Cheers,
Mathi.



-Original Message-
From: Anders Widell [mailto:anders.wid...@ericsson.com]
Sent: Friday, April 01, 2016 7:28 PM
To: Mathivanan Naickan Palanivelu; Praveen Malviya;
gary@dektech.com.au; hans.nordeb...@ericsson.com; Nagendra Kumar
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations
containing more than two OpenSAF 2N SUs [#79]

Now you are talking about the possibility to save some memory on a 1-node
system by e.g. introducing #ifdefs in the code to disable code paths that deal
with redundancy. I can agree that in some very resource-constrained
embedded system this could make sense, but on the other hand, this is not
good from a testing perspective. You would have two separate builds that
needs to be tested. From a developer's perspective, it is not good either.
#ifdefs will mess up the code, and the developers also need to build and test
the code twice. And what happens when you get the second feature, which is
also enabled and disabled using #ifdefs. You will get four possible builds. With
the third feature, eight possible builds.

On the other hand, a redundant system must work also on a single node.
Otherwise it wouldn't be redundant - i.e. if you /require/ two nodes for the
system to operate then you have a 2-node system which is less available than
just one single node. If any of the two nodes fails then the whole system fails.
So we must in any case test that we can run on a single node without
problems. Unless we have a very strong use-case for saving those extra bytes
of code I would not like to introduce a build-time option for disabling
redundancy.

We could introduce a run-time option for disallowing single-node
configurations. In fact, I would argue in such a case that it would be an option
to set the minimum allowed number of nodes in the system - i.e. the
minimum size you can scale down to. It doesn't necessarily have to be two;
maybe someone wishes to disallow any configuration with less than five
nodes.

regards,
Anders Widell

On 04/01/2016 03:05 PM, Mathivanan Naickan Palanivelu wrote:

We could tie the symmetry to the 'deploy-standlone' option chosen.
i.e. if 'deploy-standone' feature is enabled don't expect(wherever)
standbys including to not expect things like setting up shared file system and

all code flows that expect a second/alternate to take over, etc!

I think this has to be thought through and not just considered as a
matter of 'allowing a configuration change' for a tool to work.
It is another thing that we should discussed this when the asymmetry in

configuration got created!

If it's about reflecting the 'state' then there is sufficient states
to convey the status of that application.



-Original Message-
From: Anders Widell [mailto:anders.wid...@ericsson.com]
Sent: Friday, April 01, 2016 5:49 PM
To: Mathivanan Naickan Palanivelu; Praveen Malviya;
gary@dektech.com.au; hans.nordeb...@ericsson.com; Nagendra

Kumar

Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations
containing more than two OpenSAF 2N SUs [#79]

Today it is perfectly possible to configure a 1-node system without
using any build-time option. The problem today is that if you expand
a 1-node system to a 2-node system, then you cannot later shrink it
back into a 1-node system again. This asymmetry that you cannot go
back to where you came from makes little sense to me. Suppo

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

2016-04-01 Thread Mathivanan Naickan Palanivelu

I think controlling this behavior at run time should be okay. (I didn't intend 
to say that introducing a build option is the only way,
And the aim was not for saving memory either :-))

So, to start with let's then introduce a global runtime environment variable(?) 
or IMM attribute - that would 
control this standalone configuration changes to succeed.

We could think of adding restrictions to cluster-size later on perhaps.

Cheers,
Mathi.


>-Original Message-
>From: Anders Widell [mailto:anders.wid...@ericsson.com]
>Sent: Friday, April 01, 2016 7:28 PM
>To: Mathivanan Naickan Palanivelu; Praveen Malviya;
>gary@dektech.com.au; hans.nordeb...@ericsson.com; Nagendra Kumar
>Cc: opensaf-devel@lists.sourceforge.net
>Subject: Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations
>containing more than two OpenSAF 2N SUs [#79]
>
>Now you are talking about the possibility to save some memory on a 1-node
>system by e.g. introducing #ifdefs in the code to disable code paths that deal
>with redundancy. I can agree that in some very resource-constrained
>embedded system this could make sense, but on the other hand, this is not
>good from a testing perspective. You would have two separate builds that
>needs to be tested. From a developer's perspective, it is not good either.
>#ifdefs will mess up the code, and the developers also need to build and test
>the code twice. And what happens when you get the second feature, which is
>also enabled and disabled using #ifdefs. You will get four possible builds. 
>With
>the third feature, eight possible builds.
>
>On the other hand, a redundant system must work also on a single node.
>Otherwise it wouldn't be redundant - i.e. if you /require/ two nodes for the
>system to operate then you have a 2-node system which is less available than
>just one single node. If any of the two nodes fails then the whole system 
>fails.
>So we must in any case test that we can run on a single node without
>problems. Unless we have a very strong use-case for saving those extra bytes
>of code I would not like to introduce a build-time option for disabling
>redundancy.
>
>We could introduce a run-time option for disallowing single-node
>configurations. In fact, I would argue in such a case that it would be an 
>option
>to set the minimum allowed number of nodes in the system - i.e. the
>minimum size you can scale down to. It doesn't necessarily have to be two;
>maybe someone wishes to disallow any configuration with less than five
>nodes.
>
>regards,
>Anders Widell
>
>On 04/01/2016 03:05 PM, Mathivanan Naickan Palanivelu wrote:
>> We could tie the symmetry to the 'deploy-standlone' option chosen.
>> i.e. if 'deploy-standone' feature is enabled don't expect(wherever)
>> standbys including to not expect things like setting up shared file system 
>> and
>all code flows that expect a second/alternate to take over, etc!
>> I think this has to be thought through and not just considered as a
>> matter of 'allowing a configuration change' for a tool to work.
>> It is another thing that we should discussed this when the asymmetry in
>configuration got created!
>> If it's about reflecting the 'state' then there is sufficient states
>> to convey the status of that application.
>>
>>
>>> -Original Message-
>>> From: Anders Widell [mailto:anders.wid...@ericsson.com]
>>> Sent: Friday, April 01, 2016 5:49 PM
>>> To: Mathivanan Naickan Palanivelu; Praveen Malviya;
>>> gary@dektech.com.au; hans.nordeb...@ericsson.com; Nagendra
>Kumar
>>> Cc: opensaf-devel@lists.sourceforge.net
>>> Subject: Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations
>>> containing more than two OpenSAF 2N SUs [#79]
>>>
>>> Today it is perfectly possible to configure a 1-node system without
>>> using any build-time option. The problem today is that if you expand
>>> a 1-node system to a 2-node system, then you cannot later shrink it
>>> back into a 1-node system again. This asymmetry that you cannot go
>>> back to where you came from makes little sense to me. Suppose that
>>> the second node has been physically removed, so that you really have
>>> only one single node. What harm would it do to update the OpenSAF
>configuration to reflect this fact of reality?
>>>
>>> regards,
>>> Anders Widell
>>>
>>> On 04/01/2016 12:54 PM, Mathivanan Naickan Palanivelu wrote:
>>>> Ofcourse there could be applications(in different problem domains)
>>>> that
>>> could be configured to run in standalone mode or in HA mode.
&g

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

2016-04-01 Thread Anders Widell

Now you are talking about the possibility to save some memory on a 
1-node system by e.g. introducing #ifdefs in the code to disable code 
paths that deal with redundancy. I can agree that in some very 
resource-constrained embedded system this could make sense, but on the 
other hand, this is not good from a testing perspective. You would have 
two separate builds that needs to be tested. From a developer's 
perspective, it is not good either. #ifdefs will mess up the code, and 
the developers also need to build and test the code twice. And what 
happens when you get the second feature, which is also enabled and 
disabled using #ifdefs. You will get four possible builds. With the 
third feature, eight possible builds.

On the other hand, a redundant system must work also on a single node. 
Otherwise it wouldn't be redundant - i.e. if you /require/ two nodes for 
the system to operate then you have a 2-node system which is less 
available than just one single node. If any of the two nodes fails then 
the whole system fails. So we must in any case test that we can run on a 
single node without problems. Unless we have a very strong use-case for 
saving those extra bytes of code I would not like to introduce a 
build-time option for disabling redundancy.

We could introduce a run-time option for disallowing single-node 
configurations. In fact, I would argue in such a case that it would be 
an option to set the minimum allowed number of nodes in the system - 
i.e. the minimum size you can scale down to. It doesn't necessarily have 
to be two; maybe someone wishes to disallow any configuration with less 
than five nodes.

regards,
Anders Widell

On 04/01/2016 03:05 PM, Mathivanan Naickan Palanivelu wrote:
> We could tie the symmetry to the 'deploy-standlone' option chosen.
> i.e. if 'deploy-standone' feature is enabled don't expect(wherever) standbys 
> including to not expect
> things like setting up shared file system and all code flows that expect a 
> second/alternate to take over, etc!
> I think this has to be thought through and not just considered as a matter of 
> 'allowing a configuration change' for
> a tool to work.
> It is another thing that we should discussed this when the asymmetry in 
> configuration got created!
> If it's about reflecting the 'state' then there is sufficient states to 
> convey the status of that
> application.
>
>
>> -Original Message-
>> From: Anders Widell [mailto:anders.wid...@ericsson.com]
>> Sent: Friday, April 01, 2016 5:49 PM
>> To: Mathivanan Naickan Palanivelu; Praveen Malviya;
>> gary....@dektech.com.au; hans.nordeb...@ericsson.com; Nagendra Kumar
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations
>> containing more than two OpenSAF 2N SUs [#79]
>>
>> Today it is perfectly possible to configure a 1-node system without using any
>> build-time option. The problem today is that if you expand a 1-node system to
>> a 2-node system, then you cannot later shrink it back into a 1-node system
>> again. This asymmetry that you cannot go back to where you came from
>> makes little sense to me. Suppose that the second node has been physically
>> removed, so that you really have only one single node. What harm would it do
>> to update the OpenSAF configuration to reflect this fact of reality?
>>
>> regards,
>> Anders Widell
>>
>> On 04/01/2016 12:54 PM, Mathivanan Naickan Palanivelu wrote:
>>> Ofcourse there could be applications(in different problem domains) that
>> could be configured to run in standalone mode or in HA mode.
>>> Such applications could still be configured(in AMF) to be run on just 1
>> OpenSAF node, nothing in OpenSAF stops standalone applications today!
>>> But, I don't think it is necessary to trickle down an application's 
>>> standalone
>> configuration into OpenSAF's configuration too!
>>> Somehow this topic has come up again, and I don't understand the
>>> requirement behind why a user's tool expects HA middleware also to be
>> configured in standalone mode!
>>> If we still want to satisfy such(adhoc?) tools, then we could do that
>>> by bringing in a 'standalone' deployment option in OpenSAF, i.e.
>>> ./configure --deploy-standone. When this option is enable then immxml-
>> tools, AMF and any other OpenSAF service would not expect a mandatory
>> STANDBY to exist, thereby also allow deletion or any other operation of its
>> interest!
>>> Cheers,
>>> Mathi.
>>>
>>>> -Original Message-
>>>> From: praveen malviya
>>>> Sent: F

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

2016-04-01 Thread Mathivanan Naickan Palanivelu

We could tie the symmetry to the 'deploy-standlone' option chosen. 
i.e. if 'deploy-standone' feature is enabled don't expect(wherever) standbys 
including to not expect
things like setting up shared file system and all code flows that expect a 
second/alternate to take over, etc! 
I think this has to be thought through and not just considered as a matter of 
'allowing a configuration change' for
a tool to work.
It is another thing that we should discussed this when the asymmetry in 
configuration got created!
If it's about reflecting the 'state' then there is sufficient states to convey 
the status of that
application.


>-Original Message-
>From: Anders Widell [mailto:anders.wid...@ericsson.com]
>Sent: Friday, April 01, 2016 5:49 PM
>To: Mathivanan Naickan Palanivelu; Praveen Malviya;
>gary@dektech.com.au; hans.nordeb...@ericsson.com; Nagendra Kumar
>Cc: opensaf-devel@lists.sourceforge.net
>Subject: Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations
>containing more than two OpenSAF 2N SUs [#79]
>
>Today it is perfectly possible to configure a 1-node system without using any
>build-time option. The problem today is that if you expand a 1-node system to
>a 2-node system, then you cannot later shrink it back into a 1-node system
>again. This asymmetry that you cannot go back to where you came from
>makes little sense to me. Suppose that the second node has been physically
>removed, so that you really have only one single node. What harm would it do
>to update the OpenSAF configuration to reflect this fact of reality?
>
>regards,
>Anders Widell
>
>On 04/01/2016 12:54 PM, Mathivanan Naickan Palanivelu wrote:
>> Ofcourse there could be applications(in different problem domains) that
>could be configured to run in standalone mode or in HA mode.
>> Such applications could still be configured(in AMF) to be run on just 1
>OpenSAF node, nothing in OpenSAF stops standalone applications today!
>> But, I don't think it is necessary to trickle down an application's 
>> standalone
>configuration into OpenSAF's configuration too!
>>
>> Somehow this topic has come up again, and I don't understand the
>> requirement behind why a user's tool expects HA middleware also to be
>configured in standalone mode!
>>
>> If we still want to satisfy such(adhoc?) tools, then we could do that
>> by bringing in a 'standalone' deployment option in OpenSAF, i.e.
>> ./configure --deploy-standone. When this option is enable then immxml-
>tools, AMF and any other OpenSAF service would not expect a mandatory
>STANDBY to exist, thereby also allow deletion or any other operation of its
>interest!
>>
>> Cheers,
>> Mathi.
>>
>>> -----Original Message-----
>>> From: praveen malviya
>>> Sent: Friday, April 01, 2016 3:52 PM
>>> To: Anders Widell; gary@dektech.com.au;
>>> hans.nordeb...@ericsson.com; Nagendra Kumar
>>> Cc: opensaf-devel@lists.sourceforge.net
>>> Subject: Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations
>>> containing more than two OpenSAF 2N SUs [#79]
>>>
>>> Please see my comments inline below:
>>>
>>> On 31-Mar-16 6:50 PM, Anders Widell wrote:
>>>> Yes I added the check in the admin op as you suggested. But I don't
>>>> fully agree that the same check should be done when removing system
>>>> controller nodes. With the introduction of this feature, we are
>>>> starting to move away from the concept of different node types
>>>> (controller / payload). Indeed, I removed the "type" member variable
>>>> from the node class in the latest patch.
>>> [Praveen]
>>> Yes, all nodes can be controller nodes or rather all nodes are the
>>> same except their roles. But that does not change the architecture of
>>> OpenSAF w.r.t the redundancy model. i.e. The configuration is still 2N
>redundancy model.
>>> i.e. The smallest opensaf sized cluster (without payloads) would
>>> still be configured either of the two options as below:
>>> (a) immxml-clustersize -s 2 -p0
>>> During scale out, for spare addition atleast one standy has to exist
>>> before proceeding to configure the rest of the cluster nodes as
>>> standbys
>>> (OR)
>>> (b) immxml-clustersize -s 3 -p0
>>> Obviously the 3rd node and all other nodes added after the two nodes
>>> would act as spares.
>>>
>>>> To preserve backwards compatibility, I can agree to have this check
>>>> on systems that are configured with both system controller nodes and
>

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

2016-04-01 Thread Anders Widell

Today it is perfectly possible to configure a 1-node system without 
using any build-time option. The problem today is that if you expand a 
1-node system to a 2-node system, then you cannot later shrink it back 
into a 1-node system again. This asymmetry that you cannot go back to 
where you came from makes little sense to me. Suppose that the second 
node has been physically removed, so that you really have only one 
single node. What harm would it do to update the OpenSAF configuration 
to reflect this fact of reality?

regards,
Anders Widell

On 04/01/2016 12:54 PM, Mathivanan Naickan Palanivelu wrote:
> Ofcourse there could be applications(in different problem domains) that could 
> be configured to run in standalone mode or in HA mode.
> Such applications could still be configured(in AMF) to be run on just 1 
> OpenSAF node, nothing in OpenSAF stops standalone applications today!
> But, I don't think it is necessary to trickle down an application's 
> standalone configuration into OpenSAF's configuration too!
>
> Somehow this topic has come up again, and I don't understand the requirement 
> behind
> why a user's tool expects HA middleware also to be configured in standalone 
> mode!
>
> If we still want to satisfy such(adhoc?) tools, then we could do that by 
> bringing in a 'standalone' deployment option in OpenSAF,
> i.e. ./configure --deploy-standone. When this option is enable then 
> immxml-tools, AMF and any other OpenSAF service would not
> expect a mandatory STANDBY to exist, thereby also allow deletion or any other 
> operation of its interest!
>
> Cheers,
> Mathi.
>
>> -Original Message-
>> From: praveen malviya
>> Sent: Friday, April 01, 2016 3:52 PM
>> To: Anders Widell; gary....@dektech.com.au;
>> hans.nordeb...@ericsson.com; Nagendra Kumar
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations
>> containing more than two OpenSAF 2N SUs [#79]
>>
>> Please see my comments inline below:
>>
>> On 31-Mar-16 6:50 PM, Anders Widell wrote:
>>> Yes I added the check in the admin op as you suggested. But I don't
>>> fully agree that the same check should be done when removing system
>>> controller nodes. With the introduction of this feature, we are
>>> starting to move away from the concept of different node types
>>> (controller / payload). Indeed, I removed the "type" member variable
>>> from the node class in the latest patch.
>> [Praveen]
>> Yes, all nodes can be controller nodes or rather all nodes are the same 
>> except
>> their roles. But that does not change the architecture of OpenSAF w.r.t the
>> redundancy model. i.e. The configuration is still 2N redundancy model.
>> i.e. The smallest opensaf sized cluster (without payloads) would still be
>> configured either of the two options as below:
>> (a) immxml-clustersize -s 2 -p0
>> During scale out, for spare addition atleast one standy has to exist before
>> proceeding to configure the rest of the cluster nodes as standbys
>> (OR)
>> (b) immxml-clustersize -s 3 -p0
>> Obviously the 3rd node and all other nodes added after the two nodes would
>> act as spares.
>>
>>> To preserve backwards compatibility, I can agree to have this check on
>>> systems that are configured with both system controller nodes and
>>> payload nodes (as in your example with immxml-clustersize). This would
>>> mean that AMF will reject removal of any of the last two system
>>> controller nodes - IF the cluster has payload nodes. What do you think
>> [Praveen]
>> That is the normal case anyhow today. Only difference we have to make
>> now is to allow deletion of spare nodes whether there are payloads or not.
>>
>> Thanks,
>> Praveen.
>>
>>> about this approach? I am not sure how easy this would be to implement,
>>> but I can give it a try.
>>>
>>> regards,
>>> Anders Widell
>>>
>>> On 03/31/2016 03:05 PM, praveen malviya wrote:
>>>> Hi,
>>>>
>>>> In the diff patch, I have seen that admin operation on MW 2N SU is not
>>>> allowed when more than 2 SUs are configured which translates to the
>>>> fact that system is running with spare controllers.
>>>>
>>>> A similar type of check is needed for deletion of controller
>>>> configuration from AMF. The check would not allow deletion of
>>>> controller if only two of them remained. It is inline with the current
>>>> OpenSAF implementation with the fact that we do

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

2016-04-01 Thread Mathivanan Naickan Palanivelu

Ofcourse there could be applications(in different problem domains) that could 
be configured to run in standalone mode or in HA mode.
Such applications could still be configured(in AMF) to be run on just 1 OpenSAF 
node, nothing in OpenSAF stops standalone applications today! 
But, I don't think it is necessary to trickle down an application's standalone 
configuration into OpenSAF's configuration too!

Somehow this topic has come up again, and I don't understand the requirement 
behind 
why a user's tool expects HA middleware also to be configured in standalone 
mode!

If we still want to satisfy such(adhoc?) tools, then we could do that by 
bringing in a 'standalone' deployment option in OpenSAF,
i.e. ./configure --deploy-standone. When this option is enable then 
immxml-tools, AMF and any other OpenSAF service would not 
expect a mandatory STANDBY to exist, thereby also allow deletion or any other 
operation of its interest!

Cheers,
Mathi.

>-Original Message-
>From: praveen malviya
>Sent: Friday, April 01, 2016 3:52 PM
>To: Anders Widell; gary@dektech.com.au;
>hans.nordeb...@ericsson.com; Nagendra Kumar
>Cc: opensaf-devel@lists.sourceforge.net
>Subject: Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations
>containing more than two OpenSAF 2N SUs [#79]
>
>Please see my comments inline below:
>
>On 31-Mar-16 6:50 PM, Anders Widell wrote:
>> Yes I added the check in the admin op as you suggested. But I don't
>> fully agree that the same check should be done when removing system
>> controller nodes. With the introduction of this feature, we are
>> starting to move away from the concept of different node types
>> (controller / payload). Indeed, I removed the "type" member variable
>> from the node class in the latest patch.
>[Praveen]
>Yes, all nodes can be controller nodes or rather all nodes are the same except
>their roles. But that does not change the architecture of OpenSAF w.r.t the
>redundancy model. i.e. The configuration is still 2N redundancy model.
>i.e. The smallest opensaf sized cluster (without payloads) would still be
>configured either of the two options as below:
>(a) immxml-clustersize -s 2 -p0
>During scale out, for spare addition atleast one standy has to exist before
>proceeding to configure the rest of the cluster nodes as standbys
>(OR)
>(b) immxml-clustersize -s 3 -p0
>Obviously the 3rd node and all other nodes added after the two nodes would
>act as spares.
>
>>
>> To preserve backwards compatibility, I can agree to have this check on
>> systems that are configured with both system controller nodes and
>> payload nodes (as in your example with immxml-clustersize). This would
>> mean that AMF will reject removal of any of the last two system
>> controller nodes - IF the cluster has payload nodes. What do you think
>[Praveen]
>That is the normal case anyhow today. Only difference we have to make
>now is to allow deletion of spare nodes whether there are payloads or not.
>
>Thanks,
>Praveen.
>
>> about this approach? I am not sure how easy this would be to implement,
>> but I can give it a try.
>>
>> regards,
>> Anders Widell
>>
>> On 03/31/2016 03:05 PM, praveen malviya wrote:
>>> Hi,
>>>
>>> In the diff patch, I have seen that admin operation on MW 2N SU is not
>>> allowed when more than 2 SUs are configured which translates to the
>>> fact that system is running with spare controllers.
>>>
>>> A similar type of check is needed for deletion of controller
>>> configuration from AMF. The check would not allow deletion of
>>> controller if only two of them remained. It is inline with the current
>>> OpenSAF implementation with the fact that we do not allow any payload
>>> to get configured when user tries to generate imm.xml with single
>>> controller and a given no. of payload because such a configuration
>>> does not provide redundancy to payloads.
>>>
>>> Note: ./immxml-clustersize -s 1 -p 1
>>> error: Two SC's is required for clusters with payloads. Exiting!
>>>
>>>
>>> Thanks,
>>> Praveen
>>>
>>> On 31-Mar-16 2:05 AM, Anders Widell wrote:
>>>> Here is a patch that addresses the review comments from Hans and
>>>> Praveen. It should be applied on top of the AMF patch that was sent out
>>>> for review.
>>>>
>>>> thanks,
>>>> Anders Widell
>>>>
>>>> On 03/30/2016 04:35 PM, Anders Widell wrote:
>>>>> Hi!
>>>>>
>>>>> See my replies inl

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

2016-04-01 Thread praveen malviya

Please see my comments inline below:

On 31-Mar-16 6:50 PM, Anders Widell wrote:
> Yes I added the check in the admin op as you suggested. But I don't
> fully agree that the same check should be done when removing system
> controller nodes. With the introduction of this feature, we are starting
> to move away from the concept of different node types (controller /
> payload). Indeed, I removed the "type" member variable from the node
> class in the latest patch.
[Praveen]
Yes, all nodes can be controller nodes or rather all nodes are the same 
except their roles. But that does not change the
architecture of OpenSAF w.r.t the redundancy model. i.e. The
configuration is still 2N redundancy model.
i.e. The smallest opensaf sized cluster (without payloads) would still
be configured either of the two options as below:
(a) immxml-clustersize -s 2 -p0
During scale out, for spare addition atleast one standy has to exist 
before proceeding to configure the rest of the cluster nodes as standbys
(OR)
(b) immxml-clustersize -s 3 -p0
Obviously the 3rd node and all other nodes added after the two nodes
would act as spares.

>
> To preserve backwards compatibility, I can agree to have this check on
> systems that are configured with both system controller nodes and
> payload nodes (as in your example with immxml-clustersize). This would
> mean that AMF will reject removal of any of the last two system
> controller nodes - IF the cluster has payload nodes. What do you think
[Praveen]
That is the normal case anyhow today. Only difference we have to make 
now is to allow deletion of spare nodes whether there are payloads or not.

Thanks,
Praveen.

> about this approach? I am not sure how easy this would be to implement,
> but I can give it a try.
>
> regards,
> Anders Widell
>
> On 03/31/2016 03:05 PM, praveen malviya wrote:
>> Hi,
>>
>> In the diff patch, I have seen that admin operation on MW 2N SU is not
>> allowed when more than 2 SUs are configured which translates to the
>> fact that system is running with spare controllers.
>>
>> A similar type of check is needed for deletion of controller
>> configuration from AMF. The check would not allow deletion of
>> controller if only two of them remained. It is inline with the current
>> OpenSAF implementation with the fact that we do not allow any payload
>> to get configured when user tries to generate imm.xml with single
>> controller and a given no. of payload because such a configuration
>> does not provide redundancy to payloads.
>>
>> Note: ./immxml-clustersize -s 1 -p 1
>> error: Two SC's is required for clusters with payloads. Exiting!
>>
>>
>> Thanks,
>> Praveen
>>
>> On 31-Mar-16 2:05 AM, Anders Widell wrote:
>>> Here is a patch that addresses the review comments from Hans and
>>> Praveen. It should be applied on top of the AMF patch that was sent out
>>> for review.
>>>
>>> thanks,
>>> Anders Widell
>>>
>>> On 03/30/2016 04:35 PM, Anders Widell wrote:
 Hi!

 See my replies inline, marked [AndersW].

 regards,
 Anders Widell

 On 03/17/2016 11:32 AM, praveen malviya wrote:
> Hi Anders,
>
> Please find some comments and queries inline with [Praveen]
>
> Thanks,
> Praveen
>
>
> On 29-Feb-16 8:44 PM, Anders Widell wrote:
>> osaf/services/saf/amf/amfd/clm.cc | 21 +-
>>   osaf/services/saf/amf/amfd/include/amfd.h |   2 +
>>   osaf/services/saf/amf/amfd/include/cb.h   |   1 +
>>   osaf/services/saf/amf/amfd/include/role.h |   2 +
>>   osaf/services/saf/amf/amfd/main.cc|  78
>> ++-
>>   osaf/services/saf/amf/amfd/ndfsm.cc   |   9 ++-
>>   osaf/services/saf/amf/amfd/node.cc|   7 +--
>>   osaf/services/saf/amf/amfd/role.cc|  86
>> ++-
>>   osaf/services/saf/amf/amfd/sgproc.cc  |  11 +++-
>>   osaf/services/saf/amf/amfnd/clm.cc|  27 ++--
>>   10 files changed, 160 insertions(+), 84 deletions(-)
>>
>>
>> Add support for configuring the system with more than two OpenSAF 2N
>> SUs. In
>> particular, this means that all OpenSAF directors must support
>> starting up
>> and running without (initially) getting any assignment from AMF.
>> Locking of
>> an OpenSAF 2N SU is currently not supported on a system configured
>> with more
>> than two OpenSAF 2N SUs.
> [Praveen] This patch does not contain any change for any restricton
> on locking of OpenSAF 2N SU as mentioned above.
 [AndersW] No. This restriction will be documented. Do you think we
 need to add checks for this case in the admin op as well?
>>
>> diff --git a/osaf/services/saf/amf/amfd/clm.cc
>> b/osaf/services/saf/amf/amfd/clm.cc
>> --- a/osaf/services/saf/amf/amfd/clm.cc
>> +++ b/osaf/services/saf/amf/amfd/clm.cc
>> @@ -21,8 +21,7 @@
>>   #include 
>>   #include 
>>   #include 
>> -
>> -static SaVersionT

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

2016-03-31 Thread Anders Widell

Yes I added the check in the admin op as you suggested. But I don't 
fully agree that the same check should be done when removing system 
controller nodes. With the introduction of this feature, we are starting 
to move away from the concept of different node types (controller / 
payload). Indeed, I removed the "type" member variable from the node 
class in the latest patch.

To preserve backwards compatibility, I can agree to have this check on 
systems that are configured with both system controller nodes and 
payload nodes (as in your example with immxml-clustersize). This would 
mean that AMF will reject removal of any of the last two system 
controller nodes - IF the cluster has payload nodes. What do you think 
about this approach? I am not sure how easy this would be to implement, 
but I can give it a try.

regards,
Anders Widell

On 03/31/2016 03:05 PM, praveen malviya wrote:
> Hi,
>
> In the diff patch, I have seen that admin operation on MW 2N SU is not 
> allowed when more than 2 SUs are configured which translates to the 
> fact that system is running with spare controllers.
>
> A similar type of check is needed for deletion of controller 
> configuration from AMF. The check would not allow deletion of 
> controller if only two of them remained. It is inline with the current 
> OpenSAF implementation with the fact that we do not allow any payload 
> to get configured when user tries to generate imm.xml with single 
> controller and a given no. of payload because such a configuration 
> does not provide redundancy to payloads.
>
> Note: ./immxml-clustersize -s 1 -p 1
> error: Two SC's is required for clusters with payloads. Exiting!
>
>
> Thanks,
> Praveen
>
> On 31-Mar-16 2:05 AM, Anders Widell wrote:
>> Here is a patch that addresses the review comments from Hans and
>> Praveen. It should be applied on top of the AMF patch that was sent out
>> for review.
>>
>> thanks,
>> Anders Widell
>>
>> On 03/30/2016 04:35 PM, Anders Widell wrote:
>>> Hi!
>>>
>>> See my replies inline, marked [AndersW].
>>>
>>> regards,
>>> Anders Widell
>>>
>>> On 03/17/2016 11:32 AM, praveen malviya wrote:
 Hi Anders,

 Please find some comments and queries inline with [Praveen]

 Thanks,
 Praveen


 On 29-Feb-16 8:44 PM, Anders Widell wrote:
> osaf/services/saf/amf/amfd/clm.cc | 21 +-
>   osaf/services/saf/amf/amfd/include/amfd.h |   2 +
>   osaf/services/saf/amf/amfd/include/cb.h   |   1 +
>   osaf/services/saf/amf/amfd/include/role.h |   2 +
>   osaf/services/saf/amf/amfd/main.cc|  78
> ++-
>   osaf/services/saf/amf/amfd/ndfsm.cc   |   9 ++-
>   osaf/services/saf/amf/amfd/node.cc|   7 +--
>   osaf/services/saf/amf/amfd/role.cc|  86
> ++-
>   osaf/services/saf/amf/amfd/sgproc.cc  |  11 +++-
>   osaf/services/saf/amf/amfnd/clm.cc|  27 ++--
>   10 files changed, 160 insertions(+), 84 deletions(-)
>
>
> Add support for configuring the system with more than two OpenSAF 2N
> SUs. In
> particular, this means that all OpenSAF directors must support
> starting up
> and running without (initially) getting any assignment from AMF.
> Locking of
> an OpenSAF 2N SU is currently not supported on a system configured
> with more
> than two OpenSAF 2N SUs.
 [Praveen] This patch does not contain any change for any restricton
 on locking of OpenSAF 2N SU as mentioned above.
>>> [AndersW] No. This restriction will be documented. Do you think we
>>> need to add checks for this case in the admin op as well?
>
> diff --git a/osaf/services/saf/amf/amfd/clm.cc
> b/osaf/services/saf/amf/amfd/clm.cc
> --- a/osaf/services/saf/amf/amfd/clm.cc
> +++ b/osaf/services/saf/amf/amfd/clm.cc
> @@ -21,8 +21,7 @@
>   #include 
>   #include 
>   #include 
> -
> -static SaVersionT clmVersion = { 'B', 4, 1 };
> +#include "osaf_time.h"
>
>   static void clm_node_join_complete(AVD_AVND *node)
>   {
> @@ -392,9 +391,21 @@ SaAisErrorT avd_clm_init(void)
>   SaAisErrorT error = SA_AIS_OK;
>
>   TRACE_ENTER();
> -error = saClmInitialize_4(&avd_cb->clmHandle, &clm_callbacks,
> &clmVersion);
> -if (SA_AIS_OK != error) {
> -LOG_ER("Failed to initialize with CLM %u", error);
> +for (;;) {
> +SaVersionT Version = { 'B', 4, 1 };
> +error = saClmInitialize_4(&avd_cb->clmHandle,
> &clm_callbacks, &Version);
> +if (error == SA_AIS_ERR_TRY_AGAIN ||
> +error == SA_AIS_ERR_TIMEOUT ||
> +error == SA_AIS_ERR_UNAVAILABLE) {
> +if (error != SA_AIS_ERR_TRY_AGAIN) {
> +LOG_WA("saClmInitialize_4 returned %u",
> +   (unsigned) error);
> +}
> +osaf_nanosle

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

2016-03-31 Thread praveen malviya

Hi,

In the diff patch, I have seen that admin operation on MW 2N SU is not 
allowed when more than 2 SUs are configured which translates to the fact 
that system is running with spare controllers.

A similar type of check is needed for deletion of controller 
configuration from AMF. The check would not allow deletion of controller 
if only two of them remained. It is inline with the current OpenSAF 
implementation with the fact that we do not allow any payload to get 
configured when user tries to generate imm.xml with single controller 
and a given no. of payload because such a configuration does not provide 
redundancy to payloads.

Note: ./immxml-clustersize -s 1 -p 1
error: Two SC's is required for clusters with payloads. Exiting!


Thanks,
Praveen

On 31-Mar-16 2:05 AM, Anders Widell wrote:
> Here is a patch that addresses the review comments from Hans and
> Praveen. It should be applied on top of the AMF patch that was sent out
> for review.
>
> thanks,
> Anders Widell
>
> On 03/30/2016 04:35 PM, Anders Widell wrote:
>> Hi!
>>
>> See my replies inline, marked [AndersW].
>>
>> regards,
>> Anders Widell
>>
>> On 03/17/2016 11:32 AM, praveen malviya wrote:
>>> Hi Anders,
>>>
>>> Please find some comments and queries inline with [Praveen]
>>>
>>> Thanks,
>>> Praveen
>>>
>>>
>>> On 29-Feb-16 8:44 PM, Anders Widell wrote:
 osaf/services/saf/amf/amfd/clm.cc |  21 +-
   osaf/services/saf/amf/amfd/include/amfd.h |   2 +
   osaf/services/saf/amf/amfd/include/cb.h   |   1 +
   osaf/services/saf/amf/amfd/include/role.h |   2 +
   osaf/services/saf/amf/amfd/main.cc|  78
 ++-
   osaf/services/saf/amf/amfd/ndfsm.cc   |   9 ++-
   osaf/services/saf/amf/amfd/node.cc|   7 +--
   osaf/services/saf/amf/amfd/role.cc|  86
 ++-
   osaf/services/saf/amf/amfd/sgproc.cc  |  11 +++-
   osaf/services/saf/amf/amfnd/clm.cc|  27 ++--
   10 files changed, 160 insertions(+), 84 deletions(-)


 Add support for configuring the system with more than two OpenSAF 2N
 SUs. In
 particular, this means that all OpenSAF directors must support
 starting up
 and running without (initially) getting any assignment from AMF.
 Locking of
 an OpenSAF 2N SU is currently not supported on a system configured
 with more
 than two OpenSAF 2N SUs.
>>> [Praveen] This patch does not contain any change for any restricton
>>> on locking of OpenSAF 2N SU as mentioned above.
>> [AndersW] No. This restriction will be documented. Do you think we
>> need to add checks for this case in the admin op as well?

 diff --git a/osaf/services/saf/amf/amfd/clm.cc
 b/osaf/services/saf/amf/amfd/clm.cc
 --- a/osaf/services/saf/amf/amfd/clm.cc
 +++ b/osaf/services/saf/amf/amfd/clm.cc
 @@ -21,8 +21,7 @@
   #include 
   #include 
   #include 
 -
 -static SaVersionT clmVersion = { 'B', 4, 1 };
 +#include "osaf_time.h"

   static void clm_node_join_complete(AVD_AVND *node)
   {
 @@ -392,9 +391,21 @@ SaAisErrorT avd_clm_init(void)
   SaAisErrorT error = SA_AIS_OK;

   TRACE_ENTER();
 -error = saClmInitialize_4(&avd_cb->clmHandle, &clm_callbacks,
 &clmVersion);
 -if (SA_AIS_OK != error) {
 -LOG_ER("Failed to initialize with CLM %u", error);
 +for (;;) {
 +SaVersionT Version = { 'B', 4, 1 };
 +error = saClmInitialize_4(&avd_cb->clmHandle,
 &clm_callbacks, &Version);
 +if (error == SA_AIS_ERR_TRY_AGAIN ||
 +error == SA_AIS_ERR_TIMEOUT ||
 +error == SA_AIS_ERR_UNAVAILABLE) {
 +if (error != SA_AIS_ERR_TRY_AGAIN) {
 +LOG_WA("saClmInitialize_4 returned %u",
 +   (unsigned) error);
 +}
 +osaf_nanosleep(&kHundredMilliseconds);
 +continue;
 +}
 +if (error == SA_AIS_OK) break;
 +LOG_ER("Failed to Initialize with CLM: %u", error);
   goto done;
   }
   error = saClmSelectionObjectGet(avd_cb->clmHandle,
 &avd_cb->clm_sel_obj);
 diff --git a/osaf/services/saf/amf/amfd/include/amfd.h
 b/osaf/services/saf/amf/amfd/include/amfd.h
 --- a/osaf/services/saf/amf/amfd/include/amfd.h
 +++ b/osaf/services/saf/amf/amfd/include/amfd.h
 @@ -33,6 +33,7 @@
   #ifndef AVD_H
   #define AVD_H

 +#include 
   #include "logtrace.h"

   #include "amf.h"
 @@ -65,5 +66,6 @@
   #include "ckpt_msg.h"
   #include "ckpt_edu.h"
   #include "ckpt_updt.h"
 +#include "saAmf.h"

   #endif
 diff --git a/osaf/services/saf/amf/amfd/include/cb.h
 b/osaf/services/saf/amf/amfd/include/cb.h
 --- a/osaf/services/saf/amf/amfd/include/cb.h
 +++ b/osaf/services/saf/amf/amfd/inc

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

2016-03-30 Thread Anders Widell

Here is a patch that addresses the review comments from Hans and 
Praveen. It should be applied on top of the AMF patch that was sent out 
for review.


thanks,
Anders Widell

On 03/30/2016 04:35 PM, Anders Widell wrote:

Hi!

See my replies inline, marked [AndersW].

regards,
Anders Widell

On 03/17/2016 11:32 AM, praveen malviya wrote:

Hi Anders,

Please find some comments and queries inline with [Praveen]

Thanks,
Praveen


On 29-Feb-16 8:44 PM, Anders Widell wrote:

osaf/services/saf/amf/amfd/clm.cc |  21 +-
  osaf/services/saf/amf/amfd/include/amfd.h |   2 +
  osaf/services/saf/amf/amfd/include/cb.h   |   1 +
  osaf/services/saf/amf/amfd/include/role.h |   2 +
  osaf/services/saf/amf/amfd/main.cc|  78 
++-

  osaf/services/saf/amf/amfd/ndfsm.cc   |   9 ++-
  osaf/services/saf/amf/amfd/node.cc|   7 +--
  osaf/services/saf/amf/amfd/role.cc|  86 
++-

  osaf/services/saf/amf/amfd/sgproc.cc  |  11 +++-
  osaf/services/saf/amf/amfnd/clm.cc|  27 ++--
  10 files changed, 160 insertions(+), 84 deletions(-)


Add support for configuring the system with more than two OpenSAF 2N 
SUs. In
particular, this means that all OpenSAF directors must support 
starting up
and running without (initially) getting any assignment from AMF. 
Locking of
an OpenSAF 2N SU is currently not supported on a system configured 
with more

than two OpenSAF 2N SUs.
[Praveen] This patch does not contain any change for any restricton 
on locking of OpenSAF 2N SU as mentioned above.
[AndersW] No. This restriction will be documented. Do you think we 
need to add checks for this case in the admin op as well?


diff --git a/osaf/services/saf/amf/amfd/clm.cc 
b/osaf/services/saf/amf/amfd/clm.cc

--- a/osaf/services/saf/amf/amfd/clm.cc
+++ b/osaf/services/saf/amf/amfd/clm.cc
@@ -21,8 +21,7 @@
  #include 
  #include 
  #include 
-
-static SaVersionT clmVersion = { 'B', 4, 1 };
+#include "osaf_time.h"

  static void clm_node_join_complete(AVD_AVND *node)
  {
@@ -392,9 +391,21 @@ SaAisErrorT avd_clm_init(void)
  SaAisErrorT error = SA_AIS_OK;

  TRACE_ENTER();
-error = saClmInitialize_4(&avd_cb->clmHandle, &clm_callbacks, 
&clmVersion);

-if (SA_AIS_OK != error) {
-LOG_ER("Failed to initialize with CLM %u", error);
+for (;;) {
+SaVersionT Version = { 'B', 4, 1 };
+error = saClmInitialize_4(&avd_cb->clmHandle, 
&clm_callbacks, &Version);

+if (error == SA_AIS_ERR_TRY_AGAIN ||
+error == SA_AIS_ERR_TIMEOUT ||
+error == SA_AIS_ERR_UNAVAILABLE) {
+if (error != SA_AIS_ERR_TRY_AGAIN) {
+LOG_WA("saClmInitialize_4 returned %u",
+   (unsigned) error);
+}
+osaf_nanosleep(&kHundredMilliseconds);
+continue;
+}
+if (error == SA_AIS_OK) break;
+LOG_ER("Failed to Initialize with CLM: %u", error);
  goto done;
  }
  error = saClmSelectionObjectGet(avd_cb->clmHandle, 
&avd_cb->clm_sel_obj);
diff --git a/osaf/services/saf/amf/amfd/include/amfd.h 
b/osaf/services/saf/amf/amfd/include/amfd.h

--- a/osaf/services/saf/amf/amfd/include/amfd.h
+++ b/osaf/services/saf/amf/amfd/include/amfd.h
@@ -33,6 +33,7 @@
  #ifndef AVD_H
  #define AVD_H

+#include 
  #include "logtrace.h"

  #include "amf.h"
@@ -65,5 +66,6 @@
  #include "ckpt_msg.h"
  #include "ckpt_edu.h"
  #include "ckpt_updt.h"
+#include "saAmf.h"

  #endif
diff --git a/osaf/services/saf/amf/amfd/include/cb.h 
b/osaf/services/saf/amf/amfd/include/cb.h

--- a/osaf/services/saf/amf/amfd/include/cb.h
+++ b/osaf/services/saf/amf/amfd/include/cb.h
@@ -207,6 +207,7 @@ typedef struct cl_cb_tag {
  SaClmHandleT clmHandle;
  SaSelectionObjectT clm_sel_obj;

+bool fully_initialized;
  bool swap_switch; /* true - In middle of role switch. */

  /** true when active services (IMM, LOG, NTF, etc.) exist
diff --git a/osaf/services/saf/amf/amfd/include/role.h 
b/osaf/services/saf/amf/amfd/include/role.h

--- a/osaf/services/saf/amf/amfd/include/role.h
+++ b/osaf/services/saf/amf/amfd/include/role.h
@@ -34,6 +34,8 @@ extern uint32_t amfd_switch_qsd_stdby(AV
  extern uint32_t amfd_switch_stdby_actv(AVD_CL_CB *cb);
  extern uint32_t amfd_switch_qsd_actv(AVD_CL_CB *cb);
  extern uint32_t amfd_switch_actv_qsd(AVD_CL_CB *cb);
+extern uint32_t initialize_for_assignment(cl_cb_tag* cb,
+  SaAmfHAStateT ha_state);

  #endif /* ROLE_H */

diff --git a/osaf/services/saf/amf/amfd/main.cc 
b/osaf/services/saf/amf/amfd/main.cc

--- a/osaf/services/saf/amf/amfd/main.cc
+++ b/osaf/services/saf/amf/amfd/main.cc
@@ -56,6 +56,7 @@
  #include 
  #include 
  #include 
+#include "osaf_utility.h"

  static const char* internal_version_id_  __attribute__ ((used)) = 
"@(#) $Id: " INTERNAL_VERSION_ID " $";


@@ -445,7 +446,8 @@ static void rda_cb(uint32_t notused, PCS

  if (((avd_cb->ava

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

2016-03-30 Thread Anders Widell

Hi!

See my replies inline, marked [AndersW].

regards,
Anders Widell

On 03/17/2016 11:32 AM, praveen malviya wrote:
> Hi Anders,
>
> Please find some comments and queries inline with [Praveen]
>
> Thanks,
> Praveen
>
>
> On 29-Feb-16 8:44 PM, Anders Widell wrote:
>> osaf/services/saf/amf/amfd/clm.cc |  21 +-
>>   osaf/services/saf/amf/amfd/include/amfd.h |   2 +
>>   osaf/services/saf/amf/amfd/include/cb.h   |   1 +
>>   osaf/services/saf/amf/amfd/include/role.h |   2 +
>>   osaf/services/saf/amf/amfd/main.cc|  78 
>> ++-
>>   osaf/services/saf/amf/amfd/ndfsm.cc   |   9 ++-
>>   osaf/services/saf/amf/amfd/node.cc|   7 +--
>>   osaf/services/saf/amf/amfd/role.cc|  86 
>> ++-
>>   osaf/services/saf/amf/amfd/sgproc.cc  |  11 +++-
>>   osaf/services/saf/amf/amfnd/clm.cc|  27 ++--
>>   10 files changed, 160 insertions(+), 84 deletions(-)
>>
>>
>> Add support for configuring the system with more than two OpenSAF 2N 
>> SUs. In
>> particular, this means that all OpenSAF directors must support 
>> starting up
>> and running without (initially) getting any assignment from AMF. 
>> Locking of
>> an OpenSAF 2N SU is currently not supported on a system configured 
>> with more
>> than two OpenSAF 2N SUs.
> [Praveen] This patch does not contain any change for any restricton on 
> locking of OpenSAF 2N SU as mentioned above.
[AndersW] No. This restriction will be documented. Do you think we need 
to add checks for this case in the admin op as well?
>>
>> diff --git a/osaf/services/saf/amf/amfd/clm.cc 
>> b/osaf/services/saf/amf/amfd/clm.cc
>> --- a/osaf/services/saf/amf/amfd/clm.cc
>> +++ b/osaf/services/saf/amf/amfd/clm.cc
>> @@ -21,8 +21,7 @@
>>   #include 
>>   #include 
>>   #include 
>> -
>> -static SaVersionT clmVersion = { 'B', 4, 1 };
>> +#include "osaf_time.h"
>>
>>   static void clm_node_join_complete(AVD_AVND *node)
>>   {
>> @@ -392,9 +391,21 @@ SaAisErrorT avd_clm_init(void)
>>   SaAisErrorT error = SA_AIS_OK;
>>
>>   TRACE_ENTER();
>> -error = saClmInitialize_4(&avd_cb->clmHandle, &clm_callbacks, 
>> &clmVersion);
>> -if (SA_AIS_OK != error) {
>> -LOG_ER("Failed to initialize with CLM %u", error);
>> +for (;;) {
>> +SaVersionT Version = { 'B', 4, 1 };
>> +error = saClmInitialize_4(&avd_cb->clmHandle, 
>> &clm_callbacks, &Version);
>> +if (error == SA_AIS_ERR_TRY_AGAIN ||
>> +error == SA_AIS_ERR_TIMEOUT ||
>> +error == SA_AIS_ERR_UNAVAILABLE) {
>> +if (error != SA_AIS_ERR_TRY_AGAIN) {
>> +LOG_WA("saClmInitialize_4 returned %u",
>> +   (unsigned) error);
>> +}
>> +osaf_nanosleep(&kHundredMilliseconds);
>> +continue;
>> +}
>> +if (error == SA_AIS_OK) break;
>> +LOG_ER("Failed to Initialize with CLM: %u", error);
>>   goto done;
>>   }
>>   error = saClmSelectionObjectGet(avd_cb->clmHandle, 
>> &avd_cb->clm_sel_obj);
>> diff --git a/osaf/services/saf/amf/amfd/include/amfd.h 
>> b/osaf/services/saf/amf/amfd/include/amfd.h
>> --- a/osaf/services/saf/amf/amfd/include/amfd.h
>> +++ b/osaf/services/saf/amf/amfd/include/amfd.h
>> @@ -33,6 +33,7 @@
>>   #ifndef AVD_H
>>   #define AVD_H
>>
>> +#include 
>>   #include "logtrace.h"
>>
>>   #include "amf.h"
>> @@ -65,5 +66,6 @@
>>   #include "ckpt_msg.h"
>>   #include "ckpt_edu.h"
>>   #include "ckpt_updt.h"
>> +#include "saAmf.h"
>>
>>   #endif
>> diff --git a/osaf/services/saf/amf/amfd/include/cb.h 
>> b/osaf/services/saf/amf/amfd/include/cb.h
>> --- a/osaf/services/saf/amf/amfd/include/cb.h
>> +++ b/osaf/services/saf/amf/amfd/include/cb.h
>> @@ -207,6 +207,7 @@ typedef struct cl_cb_tag {
>>   SaClmHandleT clmHandle;
>>   SaSelectionObjectT clm_sel_obj;
>>
>> +bool fully_initialized;
>>   bool swap_switch; /* true - In middle of role switch. */
>>
>>   /** true when active services (IMM, LOG, NTF, etc.) exist
>> diff --git a/osaf/services/saf/amf/amfd/include/role.h 
>> b/osaf/services/saf/amf/amfd/include/role.h
>> --- a/osaf/services/saf/amf/amfd/include/role.h
>> +++ b/osaf/services/saf/amf/amfd/include/role.h
>> @@ -34,6 +34,8 @@ extern uint32_t amfd_switch_qsd_stdby(AV
>>   extern uint32_t amfd_switch_stdby_actv(AVD_CL_CB *cb);
>>   extern uint32_t amfd_switch_qsd_actv(AVD_CL_CB *cb);
>>   extern uint32_t amfd_switch_actv_qsd(AVD_CL_CB *cb);
>> +extern uint32_t initialize_for_assignment(cl_cb_tag* cb,
>> +  SaAmfHAStateT ha_state);
>>
>>   #endif /* ROLE_H */
>>
>> diff --git a/osaf/services/saf/amf/amfd/main.cc 
>> b/osaf/services/saf/amf/amfd/main.cc
>> --- a/osaf/services/saf/amf/amfd/main.cc
>> +++ b/osaf/services/saf/amf/amfd/main.cc
>> @@ -56,6 +56,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include "osaf_utility.h"
>>
>>   static const char* internal_version_id_  __attrib

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

2016-03-18 Thread praveen malviya

Hi Anders,

Please find some comments and queries inline with [Praveen]

Thanks,
Praveen


On 29-Feb-16 8:44 PM, Anders Widell wrote:
>   osaf/services/saf/amf/amfd/clm.cc |  21 +-
>   osaf/services/saf/amf/amfd/include/amfd.h |   2 +
>   osaf/services/saf/amf/amfd/include/cb.h   |   1 +
>   osaf/services/saf/amf/amfd/include/role.h |   2 +
>   osaf/services/saf/amf/amfd/main.cc|  78 ++-
>   osaf/services/saf/amf/amfd/ndfsm.cc   |   9 ++-
>   osaf/services/saf/amf/amfd/node.cc|   7 +--
>   osaf/services/saf/amf/amfd/role.cc|  86 
> ++-
>   osaf/services/saf/amf/amfd/sgproc.cc  |  11 +++-
>   osaf/services/saf/amf/amfnd/clm.cc|  27 ++--
>   10 files changed, 160 insertions(+), 84 deletions(-)
>
>
> Add support for configuring the system with more than two OpenSAF 2N SUs. In
> particular, this means that all OpenSAF directors must support starting up
> and running without (initially) getting any assignment from AMF. Locking of
> an OpenSAF 2N SU is currently not supported on a system configured with more
> than two OpenSAF 2N SUs.
[Praveen] This patch does not contain any change for any restricton on 
locking of OpenSAF 2N SU as mentioned above.
>
> diff --git a/osaf/services/saf/amf/amfd/clm.cc 
> b/osaf/services/saf/amf/amfd/clm.cc
> --- a/osaf/services/saf/amf/amfd/clm.cc
> +++ b/osaf/services/saf/amf/amfd/clm.cc
> @@ -21,8 +21,7 @@
>   #include 
>   #include 
>   #include 
> -
> -static SaVersionT clmVersion = { 'B', 4, 1 };
> +#include "osaf_time.h"
>
>   static void clm_node_join_complete(AVD_AVND *node)
>   {
> @@ -392,9 +391,21 @@ SaAisErrorT avd_clm_init(void)
>   SaAisErrorT error = SA_AIS_OK;
>
>   TRACE_ENTER();
> - error = saClmInitialize_4(&avd_cb->clmHandle, &clm_callbacks, 
> &clmVersion);
> - if (SA_AIS_OK != error) {
> - LOG_ER("Failed to initialize with CLM %u", error);
> + for (;;) {
> + SaVersionT Version = { 'B', 4, 1 };
> + error = saClmInitialize_4(&avd_cb->clmHandle, &clm_callbacks, 
> &Version);
> + if (error == SA_AIS_ERR_TRY_AGAIN ||
> + error == SA_AIS_ERR_TIMEOUT ||
> +error == SA_AIS_ERR_UNAVAILABLE) {
> + if (error != SA_AIS_ERR_TRY_AGAIN) {
> + LOG_WA("saClmInitialize_4 returned %u",
> +(unsigned) error);
> + }
> + osaf_nanosleep(&kHundredMilliseconds);
> + continue;
> + }
> + if (error == SA_AIS_OK) break;
> + LOG_ER("Failed to Initialize with CLM: %u", error);
>   goto done;
>   }
>   error = saClmSelectionObjectGet(avd_cb->clmHandle, 
> &avd_cb->clm_sel_obj);
> diff --git a/osaf/services/saf/amf/amfd/include/amfd.h 
> b/osaf/services/saf/amf/amfd/include/amfd.h
> --- a/osaf/services/saf/amf/amfd/include/amfd.h
> +++ b/osaf/services/saf/amf/amfd/include/amfd.h
> @@ -33,6 +33,7 @@
>   #ifndef AVD_H
>   #define AVD_H
>
> +#include 
>   #include "logtrace.h"
>
>   #include "amf.h"
> @@ -65,5 +66,6 @@
>   #include "ckpt_msg.h"
>   #include "ckpt_edu.h"
>   #include "ckpt_updt.h"
> +#include "saAmf.h"
>
>   #endif
> diff --git a/osaf/services/saf/amf/amfd/include/cb.h 
> b/osaf/services/saf/amf/amfd/include/cb.h
> --- a/osaf/services/saf/amf/amfd/include/cb.h
> +++ b/osaf/services/saf/amf/amfd/include/cb.h
> @@ -207,6 +207,7 @@ typedef struct cl_cb_tag {
>   SaClmHandleT clmHandle;
>   SaSelectionObjectT clm_sel_obj;
>
> + bool fully_initialized;
>   bool swap_switch; /* true - In middle of role switch. */
>
>   /** true when active services (IMM, LOG, NTF, etc.) exist
> diff --git a/osaf/services/saf/amf/amfd/include/role.h 
> b/osaf/services/saf/amf/amfd/include/role.h
> --- a/osaf/services/saf/amf/amfd/include/role.h
> +++ b/osaf/services/saf/amf/amfd/include/role.h
> @@ -34,6 +34,8 @@ extern uint32_t amfd_switch_qsd_stdby(AV
>   extern uint32_t amfd_switch_stdby_actv(AVD_CL_CB *cb);
>   extern uint32_t amfd_switch_qsd_actv(AVD_CL_CB *cb);
>   extern uint32_t amfd_switch_actv_qsd(AVD_CL_CB *cb);
> +extern uint32_t initialize_for_assignment(cl_cb_tag* cb,
> +  SaAmfHAStateT ha_state);
>
>   #endif /* ROLE_H */
>
> diff --git a/osaf/services/saf/amf/amfd/main.cc 
> b/osaf/services/saf/amf/amfd/main.cc
> --- a/osaf/services/saf/amf/amfd/main.cc
> +++ b/osaf/services/saf/amf/amfd/main.cc
> @@ -56,6 +56,7 @@
>   #include 
>   #include 
>   #include 
> +#include "osaf_utility.h"
>
>   static const char* internal_version_id_  __attribute__ ((used)) = "@(#) 
> $Id: " INTERNAL_VERSION_ID " $";
>
> @@ -445,7 +446,8 @@ static void rda_cb(uint32_t notused, PCS
>
>   if (((avd_cb->avail_state_avd == SA_AMF_HA_STANDBY) ||
>(avd_cb->avail_state_avd == SA_AMF_HA_QUIESCED)) &&
> - (cb_info->info.io_rol

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

2016-03-15 Thread Hans Nordebäck

ack, code review. MInor comments inlined/Thanks HansN

On 02/29/2016 04:14 PM, Anders Widell wrote:
>   osaf/services/saf/amf/amfd/clm.cc |  21 +-
>   osaf/services/saf/amf/amfd/include/amfd.h |   2 +
>   osaf/services/saf/amf/amfd/include/cb.h   |   1 +
>   osaf/services/saf/amf/amfd/include/role.h |   2 +
>   osaf/services/saf/amf/amfd/main.cc|  78 ++-
>   osaf/services/saf/amf/amfd/ndfsm.cc   |   9 ++-
>   osaf/services/saf/amf/amfd/node.cc|   7 +--
>   osaf/services/saf/amf/amfd/role.cc|  86 
> ++-
>   osaf/services/saf/amf/amfd/sgproc.cc  |  11 +++-
>   osaf/services/saf/amf/amfnd/clm.cc|  27 ++--
>   10 files changed, 160 insertions(+), 84 deletions(-)
>
>
> Add support for configuring the system with more than two OpenSAF 2N SUs. In
> particular, this means that all OpenSAF directors must support starting up
> and running without (initially) getting any assignment from AMF. Locking of
> an OpenSAF 2N SU is currently not supported on a system configured with more
> than two OpenSAF 2N SUs.
>
> diff --git a/osaf/services/saf/amf/amfd/clm.cc 
> b/osaf/services/saf/amf/amfd/clm.cc
> --- a/osaf/services/saf/amf/amfd/clm.cc
> +++ b/osaf/services/saf/amf/amfd/clm.cc
> @@ -21,8 +21,7 @@
>   #include 
>   #include 
>   #include 
> -
> -static SaVersionT clmVersion = { 'B', 4, 1 };
> +#include "osaf_time.h"
>   
>   static void clm_node_join_complete(AVD_AVND *node)
>   {
> @@ -392,9 +391,21 @@ SaAisErrorT avd_clm_init(void)
>   SaAisErrorT error = SA_AIS_OK;
>   
>   TRACE_ENTER();
> - error = saClmInitialize_4(&avd_cb->clmHandle, &clm_callbacks, 
> &clmVersion);
> - if (SA_AIS_OK != error) {
> - LOG_ER("Failed to initialize with CLM %u", error);
> + for (;;) {
> + SaVersionT Version = { 'B', 4, 1 };
> + error = saClmInitialize_4(&avd_cb->clmHandle, &clm_callbacks, 
> &Version);
> + if (error == SA_AIS_ERR_TRY_AGAIN ||
> + error == SA_AIS_ERR_TIMEOUT ||
> +error == SA_AIS_ERR_UNAVAILABLE) {
> + if (error != SA_AIS_ERR_TRY_AGAIN) {
> + LOG_WA("saClmInitialize_4 returned %u",
> +(unsigned) error);
> + }
> + osaf_nanosleep(&kHundredMilliseconds);
> + continue;
> + }
> + if (error == SA_AIS_OK) break;
> + LOG_ER("Failed to Initialize with CLM: %u", error);
>   goto done;
>   }
>   error = saClmSelectionObjectGet(avd_cb->clmHandle, 
> &avd_cb->clm_sel_obj);
> diff --git a/osaf/services/saf/amf/amfd/include/amfd.h 
> b/osaf/services/saf/amf/amfd/include/amfd.h
> --- a/osaf/services/saf/amf/amfd/include/amfd.h
> +++ b/osaf/services/saf/amf/amfd/include/amfd.h
> @@ -33,6 +33,7 @@
>   #ifndef AVD_H
>   #define AVD_H
>   
[HansN] use #include 
> +#include 
>   #include "logtrace.h"
>   
>   #include "amf.h"
> @@ -65,5 +66,6 @@
>   #include "ckpt_msg.h"
>   #include "ckpt_edu.h"
>   #include "ckpt_updt.h"
> +#include "saAmf.h"
>   
>   #endif
> diff --git a/osaf/services/saf/amf/amfd/include/cb.h 
> b/osaf/services/saf/amf/amfd/include/cb.h
> --- a/osaf/services/saf/amf/amfd/include/cb.h
> +++ b/osaf/services/saf/amf/amfd/include/cb.h
> @@ -207,6 +207,7 @@ typedef struct cl_cb_tag {
>   SaClmHandleT clmHandle;
>   SaSelectionObjectT clm_sel_obj;
>   
> + bool fully_initialized;
>   bool swap_switch; /* true - In middle of role switch. */
>   
>   /** true when active services (IMM, LOG, NTF, etc.) exist
> diff --git a/osaf/services/saf/amf/amfd/include/role.h 
> b/osaf/services/saf/amf/amfd/include/role.h
> --- a/osaf/services/saf/amf/amfd/include/role.h
> +++ b/osaf/services/saf/amf/amfd/include/role.h
> @@ -34,6 +34,8 @@ extern uint32_t amfd_switch_qsd_stdby(AV
>   extern uint32_t amfd_switch_stdby_actv(AVD_CL_CB *cb);
>   extern uint32_t amfd_switch_qsd_actv(AVD_CL_CB *cb);
>   extern uint32_t amfd_switch_actv_qsd(AVD_CL_CB *cb);
> +extern uint32_t initialize_for_assignment(cl_cb_tag* cb,
> +  SaAmfHAStateT ha_state);
>   
>   #endif /* ROLE_H */
>   
> diff --git a/osaf/services/saf/amf/amfd/main.cc 
> b/osaf/services/saf/amf/amfd/main.cc
> --- a/osaf/services/saf/amf/amfd/main.cc
> +++ b/osaf/services/saf/amf/amfd/main.cc
> @@ -56,6 +56,7 @@
>   #include 
>   #include 
>   #include 
> +#include "osaf_utility.h"
>   
>   static const char* internal_version_id_  __attribute__ ((used)) = "@(#) 
> $Id: " INTERNAL_VERSION_ID " $";
>   
> @@ -445,7 +446,8 @@ static void rda_cb(uint32_t notused, PCS
>   
>   if (((avd_cb->avail_state_avd == SA_AMF_HA_STANDBY) ||
>(avd_cb->avail_state_avd == SA_AMF_HA_QUIESCED)) &&
> - (cb_info->info.io_role == PCS_RDA_ACTIVE)) {
> + (cb_info->info.io_role == PCS_RDA_ACTIVE ||
> +

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

2016-03-08 Thread praveen malviya

Hi Anders,

When applied over cloud resilience patches (#1620) failures observed for 
amf patch:

Hunk #6 succeeded at 673 (offset 20 lines).
1 out of 6 hunks FAILED -- saving rejects to file 
osaf/services/saf/amf/amfd/main.cc.rej

..
1 out of 4 hunks FAILED -- saving rejects to file 
osaf/services/saf/amf/amfnd/clm.cc.rej

Please provide the latest version if possible.
Thanks,
Praveen

On 29-Feb-16 8:44 PM, Anders Widell wrote:
>   osaf/services/saf/amf/amfd/clm.cc |  21 +-
>   osaf/services/saf/amf/amfd/include/amfd.h |   2 +
>   osaf/services/saf/amf/amfd/include/cb.h   |   1 +
>   osaf/services/saf/amf/amfd/include/role.h |   2 +
>   osaf/services/saf/amf/amfd/main.cc|  78 ++-
>   osaf/services/saf/amf/amfd/ndfsm.cc   |   9 ++-
>   osaf/services/saf/amf/amfd/node.cc|   7 +--
>   osaf/services/saf/amf/amfd/role.cc|  86 
> ++-
>   osaf/services/saf/amf/amfd/sgproc.cc  |  11 +++-
>   osaf/services/saf/amf/amfnd/clm.cc|  27 ++--
>   10 files changed, 160 insertions(+), 84 deletions(-)
>
>
> Add support for configuring the system with more than two OpenSAF 2N SUs. In
> particular, this means that all OpenSAF directors must support starting up
> and running without (initially) getting any assignment from AMF. Locking of
> an OpenSAF 2N SU is currently not supported on a system configured with more
> than two OpenSAF 2N SUs.
>
> diff --git a/osaf/services/saf/amf/amfd/clm.cc 
> b/osaf/services/saf/amf/amfd/clm.cc
> --- a/osaf/services/saf/amf/amfd/clm.cc
> +++ b/osaf/services/saf/amf/amfd/clm.cc
> @@ -21,8 +21,7 @@
>   #include 
>   #include 
>   #include 
> -
> -static SaVersionT clmVersion = { 'B', 4, 1 };
> +#include "osaf_time.h"
>
>   static void clm_node_join_complete(AVD_AVND *node)
>   {
> @@ -392,9 +391,21 @@ SaAisErrorT avd_clm_init(void)
>   SaAisErrorT error = SA_AIS_OK;
>
>   TRACE_ENTER();
> - error = saClmInitialize_4(&avd_cb->clmHandle, &clm_callbacks, 
> &clmVersion);
> - if (SA_AIS_OK != error) {
> - LOG_ER("Failed to initialize with CLM %u", error);
> + for (;;) {
> + SaVersionT Version = { 'B', 4, 1 };
> + error = saClmInitialize_4(&avd_cb->clmHandle, &clm_callbacks, 
> &Version);
> + if (error == SA_AIS_ERR_TRY_AGAIN ||
> + error == SA_AIS_ERR_TIMEOUT ||
> +error == SA_AIS_ERR_UNAVAILABLE) {
> + if (error != SA_AIS_ERR_TRY_AGAIN) {
> + LOG_WA("saClmInitialize_4 returned %u",
> +(unsigned) error);
> + }
> + osaf_nanosleep(&kHundredMilliseconds);
> + continue;
> + }
> + if (error == SA_AIS_OK) break;
> + LOG_ER("Failed to Initialize with CLM: %u", error);
>   goto done;
>   }
>   error = saClmSelectionObjectGet(avd_cb->clmHandle, 
> &avd_cb->clm_sel_obj);
> diff --git a/osaf/services/saf/amf/amfd/include/amfd.h 
> b/osaf/services/saf/amf/amfd/include/amfd.h
> --- a/osaf/services/saf/amf/amfd/include/amfd.h
> +++ b/osaf/services/saf/amf/amfd/include/amfd.h
> @@ -33,6 +33,7 @@
>   #ifndef AVD_H
>   #define AVD_H
>
> +#include 
>   #include "logtrace.h"
>
>   #include "amf.h"
> @@ -65,5 +66,6 @@
>   #include "ckpt_msg.h"
>   #include "ckpt_edu.h"
>   #include "ckpt_updt.h"
> +#include "saAmf.h"
>
>   #endif
> diff --git a/osaf/services/saf/amf/amfd/include/cb.h 
> b/osaf/services/saf/amf/amfd/include/cb.h
> --- a/osaf/services/saf/amf/amfd/include/cb.h
> +++ b/osaf/services/saf/amf/amfd/include/cb.h
> @@ -207,6 +207,7 @@ typedef struct cl_cb_tag {
>   SaClmHandleT clmHandle;
>   SaSelectionObjectT clm_sel_obj;
>
> + bool fully_initialized;
>   bool swap_switch; /* true - In middle of role switch. */
>
>   /** true when active services (IMM, LOG, NTF, etc.) exist
> diff --git a/osaf/services/saf/amf/amfd/include/role.h 
> b/osaf/services/saf/amf/amfd/include/role.h
> --- a/osaf/services/saf/amf/amfd/include/role.h
> +++ b/osaf/services/saf/amf/amfd/include/role.h
> @@ -34,6 +34,8 @@ extern uint32_t amfd_switch_qsd_stdby(AV
>   extern uint32_t amfd_switch_stdby_actv(AVD_CL_CB *cb);
>   extern uint32_t amfd_switch_qsd_actv(AVD_CL_CB *cb);
>   extern uint32_t amfd_switch_actv_qsd(AVD_CL_CB *cb);
> +extern uint32_t initialize_for_assignment(cl_cb_tag* cb,
> +  SaAmfHAStateT ha_state);
>
>   #endif /* ROLE_H */
>
> diff --git a/osaf/services/saf/amf/amfd/main.cc 
> b/osaf/services/saf/amf/amfd/main.cc
> --- a/osaf/services/saf/amf/amfd/main.cc
> +++ b/osaf/services/saf/amf/amfd/main.cc
> @@ -56,6 +56,7 @@
>   #include 
>   #include 
>   #include 
> +#include "osaf_utility.h"
>
>   static const char* internal_version_id_  __attribute__ ((used)) = "@(#) 
> $Id: " INTERNAL_VERSION_ID " $";
>
> @@ -445,7 +446,8 @@ static void rda_c

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

Re: [devel] [PATCH 1 of 1] amf: Support AMF configurations containing more than two OpenSAF 2N SUs [#79]

17 matches

Site Navigation

Mail list logo

Footer information