Closed fgrehm closed 10 years ago
Amazing, thanks for all the work! I'll install and try to look how it behaves.
if I have some time I'll try to get to caching vagrant-omnibus packages as well
This also requires vagrant-omnibus to allow passing the cache directory as an argument to the install.sh invocation. I don't have too much free hacking time, so I'll try to get mitchellh/vagrant#2604 forward during the next week. And definitely will add the config option there.
Hi, Is there typo in synced_folder_opts example in README? At least couldn't copy paste that example. Gave me syntax error.
@eaapa would you mind posting the error you've got? Thanks!
Of course (sorry posted the comment quickly)!
Vagrantfile (as it is in README):
Vagrant.configure("2") do |config|
config.vm.box = 'your-box'
if Vagrant.has_plugin?("vagrant-cachier")
# Enable cache buckets auto detection
config.cache.auto_detect = true
# If you are using VirtualBox, you might want to use that to enable NFS for
# shared folders. This is also very useful for vagrant-libvirt if you want
# bi-directional sync
config.cache.synced_folder_opts = {
type: :nfs,
# The nolock option can be useful for an NFSv3 client that wants to avoid the
# NLM sideband protocol. Without this option, apt-get might hang if it tries
# to lock files needed for /var/cache/* operations. All of this can be avoided
# by using NFSv4 everywhere. Please note that the tcp option is not the default.
mount_options = ['rw', 'vers=3', 'tcp', 'nolock']
}
# For more information please check http://docs.vagrantup.com/v2/synced-folders/basic_usage.html
end
end
vagrant status
output:
Vagrant failed to initialize at a very early stage:
There is a syntax error in the following Vagrantfile. The syntax error
message is reproduced below for convenience:
/Users/ernoaapa/Documents/owns/dreamstack/.tmp/foo/Vagrantfile:16: syntax error, unexpected '\n', expecting =>
@eaapa you're right, the example is wrong. It should be:
config.cache.synced_folder_opts = {
type: :nfs,
mount_options: ['rw', 'vers=3', 'tcp', 'nolock']
}
Also there is one another (so far unknown) problem. When using my fork https://github.com/eaapa/vagrant-cachier (Note last commit. I implemented mount_options differently).
this works:
config.cache.sync_opts = {:mount_options => ['nolock,vers=3,udp']}
But with this version if I try:
config.cache.synced_folder_opts = {:mount_options => ['nolock,vers=3,udp']}
# OR
config.cache.synced_folder_opts = {:mount_options => ['nolock', 'vers=3', 'udp']}
I get:
Failed to mount folders in Linux guest. This is usually beacuse
the "vboxsf" file system is not available. Please verify that
the guest additions are properly installed in the guest and
can work properly. The command attempted was:
mount -t vboxsf -o uid=`id -u core`,gid=`getent group core | cut -d: -f3`,nolock,vers=3,udp /tmp/vagrant-cache /tmp/vagrant-cache
mount -t vboxsf -o uid=`id -u core`,gid=`id -g core`,nolock,vers=3,udp /tmp/vagrant-cache /tmp/vagrant-cache
I pushed a fix for documentation. mount_options: ...
is the same as :mount_options => ...
, just different (ruby 1.9+) syntax.
@eaapa sync_opts
doesn't even exist, so it should error out. But at least it's not used anywhere. But you skipped the type: :nfs
so Vagrant tries to mount it with vboxfs. And those options are not accepted for it. The latter format is otherwise correct (i.e. ruby array of strings).
Sorry, I missed the beginning of your comment. Maybe you had the old config.cache.enable_nfs
defined in your Vagrantfile when testing your own fork?
@eaapa Yeah, I think @tmatilai is right, you probably had the enable_nfs flag defined so that's why it was working, please let us know if the extra type: :nfs
works :smiley:
Yeah just tested and removing the old enable_nfs
and adding the extra type: :nfs
fixed it. Yay :D
But isn't the message say it's should be deprecated and will be removed in future versions? So it should support still the old enable_nfs
in this version, right?
@eaapa We could probably add some sort of logic to handle merging enable_nfs
and synced_folder_opts
configs but since the synced_folder_opts
is brand new I'm pretty sure this won't be an issue. Thanks for reporting back :-)
NP glad to help!
Just to give everyone a heads up, there are more breaking changes for the good coming up :-)
Basically we'll have automatic bucket detection enabled by default and will require cache.scope
to be set. When those 2 things are implemented I'll cut 0.6.0.
Guys, I've done some big changes tonight including a refactoring and some performance improvements. If someone is able to give it a go it will be awesome!
/cc @gionn @purpleidea @miurahr @varac @oker1 (sorry for the spam, but I believe you guys are interested on this release according to recent GH history ;-)
hi, I have compiled and tested this pull request from the perspective of [GH-84] and can confirm it works correctly when offline. Thanks for including the changes - I like your approach to the apt-lists bucket better than my original PR anyway :)
Alright folks, 0.6.0 is coming out anytime this weekend. I've pushed one last (awesome :P) feature that is to warm up cache buckets with contents of the guests directory instead of simple removing them as we currently do.
I initially implemented that for the apt-lists bucket to work around the fact that the first time the machine boots with cachier installed there won't be any files on the apt lists dir, making it impossible to install anything on the VM and possibly breaking provisioning scripts that do not do apt-get update
s before installing packages.
I think this is something that will hardly happen as pretty much everyone does the apt-get update
before doing anything on the machine but we've got everyone covered and it makes up for a nice improvement for us to implement :-)
I've rebased and merged the branch, enjoy 0.6.0 :fireworks:
Hey folks, this is what I believe will be 0.6.0. I'll be testing these changes over the week and will get to release when I'm confident enough that it won't blow up, if I have some time I'll try to get to caching vagrant-omnibus packages as well (ping @tmatilai), let's see....
@eaapa @phinze @scalp42 @tuminoid Sorry for the spam but you guys are the ones that I believe are interested on this release, so please give it a go and LMK if things are working fine for you ;-)