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

Angus Salkeld asalkeld at redhat.com
Mon Jun 14 05:30:15 PDT 2010


On Sat, Jun 12, 2010 at 01:09:07PM -0700, Steven Dake wrote:
> 
> 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 
> designs
> 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.
> 
> http://www.libqb.org
> 
Thanks Steve,

At the moment I am working on:

- Integrating my current ringbuffer implementation
  into the IPC code in order achieve asyncronous IPC (with flow control).

Next on my list is: (not in strict order)
- I want to do is to make the IPC API easier to use.
  The server side takes ~300 lines to setup. I want it
  easier to use.

- Implement atomic_get/set/incr functions.
  Use these instead of shared locks in the ringbuffer.
  Use these in the handle db instead of locks.

- Make sure the poll loop and IPC system can safely operate in other
  threading models (compared to corosync).

- Provide some integration (or at least examples) with glib and libevent.

- I have a corosync git tree that now uses libqb
  1) keep that working.
  2) possibly publish it so others can see how the integration is going.
  3) it would be good to setup a buildbot to run the cts tests on this.

- Write lots of unit test cases.

- Document all the public API (in doxygen comments)

- Put some work into the wiki.

- Get libqb into Fedora (and other distros) so corosync can migrate to it.

Hope to see more of you on the libqb mailing list: 
https://fedorahosted.org/mailman/listinfo/quarterback-devel

Post an email to the list if you want to get involved
(if you see anything above that interests you).

Regards
Angus

> 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.
> 
> Regards
> -steve
> _______________________________________________
> Openais mailing list
> Openais at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/openais


More information about the Openais mailing list