I'll give this a try, I've never used or written a function so it's a good learning exercise.
My alternative plan was to make an awful exec{} that ran after the network
define did that would do a 'sed' on the /etc/hosts file to fix puppet's ip,
which is terrible. :)
On Wed, Jan 6, 2010 at 12:42 PM, Dan Bode <[email protected]> wrote:
> Hi Ashley,
>
> since you are re-ip-ing machines to a different subnet, then I assume that
> you are maintaining the IP address for every node on the puppet server?
>
> The problem with facts here is that you are determining the IPaddress of
> the puppet master based on what the IP is as opposed to what it should be
> (after the puppet run). I would recommend using a function instead.
>
>
> host { "puppet":
> ensure => "present",
> ip => get_puppet_master($ip),
> }
>
> and then move the fact logic to this function.
>
> hope this helps,
>
> Dan
>
> On Wed, Jan 6, 2010 at 8:04 AM, Ashley Penney <[email protected]> wrote:
>
>> Hi,
>>
>> I've a fairly odd network setup and I keep running into a minor but
>> irritating issue. We have various subnets and depending on which subnet you
>> are on you have to contact puppet by different IPs. I have various
>> workarounds for this and I build a /etc/hosts on each box with an entry for
>> 'puppet' with the correct IP. This is currently done via a fact as follows:
>>
>> Facter.add("puppetip") do
>> setcode do
>>
>> result = case Facter["ipaddress"].value
>> when /10.241.209/: "10.241.209.118"
>> else "140.247.200.118"
>> end
>>
>> result
>> end
>> end
>>
>> Then I have an entry in hosts.pp that reads:
>>
>> host { "puppet":
>> ensure => "present",
>> ip => "$puppetip",
>> }
>>
>> This works great except in cases where I have to re-ip a machine to a
>> different subnet (which happens constantly for reasons too depressing to
>> describe). In this case when my defines that update the network run they
>> are unable to update the /etc/hosts entry because the facter stuff is
>> evaluated at the start of the run. My host then changes IP and cannot
>> recontact puppet to continue. I have to ssh in and manually change
>> /etc/hosts and then run puppet again.
>>
>> This irritates the hell out of me, but I can't think of another puppet
>> solution for this. I can't rely on split dns (or any dns, it's broken and
>> not ran by me) so that's not an option. Anyone have any ideas how I could
>> work around this?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<puppet-users%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<puppet-users%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
-- You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
