IMHO, optimizing for development makes the most sense (of course, i have the biased perspective of a developer). As more formal installation routines are crafted, it will make a lot of sense to use these directly within the development environment (e.g. generate deb packages, install them in the vagrant machine). I lean heavily in the direction of minimizing the requirements for vagrant up.
-=Bill 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 >>> > >>> >> >> >
