Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Date: Thu, 3 Oct 2013 11:21:22 -0400
From: Chip Childers <chip.childers@sungard.com>
To: dev@cloudstack.apache.org
Subject: Re: [Proposal] Improve VR upgrades
Message-ID: <20131003152122.GS73023@USLT-205755.sungardas.corp>
References: 
 <C7522783E0E6D3488D82B9A7F7F004B912993730@SINPEX01CL01.citrite.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <C7522783E0E6D3488D82B9A7F7F004B912993730@SINPEX01CL01.citrite.net>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Thu, Oct 03, 2013 at 11:47:57AM +0000, Kishan Kavala wrote:
> During CS upgrade, VRs are required to be upgraded to use newer systemVm template . 
> The current VR upgrade procedure has following limitations:
>  - takes 'long' time and the time exponentially increases with the size of the cloud
> - no way to sequence upgrade of different parts of the cloud, i.e., specific clusters or pods or even zones
> - there is no way to determine when a particular customer's services (e.g. VR) will be upgraded with the upgrade interval
> 
> Goals for this feature are to address the above issues
> 
> 1. Give admin control to sequence the upgrade of the cloud by:
>        - Infrastructure hierarchy: by Cluster, Pod, and Zone etc.
>        - Administrative hierarchy: by Tenant or Domain 
> 2. Minimize service interruption to users
> 3. Improve the speed of the upgrade time by making as many upgrade operations in parallel as possible
> 
> I've created JIRA ticket:
> https://issues.apache.org/jira/browse/CLOUDSTACK-4793
> 
> thanks,
> Kishan
>

This proposal sounds great, but the devil will be in the implementation
details.  To do this as rolling, we'd need to ensure backward compat
with agent>MS communications, right?

-chip