I have some use cases where I want to define multiple similar resources that should end up in a single file (via a template).

As an example I'm trying to write a puppet module that will let me manage the mapping between MAC addresses and network interface names (writing udev's persistent-net-rules file from puppet), but there are also many other similar usage cases.

I searched around and found that it could be done with the new parameterised classes syntax: if implemented that way it should end up being used like this:

node { "myserver.example.com":
  class { "network::iftab":
    interfaces => {
      "eth0" => { "mac" => "ab:cd:ef:98:76:54" }
      "eth1" => { "mac" => "98:76:de:ad:be:ef" }
    }
  }
}

Not too bad, I agree, but it would rapidly explode when you manage more complex stuff (think network configurations like in this module or any other multiple-complex-resources-in-a-single-config-file stuff).

In a similar question on SF someone suggested using Pienaar's puppet-concat module but I doubt it could get any better than parameterised classes.

What would be really cool and clean in the configuration definition would be something like the included host type, it's usage is simple, pretty and clean and naturally maps to multiple resources that will end up being configured in a single place. Transposed to my example it would be like:

node { "myserver.example.com":
  interface { 
    "eth0":
      "mac" => "ab:cd:ef:98:76:54",
      "foo" => "bar",
      "asd" => "lol",
    "eth1":
      "mac" => "98:76:de:ad:be:ef",
      "foo" => "rab",
      "asd" => "olo",
  }
}

...that looks much better to my eyes, even with 3x options to each resource.

Should I really be passing arrays to parameterised classes, or there is a better way to do this kind of stuff? Is there some accepted consensus in the puppet [users|developers] community?

By the way, I'm referring to the latest stable release of the 2.7 branch and I am not interested in compatibility with older versions.