From gergely.csatari at nokia.com Mon Jul 2 11:15:32 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Mon, 2 Jul 2018 11:15:32 +0000 Subject: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation In-Reply-To: <0B139046-4F69-452E-B390-C756543EA270@windriver.com> References: <54898258-0FC0-46F3-9C64-FE4CEEA2B78C@windriver.com> <0B139046-4F69-452E-B390-C756543EA270@windriver.com> Message-ID: Hi, Going inline. From: Waines, Greg [mailto:Greg.Waines at windriver.com] Sent: Friday, June 29, 2018 4:25 AM In-lined comments / questions below, Greg. From: "Csatari, Gergely (Nokia - HU/Budapest)" > Date: Thursday, June 28, 2018 at 3:35 AM Hi, I’ve added the following pros and cons to the different options: * One Glance with multiple backends [1] [Greg] I’m not sure I understand this option. Is each Glance Backend completely independent ? e.g. when I do a “glance image-create ...” am I specifying a backend and that’s where the image is to be stored ? This is what I was originally thinking. So I was thinking that synchronization of images to Edge Clouds is simply done by doing “glance image-create ...” to the appropriate backends. But then you say “The syncronisation of the image data is the responsibility of the backend (eg.: CEPH).” ... which makes it sound like my thinking above is wrong and the Backends are NOT completely independent, but instead in some sort of replication configuration ... is this leveraging ceph replication factor or something (for example) ? [G0]: According to my understanding the backends are in a replication configuration in this case. Jokke, am I right? * Pros: * Relatively easy to implement based on the current Glance architecture * Cons: * Requires the same Glance backend in every edge cloud instance * Requires the same OpenStack version in every edge cloud instance (apart from during upgrade) * Sensitivity for network connection loss is not clear [Greg] I could be wrong, but even though the OpenStack services in the edge clouds are using the images in their glance backend with a direct URL, I think the OpenStack services (e.g. nova) still need to get the direct URL via the Glance API which is ONLY available at the central site. So don’t think this option supports autonomy of edge Subcloud when connectivity is lost to central site. [G0]: Can’t the url point to the local Glance backend somehow? * Several Glances with an independent syncronisation service, sych via Glance API [2] * Pros: * Every edge cloud instance can have a different Glance backend * Can support multiple OpenStack versions in the different edge cloud instances * Can be extended to support multiple VIM types * Cons: * Needs a new synchronisation service [Greg] Don’t believe this is a big con ... suspect we are going to need this new synchronization service for synchronizing resources of a number of other openstack services ... not just glance. [G0]: I agree, it is not a big con, but it is a con 😊 Should I add some note saying, that a synch service is most probably needed anyway? * Several Glances with an independent syncronisation service, synch using the backend [3] [Greg] This option seems a little odd to me. We are synching the GLANCE DB via some new synchronization service, but synching the Images themselves via the backend ... I think that would be tricky to ensure consistency. [G0]: Yes, there is a place for errors here. * Pros: * I could not find any * Cons: * Needs a new synchronisation service * One Glance and multiple Glance API servers [4] * Pros: * Implicitly location aware * Cons: * First usage of an image always takes a long time * In case of network connection error to the central Galnce Nova will have access to the images, but will not be able to figure out if the user have rights to use the image and will not have path to the images data [Greg] Yeah we tripped over the issue that although the Glance API can cache the image itself, it does NOT cache the image meta data (which I am guessing has info like “user access” etc.) ... so this option improves latency of access to image itself but does NOT provide autonomy. We plan on looking at options to resolve this, as we like the “implicit location awareness” of this option ... and believe it is an option that some customers will like. If anyone has any ideas ? Are these correct? Do I miss anything? Thanks, Gerg0 [1]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#One_Glance_with_multiple_backends [2]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_sych_via_Glance_API [3]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_synch_using_the_backend [4]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#One_Glance_and_multiple_Glance_API_servers From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Monday, June 11, 2018 4:29 PM To: Waines, Greg >; OpenStack Development Mailing List (not for usage questions) >; edge-computing at lists.openstack.org Subject: RE: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation Hi, Thanks for the comments. I’ve updated the wiki: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_synch_using_the_backend Br, Gerg0 From: Waines, Greg [mailto:Greg.Waines at windriver.com] Sent: Friday, June 8, 2018 1:46 PM To: Csatari, Gergely (Nokia - HU/Budapest) >; OpenStack Development Mailing List (not for usage questions) >; edge-computing at lists.openstack.org Subject: Re: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation Responses in-lined below, Greg. From: "Csatari, Gergely (Nokia - HU/Budapest)" > Date: Friday, June 8, 2018 at 3:39 AM To: Greg Waines >, "openstack-dev at lists.openstack.org" >, "edge-computing at lists.openstack.org" > Subject: RE: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation Hi, Going inline. From: Waines, Greg [mailto:Greg.Waines at windriver.com] Sent: Thursday, June 7, 2018 2:24 PM I had some additional questions/comments on the Image Synchronization Options ( https://wiki.openstack.org/wiki/Image_handling_in_edge_environment ): One Glance with multiple backends * In this scenario, are all Edge Clouds simply configured with the one central glance for its GLANCE ENDPOINT ? * i.e. GLANCE is a typical shared service in a multi-region environment ? [G0]: In my understanding yes. * If so, how does this OPTION support the requirement for Edge Cloud Operation when disconnected from Central Location ? [G0]: This is an open question for me also. Several Glances with an independent synchronization service (PUSH) * I refer to this as the PUSH model * I don’t believe you have to ( or necessarily should) rely on the backend to do the synchronization of the images * i.e. the ‘Synch Service’ could do this strictly through Glance REST APIs (making it independent of the particular Glance backend ... and allowing the Glance Backends at Central and Edge sites to actually be different) [G0]: Okay, I can update the wiki to reflect this. Should we keep the “synchronization by the backend” option as an other alternative? [Greg] Yeah we should keep it as an alternative. * I think the ‘Synch Service’ MUST be able to support ‘selective/multicast’ distribution of Images from Central to Edge for Image Synchronization * i.e. you don’t want Central Site pushing ALL images to ALL Edge Sites ... especially for the small Edge Sites [G0]: Yes, the question is how to define these synchronization policies. [Greg] Agreed ... we’ve had some very high-level discussions with end users, but haven’t put together a proposal yet. * Not sure ... but I didn’t think this was the model being used in mixmatch ... thought mixmatch was more the PULL model (below) [G0]: Yes, this is more or less my understanding. I remove the mixmatch reference from this chapter. One Glance and multiple Glance API Servers (PULL) * I refer to this as the PULL model * This is the current model supported in StarlingX’s Distributed Cloud sub-project * We run glance-api on all Edge Clouds ... that talk to glance-registry on the Central Cloud, and * We have glance-api setup for caching such that only the first access to an particular image incurs the latency of the image transfer from Central to Edge [G0]: Do you do image caching in Glance API or do you rely in the image cache in Nova? In the Forum session there were some discussions about this and I think the conclusion was that using the image cache of Nova is enough. [Greg] We enabled image caching in the Glance API. I believe that Nova Image Caching caches at the compute node ... this would work ok for all-in-one edge clouds or small edge clouds. But glance-api caching caches at the edge cloud level, so works better for large edge clouds with lots of compute nodes. * * this PULL model affectively implements the location aware synchronization you talk about below, (i.e. synchronise images only to those cloud instances where they are needed)? In StarlingX Distributed Cloud, We plan on supporting both the PUSH and PULL model ... suspect there are use cases for both. [G0]: This means that you need an architecture supporting both. Just for my curiosity what is the use case for the pull model once you have the push model in place? [Greg] The PULL model certainly results in the most efficient distribution of images ... basically images are distributed ONLY to edge clouds that explicitly use the image. Also if the use case is NOT concerned about incurring the latency of the image transfer from Central to Edge on the FIRST use of image then the PULL model could be preferred ... TBD. Here is the updated wiki: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment [Greg] Looks good. Greg. Thanks, Gerg0 From: "Csatari, Gergely (Nokia - HU/Budapest)" > Date: Thursday, June 7, 2018 at 6:49 AM To: "openstack-dev at lists.openstack.org" >, "edge-computing at lists.openstack.org" > Subject: Re: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation Hi, I did some work ont he figures and realised, that I have some questions related to the alternative options: Multiple backends option: * What is the API between Glance and the Glance backends? * How is it possible to implement location aware synchronisation (synchronise images only to those cloud instances where they are needed)? * Is it possible to have different OpenStack versions in the different cloud instances? * Can a cloud instance use the locally synchronised images in case of a network connection break? * Is it possible to implement this without storing database credentials ont he edge cloud instances? Independent synchronisation service: * If I understood [1] correctly mixmatch can help Nova to attach a remote volume, but it will not help in synchronizing the images. is this true? As I promised in the Edge Compute Group call I plan to organize an IRC review meeting to check the wiki. Please indicate your availability in [2]. [1]: https://mixmatch.readthedocs.io/en/latest/ [2]: https://doodle.com/poll/bddg65vyh4qwxpk5 Br, Gerg0 From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Wednesday, May 23, 2018 8:59 PM To: OpenStack Development Mailing List (not for usage questions) >; edge-computing at lists.openstack.org Subject: [edge][glance]: Wiki of the possible architectures for image synchronisation Hi, Here I send the wiki page [1] where I summarize what I understood from the Forum session about image synchronisation in edge environment [2], [3]. Please check and correct/comment. Thanks, Gerg0 [1]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment [2]: https://etherpad.openstack.org/p/yvr-edge-cloud-images [3]: https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21768/image-handling-in-an-edge-cloud-infrastructure -------------- next part -------------- An HTML attachment was scrubbed... URL: From claire at openstack.org Mon Jul 2 15:04:35 2018 From: claire at openstack.org (claire at openstack.org) Date: Mon, 02 Jul 2018 15:04:35 +0000 Subject: [Edge-computing] Updated invitation: Weekly Edge Computing Group Call (14:00 UTC) @ Weekly from 9am to 10am on Tuesday from Tue Jun 5 to Tue Jul 3 (CDT) (edge-computing@lists.openstack.org) Message-ID: <00000000000005297005700584b9@google.com> This event has been changed. Title: Weekly Edge Computing Group Call (14:00 UTC) Weekly agenda & call notes: https://wiki.openstack.org/wiki/Edge_Computing_Group When: Weekly from 9am to 10am on Tuesday from Tue Jun 5 to Tue Jul 3 Central Time (changed) Where: https://zoom.us/j/777719876 Calendar: edge-computing at lists.openstack.org Who: * claire at openstack.org - organizer * Ildiko Vancsa * edge-computing at lists.openstack.org * Jonathan Bryce Event details: https://www.google.com/calendar/event?action=VIEW&eid=XzZwMmo4ZGkyNm9zamdiOWc4Z3I0Y2I5azY0cTM2YmEyNjBwNGFiYTY4cDMzNGNhMzYwcjRjZHBvNmMgZWRnZS1jb21wdXRpbmdAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MjAjY2xhaXJlQG9wZW5zdGFjay5vcmdjMmIxNDlkNjAxNmQ0YjE2YjIxN2ZmYzM2MzYzODk3NzZhZGQyNzdm&ctz=America%2FChicago&hl=en&es=0 Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account edge-computing at lists.openstack.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2508 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2574 bytes Desc: not available URL: From claire at openstack.org Mon Jul 2 15:07:04 2018 From: claire at openstack.org (claire at openstack.org) Date: Mon, 02 Jul 2018 15:07:04 +0000 Subject: [Edge-computing] Invitation: Weekly Edge Computing Group Call (0700 UTC) @ Monthly from 2am to 3am on the first Thursday from Thu Jul 5 to Thu Nov 1 (CDT) (edge-computing@lists.openstack.org) Message-ID: <000000000000e7e11e0570058c7f@google.com> You have been invited to the following event. Title: Weekly Edge Computing Group Call (0700 UTC) Weekly agenda & call notes: https://wiki.openstack.org/wiki/Edge_Computing_Group When: Monthly from 2am to 3am on the first Thursday from Thu Jul 5 to Thu Nov 1 Central Time Where: https://zoom.us/j/879678938 Calendar: edge-computing at lists.openstack.org Who: * claire at openstack.org - organizer * edge-computing at lists.openstack.org * Ildiko Vancsa Event details: https://www.google.com/calendar/event?action=VIEW&eid=XzZsMWoyZ3E1NzBwa2NiYTQ2bDJqY2I5azhrc2s0YjlwOGdyajBiOWc4OG9rNmhpMjhwMzM2Z2k1NzQgZWRnZS1jb21wdXRpbmdAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MjAjY2xhaXJlQG9wZW5zdGFjay5vcmdmMDhjZjJiNTY2MzRjNzlmNTJiOWM5MDkwYWRkY2MyZmEwOTMzODMy&ctz=America%2FChicago&hl=en&es=0 Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account edge-computing at lists.openstack.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2150 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2206 bytes Desc: not available URL: From claire at openstack.org Mon Jul 2 15:17:27 2018 From: claire at openstack.org (claire at openstack.org) Date: Mon, 02 Jul 2018 15:17:27 +0000 Subject: [Edge-computing] Invitation: Weekly Edge Computing Group Call (14:00 UTC) @ Weekly from 9am to 10am on Tuesday from Tue Jul 10 to Tue Nov 6 except Tue Jul 31 9am, Tue Sep 4 9am, Tue Oct 2 9am or Tue Oct 30 9am (CDT) (edge-computing@lists.openstack.org) Message-ID: <00000000000009cd5f057005b27c@google.com> You have been invited to the following event. Title: Weekly Edge Computing Group Call (14:00 UTC) Weekly agenda & call notes: https://wiki.openstack.org/wiki/Edge_Computing_Group When: Weekly from 9am to 10am on Tuesday from Tue Jul 10 to Tue Nov 6 except Tue Jul 31 9am, Tue Sep 4 9am, Tue Oct 2 9am or Tue Oct 30 9am Central Time Where: https://zoom.us/j/879678938 Calendar: edge-computing at lists.openstack.org Who: * claire at openstack.org - organizer * edge-computing at lists.openstack.org * Ildiko Vancsa Event details: https://www.google.com/calendar/event?action=VIEW&eid=Xzg1MmplYzFuODRzNDJiYTY2NTJrY2I5azg4bzMyYmEyNjEyNDhiYTI4Z3M0MmU5bjZkMzM2Y2k1NjAgZWRnZS1jb21wdXRpbmdAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MjAjY2xhaXJlQG9wZW5zdGFjay5vcmc0NTdlNmNiMmIwZjQ4MWJjMTQ4Nzg0NjNjZDlmNDVlNDI0NWZmYjdj&ctz=America%2FChicago&hl=en&es=0 Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account edge-computing at lists.openstack.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2326 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2386 bytes Desc: not available URL: From claire at openstack.org Mon Jul 2 15:17:49 2018 From: claire at openstack.org (Claire Massey) Date: Mon, 2 Jul 2018 10:17:49 -0500 Subject: [Edge-computing] Weekly Calls - New Day/Time for First Week of the Month Message-ID: Hi everyone, Please make note of the update to the Edge Computing Group's weekly call schedule between now and the Berlin Summit in November. The zoom link has also been updated - all of the weekly edge calls will use this link: https://zoom.us/j/879678938 Starting this week on July 5 - on the first week of every month our weekly calls will be held in an APAC friendly time - Thursdays at 0700 UTC (midnight PDT). Throughout the rest of the month the weekly calls will continue as usual on Tuesdays at 1400 UTC (7:00am PDT). The meeting invites and wiki have been updated to reflect the new schedule: https://wiki.openstack.org/wiki/Edge_Computing_Group . Schedule for reference: THURSDAYS at 0700 UTC (midnight PDT) * July 5 * August 2 * September 6 * October 4 * November 1 TUESDAYS at 1400 UTC (7:00am PDT): * July 10 * July 17 * July 24 * August 7 * August 15 * August 21 * August 28 * September 11 (skip call, instead meet F2F at Denver PTG) * September 18 * September 25 * October 9 * October 16 * October 23 * November 6 * November 13 (skip call, instead meet F2F at Berlin Summit) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Tue Jul 3 11:00:43 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Tue, 3 Jul 2018 11:00:43 +0000 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion=5Fof=5FRequirements?= In-Reply-To: <22b0f0f372f14815bdf57cc0aedfd9eb@kontron.com> References: 201806201003064375530@chinamobile.com> <00aa01d4083c$129c7350$37d559f0$@chinamobile.com> <010e01d40874$fcb3d720$f61b8560$@chinamobile.com> <012001d40879$20bab900$62302b00$@chinamobile.com> <7b2e5862b8e84260984b2983d286c8e7@kontron.com> <22b0f0f372f14815bdf57cc0aedfd9eb@kontron.com> Message-ID: Hi, Isn’t this case covered by [1] ? On the other hand there is a new set of deployment options listed by OPNFV in [2]. It would be nice if we could harmonize these somehow… [1]: https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG#Small_edge [2]: https://gerrit.opnfv.org/gerrit/#/c/58959/4/docs/development/requirements/requirements.rst Br, Gerg0 From: Éric Sarault [mailto:Eric.Sarault at kontron.com] Sent: Tuesday, June 26, 2018 2:50 PM To: Csatari, Gergely (Nokia - HU/Budapest) ; Fu Qiao ; '赵奇慧' ; 'lebre.adrien' Cc: 'edge-computing' ; 'paul-andre raymond' Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Yes, in some scenarios, we need to consider CPE units. This could be a consumer endpoint device/appliance that looks like your typical router from your ISV. These are typically ARM based units or you could also see some Intel Xeon-D units there (Atom worst case). The use case behind is to manage tens of thousands of these as an edge federation. At the same scale, think also Industrial IoT or Retail. My point is not everything is a rackmount format so we just need to be clear what the target is here as the form factor might limit the versatility of one or many use cases. --- Eric Sarault, B. Eng. Software Product Manager Kontron – An S&T Company 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada P: +1 (450) 437-5682 x eric.sarault at kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Canada Inc. By opening this email you are agreeing to Kontron's Electronic Communications Policy. From: Csatari, Gergely (Nokia - HU/Budapest) > Sent: June 26, 2018 7:09 AM To: Éric Sarault >; Fu Qiao >; '赵奇慧' >; 'lebre.adrien' > Cc: 'edge-computing' >; 'paul-andre raymond' > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, So you mean that the minimum HW spec is smaller thean 1 unit? Br, Gerg0 From: Éric Sarault [mailto:Eric.Sarault at kontron.com] Sent: Wednesday, June 20, 2018 3:14 PM To: Csatari, Gergely (Nokia - HU/Budapest) >; Fu Qiao >; '赵奇慧' >; 'lebre.adrien' > Cc: 'edge-computing' >; 'paul-andre raymond' > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Is the purpose of limiting the small edge to 1U is to classify it as the CPE use case? We need to keep in mind some CPE/vCPE equipment isn’t even “rackmountable” so we need to keep track of this (i.e: set up box, ISV router). --- Eric Sarault, B. Eng. Software Product Manager Kontron – An S&T Company 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada P: +1 (450) 437-5682 x eric.sarault at kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Canada Inc. By opening this email you are agreeing to Kontron's Electronic Communications Policy. From: Csatari, Gergely (Nokia - HU/Budapest) > Sent: June 20, 2018 5:36 AM To: Fu Qiao >; '赵奇慧' >; 'lebre.adrien' > Cc: 'edge-computing' >; 'paul-andre raymond' > Subject: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, I am okay with your classification for small, medium and large. Br, Gerg0 From: Fu Qiao [mailto:fuqiao at chinamobile.com] Sent: Wednesday, June 20, 2018 11:29 AM To: Csatari, Gergely (Nokia - HU/Budapest) >; '赵奇慧' >; 'lebre.adrien' > Cc: 'edge-computing' >; 'paul-andre raymond' > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Georgly. I read through the wiki definition for small and medium, and I guess it probably is not that direct to just define a large edge scenario. I notice that in the medium edge, the size is 2U-20U, which actually include the large edge as defined in the following email. I am afraid we probably will need detailed discussion about the size limitation for each different type, so as to make this whole definition easy to be accept. A possible proposal could be 1U for small, 2U-20U for medium, and 20-100U(or even larger) for large. So the small one can fit for CPE, medium one can fit for access and counties, and large one can fit for counties and cities 发件人: Csatari, Gergely (Nokia - HU/Budapest) [mailto:gergely.csatari at nokia.com] 发送时间: 2018年6月20日 17:18 收件人: Fu Qiao >; '赵奇慧' >; 'lebre.adrien' > 抄送: 'edge-computing' >; 'paul-andre raymond' > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Thanks for the info. I’m okay to add a large edge deployment scenario. What charasterestics should it have? * Minimum hardware specs: 10 units * Maximum hardware specs: 20 units * Physical access of maintainer: * Physical security: * Expected frequency of updates to hardware: * Expected frequency of updates to firmware: * Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): * Remote access/connectivity reliability (24/24, periodic, ...): * Physical size: * Number of instances (Edge TIC Country / Edge TIC AP according to [6]): * Distance from Base Station (Access-level DC according to [6]): * E2E delay (from UE to site) (Access according to [6]): * Bandwith need (Access according to [6]): Br, Gerg0 From: Fu Qiao [mailto:fuqiao at chinamobile.com] Sent: Wednesday, June 20, 2018 10:59 AM To: Csatari, Gergely (Nokia - HU/Budapest) >; '赵奇慧' >; 'lebre.adrien' > Cc: 'edge-computing' >; 'paul-andre raymond' > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Gergely. Actually what I am thinking is we probably need more definition for edge scenarios. I think the definition for small edge and medium edge in the white paper make sense to me, since they basically cover the usecase for customer premises usecases. However, I guess another scenario should also be added which includes 10-20 units. Such scenario is what we say for access and county level. Such unit is not that resource limited as small and medium edge, but we should also consider the resource constrains and make fully use of the limited resource. As for city level, I understand we can probably use the large edge definition for this, since it could be a quite typical cloud at that level. Hope this will help. 发件人: Csatari, Gergely (Nokia - HU/Budapest) [mailto:gergely.csatari at nokia.com] 发送时间: 2018年6月20日 16:49 收件人: Fu Qiao >; '赵奇慧' >; 'lebre.adrien' > 抄送: 'edge-computing' >; 'paul-andre raymond' > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Thanks for the comments. I’m not sure at all, that we follow the definitions from the whitepaper in the wiki 😊 I referred your talk and the naming you user there becouse of the differences in the definitions. Going inline. From: Fu Qiao [mailto:fuqiao at chinamobile.com] Sent: Wednesday, June 20, 2018 4:12 AM Hi, all. I guess some more explanations for the China Mobile’s network should be added here. The definition for small and medium edge from the whitepaper actually is different from what we say about access/county/city. Our access level CO will include compute nodes of about ten more, with distance from the Base station of 10km, delay about 2ms, and bandwidth about 50GB. [G0]: Should I add 10 units to the maximum hardware specs part of the Small edge deployment option? Our county level CO includes tens of compute nodes, with distance of 50km, delay about 2.5ms, and bandwidth of about 100GB. City level CO will have hundreds of servers, with distance of more than 100km. I guess the small edge defined in the Whitepaper, with up to 1U, is somehow suitable for edge equipment at the customer site, and this is not actually discussed in my presentation. 发件人: 赵奇慧 [mailto:zhaoqihui at chinamobile.com] 发送时间: 2018年6月20日 10:03 Hi Gergely, It's great that our data can help. But I think according the the previous definitions of small edge and medium edge, there should be a little modification here. For Small edge, the maximum hardware specs is up to 1 unit, which is similar to our Access-level DC/Edge TIC AP. For Mediun edge, the hardware spec varies from 2RU to 20RU, which is somehow like our County-level DC. So here is my suggestion: --------------------------------------------------------------------------- Small edge: · Number of instances (Edge TIC AP according to [6]): depend on demands [G0]: Can we say 3000+ here in a paranthesis? · Distance from Base Station (Access-level DC according to [6]): around 10km · E2E delay (from UE to site)(Access according to [6]): 2 ms · Bandwith need (Access according to [6]): 50 GB Medium edge: · Number of instances (Edge TIC County according to [6]): 3000+ · Distance from Base Station (Access-level DC according to [6]): around 50km · E2E delay (from UE to site) (Access according to [6]): less than 2.5 ms · Bandwith need (Access according to [6]): 100GB ---------------------------------------------------------------------------- [G0]: I’ve updated these to the wiki. Thanks, Gerg0 Best Regards, Qihui Zhao ________________________________ China Mobile Research Institute Department of Network Technology 发件人: Csatari, Gergely (Nokia - HU/Budapest) 时间: 2018/06/15(星期五)22:14 收件人: lebre.adrien; 抄送人: paul-andre raymond;edge-computing; 主题: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, I was thinking about the generic deployment specific requirements, like bandwiths and delays. I've added some of them from the CM presentation to https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Small_edge and https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Medium_edge Br, Gerg0 -----Original Message----- From: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] Sent: Thursday, June 14, 2018 11:39 PM To: Csatari, Gergely (Nokia - HU/Budapest) > Cc: Arkady Kanevsky >; fuqiao at chinamobile.com; paul-andre raymond >; edge-computing at lists.openstack.org Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements Hi all, Maybe we can try to prioritise the projects we want to investigate and then for each of them identify what are the missing elements/capabilities (one after the others) There are ongoing works on Keystone and Glance. Nova, Neutron could be the next ones because these 4 services would allow to deploy VM at the edge (and so containers inside VMs). Cinder will enable the use of remote attached volumes. Ironic can be useful later. etc.. My two cents, Ad_ri3n_ ----- Mail original ----- > De: "Gergely Csatari (Nokia - HU/Budapest)" > > > À: "Arkady Kanevsky" >, fuqiao at chinamobile.com, "paul-andre raymond" > >, "lebre adrien" > >, edge-computing at lists.openstack.org > Envoyé: Mercredi 13 Juin 2018 17:38:35 > Objet: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > Hi, > > Somehow I have a feeling that these latency requirements are related > to all projects, this is why they should be documented in the > Deployment options section. > > Br, > Gerg0 > > -----Original Message----- > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > Sent: Wednesday, June 13, 2018 4:24 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > >; fuqiao at chinamobile.com; > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr; > edge-computing at lists.openstack.org > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > Gerg0, > I think these 3 projects are implied from the wiki requirements. > But it will be good to state projects that may need work explicitly. > Thanks, > Arkady > > -----Original Message----- > From: Csatari, Gergely (Nokia - HU/Budapest) > [mailto:gergely.csatari at nokia.com] > Sent: Wednesday, June 13, 2018 4:23 AM > To: Kanevsky, Arkady; fuqiao at chinamobile.com; > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr; > edge-computing at lists.openstack.org > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > Hi, > > Should we add these to the Deployment Scenarions section of the Dublin > wiki [1]? > > [1]: > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG# > Deployment_Scenarios > > Br, > Gerg0 > > -----Original Message----- > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > Sent: Wednesday, June 6, 2018 4:49 PM > To: fuqiao at chinamobile.com; paul-andre.raymond at b-yond.com; > lebre.adrien at free.fr; edge-computing at lists.openstack.org > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements > > It is more than just nova to keystone. > We also need to consider at least neutron, glance and cinder also. > > -----Original Message----- > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 6, 2018 8:21 AM > To: 'Paul-Andre Raymond'; lebre.adrien at free.fr; > edge-computing at lists.openstack.org > Subject: [Edge-computing] 答复: 答复: Clarification of Requirements > > Yes, 5ms is one way. But this is an assumption based on the network > from China Mobile. The latency will be defer if you have different > distance, but the calculation method is the same apparently. > > -----邮件原件----- > 发件人: Paul-Andre Raymond [mailto:paul-andre.raymond at b-yond.com] > 发送时间: 2018年6月6日 21:19 > 收件人: Fu Qiao >; lebre.adrien at free.fr; > edge-computing at lists.openstack.org > 主题: Re: [Edge-computing] 答复: Clarification of Requirements > > Should we separate two kinds of latency requirements: > - Federation Latency: i.e Central Keystone to Local Keystone > - API latency: i.e. Edge Nova to local Keystone > > Should we measure it one way or Round Trip? I assume the 5ms below is > one way. > > > Paul-André > -- > > > On 6/6/18, 5:13 AM, "Fu Qiao" > wrote: > > Thank you Adrien. I was just about the reply with more details. > > About latency, this as I understand is actually decided mostly by > the distance of the distributed cloud. So it actually decided by > where exactly the location Keystone would like to deploy, and > what is the distance expectation. Like what I explain in my > presentation, we plan to have keystone sitting in the city level > to control multi cloud in counties, and the latency will be > around 5ms. But again this is a certain situation for China > Mobile. And other operators may make the conlusion on a > different structure. Another thing we can do is work on > simulation and testing and see what kind of latency the current > keystone federation scheme can tolerant. This will help the > operators to work out there structure as well. > > About bandwidth, the impression for me is we could expect more > than 50GB of bandwidth for edge for 5G. And I think that is > enough for most of the app. > > Hope this will help. > > -----邮件原件----- > 发件人: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] > 发送时间: 2018年6月6日 15:25 > 收件人: edge-computing at lists.openstack.org > 主题: Re: [Edge-computing] Clarification of Requirements > > It is rather difficult to give numbers because there are several > use-cases. > However, a good starting point can be to give a look to the > presentation Qiao Fu gave during the Vancouver summit: > https://www.openstack.org/videos/vancouver-2018/edge-tic-future-edge-cloud-for-china-mobile > There is a lot of numbers regarding the infrastructure China > Mobile is envisioning. > > Hope this helps. > ad_ri3n_ > PS: I cannot attend the meeting yesterday unfortunately but I'm > wondering whether the disconnection aspects have been discussed > (i.e. the fact that one site can be completely isolated for a > certain period of time due to network disconnections). > > ----- Mail original ----- > > De: "Jess Lampe" > > > À: edge-computing at lists.openstack.org > > Envoyé: Mercredi 6 Juin 2018 07:00:31 > > Objet: [Edge-computing] Clarification of Requirements > > > > > > > > > > During the call today, members of the Glance and Keystone teams > > requested clarity on the following areas: > > > > > > > > * Latency - what are the specific latency requirements that > > need > > to be met? > > * Bandwidth towards the edge - similarly, what are the > > limitations of bandwidth at the edge that we can expect? > > * Security - what are the specific security considerations > > that > > need to be? > > > > > > Please feel free to A.) contribute additional areas that need > > clarifying B.) clarify any of the added. > > > > > > > > > > _______________________________________________ > > 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 > _______________________________________________ Edge-computing mailing list Edge-computing at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing -------------- next part -------------- An HTML attachment was scrubbed... URL: From Greg.Waines at windriver.com Tue Jul 3 11:38:47 2018 From: Greg.Waines at windriver.com (Waines, Greg) Date: Tue, 3 Jul 2018 11:38:47 +0000 Subject: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation In-Reply-To: References: <54898258-0FC0-46F3-9C64-FE4CEEA2B78C@windriver.com> <0B139046-4F69-452E-B390-C756543EA270@windriver.com> Message-ID: In-lined below, Greg From: "Csatari, Gergely (Nokia - HU/Budapest)" Date: Monday, July 2, 2018 at 7:15 AM To: Greg Waines , "openstack-dev at lists.openstack.org" , "edge-computing at lists.openstack.org" Subject: RE: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation Hi, Going inline. From: Waines, Greg [mailto:Greg.Waines at windriver.com] Sent: Friday, June 29, 2018 4:25 AM In-lined comments / questions below, Greg. From: "Csatari, Gergely (Nokia - HU/Budapest)" > Date: Thursday, June 28, 2018 at 3:35 AM Hi, I’ve added the following pros and cons to the different options: * One Glance with multiple backends [1] [Greg] I’m not sure I understand this option. Is each Glance Backend completely independent ? e.g. when I do a “glance image-create ...” am I specifying a backend and that’s where the image is to be stored ? This is what I was originally thinking. So I was thinking that synchronization of images to Edge Clouds is simply done by doing “glance image-create ...” to the appropriate backends. But then you say “The syncronisation of the image data is the responsibility of the backend (eg.: CEPH).” ... which makes it sound like my thinking above is wrong and the Backends are NOT completely independent, but instead in some sort of replication configuration ... is this leveraging ceph replication factor or something (for example) ? [G0]: According to my understanding the backends are in a replication configuration in this case. Jokke, am I right? * Pros: * Relatively easy to implement based on the current Glance architecture * Cons: * Requires the same Glance backend in every edge cloud instance * Requires the same OpenStack version in every edge cloud instance (apart from during upgrade) * Sensitivity for network connection loss is not clear [Greg] I could be wrong, but even though the OpenStack services in the edge clouds are using the images in their glance backend with a direct URL, I think the OpenStack services (e.g. nova) still need to get the direct URL via the Glance API which is ONLY available at the central site. So don’t think this option supports autonomy of edge Subcloud when connectivity is lost to central site. [G0]: Can’t the url point to the local Glance backend somehow? [Greg] Need some input from Nova or Glance guy, but believe that Nova must still use Glance API to get access to the image, however if the storage is remote, there can be some backend optimization between glance and nova, e.g. a direct URL to the image. * Several Glances with an independent syncronisation service, sych via Glance API [2] * Pros: * Every edge cloud instance can have a different Glance backend * Can support multiple OpenStack versions in the different edge cloud instances * Can be extended to support multiple VIM types * Cons: * Needs a new synchronisation service [Greg] Don’t believe this is a big con ... suspect we are going to need this new synchronization service for synchronizing resources of a number of other openstack services ... not just glance. [G0]: I agree, it is not a big con, but it is a con 😊 Should I add some note saying, that a synch service is most probably needed anyway? * Several Glances with an independent syncronisation service, synch using the backend [3] [Greg] This option seems a little odd to me. We are synching the GLANCE DB via some new synchronization service, but synching the Images themselves via the backend ... I think that would be tricky to ensure consistency. [G0]: Yes, there is a place for errors here. * Pros: * I could not find any * Cons: * Needs a new synchronisation service * One Glance and multiple Glance API servers [4] * Pros: * Implicitly location aware * Cons: * First usage of an image always takes a long time * In case of network connection error to the central Galnce Nova will have access to the images, but will not be able to figure out if the user have rights to use the image and will not have path to the images data [Greg] Yeah we tripped over the issue that although the Glance API can cache the image itself, it does NOT cache the image meta data (which I am guessing has info like “user access” etc.) ... so this option improves latency of access to image itself but does NOT provide autonomy. We plan on looking at options to resolve this, as we like the “implicit location awareness” of this option ... and believe it is an option that some customers will like. If anyone has any ideas ? Are these correct? Do I miss anything? Thanks, Gerg0 [1]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#One_Glance_with_multiple_backends [2]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_sych_via_Glance_API [3]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_synch_using_the_backend [4]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#One_Glance_and_multiple_Glance_API_servers From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Monday, June 11, 2018 4:29 PM To: Waines, Greg >; OpenStack Development Mailing List (not for usage questions) >; edge-computing at lists.openstack.org Subject: RE: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation Hi, Thanks for the comments. I’ve updated the wiki: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_synch_using_the_backend Br, Gerg0 From: Waines, Greg [mailto:Greg.Waines at windriver.com] Sent: Friday, June 8, 2018 1:46 PM To: Csatari, Gergely (Nokia - HU/Budapest) >; OpenStack Development Mailing List (not for usage questions) >; edge-computing at lists.openstack.org Subject: Re: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation Responses in-lined below, Greg. From: "Csatari, Gergely (Nokia - HU/Budapest)" > Date: Friday, June 8, 2018 at 3:39 AM To: Greg Waines >, "openstack-dev at lists.openstack.org" >, "edge-computing at lists.openstack.org" > Subject: RE: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation Hi, Going inline. From: Waines, Greg [mailto:Greg.Waines at windriver.com] Sent: Thursday, June 7, 2018 2:24 PM I had some additional questions/comments on the Image Synchronization Options ( https://wiki.openstack.org/wiki/Image_handling_in_edge_environment ): One Glance with multiple backends * In this scenario, are all Edge Clouds simply configured with the one central glance for its GLANCE ENDPOINT ? * i.e. GLANCE is a typical shared service in a multi-region environment ? [G0]: In my understanding yes. * If so, how does this OPTION support the requirement for Edge Cloud Operation when disconnected from Central Location ? [G0]: This is an open question for me also. Several Glances with an independent synchronization service (PUSH) * I refer to this as the PUSH model * I don’t believe you have to ( or necessarily should) rely on the backend to do the synchronization of the images * i.e. the ‘Synch Service’ could do this strictly through Glance REST APIs (making it independent of the particular Glance backend ... and allowing the Glance Backends at Central and Edge sites to actually be different) [G0]: Okay, I can update the wiki to reflect this. Should we keep the “synchronization by the backend” option as an other alternative? [Greg] Yeah we should keep it as an alternative. * I think the ‘Synch Service’ MUST be able to support ‘selective/multicast’ distribution of Images from Central to Edge for Image Synchronization * i.e. you don’t want Central Site pushing ALL images to ALL Edge Sites ... especially for the small Edge Sites [G0]: Yes, the question is how to define these synchronization policies. [Greg] Agreed ... we’ve had some very high-level discussions with end users, but haven’t put together a proposal yet. * Not sure ... but I didn’t think this was the model being used in mixmatch ... thought mixmatch was more the PULL model (below) [G0]: Yes, this is more or less my understanding. I remove the mixmatch reference from this chapter. One Glance and multiple Glance API Servers (PULL) * I refer to this as the PULL model * This is the current model supported in StarlingX’s Distributed Cloud sub-project * We run glance-api on all Edge Clouds ... that talk to glance-registry on the Central Cloud, and * We have glance-api setup for caching such that only the first access to an particular image incurs the latency of the image transfer from Central to Edge [G0]: Do you do image caching in Glance API or do you rely in the image cache in Nova? In the Forum session there were some discussions about this and I think the conclusion was that using the image cache of Nova is enough. [Greg] We enabled image caching in the Glance API. I believe that Nova Image Caching caches at the compute node ... this would work ok for all-in-one edge clouds or small edge clouds. But glance-api caching caches at the edge cloud level, so works better for large edge clouds with lots of compute nodes. * * this PULL model affectively implements the location aware synchronization you talk about below, (i.e. synchronise images only to those cloud instances where they are needed)? In StarlingX Distributed Cloud, We plan on supporting both the PUSH and PULL model ... suspect there are use cases for both. [G0]: This means that you need an architecture supporting both. Just for my curiosity what is the use case for the pull model once you have the push model in place? [Greg] The PULL model certainly results in the most efficient distribution of images ... basically images are distributed ONLY to edge clouds that explicitly use the image. Also if the use case is NOT concerned about incurring the latency of the image transfer from Central to Edge on the FIRST use of image then the PULL model could be preferred ... TBD. Here is the updated wiki: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment [Greg] Looks good. Greg. Thanks, Gerg0 From: "Csatari, Gergely (Nokia - HU/Budapest)" > Date: Thursday, June 7, 2018 at 6:49 AM To: "openstack-dev at lists.openstack.org" >, "edge-computing at lists.openstack.org" > Subject: Re: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation Hi, I did some work ont he figures and realised, that I have some questions related to the alternative options: Multiple backends option: - What is the API between Glance and the Glance backends? - How is it possible to implement location aware synchronisation (synchronise images only to those cloud instances where they are needed)? - Is it possible to have different OpenStack versions in the different cloud instances? - Can a cloud instance use the locally synchronised images in case of a network connection break? - Is it possible to implement this without storing database credentials ont he edge cloud instances? Independent synchronisation service: - If I understood [1] correctly mixmatch can help Nova to attach a remote volume, but it will not help in synchronizing the images. is this true? As I promised in the Edge Compute Group call I plan to organize an IRC review meeting to check the wiki. Please indicate your availability in [2]. [1]: https://mixmatch.readthedocs.io/en/latest/ [2]: https://doodle.com/poll/bddg65vyh4qwxpk5 Br, Gerg0 From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Wednesday, May 23, 2018 8:59 PM To: OpenStack Development Mailing List (not for usage questions) >; edge-computing at lists.openstack.org Subject: [edge][glance]: Wiki of the possible architectures for image synchronisation Hi, Here I send the wiki page [1] where I summarize what I understood from the Forum session about image synchronisation in edge environment [2], [3]. Please check and correct/comment. Thanks, Gerg0 [1]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment [2]: https://etherpad.openstack.org/p/yvr-edge-cloud-images [3]: https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21768/image-handling-in-an-edge-cloud-infrastructure -------------- next part -------------- An HTML attachment was scrubbed... URL: From Greg.Waines at windriver.com Tue Jul 3 12:01:35 2018 From: Greg.Waines at windriver.com (Waines, Greg) Date: Tue, 3 Jul 2018 12:01:35 +0000 Subject: [Edge-computing] Keystone Edge Architectures In-Reply-To: References: <678C1A99-2302-438D-8D5D-91ED44B10FF9@windriver.com> <2e2495d6-531f-c0a4-27d6-3c15da111289@gmail.com> <8CB60A46-2C68-444F-994C-45D88FE77D74@windriver.com> <28270e37-13b5-2baa-6952-b084f81e3887@gmail.com> Message-ID: Hey Lance, Just following up again on the info below you provided on previous discussions on issues with API-based Synchronization of Keystone between clouds. In your example below, wouldn’t the API-based Synchronization of the user password change @ A (assuming A is the central site), result in the user password change @ B “and” the corresponding revocation event being created @ B ? Greg. < SNIP > The concept of replicating data over the API was also brought up towards the end of the call as a possible solution. The TL;DR is that each deployment would be independent, but data would be kept in sync by making API requests that forcibly create entities with the same IDs (manual replication if you will). This idea has been discussed at length over the last couple years [0]. We most recently discussed it during the summit in Sydney. Where we really tripped was replication of revocation events. For example, assume you have the ability in keystone to forcibly create things with specific IDs, allowing you to manually replicate data across your edge deployments. At the same time you're keeping the fernet keys in sync, so a user can actually generate tokens in one deployment and use them in other (since each keystone node has the same IDs for projects, domains, users, etc..), even though replication isn't happening at the database. Revocation events are records used internally by keystone to track events that affect token validity (e.g. a user changing their password or deleting a specific token), and they are not exposed via keystone's API. The concern is that without replicating this table, it would be possible for a user to: - generate a token in deployment A - use the token in deployment B to do something - change their password in deployment A, which creates a revocation event invalidating the token from step one in deployment A - the user attempts to use the token from step one in deployment A but it is considered invalid (due to the revocation event) - the user successfully executes API calls with the token from step one in deployment B because deployment B has no knowledge of the revocation event in deployment A We didn't get into that much detail in the call, but wanted to share where the conversation ended up the last time we had it. [0] https://review.openstack.org/#/c/323499/ < SNIP > -------------- next part -------------- An HTML attachment was scrubbed... URL: From claire at openstack.org Tue Jul 3 14:14:51 2018 From: claire at openstack.org (Claire Massey) Date: Tue, 3 Jul 2018 09:14:51 -0500 Subject: [Edge-computing] Weekly Calls - New Day/Time for First Week of the Month In-Reply-To: References: Message-ID: <0D85AEE6-38F1-4A7E-9C38-956DF94319DE@openstack.org> Quick reminder - there’s no call today. The first week of every month the calls will be held on Thursdays at 0700 UTC (midnight PDT). Please join the Thursday call on July 5. > On Jul 2, 2018, at 10:17 AM, Claire Massey wrote: > > Hi everyone, > > Please make note of the update to the Edge Computing Group's weekly call schedule between now and the Berlin Summit in November. > > The zoom link has also been updated - all of the weekly edge calls will use this link: https://zoom.us/j/879678938 > > Starting this week on July 5 - on the first week of every month our weekly calls will be held in an APAC friendly time - Thursdays at 0700 UTC (midnight PDT). Throughout the rest of the month the weekly calls will continue as usual on Tuesdays at 1400 UTC (7:00am PDT). > > The meeting invites and wiki have been updated to reflect the new schedule: https://wiki.openstack.org/wiki/Edge_Computing_Group . > > Schedule for reference: > > THURSDAYS at 0700 UTC (midnight PDT) > * July 5 > * August 2 > * September 6 > * October 4 > * November 1 > > TUESDAYS at 1400 UTC (7:00am PDT): > * July 10 > * July 17 > * July 24 > * August 7 > * August 15 > * August 21 > * August 28 > * September 11 (skip call, instead meet F2F at Denver PTG) > * September 18 > * September 25 > * October 9 > * October 16 > * October 23 > * November 6 > * November 13 (skip call, instead meet F2F at Berlin Summit) > > > > _______________________________________________ > Edge-computing mailing list > Edge-computing at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuqiao at chinamobile.com Wed Jul 4 01:06:21 2018 From: fuqiao at chinamobile.com (Fu Qiao) Date: Wed, 4 Jul 2018 09:06:21 +0800 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAg562U5aSNOiAg?= =?utf-8?q?Clarification=5Fof=5FRequirements?= In-Reply-To: References: 201806201003064375530@chinamobile.com> <00aa01d4083c$129c7350$37d559f0$@chinamobile.com> <010e01d40874$fcb3d720$f61b8560$@chinamobile.com> <012001d40879$20bab900$62302b00$@chinamobile.com> <7b2e5862b8e84260984b2983d286c8e7@kontron.com> <22b0f0f372f14815bdf57cc0aedfd9eb@kontron.com> Message-ID: <004801d41333$396ea780$ac4bf680$@chinamobile.com> Agree, I think a joint discussion between the team is necessary, so that we can make sure to work on a common base 发件人: Csatari, Gergely (Nokia - HU/Budapest) [mailto:gergely.csatari at nokia.com] 发送时间: 2018年7月3日 19:01 收件人: Éric Sarault ; Fu Qiao ; '赵奇慧' ; 'lebre.adrien' 抄送: 'edge-computing' ; 'paul-andre raymond' 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Isn’t this case covered by [ 1] ? On the other hand there is a new set of deployment options listed by OPNFV in [ 2]. It would be nice if we could harmonize these somehow… [1]: https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG#Small_edge [2]: https://gerrit.opnfv.org/gerrit/#/c/58959/4/docs/development/requirements/requirements.rst Br, Gerg0 From: Éric Sarault [ mailto:Eric.Sarault at kontron.com] Sent: Tuesday, June 26, 2018 2:50 PM To: Csatari, Gergely (Nokia - HU/Budapest) < gergely.csatari at nokia.com>; Fu Qiao < fuqiao at chinamobile.com>; '赵奇慧' < zhaoqihui at chinamobile.com>; 'lebre.adrien' < lebre.adrien at free.fr> Cc: 'edge-computing' < edge-computing at lists.openstack.org>; 'paul-andre raymond' < paul-andre.raymond at b-yond.com> Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Yes, in some scenarios, we need to consider CPE units. This could be a consumer endpoint device/appliance that looks like your typical router from your ISV. These are typically ARM based units or you could also see some Intel Xeon-D units there (Atom worst case). The use case behind is to manage tens of thousands of these as an edge federation. At the same scale, think also Industrial IoT or Retail. My point is not everything is a rackmount format so we just need to be clear what the target is here as the form factor might limit the versatility of one or many use cases. --- Eric Sarault, B. Eng. Software Product Manager Kontron – An S&T Company 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada P: +1 (450) 437-5682 x eric.sarault at kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Canada Inc. By opening this email you are agreeing to Kontron's Electronic Communications Policy. From: Csatari, Gergely (Nokia - HU/Budapest) < gergely.csatari at nokia.com> Sent: June 26, 2018 7:09 AM To: Éric Sarault < Eric.Sarault at kontron.com>; Fu Qiao < fuqiao at chinamobile.com>; '赵奇慧' < zhaoqihui at chinamobile.com>; 'lebre.adrien' < lebre.adrien at free.fr> Cc: 'edge-computing' < edge-computing at lists.openstack.org>; 'paul-andre raymond' < paul-andre.raymond at b-yond.com> Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, So you mean that the minimum HW spec is smaller thean 1 unit? Br, Gerg0 From: Éric Sarault [ mailto:Eric.Sarault at kontron.com] Sent: Wednesday, June 20, 2018 3:14 PM To: Csatari, Gergely (Nokia - HU/Budapest) < gergely.csatari at nokia.com>; Fu Qiao < fuqiao at chinamobile.com>; '赵奇慧' < zhaoqihui at chinamobile.com>; 'lebre.adrien' < lebre.adrien at free.fr> Cc: 'edge-computing' < edge-computing at lists.openstack.org>; 'paul-andre raymond' < paul-andre.raymond at b-yond.com> Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Is the purpose of limiting the small edge to 1U is to classify it as the CPE use case? We need to keep in mind some CPE/vCPE equipment isn’t even “rackmountable” so we need to keep track of this (i.e: set up box, ISV router). --- Eric Sarault, B. Eng. Software Product Manager Kontron – An S&T Company 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada P: +1 (450) 437-5682 x eric.sarault at kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Canada Inc. By opening this email you are agreeing to Kontron's Electronic Communications Policy. From: Csatari, Gergely (Nokia - HU/Budapest) < gergely.csatari at nokia.com> Sent: June 20, 2018 5:36 AM To: Fu Qiao < fuqiao at chinamobile.com>; '赵奇慧' < zhaoqihui at chinamobile.com>; 'lebre.adrien' < lebre.adrien at free.fr> Cc: 'edge-computing' < edge-computing at lists.openstack.org>; 'paul-andre raymond' < paul-andre.raymond at b-yond.com> Subject: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, I am okay with your classification for small, medium and large. Br, Gerg0 From: Fu Qiao [ mailto:fuqiao at chinamobile.com] Sent: Wednesday, June 20, 2018 11:29 AM To: Csatari, Gergely (Nokia - HU/Budapest) < gergely.csatari at nokia.com>; '赵奇慧' < zhaoqihui at chinamobile.com>; 'lebre.adrien' < lebre.adrien at free.fr> Cc: 'edge-computing' < edge-computing at lists.openstack.org>; 'paul-andre raymond' < paul-andre.raymond at b-yond.com> Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Georgly. I read through the wiki definition for small and medium, and I guess it probably is not that direct to just define a large edge scenario. I notice that in the medium edge, the size is 2U-20U, which actually include the large edge as defined in the following email. I am afraid we probably will need detailed discussion about the size limitation for each different type, so as to make this whole definition easy to be accept. A possible proposal could be 1U for small, 2U-20U for medium, and 20-100U(or even larger) for large. So the small one can fit for CPE, medium one can fit for access and counties, and large one can fit for counties and cities 发件人: Csatari, Gergely (Nokia - HU/Budapest) [ mailto:gergely.csatari at nokia.com] 发送时间: 2018年6月20日 17:18 收件人: Fu Qiao < fuqiao at chinamobile.com>; '赵奇慧' < zhaoqihui at chinamobile.com>; 'lebre.adrien' < lebre.adrien at free.fr> 抄送: 'edge-computing' < edge-computing at lists.openstack.org>; 'paul-andre raymond' < paul-andre.raymond at b-yond.com> 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Thanks for the info. I’m okay to add a large edge deployment scenario. What charasterestics should it have? * Minimum hardware specs: 10 units * Maximum hardware specs: 20 units * Physical access of maintainer: * Physical security: * Expected frequency of updates to hardware: * Expected frequency of updates to firmware: * Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): * Remote access/connectivity reliability (24/24, periodic, ...): * Physical size: * Number of instances (Edge TIC Country / Edge TIC AP according to [6]): * Distance from Base Station (Access-level DC according to [6]): * E2E delay (from UE to site) (Access according to [6]): * Bandwith need (Access according to [6]): Br, Gerg0 From: Fu Qiao [ mailto:fuqiao at chinamobile.com] Sent: Wednesday, June 20, 2018 10:59 AM To: Csatari, Gergely (Nokia - HU/Budapest) < gergely.csatari at nokia.com>; '赵奇慧' < zhaoqihui at chinamobile.com>; 'lebre.adrien' < lebre.adrien at free.fr> Cc: 'edge-computing' < edge-computing at lists.openstack.org>; 'paul-andre raymond' < paul-andre.raymond at b-yond.com> Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Gergely. Actually what I am thinking is we probably need more definition for edge scenarios. I think the definition for small edge and medium edge in the white paper make sense to me, since they basically cover the usecase for customer premises usecases. However, I guess another scenario should also be added which includes 10-20 units. Such scenario is what we say for access and county level. Such unit is not that resource limited as small and medium edge, but we should also consider the resource constrains and make fully use of the limited resource. As for city level, I understand we can probably use the large edge definition for this, since it could be a quite typical cloud at that level. Hope this will help. 发件人: Csatari, Gergely (Nokia - HU/Budapest) [ mailto:gergely.csatari at nokia.com] 发送时间: 2018年6月20日 16:49 收件人: Fu Qiao < fuqiao at chinamobile.com>; '赵奇慧' < zhaoqihui at chinamobile.com>; 'lebre.adrien' < lebre.adrien at free.fr> 抄送: 'edge-computing' < edge-computing at lists.openstack.org>; 'paul-andre raymond' < paul-andre.raymond at b-yond.com> 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Thanks for the comments. I’m not sure at all, that we follow the definitions from the whitepaper in the wiki 😊 I referred your talk and the naming you user there becouse of the differences in the definitions. Going inline. From: Fu Qiao [ mailto:fuqiao at chinamobile.com] Sent: Wednesday, June 20, 2018 4:12 AM Hi, all. I guess some more explanations for the China Mobile’s network should be added here. The definition for small and medium edge from the whitepaper actually is different from what we say about access/county/city. Our access level CO will include compute nodes of about ten more, with distance from the Base station of 10km, delay about 2ms, and bandwidth about 50GB. [G0]: Should I add 10 units to the maximum hardware specs part of the Small edge deployment option? Our county level CO includes tens of compute nodes, with distance of 50km, delay about 2.5ms, and bandwidth of about 100GB. City level CO will have hundreds of servers, with distance of more than 100km. I guess the small edge defined in the Whitepaper, with up to 1U, is somehow suitable for edge equipment at the customer site, and this is not actually discussed in my presentation. 发件人: 赵奇慧 [ mailto:zhaoqihui at chinamobile.com] 发送时间: 2018年6月20日 10:03 Hi Gergely, It's great that our data can help. But I think according the the previous definitions of small edge and medium edge, there should be a little modification here. For Small edge, the maximum hardware specs is up to 1 unit, which is similar to our Access-level DC/Edge TIC AP. For Mediun edge, the hardware spec varies from 2RU to 20RU, which is somehow like our County-level DC. So here is my suggestion: --------------------------------------------------------------------------- Small edge: · Number of instances (Edge TIC AP according to [6]): depend on demands [G0]: Can we say 3000+ here in a paranthesis? · Distance from Base Station (Access-level DC according to [6]): around 10km · E2E delay (from UE to site)(Access according to [6]): 2 ms · Bandwith need (Access according to [6]): 50 GB Medium edge: · Number of instances (Edge TIC County according to [6]): 3000+ · Distance from Base Station (Access-level DC according to [6]): around 50km · E2E delay (from UE to site) (Access according to [6]): less than 2.5 ms · Bandwith need (Access according to [6]): 100GB ---------------------------------------------------------------------------- [G0]: I’ve updated these to the wiki. Thanks, Gerg0 Best Regards, Qihui Zhao _____ China Mobile Research Institute Department of Network Technology 发件人: Csatari, Gergely (Nokia - HU/Budapest) 时间: 2018/06/15(星期五)22:14 收件人: lebre.adrien; 抄送人: paul-andre raymond; edge-computing; 主题: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, I was thinking about the generic deployment specific requirements, like bandwiths and delays. I've added some of them from the CM presentation to https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Small_edge and https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Medium_edge Br, Gerg0 -----Original Message----- From: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] Sent: Thursday, June 14, 2018 11:39 PM To: Csatari, Gergely (Nokia - HU/Budapest) > Cc: Arkady Kanevsky >; fuqiao at chinamobile.com ; paul-andre raymond >; edge-computing at lists.openstack.org Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements Hi all, Maybe we can try to prioritise the projects we want to investigate and then for each of them identify what are the missing elements/capabilities (one after the others) There are ongoing works on Keystone and Glance. Nova, Neutron could be the next ones because these 4 services would allow to deploy VM at the edge (and so containers inside VMs). Cinder will enable the use of remote attached volumes. Ironic can be useful later. etc.. My two cents, Ad_ri3n_ ----- Mail original ----- > De: "Gergely Csatari (Nokia - HU/Budapest)" > > > À: "Arkady Kanevsky" >, fuqiao at chinamobile.com , "paul-andre raymond" > >, "lebre adrien" > >, edge-computing at lists.openstack.org > Envoyé: Mercredi 13 Juin 2018 17:38:35 > Objet: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > Hi, > > Somehow I have a feeling that these latency requirements are related > to all projects, this is why they should be documented in the > Deployment options section. > > Br, > Gerg0 > > -----Original Message----- > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > Sent: Wednesday, June 13, 2018 4:24 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > >; fuqiao at chinamobile.com ; > paul-andre.raymond at b-yond.com ; lebre.adrien at free.fr ; > edge-computing at lists.openstack.org > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > Gerg0, > I think these 3 projects are implied from the wiki requirements. > But it will be good to state projects that may need work explicitly. > Thanks, > Arkady > > -----Original Message----- > From: Csatari, Gergely (Nokia - HU/Budapest) > [mailto:gergely.csatari at nokia.com] > Sent: Wednesday, June 13, 2018 4:23 AM > To: Kanevsky, Arkady; fuqiao at chinamobile.com ; > paul-andre.raymond at b-yond.com ; lebre.adrien at free.fr ; > edge-computing at lists.openstack.org > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > Hi, > > Should we add these to the Deployment Scenarions section of the Dublin > wiki [1]? > > [1]: > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG# > Deployment_Scenarios > > Br, > Gerg0 > > -----Original Message----- > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > Sent: Wednesday, June 6, 2018 4:49 PM > To: fuqiao at chinamobile.com ; paul-andre.raymond at b-yond.com ; > lebre.adrien at free.fr ; edge-computing at lists.openstack.org > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements > > It is more than just nova to keystone. > We also need to consider at least neutron, glance and cinder also. > > -----Original Message----- > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 6, 2018 8:21 AM > To: 'Paul-Andre Raymond'; lebre.adrien at free.fr ; > edge-computing at lists.openstack.org > Subject: [Edge-computing] 答复: 答复: Clarification of Requirements > > Yes, 5ms is one way. But this is an assumption based on the network > from China Mobile. The latency will be defer if you have different > distance, but the calculation method is the same apparently. > > -----邮件原件----- > 发件人: Paul-Andre Raymond [mailto:paul-andre.raymond at b-yond.com] > 发送时间: 2018年6月6日 21:19 > 收件人: Fu Qiao >; lebre.adrien at free.fr ; > edge-computing at lists.openstack.org > 主题: Re: [Edge-computing] 答复: Clarification of Requirements > > Should we separate two kinds of latency requirements: > - Federation Latency: i.e Central Keystone to Local Keystone > - API latency: i.e. Edge Nova to local Keystone > > Should we measure it one way or Round Trip? I assume the 5ms below is > one way. > > > Paul-André > -- > > > On 6/6/18, 5:13 AM, "Fu Qiao" > wrote: > > Thank you Adrien. I was just about the reply with more details. > > About latency, this as I understand is actually decided mostly by > the distance of the distributed cloud. So it actually decided by > where exactly the location Keystone would like to deploy, and > what is the distance expectation. Like what I explain in my > presentation, we plan to have keystone sitting in the city level > to control multi cloud in counties, and the latency will be > around 5ms. But again this is a certain situation for China > Mobile. And other operators may make the conlusion on a > different structure. Another thing we can do is work on > simulation and testing and see what kind of latency the current > keystone federation scheme can tolerant. This will help the > operators to work out there structure as well. > > About bandwidth, the impression for me is we could expect more > than 50GB of bandwidth for edge for 5G. And I think that is > enough for most of the app. > > Hope this will help. > > -----邮件原件----- > 发件人: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] > 发送时间: 2018年6月6日 15:25 > 收件人: edge-computing at lists.openstack.org > 主题: Re: [Edge-computing] Clarification of Requirements > > It is rather difficult to give numbers because there are several > use-cases. > However, a good starting point can be to give a look to the > presentation Qiao Fu gave during the Vancouver summit: > https://www.openstack.org/videos/vancouver-2018/edge-tic-future-edge-cloud-for-china-mobile > There is a lot of numbers regarding the infrastructure China > Mobile is envisioning. > > Hope this helps. > ad_ri3n_ > PS: I cannot attend the meeting yesterday unfortunately but I'm > wondering whether the disconnection aspects have been discussed > (i.e. the fact that one site can be completely isolated for a > certain period of time due to network disconnections). > > ----- Mail original ----- > > De: "Jess Lampe" > > > À: edge-computing at lists.openstack.org > > Envoyé: Mercredi 6 Juin 2018 07:00:31 > > Objet: [Edge-computing] Clarification of Requirements > > > > > > > > > > During the call today, members of the Glance and Keystone teams > > requested clarity on the following areas: > > > > > > > > * Latency - what are the specific latency requirements that > > need > > to be met? > > * Bandwidth towards the edge - similarly, what are the > > limitations of bandwidth at the edge that we can expect? > > * Security - what are the specific security considerations > > that > > need to be? > > > > > > Please feel free to A.) contribute additional areas that need > > clarifying B.) clarify any of the added. > > > > > > > > > > _______________________________________________ > > 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 > _______________________________________________ Edge-computing mailing list Edge-computing at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openstack.org Wed Jul 4 18:06:01 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Wed, 4 Jul 2018 20:06:01 +0200 Subject: [Edge-computing] Meeting reminder Message-ID: <097AC450-42C1-42E4-B2EE-0403FADFD015@openstack.org> Hi, It is a friendly reminder that we have our next meeting at 0700 UTC tomorrow (July 5). You can find the call details and meeting agenda here: https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings See you on the call tomorrow! Thanks and Best Regards, Ildikó (IRC: ildikov) From ildiko.vancsa at gmail.com Wed Jul 4 18:22:38 2018 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Wed, 4 Jul 2018 20:22:38 +0200 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion=5Fof=5FRequirements?= In-Reply-To: <004801d41333$396ea780$ac4bf680$@chinamobile.com> References: <201806201003064375530@chinamobile.com>> <00aa01d4083c$129c7350$37d559f0$@chinamobile.com> <010e01d40874$fcb3d720$f61b8560$@chinamobile.com> <012001d40879$20bab900$62302b00$@chinamobile.com> <7b2e5862b8e84260984b2983d286c8e7@kontron.com> <22b0f0f372f14815bdf57cc0aedfd9eb@kontron.com> <004801d41333$396ea780$ac4bf680$@chinamobile.com> Message-ID: Hi, As a connecting item we are also working on a template to be able to describe use cases on a standard, comparable way: * https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases * https://etherpad.openstack.org/p/feedback_on_template This might be a good starting point for a common vocabulary. It is also a question how much we can come up with buckets that fit the different use cases in terms of the size and characteristics of the edge sites. The next Edge Computing Group call is tomorrow (July 5) at 0700 UTC ( https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings ), we can start to discuss this there with those of you available. We also need to figure out whether we would like to utilize any of the already scheduled meetings in each group or rather organize a new one? Thanks and Best Regards, Ildikó > On 2018. Jul 4., at 3:06, Fu Qiao wrote: > > Agree, I think a joint discussion between the team is necessary, so that we can make sure to work on a common base > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年7月3日 19:01 > 收件人: Éric Sarault ; Fu Qiao ; '赵奇慧' ; 'lebre.adrien' > 抄送: 'edge-computing' ; 'paul-andre raymond' > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Isn’t this case covered by [1] ? > > On the other hand there is a new set of deployment options listed by OPNFV in [2]. > It would be nice if we could harmonize these somehow… > > > [1]: https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG#Small_edge > [2]: https://gerrit.opnfv.org/gerrit/#/c/58959/4/docs/development/requirements/requirements.rst > > Br, > Gerg0 > > > From: Éric Sarault [mailto:Eric.Sarault at kontron.com] > Sent: Tuesday, June 26, 2018 2:50 PM > To: Csatari, Gergely (Nokia - HU/Budapest) ; Fu Qiao ; '赵奇慧' ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre raymond' > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Yes, in some scenarios, we need to consider CPE units. This could be a consumer endpoint device/appliance that looks like your typical router from your ISV. These are typically ARM based units or you could also see some Intel Xeon-D units there (Atom worst case). The use case behind is to manage tens of thousands of these as an edge federation. At the same scale, think also Industrial IoT or Retail. My point is not everything is a rackmount format so we just need to be clear what the target is here as the form factor might limit the versatility of one or many use cases. > > --- > Eric Sarault, B. Eng. > Software Product Manager > Kontron – An S&T Company > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada > P: +1 (450) 437-5682 x > eric.sarault at kontron.com > > Website | Blog | Twitter | LinkedIn | YouTube | Facebook > > Kontron Canada Inc. > By opening this email you are agreeing to Kontron's Electronic Communications Policy. > > From: Csatari, Gergely (Nokia - HU/Budapest) > Sent: June 26, 2018 7:09 AM > To: Éric Sarault ; Fu Qiao ; '赵奇慧' ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre raymond' > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > So you mean that the minimum HW spec is smaller thean 1 unit? > > Br, > Gerg0 > > From: Éric Sarault [mailto:Eric.Sarault at kontron.com] > Sent: Wednesday, June 20, 2018 3:14 PM > To: Csatari, Gergely (Nokia - HU/Budapest) ; Fu Qiao ; '赵奇慧' ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre raymond' > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Is the purpose of limiting the small edge to 1U is to classify it as the CPE use case? We need to keep in mind some CPE/vCPE equipment isn’t even “rackmountable” so we need to keep track of this (i.e: set up box, ISV router). > > --- > Eric Sarault, B. Eng. > Software Product Manager > Kontron – An S&T Company > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada > P: +1 (450) 437-5682 x > eric.sarault at kontron.com > > Website | Blog | Twitter | LinkedIn | YouTube | Facebook > > Kontron Canada Inc. > By opening this email you are agreeing to Kontron's Electronic Communications Policy. > > From: Csatari, Gergely (Nokia - HU/Budapest) > Sent: June 20, 2018 5:36 AM > To: Fu Qiao ; '赵奇慧' ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre raymond' > Subject: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > I am okay with your classification for small, medium and large. > > Br, > Gerg0 > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 11:29 AM > To: Csatari, Gergely (Nokia - HU/Budapest) ; '赵奇慧' ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre raymond' > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, Georgly. I read through the wiki definition for small and medium, and I guess it probably is not that direct to just define a large edge scenario. > I notice that in the medium edge, the size is 2U-20U, which actually include the large edge as defined in the following email. I am afraid we probably will need detailed discussion about the size limitation for each different type, so as to make this whole definition easy to be accept. A possible proposal could be 1U for small, 2U-20U for medium, and 20-100U(or even larger) for large. So the small one can fit for CPE, medium one can fit for access and counties, and large one can fit for counties and cities > > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年6月20日 17:18 > 收件人: Fu Qiao ; '赵奇慧' ; 'lebre.adrien' > 抄送: 'edge-computing' ; 'paul-andre raymond' > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Thanks for the info. > > I’m okay to add a large edge deployment scenario. > > What charasterestics should it have? > • Minimum hardware specs: 10 units > • Maximum hardware specs: 20 units > • Physical access of maintainer: > • Physical security: > • Expected frequency of updates to hardware: > • Expected frequency of updates to firmware: > • Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): > • Remote access/connectivity reliability (24/24, periodic, ...): > • Physical size: > • Number of instances (Edge TIC Country / Edge TIC AP according to [6]): > • Distance from Base Station (Access-level DC according to [6]): > • E2E delay (from UE to site) (Access according to [6]): > • Bandwith need (Access according to [6]): > Br, > Gerg0 > > > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 10:59 AM > To: Csatari, Gergely (Nokia - HU/Budapest) ; '赵奇慧' ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre raymond' > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, Gergely. Actually what I am thinking is we probably need more definition for edge scenarios. > I think the definition for small edge and medium edge in the white paper make sense to me, since they basically cover the usecase for customer premises usecases. However, I guess another scenario should also be added which includes 10-20 units. Such scenario is what we say for access and county level. Such unit is not that resource limited as small and medium edge, but we should also consider the resource constrains and make fully use of the limited resource. > As for city level, I understand we can probably use the large edge definition for this, since it could be a quite typical cloud at that level. > Hope this will help. > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年6月20日 16:49 > 收件人: Fu Qiao ; '赵奇慧' ; 'lebre.adrien' > 抄送: 'edge-computing' ; 'paul-andre raymond' > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Thanks for the comments. > > I’m not sure at all, that we follow the definitions from the whitepaper in the wiki 😊 > > I referred your talk and the naming you user there becouse of the differences in the definitions. > > Going inline. > > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 4:12 AM > > Hi, all. I guess some more explanations for the China Mobile’s network should be added here. > The definition for small and medium edge from the whitepaper actually is different from what we say about access/county/city. Our access level CO will include compute nodes of about ten more, with distance from the Base station of 10km, delay about 2ms, and bandwidth about 50GB. > > [G0]: Should I add 10 units to the maximum hardware specs part of the Small edge deployment option? > > Our county level CO includes tens of compute nodes, with distance of 50km, delay about 2.5ms, and bandwidth of about 100GB. City level CO will have hundreds of servers, with distance of more than 100km. > I guess the small edge defined in the Whitepaper, with up to 1U, is somehow suitable for edge equipment at the customer site, and this is not actually discussed in my presentation. > > > 发件人: 赵奇慧 [mailto:zhaoqihui at chinamobile.com] > 发送时间: 2018年6月20日 10:03 > > Hi Gergely, > > It's great that our data can help. But I think according the the previous definitions of small edge and medium edge, there should be a little modification here. > > For Small edge, the maximum hardware specs is up to 1 unit, which is similar to our Access-level DC/Edge TIC AP. For Mediun edge, the hardware spec varies from 2RU to 20RU, which is somehow like our County-level DC. So here is my suggestion: > --------------------------------------------------------------------------- > Small edge: > · Number of instances (Edge TIC AP according to [6]): depend on demands > [G0]: Can we say 3000+ here in a paranthesis? > · Distance from Base Station (Access-level DC according to [6]): around 10km > · E2E delay (from UE to site)(Access according to [6]): 2 ms > · Bandwith need (Access according to [6]): 50 GB > > Medium edge: > · Number of instances (Edge TIC County according to [6]): 3000+ > · Distance from Base Station (Access-level DC according to [6]): around 50km > · E2E delay (from UE to site) (Access according to [6]): less than 2.5 ms > · Bandwith need (Access according to [6]): 100GB > ---------------------------------------------------------------------------- > > [G0]: I’ve updated these to the wiki. > > Thanks, > Gerg0 > > > Best Regards, > Qihui Zhao > China Mobile Research Institute > > Department of Network Technology > >> >> 发件人: Csatari, Gergely (Nokia - HU/Budapest) >> 时间: 2018/06/15(星期五)22:14 >> 收件人: lebre.adrien; >> 抄送人: paul-andre raymond;edge-computing; >> 主题: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements > Hi, > > I was thinking about the generic deployment specific requirements, like bandwiths and delays. > > I've added some of them from the CM presentation to https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Small_edge and https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Medium_edge > > Br, > Gerg0 > > -----Original Message----- > From: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] > Sent: Thursday, June 14, 2018 11:39 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > Cc: Arkady Kanevsky ; fuqiao at chinamobile.com; paul-andre raymond ; edge-computing at lists.openstack.org > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements > > Hi all, > > Maybe we can try to prioritise the projects we want to investigate and then for each of them identify what are the missing elements/capabilities (one after the others) > > There are ongoing works on Keystone and Glance. > Nova, Neutron could be the next ones because these 4 services would allow to deploy VM at the edge (and so containers inside VMs). > Cinder will enable the use of remote attached volumes. > Ironic can be useful later. > etc.. > > My two cents, > Ad_ri3n_ > > ----- Mail original ----- > > De: "Gergely Csatari (Nokia - HU/Budapest)" > > > > À: "Arkady Kanevsky" , fuqiao at chinamobile.com, "paul-andre raymond" > > , "lebre adrien" > > , edge-computing at lists.openstack.org > > Envoyé: Mercredi 13 Juin 2018 17:38:35 > > Objet: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Hi, > > > > Somehow I have a feeling that these latency requirements are related > > to all projects, this is why they should be documented in the > > Deployment options section. > > > > Br, > > Gerg0 > > > > -----Original Message----- > > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > > Sent: Wednesday, June 13, 2018 4:24 PM > > To: Csatari, Gergely (Nokia - HU/Budapest) > > ; fuqiao at chinamobile.com; > > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Gerg0, > > I think these 3 projects are implied from the wiki requirements. > > But it will be good to state projects that may need work explicitly. > > Thanks, > > Arkady > > > > -----Original Message----- > > From: Csatari, Gergely (Nokia - HU/Budapest) > > [mailto:gergely.csatari at nokia.com] > > Sent: Wednesday, June 13, 2018 4:23 AM > > To: Kanevsky, Arkady; fuqiao at chinamobile.com; > > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Hi, > > > > Should we add these to the Deployment Scenarions section of the Dublin > > wiki [1]? > > > > [1]: > > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG# > > Deployment_Scenarios > > > > Br, > > Gerg0 > > > > -----Original Message----- > > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > > Sent: Wednesday, June 6, 2018 4:49 PM > > To: fuqiao at chinamobile.com; paul-andre.raymond at b-yond.com; > > lebre.adrien at free.fr; edge-computing at lists.openstack.org > > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > It is more than just nova to keystone. > > We also need to consider at least neutron, glance and cinder also. > > > > -----Original Message----- > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > > Sent: Wednesday, June 6, 2018 8:21 AM > > To: 'Paul-Andre Raymond'; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Yes, 5ms is one way. But this is an assumption based on the network > > from China Mobile. The latency will be defer if you have different > > distance, but the calculation method is the same apparently. > > > > -----邮件原件----- > > 发件人: Paul-Andre Raymond [mailto:paul-andre.raymond at b-yond.com] > > 发送时间: 2018年6月6日 21:19 > > 收件人: Fu Qiao ; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > 主题: Re: [Edge-computing] 答复: Clarification of Requirements > > > > Should we separate two kinds of latency requirements: > > - Federation Latency: i.e Central Keystone to Local Keystone > > - API latency: i.e. Edge Nova to local Keystone > > > > Should we measure it one way or Round Trip? I assume the 5ms below is > > one way. > > > > > > Paul-André > > -- > > > > > > On 6/6/18, 5:13 AM, "Fu Qiao" wrote: > > > > Thank you Adrien. I was just about the reply with more details. > > > > About latency, this as I understand is actually decided mostly by > > the distance of the distributed cloud. So it actually decided by > > where exactly the location Keystone would like to deploy, and > > what is the distance expectation. Like what I explain in my > > presentation, we plan to have keystone sitting in the city level > > to control multi cloud in counties, and the latency will be > > around 5ms. But again this is a certain situation for China > > Mobile. And other operators may make the conlusion on a > > different structure. Another thing we can do is work on > > simulation and testing and see what kind of latency the current > > keystone federation scheme can tolerant. This will help the > > operators to work out there structure as well. > > > > About bandwidth, the impression for me is we could expect more > > than 50GB of bandwidth for edge for 5G. And I think that is > > enough for most of the app. > > > > Hope this will help. > > > > -----邮件原件----- > > 发件人: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] > > 发送时间: 2018年6月6日 15:25 > > 收件人: edge-computing at lists.openstack.org > > 主题: Re: [Edge-computing] Clarification of Requirements > > > > It is rather difficult to give numbers because there are several > > use-cases. > > However, a good starting point can be to give a look to the > > presentation Qiao Fu gave during the Vancouver summit: > > https://www.openstack.org/videos/vancouver-2018/edge-tic-future-edge-cloud-for-china-mobile > > There is a lot of numbers regarding the infrastructure China > > Mobile is envisioning. > > > > Hope this helps. > > ad_ri3n_ > > PS: I cannot attend the meeting yesterday unfortunately but I'm > > wondering whether the disconnection aspects have been discussed > > (i.e. the fact that one site can be completely isolated for a > > certain period of time due to network disconnections). > > > > ----- Mail original ----- > > > De: "Jess Lampe" > > > À: edge-computing at lists.openstack.org > > > Envoyé: Mercredi 6 Juin 2018 07:00:31 > > > Objet: [Edge-computing] Clarification of Requirements > > > > > > > > > > > > > > > During the call today, members of the Glance and Keystone teams > > > requested clarity on the following areas: > > > > > > > > > > > > * Latency - what are the specific latency requirements that > > > need > > > to be met? > > > * Bandwidth towards the edge - similarly, what are the > > > limitations of bandwidth at the edge that we can expect? > > > * Security - what are the specific security considerations > > > that > > > need to be? > > > > > > > > > Please feel free to A.) contribute additional areas that need > > > clarifying B.) clarify any of the added. > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > 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 From gergely.csatari at nokia.com Thu Jul 5 09:57:00 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Thu, 5 Jul 2018 09:57:00 +0000 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion=5Fof=5FRequirements?= In-Reply-To: References: <201806201003064375530@chinamobile.com>> <00aa01d4083c$129c7350$37d559f0$@chinamobile.com> <010e01d40874$fcb3d720$f61b8560$@chinamobile.com> <012001d40879$20bab900$62302b00$@chinamobile.com> <7b2e5862b8e84260984b2983d286c8e7@kontron.com> <22b0f0f372f14815bdf57cc0aedfd9eb@kontron.com> <004801d41333$396ea780$ac4bf680$@chinamobile.com> Message-ID: Hi, Back to the deployment scnearios 😊 Here is a comparision between what is proposed by Qihui Zhao in the OPNFV Edge Computing project [1] and what I've collected in the Dublin notes [2]. Small edge - Distance from base station: - OPNFV EC: less than 10km, closest site to end users/ base station - Dublin: around 10 km - E2E delay: - OPNFV EC: around 2ms - Dublin: 2 ms - Maximum bandwidth can provide - OPNFV EC: 50G - Dublin: 50 GB - Minimum server number - OPNFV EC: 1 - Dublin: 1 unit of 4 cores (two ARM or Xeon-D processors), 8 GB RAM (4 DIMM), 1 * 240 GB SSD (2 * 2.5) - Maximum server number - OPNFV EC: 20 - Dublin: 1 unit of 16 cores, 64 GB RAM, 1 * 1 TB storage - Power for a site: - OPNFV EC: < 10KW - Dublin: N/A - Services might be deployed here: - OPNFV EC: MEC, or other services which have strict requirements on latency. Services deployed in this kind of sites have huge regional deference - Dublin: N/A - Physical access of maintainer: - OPNFV EC: Rare, maintenance staff may only show up in this kind of site when machines initialize for the first time or a machine down - Dublin: Rare - Remote network connection reliability: - OPNFV EC: Not 100% reliable or stable - Dublin: No 100% uptime and variable connectivity expected. - Orchestration: - OPNFV EC: no orchestration component. MANO deployed in core site provide remote orchestration - Dublin: N/A - Degree of virtualization: - OPNFV EC: t is possible that no virtualization technology would be used in small edge site if virtualization increases structure/network complexity, reduce service performance, or cost more resources. Bare-metal is common in small edge sites. Container would also be a future choice if virtualization was needed - Dublin: N/A - Storage: - OPNFV EC: mainly consider local storage. Distributed storage would be used depending on services’ needs and site conditions. - Dublin: N/A - Physical security: - OPNFV EC: N/A - Dublin: none - Expected frequency of updates to hardware: - OPNFV EC: N/A - Dublin: 3-4 year refresh cycle - Expected frequency of updates to firmware: - OPNFV EC: N/A - Dublin: 6-12 months - Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): - OPNFV EC: N/A - Dublin: ~ 12 - 24 months, has to be possible from remote management - Physical size: - OPNFV EC: N/A - Dublin: Not all the sites will have 36 depth capability. Some sites might be limited to 12 depth. - Number of instances (Edge TIC Country / Edge TIC AP according to [6]): - OPNFV EC: N/A - Dublin: depends on demands (3000+) Medium Edge - Distance from base station: - OPNFV EC: 10x km (1 Cc: Csatari, Gergely (Nokia - HU/Budapest) ; Éric Sarault ; 赵奇慧 ; lebre.adrien ; edge-computing ; paul-andre raymond Subject: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, As a connecting item we are also working on a template to be able to describe use cases on a standard, comparable way: * https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases * https://etherpad.openstack.org/p/feedback_on_template This might be a good starting point for a common vocabulary. It is also a question how much we can come up with buckets that fit the different use cases in terms of the size and characteristics of the edge sites. The next Edge Computing Group call is tomorrow (July 5) at 0700 UTC ( https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings ), we can start to discuss this there with those of you available. We also need to figure out whether we would like to utilize any of the already scheduled meetings in each group or rather organize a new one? Thanks and Best Regards, Ildikó > On 2018. Jul 4., at 3:06, Fu Qiao wrote: > > Agree, I think a joint discussion between the team is necessary, so > that we can make sure to work on a common base > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年7月3日 19:01 > 收件人: Éric Sarault ; Fu Qiao > ; '赵奇慧' ; > 'lebre.adrien' > 抄送: 'edge-computing' ; 'paul-andre > raymond' > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Isn’t this case covered by [1] ? > > On the other hand there is a new set of deployment options listed by OPNFV in [2]. > It would be nice if we could harmonize these somehow… > > > [1]: > https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussion > s_Dublin_PTG#Small_edge > [2]: > https://gerrit.opnfv.org/gerrit/#/c/58959/4/docs/development/requireme > nts/requirements.rst > > Br, > Gerg0 > > > From: Éric Sarault [mailto:Eric.Sarault at kontron.com] > Sent: Tuesday, June 26, 2018 2:50 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > ; Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Yes, in some scenarios, we need to consider CPE units. This could be a consumer endpoint device/appliance that looks like your typical router from your ISV. These are typically ARM based units or you could also see some Intel Xeon-D units there (Atom worst case). The use case behind is to manage tens of thousands of these as an edge federation. At the same scale, think also Industrial IoT or Retail. My point is not everything is a rackmount format so we just need to be clear what the target is here as the form factor might limit the versatility of one or many use cases. > > --- > Eric Sarault, B. Eng. > Software Product Manager > Kontron – An S&T Company > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada > P: +1 (450) 437-5682 x > eric.sarault at kontron.com > > Website | Blog | Twitter | LinkedIn | YouTube | Facebook > > Kontron Canada Inc. > By opening this email you are agreeing to Kontron's Electronic Communications Policy. > > From: Csatari, Gergely (Nokia - HU/Budapest) > > Sent: June 26, 2018 7:09 AM > To: Éric Sarault ; Fu Qiao > ; '赵奇慧' ; > 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > So you mean that the minimum HW spec is smaller thean 1 unit? > > Br, > Gerg0 > > From: Éric Sarault [mailto:Eric.Sarault at kontron.com] > Sent: Wednesday, June 20, 2018 3:14 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > ; Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Is the purpose of limiting the small edge to 1U is to classify it as the CPE use case? We need to keep in mind some CPE/vCPE equipment isn’t even “rackmountable” so we need to keep track of this (i.e: set up box, ISV router). > > --- > Eric Sarault, B. Eng. > Software Product Manager > Kontron – An S&T Company > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada > P: +1 (450) 437-5682 x > eric.sarault at kontron.com > > Website | Blog | Twitter | LinkedIn | YouTube | Facebook > > Kontron Canada Inc. > By opening this email you are agreeing to Kontron's Electronic Communications Policy. > > From: Csatari, Gergely (Nokia - HU/Budapest) > > Sent: June 20, 2018 5:36 AM > To: Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > I am okay with your classification for small, medium and large. > > Br, > Gerg0 > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 11:29 AM > To: Csatari, Gergely (Nokia - HU/Budapest) > ; '赵奇慧' ; > 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, Georgly. I read through the wiki definition for small and medium, and I guess it probably is not that direct to just define a large edge scenario. > I notice that in the medium edge, the size is 2U-20U, which actually > include the large edge as defined in the following email. I am afraid > we probably will need detailed discussion about the size limitation > for each different type, so as to make this whole definition easy to > be accept. A possible proposal could be 1U for small, 2U-20U for > medium, and 20-100U(or even larger) for large. So the small one can > fit for CPE, medium one can fit for access and counties, and large one > can fit for counties and cities > > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年6月20日 17:18 > 收件人: Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > 抄送: 'edge-computing' ; 'paul-andre > raymond' > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Thanks for the info. > > I’m okay to add a large edge deployment scenario. > > What charasterestics should it have? > • Minimum hardware specs: 10 units > • Maximum hardware specs: 20 units > • Physical access of maintainer: > • Physical security: > • Expected frequency of updates to hardware: > • Expected frequency of updates to firmware: > • Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): > • Remote access/connectivity reliability (24/24, periodic, ...): > • Physical size: > • Number of instances (Edge TIC Country / Edge TIC AP according to [6]): > • Distance from Base Station (Access-level DC according to [6]): > • E2E delay (from UE to site) (Access according to [6]): > • Bandwith need (Access according to [6]): > Br, > Gerg0 > > > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 10:59 AM > To: Csatari, Gergely (Nokia - HU/Budapest) > ; '赵奇慧' ; > 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, Gergely. Actually what I am thinking is we probably need more definition for edge scenarios. > I think the definition for small edge and medium edge in the white paper make sense to me, since they basically cover the usecase for customer premises usecases. However, I guess another scenario should also be added which includes 10-20 units. Such scenario is what we say for access and county level. Such unit is not that resource limited as small and medium edge, but we should also consider the resource constrains and make fully use of the limited resource. > As for city level, I understand we can probably use the large edge definition for this, since it could be a quite typical cloud at that level. > Hope this will help. > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年6月20日 16:49 > 收件人: Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > 抄送: 'edge-computing' ; 'paul-andre > raymond' > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Thanks for the comments. > > I’m not sure at all, that we follow the definitions from the > whitepaper in the wiki 😊 > > I referred your talk and the naming you user there becouse of the differences in the definitions. > > Going inline. > > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 4:12 AM > > Hi, all. I guess some more explanations for the China Mobile’s network should be added here. > The definition for small and medium edge from the whitepaper actually is different from what we say about access/county/city. Our access level CO will include compute nodes of about ten more, with distance from the Base station of 10km, delay about 2ms, and bandwidth about 50GB. > > [G0]: Should I add 10 units to the maximum hardware specs part of the Small edge deployment option? > > Our county level CO includes tens of compute nodes, with distance of 50km, delay about 2.5ms, and bandwidth of about 100GB. City level CO will have hundreds of servers, with distance of more than 100km. > I guess the small edge defined in the Whitepaper, with up to 1U, is somehow suitable for edge equipment at the customer site, and this is not actually discussed in my presentation. > > > 发件人: 赵奇慧 [mailto:zhaoqihui at chinamobile.com] > 发送时间: 2018年6月20日 10:03 > > Hi Gergely, > > It's great that our data can help. But I think according the the previous definitions of small edge and medium edge, there should be a little modification here. > > For Small edge, the maximum hardware specs is up to 1 unit, which is similar to our Access-level DC/Edge TIC AP. For Mediun edge, the hardware spec varies from 2RU to 20RU, which is somehow like our County-level DC. So here is my suggestion: > ---------------------------------------------------------------------- > ----- > Small edge: > · Number of instances (Edge TIC AP according to [6]): depend on demands > [G0]: Can we say 3000+ here in a paranthesis? > · Distance from Base Station (Access-level DC according to [6]): around 10km > · E2E delay (from UE to site)(Access according to [6]): 2 ms > · Bandwith need (Access according to [6]): 50 GB > > Medium edge: > · Number of instances (Edge TIC County according to [6]): 3000+ > · Distance from Base Station (Access-level DC according to [6]): around 50km > · E2E delay (from UE to site) (Access according to [6]): less than 2.5 ms > · Bandwith need (Access according to [6]): 100GB > ---------------------------------------------------------------------- > ------ > > [G0]: I’ve updated these to the wiki. > > Thanks, > Gerg0 > > > Best Regards, > Qihui Zhao > China Mobile Research Institute > > Department of Network Technology > >> >> 发件人: Csatari, Gergely (Nokia - HU/Budapest) >> 时间: 2018/06/15(星期五)22:14 >> 收件人: lebre.adrien; >> 抄送人: paul-andre raymond;edge-computing; >> 主题: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements > Hi, > > I was thinking about the generic deployment specific requirements, like bandwiths and delays. > > I've added some of them from the CM presentation to > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG# > Small_edge and > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG# > Medium_edge > > Br, > Gerg0 > > -----Original Message----- > From: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] > Sent: Thursday, June 14, 2018 11:39 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > Cc: Arkady Kanevsky ; > fuqiao at chinamobile.com; paul-andre raymond > ; edge-computing at lists.openstack.org > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements > > Hi all, > > Maybe we can try to prioritise the projects we want to investigate and > then for each of them identify what are the missing > elements/capabilities (one after the others) > > There are ongoing works on Keystone and Glance. > Nova, Neutron could be the next ones because these 4 services would allow to deploy VM at the edge (and so containers inside VMs). > Cinder will enable the use of remote attached volumes. > Ironic can be useful later. > etc.. > > My two cents, > Ad_ri3n_ > > ----- Mail original ----- > > De: "Gergely Csatari (Nokia - HU/Budapest)" > > > > À: "Arkady Kanevsky" , fuqiao at chinamobile.com, "paul-andre raymond" > > , "lebre adrien" > > , edge-computing at lists.openstack.org > > Envoyé: Mercredi 13 Juin 2018 17:38:35 > > Objet: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Hi, > > > > Somehow I have a feeling that these latency requirements are related > > to all projects, this is why they should be documented in the > > Deployment options section. > > > > Br, > > Gerg0 > > > > -----Original Message----- > > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > > Sent: Wednesday, June 13, 2018 4:24 PM > > To: Csatari, Gergely (Nokia - HU/Budapest) > > ; fuqiao at chinamobile.com; > > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Gerg0, > > I think these 3 projects are implied from the wiki requirements. > > But it will be good to state projects that may need work explicitly. > > Thanks, > > Arkady > > > > -----Original Message----- > > From: Csatari, Gergely (Nokia - HU/Budapest) > > [mailto:gergely.csatari at nokia.com] > > Sent: Wednesday, June 13, 2018 4:23 AM > > To: Kanevsky, Arkady; fuqiao at chinamobile.com; > > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Hi, > > > > Should we add these to the Deployment Scenarions section of the > > Dublin wiki [1]? > > > > [1]: > > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PT > > G# > > Deployment_Scenarios > > > > Br, > > Gerg0 > > > > -----Original Message----- > > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > > Sent: Wednesday, June 6, 2018 4:49 PM > > To: fuqiao at chinamobile.com; paul-andre.raymond at b-yond.com; > > lebre.adrien at free.fr; edge-computing at lists.openstack.org > > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > It is more than just nova to keystone. > > We also need to consider at least neutron, glance and cinder also. > > > > -----Original Message----- > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > > Sent: Wednesday, June 6, 2018 8:21 AM > > To: 'Paul-Andre Raymond'; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Yes, 5ms is one way. But this is an assumption based on the network > > from China Mobile. The latency will be defer if you have different > > distance, but the calculation method is the same apparently. > > > > -----邮件原件----- > > 发件人: Paul-Andre Raymond [mailto:paul-andre.raymond at b-yond.com] > > 发送时间: 2018年6月6日 21:19 > > 收件人: Fu Qiao ; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > 主题: Re: [Edge-computing] 答复: Clarification of Requirements > > > > Should we separate two kinds of latency requirements: > > - Federation Latency: i.e Central Keystone to Local Keystone > > - API latency: i.e. Edge Nova to local Keystone > > > > Should we measure it one way or Round Trip? I assume the 5ms below > > is one way. > > > > > > Paul-André > > -- > > > > > > On 6/6/18, 5:13 AM, "Fu Qiao" wrote: > > > > Thank you Adrien. I was just about the reply with more details. > > > > About latency, this as I understand is actually decided mostly by > > the distance of the distributed cloud. So it actually decided by > > where exactly the location Keystone would like to deploy, and what > > is the distance expectation. Like what I explain in my presentation, > > we plan to have keystone sitting in the city level to control multi > > cloud in counties, and the latency will be around 5ms. But again > > this is a certain situation for China Mobile. And other operators > > may make the conlusion on a different structure. Another thing we > > can do is work on simulation and testing and see what kind of > > latency the current keystone federation scheme can tolerant. This > > will help the operators to work out there structure as well. > > > > About bandwidth, the impression for me is we could expect more than > > 50GB of bandwidth for edge for 5G. And I think that is enough for > > most of the app. > > > > Hope this will help. > > > > -----邮件原件----- > > 发件人: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] > > 发送时间: 2018年6月6日 15:25 > > 收件人: edge-computing at lists.openstack.org > > 主题: Re: [Edge-computing] Clarification of Requirements > > > > It is rather difficult to give numbers because there are several > > use-cases. > > However, a good starting point can be to give a look to the > > presentation Qiao Fu gave during the Vancouver summit: > > https://www.openstack.org/videos/vancouver-2018/edge-tic-future-edge > > -cloud-for-china-mobile There is a lot of numbers regarding the > > infrastructure China Mobile is envisioning. > > > > Hope this helps. > > ad_ri3n_ > > PS: I cannot attend the meeting yesterday unfortunately but I'm > > wondering whether the disconnection aspects have been discussed > > (i.e. the fact that one site can be completely isolated for a > > certain period of time due to network disconnections). > > > > ----- Mail original ----- > > > De: "Jess Lampe" > > > À: edge-computing at lists.openstack.org > > > Envoyé: Mercredi 6 Juin 2018 07:00:31 > > > Objet: [Edge-computing] Clarification of Requirements > > > > > > > > > > > > > > > During the call today, members of the Glance and Keystone teams > > > requested clarity on the following areas: > > > > > > > > > > > > * Latency - what are the specific latency requirements that need > > > to be met? > > > * Bandwidth towards the edge - similarly, what are the limitations > > > of bandwidth at the edge that we can expect? > > > * Security - what are the specific security considerations that > > > need to be? > > > > > > > > > Please feel free to A.) contribute additional areas that need > > > clarifying B.) clarify any of the added. > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > 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 From gergely.csatari at nokia.com Thu Jul 5 15:04:22 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Thu, 5 Jul 2018 15:04:22 +0000 Subject: [Edge-computing] Review of Dublin edge notes Message-ID: Hi, Here are the notes from todays meeting: http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/review_of_dublin_edge_notes.2018-07-05-14.01.html As we had lots of freestyle discussions maybe it worth to check also the IRC log: http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/review_of_dublin_edge_notes.2018-07-05-14.01.log.html Br, Gerg0 -----Original Appointment----- From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Thursday, June 28, 2018 4:40 PM To: Csatari, Gergely (Nokia - HU/Budapest); 'edge-computing'; Srikumar Venugopal; Waines, Greg; beth.cohen at verizon.com; Mathieu LAGRANGE; Bernier, Daniel; Martin Bäckström; Randy.Perryman at dell.com; Éric Sarault; Francis Dagenais; Arkady.Kanevsky at dell.com; Silverman, Ben; D'ANDREA, JOE (JOE); Brendon Mifsud (mifsudb); Shuquan Huang Cc: Beierl, Mark; saiyagar at redhat.com; Jan Walzer; jonathan at openstack.org; Teresa Peluso; Peter Kapatsos Subject: Review of Dublin edge notes When: csütörtök 2018. július 5 16:00-17:00 (UTC+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague. Where: #edge-computing-group on freenode Hi, Let's continue the IRC meeting to discuss the comments to the Dublin edge notes from 5.3.2.8 VM images source side: https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG. Notes of the previous meetings: * http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/ * http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/review_of_dublin_edge_notes.2018-04-20-12.58.html * http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes_ii/2018/review_of_dublin_edge_notes_ii.2018-04-25-14.01.html * http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes_03/2018/review_of_dublin_edge_notes_03.2018-05-11-13.00.html Please note, that the correction of the comments is not finished yet, tracking of comment correction is here: https://etherpad.openstack.org/p/Dublin-edge-notes-wiki Br, Gerg0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Thu Jul 5 15:07:41 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Thu, 5 Jul 2018 15:07:41 +0000 Subject: [Edge-computing] Review of Dublin edge notes Message-ID: Hi, Let's continue the IRC meeting to discuss the comments to the Dublin edge notes from 5.3.2.10 Flavors source side: https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG. Notes of the previous meetings: * http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/ * http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/review_of_dublin_edge_notes.2018-04-20-12.58.html * http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes_ii/2018/review_of_dublin_edge_notes_ii.2018-04-25-14.01.html * http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes_03/2018/review_of_dublin_edge_notes_03.2018-05-11-13.00.html Please note, that the correction of the comments is not finished yet, tracking of comment correction is here: https://etherpad.openstack.org/p/Dublin-edge-notes-wiki Br, Gerg0 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 5162 bytes Desc: not available URL: From fuqiao at chinamobile.com Mon Jul 9 01:11:28 2018 From: fuqiao at chinamobile.com (fuqiao at chinamobile.com) Date: Mon, 9 Jul 2018 09:11:28 +0800 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion=5Fof=5FRequirements?= References: <201806201003064375530@chinamobile.com>>, <00aa01d4083c$129c7350$37d559f0$@chinamobile.com>, , <010e01d40874$fcb3d720$f61b8560$@chinamobile.com>, , <012001d40879$20bab900$62302b00$@chinamobile.com>, , <7b2e5862b8e84260984b2983d286c8e7@kontron.com>, , <22b0f0f372f14815bdf57cc0aedfd9eb@kontron.com>, , <004801d41333$396ea780$ac4bf680$@chinamobile.com>, , Message-ID: <201807090911276700446@chinamobile.com> Hi, Gergely. I am totally agree that we should merge these into one set of discription. This will be much easier for us to understand the scenario and also conduct the upcomming code and test case development. what is the next step you suggest? I guess we could have a joint meeting to discuss each and every detail, or we could also put it into the OPNFV EC repo so that people can make comments on gerrit? fuqiao at chinamobile.com 发件人： Csatari, Gergely (Nokia - HU/Budapest) 发送时间： 2018-07-05 17:57 收件人： Ildiko Vancsa; Fu Qiao 抄送： Éric Sarault; 赵奇慧; lebre.adrien; edge-computing; paul-andre raymond 主题： RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Back to the deployment scnearios  Here is a comparision between what is proposed by Qihui Zhao in the OPNFV Edge Computing project [1] and what I've collected in the Dublin notes [2]. Small edge - Distance from base station: - OPNFV EC: less than 10km, closest site to end users/ base station - Dublin: around 10 km - E2E delay: - OPNFV EC: around 2ms - Dublin: 2 ms - Maximum bandwidth can provide - OPNFV EC: 50G - Dublin: 50 GB - Minimum server number - OPNFV EC: 1 - Dublin: 1 unit of 4 cores (two ARM or Xeon-D processors), 8 GB RAM (4 DIMM), 1 * 240 GB SSD (2 * 2.5) - Maximum server number - OPNFV EC: 20 - Dublin: 1 unit of 16 cores, 64 GB RAM, 1 * 1 TB storage - Power for a site: - OPNFV EC: < 10KW - Dublin: N/A - Services might be deployed here: - OPNFV EC: MEC, or other services which have strict requirements on latency. Services deployed in this kind of sites have huge regional deference - Dublin: N/A - Physical access of maintainer: - OPNFV EC: Rare, maintenance staff may only show up in this kind of site when machines initialize for the first time or a machine down - Dublin: Rare - Remote network connection reliability: - OPNFV EC: Not 100% reliable or stable - Dublin: No 100% uptime and variable connectivity expected. - Orchestration: - OPNFV EC: no orchestration component. MANO deployed in core site provide remote orchestration - Dublin: N/A - Degree of virtualization: - OPNFV EC: t is possible that no virtualization technology would be used in small edge site if virtualization increases structure/network complexity, reduce service performance, or cost more resources. Bare-metal is common in small edge sites. Container would also be a future choice if virtualization was needed - Dublin: N/A - Storage: - OPNFV EC: mainly consider local storage. Distributed storage would be used depending on services’ needs and site conditions. - Dublin: N/A - Physical security: - OPNFV EC: N/A - Dublin: none - Expected frequency of updates to hardware: - OPNFV EC: N/A - Dublin: 3-4 year refresh cycle - Expected frequency of updates to firmware: - OPNFV EC: N/A - Dublin: 6-12 months - Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): - OPNFV EC: N/A - Dublin: ~ 12 - 24 months, has to be possible from remote management - Physical size: - OPNFV EC: N/A - Dublin: Not all the sites will have 36 depth capability. Some sites might be limited to 12 depth. - Number of instances (Edge TIC Country / Edge TIC AP according to [6]): - OPNFV EC: N/A - Dublin: depends on demands (3000+) Medium Edge - Distance from base station: - OPNFV EC: 10x km (1 Cc: Csatari, Gergely (Nokia - HU/Budapest) ; Éric Sarault ; 赵奇慧 ; lebre.adrien ; edge-computing ; paul-andre raymond Subject: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, As a connecting item we are also working on a template to be able to describe use cases on a standard, comparable way: * https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases * https://etherpad.openstack.org/p/feedback_on_template This might be a good starting point for a common vocabulary. It is also a question how much we can come up with buckets that fit the different use cases in terms of the size and characteristics of the edge sites. The next Edge Computing Group call is tomorrow (July 5) at 0700 UTC ( https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings ), we can start to discuss this there with those of you available. We also need to figure out whether we would like to utilize any of the already scheduled meetings in each group or rather organize a new one? Thanks and Best Regards, Ildikó > On 2018. Jul 4., at 3:06, Fu Qiao wrote: > > Agree, I think a joint discussion between the team is necessary, so > that we can make sure to work on a common base > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年7月3日 19:01 > 收件人: Éric Sarault ; Fu Qiao > ; '赵奇慧' ; > 'lebre.adrien' > 抄送: 'edge-computing' ; 'paul-andre > raymond' > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Isn’t this case covered by [1] ? > > On the other hand there is a new set of deployment options listed by OPNFV in [2]. > It would be nice if we could harmonize these somehow… > > > [1]: > https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussion > s_Dublin_PTG#Small_edge > [2]: > https://gerrit.opnfv.org/gerrit/#/c/58959/4/docs/development/requireme > nts/requirements.rst > > Br, > Gerg0 > > > From: Éric Sarault [mailto:Eric.Sarault at kontron.com] > Sent: Tuesday, June 26, 2018 2:50 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > ; Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Yes, in some scenarios, we need to consider CPE units. This could be a consumer endpoint device/appliance that looks like your typical router from your ISV. These are typically ARM based units or you could also see some Intel Xeon-D units there (Atom worst case). The use case behind is to manage tens of thousands of these as an edge federation. At the same scale, think also Industrial IoT or Retail. My point is not everything is a rackmount format so we just need to be clear what the target is here as the form factor might limit the versatility of one or many use cases. > > --- > Eric Sarault, B. Eng. > Software Product Manager > Kontron – An S&T Company > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada > P: +1 (450) 437-5682 x > eric.sarault at kontron.com > > Website | Blog | Twitter | LinkedIn | YouTube | Facebook > > Kontron Canada Inc. > By opening this email you are agreeing to Kontron's Electronic Communications Policy. > > From: Csatari, Gergely (Nokia - HU/Budapest) > > Sent: June 26, 2018 7:09 AM > To: Éric Sarault ; Fu Qiao > ; '赵奇慧' ; > 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > So you mean that the minimum HW spec is smaller thean 1 unit? > > Br, > Gerg0 > > From: Éric Sarault [mailto:Eric.Sarault at kontron.com] > Sent: Wednesday, June 20, 2018 3:14 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > ; Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Is the purpose of limiting the small edge to 1U is to classify it as the CPE use case? We need to keep in mind some CPE/vCPE equipment isn’t even “rackmountable” so we need to keep track of this (i.e: set up box, ISV router). > > --- > Eric Sarault, B. Eng. > Software Product Manager > Kontron – An S&T Company > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada > P: +1 (450) 437-5682 x > eric.sarault at kontron.com > > Website | Blog | Twitter | LinkedIn | YouTube | Facebook > > Kontron Canada Inc. > By opening this email you are agreeing to Kontron's Electronic Communications Policy. > > From: Csatari, Gergely (Nokia - HU/Budapest) > > Sent: June 20, 2018 5:36 AM > To: Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > I am okay with your classification for small, medium and large. > > Br, > Gerg0 > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 11:29 AM > To: Csatari, Gergely (Nokia - HU/Budapest) > ; '赵奇慧' ; > 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, Georgly. I read through the wiki definition for small and medium, and I guess it probably is not that direct to just define a large edge scenario. > I notice that in the medium edge, the size is 2U-20U, which actually > include the large edge as defined in the following email. I am afraid > we probably will need detailed discussion about the size limitation > for each different type, so as to make this whole definition easy to > be accept. A possible proposal could be 1U for small, 2U-20U for > medium, and 20-100U(or even larger) for large. So the small one can > fit for CPE, medium one can fit for access and counties, and large one > can fit for counties and cities > > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年6月20日 17:18 > 收件人: Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > 抄送: 'edge-computing' ; 'paul-andre > raymond' > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Thanks for the info. > > I’m okay to add a large edge deployment scenario. > > What charasterestics should it have? > • Minimum hardware specs: 10 units > • Maximum hardware specs: 20 units > • Physical access of maintainer: > • Physical security: > • Expected frequency of updates to hardware: > • Expected frequency of updates to firmware: > • Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): > • Remote access/connectivity reliability (24/24, periodic, ...): > • Physical size: > • Number of instances (Edge TIC Country / Edge TIC AP according to [6]): > • Distance from Base Station (Access-level DC according to [6]): > • E2E delay (from UE to site) (Access according to [6]): > • Bandwith need (Access according to [6]): > Br, > Gerg0 > > > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 10:59 AM > To: Csatari, Gergely (Nokia - HU/Budapest) > ; '赵奇慧' ; > 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, Gergely. Actually what I am thinking is we probably need more definition for edge scenarios. > I think the definition for small edge and medium edge in the white paper make sense to me, since they basically cover the usecase for customer premises usecases. However, I guess another scenario should also be added which includes 10-20 units. Such scenario is what we say for access and county level. Such unit is not that resource limited as small and medium edge, but we should also consider the resource constrains and make fully use of the limited resource. > As for city level, I understand we can probably use the large edge definition for this, since it could be a quite typical cloud at that level. > Hope this will help. > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年6月20日 16:49 > 收件人: Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > 抄送: 'edge-computing' ; 'paul-andre > raymond' > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Thanks for the comments. > > I’m not sure at all, that we follow the definitions from the > whitepaper in the wiki  > > I referred your talk and the naming you user there becouse of the differences in the definitions. > > Going inline. > > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 4:12 AM > > Hi, all. I guess some more explanations for the China Mobile’s network should be added here. > The definition for small and medium edge from the whitepaper actually is different from what we say about access/county/city. Our access level CO will include compute nodes of about ten more, with distance from the Base station of 10km, delay about 2ms, and bandwidth about 50GB. > > [G0]: Should I add 10 units to the maximum hardware specs part of the Small edge deployment option? > > Our county level CO includes tens of compute nodes, with distance of 50km, delay about 2.5ms, and bandwidth of about 100GB. City level CO will have hundreds of servers, with distance of more than 100km. > I guess the small edge defined in the Whitepaper, with up to 1U, is somehow suitable for edge equipment at the customer site, and this is not actually discussed in my presentation. > > > 发件人: 赵奇慧 [mailto:zhaoqihui at chinamobile.com] > 发送时间: 2018年6月20日 10:03 > > Hi Gergely, > > It's great that our data can help. But I think according the the previous definitions of small edge and medium edge, there should be a little modification here. > > For Small edge, the maximum hardware specs is up to 1 unit, which is similar to our Access-level DC/Edge TIC AP. For Mediun edge, the hardware spec varies from 2RU to 20RU, which is somehow like our County-level DC. So here is my suggestion: > ---------------------------------------------------------------------- > ----- > Small edge: > · Number of instances (Edge TIC AP according to [6]): depend on demands > [G0]: Can we say 3000+ here in a paranthesis? > · Distance from Base Station (Access-level DC according to [6]): around 10km > · E2E delay (from UE to site)(Access according to [6]): 2 ms > · Bandwith need (Access according to [6]): 50 GB > > Medium edge: > · Number of instances (Edge TIC County according to [6]): 3000+ > · Distance from Base Station (Access-level DC according to [6]): around 50km > · E2E delay (from UE to site) (Access according to [6]): less than 2.5 ms > · Bandwith need (Access according to [6]): 100GB > ---------------------------------------------------------------------- > ------ > > [G0]: I’ve updated these to the wiki. > > Thanks, > Gerg0 > > > Best Regards, > Qihui Zhao > China Mobile Research Institute > > Department of Network Technology > >> >> 发件人: Csatari, Gergely (Nokia - HU/Budapest) >> 时间: 2018/06/15(星期五)22:14 >> 收件人: lebre.adrien; >> 抄送人: paul-andre raymond;edge-computing; >> 主题: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements > Hi, > > I was thinking about the generic deployment specific requirements, like bandwiths and delays. > > I've added some of them from the CM presentation to > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG# > Small_edge and > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG# > Medium_edge > > Br, > Gerg0 > > -----Original Message----- > From: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] > Sent: Thursday, June 14, 2018 11:39 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > Cc: Arkady Kanevsky ; > fuqiao at chinamobile.com; paul-andre raymond > ; edge-computing at lists.openstack.org > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements > > Hi all, > > Maybe we can try to prioritise the projects we want to investigate and > then for each of them identify what are the missing > elements/capabilities (one after the others) > > There are ongoing works on Keystone and Glance. > Nova, Neutron could be the next ones because these 4 services would allow to deploy VM at the edge (and so containers inside VMs). > Cinder will enable the use of remote attached volumes. > Ironic can be useful later. > etc.. > > My two cents, > Ad_ri3n_ > > ----- Mail original ----- > > De: "Gergely Csatari (Nokia - HU/Budapest)" > > > > À: "Arkady Kanevsky" , fuqiao at chinamobile.com, "paul-andre raymond" > > , "lebre adrien" > > , edge-computing at lists.openstack.org > > Envoyé: Mercredi 13 Juin 2018 17:38:35 > > Objet: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Hi, > > > > Somehow I have a feeling that these latency requirements are related > > to all projects, this is why they should be documented in the > > Deployment options section. > > > > Br, > > Gerg0 > > > > -----Original Message----- > > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > > Sent: Wednesday, June 13, 2018 4:24 PM > > To: Csatari, Gergely (Nokia - HU/Budapest) > > ; fuqiao at chinamobile.com; > > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Gerg0, > > I think these 3 projects are implied from the wiki requirements. > > But it will be good to state projects that may need work explicitly. > > Thanks, > > Arkady > > > > -----Original Message----- > > From: Csatari, Gergely (Nokia - HU/Budapest) > > [mailto:gergely.csatari at nokia.com] > > Sent: Wednesday, June 13, 2018 4:23 AM > > To: Kanevsky, Arkady; fuqiao at chinamobile.com; > > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Hi, > > > > Should we add these to the Deployment Scenarions section of the > > Dublin wiki [1]? > > > > [1]: > > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PT > > G# > > Deployment_Scenarios > > > > Br, > > Gerg0 > > > > -----Original Message----- > > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > > Sent: Wednesday, June 6, 2018 4:49 PM > > To: fuqiao at chinamobile.com; paul-andre.raymond at b-yond.com; > > lebre.adrien at free.fr; edge-computing at lists.openstack.org > > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > It is more than just nova to keystone. > > We also need to consider at least neutron, glance and cinder also. > > > > -----Original Message----- > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > > Sent: Wednesday, June 6, 2018 8:21 AM > > To: 'Paul-Andre Raymond'; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Yes, 5ms is one way. But this is an assumption based on the network > > from China Mobile. The latency will be defer if you have different > > distance, but the calculation method is the same apparently. > > > > -----邮件原件----- > > 发件人: Paul-Andre Raymond [mailto:paul-andre.raymond at b-yond.com] > > 发送时间: 2018年6月6日 21:19 > > 收件人: Fu Qiao ; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > 主题: Re: [Edge-computing] 答复: Clarification of Requirements > > > > Should we separate two kinds of latency requirements: > > - Federation Latency: i.e Central Keystone to Local Keystone > > - API latency: i.e. Edge Nova to local Keystone > > > > Should we measure it one way or Round Trip? I assume the 5ms below > > is one way. > > > > > > Paul-André > > -- > > > > > > On 6/6/18, 5:13 AM, "Fu Qiao" wrote: > > > > Thank you Adrien. I was just about the reply with more details. > > > > About latency, this as I understand is actually decided mostly by > > the distance of the distributed cloud. So it actually decided by > > where exactly the location Keystone would like to deploy, and what > > is the distance expectation. Like what I explain in my presentation, > > we plan to have keystone sitting in the city level to control multi > > cloud in counties, and the latency will be around 5ms. But again > > this is a certain situation for China Mobile. And other operators > > may make the conlusion on a different structure. Another thing we > > can do is work on simulation and testing and see what kind of > > latency the current keystone federation scheme can tolerant. This > > will help the operators to work out there structure as well. > > > > About bandwidth, the impression for me is we could expect more than > > 50GB of bandwidth for edge for 5G. And I think that is enough for > > most of the app. > > > > Hope this will help. > > > > -----邮件原件----- > > 发件人: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] > > 发送时间: 2018年6月6日 15:25 > > 收件人: edge-computing at lists.openstack.org > > 主题: Re: [Edge-computing] Clarification of Requirements > > > > It is rather difficult to give numbers because there are several > > use-cases. > > However, a good starting point can be to give a look to the > > presentation Qiao Fu gave during the Vancouver summit: > > https://www.openstack.org/videos/vancouver-2018/edge-tic-future-edge > > -cloud-for-china-mobile There is a lot of numbers regarding the > > infrastructure China Mobile is envisioning. > > > > Hope this helps. > > ad_ri3n_ > > PS: I cannot attend the meeting yesterday unfortunately but I'm > > wondering whether the disconnection aspects have been discussed > > (i.e. the fact that one site can be completely isolated for a > > certain period of time due to network disconnections). > > > > ----- Mail original ----- > > > De: "Jess Lampe" > > > À: edge-computing at lists.openstack.org > > > Envoyé: Mercredi 6 Juin 2018 07:00:31 > > > Objet: [Edge-computing] Clarification of Requirements > > > > > > > > > > > > > > > During the call today, members of the Glance and Keystone teams > > > requested clarity on the following areas: > > > > > > > > > > > > * Latency - what are the specific latency requirements that need > > > to be met? > > > * Bandwidth towards the edge - similarly, what are the limitations > > > of bandwidth at the edge that we can expect? > > > * Security - what are the specific security considerations that > > > need to be? > > > > > > > > > Please feel free to A.) contribute additional areas that need > > > clarifying B.) clarify any of the added. > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Mon Jul 9 09:09:06 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Mon, 9 Jul 2018 09:09:06 +0000 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion=5Fof=5FRequirements?= In-Reply-To: <201807090911276700446@chinamobile.com> References: <201806201003064375530@chinamobile.com>>, <00aa01d4083c$129c7350$37d559f0$@chinamobile.com>, , <010e01d40874$fcb3d720$f61b8560$@chinamobile.com>, , <012001d40879$20bab900$62302b00$@chinamobile.com>, , <7b2e5862b8e84260984b2983d286c8e7@kontron.com>, , <22b0f0f372f14815bdf57cc0aedfd9eb@kontron.com>, , <004801d41333$396ea780$ac4bf680$@chinamobile.com>, , <201807090911276700446@chinamobile.com> Message-ID: Hi, Let’s discuss on the Tuesdsay meeting. I’ve added this issue to the agenda. Br, Gerg0 From: fuqiao at chinamobile.com [mailto:fuqiao at chinamobile.com] Sent: Monday, July 9, 2018 3:11 AM To: Csatari, Gergely (Nokia - HU/Budapest) ; Ildiko Vancsa Cc: eric.sarault ; zhaoqihui ; lebre.adrien ; edge-computing ; paul-andre.raymond Subject: Re: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Gergely. I am totally agree that we should merge these into one set of discription. This will be much easier for us to understand the scenario and also conduct the upcomming code and test case development. what is the next step you suggest? I guess we could have a joint meeting to discuss each and every detail, or we could also put it into the OPNFV EC repo so that people can make comments on gerrit? ________________________________ fuqiao at chinamobile.com 发件人： Csatari, Gergely (Nokia - HU/Budapest) 发送时间： 2018-07-05 17:57 收件人： Ildiko Vancsa; Fu Qiao 抄送： Éric Sarault; 赵奇慧; lebre.adrien; edge-computing; paul-andre raymond 主题： RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Back to the deployment scnearios  Here is a comparision between what is proposed by Qihui Zhao in the OPNFV Edge Computing project [1] and what I've collected in the Dublin notes [2]. Small edge - Distance from base station: - OPNFV EC: less than 10km, closest site to end users/ base station - Dublin: around 10 km - E2E delay: - OPNFV EC: around 2ms - Dublin: 2 ms - Maximum bandwidth can provide - OPNFV EC: 50G - Dublin: 50 GB - Minimum server number - OPNFV EC: 1 - Dublin: 1 unit of 4 cores (two ARM or Xeon-D processors), 8 GB RAM (4 DIMM), 1 * 240 GB SSD (2 * 2.5) - Maximum server number - OPNFV EC: 20 - Dublin: 1 unit of 16 cores, 64 GB RAM, 1 * 1 TB storage - Power for a site: - OPNFV EC: < 10KW - Dublin: N/A - Services might be deployed here: - OPNFV EC: MEC, or other services which have strict requirements on latency. Services deployed in this kind of sites have huge regional deference - Dublin: N/A - Physical access of maintainer: - OPNFV EC: Rare, maintenance staff may only show up in this kind of site when machines initialize for the first time or a machine down - Dublin: Rare - Remote network connection reliability: - OPNFV EC: Not 100% reliable or stable - Dublin: No 100% uptime and variable connectivity expected. - Orchestration: - OPNFV EC: no orchestration component. MANO deployed in core site provide remote orchestration - Dublin: N/A - Degree of virtualization: - OPNFV EC: t is possible that no virtualization technology would be used in small edge site if virtualization increases structure/network complexity, reduce service performance, or cost more resources. Bare-metal is common in small edge sites. Container would also be a future choice if virtualization was needed - Dublin: N/A - Storage: - OPNFV EC: mainly consider local storage. Distributed storage would be used depending on services’ needs and site conditions. - Dublin: N/A - Physical security: - OPNFV EC: N/A - Dublin: none - Expected frequency of updates to hardware: - OPNFV EC: N/A - Dublin: 3-4 year refresh cycle - Expected frequency of updates to firmware: - OPNFV EC: N/A - Dublin: 6-12 months - Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): - OPNFV EC: N/A - Dublin: ~ 12 - 24 months, has to be possible from remote management - Physical size: - OPNFV EC: N/A - Dublin: Not all the sites will have 36 depth capability. Some sites might be limited to 12 depth. - Number of instances (Edge TIC Country / Edge TIC AP according to [6]): - OPNFV EC: N/A - Dublin: depends on demands (3000+) Medium Edge - Distance from base station: - OPNFV EC: 10x km (1> Cc: Csatari, Gergely (Nokia - HU/Budapest) >; Éric Sarault >; 赵奇慧 >; lebre.adrien >; edge-computing >; paul-andre raymond > Subject: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, As a connecting item we are also working on a template to be able to describe use cases on a standard, comparable way: * https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases * https://etherpad.openstack.org/p/feedback_on_template This might be a good starting point for a common vocabulary. It is also a question how much we can come up with buckets that fit the different use cases in terms of the size and characteristics of the edge sites. The next Edge Computing Group call is tomorrow (July 5) at 0700 UTC ( https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings ), we can start to discuss this there with those of you available. We also need to figure out whether we would like to utilize any of the already scheduled meetings in each group or rather organize a new one? Thanks and Best Regards, Ildikó > On 2018. Jul 4., at 3:06, Fu Qiao > wrote: > > Agree, I think a joint discussion between the team is necessary, so > that we can make sure to work on a common base > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年7月3日 19:01 > 收件人: Éric Sarault >; Fu Qiao > >; '赵奇慧' >; > 'lebre.adrien' > > 抄送: 'edge-computing' >; 'paul-andre > raymond' > > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Isn’t this case covered by [1] ? > > On the other hand there is a new set of deployment options listed by OPNFV in [2]. > It would be nice if we could harmonize these somehow… > > > [1]: > https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussion > s_Dublin_PTG#Small_edge > [2]: > https://gerrit.opnfv.org/gerrit/#/c/58959/4/docs/development/requireme > nts/requirements.rst > > Br, > Gerg0 > > > From: Éric Sarault [mailto:Eric.Sarault at kontron.com] > Sent: Tuesday, June 26, 2018 2:50 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > >; Fu Qiao >; '赵奇慧' > >; 'lebre.adrien' > > Cc: 'edge-computing' >; 'paul-andre > raymond' > > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Yes, in some scenarios, we need to consider CPE units. This could be a consumer endpoint device/appliance that looks like your typical router from your ISV. These are typically ARM based units or you could also see some Intel Xeon-D units there (Atom worst case). The use case behind is to manage tens of thousands of these as an edge federation. At the same scale, think also Industrial IoT or Retail. My point is not everything is a rackmount format so we just need to be clear what the target is here as the form factor might limit the versatility of one or many use cases. > > --- > Eric Sarault, B. Eng. > Software Product Manager > Kontron – An S&T Company > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada > P: +1 (450) 437-5682 x > eric.sarault at kontron.com > > Website | Blog | Twitter | LinkedIn | YouTube | Facebook > > Kontron Canada Inc. > By opening this email you are agreeing to Kontron's Electronic Communications Policy. > > From: Csatari, Gergely (Nokia - HU/Budapest) > > > Sent: June 26, 2018 7:09 AM > To: Éric Sarault >; Fu Qiao > >; '赵奇慧' >; > 'lebre.adrien' > > Cc: 'edge-computing' >; 'paul-andre > raymond' > > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > So you mean that the minimum HW spec is smaller thean 1 unit? > > Br, > Gerg0 > > From: Éric Sarault [mailto:Eric.Sarault at kontron.com] > Sent: Wednesday, June 20, 2018 3:14 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > >; Fu Qiao >; '赵奇慧' > >; 'lebre.adrien' > > Cc: 'edge-computing' >; 'paul-andre > raymond' > > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Is the purpose of limiting the small edge to 1U is to classify it as the CPE use case? We need to keep in mind some CPE/vCPE equipment isn’t even “rackmountable” so we need to keep track of this (i.e: set up box, ISV router). > > --- > Eric Sarault, B. Eng. > Software Product Manager > Kontron – An S&T Company > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada > P: +1 (450) 437-5682 x > eric.sarault at kontron.com > > Website | Blog | Twitter | LinkedIn | YouTube | Facebook > > Kontron Canada Inc. > By opening this email you are agreeing to Kontron's Electronic Communications Policy. > > From: Csatari, Gergely (Nokia - HU/Budapest) > > > Sent: June 20, 2018 5:36 AM > To: Fu Qiao >; '赵奇慧' > >; 'lebre.adrien' > > Cc: 'edge-computing' >; 'paul-andre > raymond' > > Subject: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > I am okay with your classification for small, medium and large. > > Br, > Gerg0 > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 11:29 AM > To: Csatari, Gergely (Nokia - HU/Budapest) > >; '赵奇慧' >; > 'lebre.adrien' > > Cc: 'edge-computing' >; 'paul-andre > raymond' > > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, Georgly. I read through the wiki definition for small and medium, and I guess it probably is not that direct to just define a large edge scenario. > I notice that in the medium edge, the size is 2U-20U, which actually > include the large edge as defined in the following email. I am afraid > we probably will need detailed discussion about the size limitation > for each different type, so as to make this whole definition easy to > be accept. A possible proposal could be 1U for small, 2U-20U for > medium, and 20-100U(or even larger) for large. So the small one can > fit for CPE, medium one can fit for access and counties, and large one > can fit for counties and cities > > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年6月20日 17:18 > 收件人: Fu Qiao >; '赵奇慧' > >; 'lebre.adrien' > > 抄送: 'edge-computing' >; 'paul-andre > raymond' > > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Thanks for the info. > > I’m okay to add a large edge deployment scenario. > > What charasterestics should it have? > • Minimum hardware specs: 10 units > • Maximum hardware specs: 20 units > • Physical access of maintainer: > • Physical security: > • Expected frequency of updates to hardware: > • Expected frequency of updates to firmware: > • Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): > • Remote access/connectivity reliability (24/24, periodic, ...): > • Physical size: > • Number of instances (Edge TIC Country / Edge TIC AP according to [6]): > • Distance from Base Station (Access-level DC according to [6]): > • E2E delay (from UE to site) (Access according to [6]): > • Bandwith need (Access according to [6]): > Br, > Gerg0 > > > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 10:59 AM > To: Csatari, Gergely (Nokia - HU/Budapest) > >; '赵奇慧' >; > 'lebre.adrien' > > Cc: 'edge-computing' >; 'paul-andre > raymond' > > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, Gergely. Actually what I am thinking is we probably need more definition for edge scenarios. > I think the definition for small edge and medium edge in the white paper make sense to me, since they basically cover the usecase for customer premises usecases. However, I guess another scenario should also be added which includes 10-20 units. Such scenario is what we say for access and county level. Such unit is not that resource limited as small and medium edge, but we should also consider the resource constrains and make fully use of the limited resource. > As for city level, I understand we can probably use the large edge definition for this, since it could be a quite typical cloud at that level. > Hope this will help. > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年6月20日 16:49 > 收件人: Fu Qiao >; '赵奇慧' > >; 'lebre.adrien' > > 抄送: 'edge-computing' >; 'paul-andre > raymond' > > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Thanks for the comments. > > I’m not sure at all, that we follow the definitions from the > whitepaper in the wiki  > > I referred your talk and the naming you user there becouse of the differences in the definitions. > > Going inline. > > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 4:12 AM > > Hi, all. I guess some more explanations for the China Mobile’s network should be added here. > The definition for small and medium edge from the whitepaper actually is different from what we say about access/county/city. Our access level CO will include compute nodes of about ten more, with distance from the Base station of 10km, delay about 2ms, and bandwidth about 50GB. > > [G0]: Should I add 10 units to the maximum hardware specs part of the Small edge deployment option? > > Our county level CO includes tens of compute nodes, with distance of 50km, delay about 2.5ms, and bandwidth of about 100GB. City level CO will have hundreds of servers, with distance of more than 100km. > I guess the small edge defined in the Whitepaper, with up to 1U, is somehow suitable for edge equipment at the customer site, and this is not actually discussed in my presentation. > > > 发件人: 赵奇慧 [mailto:zhaoqihui at chinamobile.com] > 发送时间: 2018年6月20日 10:03 > > Hi Gergely, > > It's great that our data can help. But I think according the the previous definitions of small edge and medium edge, there should be a little modification here. > > For Small edge, the maximum hardware specs is up to 1 unit, which is similar to our Access-level DC/Edge TIC AP. For Mediun edge, the hardware spec varies from 2RU to 20RU, which is somehow like our County-level DC. So here is my suggestion: > ---------------------------------------------------------------------- > ----- > Small edge: > · Number of instances (Edge TIC AP according to [6]): depend on demands > [G0]: Can we say 3000+ here in a paranthesis? > · Distance from Base Station (Access-level DC according to [6]): around 10km > · E2E delay (from UE to site)(Access according to [6]): 2 ms > · Bandwith need (Access according to [6]): 50 GB > > Medium edge: > · Number of instances (Edge TIC County according to [6]): 3000+ > · Distance from Base Station (Access-level DC according to [6]): around 50km > · E2E delay (from UE to site) (Access according to [6]): less than 2.5 ms > · Bandwith need (Access according to [6]): 100GB > ---------------------------------------------------------------------- > ------ > > [G0]: I’ve updated these to the wiki. > > Thanks, > Gerg0 > > > Best Regards, > Qihui Zhao > China Mobile Research Institute > > Department of Network Technology > >> >> 发件人: Csatari, Gergely (Nokia - HU/Budapest) >> 时间: 2018/06/15(星期五)22:14 >> 收件人: lebre.adrien; >> 抄送人: paul-andre raymond;edge-computing; >> 主题: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements > Hi, > > I was thinking about the generic deployment specific requirements, like bandwiths and delays. > > I've added some of them from the CM presentation to > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG# > Small_edge and > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG# > Medium_edge > > Br, > Gerg0 > > -----Original Message----- > From: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] > Sent: Thursday, June 14, 2018 11:39 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > > Cc: Arkady Kanevsky >; > fuqiao at chinamobile.com; paul-andre raymond > >; edge-computing at lists.openstack.org > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements > > Hi all, > > Maybe we can try to prioritise the projects we want to investigate and > then for each of them identify what are the missing > elements/capabilities (one after the others) > > There are ongoing works on Keystone and Glance. > Nova, Neutron could be the next ones because these 4 services would allow to deploy VM at the edge (and so containers inside VMs). > Cinder will enable the use of remote attached volumes. > Ironic can be useful later. > etc.. > > My two cents, > Ad_ri3n_ > > ----- Mail original ----- > > De: "Gergely Csatari (Nokia - HU/Budapest)" > > > > > À: "Arkady Kanevsky" >, fuqiao at chinamobile.com, "paul-andre raymond" > > >, "lebre adrien" > > >, edge-computing at lists.openstack.org > > Envoyé: Mercredi 13 Juin 2018 17:38:35 > > Objet: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Hi, > > > > Somehow I have a feeling that these latency requirements are related > > to all projects, this is why they should be documented in the > > Deployment options section. > > > > Br, > > Gerg0 > > > > -----Original Message----- > > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > > Sent: Wednesday, June 13, 2018 4:24 PM > > To: Csatari, Gergely (Nokia - HU/Budapest) > > >; fuqiao at chinamobile.com; > > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Gerg0, > > I think these 3 projects are implied from the wiki requirements. > > But it will be good to state projects that may need work explicitly. > > Thanks, > > Arkady > > > > -----Original Message----- > > From: Csatari, Gergely (Nokia - HU/Budapest) > > [mailto:gergely.csatari at nokia.com] > > Sent: Wednesday, June 13, 2018 4:23 AM > > To: Kanevsky, Arkady; fuqiao at chinamobile.com; > > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Hi, > > > > Should we add these to the Deployment Scenarions section of the > > Dublin wiki [1]? > > > > [1]: > > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PT > > G# > > Deployment_Scenarios > > > > Br, > > Gerg0 > > > > -----Original Message----- > > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > > Sent: Wednesday, June 6, 2018 4:49 PM > > To: fuqiao at chinamobile.com; paul-andre.raymond at b-yond.com; > > lebre.adrien at free.fr; edge-computing at lists.openstack.org > > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > It is more than just nova to keystone. > > We also need to consider at least neutron, glance and cinder also. > > > > -----Original Message----- > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > > Sent: Wednesday, June 6, 2018 8:21 AM > > To: 'Paul-Andre Raymond'; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Yes, 5ms is one way. But this is an assumption based on the network > > from China Mobile. The latency will be defer if you have different > > distance, but the calculation method is the same apparently. > > > > -----邮件原件----- > > 发件人: Paul-Andre Raymond [mailto:paul-andre.raymond at b-yond.com] > > 发送时间: 2018年6月6日 21:19 > > 收件人: Fu Qiao >; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > 主题: Re: [Edge-computing] 答复: Clarification of Requirements > > > > Should we separate two kinds of latency requirements: > > - Federation Latency: i.e Central Keystone to Local Keystone > > - API latency: i.e. Edge Nova to local Keystone > > > > Should we measure it one way or Round Trip? I assume the 5ms below > > is one way. > > > > > > Paul-André > > -- > > > > > > On 6/6/18, 5:13 AM, "Fu Qiao" > wrote: > > > > Thank you Adrien. I was just about the reply with more details. > > > > About latency, this as I understand is actually decided mostly by > > the distance of the distributed cloud. So it actually decided by > > where exactly the location Keystone would like to deploy, and what > > is the distance expectation. Like what I explain in my presentation, > > we plan to have keystone sitting in the city level to control multi > > cloud in counties, and the latency will be around 5ms. But again > > this is a certain situation for China Mobile. And other operators > > may make the conlusion on a different structure. Another thing we > > can do is work on simulation and testing and see what kind of > > latency the current keystone federation scheme can tolerant. This > > will help the operators to work out there structure as well. > > > > About bandwidth, the impression for me is we could expect more than > > 50GB of bandwidth for edge for 5G. And I think that is enough for > > most of the app. > > > > Hope this will help. > > > > -----邮件原件----- > > 发件人: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] > > 发送时间: 2018年6月6日 15:25 > > 收件人: edge-computing at lists.openstack.org > > 主题: Re: [Edge-computing] Clarification of Requirements > > > > It is rather difficult to give numbers because there are several > > use-cases. > > However, a good starting point can be to give a look to the > > presentation Qiao Fu gave during the Vancouver summit: > > https://www.openstack.org/videos/vancouver-2018/edge-tic-future-edge > > -cloud-for-china-mobile There is a lot of numbers regarding the > > infrastructure China Mobile is envisioning. > > > > Hope this helps. > > ad_ri3n_ > > PS: I cannot attend the meeting yesterday unfortunately but I'm > > wondering whether the disconnection aspects have been discussed > > (i.e. the fact that one site can be completely isolated for a > > certain period of time due to network disconnections). > > > > ----- Mail original ----- > > > De: "Jess Lampe" > > > > À: edge-computing at lists.openstack.org > > > Envoyé: Mercredi 6 Juin 2018 07:00:31 > > > Objet: [Edge-computing] Clarification of Requirements > > > > > > > > > > > > > > > During the call today, members of the Glance and Keystone teams > > > requested clarity on the following areas: > > > > > > > > > > > > * Latency - what are the specific latency requirements that need > > > to be met? > > > * Bandwidth towards the edge - similarly, what are the limitations > > > of bandwidth at the edge that we can expect? > > > * Security - what are the specific security considerations that > > > need to be? > > > > > > > > > Please feel free to A.) contribute additional areas that need > > > clarifying B.) clarify any of the added. > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbragstad at gmail.com Mon Jul 9 19:25:34 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Mon, 9 Jul 2018 14:25:34 -0500 Subject: [Edge-computing] Keystone Edge Architectures In-Reply-To: References: <678C1A99-2302-438D-8D5D-91ED44B10FF9@windriver.com> <2e2495d6-531f-c0a4-27d6-3c15da111289@gmail.com> <8CB60A46-2C68-444F-994C-45D88FE77D74@windriver.com> <28270e37-13b5-2baa-6952-b084f81e3887@gmail.com> Message-ID: <9e29b7ef-7a60-570d-89ed-d56e8031db69@gmail.com> On 07/03/2018 07:01 AM, Waines, Greg wrote: > > Hey Lance, > > Just following up again on the info below you provided on previous > discussions on issues with API-based Synchronization of Keystone > between clouds. > >   > > In your example below, wouldn’t the API-based Synchronization of the > user password change @ A (assuming A is the central site), result in > the user password change @ B “and” the corresponding revocation event > being created @ B ?   > I guess I need alittle more information in order to answer the question. Do users live in SQL or are they centrally located somewhere else? If they livein SQL, does that mean you're replicating users manually to have the same ID, name, and password across every edge deployment? If so, then you'd beable to manually create revocation events by changing theuser's password at every edge deployment. So if you have 100 deployments, you'll have to change a user's password in 100 places in order to get around the issueI described in the previous note. This leads me to another question. If users are in SQL, are you planning on relying on any PCI-DSS features[0]? If so, this might be another attack surface to consider since:   - an attacker could attempt to brute force a password in deployment A   - the attacker is locked out due to hitting maximum failed authentication attempts   - the attackerattempts to brute force the same account in deployment B (which doesn't know the same user just tried authenticatingand failed X times in deployment A) [0] https://docs.openstack.org/keystone/latest/admin/identity-security-compliance.html >   > > Greg. > >   > >   > > < SNIP > > > > The concept of replicating data over the API was also brought up > towards the end of the call as a possible solution. The TL;DR is that > each deployment would be independent, but data would be kept in sync > by making API requests that forcibly create entities with the same IDs > (manual replication if you will). This idea has been discussed at > length over the last couple years [0]. We most recently discussed it > during the summit in Sydney. > > Where we really tripped was replication of revocation events. For > example, assume you have the ability in keystone to forcibly create > things with specific IDs, allowing you to manually replicate data > across your edge deployments. At the same time you're keeping the > fernet keys in sync, so a user can actually generate tokens in one > deployment and use them in other (since each keystone node has the > same IDs for projects, domains, users, etc..), even though replication > isn't happening at the database. Revocation events are records used > internally by keystone to track events that affect token validity > (e.g. a user changing their password or deleting a specific token), > and they are not exposed via keystone's API. The concern is that > without replicating this table, it would be possible for a user to: > >  - generate a token in deployment A >  - use the token in deployment B to do something >  - change their password in deployment A, which creates a revocation > event invalidating the token from step one in deployment A >  - the user attempts to use the token from step one in deployment A > but it is considered invalid (due to the revocation event) >  - the user successfully executes API calls with the token from step > one in deployment B because deployment B has no knowledge of the > revocation event in deployment A > > We didn't get into that much detail in the call, but wanted to share > where the conversation ended up the last time we had it. > > [0] https://review.openstack.org/#/c/323499/ > > > *< SNIP >* > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From fuqiao at chinamobile.com Tue Jul 10 00:46:01 2018 From: fuqiao at chinamobile.com (fuqiao at chinamobile.com) Date: Tue, 10 Jul 2018 08:46:01 +0800 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion=5Fof=5FRequirements?= References: <201806201003064375530@chinamobile.com>>, <00aa01d4083c$129c7350$37d559f0$@chinamobile.com>, , <010e01d40874$fcb3d720$f61b8560$@chinamobile.com>, , <012001d40879$20bab900$62302b00$@chinamobile.com>, , <7b2e5862b8e84260984b2983d286c8e7@kontron.com>, , <22b0f0f372f14815bdf57cc0aedfd9eb@kontron.com>, , <004801d41333$396ea780$ac4bf680$@chinamobile.com>, , , <201807090911276700446@chinamobile.com>, Message-ID: <2018071008454045049832@chinamobile.com> When is the Tuesday meeting? my outlook was down and I lost all the invitation details... fuqiao at chinamobile.com 发件人： Csatari, Gergely (Nokia - HU/Budapest) 发送时间： 2018-07-09 17:09 收件人： fuqiao at chinamobile.com; Ildiko Vancsa 抄送： eric.sarault; zhaoqihui; lebre.adrien; edge-computing; paul-andre.raymond 主题： RE: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Let’s discuss on the Tuesdsay meeting. I’ve added this issue to the agenda. Br, Gerg0 From: fuqiao at chinamobile.com [mailto:fuqiao at chinamobile.com] Sent: Monday, July 9, 2018 3:11 AM To: Csatari, Gergely (Nokia - HU/Budapest) ; Ildiko Vancsa Cc: eric.sarault ; zhaoqihui ; lebre.adrien ; edge-computing ; paul-andre.raymond Subject: Re: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Gergely. I am totally agree that we should merge these into one set of discription. This will be much easier for us to understand the scenario and also conduct the upcomming code and test case development. what is the next step you suggest? I guess we could have a joint meeting to discuss each and every detail, or we could also put it into the OPNFV EC repo so that people can make comments on gerrit? fuqiao at chinamobile.com 发件人： Csatari, Gergely (Nokia - HU/Budapest) 发送时间： 2018-07-05 17:57 收件人： Ildiko Vancsa; Fu Qiao 抄送： Éric Sarault; 赵奇慧; lebre.adrien; edge-computing; paul-andre raymond 主题： RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Back to the deployment scnearios  Here is a comparision between what is proposed by Qihui Zhao in the OPNFV Edge Computing project [1] and what I've collected in the Dublin notes [2]. Small edge - Distance from base station: - OPNFV EC: less than 10km, closest site to end users/ base station - Dublin: around 10 km - E2E delay: - OPNFV EC: around 2ms - Dublin: 2 ms - Maximum bandwidth can provide - OPNFV EC: 50G - Dublin: 50 GB - Minimum server number - OPNFV EC: 1 - Dublin: 1 unit of 4 cores (two ARM or Xeon-D processors), 8 GB RAM (4 DIMM), 1 * 240 GB SSD (2 * 2.5) - Maximum server number - OPNFV EC: 20 - Dublin: 1 unit of 16 cores, 64 GB RAM, 1 * 1 TB storage - Power for a site: - OPNFV EC: < 10KW - Dublin: N/A - Services might be deployed here: - OPNFV EC: MEC, or other services which have strict requirements on latency. Services deployed in this kind of sites have huge regional deference - Dublin: N/A - Physical access of maintainer: - OPNFV EC: Rare, maintenance staff may only show up in this kind of site when machines initialize for the first time or a machine down - Dublin: Rare - Remote network connection reliability: - OPNFV EC: Not 100% reliable or stable - Dublin: No 100% uptime and variable connectivity expected. - Orchestration: - OPNFV EC: no orchestration component. MANO deployed in core site provide remote orchestration - Dublin: N/A - Degree of virtualization: - OPNFV EC: t is possible that no virtualization technology would be used in small edge site if virtualization increases structure/network complexity, reduce service performance, or cost more resources. Bare-metal is common in small edge sites. Container would also be a future choice if virtualization was needed - Dublin: N/A - Storage: - OPNFV EC: mainly consider local storage. Distributed storage would be used depending on services’ needs and site conditions. - Dublin: N/A - Physical security: - OPNFV EC: N/A - Dublin: none - Expected frequency of updates to hardware: - OPNFV EC: N/A - Dublin: 3-4 year refresh cycle - Expected frequency of updates to firmware: - OPNFV EC: N/A - Dublin: 6-12 months - Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): - OPNFV EC: N/A - Dublin: ~ 12 - 24 months, has to be possible from remote management - Physical size: - OPNFV EC: N/A - Dublin: Not all the sites will have 36 depth capability. Some sites might be limited to 12 depth. - Number of instances (Edge TIC Country / Edge TIC AP according to [6]): - OPNFV EC: N/A - Dublin: depends on demands (3000+) Medium Edge - Distance from base station: - OPNFV EC: 10x km (1 Cc: Csatari, Gergely (Nokia - HU/Budapest) ; Éric Sarault ; 赵奇慧 ; lebre.adrien ; edge-computing ; paul-andre raymond Subject: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, As a connecting item we are also working on a template to be able to describe use cases on a standard, comparable way: * https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases * https://etherpad.openstack.org/p/feedback_on_template This might be a good starting point for a common vocabulary. It is also a question how much we can come up with buckets that fit the different use cases in terms of the size and characteristics of the edge sites. The next Edge Computing Group call is tomorrow (July 5) at 0700 UTC ( https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings ), we can start to discuss this there with those of you available. We also need to figure out whether we would like to utilize any of the already scheduled meetings in each group or rather organize a new one? Thanks and Best Regards, Ildikó > On 2018. Jul 4., at 3:06, Fu Qiao wrote: > > Agree, I think a joint discussion between the team is necessary, so > that we can make sure to work on a common base > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年7月3日 19:01 > 收件人: Éric Sarault ; Fu Qiao > ; '赵奇慧' ; > 'lebre.adrien' > 抄送: 'edge-computing' ; 'paul-andre > raymond' > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Isn’t this case covered by [1] ? > > On the other hand there is a new set of deployment options listed by OPNFV in [2]. > It would be nice if we could harmonize these somehow… > > > [1]: > https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussion > s_Dublin_PTG#Small_edge > [2]: > https://gerrit.opnfv.org/gerrit/#/c/58959/4/docs/development/requireme > nts/requirements.rst > > Br, > Gerg0 > > > From: Éric Sarault [mailto:Eric.Sarault at kontron.com] > Sent: Tuesday, June 26, 2018 2:50 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > ; Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Yes, in some scenarios, we need to consider CPE units. This could be a consumer endpoint device/appliance that looks like your typical router from your ISV. These are typically ARM based units or you could also see some Intel Xeon-D units there (Atom worst case). The use case behind is to manage tens of thousands of these as an edge federation. At the same scale, think also Industrial IoT or Retail. My point is not everything is a rackmount format so we just need to be clear what the target is here as the form factor might limit the versatility of one or many use cases. > > --- > Eric Sarault, B. Eng. > Software Product Manager > Kontron – An S&T Company > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada > P: +1 (450) 437-5682 x > eric.sarault at kontron.com > > Website | Blog | Twitter | LinkedIn | YouTube | Facebook > > Kontron Canada Inc. > By opening this email you are agreeing to Kontron's Electronic Communications Policy. > > From: Csatari, Gergely (Nokia - HU/Budapest) > > Sent: June 26, 2018 7:09 AM > To: Éric Sarault ; Fu Qiao > ; '赵奇慧' ; > 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > So you mean that the minimum HW spec is smaller thean 1 unit? > > Br, > Gerg0 > > From: Éric Sarault [mailto:Eric.Sarault at kontron.com] > Sent: Wednesday, June 20, 2018 3:14 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > ; Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Is the purpose of limiting the small edge to 1U is to classify it as the CPE use case? We need to keep in mind some CPE/vCPE equipment isn’t even “rackmountable” so we need to keep track of this (i.e: set up box, ISV router). > > --- > Eric Sarault, B. Eng. > Software Product Manager > Kontron – An S&T Company > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada > P: +1 (450) 437-5682 x > eric.sarault at kontron.com > > Website | Blog | Twitter | LinkedIn | YouTube | Facebook > > Kontron Canada Inc. > By opening this email you are agreeing to Kontron's Electronic Communications Policy. > > From: Csatari, Gergely (Nokia - HU/Budapest) > > Sent: June 20, 2018 5:36 AM > To: Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > I am okay with your classification for small, medium and large. > > Br, > Gerg0 > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 11:29 AM > To: Csatari, Gergely (Nokia - HU/Budapest) > ; '赵奇慧' ; > 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, Georgly. I read through the wiki definition for small and medium, and I guess it probably is not that direct to just define a large edge scenario. > I notice that in the medium edge, the size is 2U-20U, which actually > include the large edge as defined in the following email. I am afraid > we probably will need detailed discussion about the size limitation > for each different type, so as to make this whole definition easy to > be accept. A possible proposal could be 1U for small, 2U-20U for > medium, and 20-100U(or even larger) for large. So the small one can > fit for CPE, medium one can fit for access and counties, and large one > can fit for counties and cities > > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年6月20日 17:18 > 收件人: Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > 抄送: 'edge-computing' ; 'paul-andre > raymond' > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Thanks for the info. > > I’m okay to add a large edge deployment scenario. > > What charasterestics should it have? > • Minimum hardware specs: 10 units > • Maximum hardware specs: 20 units > • Physical access of maintainer: > • Physical security: > • Expected frequency of updates to hardware: > • Expected frequency of updates to firmware: > • Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): > • Remote access/connectivity reliability (24/24, periodic, ...): > • Physical size: > • Number of instances (Edge TIC Country / Edge TIC AP according to [6]): > • Distance from Base Station (Access-level DC according to [6]): > • E2E delay (from UE to site) (Access according to [6]): > • Bandwith need (Access according to [6]): > Br, > Gerg0 > > > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 10:59 AM > To: Csatari, Gergely (Nokia - HU/Budapest) > ; '赵奇慧' ; > 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, Gergely. Actually what I am thinking is we probably need more definition for edge scenarios. > I think the definition for small edge and medium edge in the white paper make sense to me, since they basically cover the usecase for customer premises usecases. However, I guess another scenario should also be added which includes 10-20 units. Such scenario is what we say for access and county level. Such unit is not that resource limited as small and medium edge, but we should also consider the resource constrains and make fully use of the limited resource. > As for city level, I understand we can probably use the large edge definition for this, since it could be a quite typical cloud at that level. > Hope this will help. > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年6月20日 16:49 > 收件人: Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > 抄送: 'edge-computing' ; 'paul-andre > raymond' > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Thanks for the comments. > > I’m not sure at all, that we follow the definitions from the > whitepaper in the wiki  > > I referred your talk and the naming you user there becouse of the differences in the definitions. > > Going inline. > > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 4:12 AM > > Hi, all. I guess some more explanations for the China Mobile’s network should be added here. > The definition for small and medium edge from the whitepaper actually is different from what we say about access/county/city. Our access level CO will include compute nodes of about ten more, with distance from the Base station of 10km, delay about 2ms, and bandwidth about 50GB. > > [G0]: Should I add 10 units to the maximum hardware specs part of the Small edge deployment option? > > Our county level CO includes tens of compute nodes, with distance of 50km, delay about 2.5ms, and bandwidth of about 100GB. City level CO will have hundreds of servers, with distance of more than 100km. > I guess the small edge defined in the Whitepaper, with up to 1U, is somehow suitable for edge equipment at the customer site, and this is not actually discussed in my presentation. > > > 发件人: 赵奇慧 [mailto:zhaoqihui at chinamobile.com] > 发送时间: 2018年6月20日 10:03 > > Hi Gergely, > > It's great that our data can help. But I think according the the previous definitions of small edge and medium edge, there should be a little modification here. > > For Small edge, the maximum hardware specs is up to 1 unit, which is similar to our Access-level DC/Edge TIC AP. For Mediun edge, the hardware spec varies from 2RU to 20RU, which is somehow like our County-level DC. So here is my suggestion: > ---------------------------------------------------------------------- > ----- > Small edge: > · Number of instances (Edge TIC AP according to [6]): depend on demands > [G0]: Can we say 3000+ here in a paranthesis? > · Distance from Base Station (Access-level DC according to [6]): around 10km > · E2E delay (from UE to site)(Access according to [6]): 2 ms > · Bandwith need (Access according to [6]): 50 GB > > Medium edge: > · Number of instances (Edge TIC County according to [6]): 3000+ > · Distance from Base Station (Access-level DC according to [6]): around 50km > · E2E delay (from UE to site) (Access according to [6]): less than 2.5 ms > · Bandwith need (Access according to [6]): 100GB > ---------------------------------------------------------------------- > ------ > > [G0]: I’ve updated these to the wiki. > > Thanks, > Gerg0 > > > Best Regards, > Qihui Zhao > China Mobile Research Institute > > Department of Network Technology > >> >> 发件人: Csatari, Gergely (Nokia - HU/Budapest) >> 时间: 2018/06/15(星期五)22:14 >> 收件人: lebre.adrien; >> 抄送人: paul-andre raymond;edge-computing; >> 主题: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements > Hi, > > I was thinking about the generic deployment specific requirements, like bandwiths and delays. > > I've added some of them from the CM presentation to > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG# > Small_edge and > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG# > Medium_edge > > Br, > Gerg0 > > -----Original Message----- > From: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] > Sent: Thursday, June 14, 2018 11:39 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > Cc: Arkady Kanevsky ; > fuqiao at chinamobile.com; paul-andre raymond > ; edge-computing at lists.openstack.org > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements > > Hi all, > > Maybe we can try to prioritise the projects we want to investigate and > then for each of them identify what are the missing > elements/capabilities (one after the others) > > There are ongoing works on Keystone and Glance. > Nova, Neutron could be the next ones because these 4 services would allow to deploy VM at the edge (and so containers inside VMs). > Cinder will enable the use of remote attached volumes. > Ironic can be useful later. > etc.. > > My two cents, > Ad_ri3n_ > > ----- Mail original ----- > > De: "Gergely Csatari (Nokia - HU/Budapest)" > > > > À: "Arkady Kanevsky" , fuqiao at chinamobile.com, "paul-andre raymond" > > , "lebre adrien" > > , edge-computing at lists.openstack.org > > Envoyé: Mercredi 13 Juin 2018 17:38:35 > > Objet: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Hi, > > > > Somehow I have a feeling that these latency requirements are related > > to all projects, this is why they should be documented in the > > Deployment options section. > > > > Br, > > Gerg0 > > > > -----Original Message----- > > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > > Sent: Wednesday, June 13, 2018 4:24 PM > > To: Csatari, Gergely (Nokia - HU/Budapest) > > ; fuqiao at chinamobile.com; > > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Gerg0, > > I think these 3 projects are implied from the wiki requirements. > > But it will be good to state projects that may need work explicitly. > > Thanks, > > Arkady > > > > -----Original Message----- > > From: Csatari, Gergely (Nokia - HU/Budapest) > > [mailto:gergely.csatari at nokia.com] > > Sent: Wednesday, June 13, 2018 4:23 AM > > To: Kanevsky, Arkady; fuqiao at chinamobile.com; > > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Hi, > > > > Should we add these to the Deployment Scenarions section of the > > Dublin wiki [1]? > > > > [1]: > > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PT > > G# > > Deployment_Scenarios > > > > Br, > > Gerg0 > > > > -----Original Message----- > > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > > Sent: Wednesday, June 6, 2018 4:49 PM > > To: fuqiao at chinamobile.com; paul-andre.raymond at b-yond.com; > > lebre.adrien at free.fr; edge-computing at lists.openstack.org > > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > It is more than just nova to keystone. > > We also need to consider at least neutron, glance and cinder also. > > > > -----Original Message----- > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > > Sent: Wednesday, June 6, 2018 8:21 AM > > To: 'Paul-Andre Raymond'; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Yes, 5ms is one way. But this is an assumption based on the network > > from China Mobile. The latency will be defer if you have different > > distance, but the calculation method is the same apparently. > > > > -----邮件原件----- > > 发件人: Paul-Andre Raymond [mailto:paul-andre.raymond at b-yond.com] > > 发送时间: 2018年6月6日 21:19 > > 收件人: Fu Qiao ; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > 主题: Re: [Edge-computing] 答复: Clarification of Requirements > > > > Should we separate two kinds of latency requirements: > > - Federation Latency: i.e Central Keystone to Local Keystone > > - API latency: i.e. Edge Nova to local Keystone > > > > Should we measure it one way or Round Trip? I assume the 5ms below > > is one way. > > > > > > Paul-André > > -- > > > > > > On 6/6/18, 5:13 AM, "Fu Qiao" wrote: > > > > Thank you Adrien. I was just about the reply with more details. > > > > About latency, this as I understand is actually decided mostly by > > the distance of the distributed cloud. So it actually decided by > > where exactly the location Keystone would like to deploy, and what > > is the distance expectation. Like what I explain in my presentation, > > we plan to have keystone sitting in the city level to control multi > > cloud in counties, and the latency will be around 5ms. But again > > this is a certain situation for China Mobile. And other operators > > may make the conlusion on a different structure. Another thing we > > can do is work on simulation and testing and see what kind of > > latency the current keystone federation scheme can tolerant. This > > will help the operators to work out there structure as well. > > > > About bandwidth, the impression for me is we could expect more than > > 50GB of bandwidth for edge for 5G. And I think that is enough for > > most of the app. > > > > Hope this will help. > > > > -----邮件原件----- > > 发件人: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] > > 发送时间: 2018年6月6日 15:25 > > 收件人: edge-computing at lists.openstack.org > > 主题: Re: [Edge-computing] Clarification of Requirements > > > > It is rather difficult to give numbers because there are several > > use-cases. > > However, a good starting point can be to give a look to the > > presentation Qiao Fu gave during the Vancouver summit: > > https://www.openstack.org/videos/vancouver-2018/edge-tic-future-edge > > -cloud-for-china-mobile There is a lot of numbers regarding the > > infrastructure China Mobile is envisioning. > > > > Hope this helps. > > ad_ri3n_ > > PS: I cannot attend the meeting yesterday unfortunately but I'm > > wondering whether the disconnection aspects have been discussed > > (i.e. the fact that one site can be completely isolated for a > > certain period of time due to network disconnections). > > > > ----- Mail original ----- > > > De: "Jess Lampe" > > > À: edge-computing at lists.openstack.org > > > Envoyé: Mercredi 6 Juin 2018 07:00:31 > > > Objet: [Edge-computing] Clarification of Requirements > > > > > > > > > > > > > > > During the call today, members of the Glance and Keystone teams > > > requested clarity on the following areas: > > > > > > > > > > > > * Latency - what are the specific latency requirements that need > > > to be met? > > > * Bandwidth towards the edge - similarly, what are the limitations > > > of bandwidth at the edge that we can expect? > > > * Security - what are the specific security considerations that > > > need to be? > > > > > > > > > Please feel free to A.) contribute additional areas that need > > > clarifying B.) clarify any of the added. > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From claire at openstack.org Tue Jul 10 00:53:10 2018 From: claire at openstack.org (Claire Massey) Date: Mon, 9 Jul 2018 19:53:10 -0500 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion=5Fof=5FRequirements?= In-Reply-To: <2018071008454045049832@chinamobile.com> References: <201806201003064375530@chinamobile.com> <00aa01d4083c$129c7350$37d559f0$@chinamobile.com> <010e01d40874$fcb3d720$f61b8560$@chinamobile.com> <012001d40879$20bab900$62302b00$@chinamobile.com> <7b2e5862b8e84260984b2983d286c8e7@kontron.com> <22b0f0f372f14815bdf57cc0aedfd9eb@kontron.com> <004801d41333$396ea780$ac4bf680$@chinamobile.com> <201807090911276700446@chinamobile.com> <2018071008454045049832@chinamobile.com> Message-ID: It’s at 1400 UTC (7:00am PDT). > On Jul 9, 2018, at 7:46 PM, "fuqiao at chinamobile.com" wrote: > > When is the Tuesday meeting? my outlook was down and I lost all the invitation details... > > fuqiao at chinamobile.com > > 发件人： Csatari, Gergely (Nokia - HU/Budapest) > 发送时间： 2018-07-09 17:09 > 收件人： fuqiao at chinamobile.com; Ildiko Vancsa > 抄送： eric.sarault; zhaoqihui; lebre.adrien; edge-computing; paul-andre.raymond > 主题： RE: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > Hi, > > Let’s discuss on the Tuesdsay meeting. I’ve added this issue to the agenda. > > Br, > Gerg0 > > From: fuqiao at chinamobile.com [mailto:fuqiao at chinamobile.com] > Sent: Monday, July 9, 2018 3:11 AM > To: Csatari, Gergely (Nokia - HU/Budapest) ; Ildiko Vancsa > Cc: eric.sarault ; zhaoqihui ; lebre.adrien ; edge-computing ; paul-andre.raymond > Subject: Re: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, Gergely. I am totally agree that we should merge these into one set of discription. This will be much easier for us to understand the scenario and also conduct the upcomming code and test case development. > what is the next step you suggest? I guess we could have a joint meeting to discuss each and every detail, or we could also put it into the OPNFV EC repo so that people can make comments on gerrit? > > fuqiao at chinamobile.com > > 发件人： Csatari, Gergely (Nokia - HU/Budapest) > 发送时间： 2018-07-05 17:57 > 收件人： Ildiko Vancsa; Fu Qiao > 抄送： Éric Sarault; 赵奇慧; lebre.adrien; edge-computing; paul-andre raymond > 主题： RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > Hi, > > Back to the deployment scnearios  > > Here is a comparision between what is proposed by Qihui Zhao in the OPNFV Edge Computing project [1] and what I've collected in the Dublin notes [2]. > > Small edge > - Distance from base station: > - OPNFV EC: less than 10km, closest site to end users/ base station > - Dublin: around 10 km > - E2E delay: > - OPNFV EC: around 2ms > - Dublin: 2 ms > - Maximum bandwidth can provide > - OPNFV EC: 50G > - Dublin: 50 GB > - Minimum server number > - OPNFV EC: 1 > - Dublin: 1 unit of 4 cores (two ARM or Xeon-D processors), 8 GB RAM (4 DIMM), 1 * 240 GB SSD (2 * 2.5) > - Maximum server number > - OPNFV EC: 20 > - Dublin: 1 unit of 16 cores, 64 GB RAM, 1 * 1 TB storage > - Power for a site: > - OPNFV EC: < 10KW > - Dublin: N/A > - Services might be deployed here: > - OPNFV EC: MEC, or other services which have strict requirements on latency. Services deployed in this kind of sites have huge regional deference > - Dublin: N/A > - Physical access of maintainer: > - OPNFV EC: Rare, maintenance staff may only show up in this kind of site when machines initialize for the first time or a machine down > - Dublin: Rare > - Remote network connection reliability: > - OPNFV EC: Not 100% reliable or stable > - Dublin: No 100% uptime and variable connectivity expected. > - Orchestration: > - OPNFV EC: no orchestration component. MANO deployed in core site provide remote orchestration > - Dublin: N/A > - Degree of virtualization: > - OPNFV EC: t is possible that no virtualization technology would be used in small edge site if virtualization increases structure/network complexity, reduce service performance, or cost more resources. Bare-metal is common in small edge sites. Container would also be a future choice if virtualization was needed > - Dublin: N/A > - Storage: > - OPNFV EC: mainly consider local storage. Distributed storage would be used depending on services’ needs and site conditions. > - Dublin: N/A > - Physical security: > - OPNFV EC: N/A > - Dublin: none > - Expected frequency of updates to hardware: > - OPNFV EC: N/A > - Dublin: 3-4 year refresh cycle > - Expected frequency of updates to firmware: > - OPNFV EC: N/A > - Dublin: 6-12 months > - Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): > - OPNFV EC: N/A > - Dublin: ~ 12 - 24 months, has to be possible from remote management > - Physical size: > - OPNFV EC: N/A > - Dublin: Not all the sites will have 36 depth capability. Some sites might be limited to 12 depth. > - Number of instances (Edge TIC Country / Edge TIC AP according to [6]): > - OPNFV EC: N/A > - Dublin: depends on demands (3000+) > > Medium Edge > - Distance from base station: > - OPNFV EC: 10x km (1 - Dublin: around 50 km > - E2E delay: > - OPNFV EC: less than 2.5ms > - Dublin: less than 2.5 ms > - Maximum bandwidth can provide > - OPNFV EC: 100G > - Dublin: 100 GB > - Minimum server number > - OPNFV EC: 20 > - Dublin: 2 RU > - Maximum server number > - OPNFV EC: 100 > - Dublin: 20 RU > - Power for a site: > - OPNFV EC: 10 KW - Dublin: N/A > - Services might be deployed here: > - OPNFV EC: MEC, RAN, CPE, etc. > - Dublin: N/A > - Physical access of maintainer: > - OPNFV EC: Rare > - Dublin: Rare > - Remote network connection reliability: > - OPNFV EC: Not 100% reliable or stable > - Dublin: 24/24 (high uptime but connectivity is variable), 100% uptime expected > - Orchestration: > - OPNFV EC: no orchestration component. MANO deployed in core site provide remote orchestration. > - Dublin: N/A > - Degree of virtualization: > - OPNFV EC: depends on site conditions and service requirements. VM, container may form hybrid virtualization layer. Bare-metal is possible in middle sites > - Dublin: N/A > - Storage: > - OPNFV EC: local storage and distributed storage, which depends on site conditions and services’ needs > - Dublin: N/A > - Physical security: > - OPNFV EC: N/A > - Dublin: Medium, probably not in a secure data center, probably in a semi-physically secure; each device has some authentication (such as certificate) to verify it's a legitimate piece of hardware deployed by operator; network access is all through security enhanced methods (vpn, connected back to dmz); VPN itself is not considered secure, so other mechanism such as https should be employed as well) > - Expected frequency of updates to hardware: > - OPNFV EC: N/A > - Dublin: 5-7 years > - Expected frequency of updates to firmware: > - OPNFV EC: N/A > - Dublin: Never unless required to fix blocker/critical bug(s) > - Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): > - OPNFV EC: N/A > - Dublin: 12 - 24 months > - Physical size: > - OPNFV EC: N/A > - Dublin: N/A > - Number of instances (Edge TIC Country / Edge TIC AP according to [6]): > - OPNFV EC: N/A > - Dublin: 3000+ > > Large Edge > Is not defined in the Dublin notes > - E2E delay: around 4ms > - Distance to base station: 100x km (0.8 - Maximum bandwidth can provide: 200G > - Server number: 100+ > - Power for a site: 10x KW (2 - Services might be deployed here: CDN, SAE-GW, UPF, CPE and etc., which have large bandwidth requirements and relatively small latency requirements > - Physical access of maintainer: professional maintainer will monitor the site > - Remote network connection reliability: reliable and stable > - Orchestration: no orchestration component. MANO deployed in core site provide remote orchestration > - Degree of virtualization: almost completely virtualized in the form of VMs (if take CDN into consideration, which may not be virtualized, the virtualization degree would decrease in sites with CDN deployment) > - Storage: distributed storage > > Would it be possible somehow to merge these into one set of definitions? For me it is okay to maintain it in the OPNFV Edge Computing repo. > > [1]: https://gerrit.opnfv.org/gerrit/#/c/58959/ > [2]: https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG > > Br, > Gerg0 > > > -----Original Message----- > From: Ildiko Vancsa [mailto:ildiko.vancsa at gmail.com] > Sent: Wednesday, July 4, 2018 8:23 PM > To: Fu Qiao > Cc: Csatari, Gergely (Nokia - HU/Budapest) ; Éric Sarault ; 赵奇慧 ; lebre.adrien ; edge-computing ; paul-andre raymond > Subject: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > As a connecting item we are also working on a template to be able to describe use cases on a standard, comparable way: > > * https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases > * https://etherpad.openstack.org/p/feedback_on_template > > This might be a good starting point for a common vocabulary. It is also a question how much we can come up with buckets that fit the different use cases in terms of the size and characteristics of the edge sites. > > The next Edge Computing Group call is tomorrow (July 5) at 0700 UTC ( https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings ), we can start to discuss this there with those of you available. > > We also need to figure out whether we would like to utilize any of the already scheduled meetings in each group or rather organize a new one? > > Thanks and Best Regards, > Ildikó > > > > On 2018. Jul 4., at 3:06, Fu Qiao wrote: > > > > Agree, I think a joint discussion between the team is necessary, so > > that we can make sure to work on a common base > > > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > > [mailto:gergely.csatari at nokia.com] > > 发送时间: 2018年7月3日 19:01 > > 收件人: Éric Sarault ; Fu Qiao > > ; '赵奇慧' ; > > 'lebre.adrien' > > 抄送: 'edge-computing' ; 'paul-andre > > raymond' > > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > > > Hi, > > > > Isn’t this case covered by [1] ? > > > > On the other hand there is a new set of deployment options listed by OPNFV in [2]. > > It would be nice if we could harmonize these somehow… > > > > > > [1]: > > https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussion > > s_Dublin_PTG#Small_edge > > [2]: > > https://gerrit.opnfv.org/gerrit/#/c/58959/4/docs/development/requireme > > nts/requirements.rst > > > > Br, > > Gerg0 > > > > > > From: Éric Sarault [mailto:Eric.Sarault at kontron.com] > > Sent: Tuesday, June 26, 2018 2:50 PM > > To: Csatari, Gergely (Nokia - HU/Budapest) > > ; Fu Qiao ; '赵奇慧' > > ; 'lebre.adrien' > > Cc: 'edge-computing' ; 'paul-andre > > raymond' > > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > > > Yes, in some scenarios, we need to consider CPE units. This could be a consumer endpoint device/appliance that looks like your typical router from your ISV. These are typically ARM based units or you could also see some Intel Xeon-D units there (Atom worst case). The use case behind is to manage tens of thousands of these as an edge federation. At the same scale, think also Industrial IoT or Retail. My point is not everything is a rackmount format so we just need to be clear what the target is here as the form factor might limit the versatility of one or many use cases. > > > > --- > > Eric Sarault, B. Eng. > > Software Product Manager > > Kontron – An S&T Company > > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada > > P: +1 (450) 437-5682 x > > eric.sarault at kontron.com > > > > Website | Blog | Twitter | LinkedIn | YouTube | Facebook > > > > Kontron Canada Inc. > > By opening this email you are agreeing to Kontron's Electronic Communications Policy. > > > > From: Csatari, Gergely (Nokia - HU/Budapest) > > > > Sent: June 26, 2018 7:09 AM > > To: Éric Sarault ; Fu Qiao > > ; '赵奇慧' ; > > 'lebre.adrien' > > Cc: 'edge-computing' ; 'paul-andre > > raymond' > > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > > > Hi, > > > > So you mean that the minimum HW spec is smaller thean 1 unit? > > > > Br, > > Gerg0 > > > > From: Éric Sarault [mailto:Eric.Sarault at kontron.com] > > Sent: Wednesday, June 20, 2018 3:14 PM > > To: Csatari, Gergely (Nokia - HU/Budapest) > > ; Fu Qiao ; '赵奇慧' > > ; 'lebre.adrien' > > Cc: 'edge-computing' ; 'paul-andre > > raymond' > > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > > > Is the purpose of limiting the small edge to 1U is to classify it as the CPE use case? We need to keep in mind some CPE/vCPE equipment isn’t even “rackmountable” so we need to keep track of this (i.e: set up box, ISV router). > > > > --- > > Eric Sarault, B. Eng. > > Software Product Manager > > Kontron – An S&T Company > > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada > > P: +1 (450) 437-5682 x > > eric.sarault at kontron.com > > > > Website | Blog | Twitter | LinkedIn | YouTube | Facebook > > > > Kontron Canada Inc. > > By opening this email you are agreeing to Kontron's Electronic Communications Policy. > > > > From: Csatari, Gergely (Nokia - HU/Budapest) > > > > Sent: June 20, 2018 5:36 AM > > To: Fu Qiao ; '赵奇慧' > > ; 'lebre.adrien' > > Cc: 'edge-computing' ; 'paul-andre > > raymond' > > Subject: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > > > Hi, > > > > I am okay with your classification for small, medium and large. > > > > Br, > > Gerg0 > > > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > > Sent: Wednesday, June 20, 2018 11:29 AM > > To: Csatari, Gergely (Nokia - HU/Budapest) > > ; '赵奇慧' ; > > 'lebre.adrien' > > Cc: 'edge-computing' ; 'paul-andre > > raymond' > > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > > > Hi, Georgly. I read through the wiki definition for small and medium, and I guess it probably is not that direct to just define a large edge scenario. > > I notice that in the medium edge, the size is 2U-20U, which actually > > include the large edge as defined in the following email. I am afraid > > we probably will need detailed discussion about the size limitation > > for each different type, so as to make this whole definition easy to > > be accept. A possible proposal could be 1U for small, 2U-20U for > > medium, and 20-100U(or even larger) for large. So the small one can > > fit for CPE, medium one can fit for access and counties, and large one > > can fit for counties and cities > > > > > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > > [mailto:gergely.csatari at nokia.com] > > 发送时间: 2018年6月20日 17:18 > > 收件人: Fu Qiao ; '赵奇慧' > > ; 'lebre.adrien' > > 抄送: 'edge-computing' ; 'paul-andre > > raymond' > > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > > > Hi, > > > > Thanks for the info. > > > > I’m okay to add a large edge deployment scenario. > > > > What charasterestics should it have? > > • Minimum hardware specs: 10 units > > • Maximum hardware specs: 20 units > > • Physical access of maintainer: > > • Physical security: > > • Expected frequency of updates to hardware: > > • Expected frequency of updates to firmware: > > • Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): > > • Remote access/connectivity reliability (24/24, periodic, ...): > > • Physical size: > > • Number of instances (Edge TIC Country / Edge TIC AP according to [6]): > > • Distance from Base Station (Access-level DC according to [6]): > > • E2E delay (from UE to site) (Access according to [6]): > > • Bandwith need (Access according to [6]): > > Br, > > Gerg0 > > > > > > > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > > Sent: Wednesday, June 20, 2018 10:59 AM > > To: Csatari, Gergely (Nokia - HU/Budapest) > > ; '赵奇慧' ; > > 'lebre.adrien' > > Cc: 'edge-computing' ; 'paul-andre > > raymond' > > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > > > Hi, Gergely. Actually what I am thinking is we probably need more definition for edge scenarios. > > I think the definition for small edge and medium edge in the white paper make sense to me, since they basically cover the usecase for customer premises usecases. However, I guess another scenario should also be added which includes 10-20 units. Such scenario is what we say for access and county level. Such unit is not that resource limited as small and medium edge, but we should also consider the resource constrains and make fully use of the limited resource. > > As for city level, I understand we can probably use the large edge definition for this, since it could be a quite typical cloud at that level. > > Hope this will help. > > > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > > [mailto:gergely.csatari at nokia.com] > > 发送时间: 2018年6月20日 16:49 > > 收件人: Fu Qiao ; '赵奇慧' > > ; 'lebre.adrien' > > 抄送: 'edge-computing' ; 'paul-andre > > raymond' > > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > > > Hi, > > > > Thanks for the comments. > > > > I’m not sure at all, that we follow the definitions from the > > whitepaper in the wiki  > > > > I referred your talk and the naming you user there becouse of the differences in the definitions. > > > > Going inline. > > > > > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > > Sent: Wednesday, June 20, 2018 4:12 AM > > > > Hi, all. I guess some more explanations for the China Mobile’s network should be added here. > > The definition for small and medium edge from the whitepaper actually is different from what we say about access/county/city. Our access level CO will include compute nodes of about ten more, with distance from the Base station of 10km, delay about 2ms, and bandwidth about 50GB. > > > > [G0]: Should I add 10 units to the maximum hardware specs part of the Small edge deployment option? > > > > Our county level CO includes tens of compute nodes, with distance of 50km, delay about 2.5ms, and bandwidth of about 100GB. City level CO will have hundreds of servers, with distance of more than 100km. > > I guess the small edge defined in the Whitepaper, with up to 1U, is somehow suitable for edge equipment at the customer site, and this is not actually discussed in my presentation. > > > > > > 发件人: 赵奇慧 [mailto:zhaoqihui at chinamobile.com] > > 发送时间: 2018年6月20日 10:03 > > > > Hi Gergely, > > > > It's great that our data can help. But I think according the the previous definitions of small edge and medium edge, there should be a little modification here. > > > > For Small edge, the maximum hardware specs is up to 1 unit, which is similar to our Access-level DC/Edge TIC AP. For Mediun edge, the hardware spec varies from 2RU to 20RU, which is somehow like our County-level DC. So here is my suggestion: > > ---------------------------------------------------------------------- > > ----- > > Small edge: > > · Number of instances (Edge TIC AP according to [6]): depend on demands > > [G0]: Can we say 3000+ here in a paranthesis? > > · Distance from Base Station (Access-level DC according to [6]): around 10km > > · E2E delay (from UE to site)(Access according to [6]): 2 ms > > · Bandwith need (Access according to [6]): 50 GB > > > > Medium edge: > > · Number of instances (Edge TIC County according to [6]): 3000+ > > · Distance from Base Station (Access-level DC according to [6]): around 50km > > · E2E delay (from UE to site) (Access according to [6]): less than 2.5 ms > > · Bandwith need (Access according to [6]): 100GB > > ---------------------------------------------------------------------- > > ------ > > > > [G0]: I’ve updated these to the wiki. > > > > Thanks, > > Gerg0 > > > > > > Best Regards, > > Qihui Zhao > > China Mobile Research Institute > > > > Department of Network Technology > > > >> > >> 发件人: Csatari, Gergely (Nokia - HU/Budapest) > >> 时间: 2018/06/15(星期五)22:14 > >> 收件人: lebre.adrien; > >> 抄送人: paul-andre raymond;edge-computing; > >> 主题: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > > > I was thinking about the generic deployment specific requirements, like bandwiths and delays. > > > > I've added some of them from the CM presentation to > > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG# > > Small_edge and > > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG# > > Medium_edge > > > > Br, > > Gerg0 > > > > -----Original Message----- > > From: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] > > Sent: Thursday, June 14, 2018 11:39 PM > > To: Csatari, Gergely (Nokia - HU/Budapest) > > Cc: Arkady Kanevsky ; > > fuqiao at chinamobile.com; paul-andre raymond > > ; edge-computing at lists.openstack.org > > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Hi all, > > > > Maybe we can try to prioritise the projects we want to investigate and > > then for each of them identify what are the missing > > elements/capabilities (one after the others) > > > > There are ongoing works on Keystone and Glance. > > Nova, Neutron could be the next ones because these 4 services would allow to deploy VM at the edge (and so containers inside VMs). > > Cinder will enable the use of remote attached volumes. > > Ironic can be useful later. > > etc.. > > > > My two cents, > > Ad_ri3n_ > > > > ----- Mail original ----- > > > De: "Gergely Csatari (Nokia - HU/Budapest)" > > > > > > À: "Arkady Kanevsky" , fuqiao at chinamobile.com, "paul-andre raymond" > > > , "lebre adrien" > > > , edge-computing at lists.openstack.org > > > Envoyé: Mercredi 13 Juin 2018 17:38:35 > > > Objet: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > > > Hi, > > > > > > Somehow I have a feeling that these latency requirements are related > > > to all projects, this is why they should be documented in the > > > Deployment options section. > > > > > > Br, > > > Gerg0 > > > > > > -----Original Message----- > > > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > > > Sent: Wednesday, June 13, 2018 4:24 PM > > > To: Csatari, Gergely (Nokia - HU/Budapest) > > > ; fuqiao at chinamobile.com; > > > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr; > > > edge-computing at lists.openstack.org > > > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > > > Gerg0, > > > I think these 3 projects are implied from the wiki requirements. > > > But it will be good to state projects that may need work explicitly. > > > Thanks, > > > Arkady > > > > > > -----Original Message----- > > > From: Csatari, Gergely (Nokia - HU/Budapest) > > > [mailto:gergely.csatari at nokia.com] > > > Sent: Wednesday, June 13, 2018 4:23 AM > > > To: Kanevsky, Arkady; fuqiao at chinamobile.com; > > > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr; > > > edge-computing at lists.openstack.org > > > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > > > Hi, > > > > > > Should we add these to the Deployment Scenarions section of the > > > Dublin wiki [1]? > > > > > > [1]: > > > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PT > > > G# > > > Deployment_Scenarios > > > > > > Br, > > > Gerg0 > > > > > > -----Original Message----- > > > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > > > Sent: Wednesday, June 6, 2018 4:49 PM > > > To: fuqiao at chinamobile.com; paul-andre.raymond at b-yond.com; > > > lebre.adrien at free.fr; edge-computing at lists.openstack.org > > > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > > > It is more than just nova to keystone. > > > We also need to consider at least neutron, glance and cinder also. > > > > > > -----Original Message----- > > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > > > Sent: Wednesday, June 6, 2018 8:21 AM > > > To: 'Paul-Andre Raymond'; lebre.adrien at free.fr; > > > edge-computing at lists.openstack.org > > > Subject: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > > > Yes, 5ms is one way. But this is an assumption based on the network > > > from China Mobile. The latency will be defer if you have different > > > distance, but the calculation method is the same apparently. > > > > > > -----邮件原件----- > > > 发件人: Paul-Andre Raymond [mailto:paul-andre.raymond at b-yond.com] > > > 发送时间: 2018年6月6日 21:19 > > > 收件人: Fu Qiao ; lebre.adrien at free.fr; > > > edge-computing at lists.openstack.org > > > 主题: Re: [Edge-computing] 答复: Clarification of Requirements > > > > > > Should we separate two kinds of latency requirements: > > > - Federation Latency: i.e Central Keystone to Local Keystone > > > - API latency: i.e. Edge Nova to local Keystone > > > > > > Should we measure it one way or Round Trip? I assume the 5ms below > > > is one way. > > > > > > > > > Paul-André > > > -- > > > > > > > > > On 6/6/18, 5:13 AM, "Fu Qiao" wrote: > > > > > > Thank you Adrien. I was just about the reply with more details. > > > > > > About latency, this as I understand is actually decided mostly by > > > the distance of the distributed cloud. So it actually decided by > > > where exactly the location Keystone would like to deploy, and what > > > is the distance expectation. Like what I explain in my presentation, > > > we plan to have keystone sitting in the city level to control multi > > > cloud in counties, and the latency will be around 5ms. But again > > > this is a certain situation for China Mobile. And other operators > > > may make the conlusion on a different structure. Another thing we > > > can do is work on simulation and testing and see what kind of > > > latency the current keystone federation scheme can tolerant. This > > > will help the operators to work out there structure as well. > > > > > > About bandwidth, the impression for me is we could expect more than > > > 50GB of bandwidth for edge for 5G. And I think that is enough for > > > most of the app. > > > > > > Hope this will help. > > > > > > -----邮件原件----- > > > 发件人: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] > > > 发送时间: 2018年6月6日 15:25 > > > 收件人: edge-computing at lists.openstack.org > > > 主题: Re: [Edge-computing] Clarification of Requirements > > > > > > It is rather difficult to give numbers because there are several > > > use-cases. > > > However, a good starting point can be to give a look to the > > > presentation Qiao Fu gave during the Vancouver summit: > > > https://www.openstack.org/videos/vancouver-2018/edge-tic-future-edge > > > -cloud-for-china-mobile There is a lot of numbers regarding the > > > infrastructure China Mobile is envisioning. > > > > > > Hope this helps. > > > ad_ri3n_ > > > PS: I cannot attend the meeting yesterday unfortunately but I'm > > > wondering whether the disconnection aspects have been discussed > > > (i.e. the fact that one site can be completely isolated for a > > > certain period of time due to network disconnections). > > > > > > ----- Mail original ----- > > > > De: "Jess Lampe" > > > > À: edge-computing at lists.openstack.org > > > > Envoyé: Mercredi 6 Juin 2018 07:00:31 > > > > Objet: [Edge-computing] Clarification of Requirements > > > > > > > > > > > > > > > > > > > > During the call today, members of the Glance and Keystone teams > > > > requested clarity on the following areas: > > > > > > > > > > > > > > > > * Latency - what are the specific latency requirements that need > > > > to be met? > > > > * Bandwidth towards the edge - similarly, what are the limitations > > > > of bandwidth at the edge that we can expect? > > > > * Security - what are the specific security considerations that > > > > need to be? > > > > > > > > > > > > Please feel free to A.) contribute additional areas that need > > > > clarifying B.) clarify any of the added. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > _______________________________________________ > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuqiao at chinamobile.com Tue Jul 10 04:11:51 2018 From: fuqiao at chinamobile.com (fuqiao at chinamobile.com) Date: Tue, 10 Jul 2018 12:11:51 +0800 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion=5Fof=5FRequirements?= References: <201806201003064375530@chinamobile.com>, <00aa01d4083c$129c7350$37d559f0$@chinamobile.com>, , <010e01d40874$fcb3d720$f61b8560$@chinamobile.com>, , <012001d40879$20bab900$62302b00$@chinamobile.com>, , <7b2e5862b8e84260984b2983d286c8e7@kontron.com>, , <22b0f0f372f14815bdf57cc0aedfd9eb@kontron.com>, , <004801d41333$396ea780$ac4bf680$@chinamobile.com>, , , <201807090911276700446@chinamobile.com>, , <2018071008454045049832@chinamobile.com>, Message-ID: <2018071010071081338047@chinamobile.com> Thank you! I will ask my colleage Qihui and Yamei to join the discussion fuqiao at chinamobile.com 发件人： Claire Massey 发送时间： 2018-07-10 08:53 收件人： fuqiao at chinamobile.com 抄送： gergely.csatari; Ildiko Vancsa; edge-computing; paul-andre.raymond 主题： Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements It’s at 1400 UTC (7:00am PDT). On Jul 9, 2018, at 7:46 PM, "fuqiao at chinamobile.com" wrote: When is the Tuesday meeting? my outlook was down and I lost all the invitation details... fuqiao at chinamobile.com 发件人： Csatari, Gergely (Nokia - HU/Budapest) 发送时间： 2018-07-09 17:09 收件人： fuqiao at chinamobile.com; Ildiko Vancsa 抄送： eric.sarault; zhaoqihui; lebre.adrien; edge-computing; paul-andre.raymond 主题： RE: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Let’s discuss on the Tuesdsay meeting. I’ve added this issue to the agenda. Br, Gerg0 From: fuqiao at chinamobile.com [mailto:fuqiao at chinamobile.com] Sent: Monday, July 9, 2018 3:11 AM To: Csatari, Gergely (Nokia - HU/Budapest) ; Ildiko Vancsa Cc: eric.sarault ; zhaoqihui ; lebre.adrien ; edge-computing ; paul-andre.raymond Subject: Re: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Gergely. I am totally agree that we should merge these into one set of discription. This will be much easier for us to understand the scenario and also conduct the upcomming code and test case development. what is the next step you suggest? I guess we could have a joint meeting to discuss each and every detail, or we could also put it into the OPNFV EC repo so that people can make comments on gerrit? fuqiao at chinamobile.com 发件人： Csatari, Gergely (Nokia - HU/Budapest) 发送时间： 2018-07-05 17:57 收件人： Ildiko Vancsa; Fu Qiao 抄送： Éric Sarault; 赵奇慧; lebre.adrien; edge-computing; paul-andre raymond 主题： RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, Back to the deployment scnearios  Here is a comparision between what is proposed by Qihui Zhao in the OPNFV Edge Computing project [1] and what I've collected in the Dublin notes [2]. Small edge - Distance from base station: - OPNFV EC: less than 10km, closest site to end users/ base station - Dublin: around 10 km - E2E delay: - OPNFV EC: around 2ms - Dublin: 2 ms - Maximum bandwidth can provide - OPNFV EC: 50G - Dublin: 50 GB - Minimum server number - OPNFV EC: 1 - Dublin: 1 unit of 4 cores (two ARM or Xeon-D processors), 8 GB RAM (4 DIMM), 1 * 240 GB SSD (2 * 2.5) - Maximum server number - OPNFV EC: 20 - Dublin: 1 unit of 16 cores, 64 GB RAM, 1 * 1 TB storage - Power for a site: - OPNFV EC: < 10KW - Dublin: N/A - Services might be deployed here: - OPNFV EC: MEC, or other services which have strict requirements on latency. Services deployed in this kind of sites have huge regional deference - Dublin: N/A - Physical access of maintainer: - OPNFV EC: Rare, maintenance staff may only show up in this kind of site when machines initialize for the first time or a machine down - Dublin: Rare - Remote network connection reliability: - OPNFV EC: Not 100% reliable or stable - Dublin: No 100% uptime and variable connectivity expected. - Orchestration: - OPNFV EC: no orchestration component. MANO deployed in core site provide remote orchestration - Dublin: N/A - Degree of virtualization: - OPNFV EC: t is possible that no virtualization technology would be used in small edge site if virtualization increases structure/network complexity, reduce service performance, or cost more resources. Bare-metal is common in small edge sites. Container would also be a future choice if virtualization was needed - Dublin: N/A - Storage: - OPNFV EC: mainly consider local storage. Distributed storage would be used depending on services’ needs and site conditions. - Dublin: N/A - Physical security: - OPNFV EC: N/A - Dublin: none - Expected frequency of updates to hardware: - OPNFV EC: N/A - Dublin: 3-4 year refresh cycle - Expected frequency of updates to firmware: - OPNFV EC: N/A - Dublin: 6-12 months - Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): - OPNFV EC: N/A - Dublin: ~ 12 - 24 months, has to be possible from remote management - Physical size: - OPNFV EC: N/A - Dublin: Not all the sites will have 36 depth capability. Some sites might be limited to 12 depth. - Number of instances (Edge TIC Country / Edge TIC AP according to [6]): - OPNFV EC: N/A - Dublin: depends on demands (3000+) Medium Edge - Distance from base station: - OPNFV EC: 10x km (1 Cc: Csatari, Gergely (Nokia - HU/Budapest) ; Éric Sarault ; 赵奇慧 ; lebre.adrien ; edge-computing ; paul-andre raymond Subject: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements Hi, As a connecting item we are also working on a template to be able to describe use cases on a standard, comparable way: * https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases * https://etherpad.openstack.org/p/feedback_on_template This might be a good starting point for a common vocabulary. It is also a question how much we can come up with buckets that fit the different use cases in terms of the size and characteristics of the edge sites. The next Edge Computing Group call is tomorrow (July 5) at 0700 UTC ( https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings ), we can start to discuss this there with those of you available. We also need to figure out whether we would like to utilize any of the already scheduled meetings in each group or rather organize a new one? Thanks and Best Regards, Ildikó > On 2018. Jul 4., at 3:06, Fu Qiao wrote: > > Agree, I think a joint discussion between the team is necessary, so > that we can make sure to work on a common base > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年7月3日 19:01 > 收件人: Éric Sarault ; Fu Qiao > ; '赵奇慧' ; > 'lebre.adrien' > 抄送: 'edge-computing' ; 'paul-andre > raymond' > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Isn’t this case covered by [1] ? > > On the other hand there is a new set of deployment options listed by OPNFV in [2]. > It would be nice if we could harmonize these somehow… > > > [1]: > https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussion > s_Dublin_PTG#Small_edge > [2]: > https://gerrit.opnfv.org/gerrit/#/c/58959/4/docs/development/requireme > nts/requirements.rst > > Br, > Gerg0 > > > From: Éric Sarault [mailto:Eric.Sarault at kontron.com] > Sent: Tuesday, June 26, 2018 2:50 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > ; Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Yes, in some scenarios, we need to consider CPE units. This could be a consumer endpoint device/appliance that looks like your typical router from your ISV. These are typically ARM based units or you could also see some Intel Xeon-D units there (Atom worst case). The use case behind is to manage tens of thousands of these as an edge federation. At the same scale, think also Industrial IoT or Retail. My point is not everything is a rackmount format so we just need to be clear what the target is here as the form factor might limit the versatility of one or many use cases. > > --- > Eric Sarault, B. Eng. > Software Product Manager > Kontron – An S&T Company > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada > P: +1 (450) 437-5682 x > eric.sarault at kontron.com > > Website | Blog | Twitter | LinkedIn | YouTube | Facebook > > Kontron Canada Inc. > By opening this email you are agreeing to Kontron's Electronic Communications Policy. > > From: Csatari, Gergely (Nokia - HU/Budapest) > > Sent: June 26, 2018 7:09 AM > To: Éric Sarault ; Fu Qiao > ; '赵奇慧' ; > 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > So you mean that the minimum HW spec is smaller thean 1 unit? > > Br, > Gerg0 > > From: Éric Sarault [mailto:Eric.Sarault at kontron.com] > Sent: Wednesday, June 20, 2018 3:14 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > ; Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Is the purpose of limiting the small edge to 1U is to classify it as the CPE use case? We need to keep in mind some CPE/vCPE equipment isn’t even “rackmountable” so we need to keep track of this (i.e: set up box, ISV router). > > --- > Eric Sarault, B. Eng. > Software Product Manager > Kontron – An S&T Company > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada > P: +1 (450) 437-5682 x > eric.sarault at kontron.com > > Website | Blog | Twitter | LinkedIn | YouTube | Facebook > > Kontron Canada Inc. > By opening this email you are agreeing to Kontron's Electronic Communications Policy. > > From: Csatari, Gergely (Nokia - HU/Budapest) > > Sent: June 20, 2018 5:36 AM > To: Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > I am okay with your classification for small, medium and large. > > Br, > Gerg0 > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 11:29 AM > To: Csatari, Gergely (Nokia - HU/Budapest) > ; '赵奇慧' ; > 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, Georgly. I read through the wiki definition for small and medium, and I guess it probably is not that direct to just define a large edge scenario. > I notice that in the medium edge, the size is 2U-20U, which actually > include the large edge as defined in the following email. I am afraid > we probably will need detailed discussion about the size limitation > for each different type, so as to make this whole definition easy to > be accept. A possible proposal could be 1U for small, 2U-20U for > medium, and 20-100U(or even larger) for large. So the small one can > fit for CPE, medium one can fit for access and counties, and large one > can fit for counties and cities > > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年6月20日 17:18 > 收件人: Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > 抄送: 'edge-computing' ; 'paul-andre > raymond' > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Thanks for the info. > > I’m okay to add a large edge deployment scenario. > > What charasterestics should it have? > • Minimum hardware specs: 10 units > • Maximum hardware specs: 20 units > • Physical access of maintainer: > • Physical security: > • Expected frequency of updates to hardware: > • Expected frequency of updates to firmware: > • Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): > • Remote access/connectivity reliability (24/24, periodic, ...): > • Physical size: > • Number of instances (Edge TIC Country / Edge TIC AP according to [6]): > • Distance from Base Station (Access-level DC according to [6]): > • E2E delay (from UE to site) (Access according to [6]): > • Bandwith need (Access according to [6]): > Br, > Gerg0 > > > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 10:59 AM > To: Csatari, Gergely (Nokia - HU/Budapest) > ; '赵奇慧' ; > 'lebre.adrien' > Cc: 'edge-computing' ; 'paul-andre > raymond' > Subject: 答复: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, Gergely. Actually what I am thinking is we probably need more definition for edge scenarios. > I think the definition for small edge and medium edge in the white paper make sense to me, since they basically cover the usecase for customer premises usecases. However, I guess another scenario should also be added which includes 10-20 units. Such scenario is what we say for access and county level. Such unit is not that resource limited as small and medium edge, but we should also consider the resource constrains and make fully use of the limited resource. > As for city level, I understand we can probably use the large edge definition for this, since it could be a quite typical cloud at that level. > Hope this will help. > > 发件人: Csatari, Gergely (Nokia - HU/Budapest) > [mailto:gergely.csatari at nokia.com] > 发送时间: 2018年6月20日 16:49 > 收件人: Fu Qiao ; '赵奇慧' > ; 'lebre.adrien' > 抄送: 'edge-computing' ; 'paul-andre > raymond' > 主题: RE: [Edge-computing] 答复: 答复: Clarification_of_Requirements > > Hi, > > Thanks for the comments. > > I’m not sure at all, that we follow the definitions from the > whitepaper in the wiki  > > I referred your talk and the naming you user there becouse of the differences in the definitions. > > Going inline. > > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > Sent: Wednesday, June 20, 2018 4:12 AM > > Hi, all. I guess some more explanations for the China Mobile’s network should be added here. > The definition for small and medium edge from the whitepaper actually is different from what we say about access/county/city. Our access level CO will include compute nodes of about ten more, with distance from the Base station of 10km, delay about 2ms, and bandwidth about 50GB. > > [G0]: Should I add 10 units to the maximum hardware specs part of the Small edge deployment option? > > Our county level CO includes tens of compute nodes, with distance of 50km, delay about 2.5ms, and bandwidth of about 100GB. City level CO will have hundreds of servers, with distance of more than 100km. > I guess the small edge defined in the Whitepaper, with up to 1U, is somehow suitable for edge equipment at the customer site, and this is not actually discussed in my presentation. > > > 发件人: 赵奇慧 [mailto:zhaoqihui at chinamobile.com] > 发送时间: 2018年6月20日 10:03 > > Hi Gergely, > > It's great that our data can help. But I think according the the previous definitions of small edge and medium edge, there should be a little modification here. > > For Small edge, the maximum hardware specs is up to 1 unit, which is similar to our Access-level DC/Edge TIC AP. For Mediun edge, the hardware spec varies from 2RU to 20RU, which is somehow like our County-level DC. So here is my suggestion: > ---------------------------------------------------------------------- > ----- > Small edge: > · Number of instances (Edge TIC AP according to [6]): depend on demands > [G0]: Can we say 3000+ here in a paranthesis? > · Distance from Base Station (Access-level DC according to [6]): around 10km > · E2E delay (from UE to site)(Access according to [6]): 2 ms > · Bandwith need (Access according to [6]): 50 GB > > Medium edge: > · Number of instances (Edge TIC County according to [6]): 3000+ > · Distance from Base Station (Access-level DC according to [6]): around 50km > · E2E delay (from UE to site) (Access according to [6]): less than 2.5 ms > · Bandwith need (Access according to [6]): 100GB > ---------------------------------------------------------------------- > ------ > > [G0]: I’ve updated these to the wiki. > > Thanks, > Gerg0 > > > Best Regards, > Qihui Zhao > China Mobile Research Institute > > Department of Network Technology > >> >> 发件人: Csatari, Gergely (Nokia - HU/Budapest) >> 时间: 2018/06/15(星期五)22:14 >> 收件人: lebre.adrien; >> 抄送人: paul-andre raymond;edge-computing; >> 主题: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements > Hi, > > I was thinking about the generic deployment specific requirements, like bandwiths and delays. > > I've added some of them from the CM presentation to > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG# > Small_edge and > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG# > Medium_edge > > Br, > Gerg0 > > -----Original Message----- > From: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] > Sent: Thursday, June 14, 2018 11:39 PM > To: Csatari, Gergely (Nokia - HU/Budapest) > Cc: Arkady Kanevsky ; > fuqiao at chinamobile.com; paul-andre raymond > ; edge-computing at lists.openstack.org > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements > > Hi all, > > Maybe we can try to prioritise the projects we want to investigate and > then for each of them identify what are the missing > elements/capabilities (one after the others) > > There are ongoing works on Keystone and Glance. > Nova, Neutron could be the next ones because these 4 services would allow to deploy VM at the edge (and so containers inside VMs). > Cinder will enable the use of remote attached volumes. > Ironic can be useful later. > etc.. > > My two cents, > Ad_ri3n_ > > ----- Mail original ----- > > De: "Gergely Csatari (Nokia - HU/Budapest)" > > > > À: "Arkady Kanevsky" , fuqiao at chinamobile.com, "paul-andre raymond" > > , "lebre adrien" > > , edge-computing at lists.openstack.org > > Envoyé: Mercredi 13 Juin 2018 17:38:35 > > Objet: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Hi, > > > > Somehow I have a feeling that these latency requirements are related > > to all projects, this is why they should be documented in the > > Deployment options section. > > > > Br, > > Gerg0 > > > > -----Original Message----- > > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > > Sent: Wednesday, June 13, 2018 4:24 PM > > To: Csatari, Gergely (Nokia - HU/Budapest) > > ; fuqiao at chinamobile.com; > > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Gerg0, > > I think these 3 projects are implied from the wiki requirements. > > But it will be good to state projects that may need work explicitly. > > Thanks, > > Arkady > > > > -----Original Message----- > > From: Csatari, Gergely (Nokia - HU/Budapest) > > [mailto:gergely.csatari at nokia.com] > > Sent: Wednesday, June 13, 2018 4:23 AM > > To: Kanevsky, Arkady; fuqiao at chinamobile.com; > > paul-andre.raymond at b-yond.com; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: RE: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Hi, > > > > Should we add these to the Deployment Scenarions section of the > > Dublin wiki [1]? > > > > [1]: > > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PT > > G# > > Deployment_Scenarios > > > > Br, > > Gerg0 > > > > -----Original Message----- > > From: Arkady.Kanevsky at dell.com [mailto:Arkady.Kanevsky at dell.com] > > Sent: Wednesday, June 6, 2018 4:49 PM > > To: fuqiao at chinamobile.com; paul-andre.raymond at b-yond.com; > > lebre.adrien at free.fr; edge-computing at lists.openstack.org > > Subject: Re: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > It is more than just nova to keystone. > > We also need to consider at least neutron, glance and cinder also. > > > > -----Original Message----- > > From: Fu Qiao [mailto:fuqiao at chinamobile.com] > > Sent: Wednesday, June 6, 2018 8:21 AM > > To: 'Paul-Andre Raymond'; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > Subject: [Edge-computing] 答复: 答复: Clarification of Requirements > > > > Yes, 5ms is one way. But this is an assumption based on the network > > from China Mobile. The latency will be defer if you have different > > distance, but the calculation method is the same apparently. > > > > -----邮件原件----- > > 发件人: Paul-Andre Raymond [mailto:paul-andre.raymond at b-yond.com] > > 发送时间: 2018年6月6日 21:19 > > 收件人: Fu Qiao ; lebre.adrien at free.fr; > > edge-computing at lists.openstack.org > > 主题: Re: [Edge-computing] 答复: Clarification of Requirements > > > > Should we separate two kinds of latency requirements: > > - Federation Latency: i.e Central Keystone to Local Keystone > > - API latency: i.e. Edge Nova to local Keystone > > > > Should we measure it one way or Round Trip? I assume the 5ms below > > is one way. > > > > > > Paul-André > > -- > > > > > > On 6/6/18, 5:13 AM, "Fu Qiao" wrote: > > > > Thank you Adrien. I was just about the reply with more details. > > > > About latency, this as I understand is actually decided mostly by > > the distance of the distributed cloud. So it actually decided by > > where exactly the location Keystone would like to deploy, and what > > is the distance expectation. Like what I explain in my presentation, > > we plan to have keystone sitting in the city level to control multi > > cloud in counties, and the latency will be around 5ms. But again > > this is a certain situation for China Mobile. And other operators > > may make the conlusion on a different structure. Another thing we > > can do is work on simulation and testing and see what kind of > > latency the current keystone federation scheme can tolerant. This > > will help the operators to work out there structure as well. > > > > About bandwidth, the impression for me is we could expect more than > > 50GB of bandwidth for edge for 5G. And I think that is enough for > > most of the app. > > > > Hope this will help. > > > > -----邮件原件----- > > 发件人: lebre.adrien at free.fr [mailto:lebre.adrien at free.fr] > > 发送时间: 2018年6月6日 15:25 > > 收件人: edge-computing at lists.openstack.org > > 主题: Re: [Edge-computing] Clarification of Requirements > > > > It is rather difficult to give numbers because there are several > > use-cases. > > However, a good starting point can be to give a look to the > > presentation Qiao Fu gave during the Vancouver summit: > > https://www.openstack.org/videos/vancouver-2018/edge-tic-future-edge > > -cloud-for-china-mobile There is a lot of numbers regarding the > > infrastructure China Mobile is envisioning. > > > > Hope this helps. > > ad_ri3n_ > > PS: I cannot attend the meeting yesterday unfortunately but I'm > > wondering whether the disconnection aspects have been discussed > > (i.e. the fact that one site can be completely isolated for a > > certain period of time due to network disconnections). > > > > ----- Mail original ----- > > > De: "Jess Lampe" > > > À: edge-computing at lists.openstack.org > > > Envoyé: Mercredi 6 Juin 2018 07:00:31 > > > Objet: [Edge-computing] Clarification of Requirements > > > > > > > > > > > > > > > During the call today, members of the Glance and Keystone teams > > > requested clarity on the following areas: > > > > > > > > > > > > * Latency - what are the specific latency requirements that need > > > to be met? > > > * Bandwidth towards the edge - similarly, what are the limitations > > > of bandwidth at the edge that we can expect? > > > * Security - what are the specific security considerations that > > > need to be? > > > > > > > > > Please feel free to A.) contribute additional areas that need > > > clarifying B.) clarify any of the added. > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Greg.Waines at windriver.com Tue Jul 10 10:59:44 2018 From: Greg.Waines at windriver.com (Waines, Greg) Date: Tue, 10 Jul 2018 10:59:44 +0000 Subject: [Edge-computing] Keystone Edge Architectures In-Reply-To: <9e29b7ef-7a60-570d-89ed-d56e8031db69@gmail.com> References: <678C1A99-2302-438D-8D5D-91ED44B10FF9@windriver.com> <2e2495d6-531f-c0a4-27d6-3c15da111289@gmail.com> <8CB60A46-2C68-444F-994C-45D88FE77D74@windriver.com> <28270e37-13b5-2baa-6952-b084f81e3887@gmail.com> <9e29b7ef-7a60-570d-89ed-d56e8031db69@gmail.com> Message-ID: <6D9D26AE-53E1-40B9-B472-ADB743C5A15E@windriver.com> For the API-based Synchronization approach, - the users could live locally in SQL, and - the idea would be to have a centralized API Synchronization Framework that would automatically synchronize User’s UUID, name and password across all edge deployments. ( ... provided that UUID could be specified on the POST of the USER ...) o ... which would indirectly result in revocation events being generated on the edge clouds But agree that your comment on PCI-DSS features, is yet another example of side-affect changes in the keystone DB ... which, in this case, would not get indirectly replicated thru an API-based Synchronization Framework. Thanks for your input, Greg. On 2018-07-09, 3:25 PM, "Lance Bragstad" wrote: On 07/03/2018 07:01 AM, Waines, Greg wrote: Hey Lance, Just following up again on the info below you provided on previous discussions on issues with API-based Synchronization of Keystone between clouds. In your example below, wouldn’t the API-based Synchronization of the user password change @ A (assuming A is the central site), result in the user password change @ B “and” the corresponding revocation event being created @ B ? I guess I need a little more information in order to answer the question. Do users live in SQL or are they centrally located somewhere else? If they live in SQL, does that mean you're replicating users manually to have the same ID, name, and password across every edge deployment? If so, then you'd be able to manually create revocation events by changing the user's password at every edge deployment. So if you have 100 deployments, you'll have to change a user's password in 100 places in order to get around the issue I described in the previous note. This leads me to another question. If users are in SQL, are you planning on relying on any PCI-DSS features [0]? If so, this might be another attack surface to consider since: - an attacker could attempt to brute force a password in deployment A - the attacker is locked out due to hitting maximum failed authentication attempts - the attacker attempts to brute force the same account in deployment B (which doesn't know the same user just tried authenticating and failed X times in deployment A) [0] https://docs.openstack.org/keystone/latest/admin/identity-security-compliance.html Greg. < SNIP > The concept of replicating data over the API was also brought up towards the end of the call as a possible solution. The TL;DR is that each deployment would be independent, but data would be kept in sync by making API requests that forcibly create entities with the same IDs (manual replication if you will). This idea has been discussed at length over the last couple years [0]. We most recently discussed it during the summit in Sydney. Where we really tripped was replication of revocation events. For example, assume you have the ability in keystone to forcibly create things with specific IDs, allowing you to manually replicate data across your edge deployments. At the same time you're keeping the fernet keys in sync, so a user can actually generate tokens in one deployment and use them in other (since each keystone node has the same IDs for projects, domains, users, etc..), even though replication isn't happening at the database. Revocation events are records used internally by keystone to track events that affect token validity (e.g. a user changing their password or deleting a specific token), and they are not exposed via keystone's API. The concern is that without replicating this table, it would be possible for a user to: - generate a token in deployment A - use the token in deployment B to do something - change their password in deployment A, which creates a revocation event invalidating the token from step one in deployment A - the user attempts to use the token from step one in deployment A but it is considered invalid (due to the revocation event) - the user successfully executes API calls with the token from step one in deployment B because deployment B has no knowledge of the revocation event in deployment A We didn't get into that much detail in the call, but wanted to share where the conversation ended up the last time we had it. [0] https://review.openstack.org/#/c/323499/ < SNIP > From jess.lampe at gmail.com Tue Jul 10 13:21:59 2018 From: jess.lampe at gmail.com (Jess Lampe) Date: Tue, 10 Jul 2018 06:21:59 -0700 Subject: [Edge-computing] Use Case Help Message-ID: *Are you willing to write up a use case?* In order to complete the use cases by the end of July, we are looking for help drafting several use cases. The template for the use case can be found here: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Use_cases_template The list of unclaimed use cases can be found here: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Additional_Use_Cases If you are interested in writing, please copy the use case template under the Use Cases section and add your name after "Author". Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Tue Jul 10 15:03:19 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Tue, 10 Jul 2018 15:03:19 +0000 Subject: [Edge-computing] Invitation: Weekly Edge Computing Group Call (14:00 UTC) @ Weekly from 9am to 10am on Tuesday from Tue Jun 5 to Tue Sep 4 (CDT) (edge-computing@lists.openstack.org) In-Reply-To: References: Message-ID: Hi, Notes of the meeting: http://eavesdrop.openstack.org/meetings/weekly_edge_computing_group_call/2018/weekly_edge_computing_group_call.2018-07-10-14.03.html Br, Gerg0 -----Original Appointment----- From: claire at openstack.org [mailto:claire at openstack.org] Sent: Tuesday, May 29, 2018 3:30 PM To: claire at openstack.org; Ildiko Vancsa; edge-computing at lists.openstack.org; Jonathan Bryce Subject: [Edge-computing] Invitation: Weekly Edge Computing Group Call (14:00 UTC) @ Weekly from 9am to 10am on Tuesday from Tue Jun 5 to Tue Sep 4 (CDT) (edge-computing at lists.openstack.org) When: kedd 2018. július 10 9:00-10:00 America/Chicago. Where: https://zoom.us/j/777719876 more details » Weekly Edge Computing Group Call (14:00 UTC) When Weekly from 9am to 10am on Tuesday from Tue Jun 5 to Tue Sep 4 Central Time Where https://zoom.us/j/777719876 (map) Calendar edge-computing at lists.openstack.org Who • claire at openstack.org - organizer • Ildiko Vancsa • edge-computing at lists.openstack.org • Jonathan Bryce Weekly agenda & call notes: https://wiki.openstack.org/wiki/Edge_Computing_Group Going? All events in this series: Yes - Maybe - No more options » Invitation from Google Calendar You are receiving this courtesy email at the account edge-computing at lists.openstack.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openstack.org Wed Jul 11 19:18:28 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Wed, 11 Jul 2018 14:18:28 -0500 Subject: [Edge-computing] Berlin Summit CFP Closes in a Week Message-ID: <259799DB-4D8F-4F40-BC0A-1B7E78C3EE31@openstack.org> Hi everyone, The CFP deadline for the OpenStack Summit Berlin is less than one week away, so make sure to submit your talks before July 18th at 6:59am UTC (July 17 at 11:59pm PST). Tracks: • CI/CD • Container Infrastructure • Edge Computing • Hands on Workshops • HPC / GPU / AI • Open Source Community • Private & Hybrid Cloud • Public Cloud • Telecom & NFV SUBMIT HERE Community voting, the first step in building the Summit schedule, will open in mid July. Once community voting concludes, a Programming Committee for each Track will build the schedule. Programming Committees are made up of individuals from many different open source communities working in open infrastructure, in addition to people who have participated in the past. Read the full selection process here . Register for the Summit - Early Bird pricing ends August 21 Become a Sponsor Thanks and Best Regards, Ildikó -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openstack.org Wed Jul 11 20:39:42 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Wed, 11 Jul 2018 15:39:42 -0500 Subject: [Edge-computing] Keystone federation testing Message-ID: <3F3C47B1-F37A-4701-882F-A2D0F3AAF109@openstack.org> Hi, Within the Edge Computing Group we have a few people interested in Keystone federation testing starting with general federation and moving to edge specific test cases onwards. In case you are interested in this activity, we are organizing a call for next Thursday to talk about basic testing in OpenStack including identifying tasks and volunteers to complete them. We would like to use the time to clarify questions about Keystone federation capabilities if there’s any. We are also collaborating with the OPNFV Edge Cloud project for advanced test scenarios which we will also discuss on the call. The call details are here: https://wiki.openstack.org/wiki/Edge_Computing_Group#Federation_Testing_Call Please check out the materials on this etherpad prior to the call if you plan to join: https://etherpad.openstack.org/p/ECG_Keystone_Testing Please let me know if you have any questions. Thanks and Best Regards, Ildikó From beth.cohen at verizon.com Wed Jul 11 20:44:58 2018 From: beth.cohen at verizon.com (beth.cohen at verizon.com) Date: Wed, 11 Jul 2018 20:44:58 +0000 Subject: [Edge-computing] OpenStack Summit Berlin CFP Closes July 17 Message-ID: <168ec5d90a144cba92a3fa24a0369d81@scwexch25apd.uswin.ad.vzwcorp.com> Reminder that you have only a few days to get your session proposals in. Hi everyone, The CFP deadline for the OpenStack Summit Berlin is less than one week away, so make sure to submit your talks before July 18 at 6:59am UTC (July 17 at 11:59pm PST). Tracks: • CI/CD • Container Infrastructure • Edge Computing • Hands on Workshops • HPC / GPU / AI • Open Source Community • Private & Hybrid Cloud • Public Cloud • Telecom & NFV SUBMIT HERE There are some suggested Tweets at the bottom of this etherpad if you’d like to promote within your communities. Community voting, the first step in building the Summit schedule, will open in mid July. Once community voting concludes, a Programming Committee for each Track will build the schedule. Programming Committees are made up of individuals from many different open source communities working in open infrastructure, in addition to people who have participated in the past. Read the full selection process here. Register for the Summit - Early Bird pricing ends August 21 Become a Sponsor Cheers, Ashlee Ashlee Ferguson OpenStack Foundation ashlee at openstack.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Thu Jul 12 14:00:02 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Thu, 12 Jul 2018 14:00:02 +0000 Subject: [Edge-computing] Merging deployment scenarios to the OPNFV Edge Computing requirement document Message-ID: Hi, Here is the change what merges the deployment scenarios from the Dublin edge notes to the OPNFV Edge Computing requirements document: https://gerrit.opnfv.org/gerrit/#/c/59763/ Whenever it is merged I will only refer to this and delete the definitions form the Dublin edge notes wiki. Please check and comment. Br, Gerg0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Randy.Perryman at dell.com Thu Jul 12 18:21:00 2018 From: Randy.Perryman at dell.com (Randy.Perryman at dell.com) Date: Thu, 12 Jul 2018 18:21:00 +0000 Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Message-ID: Would a panel discussion on the following be worthwhile: Containers vs Virtual Machines on the Edge - What do you build your Cluster too? If there is interest, I would be willing to moderate, just need 3 to 5 people for the panel. Randy Perryman Technical Staff, Cloud Architect Dell EMC | OpenSource Solutions Group office + 01 603 249 7710 mobile +01 603 321 5611 [dell_logo][cos] Please consider the environment before printing this email. Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 843 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 612 bytes Desc: image002.png URL: From Eric.Sarault at kontron.com Thu Jul 12 18:25:45 2018 From: Eric.Sarault at kontron.com (=?iso-8859-1?Q?=C9ric_Sarault?=) Date: Thu, 12 Jul 2018 18:25:45 +0000 Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion In-Reply-To: References: Message-ID: <2d753e56ea6f449dac10a252e98d3c6a@kontron.com> We'd be willin to participate to that panel. --- Eric Sarault, B. Eng. Software Product Manager Kontron - An S&T Company 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada P: +1 (450) 437-4661 x2217 eric.sarault at kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Canada Inc. By opening this email you are agreeing to Kontron's Electronic Communications Policy. From: Randy.Perryman at dell.com Sent: July 12, 2018 2:21 PM To: edge-computing at lists.openstack.org Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Would a panel discussion on the following be worthwhile: Containers vs Virtual Machines on the Edge - What do you build your Cluster too? If there is interest, I would be willing to moderate, just need 3 to 5 people for the panel. Randy Perryman Technical Staff, Cloud Architect Dell EMC | OpenSource Solutions Group office + 01 603 249 7710 mobile +01 603 321 5611 [dell_logo][cos] Please consider the environment before printing this email. Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 843 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 612 bytes Desc: image002.png URL: From yong.hu at intel.com Thu Jul 12 18:34:04 2018 From: yong.hu at intel.com (Hu, Yong) Date: Thu, 12 Jul 2018 18:34:04 +0000 Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Message-ID: <94D304DB-0054-4114-A7B1-694BE3A27576@intel.com> +1 for this panel! Would it be possible in advance we form a specific agenda for this topic (Containers vs Virtual Machines on the Edge)? Regards, Yong From: Éric Sarault Date: Thursday, 12 July 2018 at 11:26 AM To: "Randy.Perryman at dell.com" , "edge-computing at lists.openstack.org" Subject: Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion We’d be willin to participate to that panel. --- Eric Sarault, B. Eng. Software Product Manager Kontron – An S&T Company 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada P: +1 (450) 437-4661 x2217 eric.sarault at kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Canada Inc. By opening this email you are agreeing to Kontron's Electronic Communications Policy. From: Randy.Perryman at dell.com Sent: July 12, 2018 2:21 PM To: edge-computing at lists.openstack.org Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Would a panel discussion on the following be worthwhile: Containers vs Virtual Machines on the Edge – What do you build your Cluster too? If there is interest, I would be willing to moderate, just need 3 to 5 people for the panel. Randy Perryman Technical Staff, Cloud Architect Dell EMC | OpenSource Solutions Group office + 01 603 249 7710 mobile +01 603 321 5611 [dell_logo][cos] Please consider the environment before printing this email. Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 844 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 613 bytes Desc: image002.png URL: From Eric.Sarault at kontron.com Thu Jul 12 18:40:59 2018 From: Eric.Sarault at kontron.com (=?utf-8?B?w4lyaWMgU2FyYXVsdA==?=) Date: Thu, 12 Jul 2018 18:40:59 +0000 Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion In-Reply-To: <94D304DB-0054-4114-A7B1-694BE3A27576@intel.com> References: <94D304DB-0054-4114-A7B1-694BE3A27576@intel.com> Message-ID: <15461f1f729e4763a1c54eb59434e2d2@kontron.com> It would be great so this way we could have some sort of minimal prep prior to the panel instead of “winging it” on stage. --- Eric Sarault, B. Eng. Software Product Manager Kontron – An S&T Company 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada P: +1 (450) 437-4661 x2217 eric.sarault at kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Canada Inc. By opening this email you are agreeing to Kontron's Electronic Communications Policy. From: Hu, Yong Sent: July 12, 2018 2:34 PM To: Éric Sarault ; Randy.Perryman at dell.com; edge-computing at lists.openstack.org Subject: Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion +1 for this panel! Would it be possible in advance we form a specific agenda for this topic (Containers vs Virtual Machines on the Edge)? Regards, Yong From: Éric Sarault > Date: Thursday, 12 July 2018 at 11:26 AM To: "Randy.Perryman at dell.com" >, "edge-computing at lists.openstack.org" > Subject: Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion We’d be willin to participate to that panel. --- Eric Sarault, B. Eng. Software Product Manager Kontron – An S&T Company 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada P: +1 (450) 437-4661 x2217 eric.sarault at kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Canada Inc. By opening this email you are agreeing to Kontron's Electronic Communications Policy. From: Randy.Perryman at dell.com > Sent: July 12, 2018 2:21 PM To: edge-computing at lists.openstack.org Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Would a panel discussion on the following be worthwhile: Containers vs Virtual Machines on the Edge – What do you build your Cluster too? If there is interest, I would be willing to moderate, just need 3 to 5 people for the panel. Randy Perryman Technical Staff, Cloud Architect Dell EMC | OpenSource Solutions Group office + 01 603 249 7710 mobile +01 603 321 5611 [dell_logo][cos] Please consider the environment before printing this email. Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 844 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 613 bytes Desc: image002.png URL: From beth.cohen at verizon.com Thu Jul 12 18:42:33 2018 From: beth.cohen at verizon.com (beth.cohen at verizon.com) Date: Thu, 12 Jul 2018 18:42:33 +0000 Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion In-Reply-To: <94D304DB-0054-4114-A7B1-694BE3A27576@intel.com> References: <94D304DB-0054-4114-A7B1-694BE3A27576@intel.com> Message-ID: Folks – I would go ahead and write up the proposal – which would include an agenda anyway – then you can prep for the panel once it has been accepted. [Verizon] Beth Cohen DMTS- NFV/SDN Network Product Strategy Verizon Technology O +781-466-2055 | M +781-434-8553 beth.cohen at verizon.com [Twitter] [Instagram] From: Hu, Yong [mailto:yong.hu at intel.com] Sent: Thursday, July 12, 2018 2:34 PM To: Éric Sarault ; Randy.Perryman at dell.com; edge-computing at lists.openstack.org Subject: [E] Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion +1 for this panel! Would it be possible in advance we form a specific agenda for this topic (Containers vs Virtual Machines on the Edge)? Regards, Yong From: Éric Sarault > Date: Thursday, 12 July 2018 at 11:26 AM To: "Randy.Perryman at dell.com" >, "edge-computing at lists.openstack.org" > Subject: Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion We’d be willin to participate to that panel. --- Eric Sarault, B. Eng. Software Product Manager Kontron – An S&T Company 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada P: +1 (450) 437-4661 x2217 eric.sarault at kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Canada Inc. By opening this email you are agreeing to Kontron's Electronic Communications Policy. From: Randy.Perryman at dell.com > Sent: July 12, 2018 2:21 PM To: edge-computing at lists.openstack.org Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Would a panel discussion on the following be worthwhile: Containers vs Virtual Machines on the Edge – What do you build your Cluster too? If there is interest, I would be willing to moderate, just need 3 to 5 people for the panel. Randy Perryman Technical Staff, Cloud Architect Dell EMC | OpenSource Solutions Group office + 01 603 249 7710 mobile +01 603 321 5611 [dell_logo][cos] Please consider the environment before printing this email. Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 844 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 613 bytes Desc: image002.png URL: From Randy.Perryman at dell.com Thu Jul 12 18:47:17 2018 From: Randy.Perryman at dell.com (Randy.Perryman at dell.com) Date: Thu, 12 Jul 2018 18:47:17 +0000 Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion In-Reply-To: References: <94D304DB-0054-4114-A7B1-694BE3A27576@intel.com> Message-ID: <23137fc8e1184cba97f99753923fbece@ausx13mpc118.AMER.DELL.COM> Agreed. I will start this in the morning Eastern Time. Eric and Yong will you both be interested in being on the Panel? Randy Perryman Technical Staff, Cloud Architect Dell EMC | OpenSource Solutions Group office + 01 603 249 7710 mobile +01 603 321 5611 [dell_logo][cos] Please consider the environment before printing this email. Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message. From: beth.cohen at verizon.com [mailto:beth.cohen at verizon.com] Sent: Thursday, July 12, 2018 2:43 PM To: Hu, Yong; Éric Sarault; Perryman, Randy; edge-computing at lists.openstack.org Subject: RE: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Folks – I would go ahead and write up the proposal – which would include an agenda anyway – then you can prep for the panel once it has been accepted. [Verizon] Beth Cohen DMTS- NFV/SDN Network Product Strategy Verizon Technology O +781-466-2055 | M +781-434-8553 beth.cohen at verizon.com [Twitter] [Instagram] From: Hu, Yong [mailto:yong.hu at intel.com] Sent: Thursday, July 12, 2018 2:34 PM To: Éric Sarault >; Randy.Perryman at dell.com; edge-computing at lists.openstack.org Subject: [E] Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion +1 for this panel! Would it be possible in advance we form a specific agenda for this topic (Containers vs Virtual Machines on the Edge)? Regards, Yong From: Éric Sarault > Date: Thursday, 12 July 2018 at 11:26 AM To: "Randy.Perryman at dell.com" >, "edge-computing at lists.openstack.org" > Subject: Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion We’d be willin to participate to that panel. --- Eric Sarault, B. Eng. Software Product Manager Kontron – An S&T Company 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada P: +1 (450) 437-4661 x2217 eric.sarault at kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Canada Inc. By opening this email you are agreeing to Kontron's Electronic Communications Policy. From: Randy.Perryman at dell.com > Sent: July 12, 2018 2:21 PM To: edge-computing at lists.openstack.org Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Would a panel discussion on the following be worthwhile: Containers vs Virtual Machines on the Edge – What do you build your Cluster too? If there is interest, I would be willing to moderate, just need 3 to 5 people for the panel. Randy Perryman Technical Staff, Cloud Architect Dell EMC | OpenSource Solutions Group office + 01 603 249 7710 mobile +01 603 321 5611 [dell_logo][cos] Please consider the environment before printing this email. Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 843 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 612 bytes Desc: image004.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 844 bytes Desc: image005.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 613 bytes Desc: image006.png URL: From Eric.Sarault at kontron.com Thu Jul 12 18:55:34 2018 From: Eric.Sarault at kontron.com (=?utf-8?B?w4lyaWMgU2FyYXVsdA==?=) Date: Thu, 12 Jul 2018 18:55:34 +0000 Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion In-Reply-To: <23137fc8e1184cba97f99753923fbece@ausx13mpc118.AMER.DELL.COM> References: <94D304DB-0054-4114-A7B1-694BE3A27576@intel.com> <23137fc8e1184cba97f99753923fbece@ausx13mpc118.AMER.DELL.COM> Message-ID: <6bf33dfce69e4d2eb4a2f843766f8a1a@kontron.com> Definitely. I can help with the proposal if you need a hand. --- Eric Sarault, B. Eng. Software Product Manager Kontron – An S&T Company 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada P: +1 (450) 437-4661 x2217 eric.sarault at kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Canada Inc. By opening this email you are agreeing to Kontron's Electronic Communications Policy. From: Randy.Perryman at dell.com Sent: July 12, 2018 2:47 PM To: beth.cohen at verizon.com; yong.hu at intel.com; Éric Sarault ; edge-computing at lists.openstack.org Subject: RE: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Agreed. I will start this in the morning Eastern Time. Eric and Yong will you both be interested in being on the Panel? Randy Perryman Technical Staff, Cloud Architect Dell EMC | OpenSource Solutions Group office + 01 603 249 7710 mobile +01 603 321 5611 [dell_logo][cos] Please consider the environment before printing this email. Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message. From: beth.cohen at verizon.com [mailto:beth.cohen at verizon.com] Sent: Thursday, July 12, 2018 2:43 PM To: Hu, Yong; Éric Sarault; Perryman, Randy; edge-computing at lists.openstack.org Subject: RE: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Folks – I would go ahead and write up the proposal – which would include an agenda anyway – then you can prep for the panel once it has been accepted. [Verizon] Beth Cohen DMTS- NFV/SDN Network Product Strategy Verizon Technology O +781-466-2055 | M +781-434-8553 beth.cohen at verizon.com [Twitter] [Instagram] From: Hu, Yong [mailto:yong.hu at intel.com] Sent: Thursday, July 12, 2018 2:34 PM To: Éric Sarault >; Randy.Perryman at dell.com; edge-computing at lists.openstack.org Subject: [E] Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion +1 for this panel! Would it be possible in advance we form a specific agenda for this topic (Containers vs Virtual Machines on the Edge)? Regards, Yong From: Éric Sarault > Date: Thursday, 12 July 2018 at 11:26 AM To: "Randy.Perryman at dell.com" >, "edge-computing at lists.openstack.org" > Subject: Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion We’d be willin to participate to that panel. --- Eric Sarault, B. Eng. Software Product Manager Kontron – An S&T Company 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada P: +1 (450) 437-4661 x2217 eric.sarault at kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Canada Inc. By opening this email you are agreeing to Kontron's Electronic Communications Policy. From: Randy.Perryman at dell.com > Sent: July 12, 2018 2:21 PM To: edge-computing at lists.openstack.org Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Would a panel discussion on the following be worthwhile: Containers vs Virtual Machines on the Edge – What do you build your Cluster too? If there is interest, I would be willing to moderate, just need 3 to 5 people for the panel. Randy Perryman Technical Staff, Cloud Architect Dell EMC | OpenSource Solutions Group office + 01 603 249 7710 mobile +01 603 321 5611 [dell_logo][cos] Please consider the environment before printing this email. Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 843 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 612 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 844 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 613 bytes Desc: image004.png URL: From kailun.qin at intel.com Fri Jul 13 00:13:17 2018 From: kailun.qin at intel.com (Qin, Kailun) Date: Fri, 13 Jul 2018 00:13:17 +0000 Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion In-Reply-To: <6bf33dfce69e4d2eb4a2f843766f8a1a@kontron.com> References: <94D304DB-0054-4114-A7B1-694BE3A27576@intel.com> <23137fc8e1184cba97f99753923fbece@ausx13mpc118.AMER.DELL.COM> <6bf33dfce69e4d2eb4a2f843766f8a1a@kontron.com> Message-ID: Great topic! I’d also be interested in being on the panel. Please kindly count me in if any help or input needed. BR, Kailun From: Éric Sarault [mailto:Eric.Sarault at kontron.com] Sent: Friday, July 13, 2018 2:56 AM To: Randy.Perryman at dell.com; beth.cohen at verizon.com; Hu, Yong ; edge-computing at lists.openstack.org Subject: Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Definitely. I can help with the proposal if you need a hand. --- Eric Sarault, B. Eng. Software Product Manager Kontron – An S&T Company 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada P: +1 (450) 437-4661 x2217 eric.sarault at kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Canada Inc. By opening this email you are agreeing to Kontron's Electronic Communications Policy. From: Randy.Perryman at dell.com Sent: July 12, 2018 2:47 PM To: beth.cohen at verizon.com; yong.hu at intel.com; Éric Sarault ; edge-computing at lists.openstack.org Subject: RE: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Agreed. I will start this in the morning Eastern Time. Eric and Yong will you both be interested in being on the Panel? Randy Perryman Technical Staff, Cloud Architect Dell EMC | OpenSource Solutions Group office + 01 603 249 7710 mobile +01 603 321 5611 [dell_logo][cos] Please consider the environment before printing this email. Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message. From: beth.cohen at verizon.com [mailto:beth.cohen at verizon.com] Sent: Thursday, July 12, 2018 2:43 PM To: Hu, Yong; Éric Sarault; Perryman, Randy; edge-computing at lists.openstack.org Subject: RE: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Folks – I would go ahead and write up the proposal – which would include an agenda anyway – then you can prep for the panel once it has been accepted. [Image removed by sender. Verizon] Beth Cohen DMTS- NFV/SDN Network Product Strategy Verizon Technology O +781-466-2055 | M +781-434-8553 beth.cohen at verizon.com [Image removed by sender. Twitter] [Image removed by sender. Instagram] From: Hu, Yong [mailto:yong.hu at intel.com] Sent: Thursday, July 12, 2018 2:34 PM To: Éric Sarault >; Randy.Perryman at dell.com; edge-computing at lists.openstack.org Subject: [E] Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion +1 for this panel! Would it be possible in advance we form a specific agenda for this topic (Containers vs Virtual Machines on the Edge)? Regards, Yong From: Éric Sarault > Date: Thursday, 12 July 2018 at 11:26 AM To: "Randy.Perryman at dell.com" >, "edge-computing at lists.openstack.org" > Subject: Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion We’d be willin to participate to that panel. --- Eric Sarault, B. Eng. Software Product Manager Kontron – An S&T Company 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada P: +1 (450) 437-4661 x2217 eric.sarault at kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Canada Inc. By opening this email you are agreeing to Kontron's Electronic Communications Policy. From: Randy.Perryman at dell.com > Sent: July 12, 2018 2:21 PM To: edge-computing at lists.openstack.org Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Would a panel discussion on the following be worthwhile: Containers vs Virtual Machines on the Edge – What do you build your Cluster too? If there is interest, I would be willing to moderate, just need 3 to 5 people for the panel. Randy Perryman Technical Staff, Cloud Architect Dell EMC | OpenSource Solutions Group office + 01 603 249 7710 mobile +01 603 321 5611 [dell_logo][cos] Please consider the environment before printing this email. Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 843 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 612 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 377 bytes Desc: image005.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.jpg Type: image/jpeg Size: 336 bytes Desc: image006.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.jpg Type: image/jpeg Size: 338 bytes Desc: image007.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.jpg Type: image/jpeg Size: 338 bytes Desc: image008.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image009.png Type: image/png Size: 844 bytes Desc: image009.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image010.png Type: image/png Size: 613 bytes Desc: image010.png URL: From fuqiao at chinamobile.com Fri Jul 13 01:21:02 2018 From: fuqiao at chinamobile.com (fuqiao at chinamobile.com) Date: Fri, 13 Jul 2018 09:21:02 +0800 Subject: [Edge-computing] Merging deployment scenarios to the OPNFV Edge Computing requirement document References: Message-ID: <201807130921023896774@chinamobile.com> Hi, Gergely. Thank you! I will review the patch. I also cc the opnfv list, see if anyone from the edge team has more comments. I will also note this patch in the next edge cloud meeting, so that we can have some follow up discussion then. fuqiao at chinamobile.com From: Csatari, Gergely (Nokia - HU/Budapest) Date: 2018-07-12 22:00 To: edge-computing at lists.openstack.org Subject: [Edge-computing] Merging deployment scenarios to the OPNFV Edge Computing requirement document Hi, Here is the change what merges the deployment scenarios from the Dublin edge notes to the OPNFV Edge Computing requirements document: https://gerrit.opnfv.org/gerrit/#/c/59763/ Whenever it is merged I will only refer to this and delete the definitions form the Dublin edge notes wiki. Please check and comment. Br, Gerg0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Randy.Perryman at dell.com Fri Jul 13 13:14:55 2018 From: Randy.Perryman at dell.com (Randy.Perryman at dell.com) Date: Fri, 13 Jul 2018 13:14:55 +0000 Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion In-Reply-To: References: <94D304DB-0054-4114-A7B1-694BE3A27576@intel.com> <23137fc8e1184cba97f99753923fbece@ausx13mpc118.AMER.DELL.COM> <6bf33dfce69e4d2eb4a2f843766f8a1a@kontron.com> Message-ID: <5bc07d932bf14576bb751c9accb810c7@ausx13mpc122.AMER.DELL.COM> Thank You everyone for the overwhelming response. As I can only put three panelist on the list, I am going to use: Eric/Beth/Vinay. I am also wondering if this topic deserves more than one session? -Randy From: Qin, Kailun [mailto:kailun.qin at intel.com] Sent: Thursday, July 12, 2018 8:13 PM To: Éric Sarault; Perryman, Randy; beth.cohen at verizon.com; Hu, Yong; edge-computing at lists.openstack.org Subject: RE: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Great topic! I’d also be interested in being on the panel. Please kindly count me in if any help or input needed. BR, Kailun From: Éric Sarault [mailto:Eric.Sarault at kontron.com] Sent: Friday, July 13, 2018 2:56 AM To: Randy.Perryman at dell.com; beth.cohen at verizon.com; Hu, Yong >; edge-computing at lists.openstack.org Subject: Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Definitely. I can help with the proposal if you need a hand. --- Eric Sarault, B. Eng. Software Product Manager Kontron – An S&T Company 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada P: +1 (450) 437-4661 x2217 eric.sarault at kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Canada Inc. By opening this email you are agreeing to Kontron's Electronic Communications Policy. From: Randy.Perryman at dell.com > Sent: July 12, 2018 2:47 PM To: beth.cohen at verizon.com; yong.hu at intel.com; Éric Sarault >; edge-computing at lists.openstack.org Subject: RE: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Agreed. I will start this in the morning Eastern Time. Eric and Yong will you both be interested in being on the Panel? Randy Perryman Technical Staff, Cloud Architect Dell EMC | OpenSource Solutions Group office + 01 603 249 7710 mobile +01 603 321 5611 [dell_logo][cos] Please consider the environment before printing this email. Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message. From: beth.cohen at verizon.com [mailto:beth.cohen at verizon.com] Sent: Thursday, July 12, 2018 2:43 PM To: Hu, Yong; Éric Sarault; Perryman, Randy; edge-computing at lists.openstack.org Subject: RE: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Folks – I would go ahead and write up the proposal – which would include an agenda anyway – then you can prep for the panel once it has been accepted. [Image removed by sender. Verizon] Beth Cohen DMTS- NFV/SDN Network Product Strategy Verizon Technology O +781-466-2055 | M +781-434-8553 beth.cohen at verizon.com [Image removed by sender. Twitter] [Image removed by sender. Instagram] From: Hu, Yong [mailto:yong.hu at intel.com] Sent: Thursday, July 12, 2018 2:34 PM To: Éric Sarault >; Randy.Perryman at dell.com; edge-computing at lists.openstack.org Subject: [E] Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion +1 for this panel! Would it be possible in advance we form a specific agenda for this topic (Containers vs Virtual Machines on the Edge)? Regards, Yong From: Éric Sarault > Date: Thursday, 12 July 2018 at 11:26 AM To: "Randy.Perryman at dell.com" >, "edge-computing at lists.openstack.org" > Subject: Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion We’d be willin to participate to that panel. --- Eric Sarault, B. Eng. Software Product Manager Kontron – An S&T Company 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada P: +1 (450) 437-4661 x2217 eric.sarault at kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Canada Inc. By opening this email you are agreeing to Kontron's Electronic Communications Policy. From: Randy.Perryman at dell.com > Sent: July 12, 2018 2:21 PM To: edge-computing at lists.openstack.org Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion Would a panel discussion on the following be worthwhile: Containers vs Virtual Machines on the Edge – What do you build your Cluster too? If there is interest, I would be willing to moderate, just need 3 to 5 people for the panel. Randy Perryman Technical Staff, Cloud Architect Dell EMC | OpenSource Solutions Group office + 01 603 249 7710 mobile +01 603 321 5611 [dell_logo][cos] Please consider the environment before printing this email. Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 843 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 612 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 359 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 334 bytes Desc: image004.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image011.jpg Type: image/jpeg Size: 336 bytes Desc: image011.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image012.jpg Type: image/jpeg Size: 336 bytes Desc: image012.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image013.png Type: image/png Size: 844 bytes Desc: image013.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image014.png Type: image/png Size: 613 bytes Desc: image014.png URL: From asayeed at redhat.com Fri Jul 13 13:29:07 2018 From: asayeed at redhat.com (Azhar Sayeed) Date: Fri, 13 Jul 2018 14:29:07 +0100 Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion In-Reply-To: <5bc07d932bf14576bb751c9accb810c7@ausx13mpc122.AMER.DELL.COM> References: <94D304DB-0054-4114-A7B1-694BE3A27576@intel.com> <23137fc8e1184cba97f99753923fbece@ausx13mpc118.AMER.DELL.COM> <6bf33dfce69e4d2eb4a2f843766f8a1a@kontron.com> <5bc07d932bf14576bb751c9accb810c7@ausx13mpc122.AMER.DELL.COM> Message-ID: <2656F7F7-2A3F-48D3-ADBC-AC44A7B379C8@redhat.com> Hi Beth, I can volunteer on the Panel - also represent a open source software point of view. If you want me to write up a draft - I can do that - just today I am flying back to Boston Please let me know Regards Azhar Sent from my iPhone > On Jul 13, 2018, at 2:14 PM, wrote: > > Thank You everyone for the overwhelming response. As I can only put three panelist on the list, I am going to use: Eric/Beth/Vinay. > > I am also wondering if this topic deserves more than one session? > > -Randy > > From: Qin, Kailun [mailto:kailun.qin at intel.com] > Sent: Thursday, July 12, 2018 8:13 PM > To: Éric Sarault; Perryman, Randy; beth.cohen at verizon.com; Hu, Yong; edge-computing at lists.openstack.org > Subject: RE: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion > > Great topic! I’d also be interested in being on the panel. Please kindly count me in if any help or input needed. > > BR, > Kailun > > From: Éric Sarault [mailto:Eric.Sarault at kontron.com] > Sent: Friday, July 13, 2018 2:56 AM > To: Randy.Perryman at dell.com; beth.cohen at verizon.com; Hu, Yong ; edge-computing at lists.openstack.org > Subject: Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion > > Definitely. > > I can help with the proposal if you need a hand. > > --- > Eric Sarault, B. Eng. > Software Product Manager > Kontron – An S&T Company > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada > P: +1 (450) 437-4661 x2217 > eric.sarault at kontron.com > > Website | Blog | Twitter | LinkedIn | YouTube | Facebook > > Kontron Canada Inc. > By opening this email you are agreeing to Kontron's Electronic Communications Policy. > > From: Randy.Perryman at dell.com > Sent: July 12, 2018 2:47 PM > To: beth.cohen at verizon.com; yong.hu at intel.com; Éric Sarault ; edge-computing at lists.openstack.org > Subject: RE: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion > > Agreed. I will start this in the morning Eastern Time. > > Eric and Yong will you both be interested in being on the Panel? > > Randy Perryman > Technical Staff, Cloud Architect > Dell EMC | OpenSource Solutions Group > office + 01 603 249 7710 > mobile +01 603 321 5611 > > > Please consider the environment before printing this email. > > Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message. > > > > > From: beth.cohen at verizon.com [mailto:beth.cohen at verizon.com] > Sent: Thursday, July 12, 2018 2:43 PM > To: Hu, Yong; Éric Sarault; Perryman, Randy; edge-computing at lists.openstack.org > Subject: RE: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion > > Folks – > I would go ahead and write up the proposal – which would include an agenda anyway – then you can prep for the panel once it has been accepted. > > > > > Beth Cohen > DMTS- NFV/SDN Network Product Strategy > Verizon Technology > > O +781-466-2055 | M +781-434-8553 > beth.cohen at verizon.com > > > > > From: Hu, Yong [mailto:yong.hu at intel.com] > Sent: Thursday, July 12, 2018 2:34 PM > To: Éric Sarault ; Randy.Perryman at dell.com; edge-computing at lists.openstack.org > Subject: [E] Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion > > +1 for this panel! > Would it be possible in advance we form a specific agenda for this topic (Containers vs Virtual Machines on the Edge)? > > Regards, > Yong > > From: Éric Sarault > Date: Thursday, 12 July 2018 at 11:26 AM > To: "Randy.Perryman at dell.com" , "edge-computing at lists.openstack.org" > Subject: Re: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion > > We’d be willin to participate to that panel. > > --- > Eric Sarault, B. Eng. > Software Product Manager > Kontron – An S&T Company > 4555, rue Ambroise-Lafortune | Boisbriand (Quebec) J7H 0A4 | Canada > P: +1 (450) 437-4661 x2217 > eric.sarault at kontron.com > > Website | Blog | Twitter | LinkedIn | YouTube | Facebook > > Kontron Canada Inc. > By opening this email you are agreeing to Kontron's Electronic Communications Policy. > > From: Randy.Perryman at dell.com > Sent: July 12, 2018 2:21 PM > To: edge-computing at lists.openstack.org > Subject: [Edge-computing] OpenStack Summit Berlin CFP - Panel Suggestion > > Would a panel discussion on the following be worthwhile: > > Containers vs Virtual Machines on the Edge – What do you build your Cluster too? > > > If there is interest, I would be willing to moderate, just need 3 to 5 people for the panel. > > > Randy Perryman > Technical Staff, Cloud Architect > Dell EMC | OpenSource Solutions Group > office + 01 603 249 7710 > mobile +01 603 321 5611 > > > Please consider the environment before printing this email. > > Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message. > > > _______________________________________________ > Edge-computing mailing list > Edge-computing at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Paterson at dell.com Mon Jul 16 18:02:26 2018 From: David.Paterson at dell.com (David.Paterson at dell.com) Date: Mon, 16 Jul 2018 18:02:26 +0000 Subject: [Edge-computing] [Use Cases] Open Caching Message-ID: <4c092ffc2d9f49758fc246efb1021281@ausx13mpc124.AMER.DELL.COM> Dell - Internal Use - Confidential Here’s my first pass at the open caching use case we discussed in Monday’s edge computing use case meeting: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Open_Caching_-_stream.2Fstore_data_at_the_edge Thanks, dp -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Thu Jul 12 14:57:59 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Thu, 12 Jul 2018 14:57:59 +0000 Subject: [Edge-computing] Review of Dublin edge notes Message-ID: Hi, Notes of todays meeting are here: http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/review_of_dublin_edge_notes.2018-07-12-14.02.html Br, Gerg0 -----Original Appointment----- From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Thursday, July 5, 2018 5:08 PM To: Csatari, Gergely (Nokia - HU/Budapest); 'edge-computing'; Srikumar Venugopal; Waines, Greg; beth.cohen at verizon.com; Mathieu LAGRANGE; Bernier, Daniel; Martin Bäckström; Randy.Perryman at dell.com; Éric Sarault; Francis Dagenais; Arkady.Kanevsky at dell.com; Silverman, Ben; D'ANDREA, JOE (JOE); Brendon Mifsud (mifsudb); Shuquan Huang; Beierl, Mark; saiyagar at redhat.com; Jan Walzer; jonathan at openstack.org; Teresa Peluso; Peter Kapatsos Cc: Mats Karlsson A; Paul Bankert Subject: Review of Dublin edge notes When: csütörtök 2018. július 12 16:00-17:00 (UTC+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague. Where: #edge-computing-group on freenode Hi, Let's continue the IRC meeting to discuss the comments to the Dublin edge notes from 5.3.2.10 Flavors source side: https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG. Notes of the previous meetings: * http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/ * http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/review_of_dublin_edge_notes.2018-04-20-12.58.html * http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes_ii/2018/review_of_dublin_edge_notes_ii.2018-04-25-14.01.html * http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes_03/2018/review_of_dublin_edge_notes_03.2018-05-11-13.00.html Please note, that the correction of the comments is not finished yet, tracking of comment correction is here: https://etherpad.openstack.org/p/Dublin-edge-notes-wiki Br, Gerg0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Paterson at dell.com Sat Jul 14 00:11:12 2018 From: David.Paterson at dell.com (David.Paterson at dell.com) Date: Sat, 14 Jul 2018 00:11:12 +0000 Subject: [Edge-computing] [Use Cases] Open Caching Message-ID: <7fcaee8924ed4521a55989fe07a90f41@ausx13mpc124.AMER.DELL.COM> Dell - Internal Use - Confidential Here’s my first pass at the open caching use case we discussed in Monday’s edge computing use case meeting: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Open_Caching_-_stream.2Fstore_data_at_the_edge Thanks, dp -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Paterson at dell.com Mon Jul 16 17:22:43 2018 From: David.Paterson at dell.com (David.Paterson at dell.com) Date: Mon, 16 Jul 2018 17:22:43 +0000 Subject: [Edge-computing] [Use Cases] Open Caching Message-ID: Dell - Internal Use - Confidential Here’s my first pass at the open caching use case we discussed in Monday’s edge computing use case meeting: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Open_Caching_-_stream.2Fstore_data_at_the_edge Thanks, dp -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openstack.org Mon Jul 16 18:36:50 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Mon, 16 Jul 2018 11:36:50 -0700 Subject: [Edge-computing] Use Cases call canceled for today Message-ID: Hi All, I had a couple of people reaching out to me about not being able to make it to the Use Cases subgroup call today, so we will cancel the today’s meeting. Please check out the wiki page for more info on the template that the group is using and on details of use cases we collected so far: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases Feel free to add your use case or join the subgroup call next week. Please let me know if you have any questions. Thanks and Best Regards, Ildikó From asayeed at redhat.com Tue Jul 17 14:32:31 2018 From: asayeed at redhat.com (Azhar Sayeed) Date: Tue, 17 Jul 2018 10:32:31 -0400 Subject: [Edge-computing] Fwd: OpenStack Summit - Berlin 2018 - Presentation Submission Received References: <0Tb6OX4MQIal347q4nqNtw@ismtpd0001p1sjc2.sendgrid.net> Message-ID: <4C71175E-7AA9-41DE-B5A8-AAE29003A015@redhat.com> Team, Per our discussion on the call this morning, I submitted a presentation for OSS Berlin on “Zero Touch Provisioning for Edge use cases” I don’t know if you can see this link because the CFP hasn’t yet closed.. I will post the link once the submissions are live.. Here is a short abstract *** Zero touch provisioning of Whitebox servers is critical for Edge use cases. Akraino community has published five blue prints of POD (Points of Delivery) for Edge. However, the blueprints of Satellite and Rover are still up for discussion. In this presentation we will discuss zero touch provisioning for Satellite and Rover blue prints of Akraino. We will explain the challenges associated with Zero Touch Provisioning for OpenStack and Kubernetes - We will show how these remote nodes can be authenticated, provisioned and managed by OpenStack and/or Kubernetes. *** The goal is to also show a simple demo as part of the presentation.. The focus is on multi-layer authentication and automation of provisioning of the remote nodes HCI or non HCI I have another speaker from Red Hat on this topic - I am open to adding another speaker from this WG if there is value.. Regards, Azhar > Begin forwarded message: > > From: speakersupport at openstack.org > Subject: OpenStack Summit - Berlin 2018 - Presentation Submission Received > Date: July 17, 2018 at 10:24:02 AM EDT > To: asayeed at redhat.com > > Hello Azhar Sayeed -- > > Thank you for your submission to the OpenStack Summit in Berlin, Nov 13-15, 2018. > > The presentation details can be found here: https://www.openstack.org/summit/berlin-2018/call-for-presentations/manage/22238/summary -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openstack.org Tue Jul 17 14:53:48 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Tue, 17 Jul 2018 07:53:48 -0700 Subject: [Edge-computing] Berlin CFP closes in less than 24 hours!! Message-ID: Hi, It is a friendly reminder that the Berlin CFP closes at 11:59pm Pacific Time / 0659 UTC. You can submit your talk/panel/workshop proposal here: https://www.openstack.org/summit/berlin-2018/call-for-presentations/ Please let me know if you have any questions or if you need any help. Thanks and Best Regards, Ildikó From gergely.csatari at nokia.com Wed Jul 18 08:01:48 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Wed, 18 Jul 2018 08:01:48 +0000 Subject: [Edge-computing] [edge][glance]: Image handling in edge environment Message-ID: Hi, We had a great Forum session about image handling in edge environment in Vancouver [1]. As one outcome of the session I've created a wiki with the mentioned architecture options [1]. During the Edge Working Group [3] discussions we identified some questions (some of them are in the wiki, some of them are in mails [4]) and also I would like to get some feedback on the analyzis in the wiki from people who know Glance. I think the best would be to have some kind of meeting and I see two options to organize this: * Organize a dedicated meeting for this * Add this topic as an agenda point to the Glance weekly meeting Please share your preference and/or opinion. Thanks, Gerg0 [1]: https://etherpad.openstack.org/p/yvr-edge-cloud-images [2]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment [3]: https://wiki.openstack.org/wiki/Edge_Computing_Group [4]: http://lists.openstack.org/pipermail/edge-computing/2018-June/000239.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Fri Jul 20 11:31:42 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Fri, 20 Jul 2018 11:31:42 +0000 Subject: [Edge-computing] [edge][glance]: Image handling in edge environment In-Reply-To: References: Message-ID: Hi, We figured out with Jokke two timeslots what would be okay for both of us for this common meeting. Please, other interested parties give your votes to here: https://doodle.com/poll/9rfcb8aavsmybzfu I will evaluate the results and fix the time on 25.07.2018 12h CET. Br, Gerg0 From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Wednesday, July 18, 2018 10:02 AM To: 'edge-computing' ; OpenStack Development Mailing List (not for usage questions) Subject: [edge][glance]: Image handling in edge environment Hi, We had a great Forum session about image handling in edge environment in Vancouver [1]. As one outcome of the session I've created a wiki with the mentioned architecture options [1]. During the Edge Working Group [3] discussions we identified some questions (some of them are in the wiki, some of them are in mails [4]) and also I would like to get some feedback on the analyzis in the wiki from people who know Glance. I think the best would be to have some kind of meeting and I see two options to organize this: * Organize a dedicated meeting for this * Add this topic as an agenda point to the Glance weekly meeting Please share your preference and/or opinion. Thanks, Gerg0 [1]: https://etherpad.openstack.org/p/yvr-edge-cloud-images [2]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment [3]: https://wiki.openstack.org/wiki/Edge_Computing_Group [4]: http://lists.openstack.org/pipermail/edge-computing/2018-June/000239.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Mon Jul 23 10:49:28 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Mon, 23 Jul 2018 10:49:28 +0000 Subject: [Edge-computing] [keystone][testing]: Test scenarios Message-ID: Hi, I’ve listed some scenario on title level to row 41 or the etherpad: https://etherpad.openstack.org/p/ECG_Keystone_Testing . Some question: * Do we keep the test design in the etherpad or should I move it to the wiki (I think Wiki is better, but you know this already 😊) * Do we want to test only the Keystone functionality or Keystone + mod shib? * Any comments? Br, Gerg0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openstack.org Mon Jul 23 16:54:08 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Mon, 23 Jul 2018 18:54:08 +0200 Subject: [Edge-computing] Denver PTG schedule Message-ID: Hi, I would like to draw your attention to the recently published schedule[1] for the upcoming Denver PTG[2]. The Edge Computing Group is scheduled for Tuesday, the only overlapping we have is with Airship. We have a planning etherpad[3] to work on topics to discuss and we need to start planning cross-project sessions with projects such as Keystone, Glance and StarlingX. Please add your name if you’re planning to attend the PTG and the edge sessions. Please let me know if you have any questions. Thanks and Best Regards, Ildikó [1] https://www.openstack.org/ptg/#tab_schedule [2] https://www.openstack.org/ptg [3] https://etherpad.openstack.org/p/EdgeComputingGroupPTG4 From ildiko at openstack.org Wed Jul 25 09:06:28 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Wed, 25 Jul 2018 11:06:28 +0200 Subject: [Edge-computing] Preparation to the face to face meeting at the PTG Message-ID: <506ED29A-9A0D-4FE3-B4AC-4C4D3D233C7E@openstack.org> Hi, The next PTG in Denver is approaching quickly: https://www.openstack.org/ptg You can find the schedule here, the Edge Computing Group will meet on Tuesday: https://www.openstack.org/ptg/#tab_schedule It is very important to plan discussions for the group and collaborative sessions with other relevant projects. We have a planning etherpad: https://etherpad.openstack.org/p/EdgeComputingGroupPTG4 Please add any topic to the etherpad that you would like to discuss at the PTG. Also please add your name to the etherpad if you’re planning to attend. In case you would like to join remotely please add your name to the etherpad in that case too and indicate that you would be a remote participant. Please let me know if you have any questions. Thanks and Best Regards, Ildikó From gergely.csatari at nokia.com Fri Jul 27 06:58:32 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Fri, 27 Jul 2018 06:58:32 +0000 Subject: [Edge-computing] Image handling in edge environment Message-ID: Hi, Let's spend this time to discuss the alternatives for Image handling in edge environment listed in here: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment * Check if the alternatives were captured correctly * Check the pros and cons * Check the concerns and questions * Decide if an alternative is a dead end For some strange reasons I do not receive mails from the OpenStack mailing list servers anymore, so if you have anything to discuss about this please use #edge-computing-group or add me directly to the mails. Br, Gerg0 --------------------------- 8< ------------ Webex: https://nokiameetings.webex.com/meet/gergely.csatari Telco if you need it: Internal : 8200300 Hungary: +3614088997 Global numbers Access code: 957 007 218 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2851 bytes Desc: not available URL: From gergely.csatari at nokia.com Fri Jul 27 07:06:45 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Fri, 27 Jul 2018 07:06:45 +0000 Subject: [Edge-computing] [edge][glance]: Image handling in edge environment In-Reply-To: References: Message-ID: Hi, The meeting will take place on 2018.08.01 18-19h CET. Here I attach the invitation. Br, Gerg0 From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Friday, July 20, 2018 1:32 PM To: 'edge-computing' ; 'OpenStack Development Mailing List (not for usage questions)' Cc: 'jokke' Subject: RE: [edge][glance]: Image handling in edge environment Hi, We figured out with Jokke two timeslots what would be okay for both of us for this common meeting. Please, other interested parties give your votes to here: https://doodle.com/poll/9rfcb8aavsmybzfu I will evaluate the results and fix the time on 25.07.2018 12h CET. Br, Gerg0 From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Wednesday, July 18, 2018 10:02 AM To: 'edge-computing' >; OpenStack Development Mailing List (not for usage questions) > Subject: [edge][glance]: Image handling in edge environment Hi, We had a great Forum session about image handling in edge environment in Vancouver [1]. As one outcome of the session I've created a wiki with the mentioned architecture options [1]. During the Edge Working Group [3] discussions we identified some questions (some of them are in the wiki, some of them are in mails [4]) and also I would like to get some feedback on the analyzis in the wiki from people who know Glance. I think the best would be to have some kind of meeting and I see two options to organize this: * Organize a dedicated meeting for this * Add this topic as an agenda point to the Glance weekly meeting Please share your preference and/or opinion. Thanks, Gerg0 [1]: https://etherpad.openstack.org/p/yvr-edge-cloud-images [2]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment [3]: https://wiki.openstack.org/wiki/Edge_Computing_Group [4]: http://lists.openstack.org/pipermail/edge-computing/2018-June/000239.html -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: "Csatari, Gergely (Nokia - HU/Budapest)" Subject: Image handling in edge environment Date: Fri, 27 Jul 2018 06:58:32 +0000 Size: 15935 URL: From jess.lampe at gmail.com Mon Jul 30 17:02:02 2018 From: jess.lampe at gmail.com (Jess Lampe) Date: Mon, 30 Jul 2018 10:02:02 -0700 Subject: [Edge-computing] Cancel Today's Meeting Message-ID: My travel back from the East Coast is was bumped up and I will be in-flight during our sync up. We do not appear to have any new content generated so I propose we postpone until next week. Cheers, Jess Lampe -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openstack.org Tue Jul 31 09:42:15 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Tue, 31 Jul 2018 06:42:15 -0300 Subject: [Edge-computing] APAC meeting slot this week Message-ID: <20D9BF52-224E-41AE-9374-5B6753AE41A2@openstack.org> Hi, It is a friendly reminder that we are switching to the APAC slot this week with the Edge Computing Group call. The APAC slot is Thursday (August 2), 0700 UTC: https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings See you on Thursday! Thanks and Best Regards, Ildikó