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 past, I do not recall ipa-upgradeconfig as being really fast, especially certmonger/Dogtag related updates were really slow thank to service restarts, etc. > 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... > 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 > _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel