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:

* 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
update by
using a monolithic version number, which brings more than a few
problems on its

I do not agree in this section. Why would you like to run it
even if it
was fast? No run is still faster than fast run.

In the ideal case the installer would be idempotent and upgrade
be re-running the installer and we should aim to do just that. We
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
use --skip-version-check option, and the IPA upgrade will be

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
This service is mandratory for DNS, so it is newly configured during
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
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

Freeipa-devel mailing list

Reply via email to