[Openais] Re: Implement configuration change support.

Steven Dake sdake at mvista.com
Wed Sep 8 00:15:02 PDT 2004


Sakai-san

Comments inline.

On Tue, 2004-09-07 at 13:28, SAKAI MIYOTAKA wrote:
> Steve ,
> 
> Steven Dake wrote:
> 
> >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.
> >
> As you pointed out , I misstook .
> 
> What I really want to say is followings .
> 
> After calling message_handler_req_amf_componentregister ,
> message_handler_req_exec_amf_componentregister
> is invoked . In that case ,
> message_handler_req_exec_amf_componentregister avoid sending
> response to the library.  
> 
> Anyway , enough design is needed .
> 

The proper way to handle this is to add a new function something like
"amf_component_register" which registers a component.  This function
would operate similiarly to message_handler_req_amf_componentregister
(the library handler) except it would setup
req_exec_amf_componentregister->source.in_addr.s_addr to 0.  Then when
the exec message handler
(message_handler_req_exec_amf_componentregister) executes, it would not
report to the library.  There is a check in the exec message handler to
report only to the originator of the message.

The amf_component_register would pair the componentUnregister function. 
amf_component_register could be used on merges, and
amf_component_unregister could be used on partitions.  Some work may
have to be done to ensure the state machine reaches consensus among the
new partition in this operational mode.  This may require new executive
messages.  I suspect the DSM may not work correctly 100% of the time by
simply adding the amf_component_register function.  Testing should tell.


> >>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.
> >
> OK .
> In this case , correct operation is necessary .
> 

I think for now we definately want to ensure a single partition after
configuration change operates correctly.  We can figure out solutions
for two or more operational partitions in the future, perhaps in 2005.

> >>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 didn't understand how gmi behave . Thank you for telling me .
> Most caese 20 is enough .=

If you want more details on gmi, in the gmi.c source code is a http link
to the design of the algorithm in use.

> >>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.  
> >
> I understand .
> 
> >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.
> >
> Sure .
> First of all , I will implement symply where only one partition remains
> after a configuration change .
> 

excellent.

> >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?
> >
> OK .
> I would like to confirme that I have to do .
> My responsiblility is to implement configuration change suport for AMF
> , and that is simple implemantaion where only partition remains
> after a configuration change .
> Next step , after consulting you , I would like to decide what I do .
> 

this sounds right.

> >>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.
> >
> It is OK with me .
> I 'm embarassed because of my terrible English .
> I'd better change appropriate the each diagram title .
> What do you think .
> Any way , I'm happy that the document I made helps someone who
> understand amf module .
> 

I think the diagrams are excellent work; something to be proud of.

If you have updates, send them to me and I'll put them on the web site.

> Is bitkeeper necessary to implement ?
> Do you have another way ?
> ( I don't have the bitkeeper licence .)
> Or should I have bitkeepr licence ( for future ) ?
> 

Bitkeeper is free (depending on your definition..) for open source
work.  Agreeing to the license just allows you to use it, but doesn't
require any payments.  I'd suggest speaking with a lawyer on the subject
if your concerned though.

But you don't have to use bitkeeper if you don't want.  diff is fine
with me for now.  Bitkeeper is only really absolutely required for
direct write access.  If you need write access later we can address the
issues at that time.

Regards
-steve

> Thanks .
> - Miyotaka Sakai .
> 
> 




More information about the Openais mailing list