Manan, Please find my answers inline. > -----Original Message----- > From: Manan Shah [mailto:manan.s...@citrix.com] > Sent: Wednesday, 16 January 2013 1:57 AM > To: cloudstack-dev@incubator.apache.org > Subject: FW: Questions related to Regions Feature > > Kishan, > > 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. > > We should try and capture all of these items in the Regions FS / Design spec > if > possible: > > > 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. > > 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. > > 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 > [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. > > 5. Removal of Region: > * On Region deletion, what happens to all of the objects that are owned by > that Region (Domains/Accounts/Projects) [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. > 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? > [KK] Global configs will be per Region. Configs need not be synced across regions. > > 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. > > 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? > [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. > > 10. DB Changes: > * Can you please document all DB related changes? New tables and existing > table changes? > [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? > [KK] This again should be part of object store related work and discussed separately. > > 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 > 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 > [KK] DB replication and disabling certain zones require manual steps. This will be documented in detail as part of upgrade procedure. > > 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. > > Regards, > Manan Shah
