Open Stack

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

o    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.

o    Every Edge Cloud instance runs its own keystone instance,

o    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 )

o    AND

o    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/20180606/b2d0a5c1/attachment.html>