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

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

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

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

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

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

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

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

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

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,

Apache EU Roadshow CFP Closing Soon (23 February)

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

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

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

Travel assistance applications open - ApacheCon NA Montreal

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

Re: Reg CLOUDSTACK-8616

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: >

Re: Reg CLOUDSTACK-8616

... 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,

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:

Re: System VMs not migrating when host down

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

RE: System VMs not migrating when host down

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