[Freeipa-devel] IPA Server upgrade 4.2 design

[Martin Kosek]

On 03/03/2015 03:49 PM, Simo Sorce wrote:
> On Tue, 2015-03-03 at 15:33 +0100, Martin Kosek wrote:
>> On 03/03/2015 03:16 PM, Simo Sorce wrote:
>>> On Mon, 2015-03-02 at 18:54 +0100, Martin Basti wrote:
>>>> On 02/03/15 18:28, Martin Kosek wrote:
>>>>> On 03/02/2015 06:12 PM, Martin Basti wrote:
>>>>>> On 02/03/15 15:43, Rob Crittenden wrote:
>>>>>>> Martin Basti wrote:
>>>>> ...
>>>>>>> But you haven't explained any case why LDAPI would fail. If LDAPI fails
>>>>>>> then you've got more serious problems that I'm not sure binding as DM is
>>>>>>> going to solve.
>>>>>>>
>>>>>>> The only case where DM would be handy IMHO is either some worst case
>>>>>>> scenario upgrade where 389-ds is up but not binding to LDAPI or if you
>>>>>>> want to allow running LDAP updates as non-root.
>>>>>> I don't know cases when LDAPI would failed, except the case LDAPI is
>>>>>> misconfigured by user, or disabled by user.
>>>>> Wasn't LDAPI needed for the DM password less upgrade so that upgrader could
>>>>> simply bind as root with EXTERNAL auth?
>>>> We can do upgrade in both way, using LDAPI or using DM password, 
>>>> preferred is LDAPI.
>>>> Question is, what is the use case for using DM password instead of LDAPI 
>>>> during upgrade.
>>>
>>> There is no use case for using the DM password.
>>
>> +1, so we will only use LDAPI and ditch DM password options and querying that
>> we now have with ipa-ldap-updater?
>>
>>>
>>>>>> It is not big effort to keep both DM binding and LDAPI in code.  A user can
>>>>>> always found som unexpected use case for LDAP update with DM password.
>>>>>>
>>>>>>>>> On ipactl, would it be overkill if there is a tty to prompt the user to
>>>>>>>>> upgrade? In a non-container world it might be surprising to have an
>>>>>>>>> upgrade happen esp since upgrades take a while.
>>>>>>>> In non-container enviroment, we can still use upgrade during RPM
>>>>>>>> transaction.
>>>>>>>>
>>>>>>>> So you suggest  not to do update automaticaly, just write Error the IPA
>>>>>>>> upgrade is required?
>>>>>>> People do all sorts of strange things. Installing the packages with
>>>>>>> --no-script isn't in the range of impossible. A prompt, and I'm not
>>>>>>> saying it's a great idea, is 2 lines of code.
>>>>>>>
>>>>>>> I guess it just makes me nervous.
>>>>>> So lets summarize this:
>>>>>> * DO upgrade if possible during RPM transaction
>>>>> Umm, I thought we want to get rid of running upgrade during RPM transaction. It
>>>>> is extremely difficult to debug upgrade stuck during RPM transaction, it also
>>>>> makes RPM upgrade run longer than needed. It also makes admins nervous when
>>>>> their rpm upgrade is suddenly waiting right before the end. I even see the
>>>>> fingers slowly reaching to CTRL+C combo... (You can see the consequences)
>>>> People are used to have IPA upgraded and ready after RPM upgrade.
>>>> They may be shocked if IPA services will be in shutdown state after RPM 
>>>> transaction.
>>>
>>> This is true, stopping IPA and requiring manual intervention is not ok.
>>
>> What is the plan then? Keep upgrades done during RPM transaction? Note that RPM
>> transaction was already stuck several times because IPA, or rather DS, deadlocked.
>>
>> We also need to address https://fedorahosted.org/freeipa/ticket/3849. The
>> original plan was to do the upgrade during ipactl start, this would fix this
>> ticket. Alternatively, should we remove the upgrade from RPM scriptlet and only
>> call asynchronous "systemctl restart ipa.service" that would trigger the
>> upgrade in separate process and log results in ipa.service?
> 
> It's a hard problem.
> First of all DS should never deadlock, we shouldn't change all our
> process because one component has a bug
> If DS deadlocks, it will do so whether it is run in RPM or not, we need
> to add some way to terminate the upgrade ourselves if it lasts too long
> I guess.
> 
> The problem with an asynchronous restart is ... when do you do that ?
> What triggers it ?

systemctl restart ipa.service --no-block :-)

If there is no better place for the upgrade outside of RPM transaction, I am
fine, as long as ipactl writes the warning for FedUp users, as Martin
mentioned, to make sure they do not run un-upgraded IPA.

Martin