[Gluster-infra] [Gluster-users] Anyone willing to help out with GlusterFS infrastructure?
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:
>> 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:
> 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
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/
2. Because it does, you could probably automate the build step using a
git hook 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.
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 to track them. It's better than copying directories and
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
More information about the Gluster-infra