[cgl_discussion] CGL requirement - checkpointing

Pan, Deng deng.pan at intel.com
Fri Jun 20 17:13:41 PDT 2003

AIS was a huge set of API, including its availability framework,
checkpointing, membership, event, messaging, and lock, and the basis is
its framework. If OCF want to adopt AIS checkpointing API, they have to
change their own existing event and membership API to AIS event and
membership API and adopt the AIS framework. Although there is no public
statement of OCF that they will never adopt AIS, I really do not think
that OCF will do that.

-----Original Message-----
From: John Cherry [mailto:cherry at osdl.org] 
Sent: 2003-06-20 23:33
To: Pan, Deng
Cc: cgl_discussion at osdl.org
Subject: RE: [cgl_discussion] CGL requirement - checkpointing

Perhaps I am missing something here.  If the OCF does not have a
checkpointing interface defined, why wouldn't they adopt the AIS
interface? or at least consider it?  Have the OCF folks said that they
would not adopt an AIS interface if they do not a checkpointing
defined themselves?


> My idea is to implement the data checkpointing based on Linux-HA
> Heartbeat project. You know, checkpointing has to depend on the low
> level services provided by
> Heartbeat project. It will be served as loadable module of Heartbeat
> because some customers may think that stateless failover is enough, as
> Peter pointed out.
> As for the API compliance, it is my biggest headache. Linux-HA
> is the reference implementation of OCF and its API will be OCF
> compliant. But currently, OCF has no data checkpointing API published.
> But if I implement AIS based on OCF, it is hard to be accepted by the
> OCF community. The most optimistic result is I create a new set of
> checkpointing API and publish it as one part of OCF, just throwing AIS
> away. Anyway, we can still borrow some ideas from AIS.
> For the licensing model, it should be GPL because Linux-HA heartbeat
> GPL.
> -----Original Message-----
> From: Peter Badovinatz [mailto:tabmowzo at us.ibm.com]
> Sent: 2003-06-20 3:02
> To: Pan, Deng
> Cc: cgl_discussion at osdl.org
> Subject: Re: [cgl_discussion] CGL requirement - checkpointing
> "Pan, Deng" wrote:
>> Hi, steven:
>> In my opinion, the main gap between customer clustering requirement
> and
>> the existing open source clustering project is the stateful failover,
>> because we have already had the stateless failover solution such as
>> Linux-HA and FailSafe. Without checkpointing, we can not do the
> stateful
>> failover and our osdl clutering efforts will be dimmed too much.
> Deng,
> You're correct that stateful failover is the gap here.  I'll point out
> that stateless failover support has a very broad market in itself, so
> shouldn't consider existing OSDL clustering efforts to be as dim as
> imply.
> But as we're talking "Carrier" Grade Linux, then yes, checkpointing is
> key missing element, and we've no current open path to support it.
>> Yes, I am considering solving this requirement. Although currently
> there
>> is no open source project aimed at this requirement, there do have
>> several commercial solutions available from SAF members right now.
>> Actually, SAF Application Interface Specification was based on those
>> solutions :-)
> We're well aware of the SAF AIS.  A specification is not an open
> implementation though, that and the existence of commercial solutions
> leads us to place checkpointing in the "future resolution" category at
> this time.  Note that the commercial solutions do not exactly map to
> AIS, despite being the inspiration for it.  The specification evolved
> away from direct match to any one implementation as it was being
> developed.
>> I will put more my ideas here later.
> We welcome them, as Steve states.
>> -----Original Message-----
>> From: Steven Dake [mailto:sdake at mvista.com]
>> Sent: 2003-06-17 23:30
>> To: Pan, Deng
>> Cc: cgl_discussion at osdl.org
>> Subject: Re: [cgl_discussion] FYI - PoC Tracking Sheets updated
>> Deng,
>> At the Helsinki F2F, checkpointing and several other cluster
>> requirements were moved to be resolved in a future specification.
>> reasoning was that making it a priority 3 requirement (since no
> projects
>> exist) would make it seem unvaluable (when it is critical for many
>> solutions) and encoding it as priority 1 would require something in
> the
>> community to use, when no real solutions currently exist.
>> If you are involved in solving this requirement or considering a
>> project, the PoC would be happy to track that information.  Please
>> me know and I'll get the information added to the tracking sheet.  At
>> this time, I know of no projects that are looking at this from an
>> application standpoint that are heading towards the requirements set
>> forth in the OSDL specs.
>> Thanks
>> -steve
>> Pan, Deng wrote:
>> >Checkpointing is the priority 1 requirement of CGL 2.0, but till
> I
>> >can not find any discussion neither in julie's PoC tracking sheet,
> nor
>> >in andy's CGL project list. Is there anybody looking into this
>> >requirement?
>> >
>> >-----Original Message-----
>> >From: Fleischer, Julie N
>> >Sent: 2003-06-17 7:54
>> >To: cgl_discussion at osdl.org
>> >Subject: [cgl_discussion] FYI - PoC Tracking Sheets updated
>> >
>> >Just thought you might like to know that I have updated the PoC
>> tracking
>> >sheet on the web with the best data I have so far.  The only area
> where
>> >there are blanks is in the "carryover, unchanged" requirements.
>> should be a simple port from Andy's spreadsheet when we get the time.
>> >
>> >The file names are:
>> >XLS format -
>> >http://www.osdl.org/docs/poc_cgl_20_priority_1_solutions.xls
>> >PDF format -
>> >http://www.osdl.org/docs/cgl_20_p1_project_list___pdf_format.pdf
>> format - attached
>> >
>> >- Julie
> Peter
> --
> Peter R. Badovinatz aka 'Wombat' -- IBM Linux Technology Center
> preferred: tabmowzo at us.ibm.com / alternate: wombat at us.ibm.com
> These are my opinions and absolutely not official opinions of IBM,
> _______________________________________________
> cgl_discussion mailing list
> cgl_discussion at lists.osdl.org
> http://lists.osdl.org/mailman/listinfo/cgl_discussion

More information about the cgl_discussion mailing list