Disable the synchronisation of /vagrant

[hferentschik]

Currently the box Vagrantfile contains:

Vagrant.configure("2") do |config|
  config.vm.base_mac = "52540013d96e"
 config.vm.synced_folder ".", "/vagrant", type: "rsync"
end

where the sync type for /vagrant is explicitly set to rsync. This is potentially a problem on Windows where rsync might not be available. Also the user might prefer to install vbguest additions. Even with vbguest additions installed he still would be forced to use rsync though.

That said, I am wondering how much sense it makes to this type of sync anyways. The directory containing the Vagrantfile is most likely irrelevant for the user. There is no need to sync it at all.

Also, we are investigating options (sshfs or vbguest additons) to mount the whole user directory into the VM (to allow Docker file mounting). In this case it becomes even less relevant to sync the Vagrant working directory to the VM.

Why do we not just disable the sync:

config.vm.synced_folder '.', '/vagrant', disabled: true

It gives the user more flexibility regarding the sync options and it also makes setup on Windows easier.

Thoughts?

[hferentschik]

Could we add label focus:devex as well, please.

[bexelbie]

@hferentschik My understanding is that once we have an alternative file sync in place this will be disabled. Until then we need something.

[LalatenduMohanty]

@hferentschik Agree. I have sent a PR to disable it for Virtualbox (was thinking of Windows + Virtualbox) redhat-imaging/imagefactory#367

For others, rsync makes sense. However the settings in Vagrantfile ( which the user uses e.g. the one created by vagrant init ) takes precedence, so have not disabled them by default. Let me know if you differ.

[hferentschik]

But it is not needed. At least not for syncing /vagrant. Why would we like to sync this directory?

[LalatenduMohanty]

@hferentschik @bexelbie Also the issue should live in https://github.com/redhat-imaging/imagefactory

[hferentschik]

@hferentschik Agree. I have sent a PR to disable it for Virtualbox redhat-imaging/imagefactory#367

nice. Need to be verified on Windows. My guess is that it was only added in the first place, since Vagrant tries to use vbguest additions as default on Windows otherwise. With completely disabling it, it should not be an problem though.

For others, rsync makes sense.

Sure. Vagrant also tries to find the best approach for syncing depending on OS.

[LalatenduMohanty]

I had raised an issue on this redhat-imaging/imagefactory#366

[LalatenduMohanty]

Need to be verified on Windows.

@hferentschik I had tried in on windows, the vagrant up command out put says sync is done , but nothing happens.

since Vagrant tries to use vbguest additions

We can disable checking for vbox guest checking in the Vagrantfile (the default on inside the .box file) if we want.

[rct]

A historical note. IIRC, rsync was added because if there was a sync'd folder and the sync'ing type wasn't specified, on some *nix hosts, vagrant would pick NFS. If NFS wasn't setup correctly or firewalled you'd get hangs that were hard to resolve.

[rct]

FYI - This needs some careful consideration that is tightly coupled to the documentation.

if you try to sync the User's home directory (including Windows c:\Users\me), there can be a number of unintended consequences:

1. If it falls back to rsync, do you really want to copy the user's whole directory into the vagrant box? It will likely be fairly large for a regular, non test user, who might have VM images, etc.
2. If the user's home directory isn't read-only inside the box, the user needs to be aware that not everthing in the box is volatile. (One bad rm -rf $FOO/ with $FOO unset and they start losing their come directory.)

[hferentschik]

A historical note. IIRC, rsync was added because if there was a sync'd folder and the sync'ing type wasn't specified, on some *nix hosts, vagrant would pick NFS. If NFS wasn't setup correctly or firewalled you'd get hangs that were hard to resolve.

Sure, but this is not any synced folder. What I am talking about is just the default sync of the current directory to /vagrant. If the user adds any other sync folders the whole issues regarding the sync type still prevails.

if you try to sync the User's home directory (including Windows c:\Users\me), there can be a number of unintended consequences:

We don't want to use a full sync per se. We are talking about a file system mount. So only the content which is accessed is copied/synchronized. We really need to sync/mount the whole user directory, since this is the only way to handle seamlessly docker volume mounts. This is what docker-machine does as well using guest additions as default.

[burrsutter]

I am using the "vagrant rsync" to /vagrant as the primary means to move my code into the VM so I can then "docker build" on it.

[bexelbie]

@burrsutter docker build works from the host

[burrsutter]

@bexelbie yes, but, our current model in our docs/demos is to "vagrant ssh" into the box to insure the end-user has the right version of the client-side utilities and a consistent user experience regardless of his/her host OS. Therefore, "vagrant rsync" is still pretty important. If we wish to eliminate "vagrant ssh" and "vagrant rsync" from our user experience, then we have a fair bit of work to do :-)

[hferentschik]

I am using the "vagrant rsync" to /vagrant as the primary means to move my code into the VM so I can then "docker build" on it.

docker build works from the host

+1, is this not we have vagrant service-manager env docker. The whole point is that I can run docker on my host, similar to docker-machine.

yes, but, our current model in our docs/demos is to "vagrant ssh"

That seems to be wrong to me. This means that you can use the CDK only for one project at the time, since in your case the Vagrantfile would need to live with your project sources. What do you do, if you have more than one project? Really the Docker daemon provided by the CDK is a general purpose tool suitable for all of my Docker needs.

Agreed, the user needs matching CLI tools, but we have been discussing solutions for that, eg adding a command to service-manager to download the matching CLI tools (see issue #90).

Therefore, "vagrant rsync" is still pretty important.

Here is the rub, folder synchronisation is important and we for sure need that, not at least to get any proper Docker use case working. That's why we are working on getting sshfs to work. However, since this might not be a viable solution for Windows in the end, we might need to give the users still the opportunity to use vbguest additions (maybe by downloading and installing it himself). Forcing the folder synchronization mechanism to rsync a we do now, is in this case just wrong. Hence, my primary motivation is to avoid enforcing rsync as synchronization mechanism.

If we wish to eliminate "vagrant ssh" and "vagrant rsync" from our user experience, then we have a fair bit of work to do :-)

vagrant ssh should always be an option. Other than that, what we need is not a sync of the directory containing the Vagrantfile, but a sync of the whole user's home directory. Either via sshfs or via vbguest additions.

Personally, I'd rather "sell" this story and potentially document to the user how to download and install matching CLI libs manually. Then, eventually CLI tools can be installed automatically (note sure whether this is something we even could aim for for GA!?)

[LalatenduMohanty]

closing this issue as PR #413 is merged now.

[vhosakot]

When I did vagrant up with the box centos/7 (virtualbox, 1703.01), ==> default: Rsyncing folder: /root/ => /vagrant was stuck for me too, and adding
config.vm.synced_folder '.', '/vagrant', disabled: true
in Vagrantfile resolved the issue for me and rsync did not happen.