[Edge-computing] Keystone Edge Architectures
Waines, Greg
Greg.Waines at windriver.com
Thu Jun 7 11:37:02 UTC 2018
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)" <gergely.csatari at nokia.com>
Date: Thursday, June 7, 2018 at 4:15 AM
To: Greg Waines <Greg.Waines at windriver.com>, "edge-computing at lists.openstack.org" <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: <http://lists.openstack.org/pipermail/edge-computing/attachments/20180607/a50795d9/attachment-0001.html>
More information about the Edge-computing
mailing list