Revision as of 09:21, 8 June 2018

This page contains a summary of the Vancouver Forum discussions about the topic. Full notes of the discussion are in here. The features and requirements for edge cloud infrastructure are described in OpenStack_Edge_Discussions_Dublin_PTG.

Concerns to be addressed

Usability

• Some data may be modified locally and must persist when changed

Functionality

• There may be significant times with no connectivity and all functions (e.g. autoscaling) must continue to function

Security

• Some data should NOT be synchornized to some sites, if the site is compromised, it should only hold relevant local data
• Centralized "view" to synch status of edge clouds would be needed for audit / compliance
• Centralized Management (of some sort) required.

Scalability

• Edge sites may be very limited hardware (eg, may be single-node infrastructure)

Architecture options

Several keystone instances with federation with API synchronsation

Every edge cloud instance runs its own keystone instances. These keystone instances are federated where each keystone node is a "service provider" accepting and validating SAML assertions from a trusted identity provider (this is not the same as k2k federation). Each keystone maintains a mapping to control access depending on who needs what (this is going to be a lot of mappings, since there can be multiple for each deployment).
Basic flow:

1. A user presents a SAML assertion to prove their idenitty
2. The mapping processes their attributes, creates a shadow user, etc..
3. From there the user creates an application credential with their shadow user
4. A user generates tokens with their application credential to do things with that specific keystone deployment

Keystone database replication

Every edge cloud instance runs its own keystone instances. The database of these instances are syncronised and the data is syncronised between the edge cloud instances by the standard replication mechanism of the database.

Isolated Domains Per Edge and Localized Authority to Change data within isolated domain(s)

• "Spoke/Hub Model"-ish
• "Local DB for local "data" and pending writes
• Local data is send up to central hub once connectivity is restored
• Sites are authoritative for it's domain(s) no other "remote" domains are aurhoritative
• Central Hub is authoritative to write to any domain
• "Code/Service" written to handle bundling local changes and ship to central for distribution/synchonization down when/if connictivity is restored
  • This must be allowed to do things that normal Keystone-API work cannot do (create project in the database with a specific UUID)

Replicated data

This is the list of data what is syncronised by StarlingX

• Keystone
  • Users
  • Projects
  • Roles
  • Assignments
  • Groups (not yet implemented)
  • Domains (not yet implemented)
  • Fernet keys (not yet implemented)
• Nova
  • Flavors
  • Flavor extra specs
  • Keypairs
  • Quotas
• Neutron
  • Security Groups
  • Security Group Rules
• Cinder
  • Quotas