v1.3.0: New Services And Enhancements

WARNING: Please DO NOT use this release. This release contains buggy code that causes some user can't install OSBA correctly. (See #656 and #658) Please use the patch release v1.3.1.

This release of Open Service Broker for Azure brings a few new services and provides enhancements to existing services. Azure Redis and Azure Storage have also been promoted to "preview" services within the broker.

New service modules:

• Azure Application Insights
• Azure IoT hub
• Azure SQL Database Failover Group

Additionally, the following enhancements are present:

• Azure Cosmos DB service module:

  • Support enabling multi-master feature in provisioning step

• Azure PostgreSQL service module:

  • Add new preview service for supporting creating Azure PostgreSQL v10

• Azure Redis Cache service module:

  • All plans in Redis module are now in Preview

• Azure Service Bus service module(Breaking Change Warning):

  • Add new services to support creating queue and topic

• Azure SQL Database service module:

  • Existing databases can be imported to OSBA's management by a new service
  • Setting connection policy is supported

• Azure Storage service module(Breaking Change Warning):

  • Add new service to support creating general purpose v2 storage account
  • Make https config, access tier, and account type configurable
  • Support specifying a name for blob container
  • All plans in Storage module are now in Preview

This release also fixes a few bugs.

v1.2.0: Enhancements for Redis, MS SQL and CosmosDB

• Ability to run multiple OSBA against a single Redis
• Enhancements to Redis:
  • Make capacity and ssl configurable and make instance updatable
  • Premium Plan now supports private subnets and backups
• Added ability to register pre-existing MS SQL Server
• Added Experimental Cognitive Services (Text Analytics) Module
• Enhancements to CosmosDB
  • All plans in Cosmosdb module are now in Preview
• Various Bug Fixes

v1.1.0

Placeholder

v1.0.1

Placeholder

v1.0.0 -- General Availability

🎉 🎉 🎉 🎉

We're excited to announce that the Open Service Broker for Azure is now generally available!

Here's what's in the release

Most relational database services and plans (previously in preview) are now stable (without further changes from v0.12.0).

In accordance with semver, future modifications to these stable plans will be backwards compatible, with a notable exception being deprecation and eventual retirement if the underlying Azure services stop supporting the particulars of a given plan. (For example, if in the future Azure starts offering a new version of MySQL and eventually phases out and older version, the broker will no longer be able to offer that older version.) The stable services and plans include:

• PostgreSQL 9.6
• MySQL 5.7
• MS SQL 12.0
  • Plans based on / billed on the "DTU" model only
  • Plans based on / billed on the new "vCore" model remain in a preview status since the underlying Azure SQL service regards vCores themselves as preview

Other services in the broker that were previously preview or experimental have been removed. We plan to add them back slowly in future releases.

Some Details on the Internals

The storage schemas for instances, bindings, and asynchronous jobs have been stabilized (without further changes from v0.12.0). In accordance with semver, expect future, minor releases of the broker to be backwards compatible. In the event that modifications to schemas are required to facilitate future, minor releases, some automated migration path or conversion from legacy stored objects to a canonical, internal representation will be accounted for.

Enjoy!

This is the first stable release of the Open Service Broker for Azure. We hope you enjoy!

v0.12.0

• Service updates:
  • Relational database services and plans (currently in preview) are in what we anticipate will be their stable, GA state. This includes:
    • PostgreSQL
    • MySQL
    • MS SQL
  • Experimental services and plans have been removed, temporarily. Doing so has permitted us to focus resources on maximizing the stability of the relational database services and plans. Expect most services and plans to be reinstated and gradually stabilized in future minor releases.
• Internals:
  • Compliance with the OSB API specification has been improved. Functionality common to all services and plans has been further stabilized. Storage schemas are in what we anticipate will be their stable, GA state.

v0.11.0

• Service updates:
  • Cosmos (experimental):
    • Added ability to specify consistency policy on provision
    • Mongo:
      • Added Spring Data Connector URI to credentials returned from bind
    • SQL:
      • Added new plans to accommodate a variety of use cases:
        • Provision an account with a single database (basic / all-in-one option)
        • Provision an account only
        • Provision one or more databases in an existing account (advanced usage)
  • MS SQL (preview):
    • Services renamed to clearly indicate API version compatibility
  • MySQL (preview):
    • Services renamed to clearly indicate API version compatibility
    • Existing plans removed / re-written to support the new Azure Database for MySQL billing model (which changed when that service itself graduated from preview to GA)
  • PostgreSQL (preview):
    • Services renamed to clearly indicate API version compatibility
    • Existing plans retired / re-written to support the new Azure Database for PostgreSQL billing model (which changed when that service itself graduated from preview to GA)
  • Redis (experimental):
    • Added Spring Data Connector URI to credentials returned from bind
• Internals:
  • Added ability to designate services or plans as "end of life." As Azure itself (eventually) retires services (or versions of services), this will permit future releases of OSBA to hide services or plans from platforms like Kubernetes Service Catalog or Cloud Foundry and cease to provision instances of those services or plans while still retaining all the logic required to deprovision existing instances of those services or plans.

v0.10.0

Our v0.10.0 adds some exciting new capabilities to Open Service Broker for Azure (OSBA)!

As with recent releases, this release focuses largely on a specific module. In this release, it was CosmosDB. You can now provide IP filter rules to secure your CosmosDB deployment. We have also updated the CosmosDB service to enable provisioning of additional CosmosDB database account types. You can now use OSBA to provision the following types:

• DocumentDB
• MongoDB
• Table
• Graph

In addition to the work on the CosmosDB service, we've made a number of other enhancements to the broker in terms of general stability and usability. The most exciting of these changes is that all modules now provide JSON schema to describe their provisioning parameters! These are visible when you retrieve the catalog.

Here is an example of the MongoDB schema:

  $schema: http://json-schema.org/draft-04/schema#
  properties:
    ipFilters:
      description: IP Range Filter to be applied to new CosmosDB account
      properties:
        allowAccessFromAzure:
          default: ""
          description: Specifies if Azure Services should be able to access the CosmosDB
            account.
          enum:
          - ""
          - enabled
          - disabled
          type: string
        allowAccessFromPortal:
          default: ""
          description: Specifies if the Azure Portal should be able to access the CosmosDB
            account. If `allowAccessFromAzure` is set to enabled, this value is ignored.
          enum:
          - ""
          - enabled
          - disabled
          type: string
        allowedIPRanges:
          description: Values to include in IP Filter. Can be an IP Address or CIDR
            range.
          items:
            description: Must be a valid IP address or CIDR
            type: string
          type: array
      type: object
    location:
      description: The Azure region in which to provision applicable resources.
      type: string
    resourceGroup:
      description: The (new or existing) resource group with which to associate new
        resources.
      type: string
    tags:
      additionalProperties:
        type: string
      description: Tags to be applied to new resources, specified as key/value pairs.
      type: object
  type: object

v0.9.0-alpha

Our v0.9.0-alpha release is a major step forward in the stability and usefulness of our broker.

Beginning with this release, our support for all three relational databases (PostgreSQL, MySQL, and MS SQL) includes three different types of service:

1. An "all-in-on" option that provisions both a DBMS (server) and a single database upon that DBMS. This is the easiest path to provisioning a new database, but because databases provisioned in this way exist in a 1:1 ration with the servers that host them, is perhaps not the most cost-effective option.

2. A "DBMS only" option that provisions just a DBMS (server), but no databases thereupon. This is useful combined with...

3. A "database only" option that provisions just a database on a DBMS of your choice. (See above.) This option enables multiple databases to be provisioned on a single server for greater cost efficiency. Note that if the request to provision a database references a DBMS that does not yet exist or has not yet completed its own provisioning process, the broker will intelligently defer database provisioning until it is able to proceed.

Please reference documentation and examples for further details on these new capabilities and note that while reshaping our support for these services as described above, service and plan names have changed. (Once the broker is stable and GA, service and plan names will be treated as immutable. For now, we have the luxury of tweaking these names until we are satisfied with them and we are availing ourselves of that opportunity whilst it exists.)

Lastly, another huge stride forward in our support for all three of the relational databases is the ability to specify multiple firewall rules when provisioning "all-in-one" or "DBMS only" services.

The maturity of our support for these three services has taken such a leap forward that we're promoting all three from an experimental state to preview. This expresses our confidence that our support for these services is coalescing into something we believe is a good approximation of what they will look like in their final, stable state. Note that we still reserve the right to make breaking changes, if needed, until the broker itself is declared GA.

v0.8.0-alpha

add api version header to api requests from the cli (#244)