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.

In the past, I do not recall
ipa-upgradeconfig as being really fast, especially certmonger/Dogtag related
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.


3)

"
* Prevent user to use ipa-upgradeconfig and ipa-ldap-updater
"

Even without arguments? Is ipactl now the only right place to trigger manual
update?

4)

"
Plugins are called from update files, using new directive
update-plugin:<plugin-name>
"

Why "update-plugin" and not just "plugin"? Do you expect other kinds of plugins
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 have some
"plan B" if we choose to indeed implement some yet unforeseen plugin based
capability...

I doubt that will happen, but if it does, we can always add "plan-b-plugin" directive.


5)

"
New class UpdatePlugin is used for all update plugins.
"

Just reuse the existing Updater class, no need to reinvent the wheel.

6)

I wonder why configuration update is done after data update and not before. I
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?)

7)

"
keep --test option and fix the plugins which do not respect the option
"

Just a note, I believe this ticket is related:
<https://fedorahosted.org/freeipa/ticket/3448>.


Good work overall!

Honza




--
Jan Cholasta

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

Reply via email to