Scheduler that frequently calls the sync endpoint of API services
This repository has been archived on 2020-09-24. You can view files and clone it, but cannot push or open issues or pull requests.
Go to file
marcsello ae822d87d8
All checks were successful
continuous-integration/drone/push Build is passing
Merge branch 'master' of kmlabz:GoldenPogacsa/consumer-scheduler
2020-05-14 22:26:26 +02:00
docs Updated documentation 2020-05-14 22:26:14 +02:00
.coveragerc added coveragerc 2020-05-13 17:17:32 +02:00
.dockerignore test 2020-03-29 17:24:47 +02:00
.drone.yml instal dev requirements 2020-05-14 21:08:09 +02:00
.gitignore test 2020-03-29 17:24:47 +02:00
app.py Updated documentation 2020-05-14 22:26:14 +02:00
communicators.py Added force ip override setting 2020-05-14 22:25:47 +02:00
Dockerfile create 2020-03-29 16:48:34 +02:00
ip_watchdog.py Added some docstrings 2020-05-14 18:43:05 +02:00
README.rst Updated documentation 2020-05-14 22:26:14 +02:00
redis_super_storage.py Documented rst 2020-05-14 19:24:20 +02:00
requirements_dev.txt Added tests for rst 2020-05-13 16:06:39 +02:00
requirements.txt Small fixes 2020-03-29 19:26:52 +02:00
test_everything.py Added force ip override setting 2020-05-14 22:25:47 +02:00

======================
P2P Consumer Scheduler
======================

The scheduler part of a consumer system for the P2P storage system.

Produced by GoldenPogácsa Inc.

Basics
------
This is a component of a fully working consumer system.
In order to setup a consumer you will need the consumer API as well and a Redis database.

This component faciliates the automatic synchronization between consumers.
As well as detecting IP changes of the host which is running on.

Part of a system
----------------

This component works as a complimentary part for the consumer API.

The information exchange between the API is solved by using a Common Redis database.
This database must be shared between the API and the Scheduler instance.

Also the UUID is shared between the two components. This is obvious since they are essentially both parts of the same system.


Communications
--------------

The communication between other consumers and producers are solved by their REST API endpoints.

The follwing events will cause communication by this object:
 * A sychronization task
 * An IP address change detected

Since the communication between consumers happens regularly the IP address change event does not cause an immediate synchronization
However communication originated by scheduler toward producers only happens when the IP address change is detected.

Synchronization
~~~~~~~~~~~~~~~

This call originated by the scheduler and happens regularly (See. configuration).

A synchronization task causes the followings:
     * Each consumer known by this consumer is checked for availability
     * Each consumer this consumer communicated with updated the availability of this consumer.
     * Each consumer which had no information of this consumer, now have.

Consumers learn about each other, and their IP addresses (and changes) during a synchronization.

Called URL::

    http://<consumer ip>/sync

Body::

        {
            "uuid" : "str: LOCAL_UUID",
            "ip" : "str: optional: IP override"
        }


IP update
~~~~~~~~~

This communication is originated by the scheduler when an IP address change is detected.

This call is used to let producers immanently know about an IP change of their consumer, so that they can converge faster.

Called URL::

    http://<producer ip>/ip

Body::

    {
        "uuid" : "str: LOCAL_UUID",
        "ip": "str: provided by param"
    }