10:45 a.m.
James Shubin <jshubin(a)redhat.com> writes:
On Tue, 2014-04-08 at 17:42 -0400, John Eckersberg wrote:
> I'm working to configure libgfapi support on nova compute nodes. In the
> old gluster module, there was a gluster::client class that just
> installed the required glusterfs-fuse package. This class is used by
> astapor in a few places (compute/cinder/glance). However there's no
> gluster::client class in the new module, so we'll need to remedy that
> somehow.
I think you've got the right idea in the next paragraph. I'll add some
more info...
>
> There is a class, gluster::mount::base, that ensures the packages are
> installed, and that class is used by each instance of gluster::mount.
> I'd like to reuse some of this, but I don't think we need all of it on
> the compute nodes (really we just need to install glusterfs-api). The
> simple way would be to create a new class glusterfs::apiclient that just
> installs the package, and include that for the nova compute case.
Can you detail what functionality is missing and needed? Please make
sure to state if this is relevant to upstream (GlusterFS) or just
downstream (RHS/RHEL OSP, etc...) Is it just to install one package or
is there anything else?
Focusing just on this bit for now...
Libvirt supports using gluster as a storage backend. It does this by
calling libgfapi to interface with gluster directly. There is no fuse
layer or filesystem mounts needed.
If nova is configured with qemu_allowed_storage_backend=gluster, then it
will generate the necessary libvirt xml to make this happen magically at
launch time. The only prerequisite is for libgfapi to be available on
the compute nodes (and for libvirt to have been build with gluster
support enabled). The glusterfs-api package is what provides the
required library.
So, I just need a class to include which provides installation of the
glusterfs-api package. I was going to just add it as a normal package
resource on my end, but I'm guessing this is something other folks might
want to take advantage of, and the puppet-gluster module seems like the
correct place to put it. It's not particular to the downstream case;
anyone who might want to use libgfapi as a client would want a canonical
way to set it up.
I'll submit a pull request with a new glusterfs::apiclient class that
does nothing else but install the glusterfs-api package, and we can work
from there. Let me know if you'd prefer another name. Maybe something
like gluster::client::api, if you anticipate having other stuff under a
gluster::client namespace?
John