Bug #1885

Requires are passed down to defines and exported with resources

Added by D K over 1 year ago. Updated over 1 year ago.

Status:Closed Start:01/23/2009
Priority:High Due date:
Assignee:James Turnbull % Done:

0%

Category:plumbing
Target version:0.25.0
Affected version:0.24.7 Branch:
Keywords:
Votes: 0

Description

When an export is in a define and the define is called with a require the require is exported.

Sample code.

class export::collect_test {

    Export::Collect_define <<||>>

}

define export::collect_define ($content) {

    file { 
       "$name":
            ensure => file, 
            owner => "root", group => "root", mode => 755,
            content => $content;
    }
    
}



class remote_export::remote_test1 {
    
    file { 
       "/tmp/testrequirefile1":
            ensure => file, 
            owner => "root", group => "root", mode => 755,
            content => "I am only required on remote host";
    }

    remote_export::remote_define {
        "remote_test1":
            content => "test file contents",
            require => File["/tmp/testrequirefile1"];
    }
    
}

class remote_export::remote_test2 {
    
    file { 
       "/tmp/testrequirefile2":
            ensure => file, 
            owner => "root", group => "root", mode => 755,
            content => "I am only required on remote host",
            before => Remote_export::Remote_define["remote_test2"];
    }

    remote_export::remote_define {
        "remote_test2":
            content => "test file contents";
    }
    
}

define remote_export::remote_define ($content) {

    file { 
       "/tmp/testlocalfile":
            ensure => file, 
            owner => "root", group => "root", mode => 755,
            content => $content;
    }
    
    @@export::collect_define {
        $name:
            content => $content;
    }
    
}

When I use a “require” to require the order in remote_export1 class it does export the require.

    id    |                         value                         | param_name_id | line | resource_id |         updated_at         |         created_at         
----------+-------------------------------------------------------+---------------+------+-------------+----------------------------+----------------------------
 12669414 | --- !ruby/object:Puppet::Parser::Resource::Reference 
title: /tmp/testrequirefile1
type: File
 |             2 |      |       94995 | 2009-01-23 12:36:06.533296 | 2009-01-23 12:36:06.533296
 12669413 | test file contents                                    |            10 |   46 |       94995 | 2009-01-23 12:35:06.005715 | 2009-01-23 12:35:06.005715

When I use a “before” to require the order in remote_export2 class it doesn’t export the require.


puppet=# SELECT * from param_values where resource_id = 94995;  
    id    |       value        | param_name_id | line | resource_id |         updated_at         |         created_at         
----------+--------------------+---------------+------+-------------+----------------------------+----------------------------
 12669413 | test file contents |            10 |   46 |       94995 | 2009-01-23 12:35:06.005715 | 2009-01-23 12:35:06.005715
(1 row)

Related issues

related to Puppet - Feature #1903: Metaparam inheritance should not involve a recursive search Closed 01/27/2009

Associated revisions

Revision e6b420088978adb3b3dd930db033df6dce59f124
Added by Luke Kanies over 1 year ago

Fixing #1885 – Relationships metaparams do not cascade

Because we now pass catalogs around, rather than a tree of resources, we no longer lose the metaparam information in definitions and classes. Thus, we no longer need to pass them down to contained resources.

Ideally we’d remove cascading of all metaparams (which is ticket #1903) but ‘schedule’ and ‘noop’ are inherently recursive but not in a way that the graph support can currently easily solve, so that’s going to have to wait for a later release.

Signed-off-by: Luke Kanies luke@madstop.com

History

Updated by James Turnbull over 1 year ago

  • Category set to plumbing
  • Status changed from Unreviewed to Accepted
  • Assignee set to Luke Kanies
  • Target version set to 0.25.0

Updated by Deepak Giridharagopal over 1 year ago

Require/before express some dependencies for the machine where the resource is defined. However, the machine that collects those resources will likely have a completely different set of dependencies.

For example, let’s say we want to use exported resources to maintain a database of services that runs on all machines (this example is a bit contrived, but is hopefully illustrative). On machine A:

@@service_db::entry {
    "postfix":
        require => Package["postfix"];
}

Now let’s say machine B wants to collect all service_db::entry resources. When it realizes that resource, it will run a command to update the db. Puppet will fail trying to apply the exported resource, as Package[postfix] couldn’t be found. And postfix will never be installed, as this box isn’t an MTA.

I suppose that I view “ordering-related” attributes like “require” and “before” as really only useful on the machine that originally defined the resources. The machine that collects them for a completely different use will likely have very different dependency requirements.

Updated by Luke Kanies over 1 year ago

  • Status changed from Accepted to Duplicate

This will be solved as part of #1903. Yes, it was filed first, but the other is more general.

Updated by Luke Kanies over 1 year ago

  • Status changed from Duplicate to Accepted

I’ve decided to fix this separately, rather than trying for all of #1903 in one go.

This is easy to do for current clients, but to provide backward compatibility the relationship parameters still need to inherit. I haven’t decided the best way to do this, but the choices seem to be either maintain through the compile whether the client is old, or have the extraction to the old format provide the inheritance functionality. The former is more likely.

Updated by Luke Kanies over 1 year ago

  • Target version changed from 0.25.0 to 2.6.0

Bumped.

Updated by Luke Kanies over 1 year ago

  • Target version changed from 2.6.0 to 0.25.0

Actually, can’t bump it; I promised it to a customer.

Updated by Luke Kanies over 1 year ago

  • Status changed from Accepted to Ready for Checkin
  • Assignee changed from Luke Kanies to James Turnbull

Pushed in the tickets/master/1885 branch in my repo.

The initial commit was essentially trivial (just removing code), but this set provides backward compatibility.

Updated by James Turnbull over 1 year ago

  • Status changed from Ready for Checkin to Closed

Pushed in commit:“e6b420088978adb3b3dd930db033df6dce59f124” in branch master.

Also available in: Atom PDF