> On May 29, 2014, 11:58 a.m., Mark Chu-Carroll wrote: > > Why? > > > > Right now, I do a lot of debugging of the client using vagrant. My typical > > workflow is: > > - Make the change in my git workspace. > > - Commit it to a branch. > > - vagrant ssh into the virtual cluster > > - git pull /vagrant mybranch > > - build client > > - test > > > > If we eliminate that .git file, then the aurora copy in the vagrant host > > can no longer be used for pulls. We can't just use the /vagrant copy, > > because that's got a ton of state. > > > > With this change, to do a similar dev workflow, I'd need to create a git > > workspace cloned from /vagrant, and also add new stuff to copy the > > resulting aurora/aurora2 pexes into the original /vagrant copy. It makes > > the workflow more complicated, and I'm not clear on what benefits it > > produces in exchange. > > > > > > > > > > Bill Farner wrote: > The workflow would be slightly different than you describe. To update > builds in the VM, you would run "vagrant provision", and rsync will pick up > the changes. Does that sound reasonable? > > Mark Chu-Carroll wrote: > It's a *lot* slower. Trying it out with a simple change in the client, > the round-trip time for a change using git is under five seconds, for git > commit, git pull, and pants to build the client. > > Running vagrant provision took one minute and 20 seconds for an > equivalent process. > > It's just a minute - but between the different things I'm working on, I > literally did that more than 20 times today. > > It's a very significant increase in time, for an uncertain benefit. What > do we gain by eliminating that .git from the provisioned copy of the > workspace? If we're really getting something out of eliminating the git > metadata from the provisioned vagrant image, then it might be worth the > price. But if not, then why are we making work harder? > > > > > Bill Farner wrote: > > It's a *lot* slower. Trying it out with a simple change in the client, > the round-trip time for a change using git is under five seconds, for git > commit, git pull, and pants to build the client. > > Yup, it's bound to be slower as-is given that there are more builds > taking place. Looks like the only way to pass arguments to the provisioner > script is via environment variables. How would you feel about that to let > you rebuild only specific components? > > > If we're really getting something out of eliminating the git metadata > from the provisioned vagrant image, then it might be worth the price. > > My intent is to standardize on the workflow within the vagrant > environment, leaning on vagrant to hide details of copying code and building. > > > > Mark Chu-Carroll wrote: > Seems like a giant kludge to work around something that isn't a problem. > > We've got a clean workflow that's fast, easy, and does a good job. Why > not just document it, instead of trying to retrofit vagrant provisioning into > doing something that it wasn't meant to do? > > If you really dislike using git for this, why not just write a companion > script that does the rsync, instead of kludging the provisioner? > > > Bill Farner wrote: > Ah, yes - i did think about pushing the rsync command into a script in > the default PATH, i'm fine with that. > > My goal is not to eradicate git, but to simplify use of the vagrant > environment. For example, Maxim and David tend to favor ./gradlew run > partially because it's one command. Meanwhile i'd like to remove ./gradlew > run for a few reasons. I see 'vagrant provision' as the possible replacement > for that command. > > I'm happy to proceed with setting up a command that does the code sync, > but i'll be looking for more than that to get to a single command. > > Mark Chu-Carroll wrote: > I'm good with getting to a single command, so long as it isn't a big step > backwards for my productivity. I'm happy to help however I can - just let me > know what you need. > > > Bill Farner wrote: > I see two workable routes, do either of these sound usable? Do any other > approaches come to mind? > > - The environment variable approach. Upside is that this makes "vagrant > provision" the uniform interface. > > # Piecemeal rebuild > COMPONENTS='scheduler,observer' vagrant provision > > # Rebuild everything > vagrant provision > > > - A build script for each component, installed during provisioning. > Downside is that piecemeal and full build approaches are very different. > > # Piecemeal rebuild > vagrant ssh -c 'rebuild client,scheduler' > > # Rebuild everything > vagrant provision > > Mark Chu-Carroll wrote: > I strongly prefer the latter approach. My experience with using > environment variables for this kind of thing is awful - every time I've done > it, I've lived to regret it. > > > Maxim Khutornenko wrote: > How about a set of component specific provisioning scripts? That would > let us do something like "vagrant provision --provision-with client". More > here: http://docs.vagrantup.com/v2/cli/provision.html
I looked into this while researching options, and as far as i can tell the --provision-with argument operates on provisioner type (e.g. shell, chef). If that's true, we would need to do something like extend the shell provisioner for the sake of gaining custom types. This is mostly speculation on my part due to ignorance to vagrant and ruby, but it seems like more trouble than it's worth. - Bill ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22008/#review44255 ----------------------------------------------------------- On May 29, 2014, 4:43 a.m., Bill Farner wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/22008/ > ----------------------------------------------------------- > > (Updated May 29, 2014, 4:43 a.m.) > > > Review request for Aurora and Mark Chu-Carroll. > > > Repository: aurora > > > Description > ------- > > Exclude .git from rsync copy in vagrant. > > > Diffs > ----- > > examples/vagrant/provision-dev-cluster.sh > ce936c19a42f4968d4706e6ef38c25db01ae2c5d > > Diff: https://reviews.apache.org/r/22008/diff/ > > > Testing > ------- > > vagrant up > > > Thanks, > > Bill Farner > >
