Add mount_options option.

[purpleidea]

This option can be very useful with the existing enable_nfs option to
choose a different protocol like tcp (udp is the default), and to add
other nfs options like nolock.

[fgrehm]

I haven't tried but would it be a problem to pass in a blank hash of mount_options to synced_folder?

[purpleidea]

I don't see why... It seems to work for me...
I'm not a ruby expert, so maybe I've missed some nuance.
What error are you getting?

[purpleidea]

Or maybe I misunderstood your comment...

[purpleidea]

I think I understand what you meant. You're asking, why do I optionally add the hash in or not pass it in at all?
this is because when you pass in a blank hash, it erases the defaults that are set from the synced_folder. By default if you pass nothing, it uses vers=3,udp,rw.

So afaik, this patch makes the most sense as is.

[fgrehm]

Oh, sorry it wasn't clear but I'm glad you understood my comment. So yeah, I wasn't sure why we need to omit the parameter instead of passing in a blank hash and what you said makes sense :)
I'm away for the weekend but will look into bringing this in by monday! 👍

[purpleidea]

On Sat, 2013-12-14 at 08:50 -0800, Fabio Rehm wrote:

@@ -18,7 +18,13 @@ def call(env)
FileUtils.mkdir_p(cache_root.to_s) unless cache_root.exist?

         nfs_flag = env[:machine].config.cache.enable_nfs

•        env[:machine].config.vm.synced_folder cache_root, '/tmp/vagrant-cache', id: "vagrant-cache", nfs: nfs_flag
  

•        mount_options = env[:machine].config.cache.mount_options
  

•        if mount_options
  

Oh, sorry it wasn't clear but I'm glad you understood my comment. So yeah, I wasn't sure why we need to omit the parameter instead of passing in a blank hash and what you said makes sense :)
I'm away for the weekend but will look into bringing this in by monday! 👍
Sounds good!
Have a nice weekend!

James

---

Reply to this email directly or view it on GitHub:
https://github.com/fgrehm/vagrant-cachier/pull/68/files#r8352205

[fgrehm]

And BTW, the plugin works fine for vagrant-libvirt? If that's the case we can add it to the compatible providers list 😃

[purpleidea]

@fgrehm Sorry for my late reply. So far it seems to (I think). There's at least one reasonably bad bug, but I can't reproduce it reliably yet. Basically what happens is when you provision a host, you'll get a permission denied error on /tmp/vagrant-cache/yum

Should probably be another bug, but I've been busy.

Also, tell me if you like this vagrantfile hack (the no-parallel). Technically there could still be an issue, but it's less risky. Which is why I hacked it in, and didn't patch it upstream:

    #
    #   cache
    #
    # TODO: this doesn't cache metadata, full offline operation not possible
    config.cache.auto_detect = true
    config.cache.enable :yum
    #config.cache.enable :apt
    if not ARGV.include?('--no-parallel')   # when running in parallel,
        config.cache.scope = :machine   # use the per machine cache
    end
    config.cache.enable_nfs = true  # sets nfs => true on the synced_folder
    # the nolock option is required, otherwise the NFSv3 client will try to
    # access the NLM sideband protocol to lock files needed for /var/cache/
    # all of this can be avoided by using NFSv4 everywhere. die NFSv3, die!
    config.cache.mount_options = ['rw', 'vers=3', 'tcp', 'nolock']

Also it would be cool if there was a way to preemptively pre-warm the future hosts... Eg: hardlink over into the respective machine dirs any .rpm's. You could do this if :machine set, and for the list of machines in vagrant status.

[purpleidea]

@fgrehm ping?

[purpleidea]

ping ping?

[fgrehm]

@purpleidea sorry for the silence, I've been on vacations and pretty much offline from github for a while, but I'm back in action and cachier is my current focus :-) expect some progress on it soonish

[purpleidea]

On Tue, Jan 28, 2014 at 4:48 PM, Fabio Rehm notifications@github.com wrote:

@purpleidea sorry for the silence, I've been on vacations and pretty much offline from github for a while, but I'm back in action and cachier is my current focus :-) expect some progress on it soonish

Great! I had assumed you got abducted by a competing caching product!

[fgrehm]

@purpleidea I'm finally getting to this, sorry for taking so long to get back to you.

After some thinking and looking around I realized that GH-78 allow us to implement this in a more general way making things future proof down here. Please see my comments over there to better understand my decision on closing this PR.

Thanks for putting this up and stay tuned for updates, if all goes well I'll be able to cut a new release over the weekend.