Requirements
|
Since 4.8
This functionality is available since version 4.8.
|
| This page is a work in progress. |
Introduction
This document contain description of requirements for new upgrade feature, which should help users simplify the process of midPoint upgrade. One part of upgrade procedure will be the update of objects stored in midPoint repository according to schema updates (see also Schema cleanup).
Functional Requirements
-
Object validation (deprecated, planned removal, others schema changes)
-
CSV (or something similar) report
-
Validation process must be able to run even with midpoint being up. This means validation must be able to run with old ninja (schema for old MP version needs to be updated to contain all deprecated/remvoed items based on version we’d like to upgrade).
-
Automatic migration recommendation(e.g. for move when replacement is defined, if element was removed we can remove, …)
-
-
Validation report
-
Report must contain information about what midpoint will handle during upgrade
-
As 1:1 (no functional changes)
-
Changes that needs review, but can be done
-
Changes that will be upgraded later during upgrade process
-
File should also contain a place where use can mark up object as "ignored", later during upgrade process and object shouldn’t be upgraded.
-
In file only simple textual description, structured but not XML delta
-
-
-
XML dump with all delta files for changes that midpoint is going to do
-
Part of validation report should be:
-
If you don’t do this, midpoint will not start
-
If you don’t do that, you can do it later
-
…
-
-
FOR LATER Validate midpoint API usages, functions, deprecated things (groovy variables, etc)
-
-
Objects upgrade
-
Report progress
-
-
Initial objects
-
Import new, if necessary upgrade existing
-
Prepare not only initial objects in "absolute state" (good for new deployments) but also deltas which can be applied in existing environments
-
-
Connectors Upgrade
-
Notify user about connectors upgrade
-
Preffered method Automatically upgrade embedded connectors, e.g. update resources connectorRef (remove oid/type/relation from filter)
-
Validate via query
-
-
Other way Add/copy "old" versions of bundled connectors to midpoint-home if necessary, as not to break resources
-
-
Upgrade DB schema
-
Check version of DB schema before
-
-
Upgrade <midpoint.home>
-
Upgrade binaries, start/stop scripts
-
Upgrade objects in DB
-
Upgrade audit records in DB (DB schema only, for now only schema compatible changes expected, do data migration expected)
-
Configurable options, e.g. stop on error or continue but report?
-
TODO more specific
-
Non-functional requirements
-
Upgrade path
-
From old LTS to new LTS (e.g. 4.4 → 4.8)
-
From feature release to next one (e.g. 4.7 → 4.8)
-
-
Should be effective for small and medium size deployments
-
Up to 250k objects in repository
-
Only deployments with native PostgresSQL repository supported
-
-
Upgrade process doesn’t have to run when midPoint is operational (running)
-
Progress reporting necessary
-
Provide detailed result what was done, status of the operations, success/error rate?
-
User has to know what happened, what’s happening, why it’s happening
-
See also these issues
-
-
Think about modularity and usability, maybe not everything is suitable in every environment, e.g. small vs. big deployments
-
All steps that can be done before MP goes offline for upgrade should be done before (e.g. validation)
Other
-
Integration with ninja
-
Possible switch to spring shell/batch
-
-
Display differences in initial import objects vs those currently stored in repository
-
What about verification results? dump list to CSV or something?
-
-
Check 4.4 LTS schema versus 4.8 schema, make sure there’s upgrade path for changes in schema
-
See also Schema cleanup
-