Upgrading Cloud Service Broker for Azure

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

Pre-upgrade procedure

ImportantBefore upgrading, it is crucial to perform the checks suggested in this section. Failure to do so can cause the upgrade 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

Important
When upgrading Cloud Service Broker for Azure, service instances might need to be upgraded. Failure to upgrade one or more instance does not cause the tile installation to fail.

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 Azure:

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 Azure from Broadcom Support.
Stage and configure the tile by following the instructions in Installing with Azure.
Make all the changes described in Upgrading to v1.4.
Verify that your configuration complies with the Important notes about upgrading service instances section later in this topic, 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. 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 last deploy-all errand log for Cloud Service Broker for Azure. Alternatively, you can verify that 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 any instances that are pending upgrades, 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. See Upgrade All Service Instances configuration for information on how to configure this task. Alternatively, you can run the upgrade at a later stage by 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 Azure 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:

Install the cf CLI UpgradeAllServices plug-in 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 plug-in 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.

Upgrade to v1.4

Upgrading to Azure Cache for Redis v6

New Redis v6 is now available through Cloud Service Broker for Azure.

Note
All brokerpak-provided plans set the Redis version to v4 to maintain compatibility with the instances already created. These plans are deprecated and removed from the brokerpak in future releases in favor of custom-defined plans in the tile. VMware recommends that you update all instances to use custom-defined plans instead.

To update to Redis v6:

Before updating the Redis version, read the Microsoft Azure upgrade recommendations and understand any possible consequences to the service.
Identify the instance that you want to update to use Redis v6.
Identify the plan used to create the instance by running:
```
cf service INSTANCE-NAME
```
Where INSTANCE-NAME is the name of the service to be updated.
Find the plan definition of the plan you identified. If it is a custom plan, you can find its definition in the tile configuration. If it is a brokerpak-provided plan, you can find the corresponding properties in the brokerpak definition.
If the plan is a custom plan, you can update the instance to use Redis v6 by running:
```
cf update-service INSTANCE-NAME -c '{"redis_version": "6"}'
```
Where INSTANCE-NAME is the name of the service to be updated.
If the plan is a brokerpak-provided one, you can either define a plan with or without a specified Redis version. Choose one of the following options:
- Option 1: Define the custom-created plan with a specified Redis version.
  1. Define a custom plan that specifies the Redis version. For example:
```
{
  "name": "custom-plan-v6",
  "id": "ba3d28f0-6b17-11ed-91ca-1f5af50ef86f",
  "description": "Custom plan",
  "sku_name": "Basic",
  "family": "C",
  "capacity": 1,
  "tls_min_version": "1.2",
  "firewall_rules": [],
  "redis_version": "6"
}
```
    Important
    All other service properties must match the plan the instance is already on. If you set the redis_version property in the plan, users cannot change that property during create or update instance operations.
  2. Update the instance to the new plan by running:
```
cf update-service INSTANCE-NAME -p NEW-PLAN-NAME
```
    Where NEW-PLAN-NAME is the name of the plan created in previous step.
- Option 2: Define a custom-created plan without a specified Redis version.
  1. Define a custom plan that does not specify the Redis version. For example:
```
{
   "name": "custom-plan-v6",
   "id": "ba3d28f0-6b17-11ed-91ca-1f5af50ef86f",
   "description": "Custom plan",
   "sku_name": "Basic",
   "family": "C",
   "capacity": 1,
   "tls_min_version": "1.2",
   "firewall_rules": []
}
```
    Important
    All service properties, other than name, id, and description, must match the plan the instance is already on.
  2. Update the instance to the new plan by running:
```
cf update-service INSTANCE-NAME -p NEW-PLAN-NAME -c '{"redis_version": "6"}'
```
    Where NEW-PLAN-NAME is the name of the plan created in previous step.