Open Stack

> Hi, 
> 
> @Ildiko, thanks once again for this draft. 
> 
> @All, It is still not clear whether the ''centralization'' word is clear (in particular in this sentence, "... we will need autonomy and centralization..."
> By centralisation here we mean that we would like to be able to administrate/use all edge sites (or edge areas) like if it was a single DC. However this ''centralisation'' can be implemented in different manners. 
> Would it be possible to qualify this term or to make it clear that it is not a centralized system as such (i.e. a single point of failure with all well known limitation such as scalability etc.)?

How about 'autonomy and hierarchical control loops'? That doesn't bring the 
notion of centralisation but rather subordination.

> 
> @Rob, if you have time, can you please give a look to the questions I put in the main etherpad: https://etherpad.opendev.org/p/ecg-untangling-the-edge. 
> Actually, I'm not sure I'm capturing well t the exact services you expect from this ''centralised'' system. If I correctly understood, it looks like it is a golden node that is used to (re)configure/(re)synchronise the edge sites. If I fully agree such services are mandatory to manage/interact with each independent control plane (one per edge site/area), this system should also provide the right abstractions/mechanisms to manage the life cycle of the edge applications (which can be deployed across multiple edge sites/areas). In other words, we need independent control loops for each edge area and at least one control loop to manage applications. 
> 
> Without discussing now whether such a system could be implemented in a (geo-)distributed manner or whether we need one global application control loop or one per application, I would appreciate if  we could highlight the fact that the control loop at the higher level (i.e. ''the centralised system you mention in your initial text'') is more complex than a golden node that is used to keep each edge site synchronised. . 

I would stick to a concept of targeted (or causal) events sourcing. Like each 
edge site has to follow a dedicated sub-flow of events in order to keep being 
synchronised, irrelevant to the state of its neighbours. That is unlike to the 
classic events sourcing, where the golden node tells its replicas to strictly 
apply (or reply) events from a log/journal. Does that makes sense? The events 
source concept is high level enough, it would not bring the blog readers to the 
jungles of technical details.

> 
> Hope this helps move forward the discussion ;-)
> Thanks
> Adrien 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando