Re: [DISCUSS] DB upgrade issue workaround for 4.10.0.0 users upgrading to 4.11.0.0

[Rene Moser]

On 02/14/2018 06:21 PM, Daan Hoogland wrote:
> the -x would only add it to the comment making it harder to find. As for
> multiple stable branches; merging forward always folows all branches
> forward so a fix on 4.9 would be merged forward to 4.10 and then 4.10 would
> be merged forward again to 4.11 and finally to master. of course there is
> always work to do in terms of solving merge conflicts but these are
> generally less then port work as the order of any commits to the
> intemediats is always preserved.

I don't say this workflow is "bad" or does not work "technically".

To me, it looks "hard" to make a decision to which branch should a fix
go in the first place. And in this workflow, you basically have to
decided it _before_ the merge: To 4.11? or even 4.10? And if I should
have merged to 4.10 but merged it to 4.11, now what?

In contrast of the cherry-pick workflow: you decide _after_ to which
versions the fix should be backported to.

To me, this seems much convenient. But can live with that.

René

Re: [DISCUSS] DB upgrade issue workaround for 4.10.0.0 users upgrading to 4.11.0.0

[Daan Hoogland]

the -x would only add it to the comment making it harder to find. As for
multiple stable branches; merging forward always folows all branches
forward so a fix on 4.9 would be merged forward to 4.10 and then 4.10 would
be merged forward again to 4.11 and finally to master. of course there is
always work to do in terms of solving merge conflicts but these are
generally less then port work as the order of any commits to the
intemediats is always preserved.

On Wed, Feb 14, 2018 at 6:15 PM, Rene Moser  wrote:

> Hi Daan
>
> On 02/14/2018 05:26 PM, Daan Hoogland wrote:
> > Rene,
> >
> > The issue is certainly not due the git workflow but to upgrade schemes we
> > have.
> >
> > The result of this workflow for us is that it is easier to find to which
> > branches a particular commit is added as by merging forward the commit id
> > of the actual fix doesn't change. so instead of looking in each branch
> for
> > a bit of code you can look for a commit id on a branches log.
>
> Ah I see.
>
> However, the same can be achieved by adding -x to cherry-picks (to add
> the origin commit id), without the downside that a fix can "only" go
> into one stable branch.
>
> Keep in mind, we certainly do have more than one stable branch at a time
> (4.11-lts, 4.12). A fix should be applicable to any stable branch.
>
> Or how would this work with the current workflow?
>
> René
>
>
>
>
>
>


-- 
Daan

Re: [DISCUSS] DB upgrade issue workaround for 4.10.0.0 users upgrading to 4.11.0.0

[Rene Moser]

Hi Daan

On 02/14/2018 05:26 PM, Daan Hoogland wrote:
> Rene,
> 
> The issue is certainly not due the git workflow but to upgrade schemes we
> have.
> 
> The result of this workflow for us is that it is easier to find to which
> branches a particular commit is added as by merging forward the commit id
> of the actual fix doesn't change. so instead of looking in each branch for
> a bit of code you can look for a commit id on a branches log.

Ah I see.

However, the same can be achieved by adding -x to cherry-picks (to add
the origin commit id), without the downside that a fix can "only" go
into one stable branch.

Keep in mind, we certainly do have more than one stable branch at a time
(4.11-lts, 4.12). A fix should be applicable to any stable branch.

Or how would this work with the current workflow?

René

Re: [DISCUSS] DB upgrade issue workaround for 4.10.0.0 users upgrading to 4.11.0.0

[Daan Hoogland]

Rene,

The issue is certainly not due the git workflow but to upgrade schemes we
have.

The result of this workflow for us is that it is easier to find to which
branches a particular commit is added as by merging forward the commit id
of the actual fix doesn't change. so instead of looking in each branch for
a bit of code you can look for a commit id on a branches log.


On Wed, Feb 14, 2018 at 4:54 PM, Rene Moser  wrote:

> 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 

Re: [DISCUSS] DB upgrade issue workaround for 4.10.0.0 users upgrading to 4.11.0.0

[Rene Moser]

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 

Apache EU Roadshow CFP Closing Soon (23 February)

[Sharan F]

Hello Everyone

This is an initial reminder to let you all know that we are holding an 
Apache EU Roadshow co-located with FOSS Backstage in Berlin on 13^th and 
14^th June 2018. https://s.apache.org/tCHx


The Call for Proposals (CFP) for the Apache EU Roadshow is currently 
open and will close at the end of next week, so if you have been 
delaying making a submission because the closing date seemed a long way 
off, then it's time to start getting your proposals submitted.


So what are we looking for?
We will have 2 Apache Devrooms available during the 2 day Roadshow so 
are looking for projects including incubating ones, to submit 
presentations, panel discussions, BoFs, or workshop proposals. The main 
focus of the Roadshow will be IoT, Cloud, Httpd and Tomcat so if your 
project is involved in or around any of these technologies at Apache 
then we are very interested in hearing from you.


Community and collaboration is important at Apache so if your project is 
interested in organising a project sprint, meetup or hackathon during 
the Roadshow, then please submit it inthe CFP as we do have some space 
available to allocate for these.


If you are wanting to submit a talk on open source community related 
topics such as the Apache Way, governance or legal aspects then please 
submit these to the CFP for FOSS Backstage.


Tickets for the Apache EU Roadshow are included as part of the 
registration for FOSS Backstage, so to attend the Roadshow you will need 
to register for FOSS Backstage. Early Bird tickets are still available 
until the 21^st February 2018.


Please see below for important URLs to remember:

-  To submit a CFP for the Apache EU Roadshow 
:http://apachecon.com/euroadshow18/ 


-  To submit a CFP for FOSS Backstage : 
https://foss-backstage.de/call-papers


-  To register to attend the Apache EU Roadshow and/or FOSS Backstage : 
https://foss-backstage.de/tickets


For further updates and information about the Apache EU Roadshowplease 
check http://apachecon.com/euroadshow18/


Thanks
Sharan Foga, VP Apache Community Development

Re: [DISCUSS] DB upgrade issue workaround for 4.10.0.0 users upgrading to 4.11.0.0

[Rohit Yadav]

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






From: Rohit Yadav 
Sent: Monday, February 12, 2018 2:29:18 PM
To: dev@cloudstack.apache.org; us...@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





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




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

Travel assistance applications open - ApacheCon NA Montreal

[Rohit Yadav]

All,

Sending this on behalf of Gavin who has asked this to be shared on our
dev/user lists:

# Start #

The Travel Assistance Committee (TAC) are pleased to announce that travel
assistance applications for ApacheCon NA 2018 are now open!

We will be supporting ApacheCon NA Montreal, Canada on 24th - 29th
September 2018

 TAC exists to help those that would like to attend ApacheCon events, but
are unable to do so for financial reasons.
For more info on this years applications and qualifying criteria, please
visit the TAC website at < http://www.apache.org/travel/ <
http://www.apache.org/travel/> >. Applications are now open and will close 1st
May.

Important: Applications close on May 1st, 2018. Applicants have until the
closing date above to submit their applications (which should contain as
much supporting material as required to efficiently and accurately process
their request), this will enable TAC to announce successful awards shortly
afterwards.

As usual, TAC expects to deal with a range of applications from a diverse
range of backgrounds. We therefore encourage (as always) anyone thinking
about sending in an application to do so ASAP.
We look forward to greeting many of you in Montreal

Kind Regards,
Gavin - (On behalf of the Travel Assistance Committee)

# End #

Regards.

Re: Reg CLOUDSTACK-8616

[Wilder Rodrigues]

Hi Rohit,

Indeed.

I was about to write a comment on his review.

Funny that in 2015 nobody, not even I who wrote the code, noticed. :)

Cheers,
Wilder



> On 14 Feb 2018, at 11:40, Rohit Yadav  wrote:
> 
> ... for reference, the current code:
> https://github.com/apache/cloudstack/blob/4.11/systemvm/debian/opt/cloud/templates/check_heartbeat.sh.templ#L29
>  
> 
> 
> 
> 
> - Rohit
>  
> 
> 
> rohit.ya...@shapeblue.com  
> www.shapeblue.com 
> @shapeblue
>   
>   
> From: Rohit Yadav
> Sent: Wednesday, February 14, 2018 11:39:24 AM
> To: Jayakarteek Vasana; dev@cloudstack.apache.org; 
> wilder.rodrig...@ekholabs.ai
> Cc: Jayapal Uradi
> Subject: Re: Reg CLOUDSTACK-8616
>  
> Hi Jayakarteek,
> 
> I think you've indeed found a bug, please submit a PR against 4.11 changing 
> the difference (current - last, not last - current):
> 
> 
> 
> - Rohit
>  
> 
> 
> From: Jayakarteek Vasana 
> Sent: Wednesday, February 14, 2018 7:49:23 AM
> To: dev@cloudstack.apache.org; wilder.rodrig...@ekholabs.ai; Rohit Yadav
> Cc: Jayapal Uradi
> Subject: Reg CLOUDSTACK-8616
>  
> Hi,
>  
> For CLOUDSTACK-8616(https://issues.apache.org/jira/browse/CLOUDSTACK-8616) , 
> changes were  made in check_heartbeat.sh.tmpl
>  
> Logic was changed on how the diff  time is verified, with the changes the IF 
> condition ( last time will always be smaller than this time) will fail every 
> time and the ELSE log will fill the disk space.
>  
>  
> So can someone check and confirm the logic for the change and whether the 
> logs are needed in the else part
>  
> https://github.com/apache/cloudstack/pull/587/files#diff-002a85328505af2975427d354a11dbff
>  
> 
>  
> --Jayakarteek
>  
> DISCLAIMER
> ==
> This e-mail may contain privileged and confidential information which is the 
> property of Accelerite, a Persistent Systems business. It is intended only 
> for the use of the individual or entity to which it is addressed. If you are 
> not the intended recipient, you are not authorized to read, retain, copy, 
> print, distribute or use this message. If you have received this 
> communication in error, please notify the sender and delete all copies of 
> this message. Accelerite, a Persistent Systems business does not accept any 
> liability for virus infected mails. 

Re: Reg CLOUDSTACK-8616

[Rohit Yadav]

... for reference, the current code:

https://github.com/apache/cloudstack/blob/4.11/systemvm/debian/opt/cloud/templates/check_heartbeat.sh.templ#L29




- Rohit







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

From: Rohit Yadav
Sent: Wednesday, February 14, 2018 11:39:24 AM
To: Jayakarteek Vasana; dev@cloudstack.apache.org; wilder.rodrig...@ekholabs.ai
Cc: Jayapal Uradi
Subject: Re: Reg CLOUDSTACK-8616


Hi Jayakarteek,


I think you've indeed found a bug, please submit a PR against 4.11 changing the 
difference (current - last, not last - current):




- Rohit






From: Jayakarteek Vasana 
Sent: Wednesday, February 14, 2018 7:49:23 AM
To: dev@cloudstack.apache.org; wilder.rodrig...@ekholabs.ai; Rohit Yadav
Cc: Jayapal Uradi
Subject: Reg CLOUDSTACK-8616


Hi,



For CLOUDSTACK-8616(https://issues.apache.org/jira/browse/CLOUDSTACK-8616) , 
changes were  made in check_heartbeat.sh.tmpl



Logic was changed on how the diff  time is verified, with the changes the IF 
condition ( last time will always be smaller than this time) will fail every 
time and the ELSE log will fill the disk space.





So can someone check and confirm the logic for the change and whether the logs 
are needed in the else part



https://github.com/apache/cloudstack/pull/587/files#diff-002a85328505af2975427d354a11dbff



--Jayakarteek



DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: Reg CLOUDSTACK-8616

[Rohit Yadav]

Hi Jayakarteek,


I think you've indeed found a bug, please submit a PR against 4.11 changing the 
difference (current - last, not last - current):




- Rohit






From: Jayakarteek Vasana 
Sent: Wednesday, February 14, 2018 7:49:23 AM
To: dev@cloudstack.apache.org; wilder.rodrig...@ekholabs.ai; Rohit Yadav
Cc: Jayapal Uradi
Subject: Reg CLOUDSTACK-8616


Hi,



For CLOUDSTACK-8616(https://issues.apache.org/jira/browse/CLOUDSTACK-8616) , 
changes were  made in check_heartbeat.sh.tmpl



Logic was changed on how the diff  time is verified, with the changes the IF 
condition ( last time will always be smaller than this time) will fail every 
time and the ELSE log will fill the disk space.





So can someone check and confirm the logic for the change and whether the logs 
are needed in the else part



https://github.com/apache/cloudstack/pull/587/files#diff-002a85328505af2975427d354a11dbff



--Jayakarteek



DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

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

Re: System VMs not migrating when host down

[Andrija Panic]

Humble opinion (until HOST HA is ready in 4.11 if not mistaken?), avoid
using HA option for VMs  - avoid setting the  "Offer HA" option on any
compute/service offerings, since we did end  up (was it ACS 4.5 or 4.8,
can't remember now) having 2 copies of SAME VM running on 2 different
hosts...imagine storage/volume corruption...this happened a few times for
us.

HOST HA looks like really a nice thing, I have not tested that yet...but
sould completely solve the problem.

On 14 February 2018 at 10:14, Paul Angus  wrote:

> Hi Sean,
>
> The 'problem' with VM HA in KVM is that it relies on the parent host agent
> to be connected to report that the VM is down.  We cannot assume that just
> because a host agent is disconnected, that the VMs on that host are not
> running.
>
> This is where HOST HA comes in, this feature detects loss of connection to
> the agent and then tries to determine if the VMs on that host are active
> and then attempts some corrective action.
>
>
> Kind regards,
>
> Paul Angus
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>
> -Original Message-
> From: Sean Lair [mailto:sl...@ippathways.com]
> Sent: 13 February 2018 23:06
> To: dev@cloudstack.apache.org
> Subject: System VMs not migrating when host down
>
> Hi all,
>
> We are testing VM HA and are having a problem with our system VMs
> (secondary storage and console) not being started up on another host when a
> host fails.
>
> Shouldn't the system VMs be VM HA-enabled?  Currently they are just in an
> "Alert" agent state, but never migrate.  We are currently running 4.9.3.
>
>
> Thanks
> Sean
>



-- 

Andrija Panić

RE: System VMs not migrating when host down

[Paul Angus]

Hi Sean,

The 'problem' with VM HA in KVM is that it relies on the parent host agent to 
be connected to report that the VM is down.  We cannot assume that just because 
a host agent is disconnected, that the VMs on that host are not running. 

This is where HOST HA comes in, this feature detects loss of connection to the 
agent and then tries to determine if the VMs on that host are active and then 
attempts some corrective action.


Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Sean Lair [mailto:sl...@ippathways.com] 
Sent: 13 February 2018 23:06
To: dev@cloudstack.apache.org
Subject: System VMs not migrating when host down

Hi all,

We are testing VM HA and are having a problem with our system VMs (secondary 
storage and console) not being started up on another host when a host fails.

Shouldn't the system VMs be VM HA-enabled?  Currently they are just in an 
"Alert" agent state, but never migrate.  We are currently running 4.9.3.


Thanks
Sean