[Freeipa-devel] IPA Server upgrade 4.2 design

[Jan Cholasta]

Dne 3.3.2015 v 11:00 Martin Basti napsal(a):
> On 03/03/15 10:55, Jan Cholasta wrote:
>> Dne 3.3.2015 v 09:55 Martin Basti napsal(a):
>>> On 03/03/15 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:
>>>>>>>>>>  ...
>>>>>>>>>> 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?
>>> at least ipa-dnskeysyncd service, requires updated schema for keys
>>> metadata.
>>> This service is mandratory for DNS, so it is newly configured during
>>> upgrade.
>>> Now it works because schema update is the first, so during configuration
>>> upgrade we have actual schema.
>>
>> Right, but what's your point? We are not discussing order of updates
>> here, I'm perfectly fine with schema updates being done before
>> configuration updates.
> So you want to run schema update before configuration upgrade every
> restart?
> OR you want to run schema update if needed based on version, and then
> run configuration upgrade?

I don't really care, as long as the schema is up-to-date, but I guess 
there is no harm in always running schema update either.

-- 
Jan Cholasta