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