[Edge-computing] Afterlife of the PTG edge discussions

Csatari, Gergely (Nokia - HU/Budapest) gergely.csatari at nokia.com
Thu Apr 12 13:38:38 UTC 2018 

Hi,

Uh-oh, sharing the Doodle link in the correct thread also: https://doodle.com/poll/azac9a3bxchawy83

On the blueprint like process: I think it is a good idea as the wiki we use is not able to handle inline comments, but for this we would need a repository first šŸ˜Š

Br,
Gerg0

From: free [mailto:lebre.adrien at free.fr]
Sent: Wednesday, April 11, 2018 2:35 PM
To: Csatari, Gergely (Nokia - HU/Budapest) <gergely.csatari at nokia.com>
Cc: edge-computing at lists.openstack.org
Subject: Re: [Edge-computing] Afterlife of the PTG edge discussions


On 11 Apr 2018, at 11:31, Csatari, Gergely (Nokia - HU/Budapest) <gergely.csatari at nokia.com<mailto:gergely.csatari at nokia.com>> wrote:

Hi,

Iā€™m open to discuss any comment sor questions in mail or over #edge-computing-group. We can even set up an hour meeting for this on #edge-computing-group.


Yes, should we propose  a few slots and see which is the best one?


#levels: One of the comments I received was not to use these different levels. I agree, that however there is a dependency between the levels, but still they are jus different feature groups.

On blueprint like process you mean to convert the text to rst, add it to a repo and do Gerrit review?


yes

ad_ri3n_

Br,
Gerg0


From: free [mailto:lebre.adrien at free.fr]
Sent: Tuesday, April 10, 2018 7:47 PM
To: Csatari, Gergely (Nokia - HU/Budapest) <gergely.csatari at nokia.com<mailto:gergely.csatari at nokia.com>>
Cc: edge-computing at lists.openstack.org<mailto:edge-computing at lists.openstack.org>
Subject: Re: [Edge-computing] Afterlife of the PTG edge discussions

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 acronyms) and I think it would be great  to discuss in details some points such as the different levels (as mentioned recent discussions in the FEMDC SiG led us to consider only 5 levels now, Iā€™m not sure we are going in the  right direction but debating on that point 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<mailto: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

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 , line 94?

Any comments to any other things on the wiki are welcome.

Thanks,
Gerg0

From: free [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]
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 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
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]
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

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

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
-          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
_______________________________________________
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


_______________________________________________
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
_______________________________________________
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

_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/edge-computing/attachments/20180412/94719bdd/attachment-0001.html>

More information about the Edge-computing mailing list