This article will describe the steps that you need to take when making a change to the service schema and how to upgrade the SMS Configuration. As part of this guide we will explain which upgrade rules need to be created and how to write them.
Note: This is a working document which will continue to evolve as as fill in more detail. If you have comments or suggestions, please feel free to make them.
Kinds of schema changes
Currently there are two ways to change the service schema in AM:
- In the xml schema files that use the sms.dtd
- Through annotations on POJO's in the AM codebase
When a change is made to the schema of AM, there needs to be a corresponding change to AM's configuration. New installations of AM will will produce the latest configuration, however existing installations of AM will have configuration that is out of date. The role of an upgrade rule in this case is to upgrade the existing configuration so that it matches the latest schema of AM.
Currently there are 3 ways a customer might upgrade AM's configuration depending on the deployment model they are using:
- LDAP SMS: These customers have a deployment based on storing their configuration in an LDAP database. They will upgrade their configuration using the AM upgrader. Developers creating these rules will implement
org.forgerock.openam.upgrade.steps.UpgradeStep Amster based Deployments: These customers have their configuration as exported Amster files. These configuration files will need to be upgraded using the
openam-config-upgrader. Developers implementing these rules will need to write new Amster rules to perform this upgrade.- File-based Configuration Deployments: Starting with AM 7.0.0, customers will be able to store their configuration in file-based configuration files on disk. Similar to Amster files in some ways, these new files will also be upgraded using the
openam-config-upgrader.
When upgrade rules need writing
For both Amster and FBC, upgrade rules only need to be written for changes to the existing configuration files i.e. not when additions are made. This is because for both Amster (via a new AM install) and FBC (via a set of base configuration files shipped it the AM docker image) any new configuration files will automatically be included.
To summarise when changes are needed:
| Change Operation | Amster | FBC |
|---|---|---|
| Modification | ✅ | ✅ |
| Deletion | ✅ | ✅ |
| Addition | ❌ | ❌ |
Checklist of required actions
As part of a schema change the following tasks need to be completed
- Create an upgrade step for: AM Upgrader
- Create upgrade rules for: Amster
- Create upgrade rules for: File Based Config
Directly Related
The openam-config-upgrader is released with AM and is the tool for upgrading both Amster-export and FBC AM configuration.
Child Pages
- Create an upgrade step for: AM Upgrader
- Create upgrade rules for: Amster
- Create upgrade rules for: File Based Config
- How the Amster upgrade process works
- How the FBC upgrade process works
- openam-config-upgrader
3 Comments
Andrew Vinall
Beware
AME-19231 - Getting issue details... STATUS
Andrew Vinall
A very useful talk by Peter Major covering upgrade. (Link to recording can be found on the title page.)
https://docs.google.com/presentation/d/1gOCh1uiQF9mhO5quvc3P59CYyKdA6uTzlzwgFhsq8Mg/edit#slide=id.p
Andrew Vinall
If the upgrade rules check will fail for the duration of the PR unless any schema change is removed from the PR
This tool is somewhat a blunt instrument but does serve the purpose to inform the developer that they have changed the schema and may need to take steps for upgrade e.g. write upgrade rules for file based configuration.
Currently, the upgrade-rules-check will fail for any schema change and will not go green (unless that schema change is removed from the PR). Note, the stage is not mandatory.
Here is an example of the test output from Jenkins, which is saying that the hash on the original schema is different from the changes in this PR
The test failure results in the message in the PR pointing to this wiki page