[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Rdo-list] Puppet glusterers unite



Greetings,

For those of you in the To: line, I believe you are all doing something
with gluster and puppet at the moment.  For anyone else on rdo-list that
might be interested, jump in :)

Primarily I want to get everyone talking to make sure we don't step on
each other's toes.  I know James has done some great work with the
puppet-gluster module, and Gilles is currently working to switch off of
the now-deprecated puppet-openstack-storage module and onto
puppet-gluster.  Crag, Jiří, and myself are working gluster-related
bugs.  So let's keep in touch.

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.

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.
However I'm concerned with the other places we were previously using
gluster::client.  Can we use the new gluster::mount define to replace
all of these instances?  Or are we going to need to refactor in those
places as well?  I'd like to have some idea where this is all going
before I start ripping it apart.

Thoughts?

-John



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]