From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Psxad-0005o3-Rq for garchives@archives.gentoo.org; Fri, 25 Feb 2011 13:20:12 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6F2031C030 for ; Fri, 25 Feb 2011 13:20:11 +0000 (UTC) Received: from mail1.deploylinux.net (mail1.deploylinux.net [209.216.192.150]) by pigeon.gentoo.org (Postfix) with ESMTP id 264091C001; Fri, 25 Feb 2011 12:31:25 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail1.deploylinux.net (Postfix) with ESMTP id C03AF26CFFC; Fri, 25 Feb 2011 04:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at deploylinux.net Received: from mail1.deploylinux.net ([127.0.0.1]) by localhost (mail1.deploylinux.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhqUqYt2+2dX; Fri, 25 Feb 2011 04:31:23 -0800 (PST) Received: from hyperion.deploylinux.net (hyperion.deploylinux.net [66.93.35.200]) by mail1.deploylinux.net (Postfix) with ESMTPSA id 7B14726CFEC; Fri, 25 Feb 2011 04:31:23 -0800 (PST) From: Matthew Marlowe Organization: DeployLinux Consulting, Inc To: Ed W Subject: [gentoo-dev] Community Development of Gentoo Server Mgmt Tools for VMware Clusters/etc - Puppet modules, github collaboration, etc - Fork of Dev Topic: Avoiding Urgent Stabilizations Date: Fri, 25 Feb 2011 04:31:21 -0800 User-Agent: KMail/1.13.5 (Linux/2.6.36-gentoo-r7a; KDE/4.4.5; x86_64; ; ) Cc: gentoo-dev@lists.gentoo.org, gentoo-server@lists.gentoo.org References: <4D501BA4.6040802@gentoo.org> <201102250308.21246.matt@deploylinux.net> <4D679480.2000508@wildgooses.com> In-Reply-To: <4D679480.2000508@wildgooses.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102250431.22020.matt@deploylinux.net> X-Archives-Salt: X-Archives-Hash: 86ab7ba8cd1ac8cd407ea3fcf781c501 Reader note -- Direct all respones to gentoo-server ML to avoid flooding gentoo-dev. For those on server-ml who missed dev-ml: I'm starting to put together a portage/stable server configuration for a large number of gentoo VM's that will eventually be hosted on a VMware ESX 4.1U1 cluster - with the goal of limiting major changes to once/year and otherwise only applying security/minimum necessary updates. I doubt it will be easy but I'm doing my best at it :) As part of that I'm maintaining on github several related repositories, including portage mask/use/config files, cluster management utilities, etc. https://github.com/deploylinux I've also started to document work on my blog: http://www.deploylinux.net/matt I'm not currently planning to utilize a separate overlay for packages/ebuilds, but it's not out of the question. I'd be happy to work with any other devs or users w/ similiar interests or production networks to manage.....github makes group development relatively easy. On Friday, February 25, 2011 03:37:36 am Ed W wrote: > I maintain a, likely much smaller, number of VMs using linux vservers. > The approach here is to almost cut each machine down to a chroot that > runs only one (or thereabouts) interesting service. To do this I have > found customised portage profiles to be the under-plugged secret since > they allow you to basically push a set of packages which should be > installed and control "per type of vm" use flags and package keywords > (eg I have www-nginx, www-apache, mail, proxy, mysql, ftp, etc > profiles). Additionally I have a small overlay of local ebuilds that > sit in the same tree > I'd rather not maintain a separate profile for each server/node type. Instead it would seem to be easier to use to a buildhost to create a combined repository of packages, and then use puppet to define nodetypes and tell each individual node which packages to install, which users to create, and which services to enable. > Up until now I haven't really made any effort to sync this whole tree > across multiple physical machines and it's a bit of an ad-hoc process. > Using something like git would probably be perfect > Agreed -- git *is* perfect and widely used in enterprise configuration management repositories. The main advantage is that it allows individual users to maintain their own forks, and yet merge contributions from other trees or to request that other repositories merge their changes w/o much effort. Github makes this even easier w/ a web interface, tools to visual changes and track contributions, and discussions/wiki's for each repository. > The still missing step is configuration management across the machine > types, eg I want to upgrade all my "Apache-WWW" class machines and merge > in all changes in /etc in a certain way... At the moment I just run > dispatch-conf across all machines, but it can be quite boring merging 20 > instances of sshd.conf... Seems like Puppet/Chef could be a solution > here, but the step up and investment to make it work seems pretty large? > Yes, I'm currently planning that puppet will control installation of new packages and pushing all configuration files. This works very well w/ RedHat Enterprise Linux/etc and if we are careful should also work for gentoo-- For updates, we may have to either extend puppet to be aware of revdep-rebuild and gentoo package versioning better, or have an external script for updating the relevant nodes after the buildhost has finished compiling them. > > > It does appear like managing large numbers of virtual machines is one > are that gentoo could score very well? Interested to see any chatter on > how others solve this problem, or any general advocacy? Probably we > should start a new thread though... > Agreed - With careful management, the time investment in QA and package management/maintenance should be more than outweighed by the benefits for reasonably sized server clusters. It would be even easier if we can have gentoo server admins work together to help build puppet modules and general mgmt utilities using a service like github. > Regards > > Ed W Matt -- Matthew Marlowe / 858-400-7430 / DeployLinux Consulting, Inc Professional Linux Hosting and Systems Administration Services www.deploylinux.net * matt@deploylinux.net 'MattM' @ irc.freenode.net