Fixes#11885
This part will not by default be packaged into release.
A README.md will be added in another commit.
Signed-off-by: Daniel Jiang <jiangd@vmware.com>
To fetch vulnerability database updated time of the Clair had moved to
the Clair adapter so removes the initialization of clair db in the core.
Signed-off-by: He Weiwei <hweiwei@vmware.com>
1. Remove `common/quota` package.
2. Remove functions about quota in `common/dao` package.
3. Move `Quota` and `QuotaUsage` models from `common/models` to
`pkg/quota/dao`.
4. Add `Count` and `List` methods to `quota.Controller`.
5. Use `quota.Controller` to implement quota APIs.
Signed-off-by: He Weiwei <hweiwei@vmware.com>
1, Leverage go v1.13 new error feature
2, Define genernal error OCI format, so that /v2 API could return a OCI compatible error
Signed-off-by: wang yan <wangyan@vmware.com>
This commit mitigates the situation when more then one adminserver is
deployed and there may be duplication error when they try to initialize
the configuration to DB.
Signed-off-by: Daniel Jiang <jiangd@vmware.com>
The sslmode of the connection with postgresql is hardcoded as "disable" currently, this commit expose it as an environment variable so that users can configure it
Signed-off-by: Wenkai Yin <yinw@vmware.com>
This commit moves the database schema upgrading after database initialization. The init will test TCP connection.
Signed-off-by: Wenkai Yin <yinw@vmware.com>
This commit make update to remove the code from ui container to init the
DB schema. As UI has dependency on admin server, so it's safe to assume
adminserver has to be ready first. Regardless the setting of the config
store of admin server, it will try to access and intialize the schema of
database.
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.
