capi-release 1.47.0 is marked as having downtime issues,
so we rolled back to capi-release 1.46.0 in cf-deployment.
Teams that have been using the release-candidate
branch of cf-deployment may notice problems in their pipelines,
caused by the fact that capi-release 1.47.0 included a database migration that got rolled back as well.
Steps provided here should help teams resolve this issue.
To un-bork your environment based on release-candidate
,
you can take the following steps:
- SSH to the API VM so that you can target the database node:
bosh ssh api/0
- Install a mysql client
sudo -i
apt-get install mysql-client
- Connect to the database
mysql -h <host> -u <username> -p
- Drop the
encyrption_key_label
column from the table:
> alter table env_groups drop column encryption_key_label;
> alter table service_brokers drop column encryption_key_label;
> alter table service_bindings drop column encryption_key_label;
> alter table service_instances drop column encryption_key_label;
> alter table service_keys drop column encryption_key_label;
> alter table apps drop column encryption_key_label;
> alter table buildpack_lifecycle_buildpacks drop column encryption_key_label;
> alter table buildpack_lifecycle_data drop column encryption_key_label;
> alter table droplets drop column encryption_key_label;
> alter table packages drop column encryption_key_label;
> alter table tasks drop column encryption_key_label;
- Make sure to remove the record of having run the migration, so that future capi-release versions will make sure to run it again:
> delete from schema_migrations where filename like '201712%';
> exit
- Clean up after yourself:
apt-get remove mysql-client
exit
Downgrade Caution
If you had any apps that were created/updated while on
capi-release
1.47.0
you may run intoUnknownError
s from the API while interacting with them after downgrading CC. This would affect other tables that have encrypted columns as well (e.g. service bindings).Looking at the logs you'll see something like this:
CAPI Release
1.47.0
had some changes to how CC encrypts data in its database and one of these changes was that we switched to a 16-byte salt while1.46.0
used an 8-byte salt. To get around this either delete the affected rows from the db or upgrade CC back to1.47.0
where the updated code can handle the longer salts.