cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <rohit.ya...@shapeblue.com>
Subject Re: [DISCUSS] DB upgrade issue workaround for 4.10.0.0 users upgrading to 4.11.0.0
Date Wed, 14 Feb 2018 14:00:03 GMT
All,


Given there was no objection to the approach, the concerned PR has been merged now. I've added
a note to the release notes website for 4.10.0.0 users only.


4.11.1.0 will contain the fix, so in case 4.10.0.0 users want to upgrade, they will not be
required to manually run the sql/upgrade-path workaround. Thanks.


- Rohit

<https://cloudstack.apache.org>



________________________________
From: Rohit Yadav <rohit.yadav@shapeblue.com>
Sent: Monday, February 12, 2018 2:29:18 PM
To: dev@cloudstack.apache.org; users@cloudstack.apache.org
Cc: Boris Stoyanov; Ernie Janse van Rensburg
Subject: [DISCUSS] DB upgrade issue workaround for 4.10.0.0 users upgrading to 4.11.0.0

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<http://www.shapeblue.com>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue




rohit.yadav@shapeblue.comĀ 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message