Skip to content
On-Demand Service Broker (ODB) BOSH Release
Ruby Shell HTML
Branch: master
Clone or download
FelisiaM and blgm Update tests to check UpdateMode
[#167507099]

Co-authored-by: George Blue <gblue@pivotal.io>
Latest commit 24bf6dd Aug 12, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.dependabot Add dependabot to the repo Aug 7, 2019
.final_builds Metadata for final release on-demand-service-broker/0.31.1 @ 17a5e33 Jul 16, 2019
config now vendoring cf-cli instead of packaging it Apr 16, 2019
examples Update tests to check UpdateMode Aug 12, 2019
jobs provide maintenance_info.version in bosh link Aug 2, 2019
packages Pass CF properties and maintenance_info to upgrade-all-service-instan… Aug 1, 2019
releases/on-demand-service-broker Metadata for final release on-demand-service-broker/0.31.1 @ 17a5e33 Jul 16, 2019
scripts make call to (empty) go binary for register-broker Apr 17, 2019
spec Pass CF properties and maintenance_info to upgrade-all-service-instan… Aug 1, 2019
src Add UpdateMode to Variable for a BOSH manifest Aug 9, 2019
vbox create-and-upload-releases now works from any loc Mar 4, 2019
.envrc Initial commit Apr 24, 2017
.gitignore Add Code config directory to .gitignore Jan 31, 2019
.gitmodules Use vendored dependencies instead of adding it to the release Nov 21, 2017
CONTRIBUTING.md
Gemfile Added maintenance_info.version in broker spec Apr 16, 2019
Gemfile.lock Added maintenance_info.version in broker spec Apr 16, 2019
ISSUE_TEMPLATE.md Update ISSUE_TEMPLATE.md May 3, 2018
LICENSE Initial commit Apr 24, 2017
NOTICE Initial commit Apr 24, 2017
README.md Updated formatting Mar 15, 2019
Rakefile Initial commit Apr 24, 2017

README.md

on-demand-service-broker-release

A BOSH release for a Cloud Foundry on-demand service broker.

The broker deploys any service release on demand. One service instance corresponds to one BOSH deployment.

To create the release, ensure you are using the Bosh CLI v2.0.48+.

User Documentation

Full user documentation can be found here.

Getting Started with ODB

Follow this guide to try out an example product.

Creating a ODB Based Service

We have an SDK to start you off building on demand services. This helps you create service adapters, required by the ODB to deploy on demand instances of your BOSH release

Packaging for Pivotal Cloud Foundry (PCF)

Once you have an ODB integration completed for your service you may wish to create a tile for the PCF marketplace. You can follow this guide to tile development.

Contributing

Releases and versioning

  • The on-demand services SDK is pre-1.0.0 and uses semantic versioning.
    • This means that we reserve the right to release breaking changes in minor versions.
  • Breaking changes will always be clearly flagged in release notes.
  • We do not backwards apply patches, as no version other than the current is in support.

A note on breaking changes

There are three different categories of breaking changes when talking about ODB

  • Behavioural/Functional breaking changes
  • Manifest breaking changes
  • SDK Interface breaking changes

It is safe to assume that, from version x to version x+1, ODB will not introduce Behavioural/Functional breaking changes. We may introduce new functionality, but it will be feature flagged and off by default (in most cases). Keep in mind that we might remove a feature flag (or most likely turn it on by default) from version x to version x+2.

While we try our best to not introduce Manifest or SDK Interface breaking changes, they are the most likely to occur in a minor bump. It usually means that the service adapter author will need to update the signature of their functions to continue to use the SDK. Note that changing the signature doesn’t enable the feature, as it usually needs an updated manifest with the feature flag turned on.

Support

The on-demand services SDK is not an end customer-facing product, and as such we do not have an official support policy. Our unofficial policy is that only the current (latest) version is supported. We do not maintain pipelines or testing for any branch of our codebase other than master.

There have been situations where we have released patch updates, e.g. 0.21.2 where we had to downgrade golang due to a cert validation issue, but this was classified as a patch due to the content of the release (small dependency change) and we did not backport the patch to any previous version.

Best practice for maintaining ODB in your tile

We recommend that you float ODB versions and bump all supported tiles whenever a new ODB version is available, in order to ensure all the latest security patches and bug fixes reach your end users (in case you want to know more about this strategy, RabbitMQ for PCF and Redis for PCF teams have been doing this successfully). In the vast majority of cases we use feature flags to ensure you stay in control of when you introduce new features to your users.

Availability of old versions

Whilst we have no official support policy, we remove all ODB versions released more than nine months ago from availability on pivnet. This is in keeping with Pivotal tiles’ official support policy. We remove docs for old versions accordingly, though they are still available in PDF format (e.g. 0.20).

You can’t perform that action at this time.