Mount location overrides ownership on an existing mountpoint

[ccope]

I want to have a mount owned by a user. I tried creating the directory resources at the top of my recipe and then calling the logical_volume resource provider with the mount location option, but this caused the provider to create new directory resources that overrode my own. I would submit a PR but I have few questions:

• Are guard statements run at compile time (I assume yes, so I can't just change it from checking Pathname.mountpoint? to Pathname.exists?)
• Is there a way for a HWRP to check if a resource for a directory is in the resource collection already?
• If neither of the above are possible, could I even catch this with chefspec in my own cookbook? I seem to be unable to stub the call to Pathname.exists in my unit tests, and it seems like Pathname probably isn't being called at all (are ruby guards not evaluated in chefspec?) My test claims that the directory is created with the ownership I expect, but that's not what happens on a real machine.

[MarkGibbons]

@ccope Here's the code that creates the directory for mounting the volume from the lvm_logical_volume provider:

      # Create the mount point
      dir_resource = directory mount_spec[:location] do
        mode 0755
        owner 'root'
        group 'root'
        recursive true
        action :nothing
        not_if { Pathname.new(mount_spec[:location]).mountpoint? }
      end

If you have another earlier directory resource that created the directory owned by another user, this will run and change the owner to root. To get around the situation you have I would do this;

1. Create the directory in my cookbook
2. Create the logical volume but don't specify the mount point in lvm_logical_volume, then the directory resource above will not be used.
3. Use a separate mount resource to mount the volume

Your questions.

Guard statements, pretty sure those execute as part of resource processing. mountpoint? and exist? check for very different things.

HWRP check. Sure, serious overkill though.

What chefspec does depends on your code. Unless you step into the providers (see the highlighted warning about doing this https://github.com/sethvargo/chefspec) chefspec doesn't know what happens in the providers. Making lots of assumptions about your chefspec code "Pathname.mountpoint?" in the resource provider was unlikely to have been invoked.

Regards, Mark

[ccope]

Thanks Mark, that helps a lot. It was just a very surprising behavior, I only expected the provider to mount the logical volume, not also create the directory. The inability to test this also sucks (and trying to do it with serverspec requires a lot of setup since this requires extra block devices in my virtual machine). At this point I've rejected the following options:

• Detect if the folder exists at the time the HWRP is executed (seems tricky/not possible given the nature of guards).
• Detect if the directory is being created by chef by examining the resource collection (seems really complicated)
• Remove the directory creation (this would be a breaking change)

The last idea I have is adding an option to the logical_volume provider, create_mountpoint, which defaults to true. What do you think of that?

[MarkGibbons]

Testing - You can use loopback file systems for testing with serverspec. No extra block devices needed. I haven't checked the test setup here recently but lvm itself used to use that technique.

The create_mountpoint option seems reasonable.

Cheers

[chazzly]

I know this conversation is a little old, but I just ran into a similar situation.

What about adding the ability to set the user, group, and mode from within the lvm_logicial_volume resource? It can still default to root,root,755.

[MarkGibbons]

Which attributes do you mean, the mount point attributes or the attributes of the file system after it is mounted?