donavan <dona...@desinc.net> writes:
> On Apr 19, 10:09 pm, Daniel Pittman <dan...@rimspace.net> wrote:
>> So, a simple "gateway" fact is essentially meaningless for our network; this
>> is probably true of at-least-some machines on at-least-some large networks.
>>
>> (So, while your fact is meaningful, it isn't a generic "gateway" fact :)
> <snip>
>> This can return multiple results, trivially, even on a simple network where
>> you have multiple definitions in /etc/network/interfaces; it breaks in the
>> face of network mapping, or of having two NICs with gateway statements.
>
> When I made up my sites broadcast fact I solved it in a manner like
> interfaces.rb. Essentially there are multiple "broadcast_$interface"
> facts, and while creating these the interface associated with
> "ipaddress" also sets the "broadcast" fact as primary.
What do you do about an interface like this:
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:30:48:97:59:ae brd ff:ff:ff:ff:ff:ff
inet 192.168.10.11/24 brd 192.168.10.255 scope global eth0
inet 192.168.10.130/24 brd 192.168.10.255 scope global secondary eth0:0
inet 192.168.10.131/24 brd 192.168.10.255 scope global secondary eth0:1
inet 192.168.10.132/24 brd 192.168.10.255 scope global secondary eth0:2
(Actually, that one is easy as all the extra addresses are in the same
segment. We have other machines where they are not...)
> Moving on to the gateway fact; I think a trivial solution is to use
> your array of gateways to create a series of "gateway_$n"[1] facts.
...by "gateway" do you mean "default route", or just "gateway" — we have hosts
that have a dozen different routes, and sometimes no default route at all,
that act inside the network.
So, there would be a different "gateway" for the 0/0, 192.168/8, and 10/8
networks, as a trivial example.
> If you can detect a default then that can be "gateway". Given I haven't
> looked at this exact problem yet, so I could be overlooking the hard bits.
I think the problem is that there is a mismatch between the simple "gateway"
model of networking, and the reality of IP networking.
For many people today, they only deal with simple machines: one local route,
to their connected Ethernet segment, and one default route to the rest of the
world.
Once you start getting multiple sites, and a need for network availability,
this starts to fall off: you will have at least some systems that have
multiple routes to other parts of the network, and then the wheels fall off.
In my opinion building assumptions that fall apart in the face of complexity
into puppet is a bad strategy — and this is just as true if you do that in the
manifests you write yourself as if the upstream developers do it.
Daniel
--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.
