Open Stack

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) <gergely.csatari at nokia.com>; 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)" <gergely.csatari at nokia.com<mailto:gergely.csatari at nokia.com>>
Date: Thursday, June 7, 2018 at 4:15 AM
To: Greg Waines <Greg.Waines at windriver.com<mailto:Greg.Waines at windriver.com>>, "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] 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<mailto: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: <http://lists.openstack.org/pipermail/edge-computing/attachments/20180608/b9ffbb0c/attachment-0001.html>