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:
Dne 24.2.2015 v 19:10 Martin Basti napsal(a):
please read the design page, any objections/suggestions appreciated
* Merge server update commands into the one command
So there is "ipa-server-install" to install the server,
--uninstall" to uninstall the server and "ipa-server-upgrade" to
server. Maybe we should bring some consistency here and have one of:
a) "ipa-server-install [--install]", "ipa-server-install
b) "ipa-server-install [install]", "ipa-server-install uninstall",
c) "ipa-server-install", "ipa-server-uninstall", "ipa-server-upgrade"
Long term, I think we want C. Besides other advantages, it will let
independent sets of options, based on what you want to do.
* Prevent to run IPA service, if code version and configuration
* 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
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 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.
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.
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
My personal opinion is, application should not try to fix itself every
One could say that application should not try to upgrade itself every
restart, but here we are, doing it anyway...
In the past, I do not recall
ipa-upgradeconfig as being really fast, especially certmonger/Dogtag
updates were really slow thank to service restarts, etc.
Correct, but I was talking about configuration file updates, not
(re)starts, which have to always be done in ipactl anyway.
* Prevent user to use ipa-upgradeconfig and ipa-ldap-updater
Even without arguments? Is ipactl now the only right place to
Sorry, I will add more details there, if this is not clear.
ipa-upgrateconfig will be removed
ipa-ldap-updater will not be able to do overall update, you will need to
specify options and update file.
Plugins are called from update files, using new directive
Why "update-plugin" and not just "plugin"? Do you expect other kinds
to be called from update files in the future? (I certainly don't.)
I have no strong feelings on this one, but IMO it is always better to
"plan B" if we choose to indeed implement some yet unforeseen plugin
I doubt that will happen, but if it does, we can always add
I do not insist on "update-plugin", I just wanted to be more specific
which type of plugin is expected there.
Well, the names of the files end with .update and they are located in
/usr/share/ipa/updates, I think that's enough hints as to what type of
plugin is expected.
New class UpdatePlugin is used for all update plugins.
Just reuse the existing Updater class, no need to reinvent the wheel.
I wonder why configuration update is done after data update and not
know it's been like that for a long time, but it seems kind of
unnatural to me,
especially now when schema update is separate from data update. (Rob?)
We need schema update first, but I haven't found any services which need
to have updated data (I might be wrong)
keep --test option and fix the plugins which do not respect the option
Just a note, I believe this ticket is related:
Good work overall!
Freeipa-devel mailing list