Skip to content

Commit

Permalink
Update subsume-aws-postgres.md
Browse files Browse the repository at this point in the history
Updated with Sridhar
  • Loading branch information
omerbensaadon authored Sep 25, 2020
1 parent defc2d3 commit e26d353
Showing 1 changed file with 18 additions and 21 deletions.
39 changes: 18 additions & 21 deletions docs/subsume-aws-postgres.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,50 +4,47 @@ It is possible to subsume control over an existing Postgres database instance th

> **_WARNING:_** Some import strategies may be destructive to resources and data. Please read and understand the processes before implementation. If possible, test these strategies on test services and apps before applying them to important services and apps.
> **_WARNING:_** Known issue, if you bind subsumed service to existing applicaiton, It creates new user credentials. Make sure this user has right permissions to ALTER and DROP existing objects or tabels.
> **_KNOWN ISSUE:_** Because of a few shortcomings of PostgreSQL, please me sure to follow the steps for importing services very closely. There is an issue where if the Legacy Service Instance and the newly provisioned CSB Service Instance are both bound to the same app, it will be impossible to unbind the Legacy Service Instance from the app.
## Overview

The basic steps to subsume control of an existing MSSQL database instance are:
The basic steps to subsume control of an existing AWS Postgres database instance are:

1. `cf create-service csb-aws-postgresql-subsume current <new service instance> -c '{...}'` to import the current state of the service instance.
2. `cf unbind-service <existing app> <postgres service instance>` to disconnect the app from the AWS service binding.
3. `cf bind-service <existing app> <new service instance>` to bind the app to the new service instance.
4. `cf purge-service-instance <aws service broker instance>` to make CF forget about the AWS managed service instance. *If you `cf delete-service <masb service instance>`, AWS Broker will delete the Postgres resource! Don't do this!*

## Importing steps
The following steps are followed to import services of a legacy service broker.
* Create a new subsume service yml file in AWS broker pak and add it to the manifest.yml. [Sample subsume service](https://github.com/pivotal/cloud-service-broker/blob/master/aws-brokerpak/aws-postgres-subsume.yml)
* Create terraform these terraform files.
* ``provider.tf``
* ``main.tf``
* ``variables.tf``
* ``outputs.tf``
* Update ``provider.tf ``with corresponding provider.
* Copy the resource block for the serivce you want to import.
* Create admin password variable in ``varialbes.tf``. This value is used for creating new credentials when binding the app.
* Build and deploy brokerpak.
* To update the service, add the fields under
[import_parameter_mappings](https://github.com/pivotal/cloud-service-broker/blob/master/aws-brokerpak/aws-postgres-subsume.yml#L36), [user_inputs](https://github.com/pivotal/cloud-service-broker/blob/master/aws-brokerpak/aws-postgres-subsume.yml#L56) and in [variables.tf](https://github.com/pivotal/cloud-service-broker/blob/master/aws-brokerpak/terraform/subsume-vmware-aws-postgres/postgres-variables.tf#L2).
### Postgres Server Administrator Password
The administrator password for the database cannot be automatically discovered. The user must provide it for the import to work. Get the Postgres Server administrator password. This was probably set when the server was created.

* Subsume the Database Instance
```bash
cf create-service csb-aws-postgresql-subsume small csb-subsume-service -c '{"aws_db_id":"<db_instance_id>","admin_password":"<password>","region":"<region>"}'.
```
```bash
cf create-service csb-aws-postgresql-subsume small csb-subsume-service -c '{"aws_db_id":"<db_instance_id>","admin_password":"<password>","region":"<region>"}'.
```
## Unbind Application from Old Service Instance
To release the MASB provided binding, unbind the app from the old service instance.
```bash
cf unbind-service <application> <masb instance>
cf unbind-service <application> <legacy instance>
```

## Bind Application to New (Subsumed) Service Instance
To create a new binding from the new service instance
```bash
cf bind-service <application> <new intance name>
```
Known issue arround user postgres [roles](https://docs.pivotal.io/aws-services/postgres.html)

## Assign User Permissions to CSB Postgres User
Unfortunately, due to a known issue related to [user roles in Postgres](https://docs.pivotal.io/aws-services/postgres.html) if you bind the subsumed service to an existing applicaiton, it creates new user credentials. Make sure this new user has right permissions to ALTER and DROP existing objects or tables by running the following commands:

* Connect to the DB Instance Running PostgreSQL in AWS (See documentation here: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToPostgreSQLInstance.html)

* If the instance of PostgreSQL you are consuming was provisioned by the legacy [PCF Service Broker for AWS](https://docs.pivotal.io/aws-services/index.html), execute the following:

```bash
# SET ROLE binding_group;
```


## 🚨 Purge Old Service Instance 🚨
CF will still have a record of the old service instance. Use `cf purge-service-instance` to purge that record. *Do not use `cf delete-service` as AWS Broker will delete the service instance that the CSB broker should now be in charge of!*
Expand Down

0 comments on commit e26d353

Please sign in to comment.