The bulk of the Ceph packaging is server side only. The main component which creates the client dependencies is the librbd package, which can be held in other repos alongside specific versions of Xen, Qemu, KVM etc. With the RHEL-OSP/RHEV3.3-based code for qemu, there is explicit dynamic loading of the library too so it doesn't need to be at build time either so that might give more flexible around cloud repo code.

Neil


On Tue, Feb 4, 2014 at 1:00 AM, Karanbir Singh <mail-lists@karan.org> wrote:
Hi Patrick,

On 02/03/2014 02:31 PM, Patrick McGarry wrote:
> Just wanted to check on this and see if anyone had thoughts on the
> formation of a storage SIG?  I'm also usually idling on freenode (and
> in #centos) as 'scuttlemonkey' if someone would like to discuss this
> further.  Thanks.

What we need to do is get the proposal stuff done, in front of the board
for the approval and then start working to import content.

I know that ceph easily seperates the cluster end from the client side,
it might then be easier to consider one part of the equation before the
other ?

At fosdem, I did manange to have a series of conversations with people
around the idea of shared code across SIG's ( the sort of thing we might
need to look into for the qemu config changes needed to make ceph work
in the client side ), and its going to be a harder problem to solve.

How are you placed to consider the storage and client sides of ceph as
independant components ?

Finally, I presume you are stepping up to the Storage SIG representative :)

- KB

--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel