1.3.0-rc1
Pre-releaseChanges in 1.3.0
Summary
- Bugfix - Purposely delay accounts service startup: #1734
- Bugfix - Add missing gateway config: #1716
- Bugfix - Fix accounts initialization: #1696
- Bugfix - Fix the ttl of the authentication middleware cache: #1699
- Change - Update ownCloud Web to v2.0.1: #1683
- Change - Update ownCloud Web to v2.0.2: #1776
- Enhancement - Remove the JWT from the log: #1758
- Enhancement - Update go-micro to v3.5.1-0.20210217182006-0f0ace1a44a9: #1670
- Enhancement - Update reva to v1.6.1-0.20210223065028-53f39499762e: #1683
- Enhancement - Add initial nats and kubernetes registry support: #1697
Details
-
Bugfix - Purposely delay accounts service startup: #1734
As it turns out the race condition between
accounts <-> storage-metadatastill remains.
This PR is a hotfix, and it should be followed up with a proper fix. Either:- block the accounts' initialization until the storage metadata is ready (using the registry)
or - allow the accounts service to initialize and use a message broker to signal the accounts the
metadata storage is ready to receive requests.
- block the accounts' initialization until the storage metadata is ready (using the registry)
-
Bugfix - Add missing gateway config: #1716
The auth provider
ldapandoidcdrivers now need to be able talk to the reva gateway. We added
thegatewayscvto the config that is passed to reva. -
Bugfix - Fix accounts initialization: #1696
Originally the accounts service relies on both the
settingsandstorage-metadatato be up
and running at the moment it starts. This is an antipattern as it will cause the entire service to
panic if the dependants are not present.We inverted this dependency and moved the default initialization data (i.e: creating roles,
permissions, settings bundles) and instead of notifying the settings service that the
account has to provide with such options, the settings is instead initialized with the options
the accounts rely on. Essentially saving bandwith as there is no longer a gRPC call to the
settings service.For the
storage-metadataa retry mechanism was added that retries by default 20 times to
fetch thecom.owncloud.storage.metadatafrom the service registry every500
miliseconds. If this retry expires the accounts panics, as its dependency on the
storage-metadataservice cannot be resolved.We also introduced a client wrapper that acts as middleware between a client and a server. For
more information on how it works further read here -
Bugfix - Fix the ttl of the authentication middleware cache: #1699
The authentication cache ttl was multiplied with
time.Secondmultiple times. This
resulted in a ttl that was not intended. -
Change - Update ownCloud Web to v2.0.1: #1683
Tags: web
We updated ownCloud Web to v2.0.1. Please refer to the changelog (linked) for details on the web
release. -
Change - Update ownCloud Web to v2.0.2: #1776
Tags: web
We updated ownCloud Web to v2.0.2. Please refer to the changelog (linked) for details on the web
release. -
Enhancement - Remove the JWT from the log: #1758
We were logging the JWT in some places. Secrets should not be exposed in logs so it got removed.
-
Enhancement - Update go-micro to v3.5.1-0.20210217182006-0f0ace1a44a9: #1670
- We updated from go micro v2 (v2.9.1) go-micro v3 (v3.5.1 edge). - oCIS runtime is now aware of
MICRO_LOG_LEVELand is set toerrorby default. This decision was made because ownCloud,
as framework builders, want to log everything oCIS related and hide everything unrelated by
default. It can be re-enabled by setting it to a log level other thanerror. i.e:
MICRO_LOG_LEVEL=info. - Updatedprotoc-gen-microto the latest
version. -
We're using Prometheus wrappers from go-micro.
- We updated from go micro v2 (v2.9.1) go-micro v3 (v3.5.1 edge). - oCIS runtime is now aware of
-
Enhancement - Update reva to v1.6.1-0.20210223065028-53f39499762e: #1683
- quota querying and tree accounting cs3org/reva#1405
-
Enhancement - Add initial nats and kubernetes registry support: #1697
We added initial support to use nats and kubernetes as a service registry using
MICRO_REGISTRY=natsandMICRO_REGISTRY=kubernetesrespectively. Multiple nodes can
be given withMICRO_REGISTRY_ADDRESS=1.2.3.4,5.6.7.8,9.10.11.12.