[DRAFT] events propagation

Possible events on a resource:

1. changed
configuration management executed on resource, and changes were found,
both ansible and puppet is able to know if there were any changes

2. failed, error
error - corresponds to problems in infrastructure, and probably cant be remediated in any way
failed - process of configuring resource failed
Does it make sense to create such separation?

3. ok
Resource executed without errors or changes, so successors may skip reloading
or whatever

4. created ??
is there such cases when we need to differentiate between updated object
and created?

--------------------------------------------------
Propagating events when there is no data changed

Control for specifying events:

on <emitter>.<emmiter_action> <event> <subscriber>.<subsciber_action>

on mariadb.run                changed keystone.run
on keystone.run               changed keystone_config.run
on keystone_config.run        changed haproxy.reload

+---------------------+
|     mariadb.run     |
+---------------------+
  |
  | changed
  v
+---------------------+
| keystone_config.run |
+---------------------+
  |
  | changed
  v
+---------------------+
|   haproxy.reload    |
+---------------------+

<u>.<action> - <event> - <v>.<action>

When data connection between several resources created - events connections should
be created as well, resource a connect resource b:

on a.run    changed b.reload
on a.remove changed b.run

-------------------------------------------------
Resolving cycles on a data plane

Resolving rmq cycle with events, lets say we have 4 objects:
- rmq.cluster
- rmq.1, rmq.2, rmq.3

rmq.cluster is a sinc that will use data from all 3 nodes, and those nodes will
consume that sinc - so there is a cycle. We can not depend just on data to resolve
this cycle.

Order of execution should be like this:

rmq.1.run rmq.2.run rmq.3.run
rmq.1.cluster_create
rmq.2.cluster_join, rmq.2.cluster_join

Also cluster operation should happen only when rmq.cluster is changed.

on rmq.cluster          changed rmq.1.cluster_create
on rmq.1.cluster_create changed rmq.2.cluster_join
on rmq.1.cluster_create changed rmq.3.cluster_join

+----------------------+
|      rmq.1.run       |
+----------------------+
  |
  | changed
  v
+----------------------+
| rmq.1.cluster_create | -+
+----------------------+  |
  |                       |
  | changed               |
  v                       |
+----------------------+  |
|  rmq.2.cluster_join  |  |
+----------------------+  |
  ^                       |
  | changed               | changed
  |                       |
+----------------------+  |
|      rmq.2.run       |  |
+----------------------+  |
+----------------------+  |
|      rmq.3.run       |  |
+----------------------+  |
  |                       |
  | changed               |
  v                       |
+----------------------+  |
|  rmq.3.cluster_join  | <+
+----------------------+



---------------------------------------------------
Resolve cycles on a execution level

We have 5 objects, which forms 2 pathes
- keystone-config -> keystone-service -> haproxy-sevice
- glance-config -> glance-service -> haproxy-service

But also we have keystone endpoint exposed via haproxy, and it is consumed in
glance-config, therefore there is a cycle. And proper resolution for this
cycle would be to install haproxy after keystone is configured, and after that
configure glance, and only after reload haproxy one more time to ensure that
glance exposed via haproxy.

     +----+
     | g  |
     +----+
       |
       |
       v
     +----+
     | gc | <+
     +----+  |
       |     |
       |     |
       v     |
     +----+  |
  +> | ha | -+
  |  +----+
  |  +----+
  |  | k  |
  |  +----+
  |    |
  |    |
  |    v
  |  +----+
  +- | kc |
     +----+

During traversal we should check if added node forms a cycle, find a pair
of nodes that created this cycle and create a node with incremented action.
In the above example this resolution will help if ha.run will be incremented
and we will have two actions - ha.run#0 and ha.run#1, and gc.run#0 will lead
to ha.run#1.