Thoughts on Parameterized Networking Module?

[Sean Alderman]

I've been hunting for a networking module to manage RHEL and perhaps Solaris platforms, Razorsedge (https://github.com/razorsedge/puppet-network) seems to be very robust module for RHEL types, but completely not parameter driven and difficult to use with a Puppet ENC.  So I was curious about your thoughts on how to either use one of the Example42 template models to write a similar networking module or perhaps a wrapper to such a module so it could be easily managed from an ENC.

The end goal with the puppet/foreman is that post-build, foreman will provide puppet with parameter information used by the networking module to reconfigure the networking from DHCP to Static where desired.  It is then possible that complex networking like interface bonding or aliases could be applied as well, which is what lead me to look at the razorsedge module to begin with.  The author suggests writing a puppet module which is parameter driven and wraps his module to feed it with the host specifics from the ENC.  The system networking structure doesn't entirely fit the package/service/config model, and neither does the wrapper concept.  So before I just run off and write something from scratch I wanted to see what you all think, since I'm fond of the Example42 style.

Thanks for your thoughts!

[Alessandro Franceschi]

It would definitively be a great thing to have a good network module in Example42 style.
I personally have not written any because I always found myself ending up with a network managed during the provisioning phase and out of Puppet control, but that's something that could/should be managed.

As you correctly remark, a network module follows different pattern from a normal application module, so I have not rigid ideas on how it should be or what parameters it should have.
I suppose that, to fit example42 "style", it should at least:
- Use params_lookup for the parameters of the main class (but does it make sense to manage the networking with a single class? Probably a set of defines (or custom type) based approach fit better this case
- Support at least Debian and RedHat distros

If you want to make a good module from scratch or from existing ones, I'd be happy to add it as submodule in the Example42 set.

[Sean Alderman]

- Use params_lookup for the parameters of the main class (but does it make sense to manage the networking with a single class?

I think the single class argument is why the author of the module I mentioned doesn't parametrize his class.  The implication is an instance for each interface or alias, which makes a lot of sense given the file structure.  Each interface gets its own unique config, so it would seem difficult to manage all interfaces from a single instance.

Perhaps I should start simply with his suggestion and attempting to wrap his module so that foreman can manage just one server's network via parameters and see how far I can get.  Starting with the specific and growing into the abstract might be better in this case...this is the problem (or the converse) which drives me to be a sysadmin, not a developer :)