It is not easy to sync/maintain the account information in several regions. Is it possible to have a separate account service, cloudstack management servers in multiple region can consult ?
Anthony > -----Original Message----- > From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] > Sent: Friday, January 18, 2013 3:41 PM > To: CloudStack DeveloperList > Subject: Re: Questions related to Regions Feature > > 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.kav...@citrix.com> wrote: > > >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 > >
