mirror/opencloud
1
0
Fork 0
mirror of https://github.com/opencloud-eu/opencloud.git synced 2026-05-06 23:23:18 -04:00
Code Issues Packages Projects Releases Wiki Activity

[docs-only] Minor docs edits

Browse Source
This commit is contained in:
Phil Davis
2022-06-13 12:39:08 +05:45
parent 588293fd19
commit 199de9a3cc
8 changed files with 30 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/architecture/efficient-stat-polling.md
View File

@@ -123,7 +123,7 @@ graph TD
{{</mermaid>}}
But how can maries client detect the change?
But how can Marie's client detect the change?
We are trading writes for reads: the client needs to stat the own tree & all shares or entry points into other storage trees.

24
docs/architecture/protocol-changes.md
View File

@@ -79,10 +79,10 @@ sequenceDiagram
participant proxy
participant ocDAV1 as ocDAV [a-k]
participant ocDAV2 as ocDAV [l-z]
Note right of Client: {spaceid} identifies the space<br>{relative/path} is relative to the space root
Client->>+proxy: PROPFIND /dav/space/{spaceid}/{relative/path}
alt username starting with a-k
proxy->>+ocDAV1: PROPFIND /dav/space/{spaceid}/{relative/path}
Note right of ocDAV1: translate ownCloud flavoured webdav<br>into CS3 API requests
@@ -105,8 +105,8 @@ sequenceDiagram
participant ocDAV
participant Gateway
participant StorageRegistry
participant StorageProvider1 as StoregeProvider [a-k]
participant StorageProvider2 as StoregeProvider [l-z]
participant StorageProvider1 as StorageProvider [a-k]
participant StorageProvider2 as StorageProvider [l-z]
Note right of ocDAV: translate ownCloud flavoured webdav<br>into CS3 API requests
ocDAV->>+Gateway: ListContainer({spaceid}, path: {relative/path})
@@ -120,7 +120,7 @@ sequenceDiagram
else username starting with l-z
Gateway->>+StorageProvider2: ListContainer({spaceid}, path: {relative/path})
StorageProvider2-->>-Gateway: []ResourceInfo
end
end
Gateway-->>-ocDAV: []ResourceInfo
{{</mermaid>}}
@@ -129,7 +129,7 @@ sequenceDiagram
**PROPFIND request against old webdav endpoints**
To route a PROPFIND request against the old webdav endpoints like `/dav/files/username`, ocdav first has to build a CS3 namespace prefix, eg. `/users/{{.Id.OpaqueId}}` to the users home.
To route a PROPFIND request against the old webdav endpoints like `/dav/files/username`, ocdav first has to build a CS3 namespace prefix, eg. `/users/{{.Id.OpaqueId}}` to the users home.
{{<mermaid class="text-center">}}
%%{init: {"sequence": { "showSequenceNumbers":true, "messageFontFamily":"courier", "messageFontWeight":"normal", "messageFontSize":"11"}}}%%
@@ -150,11 +150,11 @@ sequenceDiagram
ocDAV->>+ocDAV: {namespace/prefix} = ApplyLayout({path layout}, User), eg. /users/e/einstein
Note right of ocDAV: look up the space responsible for a path
ocDAV->>+Gateway: ListStorageSpaces(path: {namespace/prefix}/{relative/path})
Gateway-->>-ocDAV: []StorageSpace
Gateway-->>-ocDAV: []StorageSpace
Note right of ocDAV: make actual request with space and relative path
ocDAV->>+Gateway: ListContainer({spaceid}, path: {relative/path})
Gateway-->>-ocDAV: []ResourceInfo
ocDAV-->>-Client: 207 Multistatus
Gateway-->>-ocDAV: []ResourceInfo
ocDAV-->>-Client: 207 Multistatus
end
{{</mermaid>}}
@@ -192,9 +192,9 @@ sequenceDiagram
end
Note right of ocDAV: look up the space responsible for a path
ocDAV->>+Gateway: ListStorageSpaces(path: {namespace/prefix}/{relative/path})
Gateway-->>-ocDAV: []StorageSpace
Gateway-->>-ocDAV: []StorageSpace
Note right of ocDAV: make actual request with space and relative path
ocDAV->>+Gateway: ListContainer({spaceid}, path: {relative/path})
Gateway-->>-ocDAV: []ResourceInfo
ocDAV-->>-Client: 207 Multistatus
Gateway-->>-ocDAV: []ResourceInfo
ocDAV-->>-Client: 207 Multistatus
{{</mermaid>}}

2
docs/extensions/app-registry/apps.md
View File

@@ -282,7 +282,7 @@ HTTP status code: 200
```json
{
"code": "RESOURCE_NOT_FOUND",
"message": "error: not found: app 'Collabor' not found"
"message": "error: not found: app 'Collabora' not found"
}
```

8
docs/extensions/graph/groups.md
View File

@@ -23,10 +23,10 @@ The JSON representation of a Group as handled by the Groups API looks like this:
Our implementation currently supports two Attributes for a Group:
| Attribute | Description |
|---------------|-------------|
| displayName | The groups name|
| id | An unique, stable readonly identifier for the group that stays the same for the whole lifetime of the User, usually a UUID|
| Attribute | Description |
|---------------|-----------------------------------------------------------------------------------------------------------------------------|
| displayName | The groups name |
| id | An unique, stable readonly identifier for the group that stays the same for the whole lifetime of the Group, usually a UUID |
### Reading groups

14
docs/extensions/graph/users.md
View File

@@ -25,13 +25,13 @@ The JSON representation of a User handled by the Users API looks like this:
Our implementation currently supports only a limited set of Attributes of Users:
| Attribute | Description |
|---------------|-------------|
| displayName | The full name of the user, usually a combination for givenname and lastname|
| mail | The user's email address |
| onPremisesSamAccountName | The loginname/account name of the user|
| id | An unique, stable readonly identifier for the user that stays the same for the whole lifetime of the User, usually a UUID|
| passwordProfile | Contains the password of the users. This is only present when updating or creating users. It is never returned by the API|
| Attribute | Description |
|---------------|---------------------------------------------------------------------------------------------------------------------------|
| displayName | The full name of the user, usually a combination of given name and last name |
| mail | The user's email address |
| onPremisesSamAccountName | The loginname/account name of the user |
| id | An unique, stable readonly identifier for the user that stays the same for the whole lifetime of the User, usually a UUID |
| passwordProfile | Contains the password of the users. This is only present when updating or creating users. It is never returned by the API |
### Reading users

2
docs/extensions/storage/terminology.md
View File

@@ -83,7 +83,7 @@ a *quota* and *permissions*, identified by a `storage space id`.
{{< figure src="/extensions/storage/static/storagespace.drawio.svg" >}}
Examples would be every user's home storage space, project storage spaces or group storage spaces. While they all serve different purposes and may or may not have workflows like anti virus scanning enabled, we need a way to identify and manage these subtrees in a generic way. By creating a dedicated concept for them this becomes easier and literally makes the codebase cleaner. A [*storage space registry*]({{< ref "#storage-space-registries" >}}) then allows listing the capabilities of [*storage spaces*]({{< ref "#storage-spaces" >}}), e.g. free space, quota, owner, syncable, root etag, upload workflow steps, ...
Examples would be every user's home storage space, project storage spaces or group storage spaces. While they all serve different purposes and may or may not have workflows like antivirus scanning enabled, we need a way to identify and manage these subtrees in a generic way. By creating a dedicated concept for them this becomes easier and literally makes the codebase cleaner. A [*storage space registry*]({{< ref "#storage-space-registries" >}}) then allows listing the capabilities of [*storage spaces*]({{< ref "#storage-spaces" >}}), e.g. free space, quota, owner, syncable, root etag, upload workflow steps, ...
Finally, a logical `storage space id` is not tied to a specific [*storage provider*]({{< ref "#storage-providers" >}}). If the [*storage driver*]({{< ref "#storage-drivers" >}}) supports it, we can import existing files including their `file id`, which makes it possible to move [*storage spaces*]({{< ref "#storage-spaces" >}}) between [*storage providers*]({{< ref "#storage-providers" >}}) to implement storage classes, e.g. with or without archival, workflows, on SSDs or HDDs.

4
docs/ocis/deployment/bridge.md
View File

@@ -15,7 +15,7 @@ This document is a work in progress of the current setup.
## Current status
Using ocis and the ownCloud 10 [graphapi app](https://github.com/owncloud/graphapi/) it is possible today to use an existing owncloud 10 instance as a userbackend and storage backend for ocis.
Using ocis and the ownCloud 10 [graphapi app](https://github.com/owncloud/graphapi/) it is possible today to use an existing owncloud 10 instance as a user backend and storage backend for ocis.
## How to do it
@@ -117,7 +117,7 @@ $ ldapsearch -x -H ldap://127.0.0.1:9125 -b dc=ocis,dc=test -D "cn=admin,dc=ocis
```
{{< hint >}}
This is currently a readonly implementation and minimal to the usecase of authenticating users with an IDP.
This is currently a readonly implementation and minimal to the use-case of authenticating users with an IDP.
{{< /hint >}}
### Start ocis storage-gateway, storage-authbasic and storage-userprovider

4
docs/ocis/storage-backends/cephfs.md
View File

@@ -17,7 +17,7 @@ The cephfs development happens in a [Reva branch](https://github.com/cs3org/reva
## Architecture
In the original approach the driver was based on the [localfs](https://github.com/cs3org/reva/blob/a8c61401b662d8e09175416c0556da8ef3ba8ed6/pkg/storage/utils/localfs/localfs.go) driver, relying on a locally mounted cephfs. It would interface with it using the POSIX apis. This has been changed to directly call the Ceph API using https://github.com/ceph/go-ceph. It allows using the ceph admin APIs to create subvolumes for user homes and maintain a file id to path mapping using symlinks.
In the original approach the driver was based on the [localfs](https://github.com/cs3org/reva/blob/a8c61401b662d8e09175416c0556da8ef3ba8ed6/pkg/storage/utils/localfs/localfs.go) driver, relying on a locally mounted cephfs. It would interface with it using the POSIX apis. This has been changed to directly call the Ceph API using https://github.com/ceph/go-ceph. It allows using the ceph admin APIs to create sub-volumes for user homes and maintain a file id to path mapping using symlinks.
## Implemented Aspects
The recursive change time built ino cephfs is used to implement the etag propagation expected by the ownCloud clients. This allows oCIS to pick up changes that have been made by external tools, bypassing any oCIS APIs.
@@ -45,7 +45,7 @@ Trash is not implemented, as cephfs has no native recycle bin and instead relies
Shares [are mapped to ACLs](https://github.com/cs3org/reva/pull/1209/files#diff-5e532e61f99bffb5754263bc6ce75f84a30c6f507a58ba506b0b487a50eda1d9R168-R224) supported by cephfs. The share manager is used to persist the intent of a share and can be used to periodically verify or reset the ACLs on cephfs.
## Future work
- The spaces concept matches cephfs subvolumes. We can implement the CreateStorageSpace call with that, keep track of the list of storage spaces using symlinks, like for the id based lookup.
- The spaces concept matches cephfs sub-volumes. We can implement the CreateStorageSpace call with that, keep track of the list of storage spaces using symlinks, like for the id based lookup.
- The share manager needs a persistence layer.
- Currently we persist using a single json file.
- As it basically provides two lists, *shared with me* and *shared with others*, we could persist them directly on cephfs!