[Freeipa-devel] IPA Server upgrade 4.2 design

[Martin Kosek]

On 03/02/2015 07:49 AM, Jan Cholasta wrote:
> Hi,
> 
> Dne 24.2.2015 v 19:10 Martin Basti napsal(a):
>> Hello all,
>>
>> please read the design page, any objections/suggestions appreciated
>> http://www.freeipa.org/page/V4/Server_Upgrade_Refactoring
>>
> 
> 1)
> 
> "
> * Merge server update commands into the one command (ipa-server-upgrade)
> "
> 
> So there is "ipa-server-install" to install the server, "ipa-server-install
> --uninstall" to uninstall the server and "ipa-server-upgrade" to upgrade the
> server. Maybe we should bring some consistency here and have one of:
> 
>  a) "ipa-server-install [--install]", "ipa-server-install --uninstall",
> "ipa-server-install --upgrade"
> 
>  b) "ipa-server-install [install]", "ipa-server-install uninstall",
> "ipa-server-install upgrade"
> 
>  c) "ipa-server-install", "ipa-server-uninstall", "ipa-server-upgrade"

Long term, I think we want C. Besides other advantages, it will let us have
independent sets of options, based on what you want to do.

> 2)
> 
> "
> * Prevent to run IPA service, if code version and configuration version does
> not match
>   * ipactl should execute ipa-server-upgrade if needed
> "
> 
> There should be no configuration version, configuration update should be run
> always. It's fast and hence does not need to be optimized like data update by
> using a monolithic version number, which brings more than a few problems on its
> own.

I do not agree in this section. Why would you like to run it always, even if it
was fast? No run is still faster than fast run. In the past, I do not recall
ipa-upgradeconfig as being really fast, especially certmonger/Dogtag related
updates were really slow thank to service restarts, etc.

> 3)
> 
> "
> * Prevent user to use ipa-upgradeconfig and ipa-ldap-updater
> "
> 
> Even without arguments? Is ipactl now the only right place to trigger manual
> update?
> 
> 4)
> 
> "
> Plugins are called from update files, using new directive
> update-plugin:<plugin-name>
> "
> 
> Why "update-plugin" and not just "plugin"? Do you expect other kinds of plugins
> to be called from update files in the future? (I certainly don't.)

I have no strong feelings on this one, but IMO it is always better to have some
"plan B" if we choose to indeed implement some yet unforeseen plugin based
capability...

> 5)
> 
> "
> New class UpdatePlugin is used for all update plugins.
> "
> 
> Just reuse the existing Updater class, no need to reinvent the wheel.
> 
> 6)
> 
> I wonder why configuration update is done after data update and not before. I
> know it's been like that for a long time, but it seems kind of unnatural to me,
> especially now when schema update is separate from data update. (Rob?)
> 
> 7)
> 
> "
> keep --test option and fix the plugins which do not respect the option
> "
> 
> Just a note, I believe this ticket is related:
> <https://fedorahosted.org/freeipa/ticket/3448>.
> 
> 
> Good work overall!
> 
> Honza
>