RADOS object class development activity

The object interface in RADOS can be customized using a feature called object classes. Object classes can be authored in C++, or dynamically injected using Lua scripts attached to each request, loaded from a file system, or managed by Ceph. This post takes a quick look at how much this facility is used.

When object interfaces change, the interface to data changes and must be managed carefully to avoid losing access to data or degrading performance. If a few, simple interfaces exist then management may be trivial. However, if we examine the growth of the use of custom object interface in Ceph we see a trend towards non-trivial sets of interfaces. This is a big departure from relying on only standardized interfaces.

The following graph plots the number of object classes (a group of interfaces), and the total number of methods (the actual API end-points). Plotted from 2010, growth has been accelerating.

Management of interfaces is only one part of the story. Major interface development in Ceph typically occurs between version releases, so deployments see feature changes followed by bug fixes. However, with the ability for applications to dynamically change the set of interfaces, frequent changes and experimentation may be a new mode of development. Using the development history of object classes as a proxy for incremental interface changes we see that dynamic interface development will need to support a high frequency of interface churn, as can be seen in the following graph showing source code changes over time. Each dot represents a commit with the corresponding number of lines of code changed.

Clearly development is spread out over time with clumps of development presumably corresponding to release cycles. A system that encourages incremental change would be a valuable feature allowing experimentation, but there are many open questions related to this such as QoS, data and interface migration, isolation, and security.