Maintenance Updates
In the a9s Data Services Framework the lifecycle of Service Instances can be managed automatically.
This page provides an introduction to what Maintenance Updates are, and how different features help Platform Operators manage them.
Introduction
During the existence of a Service Instance, different changes can take place in its dependencies as well as its environment. These changes are referred to as Maintenance Updates. The Service Instance will not be able to pickup up these changes, unless they are redeployed.
In order to simplify routine tasks, like Update all Service Instances, the a9s Data Services Framework tracks these updates and, when enabled by the Platform Operator, makes them (partially) visible to the Application Developer. In that case, the Application Developer can decide to block the updates in order to avoid any availability issues.
The Platform Operator is able to trigger these updates routinely for all Service Instances, as long as they are not blocked. They are also able to override the block when necessary. We explain the blocking feature in the Block Maintenance Updates section of this document.
Starting with anynines-deployment v66.0.0, the updates referred to as "Automatic Updates" and/or "Available Updates", will be renamed to "Maintenance Updates".
Keep in mind that some artifacts still retain the old naming, and are to be updated at a later point in time.
Types of Updates
Currently, the a9s Data Services Framework considers the following as Maintenance Updates.
Stemcell Updates
Anytime a newer stemcell is uploaded to the BOSH Director, and applied to the Service Manifest, Service Instances can potentially be recreated so that they can use this stemcell.
Release Version Updates
Each Service Instance has several releases, many of which need to be updated everytime some change is made to the Service Manifests. This is typically the case when rolling out a new version of the a9s Data Services Framework.
Release updates are only picked up when the release versions are frozen in the Service Manifest. For more information, see Freezing Release Versions.
BOSH Runtime Configurations
BOSH Directors allows for global settings to be specified, which are globally applied to all deployments whenever they are re-deployed, which is what happens during an update of a Service Instance. For more information, see BOSH Director Runtime Configs.
Template Updates
Similarly to the release updates, the a9s BOSH Deployer Templates can change over time. In such cases, the a9s Service Broker can trigger a redeployment of the Service Instance in which a new manifest is applied, according to the most recent template available. This normally happens when the a9s Template Uploader Errand is ran, typically after rolling out a new version of the a9s Data Services Framework.
Involved Components
To implement the Maintenance Update flow, the following components of the a9s Data Services Framework are involved:
- a9s Deployment Updater: This is an errand that gets information from the a9s Service Broker regarding any available updates, and then sends back a request to the a9s Service Broker to apply the updates across all Service Instances in a specific state. As such, this errand is the main tool for the Platform Operator to perform Maintenance Updates.
- a9s Service Broker: When receiving an update request that originates from Cloud Foundry or the a9s Deployment Updater, it performs checks to see whether the Maintenance Updates are allowed. It also invokes the a9s BOSH Deployer to determine whether there are available updates.
- a9s BOSH Deployer: Closely tracks pending changes and applies those changes when invoked.
- a9s Public API: Provides information regarding available updates for a Service Instance, and can allow the Application Developer to determine whether the updates should be applied, as well as to trigger an update. Please note that the Platform Operator has to enable this first. See Block Maintenance Updates below for more information.
Trigger Maintenance Updates
By default, the a9s Service Broker will apply any of the available updates mentioned above. This means that these
changes would be applied automatically, whenever an Application Developer performs a cf update-service command.
Similarly, to perform these updates for all Service Instances that correspond to an a9s Data Service, the a9s Deployment Updater component can be used by the Platform Operator.
The errand can executed as follows:
bosh -d <service-deployment> run-errand deployment-updater
Block Maintenance Updates
While the default settings allow the Maintenance Updates to go through, it is possible for an Application Developer to restrict this, if the Platform Operator decides to give this capability to the Application Developer.
In short, there are two steps to make this happen:
- The Platform Operator enables the Application Developer to block maintenance updates.
- The Application Developer then decides, per instance, whether they want to block the updates. They can do so through the a9s Service Dashboard or the a9s Public API v1.
Although the Application Developer can block the updates for a particular Service Instance, the Platform Operator still has the means to force an update if necessary. See Override the Block for more information.
1. Platform Operator enables the Application Developers to Block Updates
As mentioned, the a9s Service Broker enables the Platform Operator to allow or forbid the Application Developer's
ability to block Maintenance Updates of their Service Instances. The Platform Operator can do so by applying the
ops/forbid-automatic-update-of-service-instance.yml Ops file.
This enables the Update tab in the a9s Service Dashboard. If you want to customize this tab, see
Customize Maintenance Updates Modal.
2. The Application Developer Blocks Updates
The Application Developer can block the Maintenance Updates as shown in Update the Service Instance, or by using the a9s Public API V1.
Override the Block
If the Platform Operator has enabled blocking, and the Application Developer has opted to disable the updates,
any subsequent operation using the CLI will require a force_update parameter.
In other words, when manually updating Service Instances with the CLI, Application Developers will have to add the
force_update parameter to their command as follows:
cf update-service MY_SERVICE -c '{ "force_update": true }'
If there is no new available update, it is not required to add the force_update parameter when manually
updating a Service Instance.
The Platform Operator can also override the blocking by running the force_deployment_updater errand:
bosh run-errand force_deployment_updater
This will update these Service Instances regardless of whether the Application Developer blocked the update or not.
The force_deployment_updater must first be installed by the Platform Operator, as shown in the
Force Deployment Updater section.
Usage Differences Between Platform Operator and Application Developer
The Maintenance Updates are observed differently by the Application Developer, compared to the Platform Operator.
In the current implementation, the Application Developer is only able to see Maintenance Updates regarding Stemcells and Releases. Runtime configurations of the BOSH director and template updates are not shown in the a9s Service Dashboard, or exposed otherwise.
In contrast, the Platform Operator is concerned with all types of Maintenance Updates, considering that the a9s Deployment Updater will trigger an update of the Service Instance if any of the updates is available (as long as maintenance updates are not blocked overall).
When there are no Stemcell or Release updates, and the Application Developer has not blocked the updates, updates related to Stemcells and BOSH Configs can take place, if triggered by the Platform Operator. This might appear unexpected to the Application Developer due to their limited visibility.
Atomicity
When an Application Developer blocks Maintenance Updates, they do so for the entire set of dependencies in a Service Instance. This means that, for example, the a9s Backup Agent cannot be updated even though one might want to only block the updates of some other component, like Logstash.
Furthermore, even though the Application Developer does not see all types of updates, as explained in Usage Differences Between Platform Operator and Application Developer, they can block all types of updates using the a9s Service Dashboard or the a9s Public API V1.
Known Limitations
The following sections describe the limitations of Maintenance Updates.
No Maintenance Windows
Currently, the Platform Operator has freedom of choice over when they decide to perform the updates. Thus, it is recommended that the Application Developer should be informed by the Platform Operator so that they can be prepared for any downtimes regarding their Service Instances.
At the moment, solutions that would allow for the Platform Operator to define maintenance-windows are being considered with the intent of implementing them in the future.
Certificate Rotations Are Not Picked Up
Currently, expired certificates of the Service Instances will be updated whenever the Application Developer or the Platform Operator triggers an update. The current implementation does not collect such changes as Maintenance Updates, and therefore implies the following:
- The a9s Deployment Updater will not detect these Service Instances as outdated when their certificates are expired. In the absence of other known updates, running the errand will have no effect.
- For the same reasons discussed in Usage Differences Between Platform Operator and Application Developer, the Application Developer is not currently able to see when the certificates need rotating.
- If there are other types of updates available, and a Service Instance has expired certificates, the a9s Deployment Updater would cause the Service Instance to be redeployed, which might leave the Service Instance in a failed state. See Secure Communication with TLS for more details on handling certificate rotations.
*Redis is a registered trademark of Redis Ltd. Any rights therein are reserved to Redis Ltd. Any use by anynines GmbH is for referential purposes only and does not indicate any sponsorship, endorsement or affiliation between Redis and anynines GmbH.