[Openais] Roadmap plans for v2.0 and v3.0

Steven Dake sdake at redhat.com
Sat Jun 12 13:09:07 PDT 2010

I have already posted about the roadmap plans for v2.0 (weaver's 
needle).  Most of that work is targeted around integrating our new 
technologies we have discussed on the mailing list and for which 
contributors have work in progress patches.  One project we will not be 
tackling in 2.0 is simplification of the code base.

In discussions with Angus Salkeld, We have decided to leave the code 
base for the infrastructure for 1.0/2.0 mostly untouched (except where 
bug fixing is needed).  We will add service engines and some other 
requested features to the code base which are hopefully surgical and do 
not disrupt the behaviour of corosync.

In 3.0 we will also introduce new features depending on where the 
community wants to put their work in.  One gap we have is a good way to 
share data around without using messages - Honza has shown some interest 
in that project and will be making progress towards a solution in the 
3.0 timeframe.

In version 3.0, we will continue our trend towards a more componentized 
architecture.  If you have had a look at 1.y.z, you will notice most 
components in the system have a component design to them already.  These 
include things like logsys, coroipc, hdb, poll, plug in loader, etc. 
Unfortunately in the mad dash to make the software work well, some of 
these internal interfaces or their implementations within are just 
bordering on or are too complex and need some rework.

The activity of reworking those infrastructure components will take 
place in the libqb project.  We will remove these infrastructure 
components from Corosync 3.0 and then depend on libqb for that 
functionality.  Corosync will then only act as a HA developer toolkit 
(providing its existing API set, service engines, and protocol). Angus 
has already made some great progress in simplifying the code base and 
reusing some common design elements.  One of these is the chunked ring 
buffer mechanism using shared memory.  This ring buffer is implemented 
currently separately in ipc and logsys.  Over time, Angus plans to 
separate out the ring buffer from these two systems.  The result?

Less lines of code
Individually unit-testable components that don't require a full cluster 
to run.
Focused performance tuning around one code base for one set of target 
Focused towards high performance client server application developers

The ring buffer concept is just one idea Angus has.  Angus has many 
other great ideas for simplification of the code base.  I invite you to 
join in his development especially if you are interested in some real 
cutting edge posix high performance systems programming.


Keep in mind this kind of effort is not going to happen overnight.  This 
is what some of the core corosync developers have discussed for the next 
2-3 years of development.  If there are gaps we have which are not 
addressed, please let us know.


More information about the Openais mailing list