Thanks Thomas. My Reply is also late :) But thanks very much for your
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.
Yes this should be flagged as optional, there is a bootstrapping
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";
> }
What do you think about making CIDR the *only* way to specify netmask?
It would simplify things...
> - The gateway parameter is optional, I suppose?
Yes
>
> - 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.
>
These all make sense, will incorporate and repost, maybe on a gist or
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...
>
I don't have any idea about that either. I have to focus on solving
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" ]
Ah, good point, updated
>
> 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
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
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.
