[Edge-computing] Afterlife of the PTG edge discussions
free
lebre.adrien at free.fr
Tue Apr 10 17:45:23 UTC 2018
Hi Gerg0,, Hi All,
First of all thanks Gerg0 for your work, it is great to see a consolidation of the different discussions.
I have a couple of questions (in particular regarding a couple of acronyms) and I think it would be great to discuss in details some points such as the different levels (as discussed some discussions from the FEMDC SiG led us to consider only 5 levels now, I’m not sure we are right but debating on that can be useful).
Could we arrange a dedicated meeting to go through this wiki page? (can be an irc exchange, a webconf….)?
How could we progress? Should we go through a blueprint like process?
Thanks
ad_rien_
BTW, the FEMDC SiG is tomorrow at 15:00 UTC.
> On 10 Apr 2018, at 16:39, Csatari, Gergely (Nokia - HU/Budapest) <gergely.csatari at nokia.com> wrote:
>
> Hi,
>
> I’ve added the requirements and updated the page based ont he coments:https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG <https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG>
>
> Some questions:
> I’ve added some MVS / Non-MVS classification to the features. Please check and comment them (is there a way to comment this wiki somehow?)
> In the „Operability data aggregation data provider part” section I could not figure out what data we would like to aggregate. Can you please help in this?
> In the „Remote control controlling part” section I could not figure out what operation we would like to issue. Can you please help in this?
> I described the synchronisation of the keystone data as it is done by a new service and not by a partitioned keystone. Should I update the descriptions according to what is described in https://etherpad.openstack.org/p/edge-alans-problems <https://etherpad.openstack.org/p/edge-alans-problems> , line 94?
>
> Any comments to any other things on the wiki are welcome.
>
> Thanks,
> Gerg0
> <>
> From: free [mailto:lebre.adrien at free.fr <mailto:lebre.adrien at free.fr>]
> Sent: Friday, March 30, 2018 9:33 AM
> To: edge-computing at lists.openstack.org <mailto:edge-computing at lists.openstack.org>
> Subject: Re: [Edge-computing] Afterlife of the PTG edge discussions
>
> Hi
>
> See my comments in line.
>
> On 29 Mar 2018, at 19:25, Csatari, Gergely (Nokia - HU/Budapest) <gergely.csatari at nokia.com <mailto:gergely.csatari at nokia.com>> wrote:
>
> Hi,
>
> Thanks for the comments. Going inline with the reactions.
>
>
> From: Waines, Greg [mailto:Greg.Waines at windriver.com <mailto:Greg.Waines at windriver.com>]
> Sent: Wednesday, March 28, 2018 12:01 PM
>
> Some initial comments:
>
> Features and requirements
> Initially talks about “... feature/requirement discussions on two levels ...”
> top->down feature oriented discussion and
> bottom->up missing requirements of existing mechanisms discussion,
> However I only see notes on the ‘top->down feature oriented discussion.
> [G0]: Yes, the requirements are still to be added.
>
> FYI, we had a couple of exchange between folks working in the FEMDC SiG. For the moment, we reduced the number of levels to 5.
> Level 1: operations (admins/devops) that include on single site (local/remote)
> Level 2: operations (admins/devops) that include several sites (collaborations between sites)
> + For Level 2, there are several use-cases, such as bootiing a VM on site A considering a VMI from site B, booting two VMs on distinct sites and interconnecting them, make a provisioning request on site A but site B should satisfy the request because there is no available resources on site A, …
> + Please consider that all operations that can be satisfied by contacting a site directly without requiring modifications or extensions within the codebase are then considered as Level 1 operations.
> Level 3: Level 2 operations but operations should consider intermittent networks (such as split brain situations)
> Level 4: Level 3 operations but across several versions of OpenStack (L4.1) and accros distinct software stack (L4.2). L4.2 may include Kubernetes…
> Level 5: Level 3 but between distinct operators.
>
> We are currently writing a small report and should be able to deliver soon.
> In addition to simplifying the first classification, the goal is to also try to identify what are the top priorities, in particular in Level 2.
>
>
>
> Features
> Base assumptions for the features
> Why do we have the statement that “edge site is composed of at least 5 servers” ?
> Edge sites should be scalable from a single all-in-one server to at least 10s of servers (maybe more)
> [G0]: This statement is from line 5 of https://etherpad.openstack.org/p/edge-gap-analysis <https://etherpad.openstack.org/p/edge-gap-analysis> I tend to agree with you on the lower number, like an edge site can be a single machine. This is one thing what I’ve learned from Beth yesterday.
> I correct it to one. If there are objections from other we can discuss 😊
>
>
>
> Would it be preferable to clarify what do we mean by one server.
> - we can consider one server as a compute/storage node (i.e. the control services are deployed higher in the hierarchy)
> - we can consider one server that host an all-in-one OpenStack but we should probably then discussed what are the mandatory mechanisms we would like to have in this all-in-one server.
>
>
> Maybe we can organize a short telco (or irc-meeting) to go through the current wiki page.
>
> My two cents,
> Adrien
>
> Feature Levels
> Maybe just me ... but I am not familiar with the use of the term ‘requirement levels’ for increasing complexity of requirements
> I think this also caused some confusion at the Dublin PTG meetings
> I would suggest
> A prioritized list of requirements,
> Where the top N requirements on that list would represent the definition of the MANDATORY / Minimum-Viable-Solution(MVS) set of requirements.
> [G0]: Okay I will reorganize the list based on this. I will look for your comments once I’m ready.
>
> General comments on Level 1 thru Level 7
> Generally I think there is too much focus on the “operational” requirements
> E.g. creating VMs, creating network, migrating VMs, etc.
> I think the high-priority/MVS requirements should be more focused on the “administrative” requirements
> E.g. managing various admin type configurations across all the edge clouds,
> like users, projects, images, flavors, security groups, quotas, etc.
> I think this administrative work alone, would be a good significant first step.
>
> [G0]: I think both of them are important and we should focus on both of them.
> Features are describing the high level target while the requirements will describe the concrete issues (like managing of the admin config). I agree however, that solving the synchronization of administrative data would be an impressive achiecement.
>
> Br,
> Gerg0
>
> Greg.
>
>
> From: "Csatari, Gergely (Nokia - HU/Budapest)" <gergely.csatari at nokia.com <mailto:gergely.csatari at nokia.com>>
> Date: Sunday, March 25, 2018 at 9:05 AM
> To: Jonathan Bryce <jonathan at openstack.org <mailto:jonathan at openstack.org>>, "edge-computing at lists.openstack.org <mailto:edge-computing at lists.openstack.org>" <edge-computing at lists.openstack.org <mailto:edge-computing at lists.openstack.org>>
> Subject: Re: [Edge-computing] Afterlife of the PTG edge discussions
>
> Hi,
>
> As I promised I started to put the conclusions of the Dublin discussions into t wiki page:https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG <https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG>
> I'm far from being ready, but in case of any comments please do not hesitate to adit the pages or indicate your comment to me.
>
> The main aim of this excercise is to collect the results of our discussions in a space what is less volatile and a bit more organized than an increasing number of etherpads.
>
> Br,
> Gerg0
>
> -----Original Message-----
> From: Jonathan Bryce [mailto:jonathan at openstack.org <mailto:jonathan at openstack.org>]
> Sent: Monday, March 19, 2018 7:20 PM
> To: edge-computing at lists.openstack.org <mailto:edge-computing at lists.openstack.org>
> Subject: Re: [Edge-computing] Afterlife of the PTG edge discussions
>
> Hi everyone,
>
> As a reminder we have a call schedule for tomorrow at 0700PDT/0900CDT/1400UTC. I would like to get into a discussion on how to begin implementing a POC for the new sync service project we started discussing in Dublin.
>
> I tried to consolidate the notes that had happened in various places starting on line 91 of https://etherpad.openstack.org/p/edge-alans-problems <https://etherpad.openstack.org/p/edge-alans-problems>
>
> If you are interested in helping to kick off development of this project, please join us tomorrow morning: Meeting Link:https://zoom.us/j/777719876 <https://zoom.us/j/777719876>
>
> Thanks,
>
> Jonathan
>
>
>
> On Mar 2, 2018, at 6:59 AM, Christopher Price <christopher.price at est.tech <mailto:christopher.price at est.tech>> wrote:
> lol, I like it. If we go with that name I'm using "rex" as an
> abbreviation. ;)
> From: Waines, Greg <Greg.Waines at windriver.com <mailto:Greg.Waines at windriver.com>>
> Sent: Friday, March 2, 2018 11:50:06 AM
> To: Csatari, Gergely (Nokia - HU/Budapest); lebre.adrien at free.fr <mailto:lebre.adrien at free.fr>;
> edge-computing at lists.openstack.org <mailto:edge-computing at lists.openstack.org>
> Subject: Re: [Edge-computing] Afterlife of the PTG edge discussions
>
> Yeah was some interesting discussions.
>
> I thought we made the most progress on Tuesday Morning where we worked
> thru “Alan’s Problems”, and were able to put down some clear requirements and even some stakes in the ground wrt the beginnings of a strawman architecture.
>
> My notes and view of those initial requirements and initial strawman architecture that we discussed are below:
> ( ... feel free to throw harpoons at my interpretation ...)
>
> First I’d like to suggest that we do the initial work on this New King Bird with the “goal” of NOT changing ANY existing service (like keystone, or glance, or ...). I think it would allow us to move forward more quickly ... and is not that restrictive wrt being able to meet the requirements below.
>
> • multi-region solution
> • i.e. central region and many edge regions
> • where region == geographically edge site
> • For larger solutions, this would extend to multiple levels,
> e.g. central region à edge region à further-out-edge regions (sites) ...
> • scaling up to 1,000s of regions/sites eventually
> • edge region/site can be any size, from small 1-node system to 100s-of-nodes system
> • a new service runs on central region for
> configuring/synchronizing/queryingSyncStatusOf system-wide data across all edge regions
> • referred to in meeting as the "New King Bird" (NKB),
> • supports REST API for configuring/queryingSyncStatusOf of system wide data across all regions
> • where system-wide data includes:
> • users, tenants, VM images (glance) … as discussed in meeting
> • … and, we never discussed but I would also throw in
> • nova flavors (& extra specs), nova key pairs, neutron security groups, and
> • nova and neutron quotas (although that is more complex than
> simple synchronization if you want quota management across the system/multiple-edge-regions)
> • will be able to specify sync-policy of 'to ALL edge regions' or
> 'to specific subset of edge regions', for each item of system-wide data,
> • synchronization process will retry continuously on failure,
> • synchronization process will automatically synch data with any newly created/joined edge region,
> • user will be able to query sync state of system-wide data on all/individual edge regions,
> • ABC Service in the central region will hold the system-wide ABC data to be synchronized
> • e.g. keystone, glance, nova, neutron, …
> • New King Bird Service will hold the meta data wrt sync-policy and sync-state for system-wide data
> • For a large multi-level region hierarchy, the New King Bird service
> would also run on selected edge clouds that would then sync data to further-out-edge regions/sites.
>
> And finally, I have to throw out the first new name suggestion for the
> ‘new king bird’ project, how about Tyrannus ( i.e. a genus of large insect-eating birds, commonly known as kingbirds)?
>
> let me know what you think,
> Greg.
>
>
>
> From: "Csatari, Gergely (Nokia - HU/Budapest)"
> <gergely.csatari at nokia.com <mailto:gergely.csatari at nokia.com>>
> Date: Wednesday, February 28, 2018 at 1:58 PM
> To: "lebre.adrien at free.fr <mailto:lebre.adrien at free.fr>" <lebre.adrien at free.fr <mailto:lebre.adrien at free.fr>>,
> "edge-computing at lists.openstack.org <mailto:edge-computing at lists.openstack.org>"
> <edge-computing at lists.openstack.org <mailto:edge-computing at lists.openstack.org>>
> Subject: [Edge-computing] Afterlife of the PTG edge discussions
>
> 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 <https://etherpad.openstack.org/p/edge-ptg-dublin>
> - Gap analyzis: https://etherpad.openstack.org/p/edge-gap-analysis <https://etherpad.openstack.org/p/edge-gap-analysis>
> - Alans problems: https://etherpad.openstack.org/p/edge-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
> _______________________________________________
> Edge-computing mailing list
> Edge-computing at lists.openstack.org <mailto:Edge-computing at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing <http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing>
>
>
> _______________________________________________
> Edge-computing mailing list
> Edge-computing at lists.openstack.org <mailto:Edge-computing at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing <http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing>
> _______________________________________________
> Edge-computing mailing list
> Edge-computing at lists.openstack.org <mailto:Edge-computing at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing <http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing>
>
> _______________________________________________
> Edge-computing mailing list
> Edge-computing at lists.openstack.org <mailto:Edge-computing at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing <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/20180410/a61a924a/attachment-0001.html>
More information about the Edge-computing
mailing list