How best to integrate dmClock QoS library into ceph codebase

From: "J. Eric Ivancich" <ivancich@redhat.com>
To: ceph-devel@vger.kernel.org
Subject: How best to integrate dmClock QoS library into ceph codebase
Date: Tue, 4 Apr 2017 09:32:35 -0400	[thread overview]
Message-ID: <6D8EA95A-572E-4C71-A6AF-6BB8A6E8B26C@redhat.com> (raw)

In our work to improve QoS with ceph, we implemented the dmClock algorithm (see: https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Gulati.pdf).

The algorithm is implemented as a general library that could be used in ceph and in other projects unrelated to ceph. To do this the dmClock library code makes use of C++ templates. On the server side, the key class takes template parameters to describe the type of a request and the type of a client identifier. On the client side, the key class takes a template parameter for the type of a server identifier.

You can find the library here:

   https://github.com/ceph/dmclock

The question is how best to integrate this library with ceph code in our git repo into the future.

There are three obvious options:

   1. Keep dmClock as a separate repo and incorporate it into ceph as a git submodule.
   2. Keep dmClock as a separate repo and incorporate it into ceph as a git subtree.
   3. Move the code into the ceph tree and stop maintaining as a generalized library.

Both git submodules and git subtrees have their own set of challenges; neither is perfect. Many have weighed in their relative advantages and disadvantages (https://www.google.com/search?q=git+submodule+subtree).

I’m inclined to keep it separate (option 1 or 2) so that others might use it in other projects.

When I started the integration, Sam recommended that it be maintained as a subtree. So that’s how it’s implemented in my not-yet-merged branch. The key challenges have been with rebases that include the commit in which the subtree was added and with pushing code changes back to the library. Since relatively few would likely be doing these types of ops, perhaps option 2 might be easiest. Currently our git PR process has an automated check for "Unmodifed Submodules". I’m guessing we’d likely want a similar check for changes in subtree code.

An argument for making it a submodule is that ceph already uses submodules and ceph developers are familiar with working with (and around) them.

But perhaps others would like to weigh in.

Thanks,

Eric