harbor/make/photon/db/initial-registry.sql

CREATE DATABASE registry ENCODING 'UTF8';
\c registry;

CREATE TABLE schema_migrations(version bigint not null primary key, dirty boolean not null);
Initialise Harbor DB schema in Harbor UI/adminserver container This commit fixes #5040, the harbor-db image will only contain empty databases, and harbor ui container will use migrate tool to run initial SQL scripts to do initialization. This is helpful for the case to configure Harbor against external DB or DBaaS like RDS for HA deployment However, this change will results some confusion as there are two tables to track schema versions have been using alembic for migration, for this release we'll try to use alembic to mock a `migration` table during upgrade so the migrator will be bypassed, in future we'll consider to consolidate to the golang based migrator. Another issue is that the UI and adminserver containers will access DB after start up in different congurations, can't ensure the sequence, so both of them will try to update the schema when started up. 2018-06-27 11:49:46 +02:00			`CREATE DATABASE registry ENCODING 'UTF8';`
Create shcema migration table in DB container The migrate tool will try to create table schema_migration upon opening the connection to DB. This will cause error when there are multiple instance of adminserver trying to access the migrator upon start. This commit move the creation of the table during the initialization of the DB container. Signed-off-by: Daniel Jiang <jiangd@vmware.com> 2018-10-12 11:17:31 +02:00			`\c registry;`
Initialise Harbor DB schema in Harbor UI/adminserver container This commit fixes #5040, the harbor-db image will only contain empty databases, and harbor ui container will use migrate tool to run initial SQL scripts to do initialization. This is helpful for the case to configure Harbor against external DB or DBaaS like RDS for HA deployment However, this change will results some confusion as there are two tables to track schema versions have been using alembic for migration, for this release we'll try to use alembic to mock a `migration` table during upgrade so the migrator will be bypassed, in future we'll consider to consolidate to the golang based migrator. Another issue is that the UI and adminserver containers will access DB after start up in different congurations, can't ensure the sequence, so both of them will try to update the schema when started up. 2018-06-27 11:49:46 +02:00
Create shcema migration table in DB container The migrate tool will try to create table schema_migration upon opening the connection to DB. This will cause error when there are multiple instance of adminserver trying to access the migrator upon start. This commit move the creation of the table during the initialization of the DB container. Signed-off-by: Daniel Jiang <jiangd@vmware.com> 2018-10-12 11:17:31 +02:00			`CREATE TABLE schema_migrations(version bigint not null primary key, dirty boolean not null);`