Commit 65071e2f authored by pfandzelter's avatar pfandzelter
Browse files

start readme

improve readme

improve readme further

add section about authentication and certificates

finish readme draft

add section about testing

reverse changes to proto files

update images

add section about multi machine nodes, fix some issues

update image

Apply 3 suggestion(s) to 1 file(s)

update commands

add cd commands
parent 6b3e5697
Pipeline #7684 passed with stages
in 17 minutes and 42 seconds
This diff is collapsed.
......@@ -38,19 +38,19 @@ As an alternative to the centralized knowledge store, nodes in FogStore can mana
When a node is configured as a replica for a keygroup, an expiration for data items can be configured: data then expires on this replica node after a certain delay (WP1.1.8).
FogStore offers some basic access control mechanisms for multi-tenancy that allows applications to protect keygroups from read/writes from other applications (WP1.1.9).
- [ ] WP1.1.1 can be installed on single or multiple machines per node
- [x] WP1.1.1 can be installed on single or multiple machines per node
- [ ] WP1.1.2 has logical addressing for geo-distributed sites
- [ ] WP1.1.3 use state-of-the-art or cloud storage system as storage backend (_Universal Storage Connector and H... Interface_ (_USCHI_))
- [ ] WP1.1.4 keygroup stores data items in append-only store or mutable table
- [ ] WP1.1.5 applications choose replica placement
- [ ] WP1.1.6 centralized store has replica knowledge (_Holistic Application Naming Service_ (_HANS_))
- [x] WP1.1.3 use state-of-the-art or cloud storage system as storage backend
- [x] WP1.1.4 keygroup stores data items in append-only store or mutable table
- [x] WP1.1.5 applications choose replica placement
- [x] WP1.1.6 centralized store has replica knowledge
- [ ] WP1.1.7 alternative consensus-based replica set change
- [ ] WP1.1.8 data items can expire on a replica if needed
- [ ] WP1.1.9 access control mechanisms for multi-tenancy
- [x] WP1.1.8 data items can expire on a replica if needed
- [x] WP1.1.9 access control mechanisms for multi-tenancy
#### WP1.2 - Trigger Node Software
Next to nodes that store replicated data, a FogStore deployment also comprises _trigger nodes_ using _Keygroup Update Replication Triggers_ (_KURT_).
Next to nodes that store replicated data, a FogStore deployment also comprises _trigger nodes_ using _Keygroup Update Replication Triggers_.
A trigger node can be configured at a keygroup level.
Trigger nodes receive all updates on data items on a specific keygroup.
A trigger node may then use this data for external systems or to write modified data back into FogStore.
......
FROM node:10-alpine
RUN apk add python make gcc g++
RUN npm config set user root
RUN npm i grpcc -g
ENTRYPOINT [ "grpcc" ]
......@@ -6,3 +6,11 @@ In order to change the log level, create a `.env`-file in this folder with the f
LOG_LEVEL=info #debug,info,warn,error,fatal,panic
LOG_LEVEL_STORE=error #debug,info,warn,error,fatal,panic
```
## Debugging
It is possible to debug nodeB of the 3NodeTest:
- Create some breakpoints
- Run the configuration "3NodeTest: Run Tests & Debug nodeB (start "Debug nodeB" immediately after!)" (equals to `make debug-nodeB` in 3NodeTest)
- Run the configuration "Debug nodeB"
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment