[Edge-computing] [all][tc][Edge][FEMDC][tripleo][akraino][starlingx] Chronicles Of A Causal Consistency

Bogdan Dobrelya bdobreli at redhat.com
Wed Dec 5 11:08:56 UTC 2018


Background.
Fact 0. Edge MVP reference architectures are limited to a single control 
plane that uses a central/global data backend by usual for boring Cloud 
computing meanings.
Fact 1. Edge clouds in Fog computing world are WAN-distributed. Far and 
middle-level tiers may be communicating to their control planes over 
high-latency (~50/100ms or more) connections.
Fact 2. Post-MVP phases [0] of future reference architectures for Edge 
imply high autonomity of edge sites (aka cloudlets [1][2]), which is 
having multiple control planes
always maintaining CRUD operations locally and replicating shared state 
asynchronously, only when "uplinks" are available, if available at all.
Fact 3. Distributed Compute Node in the post-MVP phases represents a 
multi-tiered star topology with middle-layer control planes aggregating 
thousands of computes at far edge sites and serving CRUD operations for 
those locally and fully autonomous to upper aggregation edge layers [3]. 
Those in turn might be aggregating tens of thousands of computes via 
tens/hundreds of such middle layers. And finally, there may be a central 
site or a few that want some data and metrics from all of the 
aggregation edge layers under its control, or pushing deployment 
configuration down hill through all of the layers.

Reality check.
That said, the given facts 1-3 contradict to strongly consistent data 
backends supported in today OpenStack (oslo.db), or Kubernetes as well.
That means that neither of two IaaS/PaaS solutions is ready for future 
post-MVP phases of Edge as of yet. That also means that both will need a 
new, weaker consistent, data backend to pass the future reality check. 
If you're interested in formal proves of that claim, please see for 
sources [4][5][6][7][8]. A [tl;dr] of those:

a) It is known that causal consistency is the best suitable for 
high-latency, high-scale and highly dynamic nature of membership in clusters
b) "it it is significantly harder to implement causal consistency than 
eventual consistency. This explains the fact why there is not even a 
single commercial database system
that uses causal consistency" [6]

Challenge accepted!
What can we as OpenStack community, joined the Kubernetes/OSF/CNCF 
communities perhaps, for the bright Edge future can do to make things 
passing that reality check?
It's time to start thinking off it early, before we are to face the 
post-MVP phases for Edge, IMO. That is also something being discussed in 
the neighbour topic [9] and that I'm also trying to position as a 
challenge in that very high-level draft paper [10]. As of potential 
steps on the way of implementing/adopting such a causal data backend in 
OpenStack at least, we should start looking into the papers, like 
[4][5][6][7][8] (or even [11], why not having a FS for that?), and 
probably more of it as a "theoretical background".

[0] 
https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG#Features_2
[1] 
https://github.com/State-of-the-Edge/glossary/blob/master/edge-glossary.md#cloudlet
[2] https://en.wikipedia.org/wiki/Cloudlet
[3] 
https://github.com/State-of-the-Edge/glossary/blob/master/edge-glossary.md#aggregation-edge-layer
[4] http://www.bailis.org/papers/bolton-sigmod2013.pdf
[5] http://www.cs.princeton.edu/~wlloyd/papers/eiger-nsdi13.pdf
[6] https://www.ronpub.com/OJDB_2015v2i1n02_Elbushra.pdf
[7] http://www.cs.cornell.edu/lorenzo/papers/cac-tr.pdf
[8] https://www.cs.cmu.edu/~dga/papers/cops-sosp2011.pdf
[9] 
http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000492.html
[10] 
https://github.com/bogdando/papers-ieee/blob/master/ICFC-2019/LaTeX/position_paper_1570506394.pdf
[11] http://rainbowfs.lip6.fr/data/RainbowFS-2016-04-12.pdf

-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando



More information about the Edge-computing mailing list