felicity> What sorts of things are you looking to do? Our infrastructure is used for building and testing firefox (and probably soon thunderbird as well). We want to be able to re-image and deploy machines with various OSes wherever/whenever we need them. We build and test on Windows, Linux, OS X, and mobile (though I have no illusions that anything out there will support mobile).
felicity> Is there a reason you want to stick with physical hosts instead of felicity> going all virtual? The fact that we need to support OS X means that we can't go virtual for everything since it's against the EULA to run it on a VM. Right now a good portion of our infrastructure is on Mac Minis (which don't have any sort of IPMI solution, and have issues with the clock on linux whereby they sometimes need physical intervention). There is also some question about performance and the vm overhead being too much, so we might want to stick with physical for a number of things. We definitely do want to support some virtualization, though, and we're already using both vmware and ganeti for kvm (likely the way we'll move in the future) for various things. We're using deploy studio for the macs right now (possibly for windows as well). We're using puppet on linux and os x, and are looking at doing it on windows as well (though I think puppet support on windows is minimal at the moment). felicity> The hard part for dealing with physical machines is persistent data felicity> and automated configuration. The former is pretty tricky, but could felicity> be done w/ (pre/post)install scripts/the storage backend. The felicity> latter depends on what you're doing, but can probably be solved w/ a felicity> standard PXE install and some kind of config management (home-built, felicity> puppet, cfengine, etc,) to go from the standard install to a felicity> configured/running server. I think what might be likely is that we start with a standard OS install, apply a bunch of puppet rules, and then create a golden image from that. Each week as we make changes, we do them solely with puppet, and then roll those puppet changes back into the image at the end of the week. That way people can always create our environment given a base OS install and our puppet configs, but we can cut down on install time by using customage images. Think of it as the same sort of thing as incremental and full backups. :} _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
