[Openais] Re: Implement configuration change support.

SAKAI MIYOTAKA sakai.miyotaka at nttcom.co.jp
Wed Sep 8 13:28:56 PDT 2004


Steve ,


Steven Dake wrote:

>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.
>  
>
OK. I understand what you said .

>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.
>  
>
I see .

>  
>
>>>>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.
>  
>
I would like to use time for implementation more than updating that
documents .
Please 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.
>  
>
I have got the license .
But it is first time for me to use Bitkeeper .
I 'll send another message after this message .
Please catch that .

thanks
- Miyotaka Sakai .

>Regards
>-steve
>  
>
>>Thanks .
>>- Miyotaka Sakai .
>>
>>    
>>





More information about the Openais mailing list