Re: KVM HA is broken, let's fix it

[Remi Bergsma]

Hi Lucian,

Can you please explain what the issue is with KVM HA? In my tests, HA starts 
all VMs just fine without the hypervisor coming back. At least that is on 
current 4.6. Assuming a cluster of multiple nodes of course. It will then do a 
neighbor check from another host in the same cluster. 

Also, malfunctioning NFS leads to corruption and therefore we fence a box when 
the shared storage is unreliable. Combining primary and secondary NFS is not a 
good idea for production in my opinion. 

I'm happy to help and if you have a scenario I can replay I will try that in my 
lab. 

Regards, Remi 

Sent from my iPhone

> On 10 Oct 2015, at 00:19, Nux!  wrote:
> 
> Hello, 
> 
> Following a recent thread on the users ml where slow NFS caused a mass 
> reboot, I have opened the following issue about improving HA on KVM.
> https://issues.apache.org/jira/browse/CLOUDSTACK-8943
> 
> I know there are many people around here who use KVM and are interested in a 
> more robust way of doing HA.
> 
> Please share your ideas, comments, suggestions, let's see what we can come up 
> with to make this better.
> 
> Regards,
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

Re: Requested by a presenter at CCC in Dublin today

[Remi Bergsma]

Thanks Todd! Nice to find a cloud that has been running since the vmops days :-)

What's the next upgrade? 4.5.2?

Regards, Remi 

Sent from my iPhone

> On 08 Oct 2015, at 21:27, Todd Hebert  wrote:
> 
> One of the presenters (Remi?) asked me to post this query from the cloud 
> database on our CloudPlatform, which has been in continuous operations since 
> shortly before the name change to cloud.com some years ago.  (originally 
> stood up in 2010. Apparently there was no version table back then.)
> 
> mysql> select * from version;
> ++-+-+--+
> | id | version | updated | step |
> ++-+-+--+
> |  1 | 2.2.1   | 2011-11-09 18:07:49 | Complete | 
> |  2 | 2.2.2   | 2011-11-09 18:07:49 | Complete | 
> |  3 | 2.2.4   | 2011-11-09 18:07:50 | Complete | 
> |  4 | 2.2.5   | 2011-11-09 18:07:50 | Complete | 
> |  5 | 2.2.6   | 2011-11-09 18:07:50 | Complete | 
> |  6 | 2.2.8   | 2011-11-09 18:07:50 | Complete | 
> |  7 | 2.2.9   | 2011-11-09 18:07:50 | Complete | 
> |  8 | 2.2.10  | 2011-11-09 18:07:49 | Complete | 
> |  9 | 2.2.11  | 2011-11-09 18:07:49 | Complete | 
> | 10 | 2.2.12  | 2011-11-09 18:07:49 | Complete | 
> | 11 | 2.2.13  | 2013-02-22 21:07:32 | Complete | 
> | 12 | 2.2.14  | 2013-02-22 21:07:32 | Complete | 
> | 13 | 3.0.0   | 2013-02-23 00:23:41 | Complete | 
> | 14 | 3.0.1   | 2013-02-23 00:23:41 | Complete | 
> | 15 | 3.0.2   | 2013-02-23 00:23:46 | Complete | 
> | 16 | 3.0.3   | 2013-02-23 00:23:46 | Complete | 
> | 17 | 3.0.4   | 2013-02-23 00:23:46 | Complete | 
> | 18 | 3.0.5   | 2013-02-23 00:23:46 | Complete | 
> | 19 | 3.0.6   | 2013-02-23 00:23:46 | Complete | 
> | 20 | 3.0.7   | 2014-09-29 22:49:18 | Complete | 
> | 21 | 4.1.0   | 2014-12-10 10:01:17 | Complete | 
> | 22 | 4.2.0   | 2014-12-10 10:01:17 | Complete | 
> | 23 | 4.2.1   | 2014-12-10 10:01:17 | Complete | 
> | 24 | 4.3.0   | 2014-12-10 10:01:17 | Complete | 
> ++-+-+--+
> 24 rows in set (0.00 sec)
> 
> 
> 
> Todd Hebert
> Hosting engineer
> 
> E: theb...@digiweb.ie
> A: College Business & Technology Park, Blanchardstown, Dublin 15, Ireland 
> W: http://www.digiweb.ie/
>  
> 
> 
> 

Re: BVT report 10/5

[Remi Bergsma]

Hi,

I looked into the reboot of the SSVM and CPVM and can reproduce the failing 
tests. Created an issue:
https://issues.apache.org/jira/browse/CLOUDSTACK-8933


The failure is caused by the fact that on reboot the systemvms are not patched 
(patchviasocket script), and at boot time they wait for this to happen. When I 
run the patch command manual it works. See for details the above ticket.

This is KVM related, solving it fixes it both in Advanced and Basic zones.

Who can help figuring out why it isn’t patched as it should?

Regards,
Remi




On 05/10/15 21:08, "Raja Pullela"  wrote:

>Changes in code base since last BVT report - 10/1
>-  CLOUDSTACK-8848: ensure power state is up to date when handling 
>missing VMs in powerReport - resmo 
>/ 
>detail
>-  CLOUDSTACK-8848: added null pointer guard to new public method - 
>Daan Hoogland / 
>detail
>Bugs -
>
>-  
>CloudStack-8927 /
>
>-  
>CloudStack-8923 /
>
>-  
>CloudStack-8915 /
>
>-  
>CloudStack-8876 /
>
>-  
>CloudStack-8697 / 
>related to test case failure: 
>integration.smoke.test_internal_lb.TestInternalLb.test_internallb
>
>BVT Report - 10/5/15
>
>-  Simulator Basic - 100%
>
>-  Simulator Adv - 100%
>
>-  XS Basic - 98.6%, 1 failure
>
>-  XS Adv - 95.5%, 5 failures
>
>-  KVM Basic - 94.2%, 4 failures /another run that happened on Sunday 
>night, test_07_reboot_ssvm  passed but came back up?
>
>-  KVM Adv - 92.6%, 8 failures
>
>Tests failed
>XS Basic - 1 failure
>
>-  integration.smoke.test_volumes.TestVolumes.test_02_attach_volume
>XS Adv - 5 failures
>
>-  :setup
>
>-  
>integration.smoke.test_loadbalance.TestLoadBalance.test_01_create_lb_rule_src_nat
>
>-  
>integration.smoke.test_loadbalance.TestLoadBalance.test_02_create_lb_rule_non_nat
>
>-  
>integration.smoke.test_loadbalance.TestLoadBalance.test_assign_and_removal_lb
>
>-  integration.smoke.test_internal_lb.TestInternalLb.test_internallb
>KVM Basic - 4 Failures
>
>-  
>integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso
>
>-  integration.smoke.test_volumes.TestVolumes.test_02_attach_volume
>
>-  integration.smoke.test_ssvm.TestSSVMs.test_07_reboot_ssvm
>
>-  integration.smoke.test_ssvm.TestSSVMs.test_08_reboot_cpvm
>KVM Advanced - 8 Failures
>
>-  
>integration.smoke.test_loadbalance.TestLoadBalance.test_01_create_lb_rule_src_nat
>
>-  
>integration.smoke.test_loadbalance.TestLoadBalance.test_02_create_lb_rule_non_nat
>
>-  
>integration.smoke.test_loadbalance.TestLoadBalance.test_assign_and_removal_lb
>
>-  :setup
>
>-  
>integration.smoke.test_snapshots.TestSnapshotRootDisk.test_01_snapshot_root_disk
>
>-  integration.smoke.test_ssvm.TestSSVMs.test_07_reboot_ssvm
>
>-  integration.smoke.test_ssvm.TestSSVMs.test_08_reboot_cpvm
>
>-  integration.smoke.test_internal_lb.TestInternalLb.test_internallb

Re: jenkins analysis and rat jobs

[Remi Bergsma]

Hi,

That’s great! I’d asked infra about it because it makes Jenkins more visible. 
Great that it’s there now :-)

Regards,
Remi




On 05/10/15 11:55, "Daan Hoogland"  wrote:

>H,
>
>As you have undoubtetly noticed the jobs at builds.a.o no longer comment in
>our PRs after they are done. They do however edit the commitstatus which
>found hovering over a little check near the commit-id. It used to only
>record jenkins successtatus but since PR912 it also shows the builds.a.o
>status.
>
>be warned,
>-- 
>Daan

Re: [GitHub] cloudstack pull request: CLOUDSTACK-8848: ensure power state is up...

[Remi Bergsma]

Let's merge this as-is for 4.6 and solve a blocker. The improvement can be done 
later in a separate PR. 

Sent from my iPhone

> On 02 Oct 2015, at 10:29, DaanHoogland  wrote:
> 
> Github user DaanHoogland commented on the pull request:
> 
>https://github.com/apache/cloudstack/pull/885#issuecomment-144958879
> 
>Had a look, the NPE won't occur within the scope of this fix. I would 
> suggest some changes anyway to prevent future issues as the method 
> isPowerStateUpToDate() is public.
> 
> 
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---

Re: [VOTE] jenkins jobs removal

[Remi Bergsma]

+1 on 4.3 jobs, although I'd like to hear from Rohit to confirm 

+0 on the rest as I cannot judge it. 

Regards, Remi 

Sent from my iPhone

> On 02 Oct 2015, at 02:44, Pierre-Luc Dion  wrote:
> 
> Following Jenkins jobs on j.bac.o will be deleted doing the following tasks:
> 1. backup of the jobs configuration will be taken:
>tar -zcvf j.bac.o_jobs-archive_20151005.tgz ~jenkins/jobs
> 2. job will be deleted from jenkins
> 3. workspaces will be deleted from jenkins master server to free up disk
> space.
> 
> 
> VIEW | NAME  |
> STATE| LAST_SUCCESS
> -|---|--|--
> 4.3  | cloudstack-4.3-maven-build| blue
>| 2015-08-14 01:59:15
> 4.3  | cloudstack-4.3-maven-build-noredist   |
> aborted  | 2015-03-11 08:11:01
> 4.3  | cloudstack-4.3-package-deb| blue
>| 2015-08-14 02:04:39
> 4.3  | cloudstack-4.3-package-rpm| blue
>| 2015-03-11 08:11:01
> 4.3  | cloudstack-4.3-package-rpm-noredist   | blue
>| 2014-09-02 10:29:12
> 4.3  | cloudstack-4.3-systemvm   | blue
>| 2015-01-28 15:33:09
> 4.3  | cloudstack-4.3-systemvm64 | blue
>| 2015-01-28 13:25:12
> 4.3  | HyperVAgent4.3| blue
>| 2014-12-04 11:27:14
> disabled | build-docs-admin-master   |
> disabled | 2014-03-25 13:20:25
> disabled | build-docs-devguide-master|
> disabled | 2014-03-25 13:26:51
> disabled | build-docs-install-master |
> disabled | 2014-03-25 13:26:51
> disabled | build-docs-midonet-master |
> disabled | 2014-02-06 06:44:22
> disabled | build-docs-niciranvp-master   |
> disabled | 2014-02-06 06:42:37
> disabled | build-docs-release-notes-master   |
> disabled | 2014-02-06 06:48:51
> disabled | build-docs-vxlan-master   |
> disabled | 2014-02-06 06:26:57
> disabled | build-test-centos-builtin |
> disabled | n/a
> disabled | built-test-archive|
> disabled | 2014-06-06 01:38:51
> disabled | cloudstack-4.4-auto-marvin|
> disabled | 2015-06-15 13:28:22
> disabled | docs-4.3-gsoc-guide   |
> disabled | 2015-03-08 18:20:07
> disabled | Master - Python Static Code Analysis  |
> disabled | n/a
> disabled | mgmt-build-reviewboard-requests   |
> disabled | n/a
> disabled | run-checkin-tests |
> disabled | n/a
> disabled | simulator-build   |
> disabled | 2014-07-31 09:47:03
> disabled | simulator-deploydb|
> disabled | 2014-02-12 19:50:50
> disabled | simulator-gate|
> disabled | 2014-01-23 04:18:31
> disabled | simulator-singlerun   |
> disabled | 2015-05-01 10:30:28
> disabled | start-jetty   |
> disabled | 2014-02-12 19:23:03
> disabled | stop-jetty|
> disabled | 2013-11-20 08:14:46
> disabled | test-matrix-4.4   |
> disabled | n/a
> disabled | test-matrix-extended-4.4  |
> disabled | n/a
> disabled | test-matrix-extended-master   |
> disabled | 2014-02-21 04:35:36
> disabled | test-matrix-master|
> disabled | n/a
> disabled | test-smoke-matrix-master  |
> disabled | 2014-12-21 10:39:18
> disabled | test-yumrepo-refresh-4.4  |
> disabled | 2014-10-21 09:43:33
> disabled | test-yumrepo-refresh-master   |
> disabled | 2014-11-21 05:32:00
> management   | mgmt-build-reviewboard-requests   |
> disabled | n/a
> master   | build-systemvm64-master-with-debian8  | red
> | n/a
> master   | cloudstack-rpm-packages-with-branch-parameter |
> notbuilt | n/a
> master   | pull-requests |
> notbuilt | n/a
> parameterized| cloudstack-rpm-packages-with-branch-parameter |
> notbuilt | n/a
> parameterized| parameterized-slowbuild   |
> notbuilt | n/a
> parameterized| parameterized-sytemvm |
> notbuilt | n/a
> simulator| fastsimulatorbuild   

Re: test_nicira_controller.py is failing on all Advzone - XS, KVM

[Remi Bergsma]

Hi Raja,

Skipping tests makes them invisible, I think that is Miguels point. 

Yesterday I run some tests and I almost reported all as OK only to realise it 
had skipped a test due to not having a certain setup. If it had failed, I would 
have noticed sooner.

Regards,
Remi




On 01/10/15 13:36, "Raja Pullela"  wrote:

>Hi Miguel, 
>
>I have a setup that runs pretty much everything we have under "smoke" folder 
>as is.  So, was the request to skip if the config was not there.  
>
>We can put proper error message as Koushik suggested:  "config not there or 
>incorrect config".
>With that change, it will work for you and with my setup.
>
>I can put in the PR with the changes and you can comment if it works for you?
>
>best,
>Raja
>-Original Message-
>From: sebgoa [mailto:run...@gmail.com] 
>Sent: Thursday, October 1, 2015 4:34 PM
>To: dev@cloudstack.apache.org
>Subject: Re: test_nicira_controller.py is failing on all Advzone - XS, KVM
>
>I am not aware of anyone except Schuberg that uses the nicira (NSX) cloudstack 
>integration.
>
>And since Miguel wrote the test, I am comfortable doing what he suggests and 
>not run it as part of the standard tests for a release.
>
>-sebastien
>
>On Oct 1, 2015, at 12:57 PM, Miguel Ferreira  
>wrote:
>
>> Can't we not run the test if we do not wish to do so?
>> 
>> \ Miguel Ferreira
>>   mferre...@schubergphilis.com
>> 
>> 
>> 
>> 
>> On 01 Oct 2015, at 12:11, Koushik Das 
>> mailto:koushik@citrix.com>> wrote:
>> 
>> Can't we output a proper message (missing OR incorrect config) while 
>> skipping the test?
>> 
>> On 01-Oct-2015, at 2:56 PM, Miguel Ferreira 
>> mailto:mferre...@schubergphilis.com>> wrote:
>> 
>> Hi Raja,
>> 
>> I don't agree with what you propose.
>> I do understand your intention is to be able to run all tests and skip the 
>> ones you don't have a config for.
>> However, I also see the other side of that coin, when someone actually wants 
>> to run the tests but makes a mistake in the config and the tests get skipped.
>> 
>> I think the test should fail if the config is not right, or otherwise be 
>> excluded if the indentation is to not run them.
>> 
>> Cheers,
>> \ Miguel Ferreira
>> mferre...@schubergphilis.com> to:mferre...@schubergphilis.com>
>> 
>> 
>> 
>> 
>> On 30 Sep 2015, at 19:40, Raja Pullela 
>> mailto:raja.pull...@citrix.com>>
>>  wrote:
>> 
>> Hi Miguel,
>> 
>> Can you please add some checking in the setup method for the configuration 
>> parameters and if it is not available, can you skip this test?
>> 
>> Raja
>> 
>> -Original Message-
>> From: Raja Pullela [mailto:raja.pull...@citrix.com]
>> Sent: Wednesday, September 30, 2015 5:52 PM
>> To: Miguel Ferreira 
>> mailto:mferre...@schubergphilis.com>> lto:mferre...@schubergphilis.com>>
>> Cc: dev 
>> mailto:dev@cloudstack.apache.org>> v...@cloudstack.apache.org>>
>> Subject: RE: test_nicira_controller.py is failing on all Advzone - XS, 
>> KVM
>> 
>> thanks Miguel !
>> 
>> From: Miguel Ferreira [mailto:mferre...@schubergphilis.com]
>> Sent: Wednesday, September 30, 2015 3:01 PM
>> To: Raja Pullela 
>> mailto:raja.pull...@citrix.com>> ull...@citrix.com>>
>> Cc: dev 
>> mailto:dev@cloudstack.apache.org>> v...@cloudstack.apache.org>>
>> Subject: Re: test_nicira_controller.py is failing on all Advzone - XS, 
>> KVM
>> 
>> Hi Raja,
>> 
>> That test needs a NSX cluster. With that in place, the configuration used to 
>> run the test must define a section called NiciraNvp, and that section should 
>> have an array os hosts with that name (see line 46 of the test).
>> In a Marvin config that materializes in something like this:
>> "niciraNvp": {
>> 
>> "hosts": [ "nsxcon1.cloud.lan", "nsxcon2.cloud.lan" ] }
>> 
>> Furthermore, you need to have a zone configured to use NSX and that requires 
>> more work.
>> You can find a full Marvin config for it here: 
>> https://github.com/schubergphilis/MCT-shared/blob/master/marvin/mct-zo
>> ne1-kvm1-NVP.cfg In that same git repo there are config files for 
>> deploying a NSX cluster 
>> (https://github.com/schubergphilis/MCT-shared/blob/master/deploy/cloud/nsx_cluster.conf).
>> However, we have not yet fully automated all the steps needed to get the 
>> cluster up and running (ie. setting up the cluster internals, and adding a 
>> more controllers to the cluster).
>> I can help you with that if you need.
>> 
>> Cheers,
>> \ Miguel Ferreira
>> mferre...@schubergphilis.com> to:mferre...@schubergphilis.com>
>> 
>> 
>> 
>> On 30 Sep 2015, at 09:05, Raja Pullela 
>> mailto:raja.pull...@citrix.com>>
>>  wrote:
>> 
>> Hi Miguel or someone's familiar with this test,
>> 
>> Can you please provide documentation around how to get these tests running ?
>> BTW - looks lik

Re: BVT report 10/1

[Remi Bergsma]

Thanks Raja,

Just merged #900. PR #902 doesn’t have any review yet. Once it got them, I’ll 
merge it as well.

I’m running BVT tests against some of the PRs that resolve blockers. Please 
help running the tests, as it takes quite some time. Without it, we risk of 
breaking things that were fixed before.

Regards,
Remi



On 01/10/15 13:20, "Raja Pullela"  wrote:

>Blockers - as open in ACS JIRA:
>
>-  CloudStack-8927 /
>
>-  CloudStack-8924 / Test case failure.  Waiting for PR-900/902 to be 
>merged.
>
>-  CloudStack-8923 /
>
>-  CloudStack-8915 /
>
>-  CloudStack-8876 /
>
>-  CloudStack-8697 / related to test case failure: 
>integration.smoke.test_internal_lb.TestInternalLb.test_internallb
>
>BVT report - 10/1 -
>Summary:  Runs same as earlier run on 09/29 - merging PRs 900/902 will help 
>get Simulator Basic and XS Basic to 100%.
>Hope Rajani or Remi can push these PRs!
>
>
>-  Simulator Basic - 97.6%, 1 test failed
>
>-  Simulator Adv - 100%
>
>-  XS Basic - 98.5%, 1 test failed
>
>-  XS Adv - 94.5%, 4 tests failed
>
>-  KVM Basic - 94.2%, 6 tests failed
>
>-  KVM Adv - 92.6%, 8 tests failed
>
>Test case failures:  No change from earlier report, waiting for couple of PRs 
>to be merged
>
>-  Simulator Basic
>
>o   
>integration.smoke.test_scale_vm.TestScaleVm.test_02_scale_vm_without_hypervisor_specifics
> //Failure: CloudStack-8924
>
>-  XS Basic
>
>o   
>integration.smoke.test_scale_vm.TestScaleVm.test_02_scale_vm_without_hypervisor_specifics
> //Failure: CloudStack-8924
>
>-  KVM Basic
>o
>integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso
>  //Failure: SSH failed for VM
>ointegration.smoke.test_volumes.TestVolumes.test_02_attach_volume  
>//Failure: Root cause is TBD
>ointegration.smoke.test_ssvm.TestSSVMs.test_07_reboot_ssvm  //Failure: 
>Root cause is TBD
>
>o   integration.smoke.test_ssvm.TestSSVMs.test_08_reboot_cpvm  //Failure: Root 
>cause is TBD
>
>-  XS Adv
>
>o:setup  // Failure: 
>Test Setup.  Asked if Miguel can put conditional code to skip the test; 
>assuming that this is passing in his Env.
>
>o
>integration.smoke.test_scale_vm.TestScaleVm.test_02_scale_vm_without_hypervisor_specifics
> //Failure: CloudStack-8924
>
>o
>integration.smoke.test_loadbalance.TestLoadBalance.test_01_create_lb_rule_src_nat
> //Failure: SSH failed for VM
>
>o
>integration.smoke.test_loadbalance.TestLoadBalance.test_02_create_lb_rule_non_nat
>  //Failure: SSH failed for VM
>
>o
>integration.smoke.test_loadbalance.TestLoadBalance.test_assign_and_removal_lb  
>//Failure: SSH failed for VM
>
>o   integration.smoke.test_internal_lb.TestInternalLb.test_internallb 
>//Failure: CloudStack-8697
>
>-  KVM Adv
>o
>integration.smoke.test_loadbalance.TestLoadBalance.test_01_create_lb_rule_src_nat
> //Failure: SSH failed for VM
>o
>integration.smoke.test_loadbalance.TestLoadBalance.test_02_create_lb_rule_non_nat
> //Failure: SSH failed for VM
>o
>integration.smoke.test_loadbalance.TestLoadBalance.test_assign_and_removal_lb 
>//Failure: SSH failed for VM
>o:setup  // Failure: 
>Test Setup.  Asked if Miguel can put conditional code to skip the test; 
>assuming that this is passing in his Env.
>o
>integration.smoke.test_snapshots.TestSnapshotRootDisk.test_01_snapshot_root_disk
>  //Failure: Failed to create snapshot due to an internal error
>o
>integration.smoke.test_ssvm.TestSSVMs.test_08_reboot_cpvm
> //Failure: Root cause is TBD
>ointegration.smoke.test_ssvm.TestSSVMs.test_07_reboot_ssvm //Failure: Root 
>cause is TBD
>ointegration.smoke.test_internal_lb.TestInternalLb.test_internallb 
>//Failure: CloudStack-8697
>-end---

Re: new colleagues

[Remi Bergsma]

Congrats Dahn!




On 01/10/15 12:07, "Daan Hoogland"  wrote:

>Hello fellow stackers,
>
>This to let you know that I just entered the building of Leaseweb, in order
>to be working there for the next couple of years. You know them via Whei
>Zou, who will be my close colleague. I had a great time with Schuberg
>Philis as you might know and am confident the same will happen here. I will
>continue to use personal email addresses so I want to let you this way that
>my motivation has changed ever so slightly.
>
>I didn't plan to go to Dublin yet, but as Makesh my new colleague
>threatened to mention me in his session [1], I will try to be there for
>damage control.
>
>[1] http://sched.co/44T2
>
>​hoping to contribute a lot more,​
>-- 
>Daan

Re: VR refactoring, concerns and a way out ?

[Remi Bergsma]

Hi Abhi,

Currently we run BVT tests and whatever doesn’t yet work we create a blocker 
for. The challenge is to make sure when we fix one thing, we do not 
unintentionally break something else leading to a new blocker. That’s why we do 
a lot of testing on the PRs fixing blockers, so we keep things working and 
reach a point where we can cut a release. It slows things down, but not as much 
as reintroducing old bugs and starting all over.

We don’t need more administration. The list of blockers in Jira is clear and we 
know who works on them. It doesn’t matter to me who files them nor of what type 
they are.

Regards,
Remi



On 01/10/15 06:23, "Abhinandan Prateek"  
wrote:

> I can understand Citrix concern of some critical scenarios being missed. 
> Citrix supports several customers with sometimes weird setups requiring that 
> extra step in fixing and making the code that works in all those scenarios.
>
>The current code has been contributed by community, by people who just want to 
>see cloudstack become better. The code was contributed as per process and has 
>been there for more than 6 months, not including the time that this effort 
>took, which is over an year.
>
>Can someone from Citrix consolidate all the VR issues and consolidate those 
>under an umbrella ticket. As I can see the importance of those bugs is being 
>lost in this chatter. Will request Citrix to take that extra effort in 
>identifying the bugs, putting in enough details so that the use cases it 
>breaks are understood in the community. Then it is just a number game — how 
>many are squashed and how fast by the resilient community.
>
>-abhi
>
>
>> On 24-Sep-2015, at 9:06 pm, David Nalley  wrote:
>>
>> Everything else aside, do we really think that this could be backed
>> out cleanly? The initial merge should be easy to pull out, but 6
>> months of follow on work? There's no way that's coming out cleanly.
>>
>> --David
>>
>> On Thu, Sep 24, 2015 at 11:21 AM, Raja Pullela  
>> wrote:
>>> @wilder, Not sure why you would think it as a nonsense approach? sure, you 
>>> realize amount of code churn and blockers we are dealing with when 4.6 is 
>>> ready to go out.
>>>
>>> Agreed, the refactoring happened several months ago and we could have taken 
>>> a closer look then-   the recent blockers filed have uncovered areas where 
>>> in the implementation didn't exist.  I will post the bug details around 
>>> this.
>>>
>>> Obviously, the refactoring changes missed multiple critical test scenarios 
>>> and will take substantial time to test/stabilize.
>>>
>>> The BVTs are coming good for basic zone and Adv zone there are still a 
>>> number of failures and it will take us good time to get those fixed.
>>>
>>> Besides the BVTs, regression tests are in a very bad shape.  Hope to get to 
>>> these starting next week.
>>>
>>> Please see my latest bvt report, I will post in another 2 hrs, waiting for 
>>> a new run to complete.
>>>
>>>> On Sep 24, 2015, at 7:00 PM, sebgoa  wrote:
>>>>
>>>>
>>>>> On Sep 24, 2015, at 3:17 PM, Remi Bergsma  
>>>>> wrote:
>>>>>
>>>>> Are you serious? You consider to revert a PR that was merged over 6 
>>>>> months ago? And expect it to become more stable?
>>>>
>>>> I have not followed all the latest development, but if we are talking 
>>>> about the VR refactoring, indeed it happened several months back. 
>>>> Reverting it now does not seem like a good idea.
>>>>
>>>> I am probably missed a beat here, but the latest BVT results sent by Raja 
>>>> showed XS tests almost at 100%, there were only some issues with KVM.
>>>>
>>>>> The problem, in MHO, is not that we find bugs that we consider blockers. 
>>>>> The problem is we are unable to resolve them effectively because master 
>>>>> is unstable. There currently isn’t a single PR that solves it, hence 
>>>>> there is no way to test PRs. This is because we have many PRs open and 
>>>>> they were all branched off of a master that doesn’t work. I simply can't 
>>>>> test proposed PRs.
>>>>>
>>>>> This problem occurred about 3 weeks ago, because before that master 
>>>>> worked and we could solve issues and merge PRs. I’m not saying it was 
>>>>> bug-free, but at least we could work on stabilising it. Most likely, we 
>>>>> accepted a “fix” that made things worse. Probably

Re: 4.6 blockers

[Remi Bergsma]

Indeed, this was created over night and is also against 4.5
https://issues.apache.org/jira/browse/CLOUDSTACK-8920

We should not consider that a blocker, as I have done this many times without 
issues. Will comment and ask for more details.

Regards,
Remi




On 29/09/15 14:21, "Wilder Rodrigues"  wrote:

>Hi Sebastien,
>
>We are able to use ACS + KVM for a while and I have not faced such a problem 
>as described on CLOUDSTACK-8920  
>
>Just as a reminder, we have several tests executed agains KVM with ACS 4.6 on 
>Sunday… all went fine.
>
>Cheers,
>Wilder
>
>
>> On 29 Sep 2015, at 13:36, Sebastien Goasguen  wrote:
>> 
>> Just checking JIRA, we have 5 blockers for 4.6:
>> 
>> https://issues.apache.org/jira/browse/CLOUDSTACK-8920 - not assigned
>> KVM agent cannot communicate with server on port 8250
>> 
>> The other 4 are assigned and being worked on.
>> 
>> https://issues.apache.org/jira/browse/CLOUDSTACK-8915 - assigned to Wilder
>> https://issues.apache.org/jira/browse/CLOUDSTACK-8848 - assigned to Rene
>> https://issues.apache.org/jira/browse/CLOUDSTACK-8808 - assigned to Rajani
>> https://issues.apache.org/jira/browse/CLOUDSTACK-8697 - assigned to Wilder
>> 
>> 8920 is marked as affecting 4.5.2, should it also be 4.6.0 and should we 
>> have it as blockers.
>> 
>> -Boris from pcextreme tested master (4.6.0) yesterday in his KVM/basic zone 
>> setup and he reported no issues.
>> -Nux reported an issue during testing which might be due to the Jenkins jobs 
>> not having run for a week.
>> 
>> @Raja could you send us the latest BVT results with added details on failed 
>> tests ? that would give us a somewhat compete view of the current state of 
>> 4.6.
>> 
>> -Sebastien
>

Re: Blameless post mortem

[Remi Bergsma]

Dude, this is the final friendly email about his. All points have been made in 
previous mails. This has nothing to do with ‘blameless’ and ‘learning’ anymore.

Read Seb’s mail. We will move on now.


Regards, Remi



On 28/09/15 13:54, "Bharat Kumar"  wrote:

>Hi Remi,
>
>Whatever  ever we think  we have discovered are all well known best practices 
>while developing code in community. 
>I agree that tests need to be run on a new PR,  but i wonder why was this 
>ignored when merging the VR refactor code. Perhaps we will uncover some more 
>issues if we investigate this. I believe 
>one of the reasons for this is the complexity and incomplete nature of the vr 
>refactor change and failing to identify the areas which got effected. If we 
>had a good documentation i think we cloud have understood the areas that were 
>getting 
>impacted early on, areas like the vpn ,  iptables, isolated networks rvr   etc 
> and run the relevant tests. The documentation will also help us focus on 
>these areas while reviewing  and fixing subsequent issues. Currently no one 
>knows the areas that got effected 
>due to the vr refactor change, we are seeing issues all over the code.  I 
>think this is a bigger problem than what we have discussed so far.
>
>I think presently we should stop fixing all the vr refactoring  bugs until we 
>come up with a  proper document describing the VR refactoring  changes.
>
>I am not suggesting that we should revert the vr refactor code, I am willing 
>to work on this and fix the issues,  I am only asking if we can get some 
>documentation.
>
>
>Regards,
>Bharat.
>
>On 28-Sep-2015, at 4:59 pm, Sebastien Goasguen  wrote:
>
>> 
>>> On Sep 28, 2015, at 1:14 PM, Remi Bergsma  
>>> wrote:
>>> 
>>> Hi Bharat,
>>> 
>>> 
>>> There is only one way to prove a feature works: with tests. That’s why I 
>>> say actually _running_ the tests we have today on any new PR, is the most 
>>> important thing. Having no documentation is a problem, I agree, but it is 
>>> not more important IMHO. If we had the documentation, we still would have 
>>> issues if nobody runs the tests and verifies pull requests. Documentation 
>>> that is perfect does not automatically lead to perfect implementation. So 
>>> we need tests to verify.
>>> 
>>> If we don’t agree that is also fine. We need to do both anyway and I think 
>>> we do agree on that.
>>> 
>> 
>> Also we need to move forward. We should have a live chat once 4.6 is out to 
>> discuss all issues/problems and iron out the process.
>> 
>> But reverting the VR refactor is not going to happen. There was ample 
>> discussions on the PR when it was submitted, there was time to review and 
>> raise concerns at that time. It went through quite a few reviews, tests 
>> etc…Maybe the documentation is not good, but the time to raise this concern 
>> I am afraid was six months ago. We can learn from it, but we are not going 
>> to revert it, this would not go cleanly as David mentioned.
>> 
>> So let’s get back to blockers for 4.6, are there still VR related issues 
>> with master ?
>> 
>> 
>> 
>> 
>>> Regards,
>>> Remi
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 28/09/15 12:15, "Bharat Kumar"  wrote:
>>> 
>>>> Hi Remi,
>>>> 
>>>> i do not agree with “There is no bigger problem”  part of your reply. so I 
>>>> had to repeat myself to make it more clear, Not because i am not aware of 
>>>> what this thread is supposed to do.
>>>> 
>>>> Regards,
>>>> Bharat.
>>>> 
>>>> On 28-Sep-2015, at 2:51 pm, Remi Bergsma  
>>>> wrote:
>>>> 
>>>>> Hi Bharat,
>>>>> 
>>>>> I understand your frustrations but we already agreed on this so no need 
>>>>> to repeat. This thread is supposed to list some improvements and learn 
>>>>> from it. Your point has been taken so let’s move on.
>>>>> 
>>>>> We need documentation first, then do a change after which all tests 
>>>>> should pass. Even better is we write (missing) tests before changing 
>>>>> stuff so you know they pass before and after the fact. 
>>>>> 
>>>>> When doing reviews, feel free to ask for design documentation if you feel 
>>>>> it is needed.
>>>>> 
>>>>> Regards, Remi
>>>>> 
>>>>> 
>>>>> 
>>

Re: Blameless post mortem

[Remi Bergsma]

+1

There are two VR related issues left:
- CLOUDSTACK-8697: Assign VPC Internal LB rule to a VM fails
- CLOUDSTACK-8915: Cannot SSH into VMs deployed Redundant VPC routers

The first one has been tested today and seems still present. The second we 
discovered this weekend while testing. It was broken by a recent PR and we’ll 
try to fix it and prove with tests that everything still works. Wilder and I 
will focus on these issues.

As for the other blockers, I believe Rajani works on CLOUDSTACK-8808 and René 
has sent a PR for CLOUDSTACK-8848.

Regards, Remi





On 28/09/15 13:29, "Sebastien Goasguen"  wrote:

>
>> On Sep 28, 2015, at 1:14 PM, Remi Bergsma  
>> wrote:
>> 
>> Hi Bharat,
>> 
>> 
>> There is only one way to prove a feature works: with tests. That’s why I say 
>> actually _running_ the tests we have today on any new PR, is the most 
>> important thing. Having no documentation is a problem, I agree, but it is 
>> not more important IMHO. If we had the documentation, we still would have 
>> issues if nobody runs the tests and verifies pull requests. Documentation 
>> that is perfect does not automatically lead to perfect implementation. So we 
>> need tests to verify.
>> 
>> If we don’t agree that is also fine. We need to do both anyway and I think 
>> we do agree on that.
>> 
>
>Also we need to move forward. We should have a live chat once 4.6 is out to 
>discuss all issues/problems and iron out the process.
>
>But reverting the VR refactor is not going to happen. There was ample 
>discussions on the PR when it was submitted, there was time to review and 
>raise concerns at that time. It went through quite a few reviews, tests 
>etc…Maybe the documentation is not good, but the time to raise this concern I 
>am afraid was six months ago. We can learn from it, but we are not going to 
>revert it, this would not go cleanly as David mentioned.
>
>So let’s get back to blockers for 4.6, are there still VR related issues with 
>master ?
>
>
>
>
>> Regards,
>> Remi
>> 
>> 
>> 
>> 
>> 
>> 
>> On 28/09/15 12:15, "Bharat Kumar"  wrote:
>> 
>>> Hi Remi,
>>> 
>>> i do not agree with “There is no bigger problem”  part of your reply. so I 
>>> had to repeat myself to make it more clear, Not because i am not aware of 
>>> what this thread is supposed to do.
>>> 
>>> Regards,
>>> Bharat.
>>> 
>>> On 28-Sep-2015, at 2:51 pm, Remi Bergsma  
>>> wrote:
>>> 
>>>> Hi Bharat,
>>>> 
>>>> I understand your frustrations but we already agreed on this so no need to 
>>>> repeat. This thread is supposed to list some improvements and learn from 
>>>> it. Your point has been taken so let’s move on.
>>>> 
>>>> We need documentation first, then do a change after which all tests should 
>>>> pass. Even better is we write (missing) tests before changing stuff so you 
>>>> know they pass before and after the fact. 
>>>> 
>>>> When doing reviews, feel free to ask for design documentation if you feel 
>>>> it is needed.
>>>> 
>>>> Regards, Remi
>>>> 
>>>> 
>>>> 
>>>> On 28/09/15 11:02, "Bharat Kumar"  wrote:
>>>> 
>>>>> Hi Remi,
>>>>> 
>>>>> I never intended to say that we should not run tests, but even before 
>>>>> tests we should have proper documentation. My concern was if a major 
>>>>> change is being introduced it should be properly documented. All the 
>>>>> issues which we are trying to fix are majorly due to VR refactor. If 
>>>>> there was a proper documentation for this we could
>>>>> have fixed this in a better way.  Even to add tests we need to understand 
>>>>> how a particular thing works and what data dose it expect. I think while 
>>>>> fixing the python based code changes this is where most of the people are 
>>>>> facing issues. A proper documentation will help in understanding these in 
>>>>> a better way.
>>>>> 
>>>>> Thanks,
>>>>> Bharat.
>>>>> 
>>>>> On 28-Sep-2015, at 1:57 pm, Remi Bergsma  
>>>>> wrote:
>>>>> 
>>>>>> Hi Bharat,
>>>>>> 
>>>>>> There is no bigger problem. We should always run the tests and if we 
>>>>>> find a case that isn’t currently covered by the tests we sho

Re: Blameless post mortem

[Remi Bergsma]

Hi Bharat,


There is only one way to prove a feature works: with tests. That’s why I say 
actually _running_ the tests we have today on any new PR, is the most important 
thing. Having no documentation is a problem, I agree, but it is not more 
important IMHO. If we had the documentation, we still would have issues if 
nobody runs the tests and verifies pull requests. Documentation that is perfect 
does not automatically lead to perfect implementation. So we need tests to 
verify.

If we don’t agree that is also fine. We need to do both anyway and I think we 
do agree on that.

Regards,
Remi






On 28/09/15 12:15, "Bharat Kumar"  wrote:

>Hi Remi,
>
> i do not agree with “There is no bigger problem”  part of your reply. so I 
> had to repeat myself to make it more clear, Not because i am not aware of 
> what this thread is supposed to do.
> 
>Regards,
>Bharat.
>
>On 28-Sep-2015, at 2:51 pm, Remi Bergsma  wrote:
>
>> Hi Bharat,
>> 
>> I understand your frustrations but we already agreed on this so no need to 
>> repeat. This thread is supposed to list some improvements and learn from it. 
>> Your point has been taken so let’s move on.
>> 
>> We need documentation first, then do a change after which all tests should 
>> pass. Even better is we write (missing) tests before changing stuff so you 
>> know they pass before and after the fact. 
>> 
>> When doing reviews, feel free to ask for design documentation if you feel it 
>> is needed.
>> 
>> Regards, Remi
>> 
>> 
>> 
>> On 28/09/15 11:02, "Bharat Kumar"  wrote:
>> 
>>> Hi Remi,
>>> 
>>> I never intended to say that we should not run tests, but even before tests 
>>> we should have proper documentation. My concern was if a major change is 
>>> being introduced it should be properly documented. All the issues which we 
>>> are trying to fix are majorly due to VR refactor. If there was a proper 
>>> documentation for this we could
>>> have fixed this in a better way.  Even to add tests we need to understand 
>>> how a particular thing works and what data dose it expect. I think while 
>>> fixing the python based code changes this is where most of the people are 
>>> facing issues. A proper documentation will help in understanding these in a 
>>> better way.
>>> 
>>> Thanks,
>>> Bharat.
>>> 
>>> On 28-Sep-2015, at 1:57 pm, Remi Bergsma  
>>> wrote:
>>> 
>>>> Hi Bharat,
>>>> 
>>>> There is no bigger problem. We should always run the tests and if we find 
>>>> a case that isn’t currently covered by the tests we should simply add 
>>>> tests for it. There’s no way we’ll get a stable master without them. The 
>>>> fact that they may not cover everything, is no reason to not rely on them. 
>>>> If a feature is not important enough to write a test for, then the feature 
>>>> is probably not important anyway. And if it is, then add a test :-)
>>>> 
>>>> I do agree on the design documentation requirement for any (major?) 
>>>> change. I found some design documentations on the subject you mention, but 
>>>> it should have been more detailed. 
>>>> 
>>>> Regards,
>>>> Remi
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 28/09/15 09:58, "Bharat Kumar"  wrote:
>>>> 
>>>>> Hi Remi,
>>>>> 
>>>>> Thank you for the Blame less postmortem. 
>>>>> 
>>>>> I think there is a bigger problem here than just the review process and 
>>>>> running tests. Even if we run the tests we cannot be sure that every 
>>>>> thing will work as intended. The tests will only give some level of 
>>>>> confidence. The tests may not cover all the use cases.
>>>>> 
>>>>> I think the problem here is that the way major changes to the code base 
>>>>> are dealt with. For example,  VR refactoring was done without discussing 
>>>>> the design implications and the amount of changes it would bring in. I 
>>>>> could not find any design document. The vr refactor changed a lot of code 
>>>>> and the way VR used to work and in my opinion it was incomplete-vpn, 
>>>>> isolated networks, basic networks, iptable rules and rvr in isolated case 
>>>>> etc were not implemented. Most of us are still in the process of 
>>>>> understanding this. Even before 

Re: Blameless post mortem

[Remi Bergsma]

Hi Bharat,

I understand your frustrations but we already agreed on this so no need to 
repeat. This thread is supposed to list some improvements and learn from it. 
Your point has been taken so let’s move on.

We need documentation first, then do a change after which all tests should 
pass. Even better is we write (missing) tests before changing stuff so you know 
they pass before and after the fact. 

When doing reviews, feel free to ask for design documentation if you feel it is 
needed.

Regards, Remi



On 28/09/15 11:02, "Bharat Kumar"  wrote:

>Hi Remi,
>
>I never intended to say that we should not run tests, but even before tests we 
>should have proper documentation. My concern was if a major change is being 
>introduced it should be properly documented. All the issues which we are 
>trying to fix are majorly due to VR refactor. If there was a proper 
>documentation for this we could
>have fixed this in a better way.  Even to add tests we need to understand how 
>a particular thing works and what data dose it expect. I think while fixing 
>the python based code changes this is where most of the people are facing 
>issues. A proper documentation will help in understanding these in a better 
>way.
>
>Thanks,
>Bharat.
>
>On 28-Sep-2015, at 1:57 pm, Remi Bergsma  wrote:
>
>> Hi Bharat,
>> 
>> There is no bigger problem. We should always run the tests and if we find a 
>> case that isn’t currently covered by the tests we should simply add tests 
>> for it. There’s no way we’ll get a stable master without them. The fact that 
>> they may not cover everything, is no reason to not rely on them. If a 
>> feature is not important enough to write a test for, then the feature is 
>> probably not important anyway. And if it is, then add a test :-)
>> 
>> I do agree on the design documentation requirement for any (major?) change. 
>> I found some design documentations on the subject you mention, but it should 
>> have been more detailed. 
>> 
>> Regards,
>> Remi
>> 
>> 
>> 
>> 
>> 
>> 
>> On 28/09/15 09:58, "Bharat Kumar"  wrote:
>> 
>>> Hi Remi,
>>> 
>>> Thank you for the Blame less postmortem. 
>>> 
>>> I think there is a bigger problem here than just the review process and 
>>> running tests. Even if we run the tests we cannot be sure that every thing 
>>> will work as intended. The tests will only give some level of confidence. 
>>> The tests may not cover all the use cases.
>>> 
>>> I think the problem here is that the way major changes to the code base are 
>>> dealt with. For example,  VR refactoring was done without discussing the 
>>> design implications and the amount of changes it would bring in. I could 
>>> not find any design document. The vr refactor changed a lot of code and the 
>>> way VR used to work and in my opinion it was incomplete-vpn, isolated 
>>> networks, basic networks, iptable rules and rvr in isolated case etc were 
>>> not implemented. Most of us are still in the process of understanding this. 
>>> Even before reaching this state we had to spend a lot of time fixing issues 
>>> mentioned in the thread [Blocker/Critical] VR related Issues.  
>>> 
>>> When a change of this magnitude is being made, we should call out all the 
>>> changes and document them properly. This will help people to create better 
>>> fixes. Currently when we attempt to fix the isolated vr case it is 
>>> effecting the vpc and vice versa. for example pr 738 fixed it for vpc 
>>> networks but broke it for isolated case. I believe it is not too late to at 
>>> least start documenting the changes now.
>>> 
>>> Thanks,
>>> Bharat.
>>> 
>>> On 28-Sep-2015, at 10:52 am, Sanjeev N  wrote:
>>> 
>>>> I have a concern here. Some of us are actively involved in reviewing the
>>>> PRs related to marvin tests(Enhancing existing tests/Adding new tests). If
>>>> we have to test a PR it requires an environment to be created with actual
>>>> resources and this is going to take lot of time. Some of the tests can run
>>>> on simulator but most of the tests require real hardware to test. PR
>>>> submitter is already testing and submitting the test results along with the
>>>> PR. So is it require to test these PRs by reviewers?
>>>> 
>>>> On Sat, Sep 26, 2015 at 1:49 PM, sebgoa  wrote:
>>>> 
>>>>> Remi, thanks for the detailed post-mortem, it's a good read and great
>>>>> learning.
>>>

Re: Blameless post mortem

[Remi Bergsma]

Hi Bharat,

There is no bigger problem. We should always run the tests and if we find a 
case that isn’t currently covered by the tests we should simply add tests for 
it. There’s no way we’ll get a stable master without them. The fact that they 
may not cover everything, is no reason to not rely on them. If a feature is not 
important enough to write a test for, then the feature is probably not 
important anyway. And if it is, then add a test :-)

I do agree on the design documentation requirement for any (major?) change. I 
found some design documentations on the subject you mention, but it should have 
been more detailed. 

Regards,
Remi






On 28/09/15 09:58, "Bharat Kumar"  wrote:

>Hi Remi,
>
>Thank you for the Blame less postmortem. 
>
>I think there is a bigger problem here than just the review process and 
>running tests. Even if we run the tests we cannot be sure that every thing 
>will work as intended. The tests will only give some level of confidence. The 
>tests may not cover all the use cases.
>
>I think the problem here is that the way major changes to the code base are 
>dealt with. For example,  VR refactoring was done without discussing the 
>design implications and the amount of changes it would bring in. I could not 
>find any design document. The vr refactor changed a lot of code and the way VR 
>used to work and in my opinion it was incomplete-vpn, isolated networks, basic 
>networks, iptable rules and rvr in isolated case etc were not implemented. 
>Most of us are still in the process of understanding this. Even before 
>reaching this state we had to spend a lot of time fixing issues mentioned in 
>the thread [Blocker/Critical] VR related Issues.  
>
>When a change of this magnitude is being made, we should call out all the 
>changes and document them properly. This will help people to create better 
>fixes. Currently when we attempt to fix the isolated vr case it is effecting 
>the vpc and vice versa. for example pr 738 fixed it for vpc networks but broke 
>it for isolated case. I believe it is not too late to at least start 
>documenting the changes now.
>
>Thanks,
>Bharat.
>
>On 28-Sep-2015, at 10:52 am, Sanjeev N  wrote:
>
>> I have a concern here. Some of us are actively involved in reviewing the
>> PRs related to marvin tests(Enhancing existing tests/Adding new tests). If
>> we have to test a PR it requires an environment to be created with actual
>> resources and this is going to take lot of time. Some of the tests can run
>> on simulator but most of the tests require real hardware to test. PR
>> submitter is already testing and submitting the test results along with the
>> PR. So is it require to test these PRs by reviewers?
>> 
>> On Sat, Sep 26, 2015 at 1:49 PM, sebgoa  wrote:
>> 
>>> Remi, thanks for the detailed post-mortem, it's a good read and great
>>> learning.
>>> I hope everyone reads it.
>>> 
>>> The one thing to emphasize is that we now have a very visible way to get
>>> code into master, we have folks investing time to provide review (great),
>>> we need the submitters to make due diligence and answer all comments in the
>>> reviews.
>>> 
>>> In another project i work on, nothing can be added to the code without
>>> unit tests. I think we could go down the route of asking for new
>>> integration tests and unit tests for anything. If not, the PR does not get
>>> merged. But let's digest your post-mortem and we can discuss after 4.6.0.
>>> 
>>> I see that you reverted one commit that was not made by you, that's great.
>>> 
>>> Let's focus on the blockers now, everything else can wait.
>>> 
>>> The big bonus of doing what we are doing is that once 4.6.0 is out, we can
>>> merge PRs again (assuming they are properly rebased and tested) and we can
>>> release 4.6.1 really quickly after.
>>> 
>>> -sebastien
>>> 
>>> On Sep 25, 2015, at 9:51 PM, Remi Bergsma 
>>> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> This mail is intended to be blameless. We need to learn something from
>>> it. That's why I left out who exactly did what because it’s not relevant.
>>> There are multiple examples but it's about the why. Let's learn from this
>>> without blaming anyone.
>>>> 
>>>> We know we need automated testing. We have integration tests, but we are
>>> unable to run all of them on any Pull Request we receive. If we would have
>>> that in place, it'd be much easier to spot errors, regression and so on.
>>> It'd also be more reward

Re: [j.bac.o] Jenkins jobs cleanup

[Remi Bergsma]

4.3 remove is fine with me. 

Sent from my iPhone

> On 27 Sep 2015, at 16:39, Pierre-Luc Dion  wrote:
> 
> Hi,
> 
> We recently ran out of space on jenkins master of j.bac.o [1]. Does anyone
> would object if we removed all jobs for 4.3 builds ? I did some build jobs
> for 4.6, I'll remove them as it look like we are using master for 4.6
> builds for now.
> 
> Any other suggestions?
> 
> Thanks,
> 
> [1] http://markmail.org/message/zxb3khnxrrkazmpq

Blameless post mortem

[Remi Bergsma]

Hi all,

This mail is intended to be blameless. We need to learn something from it. 
That's why I left out who exactly did what because it’s not relevant. There are 
multiple examples but it's about the why. Let's learn from this without blaming 
anyone.

We know we need automated testing. We have integration tests, but we are unable 
to run all of them on any Pull Request we receive. If we would have that in 
place, it'd be much easier to spot errors, regression and so on. It'd also be 
more rewarding to write more tests.

Unfortunately we're not there yet. So, we need to do something else instead 
until we get there. If we do nothing, we know we have many issues because a 
master that breaks on a regular basis is the most frustrating things. We said 
we'd use Pull Requests with at least two humans to review and give their OK for 
a Pull Request. In the form of LGTM: Looks Good To Me. Ok, so the LGTMs are 
there because we have no automated testing. Keep that in mind. You are supposed 
to replace automated testing until it's there.

Since we do this, master got a lot more stable. But every now and then we still 
have issues. Let's look at how we do manual reviews. Again, this is not to 
blame anyone. It's to open our eyes and make us realise what we're doing and 
what results we get out of that.


Example Pull Request #784: 
Title: CLOUDSTACK-8799 fixed the default routes

That's nice, it has a Jira id and a short description (as it should be).

The first person comes along and makes a comment:
"There was also an issue with VPC VRs" ... "Have you seen this issue? Does your 
change affects the VPC VR (single/redundant)?"

Actually a good question. Unfortunaly there comes no answer. After a reminder, 
it was promised to do tests against VPC networks. Great!

The Jenkins builds both succeed and also Travis is green. But how much value 
does this have? They have the impression to do automated testing, and although 
you could argue they do, it's far from complete. If it breaks, you know you 
have an issue. But it doesn’t work the other way around.

Back to our example PR. In the mean time, another commit gets pushed to it: 
"CLOUDSTACK-8799 fixed for vpc networks." But if you look at the Jira issue, 
you see it is about redundant virtual routers. The non-VPC ones. So this is 
vague at best. But a reviewer gives a LGTM because the person could create a 
VPC. That doesn't have anything to do with the problem being fixed in this PR 
nor with the comments made earlier. But, at least the person said what he did 
and we should all do that. What nobody knew back then, was that this broke the 
default route on VPCs.

Then something strange happens: the two commits from the PR end up on master as 
direct commits. With just one LGTM and no verification from the person 
commenting about the linked issue. This happened on Friday September 11th. 

That day 21 commits came in, from 7 Pull Request and unfortunately also from 
some direct commits. We noticed the direct commits and notified the list 
(http://cloudstack.markmail.org/message/srmszloyipkxml36). As a lot came in at 
the same time, it was decided not to revert them. Looking back, we should have 
done it.

From this point on, VPCs were broken as they wouldn't get a default route. So, 
no public internet access from VMs in VPC tiers, no VPNs working, etc. This was 
mentioned to the list on Thursday September 15th, after some chats and 
debugging going on over the weekend 
(http://cloudstack.markmail.org/message/73ulpu4p75ex24tc)

Here we are, master is broken functionality wise and new Pull Requests come in 
to fix blockers. But we cannot ever test their proper working, because VPCs are 
broken in master and so also in the PRs branched off of it. With or without 
change in the PR. 

It starts to escalate as the days go by.

I’ll leave out the bit on how this frustrated people. Although it’s good to 
know we do not want to be in this situation.

Eventually Wilder and I spent an evening and a day working on a branch where we 
loaded 7 PRs on top of each other (all VR related) only to find the VPC is 
still broken. It allowed us to zoom in and find the default route was missing 
again. We said it worked 3 weeks before, because the same tests that succeeded 
then, now were broken. We had already fixed this in PR #738 on August 25 so 
were sure about it.

After some digging we could trace it back to Pull Request #784. Imagine the 
feeling seeing your own comment there mentioning the previous issue on the 
default gateways. Fair to say our human review process clearly failed here. 
Many many hours were spent on this problem over the past two weeks. Could we 
have prevented this from happening? I think so, yes.


This example clearly shows why:

- we should use Pull Requests
  It made the change visible: Great!

- we do reviews and ask for feedback
  We got feedback and questions: Also great!

- we should always respond to feedback and verify it is resolved, before merging

Re: BVT report 9/23

[Remi Bergsma]

Hi Raja,

Thanks for the report. Can you please add details, so we can see what tests 
exactly fail? We can then try to reproduce / root cause. 

Regards, Remi 

> On 24 Sep 2015, at 21:09, Raja Pullela  wrote:
> 
> BVT report 09/23
> 
> simulator basic - 30% , earlier runs had 100% pass rate, failures need to be 
> analyzed 
> Simulator adv - 50%, earlier runs had 100% pass rate, failures need to be 
> analyzed 
> XS basic - 95.3% 
> XS Adv - 93.6% 
> XS eip - 86.7%
> KVM basic - 89.4%
> KVM Adv - Deployment issue, need to check and will update 
> KVM eip - 95.7% 
> VMware Adv - deployment issue, need to check and update 
> 
> 

Re: VR refactoring, concerns and a way out ?

[Remi Bergsma]

Are you serious? You consider to revert a PR that was merged over 6 months ago? 
And expect it to become more stable?

The problem, in MHO, is not that we find bugs that we consider blockers. The 
problem is we are unable to resolve them effectively because master is 
unstable. There currently isn’t a single PR that solves it, hence there is no 
way to test PRs. This is because we have many PRs open and they were all 
branched off of a master that doesn’t work. I simply can't test proposed PRs. 

This problem occurred about 3 weeks ago, because before that master worked and 
we could solve issues and merge PRs. I’m not saying it was bug-free, but at 
least we could work on stabilising it. Most likely, we accepted a “fix” that 
made things worse. Probably even multiple of them.

To get out of this, I think we need to combine a few PRs that make it stable. 
I’ll have a look today with Wilder and Funs to see if what fixes we need to 
combine to make it work again. Once we merge it and master actually works 
again, we can rebase any open PR with current master and work from there.

Regards,
Remi




On 24/09/15 14:00, "Ramanath Katru"  wrote:

>My vote is for the approach no.1 - to backout completely. Most of VR 
>functionalities are broken and are in a mess to say the least. It definitely 
>will take some time and effort from several folks to get it to a stable state.
>
>Ram Katru
>
>
>-Original Message-
>From: Raja Pullela [mailto:raja.pull...@citrix.com] 
>Sent: Thursday, September 24, 2015 2:06 PM
>To: dev@cloudstack.apache.org
>Subject: VR refactoring, concerns and a way out ? 
>
>Hi,
>
>
>
>I understand a concern on the VR changes was raised earlier.  My apologies to 
>restart this thread again.
>
>
>
>However, my last conversation with Jayapal, who has fixed/have been fixing lot 
>of VR issues, about the VR issues and he is pretty concerned about the 
>refactoring that has happened.  I have had the same concern for sometime now  
>(VR issues have been on the list of issues to be looked into for at least 4+ 
>weeks) and wanted to see a good solution for this- with VR being very 
>fundamental to the system.
>
>
>
>Couple of solutions/proposals –
>
>1)  Back out the VR changes – Pros: VR has been stable for some time and 
>it is working well.
>
>2)  Continue to fix/stability VR changes -   Concerns: is the unknowns, 
>what we will find out and how long this will take to stabilize the VR 
>functionality.
>
>
>
>Please chime in if you have any thoughts or concerns around this,
>
>
>
>best,
>
>Raja

Re: BVT report - 9/21

[Remi Bergsma]

Thanks for the report!

It’d really help if people would prepend their PR with ‘[BLOCKER]’ (like Boris 
did) so we can identify them and make sure they get the right attention.

@Wilder shall we share the load a bit more here and ask other to help with the 
issues currently assigned to you?

Also, master still seems broken virtual router wise, so any PRs out there might 
also have issues that weren’t introduced by the PR per se. That makes it extra 
hard to test / verify. Once these blocker issues are resolved, we might be able 
to rebase the remaining PRs and work from there.

Regards,
Remi





On 21/09/15 07:29, "Raja Pullela"  wrote:

>BVT report - 9/21
>XS Basic - 98.5%, 1 tests failed, test_01_test_vm_volume_snapshot
>XS Adv - 81.9%, 20 tests failed,
>XS EIP - 98.4%, 1 tests failed, test_01_test_vm_volume_snapshot
>KVM Basic - Deployment failure/due to bug, CLOUDSTACK-8883
>KVM Adv - Deployment failure/due to bug, CLOUDSTACK-8883
>KVM EIP - Deployment failure/due to bug, CLOUDSTACK-8883
>
>Blocker Bugs -
>Yet to be picked up
>
>-  CloudStack-8789 /BVT Impact
>
>-  CloudStack-8881 /BVT Impact
>
>-  CloudStack-8848
>
>-  CloudStack-8808
>
>Pending Resolution
>
>-  CloudStack-8883 /Boris
>
>-  CloudStack-8843 /Jayapal/Coded and ready for LGTM, latest BVT 
>result is based on this commit.
>
>-  CloudStack-8795 /Wilder
>
>-  CloudStack-8878 /Wilder
>
>-  CloudStack-8697 /Wilder
>
>BVTs failing:
>integration.smoke.test_internal_lb.TestInternalLb.test_internallb
>
>integration.smoke.test_loadbalance.TestLoadBalance.test_01_create_lb_rule_src_nat
>
>integration.smoke.test_loadbalance.TestLoadBalance.test_02_create_lb_rule_non_nat
>
>integration.smoke.test_loadbalance.TestLoadBalance.test_assign_and_removal_lb
>
>integration.smoke.test_network.TestPortForwarding.test_01_port_fwd_on_src_nat
>
>integration.smoke.test_network.TestPortForwarding.test_02_port_fwd_on_non_src_nat
>
>integration.smoke.test_network.TestRebootRouter.test_reboot_router
>
>integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_1_static_nat_rule
>
>integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_2_nat_rule
>
>integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_3_Load_Balancer_Rule
>
>integration.smoke.test_network_acl.TestNetworkACL.test_network_acl
>
>integration.smoke.test_nic.TestNic.test_01_nic
>
>integration.smoke.test_over_provisioning.TestUpdateOverProvision.test_UpdateStorageOverProvisioningFactor
>
>integration.smoke.test_scale_vm.TestScaleVm.test_01_scale_vm
>
>integration.smoke.test_service_offerings.TestServiceOfferings.test_04_change_offering_small
>
>integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_08_migrate_vm
>
>integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso
>
>integration.smoke.test_vm_snapshots.TestSnapshots.test_01_test_vm_volume_snapshot
>
>integration.smoke.test_vm_snapshots.TestVmSnapshot.test_01_create_vm_snapshots
>
>integration.smoke.test_vm_snapshots.TestVmSnapshot.test_02_revert_vm_snapshots
>
>integration.smoke.test_vm_snapshots.TestVmSnapshot.test_03_delete_vm_snapshots
>
>integration.smoke.test_volumes.TestCreateVolume.test_01_create_volume
>
>integration.smoke.test_vpc_vpn.TestVpcRemoteAccessVpn.test_vpc_remote_access_vpn
>
>

Re: Proposal to get to 100% passrate on BVTs

[Remi Bergsma]

Hi Raja,

Let’s think of a way to get the BVT score on any PR that is opened. Then we 
know if there’s a problem introduced in a PR before merge, instead of after. We 
need to automate this, or else we keep having the same issues. 

We can meet online somewhere next week to discuss our approach?

I like setting a date, but it needs to be realistic. We’re not going to solve 
all blockers by just saying it should be resolved next week. Many people need 
to step in and each fix one blocker or else it will take much longer. And it’s 
not only fixing blockers, but also testing them once a PR is there. Testing 
means building a CloudStack setup, verifying the problem is gone, etc.

Regards,
Remi




On 18/09/15 13:55, "Raja Pullela"  wrote:

>Hi,
>
>We have been having steady rate of blocker issues/breakages.  I am proposing 
>to see if we can get to a 100% passrate on BVTs by next Friday, Sep 25th or 
>sooner.
>
>Once we reach 100% passrate, we should closely monitor BVTs and back out 
>commits that we think have broken BVTs.
>I will report the BVTs passrate on a daily basis.  Also, working with Kishan 
>to see a way to make the data available online?
>
>Here is the latest status on the BVTs -
>XS Basic - 93% / 
>CLOUDSTACK-8843 (in the 
>process of testing Jayapal's fix),
>XS Adv - 81.8% / 
>CLOUDSTACK-8881, 
>CLOUDSTACK-8697
>
>KVM Basic - Deployment failure / 
>CLOUDSTACK-8883
>
>KVM Adv - Deployment failure / 
>CLOUDSTACK-8883, 
>CLOUDSTACK-8881, 
>CLOUDSTACK-8697
>
>BTW - currently, no one has picked up  
>CLOUDSTACK-8883 yet,
>
>best,
>Raja
>

Re: [PROPOSAL] stable master and 4.6 release

[Remi Bergsma]

If we all go for it, fix the blocker issues and test 4.6, then we should be 
able to do it! The CCCEU conference is in ~4 weeks, seems like a great deadline 
to work towards. But again, we all need to work together to make it happen.

Let’s not forget that making master stable is hard. Just as hard as it used to 
be in a release branch. Once we achieve a stable master, we need to keep it 
that wat which means we need to improve Travis and Jenkins so that at PR review 
time we get the right feedback from the automated systems. Until that is in 
place, we should be extra careful and show each other how things are tested and 
reviewed. Once master is stable and 4.6 is out, merging new features and 
prepping 4.7 should be a lot easier.

Let’s focus on 4.6 and make it a great release!

Regards,
Remi



From: Rohit Yadav
Reply-To: "dev@cloudstack.apache.org"
Date: Wednesday 16 September 2015 10:07
To: "dev@cloudstack.apache.org"
Subject: Re: [PROPOSAL] stable master and 4.6 release

Based on some discussion from slack, I think there is no harm in experimenting 
this for let’s say 2-4 weeks; at worst we would have blocked people from 
merging new features etc.

Remi/Rajani - do you think we can pull this off (fix blockers and do a 4.6.0 
release) in next 2-4 weeks?

On 16-Sep-2015, at 1:28 pm, Daan Hoogland 
mailto:daan.hoogl...@gmail.com>> wrote:

On Wed, Sep 16, 2015 at 9:38 AM, Rohit Yadav 
mailto:rohit.ya...@shapeblue.com>>
wrote:

1. Only BLOCKER fixes to master. If there's something else that needs to
get in, it can be discussed with the RMs on a case-by-case basis.


-1 -ish
What you’re effectively saying is to freeze/block master from new changes
until 4.6.0 releases which could take anywhere from one week to many weeks.
In reality that may be undesirable and can contribute to loss of developer
productivity time.

​agree and​



Few suggestions, though I’m not sure that best way to go forward: why not
create a 4.6 branch and merge it back when 4.6.0 releases? Alternatively,
create a development branch on which development can continue and we merge
it back to master when that branch is stable enough and 4.6.0 has released?

​I don't feel we should create a developer branch, branching 4.6.0 now and
fixing blockers there to merge them back to master as they are fixed seems
the way to go to me.
​



2. Atleast one of the reviewers of a PR should do the actual tests. We do
not have good CI in place and travis just does simulator tests.


+1 some of us talking in the background to setup an automated QA system to
use existing marvin tests to do long running integration tests but other
than Travis or Jenkins (b.a.o) we don’t have anything.

​I hate this but still +1​ (CI is/should be there so we don't need this)



--
Daan

Regards,
Rohit Yadav
Software Architect, ShapeBlue


[cid:9DD97B41-04C5-45F0-92A7-951F3E962F7A]


M. +91 88 262 30892 | 
rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab




Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

RE: Repo CS 4.5 for CentOS 7.x Missing

[Remi Bergsma]

Hi Wido,

PR 731's patch does not apply cleanly on 4.5 due to a conflict in 
LibvirtComputingResource.java. It doesn't look too complicated (just one 
conflict), but I'd rather have one of the Java gurus look at this. I just 
cherry-picked the commits to a new branch (branched off of 4.5).

757 does apply cleanly. Any time to look into it and resolve the conflict, then 
push a PR? I'd prefer sending all commits from both PRs in one new PR against 
4.5. They have the same goal anyway, and otherwise I'll have issues testing, as 
I'll hit the MariaDB bug again.

I can setup a test environment to verify it, once the PR is there.

Regards, Remi


-Original Message-
From: Wido den Hollander [mailto:w...@widodh.nl] 
Sent: zondag 13 september 2015 11:28
To: dev@cloudstack.apache.org
Subject: Re: Repo CS 4.5 for CentOS 7.x Missing



On 09/13/2015 10:47 AM, Remi Bergsma wrote:
> Hi,
> 
> The question is, is CentOS7 even supported on 4.5? The docs say it isn’t and 
> when we were voting for 4.5.2 (http://markmail.org/message/36vnwh4kiilhkunu) 
> I found some issues with CentOS 7. Regarding the KVM agent, that doesn’t work 
> properly on 4.5 (which is now fixed on master). You can usually manually work 
> around the issues, but it doesn’t work out-of-the box. If we want this, let’s 
> bring the changes to 4.5 and make a new release.
> 
> Also, MariaDB on CentOS 7 also has a problem. Or better, we made a query that 
> crashes it resulting in unable to finish loading the db. This also was fixed 
> on master, and not on 4.5 yet. This has recently been on the user@ list a few 
> times.
> 
> Looks like there is demand for CentOS7 support. But let’s then make 
> sure it actually works :-)
> 

Indeed!

> At least we need those PRs to be back ported to 4.5 (and then test it):
> 
> https://github.com/apache/cloudstack/pull/731
> https://github.com/apache/cloudstack/pull/757
> 

True. The MariaDB fix seems fine with me, but we need #731 as well.

I'm however a Ubuntu guy, so I don't know that much about CentOS and testing :)

Wido

> Regards,
> Remi
> 
> 
> 
> 
> On 13/09/15 09:25, "Keerthiraja SJ"  wrote:
> 
>> When will the 7.x rpm's will get uploaded.
>>
>>
>>
>> On Sun, Sep 13, 2015 at 6:12 AM, Pierre-Luc Dion  wrote:
>>
>>> There is one:  http://jenkins.buildacloud.org/view/build-release/  
>>> but the job is failing, I'm still not sure if it's the jenkins slave the 
>>> problem.
>>>
>>>
>>> PL
>>>
>>>
>>> On Sat, Sep 12, 2015 at 5:20 PM, Wido den Hollander 
>>> wrote:
>>>
>>>> I don't see a Jenkins job for CentOs 7. Do we even have one?
>>>>
>>>>
>>>>
>>>>> Op 12 sep. 2015 om 19:29 heeft Keerthiraja SJ 
>>>>> 
>>> het
>>>> volgende geschreven:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I could see there is no packages under the directory.
>>>>>
>>>>> http://cloudstack.apt-get.eu/rhel/7/4.5/
>>>>>
>>>>> During the instillation of CS 4.5.2 on CentOS 7.x I could see 
>>>>> while pointing the repo from 
>>>>> http://cloudstack.apt-get.eu/rhel/7/4.5/ to 
>>>>> http://cloudstack.apt-get.eu/rhel/4.5/
>>>>>
>>>>> ---> Package xml-commons-resolver.noarch 0:1.2-15.el7 will be 
>>>>> ---> installed
>>>>> --> Finished Dependency Resolution
>>>>> Error: Package: cloudstack-common-4.5.2-1.el6.x86_64 (cloudstack)
>>>>>   Requires: python(abi) = 2.6
>>>>>   Installed: python-2.7.5-18.el7_1.1.x86_64 (@updates)
>>>>>   python(abi) = 2.7
>>>>>   python(abi) = 2.7
>>>>>   Available: python-2.7.5-16.el7.x86_64 (base)
>>>>>   python(abi) = 2.7
>>>>>   python(abi) = 2.7
>>>>> Error: Package: cloudstack-management-4.5.2-1.el6.x86_64 (cloudstack)
>>>>>   Requires: tomcat6
>>>>> You could try using --skip-broken to work around the problem You 
>>>>> could try running: rpm -Va --nofiles --nodigest
>>>>>
>>>>>
>>>>> So kindly update the Cloudstack 4.5.2 for the 7 Version.
>>>>>
>>>>> Thanks,
>>>>> Keerthi
>>>>
>>>

Re: Repo CS 4.5 for CentOS 7.x Missing

[Remi Bergsma]

Hi,

The question is, is CentOS7 even supported on 4.5? The docs say it isn’t and 
when we were voting for 4.5.2 (http://markmail.org/message/36vnwh4kiilhkunu) I 
found some issues with CentOS 7. Regarding the KVM agent, that doesn’t work 
properly on 4.5 (which is now fixed on master). You can usually manually work 
around the issues, but it doesn’t work out-of-the box. If we want this, let’s 
bring the changes to 4.5 and make a new release.

Also, MariaDB on CentOS 7 also has a problem. Or better, we made a query that 
crashes it resulting in unable to finish loading the db. This also was fixed on 
master, and not on 4.5 yet. This has recently been on the user@ list a few 
times.

Looks like there is demand for CentOS7 support. But let’s then make sure it 
actually works :-)

At least we need those PRs to be back ported to 4.5 (and then test it):

https://github.com/apache/cloudstack/pull/731
https://github.com/apache/cloudstack/pull/757

Regards,
Remi




On 13/09/15 09:25, "Keerthiraja SJ"  wrote:

>When will the 7.x rpm's will get uploaded.
>
>
>
>On Sun, Sep 13, 2015 at 6:12 AM, Pierre-Luc Dion  wrote:
>
>> There is one:  http://jenkins.buildacloud.org/view/build-release/  but the
>> job is failing, I'm still not sure if it's the jenkins slave the problem.
>>
>>
>> PL
>>
>>
>> On Sat, Sep 12, 2015 at 5:20 PM, Wido den Hollander 
>> wrote:
>>
>> > I don't see a Jenkins job for CentOs 7. Do we even have one?
>> >
>> >
>> >
>> > > Op 12 sep. 2015 om 19:29 heeft Keerthiraja SJ 
>> het
>> > volgende geschreven:
>> > >
>> > > Hi All,
>> > >
>> > > I could see there is no packages under the directory.
>> > >
>> > > http://cloudstack.apt-get.eu/rhel/7/4.5/
>> > >
>> > > During the instillation of CS 4.5.2 on CentOS 7.x I could see while
>> > > pointing the repo from http://cloudstack.apt-get.eu/rhel/7/4.5/ to
>> > > http://cloudstack.apt-get.eu/rhel/4.5/
>> > >
>> > > ---> Package xml-commons-resolver.noarch 0:1.2-15.el7 will be installed
>> > > --> Finished Dependency Resolution
>> > > Error: Package: cloudstack-common-4.5.2-1.el6.x86_64 (cloudstack)
>> > >   Requires: python(abi) = 2.6
>> > >   Installed: python-2.7.5-18.el7_1.1.x86_64 (@updates)
>> > >   python(abi) = 2.7
>> > >   python(abi) = 2.7
>> > >   Available: python-2.7.5-16.el7.x86_64 (base)
>> > >   python(abi) = 2.7
>> > >   python(abi) = 2.7
>> > > Error: Package: cloudstack-management-4.5.2-1.el6.x86_64 (cloudstack)
>> > >   Requires: tomcat6
>> > > You could try using --skip-broken to work around the problem
>> > > You could try running: rpm -Va --nofiles --nodigest
>> > >
>> > >
>> > > So kindly update the Cloudstack 4.5.2 for the 7 Version.
>> > >
>> > > Thanks,
>> > > Keerthi
>> >
>>

Re: No more direct commits to master please!

[Remi Bergsma]

Hi Wido,

Thanks, good to know. Will try to figure out what went wrong here.

Regards, Remi 


> On 11 Sep 2015, at 16:40, Wido den Hollander  wrote:
> 
> 
> 
>> On 11-09-15 16:26, Remi Bergsma wrote:
>> Hi all,
>> 
>> What happened to master? I see a lot of direct commits. I thought we agreed 
>> to make a PR, then _merge_ it to master with the script in 
>> ./tools/git/git-pr.
> 
> Errr, I used that script?
> 
> This is what my Bash history shows me:
> 
> wido@wido-desktop:~/repos/cloudstack$ history |grep git-pr
> 1752  ./tools/git/git-pr https://github.com/apache/cloudstack/pull/757
> 2013  ./tools/git/git-pr https://github.com/apache/cloudstack/pull/783
> 2025  ./tools/git/git-pr https://github.com/apache/cloudstack/pull/794
> 2027  ./tools/git/git-pr https://github.com/apache/cloudstack/pull/807
> 2029  ./tools/git/git-pr https://github.com/apache/cloudstack/pull/795
> 2030  ./tools/git/git-pr https://github.com/apache/cloudstack/pull/784
> 2043  history |grep git-pr
> wido@wido-desktop:~/repos/cloudstack$
> 
> They all had 2 LGTM, so I merged them.
> 
> Any idea what went wrong here?
> 
>> We’re getting ready for a 4.6 RC and this makes stuff extra hard to track. 
>> Most direct commits seem to come from PRs, but I don’t think all of them did.
>> 
>> Talking about this (there are more):
>> https://github.com/apache/cloudstack/commit/b66dcda49f370e6fc91ebff889a694f17826ca44
>> https://github.com/apache/cloudstack/commit/1c6378ec0056e8c75990a4a0c15e99b2df162a75
>> https://github.com/apache/cloudstack/commit/1a02773b556a0efa277cf18cd099fc62a4e27706
>> https://github.com/apache/cloudstack/commit/ba59a4b6f31e48e4b6e43e16068e4cacdc45
>> https://github.com/apache/cloudstack/commit/f661ac0a2a783447b6eaab590d58091ec542aec2
>> 
>> Please don’t make me revert the direct commits.
>> 
>> If you need help with getting PRs merged, ping me or Rajani as we’re happy 
>> to help.
>> 
>> Thanks,
>> Remi
>> 

No more direct commits to master please!

[Remi Bergsma]

Hi all,

What happened to master? I see a lot of direct commits. I thought we agreed to 
make a PR, then _merge_ it to master with the script in ./tools/git/git-pr.

We’re getting ready for a 4.6 RC and this makes stuff extra hard to track. Most 
direct commits seem to come from PRs, but I don’t think all of them did.

Talking about this (there are more):
https://github.com/apache/cloudstack/commit/b66dcda49f370e6fc91ebff889a694f17826ca44
https://github.com/apache/cloudstack/commit/1c6378ec0056e8c75990a4a0c15e99b2df162a75
https://github.com/apache/cloudstack/commit/1a02773b556a0efa277cf18cd099fc62a4e27706
https://github.com/apache/cloudstack/commit/ba59a4b6f31e48e4b6e43e16068e4cacdc45
https://github.com/apache/cloudstack/commit/f661ac0a2a783447b6eaab590d58091ec542aec2

Please don’t make me revert the direct commits.

If you need help with getting PRs merged, ping me or Rajani as we’re happy to 
help.

Thanks,
Remi

Re: Cloudstack session storage in Redis or Memcache databases

[Remi Bergsma]

Hi Artjoms,

Why would you want to share sessions?

If you refer to login, I’d go for single-sign-on instead. SAML2 landed in 4.5 I 
think and it is awesome.

Regards,
Remi


From: Artjoms Petrovs
Reply-To: "dev@cloudstack.apache.org"
Date: Thursday 10 September 2015 16:34
To: "dev@cloudstack.apache.org"
Subject: Cloudstack session storage in Redis or Memcache databases

Hello!

Once again I am up to think about some crazy ideas.
Is it possible to store the Cloudstack session in a shared Memcached or Redis 
database? This way I would like to share the session with a PHP system, located 
on the same server.

Best regards,
Artjoms Petrovs

[cid:image001.jpg@01D0EBEE.B4D0F000]
Artjoms Petrovs
System Analyst / Programmer

Telia Latvija, Ltd. | Lielvardes street 8a, Riga, Latvia, LV-1006
Ph.:   +371 67082144
Mob. +371 27498048
artjoms.petr...@telia.lv | telia.lv

This email (and any attachements or hyperlinks within it) may contain 
information that is confidential, legally  privileged or otherwise protected 
from disclosure.
If you are not the intended recipient of this email, you are not entitled to 
use, disclose, distribute, copy, print, disseminate or rely on this email in 
any way. If you have received this email in error, please notify the sender 
immediately by or email and destroy it, and all copies of it.

Update on ACS 4.6

[Remi Bergsma]

Hi all,


A lot of work is being done to make 4.6 ready for a release. It's great to see 
it's getting better every day!


Today Rajani and myself looked at all blocker and critical issues on 4.6. We 
decided to bump some of them to blocker. Two more issues need to verified 
against current master. In case still broken, they will be marked blocker as 
well. This means we'll have 6-8 blocker issues to resolve. Most of them are 
virtual router related and we feel we cannot do a RC without properly fixing 
them.


If you have some time, please:


Look at the 4.6 release dashboard:

https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326765


Fix one of the blockers (or critical issues):

https://issues.apache.org/jira/browse/CLOUDSTACK-8697?filter=12332940


It also helps if people help reviewing PRs:

https://github.com/apache/cloudstack/pulls


Apart from these issues, 4.6 (aka master) is pretty stable. Feel free to 
test-drive it and verify your key functionality.


Thanks!


Regards from the 4.6 RMs,


Rajani / Remi

Re: Heads-up: Serious investigator issue in 4.4

[Remi Bergsma]

Yes, I'm sure.

Have a look at table async_job_join_map

What foreign keys are there? I deleted fk_async_job_join_map__join_job_id, as 
per 4.5 upgrade script.

Regards, Remi


On 09 Sep 2015, at 01:44, Pierre-Luc Dion 
mailto:pd...@cloudops.com>> wrote:

Hello Remi,

Are you sure the async job issue is not fixed in 4.4.4? Because for us
upgrading to it did solve that problem so far.

Thanks for sharing latest info,

Cheers

PL
On Sep 4, 2015 4:34 PM, "Remi Bergsma" 
mailto:rberg...@schubergphilis.com>> wrote:

Hi all,


This brought me some serious headaches this week. HA in 4.4.4 (and any
4.4.x version would have this) doesn't do investigations properly due to
the Hyper-V investigator returning false instead of null. So, it confirms
any VM as down whereas it may be running. Yes, this becomes a mess indeed
;-) In 4.5 and master this was already fixed.


Links:

https://issues.apache.org/jira/browse/CLOUDSTACK-8811

https://github.com/apache/cloudstack/pull/761


Another issue on 4.4 is with the cleaning of async jobs. That fails due to
a foreign key constraint (also solved in 4.5 already) causing it to block
other jobs:

https://issues.apache.org/jira/browse/CLOUDSTACK-8810


Might write a blog about it once I got some sleep ;-)


We're running 4.4 HEAD now.


I'd recommend anyone using 4.4.x to either compile packages from the 4.4
branch (with the fixes included) or, even better, upgrade to 4.5.2.


Regards,

Remi

PS: I wasn’t able to do any PR review this week. Too busy fire fighting,
worked day & night. Hope to return to normal operations next week.

Re: Build failed in Jenkins: build-master-slowbuild #2238

[Remi Bergsma]

FYI: talked to Rajani and the findbugs issue will be resolved Monday. The 
actual build works so I can live with the delay.

Sent from my iPhone

> On 06 Sep 2015, at 07:19, "jenk...@cloudstack.org"  
> wrote:
> 
> See 
> 
> --
> [...truncated 28185 lines...]
> [INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ 
> cloud-quickcloud ---
> [INFO] No sources to compile
> [INFO] 
> [INFO] >>> findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
> cloud-quickcloud >>>
> [INFO] 
> [INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
> ---
> [INFO] 
> [INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
> cloud-quickcloud <<<
> [INFO] 
> [INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
> cloud-quickcloud ---
> [INFO] 
> [INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
> cloud-quickcloud ---
> [WARNING] No files to instrument.
> [INFO] NOT adding cobertura ser file to attached artifacts list.
> [INFO] 
> [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
> cloud-quickcloud ---
> [debug] execute contextualize
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory 
> 
> [INFO] Copying 3 resources
> [INFO] Copying 3 resources
> [INFO] 
> [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
> cloud-quickcloud ---
> [INFO] No sources to compile
> [INFO] 
> [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ 
> cloud-quickcloud ---
> [INFO] 
> [INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
> cloud-quickcloud <<<
> [INFO] 
> [INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
> cloud-quickcloud ---
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
> [1.692s]
> [INFO] Apache CloudStack . SUCCESS [2.103s]
> [INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.801s]
> [INFO] Apache CloudStack Framework - Managed Context . SUCCESS [19.081s]
> [INFO] Apache CloudStack Utils ... SUCCESS [1:32.156s]
> [INFO] Apache CloudStack Framework ... SUCCESS [0.114s]
> [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.167s]
> [INFO] Apache CloudStack Framework - Configuration ... SUCCESS [27.570s]
> [INFO] Apache CloudStack API . SUCCESS [1:48.808s]
> [INFO] Apache CloudStack Framework - REST  SUCCESS [15.998s]
> [INFO] Apache CloudStack Framework - IPC . SUCCESS [29.210s]
> [INFO] Apache CloudStack Cloud Engine  SUCCESS [0.091s]
> [INFO] Apache CloudStack Cloud Engine API  SUCCESS [27.368s]
> [INFO] Apache CloudStack Framework - Security  SUCCESS [24.559s]
> [INFO] Apache CloudStack Core  SUCCESS [1:17.794s]
> [INFO] Apache CloudStack Agents .. SUCCESS [35.398s]
> [INFO] Apache CloudStack Framework - Clustering .. SUCCESS [35.722s]
> [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [13.837s]
> [INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:10.961s]
> [INFO] Apache CloudStack Framework - Jobs  SUCCESS [47.265s]
> [INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS 
> [31.042s]
> [INFO] Apache CloudStack Server .. SUCCESS [4:30.930s]
> [INFO] Apache CloudStack Usage Server  SUCCESS [47.219s]
> [INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
> [1:30.343s]
> [INFO] Apache CloudStack Cloud Services .. SUCCESS [0.070s]
> [INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.435s]
> [INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [1:07.238s]
> [INFO] Apache CloudStack Engine Storage Component  SUCCESS [53.275s]
> [INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [33.577s]
> [INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [27.691s]
> [INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS 
> [31.426s]
> [INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [21.860s]
> [INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [33.857s]
> [INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.395s]
> [INFO] Apache CloudStack Cloud Engine Service  SUCCESS [5.987s]
> [INFO] Apache CloudStack Plugin POM .. SUCCESS [0.749s]
> [INFO] Apache CloudStack Plugin - API Rate Lim

Heads-up: Serious investigator issue in 4.4

[Remi Bergsma]

Hi all,


This brought me some serious headaches this week. HA in 4.4.4 (and any 4.4.x 
version would have this) doesn't do investigations properly due to the Hyper-V 
investigator returning false instead of null. So, it confirms any VM as down 
whereas it may be running. Yes, this becomes a mess indeed ;-) In 4.5 and 
master this was already fixed.


Links:

https://issues.apache.org/jira/browse/CLOUDSTACK-8811

https://github.com/apache/cloudstack/pull/761


Another issue on 4.4 is with the cleaning of async jobs. That fails due to a 
foreign key constraint (also solved in 4.5 already) causing it to block other 
jobs:

https://issues.apache.org/jira/browse/CLOUDSTACK-8810


Might write a blog about it once I got some sleep ;-)


We're running 4.4 HEAD now.


I'd recommend anyone using 4.4.x to either compile packages from the 4.4 branch 
(with the fixes included) or, even better, upgrade to 4.5.2.


Regards,

Remi

PS: I wasn’t able to do any PR review this week. Too busy fire fighting, worked 
day & night. Hope to return to normal operations next week.

Re: [BLOCKER] Master broken due to PR 714 (CLOUDSTACK-8750)

[Remi Bergsma]

I say we revert so the 4.6 testing can continue and then work on fixing why 
this broke the build. No hard feelings, we simply need master to build. 

If someone can revert, please do. I can do it in about two hours. 

Sent from my iPhone

> On 31 Aug 2015, at 06:58, Koushik Das  wrote:
> 
> I am no longer able to start MS after this. I did a clean build followed by 
> starting MS. Did travis pass for it? Should we revert? 
> 
>> mvn clean install -Dsimulator -DskipTests
>> mvn -pl client jetty:run -Dsimulator
> 
> Getting the following error. No qualifying bean of type 
> [com.cloud.network.element.HAProxyLBRule] found for dependency: expected at 
> least 1 bean which qualifies as autowire candidate for this dependency.
> 
> 2015-08-31 09:51:29.195:WARN::Nested in 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'accountManagerImpl': Injection of autowired dependencies failed; 
> nested exception is org.springframework.beans.factory.BeanCreationException: 
> Could not autowire field: private com.cloud.storage.dao.VMTemplateDao 
> com.cloud.user.AccountManagerImpl._templateDao; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'VMTemplateDaoImpl': Injection of autowired dependencies failed; 
> nested exception is org.springframework.beans.factory.BeanCreationException: 
> Could not autowire field: 
> org.apache.cloudstack.storage.datastore.db.TemplateDataStoreDao 
> com.cloud.storage.dao.VMTemplateDaoImpl._templateDataStoreDao; nested 
> exception is org.springframework.beans.factory.BeanCreationException: Error 
> creating bean with name 'templateDataStoreDaoImpl': Injection of autowired 
> dependencies failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Could not autowire 
> field: private 
> org.apache.cloudstack.engine.subsystem.api.storage.DataStoreManager 
> org.apache.cloudstack.storage.image.db.TemplateDataStoreDaoImpl._storeMgr; 
> nested exception is org.springframework.beans.factory.BeanCreationException: 
> Error creating bean with name 'dataStoreProviderManager': Injection of 
> autowired dependencies failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Could not autowire 
> field: 
> org.apache.cloudstack.storage.datastore.PrimaryDataStoreProviderManager 
> org.apache.cloudstack.storage.datastore.provider.DataStoreProviderManagerImpl.primaryDataStoreProviderMgr;
>  nested exception is org.springframework.beans.factory.BeanCreationException: 
> Error creating bean with name 'primaryDataStoreProviderMgr': Injection of 
> autowired dependencies failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Could not autowire 
> field: com.cloud.storage.StorageManager 
> org.apache.cloudstack.storage.datastore.manager.PrimaryDataStoreProviderManagerImpl.storageMgr;
>  nested exception is org.springframework.beans.factory.BeanCreationException: 
> Error creating bean with name 'storageManagerImpl': Injection of autowired 
> dependencies failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Could not autowire 
> field: protected com.cloud.agent.AgentManager 
> com.cloud.storage.StorageManagerImpl._agentMgr; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'clusteredAgentManagerImpl': Injection of autowired dependencies 
> failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Could not autowire 
> field: protected com.cloud.ha.HighAvailabilityManager 
> com.cloud.agent.manager.AgentManagerImpl._haMgr; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'highAvailabilityManagerExtImpl': Injection of autowired 
> dependencies failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Could not autowire 
> field: com.cloud.alert.AlertManager 
> com.cloud.ha.HighAvailabilityManagerImpl._alertMgr; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'alertManagerImpl': Injection of autowired dependencies failed; 
> nested exception is org.springframework.beans.factory.BeanCreationException: 
> Could not autowire field: protected com.cloud.capacity.CapacityManager 
> com.cloud.alert.AlertManagerImpl._capacityMgr; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'capacityManagerImpl': Injection of autowired dependencies failed; 
> nested exception is org.springframework.beans.factory.BeanCreationException: 
> Could not autowire field: com.cloud.resource.ResourceManager 
> com.cloud.capacity.CapacityManagerImpl._resourceMgr; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'resourceManagerImpl': Injection 

Re: Discuss reserving memory on KVM hypervisors ref: CLOUDSTACK-8678

[Remi Bergsma]

Making the agent property work (host.reserved.mem.mb) would be awesome! On labs 
you can then set it to something low. 

Let me know if you need help with testing!

Thanks, Remi 

Sent from my iPhone

> On 29 Aug 2015, at 07:49, Erik Weber  wrote:
> 
> Make it configurable to enable/disable the check? Or even the size.
> 
> For labs etc you might not have or want that much to spare.
> 
> 
> Erik
> 
> Den lørdag 29. august 2015 skrev Josh Harshman 
> følgende:
> 
>> Wido -
>> Looks like the problem resides in the logic that does the detection of the
>> host resources.  It looks like most, if not all, the KVM host detection
>> occurs in the LibvirtComputingResource class.  Here I can modify it so it
>> will take the value stored in dom0MinMem into account when calculating the
>> ram available.
>> 
>> I've forked the repo and am working on a fix.
>> Does anyone have anything to add?  Suggestions?
>> 
>> 
>> From: Wido den Hollander >
>> Sent: Friday, August 28, 2015 12:38 AM
>> To: dev@cloudstack.apache.org 
>> Subject: Re: Discuss reserving memory on KVM hypervisors ref:
>> CLOUDSTACK-8678
>> 
>> 
>> 
>> Josh Harshman
>> Cloud Engineer
>> 
>> Intrinium
>> 
>>> On 27-08-15 18:36, Josh Harshman wrote:
>>> In a KVM cluster, CloudStack sees 100% of the compute node's RAM and
>> treats it as allocatable space which eventually leads to OOM killing guests.
>>> 
>>> 
>>> There is an agent property named host.reserved.mem.mb which is able to
>> be set in the agent.properties file and passed to the management server.
>> This value is stored as dom0MinMem, however, it appears to be ignored.
>>> 
>>> 
>>> If we could tweak the host capacity calculation and have it take this
>> into account, I believe that would be ideal.
>>> 
>>> 
>>> Side note: the variable dom0MinMem is declared as an int and can be
>> overflowed. Suggested change would be make it a long and add a check
>> especially if we are going to make this a configurable parameter.
>> 
>> Yes, that seems like a sane thing to do. We should be able to say that
>> eg 8GB of memory should stay available for the HV.
>> 
>> Don't know where the problem lies though. A PR is welcome :)
>> 
>> Wido
>> 
>>> 
>>> 
>>> Josh Harshman
>>> 
>>> Cloud Engineer
>>> 
>>> 
>>> Intrinium
>>> Tel: (509) 465-1234 x5259
>>> Fax: (866) 565-4578
>>> Lync / Skype: josh.harsh...@intrinium.com 
>>> Web: http://intrinium.com
>>> 
>>> 
>>> [Intrinium Long Sig Logo]
>>> 
>>> 
>>> [Facebook]
>> [Twitter]   [Linkedin] <
>> http://www.linkedin.com/company/intrinium_networks_it_security?trk=fc_badge>
>> [Youtube]  [Blog] <
>> http://intrinium.com/blog/>
>>> 
>>> Information Security and Compliance Consulting | Managed IT and Security
>> Services | Cloud Services
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they are
>> addressed. If you have received this email in error please notify the
>> system manager. This message contains confidential information and is
>> intended only for the individual named. If you are not the named addressee
>> you should not disseminate, distribute or copy this e-mail. Please notify
>> the sender immediately by e-mail if you have received this e-mail by
>> mistake and delete this e-mail from your system. If you are not the
>> intended recipient you are notified that disclosing, copying, distributing
>> or taking any action in reliance on the contents of this information is
>> strictly prohibited.
>> 

Re: FYI: MariaDB upgrade on CentOS 7 breaks install

[Remi Bergsma]

Missed that one, thx! ;-)



On 27/08/15 12:03, "Wido den Hollander"  wrote:

>On 08/26/2015 10:33 PM, Remi Bergsma wrote:
>> Hi all,
>> 
>> Not sure if MariaDB is even supported, but for those who use it:
>> 
>> Today I run into an issue with the latest MariaDB on CentOS7 (it was 
>> upgraded from 5.5.41 -> 5.5.44). After the upgrade I could no longer install 
>> CloudStack due to the following error (traced it to this file by executing 
>> all steps manually):
>> 
>> ---
>
>I've seen this as well on a clean install on Ubuntu 14.04, even with
>MariaDB 10.
>
>I posted it on the list before:
>http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201508.mbox/%3c55c1c38f.9090...@widodh.nl%3E
>
>Wido
>
>> [root@cs3 db]# mysql cloud < 
>> /data/git/cs3/cloudstack/developer/target/db/db/schema-421to430.sql
>> ERROR 2013 (HY000) at line 114: Lost connection to MySQL server during query
>> 
>> Trying to get some variables.
>> Some pointers may be invalid and cause the dump to abort.
>> Query (0x7fc8909cd318): UPDATE `cloud`.`configuration` SET value = 
>> CONCAT("*.",(SELECT `temptable`.`value` FROM (SELECT * FROM 
>> `cloud`.`configuration` WHERE `name`="consoleproxy.url.domain") AS 
>> `temptable` WHERE `temptable`.`name`="consoleproxy.url.domain")) WHERE 
>> `name`="consoleproxy.url.domain"
>> Connection ID (thread ID): 10
>> Status: NOT_KILLED
>> 
>> Optimizer switch: 
>> index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=off
>> 
>> The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
>> information that should help you find out what is causing the crash.
>> ---
>> 
>> The MySQL server crashed, then restarted. I haven't debugged it further but 
>> a downgrade works:
>> 
>> systemctl stop mariadb
>> yum remove mariadb-libs
>> yum install mariadb-1:5.5.41-2.el7_0.x86_64
>> yum install mariadb-server-1:5.5.41-2.el7_0.x86_64
>> systemctl start mariadb
>> 
>> Just in case someone else runs into it.
>> 
>> Regards,
>> Remi
>> 

Re: FYI: MariaDB upgrade on CentOS 7 breaks install

[Remi Bergsma]

Hi Wei,

Thanks a lot, this solved it! :-)

Can you open a PR please?

Be sure to ping @wido as he might want to test it on Ubuntu as well. I expect 
this will also work fine.

Thanks, Remi




On 27/08/15 14:37, "Wei ZHOU"  wrote:

>Hi Remi,
>
>Can you test the following change?
>
># git diff setup/db/db/schema-421to430.sql
>diff --git a/setup/db/db/schema-421to430.sql
>b/setup/db/db/schema-421to430.sql
>index 3f2ad02..0a96ea0 100644
>--- a/setup/db/db/schema-421to430.sql
>+++ b/setup/db/db/schema-421to430.sql
>@@ -111,8 +111,7 @@ CREATE TABLE `cloud`.`async_job_join_map` (
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
>
> #realhostip changes, before changing table and adding default value
>-UPDATE `cloud`.`configuration` SET value = CONCAT("*.",(SELECT
>`temptable`.`value` FROM (SELECT * FROM `cloud`.`configuration` WHERE
>`name`="consoleproxy.url.domain") AS `temptable` WHERE
>`temptable`.`name`="consoleproxy.url.domain")) W
>-UPDATE `cloud`.`configuration` SET `value` = CONCAT("*.",(SELECT
>`temptable`.`value` FROM (SELECT * FROM `cloud`.`configuration` WHERE
>`name`="secstorage.ssl.cert.domain") AS `temptable` WHERE
>`temptable`.`name`="secstorage.ssl.cert.dom
>+UPDATE `cloud`.`configuration` SET value=CONCAT("*.",value) WHERE
>`name`="consoleproxy.url.domain" OR `name`="secstorage.ssl.cert.domain";
>
> ALTER TABLE `cloud`.`configuration` ADD COLUMN `default_value`
>VARCHAR(4095) COMMENT 'Default value for a configuration parameter';
> ALTER TABLE `cloud`.`configuration` ADD COLUMN `updated` datetime COMMENT
>'Time this was updated by the server. null means this row is obsolete.';
>
>
>
>
>2015-08-27 12:03 GMT+02:00 Wido den Hollander :
>
>> On 08/26/2015 10:33 PM, Remi Bergsma wrote:
>> > Hi all,
>> >
>> > Not sure if MariaDB is even supported, but for those who use it:
>> >
>> > Today I run into an issue with the latest MariaDB on CentOS7 (it was
>> upgraded from 5.5.41 -> 5.5.44). After the upgrade I could no longer
>> install CloudStack due to the following error (traced it to this file by
>> executing all steps manually):
>> >
>> > ---
>>
>> I've seen this as well on a clean install on Ubuntu 14.04, even with
>> MariaDB 10.
>>
>> I posted it on the list before:
>>
>> http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201508.mbox/%3c55c1c38f.9090...@widodh.nl%3E
>>
>> Wido
>>
>> > [root@cs3 db]# mysql cloud <
>> /data/git/cs3/cloudstack/developer/target/db/db/schema-421to430.sql
>> > ERROR 2013 (HY000) at line 114: Lost connection to MySQL server during
>> query
>> >
>> > Trying to get some variables.
>> > Some pointers may be invalid and cause the dump to abort.
>> > Query (0x7fc8909cd318): UPDATE `cloud`.`configuration` SET value =
>> CONCAT("*.",(SELECT `temptable`.`value` FROM (SELECT * FROM
>> `cloud`.`configuration` WHERE `name`="consoleproxy.url.domain") AS
>> `temptable` WHERE `temptable`.`name`="consoleproxy.url.domain")) WHERE
>> `name`="consoleproxy.url.domain"
>> > Connection ID (thread ID): 10
>> > Status: NOT_KILLED
>> >
>> > Optimizer switch:
>> index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=off
>> >
>> > The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html
>> contains
>> > information that should help you find out what is causing the crash.
>> > ---
>> >
>> > The MySQL server crashed, then restarted. I haven't debugged it further
>> but a downgrade works:
>> >
>> > systemctl stop mariadb
>> > yum remove mariadb-libs
>> > yum install mariadb-1:5.5.41-2.el7_0.x86_64
>> > yum install mariadb-server-1:5.5.41-2.el7_0.x86_64
>> > systemctl start mariadb
>> >
>> > Just in case someone else runs into it.
>> >
>> > Regards,
>> > Remi
>> >
>>

FYI: MariaDB upgrade on CentOS 7 breaks install

[Remi Bergsma]

Hi all,

Not sure if MariaDB is even supported, but for those who use it:

Today I run into an issue with the latest MariaDB on CentOS7 (it was upgraded 
from 5.5.41 -> 5.5.44). After the upgrade I could no longer install CloudStack 
due to the following error (traced it to this file by executing all steps 
manually):

---
[root@cs3 db]# mysql cloud < 
/data/git/cs3/cloudstack/developer/target/db/db/schema-421to430.sql
ERROR 2013 (HY000) at line 114: Lost connection to MySQL server during query

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7fc8909cd318): UPDATE `cloud`.`configuration` SET value = 
CONCAT("*.",(SELECT `temptable`.`value` FROM (SELECT * FROM 
`cloud`.`configuration` WHERE `name`="consoleproxy.url.domain") AS `temptable` 
WHERE `temptable`.`name`="consoleproxy.url.domain")) WHERE 
`name`="consoleproxy.url.domain"
Connection ID (thread ID): 10
Status: NOT_KILLED

Optimizer switch: 
index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=off

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
---

The MySQL server crashed, then restarted. I haven't debugged it further but a 
downgrade works:

systemctl stop mariadb
yum remove mariadb-libs
yum install mariadb-1:5.5.41-2.el7_0.x86_64
yum install mariadb-server-1:5.5.41-2.el7_0.x86_64
systemctl start mariadb

Just in case someone else runs into it.

Regards,
Remi

Re: [DISCUSS] Improving community experience for (new) contributors

[Remi Bergsma]

Hi Rohit,

Thanks for sharing your observations. I agree with you that anybody that 
contributes (or uses) Apache CloudStack should feel welcome in the community.

In the past weeks I tried to respond to as many PRs as I could and merge them 
as soon as it met the requirements. When I can not review myself, I usually 
ping someone and ask to do the review. This way I hope new contributors too get 
a fast response. I agree this is important so let us all have a look at the PRs 
on a regular basis and review them if possible.

Also, I dropped the closing of PRs for now. I get your point and propose to 
leave it as-is. It’s not important now.

I see a master that gets more stable every day and I think that’s awesome. Also 
for new contributors or new users this is great, as most new devs will checkout 
master to see if it is any good. In the current state, I’d say we improved 
greatly.

So, it’s true that our review process takes time and effort, but IMHO it’s 
worth it. Running tests before anything hits master shows us problems in 
advance. And in case it doesn’t, we can always go ahead and improve the tests.

If you see things we can improve, please share.

Regards,
Remi


> On 26 Aug 2015, at 12:20, Rohit Yadav  wrote:
> 
> Hi all,
> 
> I’ve identified few issues around the recent changes that I don’t know
> how we can fix or improve but I hope to get feedback from the
> community.
> 
> I understand that you may disagree with what I’m sharing which is
> alright, even in your disagreement I hope that you don’t take an
> offence on that, that is certainly not my aim. I personally want to
> the community to be felt welcoming so that we can attract and retain
> new contributors and have a nice environment for everyone.
> 
> Some observations and comments:
> 
> - Generally those of us who have worked for long in the community or
> have colleagues from dayjob working in the ACS community - we have
> better chances in getting their PRs merged; for new contributors this
> pattern is not encouraging and certainly not welcoming if their PRs
> get closed.
> 
> - The recent drive to use Github PRs seems to be really working great
> for us, but still the requirements of at least 2 +1s/LGTM, unit tests
> and pedantic bike-shedding has cost us new developers/contributors and
> kills the joy of programming for some; for experienced and
> commercially backed developers this makes sense. I personally try to
> be pragmatic and lenient on code reviews as long as smoke tests
> (Travis) pass.
> 
> - Contributions are process-oriented that cost time and effort; there
> have been initiative to satisfy the tool but not the human, and not
> optimizing on developer time.
> 
> - What should we do to get more developer contributors and how to
> attract hobbyists or casual contributors.
> 
> Regards.

Re: review wanted

[Remi Bergsma]

Great! Welcome :-)

> On 25 Aug 2015, at 00:41, Rafael Weingärtner  
> wrote:
> 
> Hi Daan,
> I think that we should do a proper introduction.
> It might seem kind of odd to some people that a bunch of folks suddenly
> started working for free.
> 
> Our first PR was done a while ago:
> https://github.com/apache/cloudstack/pull/560. Then we did
> https://github.com/apache/cloudstack/pull/700, and the last one was the
> https://github.com/apache/cloudstack/pull/714, that is still in the review
> process.
> 
> Until now you know Pedro (PR 714) and Critofolini (PR 700), but we are a
> team of five. We work under the same project and the improvements/clean ups
> that we have been doing to the ACS is a way we found to improve our
> knowledge of the software that we are using.
> 
> I am a Ph. D. candidate, researching/developing autonomic models that can
> be used to manage and optimize a cloud computing environment that provide
> infrastructure as a service. We have done an extensive work comparing and
> discussing cloud computing orchestration platforms that are most widely
> used. CloudStack was the orchestration tool chosen to develop my proposals,
> in order to test and validate them.
> 
> I have several undergrad students working with me; none of them had real
> experience developing java web applications, the PRs we are creating is the
> way we found to teach them some Java developing skills, while getting to
> know a little better of ACS core and architecture. At the same time we are
> contributing to the software we use.
> 
> The team that works with me and you will probably see creating more PRs is
> the following:
> 
>   - Gabriel Beims Bräscher
>   - Pedro Henrique Pereira Martins
>   - Lucas Berri Cristofolini
>   - Alexandre Santana
> 
> 
> All of them are Computer Science student. They all are developing their
> graduation projects within my thesis.  Sadly, some of the things we are
> doing here and that we have already prototyped, we cannot commit to the ACS
> community (at least not yet); hence it is part of a thesis project.
> However, once we start publishing papers, I think you will like what we
> have been working on.
> 
> Hope we can keep up the good work and keep learning with you all guys from
> the ACS community.
> Waiting to hear the feedbacks on PR 714 ;)
> 
> 
> On Sat, Aug 22, 2015 at 1:10 AM, Daan Hoogland 
> wrote:
>> 
>> everybody, I will LGTM PR #714 [1] and I would like to have more then one
>> extra pair of eyes this time. Some group of folks, I know there is at
> least
>> three of them, have decided to invest in cleaning some code in CS and I
>> think their work deserves full attention. they worked on refactoring some
>> of the CitrixResourceBase hierarchy [2] and now they are busy on the
>> ComponentLifecycleBase
>> hierarchy.
>> 
>> Please have a look,
>> 
>> [1] https://github.com/apache/cloudstack/pull/714
>> [2] https://github.com/apache/cloudstack/pull/700
>> 
>> --
>> Daan
> 
> 
> 
> 
> --
> Rafael Weingärtner

Re: SDN solutions in use today with CloudStack

[Remi Bergsma]

We use it with hundreds of XenServers (currently 6.2) and KVM hypervisors on 
CentOS 7. Open vSwitch does the magic. We did upgrade ovs to a more recent 
version, though. 

Regards, Remi 

Sent from my iPhone

> On 21 Aug 2015, at 14:04, Zaeem Arshad  wrote:
> 
> How does that integrate with a XenServer based environment?
> 
> Regards
> 
> Zaeem
> 
> On Fri, Aug 21, 2015 at 1:17 AM, Remi Bergsma 
> wrote:
> 
>> Hi Simon,
>> 
>> At Schuberg Philis we use Nicira (which nowadays is called VMware NSX-MH)
>> in production since 2012. It works well for us. The plugin is also still
>> maintained and is getting some tlc as we speak.
>> 
>> The Nuage plugin was introduced recently, I think in 4.5. I hear people
>> are using this a lot so it’s definitely something to investigate. The
>> others I have never tried. Really wondering if anyone is using GRE in
>> CloudStack?
>> 
>> Regards,
>> Remi
>> 
>> 
>>> On 20 Aug 2015, at 20:41, Simon Weller  wrote:
>>> 
>>> Hi all,
>>> 
>>> We  are currently exploring options for improving our networking setup
>> (read SDN) within CS for our advanced zones.
>>> 
>>> There are a few plugins currently available for various third party SDN
>> providers (Nicira, Big Switch VNS, MidoNet, Stratosphere SSP, Nuage VSP  et
>> al), as well as some pre-SDN functionality using native VXLAN, OVS GRE and
>> of course vlans.
>>> 
>>> Most of the organizations mentioned above appear to have drunken the
>> OpenStack kool-aid and don't even mention support for CloudStack on their
>> commercial websites.
>>> 
>>> It seems that some of these plugins are getting rather old now and I'd
>> be interesting to know (if you're willing to share) what is in use in the
>> community today.
>>> 
>>> - Si
>> 
>> 

Re: SDN solutions in use today with CloudStack

[Remi Bergsma]

Hi Simon,

At Schuberg Philis we use Nicira (which nowadays is called VMware NSX-MH) in 
production since 2012. It works well for us. The plugin is also still 
maintained and is getting some tlc as we speak.

The Nuage plugin was introduced recently, I think in 4.5. I hear people are 
using this a lot so it’s definitely something to investigate. The others I have 
never tried. Really wondering if anyone is using GRE in CloudStack?

Regards,
Remi
 

> On 20 Aug 2015, at 20:41, Simon Weller  wrote:
> 
> Hi all,
> 
> We  are currently exploring options for improving our networking setup (read 
> SDN) within CS for our advanced zones.
> 
> There are a few plugins currently available for various third party SDN 
> providers (Nicira, Big Switch VNS, MidoNet, Stratosphere SSP, Nuage VSP  et 
> al), as well as some pre-SDN functionality using native VXLAN, OVS GRE and of 
> course vlans.
> 
> Most of the organizations mentioned above appear to have drunken the 
> OpenStack kool-aid and don't even mention support for CloudStack on their 
> commercial websites.
> 
> It seems that some of these plugins are getting rather old now and I'd be 
> interesting to know (if you're willing to share) what is in use in the 
> community today.
> 
> - Si
> 
> 
> 

Re: [VOTE] Apache Cloudstack 4.5.2 (Round 2)

[Remi Bergsma]

Hi all,

+1 (binding)

Tested:

1. Advanced zone with XenServer
- Deployed VPCs, VMs and VPNs between them
- Crashed a XenServer, watched it recover
- Tested it again and all was fine. All I had to do was reset the VPN 
connection, but maybe it'd have done it automatically if I waited longer.

2. Advanced zone with KVM (on CentOS 7 that is, after some manual tweaks)
- Advanced zone with XenServer
- Deployed VPCs, VMs and VPNs between them
- Crashed a KVM hypervisor, watched it recover
- Tested it again and all was fine. VPN recovery was automatic.

3. Upgraded 4.4.4 -> 4.5.2 
It went fine.

About KVM on CentOS 7
At work we're actually running KVM on CentOS 7, on ACS 4.4.x. Although I know 
not many people do. I tried it on 4.5.2 and encountered the issues described in 
CLOUDSTACK-8443. I checked the documentation and it said we only support CentOS 
6.3 (I assume .3 should be .x but anyway) on ACS 4.5.x so I'll just ignore this 
for now.

I have updated the Jira issue with some findings and I will investigate this 
further, so we can fix it and at least start supporting CentOS 7 as a KVM 
hypervisor out-of-the-box in 4.6.

If we feel we want to fix KVM on CentOS 7 in 4.5.2 then we need another 
4.5.2RC, in which case I'm happy to help making it happen ;-)

Regards,
Remi



> On 20 Aug 2015, at 08:26, Rajani Karuturi  wrote:
> 
> +1(binding)
> 
> tested fresh install on xenserver 6.5 advanced zone setup.
> 
> register template, create network, launch vm, view console etc. worked fine.
> 
> 
> ~Rajani
> 
> On Thu, Aug 20, 2015 at 12:04 AM, Milamber  wrote:
> 
>> Hello,
>> 
>> +1 (binding)
>> 
>> * Building CloudStack ubuntu packages from Git 4.5.2 RC2 tag.
>> 
>> * Tests migration from 4.4.4 -> 4.5.2rc2 on Ubuntu 14.04.3 (1 mgr, 2
>> nodes, 1 nfs), basic install, NFS storage, KVM, SystemVM shapeblue, After
>> migration: some tests on HA (crash node), some tests with templates,
>> account management in webui, test localization french, and CS<->cloud-init
>> on debian.
>> 
>> * Tests fresh install on Ubuntu 14.04.3 (1 mgr, 2 nodes, 1 nfs), advanced
>> network install NFS storage, KVM, SystemVM shapeblue, some tests on HA
>> (crash node), some tests with templates, and CS<->cloud-init on debian.
>> 
>> * Some tests (register template, create network, register ssh key, create
>> instance, get IP) with Ansible + ansible-cloudstack module from @resmo
>> 
>> Thanks for the RM.
>> 
>> Milamber
>> 
>> 
>> Please note this bug message in the last migration step (when I rebooted
>> all systemvm/router).
>> 
>> root@cs-mgr1:~# cloudstack-sysvmadm -d 127.0.0.1 -u cloud -p cloudPass -a
>> /usr/bin/cloudstack-sysvmadm: line 21: /etc/rc.d/init.d/functions: No such
>> file or directory
>> 
>> Stopping and starting 1 secondary storage vm(s)...
>> Done stopping and starting secondary storage vm(s)
>> 
>> Stopping and starting 1 console proxy vm(s)...
>> Done stopping and starting console proxy vm(s) .
>> 
>> Stopping and starting 1 running routing vm(s)...
>> Done restarting router(s).
>> 
>> 
>> 
>> 
>> On 19/08/2015 10:22, Rohit Yadav wrote:
>> 
>>> Hi All,
>>> 
>>> I've created a 4.5.2 release, with the following artifacts up for a vote:
>>> 
>>> Git Branch and Commit SH:
>>> 
>>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.5-RC20150819T1442
>>> Commit: 7385441807ba3fde3d45c226df6b1bdd2f36ae26
>>> Tag: 4.5.2-rc2
>>> 
>>> List of changes:
>>> 
>>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.5-RC20150819T1442
>>> 
>>> Source release (checksums and signatures are available at the same
>>> location):
>>> https://dist.apache.org/repos/dist/dev/cloudstack/4.5.2/
>>> 
>>> PGP release keys (signed using 0EE3D884):
>>> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>>> 
>>> The vote will be open for 72 hours.
>>> 
>>> For sanity in tallying the vote, can PMC members please be sure to
>>> indicate "(binding)" with their vote?
>>> 
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>> 
>>> Regards.
>>> 
>>> 
>> 

Re: Merging Pull Requests

[Remi Bergsma]

Hi Wido,

Nice!

The latest version should detect your Apache GitHub remote name.

Regards,
Remi

> On 20 Aug 2015, at 09:13, Wido den Hollander  wrote:
> 
> 
> 
> On 19-08-15 17:27, Remi Bergsma wrote:
>> Hi all,
>> 
>> As it is now, additions to CloudStack need to go through a GitHub PR and, if 
>> accepted, merged to the Apache remote (not in GitHub). This means that 
>> merging a PR for CloudStack is a bit more involved than merging a normal 
>> GitHub PR.
>> 
>> To help with this, Miguel, Rajani, Daan and myself, have created some 
>> scripts. One is 'git-pr' to merge a PR, the second one is 'git-fwd-merge' 
>> used by RM to merge branches (starting 4.6).
>> 
>> Links:
>> [1] PR to add the scripts
>> [2] Wiki 
>> 
>> I'd be great if we would all use these scripts to merge Pull Requests 
>> (instead of applying patches).
>> 
> 
> Yes, I'm using it know. The remote names were a bit confusing in the
> beginning, but when I got that fixed it worked fine.
> 
> Wido
> 
>> Let me know if you need help!
>> 
>> Thanks & Regards,
>> 
>> Remi
>> 
>> [1] https://github.com/apache/cloudstack/pull/721
>> [2] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61311655
>> 

Merging Pull Requests

[Remi Bergsma]

Hi all,

As it is now, additions to CloudStack need to go through a GitHub PR and, if 
accepted, merged to the Apache remote (not in GitHub). This means that merging 
a PR for CloudStack is a bit more involved than merging a normal GitHub PR.

To help with this, Miguel, Rajani, Daan and myself, have created some scripts. 
One is 'git-pr' to merge a PR, the second one is 'git-fwd-merge' used by RM to 
merge branches (starting 4.6).

Links:
[1] PR to add the scripts
[2] Wiki 

I'd be great if we would all use these scripts to merge Pull Requests (instead 
of applying patches).

Let me know if you need help!

Thanks & Regards,

Remi

[1] https://github.com/apache/cloudstack/pull/721
[2] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61311655

Review PRs: please help!

[Remi Bergsma]

Hi all,

Could you please have a look at the PRs we have waiting [1] and review them? 
Test it, look at the code or otherwise review them. Add comments, or add a LGTM 
when you think it’s OK. Even if you review just one PR per day it already helps 
:-)

I’ll keep an eye on them as well and will merge when the requirements are met.

Thanks,
Remi

[1] https://github.com/apache/cloudstack/pulls 

Re: [PROPOSAL] Closing PRs older than 1 month and without activity

[Remi Bergsma]

Hi all,

This PR includes the ones we can close now:
https://github.com/apache/cloudstack/pull/706

Any LGTM’s so we can merge it?

Thanks,
Remi


On 17 Aug 2015, at 18:56, Rajani Karuturi 
mailto:raj...@apache.org>> wrote:

+1 for auto closing.
I also agree with Boris that we need to distinguish discarded vs. Merged
prs.


On Mon, Aug 17, 2015 at 21:51 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>> wrote:

+1 Sounds reasonable

On Mon, Aug 17, 2015 at 8:25 AM, Remi Bergsma 
mailto:rberg...@schubergphilis.com>
>
wrote:

Hi all,

There are several PRs that are quite old. They haven't been updated by
their author for over a month and there was no response to comments made.

As a RM, I want to maintain an as-short-as-possible list of PRs that is
actively worked on. It is perfectly fine if a PR is open for a longer
time,
as long as it is actively maintained (or has a comment that explains why
there is a delay). Long lists of open PRs don't give the impression we
actively work on them and might keep people from contributing.

Proposal:
Let's close PRs where the author did not respond for over a month.

How?
For now, I'll manually select the PRs that I propose to close. Next, I
make a PR with an empty commit that closes the PRs by triggering asfbot
(as
we cannot otherwise close PRs due to it being read-only for committers).
By
using a PR, it should be visible which PRs will get closed (after 2x LGTM
and no -1). I’ll send an example PR with link to this thread after I've
sent this e-mail.

Work lost?
The work done in a PR is not lost by closing the PR! If someone wants to
take over, this is how you can merge the work in a new branch (keeping
author and commit hashes the same) and add more commits on top of it. You
can then send it as a new PR.

Example:
 prId=12345
 git fetch origin pull/${prId}/head:pr/${prId}
 git merge --no-ff --log -m "Merging PR ${prId} and continuing the work"
pr/${prId}
 git commit --amend -s --allow-empty-message -m ''


Please let me know what you think: +1 or -1?

If -1, what should we do instead?

Regards,
Remi




--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com> 

o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*



--
-
Sent from Windows Phone
~Rajani

Re: [PROPOSAL] Closing PRs older than 1 month and without activity

[Remi Bergsma]

Hi Rajani,

If we truly “merge” PRs, which I think we should do (instead of applying a 
patch) then those will be in state “Merged” (purple) versus “Closed” (red).

Regards,
Remi


On 17 Aug 2015, at 18:56, Rajani Karuturi 
mailto:raj...@apache.org>> wrote:

+1 for auto closing.
I also agree with Boris that we need to distinguish discarded vs. Merged
prs.


On Mon, Aug 17, 2015 at 21:51 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>> wrote:

+1 Sounds reasonable

On Mon, Aug 17, 2015 at 8:25 AM, Remi Bergsma 
mailto:rberg...@schubergphilis.com>
>
wrote:

Hi all,

There are several PRs that are quite old. They haven't been updated by
their author for over a month and there was no response to comments made.

As a RM, I want to maintain an as-short-as-possible list of PRs that is
actively worked on. It is perfectly fine if a PR is open for a longer
time,
as long as it is actively maintained (or has a comment that explains why
there is a delay). Long lists of open PRs don't give the impression we
actively work on them and might keep people from contributing.

Proposal:
Let's close PRs where the author did not respond for over a month.

How?
For now, I'll manually select the PRs that I propose to close. Next, I
make a PR with an empty commit that closes the PRs by triggering asfbot
(as
we cannot otherwise close PRs due to it being read-only for committers).
By
using a PR, it should be visible which PRs will get closed (after 2x LGTM
and no -1). I’ll send an example PR with link to this thread after I've
sent this e-mail.

Work lost?
The work done in a PR is not lost by closing the PR! If someone wants to
take over, this is how you can merge the work in a new branch (keeping
author and commit hashes the same) and add more commits on top of it. You
can then send it as a new PR.

Example:
 prId=12345
 git fetch origin pull/${prId}/head:pr/${prId}
 git merge --no-ff --log -m "Merging PR ${prId} and continuing the work"
pr/${prId}
 git commit --amend -s --allow-empty-message -m ''


Please let me know what you think: +1 or -1?

If -1, what should we do instead?

Regards,
Remi




--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com> 

o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*



--
-
Sent from Windows Phone
~Rajani

Re: [PROPOSAL] Closing PRs older than 1 month and without activity

[Remi Bergsma]

Hi Boris,

I like the idea, but this is a bit harder than it seems. We only have read-only 
access to GitHub, because it is a mirror of the actual git repo at Apache. 
That’s why we cannot simply close PRs etc. For the same reason, I cannot create 
labels or assign them. Not even for the PRs I submitted myself.

The closed PRs do get linked to the PR that closed them, because it was 
mentioned there. So, there’s a way to track them, just not as handy as a GitHub 
label would have been.

If anyone knows of a trick, let me know!

Regards,
Remi


> On 17 Aug 2015, at 18:09, Boris Schrijver  wrote:
> 
> Remi,
> 
> Would it be possible to give the closed PRs which are not merged due to
> inactivity or unfinished code-work a label? So the can be recognized when they
> are closed? 
> 
> Best regards,
> 
> Boris Schrijver
> 
> TEL: +31633784542
> MAIL: bo...@pcextreme.nl
> 
>> 
>>On August 17, 2015 at 5:49 PM Somesh Naidu 
>> wrote:
>> 
>> 
>>+1
>> 
>>Regards,
>>Somesh
>> 
>> 
>>-Original Message-
>>From: Remi Bergsma [mailto:rberg...@schubergphilis.com]
>>Sent: Monday, August 17, 2015 10:26 AM
>>To: dev@cloudstack.apache.org
>>Subject: [PROPOSAL] Closing PRs older than 1 month and without activity
>> 
>>Hi all,
>> 
>>There are several PRs that are quite old. They haven't been updated by
>> their author for over a month and there was no response to comments made.
>> 
>>As a RM, I want to maintain an as-short-as-possible list of PRs that is
>> actively worked on. It is perfectly fine if a PR is open for a longer time, 
>> as
>> long as it is actively maintained (or has a comment that explains why there 
>> is
>> a delay). Long lists of open PRs don't give the impression we actively work 
>> on
>> them and might keep people from contributing.
>> 
>>Proposal:
>>Let's close PRs where the author did not respond for over a month.
>> 
>>How?
>>For now, I'll manually select the PRs that I propose to close. Next, I
>> make a PR with an empty commit that closes the PRs by triggering asfbot (as 
>> we
>> cannot otherwise close PRs due to it being read-only for committers). By 
>> using
>> a PR, it should be visible which PRs will get closed (after 2x LGTM and no
>> -1). I’ll send an example PR with link to this thread after I've sent this
>> e-mail.
>> 
>>Work lost?
>>The work done in a PR is not lost by closing the PR! If someone wants to
>> take over, this is how you can merge the work in a new branch (keeping author
>> and commit hashes the same) and add more commits on top of it. You can then
>> send it as a new PR.
>> 
>>Example:
>>prId=12345
>>git fetch origin pull/${prId}/head:pr/${prId}
>>git merge --no-ff --log -m "Merging PR ${prId} and continuing the work"
>> pr/${prId}
>>git commit --amend -s --allow-empty-message -m ''
>> 
>> 
>>Please let me know what you think: +1 or -1?
>> 
>>If -1, what should we do instead?
>> 
>>Regards,
>>Remi
>> 
> 

[PROPOSAL] Closing PRs older than 1 month and without activity

[Remi Bergsma]

Hi all,

There are several PRs that are quite old. They haven't been updated by their 
author for over a month and there was no response to comments made.

As a RM, I want to maintain an as-short-as-possible list of PRs that is 
actively worked on. It is perfectly fine if a PR is open for a longer time, as 
long as it is actively maintained (or has a comment that explains why there is 
a delay). Long lists of open PRs don't give the impression we actively work on 
them and might keep people from contributing.

Proposal:
Let's close PRs where the author did not respond for over a month.

How?
For now, I'll manually select the PRs that I propose to close. Next, I make a 
PR with an empty commit that closes the PRs by triggering asfbot (as we cannot 
otherwise close PRs due to it being read-only for committers). By using a PR, 
it should be visible which PRs will get closed (after 2x LGTM and no -1). I’ll 
send an example PR with link to this thread after I've sent this e-mail.

Work lost?
The work done in a PR is not lost by closing the PR! If someone wants to take 
over, this is how you can merge the work in a new branch (keeping author and 
commit hashes the same) and add more commits on top of it. You can then send it 
as a new PR.

Example:
  prId=12345
  git fetch origin pull/${prId}/head:pr/${prId}
  git merge --no-ff --log -m "Merging PR ${prId} and continuing the work" 
pr/${prId}
  git commit --amend -s --allow-empty-message -m ''


Please let me know what you think: +1 or -1?

If -1, what should we do instead?

Regards,
Remi

Re: [VOTE] Release Apache CloudStack CloudMonkey 5.3.2

[Remi Bergsma]

+1 (binding)

Compiled, installed and did some basic testing. Then run some dev/test scripts 
to deploy test infra with cloudmonkey and that all works fine.

> On 14 Aug 2015, at 11:08, Rohit Yadav  wrote:
> 
> Hi All,
> 
> I've created a 5.3.2 release of CloudMonkey, with the following
> artifacts up for a vote:
> 
> Git Branch and Commit SH:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack-cloudmonkey.git;a=shortlog;h=refs/heads/master
> Commit: 1bc53d20349b6bae4ae4432e7cb6c6261c1dd290
> 
> List of changes:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack-cloudmonkey.git;a=blob_plain;f=CHANGES.md;hb=master
> 
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/cloudmonkey-5.3.2/
> 
> PGP release keys (signed using 0EE3D884):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> 
> Due to upcoming weekends, the vote will be open for 120 hours (or 5 days).
> 
> For sanity in tallying the vote, can PMC members please be sure to
> indicate "(binding)" with their vote?
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Regards.

Re: Remi Bergsma joins the PMC

[Remi Bergsma]

Thanks everyone! Great working with you :-)

> On 11 Aug 2015, at 07:44, Wilder Rodrigues  
> wrote:
> 
> Congratulations, dude!
> 
> Cheers,
> Wilder
> 
> Sent from my iPhone
> 
>> On 10 Aug 2015, at 19:09, Daan Hoogland  wrote:
>> 
>> LS,
>> 
>> Today the PMC has invited Remi Bergsma to join its ranks. I am happy to say
>> that he accepted. Please join me in congratulating Remi.
>> 
>> ​regards,​
>> -- 
>> Daan

Re: [Blocker/Critical] VR related Issues

[Remi Bergsma]

Hi Kishan,

Thanks for your mail, we clearly need to spend some time in debugging and 
fixing these issues. Let me look into the blocking Remote Access VPN issue 
(CLOUDSTACK-8690) and see if I can reproduce / fix it.

Regards,
Remi


> On 11 Aug 2015, at 11:33, Kishan Kavala  wrote:
> 
> Below VR related issues currently open. Most of these issues did not exist in 
> 4.5.x and are related to VR refactor (persistent VR).
> 
> Blocker
> https://issues.apache.org/jira/browse/CLOUDSTACK-8690 - Remote Access VPN not 
> working
> 
> Critical
> https://issues.apache.org/jira/browse/CLOUDSTACK-8688 - Default policy for 
> INPUT and FORWARD chain is ACCEPT in VR filter table (Wilder is working on 
> this) 
> https://issues.apache.org/jira/browse/CLOUDSTACK-8681 - CS does not honor the 
> default deny egress policy in isolated network
> https://issues.apache.org/jira/browse/CLOUDSTACK-8710 - site2site vpn 
> iptables rules are not configured on VR
> https://issues.apache.org/jira/browse/CLOUDSTACK-8685 - Default route is not 
> configured on VPC VR
> https://issues.apache.org/jira/browse/CLOUDSTACK-8694  - Monitor service cron 
> job not visible
> 
> 
> 

Re: Anyone wants to take over these orphaned PRs?

[Remi Bergsma]

Hi Suresh,

Thanks for picking this up! Some PRs got feedback, it’d be great if that could 
be addressed. In a perfect world, changes are submitted with tests. I see many 
reviewers ask for them, so adding them definitely helps in getting LGTMs. 

Not 100% sure what you mean by “Can we take up the testcases for LGTM(s) PRs 
later and merge them”. You want to add the tests later? You can also take some 
more time and send it all in once. No hurries.

Do you want to keep the current PRs open for now or should we close them?

Regards, Remi

> On 10 Aug 2015, at 06:25, Suresh Kumar Anaparti 
>  wrote:
> 
> Hi Remi,
> 
> I'll work on these PRs and finalize them. Will send new PRs for them. As 
> Likitha is not responding, Can we take up the testcases for LGTM(s) PRs later 
> and merge them?  
> 
> Thanks,
> Suresh
> 
> -----Original Message-
> From: Remi Bergsma [mailto:rberg...@schubergphilis.com] 
> Sent: Monday, 10 August 2015 12:20 AM
> To: 'dev@cloudstack.apache.org'
> Subject: Anyone wants to take over these orphaned PRs?
> 
> Hi all,
> 
> These are 9 PRs sent by Likitha. If I understand correctly Likitha is no 
> longer working with Citrix/ACS. The PRs seem mostly VMware related. Some have 
> LGTM(s), most have comments about missing unit tests.
> 
> What do we want to do with them? There's probably not gonna be an update from 
> Likitha, so waiting for that does not make sense. Does anyone wants to step 
> in and finalize a PR? You can get the PR to your own branch and add some work 
> on top of the existing commits and finally send it as a new PR.
> 
> I'll add a comment to each of them. If no one wants to take it over, I think 
> we should close the PRs without merging. It's a pity, but I would rather not 
> have long lists of orphaned PRs laying around. The less PRs are open, the 
> better.
> 
> Any comments?
> 
> Regards,
> Remi
> 
> Cloudstack 8612 [VMware] #562
> https://github.com/apache/cloudstack/pull/562
> 
> CLOUDSTACK-8611. CS waits indefinitely for CheckS2SVpnConnectionsComm... #561
> https://github.com/apache/cloudstack/pull/561
> 
> CLOUDSTACK-8609. [VMware] VM is not accessible after a migration acro... #556
> https://github.com/apache/cloudstack/pull/556
> 
> CLOUDSTACK-8608. [VMware] System VM's failed to start due to permissions 
> issue. #555
> https://github.com/apache/cloudstack/pull/555
> 
> CLOUDSTACK-8610. Unable to attach 7th Disk to Windows Server 2012 R2 ... #554
> https://github.com/apache/cloudstack/pull/554
> ==> This one has 2xLGTM, but also some remarks to add unit tests.
> 
> CLOUDSTACK-8602. MigrateVirtualMachineWithVolume leaves old chain dat... #548
> https://github.com/apache/cloudstack/pull/548
> ==> 1x LGTM
> 
> CLOUDSTACK-8601. VMFS storage added as local storage can be re-added ... #547
> https://github.com/apache/cloudstack/pull/547
> ==> 1x LGTM
> 
> CLOUDSTACK-8599. CS reports failure for a successful migration. #544
> https://github.com/apache/cloudstack/pull/544
> 
> CLOUDSTACK-8415. SSVM shutdown during snapshot operation leaves behin... #540
> https://github.com/apache/cloudstack/pull/540
> 
> 

Re: happy birthday dear cloudstack.git

[Remi Bergsma]

Awesome! Happy birthday :-)

On 10 Aug 2015, at 13:39, Rohit Yadav 
mailto:rohit.ya...@shapeblue.com>> wrote:

Fantastic :)

On 10-Aug-2015, at 3:07 pm, Punith S 
mailto:punit...@cloudbyte.com>> wrote:

Wow! happy birthday cloudstack :)

On Mon, Aug 10, 2015 at 3:03 PM, Wido den Hollander 
mailto:w...@widodh.nl>> wrote:

Congrats! Great :-)

On 10-08-15 11:17, Daan Hoogland wrote:
Ladies and gentleman,

At the 11th of August 2010, Manuel Amador made the first commit in our
repository. I never met the guy but want to take the occasion to
congratulate him and all other contributors with the 5th aniversary of
our
repository.

​:beer::cake::clappinghands:​





--
Regards,

punith s
cloudbyte.com

Regards,
Rohit Yadav
Software Architect, ShapeBlue




M. +91 88 262 30892 | 
rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab




Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: Anyone wants to take over these orphaned PRs?

[Remi Bergsma]

Hi Mike,

Thanks! It seems the testing / verification is still to do and that is the 
work. Merging itself can be done with a one-liner. 

Are you able to verify the fix in your lab?

Sent from my iPhone

> On 10 Aug 2015, at 04:13, Mike Tutkowski  wrote:
> 
> I could take this one:
> 
> CLOUDSTACK-8601. VMFS storage added as local storage can be re-added ...
> #547
> https://github.com/apache/cloudstack/pull/547
> ==> 1x LGTM
> 
> I asked this in the PR discussion, but are we under the impression that
> this code has been tested well enough? If so, I can just merge it as the
> code itself LGTM.
> 
> On Sun, Aug 9, 2015 at 12:49 PM, Remi Bergsma 
> wrote:
> 
>> Hi all,
>> 
>> These are 9 PRs sent by Likitha. If I understand correctly Likitha is no
>> longer working with Citrix/ACS. The PRs seem mostly VMware related. Some
>> have LGTM(s), most have comments about missing unit tests.
>> 
>> What do we want to do with them? There's probably not gonna be an update
>> from Likitha, so waiting for that does not make sense. Does anyone wants to
>> step in and finalize a PR? You can get the PR to your own branch and add
>> some work on top of the existing commits and finally send it as a new PR.
>> 
>> I'll add a comment to each of them. If no one wants to take it over, I
>> think we should close the PRs without merging. It's a pity, but I would
>> rather not have long lists of orphaned PRs laying around. The less PRs are
>> open, the better.
>> 
>> Any comments?
>> 
>> Regards,
>> Remi
>> 
>> Cloudstack 8612 [VMware] #562
>> https://github.com/apache/cloudstack/pull/562
>> 
>> CLOUDSTACK-8611. CS waits indefinitely for CheckS2SVpnConnectionsComm...
>> #561
>> https://github.com/apache/cloudstack/pull/561
>> 
>> CLOUDSTACK-8609. [VMware] VM is not accessible after a migration acro...
>> #556
>> https://github.com/apache/cloudstack/pull/556
>> 
>> CLOUDSTACK-8608. [VMware] System VM's failed to start due to permissions
>> issue. #555
>> https://github.com/apache/cloudstack/pull/555
>> 
>> CLOUDSTACK-8610. Unable to attach 7th Disk to Windows Server 2012 R2 ...
>> #554
>> https://github.com/apache/cloudstack/pull/554
>> ==> This one has 2xLGTM, but also some remarks to add unit tests.
>> 
>> CLOUDSTACK-8602. MigrateVirtualMachineWithVolume leaves old chain dat...
>> #548
>> https://github.com/apache/cloudstack/pull/548
>> ==> 1x LGTM
>> 
>> CLOUDSTACK-8601. VMFS storage added as local storage can be re-added ...
>> #547
>> https://github.com/apache/cloudstack/pull/547
>> ==> 1x LGTM
>> 
>> CLOUDSTACK-8599. CS reports failure for a successful migration. #544
>> https://github.com/apache/cloudstack/pull/544
>> 
>> CLOUDSTACK-8415. SSVM shutdown during snapshot operation leaves behin...
>> #540
>> https://github.com/apache/cloudstack/pull/540
> 
> 
> -- 
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play>*™*

Anyone wants to take over these orphaned PRs?

[Remi Bergsma]

Hi all,

These are 9 PRs sent by Likitha. If I understand correctly Likitha is no longer 
working with Citrix/ACS. The PRs seem mostly VMware related. Some have LGTM(s), 
most have comments about missing unit tests.

What do we want to do with them? There's probably not gonna be an update from 
Likitha, so waiting for that does not make sense. Does anyone wants to step in 
and finalize a PR? You can get the PR to your own branch and add some work on 
top of the existing commits and finally send it as a new PR.

I'll add a comment to each of them. If no one wants to take it over, I think we 
should close the PRs without merging. It's a pity, but I would rather not have 
long lists of orphaned PRs laying around. The less PRs are open, the better.

Any comments?

Regards,
Remi

Cloudstack 8612 [VMware] #562
https://github.com/apache/cloudstack/pull/562

CLOUDSTACK-8611. CS waits indefinitely for CheckS2SVpnConnectionsComm... #561
https://github.com/apache/cloudstack/pull/561

CLOUDSTACK-8609. [VMware] VM is not accessible after a migration acro... #556
https://github.com/apache/cloudstack/pull/556

CLOUDSTACK-8608. [VMware] System VM's failed to start due to permissions issue. 
#555
https://github.com/apache/cloudstack/pull/555

CLOUDSTACK-8610. Unable to attach 7th Disk to Windows Server 2012 R2 ... #554
https://github.com/apache/cloudstack/pull/554
==> This one has 2xLGTM, but also some remarks to add unit tests.

CLOUDSTACK-8602. MigrateVirtualMachineWithVolume leaves old chain dat... #548
https://github.com/apache/cloudstack/pull/548
==> 1x LGTM

CLOUDSTACK-8601. VMFS storage added as local storage can be re-added ... #547
https://github.com/apache/cloudstack/pull/547
==> 1x LGTM

CLOUDSTACK-8599. CS reports failure for a successful migration. #544
https://github.com/apache/cloudstack/pull/544

CLOUDSTACK-8415. SSVM shutdown during snapshot operation leaves behin... #540
https://github.com/apache/cloudstack/pull/540

Re: Super trivial code change and PR

[Remi Bergsma]

We'll live with it this time I'd say ;-) Thanks for bringing it up!

Regards, Remi 

> On 06 Aug 2015, at 08:09, Mike Tutkowski  wrote:
> 
> Fair enough
> 
> Do you want me to revert this one or are we OK to just live with it?
> 
> On Wed, Aug 5, 2015 at 11:57 PM, Remi Bergsma 
> wrote:
> 
>> Hi Mike,
>> 
>> Yes, I want everything to go through a PR.
>> 
>> Otherwise:
>> - there are no Travis CI and other tests run
>> - we need to describe what 'trivial' is and what not
>> - the change is not visible
>> 
>> The goal is a stable master at all times and we cannot reach that with
>> direct commits.
>> 
>> I do get your point, it feels like overhead and more work. You're not
>> bothering! This workflow brings better quality when we all do this. It
>> should be easy to get LGTMs fast on such a PR. Ping the list, as you did
>> with the other PR and it will fly.
>> 
>> Regards, Remi
>> 
>>>> On 06 Aug 2015, at 06:48, Mike Tutkowski 
>>> wrote:
>>> 
>>> Hi everyone,
>>> 
>>> Hopefully this isn't an issue, but I occasionally have super trivial, but
>>> useful changes to SolidFire-only code that I'd like to push without
>>> bothering with a PR.
>>> 
>>> For example:
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob;f=plugins/storage/volume/solidfire/src/org/apache/cloudstack/storage/datastore/lifecycle/SolidFireSharedPrimaryDataStoreLifeCycle.java;h=7cb690014bbc4834c430febe050ccb133528e1fb;hb=2c8d179b7abf6da1c99390788c3329f243e172db
>>> 
>>> In this commit, I renamed two variables to be more descriptive. It only
>>> impacts the SolidFire plug-in and is purely for readability.
>>> 
>>> Does this sound OK to do or do we literally want ever single change (no
>>> matter how trivial) to go in via PR?
>>> 
>>> Thanks!
>>> 
>>> --
>>> *Mike Tutkowski*
>>> *Senior CloudStack Developer, SolidFire Inc.*
>>> e: mike.tutkow...@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the cloud
>>> <http://solidfire.com/solution/overview/?video=play>*™*
> 
> 
> 
> -- 
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play>*™*

Re: Super trivial code change and PR

[Remi Bergsma]

Hi Mike,

Yes, I want everything to go through a PR. 

Otherwise:
- there are no Travis CI and other tests run
- we need to describe what 'trivial' is and what not 
- the change is not visible

The goal is a stable master at all times and we cannot reach that with direct 
commits. 

I do get your point, it feels like overhead and more work. You're not 
bothering! This workflow brings better quality when we all do this. It should 
be easy to get LGTMs fast on such a PR. Ping the list, as you did with the 
other PR and it will fly. 

Regards, Remi 

> On 06 Aug 2015, at 06:48, Mike Tutkowski  wrote:
> 
> Hi everyone,
> 
> Hopefully this isn't an issue, but I occasionally have super trivial, but
> useful changes to SolidFire-only code that I'd like to push without
> bothering with a PR.
> 
> For example:
> 
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob;f=plugins/storage/volume/solidfire/src/org/apache/cloudstack/storage/datastore/lifecycle/SolidFireSharedPrimaryDataStoreLifeCycle.java;h=7cb690014bbc4834c430febe050ccb133528e1fb;hb=2c8d179b7abf6da1c99390788c3329f243e172db
> 
> In this commit, I renamed two variables to be more descriptive. It only
> impacts the SolidFire plug-in and is purely for readability.
> 
> Does this sound OK to do or do we literally want ever single change (no
> matter how trivial) to go in via PR?
> 
> Thanks!
> 
> -- 
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*

Re: s2s vpn related iptables are not applied on VR

[Remi Bergsma]

Hi,

Could you please create an ACS issue for this, so we can track it? Sounds like 
something we need to fix.

Thanks,
Remi

> On 05 Aug 2015, at 14:30, Jayapal Reddy Uradi  
> wrote:
> 
> Hi,
> 
> I haves configured the s2s vpn in vpc network. Observed that the iptables 
> rules related to s2s vpn are not configured on the VR.
> In configure.py there is method 'configure_iptables' which is having rules 
> but these are not getting applied on VR.
> Can you please look into this.
> 
> Also can you please the document to understand the flow of configuration.
> Also in the dev environment when I am working on site to site vpn I want to 
> apply only s2s vpn config not whole config again. Can you also please tell me 
> how can we do this.
> 
> Thanks,
> Jayapal 
> 

Re: [DISCUSS][PROPOSAL] cleanup repo

[Remi Bergsma]

+1

> On 02 Aug 2015, at 15:46, Daan Hoogland  wrote:
> 
> As we are changing our review process I want to clean up the
> repository at apache getting rid of stale branches. Of course the
> release branches of old releases should stay, but a lot of old
> branches have been merged at unknown places in the master or old
> release branches. I want to propose to delete them as much as
> possible.
> 
> - I want to delete any branch that has no commits newer then one year old
> - I want to ask the last commiter on any branch with commits newer
> then one year to review if 'their' branch can be removed
> - All branches that are merged back are to remain untouched.
> 
> ideally only the branches 4.0, 4.1, 4.2, 4.3, 4.4, 4.5 and master will
> remain as branches HEAD. This is unfortunately not true for some older
> releases that were never merged back into their respective release
> branches. Any work in progress will of course not be touched.
> 
> comments?
> -- 
> Daan

ACS 4.6 RC is just around the corner!

[Remi Bergsma]

Hi all,

The last remaining blocker was just resolved! There are some bugs being worked 
on that should be ready in the next couple of days. We will create the RC when 
these issues are resolved:

CLOUDSTACK-8688: Default policy for INPUT and FORWARD chain is ACCEPT in VR 
filter table [1]
CLOUDSTACK-8696: Create Region fails with endpoint parameter validation 
exception [2]
And this Pull Request is merged: 647 [3]

Could anyone that wants to include a Pull Request in the upcoming 4.6 please 
find 2x LGTM asap so we can merge those as well? We plan to create the first RC 
soon.

Please help!
Currently, we have 32 PRs open [4] that are looking forward to their review. 
Please help in reviewing them, so as much as possible can be included in 4.6. 
Especially for bug fixes this is important. If you have a PR open, feel free to 
ask for reviews!

Regards,

Rajani / Remi


[1] https://issues.apache.org/jira/browse/CLOUDSTACK-8688
[2] https://issues.apache.org/jira/browse/CLOUDSTACK-8696
[3] https://github.com/apache/cloudstack/pull/647
[4] https://github.com/apache/cloudstack/pulls

[PROPOSAL] Release principles for Apache CloudStack

[Remi Bergsma]

Hi all,

First of all, thanks for all the feedback! There were two approaches discussed 
to handle bug fixing (as you can read in discussion tread [1]) and we simply 
went ahead and tried them both. That’s how we figured out the best one (we also 
described why we choose this approach over the other). 

The release principles [2] have been updated accordingly on the wiki. The 
difference was in the details only but it was important to understand it fully 
and agree on it before we got started.

We both volunteered to be RM and are now ready to get started!

Regards,
Rajani / Remi


[1] 
http://markmail.org/search/?q=%5BDISCUSS%5D%20Release%20principles%20for%20Apache%20CloudStack#query:%5BDISCUSS%5D%20Release%20principles%20for%20Apache%20CloudStack+page:1+mid:i32jjj5cis223hwd+state:results
[2] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up

Re: [DISCUSS] Release principles for Apache CloudStack

[Remi Bergsma]

I’m back online and will continue working on this as soon as I worked through 
the many mails ;-)

Happy to be your RM together with Rajani!

Regards,
Remi


On 17 Jul 2015, at 17:04, sebgoa mailto:run...@gmail.com>> 
wrote:

Finally read the thread,

It seems to me that a way forward is to have Remi and Rajani RM 4.6 (which is 
currently master).

The two of them can discuss and start RMing 4.6  (PR merge etc) and then we can 
iterate on the wiki release scenario.

@Remi @Rajani, would that work for you and you ready to get started ?

-sebastien


On Jul 10, 2015, at 8:17 PM, Daan Hoogland 
mailto:daan.hoogl...@gmail.com>> wrote:

I hate to be as opiniated as I am but here it comes ;)

On Fri, Jul 10, 2015 at 7:39 PM, Rohit Yadav 
mailto:rohit.ya...@shapeblue.com>>
wrote:

While I like the ideas generally [1], some concerns and observations
that I wish could be considered;

- active contributor crunch:

we don’t have large number of active people working towards testing,
fixing bugs and release, and reviewing/merging PRs on *master*; this
affects the agility of any process or workflow we want to put in, or expect
resolution in a certain window (3-5 days etc.);

​This is a very valid concern. We are a large community but not in any way
big enough. One approach is to let no backporting of bugfixes happen! it
sound contrary to some of your points but I think it is actually a
mitigation (see below).
​


- diverse interests:

our user-base may not necessarily want to upgrade to newer version of
CloudStack even if they can proved to be quite stable; in-fact commercially
some of us are paid to maintain stable branches and support users who are
still on 4.2/4.3/4.4/4.5 etc; based on my experience, a typical enterprise
users usually stick with a version (that works for them) for at least 6
months, while smb user or in-house consumers are quite agile who may
upgrade as quickly as when new releases are made;

​User do go for bug fixes and are not concerned with any backwards
compatible changes to functionality. If we guard against those, point
releases are replaced by the minors and people can be as 'sticky' as they
want. In the end it is a matter of naming and discipline. Of course we need
to sell our policy.
​


- diverse branching/merging workflow usage and understanding:

the bugfix workflow may not be acceptable (to go on master first), a lot
of people have their own way of branching/merging in their organisations
that affect how they do it in the the project

​I do not think it is. If you want something fixed you should fix it on the
oldest version it needs fixing on. No backporting at all. this only
mystifies our git tree and ​

​prohibits good administration. Bug-fixes can be merged forward and whether
anyone has one of infinite other possible​ release management schemes
internally should not influence the way they work on this project.


- waiting time on new changes:

since we don’t have large number of active testers and developers who
can fix bugs rapidly, freezing master and doing the release may take a lot
of time (unless if we can put a hard deadline or have some schedule to
support that?), in which case new features and refactoring work will have
to lay hanging (and some rebase/code-rework may be needed later when they
are merged, when master is open)

​lso very valid. No freeze, just release candidates would be a solution to
that. One point in time is proposed as candidate and voted on. if it goes
it goes, if it doesn't there will be new chances in the near future. We do
depend on good quality control on master for this.
​



- release risk:

after a release x.y.0 is made and since master can receive new features,
refactoring work; the next x.y.1 can potentially add more regressions due
to those new features and refactoring/re-architectural work

​I don't agree here; any x.y.1 will be on a branch other then master.​




- release maintenance and support demands:

historically there has been an assumed or known stable release that is
fairly tested in the wild and has built trust due to usage by users
(through meetups, users ML, customer interactions etc), in the past those
versions were 4.2.1 then 4.3.1/4.3.2, now based on my experience the last
stable release is 4.5.1

​You know we don't agree on 4.4 vs 4.5 and I don't want to fight that fight
here and now but how is this a concern either way? Any minor can have point
releases following it if needed.
​



[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack

On 02-Jul-2015, at 5:16 pm, Remi Bergsma  wrote:

Hi all,

We already agreed contributions should always go via a PR and require two
LGTM’s before we merge. Let me propose the next step on how I think we
should do release management for 4.6 and on.

I talked to several people over the past weeks and wrote this wiki article:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+f

Re: IRC and Slack

[Remi Bergsma]

Hi all,

I setup a gateway that sends messages back and forth. Let me use it for a while 
to so I can tweak it if needed. It also needs to prove how stable this is.

This is what it does:
Freenode #cloudstack <<===>> Slack #general

So, item 3 from the list done and this will help me doing item 2 as well ;-)

Hope this is a good solution for all!

Regards,
Remi


> On 04 Jul 2015, at 18:37 , sebgoa  wrote:
> 
> I think we are all in agreement here, so let's move on with:
> 
> -consolidate #cloudstack and #cloudstack-dev (who can do that ? )
> -let's try to be more present on IRC (that's for everyone )
> -let's try to setup some slack/IRC proxy so that folks who are using Slack 
> right now can make the IRC folks benefit from their conversation. ( I think 
> Remi said he would test something out)
> 
> -sebastien
> 
> 
> On Jul 4, 2015, at 6:27 PM, Remi Bergsma  wrote:
> 
>> John,
>> 
>> All we did was quickly setup as POC to test it out with some folks. I never 
>> said it should replace anything in its current state.
>> 
>> Regards, Remi
>> 
>> 
>> 
>>> On 04 Jul 2015, at 16:32 , John Burwell  wrote:
>>> 
>>> Remi,
>>> 
>>> The fact that a chat channel is limited to those with an @apache.org 
>>> account and requires knowing who to ask for invitation runs counter the 
>>> Apache Way.  Chat channels should be open and discoverable by all.
>>> 
>>> I am with Nux, -1 for anything like Hipchat, Slack, etc.  If some folks 
>>> prefer Slack or Hipchat.  I have no issue with those that wish to run their 
>>> own IRC gateways to these services.  However, I believe the official means 
>>> endorsed by the community should be Freenode.
>>> 
>>> Thanks,
>>> -John
>>> 
>>> ---
>>> John Burwell (@john_burwell)
>>> VP of Software Engineering, ShapeBlue
>>> (571) 403-2411 | +44 20 3603 0542
>>> http://www.shapeblue.com
>>> 
>>> 
>>> 
>>>> On Jul 3, 2015, at 4:17 AM, Remi Bergsma  wrote:
>>>> 
>>>> I setup a proof-of-concept a while back to test it: 
>>>> http://cloudstackdev.slack.com. There currently are around 30 people, 
>>>> mostly dev from this list.
>>>> 
>>>> Anyone with an @apache.org account can sign-up and anyone else could ask 
>>>> me, Daan, Rohit, Wilder or Funs for an invite (for now). I can imagine we 
>>>> setup some other structure for this later on. If you want to be admin, 
>>>> just ping me.
>>>> 
>>>> Regards,
>>>> Remi
>>>> 
>>>> 
>>>>> On 3 jul. 2015, at 10:10, Erik Weber  wrote:
>>>>> 
>>>>> On Fri, Jul 3, 2015 at 9:27 AM, sebgoa  wrote:
>>>>> 
>>>>>> Some great ideas in there.
>>>>>> 
>>>>>> I am +1 for:
>>>>>> 
>>>>>> -consolidate #cloudstack-dev and #cloudstack
>>>>>> -move bots to #cloudstack-announce
>>>>>> -Remi's idea to publish slack message to #cloudstack (and vice versa).
>>>>>> -the idea to use something like discourse or stack overflow etc…
>>>>>> 
>>>>>> Somebody wants to take this on :)
>>>>>> 
>>>>>> 
>>>>> 
>>>>> +1 :-)
>>>>> 
>>>>> Is this slack available already? If so, how do I get an invitation?
>>>>> 
>>>>> --
>>>>> Erik
>>>> 
>>> 
>>> Find out more about ShapeBlue and our range of CloudStack related services
>>> 
>>> IaaS Cloud Design & 
>>> Build<http://shapeblue.com/iaas-cloud-design-and-build//>
>>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>>> CloudStack Software 
>>> Engineering<http://shapeblue.com/cloudstack-software-engineering/>
>>> CloudStack Infrastructure 
>>> Support<http://shapeblue.com/cloudstack-infrastructure-support/>
>>> CloudStack Bootcamp Training 
>>> Courses<http://shapeblue.com/cloudstack-training/>
>>> 
>>> This email and any attachments to it may be confidential and are intended 
>>> solely for the use of the individual to whom it is addressed. Any views or 
>>> opinions expressed are solely those of the author and do not necessarily 
>>> represent those of Shape Blue Ltd or related companies. If you are not the 
>>> intended recipient of this email, you must neither take any action based 
>>> upon its contents, nor copy or show it to anyone. Please contact the sender 
>>> if you believe you have received this email in error. Shape Blue Ltd is a 
>>> company incorporated in England & Wales. ShapeBlue Services India LLP is a 
>>> company incorporated in India and is operated under license from Shape Blue 
>>> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil 
>>> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is 
>>> a company registered by The Republic of South Africa and is traded under 
>>> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>> 
> 

Re: IRC and Slack

[Remi Bergsma]

John,

All we did was quickly setup as POC to test it out with some folks. I never 
said it should replace anything in its current state.

Regards, Remi



> On 04 Jul 2015, at 16:32 , John Burwell  wrote:
> 
> Remi,
> 
> The fact that a chat channel is limited to those with an @apache.org account 
> and requires knowing who to ask for invitation runs counter the Apache Way.  
> Chat channels should be open and discoverable by all.
> 
> I am with Nux, -1 for anything like Hipchat, Slack, etc.  If some folks 
> prefer Slack or Hipchat.  I have no issue with those that wish to run their 
> own IRC gateways to these services.  However, I believe the official means 
> endorsed by the community should be Freenode.
> 
> Thanks,
> -John
> 
> ---
> John Burwell (@john_burwell)
> VP of Software Engineering, ShapeBlue
> (571) 403-2411 | +44 20 3603 0542
> http://www.shapeblue.com
> 
> 
> 
>> On Jul 3, 2015, at 4:17 AM, Remi Bergsma  wrote:
>> 
>> I setup a proof-of-concept a while back to test it: 
>> http://cloudstackdev.slack.com. There currently are around 30 people, mostly 
>> dev from this list.
>> 
>> Anyone with an @apache.org account can sign-up and anyone else could ask me, 
>> Daan, Rohit, Wilder or Funs for an invite (for now). I can imagine we setup 
>> some other structure for this later on. If you want to be admin, just ping 
>> me.
>> 
>> Regards,
>> Remi
>> 
>> 
>>> On 3 jul. 2015, at 10:10, Erik Weber  wrote:
>>> 
>>> On Fri, Jul 3, 2015 at 9:27 AM, sebgoa  wrote:
>>> 
>>>> Some great ideas in there.
>>>> 
>>>> I am +1 for:
>>>> 
>>>> -consolidate #cloudstack-dev and #cloudstack
>>>> -move bots to #cloudstack-announce
>>>> -Remi's idea to publish slack message to #cloudstack (and vice versa).
>>>> -the idea to use something like discourse or stack overflow etc…
>>>> 
>>>> Somebody wants to take this on :)
>>>> 
>>>> 
>>> 
>>> +1 :-)
>>> 
>>> Is this slack available already? If so, how do I get an invitation?
>>> 
>>> --
>>> Erik
>> 
> 
> Find out more about ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Software 
> Engineering<http://shapeblue.com/cloudstack-software-engineering/>
> CloudStack Infrastructure 
> Support<http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training 
> Courses<http://shapeblue.com/cloudstack-training/>
> 
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is a company 
> incorporated in India and is operated under license from Shape Blue Ltd. 
> Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
> operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
> registered by The Republic of South Africa and is traded under license from 
> Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [DISCUSS] Release principles for Apache CloudStack

[Remi Bergsma]

Hi Rajani,

Happy to hear we agree on the goal and on the release process. Also great you 
want to join the RM effort!

What remains is a discussion about the maintenance. I think the difference in 
our approaches, is that you say “commit to release branch, then bring it to 
master” and I say the opposite: “commit to master (pr) and then bring to 
release branch”. There are pros/cons for each.

Let’s first see if we agree on more parts:
- maintenance releases for x.y should only receive bug fixes, no new features
- we should release often and only maintain the current x.y release (and master 
obviously)
- upgrades should be smooth so there is no reason to stay on older releases (we 
should help users upgrade)

I’m trying to understand how the merge workflow would look like. As I’m not a 
hardcore dev, I probably just miss the experience. Let me play a bit with it in 
order to get a good understanding of what you say. That makes it a better 
discussion later on.

Have a nice weekend,

Regards,
Remi


> On 3 jul. 2015, at 13:01, Rajani Karuturi  wrote:
> 
> I agree to the goal. No regressions can be achieved either by cherry-picks
> or merges. Both requires developers to agree to it and has equal
> probability to miss.
> 
> The advantage in case of merge is, lets say you do a commit a1 to 4.5
> branch and forget to merge to master. now, someone else did a2 and is
> trying to merge. He will see both the commits and can make choice either to
> ask about a1 or merge both.
> may be if the merge has conflicts or is not a clean merge, it can be done
> as PR which follows the usual process.
> 
> with respect to refactoring, we can always do separate PRs on master and
> the release branch. The merge from release branch to master in this case
> would be an empty merge (git merge -s ours)
> 
> The problem I see with the current approach is its not always backporting
> the fix to release. This works if the issue reported is already known and
> fixed on master or any forward releases.
> Usually, you work on a release branch only when an issue is reported on it.
> For a issue reported on 4.5, first thing I do is check if the issue really
> exists in 4.5 and would also find the solution around the same time. Its
> sounds natural to me to push to 4.5(get the load off your head whether it
> is customer issue or security issue) and then merge to forward releases.
> Now, with the new process, I will have to first verify if the bug exists in
> the current release+1, fix in it first, then go back to release branch,
> verify if it exists and fix it there.
> Obviously there would be exceptions in merging and you may have to
> cherry-pick once in a while. But, making it the process is what concerns me.
> 
> 
> In addition to the goal mentioned, I would also like to find which all
> versions the commit is present in.
> For example, If a security issue is reported on 4.5, I found that this is a
> regression from commit abcde. Now, I would like to find which all version
> this is present as this security patch should be delivered on all the
> versions.
> In the current situation and also in the new process suggested, the only
> way to find it is to go to each and every release and see if the commit is
> present.
> In the merge route, its simple git merge --contains abcde
> 
> Merging is not easy. It requires discipline. But, it has benefits. If
> everyone follows it, its as easy as cherry-picking as the code diff will be
> exactly same.
> 
> 
> Maintaining a release is the second part of the story :) I do agree with
> you on the release process for 4.6. Lets start with it for 4.6 release and
> continue discussing on how we want to maintain 4.6.x(may be we would never
> need one ;))
> 
> I can volunteer to be the additional RM for 4.6.
> 
> 
> ~Rajani
> 
> On Fri, Jul 3, 2015 at 1:36 PM, Remi Bergsma  <mailto:r...@remi.nl>> wrote:
> 
>> Hi Rajani, all,
>> 
>> I do think we have the same goal in mind: no regression and no cherry-pick
>> mess.
>> 
>> Just did some reading on "tofu scale" and see two issues:
>> - if it doesn't happen / isn't completed we'll have regression as we've
>> seen before. I want a working model that prevents regression by default or
>> else we will not reach smooth upgrades without introducing old bugs again.
>> - we are doing lots of refactoring work (probably will be doing even more)
>> where this model also will not work because the merge fails to apply
>> cleanly (this is what Erik mentioned yesterday). Fixing that conflict is
>> invisible on the dev-list (as we have no PR) and error prone (not tested
>> before commit, no LGTMs).
>> 
>> Don’t get me wrong, I don’t want the cherry-pick mess we 

Re: [DISCUSS] LTS releases?

[Remi Bergsma]

Agree with the ideal world scenario :-)

If we look at it from the other side: Why is it that people want to stay on 
older releases?

From personal experience I know that in the beginning the 4.4 release wasn’t 
that stable. I upgraded production systems from 4.3.0 to 4.4.2 and it was 
painful. That is not true anymore today, as 4.4.4 is pretty nice. From what I 
hear, 4.5.1 is also doing well. Great steps have been made already to make sure 
this will not happen again.

Still, I can imagine that this may have scared some people and it made them 
stay where they are (at 4.3). Let’s investigate if people running 4.3 want to 
upgrade to 4.5.x or the upcoming 4.6 and, more important, why not? Then let’s 
fix that or prove it works.

Regards,
Remi


> What is *our* plan :)
> 
> We used to only maintain the last two major releases.
> 
> We diverged from that model when 4.5.0 came out and that we still wanted to 
> maintain 4.3 because 4.3 was working so well for people.
> 
> My personal preference would be to get into a rolling release model, where we 
> maintain only the last major release.
> This is why making master stable and the base for all our releases is so 
> important.
> 
> Users should get into a model where they continuously upgrade/deploy and 
> don't get stuck on a unmaintained branch with forks that prevents upgrade.
> 
> When users face an issue, we patch and release, then they upgrade always to 
> the latest version.
> 
> That's the ideal world :)

Re: IRC and Slack

[Remi Bergsma]

Yes, I’ll have some time off coming up so I’ll give it a go.

> any chance you can try that IRC/Slack integration pointing to #cloudstack ?

Re: IRC and Slack

[Remi Bergsma]

I setup a proof-of-concept a while back to test it: 
http://cloudstackdev.slack.com. There currently are around 30 people, mostly 
dev from this list.

Anyone with an @apache.org account can sign-up and anyone else could ask me, 
Daan, Rohit, Wilder or Funs for an invite (for now). I can imagine we setup 
some other structure for this later on. If you want to be admin, just ping me.

Regards,
Remi
 

> On 3 jul. 2015, at 10:10, Erik Weber  wrote:
> 
> On Fri, Jul 3, 2015 at 9:27 AM, sebgoa  wrote:
> 
>> Some great ideas in there.
>> 
>> I am +1 for:
>> 
>> -consolidate #cloudstack-dev and #cloudstack
>> -move bots to #cloudstack-announce
>> -Remi's idea to publish slack message to #cloudstack (and vice versa).
>> -the idea to use something like discourse or stack overflow etc…
>> 
>> Somebody wants to take this on :)
>> 
>> 
> 
> +1 :-)
> 
> Is this slack available already? If so, how do I get an invitation?
> 
> -- 
> Erik

Re: [DISCUSS] Release principles for Apache CloudStack

[Remi Bergsma]

Hi Rajani, all,

I do think we have the same goal in mind: no regression and no cherry-pick mess.

Just did some reading on "tofu scale" and see two issues:
- if it doesn't happen / isn't completed we'll have regression as we've seen 
before. I want a working model that prevents regression by default or else we 
will not reach smooth upgrades without introducing old bugs again. 
- we are doing lots of refactoring work (probably will be doing even more) 
where this model also will not work because the merge fails to apply cleanly 
(this is what Erik mentioned yesterday). Fixing that conflict is invisible on 
the dev-list (as we have no PR) and error prone (not tested before commit, no 
LGTMs).

Don’t get me wrong, I don’t want the cherry-pick mess we experienced before.

What will be different:
- master is stable instead of unstable
- we’ll branch off x.y (say 4.6 which is up next) only after a vote on a RC 
passes. Instead of branching it off first, then make it stable and release it 
and cherry-pick stuff around. So, no cherry-picking here.
- once the x.y branch is there, we should do no back ports of features. Only 
(critical?) bug fixes. 

Those bug fixes (that went to master first through PR and got 2x LGTM) could 
now also be applied to the x.y. branch (and become x.y.1 or similar) Instead of 
cherry-picking, I’d apply the same PR to x.y (if possible, or else a new PR 
that reimplements the fix for x.y in which case it would need its own 2x LGTM). 
In any bug fix PR we should mention the jira bug id (and PR id) in the commit 
message. This, you could argue, is like cherry-picking as it makes a new commit 
id. As the amount of bug fix commits should me minimal, I think this is ok.

We should make sure upgrades are so smooth that our users can upgrade easily 
and we don’t have to maintain previous releases for a long time.

I clarified some more things on the wiki and also updated the diagrams.

Regards,
Remi


> On 3 jul. 2015, at 04:29, Rajani Karuturi  wrote:
> 
> I do not agree to backporting aka cherry picking. I prefer forward
> merges(tofu scale) 4.4 to 4.5 to master etc.
> That way, none of the changes will be missed and git branch --contains
> gives a nice view of where all the changes went.
> 
> 
> On Thu, Jul 2, 2015 at 23:16 PM, Remi Bergsma  <mailto:r...@remi.nl>> wrote:
> 
> Hi Daan,
> 
> Indeed. I prefer committing to master first, as it will ensure everything
> ends up there (unless some specific use cases). Currently, we have the risk
> of forgetting to include a fix to a release branch back to master.
> 
> When we reverse it, some bug fix that should end up in the x.y branch, is
> committed to master, then also applied (or reimplemented) to x.y. If you
> then only take one of the two steps, there is no issue as it will be in
> master only (and people will notice). In the other situation, when we
> accept a PR to x.y and forget to merge back, we possibly introduce
> regression bugs.
> 
> I will update the diagram and wiki later tonight.
> 
> While reviewing PRs, let’s be alert to see PRs not pointed towards master
> and at least discuss it.
> 
> Regards,
> Remi
> 
> 
>> On 2 jul. 2015, at 16:54, Daan Hoogland  > wrote:
>> 
>> On Thu, Jul 2, 2015 at 2:29 PM, Remi Bergsma > <mailto:r...@remi.nl> >
> wrote:
>>> Since the goal is a stable master, I’d say the bug fix should go to
> master first.
>> 
>> 
>> Remi, this means that merge back of the branch makes no sense anymore.
>> 
>> --
>> Daan
> 
> 
> 
> -- 
> -
> Sent from Windows Phone
> ~Rajani

Re: [DISCUSS] Release principles for Apache CloudStack

[Remi Bergsma]

> On 3 jul. 2015, at 09:21, sebgoa  wrote:
> 
> On Jul 3, 2015, at 9:06 AM, Raja Pullela  wrote:
> 
>> Remi, 
>> 
>> couple of questions on the branching part - when we take the Feature PR and 
>> Feature is back in Master, feel like we are potentially destabilizing Master 
>> ?   I know, currently we push changes to master even before anything is 
>> tested fully - agree, we are now running the Travis test before a checkin - 
>> however, I feel those are not sufficient ?  
>> 
>> IMHO - we should take a release branch open it up for PR/checkins and once 
>> the testing is done the branch gets into Master - we take RC from the master 
>> and release it.  That way no one checkins to master and constantly tested 
>> changes get into/merged to master.  
>> 
>> I remember seeing similar changes proposed by few folks... I have been 
>> little out of touch on those changes.
>> 
> 
> Basically yes, we should not merge untested, unfinished features in master


Exactly. Whatever is merged to master “should just work (tm)”. 
The purpose of having people say this "LGTM", is also to have them verify / 
test it. In a perfect world this testing is automated. Until we’re there, we 
need to rely on people to do this. 

Regards, Remi

Re: [DISCUSS] 4.5.2 bugfix sprint

[Remi Bergsma]

Hi Rohit,

Could you see if you can add this bug fix as well? It fixes the X-Forwarded-For 
header in HAProxy.
https://github.com/apache/cloudstack/pull/549

Thanks,
Remi


> On 25 jun. 2015, at 21:35, Rohit Yadav  wrote:
> 
> Hi all,
> 
> Now that 4.4.4 has passed, I would like to start a 4.5.2 release effort soon. 
> Please share any blockers, critical issues and other problems you may have 
> discovered with 4.5.1 that we should try to fix in ACS 4.5.2.
> 
> Thanks.
> 
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
> 
> 
> 
> Find out more about ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design & Build
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Software 
> Engineering
> CloudStack Infrastructure 
> Support
> CloudStack Bootcamp Training 
> Courses
> 
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is a company 
> incorporated in India and is operated under license from Shape Blue Ltd. 
> Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
> operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
> registered by The Republic of South Africa and is traded under license from 
> Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: IRC and Slack

[Remi Bergsma]

What if we use the best of both worlds, by using something like [1]?

We obviously need to dive a bit into this and see how well it works. There 
might be alternatives. The benefit of such a solution would be that if you 
could see messages on IRC in Slack and v.v. that would make them more visible.

It could also solve the IRC history and mobile client issues.

Regards,
Remi

[1] https://github.com/ekmartin/slack-irc


> On 2 jul. 2015, at 21:15, John Burwell  wrote:
> 
> All,
> 
> For me, the most significant issues with IRC is that there is no searchable 
> history, backlog to catch up when offline, or good mobile clients (yes, 
> mobile IRC clients exists, but work poorly in my view).  While some of these 
> solutions can be solved by running an IRC proxy such as znc or using a 
> service such as IRCcloud, it far more effort than Slack.
> 
> On the other side, as Rene mentions, Freenode is the Github of open source 
> chat (or, since Freenode is older, one could say that Github is the Freenode 
> of open source code hosting).  People go to #cloudstack on Freenode 
> reflexively.  I would bet that they often arrive at the channel without 
> consulting cloudstack.apache.org.  For me, the value of being part of the hub 
> of open source chat trumps the creature comforts offered by Slack because it 
> brings in more people.
> 
> For these reasons, I am -1 on moving away from Freenode.  I also like the 
> idea of getting the ASFbot notifications out of channel.  I also think it 
> would beneficial to consolidate #cloudstack and #cloudstack-dev.  Exposing 
> users to development conversations seems very beneficial to me.
> 
> Thanks,
> -John
> 
> ---
> John Burwell (@john_burwell)
> VP of Software Engineering, ShapeBlue
> (571) 403-2411 | +44 20 3603 0542
> http://www.shapeblue.com
> 
> 
> 
>> On Jul 2, 2015, at 5:07 AM, Rene Moser  wrote:
>> 
>> Hi
>> 
>> On 02.07.2015 10:39, Sebastien Goasguen wrote:
>>> We need to take a decision here. Shall we officially abandon IRC and out a 
>>> notice there that points towards Slack.
>> 
>> -1 for abondon IRC.
>> 
>> * IRC is simple and easy, well known and distributed. Not every question
>> fits to IRC, thats ok. If it gets too complicated ML is preferred.
>> 
>> * IRC freenode is the convention of how to get direct contact to devs of
>> any open source project without need of invitation and email
>> registration, and saved me "my ass" several times...
>> 
>> Yours
>> René
> 
> Find out more about ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design & Build
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Software 
> Engineering
> CloudStack Infrastructure 
> Support
> CloudStack Bootcamp Training 
> Courses
> 
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is a company 
> incorporated in India and is operated under license from Shape Blue Ltd. 
> Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
> operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
> registered by The Republic of South Africa and is traded under license from 
> Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [ANNOUNCE] Karen Voung as a new PMC member of CloudStack

[Remi Bergsma]

Congratulations Karen! :-)

> On 02 Jul 2015, at 20:15, John Burwell  wrote:
> 
> All,
> 
> The Project Management Committee (PMC) for Apache CloudStack are pleased to 
> announce that Karen Voung (karenv) has accepted our invitation to join the 
> PMC.
> 
> Please join me in congratulating her.
> 
> On behalf of the Apache CloudStack PMC,
> -John Burwell
> 
> ---
> John Burwell (@john_burwell)
> VP of Software Engineering, ShapeBlue
> (571) 403-2411 | +44 20 3603 0542
> http://www.shapeblue.com
> 
> 
> 
> Find out more about ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design & Build
> CSForge - rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Software 
> Engineering
> CloudStack Infrastructure 
> Support
> CloudStack Bootcamp Training 
> Courses
> 
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is a company 
> incorporated in India and is operated under license from Shape Blue Ltd. 
> Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
> operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
> registered by The Republic of South Africa and is traded under license from 
> Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [DISCUSS] Release principles for Apache CloudStack

[Remi Bergsma]

Hi Daan,

Indeed. I prefer committing to master first, as it will ensure everything ends 
up there (unless some specific use cases). Currently, we have the risk of 
forgetting to include a fix to a release branch back to master. 

When we reverse it, some bug fix that should end up in the x.y branch, is 
committed to master, then also applied (or reimplemented) to x.y. If you then 
only take one of the two steps, there is no issue as it will be in master only 
(and people will notice). In the other situation, when we accept a PR to x.y 
and forget to merge back, we possibly introduce regression bugs.

I will update the diagram and wiki later tonight.

While reviewing PRs, let’s be alert to see PRs not pointed towards master and 
at least discuss it.

Regards,
Remi


> On 2 jul. 2015, at 16:54, Daan Hoogland  wrote:
> 
> On Thu, Jul 2, 2015 at 2:29 PM, Remi Bergsma  wrote:
>> Since the goal is a stable master, I’d say the bug fix should go to master 
>> first.
> 
> 
> Remi, this means that merge back of the branch makes no sense anymore.
> 
> -- 
> Daan

Re: [DISCUSS] LTS releases?

[Remi Bergsma]

Bug fixing in older releases is actually a lot of work. For security related 
issues we could maybe do it. 

Personally, I prefer to have a fast release cycle and smooth (tested) upgrade 
paths over 2-year LTS release cycle. It's more agile. As a bonus, people get 
the new features. 

The more people do upgrades that work (tm) the more confident they are. I'd 
really want to show that upgrades work so well that we need no LTS. 

But there might be other reasons people have where LTS would help. Please share!

Regards, Remi 


> On 02 Jul 2015, at 16:25, Rene Moser  wrote:
> 
> Maybe a little bit off topic to the new release process, therefor a new
> thread...
> 
> speaking about releases. I just thought about supporting LTS releases.
> 
> This would mean "someone" or "we" make a commitment to add bug fixes
> (only) for a specified time. e.g. 2 years for a release or until the
> next LTS release?
> 
> Would this something anyone would be interested in?
> 
> Yours
> René

Re: [DISCUSS] Release principles for Apache CloudStack

[Remi Bergsma]

Hi René,

The reason is that I tried to stay close to how it is done now so we could 
reuse the scrips. 

You do have a valid point, as indeed no commits are expected (nor should be 
allowed) until the vote passes. 

Pinging @dahn to ask if he knows of other reasons to use a branch for RC and if 
he foresees any issues if we'd switch to a release tag instead (and branch off 
of it once vote passes). 

Regards, Remi 


> On 02 Jul 2015, at 16:16, Rene Moser  wrote:
> 
> Hi Remi
> 
>> On 02.07.2015 13:46, Remi Bergsma wrote:
>> I talked to several people over the past weeks and wrote this wiki article:
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack
>>  
>> <https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack>
>>  
>> 
>> If you like this way of working, I volunteer to be your RM :-)
> 
> It is always good to see this release process which looks +/- identical
> to successful Linux kernel release process. :)
> 
> The only thing I am curious about, if I get it right:
> 
> Why do you branch off for RC? Why not just "tag" a commit in branch
> master as RC and branch off once it is releases from a release tag v.x.y?
> 
> Because it is unlikely you make any commits on that branch anyway. Or
> did I miss anything?
> 
> Yours
> René
> 
> 
> 

Re: [DISCUSS] Release principles for Apache CloudStack

[Remi Bergsma]

Thanks! Appreciate it :-)

> On 02 Jul 2015, at 13:51, Daan Hoogland  wrote:
> 
> be sure you're backed
> 
>> On Thu, Jul 2, 2015 at 1:46 PM, Remi Bergsma  wrote:
>> Hi all,
>> 
>> We already agreed contributions should always go via a PR and require two 
>> LGTM’s before we merge. Let me propose the next step on how I think we 
>> should do release management for 4.6 and on.
>> 
>> I talked to several people over the past weeks and wrote this wiki article:
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack
>>  
>> <https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack>
>> 
>> If you like this way of working, I volunteer to be your RM :-)
>> 
>> Like folks suggested earlier, it would be nice to work on this with multiple 
>> people. So, feel free to join. Maybe @dahn @bhaisaab and/or others are 
>> willing to teach me some of their tricks.
>> 
>> Regards,
>> Remi
> 
> 
> 
> -- 
> Daan

Re: [DISCUSS] Release principles for Apache CloudStack

[Remi Bergsma]

Hi Erik, Kishan,

Since the goal is a stable master, I’d say the bug fix should go to master 
first. This way we make sure all upcoming releases have the fix included. I’ll 
add this to the wiki. 

Then we should decide if the fix should go back to other release branches as 
wel. 
When we get a PR that is not against master, we should be extra careful. Maybe 
we should ask people to specify why they want to do this. There could be a 
valid reason, of course. The danger is introducing old bugs again if people 
upgrade and I want to prevent that.

In Erik’s example:
The first PR is against master and fixes SomeRandomFunction(). Now we know any 
release branched off master has this fix.
If we decide we want to fix 4.6 as well, a second PR should be created against 
4.6 (reimplementation of the fix to older version as per Erik's example).

In a perfect world we should be able to merge back from 4.6 to master. But for 
example i case of refactoring this is not possible.

Regards,
Remi


> On 2 jul. 2015, at 14:05, Erik Weber  wrote:
> 
> How about bugfix PRs that involves refactored code between versions?
> 
> Example:
> 
>   - 4.6.0 is released
>   - SomeRandomFunction() is refactored
>   - 4.7.0 is released
>   - A bug is discovered in SomeRandomFunction() and applies to both 4.6.0
>   and 4.7.0
>   - A bugfix PR is sent to the 4.6 branch
> 
> I understand that the code has to be ported to both versions, but how do we
> ensure/enforce that it actually happens?
> 
> -- 
> 
> Erik
> 
> On Thu, Jul 2, 2015 at 2:03 PM, Kishan Kavala 
> wrote:
> 
>> Remi,
>> Release process looks good to me. Can you also add some info about
>> maintenance release?
>> - After release, will the fixes go into x.y branch and merged back to
>> master?
>> - or bug fixes go into master and selectively merged back to x.y branch?
>> 
>> 
>> -Original Message-
>> From: Remi Bergsma [mailto:r...@remi.nl]
>> Sent: 02 July 2015 17:17
>> To: 
>> Subject: [DISCUSS] Release principles for Apache CloudStack
>> 
>> Hi all,
>> 
>> We already agreed contributions should always go via a PR and require two
>> LGTM’s before we merge. Let me propose the next step on how I think we
>> should do release management for 4.6 and on.
>> 
>> I talked to several people over the past weeks and wrote this wiki article:
>> 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack
>> <
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack
>>> 
>> 
>> If you like this way of working, I volunteer to be your RM :-)
>> 
>> Like folks suggested earlier, it would be nice to work on this with
>> multiple people. So, feel free to join. Maybe @dahn @bhaisaab and/or others
>> are willing to teach me some of their tricks.
>> 
>> Regards,
>> Remi
>> 
>> 

[DISCUSS] Release principles for Apache CloudStack

[Remi Bergsma]

Hi all,

We already agreed contributions should always go via a PR and require two 
LGTM’s before we merge. Let me propose the next step on how I think we should 
do release management for 4.6 and on.

I talked to several people over the past weeks and wrote this wiki article:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack
 

 

If you like this way of working, I volunteer to be your RM :-)

Like folks suggested earlier, it would be nice to work on this with multiple 
people. So, feel free to join. Maybe @dahn @bhaisaab and/or others are willing 
to teach me some of their tricks.

Regards,
Remi

Re: [ANNOUNCE] Wilder Rodrigues as a new PMC member of CloudStack

[Remi Bergsma]

Awesome news Wilder! :-)

Sent from my iPhone

> On 01 Jul 2015, at 19:12, Rohit Yadav  wrote:
> 
> The Project Management Committee (PMC) for Apache CloudStack are pleased to 
> announce that Wilder  Rodrigues (ekho) has accepted our invitation to join 
> the PMC.
> 
> Please join me in congratulating him.
> 
> On behalf of the Apache CloudStack PMC,
> Rohit Yadav
> 
> ---
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
> 
> Find out more about ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design & Build
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Software 
> Engineering
> CloudStack Infrastructure 
> Support
> CloudStack Bootcamp Training 
> Courses
> 
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is a company 
> incorporated in India and is operated under license from Shape Blue Ltd. 
> Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
> operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
> registered by The Republic of South Africa and is traded under license from 
> Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [PROPOSAL] Commit to master through PR only

[Remi Bergsma]

Let’s do it!

Starting tomorrow we’ll commit to master through PR only (as described below), 
and we’ll evaluate this at Sept 30, 2015. 

I’ll put a reminder in my schedule to start the thread.

Regards,
Remi

> On 26 jun. 2015, at 23:10, Daan Hoogland  wrote:
> 
> date := 2015-09-30 ???
> 
> On Fri, Jun 26, 2015 at 9:54 PM, David Nalley  wrote:
>> On Thu, Jun 25, 2015 at 10:38 AM, Sebastien Goasguen  
>> wrote:
>>> Folks,
>>> 
>>> A few of us are in Amsterdam at DevOps days. We are chatting about release 
>>> management procedure.
>>> Remi is working on a set of principles that he will put on the wiki to 
>>> start a [DISCUSS].
>>> 
>>> However to get started on the right track. I would like to propose the 
>>> following easy step:
>>> 
>>> Starting Monday June 29th (next monday):
>>> 
>>> - Only commit through PR will land on master (after a minimum of 2 LGTM and 
>>> green Travis results)
>>> - Direct commit will be reverted
>>> - Any committer can merge the PR.
>>> 
>>> Goal being to start having a new practice -everything through PR for 
>>> everyone- which is an easy way to gate our own commits building up to a PR.
>>> 
>>> There is no tooling involved, just human agreement.
>>> 
>>> cheers,
>>> 
>>> -Sebastien
>> 
>> In general, +1
>> I think we should set a time, say a month or two out, to review how
>> well it has worked, and what we need to tweak to make things better. I
>> think we should be explicit with this so that we can say 'On $date'
>> we'll start a thread to talk about what has and hasn't worked and how
>> we can improve this.
>> 
>> --David
> 
> 
> 
> -- 
> Daan

Re: [PROPOSAL] Commit to master through PR only

[Remi Bergsma]

Good point Daan, I like it!

2015-06-25 16:49 GMT+02:00 Daan Hoogland :

> I still don't think travis is reliable enough to give a definite 'no'.
> Two LGTMs is fine and a good argument if travis is red on why this is
> not a problem for this case.
>
> On Thu, Jun 25, 2015 at 4:47 PM, Rafael Fonseca 
> wrote:
> > Couldn't make it either :'(
> >
> > I think it's a very sound idea in principle, but afraid waiting for two
> > LGTM might slow things down even further... up to the majority vote i
> guess
> > it's a good principle either way :)
> >
> > On Thu, Jun 25, 2015 at 4:41 PM, Wido den Hollander 
> wrote:
> >
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >>
> >>
> >> On 06/25/2015 04:38 PM, Sebastien Goasguen wrote:
> >> > Folks,
> >> >
> >> > A few of us are in Amsterdam at DevOps days. We are chatting about
> >> > release management procedure. Remi is working on a set of
> >> > principles that he will put on the wiki to start a [DISCUSS].
> >> >
> >>
> >> Bummer I couldn't make it :(
> >>
> >> > However to get started on the right track. I would like to propose
> >> > the following easy step:
> >> >
> >> > Starting Monday June 29th (next monday):
> >> >
> >> > - Only commit through PR will land on master (after a minimum of 2
> >> > LGTM and green Travis results) - Direct commit will be reverted -
> >> > Any committer can merge the PR.
> >> >
> >> > Goal being to start having a new practice -everything through PR
> >> > for everyone- which is an easy way to gate our own commits building
> >> > up to a PR.
> >> >
> >>
> >> I'd say this is a good idea :-)
> >>
> >> > There is no tooling involved, just human agreement.
> >> >
> >> > cheers,
> >> >
> >> > -Sebastien
> >> >
> >> -BEGIN PGP SIGNATURE-
> >> Version: GnuPG v1
> >>
> >> iQIcBAEBAgAGBQJVjBMAAAoJEAGbWC3bPspCRYkP/jGuB3qelhlwNKY0UJZVs43T
> >> wh3+8TKO2OTuchR4TLqJDLpWcpaHYamxukDDwNyI2+7hpZuNNnT6t4KhA5CpSITj
> >> BVa8M9nBJAKXjPcnSPNCE8RYA6BPfwnywupwA294rnNcclDurzdHd6WssE0VCH0g
> >> XDM8vuA1tKx55B5TTQSNwDNdlai6aaB/xTQRoFXQWEUwwkyDZF16kvYvglhycVKn
> >> hpg/tpl4VEGCA3G5ddX3fFGDYYUFYoAYO62zpLaq9xUQN2iVny3LO9LhznfXqUc2
> >> XUaksY9hW/8HgaeipbbbWekRZ3J/XCc9/fchFna41WlJOxju49Do5nVTtV3UdBVh
> >> BVBW7NTmnlX3Bs9zyFyp21SIvbQMRDLTolHx0GH9rPhU34l9ww/10MEBPNP0wS7K
> >> Xg/0TpsAviUijqKjxNbXMG+bTaPMrUtDHuoJMWUbGf+KVHVlUdNvshaURlL8SAFW
> >> CIRWhj5Ww+rRyIrpXjC7zXv/qg7aTPD1e02nV7XfoldyDRe72QUmwa7umwZkjvQ6
> >> r9Fxu9S0fySbakAWxYVGjQbCpK+xGCY0ndzH/eYNnf8SX2MGIEKapbJ0kkTWvTu7
> >> aQvV/Y9hLAGMNlYCPiAK4eBFgNc7wdG/D+ZZ6t8Oxmb5O9WMlBCddvvX4mn5UlIo
> >> gbjGNJ/+Swk3z4potjpD
> >> =SkOY
> >> -END PGP SIGNATURE-
> >>
>
>
>
> --
> Daan
>

Re: Build environment stability

[Remi Bergsma]

+1! Thanks guys :-)

> On 22 Jun 2015, at 07:38, Rajani Karuturi  wrote:
> 
> Thanks for all the hard work Rafeal and Daan. much needed fixes.
> 
> ~Rajani
> 
> On Mon, Jun 22, 2015 at 2:35 AM, Rafael Fonseca 
> wrote:
> 
>> Hi all,
>> 
>> Sorry for the 100+ SPAM mails from asfbot caused by me, this was a good
>> weekend for the Cloudstack build environment though :)
>> 
>> - jenkins-slow-build is now sucessful:
>> Daan worked very hard on this to get it running properly, we now have
>> proper alerting for bad practice/bugs on new code ... thanks Daan :)
>> 
>> - Travis timeouts/failures
>> PR #482 fixed a few problems that were causing failures, not a single false
>> positive since it has been merged.. and i gave travis quite some work to do
>> :)
>> 
>> - Jenkins OVM3 failure
>> PR #497 fixes the problem.. gave me some work to debug but it's done! will
>> no longer get those anoying FAILURE messages from jenkins when your code is
>> proper after this one is also merged.
>> 
>> Happy Cloudstacking to all :)
>> 
>> Rafael
>> 

Re: [VOTE] release candidate 4.4.4 (4.4-RC20150618T1117)

[Remi Bergsma]

Hi Daan,

Thanks for fixing and testing it! After DevOpsDays Ams I will also give it a go.

I can prepare a PR for the release notes and document the new setting. You can 
then merge it when the release passes. Or should we do this in another way?

Regards,
Remi


> On 22 Jun 2015, at 16:35, Daan Hoogland  wrote:
> 
> tested specifically the blocker issue in a two host cluster with an
> isolated network.
> 
> both the option values false and true gave expected result on setting
> router.reboot.when.outofband.migrated
> 
> based on this behavior and the fact that setup worked smoothly
> 
> +1 (binding)
> 
> one point of attention is that a remark on this option should go in
> the release notes.
> 
> On Sat, Jun 20, 2015 at 8:49 PM, Milamber  wrote:
>> Hello,
>> 
>> +1 (binding)
>> 
>> Tests on Ubuntu 14.04.2 (1 mgr, 2 nodes, 1 nfs), advanced network fresh
>> install, NFS storage, KVM, some tests on HA (crash vm/restore), SystemVM
>> shape, some tests with templates, and CS<->cloud-init on debian.
>> 
>> Tests on Ubuntu 14.04.2 (All-in-one ansible installation[1]), advanced
>> network fresh installation
>> 
>> Thanks for the RM.
>> 
>> Milamber
>> 
>> [1] https://github.com/milamberspace/ansible-cloudstack-ubuntu-aio
>> 
>> 
>> 
>> On 18/06/2015 09:24, Daan Hoogland wrote:
>>> 
>>> Hi All,
>>> 
>>> I've created a 4.4.4 release, with the following artifacts up for a vote:
>>> 
>>> Git Branch and Commit SH:
>>> 
>>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20150618T1117
>>> Commit: 6f41061e1428527c3f826d268377557ce607196b
>>> 
>>> List of changes:
>>> 
>>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/tags/4.4.4
>>> 
>>> Source release (checksums and signatures are available at the same
>>> location):
>>> https://dist.apache.org/repos/dist/dev/cloudstack/4.4.4/
>>> 
>>> PGP release keys (signed using 5AABEBEA):
>>> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>>> 
>>> Vote will be open for 72 hours.
>>> 
>>> For sanity in tallying the vote, can PMC members please be sure to
>>> indicate "(binding)" with their vote?
>>> 
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>> 
>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Daan

Re: devopsdays amsterdam

[Remi Bergsma]

@seb: cool!

I'll be there too and host a CloudStack hands-on workshop on Wednesday. 

Regards, Remi 


> On 17 Jun 2015, at 14:06, sebgoa  wrote:
> 
> I am coming over.
> 
> 
>> On Jun 17, 2015, at 1:54 PM, Daan Hoogland  wrote:
>> 
>> H,
>> 
>> Who are going, next week?
>> 
>> -- 
>> Daan
> 

Re: [GitHub] cloudstack pull request: CLOUDSTACK-8545 make reboot on out of ban...

[Remi Bergsma]

Thanks for picking this up!

LGTM, I'll try to test it tomorrow. 

One comment: I'd propose the setting name to reflect 'out of band'. Now it 
looks like when you migrate a router in ACS it will also reboot. 

router.reboot.when.outofband.migrated?

Regards, Remi 


Sent from my iPhone

> On 16 Jun w2015, at 17:20, DaanHoogland  wrote:
> 
> GitHub user DaanHoogland opened a pull request:
> 
>https://github.com/apache/cloudstack/pull/466
> 
>CLOUDSTACK-8545 make reboot on out of band migration configurable
> 
> 
> 
> You can merge this pull request into a Git repository by running:
> 
>$ git pull https://github.com/DaanHoogland/cloudstack 4.4
> 
> Alternatively you can review and apply these changes as the patch at:
> 
>https://github.com/apache/cloudstack/pull/466.patch
> 
> To close this pull request, make a commit to your master/trunk branch
> with (at least) the following in the commit message:
> 
>This closes #466
> 
> 
> commit 68a4d5f9d457734279a987e028690d72b2815439
> Author: Daan Hoogland 
> Date:   2015-06-16T15:12:43Z
> 
>CLOUDSTACK-8545 make reboot on out of band migration configurable
> 
> 
> 
> 
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---

Re: [GitHub] cloudstack pull request: Allow test to run on tiny linux templates...

[Remi Bergsma]

LGTM, will try to give it a test drive today. Thanks!

Sent from my iPhone

> On 10 Jun 2015, at 11:17, isoutham  wrote:
> 
> GitHub user isoutham opened a pull request:
> 
>https://github.com/apache/cloudstack/pull/381
> 
>Allow test to run on tiny linux templates using busybox
> 
>When running in test environments containing netted-nested hypervisors, 
> the centos template is a little "heavy".  This test presumes that apache will 
> be installed on the target system which is not the case with tiny linux as it 
> is busy box based.
> 
>Just adds some extra code to detect the busy box binary and use it if it 
> is there.
> 
>Test succeeds under KVM and Xen running tiny linux and centos.
> 
> You can merge this pull request into a Git repository by running:
> 
>$ git pull https://github.com/isoutham/cloudstack test_vpc_network_pfrules
> 
> Alternatively you can review and apply these changes as the patch at:
> 
>https://github.com/apache/cloudstack/pull/381.patch
> 
> To close this pull request, make a commit to your master/trunk branch
> with (at least) the following in the commit message:
> 
>This closes #381
> 
> 
> commit d3616016b0eb3f8f48b2e8ec2819b557ba60a4f0
> Author: Ian Southam 
> Date:   2015-06-10T09:12:17Z
> 
>Allow test to run on tiny linux templates using busybox
> 
> 
> 
> 
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---

Re: 4.6

[Remi Bergsma]

Hi,

I can jump in and work with Rohit and Daan to make 4.6 happen.

+1 for the QA on master. It would be best if we could then all focus on 
stabilizing 4.6 aka master and wait with refactor stuff and new features until 
4.6 is out, which is the start of 4.7. 

On the other hand, building new features in the mean time isn't a big issue, as 
rebasing to a master that gets more stable every day is much easier than it is 
today I'd say. You just cannot merge new stuff until 4.6 is out. 

Let's write down some guidelines and see if this approach makes sense. 

Regards, Remi 

> On 08 Jun 2015, at 21:43, Sebastien Goasguen  wrote:
> 
> Folks,
> 
> We need to freeze 4.6 asap.
> 
> I originally agreed to RM 4.6 and Daan also stepped up.
> 
> But I would like to work on doing a release of ec2stack and gcestack, so I 
> will step down from 4.6 RM.
> 
> Anybody wants to jump in.
> 
> There is already a ton of things in 4.6 and we need to release.
> 
> Ideally we also need to QA directly on master, so that we can build 4.7 on 
> top of a stable release.
> 
> 
> -sebastien

Re: [ANNOUNCE] New PMC member: Bruno Demion aka Milamber

[Remi Bergsma]

Congratulations Bruno!

Sent from my iPhone

> On 08 Jun 2015, at 12:38, Sebastien Goasguen  wrote:
> 
> The Project Management Committee (PMC) for Apache CloudStack is pleased to
> announce that Bruno Demion has accepted our invitation to join the PMC.
> 
> Please join me in congratulating him.
> 
> On behalf of the Apache CloudStack PMC
> -- 
> Sebastien

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

[Remi Bergsma]

+1

On 04 Jun 2015, at 14:29, Rohit Yadav 
mailto:rohit.ya...@shapeblue.com>> wrote:

Hi,

On 04-Jun-2015, at 11:05 am, Remi Bergsma 
mailto:rberg...@schubergphilis.com>> wrote:

To summarise:
#1. rebooting VR is needed for hypervisors that have their own DR (like VMware 
and Hyperv) as a restart outside of CloudStack makes it lose its config hence 
the VR is unavailable
#2. rebooting is NOT needed for successful live migrations on _any_ hypervisor 
(since there was no restart everything still works)
#3. CloudStack 4.6 has persistent config in VR, so rebooting is never needed

The current behaviour in 4.4.3, 4.5.1 and master:
- always rebooting VR when out-of-band detected ==> Works great for #1, but 
makes case #2 not work

The previous behaviour:
- never rebooting VR when out-of-band detected ==>  Works great for #2, but 
makes case #1 not work

We need something that works for both cases :-)

About #1 and #2:
Can we detect in another way that a VR became unreachable/non-functional and do 
an action based on that?

So, if a VR lives on a VMware hypervisor that happens to crash, VMware HA will 
start it on another available hypervisor but without config it will not be 
reachable on the control network. If we want to do it generic, I’d say that 
when a VR is not controllable any more we could reboot it. We could also make 
this a setting ‘systemvm auto reboot on control failure’ or whatever we call it.

This would then also be a useful feature in 4.6

About #3:
I’d suggest at least reverting the commit to master, as it makes no sense since 
the VR is persistent already.
https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java#L2638
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=c3515c9

I agree on master, we can revert due to #3.

On 4.4 and 4.5 branches, if we revert it than it will break #1 and if we keep 
it - it breaks #2. We need to fix this in a hypervisor agnostic way.

So, if we can use aggregated cmd execution that Sudhashu and others have 
shared, in case of an out of band migration we can do this:

1. If we’re unable to reach VR, we can keep the RebootTask to do its job. In 
many cases I’ve seen VR disk corruption, so if after rebooting VR (which might 
kick in fsck) it fails CloudStack may eventually recreate a new VR makes sense. 
This will solve #1. This case IMO is highly unlikely.

2. If we’re able to reach the VR after VR is migrated out of band, we run an 
AgrregationExecutionTask sending all the rules for that VR. This will solve #2 
without needing to reboot a VM. This case is more likely to happen, so if I’ve 
pick between this and the above case, I would try to solve for this case.

I’m not sure about the actual implementation, and will re-applying rules using 
a AgrregationExecutionTask cause any issue in the VR? Comments?

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | 
rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>
Blog: bhaisaab.org<http://bhaisaab.org/> | Twitter: @_bhaisaab



Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Software 
Engineering<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure 
Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

[Remi Bergsma]

To summarise:
#1. rebooting VR is needed for hypervisors that have their own DR (like VMware 
and Hyperv) as a restart outside of CloudStack makes it lose its config hence 
the VR is unavailable
#2. rebooting is NOT needed for successful live migrations on _any_ hypervisor 
(since there was no restart everything still works)
#3. CloudStack 4.6 has persistent config in VR, so rebooting is never needed

The current behaviour in 4.4.3, 4.5.1 and master:
- always rebooting VR when out-of-band detected ==> Works great for #1, but 
makes case #2 not work

The previous behaviour:
- never rebooting VR when out-of-band detected ==>  Works great for #2, but 
makes case #1 not work

We need something that works for both cases :-)

About #1 and #2:
Can we detect in another way that a VR became unreachable/non-functional and do 
an action based on that?

So, if a VR lives on a VMware hypervisor that happens to crash, VMware HA will 
start it on another available hypervisor but without config it will not be 
reachable on the control network. If we want to do it generic, I’d say that 
when a VR is not controllable any more we could reboot it. We could also make 
this a setting ‘systemvm auto reboot on control failure’ or whatever we call it.

This would then also be a useful feature in 4.6

About #3:
I’d suggest at least reverting the commit to master, as it makes no sense since 
the VR is persistent already.
https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java#L2638
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=c3515c9

Regards,
Remi



On 04 Jun 2015, at 10:03, Wilder Rodrigues 
mailto:wrodrig...@schubergphilis.com>> wrote:

There was a bug in the persistent stuff that was fixed here: 
https://issues.apache.org/jira/browse/CLOUDSTACK-4605

User data, IP tables, guest networks and pretty much everything else will be 
persisted.

Cheers,
Wilder


On 04 Jun 2015, at 09:54, Daan Hoogland 
mailto:daan.hoogl...@gmail.com>>
 wrote:

On Thu, Jun 4, 2015 at 8:15 AM, Jayapal Reddy Uradi
mailto:jayapalreddy.ur...@citrix.com>>
 wrote:
In VR configuration persistence (4.6) only iptables rules are persisted ?
There are other configuration (interface ips, routes etc in VR will be lost on 
reboot) are these taken care ?


By design all config is persisted but let's double check on that.

@Ian: sir, can you confirm?

--
Daan (being to lazy/busy to check the code)

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

[Remi Bergsma]

Hi all,

I just had a look at this more closely and had a chat with Ian about it. The 
only way for the original problem to happen (losing iptables rules) is if the 
live migrate would fail and the hypervisor rebooted the vm. The cause is the 
non-persistance of the router configuration, which is fixed in 4.6 by the way. 
I would say failing live migrations does not happen often (I have never seen it 
happening).

Anyway, once this happens to the router, it is stuck in a state where it does 
not have the linklocal configuration any more. Would CloudStack be able to 
issue a aggregate command while it cannot reach it? Rebooting might be the only 
way out after all. It’s just that rebooting by default in case of out-of-band 
migrations I’d say is a little bit too much. CloudStack would detect the 
problem anyway, as it cannot reach the linklocal anymore.

The interesting situation is that we have releases out there that now reboot by 
default.

My proposal to solve it in 4.4 and 4.5:
- Implement a setting ‘reboot systemvm when out-of-band migration detected’.
The default should be false and release notes should mention a changed 
behaviour from 4.4.3 and 4.5.1. To get the old behaviour, switch to true. A 
small group of people should be interested in this.

I guess this is the best of both worlds. Do you guys agree?

The other option I see is to revert the commit, as I think that serves most 
people.

Who is willing to help implement it?

Regards, Remi


On 03 Jun 2015, at 17:42, Rene Moser 
mailto:m...@renemoser.net>> wrote:

Hi

On 03.06.2015 17:06, Ian Southam wrote:
If the machine crashes and/or rebooted during the oob migration by a party that 
is not the orchestrator, (read vCenter) then the rules will be lost.

I fully agree, a reboot due a failing live migration, would cause a
reboot. So what? Then we blame VMware, the orchestration will reboot the
VR and everything is fine. This would cause seconds of outage.

But then the missing persistence of the iptables would be the problem,
not the live migration task, right?

We should fix the persistence of the rules during reboot and not try to
be more clever then the hypervisor cluster orchestration.

Just my 2 cents.

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

[Remi Bergsma]

Hi all,

I just had a look at this more closely and had a chat with Ian about it. The 
only way for the original problem to happen (losing iptables rules) is if the 
live migrate would fail and the hypervisor rebooted the vm. The cause is the 
non-persistance of the router configuration, which is fixed in 4.6 by the way. 
I would say failing live migrations does not happen often (I have never seen it 
happening).

Anyway, once this happens to the router, it is stuck in a state where it does 
not have the linklocal configuration any more. Would CloudStack be able to 
issue a aggregate command while it cannot reach it? Rebooting might be the only 
way out after all. It’s just that rebooting by default in case of out-of-band 
migrations I’d say is a little bit too much. CloudStack would detect the 
problem anyway, as it cannot reach the linklocal anymore.

The interesting situation is that we have releases out there that now reboot by 
default.

My proposal to solve it in 4.4 and 4.5:
- Implement a setting ‘reboot systemvm when out-of-band migration detected’.
The default should be false and release notes should mention a changed 
behaviour from 4.4.3 and 4.5.1. To get the old behaviour, switch to true. A 
small group of people should be interested in this.

I guess this is the best of both worlds. Do you guys agree?

The other option I see is to revert the commit, as I think that serves most 
people.

Who is willing to help implement it?

Regards, Remi


On 03 Jun 2015, at 17:42, Rene Moser 
mailto:m...@renemoser.net>> wrote:

Hi

On 03.06.2015 17:06, Ian Southam wrote:
If the machine crashes and/or rebooted during the oob migration by a party that 
is not the orchestrator, (read vCenter) then the rules will be lost.

I fully agree, a reboot due a failing live migration, would cause a
reboot. So what? Then we blame VMware, the orchestration will reboot the
VR and everything is fine. This would cause seconds of outage.

But then the missing persistence of the iptables would be the problem,
not the live migration task, right?

We should fix the persistence of the rules during reboot and not try to
be more clever then the hypervisor cluster orchestration.

Just my 2 cents.

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

[Remi Bergsma]

I think the aggregate approach is much better (missed that mail at). Great it 
is available in 4.4 as well so we can fix it in both 4.4 and 4.5 in the same 
way.


On 03 Jun 2015, at 14:38, Koushik Das  wrote:
> 
> I think as a design principle we shouldn't introduce HV specific checks in 
> the orchestration/API layers.
> I am not sure if the problem is specific to Vmware. Any out of band VR 
> movement can lead to this issue. For now it is seen in Vmware but what about 
> other HVs where CS relies on native HA provided by HV.
> 
> -Original Message-
> From: Remi Bergsma [mailto:rberg...@schubergphilis.com] 
> Sent: Wednesday, 3 June 2015 17:54
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
> 
> This is a VMware specific problem, right?
> We could also limit the fix to this hypervisor only.
> 
> Regards,
> Remi
> 
> 
> On 03 Jun 2015, at 14:12, Koushik Das 
> mailto:koushik@citrix.com>> wrote:
> 
> In case the VR is moved out of band (say as part of Vmware DRS), all network 
> rules are lost. Rebooting VR from CS re-applies all the rules. Either the 
> reboot is done manually from UI/API or automatically as was done as part of 
> CLOUDSTACK-7994.
> 
> I haven't looked at the aggregate command. If it can be used to apply rules 
> on VR without a reboot then that should work as well.
> 
> -Koushik
> 
> -Original Message-
> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
> Sent: Wednesday, 3 June 2015 17:18
> To: dev
> Subject: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
> 
> Hi all,
> 
> Recently a behaviour was reported for ACS 4.5.1, where out of band VR 
> migration would cause rebooting of VR. It seems this is a desired behaviour 
> as per this issue: https://issues.apache.org/jira/browse/CLOUDSTACK-7994
> 
> It was shared on the thread on users ML that since CloudStack now supports 
> aggregate commands for VR, this behaviour is unnecessary.
> 
> The VR in 4.5+ supports aggregated execution of commands on VRs to allows us 
> to achieve eventual consistency of VR state without actually rebooting it, 
> see this for details: https://issues.apache.org/jira/browse/CLOUDSTACK-6047
> 
> Please share your comments on whether if we should revert the fix or not, and 
> the best way to do it. Thanks.
> 
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | 
> rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>
> Blog: bhaisaab.org<http://bhaisaab.org> | Twitter: @_bhaisaab
> 
> 
> 
> Find out more about ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design & 
> Build<http://secure-web.cisco.com/1dxwCI-iCtF6Z_nBrHijVPBNYijQKrOiFTNAyoWGJy4rj0SYtw0-E0Y0pAkH3D-NB0b01e1nt_XkrPm26uaNt3xXaVo4ZbAU7coVeFNM7kzqwOki5MLTTck7Y8OTbP1c-Zv9PMiy-M43LI_uAvDx-mT_q0vQcDZCt4fKB5W9A3-8Bdv5rzE0m03ik1kkWENKj/http%3A%2F%2Fshapeblue.com%2Fiaas-cloud-design-and-build%2F%2F>
> CSForge – rapid IaaS deployment 
> framework<http://secure-web.cisco.com/1KBMX-P7Uz8rk1CFZiKEJ6XOBtwCL6e4cxHjHhKOIeqCjjNcPHHrb0GoqH0CpXLUo42d8MsSS0X8jUVxeUQUuCEywQ8cHO7-KakvmeWrimKoqc3jlsmu_OgNQqdMRNwrO_uw71z7aOol5O-nshuUYfVgArT2kp2roAFkOUfEGQ2uyy18JLB5k2WhCMiyVyNs1/http%3A%2F%2Fshapeblue.com%2Fcsforge%2F>
> CloudStack 
> Consulting<http://secure-web.cisco.com/18B_NmraREMmC8vTWKXxDVFNi6uVPHolLmQtOC5pxOCqqVKFHBRYmXzR0e97TssbyoSyR90ruMa9xhxhyhPzd1nHvmYZXJWuiWx5eG0625EWlv3ZmrPpKJQcMrxeXCP4RXYkxVrnqKj-V0pH1AMKLwP5WRSrohlcx2oht8DsGOcyHmpFGdATnwmsBwW15ubts/http%3A%2F%2Fshapeblue.com%2Fcloudstack-consultancy%2F>
> CloudStack Software 
> Engineering<http://secure-web.cisco.com/1YTx4foSk2LL4qOkJ6hp8arX_tkHSgGLRhcrIh4tiJcMv4yOrG9LDzy23u-Of4to5Vw7pzPe7Z2BtX6UOObpoMHTu1Ygga8bXXaPX063jdDnTXVIeAzV86Qiya0QaVMLi8Yr7h619NJTW99-b2MVlgfrhYr2y0-xhqyX8x_qwxJsJ7ImNvcIeqtzluHsyEMwW/http%3A%2F%2Fshapeblue.com%2Fcloudstack-software-engineering%2F>
> CloudStack Infrastructure 
> Support<http://secure-web.cisco.com/1mWtUTi0OKF8weMnbfj_o1Xj1zQYn6dXlewUgkdu2L6UuSQi2hZdVPstsZ4PKm8seKRW9wKYnvF70hbKmhFdfk6XVguYW3ZXOBYvkNdiBK-yy31X-1Y4f2ESLclUvykFEl7X-hNmgBZkXpgP-uBL1ohAu36e0HtgdNE1zuX04JWN1YQzfKcYUHCb7GeKszF3x/http%3A%2F%2Fshapeblue.com%2Fcloudstack-infrastructure-support%2F>
> CloudStack Bootcamp Training 
> Courses<http://secure-web.cisco.com/16ybXVrdBe17I4mnCuuKp4rP7MHtjPD8iKc-dybhmY02WlxPCR05bGrGVQcpjdJyLH0Iw_X1oC5orlEkNVEpIQLjDWOdf3rsjI2WOQTECMHhA89ZuuE_96g0HQ-eLw_ylw4XsSOUq6KPyLjYryreJO38qidzmHjY6bxYb1MpUr9E7sCwzq_XBVDBdZFH5gdWF/http%3A%2F%2Fshapeblue.com%2Fcloudstack-training%2F>
> 
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed.

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

[Remi Bergsma]

That’s great, sounds like the best way to do it then :-)

> On 03 Jun 2015, at 14:21, Sudhansu Sahu  wrote:
> 
> The aggregate command was introduced in 4.4 so we can implement this in
> 4.4 as well.
> 
> 
> Regards
> Sudhansu Sahu
> CPG-Orchestration
> T: +91-4044308412 | M: +91-9989334676
> sudhansu.s...@citrix.com <mailto:%20sudhansu.s...@citrix.com>
> 
> <http://www.citrix.com>
> 
> Powering mobile workstyles and cloud services
> 
> 
> 
> 
> 
> 
> On 03/06/15 5:35 pm, "Remi Bergsma"  wrote:
> 
>> Hi all,
>> 
>> If I understand correctly, this is also in 4.4.3 (and the upcoming
>> 4.4.4). The report on user list:
>> http://markmail.org/message/nth7qck27s2chwoc?q=VMsync+issues+with+VRs%3F> ttp://markmail.org/message/nth7qck27s2chwoc?q=VMsync+issues+with+VRs?>
>> 
>> As VPCs are non-redundant, a sudden reboot impacts users. I¹d like to do
>> this in a non-impacting way.
>> 
>> Why out-of-band migrations? When patching XenServer at scale, it is much
>> faster to set the cluster to ³unmanaged² in CloudStack and ³evacuate² a
>> XenServer host directly (i.e. making it empty by live-migrating), turn
>> off HA, disable it, patch, reboot, enable, and do this for all
>> hypervisors in the pool. Finally, turning HA on again and set CloudStack
>> to ³manage² the cluster again. I have scripted this, so we can
>> automatically patch clusters at scale.
>> 
>> In CloudStack 4.4.2 this works and the database gets updated with the
>> current information on where VMs live. In CloudStack versions which
>> include this fix, CloudStack will reboot all routers ³to be sure². This
>> prevents me from doing maintenance without impact.
>> 
>> I¹d propose to either limit the fix to VMware, or come up with a way that
>> does not require a reboot.
>> CLOUDSTACK-6047 sounds interesting, just curious how to do it in 4.4 for
>> now.
>> 
>> Regards,
>> Remi
>> 
>> 
>> On 03 Jun 2015, at 13:48, Rohit Yadav
>> mailto:rohit.ya...@shapeblue.com>> wrote:
>> 
>> Hi all,
>> 
>> Recently a behaviour was reported for ACS 4.5.1, where out of band VR
>> migration would cause rebooting of VR. It seems this is a desired
>> behaviour as per this issue:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-7994
>> 
>> It was shared on the thread on users ML that since CloudStack now
>> supports aggregate commands for VR, this behaviour is unnecessary.
>> 
>> The VR in 4.5+ supports aggregated execution of commands on VRs to allows
>> us to achieve eventual consistency of VR state without actually rebooting
>> it, see this for details:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-6047
>> 
>> Please share your comments on whether if we should revert the fix or not,
>> and the best way to do it. Thanks.
>> 
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +91 88 262 30892 |
>> rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>
>> Blog: bhaisaab.org<http://bhaisaab.org> | Twitter: @_bhaisaab
>> 
>> 
>> 
>> Find out more about ShapeBlue and our range of CloudStack related services
>> 
>> IaaS Cloud Design &
>> Build<http://secure-web.cisco.com/1IT9RaYLUZQ7chW-ARcRoDX3w8TYuNItsW60qZQi
>> l7aWzHZFqJrFxNiP2VzZqELd-h6T1__-zg-Kyen2Zd69cUxRpIBmAWagY9rwoDCh5R7GHlYCcG
>> Rwi-D9DorUzAXVWz5n3oN2zwfSTW3ed4ocuu4UNsecm9oITVtWSL3QgVRpRHkT3UFf1zDYQXNR
>> G3XqR/http%3A%2F%2Fshapeblue.com%2Fiaas-cloud-design-and-build%2F%2F>
>> CSForge ­ rapid IaaS deployment
>> framework<http://secure-web.cisco.com/14UFU_a4mRs8mk63Pv_UPdDv4W0GDdbuUt5s
>> OS7E4ItlYkAlflu_KsLkcOuzACQ3y7NaLNJ7tYIf1c1IHeC92mLjh3izOh5RqEGP3SgnycXSxi
>> rsTFmNTfUBWtqDnHuRMYngTjUIoLbALtF1fhpX2FA3_vZBRmZJnumWhZTLXAASxXfMliY0MKD2
>> D2677-hCM/http%3A%2F%2Fshapeblue.com%2Fcsforge%2F>
>> CloudStack 
>> Consulting<http://secure-web.cisco.com/14OAw2w9F6PgJ7tF5Ued8EsvlPYVACEpMvI
>> z1zvbYOynBFgSPev-ETG0lB7jxmMUDsgjlWDk0dwmrBFCedYIHx4QX45kG6w0Dfb_C53KJosYK
>> 4Z8f2Qyec5x_Nljvn7D_ZfdjEfPl4xF6_iylDvj_80TL1ZBHOAIpPoZwDYiwNPUGSk-liakENF
>> jSikM93RrP/http%3A%2F%2Fshapeblue.com%2Fcloudstack-consultancy%2F>
>> CloudStack Software
>> Engineering<http://secure-web.cisco.com/1-9DE8xL74Rj9MTkhEw1oEcRxAawJfQcb2
>> nPTPaBPz-WyCU0TQKIStZ4ENC3UTOInjHv8ib3FVGNs8jYjBR4SEC1BOCnmLTx2QPbZQJ6ILdI
>> YLqTv8hbRO0hu8vXCLThbK9cmnUG--m-CwlJHl-u4Gnnt9aUqHvFnncH1J22tPVjB39Ue7zD1t
>> 1bmAW9a8L-n/http%3A%2F%2Fshapeblue.com%2Fcloudstack-software-engineering%2
>> F>
>> C

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

[Remi Bergsma]

This is a VMware specific problem, right?
We could also limit the fix to this hypervisor only.

Regards,
Remi


On 03 Jun 2015, at 14:12, Koushik Das 
mailto:koushik@citrix.com>> wrote:

In case the VR is moved out of band (say as part of Vmware DRS), all network 
rules are lost. Rebooting VR from CS re-applies all the rules. Either the 
reboot is done manually from UI/API or automatically as was done as part of 
CLOUDSTACK-7994.

I haven't looked at the aggregate command. If it can be used to apply rules on 
VR without a reboot then that should work as well.

-Koushik

-Original Message-
From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
Sent: Wednesday, 3 June 2015 17:18
To: dev
Subject: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

Hi all,

Recently a behaviour was reported for ACS 4.5.1, where out of band VR migration 
would cause rebooting of VR. It seems this is a desired behaviour as per this 
issue: https://issues.apache.org/jira/browse/CLOUDSTACK-7994

It was shared on the thread on users ML that since CloudStack now supports 
aggregate commands for VR, this behaviour is unnecessary.

The VR in 4.5+ supports aggregated execution of commands on VRs to allows us to 
achieve eventual consistency of VR state without actually rebooting it, see 
this for details: https://issues.apache.org/jira/browse/CLOUDSTACK-6047

Please share your comments on whether if we should revert the fix or not, and 
the best way to do it. Thanks.

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | 
rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & 
Build
CSForge – rapid IaaS deployment 
framework
CloudStack 
Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training 
Courses

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

[Remi Bergsma]

Hi all,

If I understand correctly, this is also in 4.4.3 (and the upcoming 4.4.4). The 
report on user list: 
http://markmail.org/message/nth7qck27s2chwoc?q=VMsync+issues+with+VRs%3F

As VPCs are non-redundant, a sudden reboot impacts users. I’d like to do this 
in a non-impacting way.

Why out-of-band migrations? When patching XenServer at scale, it is much faster 
to set the cluster to “unmanaged” in CloudStack and “evacuate” a XenServer host 
directly (i.e. making it empty by live-migrating), turn off HA, disable it, 
patch, reboot, enable, and do this for all hypervisors in the pool. Finally, 
turning HA on again and set CloudStack to “manage” the cluster again. I have 
scripted this, so we can automatically patch clusters at scale.

In CloudStack 4.4.2 this works and the database gets updated with the current 
information on where VMs live. In CloudStack versions which include this fix, 
CloudStack will reboot all routers “to be sure”. This prevents me from doing 
maintenance without impact.

I’d propose to either limit the fix to VMware, or come up with a way that does 
not require a reboot.
CLOUDSTACK-6047 sounds interesting, just curious how to do it in 4.4 for now.

Regards,
Remi


On 03 Jun 2015, at 13:48, Rohit Yadav 
mailto:rohit.ya...@shapeblue.com>> wrote:

Hi all,

Recently a behaviour was reported for ACS 4.5.1, where out of band VR migration 
would cause rebooting of VR. It seems this is a desired behaviour as per this 
issue: https://issues.apache.org/jira/browse/CLOUDSTACK-7994

It was shared on the thread on users ML that since CloudStack now supports 
aggregate commands for VR, this behaviour is unnecessary.

The VR in 4.5+ supports aggregated execution of commands on VRs to allows us to 
achieve eventual consistency of VR state without actually rebooting it, see 
this for details: https://issues.apache.org/jira/browse/CLOUDSTACK-6047

Please share your comments on whether if we should revert the fix or not, and 
the best way to do it. Thanks.

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | 
rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [VOTE] release candidate 4.4.4

[Remi Bergsma]

I'd say, as a default: 4.4.0 will be nice for any 4.4.x release, and 4.5.0
for 4.5.x etc. This is also close to what was hard-coded before.

Regards,
Remi


2015-06-01 11:33 GMT+02:00 Daan Hoogland :

> Guess we'll be making a new rc. The value can be 0.0.0 for my part, it must
> be an operator decision to set the MinVRVersion if it must be higher. It
> will always be an upgrade matter and any seeded template should be accepted
> as per the installation notes. Of course the other side of the issue is
> whether a version will work at all. The operator can create a version of
> the template with their own versioning scheme, however. I should be writing
> all this in another {DISCUSS]-thread.
>
> cancelling the RC to add code for Bruno's requirement.
>
> Op ma 1 jun. 2015 om 08:35 schreef Milamber :
>
> >
> > Please note: I my case, there isn't an upgrade, I have the issue with
> > 4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
> > 4.4-RC20150529T2004)
> >
> >
> >
> >
> > On 01/06/2015 07:22, Erik Weber wrote:
> > > If it means that all upgrades are unable to do VR related tasks (
> > starting
> > > VMs for one.. ), I'd call that regression and redo.
> > > Relying on all our users to do manual fixing just because we don't want
> > to
> > > call off the RC is bad IMHO.
> > >
> > >
> >
> >
>

Re: [VOTE] release candidate 4.4.4

[Remi Bergsma]

Hi Milamber,

I think it is new in 4.4.4, backported from master but Daan can confirm. 

4.4.1 refers to the system vm template version and not per se to CloudStack 
4.4.1. There is no reason to upgrade it so it can stay at 4.4.1 again as the 
upgrade procedure is much easier and faster without upgrading systemvms. 

It is a great feature because it allows to upgrade the systemvm template 
regardless of CloudStack version. Handy when there's a new glibc/shellshock 
alike issue. 

But it should work transparently and not bug users. Will work with Daan today 
to fix it. 

Same could be going on in 4.5 branch, will check that too. 

Regards, Remi 

Sent from my iPhone

> On 31 May 2015, at 19:50, Milamber  wrote:
> 
> Hello Remi,
> 
> Ok thanks.
> I execute this SQL request below, and now it's works.
> 
> 
> INSERT INTO `cloud`.`configuration`(`category`, `instance`, `component`, 
> `name`, `value`, `description`, `default_value`, `updated`, `scope`, 
> `is_dynamic`) VALUES('Advanced', 'DEFAULT', 'management-server', 
> 'minreq.sysvmtemplate.version', '4.4.1', 'The minimal version for the 
> systemvm', '4.4.1', NULL, NULL, 0);
> 
> 
> If I understand well, this "bug"/missing entry in database exists since 4.4.2?
> 
> 
> @Daan, Probably it would be better to fix this before the 4.4.4 release?
> 
> 
> Milamber
> 
> 
>> On 31/05/2015 17:07, Remi Bergsma wrote:
>> Hi Milamber,
>> 
>> It is a global setting, although it appears not to be present in the 
>> cloud.configuration table by default (so you cannot find it). If you insert 
>> it, it works.
>> 
>> I also played with the upgrade and did insert the setting, since at work we 
>> had changed the minimal version to a non standard 4.4.2 during a patch 
>> round. So I knew it wouldn't work out of the box for me.
>> 
>> @daan: We might want to set the setting by default to 4.4.1 (in db) so 
>> upgrades work out-of-the-box and you can control it from the global settings 
>> pane. This may also need some attention in the docs. What do you think?
>> 
>> Regards, Remi
>> 
>>> On 31 May 2015, at 17:36, Milamber  wrote:
>>> 
>>> Hello Rohit,
>>> 
>>>> On 31/05/2015 11:57, Rohit Yadav wrote:
>>>> +1 (binding)
>>>> 
>>>> Here’s a test repository you can use for convenience built out of this 
>>>> tag/RC:
>>>> http://packages.shapeblue.com/cloudstack/testing/
>>>> 
>>>> Deployed Basic Zone with/without SG, tested vm lifecycle.
>>>> 
>>>> The VM deployment failed for me as minreq.sysvmtemplate.version global 
>>>> setting was set to 4.4.4, and I was using 4.4.1 template.
>>> Me too, all my tests failed because VR must be updated. I've past some 
>>> hours to find why (test with different systemvmtemplate file, re-install, 
>>> etc.)
>>> 
>>>> After setting this to 4.4.1, all normal vm lifecycle worked for me.
>>> Where ? directly in 
>>> ./engine/api/src/org/apache/cloudstack/engine/orchestration/service/NetworkOrchestrationService.java
>>>  ?
>>> 
>>> I don't find the minreq.sysvmtemplate.version key in the Global Settings 
>>> view.
>>> 
>>> Milamber
>>> 
>>> 
>>>> We need to document this in the docs, the systemvmtemplate build for 4.4 
>>>> has been failing which might need to be fixed if we want 4.4.4 
>>>> template:http://jenkins.buildacloud.org/view/4.4/
>>>> 
>>>>> On 29-May-2015, at 8:10 pm, Daan Hoogland  wrote:
>>>>> 
>>>>> Hi All,
>>>>> 
>>>>> I've created a 4.4.4 release, with the following artifacts up for a vote:
>>>>> 
>>>>> Git Branch and Commit
>>>>> SH:https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/
>>>>> <https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20150526T2323>4.4-RC20150529T2004
>>>>> Commit: 7d2320cd1d27842fae73c7f43ef422da354f
>>>>> 
>>>>> List of 
>>>>> changes:https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/tags/4.4.4
>>>>> 
>>>>> Source release (checksums and signatures are available at the same
>>>>> location):https://dist.apache.org/repos/dist/dev/cloudstack/4.4.4/
>>>>> 
>>>>> PGP release keys (signed using
>>>>> A