Skip to main content
Version: 72.0.0

Stop/Start

danger

Currently a9s PostgreSQL is the only Data Service that supports the usage of the Stop/Start feature.

Trying to apply the information contained on this document to an a9s Data Service aside from the ones mentioned above can leave the Service Instances in an irrecuperable state.

caution

This feature is currently in Beta.

The Stop/Start feature allows an Application Developer to remove the VMs belonging to a Service Instance when necessary and add them again later without losing any persistent data. This allows them to save on infrastructure costs during periods when the Service Instance is not needed.

Enable the Stop/Start Feature​

The Stop/Start feature is disabled by default in the a9s Public API. The Ops file enable-stop-start-feature.yml can be used to enable the feature by applying it to the different a9s Data Services.

note

To disable the Stop/Start feature, the a9s Data Services need to be deployed once more, without the Ops file.

warning

It is not recommend to leave any a9s Service Instances with the stopped status, if the feature is to be disabled. Thus, before disabling the feature, make sure to start all Service Instances that are currently stopped are either properly started or deleted.

Usage of the Stop/Start Feature​

For more information about the usage of the Stop/Start feature, see Common Features - Stop/Start Feature.

Expected Behavior​

  • Any attempt to bind an application to a stopped Service Instance, or to create a Service Key for it, will be rejected, as a stopped Service Instance doesn’t count as provisioned.

  • Any attempt to unbind an application, or to delete a Service Key, from a stopped Service Instance will be rejected, as a stopped Service Instance doesn’t count as provisioned.

  • Any attempt to update a custom parameter for a stopped Service Instance will be rejected, as a stopped Service Instance doesn’t count as provisioned.

  • Any attempt to update the Service Plan for a stopped Service Instance will be rejected, as a stopped Service Instance doesn’t count as provisioned.

  • Only the data stored on the persistent disk is retained and available again after a restart; all data in the memory and on the ephemeral disk is lost when a Service Instance is stopped.

  • Calling the start endpoint of the a9s Public API for a Service Instance in any state other than stopped will not trigger a BOSH task and instead will get the following error message:

    Service Instance is currently in the state '<Service Instance's state> and not in 'stopped'.

  • Calling the stop endpoint of the a9s Public API for a Service Instance in any state other than provisioned will not trigger a BOSH task and instead will get the following error message:

    Service Instance is currently in the state <Service Instance's state> and not in 'provisioned'.

Known Limitations​

  • The Application Developer cannot determine via the Cloud Foundry's cf CLI whether a Service Instance has been stopped or not.
  • If a binding, or a service key, for a Service Instance exists in CF, this Service Instance cannot be deleted as long as it is stopped.
  • Automated and periodic backups cannot take place for a stopped Service Instance, as the responsible process for triggering them cannot be executed.
  • When the a9s Deployment Updater, executed under the update strategy, encounters a Service Instance in the stopped state, the Service Instance will just be skipped. These skipped Service Instances will not affect the success of the a9s Deployment Updater. The amount of affected Service Instances can be seen in the output of the BOSH errand.
    • Due to this, stopped Service Instances will not be updated in any of the following scenarios:
      • A new version of the a9s Data Service is available.
      • A new feature, CVE fix, or bug fix is released.
      • Certificate rotation has taken place.