The Puppet Labs Issue Tracker has Moved:

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using See the following page for information on filing tickets with JIRA:

Feature #3153

Network interface type

Added by Anonymous about 6 years ago. Updated over 3 years ago.

Status:AcceptedStart date:02/05/2010
Priority:NormalDue date:
Assignee:Adrien Thebo% Done:


Target version:-
Affected Puppet version:0.25.4 Branch:
Keywords:networking types

We've Moved!

Ticket tracking is now hosted in JIRA:


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.

Related issues

Related to Puppet - Bug #1128: interface errors on centos / redhat Closed
Related to Puppet - Bug #1152: interface{} fails on RHEL Duplicate
Related to Puppet - Feature #2761: Support for routes/ network configuration Accepted 10/29/2009


#1 Updated by James Turnbull about 6 years ago

  • Category set to network
  • Status changed from Unreviewed to Accepted
  • Assignee set to Anonymous

Mike – all yours in you want to open Pandora’s box I’d love to see what’s inside… :)

#2 Updated by Anonymous about 6 years ago

This should go to unassigned for someone to pick up once we decide the proper release

#3 Updated by Peter Meier about 6 years ago

there have been once a network type, unfortunately it didn’t get any support from someone to fix the outstanding issues, hence it was remove –> #1128

#4 Updated by James Turnbull about 6 years ago

  • Assignee deleted (Anonymous)

No sense of humour… shakes head

As Peter indicated this is a challenging one. I think I’ve got an updated branch of the all network type’s code that got a few more things working but is still broken. I’ll find it.

#5 Updated by James Turnbull about 6 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 ...?)
  ensure (onboot)
  boot protocol (DHCP/etc)
  interface number
  IP address

And then flesh out for Solaris and others. Providers are sufficiently unique that it could be quite a complex exercise.

#6 Updated by Laurent Bigonville almost 5 years ago


Any progress on this?

That’s a Resource type that would really help to add some portability of you recipes.

#7 Updated by James Turnbull almost 5 years ago

Laurent – have a look at

#8 Updated by Laurent Bigonville almost 5 years ago


Thanks for your update. This module was already on my radar, unfortunately it lacks of debian support :(

#9 Updated by James Turnbull about 4 years ago

  • Status changed from Accepted to Investigating
  • Assignee set to Adrien Thebo

Have fun…

#10 Updated by Adrien Thebo about 4 years ago

  • Status changed from Investigating to Accepted

I have a module prototype at 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.

#11 Updated by Robin Bowes almost 4 years ago

It sure would be nice if something like this got finished, and also worked with RHEL flavours…

#12 Updated by Adrien Thebo almost 4 years ago

I’m actually very slowly working on this… I’m doing some refactoring on the backing code to make this more possible.

#13 Updated by Adrien Thebo over 3 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 with RHEL and Debian support. Requires Facter 1.6.2. If people would test this for me, that would be great.

Also available in: Atom PDF