Responses in-lined below, Greg.
From: "Csatari, Gergely (Nokia - HU/Budapest)" gergely.csatari@nokia.com Date: Friday, June 8, 2018 at 5:23 AM To: Greg Waines Greg.Waines@windriver.com, "edge-computing@lists.openstack.org" edge-computing@lists.openstack.org Subject: RE: [Edge-computing] Keystone Edge Architectures
Hi,
Thanks for the answer.
According to my understanding this is what we tried to describe in the first option. [Greg] Ok ... maybe this is me not understanding what ‘federated’ keystone is. My understanding of federated keystone ( please correct me if I am wrong ):
· All clouds run a Keystone Instance (service provider)
· But all Keystone Instances leverage the same remote IdentityProvider as the backend for User Authentication
o i.e. there is a single remote IdentityProvider with all the user credentials
· The Keystone Instances in each cloud must have the MAPPINGs between IdentityProvider user & SAML Assertions - to – Keystone Project/User/Token/etc.
So is the “API Synchronization” that you mention in this first option, referring to the synchronization of these MAPPINGs ?
We are NOT using keystone federation in StarlingX.
Maybe what we are doing in StarlingX is a fourth option. Similar to Option 2 – “Keystone database replication” .... but using an “API-based synchronization” and Fernet Key Synchronization to enable use of Tokens across all clouds.
e.g.
Option 4 – Keystone API Synchronization & Fernet Key Synchronization
· Every Edge Cloud instance runs its own keystone instance,
· Keystone resources are replicated from central site to edge clouds using API-based Synchronization,
o i.e. projects, users, groups, domains, ...
· 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.
I’ve also added the list of synched data to the wiki: https://wiki.openstack.org/wiki/Keystone_edge_architectures#Replicated_data [Greg] And you probably want to put an asterisk (*) by the Quotas items, as similar to Kingbird, we dynamically manage quotas across the Edge Clouds in order to provide Quotas at the Distributed Cloud Level. I.e. a project that has a quota of 10 instances, can only create 10 instances across ALL Edge Clouds; NOT 10 instances per Edge Cloud.
Is the replication service part of the open sourced StarlingX? [Greg] Yes.
Thanks, Gerg0
From: Waines, Greg [mailto:Greg.Waines@windriver.com] Sent: Thursday, June 7, 2018 1:37 PM To: Csatari, Gergely (Nokia - HU/Budapest) gergely.csatari@nokia.com; edge-computing@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@nokia.commailto:gergely.csatari@nokia.com> Date: Thursday, June 7, 2018 at 4:15 AM To: Greg Waines <Greg.Waines@windriver.commailto:Greg.Waines@windriver.com>, "edge-computing@lists.openstack.orgmailto:edge-computing@lists.openstack.org" <edge-computing@lists.openstack.orgmailto:edge-computing@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@windriver.com] Sent: Wednesday, June 6, 2018 3:44 PM To: edge-computing@lists.openstack.orgmailto:edge-computing@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-da... )
* 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.