On Wed, Jan 6, 2010 at 10:09 AM, Ashley Penney <[email protected]> wrote:

> My only concern about this is that functions evaluate on the server,
> right?


right


> The only place I change ip's is in a variable ($ip) in nodes.pp for each
> node.


yes, this variable should represent the desired state of ipaddress.


> I do export a host{} entry for each box to storeconfig but I don't know if
> I can rely on that being updated in time for the function to look.


I don't follow what you mean here. The function wouldn't use the exported
resource, it would just use $ip. (unless there is something I am not
understanding)


>
>

> On Wed, Jan 6, 2010 at 1:00 PM, Dan Bode <[email protected]> wrote:
>
>>
>>
>> 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]<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.

Reply via email to