[Gluster-infra] [Gluster-users] Anyone willing to help out with GlusterFS infrastructure?

Michael DePaulo mikedep333 at gmail.com
Tue Oct 7 03:23:06 UTC 2014

On Mon, Oct 6, 2014 at 1:42 PM, Justin Clift <justin at gluster.org> wrote:
> On 06/10/2014, at 2:26 PM, Michael DePaulo wrote:
> <snip>
>> Understood. But how should duplicate content be handled? Should the
>> wiki have its getting started guide replaced with a link to the static
>> website's getting started guide?
> Yeah, that doesn't sound like a bad idea at all.  The general thought
> is that the static website should be the place for "more refined"
> documentation, with the wiki being for stuff that changes pretty often
> or is still under construction.
> There aren't any hard and fast rules yet, and the static website
> building process itself isn't great (needs to be worked through).
> Actually... probably the very greatest immediate need we have at the
> moment is to refine the static website building process here:
>   http://www.gluster.org/community/documentation/index.php/Building_Gluster_Website
> Because right now it's a real pita.  davemc (also on gluster-infra)
> has been fighting with it for a few days in order to add a new page.
> (if you can massively simplify the static website building process,
> davemc is likely to send you a case of beer. :>)
> Soumya Deb (CC'd) has been looking at the overall website info
> structure + direction, so probably has some good thoughts already on
> where we should take things.
> Side note - I'm off sick today (bad head cold), so about to crawl
> back into bed.  If you need accounts on the website staging and
> production server, Michael Scherer (misc) can create them for you. :)
> Regards and best wishes,
> Justin Clift

Hi guys,

So here are my ideas on improving the process.

I volunteer to implement them (after we discuss them.)

1. If the website did not require a build step (bundle exec middleman
build), you would put the git the git repo directly under
/var/www/html/ (staging.gluster.org) or /var/www/staging/
(www.gluster.org) .

2. Because it does, you could probably automate the build step using a
git hook[1] to call a (shell) script. We use git hooks on X2Go. So for
example, whenever some calls "git checkout <revision>" in a clone of
gluster-site.git under ~build/ , the build step (including the
installation to the aforementioned dirs) is performed. I think the
hook for this is "post-checkout".

3. If the build step needs to be done under a chroot because
www.gluster.org is not running CentOS 7, RHEL7 or F20, then there is
probably an easy way to do so with a script. On X2Go, we use mock to
build RPM packages inside a chroot.[2]

4. In the long run, there's probably a way to make it so that merely
pushing to certain branches on gluster-site.git on glusterforge
automatically updates the staging server or the production server. A
primitive way of doing so would be to have a cron job on
staging.gluster.org and www.gluster.org run git pull every 5 minutes.
And whenever git pull does pull a new version, that would in turn
would trigger a hook. I think the hook for this is "post-merge"

5. If building the built website is reproducible, there is no need to
backup prior builds.

6. If you really do want to backup prior builds, then use either git
or bup[3] to track them. It's better than copying directories and
tarballs around.

7. If you want to make sure people do not overwrite /var/www/html/ on
the production server, then change the permissions/ownership on that


[1] https://www.kernel.org/pub/software/scm/git/docs/githooks.html
[2] http://code.x2go.org/gitweb?p=buildscripts.git;a=blob;f=bin/build-rpm-package;h=c1efa6017b3e96fe388a808610528757b3ffd7fc;hb=HEAD
[3] https://github.com/apenwarr/bup

More information about the Gluster-infra mailing list