[Freeipa-devel] IPA Server upgrade 4.2 design

[Simo Sorce]

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.

> >> 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.

> I have no more objections.
> 
> >
> >> * 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
> >>
> 
> 


-- 
Simo Sorce * Red Hat, Inc * New York