On Thursday, October 25, 2012 8:05:09 PM UTC-5, Brian Rak wrote: > > I've been using Puppet to manage network interfaces on our machines. To > do this I've got a class very similar to > http://forge.puppetlabs.com/razorsedge/network . I'm encountering some > annoyances with this method of handling it: > > 1) Every interface I have has to have a unique alias number. This means > that whenever I want to add a new IP alias I have to grep through my entire > tree and find an unused number. This seems... less then optimal. >
Why are your interface definitions spread throughout your tree? > 2) If I'm changing an interface (say from normal to bonded networking) I > have to go and switch the interface definitions for everything on that > machine. This also makes it difficult to have the same module used on > multiple machines (as their networking config needs to match exactly). > Why are you hardcoding interface names if it is important to be able to easily switch interfaces? > 2a) This gets more annoying as some of our newer machines have network > interfaces emX instead of ethX. This means that all the definitions need > to be updated once again when we change hardware. > Again, why are you hardcoding interface names? > > Has anyone encountered this and come up with a decent solution? I should > note that I'm using CentOS, all the modules I can find on forge appear to > be doing very similar things. > I have not tackled the specific problem you describe, but I'm inclined to think it arises more from the organization of your modules and manifest set than from any behavior of Puppet itself, or from interface-management modules such as the one you referred to. I think you need a dose or two of indirection and maybe added structure in your manifests. Some of the kinds of things to consider are - declaring interfaces inside classes, then establishing relationships where needed to the containing class instead of to the resource itself - storing interface details in class variables and / or external data - extracting interface definitions to their own module to narrow your search space - keeping separate documentation of the interfaces in use on each system - overall, working to make your manifests as DRY as possible, so that you only need to make changes in one place If you presented example code then we might have more specific suggestions. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/CV2EP8gGryIJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
