PATCH - Resource identification

Example: identification of overrides

#!/usr/bin/env puppet

class foo {
        file { "foo-dir":
                path => "/tmp/foo",
                ensure => directory,
        }
}

class bar inherits foo {
        File["foo-dir"] { ensure => file }
}

class baz inherits foo {
        File["foo-dir"] { ensure => file }
}
class mesh {
        include baz
        include bar
        # without identification, bang goes puppet
}

include mesh

CC-ing Thijs, from the mailing list.

Another example, plain identification

#!/usr/bin/env puppet

define mkdir ($a, $b) {
	file { "$a": ensure => directory }
	file { "$a/conf.d": ensure => directory }
	file { "$a/conf.d/$b": ensure => directory }
}

mkdir { "one":
	a => "/tmp",
	b => "ldap.ini",
}

mkdir { "two":
	a => "/tmp",
	b => "auth.ini",
}

#replace /tmp by /var/trac/proj for a real-world example.

This is rejected (no change here):

#!/usr/bin/env puppet

class foo {
	file { "foo-dir":
		path => "/tmp/foo",
		ensure => directory,
	}
}

define oink($a) {
	include foo
	File["foo-dir"] { path => "/tmp/foo/$a" }
}

class wut {
	oink { "o1": a => "123" }
	oink { "o2": a => "234" }
	#This should fail
}

include wut

It turns out that overrides aren't merged the way they should be in a complete configuration I have, I'm now looking for a simple test where this behaves incorrectly.

Here are some edge cases that make this complicated, and show that this patch isn't quite sufficient:

# Eventual equality
class one {
    file { "/testing": mode => 755, content => foo }
}

class two inherits one {
    File["/testing"] { owner => root }
}

class base {
    file { "/testing": owner => root, content => foo }
}

class sub inherits base {
    File["/testing"] { mode => 755 }
}

include two, sub

# Generated equality
define myfile($owner) {
    file { $name: owner => $owner }
}

class base {
    exec { echo: command => "/bin/echo something", refreshonly => true }

class one {
    myfile { $name: notify => Exec[echo], owner => root }
}

class two {
    file { $name: notify => Exec[echo], owner => root }
}

include base, one, two

# Within a single heirarchy
class base {
    file { "/testing": content => foo }
}

class sub1 inherits base {
    File["/testing"] { owner => root }
}

class sub2 inherits sub1 {
    File["/testing"] { group => root, mode => 755 }
}

class child1 inherits base {
    File["/testing"] { group => root, owner => root }
}

class child2 inherits child1 {
    File["/testing"] { mode => 755 }
}

include child2, sub2

More difficult edge cases:

# Initial equality, but not actual
class base {
    file { "/testing": content => foo }
}

class sub1 inherits base {
    File["/testing"] { mode => 755 }
}

class head {
    file { "/testing": content => foo }
}

class child1 inherits head {
    File["/testing"] { mode => 644 }
}

# "Valid" override, but only when evaluated in the right order.
# How do you guarantee that you keep the resource from 'base'
# around, not 'head'?
class base {
    file { "/testing": content => foo }
}

class sub1 inherits base {
    File["/testing"] { mode => 755 }
}

class head {
    file { "/testing": content => foo }
}

# Equal at definition time but not once metaparams are added.
define myfile($owner) {
    file { $name: owner => $owner }
}

class class1 {
    myfile { "/testing": owner => root, notify => Exec[myexec] }
}

class class2 {
    file { $name: owner => root }
}

A few points to keep in mind, that make identification currently difficult in puppet

• the same parameter may be overriden multiple times, provided it is done on the same class hierarchy. This is a problem because we have to keep track of the context an override was declared in, and with identification, this context may become a set of contexts.
• an override is only valid if made in a scope that includes the overriden resource
• metaparameters can be applied to a defined type, where it cascades to the resources contained there.

The third point does not seem too hard, if metaparameters can be merged. eg, noop + not noop -> not noop, Exec[a] + Exec b -> [Exec[a], Exec[b]], etc.

After much discussion, it looks like this feature is currently painfully difficult and likely will become impossible in the near future. Sorry.