# The Controller is implemented so that it provides the Application Update user interface, which allows a user to ask for the list of available updates for a particular application instance, select a required patch or upgrade from the list and initiate the instance update.
# The Controller is implemented so that it stores all information about old package and the application instance:
# The Control Panel is implemented so that the directories tree rooted in the web site home directory represents the URL structure of the hosting environment as it is accessible from the Internet.
Starting Point. User initiates opening a list of updates available for a particular application instance.
Step 1. The Controller resolves update packages for the instance and displays a list of available updates:
Sub-step 1.1. Searches through metadata of all application packages in Repository to find those of the same application as the application instance but different version and release (basing on the values of
"/application/release" elements in metadata files).
Sub-step 1.2. From the packages found on the previous sub-step, the Controller selects the patch and upgrade packages:
matchattributes of any
matchattributes of the
Sub-step 1.3. Displays the list of available updates to the user, grouping the available packages as patches and upgrades. The list contains controls which allow user to select a package to which the instance must be updated and initiate the process of application update. Depending on whether a patch or upgrade is selected, the Controller starts the process of patching or upgrading.
The following scenario steps that describe patching are marked with the P letter, those that describe upgrading, with the U letter, those that are performed in both cases are just numbered and don't have any letter marks.
Step 2. The Controller backs up old instance data.
Step 3. The Controller parses application metadata file
APP-META.xml of the update package
: extracts and organizes all information about the package.
Step 4-U. The Controller determines the new requirements and checks if they are satisfied with the current conditions.
Sub-step 4-U.1. Gets information about service configuration script (
"/service/provision/configuration-script/script-language") and checks whether there is an appropriate interpreter in the system and it can be used on the hosting environment to run the configuration script. If the check fails, the Controller adds a message about it to the error stack.
Sub-step 4-U.2. Gets information on the disk space occupied by the new application when it's installed (
"/service/provision/url-mapping/installed-size") and checks if there is enough free disk space in the hosting environment: compares whether the new installation size is smaller than the sum of the site free disk space and the old installation size. If the check fails, the Controller adds a message about it to the error stack.
Sub-step 4-U.3. Gets the list of new requirements (
"/service/requirements") and compares them to the old ones in order to check whether the old requirements satisfactions satisfy them. If there are any new requirements that need satisfaction, goes to the Sub-step 4-U.4; if no, goes to the Sub-step 4-U.5.
Sub-step 4-U.4. Checks if the current hosting environment conditions allow satisfying the new requirements (for example, if the scripts support is enabled for the site, if the usage of such databases is allowed on the site, etc.).
If the check succeeds, the Controller satisfies the requirements and performs all the necessary additional operations (e.g., migrates the database from the old database server to the new one). Then stores all the information about them (for the purpose of future deallocating or re-allocating) and prepares all the necessary environment variables which concern the satisfied requirements.
If the check fails, the Controller adds a message about it to the error stack.
Sub-step 4-U.5. Checks the error stack status.
If it contains any messages, the Controller stops the process of upgrading the application and displays the screen with the error stack content.
If there are no messages, the Controller continues to the next step.
Step 5. The Controller checks whether the new service has an end-user license which regulates the service usage (
"/service/license"). If it has, the Controller creates a screen displaying the license text. If there is the
" attribute, the screen contains the I agree to the license terms (...) checkbox and the submit and cancel buttons, and the Controller continues updating only if the user submits the selected checkbox.
Step 6-P. The Controller checks if the new package metadata contains any installation-only settings which differ (according to the setting ID) from the old installation-only settings (the
"//setting" elements that have the
installation-only="true" attribute). If it does, the Controller prepares for such settings environment variables with default values taken from the package metadata. If no default values found, the Controller skips the step.
Step 6-U. The Controller checks if the instance upgrade requires configuring additional settings, and if so, presents the user with configuration form and processes the data submitted by user.
Sub-step 6-U.1. From the upgrade package information, gets the list of all service installation-only settings (the
"//setting" elements that have the
Sub-step 6-U.2. Retrieves the stored list of old installation-only settings, compares it to the list created on the previous sub-step, and selects the new installation settings contained in the new package (the ones the old package didn't have) if there are any.
Sub-step 6-U.3. For each new installation setting, creates a list of elements that the form will contain so that the user could enter the required settings values. For each setting data type the Controller makes the corresponding form element (text box, drop-down menu, etc.), adds to each element a label and tooltip from the required locale, and so on. And generates the form.
Sub-step 6-U.4. As the user enters the required information and submits the form, the Controller gets the submitted data and validates each setting value basing on the settings information from the package metadata. If an invalid value is set, the Controller returns to the previous sub-step: Generates the installation form again adding to it messages about wrong values.
Sub-step 6-U.5. From the upgrade package information, gets the list of all service settings that lack the
Sub-step 6-U.6. Retrieves the stored list of old settings, compares it to the list created on the previous sub-step, and selects the new settings contained in the new package (the ones the old package didn't have) if there are any.
Sub-step 6-U.7. For each new setting, creates a list of elements that the form will contain so that the user could enter the required settings values. For each setting data type the Controller makes the corresponding form element (text box, drop-down menu, etc.), adds to each element a label and tooltip from the required locale, and so on. And generates the form.
Sub-step 6-U.8. As the user enters the required information and submits the form, the Controller gets the submitted data and validates each setting value basing on the settings information from the package metadata. If an invalid value is set, the Controller returns to the previous sub-step: Generates the installation form again adding to it messages about wrong values.
Sub-step 6-U.9. Prepares all the necessary environment variables concerning the settings.
Step 7. The Controller deploys the new application files to the site.
Sub-step 7.1. Gets the stored information about old application files, and removes them.
Sub-step 7.2. Deploys the new application files following the instructions defined in the update package
"/provision/url-mapping" rules. Properly copies the files and performs the actions required to set URL handlers and permissions. While deploying the application, the Controller prepares the required mapping-related environment variables, and records the information on each directory where the application files are copied. When deployment is finished, the Controller saves this information for the purpose of future application upgrade or removal.
Note: application web access is configured, but not activated.
Step 8. The Controller gets the new application global configuration stored in the Repository, analyzes it and prepares global-configuration environment variables.
Step 9. The Controller invokes the application configuration script to configure the application.
Sub-step 9.1. Gathers all the information about environment variables prepared on the previous steps and other required variables (full instance URL, for example), and creates the variables basing on the rules defined in the Specification.
Sub-step 9.2. Runs the configuration script in the environment where all the environment variables created on the previous sub-step are defined, passing to it the old application version and release as arguments.
Sub-step 9.3. If the script invocation succeeds, the Controller activates application web access and displays to the user the screen with the successful update message and congratulations. If the script invocation fails, the Controller restores old instance from the back up and displays the screen with the error message.
Step 10. The Controller organizes access to the new metadata file and the scripts directory from the update package for the instance.
Please send us your feedback on this help page