Upgrading Cloud Service Broker for GCP

Would you like to upgrade Tanzu Cloud Service Broker for GCP? This topic tells you about the Upgrade procedure, Upgrading service instances, and specific details about Upgrading to v1.2.1.

Pre-upgrade procedure

Important Before upgrading, it is crucial to perform the checks suggested in this section. Not doing so could 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. More details can be found in the Managing orphaned service instances documentation.

Upgrade procedure

To upgrade Cloud Service Broker for GCP:

Before you stage the new tile version, verify that all service instances are up to date.
Download the new version of Cloud Service Broker for GCP from Broadcom Support.
Stage and configure the tile by following the instructions in Installing with GCP.
Make all the changes described in Upgrading to v1.2.1.
Verify that your configuration complies with the important notes about upgrading service instances, especially regarding upgrading all instances of config, plans, and beta offerings.
Go to the Ops Manager Installation Dashboard.
Click Review Pending Changes and then click Apply Changes.
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. So 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 GCP. Alternatively, you can verify all instances are up to date with the CLI plug-in and the -dry-run flag, which outputs the list of instances pending upgrade.

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:

Select 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. For information about how to configure this task, see Upgrade All Service Instances configuration. Alternatively, run the upgrade at a later stage using the CLI plug-in.
Select 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. Verify that the Enable Beta offerings check box is selected if you have instances from those offerings that 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 GCP and Upgrading to v1.2.1 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:

Install the cf CLI UpgradeAllServices plugin on Cloud Foundry.
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:

Install the cf CLI UpgradeAllServices plugin on Cloud Foundry.
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 v1.2.1

Google MySQL

The following sections describe changes for the Google MySQL service.

Retiring beta instances

The Google MySQL service is now generally available. The service instances provisioned by the beta version of the Google MySQL service are no longer supported. You must remove the service instances from the supervision of Cloud Service Broker for GCP.

If all MySQL instances are not removed, the installation fails with the following error message:

Server error, status code: 502, error code: 270012, message: Service broker catalog is invalid:
Service names must be unique within a broker. Services with names ["csb-google-mysql"] already exist

There are two options for removing a service instances from the supervision of Cloud Service Broker for GCP:

Purge the service instance, in which case it is removed from Cloud Foundry but the database instance remains in GCP
Delete the service instance, which also deletes data

To purge a service instance:

Obtain credentials for the service instance. You can do this by creating a user through the Google Cloud Console, or by recovering the existing credentials from CredHub. For instructions, see the VMware Tanzu Support documentation.
Purge the service instances by running:
```
cf purge-service-instance SERVICE-INSTANCE
```
For more information about the command, see the Cloud Foundry CLI documentation.
Upgrade to Cloud Service Broker for GCP v1.2.1
Use the credentials to manage the data by using one of these methods:
- Option 1: Migrate the data to a newly created MySQL instance. For more information, see Migrating to a Google Cloud SQL for MySQL Instance.
- Option 2: Create a user-provided service instance for further consumption by applications.

Changing custom plans

Make the following changes to existing custom plans before upgrading.

Set `tier` for the MySQL service

The old property cores is removed. To define compute and memory capacity, you must use tier instead.

If you have custom plans already configured for MySQL, you must change the configuration to use tier. For example:

  {
    "name": "my-custom-plan",
    "id": "dd448d6e-1d71-11ed-9974-77a0c9ef0141",
    "description": "Custom plan",
    "tier": "db-n1-standard-2",
    "storage_gb": 10,
    "mysql_version": "MYSQL_8_0"
  }

For more information about the machine types, see the Google Cloud documentation.

Set `authorized_network_id` for the MySQL service

The old property authorized_network is removed. To define the ID of the Google Compute Engine network to which the instance is connected, you must use authorized_network_id instead.

If you have custom plans already configured for MySQL, and you included the authorized_network property, you must change the configuration to use authorized_network_id. For example:

  {
    "name": "my-custom-plan",
    "id": "dd448d6e-1d71-11ed-9974-77a0c9ef0141",
    "description": "Custom plan",
    "authorized_network_id": "projects/GCP_PROJECT/global/networks/VPC_NAME",
    "storage_gb": 10,
    "mysql_version": "MYSQL_5_7"
  }

Google Storage Bucket

The following sections describe changes for the Google Storage Bucket service.

About beta instances

The Google Storage Bucket service is now generally available. Keeping beta instances is discouraged because beta instances are not suitable for production.

You can choose to update the instances, but there are breaking changes that can affect the configuration of the plans you must define. For more information, see the following section, Restoring brokerpak-provided plans.

Restoring brokerpak-provided plans

From this version onwards, Google Storage Bucket plans are no longer provided with the brokerpak. If you have 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.

This version adds breaking changes that force the recreation of the bucket if the old plans are not correctly configured.

A change in the region forces the recreation of the bucket. Therefore, if the default region set by the operator in the tile configuration changes, you must add the region property to the old plan, setting the value equal to the old instance region.

For example, if you created the old instance by using the private plan, and using as default region the us-central-1, the plan must look like this:

{
    "name": "private",
    "id": "bbc4853e-8a63-11ea-a54e-670ca63cee0b",
    "description": "Private Storage bucket",
    "region": "us-central1",
    "metadata": {
      "displayName": "Private"
    }
}

If you created the old instance by using the public plan, and using as default region the us-central-1, the plan must look like this:

{
    "name": "public-read",
    "id": "c07f21a6-8a63-11ea-bc1b-d38b123189cb",
    "description": "Public-read Storage bucket",
    "region": "us-central1",
    "metadata": {
      "displayName": "Public Read"
    }
}

The default storage class now is MULTI_REGIONAL, which enables high availability across a large area. Previously, the default value was STANDARD. This storage class needs a large region like US.

If the old instance was created by using a storage class different from MULTI_REGIONAL, add the old instance storage class to match the parameters. If you don’t, the upgrade process tries to set the storage class to MULTI_REGIONAL by using the configured region. If the configured region is not a valid region for the MULTI_REGIONAL storage class configuration, the process is blocked. For more information about valid regions, see the Google Cloud documentation. See Configuration Parameters for more information.

For example, if you created the old instance by using the private plan, using as default region the us-central-1, and “STANDARD” as storage_class configuration, the plan must look like this:

{
    "name": "private",
    "id": "bbc4853e-8a63-11ea-a54e-670ca63cee0b",
    "description": "Private Storage bucket",
    "region": "us-central1",
    "storage_class": "STANDARD",
    "metadata": {
      "displayName": "Private"
    }
}

For example, if you created the old instance by using the public plan, using as default region the us-central-1, and “STANDARD” as storage_class configuration, the plan must look like this:

{
    "name": "public-read",
    "id": "c07f21a6-8a63-11ea-bc1b-d38b123189cb",
    "description": "Public-read Storage bucket",
    "region": "us-central1",
    "storage_class": "STANDARD",
    "metadata": {
      "displayName": "Public Read"
    }
}

Caution
You cannot edit plan properties during a provision or update operation. The same considerations must be taken into account for the customized plans you created.

If you instead want to delete all previously created service instances, delete them before upgrading Cloud Service Broker for GCP to this version.

To remove the instances from the broker and the IaaS, run:

cf delete-service SERVICE-NAME

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

cf purge-service-instance

Google Redis

The following sections describe changes for the Google Redis service.

Restoring brokerpak-provided plans

From this version onwards, Google Redis plans are no longer provided with the brokerpak. If you have 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.

Caution
Google Redis is a beta version and therefore not suitable for production.

If you instead want to delete all previously created service instances, delete them before upgrading Cloud Service Broker for GCP to this version.

To remove the instances from the broker and the IaaS, run:

cf delete-service SERVICE-NAME

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

cf purge-service-instance

Pre-upgrade procedure

Upgrade procedure

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

Important notes about upgrading service instances

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

Upgrade instances through the CLI plug-in

Upgrading to v1.2.1

Google MySQL

Retiring beta instances

Changing custom plans

Set tier for the MySQL service

Set authorized_network_id for the MySQL service

Google Storage Bucket

About beta instances

Restoring brokerpak-provided plans

Google Redis

Restoring brokerpak-provided plans

Set `tier` for the MySQL service

Set `authorized_network_id` for the MySQL service