Skip to main content
Version: Develop

Service Catalog

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

Services Configuration

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.

Explanation

KeyTypeDescription
name*stringThe 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*stringAn 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*stringA short description of the service. MUST be a non-empty string.
label*stringLabel used by a9s Service Broker.
version*stringThe version of the service (eg. 10 for PostgreSQL 10)
bindable*booleanSpecifies 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).
requiresarray of stringsA list of permissions that the user would have to give the service, if they provision it. The only permissions currently supported are syslog_drain, route_forwarding and volume_mount.
tagsarray of stringsTags 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_urlstringLink to the documentation of your service
metadataJSON objectAn 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_clientobjectContains the data necessary to activate the Dashboard SSO feature for this service.
plansarray of objectsA list of plans for this service, schema is defined here. MUST contain at least one plan.
plans-to-test-for-release-update*array of stringsThese plans will be tested when the platform is updated to a new version. The smoke tests errand is the one responsible for executing these tests. The value for this key can be left empty []. See Service Plans for further information.
plans-to-test*array of stringsThese are the plans that are configured for the service broker and that should be tested. The smoke tests errand is the one responsible for executing these tests. The value for this key can be left empty []. See Service Plans for further information.
planupdates-to-test*array of stringsThese plans will be tested when the service is updated to another plan, e.g: postgresql-single-nano to postgresql-single-medium. The smoke tests errand is the one responsible for executing these tests. The value for this key can be left empty []. See the Service Plans documentation for further information.

NOTE:

keys marked by an * are required

Example

postgresql_service:
services:
a9s-postgresql10:
name: a9s-postgresql10
guid: fd4b5214-4755-457a-9fc0-c1caa7e7a203
description: 'This is a service creating and managing dedicated PostgreSQL service instances and clusters, powered by the anynines Service Framework'
label: a9s-postgresql
version: 10
bindable: true
requires: []
tags: ['sql', 'database', 'object-relational', 'consistent']
documentation_url: https://docs.anynines.com/
metadata:
displayName: "a9s PostgreSQL 10"
supportUrl: https://dssupport.anynines.com
documentationUrl: https://docs.anynines.com/
shareable: true
dashboard_client:
id: a9s-postgresql-dashboard-client-id
plans:
- See Service Plan documentation for further details
plans-to-test-for-release-update: []
plans-to-test: []
planupdates-to-test: {}