Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change default Vagrant synced folder to "/vagrant". #34

Merged
merged 1 commit into from
Jul 28, 2016

Conversation

tjanez
Copy link
Contributor

@tjanez tjanez commented Dec 14, 2015

This is the expected default for Vagrant boxes:
https://docs.vagrantup.com/v2/synced-folders/

Note that the current default synced folder location caused confusion for many people (including me): hashicorp/vagrant#6154.

@LalatenduMohanty
Copy link
Contributor

LGTM

@tjanez
Copy link
Contributor Author

tjanez commented Dec 14, 2015

Is it possible to test this change by triggering a scratch koji build?

@kbsingh
Copy link
Collaborator

kbsingh commented Dec 17, 2015

is this going to cause any breakage for folks who have currently deployed centos box's and do an update

@tjanez
Copy link
Contributor Author

tjanez commented Mar 18, 2016

@kbsingh, sorry for the late reply.

Yes, it would cause breakage for people who rely on /home/vagrant/sync in their Vagrant provisioning scripts.
They would have two options:

  1. Add the following snippet to Vagrantfile to restore the previous behaviour:

    config.vm.synced_folder ".", "/home/vagrant/sync"

    One could even have both, /vagrant and /home/vagrant/sync, enabled at the same time. I don't know if that would cause any performance penalty though.

  2. Update their provisioning scripts to use /vagrant in place of /home/vagrant/rsync.

My rationale for this change is that the whole Vagrant eco-system is way bigger that the number of current Vagrant CentOS box users who rely on /home/vagrant/sync directory.

Thus this change would make CentOS with Vagrant experience a bit better by using Vagrant's default synced folder location.

If we go for option 1., I can add a note to the README.

@ascotan
Copy link

ascotan commented Mar 24, 2016

I ran into this today trying to use the centos/7 box. The local ansible provisioner uses the default /vagrant path, making this box unusable for ansible provisioning.

Requirements:
The playbook.yml file is stored in your Vagrant's project home directory.
The default shared directory is enabled (. → /vagrant).

@davidlt
Copy link

davidlt commented Apr 4, 2016

I hit this all on centos/7. The expectance was /vagrant, not /home/vagrant/sync director synced via rsync at boot time.

+1 for bringing expected behaviour, i.e. /vagrant.

@tjanez tjanez force-pushed the change_default_sync_folder branch from 6e6001c to 13d2208 Compare May 6, 2016 21:36
@tjanez
Copy link
Contributor Author

tjanez commented May 6, 2016

I've rebased the PR. @kbsingh, what's you opinion on this?

@R-Gerard
Copy link

+1

@tjanez
Copy link
Contributor Author

tjanez commented Jun 10, 2016

@kbsingh, ping?

@tjanez
Copy link
Contributor Author

tjanez commented Jun 20, 2016

An update regarding this issue from the blog post about the updated Vagrant images on the official CentOS blog:

The Vagrant sync folder is /home/vagrant/sync instead of /vagrant (which is the Vagrant default). The plan is to create link between the two locations in the next release, and only leave /vagrant in place in the release after the next.

@lpancescu
Copy link
Contributor

@tjanez Thanks for the patch! This is exactly what I wanted to add for the next iteration of our Vagrant images, probably skipping the transitional release linking the two locations (I was just preparing to implement this myself when I found your existing PR).

@tjanez
Copy link
Contributor Author

tjanez commented Jun 24, 2016

@lpancescu, no problem, I'm glad this issue will get resolved soon!

@kbsingh
Copy link
Collaborator

kbsingh commented Jul 28, 2016

lets do it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants