[PUP-8106] "mount" type should autorequire its mountpoint Created: 2017/10/30  Updated: 2018/02/06  Resolved: 2018/02/06

Status: Resolved
Project: Puppet
Component/s: Types and Providers
Affects Version/s: PUP 5.3.2
Fix Version/s: None

Type: New Feature Priority: Normal
Reporter: Johnson Earls Assignee: Kris Bosland
Resolution: Won't Do Votes: 0
Labels: community
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to PUP-6397 File autorequire in Mount causes depe... Closed
Template:
Epic Link: Mount Type/Provider Improvements
Sub-team: Coremunity
Team: Platform Core
Sprint: Platform Core KANBAN
Release Notes: New Feature
Release Notes Summary: The mount resource now auto requires the file resource that is its mountpoint.
QA Risk Assessment: Needs Assessment

 Description   

The mount type should autorequire a File resource for its mountpoint.

    mount { '/usr/local/foo':
        ensure => mounted,
        ...
    }
    file { '/usr/local/foo':
        ensure => directory,
    }

This will try to mount /usr/local/foo before creating it.

I've got a mountpoint being created in one component and the nfs share being mounted from another component. So my profile has to know the details of the components to know that it has to create the ordering relationship. This should be automatic.



 Comments   
Comment by Johnson Earls [ 2017/10/30 ]

I'm attempting a PR for this. Given how little I know about the autorequires stuff, I hope it ends up correct.

Comment by Johnson Earls [ 2017/10/31 ]

Submitted PR#6325 for this.

Comment by Kris Bosland [ 2017/12/18 ]

Merged to master https://github.com/puppetlabs/puppet/commit/e0676fb4f7d37ffb3029caf3f310c83ef72fd2a0.

Comment by Melissa Stone [ 2018/02/06 ]

I've opened https://github.com/puppetlabs/puppet/pull/6607 to revert this change. It seems it reintroduces a bug fixed by https://tickets.puppetlabs.com/browse/PUP-6397 where the auorequire in mount will cause dependency loops.

Generated at Sun Oct 13 17:50:16 PDT 2019 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.