[Openais] Roadmap plans for v2.0 and v3.0
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
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
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