The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
Network interface type
|Assignee:||Adrien Thebo||% Done:|
|Affected Puppet version:||0.25.4||Branch:|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
This ticket may be automatically exported to the PUP project on JIRA using the button below:
Talking with user, would be nice to be able to model network interface config in Puppet to faciliate easy changes — OS installers particularly Anaconda do not allow all options.
Taking a look at interface modelling in Cobbler will show some of the things we’d like to represent — including bonding and arbitrarily named interfaces, as well as some examples of kludgy templates for configuring those on RHEL/Fedora. Will take additional work to make something Debian/Ubuntu other friendly.
This seems to also require the need to express arbitrary datastructures in external nodes.
#5 Updated by James Turnbull over 4 years ago
So my first thoughts are the old code is probably good as a “don’t do this the same way again” guide.
I recommend a start from scratch with a new type. I think the first issue is to data model something that works for a variety of platforms, something like:
interface name (namevar) interface type (loopback, normal, alias ...?) description ensure (onboot) boot protocol (DHCP/etc) interface number IP address netmask broadcast
And then flesh out for Solaris and others. Providers are sufficiently unique that it could be quite a complex exercise.
#10 Updated by Adrien Thebo over 2 years ago
- Status changed from Investigating to Accepted
I have a module prototype at https://github.com/adrienthebo/puppet-network. It supports some pretty neat features, but the type interface needs to be redesigned and I need to make sure the tests really cover everything. When I get some time free I’ll finish this off.
#13 Updated by Adrien Thebo almost 2 years ago
My work on this has convinced me that a type that’s actually useable across a number of platforms is also going to require additional logic to handle complex cases. For things like bridged interfaces, there’s too much disparity between platforms to implement that just in a native type. My plan has been to implement a fairly low level type that implements the basic cases, allows passthrough to the underlying system, and expects the more complex behavior to be implemented in the Puppet DSL.
Code is at http://forge.puppetlabs.com/adrien/network with RHEL and Debian support. Requires Facter 1.6.2. If people would test this for me, that would be great.