[Freeipa-devel] IPA Server upgrade 4.2 design

Tue Mar 3 10:06:38 UTC 2015

Dne 3.3.2015 v 11:04 Petr Spacek napsal(a):
> On 3.3.2015 10:58, Martin Kosek wrote:
>> 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.
>
> Maybe I'm missing something but
>
> if not state.get('dns_forward_zones_supported'):
> 	# upgrade to forward zones here
>
> seems less error-prone than
>
> if version < 4.0:
> 	# upgrade to forward zones here
> 	# make me a sandwich
> 	# consult local oracle to guess that other features where backported
> 	#	to currently running code
>

Exactly!

-- 
Jan Cholasta