I think keeping a multi-machine setup for testing is important since it's much closer to actual deployment (and it'll catch a class of bugs that might not show up when everything's on localhost). Also as a technical note as far as I know you can't run more than one slave instance per VM when you're using the cgroups isolator (due to global kernel state) and the multi-slave test case is important as well.
I'd say shoot for a refactoring where you can have 2 setups, one single-VM low-footprint one for dev and one multi-VM high-footprint setup for e2e testing, aiming for a minimum of code duplication. On Tue, Apr 1, 2014 at 12:16 PM, Jake Farrell <jfarr...@apache.org> wrote: > Whats the end goal that we want to have with the vagrant image, easier > development and testing or as a sample setup for a small cluster. I think > that for simplicity keeping it all on one vm for development and initial > testing is the best approach and then perhaps for the end to end tests we > can use the same chef scripts with a multi-vm. > > -Jake > > > On Tue, Apr 1, 2014 at 3:06 PM, Bill Farner <wfar...@apache.org> wrote: > > > Should i take this a step further and use one machine for everything? I > > realize this is less 'pure', but purity doesn't help folks much if they > > need to buy a new computer to use it. > > > > -=Bill > > > > > > On Tue, Apr 1, 2014 at 9:06 AM, Jake Farrell <jfarr...@apache.org> > wrote: > > > >> +1, good call > >> > >> -Jake > >> > >> > >> On Tue, Apr 1, 2014 at 11:43 AM, Bill Farner <wfar...@apache.org> > wrote: > >> > >> > Does anybody have an issue with me combining the 'master' components > in > >> our > >> > vagrant configuration to one machine? Currently we have three > machines: > >> > zookeeper, scheduler, master. It should be straightforward to combine > >> > these into a single machine, at which point 'vagrant up' is much > faster > >> and > >> > can be run on a machine with less RAM. This is a part of my effort to > >> > improve the vagrant setup [1]. > >> > > >> > > >> > -=Bill > >> > > >> > > >> > [1] https://issues.apache.org/jira/browse/AURORA-299 > >> > > >> > > > > >