Page History

...

 User Accounts will be available across Regions. User should be able to use the same account in all Regions. Switching between Regions should not require the user to sign-on again (SSO should be supported).

Templates

 CS Templates are currently zone specific. Templates should be available to all zones within a region. User should be able to migrate templates from one Region to another. This requires S3 like object store

...

 An authentication service will available for components like object-store to authenticate and get account information using getUser API

Custom Authentication Adapter

Existing UserAuthenticator will be enhanced to support provisioning from directory services like LDAP and Active Directory.

Account can also be auto-provisioned using the directory service

Assumptions

Object Store: This feature assumes that S3 like object store is available. Either implemented in CloudStack or through integrations

Templates, Snapshots, EIP and ELP work is not part of this spec. There are being tracked separately as per JIRA tickets mentioned above.

Any failure to sync API calls will be logged in region_sync table. It is the responsibility if the cloud operator to propagate these changes offline.

Usage

Usage records will be generated by each Region separately. Portal layer above CS should combine usage across Regions into a consolidated invoice.

...

1. Create Account

   Create Account A1 in Region1 (Region Id 1). Propagate account creation to all the remaining Regions. Account creation will fail if account is not created in all the RegionsAn entry will be added to region_sync table if account creation API fails in any region.  Source Region Id for A1 will be 1. External Id(UUID) for the Account should be same in all Regions.  External Ids could be UUID or  username + domainpath or any string which is unique across Regions.  This external ID has to be provided during Account creation. Account DB Ids could be different for each Region. 

2. Update Account (update/disable/enable Account)

   Account update actions are forwarded to the source Region. After source Region is successfully updated, account update is propagated to the remaining Regions. Account update fails if the source Region cannot be updated or is  unavailableunavailable. 

3. Delete Account

   Delete Account is forwarded to the source Region. After account is successfully  deleted in the source Region, delete is propagated to the other Regions. Account delete fails if the delete in source Region fails  or or is  unavailableunavailable. 
4. Login to Region A and move to Region B without providing credentialsSimilarly for users and domains.

Architecture and Design description

...

Each Region will have a separate database. Below data will be common to all databases across Regions:

1. Account
2. User
3. DomainRegion related meta data

Remaining data is expected to be per-Region and not shared across databases in other Regions. 

...

Changes to existing tables

...

• When creating the account, it is created first in the Region that the user is logged into
• Account table will include region_id column, indicating the Region that it is created from
• This Region is responsible for propagation of Account creation to other Regions
• Account deletion/modification is always forwarded to the Region that originally created the account 
• The Region that originally created account is responsible for deleting the account from all of the regions before it declares the account is deleted. If it cannot reach an Region, account deletion failsan entry is created in the region_sync table with api details.

The same applies for Domains and Users.

Create: For any resource created in Region A, MS is Region A  will send API requests to peer Regions along with external Id of the resource. API requests are sent to the peer Regions using the end_point of each Region

...

Once logged in User should be able to switch from one Region to another without providing credentials again (Single sign-on?)

Secondary Storage

Snapshots and Templates are currently stored on secondary storage. After snapshots/templates are moved to object store, role of secondary storage will change. There were proposals also to move secondary storage to pod-level.

web services APIs

New APIs

...

1. userapikey: Get user details by API key 

Changes to existing APIs

• createAccount  createAccount 
  1. New parameters
     1. accountid : External Id for the Account. Could be UUID or domainpath + username or any string unique across RegionsUUID of the account
     2. userid:  External Id UUID for the User. 
     3. regionid: Id of the source Region where Account creation request was initiated
• deleteAccount, updateAccount, disableAccount, enableAccount
  1. New parameter
     1. ispropagate: Boolean flag which indicated if the API call is being propagated from another Region
• createUser
  1. userid: UUID for the User. 
  2. regionid: Id of the source Region where User creation request was initiated
• deleteUser/updateUser/disableUser/enableUser/lockUser
  1. ispropagate: Boolean flag which indicated if the API call is being propagated from another Region
• createDomain
  • New parameters
    • domainid: UUID for the Domain
    • regionid: Id of the source Region where Domain creation request was initiated

• deleteDomain/updateDomain
  • ispropagate: Boolean flag which indicated if the API call is being propagated from another Region

Limitations

1. Since all update/delete operations are forwarded to the source region (i.e the region where the resource was initially created), if the source region is down, these operations will fail

...

• User/Admin should be able to view all Regions by logging into a MS of any of the Regions. User then should be able to select a specific Region to view details of that Region.
  • Reports on the dashboard should be aggregated to Region level
• On first UI access (after MS installation), user should be able to connect to another CloudStack MS (in another Region) or treat this instance as the first region
• Modify the start-up wizard to force users define the Region (Region Name, Description, etc) before they start creating the Availability Zones
• Users should be able to switch between various regions for UI using Single Sign-On.

...