The a9s Service Broker can provide different services and service plans. Which services and service plans are provided can be configured in the specific service config for each service. e.g. the postgresql.yml.example
You can have a list of services under the key
services. Here are a list of
properties you can use to setup your service and their descriptions.
|name*||string||The name of the Service Offering. MUST be unique across all Service Offering objects that are returned in this response. MUST be a non-empty string. Using a CLI-friendly name is RECOMMENDED.|
|guid*||string||An identifier used to correlate this Service Offering in future requests to the Service Broker. This MUST be globally unique such that Platforms (and their users) MUST be able to assume that seeing the same value (no matter what Service Broker uses it) will always refer to this Service Offering. MUST be a non-empty string. Using a GUID is RECOMMENDED.|
|description*||string||A short description of the service. MUST be a non-empty string.|
|label*||string||Label used by a9s Service Broker.|
|version*||string||The version of the service (eg. 10 for PostgreSQL 10)|
|bindable*||boolean||Specifies whether service instances of the service can be bound to applications. This specifies the default for all plans of this service. Plans can override this field (see Service Plans Documentation).|
|requires||array of strings||A list of permissions that the user would have to give the service, if they provision it. The only permissions currently supported are |
|tags||array of strings||Tags provide a flexible mechanism to expose a classification, attribute, or base technology of a service, enabling equivalent services to be swapped out without changes to dependent logic in applications, buildpacks, or other services. E.g. mysql, relational, redis, key-value, caching, messaging, amqp.|
|documentation_url||string||Link to the documentation of your service|
|metadata||JSON object||An opaque object of metadata for a service offering. Controller treats this as a blob. Note that there are conventions in existing brokers and controllers for fields that aid in the display of catalog data.|
|dashboard_client||object||Contains the data necessary to activate the Dashboard SSO feature for this service.|
|plans||array of objects||A list of plans for this service, schema is defined here. MUST contain at least one plan.|
|plans-to-test-for-release-update*||array of strings||These plans will be tested when the platform is updated to a new version. The |
|plans-to-test*||array of strings||These are the plans that are configured for the service broker and that should be tested. The |
|planupdates-to-test*||array of strings||These plans will be tested when the service is updated to another plan, e.g: |
keys marked by an
description: 'This is a service creating and managing dedicated PostgreSQL service instances and clusters, powered by the anynines Service Framework'
tags: ['sql', 'database', 'object-relational', 'consistent']
displayName: "a9s PostgreSQL 10"
- See Service Plan documentation for further details