This topic tells you how to upgrade Tanzu Cloud Service Broker for AWS. The following sections have information about upgrading to v1.3.0.

Amazon RDS for MySQL

The following sections describe changes for Amazon RDS for MySQL.

Unsecured connections are no longer supported

All connections in RDS MySQL instances must use TLS encryption. This change is applied to previously existing instances after upgrading or binding recreation. For connections and binding creation to continue to work, you must install the AWS certificate bundle in Ops Manager.

Restoring brokerpak-provided plans

From this version onwards, MySQL plans are no longer provided with the brokerpak. If you have Amazon RDS for MySQL instances that you want to maintain, you must add previously provided plans through the tile. For more information, see Add previously provided pre-configured plans.

If you instead want to delete all previously created Amazon RDS for MySQL service instances, you must delete them before upgrading Cloud Service Broker for AWS to this version.

To remove the instances from the broker, run:

cf delete-service SERVICE-NAME

To remove instances from Cloud Foundry, but retain them in the IaaS, run:

cf purge-service-instance

Caution: You cannot edit plan properties during a provision or update operation.

Changing custom plans

Make the following changes to existing custom plans before upgrading.

Set storage_type

If you have custom plans already configured for MySQL, you must change the configuration. This is because the new storage_type property is io1 by default, which attempts to move all service instances into a new storage type from the general purpose (gp2) type that they are on currently.

To ensure that no unintended changes happen to your existing instances, add the storage_type property to your plan with value gp2. For example:

  {
    "name": "my-custom-plan",
    "id": "dd448d6e-1d71-11ed-9974-77a0c9ef0141",
    "description": "Custom plan",
    "cores": 2,
    "storage_gb": 5,
    "mysql_version": 5.7,
    "storage_type": "gp2"
  }

If you decide to change your old plans to use the io1 value, set storage_gb to at least 100 GB, because this is the minimum value that this type of disk supports. For more information, see the AWS documentation.

Set storage_encrypted, multi_az, and storage_autoscale

When you update to the latest broker, all existing instances are upgraded to have storage encryption, Multi-AZ, and storage autoscaling activated.

To deactivate these settings, add storage_encrypted, multi_az, and storage_autoscale properties with the value false to existing custom plans before you upgrade the broker. For example:

  {
    "name": "my-custom-plan",
    "id": "dd448d6e-1d71-11ed-9974-77a0c9ef0141",
    "description": "Custom plan",
    "cores": 2,
    "storage_gb": 5,
    "mysql_version": 5.7,
    "storage_encrypted": false,
    "multi_az": false,
    "storage_autoscale": false
  }

Remove use_tls

If you have plans with the property use_tls configured, you must remove the property. This is because TLS connections are always enabled.

Amazon Aurora PostgreSQL-Compatible Edition (Beta)

The following sections describe changes for Amazon Aurora PostgreSQL-Compatible Edition (Beta).

Unsecured connections from the broker are no longer supported

Cloud Service Broker for AWS connections to Aurora PostgreSQL instances must use TLS encryption. For bind and unbind to work, you must install the AWS certificate bundle in Ops Manager.

Pre-Upgrade procedure

ImportantBefore upgrading, it is crucial to perform the checks suggested in this section. Failure to can cause the upgrade process to fail and leave the broker unable to manage your instances.

  • Check if services are up-to-date Execute the command:

    cf upgrade-all-services BROKER-NAME -check-up-to-date

    This command checks whether all services provided by the specified broker are up-to-date. An instance is considered not up-to-date if it is pending upgrade, or if it is an orphaned service instance.

  • Check for orphaned service instances For greater granularity, you can specifically check only orphan service instances by running this command:

    cf upgrade-all-services BROKER-NAME -check-deactivated-plans

    This checks for any service instances still using plans that have been deactivated. For more information, see Managing orphaned service instances documentation.

Upgrade procedure

To upgrade the Cloud Service Broker for AWS to a later version:

Review the deploy-all errand logs in the change log to verify that no errors occurred when upgrading instances.

To upgrade Cloud Service Broker for AWS:

  1. Before you stage the new tile version, verify that all service instances are up to date.

  2. Download the new version of Cloud Service Broker for AWS from VMware Tanzu Network.

  3. Stage and configure the tile by following the instructions in Installing with AWS.

  4. Make all the changes described in Upgrading to v1.4.

  5. Verify that your configuration complies with the important notes about upgrading service instances, especially regarding upgrading all instances to the config, plans, and beta offerings.

  6. Go to the Ops Manager Installation Dashboard.

  7. Click Review Pending Changes and then click Apply Changes.

  8. Review the deploy-all errand logs for any errors created because of the upgrade instances task.

Verify that service instances are up to date before upgrading the tile

Service instances that haven’t been upgraded with one version of the tile might not be upgradable by a later version. For this reason, verify that there are no service instances pending upgrade before staging the new version of the tile.

You can see whether there are instances with a pending upgrade by reviewing the deploy-all errand log for Cloud Service Broker for AWS. Alternatively, you can ensure all instances are up to date with the CLI plug-in and the -dry-run flag, which outputs the list of instances pending upgrade.

You can see whether there are instances with a pending upgrade by using the CLI plug-in. For more information, see ensuring all instances are up to date with the CLI plug-in.

If you find instances that are pending upgrade, follow the upgrading instructions for your current version.

Important notes about upgrading service instances

Before you start upgrading service instances, see the following notes:

  • Selecting the Upgrade all services check box:

    If the Upgrade all services check box is not selected, service instances are not upgraded during installation. These instances become unmanageable by the broker. Any operations on that instance, such as update, bind, unbind, or delete, are blocked until you run the upgrade task. You can run the upgrade task at any time before upgrading the product to a later version. See Upgrade All Service Instances configuration for information about how to configure this task. Alternatively, run the upgrade at a later stage by using the CLI plug-in.

  • Selecting the Enable Beta offerings check box:

    If the Enable Beta offerings check box is not selected when applying changes, instances from those service offerings are not upgraded. These instances become unmanageable by the broker. Ensure that the Enable Beta offerings check box is selected if you have instances from those offerings you intend to keep updated.

  • Deleting custom plans:

    If you delete custom plans before upgrading all instances, instances from these plans are not upgraded. These instances become unmanageable by the broker. Delete plans after upgrading all instances, or see Release Notes for Cloud Service Broker for AWS and Upgrading to v1.4 to prevent conflicting upgrades.

  • Only upgrade the tile after all service instances are up to date:

    You can run the upgrade all instances task as many times as needed. If you prefer, run the upgrade all instances task by using the cf CLI instead of, or in addition to, running it through the tile. Failure to upgrade one or more instances does not cause the tile installation to fail. Review the deploy all errand logs to verify that all instances have upgraded.

Verify that all instances are up to date with the CLI plug-in

To verify that no instances are pending upgrade:

  1. Install the cf CLI UpgradeAllServices plugin on Cloud.

  2. Follow the instructions in the Usage section of the README in the upgrade-all-services-cli-plugin GitHub repository to perform a check-up-to-date command.

    check-up-to-date example:

    cf upgrade-all-services BROKER-NAME -check-up-to-date

    These command provide a list, from enabled plans, of instances that are pending upgrades, and a list of orphaned service instances that belong to deactivated plans. Manage all the instances listed before attempting a tile upgrade.

Upgrade instances through the CLI plug-in

To run the cf CLI plug-in:

  1. Install the cf CLI UpgradeAllServices plugin on Cloud Foundry.

  2. To run the upgrade, follow the instructions in the Usage section of the README in the upgrade-all-services-cli-plugin GitHub repository.

    For example:

    cf upgrade-all-services BROKER-NAME

Run the CLI plug-in with the -dry-run flag before applying the service instance upgrade to find out which instances are pending upgrade.

Upgrading to 1.4

Amazon Aurora PostgreSQL-Compatible Edition

The following sections describe changes for Amazon Aurora PostgreSQL-Compatible Edition.

Unsecured connections from the broker are no longer supported

Cloud Service Broker for AWS connections to Aurora PostgreSQL instances must use TLS encryption. For bind and unbind to work, the AWS certificate bundle must be installed in Ops Manager.

check-circle-line exclamation-circle-line close-line
Scroll to top icon