[Freeipa-devel] IPA Server upgrade 4.2 design

[Jan Cholasta]

Dne 3.3.2015 v 10:58 Martin Kosek napsal(a):
> 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.

How exactly is adding another logic layer on top of the configuration 
update more simple and stupid?

>
> Martin

-- 
Jan Cholasta