You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@aurora.apache.org by Bill Farner <wf...@apache.org> on 2014/05/29 06:43:37 UTC
Review Request 22008: Exclude .git from rsync copy in vagrant.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22008/
-----------------------------------------------------------
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
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
Posted by Bill Farner <wf...@apache.org>.
> 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
>
>
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
Posted by Bill Farner <wf...@apache.org>.
> 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.
>
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
- 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
>
>
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
Posted by Mark Chu-Carroll <mc...@twopensource.com>.
> 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
>
>
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
Posted by Bill Farner <wf...@apache.org>.
> 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?
>
> Maxim Khutornenko wrote:
> 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).
As far as i can tell, that is true - --provision-with is described in your link above. Interested to hear if you found differently.
- 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
>
>
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
Posted by Maxim Khutornenko <ma...@apache.org>.
> 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
>
>
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
Posted by Mark Chu-Carroll <mc...@twopensource.com>.
> 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?
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?
- 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
>
>
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
Posted by Bill Farner <wf...@apache.org>.
> 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.
Maxim, based on my above comment - what do you think about the second option i posted previously?
- 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
>
>
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
Posted by Bill Farner <wf...@apache.org>.
> 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?
>
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.
- 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
>
>
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
Posted by Mark Chu-Carroll <mc...@twopensource.com>.
> 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.
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.
- 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
>
>
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
Posted by Maxim Khutornenko <ma...@apache.org>.
> 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
>
>
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
Posted by Bill Farner <wf...@apache.org>.
> 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?
>
>
>
> 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.
- 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
>
>
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
Posted by Bill Farner <wf...@apache.org>.
> 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.
> >
> >
> >
> >
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?
- 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
>
>
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
Posted by Mark Chu-Carroll <mc...@twopensource.com>.
> 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.
>
>
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?
- 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
>
>
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
Posted by Mark Chu-Carroll <mc...@twopensource.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22008/#review44255
-----------------------------------------------------------
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.
- Mark Chu-Carroll
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
>
>