Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Date: Tue, 2 Oct 2012 10:33:08 +1100 (NCT)
From: "haroon abdelrahman (JIRA)" <jira@apache.org>
To: cloudstack-dev@incubator.apache.org
Message-ID: <1385144946.151793.1349134388638.JavaMail.jiratomcat@arcas>
Subject: [jira] [Created] (CLOUDSTACK-241) AWS Style Regions
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

haroon abdelrahman created CLOUDSTACK-241:
---------------------------------------------

             Summary: AWS Style Regions
                 Key: CLOUDSTACK-241
                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-241
             Project: CloudStack
          Issue Type: New Feature
            Reporter: haroon abdelrahman
            Assignee: haroon abdelrahman


Regions
1 Background

Currently, CloudStack only supports Amazon style Availability zones (AZ). T=
his feature is to allow the CloudStack infrastructure hierarchy to support =
Amazon style Regions. Regions provides the following benefits to customers:
=E2=80=A2 Higher availability of the services: users can deploy services ac=
ross AZs and even if one of the AZ goes down the services are still availab=
le to the end-user through VMs deployed in other zones.
=E2=80=A2Higher availability of the MS: Since MS only manages a single Regi=
on, if that MS goes down, only that particular Region is impacted. Admin sh=
ould be able to access all the other Regions.
=E2=80=A2Scalability: The scalability limit of CloudStack dramatically impr=
oves, as the scalability limit of MS is limited to a single Region.
=E2=80=A2Object Store: With Regions construct, CloudStack would also allow =
users to define Object Store (Secondary Storage) across AZs. This helps use=
rs easily deploy VMs in different AZs using the same template, offerings. =
=20

2Requirements
=E2=80=A2Admin should be able to install a management server for a Region a=
nd then connect to management servers in other Regions. Each Management Ser=
ver in each region should know about all other regions and their management=
 servers.
oConnect To Region
=E2=80=A2Admin should be able to create multiple Regions within a CloudStac=
k cloud. I.e., CloudStack should manage multiple regions within a cloud. Th=
e following operations should be supported:
oCreate Region
oDelete Region
oList Regions
=E2=80=A2Admin should be able to create multiple zones with a Region. Manag=
ement server cluster manages all the zones within the region. Following Zon=
e operations should be supported on per regions basis:
oCreate Zone
oDelete Zone
oList Zones
=E2=80=A2Management Server cluster for each region should only control the =
infrastructure within that region. In other words, if a management server c=
luster fails, then only the region managed by that server cluster should be=
 inaccessible for admin and users. It should not have any impact on the oth=
er Regions in the cloud
=E2=80=A2Each Region should have access to an object store. The object stor=
e should be common to all Zones within the Region. I.e., any object stored =
from a Zone should be visible across all the other zones within the region
=E2=80=A2EIP function should be available across both basic and advance Zon=
es within a Region
=E2=80=A2ELB function should be available across both basic and advance Zon=
es within a Region
=E2=80=A2The administrative hierarchy  (Users, Accounts, Domains, Projects)=
 - should be valid across all the regions. I.e., if admins create domains, =
accounts and users etc. in one region it should be reflected in other regio=
ns as well. =20
=E2=80=A2Authentication credentials =E2=80=93 username, password, keys =E2=
=80=93 should be valid across all regions
=E2=80=A2Switching between Regions should not require the user to sign-on a=
gain (SSO should be supported).
=E2=80=A2Resource management should be extended to Region level
oAvailable compute, storage, network (IPs, VLANs etc.) resources that are c=
urrently tracked should be aggregated and displayed at region level
oAppropriate global parameters should be available at Region level while th=
e remaining would be available at Zone level
=E2=80=A2Usage: All the (per account) usage records should be aggregated to=
 Regions level
=E2=80=A2Global Configurations: All of the administrative hierarchy (Domain=
s, Accounts, Users, Projects) related Global Configurations should have con=
sistent values across all regions and has to be propagated when a user modi=
fies a configuration on one of the regions.
=E2=80=A2Each region should maintain a list of all other regions and their =
region endpoints.

Note:
=E2=80=A2Users are required to deploy all the MSs of a particular region in=
 one zone
3UI / UX Requirements
=E2=80=A2User/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 Regio=
n to view details of that Region.=20
oReports on the dashboard should be aggregated to Region level
=E2=80=A2On first UI access, user should be able to connect to another Clou=
dstack instance or treat this instance as the first region
=E2=80=A2Modify the start-up wizard to force users define the Region (Regio=
n Name, Description, etc) before they start creating the Availability Zones
=E2=80=A2Users should be able to switch between various regions for UI usin=
g SSO.
4Upgrade Scenarios
Following upgrade scenarios should be supported:
=E2=80=A2Multiple Zones to Multiple Regions: Current deployments with multi=
ple Zones should be able to move to a deployment of multiple Regions. Admin=
s should be able to map one or more zones to a Region
=E2=80=A2All AZs in each Region should get access to all secondary storage =
from each region
=E2=80=A2Multiple Zones to Region: Current deployments with multiple Zones =
should be able to move to a deployment of single Region (this is a subset o=
f the above requirement)
oThis should be default upgrade behavior

5Non-Requirements
=E2=80=A2Management Server limited to per Zone is not a requirement for Cam=
po. This functionality could be added in a subsequent release
=E2=80=A2EIP and ELB functions across zones are only supported when both zo=
nes are either basic or advance. It is not required to support EIP or ELB a=
cross basic and advanced zones
=E2=80=A2It is not required to display a dashboard/reports that are aggrega=
ted across Regions

6Open Items:
=E2=80=A2How will the hierarchy change with the requirement of supporting b=
oth a Basic Zone and an Advanced Zone within a single Cloudstack instance?
=E2=80=A2Assuming we don=E2=80=99t need the capability / APIs to disconnect=
 Management server from one set and connect to another set of management se=
rvers


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira