[Freeipa-devel] IPA Server upgrade 4.2 design

[Martin Kosek]

On 03/03/2015 09:36 AM, Petr Spacek wrote:
> On 3.3.2015 09:33, Jan Cholasta wrote:
>> Dne 3.3.2015 v 09:06 Martin Basti napsal(a):
>>> On 03/03/15 07:31, Jan Cholasta wrote:
>>>> Dne 2.3.2015 v 13:51 Martin Basti napsal(a):
>>>>> On 02/03/15 13:12, Jan Cholasta wrote:
>>>>>> 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.
>>>>> I doesn't like this idea, if user wants to fix something, the one should
>>>>> use --skip-version-check option, and the IPA upgrade will be executed.
>>>>
>>>> Well, what I don't like is dealing with meaningless version numbers.
>>>> They are causing us grief in API versioning and I don't see why it
>>>> would be any different here.
>>> However you must keep the version because of schema and data upgrade, so
>>> why not to execute update as one batch instead of doing config upgrade
>>> all the time, and then data upgrade only if required.
>>
>> Because there is no exact mapping between version number and what features are
>> actually available. A state file is tons better than a single version number.
>>
>>>
>>> Some configuration upgrades, like adding new DNS related services,
>>> requires new schema, how we can handle this?
>>
>> This does not sound right. Could you be more specific?
>>
>>> Running schema upgrade every time?
>>>>
>>>>> What if a service changes in a way, the IPA configuration will not work?
>>>>
>>>> Then it's a bug and needs to be fixed, like any other bug. IIRC there
>>>> was only one or two occurences of such bug in the past 3 years (I
>>>> remember sshd_config), so I don't think you have a strong case here.
>>> Ok
>>>>
>>>>> The user will need to change it manually, but after each restart,
>>>>> upgrade will change the value back into IPA required configuration which
>>>>> will not work.
>>>>
>>>> Says who? It's our code, we can do whatever we want, it doesn't have
>>>> to be dumb like this.
>>>>
>>>>> Yes, we have upgrade state file, but then the comparing of one value is
>>>>> faster then checking each state if was executed.
>>>>
>>>> How faster is that, like, few milliseconds? Are you seriously
>>>> considering this the right optimization in a process that is
>>>> magnitudes slower?
>>> Ok the speed is not so important, but I still do not like the idea of
>>> executing the code which is not needed to be executed, because I know
>>> the version is the same as was before last restart, so nothing changed.
>>
>> Weren't "clever" optimizations like this what got us into this whole
>> refactoring bussiness in the first place?
> 
> I very much agree with Honza. We should always start with something
> stupidly-simply and enhance it later, when it is clear if it is really necessary.
> 
> Do not over-engineer it from the very beginning.

I completely agree with starting stupid and simply and improving in time.
However, are we sure that what Honza proposed is the simple and stupid way?

Doing config upgrade only when needed and thus not depending on the efficiency
and idempotency of the config upgraders seems to me as *the* stupid and simple
way for upgrade refactoring.

Martin