From beth.cohen at verizon.com Mon Feb 5 04:18:49 2018 From: beth.cohen at verizon.com (beth.cohen at verizon.com) Date: Mon, 5 Feb 2018 04:18:49 +0000 Subject: [Edge-computing] Request for people interested in an Edge Computing Security session at Summit Message-ID: <0817208cbd1d4edcab7b9fad31762aee@OMZP1LUMXCA08.uswin.ad.vzwcorp.com> Folks - I have submitted a proposal for a session at the Vancouver Summit on Securing the Edge. I am looking for people who would like to join me on the panel/presentation. Drop me a note if you are interested in participating. Cloud Edge computing use cases range from IoT to VR/AR and any widely distributed application in between. However, taking OpenStack out of the data center requires an entirely new approach to security when there is far less ability to restrict access and often the applications require a shared tenant model. Some of the factors that need to be considered include: • More stringent requirements for infrastructure software (code/design) in exposed environments • New ways of thinking about RBAC at the control interfaces • Conflicts arising from shared ownership and divided responsibilities for devices/systems/applications • Managing lifecycle operations and deployments over insecure WAN connections • Different ways of looking at tenant spaces in remote locations • Imposing network/compute/storage/memory separation from the underlying virtualization/hardware components • Managing security over intermittent WAN connections • Securing semi-autonomous and self-managed locations Beth Cohen NFV/SDN Network Product Strategy O +781-466-2055 | M +781-434-8553 beth.cohen at verizon.com      From pramchan at yahoo.com Tue Feb 6 08:17:13 2018 From: pramchan at yahoo.com (prakash RAMCHANDRAN) Date: Tue, 6 Feb 2018 08:17:13 +0000 (UTC) Subject: [Edge-computing] 2018 Work Sessions for Attemting to drive Edge Computing towards Abstractions References: <1906914376.4442858.1517905033376.ref@mail.yahoo.com> Message-ID: <1906914376.4442858.1517905033376@mail.yahoo.com> Hi all, First returning to Edge after few months and like to understand what I saw was discussed in this forum till now, from OpenDev at SF last year till date: 1. General idea of Special VM at edge as cloudlet by Prof Satya of CMU with his App centric approach and more geared towards computing 1 hop from device, clearly the best reserach to date for Edge cloud/computing. 2.use cases - edge could infra, single vs multi-operator, capacity, alarms/monitor, unified dashbaord, PM, FM, VM migration, Discovery, Registry, VM Overlay/Sythesys, VM Residual3. LTE based edge with RRH, ENB, Front end micro DC for Mobile apps.(like CMU /Nokia labs)4.  Classifiation of Infra based on sizing of requirments at edge by compute/HPC, stoarge, throughput,latnecy, Interaction and typical use cases in auto for V2I with hierarchial cloud with edge closer to device. All variations have some or the other proprietary approach and we need lowest common base to make sense from to defining edge cloud Infra or edge cloud App. Abstractions are key and here is an attempt to arrive at commn absractions for use cases. Suggest we discuss how to derive lowest coomon objects based on following Abstracions as a start: Abstratiing edge compute Infrastructure & Applications for Openstack 1. IDP - Third Party/ CSP2. Cloud and/or CSP - Provider/Tenanant, Type - Central/Ditributed/Edge3. Cluster - node (Compute, Network, Storage, Mixed, cloudlet ), type (Phy, Virt), topology, template, capability(Bandwidth, Latency, Jitter)4. Service composition over Cluster using VM, Containers or Unikernal5. Serbice Discovery & Registartion in Catalog6. Workload Supported - Video Streaming, Real time Application(Audio, Alarms), IoT Application, Interactive apps like Games/AR/VR/MR, Presence and Messaging (twitter/IM)7. Hardware Acceleration - Compression, Encryption, Offloading workloads8.Stateless and State Management for Applications on Edge Infrastructure 9. End-to-End Service level Policy, Resource pooling/Charging , Resiliance and other Opesrational complexity management. Since we have had many false starts sticking to basics like Prof. Saty suggetss is the best way and you are welcome to tear apart what I write here to give some alternate approach to simplify the complexity of dancing elephents as our reaserch folks call it. Also if you can educate on any projects that have covered of late any of the above which I am un-aware please educate me. Our window to close is Thursday for Vanouver CFP and like to hear from you all to see where are we headed after several attempts to get consensus on Edge Computing. We discuss this based on time available this or few more weeks when we continue this to get some reasoanble idea for blueprints and directions we take in 2018. ThanksPrakash -------------- next part -------------- An HTML attachment was scrubbed... URL: From claire at openstack.org Thu Feb 8 16:40:03 2018 From: claire at openstack.org (Claire Massey) Date: Thu, 8 Feb 2018 10:40:03 -0600 Subject: [Edge-computing] CFP Deadline Today - OpenStack Summit Vancouver Message-ID: <23F5D791-027B-44F4-AD37-9265D6105CC3@openstack.org> Hi everyone, Final reminder - the Vancouver Summit CFP closes TODAY at 11:59pm PST (February 9 at 6:59am UTC). Please consider submitting a talk to the *Edge Computing* track and invite your colleagues from other open source communities to come speak and collaborate. List of tracks: • Container infrastructure • Edge computing • CI/CD • HPC/GPU/AI • Open source community • OpenStack private, public and hybrid cloud View topic ideas for each track HERE . Please submit your proposals before the deadline today. Thanks! Claire -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openstack.org Wed Feb 14 16:06:53 2018 From: ildiko at openstack.org (Ildiko Vancsa) Date: Wed, 14 Feb 2018 17:06:53 +0100 Subject: [Edge-computing] New Cloud Edge Computing white paper Message-ID: Hi everyone, I’m very excited to share that today, the OSF Edge Computing Group released 'Cloud Edge Computing: Beyond the Data Center', a white paper that explores the area of edge computing by identifying use cases, scenarios and commonalities in the challenges to support broadscale edge computing adoption. Members of the OSF Edge Computing Group—including representatives from AT&T, B.Yond, Cisco, Ericsson, HPE, IMT Atlantique, Inmarsat, Red Hat, Verizon and Walmart Labs—have identified fundamental requirements and are issuing a challenge to the open infrastructure community to create and/or adapt the tools that are needed to enable broad adoption. In addition to the white paper, the group has established weekly meetings to further the cross-community collaboration around edge computing. Interested in joining? Learn more about the Edge Computing Group and how you can get involved: https://www.openstack.org/edge-computing/ Thank you to everyone who contributed! Best Regards, Ildikó From claire at openstack.org Tue Feb 20 16:54:57 2018 From: claire at openstack.org (Claire Massey) Date: Tue, 20 Feb 2018 10:54:57 -0600 Subject: [Edge-computing] Community Voting- OpenStack Summit Vancouver 2018 Message-ID: Hi everyone, Session voting is now open for the May 2018 OpenStack Summit in Vancouver. VOTE HERE Hurry, voting closes Sunday, February 25 at 11:59pm Pacific Time (Monday, February 26 at 7:59 UTC). The Programming Committees will ultimately determine the final schedule. Community votes are meant to help inform the decision, but are not considered to be the deciding factor. The Programming Committee members exercise judgment in their area of expertise and help ensure diversity. View full details of the session selection process here . Continue to visit https://www.openstack.org/summit/vancouver-2018 for all Summit-related information. REGISTER Register HERE before prices increase in early April! VISA APPLICATION PROCESS More information about the visa process can be found HERE . TRAVEL SUPPORT PROGRAM March 22 is the last day to submit applications. Please submit your applications HERE by 11:59pm Pacific Time (March 23 at 6:59am UTC). If you have any questions, please email summit at openstack.org . Thanks, Claire -------------- next part -------------- An HTML attachment was scrubbed... URL: From claire at openstack.org Tue Feb 20 18:00:32 2018 From: claire at openstack.org (Claire Massey) Date: Tue, 20 Feb 2018 12:00:32 -0600 Subject: [Edge-computing] New Weekly Call Times, Starting March 13 Message-ID: <75FFF6ED-3B5C-4EA9-B770-377E02609CC7@openstack.org> Hi everyone, If you’re attending the PTG event in Dublin next week, we’ll be hosting Edge discussions on Monday and Tuesday in the Celtic Suite on Level 5 of Croke Park. You can view the proposed agenda here: https://etherpad.openstack.org/p/edge-ptg-dublin . Moving forward we’d like to adjust the time of our weekly OSF Edge Computing Group calls to accommodate different timezones. Below is the list of upcoming calls with alternating times each week - at 7:00am PT and 5:00pm PT. If you haven’t yet joined the weekly calls, we invite you to get involved here: *Meeting Link for all calls: https://zoom.us/j/777719876 *Notes & Recordings for all calls: https://etherpad.openstack.org/p/2017_edge_computing_working_sessions UPCOMING SCHEDULE: Tuesdays at 5:00pm PT / Wednesdays at 1:00 UTC: *March 13 *March 27 *April 10 *April 24 *May 8 Tuesdays at 7:00am PT / 15:00 UTC: *March 20 *April 3 *April 17 *May 1 *May 15 Please email me directly if you’d like to be added to the calendar invite for the above call schedule. Thanks, Claire -------------- next part -------------- An HTML attachment was scrubbed... URL: From asimha at redhat.com Thu Feb 22 14:25:40 2018 From: asimha at redhat.com (Ajay Simha) Date: Thu, 22 Feb 2018 09:25:40 -0500 Subject: [Edge-computing] Oaktree Message-ID: <2F95AC44-2185-4E58-94D3-F46313D2143E@redhat.com> Hi, I believe it was Monty talking about Oaktree on Tuesday’s call. Do you see Oaktree being used by ONAP and similar MANOs to orchestrate/manage different clouds? Thanks Ajay AJAY SIMHA SR. PRINCIPAL ARCHITECT - TELCO PRACTICE Red Hat  100 E. Davie St. Raleigh, NC 27601 asimha at redhat.com T: +19197544490 M: +19195220465 TRIED. TESTED. TRUSTED. -------------- next part -------------- An HTML attachment was scrubbed... URL: From srinivasa.r.addepalli at intel.com Thu Feb 22 14:37:21 2018 From: srinivasa.r.addepalli at intel.com (Addepalli, Srinivasa R) Date: Thu, 22 Feb 2018 14:37:21 +0000 Subject: [Edge-computing] Oaktree In-Reply-To: <2F95AC44-2185-4E58-94D3-F46313D2143E@redhat.com> References: <2F95AC44-2185-4E58-94D3-F46313D2143E@redhat.com> Message-ID: ONAP uses two kinds of APIs - HEAT API - Individual component API. My understanding ONAP is moving towards second method of calling individual component API when ONAP moves to TOSCA based orchestration. They are all REST API, not the gRPC APIs. Is Oaktree part of Pike release? Thanks Srini From: Ajay Simha [mailto:asimha at redhat.com] Sent: Thursday, February 22, 2018 6:26 AM To: edge-computing at lists.openstack.org Subject: [Edge-computing] Oaktree Hi, I believe it was Monty talking about Oaktree on Tuesday’s call. Do you see Oaktree being used by ONAP and similar MANOs to orchestrate/manage different clouds? Thanks Ajay AJAY SIMHA SR. PRINCIPAL ARCHITECT - TELCO PRACTICE Red Hat 100 E. Davie St. Raleigh, NC 27601 asimha at redhat.com T: +19197544490 M: +19195220465 [Image removed by sender.] TRIED. TESTED. TRUSTED. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 500 bytes Desc: image001.jpg URL: From thingee at gmail.com Thu Feb 22 15:39:17 2018 From: thingee at gmail.com (Mike Perez) Date: Thu, 22 Feb 2018 07:39:17 -0800 Subject: [Edge-computing] Oaktree In-Reply-To: References: <2F95AC44-2185-4E58-94D3-F46313D2143E@redhat.com> Message-ID: <20180222153917.GB32596@gmail.com> On 14:37 Feb 22, Addepalli, Srinivasa R wrote: > ONAP uses two kinds of APIs > > - HEAT API > > - Individual component API. > > My understanding ONAP is moving towards second method of calling individual > component API when ONAP moves to TOSCA based orchestration. They are all > REST API, not the gRPC APIs. > > Is Oaktree part of Pike release? Oaktree is very much still in development. It currently supports list images and list flavors so far. Monty sent an email back in November giving the current state and future, although these ideas might be out of date. http://lists.openstack.org/pipermail/openstack-dev/2017-November/124974.html -- Mike Perez (thingee) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lebre.adrien at free.fr Sat Feb 24 11:19:56 2018 From: lebre.adrien at free.fr (lebre.adrien at free.fr) Date: Sat, 24 Feb 2018 12:19:56 +0100 (CET) Subject: [Edge-computing] Oaktree In-Reply-To: <20180222153917.GB32596@gmail.com> Message-ID: <1810724299.496158894.1519471196947.JavaMail.root@zimbra29-e5> Hi all, >From my viewpoint, Oaktree (like ONAP) can be considered as top/down (or over the top) solutions. That is, they use/orchestrate cloud software stacks such as OpenStack. Unless I miss a discussion/mail ;), the question whether we should go to an -- over the top or bottom/up or even an hybrid -- approach is still undefined. With an over-the-top solution, you may have to reimplement a lot of mechanisms/services that are already available at the cloud level (i.e. inside the Openstack codebase). I'm thinking about things like scheduling (Placement API), VM image sharing (geo-distributed Glance), ...). Moreover, it is not clear that such over-the-top solution can fulfil some edge requirements such as the network-split-brain one. In other words, will/should the over-the-top solution be fully distributed in the sense that there is an entry point on each edge site? Can end-users use the edge-site directly without going through the over-the-top API? How mitigating synchronisation problems that may occur in such a context? On the other side (bottom/up approach), making a software stack as complex as OpenStack collaborative is definitely a challenge that could require significant efforts in terms of development (probably requiring important revisions in major services). Is the OpenStack community ok/ready to do such an effort? I hope the PTG discussion will enable us to clarify the different pros/cons of each approach in order to mitigate the development efforts overall and reduce also the complexity of the whole resource management system of an edge infrastructure. I'm definitely not an Oaktree nor ONAP expert but I think it would be valuable to better understand what is inside and try to identify whether some of the mechanisms are not redundant in somehow with the OpenStack ones. >From my viewpoint, it is important if we go with an over-the-top solution to keep the complexity of the global software stack as minimal as possible. My two cents, Adrien PS: A similar debate has been done during the Tricircle big tent application (in 2016). It led to the split of Tricircle in two projets: Tricircle that deals with the network aspects and Trio2o, which aims to orchestrate several regions. The first one is under the big tent whereas the added value of the second one w.r.t. the Openstack codebase was not convincing enough to be accepted as a new project. ----- Mail original ----- > De: "Mike Perez" > À: "Srinivasa R Addepalli" > Cc: edge-computing at lists.openstack.org > Envoyé: Jeudi 22 Février 2018 16:39:17 > Objet: Re: [Edge-computing] Oaktree > > On 14:37 Feb 22, Addepalli, Srinivasa R wrote: > > ONAP uses two kinds of APIs > > > > - HEAT API > > > > - Individual component API. > > > > My understanding ONAP is moving towards second method of calling > > individual > > component API when ONAP moves to TOSCA based orchestration. They > > are all > > REST API, not the gRPC APIs. > > > > Is Oaktree part of Pike release? > > Oaktree is very much still in development. It currently supports list > images > and list flavors so far. Monty sent an email back in November giving > the > current state and future, although these ideas might be out of date. > > http://lists.openstack.org/pipermail/openstack-dev/2017-November/124974.html > > -- > Mike Perez (thingee) > > _______________________________________________ > Edge-computing mailing list > Edge-computing at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing > From yih.leong.sun at intel.com Sat Feb 24 18:07:01 2018 From: yih.leong.sun at intel.com (Sun, Yih Leong) Date: Sat, 24 Feb 2018 18:07:01 +0000 Subject: [Edge-computing] Oaktree In-Reply-To: <1810724299.496158894.1519471196947.JavaMail.root@zimbra29-e5> References: <20180222153917.GB32596@gmail.com>, <1810724299.496158894.1519471196947.JavaMail.root@zimbra29-e5> Message-ID: <317E3C85-1A2A-4423-A55F-DFA6ECDCCC5A@intel.com> My understanding on Oaktree is it is a gPRC API and support multiple clouds (currently for multiple OpenStack Clouds / Regions but potentially can support non-OpenStack cloud in the future) and provide consistent model for “user” to manage resources across “differences” in every clouds. It uses gRPC and protobuf which is more streamline and network efficient. > On Feb 24, 2018, at 3:20 AM, "lebre.adrien at free.fr" wrote: > > Hi all, > > From my viewpoint, Oaktree (like ONAP) can be considered as top/down (or over the top) solutions. > That is, they use/orchestrate cloud software stacks such as OpenStack. > > Unless I miss a discussion/mail ;), the question whether we should go to an -- over the top or bottom/up or even an hybrid -- approach is still undefined. > > With an over-the-top solution, you may have to reimplement a lot of mechanisms/services that are already available at the cloud level (i.e. inside the Openstack codebase). I'm thinking about things like scheduling (Placement API), VM image sharing (geo-distributed Glance), ...). > Moreover, it is not clear that such over-the-top solution can fulfil some edge requirements such as the network-split-brain one. In other words, will/should the over-the-top solution be fully distributed in the sense that there is an entry point on each edge site? Can end-users use the edge-site directly without going through the over-the-top API? How mitigating synchronisation problems that may occur in such a context? > > On the other side (bottom/up approach), making a software stack as complex as OpenStack collaborative is definitely a challenge that could require significant efforts in terms of development (probably requiring important revisions in major services). Is the OpenStack community ok/ready to do such an effort? > > I hope the PTG discussion will enable us to clarify the different pros/cons of each approach in order to mitigate the development efforts overall and reduce also the complexity of the whole resource management system of an edge infrastructure. > > I'm definitely not an Oaktree nor ONAP expert but I think it would be valuable to better understand what is inside and try to identify whether some of the mechanisms are not redundant in somehow with the OpenStack ones. > From my viewpoint, it is important if we go with an over-the-top solution to keep the complexity of the global software stack as minimal as possible. > > > My two cents, > Adrien > PS: A similar debate has been done during the Tricircle big tent application (in 2016). It led to the split of Tricircle in two projets: Tricircle that deals with the network aspects and Trio2o, which aims to orchestrate several regions. The first one is under the big tent whereas the added value of the second one w.r.t. the Openstack codebase was not convincing enough to be accepted as a new project. > > ----- Mail original ----- >> De: "Mike Perez" >> À: "Srinivasa R Addepalli" >> Cc: edge-computing at lists.openstack.org >> Envoyé: Jeudi 22 Février 2018 16:39:17 >> Objet: Re: [Edge-computing] Oaktree >> >>> On 14:37 Feb 22, Addepalli, Srinivasa R wrote: >>> ONAP uses two kinds of APIs >>> >>> - HEAT API >>> >>> - Individual component API. >>> >>> My understanding ONAP is moving towards second method of calling >>> individual >>> component API when ONAP moves to TOSCA based orchestration. They >>> are all >>> REST API, not the gRPC APIs. >>> >>> Is Oaktree part of Pike release? >> >> Oaktree is very much still in development. It currently supports list >> images >> and list flavors so far. Monty sent an email back in November giving >> the >> current state and future, although these ideas might be out of date. >> >> http://lists.openstack.org/pipermail/openstack-dev/2017-November/124974.html >> >> -- >> Mike Perez (thingee) >> >> _______________________________________________ >> 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 dtroyer at gmail.com Sat Feb 24 21:13:12 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Sat, 24 Feb 2018 15:13:12 -0600 Subject: [Edge-computing] Oaktree In-Reply-To: <317E3C85-1A2A-4423-A55F-DFA6ECDCCC5A@intel.com> References: <20180222153917.GB32596@gmail.com> <1810724299.496158894.1519471196947.JavaMail.root@zimbra29-e5> <317E3C85-1A2A-4423-A55F-DFA6ECDCCC5A@intel.com> Message-ID: On Sat, Feb 24, 2018 at 12:07 PM, Sun, Yih Leong wrote: > My understanding on Oaktree is it is a gPRC API and support multiple clouds (currently for multiple OpenStack Clouds / Regions but potentially can support non-OpenStack cloud in the future) and provide consistent model for “user” to manage resources across “differences” in every clouds. It uses gRPC and protobuf which is more streamline and network efficient. To expand on Leong's answer a bit, Oaktree encapsulates the OpenStack Shade library[0] behind a gRPC API to remove deployment differences for applications that need to use multiple OpenStack clouds. (The gRPC part is not a requirement, it could just as well be REST.) This relieves applications from needing to know or care about the various ways OpenStack might be deployed. And we know it works because the Nodepool component of the OpenStack CI infrastructure uses it to manage the numerous clouds used for all of OpenStack CI testing. Expanding Oaktree to other cloud APIs would effectively be a re-write of Apache jclouds, rather something like jclouds would offload the deployment details to Oaktree for its OpenStack back-end. dt [0] Shade as been merged into the OpenStackSDK project which is approaching a 1.0 release at which time Shade itself will begin its transition to a call-through wrapper to the SDK. This will bring all of the current 'business login' in Shade to all consumers of the SDK such as OpenStackClient. -- Dean Troyer dtroyer at gmail.com From gergely.csatari at nokia.com Wed Feb 28 13:58:53 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Wed, 28 Feb 2018 13:58:53 +0000 Subject: [Edge-computing] Afterlife of the PTG edge discussions Message-ID: Hi, Thanks Adrian for facilitating the workshop. It was a very interesting and diverse discussion 😉 I can help in organizing the notes after the PTG workshop. We used 3 etherpads: * PTG schedule: https://etherpad.openstack.org/p/edge-ptg-dublin * Gap analyzis: https://etherpad.openstack.org/p/edge-gap-analysis * Alans problems: https://etherpad.openstack.org/p/edge-alans-problems In the PTG schedule and the Gap analyzis we have high level discussions mostly about what we would like to do while in Alans problems we have detailed notes about some parts of how we would like to solve some of the problems. I think both of these are valuable information and we should somehow have the following things: * a description about what we would like to achieve. Maybe in some other format than a list of etherpads. * a list of concrete requirements to specific projects (being existing or something new) * maybe some prototypes based on the Tuesday afternoon discussions for the keystone data and image distribution (by the way can someone post the picture of THE PLAN?) Any opinions? Br, Gerg0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lebre.adrien at free.fr Wed Feb 28 15:07:15 2018 From: lebre.adrien at free.fr (lebre.adrien at free.fr) Date: Wed, 28 Feb 2018 16:07:15 +0100 (CET) Subject: [Edge-computing] Afterlife of the PTG edge discussions In-Reply-To: Message-ID: <260398208.516642890.1519830435823.JavaMail.root@zimbra29-e5> Hi Gerg0, > > [...] > I can help in organizing the notes after the PTG workshop. > > Thanks, > > [...] > > I think both of these are valuable information and we should somehow > have the following things: > > * a description about what we would like to achieve. Maybe in > some other format than a list of etherpads. Definitely ;-) First, I think the monday's list should be completed with the additional informations that have been identified through the allan's problem - being able to define roles per regions/sites (one user may have some specific rights on one site while being not allowed to use specific services on another one. - ... Moreover, we should probably redistribute the different requirements according to the perspective of an end-user/developer vs an administrator (right now, most of the admin operations belong to Level 5, not sure this is the best way to classify, especially if the goal is to class each operation according to the complexity level). > * a list of concrete requirements to specific projects (being > existing or something new) Yes, maybe this requires a bit of works from our side but I think you're right: it is definitely the right way to go. > * maybe some prototypes based on the Tuesday afternoon > discussions for the keystone data and image distribution (by the > way can someone post the picture of THE PLAN?) I think Ildiko took a photo of the Jonathan's diagram. >From my side to be honest, there are still some points that are unclear (i.e. or at least I need more time to be convinced before starting prototyping :-P). In particular: - Using this new NKB means that each edge site will be passive (in the sense that you cannot create a new role/a new VM image/a new... without going through the NKB service? What will happen if someone wants to create a new VM image from the edge but the NKB is not reachable? Don't get me wrong, I'm convinced that being non intrusive is good (so developing a mechanism that enables collaborations between independent edge sites by leveraging only APIs makes sense). The doubts I have are regarding how such mechanisms can be implemented while mitigating as much as possible (i) communications between edge sites and this service and (ii) possible inconsistency issues. - At the end, we also briefly mentioned that the NKB will ensure some guarantees (i.e. like an autonomous checker in charge of maintaining the presence/availability of specific images across the sites). This also makes sense but looks to be an advanced self-healing feature. Ok, Why not? If we can do it it is great. However, I'm bit scared about what will be present at the end inside this NKB service (and all golden* services)? - What is the difference between such a new NKB and the tricircle proposal (before splitting) is also something I think it would be valuable to better understand? - I didn't attend the nova session unfortunately this morning but I get the feeling that we can also learn a lot from the questions they have been discussing for more than two years regarding the cell V2 architecture (see for instance [2] line 37 the discussion regarding glance for all cells vs one glance per cells vs....). Moving forward on the question of being able to benefit from the locality aspects, which is also an advanced feature from my viewpoint (i.e. instead of pulling my image from the golden glance, I would like to get it from my neighbourhood). I'm wondering how this run nowadays with Glance on a large cluster (are Glance/Nova rack aware: if an image is available on one compute node and you want to provision a new VM with the same image on a server which belongs to the same rack. Is Glance/Nova pulling the image from the official URI or from the compute node in order to mitigate the overhead on the network). - ... Maybe we can leverage either the edge sessions organised by the foundation and the FEMDC IRC meetings to dig a bit more of this architecture and to better understand what does it mean also for Nova and Neutron (the discussion focused on keystone and glance yesterday). This can lead to a possible reference architecture/blueprint with well-identified requirements for the different projects. We can setup an etherpad and try to prepare the different questions we may all have. Last but not the least, I really appreciated the discussion with Alan yesterday (thanks BTW ;)). It enabled us to highlight/discuss a few problems that ATT have to deal with. I'm wondering whether we cannot have such an exchange with some other folks. I know OVH for instance are operating several regions also. I think it would be valuable to understand how they deal with all the administrator challenges Alan pointed yesterday and whether they are also facing any other problems. Maybe the foundation can help us to organise such an exchange. Jonathan? My two cents, Adrien PS: thanks for starting the discussion! > > > > > Any opinions? > > > > Br, > > Gerg0 From lebre.adrien at free.fr Wed Feb 28 15:21:56 2018 From: lebre.adrien at free.fr (lebre.adrien at free.fr) Date: Wed, 28 Feb 2018 16:21:56 +0100 (CET) Subject: [Edge-computing] Afterlife of the PTG edge discussions In-Reply-To: <260398208.516642890.1519830435823.JavaMail.root@zimbra29-e5> Message-ID: <285560069.516693507.1519831316750.JavaMail.root@zimbra29-e5> > [..] > - What is the difference between such a new NKB and the tricircle > proposal (before splitting) [1] is also something I think it would be > valuable to better understand? [1] https://wiki.openstack.org/wiki/Tricircle_before_splitting > - I didn't attend the nova session unfortunately this morning but I > get the feeling that we can also learn a lot from the questions they > have been discussing for more than two years regarding the cell V2 > architecture (see for instance [2] line 37 the discussion regarding > glance for all cells vs one glance per cells vs....). [2] https://etherpad.openstack.org/p/nova-ptg-rocky > [...] sorry Ad_ri3n_