[Freeipa-devel] IPA Server upgrade 4.2 design

Tue Mar 3 11:08:23 UTC 2015

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?