[Freeipa-devel] IPA Server upgrade 4.2 design

Tue Mar 3 11:15:07 UTC 2015

Dne 3.3.2015 v 12:08 Martin Kosek napsal(a):
> On 03/03/2015 11:06 AM, Jan Cholasta wrote:
>> 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!
>>
>
> Question is, what is the magical
>
> state.get('dns_forward_zones_supported')
>
> command :-) Is this the sysrestore State Store or is there any complicated
> schema check and LDAP searches for DNS master zones with forwarders?

This is about local configuration strictly, so it's state store check.

-- 
Jan Cholasta