[Openais] Re: Implement configuration change support.

[Steven Dake]

Sakai-san

I have copied the openais mailing list so others can benefit from our
exchanges.

Your ideas are good I've included some comments inline.

On Mon, 2004-09-06 at 14:31, SAKAI MIYOTAKA wrote:
> Steve ,
> 
> TODO list says ,
> "Very Important: Implement configuration change support. This includes
> partitions."
> I think so too.
> 
> I suppose this could be done , without a lot of changes of dsm and
> interfaces to other aisexecs .
> 
> My idea is followings
> 
> To implement configuration chage is to implement .config _fn
> in service_handler amf_service_handler .
> If .config_fn is called and left nodes exist ,

There is already a function called within the service handler for
configuration changes.  The problem is that the configuration change
handler isn't implemented for AMF, CKPT, or EVT.  CLM is implemented,
though.

The interface in the service handler is:
.confchg_fn (which is defined in the amf to 0 at the moment).  The
function call looks like this:

static int amf_confchg_fn (
    struct sockaddr_in *member_list, int member_list_entries,
    struct sockaddr_in *left_list, int left_list_entries,
    struct sockaddr_in *joined_list, int joined_list_entries);


> .config_fn calls dsmEnabledUnlockedTransitionDisabledUnlocked to
> components in left nodes.
> If joined nodes exist , .config_fn calls a function changed
> message_handler_req_amf_componentregister.
> After calling message_handler_req_amf_componentregister ,
> message_handler_req_exec_amf_componentunregister
> is invoked . In that case ,
> message_handler_req_exec_amf_componentunregister does must not
> call libais_send_response .

Right I understand what you desire.  To avoid sending a response to the
library when doing a component unregister, use the
"componentUnregister()" function in amf executive.

You will probably need an added function component_register which
behaves the same as componentUnregister.

> But my concern is performance .
> If a aisexective has a lot of componet , when a certain node joining ,a
> lot of UDP packets sende

I'd focus on correct operation instead of performance at this point. 
I'd expect the failover happens in less then 5ms in most cases today and
if we can keep this sort of performance we should be satisified.

> In that case , it might be neccessary to chage EVS .
> ( For example , Token keeping during several messages sending . )
> 

The gmi (low level group messaging interface) keeps a token for as many
messages as can be sent without overflowing local or remote buffers. 
This happens to be set  to 20 at the moment, but can be increased.  I've
run it at 80 without packet loss, but slower CPUs have problems with
that.  Eventually we need to rework the flow control so it determines
the maximum flow control rate for the processors that make up the
configuration.

> I would like to implement this changes , if you don't mind and allow me .
> My idea showed above is verry simple , but I know it is necessary to
> design enough .
> when implemening this , your advice must be needed .
> Please agreed with me and tell me deadline .
> ( Pleaes give me enough time )
> 

Your contributions for partitioning would be wonderful!  I'd suggest
keeping in mind what should happen when two seperate partitions occur
and operate simulatenously.  This is a big problem with the AIS AMF
spec.  But if we can get it to work for the most common case where only
one partition remains after a configuration change, we should be
satisified for our next release.

We are hoping to have a release by the end of the year including CLM,
EVT, AMF, CKPT and the recently added EVS.  If someone develops the two
remaining services between now and November, we may also add support for
those.  The release should have some basic man pages.  We should also
strive for 90% code coverage with the test suites we have available.

How does this timeline work for you?

> By the way , to understand amf module , I made document attaced this
> message .
> This document isn't well reviewed , but it help someone understand amf
> module .
> if you allow me , I send it to mailing list .
> And give me some advice .
> 

This is really great work!  If it is ok with you, I'll post this to the
openais web site so other people can see it.  Let me know if that is ok.

Regards
-steve

> regards
> - Miyotaka Sakai .