On 03/03/2015 11:05 AM, Jan Cholasta wrote:
> 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?

Maybe it isn't. I must admit I am getting little confused with this thread.

If you envision the (config) upgrades to work differently than in the design
page, can you please summarize your proposal maybe even in a separate thread so
that we can assess it? Maybe it makes more sense, but right now it is difficult
to follow the big picture in this thread.

Thanks,
Martin

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to