[Gluster-infra] configuration management for the gluster infra, RFC

Benjamin Turner bennyturns at gmail.com
Tue Aug 19 17:24:05 UTC 2014


I have automated just about anything you can think of WRT deploying gluster
in shell script and python, I haven't had a chance to port any of it to a
tool though.  I don't have an opinion one way or another which tool you
want to use but I would be happy to learn whatever is chosen and help out
this.  My deployment scripts that I currently use to deploy / configure
gluster would probably be a good starting point, at least we can pull the
list of what needs to be done and the shell commands to do it.  Here is
what I do for every automated RHS deployment(if applicable, its all
configurable), maybe this is a good starting point:

-setup samba
-configure 10G NW and tuning
-run env setup server && clients
-set tuning
-peer probe
-volume create
-volume start
-enable volume quota
-set volume options
-mount clients

Here is a snip of env setup servers as I think this will have most of what
we need to pull from:

    # pvcreate and create a list of disks
    disk_list=""
    for disk in $(egrep -v '(name|vda|sda|dm|^$)' /proc/partitions | awk \
    '{print $4}'); do
        pvcreate --dataalignment $dataalign -ff -y /dev/$disk
        disk_list="$disk_list /dev/$disk"
    done

Here I assume that sda or vda are going to have the root fs and create PVs
for bricks with whatever is left, and align them properly for a 256k stripe
sized RAID.  I assume we would want to do something similar in the
puppet/ansible/chef/whatever module?

-b


On Tue, Aug 19, 2014 at 12:29 PM, Michael Scherer <mscherer at redhat.com>
wrote:

> Hi,
>
> I have been wondering about using a configuration management system to
> manage as much as possible on the infra side. The latest start of a
> discussion on backup showed that we do not really have a clear idea of
> what is installed, and that we would still need to do thing manually to
> install the backup system, which is a error prone process, and a bit
> slower ( at least for me, I do not type as fast as a script can react ).
>
> Justin also pointed to me the documentation he wrote for installing
> jenkins, most of it that could be properly automated
> ( http://www.gluster.org/community/documentation/index.php/Jenkins_setup
> ).
>
> So we have been quickly exchanging a couple of mail on using something
> to automate things, but that's not something that should be decided or
> discussed in private, so here we are, we should discuss this publically.
>
>
> First, the main question is to know if people here are familiar with
> such systems. I already deployed in the past everything just to find out
> that I was the only one to know it, which kinda reduced the bus factor
> to 1 and blocked others into doing system administration, and putting
> myself in the position of a bottleneck. Even if I was efficient, I was
> still blocking stuff.
>
> I am not sure if people on this list know the ideas and the concepts
> ( even on a very high level point of view ), but since not everybody is
> sysadmin, so if it sound like a foreign language, do not hesitate to
> ask, i will be happy to clarify :)
>
> The idea is to use a system ( puppet, ansible, chef, etc ) to describe
> the infrastructure in a high level way, and have the system do what is
> needed to have it conform to the specification. Since that's done using
> text file, that's VCS friendly, and permit to use the regular advantage
> of source code ( ie, audit by logging, review, etc ). This also permit
> to duplicate the configuration quite easily if done well, which permit
> to test upgrade or anything. And of course, since that's automated,
> there is no way that a human forget a step. There is various possible
> architecture ( client/server, without or with agent, etc ), and we can
> have the infrastructure being partially managed and still do thing
> manually.
>
> Then once we answered this question "does it rin a bell to most people
> and would it be useful" ), the next step will be to decide the
> architecture to manage everything, which is usually constrained by the
> software we want to use. I usually try to side step this question by
> asking others questions such as :
> - what are the needs ( ie, purely configuration or should we expect
> orchestration of one off task on a regular basis )
> - do we have contraints, and what are they ? ( like "we need to manage
> hurd system", or "we will add windows system in the future" )
> - is there people familiar with a existing system, and wanting to help.
>
> So, in term of needs, I see several things :
> - managing the infra. That mean making sure the configuration is
> consistent, but also deploy new systems and make sure they are correct
> ( ie selinux, proper ssh keys, etc ).
> - running some specific tasks on a regular basis. For example, upgrade,
> etc. So far, besides upgrades ( and that can be done by cron ), i do not
> see much repeated tasks, but maybe I am wrong.
>
> Then once we have this, we can make proposals, see if something is
> missing and iterate on it. And deploy, converting stuff as we go, and
> using the system for new stuff..
>
> On term of constraints, I suppose that we need something that work on
> RHEL and Netbsd. I assume sooner or later, we may add different builders
> on debian, or differents arch. I do remember seeing something about osx,
> but that's likely not much different than netbsd in term of tools ( even
> if I expect netbsd to have more, but from a portage point of view, both
> are less problematic than windows ). I do not see much more, I would
> strongly express a preference for something packaged on both platform.
>
> And in term of who know what, well, I can only answer for me, that I
> know ansible and puppet quite well, but I am open to others systems.
>
> So, any comments ?
> --
> Michael Scherer
> Open Source and Standards, Sysadmin
>
> _______________________________________________
> Gluster-infra mailing list
> Gluster-infra at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-infra
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-infra/attachments/20140819/72e012fe/attachment.html>


More information about the Gluster-infra mailing list