aurora-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maxim Khutornenko" <ma...@apache.org>
Subject Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
Date Fri, 30 May 2014 21:56:40 GMT


> 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.
>

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


- 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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message