## General provisioning process

### Installation process

Prospero delegates provisioning server to Galleon. When Galleon attempts to resolve components needed by the server, instead of using versions provided by the feature packs, Prospero intercepts that request and uses Wildfly Channels to find the correct version of the component and resolve it from the channels repositories.

image::overview.png[]

Every time a server is provisioned, it will receive the latest available components.

### Update process [[update_process]]

When new versions of components are made available, Prospero can apply those to existing servers. In order to find updates following steps are executed:

1. Download the latest version of channel manifests from Maven repositories
2. Compare component versions in the server to the latest available versions in channels.

If updates are available, they will be applied to the server in a following process:

1. Provision a new, updated server in a temporary directory.
2. Compare the changes between the new and old server.
3. Apply changes in the new server to the base server.

#### Resolving update conflicts

Generally user modified files in the server will never be changed during the update.

Sometimes server files might be modified both in the base server and in an incoming update. An example of this might be a configuration file changed by the user to support their setup and changed in the update to modify a default configuration value.

In such case, the user changes are persisted and not modified. The new, updated file configuration is created next to the old file with a `.glnew` suffix, and the user is notified that there was a conflict. The user can resolve the conflict manually after the update.

The exception to this rule are files considered to be `system paths`. They should not be modified by the user and will always be kept in sync with the changes provided by the updates. Any user changes will be replaced during the update and stored with a `.glold` suffix. An example of such files is a content of `modules/system` folder.

[cols="1,1,1,1"]
|===
| User modified | Update modified | System path | Resolution
| Y | N | n/a | Original file is used.
| N | Y | n/a | Updated version is used. Original file is discarded
| Y | Y | Y | Updated version is used. Original file is persisted with `.glold` suffix
| Y | Y| N | Original file is used. Updated version is persisted with `.glnew` suffix
|===

#### Update operation limitations

During "*apply changes*" phase of updates, any processes using server's resources need to be stopped to avoid resource locking issues. The user should manually shut down the server before performing update.

To reduce server downtime, the update operation can be performed in two steps - `prepare` and `apply`. In the first step, a candidate update server is provisioned in a new directory. The second step, compares the changes between the candidate and the base server and applies them to the base server.

If the update is split into separate steps, the `prepare` step can be performed while the server is running. See <<Working with update candidates>> for details.
