Kishan, I am planning to test this feature. I have the following queries after going over the FS and PRD:
1. PRD states - "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" Does this mean that we will have 1 Secondary Storage for the entire region and this would mean only 1 SSVM/region. In "Assumptions" section - following is state: Object Store: This feature assumes that S3 like object store is available. Either implemented in CloudStack or through integrations Wanted to confirm that we should be able to use NFS for Secondary Storage in such cases where we will share the same Secondary storage for multiple zones within the same region. In case of Upgrade scenario , where we have multiple zones with multiple Secondary storages ( 1 per zone) to begin with and we upgrade to a set up where all the zones become part of the same Region , what is the plan for handling the secondary storage merge ? Do we ask customers to do a manual merge of all the templates and snapshots from all the Secondary storages to one shared secondary storage before proceeding with the upgrade? 2. Will the following template API calls continue to refer to zoneId - createTemplate(), registerTemplate(),extractTemplate() ? In case of multiple zones with in the same region with only 1 secondary storage , it seems confusing to allow users to create templates for only 1 zone ? Also will the semantics of the existing copyTemplate() be changed to supporting copying of templates between regions ? Currently this API lets us copy templates between zones which will not be needed anymore. Or are we introducing a new API for supporting copying of templates between regions. 3. AWS impact - With the notion of "Regions" being introduced and having accounts/domains being replicated across multiple management server clusters , there will be a need to do the same kind of replication of "usercredentials" table in cloud_bridge as part of AWS user registeration. Will there be a need to expose the region parameter for any of the supported AWS api calls ? 4. For the following authentication related features mentioned in the FS: "Authentication Service 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." Are these authentication adapters specific to "Regions". Some of these already exist in the product without "Regions" concept. Wanted to know why FS mentions these authenticators specifically ? Could you please provide more insight into how these authenticators are affected because of the notion of "Regions" being introduced ? 5. With Accounts being shared across multiple "Regions", How are we planning to manage the various resource limits that are enforced at the account level/Domain level/Project level ? Should we expect the Resource counts to be honored across multiple regions? For example , if I have an account level resource limit for Vms to be set at 10 , then this account should be allowed to deploy only a maximum of 10 Vms across all the regions ? 6. PRD states - "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 region." Can we include all the global parameters that need to be synced across multiple regions in FS ? Do we expect this sync to happen when these global parameters actually get changed ? Global parameter changes require restart of management servers to take effect ? In case of global parameters that need to be in sync across multiple regions ,do we alert the users that all management servers need to be restarted? 7. Could you list all the DB changes introduced - 1) All new tables and 2) Changes done to existing tables -Thanks Sangeetha -----Original Message----- From: Kishan Kavala [mailto:kishan.kav...@citrix.com] Sent: Monday, January 07, 2013 3:50 AM To: cloudstack-dev@incubator.apache.org Subject: RE: [ASFCS41] AWS-Style Regions I've updated the spec and moved it to ASF wiki. https://cwiki.apache.org/confluence/display/CLOUDSTACK/AWS-Style+Regions+Functional+Spec Most of the implementation was already done on the Regions feature branch. Data synchronization across regions is done via regular API calls with admin keys. All update/delete operations are sent to the source Region (i.e. the region where the resource was initially created). If the source region is down, update/delete operations will fail. Is this an acceptable limitation? Should we consider other options instead of using API calls for data synchronization? Basically the problem we trying to solve is to keep data in certain tables (account, users, domains) consistent across multiple distributed databases (one database in each region). -----Original Message----- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Thursday, 13 December 2012 11:14 PM To: cloudstack-dev@incubator.apache.org Subject: Re: [ASFCS41] AWS-Style Regions On Thu, Dec 13, 2012 at 12:02 PM, Manan Shah <manan.s...@citrix.com> wrote: > Yes, Chip, this is the same feature. I didn't see the requirements and > so added them and linked the JIRA tickets and requirements together. > > I am not a developer of this feature and so I added the requirements > in the "Not committed to a release" page but I am proposing that this > feature be completed in time for the end of Jan feature freeze time. Thanks for clarifying. Kishan appears to have the Jira record assigned to him. Kishan - is this something you are hoping to make it into 4.1? Thanks! > Regards, > Manan Shah > > > > > On 12/12/12 9:19 PM, "Chip Childers" <chip.child...@sungard.com> wrote: > >>On Wed, Dec 12, 2012 at 7:25 PM, Manan Shah <manan.s...@citrix.com> wrote: >>> Hi, >>> >>> I would like to propose a new feature for AWS-Style Regions. I have >>>created a JIRA ticket and provided the requirements at the following >>>location. Please provide feedback on the requirements. >>> >>> JIRA Ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-241 >>> Requirements: >>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/AWS-Style+Regi >>>ons >>> >>> Regards, >>> Manan Shah >> >>Thanks for sharing Manan! >> >>One question though: Is this the same, or different, from what was >>discussed in [1]? I'm asking, because I'm trying to track down all >>features that are being proposed to ensure that we don't have any lose >>ends. >> >>Also, are you proposing that this be completed in time for the feature >>freeze at the end of January? >> >>-chip >> >>[1] http://markmail.org/thread/iellnivoxq3kgz5w > >
