Instance overrides get more complicated...

Okay, things just got more complicated.

It's pretty straightforward if none of the objects in question have any relationships. You destroy the implicit objects, and swap in the explicit ones.

It gets much more complicated with things like dependencies:


file { "/etc": recurse => true, owner => root }
service { apache: subscribe => file["/etc/apache/apache.conf"] }
file { "/etc/apache": owner => apache, recurse => true }


In this situation, the "/etc/apache" declaration should override the "/etc" declaration, but we definitely don't want it to happen in such a way that we lose the subscription by the apache process.

So, we can't just destroy the old files and plop in the new ones; we have to go in and replace old values with new values. But we have to do it recursively -- the overriding files can be whole trees of files, not just individual files. And, importantly, their children are implicit, which means we can't just use normal overriding mechanisms, or it would look like one implicit file overriding another.

Maybe the solution is to switch from "hard" links like I'm using now with subscriptions (i.e., when I make a subscription I actually store a reference to the object) to "symbolic" links (i.e., just record the type and name). This would allow me to swap new objects in without screwing up the subscriptions.

That sounds like the best option; I've already had one really nasty bug that was caused by this storing of references (if I created an object that subscribed to something but didn't get completely created, I removed the object but didn't destroy the subscription, which resulted in the object staying around -- very bad, and very difficult to track down).