Subsuming a Amazon RDS for PostgreSQL (Beta) Instance

This topic describes moving an Amazon Relational Database Service (Amazon RDS) for PostgreSQL Instance from the VMware Tanzu Service Broker for AWS tile to the Tanzu Cloud Service Broker for AWS tile.

This process of moving control of an instance from one broker tile to another is called subsuming the instance.

About Subsuming an Amazon RDS for PostgreSQL Instance

Because the VMware Tanzu Service Broker for AWS (hereafter: “the legacy broker”) tile is going out of support, it is important to move PostgreSQL instances that were created by the legacy broker over to the Cloud Service Broker for AWS.

Subsuming the instance allows you to move the PostgreSQL instance from the control of one broker to the control of another without migrating the data.

After the subsuming process, you can manage the instance and the associated PostgreSQL instance just like any other service instance.

For general information about the VMware Tanzu Service Broker for AWS tile, see VMware Tanzu Service Broker for AWS.

Overview of the Process

Detailed steps for subsuming are given below. However, the outline of the process is:

Create a new Cloud Service-brokered instance.
Import information about the PostgreSQL instance using the “subsume” plan in the Cloud Foundry Marketplace.
Unbind apps from the legacy broker’s instance.
Bind apps to the new Cloud Service-brokered instance.
Purge the connections between the legacy-brokered instance and the PostgreSQL instance.
Restage any apps which were connected to the legacy PostgreSQL instance.

Prerequisite

Before you can subsume a PostgreSQL instance, you must have the admin password for the database. If you do not have the original password for the PostgreSQL Database, you must reset it in order to subsume the database.

Find instructions on how to reset the password for your PostgreSQL database on the AWS website.

Subsume a VMware Tanzu Service Broker for AWS PostgreSQL Instance

Caution The subsume process is potentially destructive. VMware recommends creating a manual backup of your Amazon RDS instance before attempting this procedure. For how to backup an Amazon RDS DB instance, see the AWS Documentation.

To subsume control of an existing legacy PostgreSQL instance to the Cloud Service Broker for AWS:

Get the legacy PostgreSQL instance details by running:

cf service LEGACY-SERVICE-INSTANCE

Where is LEGACY-SERVICE-INSTANCE is the name of the PostgreSQL instance to transfer control of to Cloud Service Broker for AWS

For example:

$ cf service my-old-instance
name:             my-legacy-instance
service:          aws-rds-PostgreSQL
tags:
plan:             basic
description:      Create and manage Amazon RDS PostgreSQL deployments
documentation:    https<span>:</span>//aws.amazon.com/rds/postgresql/
dashboard:
service broker:   aws-services-broker

Showing status of last operation from service my-legacy-instance...

status:    create succeeded
message:   Instance identifier(s) : [e7c0ac8a-0416-11eb-ae0e-3bbe060ffff9]
started:   2020-09-15T21:30:41Z
updated:   2020-09-15T21:34:53Z

There are no bound apps for this service.

Upgrades are not supported by this broker.

Record the AWS resource ID in Instance identifier(s).

Create a new PostgreSQL service instance using Cloud Service Broker for AWS and import the existing legacy-provisioned resource by choosing the “subsume” plan and including the metadata as shown:
```
cf create-service csb-aws-postgresql subsume NEW-SERVICE-INSTANCE -c '{{"aws_db_id":"AWS-RESOURCE-ID","admin_password":"ADMIN-PASSWORD"}}'
```
Where:
- NEW-SERVICE-INSTANCE is a name you choose for the new service instance that Cloud Service Broker for AWS creates to replace legacy PostgreSQL service instance.
- ADMIN-PASSWORD is the admin password for the database. See Prerequisite above.
- AWS-RESOURCE-ID is the instance identifier from the output of step 1 above.
For example:
```
$ cf create-service csb-aws-postgresql subsume my-csb-aws-instance \
-c '{"aws_db_id":"e7c0ac8a-0416-11eb-ae0e-3bbe060ffff9","admin_password":"example-PA55W0RD"}'
```
Disconnect the app from the legacy service binding by running:
```
cf unbind-service APP-NAME LEGACY-SERVICE-INSTANCE
```
Where:
- APP-NAME is the app using the PostgreSQL instance.
- LEGACY-SERVICE-INSTANCE is the name of the VMware Tanzu Service Broker for AWS-brokered PostgreSQL instance.
For example:
```
$ cf unbind-service my-app my-old-instance
```
Bind the app to the new service instance by running:
```
cf bind-service APP-NAME NEW-SERVICE-INSTANCE
```
Where NEW-SERVICE-INSTANCE is the name of the Cloud Service Broker for AWS service instance that you created in step 2 above.

For example:
```
$ cf bind-service my-app my-csb-aws-instance
```
Because Cloud Service Broker for AWS creates new credentials at bind time, this creates new binding credentials for the app.
Restage the app:
```
cf restage APP-NAME
```
Remove record of the old VMware Tanzu Service Broker for AWS-brokered PostgreSQL instance and any child objects from Cloud Foundry by running:
```
cf purge-service-instance LEGACY-SERVICE-INSTANCE
```
For example:
```
$ cf purge-service-instance my-old-instance
```
Caution Do not run cf delete-service because then the VMware Tanzu Service Broker for AWS deletes the AWS resource, that is, the database.

Next Steps

When all VMware Tanzu Service Broker for AWS-brokered service instances for all apps have been moved to Cloud Service-brokered instances, you can uninstall the VMware Tanzu Service Broker for AWS tile from Ops Manager.