What follows is a list of some of the expected or perceived benefits of splitting ceilometer functionality into separate repos. For some of the original thinking on this topic see the etherpad used to plan the summit sessions¹.

Though listed as a separate items it is fair to say that each of these informs the others and the sum is greater than the parts, yadda yadda. I'm taking as writ that ceilometer has a stigma associated with it.

There's a list of things below but the single most important thing in any of these (and basically present throughout all the items in the list) is that splitting things into separate repos provide granularity: of access, of understanding, of composition. The functionality of ceilometer is most likely to be used and improved by actually interested people² when it has that granularity.

• Operator feedback indicates that a significant segment use functionality provided by ceilometer in a piecemeal fashion. That is, at least some of them pick and choose what is useful to them.

  That picking and choosing informs some of the boundaries that are being used to define where to split:

  • collecting data (samples/events) (pollsters/notifcation agents)
  • transforming data
  • storing data
  • dispatching data somewhere else
  • alarming via aggregate data
  • alarming via life data
  • using data for "chargeback" and "showback"

  Doing splits makes the different pieces more visible, selectable and capable of composition. It's well known by people with existing deep understanding of ceilometer that composition is possible but it is not something that is obvious. It needs to be in order for ceilometer's usefulness to reach all potential users.

• Different parts of ceilometer are more relevant than others but are perceived as being in a lump that is perceived as not great at what it does. Breaking things into pieces allows different parts to evolve, get attention and be analyzed separately.

  In some cases this might allow parts that are no longer relevant to usefully whither and die (from lack of attention) and in others it will highlight where important pieces need more attention but contributors are not aware.

• Ceilometer spent a lot of time and effort fulfilling the now apparently pointless TC gap-analysis. Much of that effort was not especially visible to watchers of the project, either end users or potential contributors.

  Splitting the repos and giving things new names is a visible signal that ceilometer is actively taking steps to make itself useful to a broader audience. This reinvigorates existing contributors and has the potential to attract more.

  It also effectively forces an audit of the code on master. In a gerrit driven environment this doesn't happen as much as it should.

• A small piece of the pie may be attractive or useful to someone, for example the polling agents. If these are made to be independent tools that can be used with other systems (e.g. StackTach) then some of the special knowledge with ceilometer contains (e.g. how to poll all this stuff) can be used and contributed to without the stigma associated with the project at large.

• Smaller pieces are easier to test, document and maintain. It is also easier to reify strong API or other surface layer contracts when the purpose of a piece is constrained.

  Smaller pieces with small numbers of responsibilities are easier to compose. Single Responsibility Principle applies in services as much as it does in OO.

There are clear risks associated with these kinds of changes and project will need to make and maintain plans to manage that. Splitting up repos:

• can harm discoverability
• can incur costs and confusion in product packaging and deployment
• could be done on the wrong boundaries and require clean up later
• is so exciting that it is easy to bite off more than we can chew

(I had more to say, but then meeting time started, and that's three hours straight for IRC meetings so I reckon this is enough to get the ball rolling. Feel free to respond with requests for clarifications, additions, etc.)