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