August 2021 - Edge-computing - lists.opendev.org

Edge for scientific research session on September 13
by Ildiko Vancsa 13 Sep '21

13 Sep '21

Hi, I’m very excited to invite you to a session with the Chameleon project to discuss how edge computing is powering education, scientific research and more! As always in the area of edge there are challenges and gaps that we need to solve together. In that sense the session will start with a presentation that we will then turn into a discussion to turn towards discussing solutions. The session will take place on the weekly call on __September 13, at 1300 UTC / 6am Pacific__. Please find the details of the session below. Thanks and Best Regards, Ildikó Title: Chameleon: a cloud to edge infrastructure for science Abstract: The NSF-funded Chameleon project (www.chameleoncloud.org) provides an OpenStack-based bare metal reconfigurable cloud that supports systems research, education, and emergent application projects in science. The facility has been in existence for 6+ years, and has served ~6,000 users working on a variety of projects ranging from networking, operating systems design, and security, to innovative applications in astronomy, physics, and life sciences. Recent research trends in IoT and edge computing, as evidenced by increased numbers of project applications in those areas, made it clear that Chameleon needed to expand into the edge space. Remaining within the OpenStack framework allowed us to leverage end-user features that we developed for Chameleon, such as access via federated identity and Jupyter integration. Accordingly, we developed infrastructure called CHI@Edge that adapts Zun to provision containers on edge devices and significantly expands its capabilities to work in the edge space. The talk will describe our use case and the emergent product definition, the OpenStack adaptations we made to the current preview implementation, the directions we plan to take in our further work, as well as the ecosystem of projects and NSF infrastructure deployments leveraging this work and collaborating with us. ——— Ildikó Váncsa Senior Manager, Community & Ecosystem Open Infrastructure Foundation

1 3

Upcoming meeting schedule
by Ildiko Vancsa 31 Aug '21

31 Aug '21

Hi, As we have a couple things coming up for our weekly calls I wanted to give you a quick overview and reminder of our plans for the next few weeks: * August 30 - We’ve been discussing our plans for the upcoming PTG[1] event which we will be finalizing on this call. * September 6 - US Labor Day, the meeting will be cancelled. * September 13 - Chameleon project: edge for education and scientific research presentation and discussion. As a reminder the weekly calls are happening on Mondays at 6am Pacific / 1300 UTC. You can find the meeting details here: https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings Please let me know if you have any questions. Thanks, Ildikó [1] https://www.openstack.org/ptg/ ——— Ildikó Váncsa Senior Manager, Community & Ecosystem Open Infrastructure Foundation

1 1

Updated Edge October 2021 PTG Session writeups
by Cohen, Beth F 26 Aug '21

26 Aug '21

Folks - Please review the session writeups. I have 12 sessions identified from a total of 14. Some of them can be broken into two sessions, so I suspect we do have enough sessions to fill all the slots at this point. https://etherpad.opendev.org/p/ecg-ptg-october-2021 -- -- *Beth Cohen* SDN Network Product Strategy Verizon Business Group M 781.434.8553

4 4

Blog post series and PTG
by Ildiko Vancsa 09 Aug '21

09 Aug '21

Hi, First of all let me announce that our new blog post, 'Is Edge Computing a Distributed System at Scale?’, is now live on Superuser: https://superuser.openstack.org/articles/is-edge-computing-a-distributed-sy… The discussion on distributed systems and/vs edge computing has just started, we have a lot more to untangle there. Hereby I would like to invite everyone who has some follow up thoughts or questions to the above blog to join our calls on Mondays at 6am PDT / 1300 UTC[1]. We have a thread already going about the distributed systems topic. If you’re not on the edge-computing mailing list[2], you can check the archive here: http://lists.openstack.org/pipermail/edge-computing/2021-August/000779.html If you would like to join the discussion please subscribe to the mailing list and reply to the thread. We are also continuously looking for new topics, so if you have an edge conundrum you can bring that to discuss with the group as well! The Edge Computing Group will be participating in the upcoming PTG[3] in October. We have three slots booked for this fully online event for some more deep dive technical discussions about edge infrastructures including challenges and solutions. If you have topics you would like to discuss please add that to our planning etherpad: https://etherpad.opendev.org/p/ecg-ptg-october-2021 Also please add your name to your topic and add your contact info to the etherpad so we can keep you in the loop during the planning phase. Please let me know if you have any questions. Thanks and Best Regards, Ildikó [1] https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings [2] http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing [3] https://www.openstack.org/ptg/ ——— Ildikó Váncsa Senior Manager, Community & Ecosystem Open Infrastructure Foundation

1 0

Edits to the Blog completed
by Cohen, Beth F 09 Aug '21

09 Aug '21

Ildiko and the rest of the Edge group. I have edited the Blog and hopefully made it a better and more entertaining read. -- -- *Beth Cohen* SDN Network Product Strategy Verizon Business Group M 781.434.8553

4 4

Re: [Edge-computing] Distributed systems first blog post
by lebre.adrien＠free.fr 09 Aug '21

09 Aug '21

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

1 0

Re: [Edge-computing] Distributed systems first blog post
by Bogdan Dobrelya 01 Aug '21

01 Aug '21

> 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

2 1