You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by "haroon abdelrahman (JIRA)" <ji...@apache.org> on 2012/10/02 01:33:08 UTC
[jira] [Created] (CLOUDSTACK-241) AWS Style Regions
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). This feature is to allow the CloudStack infrastructure hierarchy to support Amazon style Regions. Regions provides the following benefits to customers:
• Higher availability of the services: users can deploy services across AZs and even if one of the AZ goes down the services are still available to the end-user through VMs deployed in other zones.
•Higher availability of the MS: Since MS only manages a single Region, if that MS goes down, only that particular Region is impacted. Admin should be able to access all the other Regions.
•Scalability: The scalability limit of CloudStack dramatically improves, as the scalability limit of MS is limited to a single Region.
•Object Store: With Regions construct, CloudStack would also allow users to define Object Store (Secondary Storage) across AZs. This helps users easily deploy VMs in different AZs using the same template, offerings.
2Requirements
•Admin should be able to install a management server for a Region and then connect to management servers in other Regions. Each Management Server in each region should know about all other regions and their management servers.
oConnect To Region
•Admin should be able to create multiple Regions within a CloudStack cloud. I.e., CloudStack should manage multiple regions within a cloud. The following operations should be supported:
oCreate Region
oDelete Region
oList Regions
•Admin should be able to create multiple zones with a Region. Management server cluster manages all the zones within the region. Following Zone operations should be supported on per regions basis:
oCreate Zone
oDelete Zone
oList Zones
•Management Server cluster for each region should only control the infrastructure within that region. In other words, if a management server cluster 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 other Regions in the cloud
•Each Region should have access to an object store. The object store 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
•EIP function should be available across both basic and advance Zones within a Region
•ELB function should be available across both basic and advance Zones within a Region
•The 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 regions as well.
•Authentication credentials – username, password, keys – should be valid across all regions
•Switching between Regions should not require the user to sign-on again (SSO should be supported).
•Resource management should be extended to Region level
oAvailable compute, storage, network (IPs, VLANs etc.) resources that are currently tracked should be aggregated and displayed at region level
oAppropriate global parameters should be available at Region level while the remaining would be available at Zone level
•Usage: All the (per account) usage records should be aggregated to Regions level
•Global Configurations: All of the administrative hierarchy (Domains, Accounts, Users, Projects) related Global Configurations should have consistent values across all regions and has to be propagated when a user modifies a configuration on one of the regions.
•Each region should maintain a list of all other regions and their region endpoints.
Note:
•Users are required to deploy all the MSs of a particular region in one zone
3UI / UX Requirements
•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.
oReports on the dashboard should be aggregated to Region level
•On first UI access, user should be able to connect to another Cloudstack instance 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 SSO.
4Upgrade Scenarios
Following upgrade scenarios should be supported:
•Multiple Zones to Multiple Regions: Current deployments with multiple Zones should be able to move to a deployment of multiple Regions. Admins should be able to map one or more zones to a Region
•All AZs in each Region should get access to all secondary storage from each region
•Multiple Zones to Region: Current deployments with multiple Zones should be able to move to a deployment of single Region (this is a subset of the above requirement)
oThis should be default upgrade behavior
5Non-Requirements
•Management Server limited to per Zone is not a requirement for Campo. This functionality could be added in a subsequent release
•EIP and ELB functions across zones are only supported when both zones are either basic or advance. It is not required to support EIP or ELB across basic and advanced zones
•It is not required to display a dashboard/reports that are aggregated across Regions
6Open Items:
•How will the hierarchy change with the requirement of supporting both a Basic Zone and an Advanced Zone within a single Cloudstack instance?
•Assuming we don’t need the capability / APIs to disconnect Management server from one set and connect to another set of management servers
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-241) AWS Style Regions
Posted by "Sudha Ponnaganti (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sudha Ponnaganti updated CLOUDSTACK-241:
----------------------------------------
Fix Version/s: 4.1.0
> AWS Style Regions
> -----------------
>
> Key: CLOUDSTACK-241
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-241
> Project: CloudStack
> Issue Type: New Feature
> Affects Versions: 4.1.0
> Reporter: haroon abdelrahman
> Assignee: Kishan Kavala
> Fix For: 4.1.0
>
>
> Regions
> 1 Background
> Currently, CloudStack only supports Amazon style Availability zones (AZ). This feature is to allow the CloudStack infrastructure hierarchy to support Amazon style Regions. Regions provides the following benefits to customers:
> • Higher availability of the services: users can deploy services across AZs and even if one of the AZ goes down the services are still available to the end-user through VMs deployed in other zones.
> •Higher availability of the MS: Since MS only manages a single Region, if that MS goes down, only that particular Region is impacted. Admin should be able to access all the other Regions.
> •Scalability: The scalability limit of CloudStack dramatically improves, as the scalability limit of MS is limited to a single Region.
> •Object Store: With Regions construct, CloudStack would also allow users to define Object Store (Secondary Storage) across AZs. This helps users easily deploy VMs in different AZs using the same template, offerings.
> 2Requirements
> •Admin should be able to install a management server for a Region and then connect to management servers in other Regions. Each Management Server in each region should know about all other regions and their management servers.
> oConnect To Region
> •Admin should be able to create multiple Regions within a CloudStack cloud. I.e., CloudStack should manage multiple regions within a cloud. The following operations should be supported:
> oCreate Region
> oDelete Region
> oList Regions
> •Admin should be able to create multiple zones with a Region. Management server cluster manages all the zones within the region. Following Zone operations should be supported on per regions basis:
> oCreate Zone
> oDelete Zone
> oList Zones
> •Management Server cluster for each region should only control the infrastructure within that region. In other words, if a management server cluster 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 other Regions in the cloud
> •Each Region should have access to an object store. The object store 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
> •EIP function should be available across both basic and advance Zones within a Region
> •ELB function should be available across both basic and advance Zones within a Region
> •The 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 regions as well.
> •Authentication credentials – username, password, keys – should be valid across all regions
> •Switching between Regions should not require the user to sign-on again (SSO should be supported).
> •Resource management should be extended to Region level
> oAvailable compute, storage, network (IPs, VLANs etc.) resources that are currently tracked should be aggregated and displayed at region level
> oAppropriate global parameters should be available at Region level while the remaining would be available at Zone level
> •Usage: All the (per account) usage records should be aggregated to Regions level
> •Global Configurations: All of the administrative hierarchy (Domains, Accounts, Users, Projects) related Global Configurations should have consistent values across all regions and has to be propagated when a user modifies a configuration on one of the regions.
> •Each region should maintain a list of all other regions and their region endpoints.
> Note:
> •Users are required to deploy all the MSs of a particular region in one zone
> 3UI / UX Requirements
> •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.
> oReports on the dashboard should be aggregated to Region level
> •On first UI access, user should be able to connect to another Cloudstack instance 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 SSO.
> 4Upgrade Scenarios
> Following upgrade scenarios should be supported:
> •Multiple Zones to Multiple Regions: Current deployments with multiple Zones should be able to move to a deployment of multiple Regions. Admins should be able to map one or more zones to a Region
> •All AZs in each Region should get access to all secondary storage from each region
> •Multiple Zones to Region: Current deployments with multiple Zones should be able to move to a deployment of single Region (this is a subset of the above requirement)
> oThis should be default upgrade behavior
> 5Non-Requirements
> •Management Server limited to per Zone is not a requirement for Campo. This functionality could be added in a subsequent release
> •EIP and ELB functions across zones are only supported when both zones are either basic or advance. It is not required to support EIP or ELB across basic and advanced zones
> •It is not required to display a dashboard/reports that are aggregated across Regions
> 6Open Items:
> •How will the hierarchy change with the requirement of supporting both a Basic Zone and an Advanced Zone within a single Cloudstack instance?
> •Assuming we don’t need the capability / APIs to disconnect Management server from one set and connect to another set of management servers
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-241) AWS Style Regions
Posted by "haroon abdelrahman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
haroon abdelrahman reassigned CLOUDSTACK-241:
---------------------------------------------
Assignee: Kishan Kavala (was: haroon abdelrahman)
> AWS Style Regions
> -----------------
>
> Key: CLOUDSTACK-241
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-241
> Project: CloudStack
> Issue Type: New Feature
> Affects Versions: 4.1.0
> Reporter: haroon abdelrahman
> Assignee: Kishan Kavala
>
> Regions
> 1 Background
> Currently, CloudStack only supports Amazon style Availability zones (AZ). This feature is to allow the CloudStack infrastructure hierarchy to support Amazon style Regions. Regions provides the following benefits to customers:
> • Higher availability of the services: users can deploy services across AZs and even if one of the AZ goes down the services are still available to the end-user through VMs deployed in other zones.
> •Higher availability of the MS: Since MS only manages a single Region, if that MS goes down, only that particular Region is impacted. Admin should be able to access all the other Regions.
> •Scalability: The scalability limit of CloudStack dramatically improves, as the scalability limit of MS is limited to a single Region.
> •Object Store: With Regions construct, CloudStack would also allow users to define Object Store (Secondary Storage) across AZs. This helps users easily deploy VMs in different AZs using the same template, offerings.
> 2Requirements
> •Admin should be able to install a management server for a Region and then connect to management servers in other Regions. Each Management Server in each region should know about all other regions and their management servers.
> oConnect To Region
> •Admin should be able to create multiple Regions within a CloudStack cloud. I.e., CloudStack should manage multiple regions within a cloud. The following operations should be supported:
> oCreate Region
> oDelete Region
> oList Regions
> •Admin should be able to create multiple zones with a Region. Management server cluster manages all the zones within the region. Following Zone operations should be supported on per regions basis:
> oCreate Zone
> oDelete Zone
> oList Zones
> •Management Server cluster for each region should only control the infrastructure within that region. In other words, if a management server cluster 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 other Regions in the cloud
> •Each Region should have access to an object store. The object store 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
> •EIP function should be available across both basic and advance Zones within a Region
> •ELB function should be available across both basic and advance Zones within a Region
> •The 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 regions as well.
> •Authentication credentials – username, password, keys – should be valid across all regions
> •Switching between Regions should not require the user to sign-on again (SSO should be supported).
> •Resource management should be extended to Region level
> oAvailable compute, storage, network (IPs, VLANs etc.) resources that are currently tracked should be aggregated and displayed at region level
> oAppropriate global parameters should be available at Region level while the remaining would be available at Zone level
> •Usage: All the (per account) usage records should be aggregated to Regions level
> •Global Configurations: All of the administrative hierarchy (Domains, Accounts, Users, Projects) related Global Configurations should have consistent values across all regions and has to be propagated when a user modifies a configuration on one of the regions.
> •Each region should maintain a list of all other regions and their region endpoints.
> Note:
> •Users are required to deploy all the MSs of a particular region in one zone
> 3UI / UX Requirements
> •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.
> oReports on the dashboard should be aggregated to Region level
> •On first UI access, user should be able to connect to another Cloudstack instance 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 SSO.
> 4Upgrade Scenarios
> Following upgrade scenarios should be supported:
> •Multiple Zones to Multiple Regions: Current deployments with multiple Zones should be able to move to a deployment of multiple Regions. Admins should be able to map one or more zones to a Region
> •All AZs in each Region should get access to all secondary storage from each region
> •Multiple Zones to Region: Current deployments with multiple Zones should be able to move to a deployment of single Region (this is a subset of the above requirement)
> oThis should be default upgrade behavior
> 5Non-Requirements
> •Management Server limited to per Zone is not a requirement for Campo. This functionality could be added in a subsequent release
> •EIP and ELB functions across zones are only supported when both zones are either basic or advance. It is not required to support EIP or ELB across basic and advanced zones
> •It is not required to display a dashboard/reports that are aggregated across Regions
> 6Open Items:
> •How will the hierarchy change with the requirement of supporting both a Basic Zone and an Advanced Zone within a single Cloudstack instance?
> •Assuming we don’t need the capability / APIs to disconnect Management server from one set and connect to another set of management servers
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-241) AWS Style Regions
Posted by "haroon abdelrahman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
haroon abdelrahman updated CLOUDSTACK-241:
------------------------------------------
Affects Version/s: 4.1.0
> AWS Style Regions
> -----------------
>
> Key: CLOUDSTACK-241
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-241
> Project: CloudStack
> Issue Type: New Feature
> Affects Versions: 4.1.0
> Reporter: haroon abdelrahman
> Assignee: haroon abdelrahman
>
> Regions
> 1 Background
> Currently, CloudStack only supports Amazon style Availability zones (AZ). This feature is to allow the CloudStack infrastructure hierarchy to support Amazon style Regions. Regions provides the following benefits to customers:
> • Higher availability of the services: users can deploy services across AZs and even if one of the AZ goes down the services are still available to the end-user through VMs deployed in other zones.
> •Higher availability of the MS: Since MS only manages a single Region, if that MS goes down, only that particular Region is impacted. Admin should be able to access all the other Regions.
> •Scalability: The scalability limit of CloudStack dramatically improves, as the scalability limit of MS is limited to a single Region.
> •Object Store: With Regions construct, CloudStack would also allow users to define Object Store (Secondary Storage) across AZs. This helps users easily deploy VMs in different AZs using the same template, offerings.
> 2Requirements
> •Admin should be able to install a management server for a Region and then connect to management servers in other Regions. Each Management Server in each region should know about all other regions and their management servers.
> oConnect To Region
> •Admin should be able to create multiple Regions within a CloudStack cloud. I.e., CloudStack should manage multiple regions within a cloud. The following operations should be supported:
> oCreate Region
> oDelete Region
> oList Regions
> •Admin should be able to create multiple zones with a Region. Management server cluster manages all the zones within the region. Following Zone operations should be supported on per regions basis:
> oCreate Zone
> oDelete Zone
> oList Zones
> •Management Server cluster for each region should only control the infrastructure within that region. In other words, if a management server cluster 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 other Regions in the cloud
> •Each Region should have access to an object store. The object store 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
> •EIP function should be available across both basic and advance Zones within a Region
> •ELB function should be available across both basic and advance Zones within a Region
> •The 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 regions as well.
> •Authentication credentials – username, password, keys – should be valid across all regions
> •Switching between Regions should not require the user to sign-on again (SSO should be supported).
> •Resource management should be extended to Region level
> oAvailable compute, storage, network (IPs, VLANs etc.) resources that are currently tracked should be aggregated and displayed at region level
> oAppropriate global parameters should be available at Region level while the remaining would be available at Zone level
> •Usage: All the (per account) usage records should be aggregated to Regions level
> •Global Configurations: All of the administrative hierarchy (Domains, Accounts, Users, Projects) related Global Configurations should have consistent values across all regions and has to be propagated when a user modifies a configuration on one of the regions.
> •Each region should maintain a list of all other regions and their region endpoints.
> Note:
> •Users are required to deploy all the MSs of a particular region in one zone
> 3UI / UX Requirements
> •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.
> oReports on the dashboard should be aggregated to Region level
> •On first UI access, user should be able to connect to another Cloudstack instance 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 SSO.
> 4Upgrade Scenarios
> Following upgrade scenarios should be supported:
> •Multiple Zones to Multiple Regions: Current deployments with multiple Zones should be able to move to a deployment of multiple Regions. Admins should be able to map one or more zones to a Region
> •All AZs in each Region should get access to all secondary storage from each region
> •Multiple Zones to Region: Current deployments with multiple Zones should be able to move to a deployment of single Region (this is a subset of the above requirement)
> oThis should be default upgrade behavior
> 5Non-Requirements
> •Management Server limited to per Zone is not a requirement for Campo. This functionality could be added in a subsequent release
> •EIP and ELB functions across zones are only supported when both zones are either basic or advance. It is not required to support EIP or ELB across basic and advanced zones
> •It is not required to display a dashboard/reports that are aggregated across Regions
> 6Open Items:
> •How will the hierarchy change with the requirement of supporting both a Basic Zone and an Advanced Zone within a single Cloudstack instance?
> •Assuming we don’t need the capability / APIs to disconnect Management server from one set and connect to another set of management servers
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira