On Wed, Jan 6, 2010 at 9:55 AM, Ashley Penney <[email protected]> wrote:
> I'll give this a try, I've never used or written a function so it's a good
> learning exercise.
>
I am sure you have used at least 2 functions, template and include :)
>
> 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]<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.
