[Freeipa-devel] IPA Server upgrade 4.2 design

[Petr Spacek]

On 2.3.2015 18:54, 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.
>>
>>> 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.
> 
> I have no more objections.

IMHO the problem with long-running RPM upgrade should be approached from the
other way: Just print message 'IPA server upgrade is running, press CTRL+C if
you want to destroy your IPA server'.

bind-dyndb-ldap prints a message about SELinux in RPM scriptlets for couple
releases now and nobody complained (yet? :-).

Petr^2 Spacek

> 
>>
>>> * ipactl will NOT run upgrade, just print Error: 'please upgrade ....'
>>> * User has to run ipa-server-upgrade manually
>>>
>>> Does I understand it correctly?
>>>>>> With --skip-version-check what sorts of problems can we foresee? I
>>>>>> assume a big warning will be added to at least the man page, if not
>>>>>> the cli?
>>>>> For this big warning everywhere.
>>>>> The main problem is try to run older IPA with newer data. In containers
>>>>> the problem is to run different platform specific versions which differ
>>>>> in functionality/bugfixes etc..
>>>> Ok, pretty much the things I was thinking as well. A scary warning
>>>> definitely seems warranted.
>>>>
>>>>>> Where does platform come from? I'm wondering how Debian will handle this.
>>>>> platform is derived from ipaplatform file which is used with the
>>>>> particular build. Debian should have own platform file.
>>>> Ok, I'd add that detail to the design.
>>>>
>>>> rob
>>>
> 
> 


-- 
Petr^2 Spacek