Dne 3.3.2015 v 10:55 Martin Kosek napsal(a):
On 03/03/2015 09:55 AM, Martin Basti wrote:
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:
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?
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.

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?
The "clever" optimizations worked in past, but IPA grown and now contains
constraints/requirements which nobody expected.  What if we will need some
update which needs to execute time-consuming system check during every upgrade
in future?
User can always run the upgrade manually, with --skip-version-check, and then
configuration plugins will decide if the upgrade is needed.

I tend to agree with Martin, I would prefer to be on the safe side and not run
config upgrades every time, unless we are explicitly asked to or unless we are
absolutely sure that our idempotent upgrade scripts perfect for this use case.

Which is not what I think we can say for 4.2. Maybe we could do it as gradual
steps? Do on-demand config update with the said flag and when were confident
about our idempotent upgrader, measure the time impact and start doing it every
time?

I would very much prefer to do it the other way around, so that most bugs in the code are caught early, instead of hidden behind the version comparison.


Martin



--
Jan Cholasta

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

Reply via email to