On 2010-05-06 15:59, Dejan Muhamedagic wrote: > Hi, > > On Thu, May 06, 2010 at 03:47:21PM +0200, Florian Haas wrote: >> Brad,
Apologies to Dag for addressing him as Brad. I was distracted.
>> sorry, I'll have to drop this one too as it's doing the wrong thing.
>>
>> On 2010-05-06 01:49, Dag Stenstad wrote:
> [...]
>>> + fi
>>> target_node=$(host $OCF_RESKEY_CRM_meta_migrate_target | \
>>> awk '{ print $1; }')
>>> + if [ ${target_node} = "Host" ]; then
>>> + ocf_log error "Unable to resolve migrate target FQDN."
>>> + ocf_log debug "This is probably due to a misconfigured
>>> /etc/resolv.conf, missing"
>>> + ocf_log debug "entries in /etc/hosts or a generally broken DNS
>>> setup."
>>> + exit $OCF_ERR_CONFIGURED
>>> + fi
>> Hmmm. I'm ambiguous about this part. What this means is that if we
>> initiate migration, and we can't resolve the host name at that time, we
>> don't just stop the migration and recover the resource through an
>> in-place shutdown and restart, but we're forcing it away, without any VM
>> migration, to a different host. I think this should be
>> $OCF_ERR_GENERIC... what do others think?
>
> Agreed. The problem may even be temporary. I'd probably try to
> avoid using host resolving in resources anyway.
Yes, but in the use case Dag describes it makes good sense.
So what is your suggestion? Loop on resolving and time out if it
ultimately fails?
Cheers,
Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
