Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
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
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
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
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
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
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
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.
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.
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,
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
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,
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
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
Re: Review Request 22008: Exclude .git from rsync copy in vagrant.
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
