From kk0563 at att.com Fri Jun 1 07:38:16 2018 From: kk0563 at att.com (KATHIRVEL, KANDAN) Date: Fri, 1 Jun 2018 07:38:16 +0000 Subject: [Edge-computing] [opnfv-tech-discuss] [edge cloud]Edge cloud project meeting//this week's meeting will be onsite meeting during the OPNFV plugfest. we will also open Zoom channel during the call Message-ID: https://zoom.us/j/5014627785 meeting agenda and minutes are kept in the following etherpad page https://etherpad.opnfv.org/p/edge_cloud_meeting_minutes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 9106 bytes Desc: not available URL: From kk0563 at att.com Fri Jun 1 07:38:15 2018 From: kk0563 at att.com (KATHIRVEL, KANDAN) Date: Fri, 1 Jun 2018 07:38:15 +0000 Subject: [Edge-computing] [opnfv-tech-discuss] [edge cloud]Edge cloud project meeting//this week's meeting will be onsite meeting during the OPNFV plugfest. we will also open Zoom channel during the call Message-ID: https://zoom.us/j/5014627785 meeting agenda and minutes are kept in the following etherpad page https://etherpad.opnfv.org/p/edge_cloud_meeting_minutes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 9090 bytes Desc: not available URL: From kk0563 at att.com Fri Jun 1 11:40:47 2018 From: kk0563 at att.com (KATHIRVEL, KANDAN) Date: Fri, 1 Jun 2018 11:40:47 +0000 Subject: [Edge-computing] [opnfv-tech-discuss] [edge cloud]Edge cloud project meeting//this week's meeting will be onsite meeting during the OPNFV plugfest. we will also open Zoom channel during the call Message-ID: https://zoom.us/j/5014627785 meeting agenda and minutes are kept in the following etherpad page https://etherpad.opnfv.org/p/edge_cloud_meeting_minutes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 9053 bytes Desc: not available URL: From claire at openstack.org Tue Jun 5 13:38:57 2018 From: claire at openstack.org (Claire Massey) Date: Tue, 5 Jun 2018 08:38:57 -0500 Subject: [Edge-computing] Reminder: weekly calls starting today Message-ID: <33805845-25CA-43D0-B7AE-839BC5D53633@openstack.org> Hi everyone, Friendly reminder, the weekly Edge Computing Group calls pick back up today - starting in about 20 minutes from now at 7:00am PDT (1400 UTC). The calls will be held every Tuesday at this time. Dial in: https://zoom.us/j/777719876 Weekly agenda & call notes: https://wiki.openstack.org/wiki/Edge_Computing_Group Thanks, Claire From fuqiao1 at outlook.com Tue Jun 5 11:43:24 2018 From: fuqiao1 at outlook.com (=?utf-8?B?5LuYIOS5lA==?=) Date: Tue, 5 Jun 2018 11:43:24 +0000 Subject: [Edge-computing] [opnfv-tech-discuss] [edge cloud]Edge cloud project meeting//this week's meeting will be onsite meeting during the OPNFV plugfest. we will also open Zoom channel during the call Message-ID: Hi, all. I am really sorry for yesterday’s zoom link. We do not have meeting system here in ETSI, and I can only use my laptop. I will try to recap the meeting during our next call -------------- next part -------------- An HTML attachment was scrubbed... URL: From jess.lampe at gmail.com Wed Jun 6 05:00:31 2018 From: jess.lampe at gmail.com (Jess Lampe) Date: Tue, 5 Jun 2018 22:00:31 -0700 Subject: [Edge-computing] Clarification of Requirements Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lebre.adrien at free.fr Wed Jun 6 07:24:30 2018 From: lebre.adrien at free.fr (lebre.adrien at free.fr) Date: Wed, 6 Jun 2018 09:24:30 +0200 (CEST) Subject: [Edge-computing] Clarification of Requirements In-Reply-To: Message-ID: <2100552307.166806266.1528269870731.JavaMail.root@zimbra29-e5.priv.proxad.net> 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 > From fuqiao at chinamobile.com Wed Jun 6 09:13:08 2018 From: fuqiao at chinamobile.com (Fu Qiao) Date: Wed, 6 Jun 2018 17:13:08 +0800 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAgQ2xhcmlmaWNhdGlvbiBvZiBS?= =?utf-8?q?equirements?= In-Reply-To: <2100552307.166806266.1528269870731.JavaMail.root@zimbra29-e5.priv.proxad.net> References: <2100552307.166806266.1528269870731.JavaMail.root@zimbra29-e5.priv.proxad.net> Message-ID: <010501d3fd76$97c84890$c758d9b0$@chinamobile.com> 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 From paul-andre.raymond at b-yond.com Wed Jun 6 13:18:52 2018 From: paul-andre.raymond at b-yond.com (Paul-Andre Raymond) Date: Wed, 6 Jun 2018 13:18:52 +0000 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAgQ2xhcmlmaWNhdGlvbiBvZiBS?= =?utf-8?q?equirements?= In-Reply-To: <010501d3fd76$97c84890$c758d9b0$@chinamobile.com> References: <2100552307.166806266.1528269870731.JavaMail.root@zimbra29-e5.priv.proxad.net> <010501d3fd76$97c84890$c758d9b0$@chinamobile.com> Message-ID: <820A8FF6-0412-41DC-AC30-E49A210389B7@b-yond.com> 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 From fuqiao at chinamobile.com Wed Jun 6 13:21:21 2018 From: fuqiao at chinamobile.com (Fu Qiao) Date: Wed, 6 Jun 2018 21:21:21 +0800 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion_of_Requirements?= In-Reply-To: <820A8FF6-0412-41DC-AC30-E49A210389B7@b-yond.com> References: <2100552307.166806266.1528269870731.JavaMail.root@zimbra29-e5.priv.proxad.net> <010501d3fd76$97c84890$c758d9b0$@chinamobile.com> <820A8FF6-0412-41DC-AC30-E49A210389B7@b-yond.com> Message-ID: <011b01d3fd99$456077d0$d0216770$@chinamobile.com> 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 From Greg.Waines at windriver.com Wed Jun 6 13:44:11 2018 From: Greg.Waines at windriver.com (Waines, Greg) Date: Wed, 6 Jun 2018 13:44:11 +0000 Subject: [Edge-computing] Keystone Edge Architectures Message-ID: <678C1A99-2302-438D-8D5D-91ED44B10FF9@windriver.com> Hey ... just taking a look at the options in https://wiki.openstack.org/wiki/Keystone_edge_architectures . For the first option, i.e. ‘Several keystone instances with federation with API synchronsation’ · I am assuming that the Keystone Instance at each Edge Cloud Instance is communicating with a non-local central Identity Provider · If this is the case, the concern list above related to operability with no connectivity o i.e. “There may be significant times with no connectivity and all functions (e.g. autoscaling) must continue to function” In the ‘Distributed Cloud’ sub-project of the StarlingX project ( i.e. see summit presentation @ https://www.openstack.org/videos/vancouver-2018/edge-computing-operations-day-1-deployment-and-day-2-management ) · our initial keystone approach is simply the standard multi-region centralized shared keystone, so no scalability and no autonomy for edge clouds on loss of connectivity, · · BUT we are currently taking more of the ‘second option’ approach (i.e. ‘Keystone database replication’) ... with some additions i.e. o Every Edge Cloud instance runs its own keystone instance, o Keystone resources are replicated from central site to edge clouds using our distribute-cloud-replication-framework, § i.e. projects, users, groups, domains, roles, ... § ( i.e. not a low-level DB synchronization ... more a high-level journaling / synchronization of resources ) o AND o Also supporting Fernet Key synchronization and management across Edge Clouds in order to enable Tokens created at any Edge / Central cloud being able to be used (and authenticated) in any other clouds. § Required for some distributed services scenarios, e.g. glance-api pulling from a remote glance-registry, etc. (likely for future scenarios we don’t currently understand). Comments ? Greg. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul-andre.raymond at b-yond.com Wed Jun 6 14:05:10 2018 From: paul-andre.raymond at b-yond.com (Paul-Andre Raymond) Date: Wed, 6 Jun 2018 14:05:10 +0000 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion_of_Requirements?= Message-ID: <817E37E2-09E3-4FCB-B15F-7698C69DDD58@b-yond.com> 5ms one way is not uncommon. But requirements should be for the worst case not the average case. For another interesting data point, we can look at MEF which talks about One-Way delay constraints of 10 ms for backhaul links. Paul-André -- On 6/6/18, 9:21 AM, "Fu Qiao" wrote: 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 From Arkady.Kanevsky at dell.com Wed Jun 6 14:49:27 2018 From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com) Date: Wed, 6 Jun 2018 14:49:27 +0000 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion_of_Requirements?= In-Reply-To: <011b01d3fd99$456077d0$d0216770$@chinamobile.com> References: <2100552307.166806266.1528269870731.JavaMail.root@zimbra29-e5.priv.proxad.net> <010501d3fd76$97c84890$c758d9b0$@chinamobile.com> <820A8FF6-0412-41DC-AC30-E49A210389B7@b-yond.com> <011b01d3fd99$456077d0$d0216770$@chinamobile.com> Message-ID: <5116516a346943bead676c16be75cea5@AUSX13MPS308.AMER.DELL.COM> 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 From gergely.csatari at nokia.com Thu Jun 7 08:15:46 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Thu, 7 Jun 2018 08:15:46 +0000 Subject: [Edge-computing] Keystone Edge Architectures In-Reply-To: <678C1A99-2302-438D-8D5D-91ED44B10FF9@windriver.com> References: <678C1A99-2302-438D-8D5D-91ED44B10FF9@windriver.com> Message-ID: Hi, What do you mean by high level journaling / syncrronsation? For me one of the basic differences between option 1 and 2 is the understanding of the data semantics during the synchronisaiton in case of option 1 and synchronising blobs of data in case of option 2. Can you share what data do you synchronise between the Keystone instances? This is also a piece of information what we are looking for. Thanks, Gerg0 From: Waines, Greg [mailto:Greg.Waines at windriver.com] Sent: Wednesday, June 6, 2018 3:44 PM To: edge-computing at lists.openstack.org Subject: [Edge-computing] Keystone Edge Architectures Hey ... just taking a look at the options in https://wiki.openstack.org/wiki/Keystone_edge_architectures . For the first option, i.e. ‘Several keystone instances with federation with API synchronsation’ * I am assuming that the Keystone Instance at each Edge Cloud Instance is communicating with a non-local central Identity Provider * If this is the case, the concern list above related to operability with no connectivity * i.e. “There may be significant times with no connectivity and all functions (e.g. autoscaling) must continue to function” In the ‘Distributed Cloud’ sub-project of the StarlingX project ( i.e. see summit presentation @ https://www.openstack.org/videos/vancouver-2018/edge-computing-operations-day-1-deployment-and-day-2-management ) * our initial keystone approach is simply the standard multi-region centralized shared keystone, so no scalability and no autonomy for edge clouds on loss of connectivity, * * BUT we are currently taking more of the ‘second option’ approach (i.e. ‘Keystone database replication’) ... with some additions i.e. * Every Edge Cloud instance runs its own keystone instance, * Keystone resources are replicated from central site to edge clouds using our distribute-cloud-replication-framework, * i.e. projects, users, groups, domains, roles, ... * ( i.e. not a low-level DB synchronization ... more a high-level journaling / synchronization of resources ) * AND * Also supporting Fernet Key synchronization and management across Edge Clouds in order to enable Tokens created at any Edge / Central cloud being able to be used (and authenticated) in any other clouds. * Required for some distributed services scenarios, e.g. glance-api pulling from a remote glance-registry, etc. (likely for future scenarios we don’t currently understand). Comments ? Greg. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Thu Jun 7 10:49:31 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Thu, 7 Jun 2018 10:49:31 +0000 Subject: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation Message-ID: 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 gergely.csatari at nokia.com Thu Jun 7 11:10:25 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Thu, 7 Jun 2018 11:10:25 +0000 Subject: [Edge-computing] Doodle for next Review of Dublin edge notes meeting In-Reply-To: References: Message-ID: Hi, Let's try to continue from 5.3 next week. [1]. [1]: https://doodle.com/poll/v7qse7fqr2azy2zi Br, Gerg0 From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Wednesday, May 16, 2018 1:10 PM To: 'edge-computing at lists.openstack.org' Subject: RE: Doodle for next Review of Dublin edge notes meeting Hi, I could not find any time with more than 2 okays, so let's not continue this week. We can use the remainig time of the Edge Computing BoF [1] if there will be any. Br, Gerg0 [1]: https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21685/edge-computing-group-bof From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Friday, May 11, 2018 5:17 PM To: 'edge-computing at lists.openstack.org' > Subject: Doodle for next Review of Dublin edge notes meeting Hi, Let's not stop the fun and try to sqeeze one more review meeting before Vancouver. https://doodle.com/poll/rw7fhsm3vpbbxce4 Br, Gerg0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Greg.Waines at windriver.com Thu Jun 7 11:37:02 2018 From: Greg.Waines at windriver.com (Waines, Greg) Date: Thu, 7 Jun 2018 11:37:02 +0000 Subject: [Edge-computing] Keystone Edge Architectures In-Reply-To: References: <678C1A99-2302-438D-8D5D-91ED44B10FF9@windriver.com> Message-ID: <77FE167D-B416-4C8C-9D83-E34779D394B3@windriver.com> Hey Gergely, Wrt High-Level journaling/synchronization ... I really mean · We are NOT doing some low-level semantic-unaware DB synchronization, · Instead we are doing a more high level, semantic-aware replication of Keystone Resources from the Central Site to ALL the Edge Clouds o we are generally replicating REST API commands for creating/modifying/deleting Keystone Resources between Central Site and ALL the Edge Clouds § although more sophisticated than that, as it supports retries on failures and audits of resources to handle scenarios where Edge Clouds are disconnected during changes to the Central Site, etc. o the Keystone Resources we are currently synchronizing are: Users, Projects, Roles and Assignments § ... should be doing Groups and Domains as well ... but currently don’t leverage User Groups and only have default Domain in StarlingX § and, will also synchronize Fernet keys so that tokens created on any cloud can be used/validated on any cloud. · This is built on a common synchronization framework for providing common utilities / mechanisms for broadcast of messages to all Edge Clouds, retries, audits, etc o E.g. we use this framework for also synchronizing § Nova’s – flavors, flavor extra-specs, keypairs, quotas § Neutron’s – security groups, security group rules § Cinder’s - quotas Greg. From: "Csatari, Gergely (Nokia - HU/Budapest)" Date: Thursday, June 7, 2018 at 4:15 AM To: Greg Waines , "edge-computing at lists.openstack.org" Subject: RE: [Edge-computing] Keystone Edge Architectures Hi, What do you mean by high level journaling / syncrronsation? For me one of the basic differences between option 1 and 2 is the understanding of the data semantics during the synchronisaiton in case of option 1 and synchronising blobs of data in case of option 2. Can you share what data do you synchronise between the Keystone instances? This is also a piece of information what we are looking for. Thanks, Gerg0 From: Waines, Greg [mailto:Greg.Waines at windriver.com] Sent: Wednesday, June 6, 2018 3:44 PM To: edge-computing at lists.openstack.org Subject: [Edge-computing] Keystone Edge Architectures Hey ... just taking a look at the options in https://wiki.openstack.org/wiki/Keystone_edge_architectures . For the first option, i.e. ‘Several keystone instances with federation with API synchronsation’ * I am assuming that the Keystone Instance at each Edge Cloud Instance is communicating with a non-local central Identity Provider * If this is the case, the concern list above related to operability with no connectivity * i.e. “There may be significant times with no connectivity and all functions (e.g. autoscaling) must continue to function” In the ‘Distributed Cloud’ sub-project of the StarlingX project ( i.e. see summit presentation @ https://www.openstack.org/videos/vancouver-2018/edge-computing-operations-day-1-deployment-and-day-2-management ) * our initial keystone approach is simply the standard multi-region centralized shared keystone, so no scalability and no autonomy for edge clouds on loss of connectivity, * * BUT we are currently taking more of the ‘second option’ approach (i.e. ‘Keystone database replication’) ... with some additions i.e. * Every Edge Cloud instance runs its own keystone instance, * Keystone resources are replicated from central site to edge clouds using our distribute-cloud-replication-framework, * i.e. projects, users, groups, domains, roles, ... * ( i.e. not a low-level DB synchronization ... more a high-level journaling / synchronization of resources ) * AND * Also supporting Fernet Key synchronization and management across Edge Clouds in order to enable Tokens created at any Edge / Central cloud being able to be used (and authenticated) in any other clouds. * Required for some distributed services scenarios, e.g. glance-api pulling from a remote glance-registry, etc. (likely for future scenarios we don’t currently understand). Comments ? Greg. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Greg.Waines at windriver.com Thu Jun 7 12:23:44 2018 From: Greg.Waines at windriver.com (Waines, Greg) Date: Thu, 7 Jun 2018 12:23:44 +0000 Subject: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation Message-ID: <54898258-0FC0-46F3-9C64-FE4CEEA2B78C@windriver.com> 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 ? o i.e. GLANCE is a typical shared service in a multi-region environment ? · If so, how does this OPTION support the requirement for Edge Cloud Operation when disconnected from Central Location ? 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 o 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) · I think the ‘Synch Service’ MUST be able to support ‘selective/multicast’ distribution of Images from Central to Edge for Image Synchronization o i.e. you don’t want Central Site pushing ALL images to ALL Edge Sites ... especially for the small Edge Sites · Not sure ... but I didn’t think this was the model being used in mixmatch ... thought mixmatch was more the PULL model (below) 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 o We run glance-api on all Edge Clouds ... that talk to glance-registry on the Central Cloud, and o 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 · · 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. Greg. 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 Remo at italy1.com Thu Jun 7 16:08:03 2018 From: Remo at italy1.com (Remo Mattei) Date: Thu, 7 Jun 2018 09:08:03 -0700 Subject: [Edge-computing] Doodle for next Review of Dublin edge notes meeting In-Reply-To: References: Message-ID: <4FC45985-CA46-4100-92D9-ABF482D78C50@italy1.com> Hi guys, What time next week? Sorry I missed this week crazy trying to go production with OpenStack > On Jun 7, 2018, at 4:10 AM, Csatari, Gergely (Nokia - HU/Budapest) wrote: > > Hi, > > Let’s try to continue from 5.3 next week. > > [1]. > > [1]: https://doodle.com/poll/v7qse7fqr2azy2zi > > Br, > Gerg0 >   <> > From: Csatari, Gergely (Nokia - HU/Budapest) > Sent: Wednesday, May 16, 2018 1:10 PM > To: 'edge-computing at lists.openstack.org ' > > Subject: RE: Doodle for next Review of Dublin edge notes meeting > > Hi, > > I could not find any time with more than 2 okays, so let’s not continue this week. > > We can use the remainig time of the Edge Computing BoF [1 ] if there will be any. > > Br, > Gerg0 > > [1]: https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21685/edge-computing-group-bof > > > From: Csatari, Gergely (Nokia - HU/Budapest) > Sent: Friday, May 11, 2018 5:17 PM > To: 'edge-computing at lists.openstack.org ' > > Subject: Doodle for next Review of Dublin edge notes meeting > > Hi, > > Let’s not stop the fun and try to sqeeze one more review meeting before Vancouver. > > https://doodle.com/poll/rw7fhsm3vpbbxce4 > > Br, > Gerg0 > _______________________________________________ > 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 jess.lampe at gmail.com Thu Jun 7 23:44:27 2018 From: jess.lampe at gmail.com (Jess Lampe) Date: Thu, 7 Jun 2018 16:44:27 -0700 Subject: [Edge-computing] Invite Use Case Experts Message-ID: Interested in joining Q&A sessions with experts in particular edge use cases or scenarios? Add your name here: https://etherpad.openstack.org/p/edge-use-case Our goal would be to invite experts tackling specific problems so that we can learn more about the problems we are solving for. Examples: - Non-Profits working on IoT setups - Retail "cloud-in-a-box" providers If there is enough interest, we could consider using part of the Tuesday meetings. If a handful of people are interested, we can schedule it for other days. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Fri Jun 8 06:04:08 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Fri, 8 Jun 2018 06:04:08 +0000 Subject: [Edge-computing] Doodle for next Review of Dublin edge notes meeting In-Reply-To: <4FC45985-CA46-4100-92D9-ABF482D78C50@italy1.com> References: , <4FC45985-CA46-4100-92D9-ABF482D78C50@italy1.com> Message-ID: <7e25b16b-b899-4749-95c0-7f8df2d5417b@nokia.com> Hi, You can vote for the time in the Doodle link provided. Br, Gerg0 Sent from Nine ________________________________ From: Remo Mattei Sent: Thursday, June 7, 2018 6:08 PM To: Csatari, Gergely (Nokia - HU/Budapest) Cc: edge-computing at lists.openstack.org Subject: Re: [Edge-computing] Doodle for next Review of Dublin edge notes meeting Hi guys, What time next week? Sorry I missed this week crazy trying to go production with OpenStack On Jun 7, 2018, at 4:10 AM, Csatari, Gergely (Nokia - HU/Budapest) > wrote: Hi, Let’s try to continue from 5.3 next week. [1]. [1]: https://doodle.com/poll/v7qse7fqr2azy2zi Br, Gerg0 From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Wednesday, May 16, 2018 1:10 PM To: 'edge-computing at lists.openstack.org' > Subject: RE: Doodle for next Review of Dublin edge notes meeting Hi, I could not find any time with more than 2 okays, so let’s not continue this week. We can use the remainig time of the Edge Computing BoF [1] if there will be any. Br, Gerg0 [1]: https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21685/edge-computing-group-bof From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Friday, May 11, 2018 5:17 PM To: 'edge-computing at lists.openstack.org' > Subject: Doodle for next Review of Dublin edge notes meeting Hi, Let’s not stop the fun and try to sqeeze one more review meeting before Vancouver. https://doodle.com/poll/rw7fhsm3vpbbxce4 Br, Gerg0 _______________________________________________ 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 Fri Jun 8 07:39:25 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Fri, 8 Jun 2018 07:39:25 +0000 Subject: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation In-Reply-To: <54898258-0FC0-46F3-9C64-FE4CEEA2B78C@windriver.com> References: <54898258-0FC0-46F3-9C64-FE4CEEA2B78C@windriver.com> Message-ID: 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? * 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. * 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. * * 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? Here is the updated wiki: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment 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 amotoki at gmail.com Fri Jun 8 08:14:35 2018 From: amotoki at gmail.com (Akihiro Motoki) Date: Fri, 8 Jun 2018 17:14:35 +0900 Subject: [Edge-computing] [Openstack-sigs] [OpenStack-I18n] Edge Computing Whitepaper Translation In-Reply-To: References: <20180529135041.cyjrl3vtpwajhicq@yuggoth.org> <558F16D9-EB0A-421F-8832-B2DE320E5555@gmail.com> Message-ID: Hi all, # I added edge-computing ML as the edge computing team uses a separate list other than the SIG ML. # The original discussion happened in openstack-sigs ML. I just forgot to add the edge ML. What is the next step of the translation of the edge computing white paper with RST? My temporary translation publishing [1] should not be published as-is due to the CC BY-ND license. This is to prove how it works. I would like to move this forward and am happy to help the setup of a repo if needed. Where can we discuss this? The edge computing group meeting is not listed at http://eavesdrop.openstack.org/ and I don't know when and where it happens. [1] https://amotoki.github.io/edge-computing-whitepaper/ Thanks, Akihiro 2018年5月29日(火) 23:37 Akihiro Motoki : > Hi Ildiko and all, > > I am happy to hear that HTML-based publishing is now on the table :) > I am synced with Ian and Frank on this topic, though I failed to join the > conversation at Vancouver. > RST based process is used much in the community and translation > publishinng of project docs which Ian and us are working on will make the > continuous publishing easier. > I am happy to help setting up a new doc infrastructure and/or publishing > translations. > > Regarding the license, CC BY-ND license turned out a bit too strict in our > collaborative works when I checked the current one. > Hopefully we can get a good conclusion for further similar cases. > > Thanks, > Akihiro > > > > 2018年5月29日(火) 23:19 Ildiko Vancsa : > >> Hi Akihiro and All, >> >> Thank you for your efforts on helping with publishing the white paper in >> additional languages. >> >> I talked to Ian and Frank last week about this topic and the conundrum on >> the Foundation side whether or not to do the print version for the >> translations as that is what slows down the process a lot due to the design >> work it requires. >> >> We got to the conclusion with our team from the Foundation (cc’ed >> Allison, Jimmy and Wes) to do HTML-based publishing to reduce this >> overhead. We need to clarify now on the process and as Jeremy indicated the >> licensing as well. >> >> Thanks, >> Ildikó >> >> >> > On 2018. May 29., at 15:50, Jeremy Stanley wrote: >> > >> > On 2018-05-29 18:50:23 +0900 (+0900), Akihiro Motoki wrote: >> > [...] >> >> NOTE: Anyway I need to grant it from the foundation because CC >> >> Attribution-NoDerivatives 4.0 International license does not allow >> >> me to share translations without permission. I updated this files >> >> only for discussion and will close this soon. >> > [...] >> > >> > It seems like this is a really poor choice of license as it's >> > impairing open collaboration. Even Creative Commons suggests that >> > the CC BY-ND license is unsuitable for free cultural works: >> > >> > https://creativecommons.org/share-your-work/public-domain/freeworks/ >> > >> > We should see about getting this changed to CC BY like is used for >> > other collaborative works produced by our community. >> > -- >> > Jeremy Stanley >> > _______________________________________________ >> > openstack-sigs mailing list >> > openstack-sigs at lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> >> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Fri Jun 8 09:23:00 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Fri, 8 Jun 2018 09:23:00 +0000 Subject: [Edge-computing] Keystone Edge Architectures In-Reply-To: <77FE167D-B416-4C8C-9D83-E34779D394B3@windriver.com> References: <678C1A99-2302-438D-8D5D-91ED44B10FF9@windriver.com> <77FE167D-B416-4C8C-9D83-E34779D394B3@windriver.com> Message-ID: Hi, Thanks for the answer. According to my understanding this is what we tried to describe in the first option. I’ve also added the list of synched data to the wiki: https://wiki.openstack.org/wiki/Keystone_edge_architectures#Replicated_data Is the replication service part of the open sourced StarlingX? Thanks, Gerg0 From: Waines, Greg [mailto:Greg.Waines at windriver.com] Sent: Thursday, June 7, 2018 1:37 PM To: Csatari, Gergely (Nokia - HU/Budapest) ; edge-computing at lists.openstack.org Subject: Re: [Edge-computing] Keystone Edge Architectures Hey Gergely, Wrt High-Level journaling/synchronization ... I really mean * We are NOT doing some low-level semantic-unaware DB synchronization, * Instead we are doing a more high level, semantic-aware replication of Keystone Resources from the Central Site to ALL the Edge Clouds * we are generally replicating REST API commands for creating/modifying/deleting Keystone Resources between Central Site and ALL the Edge Clouds * although more sophisticated than that, as it supports retries on failures and audits of resources to handle scenarios where Edge Clouds are disconnected during changes to the Central Site, etc. * the Keystone Resources we are currently synchronizing are: Users, Projects, Roles and Assignments * ... should be doing Groups and Domains as well ... but currently don’t leverage User Groups and only have default Domain in StarlingX * and, will also synchronize Fernet keys so that tokens created on any cloud can be used/validated on any cloud. * This is built on a common synchronization framework for providing common utilities / mechanisms for broadcast of messages to all Edge Clouds, retries, audits, etc * E.g. we use this framework for also synchronizing * Nova’s – flavors, flavor extra-specs, keypairs, quotas * Neutron’s – security groups, security group rules * Cinder’s - quotas Greg. From: "Csatari, Gergely (Nokia - HU/Budapest)" > Date: Thursday, June 7, 2018 at 4:15 AM To: Greg Waines >, "edge-computing at lists.openstack.org" > Subject: RE: [Edge-computing] Keystone Edge Architectures Hi, What do you mean by high level journaling / syncrronsation? For me one of the basic differences between option 1 and 2 is the understanding of the data semantics during the synchronisaiton in case of option 1 and synchronising blobs of data in case of option 2. Can you share what data do you synchronise between the Keystone instances? This is also a piece of information what we are looking for. Thanks, Gerg0 From: Waines, Greg [mailto:Greg.Waines at windriver.com] Sent: Wednesday, June 6, 2018 3:44 PM To: edge-computing at lists.openstack.org Subject: [Edge-computing] Keystone Edge Architectures Hey ... just taking a look at the options in https://wiki.openstack.org/wiki/Keystone_edge_architectures . For the first option, i.e. ‘Several keystone instances with federation with API synchronsation’ * I am assuming that the Keystone Instance at each Edge Cloud Instance is communicating with a non-local central Identity Provider * If this is the case, the concern list above related to operability with no connectivity * i.e. “There may be significant times with no connectivity and all functions (e.g. autoscaling) must continue to function” In the ‘Distributed Cloud’ sub-project of the StarlingX project ( i.e. see summit presentation @ https://www.openstack.org/videos/vancouver-2018/edge-computing-operations-day-1-deployment-and-day-2-management ) * our initial keystone approach is simply the standard multi-region centralized shared keystone, so no scalability and no autonomy for edge clouds on loss of connectivity, * * BUT we are currently taking more of the ‘second option’ approach (i.e. ‘Keystone database replication’) ... with some additions i.e. * Every Edge Cloud instance runs its own keystone instance, * Keystone resources are replicated from central site to edge clouds using our distribute-cloud-replication-framework, * i.e. projects, users, groups, domains, roles, ... * ( i.e. not a low-level DB synchronization ... more a high-level journaling / synchronization of resources ) * AND * Also supporting Fernet Key synchronization and management across Edge Clouds in order to enable Tokens created at any Edge / Central cloud being able to be used (and authenticated) in any other clouds. * Required for some distributed services scenarios, e.g. glance-api pulling from a remote glance-registry, etc. (likely for future scenarios we don’t currently understand). Comments ? Greg. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Greg.Waines at windriver.com Fri Jun 8 11:45:55 2018 From: Greg.Waines at windriver.com (Waines, Greg) Date: Fri, 8 Jun 2018 11:45:55 +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> Message-ID: 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 Fri Jun 8 12:31:15 2018 From: Greg.Waines at windriver.com (Waines, Greg) Date: Fri, 8 Jun 2018 12:31:15 +0000 Subject: [Edge-computing] Keystone Edge Architectures In-Reply-To: References: <678C1A99-2302-438D-8D5D-91ED44B10FF9@windriver.com> <77FE167D-B416-4C8C-9D83-E34779D394B3@windriver.com> Message-ID: Responses in-lined below, Greg. From: "Csatari, Gergely (Nokia - HU/Budapest)" Date: Friday, June 8, 2018 at 5:23 AM To: Greg Waines , "edge-computing at lists.openstack.org" Subject: RE: [Edge-computing] Keystone Edge Architectures Hi, Thanks for the answer. According to my understanding this is what we tried to describe in the first option. [Greg] Ok ... maybe this is me not understanding what ‘federated’ keystone is. My understanding of federated keystone ( please correct me if I am wrong ): · All clouds run a Keystone Instance (service provider) · But all Keystone Instances leverage the same remote IdentityProvider as the backend for User Authentication o i.e. there is a single remote IdentityProvider with all the user credentials · The Keystone Instances in each cloud must have the MAPPINGs between IdentityProvider user & SAML Assertions - to – Keystone Project/User/Token/etc. So is the “API Synchronization” that you mention in this first option, referring to the synchronization of these MAPPINGs ? We are NOT using keystone federation in StarlingX. Maybe what we are doing in StarlingX is a fourth option. Similar to Option 2 – “Keystone database replication” .... but using an “API-based synchronization” and Fernet Key Synchronization to enable use of Tokens across all clouds. e.g. Option 4 – Keystone API Synchronization & Fernet Key Synchronization · Every Edge Cloud instance runs its own keystone instance, · Keystone resources are replicated from central site to edge clouds using API-based Synchronization, o i.e. projects, users, groups, domains, ... · Also supporting Fernet Key synchronization and management across Edge Clouds in order to enable Tokens created at any Edge / Central cloud being able to be used (and authenticated) in any other clouds. I’ve also added the list of synched data to the wiki: https://wiki.openstack.org/wiki/Keystone_edge_architectures#Replicated_data [Greg] And you probably want to put an asterisk (*) by the Quotas items, as similar to Kingbird, we dynamically manage quotas across the Edge Clouds in order to provide Quotas at the Distributed Cloud Level. I.e. a project that has a quota of 10 instances, can only create 10 instances across ALL Edge Clouds; NOT 10 instances per Edge Cloud. Is the replication service part of the open sourced StarlingX? [Greg] Yes. Thanks, Gerg0 From: Waines, Greg [mailto:Greg.Waines at windriver.com] Sent: Thursday, June 7, 2018 1:37 PM To: Csatari, Gergely (Nokia - HU/Budapest) ; edge-computing at lists.openstack.org Subject: Re: [Edge-computing] Keystone Edge Architectures Hey Gergely, Wrt High-Level journaling/synchronization ... I really mean * We are NOT doing some low-level semantic-unaware DB synchronization, * Instead we are doing a more high level, semantic-aware replication of Keystone Resources from the Central Site to ALL the Edge Clouds * we are generally replicating REST API commands for creating/modifying/deleting Keystone Resources between Central Site and ALL the Edge Clouds * although more sophisticated than that, as it supports retries on failures and audits of resources to handle scenarios where Edge Clouds are disconnected during changes to the Central Site, etc. * the Keystone Resources we are currently synchronizing are: Users, Projects, Roles and Assignments * ... should be doing Groups and Domains as well ... but currently don’t leverage User Groups and only have default Domain in StarlingX * and, will also synchronize Fernet keys so that tokens created on any cloud can be used/validated on any cloud. * This is built on a common synchronization framework for providing common utilities / mechanisms for broadcast of messages to all Edge Clouds, retries, audits, etc * E.g. we use this framework for also synchronizing * Nova’s – flavors, flavor extra-specs, keypairs, quotas * Neutron’s – security groups, security group rules * Cinder’s - quotas Greg. From: "Csatari, Gergely (Nokia - HU/Budapest)" > Date: Thursday, June 7, 2018 at 4:15 AM To: Greg Waines >, "edge-computing at lists.openstack.org" > Subject: RE: [Edge-computing] Keystone Edge Architectures Hi, What do you mean by high level journaling / syncrronsation? For me one of the basic differences between option 1 and 2 is the understanding of the data semantics during the synchronisaiton in case of option 1 and synchronising blobs of data in case of option 2. Can you share what data do you synchronise between the Keystone instances? This is also a piece of information what we are looking for. Thanks, Gerg0 From: Waines, Greg [mailto:Greg.Waines at windriver.com] Sent: Wednesday, June 6, 2018 3:44 PM To: edge-computing at lists.openstack.org Subject: [Edge-computing] Keystone Edge Architectures Hey ... just taking a look at the options in https://wiki.openstack.org/wiki/Keystone_edge_architectures . For the first option, i.e. ‘Several keystone instances with federation with API synchronsation’ * I am assuming that the Keystone Instance at each Edge Cloud Instance is communicating with a non-local central Identity Provider * If this is the case, the concern list above related to operability with no connectivity * i.e. “There may be significant times with no connectivity and all functions (e.g. autoscaling) must continue to function” In the ‘Distributed Cloud’ sub-project of the StarlingX project ( i.e. see summit presentation @ https://www.openstack.org/videos/vancouver-2018/edge-computing-operations-day-1-deployment-and-day-2-management ) * our initial keystone approach is simply the standard multi-region centralized shared keystone, so no scalability and no autonomy for edge clouds on loss of connectivity, * * BUT we are currently taking more of the ‘second option’ approach (i.e. ‘Keystone database replication’) ... with some additions i.e. * Every Edge Cloud instance runs its own keystone instance, * Keystone resources are replicated from central site to edge clouds using our distribute-cloud-replication-framework, * i.e. projects, users, groups, domains, roles, ... * ( i.e. not a low-level DB synchronization ... more a high-level journaling / synchronization of resources ) * AND * Also supporting Fernet Key synchronization and management across Edge Clouds in order to enable Tokens created at any Edge / Central cloud being able to be used (and authenticated) in any other clouds. * Required for some distributed services scenarios, e.g. glance-api pulling from a remote glance-registry, etc. (likely for future scenarios we don’t currently understand). Comments ? Greg. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekuvaja at redhat.com Fri Jun 8 13:17:46 2018 From: ekuvaja at redhat.com (Erno Kuvaja) Date: Fri, 8 Jun 2018 14:17:46 +0100 Subject: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation In-Reply-To: References: Message-ID: Hi, Answering inline. Best, Erno "jokke" Kuvaja On Thu, Jun 7, 2018 at 11:49 AM, Csatari, Gergely (Nokia - HU/Budapest) wrote: > 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? glance_store library > How is it possible to implement location aware synchronisation (synchronise > images only to those cloud instances where they are needed)? This needs bit of hooking. We need to update the locations into Glance once the replication has happened. > Is it possible to have different OpenStack versions in the different cloud > instances? In my understanding it's not supported to mix versions within OpenStack cloud apart from during upgrade. > Can a cloud instance use the locally synchronised images in case of a > network connection break? That depends a lot of the implementation. If there is local glance node with replicated db and store, yes. > Is it possible to implement this without storing database credentials ont he > edge cloud instances? Again depending of the deployment. You definitely cannot have both, access during network outage and access without db credentials. if one needs to have local access of images without db credentials, there is always possibility for the local Ceph back-end with remote glance-api node. In this case Nova can talk directly to the local Ceph back-end and communicate with centralized glance-api that has the credentials to the db. The problem with loosing the network in this scenario is that Nova will have no idea if the user has rights to use the image or not and it will not know the path to that image's data. > > > > 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 > > > _______________________________________________ > Edge-computing mailing list > Edge-computing at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing > From ildiko.vancsa at gmail.com Fri Jun 8 16:16:32 2018 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Fri, 8 Jun 2018 18:16:32 +0200 Subject: [Edge-computing] [Openstack-sigs] [OpenStack-I18n] Edge Computing Whitepaper Translation In-Reply-To: References: <20180529135041.cyjrl3vtpwajhicq@yuggoth.org> <558F16D9-EB0A-421F-8832-B2DE320E5555@gmail.com> Message-ID: <297D0BCC-4EB7-401E-883D-EC5D3BDE1C59@gmail.com> Hi Akihiro, It is on our priority list to put up the translated versions in an online format as well as work out to have the .po files available. Jimmy is looking into it and will give an update once we got some progress. Thanks and Best Regards, Ildikó > On 2018. Jun 8., at 10:14, Akihiro Motoki wrote: > > Hi all, > > # I added edge-computing ML as the edge computing team uses a separate list other than the SIG ML. > # The original discussion happened in openstack-sigs ML. I just forgot to add the edge ML. > > What is the next step of the translation of the edge computing white paper with RST? > My temporary translation publishing [1] should not be published as-is due to the CC BY-ND license. This is to prove how it works. > I would like to move this forward and am happy to help the setup of a repo if needed. > > Where can we discuss this? > The edge computing group meeting is not listed at http://eavesdrop.openstack.org/ and I don't know when and where it happens. > > [1] https://amotoki.github.io/edge-computing-whitepaper/ > > Thanks, > Akihiro > > 2018年5月29日(火) 23:37 Akihiro Motoki : > Hi Ildiko and all, > > I am happy to hear that HTML-based publishing is now on the table :) > I am synced with Ian and Frank on this topic, though I failed to join the conversation at Vancouver. > RST based process is used much in the community and translation publishinng of project docs which Ian and us are working on will make the continuous publishing easier. > I am happy to help setting up a new doc infrastructure and/or publishing translations. > > Regarding the license, CC BY-ND license turned out a bit too strict in our collaborative works when I checked the current one. > Hopefully we can get a good conclusion for further similar cases. > > Thanks, > Akihiro > > > > 2018年5月29日(火) 23:19 Ildiko Vancsa : > Hi Akihiro and All, > > Thank you for your efforts on helping with publishing the white paper in additional languages. > > I talked to Ian and Frank last week about this topic and the conundrum on the Foundation side whether or not to do the print version for the translations as that is what slows down the process a lot due to the design work it requires. > > We got to the conclusion with our team from the Foundation (cc’ed Allison, Jimmy and Wes) to do HTML-based publishing to reduce this overhead. We need to clarify now on the process and as Jeremy indicated the licensing as well. > > Thanks, > Ildikó > > > > On 2018. May 29., at 15:50, Jeremy Stanley wrote: > > > > On 2018-05-29 18:50:23 +0900 (+0900), Akihiro Motoki wrote: > > [...] > >> NOTE: Anyway I need to grant it from the foundation because CC > >> Attribution-NoDerivatives 4.0 International license does not allow > >> me to share translations without permission. I updated this files > >> only for discussion and will close this soon. > > [...] > > > > It seems like this is a really poor choice of license as it's > > impairing open collaboration. Even Creative Commons suggests that > > the CC BY-ND license is unsuitable for free cultural works: > > > > https://creativecommons.org/share-your-work/public-domain/freeworks/ > > > > We should see about getting this changed to CC BY like is used for > > other collaborative works produced by our community. > > -- > > Jeremy Stanley > > _______________________________________________ > > openstack-sigs mailing list > > openstack-sigs at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > _______________________________________________ > Edge-computing mailing list > Edge-computing at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing From jimmy at openstack.org Fri Jun 8 17:00:13 2018 From: jimmy at openstack.org (Jimmy McArthur) Date: Fri, 08 Jun 2018 12:00:13 -0500 Subject: [Edge-computing] [Openstack-sigs] [OpenStack-I18n] Edge Computing Whitepaper Translation In-Reply-To: <297D0BCC-4EB7-401E-883D-EC5D3BDE1C59@gmail.com> References: <20180529135041.cyjrl3vtpwajhicq@yuggoth.org> <558F16D9-EB0A-421F-8832-B2DE320E5555@gmail.com> <297D0BCC-4EB7-401E-883D-EC5D3BDE1C59@gmail.com> Message-ID: <5B1AB61D.409@openstack.org> We are currently targeting June 25 for the initial version of the Edge whitepaper. However, I'll know more by EOW next. Cheers, Jimmy Ildiko Vancsa wrote: > Hi Akihiro, > > It is on our priority list to put up the translated versions in an online format as well as work out to have the .po files available. > > Jimmy is looking into it and will give an update once we got some progress. > > Thanks and Best Regards, > Ildikó > > >> On 2018. Jun 8., at 10:14, Akihiro Motoki wrote: >> >> Hi all, >> >> # I added edge-computing ML as the edge computing team uses a separate list other than the SIG ML. >> # The original discussion happened in openstack-sigs ML. I just forgot to add the edge ML. >> >> What is the next step of the translation of the edge computing white paper with RST? >> My temporary translation publishing [1] should not be published as-is due to the CC BY-ND license. This is to prove how it works. >> I would like to move this forward and am happy to help the setup of a repo if needed. >> >> Where can we discuss this? >> The edge computing group meeting is not listed at http://eavesdrop.openstack.org/ and I don't know when and where it happens. >> >> [1] https://amotoki.github.io/edge-computing-whitepaper/ >> >> Thanks, >> Akihiro >> >> 2018年5月29日(火) 23:37 Akihiro Motoki: >> Hi Ildiko and all, >> >> I am happy to hear that HTML-based publishing is now on the table :) >> I am synced with Ian and Frank on this topic, though I failed to join the conversation at Vancouver. >> RST based process is used much in the community and translation publishinng of project docs which Ian and us are working on will make the continuous publishing easier. >> I am happy to help setting up a new doc infrastructure and/or publishing translations. >> >> Regarding the license, CC BY-ND license turned out a bit too strict in our collaborative works when I checked the current one. >> Hopefully we can get a good conclusion for further similar cases. >> >> Thanks, >> Akihiro >> >> >> >> 2018年5月29日(火) 23:19 Ildiko Vancsa: >> Hi Akihiro and All, >> >> Thank you for your efforts on helping with publishing the white paper in additional languages. >> >> I talked to Ian and Frank last week about this topic and the conundrum on the Foundation side whether or not to do the print version for the translations as that is what slows down the process a lot due to the design work it requires. >> >> We got to the conclusion with our team from the Foundation (cc’ed Allison, Jimmy and Wes) to do HTML-based publishing to reduce this overhead. We need to clarify now on the process and as Jeremy indicated the licensing as well. >> >> Thanks, >> Ildikó >> >> >>> On 2018. May 29., at 15:50, Jeremy Stanley wrote: >>> >>> On 2018-05-29 18:50:23 +0900 (+0900), Akihiro Motoki wrote: >>> [...] >>>> NOTE: Anyway I need to grant it from the foundation because CC >>>> Attribution-NoDerivatives 4.0 International license does not allow >>>> me to share translations without permission. I updated this files >>>> only for discussion and will close this soon. >>> [...] >>> >>> It seems like this is a really poor choice of license as it's >>> impairing open collaboration. Even Creative Commons suggests that >>> the CC BY-ND license is unsuitable for free cultural works: >>> >>> https://creativecommons.org/share-your-work/public-domain/freeworks/ >>> >>> We should see about getting this changed to CC BY like is used for >>> other collaborative works produced by our community. >>> -- >>> Jeremy Stanley >>> _______________________________________________ >>> openstack-sigs mailing list >>> openstack-sigs at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> _______________________________________________ >> 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 Jun 11 08:15:29 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Mon, 11 Jun 2018 08:15:29 +0000 Subject: [Edge-computing] Review of Dublin edge notes 04 Message-ID: Hi, Let's continue the IRC meeting to discuss the comments to the Dublin edge notes: https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG 5.3 Requirements . Notes of the previous meetings: * 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: 5524 bytes Desc: not available URL: From gergely.csatari at nokia.com Mon Jun 11 10:44:20 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Mon, 11 Jun 2018 10:44:20 +0000 Subject: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation In-Reply-To: References: Message-ID: Hi, Going inline. -----Original Message----- From: Erno Kuvaja [mailto:ekuvaja at redhat.com] Sent: Friday, June 8, 2018 3:18 PM Hi, Answering inline. Best, Erno "jokke" Kuvaja On Thu, Jun 7, 2018 at 11:49 AM, Csatari, Gergely (Nokia - HU/Budapest) wrote: > 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? glance_store library > How is it possible to implement location aware synchronisation > (synchronise images only to those cloud instances where they are needed)? This needs bit of hooking. We need to update the locations into Glance once the replication has happened. [G0]: Okay, but how to avoid the replication to sites where the image is not needed? > Is it possible to have different OpenStack versions in the different > cloud instances? In my understanding it's not supported to mix versions within OpenStack cloud apart from during upgrade. [G0]: Understood. This might be a problem ont he long run. With lots of edge cloud instance it can not be guaranteed, that all of them are upgraded in one go. > Can a cloud instance use the locally synchronised images in case of a > network connection break? That depends a lot of the implementation. If there is local glance node with replicated db and store, yes. [G0]: So we need a replicated Glance DB, a store and a backend in every edge cloud instance for this? How the database would be syncronised in this case? > Is it possible to implement this without storing database credentials > ont he edge cloud instances? Again depending of the deployment. You definitely cannot have both, access during network outage and access without db credentials. if one needs to have local access of images without db credentials, there is always possibility for the local Ceph back-end with remote glance-api node. In this case Nova can talk directly to the local Ceph back-end and communicate with centralized glance-api that has the credentials to the db. The problem with loosing the network in this scenario is that Nova will have no idea if the user has rights to use the image or not and it will not know the path to that image's data. [G0]: Okay > 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 [G0]: Please add your availability here. Thanks, Gerg0 > > > > 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 > > > _______________________________________________ > 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 Mon Jun 11 11:32:44 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Mon, 11 Jun 2018 11:32:44 +0000 Subject: [Edge-computing] Keystone Edge Architectures In-Reply-To: References: <678C1A99-2302-438D-8D5D-91ED44B10FF9@windriver.com> <77FE167D-B416-4C8C-9D83-E34779D394B3@windriver.com> Message-ID: Hi, Thanks for the answers. I’ve added a 4th option and the note to the Quotas. https://wiki.openstack.org/wiki/Keystone_edge_architectures Br, Gerg0 From: Waines, Greg [mailto:Greg.Waines at windriver.com] Sent: Friday, June 8, 2018 2:31 PM To: Csatari, Gergely (Nokia - HU/Budapest) ; edge-computing at lists.openstack.org Subject: Re: [Edge-computing] Keystone Edge Architectures Responses in-lined below, Greg. From: "Csatari, Gergely (Nokia - HU/Budapest)" > Date: Friday, June 8, 2018 at 5:23 AM To: Greg Waines >, "edge-computing at lists.openstack.org" > Subject: RE: [Edge-computing] Keystone Edge Architectures Hi, Thanks for the answer. According to my understanding this is what we tried to describe in the first option. [Greg] Ok ... maybe this is me not understanding what ‘federated’ keystone is. My understanding of federated keystone ( please correct me if I am wrong ): * All clouds run a Keystone Instance (service provider) * But all Keystone Instances leverage the same remote IdentityProvider as the backend for User Authentication * i.e. there is a single remote IdentityProvider with all the user credentials * The Keystone Instances in each cloud must have the MAPPINGs between IdentityProvider user & SAML Assertions - to – Keystone Project/User/Token/etc. So is the “API Synchronization” that you mention in this first option, referring to the synchronization of these MAPPINGs ? We are NOT using keystone federation in StarlingX. Maybe what we are doing in StarlingX is a fourth option. Similar to Option 2 – “Keystone database replication” .... but using an “API-based synchronization” and Fernet Key Synchronization to enable use of Tokens across all clouds. e.g. Option 4 – Keystone API Synchronization & Fernet Key Synchronization * Every Edge Cloud instance runs its own keystone instance, * Keystone resources are replicated from central site to edge clouds using API-based Synchronization, * i.e. projects, users, groups, domains, ... * Also supporting Fernet Key synchronization and management across Edge Clouds in order to enable Tokens created at any Edge / Central cloud being able to be used (and authenticated) in any other clouds. I’ve also added the list of synched data to the wiki: https://wiki.openstack.org/wiki/Keystone_edge_architectures#Replicated_data [Greg] And you probably want to put an asterisk (*) by the Quotas items, as similar to Kingbird, we dynamically manage quotas across the Edge Clouds in order to provide Quotas at the Distributed Cloud Level. I.e. a project that has a quota of 10 instances, can only create 10 instances across ALL Edge Clouds; NOT 10 instances per Edge Cloud. Is the replication service part of the open sourced StarlingX? [Greg] Yes. Thanks, Gerg0 From: Waines, Greg [mailto:Greg.Waines at windriver.com] Sent: Thursday, June 7, 2018 1:37 PM To: Csatari, Gergely (Nokia - HU/Budapest) >; edge-computing at lists.openstack.org Subject: Re: [Edge-computing] Keystone Edge Architectures Hey Gergely, Wrt High-Level journaling/synchronization ... I really mean * We are NOT doing some low-level semantic-unaware DB synchronization, * Instead we are doing a more high level, semantic-aware replication of Keystone Resources from the Central Site to ALL the Edge Clouds * we are generally replicating REST API commands for creating/modifying/deleting Keystone Resources between Central Site and ALL the Edge Clouds * although more sophisticated than that, as it supports retries on failures and audits of resources to handle scenarios where Edge Clouds are disconnected during changes to the Central Site, etc. * the Keystone Resources we are currently synchronizing are: Users, Projects, Roles and Assignments * ... should be doing Groups and Domains as well ... but currently don’t leverage User Groups and only have default Domain in StarlingX * and, will also synchronize Fernet keys so that tokens created on any cloud can be used/validated on any cloud. * This is built on a common synchronization framework for providing common utilities / mechanisms for broadcast of messages to all Edge Clouds, retries, audits, etc * E.g. we use this framework for also synchronizing * Nova’s – flavors, flavor extra-specs, keypairs, quotas * Neutron’s – security groups, security group rules * Cinder’s - quotas Greg. From: "Csatari, Gergely (Nokia - HU/Budapest)" > Date: Thursday, June 7, 2018 at 4:15 AM To: Greg Waines >, "edge-computing at lists.openstack.org" > Subject: RE: [Edge-computing] Keystone Edge Architectures Hi, What do you mean by high level journaling / syncrronsation? For me one of the basic differences between option 1 and 2 is the understanding of the data semantics during the synchronisaiton in case of option 1 and synchronising blobs of data in case of option 2. Can you share what data do you synchronise between the Keystone instances? This is also a piece of information what we are looking for. Thanks, Gerg0 From: Waines, Greg [mailto:Greg.Waines at windriver.com] Sent: Wednesday, June 6, 2018 3:44 PM To: edge-computing at lists.openstack.org Subject: [Edge-computing] Keystone Edge Architectures Hey ... just taking a look at the options in https://wiki.openstack.org/wiki/Keystone_edge_architectures . For the first option, i.e. ‘Several keystone instances with federation with API synchronsation’ * I am assuming that the Keystone Instance at each Edge Cloud Instance is communicating with a non-local central Identity Provider * If this is the case, the concern list above related to operability with no connectivity * i.e. “There may be significant times with no connectivity and all functions (e.g. autoscaling) must continue to function” In the ‘Distributed Cloud’ sub-project of the StarlingX project ( i.e. see summit presentation @ https://www.openstack.org/videos/vancouver-2018/edge-computing-operations-day-1-deployment-and-day-2-management ) * our initial keystone approach is simply the standard multi-region centralized shared keystone, so no scalability and no autonomy for edge clouds on loss of connectivity, * * BUT we are currently taking more of the ‘second option’ approach (i.e. ‘Keystone database replication’) ... with some additions i.e. * Every Edge Cloud instance runs its own keystone instance, * Keystone resources are replicated from central site to edge clouds using our distribute-cloud-replication-framework, * i.e. projects, users, groups, domains, roles, ... * ( i.e. not a low-level DB synchronization ... more a high-level journaling / synchronization of resources ) * AND * Also supporting Fernet Key synchronization and management across Edge Clouds in order to enable Tokens created at any Edge / Central cloud being able to be used (and authenticated) in any other clouds. * Required for some distributed services scenarios, e.g. glance-api pulling from a remote glance-registry, etc. (likely for future scenarios we don’t currently understand). Comments ? Greg. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Mon Jun 11 14:28:54 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Mon, 11 Jun 2018 14:28:54 +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> Message-ID: 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 ildiko at openstack.org Tue Jun 12 10:27:59 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Tue, 12 Jun 2018 12:27:59 +0200 Subject: [Edge-computing] Find an alternate APAC friendly time slot for the meeting call Message-ID: <29C12068-7DFF-4F48-AD36-67572776CB60@openstack.org> Hi All, Our current time slot for the Edge computing group call is in an inconvenient time for people in the APAC region. It would be great to find an alternating time slot to have the call once a month. I created a Doodle poll to see whether we can do better on that regard: https://doodle.com/poll/7vswvnyczuxeh966 __I would like to ask everyone to ignore the exact dates when you fill out the form as we are trying to find an alternating slot that works long term.__ If you know anyone who might not be on this list, but would be interested in participating please forward the Doodle link to them. Thanks and Best Regards, Ildikó From ildiko at openstack.org Tue Jun 12 13:16:37 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Tue, 12 Jun 2018 15:16:37 +0200 Subject: [Edge-computing] Meeting reminder Message-ID: Hi All, It is a friendly reminder that we have our next call in less than 45 minutes. You can find the agenda and details on the wiki: https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings Thanks and Best Regards, Ildikó From gergely.csatari at nokia.com Tue Jun 12 15:01:34 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Tue, 12 Jun 2018 15:01:34 +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, Minutes: http://eavesdrop.openstack.org/meetings/weekly_edge_computing_group_call/2018/weekly_edge_computing_group_call.2018-06-12-14.05.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únius 12 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 jess.lampe at gmail.com Tue Jun 12 15:02:49 2018 From: jess.lampe at gmail.com (Jess Lampe) Date: Tue, 12 Jun 2018 08:02:49 -0700 Subject: [Edge-computing] Use Case Studies Message-ID: *Goal of Use Case Sub Groups* - Capture known use cases in the - Continue to add new use cases as they are discovered. - Derive known use cases from captured use cases and add to story board. *Doodle for Standing Meeting* I added a doodle for available times. https://doodle.com/poll/wnmmstbrtmfgw5yc *Ongoing requests* - If you have a known use case, please add it to the use case wiki. - If you have an expert who would like to speak on a use case (like Giovanni did today, please sign up on the etherpad -------------- next part -------------- An HTML attachment was scrubbed... URL: From claire at openstack.org Tue Jun 12 17:26:15 2018 From: claire at openstack.org (Claire Massey) Date: Tue, 12 Jun 2018 12:26:15 -0500 Subject: [Edge-computing] Berlin Summit CFP Deadline July 17 Message-ID: <92FA72CB-E0AD-4EA4-B1A6-97CAA9F9CC67@openstack.org> Hi everyone, The Call for Presentations is open for the Berlin Summit , November 13-15. The deadline to submit your presentation is July 17. At the Vancouver Summit, we focused on open infrastructure integration as the Summit has evolved over the years to cover more than just OpenStack. We had over 30 different projects from the open infrastructure community join, including Kubernetes, Docker, Ansible, OpenShift and many more. The Tracks were organized around specific use cases and will remain the same for Berlin with the addition of Hands on Workshops as its own dedicated Track. We encourage you to submit presentations covering the open infrastructure tools you’re using, as well as the integration work needed to address these use cases. We also encourage you to invite peers from other open source communities to speak and collaborate. The Tracks are: • CI/CD • Container Infrastructure • Edge Computing • Hands on Workshops • HPC / GPU / AI • Open Source Community • Private & Hybrid Cloud • Public Cloud • Telecom & NFV 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. If you’re interested in nominating yourself or someone else to be a member of the Summit Programming Committee for a specific Track, please fill out the nomination form . Nominations will close on June 28. Again, the deadline to submit proposals is July 17. Please note topic submissions for the OpenStack Forum (planning/working sessions with OpenStack devs and operators) will open at a later date. The Early Bird registration deadline will be in mid August. We’re working hard to make it the best Summit yet, and look forward to bringing together different open infrastructure communities to solve these hard problems together. Want to provide feedback on this process? Please focus discussion on the openstack-community mailing list, or contact the Summit Team directly at summit at openstack.org . Thanks, Claire -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Wed Jun 13 09:22:34 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Wed, 13 Jun 2018 09:22:34 +0000 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion_of_Requirements?= In-Reply-To: <5116516a346943bead676c16be75cea5@AUSX13MPS308.AMER.DELL.COM> References: <2100552307.166806266.1528269870731.JavaMail.root@zimbra29-e5.priv.proxad.net> <010501d3fd76$97c84890$c758d9b0$@chinamobile.com> <820A8FF6-0412-41DC-AC30-E49A210389B7@b-yond.com> <011b01d3fd99$456077d0$d0216770$@chinamobile.com> <5116516a346943bead676c16be75cea5@AUSX13MPS308.AMER.DELL.COM> Message-ID: 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 From Arkady.Kanevsky at dell.com Wed Jun 13 14:24:09 2018 From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com) Date: Wed, 13 Jun 2018 14:24:09 +0000 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion_of_Requirements?= In-Reply-To: References: <2100552307.166806266.1528269870731.JavaMail.root@zimbra29-e5.priv.proxad.net> <010501d3fd76$97c84890$c758d9b0$@chinamobile.com> <820A8FF6-0412-41DC-AC30-E49A210389B7@b-yond.com> <011b01d3fd99$456077d0$d0216770$@chinamobile.com> <5116516a346943bead676c16be75cea5@AUSX13MPS308.AMER.DELL.COM> Message-ID: <52a103f1f4b24dc6ac96a9ebc71110b2@AUSX13MPS308.AMER.DELL.COM> 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 From gergely.csatari at nokia.com Wed Jun 13 15:38:35 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Wed, 13 Jun 2018 15:38:35 +0000 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion_of_Requirements?= In-Reply-To: <52a103f1f4b24dc6ac96a9ebc71110b2@AUSX13MPS308.AMER.DELL.COM> References: <2100552307.166806266.1528269870731.JavaMail.root@zimbra29-e5.priv.proxad.net> <010501d3fd76$97c84890$c758d9b0$@chinamobile.com> <820A8FF6-0412-41DC-AC30-E49A210389B7@b-yond.com> <011b01d3fd99$456077d0$d0216770$@chinamobile.com> <5116516a346943bead676c16be75cea5@AUSX13MPS308.AMER.DELL.COM> <52a103f1f4b24dc6ac96a9ebc71110b2@AUSX13MPS308.AMER.DELL.COM> Message-ID: 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 From pramchan at yahoo.com Wed Jun 13 17:01:22 2018 From: pramchan at yahoo.com (prakash RAMCHANDRAN) Date: Wed, 13 Jun 2018 17:01:22 +0000 (UTC) Subject: [Edge-computing] Edge-computing Digest, Vol 8, Issue 18 In-Reply-To: References: Message-ID: <1769009351.3265334.1528909282461@mail.yahoo.com> Jess, I had added to ether pad set earlier set by Arkady for edge use case. Can you send the doodle poll to people listed therein who are not included herein. https://etherpad.openstack.org/p/edge-use-case Thanks Prakash On Wednesday, June 13, 2018, 8:06:43 AM PDT, edge-computing-request at lists.openstack.org wrote: Send Edge-computing mailing list submissions to     edge-computing at lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit     http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing or, via email, send a message with subject or body 'help' to     edge-computing-request at lists.openstack.org You can reach the person managing the list at     edge-computing-owner at lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Edge-computing digest..." Today's Topics:   1. Use Case Studies (Jess Lampe)   2. Berlin Summit CFP Deadline July 17 (Claire Massey)   3. Re: 答复:  答复:  Clarification of Requirements       (Csatari, Gergely (Nokia - HU/Budapest))   4. Re: 答复:  答复:  Clarification of Requirements       (Arkady.Kanevsky at dell.com) ---------------------------------------------------------------------- Message: 1 Date: Tue, 12 Jun 2018 08:02:49 -0700 From: Jess Lampe To: "edge-computing at lists.openstack.org"     Subject: [Edge-computing] Use Case Studies Message-ID:     Content-Type: text/plain; charset="utf-8" *Goal of Use Case Sub Groups*   - Capture known use cases in the   - Continue to add new use cases as they are discovered.   - Derive known use cases from captured use cases and add to story board. *Doodle for Standing Meeting* I added a doodle for available times. https://doodle.com/poll/wnmmstbrtmfgw5yc *Ongoing requests*   - If you have a known use case, please add it to the use case wiki.     - If you have an expert who would like to speak on a use case (like   Giovanni did today, please sign up on the etherpad   -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 12 Jun 2018 12:26:15 -0500 From: Claire Massey To: edge-computing at lists.openstack.org Subject: [Edge-computing] Berlin Summit CFP Deadline July 17 Message-ID: <92FA72CB-E0AD-4EA4-B1A6-97CAA9F9CC67 at openstack.org> Content-Type: text/plain; charset="utf-8" Hi everyone, The Call for Presentations is open for the Berlin Summit , November 13-15. The deadline to submit your presentation is July 17. At the Vancouver Summit, we focused on open infrastructure integration as the Summit has evolved over the years to cover more than just OpenStack. We had over 30 different projects from the open infrastructure community join, including Kubernetes, Docker, Ansible, OpenShift and many more. The Tracks were organized around specific use cases and will remain the same for Berlin with the addition of Hands on Workshops as its own dedicated Track. We encourage you to submit presentations covering the open infrastructure tools you’re using, as well as the integration work needed to address these use cases. We also encourage you to invite peers from other open source communities to speak and collaborate. The Tracks are:     • CI/CD     • Container Infrastructure     • Edge Computing     • Hands on Workshops     • HPC / GPU / AI     • Open Source Community     • Private & Hybrid Cloud     • Public Cloud     • Telecom & NFV 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. If you’re interested in nominating yourself or someone else to be a member of the Summit Programming Committee for a specific Track, please fill out the  nomination form . Nominations will close on June 28. Again, the deadline to  submit proposals is July 17. Please note topic submissions for the OpenStack Forum (planning/working sessions with OpenStack devs and operators) will open at a later date. The Early Bird registration deadline will be in mid August. We’re working hard to make it the best Summit yet, and look forward to bringing together different open infrastructure communities to solve these hard problems together. Want to provide feedback on this process? Please focus discussion on the openstack-community mailing list, or contact the Summit Team directly at summit at openstack.org . Thanks, Claire -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Wed, 13 Jun 2018 09:22:34 +0000 From: "Csatari, Gergely (Nokia - HU/Budapest)"     To: "Arkady.Kanevsky at dell.com" ,     "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 Message-ID:         Content-Type: text/plain; charset="utf-8" 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 ------------------------------ Message: 4 Date: Wed, 13 Jun 2018 14:24:09 +0000 From: To: , ,     , ,     Subject: Re: [Edge-computing] 答复:  答复:  Clarification of     Requirements Message-ID:     <52a103f1f4b24dc6ac96a9ebc71110b2 at AUSX13MPS308.AMER.DELL.COM> Content-Type: text/plain; charset="utf-8" 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 ------------------------------ Subject: Digest Footer _______________________________________________ Edge-computing mailing list Edge-computing at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing ------------------------------ End of Edge-computing Digest, Vol 8, Issue 18 ********************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Thu Jun 14 15:03:14 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Thu, 14 Jun 2018 15:03:14 +0000 Subject: [Edge-computing] Review of Dublin edge notes 04 Message-ID: Hi, Minutes of todays meeting: http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes_04/2018/review_of_dublin_edge_notes_04.2018-06-14-14.18.html Br, Gerg0 -----Original Appointment----- From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Monday, June 11, 2018 10:15 AM To: Csatari, Gergely (Nokia - HU/Budapest); edge-computing at lists.openstack.org; free; Paul-Andre Raymond; Éric Sarault; beth.cohen at verizon.com; CARVER, PAUL; Martin Bäckström; Kit Colbert; Silverman, Ben; Srikumar Venugopal; jonathan at openstack.org; Waines, Greg; Shashi Kant Singh; Mathieu LAGRANGE; D'ANDREA, JOE (JOE); stephan.terblanche at verizonwireless.com; Mats Karlsson A; DRUTA, DAN; BUYUKKOC, CAGATAY; Francis Dagenais; Paul Bankert; Shuquan Huang; Trinath Somanchi; Yves Desrochers; nathan.rader at canonical.com Cc: Arkady.Kanevsky at dell.com; saiyagar at redhat.com; Teresa Peluso Subject: Review of Dublin edge notes 04 When: csütörtök 2018. június 14 16:00-17:00 (UTC+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague. Where: #edge-computing-group Hi, Let's continue the IRC meeting to discuss the comments to the Dublin edge notes: https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG 5.3 Requirements . Notes of the previous meetings: * 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 lebre.adrien at free.fr Thu Jun 14 21:38:50 2018 From: lebre.adrien at free.fr (lebre.adrien at free.fr) Date: Thu, 14 Jun 2018 23:38:50 +0200 (CEST) Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion_of_Requirements?= In-Reply-To: Message-ID: <1430109911.246466899.1529012330134.JavaMail.root@zimbra29-e5.priv.proxad.net> 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 > From gergely.csatari at nokia.com Fri Jun 15 14:14:42 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Fri, 15 Jun 2018 14:14:42 +0000 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion_of_Requirements?= In-Reply-To: <1430109911.246466899.1529012330134.JavaMail.root@zimbra29-e5.priv.proxad.net> References: <1430109911.246466899.1529012330134.JavaMail.root@zimbra29-e5.priv.proxad.net> Message-ID: 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 > From ildiko at openstack.org Sun Jun 17 11:29:35 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Sun, 17 Jun 2018 13:29:35 +0200 Subject: [Edge-computing] Find an alternate APAC friendly time slot for the meeting call In-Reply-To: <29C12068-7DFF-4F48-AD36-67572776CB60@openstack.org> References: <29C12068-7DFF-4F48-AD36-67572776CB60@openstack.org> Message-ID: <0401BAC5-8DB3-47D4-9809-4A558A31C315@openstack.org> Hi All, Just a friendly reminder that the poll is still open, please take a look if you haven’t participated yet. Also if you know anyone in the APAC region who would like to join and might not be on the mailing list please forward the link to them. Thanks and Best Regards, Ildikó > On 2018. Jun 12., at 12:27, Ildiko Vancsa wrote: > > Hi All, > > Our current time slot for the Edge computing group call is in an inconvenient time for people in the APAC region. It would be great to find an alternating time slot to have the call once a month. > > I created a Doodle poll to see whether we can do better on that regard: https://doodle.com/poll/7vswvnyczuxeh966 > > __I would like to ask everyone to ignore the exact dates when you fill out the form as we are trying to find an alternating slot that works long term.__ > > If you know anyone who might not be on this list, but would be interested in participating please forward the Doodle link to them. > > Thanks and Best Regards, > Ildikó > > > > _______________________________________________ > Edge-computing mailing list > Edge-computing at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing From jess.lampe at gmail.com Mon Jun 18 06:33:30 2018 From: jess.lampe at gmail.com (Jess Lampe) Date: Sun, 17 Jun 2018 23:33:30 -0700 Subject: [Edge-computing] Use Case Meeting Message-ID: The results of the Doodle for a Use Case meeting found *2 pm Pacific on Mondays* to be the only time that everyone is available. *Tomorrow, Monday, June 18 at 2 pm* will be the first meeting. I added an agenda for the first meeting to the etherpad of the sub-group: https://etherpad.openstack.org/p/edge-use-case Please add any additional topics you would like covered. Am I missing anything? Please let me know. Thanks. Jess -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko.vancsa at gmail.com Mon Jun 18 14:00:31 2018 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Mon, 18 Jun 2018 16:00:31 +0200 Subject: [Edge-computing] Use Case Meeting In-Reply-To: References: Message-ID: <3F964E36-AFBA-4C04-9F00-2BA27D228C53@gmail.com> Hi Jess, Thanks for putting together the Doodle poll, I'm looking forward to the meeting today. I have only a quick questions. I’ve just recognized that the hour earlier slot would work for more people. I have a slight conflict, but I can make it work. Would that be possible to switch over to an hour earlier? Either from today or from next Monday? Thanks, Ildikó > On 2018. Jun 18., at 8:33, Jess Lampe wrote: > > The results of the Doodle for a Use Case meeting found 2 pm Pacific on Mondays to be the only time that everyone is available. > > Tomorrow, Monday, June 18 at 2 pm will be the first meeting. > > I added an agenda for the first meeting to the etherpad of the sub-group: https://etherpad.openstack.org/p/edge-use-case > > Please add any additional topics you would like covered. > > Am I missing anything? Please let me know. > > Thanks. > > Jess > > > > _______________________________________________ > Edge-computing mailing list > Edge-computing at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing From beth.cohen at verizon.com Mon Jun 18 14:04:12 2018 From: beth.cohen at verizon.com (beth.cohen at verizon.com) Date: Mon, 18 Jun 2018 14:04:12 +0000 Subject: [Edge-computing] [E] Re: Use Case Meeting In-Reply-To: <3F964E36-AFBA-4C04-9F00-2BA27D228C53@gmail.com> References: <3F964E36-AFBA-4C04-9F00-2BA27D228C53@gmail.com> Message-ID: <0bf712d2f5e74c9584ec3a1b754659ec@scwexch25apd.uswin.ad.vzwcorp.com> Folks - 4PM EST (which is an hour earlier) works for me. Beth Cohen NFV/SDN Network Product Strategy O +781-466-2055 | M +781-434-8553 beth.cohen at verizon.com      -----Original Message----- From: Ildiko Vancsa [mailto:ildiko.vancsa at gmail.com] Sent: Monday, June 18, 2018 10:01 AM To: Jess Lampe Cc: edge-computing at lists.openstack.org Subject: [E] Re: [Edge-computing] Use Case Meeting Hi Jess, Thanks for putting together the Doodle poll, I'm looking forward to the meeting today. I have only a quick questions. I’ve just recognized that the hour earlier slot would work for more people. I have a slight conflict, but I can make it work. Would that be possible to switch over to an hour earlier? Either from today or from next Monday? Thanks, Ildikó > On 2018. Jun 18., at 8:33, Jess Lampe wrote: > > The results of the Doodle for a Use Case meeting found 2 pm Pacific on Mondays to be the only time that everyone is available. > > Tomorrow, Monday, June 18 at 2 pm will be the first meeting. > > I added an agenda for the first meeting to the etherpad of the sub-group: https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_edge-2Duse-2Dcase&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=5dXczXJFW5cPlYKj3RmnDAolX1SLQ_ROivpFW1ukVEw&s=hZfvSxydotAbyMxxfIN4gzNQqaE-ED1s9KJFXsvc3oQ&e= > > Please add any additional topics you would like covered. > > Am I missing anything? Please let me know. > > Thanks. > > Jess > > > > _______________________________________________ > Edge-computing mailing list > Edge-computing at lists.openstack.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_edge-2Dcomputing&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=5dXczXJFW5cPlYKj3RmnDAolX1SLQ_ROivpFW1ukVEw&s=tTWGB_8eHbOq_fLxQSI1IminjmFBYUsmqQRRDkHA1Ow&e= _______________________________________________ Edge-computing mailing list Edge-computing at lists.openstack.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_edge-2Dcomputing&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=5dXczXJFW5cPlYKj3RmnDAolX1SLQ_ROivpFW1ukVEw&s=tTWGB_8eHbOq_fLxQSI1IminjmFBYUsmqQRRDkHA1Ow&e= From jess.lampe at gmail.com Mon Jun 18 14:44:10 2018 From: jess.lampe at gmail.com (Jess Lampe) Date: Mon, 18 Jun 2018 07:44:10 -0700 Subject: [Edge-computing] [E] Re: Use Case Meeting In-Reply-To: <0bf712d2f5e74c9584ec3a1b754659ec@scwexch25apd.uswin.ad.vzwcorp.com> References: <3F964E36-AFBA-4C04-9F00-2BA27D228C53@gmail.com> <0bf712d2f5e74c9584ec3a1b754659ec@scwexch25apd.uswin.ad.vzwcorp.com> Message-ID: Looks like we had more responses since last night that shifted the result. No problem. An hour earlier works. See everyone at 1 pm Pacific. On Mon, Jun 18, 2018 at 7:04 AM wrote: > Folks - > 4PM EST (which is an hour earlier) works for me. > > > > > Beth Cohen > NFV/SDN Network Product Strategy > > O +781-466-2055 | M +781-434-8553 > beth.cohen at verizon.com > > > > > > -----Original Message----- > From: Ildiko Vancsa [mailto:ildiko.vancsa at gmail.com] > Sent: Monday, June 18, 2018 10:01 AM > To: Jess Lampe > Cc: edge-computing at lists.openstack.org > Subject: [E] Re: [Edge-computing] Use Case Meeting > > Hi Jess, > > Thanks for putting together the Doodle poll, I'm looking forward to the > meeting today. I have only a quick questions. > > I’ve just recognized that the hour earlier slot would work for more > people. I have a slight conflict, but I can make it work. Would that be > possible to switch over to an hour earlier? Either from today or from next > Monday? > > Thanks, > Ildikó > > > > On 2018. Jun 18., at 8:33, Jess Lampe wrote: > > > > The results of the Doodle for a Use Case meeting found 2 pm Pacific on > Mondays to be the only time that everyone is available. > > > > Tomorrow, Monday, June 18 at 2 pm will be the first meeting. > > > > I added an agenda for the first meeting to the etherpad of the > sub-group: > https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_edge-2Duse-2Dcase&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=5dXczXJFW5cPlYKj3RmnDAolX1SLQ_ROivpFW1ukVEw&s=hZfvSxydotAbyMxxfIN4gzNQqaE-ED1s9KJFXsvc3oQ&e= > > > > Please add any additional topics you would like covered. > > > > Am I missing anything? Please let me know. > > > > Thanks. > > > > Jess > > > > > > > > _______________________________________________ > > Edge-computing mailing list > > Edge-computing at lists.openstack.org > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_edge-2Dcomputing&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=5dXczXJFW5cPlYKj3RmnDAolX1SLQ_ROivpFW1ukVEw&s=tTWGB_8eHbOq_fLxQSI1IminjmFBYUsmqQRRDkHA1Ow&e= > > > _______________________________________________ > Edge-computing mailing list > Edge-computing at lists.openstack.org > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_edge-2Dcomputing&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=5dXczXJFW5cPlYKj3RmnDAolX1SLQ_ROivpFW1ukVEw&s=tTWGB_8eHbOq_fLxQSI1IminjmFBYUsmqQRRDkHA1Ow&e= > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko.vancsa at gmail.com Mon Jun 18 15:31:46 2018 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Mon, 18 Jun 2018 17:31:46 +0200 Subject: [Edge-computing] [E] Use Case Meeting In-Reply-To: References: <3F964E36-AFBA-4C04-9F00-2BA27D228C53@gmail.com> <0bf712d2f5e74c9584ec3a1b754659ec@scwexch25apd.uswin.ad.vzwcorp.com> Message-ID: <2EE46BEB-4A13-46BE-AA85-93B2BF2B59BE@gmail.com> Thanks Jess! I created a Subgroups section on the wiki and added the weekly call details there too: https://wiki.openstack.org/wiki/Edge_Computing_Group#Subgroups Thanks, Ildikó > On 2018. Jun 18., at 16:44, Jess Lampe wrote: > > Looks like we had more responses since last night that shifted the result. > > No problem. An hour earlier works. See everyone at 1 pm Pacific. > > On Mon, Jun 18, 2018 at 7:04 AM wrote: > Folks - > 4PM EST (which is an hour earlier) works for me. > > > > > Beth Cohen > NFV/SDN Network Product Strategy > > O +781-466-2055 | M +781-434-8553 > beth.cohen at verizon.com > > > > > > -----Original Message----- > From: Ildiko Vancsa [mailto:ildiko.vancsa at gmail.com] > Sent: Monday, June 18, 2018 10:01 AM > To: Jess Lampe > Cc: edge-computing at lists.openstack.org > Subject: [E] Re: [Edge-computing] Use Case Meeting > > Hi Jess, > > Thanks for putting together the Doodle poll, I'm looking forward to the meeting today. I have only a quick questions. > > I’ve just recognized that the hour earlier slot would work for more people. I have a slight conflict, but I can make it work. Would that be possible to switch over to an hour earlier? Either from today or from next Monday? > > Thanks, > Ildikó > > > > On 2018. Jun 18., at 8:33, Jess Lampe wrote: > > > > The results of the Doodle for a Use Case meeting found 2 pm Pacific on Mondays to be the only time that everyone is available. > > > > Tomorrow, Monday, June 18 at 2 pm will be the first meeting. > > > > I added an agenda for the first meeting to the etherpad of the sub-group: https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_edge-2Duse-2Dcase&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=5dXczXJFW5cPlYKj3RmnDAolX1SLQ_ROivpFW1ukVEw&s=hZfvSxydotAbyMxxfIN4gzNQqaE-ED1s9KJFXsvc3oQ&e= > > > > Please add any additional topics you would like covered. > > > > Am I missing anything? Please let me know. > > > > Thanks. > > > > Jess > > > > > > > > _______________________________________________ > > Edge-computing mailing list > > Edge-computing at lists.openstack.org > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_edge-2Dcomputing&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=5dXczXJFW5cPlYKj3RmnDAolX1SLQ_ROivpFW1ukVEw&s=tTWGB_8eHbOq_fLxQSI1IminjmFBYUsmqQRRDkHA1Ow&e= > > > _______________________________________________ > Edge-computing mailing list > Edge-computing at lists.openstack.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_edge-2Dcomputing&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=5dXczXJFW5cPlYKj3RmnDAolX1SLQ_ROivpFW1ukVEw&s=tTWGB_8eHbOq_fLxQSI1IminjmFBYUsmqQRRDkHA1Ow&e= From ildiko at openstack.org Mon Jun 18 20:04:59 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Mon, 18 Jun 2018 22:04:59 +0200 Subject: [Edge-computing] [E] Use Case Meeting In-Reply-To: <2EE46BEB-4A13-46BE-AA85-93B2BF2B59BE@gmail.com> References: <3F964E36-AFBA-4C04-9F00-2BA27D228C53@gmail.com> <0bf712d2f5e74c9584ec3a1b754659ec@scwexch25apd.uswin.ad.vzwcorp.com> <2EE46BEB-4A13-46BE-AA85-93B2BF2B59BE@gmail.com> Message-ID: Hi, Friendly reminder that the use cases call is on now! :) We have a new meeting link/ID, please use this one: • Zoom link: https://zoom.us/j/879678938 • Dialing in from phone: • Dial(for higher quality, dial a number based on your current location): US: +1 669 900 6833 or +1 646 876 9923 • Meeting ID: 879 678 938 • International numbers available: https://zoom.us/u/ed95sU7aQ Thanks, Ildikó > On 2018. Jun 18., at 17:31, Ildiko Vancsa wrote: > > Thanks Jess! > > I created a Subgroups section on the wiki and added the weekly call details there too: https://wiki.openstack.org/wiki/Edge_Computing_Group#Subgroups > > Thanks, > Ildikó > > >> On 2018. Jun 18., at 16:44, Jess Lampe wrote: >> >> Looks like we had more responses since last night that shifted the result. >> >> No problem. An hour earlier works. See everyone at 1 pm Pacific. >> >> On Mon, Jun 18, 2018 at 7:04 AM wrote: >> Folks - >> 4PM EST (which is an hour earlier) works for me. >> >> >> >> >> Beth Cohen >> NFV/SDN Network Product Strategy >> >> O +781-466-2055 | M +781-434-8553 >> beth.cohen at verizon.com >> >> >> >> >> >> -----Original Message----- >> From: Ildiko Vancsa [mailto:ildiko.vancsa at gmail.com] >> Sent: Monday, June 18, 2018 10:01 AM >> To: Jess Lampe >> Cc: edge-computing at lists.openstack.org >> Subject: [E] Re: [Edge-computing] Use Case Meeting >> >> Hi Jess, >> >> Thanks for putting together the Doodle poll, I'm looking forward to the meeting today. I have only a quick questions. >> >> I’ve just recognized that the hour earlier slot would work for more people. I have a slight conflict, but I can make it work. Would that be possible to switch over to an hour earlier? Either from today or from next Monday? >> >> Thanks, >> Ildikó >> >> >>> On 2018. Jun 18., at 8:33, Jess Lampe wrote: >>> >>> The results of the Doodle for a Use Case meeting found 2 pm Pacific on Mondays to be the only time that everyone is available. >>> >>> Tomorrow, Monday, June 18 at 2 pm will be the first meeting. >>> >>> I added an agenda for the first meeting to the etherpad of the sub-group: https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_edge-2Duse-2Dcase&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=5dXczXJFW5cPlYKj3RmnDAolX1SLQ_ROivpFW1ukVEw&s=hZfvSxydotAbyMxxfIN4gzNQqaE-ED1s9KJFXsvc3oQ&e= >>> >>> Please add any additional topics you would like covered. >>> >>> Am I missing anything? Please let me know. >>> >>> Thanks. >>> >>> Jess >>> >>> >>> >>> _______________________________________________ >>> Edge-computing mailing list >>> Edge-computing at lists.openstack.org >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_edge-2Dcomputing&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=5dXczXJFW5cPlYKj3RmnDAolX1SLQ_ROivpFW1ukVEw&s=tTWGB_8eHbOq_fLxQSI1IminjmFBYUsmqQRRDkHA1Ow&e= >> >> >> _______________________________________________ >> Edge-computing mailing list >> Edge-computing at lists.openstack.org >> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_edge-2Dcomputing&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=5dXczXJFW5cPlYKj3RmnDAolX1SLQ_ROivpFW1ukVEw&s=tTWGB_8eHbOq_fLxQSI1IminjmFBYUsmqQRRDkHA1Ow&e= > > > _______________________________________________ > 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 Tue Jun 19 12:41:00 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Tue, 19 Jun 2018 12:41:00 +0000 Subject: [Edge-computing] Review of Dublin edge notes 04 In-Reply-To: References: Message-ID: Hi, As we discussed ont he meeting we should have a static time for the review meetings during the week. Here is a Doodle to vote for it: https://doodle.com/poll/992km9kvpechnimx Please DO NOT pay attention to the dates, select the time slots the work for you IN GENERAL. Br, Gerg0 From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Thursday, June 14, 2018 5:03 PM To: edge-computing at lists.openstack.org; free ; Paul-Andre Raymond ; Éric Sarault ; beth.cohen at verizon.com; CARVER, PAUL ; Martin Bäckström ; Kit Colbert ; Silverman, Ben ; Srikumar Venugopal ; jonathan at openstack.org; Waines, Greg ; Shashi Kant Singh ; Mathieu LAGRANGE ; D'ANDREA, JOE (JOE) ; stephan.terblanche at verizonwireless.com; Mats Karlsson A ; DRUTA, DAN ; BUYUKKOC, CAGATAY ; Francis Dagenais ; Paul Bankert ; Shuquan Huang ; Trinath Somanchi ; Yves Desrochers ; nathan.rader at canonical.com Cc: Arkady.Kanevsky at dell.com; saiyagar at redhat.com; Teresa Peluso Subject: RE: Review of Dublin edge notes 04 Hi, Minutes of todays meeting: http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes_04/2018/review_of_dublin_edge_notes_04.2018-06-14-14.18.html Br, Gerg0 -----Original Appointment----- From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Monday, June 11, 2018 10:15 AM To: Csatari, Gergely (Nokia - HU/Budapest); edge-computing at lists.openstack.org; free; Paul-Andre Raymond; Éric Sarault; beth.cohen at verizon.com; CARVER, PAUL; Martin Bäckström; Kit Colbert; Silverman, Ben; Srikumar Venugopal; jonathan at openstack.org; Waines, Greg; Shashi Kant Singh; Mathieu LAGRANGE; D'ANDREA, JOE (JOE); stephan.terblanche at verizonwireless.com; Mats Karlsson A; DRUTA, DAN; BUYUKKOC, CAGATAY; Francis Dagenais; Paul Bankert; Shuquan Huang; Trinath Somanchi; Yves Desrochers; nathan.rader at canonical.com Cc: Arkady.Kanevsky at dell.com; saiyagar at redhat.com; Teresa Peluso Subject: Review of Dublin edge notes 04 When: csütörtök 2018. június 14 16:00-17:00 (UTC+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague. Where: #edge-computing-group Hi, Let's continue the IRC meeting to discuss the comments to the Dublin edge notes: https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG 5.3 Requirements . Notes of the previous meetings: * 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 ildiko at openstack.org Tue Jun 19 13:21:36 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Tue, 19 Jun 2018 15:21:36 +0200 Subject: [Edge-computing] Weekly call reminder Message-ID: <96D1B7AC-0F0A-47B8-8292-4C4268353089@openstack.org> Hi All, This is a friendly reminder that we are having our next weekly call in 40 minutes at 7am PDT / 1400 UTC. You can find the call details and the agenda here: https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings Thanks, Ildikó From Arkady.Kanevsky at dell.com Tue Jun 19 13:59:20 2018 From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com) Date: Tue, 19 Jun 2018 13:59:20 +0000 Subject: [Edge-computing] Weekly call reminder In-Reply-To: <96D1B7AC-0F0A-47B8-8292-4C4268353089@openstack.org> References: <96D1B7AC-0F0A-47B8-8292-4C4268353089@openstack.org> Message-ID: Will miss one today. -----Original Message----- From: Ildiko Vancsa [mailto:ildiko at openstack.org] Sent: Tuesday, June 19, 2018 8:22 AM To: edge-computing at lists.openstack.org Subject: [Edge-computing] Weekly call reminder Hi All, This is a friendly reminder that we are having our next weekly call in 40 minutes at 7am PDT / 1400 UTC. You can find the call details and the agenda here: https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings Thanks, Ildikó _______________________________________________ Edge-computing mailing list Edge-computing at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing From ildiko at openstack.org Tue Jun 19 17:09:47 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Tue, 19 Jun 2018 19:09:47 +0200 Subject: [Edge-computing] PTG Denver 2018 Registration & Hotel Info Message-ID: <2DE8484C-628D-494D-B134-08410A02BD3C@openstack.org> Hi, We talked about the PTG last week and we are planning a full day for the Edge Computing Group to meet face to face in Denver. The registration is already open for the PTG, below you can find important details to get prepared for the event. The fourth Project Teams Gathering will be held September 10-14th back at the Renaissance Stapleton Hotel in Denver, Colorado (3801 Quebec Street, Denver, Colorado 80207). REGISTRATION AND HOTEL Registration is now available here: https://denver2018ptg.eventbrite.com The price is currently USD $399 until August 23 at 6:59 UTC. After that date, the price will be USD $599 so buy your pass before the price increases! We've reserved a very limited block of discounted hotel rooms at $149/night USD (does not include breakfast) with the Renaissance Denver Stapleton Hotel where the event will be held. Please move quickly to reserve a room by August 20th or until they sell out! TRAIN NEAR HOTEL The hotel has informed us that the RTD is anticipating the area near the Renaissance Denver Stapleton Hotel being deemed a quiet zone by end of July, with a more realistic completion date of August 15th. This means there should not be any train horns during the week of the PTG! HELPFUL LINKS: Registration: https://denver2018ptg.eventbrite.com Visa Invitation Letter (deadline August 24): https://openstackfoundation.formstack.com/forms/visa_form_denver_2018_ptg Travel Support Program (first round deadline July 1): https://openstackfoundation.formstack.com/forms/travelsupportptg_denver_2018 Sponsorship: https://www.openstack.org/ptg#tab_sponsor Book a Hotel Room (deadline August 20): https://www.marriott.com/meeting-event-hotels/group-corporate-travel/groupCorp.mi?resLinkData=Project%20Teams%20Gathering%2C%20Openstack%5Edensa%60opnopna%7Copnopnb%60149.00%60USD%60false%604%609/5/18%609/18/18%608/20/18&app=resvlink&stop_mobi=yes Please let me or Kendall (in cc) know if you have any questions, looking forward to seeing everyone in Denver! Thanks and Best Regards, Ildikó -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhaoqihui at chinamobile.com Wed Jun 20 02:03:06 2018 From: zhaoqihui at chinamobile.com (=?utf-8?B?6LW15aWH5oWn?=) Date: 20 Jun 2018 10:03:06 +0800 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion=5Fof=5FRequirements?= Message-ID: 201806201003064375530@chinamobile.com> 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 demandsDistance from Base Station (Access-level DC according to [6]): around 10km E2E delay (from UE to site)(Access according to [6]): 2 msBandwith 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 msBandwith need (Access according to [6]): 100GB ---------------------------------------------------------------------------- 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_RequirementsHi, 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 fuqiao at chinamobile.com Wed Jun 20 02:11:59 2018 From: fuqiao at chinamobile.com (Fu Qiao) Date: Wed, 20 Jun 2018 10:11:59 +0800 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAJ562U5aSNOiAg562U5aSNOiAg?= =?utf-8?q?Clarification=5Fof=5FRequirements?= In-Reply-To: 201806201003064375530@chinamobile.com> References: 201806201003064375530@chinamobile.com> Message-ID: <00aa01d4083c$129c7350$37d559f0$@chinamobile.com> 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. 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 收件人: Csatari, Gergely (Nokia - HU/Budapest) ; lebre.adrien 抄送: edge-computing ; paul-andre raymond 主题: Re: [Edge-computing] 答复: 答复: Clarification_of_Requirements 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 · 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 ---------------------------------------------------------------------------- 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 jess.lampe at gmail.com Wed Jun 20 04:58:09 2018 From: jess.lampe at gmail.com (Jess Lampe) Date: Tue, 19 Jun 2018 21:58:09 -0700 Subject: [Edge-computing] Use Cases Message-ID: *Proposed Template* To see the proposed layout, go to the Use Cases Page. - Near the top of the page you will find the layout in markup. - Below the template, the use cases that existed already were converted into the template. - At the bottom, please find the requirements that were captured at the Dublin event. I moved them to this Use Case page to centralize use cases and requirements. *Feedback? * As requested in the Monday and Tuesday meetings, we are soliciting feedback on the template format. Does it help sufficiently describe possible use cases? Does it help with mapping to requirements? I've created an etherpad to collect feedback. https://etherpad.openstack.org/p/feedback_on_template Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Wed Jun 20 07:56:52 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Wed, 20 Jun 2018 07:56:52 +0000 Subject: [Edge-computing] [Use Cases]: Some comments / questions Message-ID: Hi, Some comments and questions to https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases * (Can't we have a wiki with quick comment capabilities?) * What is TK? * Requirements: This is a section what is still under review in the Dublin PTG Discussion notes [1]. I will mirror the correction of the comments to here also, but I keep updating the original version until the end of the reviews. After the review finished we can remove the content from the original location and maintain it here. [1]: https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Requirements%7C Br, Gerg0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Wed Jun 20 08:48:53 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Wed, 20 Jun 2018 08:48:53 +0000 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion=5Fof=5FRequirements?= In-Reply-To: <00aa01d4083c$129c7350$37d559f0$@chinamobile.com> References: 201806201003064375530@chinamobile.com> <00aa01d4083c$129c7350$37d559f0$@chinamobile.com> Message-ID: 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 fuqiao at chinamobile.com Wed Jun 20 08:59:24 2018 From: fuqiao at chinamobile.com (Fu Qiao) Date: Wed, 20 Jun 2018 16:59:24 +0800 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAJ562U5aSNOiAg562U5aSNOiAg?= =?utf-8?q?Clarification=5Fof=5FRequirements?= In-Reply-To: References: 201806201003064375530@chinamobile.com> <00aa01d4083c$129c7350$37d559f0$@chinamobile.com> Message-ID: <010e01d40874$fcb3d720$f61b8560$@chinamobile.com> 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 gergely.csatari at nokia.com Wed Jun 20 09:17:37 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Wed, 20 Jun 2018 09:17:37 +0000 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion=5Fof=5FRequirements?= In-Reply-To: <010e01d40874$fcb3d720$f61b8560$@chinamobile.com> References: 201806201003064375530@chinamobile.com> <00aa01d4083c$129c7350$37d559f0$@chinamobile.com> <010e01d40874$fcb3d720$f61b8560$@chinamobile.com> Message-ID: 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 fuqiao at chinamobile.com Wed Jun 20 09:29:02 2018 From: fuqiao at chinamobile.com (Fu Qiao) Date: Wed, 20 Jun 2018 17:29:02 +0800 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAJ562U5aSNOiAg562U5aSNOiAg?= =?utf-8?q?Clarification=5Fof=5FRequirements?= In-Reply-To: References: 201806201003064375530@chinamobile.com> <00aa01d4083c$129c7350$37d559f0$@chinamobile.com> <010e01d40874$fcb3d720$f61b8560$@chinamobile.com> Message-ID: <012001d40879$20bab900$62302b00$@chinamobile.com> 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) < 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 >; '赵奇慧' >; '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 gergely.csatari at nokia.com Wed Jun 20 09:35:45 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Wed, 20 Jun 2018 09:35:45 +0000 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion=5Fof=5FRequirements?= In-Reply-To: <012001d40879$20bab900$62302b00$@chinamobile.com> References: 201806201003064375530@chinamobile.com> <00aa01d4083c$129c7350$37d559f0$@chinamobile.com> <010e01d40874$fcb3d720$f61b8560$@chinamobile.com> <012001d40879$20bab900$62302b00$@chinamobile.com> Message-ID: 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 Eric.Sarault at kontron.com Wed Jun 20 13:13:30 2018 From: Eric.Sarault at kontron.com (=?utf-8?B?w4lyaWMgU2FyYXVsdA==?=) Date: Wed, 20 Jun 2018 13:13:30 +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> Message-ID: <7b2e5862b8e84260984b2983d286c8e7@kontron.com> 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 jess.lampe at gmail.com Wed Jun 20 19:54:17 2018 From: jess.lampe at gmail.com (Jess Lampe) Date: Wed, 20 Jun 2018 12:54:17 -0700 Subject: [Edge-computing] Edge-computing Digest, Vol 8, Issue 25 In-Reply-To: References: Message-ID: Hi Gergely, TK is a place holder text for "more to come". It's a letter pairing in english that is so infrequent you can search TK and not find any other words in a document. On Wed, Jun 20, 2018 at 1:49 AM wrote: > Send Edge-computing mailing list submissions to > edge-computing at lists.openstack.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing > or, via email, send a message with subject or body 'help' to > edge-computing-request at lists.openstack.org > > You can reach the person managing the list at > edge-computing-owner at lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Edge-computing digest..." > > > Today's Topics: > > 1. Use Cases (Jess Lampe) > 2. [Use Cases]: Some comments / questions > (Csatari, Gergely (Nokia - HU/Budapest)) > 3. Re: 答复: 答复: Clarification_of_Requirements > (Csatari, Gergely (Nokia - HU/Budapest)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 19 Jun 2018 21:58:09 -0700 > From: Jess Lampe > To: "edge-computing at lists.openstack.org" > > Subject: [Edge-computing] Use Cases > Message-ID: > uLgdiJq5N23dLBWf881+v689iVcD2XoWAuo3FneaXA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > *Proposed Template* > To see the proposed layout, go to the Use Cases Page. > > > - Near the top of the page you will find the layout in markup. > - Below the template, the use cases that existed already were converted > into the template. > - At the bottom, please find the requirements that were captured at the > Dublin event. I moved them to this Use Case page to centralize use cases > and requirements. > > *Feedback? * > As requested in the Monday and Tuesday meetings, we are soliciting feedback > on the template format. > > Does it help sufficiently describe possible use cases? Does it help with > mapping to requirements? > > I've created an etherpad to collect feedback. > https://etherpad.openstack.org/p/feedback_on_template > > Thanks! > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.openstack.org/pipermail/edge-computing/attachments/20180619/37497a5c/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Wed, 20 Jun 2018 07:56:52 +0000 > From: "Csatari, Gergely (Nokia - HU/Budapest)" > > To: "edge-computing at lists.openstack.org" > > Subject: [Edge-computing] [Use Cases]: Some comments / questions > Message-ID: > < > AM5PR0701MB23060860C2C823CFF546B305E1770 at AM5PR0701MB2306.eurprd07.prod.outlook.com > > > > Content-Type: text/plain; charset="utf-8" > > Hi, > > Some comments and questions to > https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases > > > * (Can't we have a wiki with quick comment capabilities?) > * What is TK? > * Requirements: This is a section what is still under review in the > Dublin PTG Discussion notes [1< > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Requirements%7C>]. > I will mirror the correction of the comments to here also, but I keep > updating the original version until the end of the reviews. After the > review finished we can remove the content from the original location and > maintain it here. > > [1]: > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Requirements%7C > > Br, > Gerg0 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.openstack.org/pipermail/edge-computing/attachments/20180620/7d421fda/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Wed, 20 Jun 2018 08:48:53 +0000 > From: "Csatari, Gergely (Nokia - HU/Budapest)" > > To: Fu Qiao , '赵奇慧' > , 'lebre.adrien' > Cc: 'edge-computing' , 'paul-andre > raymond' > Subject: Re: [Edge-computing] 答复: 答复: > Clarification_of_Requirements > Message-ID: > < > AM5PR0701MB230662E4AF23BE59F46650F3E1770 at AM5PR0701MB2306.eurprd07.prod.outlook.com > > > > Content-Type: text/plain; charset="utf-8" > > 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]< > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#cite_note-Edge_TIC:_Future_edge_cloud_for_China_Mobile-6>): > depend on demands > [G0]: Can we say 3000+ here in a paranthesis? > · Distance from Base Station (Access-level DC according to [6]< > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#cite_note-Edge_TIC:_Future_edge_cloud_for_China_Mobile-6>): > around 10km > · E2E delay (from UE to site)(Access according to [6]< > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#cite_note-Edge_TIC:_Future_edge_cloud_for_China_Mobile-6>): > 2 ms > · Bandwith need (Access according to [6]< > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#cite_note-Edge_TIC:_Future_edge_cloud_for_China_Mobile-6>): > 50 GB > > Medium edge: > · Number of instances (Edge TIC County according to [6]< > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#cite_note-Edge_TIC:_Future_edge_cloud_for_China_Mobile-6>): > 3000+ > · Distance from Base Station (Access-level DC according to [6]< > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#cite_note-Edge_TIC:_Future_edge_cloud_for_China_Mobile-6>): > around 50km > · E2E delay (from UE to site) (Access according to [6]< > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#cite_note-Edge_TIC:_Future_edge_cloud_for_China_Mobile-6>): > less than 2.5 ms > · Bandwith need (Access according to [6]< > https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#cite_note-Edge_TIC:_Future_edge_cloud_for_China_Mobile-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) gergely.csatari at nokia.com> > 时间: 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 Arkady.Kanevsky at dell.com>>; fuqiao at chinamobile.com fuqiao at chinamobile.com>; paul-andre raymond >; > edge-computing at lists.openstack.org 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" Arkady.Kanevsky at dell.com>>, fuqiao at chinamobile.com fuqiao at chinamobile.com>, "paul-andre raymond" > > >, > "lebre adrien" > > >, > edge-computing at lists.openstack.org 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 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 fuqiao at chinamobile.com>; > > paul-andre.raymond at b-yond.com; > lebre.adrien at free.fr; > > edge-computing at lists.openstack.org 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#< > 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 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 lebre.adrien at free.fr>; > > edge-computing at lists.openstack.org 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 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" fuqiao at chinamobile.com>> 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 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 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 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 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 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 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 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 Edge-computing at lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.openstack.org/pipermail/edge-computing/attachments/20180620/b0b7357b/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Edge-computing mailing list > Edge-computing at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing > > > ------------------------------ > > End of Edge-computing Digest, Vol 8, Issue 25 > ********************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openstack.org Thu Jun 21 07:06:09 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Thu, 21 Jun 2018 09:06:09 +0200 Subject: [Edge-computing] PTG Denver 2018 further information Message-ID: Hi, Please find below a bit more details on the upcoming PTG (https://www.openstack.org/ptg/) from my colleague, Kendall below. You can see which teams are planning to meet in Denver and plan collaborative sessions based on this information. The Edge Computing Group is planned for a full day meeting, we are still working on the exact schedule. Please add your name to the following etherpad if you plan on attending: https://etherpad.openstack.org/p/EdgeComputingGroupPTG4 Please let me know if you have any questions to the information below or about the PTG itself. Thanks and Best Regards, Ildikó (IRC: ildikov) ----------------------------------------------- Hello Everyone! Wanted to give you some updates on PTG4 planning. We have finalized the list of SIGs/ Groups/WGs/Teams that are attending. They are as follows: * Airship * API SIG * Barbican/Security SIG * Blazar * Chef OpenStack * Cinder * Cyborg * Designate * Documentation * Edge Computing Group * First Contact SIG * Glance * Heat * Horizon * Infrastructure * Interop WG * Ironic * Kata * Keystone * Kolla * LOCI * Manila * Masakari * Mistral * Monasca * Neutron * Nova * Octavia * OpenStack Ansible * OpenStack Charms * OpenStack Helm * OpenStackClient * Operator Meetup * Puppet OpenStack * QA * Oslo * Public Cloud WG * Release Management * Requirements * Sahara * Scientific SIG * Self-Healing SIG * SIG-K8s * StarlingX * Swift * OpenStack TC * TripleO * Upgrades SIG * Watcher * Zuul (pending confirmation) Thierry and I are working on placing them into a strawman schedule to reduce conflicts between related or overlapping groups. We should have more on what that will look like and a draft for you all to review in the next few weeks. We also wanted to remind you all of the Travel Support Program. We are again doing a two phase selection. The first deadline is approaching: July 1st. At this point we have less than a dozen applicants so if you need it or even think you need it, I urge you to apply here[1]. Also! Reminder that we have a finite number of rooms in the hotel block so please book early to make sure you get the discounted rate before they run out. You can book those rooms here[2] (pardon the ugly URL). Can't wait to see you all there! -Kendall Nelson (diablo_rojo) P.S. Gonna try to do a game night again since you all seemed to enjoy it so much last time :) [1] https://openstackfoundation.formstack.com/forms/travelsupportptg_denver_2018 [2] https://www.marriott.com/meeting-event-hotels/group-corporate-travel/groupCorp.mi?resLinkData=Project%20Teams%20Gathering%2C%20Openstack%5Edensa%60opnopna%7Copnopnb%60149.00%60USD%60false%604%609/5/18%609/18/18%608/20/18&app=resvlink&stop_mobi=yes From beth.cohen at verizon.com Thu Jun 21 13:45:06 2018 From: beth.cohen at verizon.com (beth.cohen at verizon.com) Date: Thu, 21 Jun 2018 13:45:06 +0000 Subject: [Edge-computing] [E] PTG Denver 2018 further information In-Reply-To: References: Message-ID: Folks - Just be aware that the PTG is at the same time as a major Jewish holiday, so I will not be able to attend. :-( Beth Cohen DMTS- NFV/SDN Network Product Strategy Verizon Technology O +781-466-2055 | M +781-434-8553 beth.cohen at verizon.com      -----Original Message----- From: Ildiko Vancsa [mailto:ildiko at openstack.org] Sent: Thursday, June 21, 2018 3:06 AM To: edge-computing at lists.openstack.org Subject: [E] [Edge-computing] PTG Denver 2018 further information Hi, Please find below a bit more details on the upcoming PTG (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openstack.org_ptg_&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=xS-m76zGqzeXG5v7fC2rMoxWtTe3vy3XrZ1MOioboNE&s=LWniKY8MC_IuS_5LkWgO1UaEY_pfEYMGY_qECC2bMD4&e=) from my colleague, Kendall below. You can see which teams are planning to meet in Denver and plan collaborative sessions based on this information. The Edge Computing Group is planned for a full day meeting, we are still working on the exact schedule. Please add your name to the following etherpad if you plan on attending: https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_EdgeComputingGroupPTG4&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=xS-m76zGqzeXG5v7fC2rMoxWtTe3vy3XrZ1MOioboNE&s=iUMhvY1yv8fmfYz1z_6wDcuEPqOYwJwmAGFhXramByg&e= Please let me know if you have any questions to the information below or about the PTG itself. Thanks and Best Regards, Ildikó (IRC: ildikov) ----------------------------------------------- Hello Everyone! Wanted to give you some updates on PTG4 planning. We have finalized the list of SIGs/ Groups/WGs/Teams that are attending. They are as follows: * Airship * API SIG * Barbican/Security SIG * Blazar * Chef OpenStack * Cinder * Cyborg * Designate * Documentation * Edge Computing Group * First Contact SIG * Glance * Heat * Horizon * Infrastructure * Interop WG * Ironic * Kata * Keystone * Kolla * LOCI * Manila * Masakari * Mistral * Monasca * Neutron * Nova * Octavia * OpenStack Ansible * OpenStack Charms * OpenStack Helm * OpenStackClient * Operator Meetup * Puppet OpenStack * QA * Oslo * Public Cloud WG * Release Management * Requirements * Sahara * Scientific SIG * Self-Healing SIG * SIG-K8s * StarlingX * Swift * OpenStack TC * TripleO * Upgrades SIG * Watcher * Zuul (pending confirmation) Thierry and I are working on placing them into a strawman schedule to reduce conflicts between related or overlapping groups. We should have more on what that will look like and a draft for you all to review in the next few weeks. We also wanted to remind you all of the Travel Support Program. We are again doing a two phase selection. The first deadline is approaching: July 1st. At this point we have less than a dozen applicants so if you need it or even think you need it, I urge you to apply here[1]. Also! Reminder that we have a finite number of rooms in the hotel block so please book early to make sure you get the discounted rate before they run out. You can book those rooms here[2] (pardon the ugly URL). Can't wait to see you all there! -Kendall Nelson (diablo_rojo) P.S. Gonna try to do a game night again since you all seemed to enjoy it so much last time :) [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__openstackfoundation.formstack.com_forms_travelsupportptg-5Fdenver-5F2018&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=xS-m76zGqzeXG5v7fC2rMoxWtTe3vy3XrZ1MOioboNE&s=sfTEzhgbkw5gOkVE3uNyW_GLN88pmEEH4iVN7n8CuNQ&e= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.marriott.com_meeting-2Devent-2Dhotels_group-2Dcorporate-2Dtravel_groupCorp.mi-3FresLinkData-3DProject-2520Teams-2520Gathering-252C-2520Openstack-255Edensa-2560opnopna-257Copnopnb-2560149.00-2560USD-2560false-25604-25609_5_18-25609_18_18-25608_20_18-26app-3Dresvlink-26stop-5Fmobi-3Dyes&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=xS-m76zGqzeXG5v7fC2rMoxWtTe3vy3XrZ1MOioboNE&s=3xyxzwTqKWG8hZjOlAtI24W0A4fw19uC-paXg_Cu4BE&e= _______________________________________________ Edge-computing mailing list Edge-computing at lists.openstack.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_edge-2Dcomputing&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=xS-m76zGqzeXG5v7fC2rMoxWtTe3vy3XrZ1MOioboNE&s=ZL_MkQnY2wMWY4_XXlzzgl8QS6J6CF8IqNFzC8afrG4&e= From Greg.Waines at windriver.com Thu Jun 21 18:24:45 2018 From: Greg.Waines at windriver.com (Waines, Greg) Date: Thu, 21 Jun 2018 18:24:45 +0000 Subject: [Edge-computing] Keystone Edge Architectures In-Reply-To: References: <678C1A99-2302-438D-8D5D-91ED44B10FF9@windriver.com> <77FE167D-B416-4C8C-9D83-E34779D394B3@windriver.com> Message-ID: <808E38AB-ED28-4728-9DCE-70985305F5B9@windriver.com> A question for the general team and the ‘KEYSTONE’ Edge team in particular. It seems like we are going down the solution path of ‘federated’ keystone. ( i.e. the first option described at https://wiki.openstack.org/wiki/Keystone_edge_architectures ) My understanding of ‘federated’ keystone (and this solution) is that · All clouds run a Keystone Instance (service provider) · But all Keystone Instances leverage some remote IdentityProvider as the backend for User Authentication o i.e. there is a remote IdentityProvider with all the user credentials · i.e. local Keystone instances (in edge clouds), if they lose connectivity to remote IdentityProvider, can NOT do authentication of user or validation of tokens. If this is the case, then how does the ‘federated’ keystone option meet the requirement that “There may be significant times where an edge cloud has no remote connectivity and all functions (e.g. autoscaling) must continue to function” ? I would have thought that we would have ruled this out immediately ? Greg. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openstack.org Thu Jun 21 19:34:05 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Thu, 21 Jun 2018 21:34:05 +0200 Subject: [Edge-computing] Keystone federation testing - Volunteers Needed Message-ID: <11D1B1A5-44EB-45B2-9961-36936D7AC3C8@openstack.org> Hi, As I mentioned on the weekly calls one of the activities we are planning to do is test and improve Keystone to fit better the Edge scenarios. One of the options we talked about at the Forum in Vancouver was federation. Keystone supports federation[1][2][3] in different setups, but it’s not fully tested in an automated fashion at this point. We are planning to add more tests to validate the federation capabilities. I created an etherpad[4] to plan activities, __please add your name if you are interested in participating__. You can find relevant links to planned Keystone architectures and former testing activities on our wiki page[5]. Please let me know if you have any questions. Thanks and Best Regards, Ildikó [1] https://docs.openstack.org/security-guide/identity/federated-keystone.html [2] https://docs.openstack.org/keystone/queens/advanced-topics/federation/configure_federation.html [3] https://docs.openstack.org/keystone/queens/advanced-topics/federation/federated_identity.html [4] https://etherpad.openstack.org/p/ECG_Keystone_Testing [5] https://wiki.openstack.org/wiki/Edge_Computing_Group#Keystone From jess.lampe at gmail.com Mon Jun 25 03:58:44 2018 From: jess.lampe at gmail.com (Jess Lampe) Date: Mon, 25 Jun 2018 03:58:44 +0000 Subject: [Edge-computing] Invitation: Edge Computing - Use Case Meeting @ Weekly from 1pm to 2pm on Monday (PDT) (edge-computing@lists.openstack.org) Message-ID: <000000000000df31de056f6f6506@google.com> You have been invited to the following event. Title: Edge Computing - Use Case Meeting Next meeting: Monday(June 18) at 1pm PDT / 2000 UTC Zoom link: https://zoom.us/j/879678938 Dialing in from phone: Dial(for higher quality, dial a number based on your current location): US: +1 669 900 6833 or +1 646 876 9923 Meeting ID: 879 678 938 International numbers available: https://zoom.us/u/ed95sU7aQ When: Weekly from 1pm to 2pm on Monday Pacific Time Calendar: edge-computing at lists.openstack.org Who: * Jess Lampe - organizer * edge-computing at lists.openstack.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=NzdraGQwZjJ1MzVjODdjajVsYmMyZDY5M3UgZWRnZS1jb21wdXRpbmdAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MjAjamVzcy5sYW1wZUBnbWFpbC5jb204NzljMGJkZGMzOTg5OWRjODA3N2M1NTRhMWQyMDdlZDNiOTVmNDMw&ctz=America%2FLos_Angeles&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: 2102 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2158 bytes Desc: not available URL: From jess.lampe at gmail.com Mon Jun 25 04:10:08 2018 From: jess.lampe at gmail.com (Jess Lampe) Date: Sun, 24 Jun 2018 21:10:08 -0700 Subject: [Edge-computing] Use Case Meeting Message-ID: Hi Everyone, 1.) I sent out a calendar invite for the ongoing Use Case Meeting. Please accept if you are interested in attending the weekly meetings at Monday 1pm Pacific. 2.) I will not be able to attend the meeting tomorrow due last minute shifts in my schedule. Beth - if you are attending can you lead the review of the use case template? The use case template can be found on the use case wiki page . Our plan is to write complete use cases with the template as a guide starting this week. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openstack.org Mon Jun 25 05:33:34 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Mon, 25 Jun 2018 07:33:34 +0200 Subject: [Edge-computing] Use Cases In-Reply-To: References: Message-ID: <377EC85F-CBD3-4868-9141-3BA327B866BF@openstack.org> Hi Jess, I copied the template to the etherpad you linked in earlier and added one question that I had to it from mainly wording: https://etherpad.openstack.org/p/feedback_on_template Thanks, Ildikó > On 2018. Jun 20., at 6:58, Jess Lampe wrote: > > Proposed Template > To see the proposed layout, go to the Use Cases Page. > • Near the top of the page you will find the layout in markup. > • Below the template, the use cases that existed already were converted into the template. > • At the bottom, please find the requirements that were captured at the Dublin event. I moved them to this Use Case page to centralize use cases and requirements. > Feedback? > As requested in the Monday and Tuesday meetings, we are soliciting feedback on the template format. > > Does it help sufficiently describe possible use cases? Does it help with mapping to requirements? > > I've created an etherpad to collect feedback. > https://etherpad.openstack.org/p/feedback_on_template > > Thanks! > _______________________________________________ > Edge-computing mailing list > Edge-computing at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing From beth.cohen at verizon.com Mon Jun 25 12:27:10 2018 From: beth.cohen at verizon.com (beth.cohen at verizon.com) Date: Mon, 25 Jun 2018 12:27:10 +0000 Subject: [Edge-computing] Another Use case for Edge -- Content delivery Message-ID: <9c837560fee94c68a67878f43fb5e3b1@scwexch25apd.uswin.ad.vzwcorp.com> Folks - Saw this story today: LiquidSky is using 5G to explore the edge of cloud computing This is a content delivery edge use case. [Verizon] Beth Cohen DMTS - NFV/SDN Network Product Strategy Verizon Technology 60 Sylvan Rd Waltham, MA 02451 O +781-466-2055 | M +781-434-8553 beth.cohen at verizon.com [Twitter] [Instagram] -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.price at est.tech Mon Jun 25 12:51:50 2018 From: christopher.price at est.tech (Christopher Price) Date: Mon, 25 Jun 2018 12:51:50 +0000 Subject: [Edge-computing] Another Use case for Edge -- Content delivery Message-ID: <306A2796-613C-4A9F-A734-AD271186ECD9@est.tech> Nice link Beth. I like this one (still believing that gaming will drive the development of augmented reality far more than pop-up-pricing at the local store). 😉 (And it needs the edge-cloud.) / Chris From: "beth.cohen at verizon.com" Date: Monday, 25 June 2018 at 14:31 To: "edge-computing at lists.openstack.org" Subject: [Edge-computing] Another Use case for Edge -- Content delivery Resent-From: Christopher Price Folks – Saw this story today: LiquidSky is using 5G to explore the edge of cloud computing This is a content delivery edge use case. [Image removed by sender. Verizon] Beth Cohen DMTS - NFV/SDN Network Product Strategy Verizon Technology 60 Sylvan Rd Waltham, MA 02451 O +781-466-2055 | M +781-434-8553 beth.cohen at verizon.com [Image removed by sender. Twitter] [Image removed by sender. Instagram] -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openstack.org Mon Jun 25 16:05:25 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Mon, 25 Jun 2018 18:05:25 +0200 Subject: [Edge-computing] Another Use case for Edge -- Content delivery In-Reply-To: <306A2796-613C-4A9F-A734-AD271186ECD9@est.tech> References: <306A2796-613C-4A9F-A734-AD271186ECD9@est.tech> Message-ID: <1FFB88F1-26FE-4159-984D-1B2EA05DDCBF@openstack.org> Hi, Thanks for sharing Beth. We should add this to the wiki too even if just the link to keep track of things and can talk about it on the Use cases call too. Thanks, Ildikó Sent from my iPhone > On 2018. Jun 25., at 14:51, Christopher Price wrote: > > Nice link Beth. > I like this one (still believing that gaming will drive the development of augmented reality far more than pop-up-pricing at the local store). 😉 > (And it needs the edge-cloud.) > > / Chris > > From: "beth.cohen at verizon.com" > Date: Monday, 25 June 2018 at 14:31 > To: "edge-computing at lists.openstack.org" > Subject: [Edge-computing] Another Use case for Edge -- Content delivery > Resent-From: Christopher Price > > Folks – > Saw this story today: > > LiquidSky is using 5G to explore the edge of cloud computing > This is a content delivery edge use case. > > > > > Beth Cohen > DMTS - NFV/SDN Network Product Strategy > Verizon Technology > > 60 Sylvan Rd > Waltham, MA 02451 > > O +781-466-2055 | M +781-434-8553 > beth.cohen at verizon.com > > > > > > _______________________________________________ > 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 jimmy at openstack.org Mon Jun 25 16:44:26 2018 From: jimmy at openstack.org (Jimmy McArthur) Date: Mon, 25 Jun 2018 11:44:26 -0500 Subject: [Edge-computing] [OpenStack-I18n] [Openstack-sigs] Edge Computing Whitepaper Translation In-Reply-To: <5B1AB61D.409@openstack.org> References: <20180529135041.cyjrl3vtpwajhicq@yuggoth.org> <558F16D9-EB0A-421F-8832-B2DE320E5555@gmail.com> <297D0BCC-4EB7-401E-883D-EC5D3BDE1C59@gmail.com> <5B1AB61D.409@openstack.org> Message-ID: <5B311BEA.9010908@openstack.org> Hi all - I wanted to give a quick update on this. Because of some emergency server issues and last minute projects with the OpenStack website, we've had to push these back. We're targeting July 13th for Edge (and hopefully Containers) whitepaper. I'll also add that as part of the plan, we will be creating a new template in our system to make it MUCH easier to push future whitepaper content directly to Zanata. I realize this feels a little slow and painful and everyone is eager to get it up, but I think we'll have a very good system once we're done. Thank you all for your patience! Jimmy Jimmy McArthur wrote: > We are currently targeting June 25 for the initial version of the Edge > whitepaper. However, I'll know more by EOW next. > > Cheers, > Jimmy > > Ildiko Vancsa wrote: >> Hi Akihiro, >> >> It is on our priority list to put up the translated versions in an online format as well as work out to have the .po files available. >> >> Jimmy is looking into it and will give an update once we got some progress. >> >> Thanks and Best Regards, >> Ildikó >> >> >>> On 2018. Jun 8., at 10:14, Akihiro Motoki wrote: >>> >>> Hi all, >>> >>> # I added edge-computing ML as the edge computing team uses a separate list other than the SIG ML. >>> # The original discussion happened in openstack-sigs ML. I just forgot to add the edge ML. >>> >>> What is the next step of the translation of the edge computing white paper with RST? >>> My temporary translation publishing [1] should not be published as-is due to the CC BY-ND license. This is to prove how it works. >>> I would like to move this forward and am happy to help the setup of a repo if needed. >>> >>> Where can we discuss this? >>> The edge computing group meeting is not listed athttp://eavesdrop.openstack.org/ and I don't know when and where it happens. >>> >>> [1]https://amotoki.github.io/edge-computing-whitepaper/ >>> >>> Thanks, >>> Akihiro >>> >>> 2018年5月29日(火) 23:37 Akihiro Motoki: >>> Hi Ildiko and all, >>> >>> I am happy to hear that HTML-based publishing is now on the table :) >>> I am synced with Ian and Frank on this topic, though I failed to join the conversation at Vancouver. >>> RST based process is used much in the community and translation publishinng of project docs which Ian and us are working on will make the continuous publishing easier. >>> I am happy to help setting up a new doc infrastructure and/or publishing translations. >>> >>> Regarding the license, CC BY-ND license turned out a bit too strict in our collaborative works when I checked the current one. >>> Hopefully we can get a good conclusion for further similar cases. >>> >>> Thanks, >>> Akihiro >>> >>> >>> >>> 2018年5月29日(火) 23:19 Ildiko Vancsa: >>> Hi Akihiro and All, >>> >>> Thank you for your efforts on helping with publishing the white paper in additional languages. >>> >>> I talked to Ian and Frank last week about this topic and the conundrum on the Foundation side whether or not to do the print version for the translations as that is what slows down the process a lot due to the design work it requires. >>> >>> We got to the conclusion with our team from the Foundation (cc’ed Allison, Jimmy and Wes) to do HTML-based publishing to reduce this overhead. We need to clarify now on the process and as Jeremy indicated the licensing as well. >>> >>> Thanks, >>> Ildikó >>> >>> >>>> On 2018. May 29., at 15:50, Jeremy Stanley wrote: >>>> >>>> On 2018-05-29 18:50:23 +0900 (+0900), Akihiro Motoki wrote: >>>> [...] >>>>> NOTE: Anyway I need to grant it from the foundation because CC >>>>> Attribution-NoDerivatives 4.0 International license does not allow >>>>> me to share translations without permission. I updated this files >>>>> only for discussion and will close this soon. >>>> [...] >>>> >>>> It seems like this is a really poor choice of license as it's >>>> impairing open collaboration. Even Creative Commons suggests that >>>> the CC BY-ND license is unsuitable for free cultural works: >>>> >>>> https://creativecommons.org/share-your-work/public-domain/freeworks/ >>>> >>>> We should see about getting this changed to CC BY like is used for >>>> other collaborative works produced by our community. >>>> -- >>>> Jeremy Stanley >>>> _______________________________________________ >>>> openstack-sigs mailing list >>>> openstack-sigs at lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >>> _______________________________________________ >>> openstack-sigs mailing list >>> openstack-sigs at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >>> _______________________________________________ >>> Edge-computing mailing list >>> Edge-computing at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing >> > > _______________________________________________ > OpenStack-I18n mailing list > OpenStack-I18n at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openstack.org Mon Jun 25 19:57:57 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Mon, 25 Jun 2018 21:57:57 +0200 Subject: [Edge-computing] Use cases call meeting reminder Message-ID: Hi, It is a friendly reminder that we are having the Use cases subgroup call at 2000 UTC. Call details are here: https://wiki.openstack.org/wiki/Edge_Computing_Group#Use_cases See you in a few minutes! :) Thanks and Best Regards, Ildikó (IRC: ildikov) From lbragstad at gmail.com Mon Jun 25 20:26:03 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Mon, 25 Jun 2018 15:26:03 -0500 Subject: [Edge-computing] Keystone Edge Architectures In-Reply-To: <678C1A99-2302-438D-8D5D-91ED44B10FF9@windriver.com> Message-ID: <2e2495d6-531f-c0a4-27d6-3c15da111289@gmail.com> Hi Greg, Jumping in a bit late, but I can try and clear up some of the questions around keystone's federated identity implementation. Your initial assessment of federated identity is accurate where each keystone node in the deployment refers to an external identity provider as the source of truth for user identities. But, keystone doesn't actively reach out to the external identity provider at authentication time. Instead, a user presents keystone (which is acting as a service provider) with a SAML document that keystone will verify with a set of certificates from the identity provider. If keystone can prove the SAML assertion came from a trusted identity provider, it processes the attributes through a mapping engine, which essentially translates the SAML assertion into OpenStack-specific terminology. The actual validation of the SAML assertion doesn't require a connection to the identity provider that issued it. This trust relationship is established when setting up federated identity via configuration (e.g. these are the certs for the identity provider that I trust). Hopefully that helps Lance -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From gergely.csatari at nokia.com Tue Jun 26 08:52:50 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Tue, 26 Jun 2018 08:52:50 +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: 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 * 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: 2747 bytes Desc: not available URL: From gergely.csatari at nokia.com Tue Jun 26 11:09:13 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Tue, 26 Jun 2018 11:09:13 +0000 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgQ2xhcmlmaWNh?= =?utf-8?q?tion=5Fof=5FRequirements?= In-Reply-To: <7b2e5862b8e84260984b2983d286c8e7@kontron.com> References: 201806201003064375530@chinamobile.com> <00aa01d4083c$129c7350$37d559f0$@chinamobile.com> <010e01d40874$fcb3d720$f61b8560$@chinamobile.com> <012001d40879$20bab900$62302b00$@chinamobile.com> <7b2e5862b8e84260984b2983d286c8e7@kontron.com> Message-ID: 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 Jun 26 11:52:55 2018 From: Greg.Waines at windriver.com (Waines, Greg) Date: Tue, 26 Jun 2018 11:52:55 +0000 Subject: [Edge-computing] Keystone Edge Architectures In-Reply-To: <2e2495d6-531f-c0a4-27d6-3c15da111289@gmail.com> References: <678C1A99-2302-438D-8D5D-91ED44B10FF9@windriver.com> <2e2495d6-531f-c0a4-27d6-3c15da111289@gmail.com> Message-ID: <8CB60A46-2C68-444F-994C-45D88FE77D74@windriver.com> Thanks Lance ... this clears up my general confusion. So it sounds like user authentication can be performed by the edge keystone, even when it does not currently have connectivity to the remote identity provider. So ... just a few clarifying questions so I understand at high-level how this works. Is the following correct flow of events on the Edge Cloud? ( note have some embedded questions as well ) · Some time during configuration or initial connectivity (?) with the remote Federated Identity Provider, the Edge Cloud Keystone gets CERTIFICATE(s) of the remote Federated Identity Provider, o I assume that these CERTIFICATE(s) can be updated as well by Federated Identity Provider as certs expire or change, · Also at configuration time or initial connectivity, I assume there is also a set of SAML --> OpenStack User/Tenant/Role MAPPINGs that get configured on the Edge Cloud, (Correct ?) · A LOCAL user/client to the Edge Cloud, when sending an authenticated REST API Request, first gets a token from the LOCAL Keystone by sending a Token Request to the LOCAL Keystone with a ‘signed’ SAML doc as the user authentication information o The LOCAL keystone uses the CERTIFICATE(s) (of the federated identity provider) that it has, to validate the SAML doc is authentic, and o Then uses the info in the SAML doc to convert to the associated OpenStack User/Tenant/Role , and o Then generates the appropriate local token. o CORRECT ? o QUESTIONS § How does the LOCAL user/client get the ‘signed’ SAML doc ? · ? does this required connectivity to remote Federated Identity Provider ? Greg. From: Lance Bragstad Date: Monday, June 25, 2018 at 4:26 PM To: "edge-computing at lists.openstack.org" Subject: [Edge-computing] Keystone Edge Architectures Hi Greg, Jumping in a bit late, but I can try and clear up some of the questions around keystone's federated identity implementation. Your initial assessment of federated identity is accurate where each keystone node in the deployment refers to an external identity provider as the source of truth for user identities. But, keystone doesn't actively reach out to the external identity provider at authentication time. Instead, a user presents keystone (which is acting as a service provider) with a SAML document that keystone will verify with a set of certificates from the identity provider. If keystone can prove the SAML assertion came from a trusted identity provider, it processes the attributes through a mapping engine, which essentially translates the SAML assertion into OpenStack-specific terminology. The actual validation of the SAML assertion doesn't require a connection to the identity provider that issued it. This trust relationship is established when setting up federated identity via configuration (e.g. these are the certs for the identity provider that I trust). Hopefully that helps Lance -------------- next part -------------- An HTML attachment was scrubbed... URL: From beth.cohen at verizon.com Tue Jun 26 12:25:50 2018 From: beth.cohen at verizon.com (beth.cohen at verizon.com) Date: Tue, 26 Jun 2018 12:25:50 +0000 Subject: [Edge-computing] Request for help running the Weekly Meeting June 26 Message-ID: <01273bcd8c624d54860e0c6718979246@scwexch25apd.uswin.ad.vzwcorp.com> Folks - I was supposed to help run the call today, but I have a meeting in house that I cannot get out of. I am requesting that someone else run the call instead. Here is the agenda. Thanks in advance. Claire takes care of the recording. The discussion topics for tomorrow's meeting are: * The APAC friendly slot, which is: Every first Thursday of the month at 9am Central European Time / 3pm in Beijing, first APAC call is July 5th * Sub-group updates * Use cases - Beth and Jess * Glance/Dublin review - Gergely * Keystone - The main update here is that we are having a call with the OPNFV Edge Cloud project on Wednesday (3pm Central European / 8am US Central) about Keystone federation testing, we have a handful of people to start working on that to see Keystone's functionality in that area. If anyone is interested on the call to join, here's the etherpad: https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_ECG-5FKeystone-5FTesting&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=a9ccSWQQGtD_IsZs-VrUAE7pE7aMVMjeWUOcqi0mpAI&s=nByM9CiCSM7HyjJNpqCsWwaJIclQw7cnECaJsB81i8o&e= It's in the meeting agenda too. * Keystone Edge architectures - There's also a mail thread about suitable Keystone Edge architectures, that can be a good topic for tomorrow's call. I will also check whether people from the Keystone team could join to revisit and continue the discussion we started in Vancouver at the Forum. [Verizon] Beth Cohen DMTS - NFV/SDN Network Product Strategy Verizon Technology 60 Sylvan Rd Waltham, MA 02451 O +781-466-2055 | M +781-434-8553 beth.cohen at verizon.com [Twitter] [Instagram] -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Sarault at kontron.com Tue Jun 26 12:50:06 2018 From: Eric.Sarault at kontron.com (=?utf-8?B?w4lyaWMgU2FyYXVsdA==?=) Date: Tue, 26 Jun 2018 12:50:06 +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> Message-ID: <22b0f0f372f14815bdf57cc0aedfd9eb@kontron.com> 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 pvaanane at redhat.com Tue Jun 26 13:00:57 2018 From: pvaanane at redhat.com (Pasi Vaananen) Date: Tue, 26 Jun 2018 09:00:57 -0400 Subject: [Edge-computing] =?utf-8?b?562U5aSNOiDnrZTlpI06IENsYXJpZmljYXRp?= =?utf-8?q?on=5Fof=5FRequirements?= In-Reply-To: <22b0f0f372f14815bdf57cc0aedfd9eb@kontron.com> References: <00aa01d4083c$129c7350$37d559f0$@chinamobile.com> <010e01d40874$fcb3d720$f61b8560$@chinamobile.com> <012001d40879$20bab900$62302b00$@chinamobile.com> <7b2e5862b8e84260984b2983d286c8e7@kontron.com> <22b0f0f372f14815bdf57cc0aedfd9eb@kontron.com> Message-ID: <2da6ca80-ec39-9377-e799-fc45df9806b2@redhat.com> True - not everything is rackmount, not even in the network side. And, the depth and therefore volume / power of the one "standard" RU varies by at least a factor of two to four between the sites where RUs are considered to be somewhat relevant. As this discussion is about SW aspects of the system, not how about build and package hardware, we do not need to / should not focus on the nebulous things like RUs as a metric - but number of independent nodes per installation site (it does not matter how the stuff gets packaged, but what it is - and even on the 1RU, one can easily package anything from one to two 2-skt servers and much more of the say Xeon-D's or ARM SoCs in given space / power envelope). Pasi On 06/26/2018 08:50 AM, Éric Sarault wrote: > > 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'sElectronic > 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'sElectronic > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Tue Jun 26 14:45:34 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Tue, 26 Jun 2018 14:45:34 +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 from the meeting: http://eavesdrop.openstack.org/meetings/weekly_edge_computing_group_call/2018/weekly_edge_computing_group_call.2018-06-26-14.02.html OPNFV Edge cloud project meeting: * Next meeting date: 2018.06.27 1500 CET / Calendar invitation attached * Zoom: https://zoom.us/j/5014627785 * Agenda and minutes: https://etherpad.opnfv.org/p/edge_cloud_meeting_minutes 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únius 26 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: -------------- next part -------------- An embedded message was scrubbed... From: Fu Qiao Subject: [opnfv-tech-discuss] [edge cloud]Edge cloud project meeting Date: Wed, 18 Apr 2018 12:15:09 +0000 Size: 8151 URL: From Greg.Waines at windriver.com Wed Jun 27 16:30:34 2018 From: Greg.Waines at windriver.com (Waines, Greg) Date: Wed, 27 Jun 2018 16:30:34 +0000 Subject: [Edge-computing] Keystone Edge Architectures In-Reply-To: <8CB60A46-2C68-444F-994C-45D88FE77D74@windriver.com> References: <678C1A99-2302-438D-8D5D-91ED44B10FF9@windriver.com> <2e2495d6-531f-c0a4-27d6-3c15da111289@gmail.com> <8CB60A46-2C68-444F-994C-45D88FE77D74@windriver.com> Message-ID: Just following up on this mailing list item ... we discussed at the edge-computing weekly meeting. Summary: · FAILURE SCENARIO o EDGE CLOUD and all its LOCAL Users/Clients (e.g. CLI running on cloud or adjacent workstation), have LOST CONNECTIVITY to the Central Cloud and the Central Remote Identity Provider · If a LOCAL User/Client has already authenticated with the Central Remote Identity Provider and already has a signed SAML assertion o Then the LOCAL User/Client can use that signed SAML assertion to create a token with LOCAL Keystone § Where LOCAL Keystone can independently validate the signed SAML Assertion and map to appropriate Keystone objects and create a TOKEN o AND the LOCAL User/Client can then use this TOKEN to proceed with a request to a LOCAL Service. · HOWEVER, If the LOCAL User/Client o Does NOT have a signed SAML assertion yet ... or it expired (? Not sure if they can expire ?), THEN o The LOCAL User/Client can not create a TOKEN. § ( unless there are local (i.e. non-federated) users defined ... but seems to defeat the purpose of federation ) So suspect there still are some connectivity failure scenarios that restrict the autonomy of a disconnected Edge Cloud. *** I would suggest that the testing that we are trying to setup around federated Keystone SHOULD explicitly test these connectivity failure scenarios in order to characterize how bad of an issue this is or not. Let me know if I did not summarize correctly, Greg. From: Greg Waines Date: Tuesday, June 26, 2018 at 7:52 AM To: Lance Bragstad , "edge-computing at lists.openstack.org" Subject: Re: [Edge-computing] Keystone Edge Architectures Thanks Lance ... this clears up my general confusion. So it sounds like user authentication can be performed by the edge keystone, even when it does not currently have connectivity to the remote identity provider. So ... just a few clarifying questions so I understand at high-level how this works. Is the following correct flow of events on the Edge Cloud? ( note have some embedded questions as well ) · Some time during configuration or initial connectivity (?) with the remote Federated Identity Provider, the Edge Cloud Keystone gets CERTIFICATE(s) of the remote Federated Identity Provider, o I assume that these CERTIFICATE(s) can be updated as well by Federated Identity Provider as certs expire or change, · Also at configuration time or initial connectivity, I assume there is also a set of SAML --> OpenStack User/Tenant/Role MAPPINGs that get configured on the Edge Cloud, (Correct ?) · A LOCAL user/client to the Edge Cloud, when sending an authenticated REST API Request, first gets a token from the LOCAL Keystone by sending a Token Request to the LOCAL Keystone with a ‘signed’ SAML doc as the user authentication information o The LOCAL keystone uses the CERTIFICATE(s) (of the federated identity provider) that it has, to validate the SAML doc is authentic, and o Then uses the info in the SAML doc to convert to the associated OpenStack User/Tenant/Role , and o Then generates the appropriate local token. o CORRECT ? o QUESTIONS § How does the LOCAL user/client get the ‘signed’ SAML doc ? · ? does this required connectivity to remote Federated Identity Provider ? Greg. From: Lance Bragstad Date: Monday, June 25, 2018 at 4:26 PM To: "edge-computing at lists.openstack.org" Subject: [Edge-computing] Keystone Edge Architectures Hi Greg, Jumping in a bit late, but I can try and clear up some of the questions around keystone's federated identity implementation. Your initial assessment of federated identity is accurate where each keystone node in the deployment refers to an external identity provider as the source of truth for user identities. But, keystone doesn't actively reach out to the external identity provider at authentication time. Instead, a user presents keystone (which is acting as a service provider) with a SAML document that keystone will verify with a set of certificates from the identity provider. If keystone can prove the SAML assertion came from a trusted identity provider, it processes the attributes through a mapping engine, which essentially translates the SAML assertion into OpenStack-specific terminology. The actual validation of the SAML assertion doesn't require a connection to the identity provider that issued it. This trust relationship is established when setting up federated identity via configuration (e.g. these are the certs for the identity provider that I trust). Hopefully that helps Lance -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Thu Jun 28 07:35:29 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Thu, 28 Jun 2018 07:35:29 +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> Message-ID: Hi, I’ve added the following pros and cons to the different options: * One Glance with multiple backends [1] * 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 * 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 * Several Glances with an independent syncronisation service, synch using the backend [3] * 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 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 Eric.Sarault at kontron.com Thu Jun 28 14:05:44 2018 From: Eric.Sarault at kontron.com (=?iso-8859-1?Q?=C9ric_Sarault?=) Date: Thu, 28 Jun 2018 14:05:44 +0000 Subject: [Edge-computing] Review of Dublin edge notes In-Reply-To: <5c63ad20de9e428285b7b7a7a611772a@kontron.com> References: <5c63ad20de9e428285b7b7a7a611772a@kontron.com> Message-ID: <5eca597286af4714ac7b250c3b326e2d@kontron.com> Sorry, I cannot make it today. Internal emergency. --- 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. -----Original Appointment----- From: Csatari, Gergely (Nokia - HU/Budapest) Sent: June 26, 2018 4:54 AM To: Csatari, Gergely (Nokia - HU/Budapest); 'edge-computing' Subject: [Edge-computing] Review of Dublin edge notes When: June 28, 2018 4:00 PM-5:00 PM (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: 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 * 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 Tue Jun 26 08:51:03 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Tue, 26 Jun 2018 08:51:03 +0000 Subject: [Edge-computing] Review of Dublin edge notes 04 In-Reply-To: References: Message-ID: Hi, Thanks for the votes. We will have the meetings on Thursday 16-17h CET. I will create a recurring invitation. Br, Gerg0 From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Tuesday, June 19, 2018 2:41 PM To: 'edge-computing at lists.openstack.org' ; 'free' ; 'Paul-Andre Raymond' ; 'Éric Sarault' ; 'beth.cohen at verizon.com' ; 'CARVER, PAUL' ; 'Martin Bäckström' ; 'Kit Colbert' ; 'Silverman, Ben' ; 'Srikumar Venugopal' ; 'jonathan at openstack.org' ; 'Waines, Greg' ; 'Shashi Kant Singh' ; 'Mathieu LAGRANGE' ; 'D'ANDREA, JOE (JOE)' ; 'stephan.terblanche at verizonwireless.com' ; 'Mats Karlsson A' ; 'DRUTA, DAN' ; 'BUYUKKOC, CAGATAY' ; 'Francis Dagenais' ; 'Paul Bankert' ; 'Shuquan Huang' ; 'Trinath Somanchi' ; 'Yves Desrochers' ; 'nathan.rader at canonical.com' Cc: 'Arkady.Kanevsky at dell.com' ; 'saiyagar at redhat.com' ; 'Teresa Peluso' Subject: RE: Review of Dublin edge notes 04 Hi, As we discussed ont he meeting we should have a static time for the review meetings during the week. Here is a Doodle to vote for it: https://doodle.com/poll/992km9kvpechnimx Please DO NOT pay attention to the dates, select the time slots the work for you IN GENERAL. Br, Gerg0 From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Thursday, June 14, 2018 5:03 PM To: edge-computing at lists.openstack.org; free >; Paul-Andre Raymond >; Éric Sarault >; beth.cohen at verizon.com; CARVER, PAUL >; Martin Bäckström >; Kit Colbert >; Silverman, Ben >; Srikumar Venugopal >; jonathan at openstack.org; Waines, Greg >; Shashi Kant Singh >; Mathieu LAGRANGE >; D'ANDREA, JOE (JOE) >; stephan.terblanche at verizonwireless.com; Mats Karlsson A >; DRUTA, DAN >; BUYUKKOC, CAGATAY >; Francis Dagenais >; Paul Bankert >; Shuquan Huang >; Trinath Somanchi >; Yves Desrochers >; nathan.rader at canonical.com Cc: Arkady.Kanevsky at dell.com; saiyagar at redhat.com; Teresa Peluso > Subject: RE: Review of Dublin edge notes 04 Hi, Minutes of todays meeting: http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes_04/2018/review_of_dublin_edge_notes_04.2018-06-14-14.18.html Br, Gerg0 -----Original Appointment----- From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Monday, June 11, 2018 10:15 AM To: Csatari, Gergely (Nokia - HU/Budapest); edge-computing at lists.openstack.org; free; Paul-Andre Raymond; Éric Sarault; beth.cohen at verizon.com; CARVER, PAUL; Martin Bäckström; Kit Colbert; Silverman, Ben; Srikumar Venugopal; jonathan at openstack.org; Waines, Greg; Shashi Kant Singh; Mathieu LAGRANGE; D'ANDREA, JOE (JOE); stephan.terblanche at verizonwireless.com; Mats Karlsson A; DRUTA, DAN; BUYUKKOC, CAGATAY; Francis Dagenais; Paul Bankert; Shuquan Huang; Trinath Somanchi; Yves Desrochers; nathan.rader at canonical.com Cc: Arkady.Kanevsky at dell.com; saiyagar at redhat.com; Teresa Peluso Subject: Review of Dublin edge notes 04 When: csütörtök 2018. június 14 16:00-17:00 (UTC+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague. Where: #edge-computing-group Hi, Let's continue the IRC meeting to discuss the comments to the Dublin edge notes: https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG 5.3 Requirements . Notes of the previous meetings: * 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 zhaoqihui at chinamobile.com Thu Jun 28 09:54:10 2018 From: zhaoqihui at chinamobile.com (zhaoqihui at chinamobile.com) Date: Thu, 28 Jun 2018 17:54:10 +0800 Subject: [Edge-computing] =?gb2312?b?tPC4tDogIFtvcG5mdi10ZWNoLWRpc2N1c3Np?= =?gb2312?b?b25dW0VkZ2UgQ2xvdWRdIG1pbnV0ZXMgZm9yIHdlZWtseSBtZWV0?= =?gb2312?b?aW5nIG9uIEp1bmUgMjd0aA==?= Message-ID: <000701d40ec5$f70c9490$e525bdb0$@chinamobile.com> Hi Team, Here is the meeting minutes for this week: https://etherpad.opnfv.org/p/edge_cloud_meeting_minutes * continue discussion on keystone testing * https://etherpad.openstack.org/p/ECG_Keystone_Testing * https://wiki.openstack.org/wiki/Keystone_edge_architectures * scenario from OPNFV: real deployment, e.g. real multi cloud in distributed sites * keystone team expects edge cloud team to define the scenario, write opnfv-edge-specific test cases (current keystone federation test cases are basic), and provide OPNFV Pharos hardware topology for real OpenStack deployment * EC WG are still talking about whether federation is a good solution, other option could be db replication * OPNFV can start with two baremetal environment in same lab, and develop the testcase first. will have to see if the current framework in opnfv can be used * people who are interested in keystone edge testing, please sign up: https://etherpad.opnfv.org/p/edge_cloud_meeting_minutes * continue discussion on EnOS * enoslib: https://enoslib.readthedocs.io/en/stable/ - Book resources - Emulate your infrastructure (TC) + Netem: https://wiki.linuxfoundation.org/networking/netem - deploy a complex software * enoslib has been used to conduct such experiments: +ombt-orchestrator ( AMQP alternatives for the edge) - enoslib + oslo - https://docs.openstack.org/performance-docs/latest/test_plans/massively_dist ribute_rpc/plan.html + juice (devstack / keystone in an edge context) - enoslib + devstack for keystone - https://beyondtheclouds.github.io/blog/openstack/cockroachdb/2018/06/04/eval uation-of-openstack-multi-region-keystone-deployments.html * Enos: https://enos.readthedocs.io/en/stable/ EnOSlib + OpenStack * See FEMDC webpage for more enos-related presentation: https://wiki.openstack.org/wiki/Fog_Edge_Massively_Distributed_Clouds#Achiev ed_Actions * requirement doc has been uploaded to gerrti: https://gerrit.opnfv.org/gerrit/#/c/58959/ . Please review and leave your comment for the report. * Alternative meeting on Thursday might be canceled. We’ll continue meeting on Wednesday bi-weekly. Best, Qihui -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Thu Jun 28 14:36:57 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Thu, 28 Jun 2018 14:36:57 +0000 Subject: [Edge-computing] Review of Dublin edge notes Message-ID: Hi, Today we had only a 30 min meeting due to low participation. Notes are here: http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/review_of_dublin_edge_notes.2018-06-28-14.01.html Some questions related to Keystone: * Can a Keystone in VIO act as an Identity provider for K2K federation? * Do we need further synchronisation of RBAC data on top of what we have in K2K federation? Thanks, Gerg0 -----Original Appointment----- From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Tuesday, June 26, 2018 10:53 AM To: Csatari, Gergely (Nokia - HU/Budapest); 'edge-computing' Cc: 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 Subject: Review of Dublin edge notes When: csütörtök 2018. június 28 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: 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 * 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 Jun 28 14:40:27 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Thu, 28 Jun 2018 14:40:27 +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.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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 4470 bytes Desc: not available URL: From lbragstad at gmail.com Thu Jun 28 16:26:47 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Thu, 28 Jun 2018 11:26:47 -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> Message-ID: <28270e37-13b5-2baa-6952-b084f81e3887@gmail.com> On 06/27/2018 11:30 AM, Waines, Greg wrote: > > Just following up on this mailing list item ... we discussed at the > edge-computing weekly meeting. > >   > > Summary: > > ·         FAILURE SCENARIO > > o    EDGE CLOUD and all its LOCAL Users/Clients (e.g. CLI running on > cloud or adjacent workstation), > have LOST CONNECTIVITY to the Central Cloud and the Central Remote > Identity Provider > > ·         If a LOCAL User/Client has already authenticated with the > Central Remote Identity Provider and >                                                   already has a signed > SAML assertion > > o    Then the LOCAL User/Client can use that signed SAML assertion > to create a token with LOCAL Keystone > > §  Where LOCAL Keystone can independently validate the signed SAML > Assertion > and map to appropriate Keystone objects and create a TOKEN > > o    AND > the LOCAL User/Client can then use this TOKEN to proceed with a > request to a LOCAL Service. > > ·         HOWEVER, > If the LOCAL User/Client > > o    Does NOT have a signed SAML assertion yet ... or it expired (? > Not sure if they can expire ?), > I should clarify this a bit. Keystone doesn't deal with SAML directly when it act as a service provider. Instead it uses Apache plugins (e.g. mod_shib) to do the SAML verification. This is also related to the bit on the call where Kristi and I talked about how keystone needs to establish trust with the identity provider. Keystone, specifically mod_shib and the web server, need to be configured with the certificates used to validate SAML from the identity provider, which is an out-of-band process. >         THEN > > o    The LOCAL User/Client can not create a TOKEN. > > §  ( unless there are local (i.e. non-federated) users defined ... but > seems to defeat the purpose of federation ) > >   > > So suspect there still are some connectivity failure scenarios that > restrict the autonomy of a disconnected Edge Cloud. > >   > > */*** I would suggest that the testing that we are trying to setup > around federated Keystone SHOULD explicitly >         test these connectivity failure scenarios in order to > characterize how bad of an issue this is or not./* > >   > > Let me know if I did not summarize correctly, > > Greg. > 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/ >   > >   > > *From: *Greg Waines > *Date: *Tuesday, June 26, 2018 at 7:52 AM > *To: *Lance Bragstad , > "edge-computing at lists.openstack.org" > *Subject: *Re: [Edge-computing] Keystone Edge Architectures > >   > > Thanks Lance ... this clears up my general confusion. > > So it sounds like user authentication can be performed by the edge > keystone, even when it does not currently have connectivity to the > remote identity provider. > >   > > So ... just a few clarifying questions so I understand at high-level > how this works. > >   > > Is the following correct flow of events on the Edge Cloud? > > ( note have some embedded questions as well ) > > > ·         Some time during configuration or initial connectivity (?) > with the remote Federated Identity Provider, > the Edge Cloud Keystone gets CERTIFICATE(s) of the remote Federated > Identity Provider, > > o   I assume that these CERTIFICATE(s) can be updated as well by > Federated Identity Provider > as certs expire or change, > > > ·         Also at configuration time or initial connectivity, > I assume there is also a set of SAML àOpenStack User/Tenant/Role > MAPPINGs that get configured > on the Edge Cloud,   (Correct ?) > > > ·         A _LOCAL user/client_ to the Edge Cloud, when sending an > authenticated REST API Request, > first gets a token from the LOCAL Keystone by sending a Token Request > to the LOCAL Keystone > with a ‘signed’ SAML doc as the user authentication information > > o   The LOCAL keystone uses the CERTIFICATE(s) (of the federated > identity provider) that it has, > to validate the SAML doc is authentic, and > > o   Then uses the info in the SAML doc to convert to the associated > OpenStack User/Tenant/Role , and > > o   Then generates the appropriate local token. > > o   CORRECT ? > > > > o   QUESTIONS > > §  How does the LOCAL user/client get the ‘signed’ SAML doc ? > > ·         ? does this required connectivity to remote Federated > Identity Provider ? > >   > >   > > Greg. > >   > >   > >   > > *From: *Lance Bragstad > *Date: *Monday, June 25, 2018 at 4:26 PM > *To: *"edge-computing at lists.openstack.org" > > *Subject: *[Edge-computing] Keystone Edge Architectures > >   > > Hi Greg, > >   > > Jumping in a bit late, but I can try and clear up some of the questions > > around keystone's federated identity implementation. > >   > > Your initial assessment of federated identity is accurate where each > > keystone node in the deployment refers to an external identity provider > > as the source of truth for user identities. But, keystone doesn't > > actively reach out to the external identity provider at authentication > > time. Instead, a user presents keystone (which is acting as a service > > provider) with a SAML document that keystone will verify with a set of > > certificates from the identity provider. If keystone can prove the SAML > > assertion came from a trusted identity provider, it processes the > > attributes through a mapping engine, which essentially translates the > > SAML assertion into OpenStack-specific terminology. > >   > > The actual validation of the SAML assertion doesn't require a connection > > to the identity provider that issued it. This trust relationship is > > established when setting up federated identity via configuration (e.g. > > these are the certs for the identity provider that I trust). > >   > > Hopefully that helps > >   > > Lance > >   > >   > -------------- 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 Greg.Waines at windriver.com Fri Jun 29 01:29:57 2018 From: Greg.Waines at windriver.com (Waines, Greg) Date: Fri, 29 Jun 2018 01:29:57 +0000 Subject: [Edge-computing] Keystone Edge Architectures In-Reply-To: <28270e37-13b5-2baa-6952-b084f81e3887@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> Message-ID: Hey Lance, Thanks for the info below So seems like from previous discussions there is a little hesitation about “use of fernet issued from one keystone in another”, unless if “replicated/in-sync keystones” are used. ( is that correct interpretation ? ... or is it a total ‘-2’ on fernet tokens from one keystone used in another ? ) Does “replicated/in-sync keystones” refer to keytsones whose DBs are sync’d at the DB-level ? ( e.g. one read/write DB and many read replicas ? ) If yes, .... how does one handle Software Upgrade across a Distributed Cloud in this “replicated keystone” environment, where the Central Cloud Keystone could have a different DB schema than the Edge Subcloud ? 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 Greg.Waines at windriver.com Fri Jun 29 02:24:45 2018 From: Greg.Waines at windriver.com (Waines, Greg) Date: Fri, 29 Jun 2018 02:24:45 +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> Message-ID: <0B139046-4F69-452E-B390-C756543EA270@windriver.com> In-lined comments / questions below, Greg. From: "Csatari, Gergely (Nokia - HU/Budapest)" > Date: Thursday, June 28, 2018 at 3:35 AM To: "ekuvaja at redhat.com" >, 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, 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) ? * 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. * 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. * 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. * 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: