achlysproject/achlys

Erlang framework for building applications with Lasp on GRiSP

Achlys

The Achlys framework is a tool designed to help application developers build Erlang/OTP programs using the Lasp libraries and running on GRiSP embedded systems in a wireless sensor network configuration. A more detailed description is available in this document.

Demonstration (turn on CC !)

Achlys tasks

Achlys is being developed in the context of edge computing research within the H2020 LightKone project. The 2 main objectives of the framework are to provide :

• Resilient storage across a cluster of IoT sensing devices
• A general purpose task model allowing any function to be propagated and executed in the cluster

Disclaimer : Achlys is currently under active development, hence a production-ready release is not yet available.

Achlys is the goddess of deadly poison ... but fortunately there is an AntidoteDB

Minimum requirements

• otp 22.0
• rebar3 3.13.1
• grisp 1.2.0
• rebar3_grisp 1.3.0

Development requirements (optional)

• grisp-software : a fully built grisp toolchain.
• grisp_tools 0.2.6 or above
• partisan 4.1.0 or above
• lasp 0.10.0 or above

Deployment guide

Additional information on the deployment of GRiSP applications with Achlys can be found below :

• Deployment guide

Extending Achlys

Achlys is a framework for generic computations by definition, therefore it can be extented and fine-tuned to turn it into a software that supports any possible application :

• Task Model API example usage

Wiki

A Wiki is currently being written and will aim at providing a wide range of examples and tutorials in order to demonstrate the capabilities of Lasp on GRiSP at the Edge.

The GRiSP Wiki also provides necessary steps in order to setup the required dependencies in order to run Achlys on the GRiSP boards. There are also useful resources that are interesting for general usage of GRiSP boards.

Elixir is also supported on GRiSP, and there two very interesting articles by @Theuns-Botha that provide detailed information on how to setup an Elixir development environment :

• Going bare metal with Elixir and GRiSP
• IEx Remote Shell into your Elixir driven GRiSP Board

EDoc preview

The development process has not yet reached a level of maturity allowing for an actual release of the program. Therefore, the documentation is currently more of an insight at the software design and more generally at the features that will be provided.

Once a satisfactory amount of testing and features will be implemented, a versioned package will be released and the documentation will be a reliable set of specifications.

The online version of the documentation is found at :

HexDocs

Architecture

The design pattern will follow the "facade" concept as much as possible, hence there will be an API that will provide an easy access to all the modules and functions. The documentation will be reorganized to focus on thoroughly explaining the usage, and will regroup the information of submodules like these :

Mind map

A Mindly reasoning construct. Allows for easier visualization of problems and tasks, hence more efficient solving.

• The API branch of the map provides a description of some features and simple usage examples.
• For Achlys, it is currently an additional asset to structure software improvement ideas.

NOTE : An online interactive version is available here

achlys's Issues

Use cookie-based cluster isolation mechanism

API usage examples on HexDocs

• Deployment guide
• Lasp API usage examples
• Task model API edocs
• Local testing guide

Durable delta-CRDT states

As described by Almeida et al. in Delta State Replicated Data Types, the system model requires the following :

Nodes have access to durable storage; they can crash but will eventually recover with the content of the durable storage just before the crash occurred. Durable state is written atomically at each state transition.

• Investigate possible use of the Lasp DETS storage backend
• Mitigate DETS file corruption due to hardware shutdowns on GRiSP boards during execution (DETS files are empty after hard reset -> not_a_dets_file error is thrown when the Lasp storage backend attempts to open it)

extend public API

Enable API functions for gathering data from available drivers

Deactivate all alloc subcomponents

Update documentation

• Installation guide
• Test environment configuration
• GRiSP deployment configuration
• API documentation on Hex

Stress testing in function of cluster size

Stress

Overall "stress" seems to correlate with the intervals between requests in general.
process heap growth is probably observed above a certain threshold of updates per unit of time.

• 2 nodes cluster aggregates temperatures with stable memory footprint
• 4 nodes
• 8 nodes

Add tutorial in Wiki section

Wiki

• The Wiki needs to be completed with at least a basic application example and the necessary steps for deployment.

Remove static network configuration

Hostname resolution

DNS service equivalent with default configuration must be used instead of manual entries for each host

MAC addresses

Per device unique identification must be used for mapping

• DNS service through inet_dns
• Retrieve hardware address in EEPROM

Document GRiSP runtime ad hoc networking

Context

This feature needs documentation, either in the README or on the wiki.

Originally posted by @eproxus in grisp/grisp#41 (comment)

Extract behavior for sensor workers

Add OTP behavior capturing the sensor worker interface with mandatory callbacks

bad_term_file,"./config/test.config.src"

make shell causes an error on on WSL (Kali Linux)

Here is the output of the terminal :

user@VivoBook:~/achlys$ cat /etc/os-release
PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
ID=kali
VERSION="2019.4"
VERSION_ID="2019.4"
VERSION_CODENAME="kali-rolling"
ID_LIKE=debian
ANSI_COLOR="1;31"
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"
user@VivoBook:~/achlys$ make shell
Launching shell node
Using long names
===> Verifying dependencies...
===> Compiling achlys
src/achlys.erl:176: Warning: variable 'F' is unused
src/achlys.erl:184: Warning: variable 'F' is unused
src/achlys.erl:188: Warning: variable 'Elem' is unused
src/achlys.erl:200: Warning: variable 'Minimum' is unused

src/achlys_cleaner.erl:51: Warning: type gc_config() is unused
src/achlys_cleaner.erl:238: Warning: variable 'TimerRef' is unused

src/achlys_task_worker.erl:165: Warning: variable 'Info' is unused

src/achlys_util.erl:61: Warning: variable 'Func' is unused
src/achlys_util.erl:125: Warning: variable 'T' is unused
src/achlys_util.erl:184: Warning: variable 'T' is unused

src/achlys_pmod_als_worker.erl:68: Warning: type crdt() is unused
src/achlys_pmod_als_worker.erl:235: Warning: variable 'T' is unused
src/achlys_pmod_als_worker.erl:245: Warning: variable 'C2' is unused

src/achlys_pmod_nav_worker.erl:245: Warning: variable 'C2' is unused
src/achlys_pmod_nav_worker.erl:274: Warning: variable 'C3' is unused

Erlang/OTP 22 [erts-10.4] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [hipe]

===> {bad_term_file,"./config/test.config.src",
               {41,erl_parse,["syntax error before: ","'}'"]}}
make: *** [Makefile:71: shell] Error 1

Same for this configuration (VM)

user@kali:~/achlys$ cat /etc/os-release
PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
ID=kali
VERSION="2018.4"
VERSION_ID="2018.4"
ID_LIKE=debian
ANSI_COLOR="1;31"
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"

Initial release

for minimal deployments

Implement resilient local persistence

ETS table size management

• Add configuration parameters to set sliding windows to preserve only N most recent ETS entries when collecting raw data streams.
• Purge tables periodically based on configuration

Occasional data convergence failures when performing simultaneous bidirectional joins

• Check for existing variables and members in the cluster instead of automatic full bidirectional joins and declarations

LiveView Dashboard

https://twitter.com/chris_mccord/status/1110948008613548032?s=19

Feature required : available memory

API call description

The framework must be able to provide a function such as :

achlys:memory(remaining)

That returns the exact amount of memory that is usable by the application at any point in time. The feature will possibly be implemented in a separate library that would be included as a dependency.

• Write scenario that can easily reproduce the same crash dump
• Collect sufficient information regarding the following memory management common issues :

1. Detailed report on fragmentation status
2. Detailed report about existence of leakage

• Implement API function that computes the best estimate possible of usable memory w.r..t previously collected information. The behavior that should be adopted regarding GC is not yet defined. Example : If called during garbing, the available memory would appear lower due to copies being made before fullsweep. The program would not be aware that much more space is free immediately after the GC completion. Possible workaround would be to perform manual GC when function is called, but this heavily limits the usability of the function as calling it very frequently would cause overhead.
• Validate correctness of returned values
• Optional : integration in a monitoring dashboard such a Prometheus

RTEMS shell

• silent Erlang shell and RTEMS shell access
• Access Erlang Remote Shell while RTEMS shell option is selected
• Clusterize nodes exposing different shells
• Combine all possibile configurations in a single cluster and deploy Achlys