Apply suggestions from code review

Co-authored-by: Alex Unger <6905948+refs@users.noreply.github.com>
This commit is contained in:
Jörn Friedrich Dreyer
2020-12-09 15:48:11 +01:00
committed by GitHub
parent 7fa0bf1d92
commit cca8cb4386
2 changed files with 4 additions and 6 deletions

View File

@@ -8,7 +8,7 @@ Technical Story: [File system based indexing](https://github.com/owncloud/ocis-a
## Context and Problem Statement
To set up HA or a geo replicated setup we need to persist accounts in a distributed way. Furthermore, the bleve index makes the accounts service stateful, which we wand to avoid for a scale out deployment.
To set up High Availability (HA) or a geo-replicated setup we need to persist accounts in a distributed way. Furthermore, the [bleve](https://github.com/blevesearch/bleve) index makes the accounts service stateful, which we want to avoid for a scale out deployment.
## Considered Options
@@ -17,7 +17,7 @@ To set up HA or a geo replicated setup we need to persist accounts in a distribu
## Decision Outcome
Chosen option: "Persist users in a CS3 storage", because we have one service less running and can rely on the filesystem for geo replication and HA.
Chosen option: "Persist users in a CS3 storage", because we have one service less running and can rely on the filesystem for geo-replication and HA.
### Positive Consequences <!-- optional -->

View File

@@ -1,4 +1,4 @@
# 3. Outsource Usermanagement
# 3. Outsource User Management
* Status: accepted <!-- optional -->
* Deciders: @butonic, @mbarz, @kfreitag, @hd, @pmaier1 <!-- optional -->
@@ -13,7 +13,7 @@ To attach metadata like shares to users ownCloud relies on persistent, non-reass
## Decision Drivers <!-- optional -->
* OCIS should be a single binary that can run out of the box without external dependencies like an LDAP server.
* Time: we want to build a release candiddate asap.
* Time: we want to build a release candidate asap.
## Considered Options
@@ -59,7 +59,6 @@ Currently, the accounts service is the source of truth and we use it to implemen
* Good, because we can manage users out of the box
* Good, because we can persist accounts in a CS3 storage provider
* Bad, because it maintains a separate user repository: it needs to either learn or sync users.
* … <!-- numbers of pros and cons can vary -->
### Move accounts functionality to GLauth and name it accounts
@@ -88,4 +87,3 @@ We should use an existing ldap server and make GLauth a drop in replacement for
* Good, because we can use the CS3 user proviter with the existing ldap / rest driver.
* Bad, because OCIS admins may not have the rights to manage role assignments. (But this is handled at a different department.)
* Bad, because OCIS admins may not have the rights to disable users if an external LDAP is used instead of the drop in GLauth.
* … <!-- numbers of pros and cons can vary -->