[Freeipa-devel] IPA Server upgrade 4.2 design

[Jan Cholasta]

Dne 2.3.2015 v 12:23 Martin Kosek napsal(a):
> 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 ideal case the installer would be idempotent and upgrade would be 
re-running the installer and we should aim to do just that. We kind of 
do that already, but there is a lot of code duplication in installers 
and ipa-upgradeconfig (I would like to fix that when refactoring 
installers). IMO it's better to always make 100% sure the configuration 
is correct rather than to save a second or two.

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

Correct, but I was talking about configuration file updates, not 
(re)starts, which have to always be done in ipactl anyway.

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

I doubt that will happen, but if it does, we can always add 
"plan-b-plugin" directive.

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


-- 
Jan Cholasta