> 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 > > Bill Farner wrote: > 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 Farner wrote: > Maxim, based on my above comment - what do you think about the second > option i posted previously?
Did you have a chance to validate that --provision-with would not work against a script? If so, I am fine with it as it's relatively close to the flagged approach (though a bit less convenient). - Maxim ----------------------------------------------------------- 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 > >
