Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-6397

File autorequire in Mount causes dependency loops

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: PUP 4.5.0, PUP 4.5.1
    • Fix Version/s: PUP 4.6.1
    • Component/s: Types and Providers
    • Labels:
      None
    • Environment:

      Linux

    • Template:
    • Acceptance Criteria:
      Hide

      It should be possible to:

      $_instance_path = '/opt/tomcat_myinstance'
       
      mount { $_instance_path:
        ensure => 'mounted',
        device => '/dev/foo',
        fstype => 'test',
      }
       
      tomcat::instance { 'myinstance':
        catalina_home => '/usr/share/tomcat6',
        catalina_base => $_instance_path,
        require       => Mount[$_instance_path],
      }
      

      Since Puppet 4.5.0, this fails with a dependency cycle:

      Error: Failed to apply catalog: Found 1 dependency cycle:
      (File[/opt/tomcat_myinstance] => Mount[/opt/tomcat_myinstance] => Tomcat::Instance[tomcat_myinstance] => File[/opt/tomcat_myinstance])
      

      tomcat::instance is from puppetlabs/tomcat.

      Show
      It should be possible to: $_instance_path = '/opt/tomcat_myinstance'   mount { $_instance_path: ensure => 'mounted', device => '/dev/foo', fstype => 'test', }   tomcat::instance { 'myinstance': catalina_home => '/usr/share/tomcat6', catalina_base => $_instance_path, require => Mount[$_instance_path], } Since Puppet 4.5.0, this fails with a dependency cycle: Error: Failed to apply catalog: Found 1 dependency cycle: (File[/opt/tomcat_myinstance] => Mount[/opt/tomcat_myinstance] => Tomcat::Instance[tomcat_myinstance] => File[/opt/tomcat_myinstance]) tomcat::instance is from puppetlabs/tomcat.
    • Story Points:
      0
    • Sprint:
      Client 2016-08-24
    • Release Notes:
      Bug Fix
    • Release Notes Summary:
      Overly aggressive autorelationships between mount and file types have been scaled back

      Description

      One of the autorequires added to Mount in 4.5.0 causes dependency loops in our install. See Acceptance Criteria first for a sample use case.

      The root cause is the File type assuming that the path is a unique identifier (namevar), while that's not true when Mounts are involved. PUP-6099 broke the workaround for that situation.

      When /x is a mountpoint, there are actually two /x directories: the mountpoint on the parent filesystem (/x in the / filesystem, invisible once mounted) and the mounted directory (the root of the mounted /x filesystem). These two directories are different system objects and may have different owners/modes/etc.

      The mountpoint is just a technical prerequisite to make mount work. What we usually want to manage in depth is the mounted directory. However, PUP-6099 makes Puppet only manage the mountpoint:

      File[/x] -> Mount[/x]                    # Forced by PUP-6099
      Mountpoint[/x] -> Mount[/x] -> File[/x]  # What we would want to do
      

      With Mountpoint a (not yet written) lightweight File clone that just ensures directory existence and root-ownership. So far I used an Exec hack as a quick workaround.

      Why it is important that File manages the mounted directory and not the mountpoint:

      • This is where the content lives and where we want the full power of the File type.
      • Doing otherwise breaks modules which manage the mounted directory as a File (see Acceptance Criteria).

      Suggested course of action: roll back the autorequire (lib/puppet/type/mount.rb:301) until a resolution for the more general issue described above is available. At the very least, please make it optional.

        Attachments

          Issue Links

            Activity

              jsd-sla-details-panel

                People

                • Assignee:
                  john.duarte John Duarte
                  Reporter:
                  tequeter Thomas Equeter
                • Votes:
                  1 Vote for this issue
                  Watchers:
                  14 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Zendesk Support