Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of Chiradeep.Vittal@citrix.com
 designates 66.165.176.89 as permitted sender)
From: Chiradeep Vittal <Chiradeep.Vittal@citrix.com>
To: CloudStack DeveloperList <cloudstack-dev@incubator.apache.org>
Date: Fri, 18 Jan 2013 15:41:12 -0800
Subject: Re: Questions related to Regions Feature
Thread-Topic: Questions related to Regions Feature
Thread-Index: Ac311UyxnQNYhsepTQ2f/6EE+giyTw==
Message-ID: <CD1F1D5C.41456%chiradeep.vittal@citrix.com>
In-Reply-To: 
 <33740054EBF5B64BB213E2E0916F2C13F011BBE73A@BANPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.13.0.110805
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

I think that replication of data to each region (even if it is only for
account data) is fraught with complexity and should be left to an external
service.
Can we simplify by assuming that accounts are synced "somehow"?

On 1/17/13 4:58 AM, "Kishan Kavala" <Kishan.Kavala@citrix.com> wrote:

>Manan,
> Please find my answers inline.
>
>> -----Original Message-----
>> From: Manan Shah [mailto:manan.shah@citrix.com]
>> Sent: Wednesday, 16 January 2013 1:57 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: FW: Questions related to Regions Feature
>>=20
>> Kishan,
>>=20
>> I reviewed the FS and I have quite a few questions. I have also reviewed
>> questions posted by Sangeetha and tried to cover all of her questions
>>as well.
>> Please see the questions below and let us know your thoughts.
>>=20
>> We should try and capture all of these items in the Regions FS / Design
>>spec if
>> possible:
>>=20
>>=20
>> 1. Assumption is that we will support both NFS as well as ObjectStore
>>as a
>> secondary storage. This also means that all templates stored in NFS
>>storage
>> (Region-wide) should be available for all zones within a region.
>
>[KK] Object store is Region-wide. Secondary storage will remain at the
>zone level the way it is now. Migration will be required only when
>someone using NFS secondary storage in 4.0 moves to object store in 4.1.
>This migration will be manual process which has to be documented along
>with some scripts to migrate.
>
>>=20
>> 2. Assumption is that we will continue to support NFS as a secondary
>>storage
>> at the zone level as well as add support for NFS as secondary storage
>>at the
>> region level
>
>[KK] NFS secondary storage will be supported at the zone level only.
>There will be no NFS secondary storage at Region level. Support for
>object store at region level will be added. Using object store is
>optional. During upgrade if someone wants to use object store, data in
>NFS secondary storage has to be migrated to object store as mentioned
>above.
>
>>=20
>> 3. Addition of a new Region to a existing Cloud:
>> A. New Region Addition:
>> 	* Current functionality is to add a new Region to every existing
>>region.
>> This is undesirable. We should replicate the regions DB table just like
>> Domain/Accounts, etc so that end users have to add it only in 1 place
>
>[KK] It is a good to have functionality. Add Region is a one-time
>operation and we can live with this limitation for 4.1 release.
>
>> 	* Please update the FS with the expected admin workflow B. Sync of
>> Domain / Account / etc:
>
>[KK]  I'll add these to FS
>
>> 	* You had mentioned that this would be done only on a as-needed
>> basis.
>> This seems to be confusing. We need to clearly indicate when would the
>>DB
>> tables be synced. Our expectation was that when a new Region is added,
>>all
>> necessary DB tables will get populated  from sync'd DB Table list C.
>>Sync of
>
>[KK] When a new Region is added, existing Account/User/Domain details
>have to copied to new Region manually. This will be documented in FS with
>steps to copy the data. Any changes after adding Region will be
>propagated immediately.
>
>> Projects:
>> 	* This is in requirements but seems to be missing in FS
>>=20
>
>[KK]  Projects won't be available across regions.
>
>> 4. Sync of Domain / Account when a Region goes down and comes back up:
>> * You seem to indicate that this would be done on a on-demand basis. Not
>> clear of the use cases. FS needs to document the details.
>
>[KK] It is the responsibility of the source region to ensure that changes
>are propagated to all regions. I'm still exploring on how to ensure this.
>
>>=20
>> 5. Removal of Region:
>> * On Region deletion, what happens to all of the objects that are owned
>>by
>> that Region (Domains/Accounts/Projects)
>=20
>[KK] Ownership of the deleted Region objects has to be manually changed
>to another Region. This again will be documented along with scripts to
>make this change.
>
>> 6. Steps to add / remove Regions:
>> * Please document the procedure to add/remove regions.
>
>[KK] Add/Remove will be through addRegion and removeRegion APIs. I'll add
>workflows to FS explaining the same.
>
>=20
>> 7. Sync of Global Params:
>> * Assuming that account/domain/etc related global configs will be
>> propagated. Please list all of the global params that will be
>>propagated.
>> Global Param changes require a re-start of Mgmt servers. So, if a domain
>> related global config is changed, would we  display a message for all
>>regions
>> to re-start mgmt servers?
>>=20
>
>[KK] Global configs will be per Region. Configs need not be synced across
>regions.
>
>>=20
>> 8. Resource Limits at the Global level: For example, if a user is
>>authorized to
>> spin 5 VMs,  that should be 5 VMs for the entire cloud and not 5 VMs
>>for a
>> Region
>
>[KK]  Limits again will be per Region.
>
>>=20
>> 9. API Related changes:
>> * Please indicate in FS all API changes (new APIs as well as changes
>>made to
>> existing APIs)
>> * What about createTemplate(), registerTemplate(),extractTemplate()
>>APIs?
>> How will the copyTemplate() API change?
>>=20
>
>[KK]  Regiona API changes are already added to FS. Template related API
>changes will be part of object store work and should probably be
>discussed in that spec.
>
>>=20
>> 10. DB Changes:
>> * Can you please document all DB related changes? New tables and
>>existing
>> table changes?
>>=20
>
>[KK] Sure, I'll add DB changes to spec.
>
>> 11. SSVM behavior changes:
>> * Are there any SSVM behavior changes?
>> * If a VM is being launched in Zone 1 whose template is in secondary
>>storage
>> accessible to zone 1 but physically located in zone 2, would the SSVM
>>from
>> zone 1 be able to fetch template from secondary storage in zone 2?
>>=20
>
>[KK]  This again should be part of object store related work and
>discussed separately.
>
>>=20
>> 12. I understand that the EC2 SOAP support requires another
>>authentication
>> mechanism. Assuming we will support this as well.
>>
>
>[KK] I'm not sure about this requirement
>
>=20
>> 13. Upgrade Support:
>> * Assuming we will support all current zones to be in 1 region (with
>>zone-
>> wide secondary storage)
>> * Assuming we will support mix-and-match use case where users can pick
>> which zones belong to which regions?
>> * How will the DB be replicated and split apart?
>> * Assuming we support mix-and-match, please document the steps that the
>> admins would have to go through
>>=20
>
>[KK] DB replication and disabling certain zones require manual steps.
>This will be documented in detail as part of upgrade procedure.
>
>>=20
>> 14. You have mentioned some details in FS related to authentication.
>>Can you
>> elaborate this or remove it?
>
>[KK] UI should display drop-down list of Regions and when a new Region is
>selection, end_point should change to the selected Region without
>requiring authentication.
>
>>=20
>> Regards,
>> Manan Shah
>