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

[Michael Scherer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://www.gluster.org/pipermail/gluster-infra/attachments/20140819/a02f009e/attachment.sig>