> On May 29, 2014, 7: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

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.


- Mark


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22008/#review44255
-----------------------------------------------------------


On May 29, 2014, 12: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, 12: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
> 
>

Reply via email to