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.

The term ''hierarchical'' looks to me also connoted. 
I have the feeling that it is the notion of a mechanism capable of giving the illusion that all the edge sites form a single system that is important, isn't it?
A kind of single pane of glass that can be used to manage the life cycle of -- both -- the edge sites/areas -- and -- the edge applications. 

> 
> > 
> > @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.

If I'm correctly understanding your point, this might be ok but we need to consider that some events are related to the edge applications you would like to execute across  different edge sites (i.e. events are not only related to keeping edge sites synchronised). 

best regards, 
Adrien


>