networkinterface type proposal
Eric Sorenson
Scott Smith
--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
James Turnbull
> Hi - I've searched around and haven't found anyone who's implemented a
> type+provider for configuring network interfaces in puppet. Does anyone
> have such a thing already running that's just not on forge / github? I
> found some prior art (aside from the old 'interface' type which was
> deleted in 0.24) but most people seem to use definitions + templates
> which isn't a good "first class citizen" solution.
>
> I and other puppet hackers around my organization worked up a strawman
> proposal that we thought would be a reasonable interface and I figured I
> would float it by the list. Obviously it's a complicated beast but this
> would be great functionality to have in puppet. I'll
> update https://projects.puppetlabs.com/issues/3153 with the results of
> the discussion here and maybe we can get some traction on it.
>
> - Eric Sorenson - N37 17.255 W121 55.738 - http://twitter.com/ahpook -
Eric
One of our GSOC students started some work on this:
https://github.com/blkperl/puppet-network
James
--
James Turnbull
Puppet Labs
1-503-734-8571
Thomas Bellman
(Sorry for responding late; I'm a bit behind in reading puppet-users
and puppet-dev.)
> Hi - I've searched around and haven't found anyone who's implemented
> a type+provider for configuring network interfaces in puppet. Does
> anyone have such a thing already running that's just not on forge /
> github? I found some prior art (aside from the old 'interface' type
> which was deleted in 0.24) but most people seem to use definitions +
> templates which isn't a good "first class citizen" solution.
>
> I and other puppet hackers around my organization worked up a strawman
> proposal that we thought would be a reasonable interface and I figured
> I would float it by the list. Obviously it's a complicated beast but
> this would be great functionality to have in puppet. I'll update
> https://projects.puppetlabs.com/issues/3153 with the results of the
> discussion here and maybe we can get some traction on it.
> ### basic examples
> networkinterface { "eth0":
> ensure => enabled,
> bootproto => dhcp, # required for DHCP/BOOTP, optional for static
> hwaddr => "00:aa:bb:cc:dd:ee"
> }
>
> networkinterface { "eth0":
> ensure => "enabled", # sets ONBOOT=true, causes ifup refresh
> hwaddr => "00:aa:bb:cc:dd:ee"
> ipaddress => "10.0.0.2",
> netmask => "255.255.255.0",
> gateway => "10.0.0.1",
> }
The basic seems OK. A few comments, questions and discussion points:
- What does the hwaddr parameter do? I guess that it corresponds to
the HWADDR setting in /etc/sysconfig/network-scripts/ifcfg-eth* on
RedHat:ish systems, and not the MACADDR setting? I.e. it will be
used to select which interface is eth0, not the set the MAC address
of eth0? I hope it is supposed to be an optional parameter, so we
don't have to write 'hwaddr => $macaddress_eth0' on every interface
resource.
- It would be nice to be able to specify the netmask as either a proper
netmask (i.e. like 255.255.255.0) or as a number of bits (i.e. 24).
- It would be nice to be able to specify the IP address and netmask
in one parameter using CIDR notation, i.e:
networkinterface {
"eth0": ipaddress => "10.0.0.3/24";
"eth1": ipaddress => "192.168.17.23/255.255.240.0";
}
- The gateway parameter is optional, I suppose?
- I would like the ensure parameter to be split into two: 'ensure => up',
'ensure => down' or 'ensure => dontcare' to specify which state the
interface should be in right now, and 'onboot => true' or 'onboot =>
false' to specify if it should be brought up when the machine boots.
(Exact names of the parameters and values is not so important.)
- There is also a need to be able to configure an interface as up (and
onboot=true) but without setting any network parameters. I need it
on some of my multihomed Xen dom0 machines, where the dom0 itself
should only use eth1, but the guests need a connection via eth0. If
I bring down eth0, my guests lose their network... In the definition
I'm using now, I use 'bootproto => unconfigured, onboot => true,
ensure => up', but I'm not married to that particular spelling.
- And here's a big discussion point: IPv6. One can use different
address assignment methods for IPv4 and IPv6 for the same interface.
On IPv6 it is also common to have several addresses on each interface.
I don't really have any ideas here, though; we are only just now
starting to look at IPv6, I'm afraid...
> ### vlan example
> networkinterface { "vlan201":
> ensure => "enabled",
> ipaddress => "10.0.0.3",
> netmask => "255.255.255.0",
> gateway => "10.0.0.1",
> vlantag => "201", # 1 through 4096
> physicaldev => "eth0", # parent device, need this or hwaddr
> # not too happy about this, but IMO the yum 'enablerepo' example
> # shows there is a need to pass arbitrary provider-specific args
> # i.e. the RH sysvinit provider would turn " " to \n and
> # drop these into the network-scripts file.
> # This particular option enables '/dev/vlan201' instead of '/dev/eth0.201'
> extra_opts => "VLAN_NAME_TYPE=VLAN_PLUS_VID_NO_PAD PEERDNS=NO PEERNTP=NO"
> }
The extra_opts parameter is a good idea. I would suggest that you
should specifiy it as an array of options, like this:
extra_opts => [ "VLAN_NAME_TYPE=VLAN_PLUS_VID_NO_PAD",
"PEERDNS=NO",
"PEERNTP=NO" ]
I don't have any specific comments on the VLAN stuff, though.
> ### bonding example - master interface with two slaves
> networkinterface { "bond0":
> ensure => "enabled",
> ipaddress => "10.0.0.4",
> netmask => "255.255.255.0",
> gateway => "10.0.0.1",
> # rather than support a crapload of attributes like "bond_mode => active_backup",
> # use the new-style BONDING_OPTS variable
> extra_opts => "BONDING_OPTS='mode=active-backup arp_interval=60 arp_ip_target=192.168.1.254'"
> }
> # slave interfaces for the bond
> networkinterface { "eth0":
> ensure => enabled,
> bond_master => bond0,
> }
> networkinterface { "eth1":
> ensure => enabled,
> bond_master => bond0,
> }
The only comment I have on bonding, is to think about terminology.
I believe the official Ethernet name is "aggregation", while Linux
calls it "bonding", and HP use "trunking".
> ### ip aliases
> # this requires a unique namevar so you couldn't model solaris
> # or iproute2-style secondary addresses without composite keys
> networkinterface { "bge0:1":
> ensure => enabled,
> ipaddress => "10.0.0.5",
> netmask => "255.255.255.0",
> gateway => "10.0.0.1",
> }
Iproute2-style secondary addresses probably ties into how one
should configure IPv6 addresses.
/Bellman
Eric Sorenson
good
points. Replies inline.
On Mar 16, 8:06 am, Thomas Bellman <bell...@nsc.liu.se> wrote:
> - What does the hwaddr parameter do? I guess that it corresponds to
> the HWADDR setting in /etc/sysconfig/network-scripts/ifcfg-eth* on
> RedHat:ish systems, and not the MACADDR setting? I.e. it will be
> used to select which interface is eth0, not the set the MAC address
> of eth0? I hope it is supposed to be an optional parameter, so we
> don't have to write 'hwaddr => $macaddress_eth0' on every interface
> resource.
problem
here between interface fact names/values and what's specified in
manifest
but the whole type will be tricky that way.
> - It would be nice to be able to specify the netmask as either a proper
> netmask (i.e. like 255.255.255.0) or as a number of bits (i.e. 24).
>
> - It would be nice to be able to specify the IP address and netmask
> in one parameter using CIDR notation, i.e:
>
> networkinterface{
> "eth0": ipaddress => "10.0.0.3/24";
> "eth1": ipaddress => "192.168.17.23/255.255.240.0";
> }
It would simplify things...
> - The gateway parameter is optional, I suppose?
>
> - I would like the ensure parameter to be split into two: 'ensure => up',
> 'ensure => down' or 'ensure => dontcare' to specify which state the
> interface should be in right now, and 'onboot => true' or 'onboot =>
> false' to specify if it should be brought up when the machine boots.
> (Exact names of the parameters and values is not so important.)>
> - There is also a need to be able to configure an interface as up (and
> onboot=true) but without setting any network parameters. I need it
> on some of my multihomed Xen dom0 machines, where the dom0 itself
> should only use eth1, but the guests need a connection via eth0. If
> I bring down eth0, my guests lose their network... In the definition
> I'm using now, I use 'bootproto => unconfigured, onboot => true,
> ensure => up', but I'm not married to that particular spelling.
>
a
fork of blkperl's provider since that's where I'm starting.
> - And here's a big discussion point: IPv6. One can use different
> address assignment methods for IPv4 and IPv6 for the same interface.
> On IPv6 it is also common to have several addresses on each interface.
> I don't really have any ideas here, though; we are only just now
> starting to look at IPv6, I'm afraid...
>
the problem in front of me; maybe if someone wants to work on ipv6
they can chime in with their opinion.
> The extra_opts parameter is a good idea. I would suggest that you
> should specifiy it as an array of options, like this:
>
> extra_opts => [ "VLAN_NAME_TYPE=VLAN_PLUS_VID_NO_PAD",
> "PEERDNS=NO",
> "PEERNTP=NO" ]