[Freeipa-devel] [PATCH] 0335 ipa-replica-install: Move check for existing host before DNS resolution check

[Petr Viktorin]

On 01/22/2014 08:00 PM, Rob Crittenden wrote:
> Petr Viktorin wrote:
>> On 01/14/2014 07:59 PM, Rob Crittenden wrote:
>>> Petr Viktorin wrote:
>>>> On 01/13/2014 05:19 PM, Rob Crittenden wrote:
>>>>> Petr Viktorin wrote:
>>>>>> See commit message & ticket for details.
>>>>>>
>>>>>> https://fedorahosted.org/freeipa/ticket/3889
>>>>>
>>>>> If memory serves this was done so that both the replication and the
>>>>> host
>>>>> checks would be done so the admin wouldn't die a death of a thousand
>>>>> cuts.
>>>>>
>>>>> If a leftover agreement exists then the replica install will fail. You
>>>>> delete the agreement. The next install may fail too if the host
>>>>> exists.
>>>>> We should check for both before quitting.
>>>>
>>>> AFAIK nowadays ipa-replica-manage del should also remove the host
>>>> entry,
>>>> so it's correct to suggest just that.
>>>>
>>>
>>> I couldn't find any place in the code the host is removed. This would
>>> have to be a pretty specialized case because you'd only remove the host
>>> if you were also deleting the last agreement.
>>
>> Well, `ipa-replica-manage del` does remove all agreements. So if we
>> suggest deleting the replica, it makes no sense to suggest running `ipa
>> host-del` after it.
>
> The replica_cleanup() function removes all principals associated to the
> master you're deleting, effectively deleting the host. That's what you
> saw in your reproduction (and why on a cursory look I couldn't find
> anywhere we explicitly delete the host).
>
> I still have the feeling one might see this two-step delete agreement,
> delete host, particularly when installs go sideways, but we're talking a
> rare case of running one extra command at worst. I wasn't able to force
> it to happen so my concerns are likely unwarranted.

I'd like to see the situation where that happens. I'd consider it a bug 
in ipe-replica-manage.

> Given the patch fixes a real, rather that my potentially imaginary
> issue, ACK. We can always revisit it if needed.

Thanks, pushed to master: b4401a17706176ed7a82d82ad559f30c78a37ab2

-- 
Petr³