incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sangeetha Hariharan <>
Subject RE: [ASFCS41] AWS-Style Regions
Date Mon, 07 Jan 2013 22:13:36 GMT

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

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


-----Original Message-----
From: Kishan Kavala [] 
Sent: Monday, January 07, 2013 3:50 AM
Subject: RE: [ASFCS41] AWS-Style Regions

I've updated the spec and moved it to ASF wiki.

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 []
Sent: Thursday, 13 December 2012 11:14 PM
Subject: Re: [ASFCS41] AWS-Style Regions

On Thu, Dec 13, 2012 at 12:02 PM, Manan Shah <> 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?


> Regards,
> Manan Shah
> On 12/12/12 9:19 PM, "Chip Childers" <> wrote:
>>On Wed, Dec 12, 2012 at 7:25 PM, Manan Shah <> 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:
>>> Requirements:
>>> 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 
>>Also, are you proposing that this be completed in time for the feature 
>>freeze at the end of January?

View raw message