>  If you don't want to use Puppet or Chef, you can just configure an instance 
> by hand (by SSHing into it, usually) and regenerate a Vagrant box from the 
> result.

Actually, even if you do want to use Puppet, a VM can be useful.  I have a 
local VM (not Vagrant) set up that I use to test new puppet manifests.  I'm 
using our operations/puppet production branch directly.  As is, it wasn't 
completely straightforward to set this up with the way our puppet repository is 
now, but it is possible.  Labs is good for final testing of manifests, but it 
is hard to use it to test changes as you make them.

So ummmm, yeahhhhhh!  This could be good for (some) ops people too.



On Oct 16, 2012, at 6:24 AM, Ori Livneh <[email protected]> wrote:

> 
> 
> On Monday, October 15, 2012 at 10:28 PM, Andrew Bogott wrote:
>> Does a single-instance install provide a sufficient test platform for 
>> 80% of the likely patches, or does all of the interesting stuff require 
>> a full-blown cluster?
> 
> I don't want to guess percentages, but a significant amount of development 
> work -- especially front-end -- can be adequately tested on a VM. 
>> If single-system servers are truly useful in most cases, then a 
>> prepackaged VM image seems straightforward and handy. Presuming that 
>> the devs are willing/able to run a few git commands before they start 
>> coding, we could potentially leave puppet and Vagrant out of the 
>> equation and just build a one-off image by hand and include strict 
>> instructions to fetch and rebase immediately after opening. It looks 
>> like that's roughly what Mozilla is doing at the moment.
> 
> Vagrant is a means for doing precisely that. If you don't want to use Puppet 
> or Chef, you can just configure an instance by hand (by SSHing into it, 
> usually) and regenerate a Vagrant box from the result. Vagrant can set up 
> shared folders between the host and guest VM, so what we might want to do is 
> simply tell Vagrant to mount its project directory on the host machine as 
> /srv/mediawiki (or whatever) in the guest VM, and have apache serve that. 
> That makes it very easy to track head in git: you keep a clone of the 
> repository up-to-date on your local disk, and leave it for the VM to serve 
> it. That would spare people the trouble of having to set up a LAMP stack. 
> 
> Is anyone interested in taking this on? I've done it before and found it 
> useful, so I'd be happy to provide some assistance. Otherwise I'll work on it 
> myself when I get the chance.
> 
> 
> --
> Ori Livneh
> [email protected]
> 
> 
> 
> 
> _______________________________________________
> Wikitech-l mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to