cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rene Moser <m...@renemoser.net>
Subject Re: [DISCUSS] DB upgrade issue workaround for 4.10.0.0 users upgrading to 4.11.0.0
Date Wed, 14 Feb 2018 15:54:56 GMT
Hi all

Thanks for taking care of this issue.

However, I wonder how we can prevent such issues in the future and
wondering if this "incident" has its orginos by our current git workflow.

I find the workflow "commit to stable branch --> merge back to master"
is inconvenient. Because at one point, the branches divert too much
(think of refactorings on master branch) and a merge back to the master
would not work or would break.

In most of the project I work with, there are stable-branches as well
but any fix (and feature of course) has to be on master first. Any
serious fix could be cherry picked to stable branches (there may be more
than one) if applicable or an alternative fix could be made. stable
branches never receives merges from or to master branch.

To be honest, I haven't seen any project adopting this workflow, I
wondered why and how come we have this workflow.

Thanks for clarification.

René



On 02/12/2018 02:29 PM, Rohit Yadav wrote:
> All,
> 
> 
> Some of us have discussed and found an upgrade path issue that only affects the 4.10.0.0
users who may see missing columns in certain tables post upgrading to 4.11.0.0 version.
> 
> 
> The issue is/was that at the time 4.10.0.0 was released, PRs were merged to the 'then'
master branch that made changes to the 4.9.3.0->4.10.0.0 upgrade path instead of the 4.10.0.0->4.11.0.0
upgrade path. One of such change was an ALTER statement that added a new column `service_package_id`,
and if 4.10.0.0 version is upgraded to 4.11.0.0 such environments may report sql related errors
related to this column.
> 
> 
> (My colleagues Bobby and Ernie may chip in their findings and test results as well)
> 
> 
> Pull request: https://github.com/apache/cloudstack/pull/2452
> 
> Jira ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-10285
> 
> 
> The proposed workaround is to move the changes to the expected upgrade path of 4.10.0.0->4.11.0.0.
This is *not ideal* given 4.11.0.0 is released but at least 4.10.0.0 users who may want to
upgrade to 4.11.1.0 or later won't face the issue.
> 
> 
> The proposed workaround for current 4.10.0.0 users who may want to upgrade to 4.11.0.0
is to run the following sql statements from the PR above before upgrading to 4.11.0.0: (we
may discuss and update the release notes website as well)
> 
> 
> ### start sql ###
> 
> 
> use cloud;
> 
> 
> CREATE TABLE IF NOT EXISTS `cloud`.`netscaler_servicepackages` (
>   `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT 'id',
>   `uuid` varchar(255) UNIQUE,
>   `name` varchar(255) UNIQUE COMMENT 'name of the service package',
>   `description` varchar(255) COMMENT 'description of the service package',
>   PRIMARY KEY  (`id`)
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
> 
> CREATE TABLE IF NOT EXISTS `cloud`.`external_netscaler_controlcenter` (
>   `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT 'id',
>   `uuid` varchar(255) UNIQUE,
>   `username` varchar(255) COMMENT 'username of the NCC',
>   `password` varchar(255) COMMENT 'password of NCC',
>   `ncc_ip` varchar(255) COMMENT 'IP of NCC Manager',
>   `num_retries` bigint unsigned NOT NULL default 2 COMMENT 'Number of retries in ncc
for command failure',
>   PRIMARY KEY  (`id`)
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
> 
> ALTER TABLE `cloud`.`sslcerts` ADD COLUMN `name` varchar(255) NULL default NULL COMMENT
'Name of the Certificate';
> ALTER TABLE `cloud`.`network_offerings` ADD COLUMN `service_package_id` varchar(255)
NULL default NULL COMMENT 'Netscaler ControlCenter Service Package';
> 
> 
> DROP VIEW IF EXISTS `cloud`.`user_view`;
> CREATE VIEW `cloud`.`user_view` AS
>     select
>         user.id,
>         user.uuid,
>         user.username,
>         user.password,
>         user.firstname,
>         user.lastname,
>         user.email,
>         user.state,
>         user.api_key,
>         user.secret_key,
>         user.created,
>         user.removed,
>         user.timezone,
>         user.registration_token,
>         user.is_registered,
>         user.incorrect_login_attempts,
>         user.source,
>         user.default,
>         account.id account_id,
>         account.uuid account_uuid,
>         account.account_name account_name,
>         account.type account_type,
>         account.role_id account_role_id,
>         domain.id domain_id,
>         domain.uuid domain_uuid,
>         domain.name domain_name,
>         domain.path domain_path,
>         async_job.id job_id,
>         async_job.uuid job_uuid,
>         async_job.job_status job_status,
>         async_job.account_id job_account_id
>     from
>         `cloud`.`user`
>             inner join
>         `cloud`.`account` ON user.account_id = account.id
>             inner join
>         `cloud`.`domain` ON account.domain_id = domain.id
>             left join
>         `cloud`.`async_job` ON async_job.instance_id = user.id
>             and async_job.instance_type = 'User'
>             and async_job.job_status = 0;
> 
> 
> ### end sql ###
> 
> 
> Thoughts, perhaps other ways to tackle this?
> 
> 
> - Rohit
> 
> <https://cloudstack.apache.org>
> 
> 
> 
> rohit.yadav@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>   
>  
> 
> 

Mime
View raw message