On May 27, 2009, at 3:01 AM, Bart Vanbrabant wrote:

>
> Hi,
>
> Last year I used puppet for my master thesis. I added quite some
> features to puppet for this. It has been too long but I finally got
> one feature documented and ported to the latest master. The
> explanation and some examples are in this email. The code for this is
> in github: http://github.com/bartv/puppet/tree/master
>
> Conflict handling
> -----------------
>
> Because of Puppet's declarative nature it is impossible to define  
> resources of
> the same name if they have the same resource type. Conflict handling  
> introduces
> a new metaparameter called 'conflicthandler'. When this parameter is  
> set,
> resources with conflicting names do not generate an exception but  
> are handed
> off to the conflicthandler referenced in the metaparameter. Because  
> the
> conflict handling only happens at the end of the compilation process  
> it only
> makes sense to use these conflicthandlers on native resources.
>
> The patch allows new conflicthandlers to be defined like custom  
> functions in
> puppet/parser/conflicthandlers Puppet contains one conflicthandler  
> for file
> resources. The 'concat' handlers handles the conflict by collecting  
> the content
> parameters of all conflicting resources, sorts them and concatenates  
> them.  The
> sorting is required so only real content changes will case a  
> reconfiguration
> instead of different ordering. The 'concat' handler can be used like  
> that file
> fragment pattern.
>
> Using the concat conflict manager and file resources a lot of  
> existing native
> types can be replaced. The only downside is you can only manage a  
> full file
> instead of specific lines or groups of lines. But the only sane way  
> to use
> these native resources such as hosts, nagios_*, sshkey, etc is by  
> setting Type
> { purge => true } any way.

This is really interesting.  Still trying to absorb the implications,  
so I can't really make a real assessment at this point.

Other than the sorting handler for doing file concatenation, what  
useful conflict handlers do you see existing?

I've long been wanting a builtin mechanism for providing what this  
sorting handler provides -- the ability to specify file snippets in  
the language and have them turned into files automatically on the  
client -- so this is of special interest to me.  I'm trying to see  
what other useful handlers might exist that would justify this being a  
general service rather than a specific solution for file snippets.

This makes me think of the work I'd like to do around making it easier  
for native types to generate other native resources -- e.g., something  
like what you have but that retained the semantically rich logging,  
and having the host -> file conversion take place on the client rather  
than on the server.

>
> example usage
> +++++++++++++
>
> # A host entry in /etc/hosts. It replaces the native resource and is  
> functional
> # equivalent to the native host type if Host { purge => true } is set.

There is one crucial difference between this and native Host support:  
Logging is semantically rich with the native type (e.g., 'changed ip  
address from X to Y') but not with the file ('changed contents from  
<hash> to <hash>').  You might make 50 changes in a hosts file in one  
transaction and it would show up as a single change.

Not saying this kills the feature, just that it does make a  
difference, and that difference is one of the reasons I frequently  
espouse native types.

>
> define host($ip, $alias = "", $ensure = "present", $target = "/etc/ 
> hosts") {
>    case $ensure {
>        present: {
>            file {$target:
>                conflicthandler => "concat",
>                owner => root,
>                group => root,
>                mode => 0644,
>                content => "$ip $name $alias\n",
>            }
>        }
>        default: {}
>    }
> }
>
> host {"localhost":
>    ip => "127.0.0.1",
>    alias => "localhost.localdomain",
> }
>
> host {"localhost6":
>    ip => "::1",
>    alias => "localhost6.localdomain6",
> }
>
> example handler (define in puppet/parser/conflicthandlers/ignore.pp)
> +++++++++++++++
>
> This handler just keeps the first one found and ignores the other  
> conflicting
> rules.
>
> # ignore conflicting users if they have the same parameters
> def are_equal?(one, two)
>    # TODO
> end
>
> class Puppet::Parser::ConflictHandler
>    self.newconflicthandler("user", "ignore")
>        conflicts.each do |conflict|
>            # resource variable contains the resource that was added
> to the catalog
>            raise ArgumentError.new("Conflict!") unless
> are_equal?(resource, conflict)
>        end
>    end
> end
>
> Todo
> ++++
>
> - add a better api for writing conflicthandlers, especially to work  
> with the
>  resources
> - only allow conflicthandlers on native resources or make them work on
>  non-native resources. But this can only work IF the conflicting  
> define does
>  NOT generate any new conflicting defines for the same resource.


I would think that the handlers would work on defined resources as  
well as native resources, as long as they were triggered at the right  
time.  The complexity would be making sure that that happened -- you  
could quite easily have conflicting native resources at drastically  
different depths in the configuration, so it'd be very difficult to  
have both of them in their final state at the same time without one of  
them having already been evaluated.

-- 
The brain is a wonderful organ. It starts working the moment you get
up in the morning and does not stop until you get into the office.
     --Robert Frost
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to