[Edge-computing] LTE scenario
lebre.adrien at free.fr
lebre.adrien at free.fr
Fri Jan 5 23:48:17 UTC 2018
Hi,
Could someone elaborate a bit more on such a use-case (in the user stories etherpad if possible [1])?
It looks at least from my side, to be an advanced scenario. Advanced in the sense that it increases the number of challenges to deal with significantly.
Diving into the detail, there are some points that are unclear from my side with such a LTE use-case.
If I consider that a cloudlet is a edge site and if this edge site is operated by a telco, I guess the IP
of this edge site will not be so dynamic?
Moreover, by using a Dynamic DNS approach, it can be rather ok to find how interacting with this edge site. I'm not sure I'm seeing the issue here.
Maybe, the performance of the LTE connection will be the major issue in particular if we have to administrate and use the edge site remotely. For instance if you want provision any kind of VM, then dedicated mechanisms have to be designed to prefetch the VM image from a remote repo to this edge site.
There are academic proposals (e.g., see the previous publications that have been pointed by Satya for instance) but those solutions require to have at least a few templates/backing files already available in the edge site.
If you expect to have a VM image repository available on this ``LTE'' edge site, are you considering to be able to provision/relocate/migrate a VM from that site to another one? In such a case, dedicated mechanisms are mandatory to deal with all data mouvements related to this relocation between the edge sites !? Here there are also academics proposals but they have specific requirements.
[1] https://etherpad.openstack.org/p/2017_edge_computing_working_sessions_existing_gaps
----- Mail original -----
> De: "Suyash Sinha" <suyash.sinha at gmail.com>
> À: "beth cohen" <beth.cohen at verizon.com>
> Cc: edge-computing at lists.openstack.org
> Envoyé: Vendredi 5 Janvier 2018 17:32:36
> Objet: Re: [Edge-computing] [E] Re: : Connectivity (WAS: Upcoming Work Sessions Schedule - Edge)
>
>
>
> Yes. This is what I have been seeing as well.
>
>
> On Jan 5, 2018 6:54 AM, < beth.cohen at verizon.com > wrote:
>
>
>
>
>
>
> Yes. That is a common Telco use case! That is why I am so concerned
> with making sure that it will work as a “mesh” network, because that
> is one major use case.
>
>
>
>
>
> Verizon
>
> Beth Cohen
> NFV/SDN Network Product Strategy
>
> O +781-466-2055 | M +781-434-8553
> beth.cohen at verizon.com
>
> FacebookTwitterInstagram
>
>
>
>
>
>
>
> From: Csatari, Gergely (Nokia - HU/Budapest) [mailto:
> gergely.csatari at nokia.com ]
> Sent: Friday, January 05, 2018 9:04 AM
> To: Suyash Sinha < suyash.sinha at gmail.com >
> Cc: edge-computing at lists.openstack.org
> Subject: [E] Re: [Edge-computing] : Connectivity (WAS: Upcoming Work
> Sessions Schedule - Edge)
>
>
>
> Hi,
>
>
>
> You mean that the whole edge cloud is connected via LTE or any other
> mobile network?
>
>
>
> Br,
>
> Gerg0
>
>
>
>
>
>
>
>
>
>
>
> From: Suyash Sinha [ mailto:suyash.sinha at gmail.com ]
> Sent: Tuesday, January 2, 2018 6:45 PM
> To: Csatari, Gergely (Nokia - HU/Budapest) <
> gergely.csatari at nokia.com >
> Cc: Claire Massey < claire at openstack.org >;
> edge-computing at lists.openstack.org
> Subject: Re: [Edge-computing] Upcoming Work Sessions Schedule - Edge
>
>
>
>
> Thanks Gergely. very helpful/
>
>
>
>
>
> Based on my experience, there is also an issue of endpoint public IP
> address for the "edge cloudlet". We take the public IP for granted
> in the main datacenter but this may not be the case for edge. The
> edge cloudlet maybe connecting to the rest of the world via a client
> IP over LTE or other network that can change very often.
>
>
>
>
>
> On Tue, Jan 2, 2018 at 8:34 AM, Csatari, Gergely (Nokia -
> HU/Budapest) < gergely.csatari at nokia.com > wrote:
>
>
>
>
>
> Hi,
>
>
>
> For telco the edge cloud is a necesary tool to bring the computing
> capability close to the end user. This is a must in case of latency
> sensitive applications.
>
>
>
> The main differences compared to a central cloud are:
>
> * Size is smaller, therefore the relative price of the management
> of the cloud is expensive (from a 4 node big cloud I would not
> like to have 3 dedicated control nodes)
> * Location is not central, therefore any management activities
> which are not remote are very expensive and security should be
> provided
> * Cardinality is a lot, therefore automatization of management
> activities are needed
> * Workload is very volatile, therefore it should be very fast to
> start and stop workloads
> * Workload is roaming, therefore there shold be a way to migrate
> the context of a workload
>
>
>
>
> They are similar with the main clouds in a sense, that:
>
> * low latency networking and compute are needed
> * some workloads are delivered as VM images and some are as
> container images
> * Resource limits are needed for the applications
> * Network separation is needed between the applications
>
>
>
>
> Br,
>
> Gerg0
>
>
>
> From: Suyash Sinha [mailto: suyash.sinha at gmail.com ]
> Sent: Friday, December 22, 2017 3:21 PM
> To: Csatari, Gergely (Nokia - HU/Budapest) <
> gergely.csatari at nokia.com >
> Cc: Claire Massey < claire at openstack.org >;
> edge-computing at lists.openstack.org
>
>
>
>
> Subject: Re: [Edge-computing] Upcoming Work Sessions Schedule - Edge
>
>
>
>
>
>
> Gergely - Thanks for the share. What you are suggesting makes sense
> from a structural perspective.
>
>
>
>
>
> I have been studying the edge cloud space and writing on it since
> 2015 (
> https://www.linkedin.com/pulse/pushing-cloud-edge-suyash-sinha/ ) .
> So glad to see the work starting at openstack.
>
>
>
>
>
> For me, the fundamental question that we must start with is "why edge
> cloud". what necessitates it? What are the technical, business and
> ecosystem reasons. What use cases about edge cloud are fundamentally
> different from the "mainframe" cloud? Perhaps, that will better help
> educate us about the structural aspects like VMs and containers etc.
>
>
>
>
>
> Thanks,
>
>
> Suyash
>
>
>
>
>
>
>
>
> On Wed, Dec 20, 2017 at 2:31 AM, Csatari, Gergely (Nokia -
> HU/Budapest) < gergely.csatari at nokia.com > wrote:
>
>
>
>
>
> Hi,
>
>
>
> Thanks for the discussions around the user stories. Some follow up
> questions and notes:
>
> * Generic: I tried to use the user story template, but I think we
> should add more descriptions becouse I feel the user story
> format a bit to restrctive to add all information we discussed.
>
>
>
>
> * Definitions: I’ve added four definitions to make the discussion
> about the user stories more easy. Should we add a definition to
> „Edge cloud” and/or „Edge cloud infrastructure” also?
>
>
> * Workload: Several VM or linux containers of any kind
>
>
>
>
> * The whole point of this, is to indicate that we are talking
> about VM-s and (OCI compliant) containers
> * Maybe we can change „workload” to „virtualisation
> container” if you are not very mutch agains using terms from
> ETSI NFV 😊 .
>
>
> * (Edge Cloud) Infrastructure operator: an organisation
> responsible for operating an (edge cloud) infrastrucure
>
>
> * (Edge Cloud) infrastructure user: an organisation or person who
> is using the (edge cloud) infrastructure services to start
> workload
>
>
> * application user: an organisation or person who is using the
> application services runnig on top of the workloads in the (edge
> cloud) infrastructure
>
>
> * User story 1:
>
>
>
>
> * Can someone provide some references to the Glance edge
> friendly images?
>
>
> * User story 2:
>
>
>
>
> * From requirements point of view what is the difference
> between the multiple operator and the single operator case?
> In both cases there will be a need to transfer user
> metadata, workload images and realtime memory content
> between two edge clouds. Do I miss something (accounting
> maybe)?
>
>
> * User story 3:
>
>
>
>
> * Should we extend this to contain all FM and PM data and
> configurable views?
> * Here I do not see the case when one edge cloud
> infrastructure operator would be interested in the FM and PM
> data of an other edge cloud infrastructure operators
> infrastructure. Can you please explain this a bit? Is this
> the case when one uber operator uses edge cloud
> infrastructure sevice from other operators?
>
>
> * User Story 5:
>
>
>
>
> * In the Kuberentes is deployed directly on bare metal case.
> OpenStack should only provide the hardware management part
> and the capability to deploy Kubernetes.
> * For the Kuberentes deployed in VM-s case: What is the
> purpose of this? This is benefitial only if there is only an
> OpenStack what needs to be extended with the capaility to
> run containers (and still Magnum can deploy COE to bare
> metal if I remember correctly) or someone would like to run
> VM-s and contaienr in the same infra.
>
>
>
>
>
>
> * The question how to deploy OpenStack to the edge sites
> is very valid. I think this should be a separate user
> story. Do we want to deploy OpenStack remotely?
>
>
> * User Story 7:
>
>
>
>
> * Can someone provide a reference to Mahadev Satyanarayanan-s
> cloudlet material?
> * I understand that the different application cases generate
> different traffic patterns, but what is the differentce in
> terms of infrastructure requirements?
>
>
> * User Story 10
>
>
>
>
> * I think the sharing of OpenStack users and tenants is not
> needed between operators. Maybe I’m totally missing this
> multi operator case, so please explain 😊
>
>
> * User Story 12
>
>
>
>
> * So here the required functionly is that when a new edge
> site is built it automaically finds the other clouds in the
> edge cloud infrastructure and builds up the needed
> connections? Is it ok to provide an ip address or fqdn as a
> hint for this or this should be totally automatic?
>
>
> Any comments to anything are welcome 😊
>
>
>
> Br,
>
> Gerg0
>
>
>
>
>
> From: Csatari, Gergely (Nokia - HU/Budapest)
> Sent: Tuesday, December 19, 2017 2:35 PM
> To: 'Claire Massey' < claire at openstack.org >;
> edge-computing at lists.openstack.org
> Subject: RE: [Edge-computing] Upcoming Work Sessions Schedule - Edge
>
>
>
> Hi,
>
>
>
> I think ont he existing gaps we should collect user stories to a
> separate etherpad, so I sarted just an other one:
> https://etherpad.openstack.org/p/2017_edge_computing_working_sessions_existing_gaps
>
>
>
> From the user stories we can generate requirements which can be
> turned into implementable pieces after a while 😊
>
>
>
> Br,
>
> Gerg0
>
>
>
>
>
> From: Claire Massey [ mailto:claire at openstack.org ]
> Sent: Tuesday, December 19, 2017 12:24 AM
> To: edge-computing at lists.openstack.org
> Subject: Re: [Edge-computing] Upcoming Work Sessions Schedule - Edge
>
>
>
> Correction - December 19th at 9:00am CST. Meeting Link:
> https://zoom.us/j/777719876
>
>
>
>
>
>
>
> On Dec 18, 2017, at 5:12 PM, Claire Massey < claire at openstack.org >
> wrote:
>
>
>
>
>
>
> Quick reminder - we have another community Edge Work Session call
> tomorrow Tuesday, December 18 at 9:00am CST .
>
>
>
>
>
> Meeting Link: https://zoom.us/j/777719876
>
>
>
>
>
> Etherpad: :
> https://etherpad.openstack.org/p/2017_edge_computing_working_sessions
>
>
>
>
>
> We look forward to chatting with you all then. Thanks!
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Dec 11, 2017, at 4:31 PM, Claire Massey < claire at openstack.org >
> wrote:
>
>
>
>
>
> Hi everyone,
>
>
>
>
>
> Quick reminder that we have another community Edge Work Session call
> tomorrow, Tuesday, at 9:00am CST.
>
>
>
>
>
> Meeting Link: https://zoom.us/j/777719876
>
>
>
>
>
> Etherpad: :
> https://etherpad.openstack.org/p/2017_edge_computing_working_sessions
>
>
>
>
>
> We look forward to chatting with you all then.
>
>
>
>
>
> Thanks,
>
>
> Claire
>
>
>
>
>
>
>
>
>
>
>
> On Nov 29, 2017, at 12:15 PM, Claire Massey < claire at openstack.org >
> wrote:
>
>
>
>
>
>
> Thank you to everyone who attended the first edge work session call
> yesterday!
>
>
>
>
>
> Records from the meeting:
>
>
> * Etherpad:
> https://etherpad.openstack.org/p/2017_edge_computing_working_sessions
>
>
> * Audio recording of the November 28 meeting:
> https://zoom.us/recording/play/t_XmAP-VK1RRGKhy_Epb4TF57rlOIM1gkd9qvJQ18G9eidjhBS-UHprOzCjA6NSB
>
>
>
>
>
> During the meeting we established three focus areas for work to be
> done:
>
>
> - OpenStack existing gaps
>
>
> - Cross-community efforts
>
>
> - Potential new project needs
>
>
>
>
>
> Volunteers have signed up to help lead these efforts. More details
> and next steps will soon be shared on the mailing list as well as
> the opportunity for others to get involved.
>
>
>
>
>
> The next edge work session call will be on Tuesday, December 12, at
> 9:00am CST (15:00 UTC) at https://zoom.us/j/777719876 .
>
>
>
>
>
> Thanks,
>
>
> Claire
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Nov 26, 2017, at 4:15 PM, Claire Massey < claire at openstack.org >
> wrote:
>
>
>
>
>
> Hi there,
>
>
>
>
>
> Welcome to the new Edge-Computing mailing list!
>
>
>
>
>
> Starting this week the OpenStack Foundation will host a series of
> work sessions to pick up on the progress made at the OpenDev event
> in September [0] and the Edge Use Cases & Architecture forum session
> [1] at the Sydney Summit. The goal for the work sessions is to end
> 2017 with a clear set of edge operational requirements and
> documentation (there’s a whitepaper already in the works).
>
>
>
>
>
> If you’d like to become an active participant to support this effort
> please join us.
>
>
>
>
>
> Agenda and notes will be updated here:
> https://etherpad.openstack.org/p/2017_edge_computing_working_sessions
> .
>
>
>
>
>
> The calls will be held on Tuesday’s at 9:00am CST (15:00 UTC) on
>
>
> *November 28
>
>
> *December 12
>
>
> *December 19
>
>
>
>
>
>
> Meeting Link: https://zoom.us/j/777719876
>
>
>
>
>
> Or Telephone:
>
>
> US: +1 646 876 9923 or +1 669 900 6833 or +1 408 638 0968
>
>
> Meeting ID: 777 719 876
>
>
>
>
>
> International numbers available:
> https://zoom.us/zoomconference?m=QQS_rcoIKkXtIdC_0EpVQ80nU8MYS4Y0
>
>
>
>
>
>
>
>
> ****
>
>
> [0] http://www.opendevconf.com/schedule/
>
>
> [1]
> https://etherpad.openstack.org/p/OS_Sydney_edge_computing_use_cases
>
>
>
>
>
> Thanks,
>
>
> Claire Massey
>
> _______________________________________________
> Edge-computing mailing list
> Edge-computing at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
>
>
>
> _______________________________________________
> Edge-computing mailing list
> Edge-computing at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
>
>
>
> _______________________________________________
> Edge-computing mailing list
> Edge-computing at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
>
>
>
> _______________________________________________
> Edge-computing mailing list
> Edge-computing at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
>
>
>
>
> _______________________________________________
> Edge-computing mailing list
> Edge-computing at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
>
>
>
>
>
>
>
>
> --
>
>
>
>
>
> s
>
>
>
>
>
>
>
>
> --
>
>
>
>
>
> s
> _______________________________________________
> Edge-computing mailing list
> Edge-computing at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
>
More information about the Edge-computing
mailing list