Re: 4.8.2.0/4.9.1.0/4.10.0.0 RC Status

[John Burwell]

Ozhan,

As I said on the PR, #1710 addresses a fairly narrow case (RBD on KVM), and 
4.9.1.0 is extremely late.  There are a lot “small” fixes that could be 
included.  However, it would further delay delivery of significant dies that 
nearly all users.  At some point, we must draw a line, and this fix will have 
to wait until 4.9.2.0/4.10.1.0/4.11.0.0.

Thanks,
-John


john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

> On Nov 17, 2016, at 5:22 AM, Özhan Rüzgar Karaman <oruzgarkara...@gmail.com> 
> wrote:
> 
> Hi John & Rohit;
> If we have time could we add PR 1710 to the upcoming RC for 4.9.1.0. Its a
> small fix but its waiting for log time...
> 
> Thanks again,
> Özhan
> 
> On Thu, Nov 17, 2016 at 9:23 AM, John Burwell <john.burw...@shapeblue.com>
> wrote:
> 
>> All,
>> 
>> I apologize for being relatively radio silent.  We have mage good progress
>> towards getting RCs out for 4.8.2.0, 4.9.1.0, and 4.10.0.0.  On 31 October
>> 2016, we 17 outstanding PRs to be merged.  As of today (17 Nov 2016), we
>> have 9 PRs to merge with pending one potential blocker/critical defect fix:
>> 
>> * 4.10.0.0 (+ all 4.8.2.0 and 4.9.1.0 PRs)
>> * 1542 (regression tests running)
>>  * 1545 (code review comments; regression tests pending)
>>  * 1577 (Jenkins failures; regression tests pending)
>>  * 1579 (needs rebase + commit squash; regression tests pending)
>>  * 1580 (needs rebase + commit squash; regression tests pending)
>> * 4.9.1.0 (+ all 4.8.2.0 PRs)
>>  * 1681 (test failures to resolve)
>>  * 1684 (working out the proper fix to an upgrade issue)
>> * 4.8.2.0
>>* 1745 (test failures to resolve)
>>* 1765 (squash commits; code review feedback; regression tests
>> pending)
>> 
>> Once all PRs are merged, we will re-execute the tests on each of the
>> release branches.  Rohit has opened tracking PRs for 4.8 [1], 4.9 [2], and
>> master [3] to understand the state of the release branches as we continue
>> to merge PRs.
>> 
>> Thank you to everyone who has reviewed, tested, and merged PRs.  I am
>> hopeful that we are very close to cutting these RCs.
>> 
>> Thanks again,
>> -John
>> 
>> [1]: https://github.com/apache/cloudstack/pull/1752
>> [2]: https://github.com/apache/cloudstack/pull/1753
>> [3]: https://github.com/apache/cloudstack/pull/1754
>> 
>> john.burw...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
>> @shapeblue
>> 
>> 
>> 
>> 

4.8.2.0/4.9.1.0/4.10.0.0 RC Status

[John Burwell]

All,

I apologize for being relatively radio silent.  We have mage good progress 
towards getting RCs out for 4.8.2.0, 4.9.1.0, and 4.10.0.0.  On 31 October 
2016, we 17 outstanding PRs to be merged.  As of today (17 Nov 2016), we have 9 
PRs to merge with pending one potential blocker/critical defect fix:

* 4.10.0.0 (+ all 4.8.2.0 and 4.9.1.0 PRs)
* 1542 (regression tests running)
  * 1545 (code review comments; regression tests pending)
  * 1577 (Jenkins failures; regression tests pending)
  * 1579 (needs rebase + commit squash; regression tests pending)
  * 1580 (needs rebase + commit squash; regression tests pending)
* 4.9.1.0 (+ all 4.8.2.0 PRs)
  * 1681 (test failures to resolve)
  * 1684 (working out the proper fix to an upgrade issue)
* 4.8.2.0
* 1745 (test failures to resolve)
* 1765 (squash commits; code review feedback; regression tests pending)

Once all PRs are merged, we will re-execute the tests on each of the release 
branches.  Rohit has opened tracking PRs for 4.8 [1], 4.9 [2], and master [3] 
to understand the state of the release branches as we continue to merge PRs.

Thank you to everyone who has reviewed, tested, and merged PRs.  I am hopeful 
that we are very close to cutting these RCs.

Thanks again,
-John

[1]: https://github.com/apache/cloudstack/pull/1752
[2]: https://github.com/apache/cloudstack/pull/1753
[3]: https://github.com/apache/cloudstack/pull/1754

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

Re: Migrating CloudStack content from download.cloud.com

[John Burwell]

Chiradeep,

I am +1 to using a mirror list downloaded from downloads.cloudstack.apache.org 
via https only (i.e. https://downloads.cloudstack.apache.org/mirror.lst).  This 
approach seems to be a common approach employed by other Apache projects that 
need to provided downloadable assets.  Therefore, I would imagine it would be 
something ASF Infra would be able to support.

It also seems like we should have a hashes of a assets hosted on 
downloads.cloudstack.apache.org in order to allow users to verify that mirror 
has not been corrupted.

Anyone opposed to targeting this change for the next round of releases -- 
4.9.2.0, 4.10.1.0, and 4.11.0.0?

Thanks,
-John


john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

> On Nov 1, 2016, at 2:25 PM, Chiradeep Vittal  wrote:
> 
> I believe that there is already a new site, but the software still points
> to download.cloud.com.  There was also discussion about
> - building mirror sites instead of a SPOF site
> - eliminating the automatic download of templates and updating the
> documentation on use of offline templates.
> Older releases may not be changed, but users need to be notified and
> documentation needs to be updated and publicized.
> 
> Thread here:
> http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201605.mbox/thread?4
> 
> We should ask for the download.cloud.com site to be taken offline for 24
> hours to see how many people scream, perhaps then the community will swing
> into action?
> 
> 
> 
> On Mon, Oct 31, 2016 at 1:49 PM, Rajesh Ramchandani <
> rajesh.ramchand...@accelerite.com> wrote:
> 
>> Are we looking for new server to host this site?
>> 
>> 
>> 
>> On Mon, Oct 31, 2016 at 12:46 PM -0700, "Chiradeep Vittal" <
>> chirade...@gmail.com> wrote:
>> 
>> Bumping this. Any progress on this? download.cloud.com is not an Apache
>> property and is subject to the whims of its owner (Citrix).
>> 
>> On Mon, Jun 6, 2016 at 9:44 AM, Chiradeep Vittal 
>> wrote:
>> 
>>> Any progress on this? There's nearly a 100K downloads of systemvm
>>> templates from download.cloud.com per month. Would be a shame to leave
>>> these folks stranded.
>>> 
>>> On Tue, May 31, 2016 at 4:49 AM, Paul Angus 
>>> wrote:
>>> 
 +1.  we need to figure out the way forward, but this needs to be done
 'right' not just 'fast'.
 
 
 paul.an...@shapeblue.com
 www.shapeblue.com
 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
 @shapeblue
 
 
 
 -Original Message-
 From: Raja Pullela [mailto:raja.pull...@accelerite.com]
 Sent: 31 May 2016 07:33
 To: CloudStack Dev 
 Subject: Re: Migrating CloudStack content from download.cloud.com
 
 +1, hope we will be able to discuss this at the Collab this week and
 decide on the next steps.
 
 best,
 Raja Pullela
 Senior Manager, Product Development
 Accelerate,
 2055,Laurelwood Road,  Santa Clara, CA 95054, USA
 Phone: 1-408-216-7010,  www.accelerite.com,@accelerite> accelerite.com,@accelerite>
 
> On May 31, 2016, at 10:23 AM, Chiradeep Vittal 
 wrote:
> 
> I hope this gets discussed during the CloudStack Collab over the next
> few days. Again, I'd urge everybody to consider: "what if
> download.cloud.com went away next week". Waiting till some
> hypothetical last date only means that we will scramble a week before
 that last date.
> 
> On Fri, May 20, 2016 at 5:42 PM, Chiradeep Vittal
> 
> wrote:
> 
>> Yes, the mirror site would be on github or apache.org
>> 
>> Step 6 in the install guide would have instructions like:
>> a. Install System VM Templates:
>> > list> b. Installing other templates cloud-install-tmplt
>>> enter OS (linux only)
>>> Ubuntu 16.04
>>  Installing...
>> 
>> Or, step (b) could generate a cloudmonkey script.
>> 
>> 
>> On Fri, May 20, 2016 at 1:57 PM, Will Stevens >> 
>> wrote:
>> 
>>> Cant we just host the mirror list in apache.org and then actually
>>> host the mirrors in different places around the world?  A company
>>> could sponsor the few bucks a month for AWS and have one of the
>>> mirrors be in AWS and the mirror list in apache.org would just be
>>> updated to add the AWS mirror.
>>> 
>>> Isn't that basically what we are proposing here?  The ability to
>>> have different mirrors with the 'official' endpoint being in an
>>> apache.org endpoint to list the mirrors?
>>> 
>>> *Will STEVENS*
>>> Lead Developer
>>> 
>>> *CloudOps* *| *Cloud Solutions Experts
>>> 420 

Re: Outstanding Review/Testing for 4.8.2.0/4.9.1.0/4.10.0.0 RCs

[John Burwell]

Haijao,

We are nearly a month late for these releases.  Therefore, only new feature PRs 
that are well reviewed and tested are being included in 4.10.0.0.  The 
intention is to return to the 1 month maintenance/2 month regular release cycle 
once we can get these releases delivered. 

Additionally, XenServer 7 will be merged to both LTS and regular release 
branches.  The reasoning for adding it to LTS is that newer hardware is not 
supported by XenServer 6.5.  Therefore, XenServer users would not have an 
effective LTS because they would be unable to deploy new hardware.  Support for 
it will most likely land in the next LTS and regular releases — 4.9.2.0 and 
4.11.0.0. 

Thanks,
-John


john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

> On Nov 1, 2016, at 2:36 AM, Haijiao <18602198...@163.com> wrote:
> 
> Hi, John
> 
> 
> 
> Is that possible to include these 2 PRs in 4.10 since 4.10 is supposed to be 
> a release with new features.
> 
> 
> #1711  XenServer 7 Support
> https://github.com/apache/cloudstack/pull/1711
> #977   VM Snapshotting implementation for KVM  
> https://github.com/apache/cloudstack/pull/977
> 
> 
> thanks !
> 
> 
> 在2016年11月01 11时23分, "John Burwell"<john.burw...@shapeblue.com>写道:
> 
> All,
> 
> Since we have stabilized the smoke tests, we have made good progress merging 
> PRs.  Currently, the following open PRs are being targeted for these releases:
> 
>* 4.10.0.0 (+ all 4.8.2.0 and 4.9.1.0 PRs)
> * 1542
> * 1545
> * 1577
> * 1578
> * 1579
> * 1580
>* 1600
>* 1732
>* 4.9.1.0 (+ all 4.8.2.0 PRs)
> * 1676
> * 1677
> * 1678
> * 1680
> * 1681
> * 1684
>* 4.8.2.0
> * 1673
> * 1674
> * 1694
> 
> Are there any other open PRs that folks feel should be included in these 
> releases?  I have updated each of these PRs with next steps, and, where 
> possible, kicked off regression tests.
> 
> I would like to get the 4.8.2.0, 4.9.1.0, and 4.10.0.0 RCs out by COB, next 
> Wednesday (5 Wednesday 2016).  Any assistance people can provide 
> reviewing/testing these PRs to get them merged would be much appreciated.
> 
> Thanks,
> -John
> john.burw...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
> 
> 
> 

Outstanding Review/Testing for 4.8.2.0/4.9.1.0/4.10.0.0 RCs

[John Burwell]

All,

Since we have stabilized the smoke tests, we have made good progress merging 
PRs.  Currently, the following open PRs are being targeted for these releases:

* 4.10.0.0 (+ all 4.8.2.0 and 4.9.1.0 PRs)
* 1542
* 1545
* 1577
* 1578
* 1579
* 1580
* 1600
* 1732
* 4.9.1.0 (+ all 4.8.2.0 PRs)
* 1676
* 1677
* 1678
* 1680
* 1681
* 1684
* 4.8.2.0
* 1673
* 1674
* 1694

Are there any other open PRs that folks feel should be included in these 
releases?  I have updated each of these PRs with next steps, and, where 
possible, kicked off regression tests.

I would like to get the 4.8.2.0, 4.9.1.0, and 4.10.0.0 RCs out by COB, next 
Wednesday (5 Wednesday 2016).  Any assistance people can provide 
reviewing/testing these PRs to get them merged would be much appreciated.

Thanks,
-John
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

Out 18 - 25 Oct 2016

[John Burwell]

All,

I will be out 18-25 Oct 2016 for ankle surgery.  Murali Reddy will reviewing, 
testing, and merging PRs until I return.

Thanks,
-John
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

Re: 4.8, 4.9, and master Testing Status

[John Burwell]

All,

We have made great strides stabilizing the 4.8 [1] and 4.9 [2] smoke tests.  
While we are not super green, the following remaining failures/issues are 
isolated to the VPC VR and secondary storage.  

* CLOUDSTACK-9541: redundant VPC VR: issues when master and backup 
switch happens on failover [3]
* CLOUDSTACK-9540: createPrivateGateway create private network does not 
create proper VLAN network on XenServer
* CLOUDSTACK-9528: SSVM Downloads (built-in) template multiple times

Therefore, I would like to merge these two PRs so that we can begin the process 
of rebasing and retesting the PRs slotted for 4.8 and 4.9 that are not affected 
by these issues (i.e. PRs unrelated to secondary storage or the VR).  Our hope 
is that we can correct these issues quickly, and by the time we have worked 
through the backlog of pending PRs, these issues will be addressed and we can 
move those impacted forward.

Unfortunately, the master PR [5] has 6 failures and 4 errors on XenServer [6] 
that we are currently analyzing.  We hope to have these resolved shortly in 
order to begin progressing PRs targeting master.

I would like to get 1692 [1] and 1703 [2] merged in the next 24 hours.  We need 
to complete the following actions in order to accomplish this goal:

* Obtain at least one code review LGTM on PR #1692 [1]
* Obtain at least one code review LGTM on PR #1703 [2]
* Obtain at least one test review LGTM on PR #1703 [2]

Once these PRs, I will be updating PRs slotted for 4.8 and 4.9 to ping authors 
for a rebase.  Following each rebase, we will trigger blueorangutan to retest 
each one.

Thank again for your patience and assistance,
-John

[1]: https://github.com/apache/cloudstack/pull/1692
[2]: https://github.com/apache/cloudstack/pull/1703
[3]: https://issues.apache.org/jira/browse/CLOUDSTACK-9541
[4]: https://issues.apache.org/jira/browse/CLOUDSTACK-9540
[5]: https://github.com/apache/cloudstack/pull/1708
[6]: https://github.com/apache/cloudstack/pull/1708#issuecomment-253698099

> On Oct 7, 2016, at 10:12 AM, Will Stevens <wstev...@cloudops.com> wrote:
> 
> Great work everyone.  Don't worry about the sporadic updates, that is just
> the nature of the beast when working through stuff like this.  Well done so
> far...
> 
> *Will STEVENS*
> Lead Developer
> 
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
> 
> On Fri, Oct 7, 2016 at 9:53 AM, John Burwell <john.burw...@shapeblue.com>
> wrote:
> 
>> All,
>> 
>> Thank you Ilya and Haijao for your words of encouragement.  In addition to
>> the efforts of Paul, Rohit, Murali, Abhi, and Bobby, Sergey Levitskiy has
>> been providing great help testing VMware.
>> 
>> I apologize for my sporadic status updates.  We have made significant
>> progress in getting smoke tests to pass on KVM, XenServer, and VMware.
>> Currently, we have the following number of failures and errors:
>> 
>>* KVM: 0
>>* VMware: 4
>>* XenServer: 8
>> 
>> The outstanding failures and errors seem to be the caused by the following
>> issues:
>> 
>>1. On VMware and XenServer, guest VMs in VPCs start but don’t
>> acquire IP addresses causing tests relying on SSH connectivity tests to
>> fail.  The issue occurs does not occur on KVM, intermittently on VMware,
>> and consistently on XenServer.  This issue affects the test_vpc_redundant,
>> test_privategw_acl, and test_vpc_vpn test suites.   We believe that this
>> issue may be caused by either the guest VMs startup/DHCP wait period
>> winning the race with the VPC VR configuration or there is a problem on the
>> VPC VR assigning IP addresses.  We are currently investigating and expect
>> to identify the root cause shortly.
>>2. SSVM downloads str being restarted due to ping timeouts on
>> XenServer and VMware.  We are seeing the following messages such as the
>> following in the Management Server logs:
>> 
>>com.cloud.utils.exception.CloudRuntimeException: Failed
>> to send command, due to 
>> Agent:5,com.cloud.exception.OperationTimedoutException:
>> Commands
>>9042102151853113352 to Host 5 timed out after 2400
>> 
>>  Our initial investigation discovered different timezones being
>> used by the system VM templates and Management Server.  This discrepancy We
>> have modified Trillian to ensure consistent configuration of time zones
>> across a cluster, and are preparing another run for XenServer and VMware.
>> KVM is not affected by this time zone issue because KVM hosts use the same
>> CentOS template as CentOS based Management Servers -- c

Re: [ANNOUNCE] New committer: Syed Ahmed

[John Burwell]

Congratulations, Syed.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Oct 7, 2016, at 6:30 AM, Paul Angus  wrote:
> 
> Congrats Syed.!
> 
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 
> 
> -Original Message-
> From: Rafael Weingärtner [mailto:rafaelweingart...@gmail.com] 
> Sent: 06 October 2016 16:59
> To: dev@cloudstack.apache.org
> Subject: Re: [ANNOUNCE] New committer: Syed Ahmed
> 
> Congratulations Syed!
> 
> Welcome to the club ;)
> 
> On Thu, Oct 6, 2016 at 12:56 PM, Nicolás Vázquez 
> wrote:
> 
>> Congratulations Syed!
>> 
>> 2016-10-06 11:21 GMT-03:00 Syed Ahmed :
>> 
>>> Thank you all :)
>>> 
>>> On Thu, Oct 6, 2016 at 6:17 AM, Wei ZHOU  wrote:
>>> 
 Congratulations, Syed!!
 
 2016-10-05 22:07 GMT+02:00 Will Stevens :
 
> The Project Management Committee (PMC) for Apache CloudStack has 
> asked Syed Ahmed to become a committer and we are pleased to 
> announce that he has accepted.
> 
> Being a committer allows many contributors to contribute more 
> autonomously. For developers, it makes it easier to submit 
> changes
>> and
> eliminates the need to have contributions reviewed via the patch 
> submission process. Whether contributions are 
> development-related or otherwise, it is a recognition of a 
> contributor's participation in
>> the
> project and commitment to the project and the Apache Way.
> 
> Please join me in congratulating Syed!
> 
> Will Stevens
> on behalf of the CloudStack PMC
> 
 
>>> 
>> 
> 
> 
> 
> --
> Rafael Weingärtner

Re: 4.8, 4.9, and master Testing Status

[John Burwell]

All,

Thank you Ilya and Haijao for your words of encouragement.  In addition to the 
efforts of Paul, Rohit, Murali, Abhi, and Bobby, Sergey Levitskiy has been 
providing great help testing VMware.  

I apologize for my sporadic status updates.  We have made significant progress 
in getting smoke tests to pass on KVM, XenServer, and VMware.  Currently, we 
have the following number of failures and errors:

* KVM: 0
* VMware: 4
* XenServer: 8

The outstanding failures and errors seem to be the caused by the following 
issues:

1. On VMware and XenServer, guest VMs in VPCs start but don’t acquire 
IP addresses causing tests relying on SSH connectivity tests to fail.  The 
issue occurs does not occur on KVM, intermittently on VMware, and consistently 
on XenServer.  This issue affects the test_vpc_redundant, test_privategw_acl, 
and test_vpc_vpn test suites.   We believe that this issue may be caused by 
either the guest VMs startup/DHCP wait period winning the race with the VPC VR 
configuration or there is a problem on the VPC VR assigning IP addresses.  We 
are currently investigating and expect to identify the root cause shortly.
2. SSVM downloads str being restarted due to ping timeouts on XenServer 
and VMware.  We are seeing the following messages such as the following in the 
Management Server logs:

com.cloud.utils.exception.CloudRuntimeException: Failed to send 
command, due to Agent:5,com.cloud.exception.OperationTimedoutException: 
Commands 
9042102151853113352 to Host 5 timed out after 2400

  Our initial investigation discovered different timezones being used 
by the system VM templates and Management Server.  This discrepancy We have 
modified Trillian to ensure consistent configuration of time zones across a 
cluster, and are preparing another run for XenServer and VMware.  KVM is not 
affected by this time zone issue because KVM hosts use the same CentOS template 
as CentOS based Management Servers -- creating time zone consistency by side 
effect.

Reports of each test run are available on PR #1692 [1].  We have kicked a new 
round of tests on KVM, VMware, and XenServer with the time zone fix and 
additional instrumentation to run down the VPC VR race condition.

Instead of directly forward merging these changes, we plan to open a PR for 
each forward merge.  Since we are very close to having 4.8 resolved, Rohit has 
open PR 1703 [2] for the 4.9 forward merge and kicked off a test run.  While we 
cannot close this PR until 1692 is complete, we are hoping to get a head start 
on any issues in the 4.9 branch.

Thank you again for your patience,
-John

[1]: https://github.com/apache/cloudstack/pull/1692
[2]: https://github.com/apache/cloudstack/pull/1703

> On Oct 5, 2016, at 4:32 AM, Haijiao <18602198...@163.com> wrote:
> 
> Though I am one of the silent majority, I would thank John the dev team for 
> your continuous effort, you keep ACS alive and better !
> 
> 
> Just heard one of biggest finance company in China running 10,000+ VMs on ACS 
> 4.4 for production/dev/QAS,  you guys should be proud of that.
> Salute to you!
> 
> 
> 
> 
> 
> 
> 
> 在2016年10月05 03时09分, "ilya"<ilya.mailing.li...@gmail.com>写道:
> 
> John and Team
> 
> Thanks for amazing work and contributing back.
> 
> Regards,
> ilya
> 
> On 10/3/16 9:48 PM, John Burwell wrote:
>> All,
>> 
>> A quick update on our progress to pass all smoke tests aka super green.  We 
>> have reduced the failures and errors for XenServer from 93 to 9 and for 
>> VMware from 51 to 14.  A CentOS 6/CentOS 6 KVM run is currently executing.  
>> Based on manual tests/fixes, we are expecting to be the first super green 
>> configuration.  We have also found the following additional defects:
>> 
>>  * CLOUDSTACK-9528 [2]: SSVM Downloads (built-in) Template Multiple Times
>>  * CLOUDSTACK-9529 [3]: Marvin Tests Do Not Clean Up Properly
>> 
>> 9528 is causing XenServer environments to fail to install and startup 
>> cleanly.  A lack of cleanup described in 9529 is causing XenServer to 
>> exhaust available resources before a test run completes.  We believe that 
>> resolution of these issues will address most, if not all, of the XenServer 
>> issues.
>> 
>> Thanks,
>> -John
>> 
>> [1]: 
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65873020
>> [2]: https://issues.apache.org/jira/browse/CLOUDSTACK-9528
>> [3]: https://issues.apache.org/jira/browse/CLOUDSTACK-9529
>> 
>>> 
>> john.burw...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
>> @shapeblue
>> 
>> 
>> 
>> On Sep 30, 2016, at 2:40 AM, John Burwell <john

Re: 4.8, 4.9, and master Testing Status

[John Burwell]

All,

A quick update on our progress to pass all smoke tests aka super green.  We 
have reduced the failures and errors for XenServer from 93 to 9 and for VMware 
from 51 to 14.  A CentOS 6/CentOS 6 KVM run is currently executing.  Based on 
manual tests/fixes, we are expecting to be the first super green configuration. 
 We have also found the following additional defects:

  * CLOUDSTACK-9528 [2]: SSVM Downloads (built-in) Template Multiple Times 
  * CLOUDSTACK-9529 [3]: Marvin Tests Do Not Clean Up Properly

9528 is causing XenServer environments to fail to install and startup cleanly.  
A lack of cleanup described in 9529 is causing XenServer to exhaust available 
resources before a test run completes.  We believe that resolution of these 
issues will address most, if not all, of the XenServer issues.

Thanks,
-John

[1]: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65873020
[2]: https://issues.apache.org/jira/browse/CLOUDSTACK-9528
[3]: https://issues.apache.org/jira/browse/CLOUDSTACK-9529

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Sep 30, 2016, at 2:40 AM, John Burwell <john.burw...@shapeblue.com> wrote:
> 
> All,
> 
> Using blueorganutan, Rohit, Murali, Boris, Paul, Abhi, and I are executing 
> the smoke tests for the 4.8, 4.9, and master branches against the following 
> environments:
> 
>   * CentOS 7.2 Management Server + VMware 5.5u3 + NFS Primary/Secondary 
> Storage
>   * CentOS 7.2 Management Server + XenServer 6.5SP1 + NFS 
> Primary/Secondary Storage
>   * CentOS 7.2 Management Server + CentOS 7.2 KVM + NFS Primary/Secondary 
> Storage
> 
> Thus far, we have found seven (7) test case and/or CloudStack defects in the 
> VMware run for the 4.8 branch [1].  We are currently triaging fifty-one (51) 
> new issues from the XenServer run to determine which issues were 
> environmental and defects.  This triage work should be completed today (30 
> Sept 2016).  Finally, we are awaiting the results of the KVM run.  
> 
> We are using PR #1692 [2] as the master tracking PR to fix all defects in the 
> 4.8 branch.  Our goal is to get all non-skip tests to pass and then merge 
> this PR to the 4.8, 4.9, and master.  For each bug, we are creating a JIRA 
> ticket and adding a commit to the PR.  Currently, the branch for this PR is 
> in the shapeblue repo (the branch started with a much smaller fix from Paul 
> and we just kept using it).  However, if others are interested in picking up 
> defects, we will move it to ASF repo.  Once the 4.8 branch is stabilized, we 
> plan to re-execute these tests on the 4.9 and master branches as we expect 
> that the 4.9 and master branches will have additional issues.
> 
> Since we are in a test freeze, I propose that no further PRs are merged to 
> the 4.8, 4.9, and master branches until they are stabilized.  The following 
> PRs will be re-based, re-tested, and merged to 4.8, 4.9.1.0, and/or 4.10.0.0 
> post-stabilization:
> 
>   * 1696
>   * 1694
>   * 1684
>   * 1681
>   * 1680
>   * 1678
>   * 1677
>   * 1676
>   * 1674
>   * 1673
>   * 1642
>   * 1624
>   * 1615
>   * 1600
>   * 1545
>   * 1542
> 
> I recognize that this a large backlog of contributions ready to merge, and 
> apologize for asking folks to wait.  However, given current state of the 
> release branches, merging them before we complete fixing the smoke tests 
> would create a moving target that further delay stabilization.  
> 
> Obviously, it is unlikely we will make the 10 October 2016 release date for 
> the 4.8.2.0, 4.9.1.0, and 4.10.0.0 releases.  At this point, it is difficult 
> to estimate the size of the schedule slip because we still have issues to 
> triage and test runs to complete.  I have created a wiki page [2] to track 
> progress on this effort.  
> 
> Does this approach sound reasonable?  Any suggestions to speed up this 
> process will be greatly appreciated as stabilizing and re-opening these 
> branches stable ASAP is critical for the community.
> 
> Thanks,
> -John
> 
> [1]: 
> https://issues.apache.org/jira/browse/CLOUDSTACK-9518?jql=project%20%3D%20CLOUDSTACK%20AND%20fixVersion%20in%20(4.8.2.0)%20AND%20labels%20in%20(4.8.2.0-smoke-test-failure)
> [2]: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65873020
> 
>> On Sep 26, 2016, at 8:38 AM, Will Stevens <wstev...@cloudops.com> wrote:
>> 
>> Yes, I think it is important that you or Rajani sign off on anything that
>> gets in while branches are frozen so you guys can stay on top of what goes
>> in.
>> 
>> Thanks for all the hard work team.  :)
>> 
&

4.8, 4.9, and master Testing Status

[John Burwell]

All,

Using blueorganutan, Rohit, Murali, Boris, Paul, Abhi, and I are executing the 
smoke tests for the 4.8, 4.9, and master branches against the following 
environments:

* CentOS 7.2 Management Server + VMware 5.5u3 + NFS Primary/Secondary 
Storage
* CentOS 7.2 Management Server + XenServer 6.5SP1 + NFS 
Primary/Secondary Storage
* CentOS 7.2 Management Server + CentOS 7.2 KVM + NFS Primary/Secondary 
Storage

Thus far, we have found seven (7) test case and/or CloudStack defects in the 
VMware run for the 4.8 branch [1].  We are currently triaging fifty-one (51) 
new issues from the XenServer run to determine which issues were environmental 
and defects.  This triage work should be completed today (30 Sept 2016).  
Finally, we are awaiting the results of the KVM run.  

We are using PR #1692 [2] as the master tracking PR to fix all defects in the 
4.8 branch.  Our goal is to get all non-skip tests to pass and then merge this 
PR to the 4.8, 4.9, and master.  For each bug, we are creating a JIRA ticket 
and adding a commit to the PR.  Currently, the branch for this PR is in the 
shapeblue repo (the branch started with a much smaller fix from Paul and we 
just kept using it).  However, if others are interested in picking up defects, 
we will move it to ASF repo.  Once the 4.8 branch is stabilized, we plan to 
re-execute these tests on the 4.9 and master branches as we expect that the 4.9 
and master branches will have additional issues.

Since we are in a test freeze, I propose that no further PRs are merged to the 
4.8, 4.9, and master branches until they are stabilized.  The following PRs 
will be re-based, re-tested, and merged to 4.8, 4.9.1.0, and/or 4.10.0.0 
post-stabilization:

* 1696
* 1694
* 1684
* 1681
* 1680
* 1678
* 1677
* 1676
* 1674
* 1673
* 1642
* 1624
* 1615
* 1600
* 1545
* 1542

I recognize that this a large backlog of contributions ready to merge, and 
apologize for asking folks to wait.  However, given current state of the 
release branches, merging them before we complete fixing the smoke tests would 
create a moving target that further delay stabilization.  

Obviously, it is unlikely we will make the 10 October 2016 release date for the 
4.8.2.0, 4.9.1.0, and 4.10.0.0 releases.  At this point, it is difficult to 
estimate the size of the schedule slip because we still have issues to triage 
and test runs to complete.  I have created a wiki page [2] to track progress on 
this effort.  

Does this approach sound reasonable?  Any suggestions to speed up this process 
will be greatly appreciated as stabilizing and re-opening these branches stable 
ASAP is critical for the community.

Thanks,
-John

[1]: 
https://issues.apache.org/jira/browse/CLOUDSTACK-9518?jql=project%20%3D%20CLOUDSTACK%20AND%20fixVersion%20in%20(4.8.2.0)%20AND%20labels%20in%20(4.8.2.0-smoke-test-failure)
[2]: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65873020

> On Sep 26, 2016, at 8:38 AM, Will Stevens <wstev...@cloudops.com> wrote:
> 
> Yes, I think it is important that you or Rajani sign off on anything that
> gets in while branches are frozen so you guys can stay on top of what goes
> in.
> 
> Thanks for all the hard work team.  :)
> 
> *Will STEVENS*
> Lead Developer
> 
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
> 
> On Mon, Sep 26, 2016 at 2:10 AM, John Burwell <john.burw...@shapeblue.com>
> wrote:
> 
>> All,
>> 
>> Per our release schedule [1], the 4.8, 4.9, and master branches are frozen
>> for testing.  There are some straggling PRs that Rajani and I are working
>> to merge.  Is it acceptable to everyone that for the next two (2) weeks,
>> all PRs require not only 2 LGTMs, but approval by Rajani or I to be merged
>> to these branches?  To be clear, we don’t have to perform the merges,
>> simply give a thumbs up.
>> 
>> Thanks,
>> -John
>> john.burw...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
>> @shapeblue
>> 
>> 
>> 
>> 


john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

Re: [RESULT][VOTE] Apache CloudStack 4.8.1

[John Burwell]

Will,

We make a announcement for 4.8.2.0.  I just wanted to make sure that there was 
a 4.8.1 since we are working on 4.8.2.0 …

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Sep 27, 2016, at 1:09 PM, Will Stevens <wstev...@cloudops.com> wrote:
> 
> There is a different thread (take two) which has the official votes and
> such.  I did not do an announcement for the release though.
> 
> *Will STEVENS*
> Lead Developer
> 
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
> 
> On Tue, Sep 27, 2016 at 1:07 PM, Will Stevens <wstev...@cloudops.com> wrote:
> 
>> We did have an official release in the sense that it was voted on and
>> released, but I did not make a big scene about.   You guys were working on
>> 4.8.2 and I just wanted to get it released before you guys modified the
>> branch so the release branching didn't get messed up.
>> 
>> *Will STEVENS*
>> Lead Developer
>> 
>> *CloudOps* *| *Cloud Solutions Experts
>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>> w cloudops.com *|* tw @CloudOps_
>> 
>> On Tue, Sep 27, 2016 at 1:01 PM, John Burwell <john.burw...@shapeblue.com>
>> wrote:
>> 
>>> Will,
>>> 
>>> Have we had an official 4.8.1 release?
>>> 
>>> Thanks,
>>> -John
>>> 
>>>> 
>>> john.burw...@shapeblue.com
>>> www.shapeblue.com
>>> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
>>> @shapeblue
>>> 
>>> 
>>> 
>>> On Aug 15, 2016, at 11:48 AM, Will Stevens <wstev...@cloudops.com> wrote:
>>>> 
>>>> Thanks Milamber.  I will add my own vote.
>>>> 
>>>> *Will STEVENS*
>>>> Lead Developer
>>>> 
>>>> *CloudOps* *| *Cloud Solutions Experts
>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>>> w cloudops.com *|* tw @CloudOps_
>>>> 
>>>> On Mon, Aug 15, 2016 at 11:45 AM, Milamber <milam...@apache.org> wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> This vote isn't compliant with the ASF release vote. We need as least 3
>>>>> PMC +1 vote [1].
>>>>> 
>>>>> Will, you can just vote +1 and resend the result. (Or another PMC
>>> member)
>>>>> 
>>>>> Milamber
>>>>> 
>>>>> [1] http://www.apache.org/foundation/voting.html#ReleaseVotes
>>>>> 
>>>>> 
>>>>> 
>>>>> On 15/08/2016 15:16, Will Stevens wrote:
>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> After 72+ hours, the vote for CloudStack 4.8.1 *passes* with
>>>>>> 2 PMC + 1 non-PMC votes.
>>>>>> 
>>>>>> +1 (PMC / binding)
>>>>>> * Mike Tutkowski
>>>>>> * Milamber
>>>>>> 
>>>>>> +1 (non binding)
>>>>>> * Simon Weller
>>>>>> 
>>>>>> 0
>>>>>> none
>>>>>> 
>>>>>> -1
>>>>>> none
>>>>>> 
>>>>>> Thanks to everyone participating.
>>>>>> 
>>>>>> I will now prepare the release announcement to go out after 24 hours
>>> to
>>>>>> give the mirrors time to catch up.
>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> 
>> 

Re: [RESULT][VOTE] Apache CloudStack 4.8.1

[John Burwell]

Will,

Have we had an official 4.8.1 release?

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Aug 15, 2016, at 11:48 AM, Will Stevens  wrote:
> 
> Thanks Milamber.  I will add my own vote.
> 
> *Will STEVENS*
> Lead Developer
> 
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
> 
> On Mon, Aug 15, 2016 at 11:45 AM, Milamber  wrote:
> 
>> Hello,
>> 
>> This vote isn't compliant with the ASF release vote. We need as least 3
>> PMC +1 vote [1].
>> 
>> Will, you can just vote +1 and resend the result. (Or another PMC member)
>> 
>> Milamber
>> 
>> [1] http://www.apache.org/foundation/voting.html#ReleaseVotes
>> 
>> 
>> 
>> On 15/08/2016 15:16, Will Stevens wrote:
>> 
>>> Hi all,
>>> 
>>> After 72+ hours, the vote for CloudStack 4.8.1 *passes* with
>>> 2 PMC + 1 non-PMC votes.
>>> 
>>> +1 (PMC / binding)
>>> * Mike Tutkowski
>>> * Milamber
>>> 
>>> +1 (non binding)
>>> * Simon Weller
>>> 
>>> 0
>>> none
>>> 
>>> -1
>>> none
>>> 
>>> Thanks to everyone participating.
>>> 
>>> I will now prepare the release announcement to go out after 24 hours to
>>> give the mirrors time to catch up.
>>> 
>>> 
>> 

L10N Translation File Format

[John Burwell]

All,

As part of the effort to remove the requirement for JSPs and streamline the 
development process, Milamber has raised the option of replacing the 
message*.properties files with a JSON key/value format [1].  As I understand 
it, Transifex supports this file format, and it appears that it would simplify 
the PR as it would remove the need to convert the message*.properties files to 
JSON.  Is my understanding correct?  If so, are there any downsides to 
switching over the JSON format?

Thanks,
-John

[1]: https://github.com/apache/cloudstack/pull/1669#issuecomment-249790923

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

4.8, 4.9, and master Branches Frozen for Testing

[John Burwell]

All,

Per our release schedule [1], the 4.8, 4.9, and master branches are frozen for 
testing.  There are some straggling PRs that Rajani and I are working to merge. 
 Is it acceptable to everyone that for the next two (2) weeks, all PRs require 
not only 2 LGTMs, but approval by Rajani or I to be merged to these branches?  
To be clear, we don’t have to perform the merges, simply give a thumbs up.

Thanks,
-John
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

Re: Upcoming 4.8, 4.9, and master Freeze

[John Burwell]

All,

I had intended to complete updates the release schedule [1] early last week, 
but a variety of community and $dayjob activities distracted me.  I apologize 
for the delay.

I have updated the dates to reflect the recent schedule slips.  Also, per our 
recent discussions, I have changed the LTS process to be a long-running release 
branch rather a separate branch.  Maintenance releases for LTS branches are now 
scheduled to occur monthly for the first 14 months of an LTS branch’s support 
period.

Please let me know if there is any additional feedback,
-John

[1]: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/%5BPROPOSAL%5D+2016-2017+Release+Cycle+and+Calendar

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Sep 19, 2016, at 1:18 AM, John Burwell <john.burw...@shapeblue.com> wrote:
> 
> All,
> 
> The 4.8.2.0 and 4.9.1.0 releases have taken more time than expected to 
> finalize.  Per our original schedule [1], 4.9.2.0 and 4.10.0.0 were scheduled 
> to freeze yesterday (18 September 2016).  I propose the following schedule 
> and end-of-life (EOL) changes:
> 
>* 4.8.2.0 is still open, but 4.8 EOL is scheduled for 19 September 2016.  
> I propose freezing the 4.8 branch this Sunday, 25 Sept 2016, and extending 
> the EOL to 31 October 2016.  This extension will provide 4.8 users with a 
> slightly longer support period to compensate the schedule delays.  With one 
> week to test and one week for RC voting, the 4.10.0.0 release date would be 
> pushed out to 10 October 2016.
>* Since we are still working to close out 4.9.1.0, I am proposing that we 
> combine 4.9.1.0 and 4.9.2.0 into the 4.9.1.0 release, and extend the freeze 
> date to 25 Sept 2016 in order to close out open issues.  With one week to 
> test and one week for RC voting, the 4.10.0.0 release date would be pushed 
> out to 10 October 2016.
>* Extend the 4.10.0.0 freeze date by one (1) week to this Sunday, 25 Sept 
> 2016.  With one week to test and one week for RC voting, the 4.10.0.0 release 
> date would be pushed out to 10 October 2016.
> 
> Assuming these changes are acceptable, i will update the release schedule [1] 
> to reflect the new dates and cascade the changes out to future releases by 
> COB Monday (19 Sept 2016).
> 
> I have captured a list of open PRs and JIRA tickets to target for 4.8.2.0, 
> 4.9.1.0, and 4.10.0.0 in a Google Sheet [2].  Please review and let me know 
> if any additional items should be added.  Of note, we have two potential 
> blockers for all three (3) releases — CLOUDSTACK-9489 [3] and CLOUDSTACK-9497 
> [4].  Finally, except for blockers, these are best effort targets.  If they 
> are not closed out by 25 Sept 2016, the release branches will be frozen and 
> any open PRs will be deferred to the next release cycle.
> 
> Thanks,
> -John
> 
> [1]: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/%5BPROPOSAL%5D+2016-2017+Release+Cycle+and+Calendar<https://cwiki.apache.org/confluence/display/CLOUDSTACK/[PROPOSAL]+2016-2017+Release+Cycle+and+Calendar>
> [2]: 
> https://docs.google.com/spreadsheets/d/1N9Mrg-RQZRch3x2BoRutGQKija_TnQC5tnaNOWy0IuY/edit?usp=sharing
> [3]: https://issues.apache.org/jira/browse/CLOUDSTACK-9489
> [4]: https://issues.apache.org/jira/browse/CLOUDSTACK-9497
> 
> 
> john.burw...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
> 
> 
> 

Re: Request for comments: Moving to Spring 4 and Java 8

[John Burwell]

All,

Reviving this thread as it would be a Good Thing(tm) to get Spring 4 merged for 
4.10.0.0.  Based on Rohit’s original question, it appears that the only issue 
is F5 on Java8 (not on Java7).  Is there someone available with F5 knowledge 
who can investigate it?  If not, would it be acceptable to limit F5 users of 
4.10.0.0 to Java7 due to this issue? 

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Aug 12, 2016, at 8:14 AM, Rohit Yadav  wrote:
> 
> All,
> 
> 
> It's about time to migrate master to Java 8 JDK and Spring 4. Please help 
> review the following PRs:
> 
> https://github.com/apache/cloudstack/pull/1638
> 
> 
> There are three outstanding issues that I need help and feedback on:
> 
> 
> 1. F5 plugin fails to build due to issue likely in the axis dependency 
> library, I've disabled it from the build now. Do we have a F5 
> developer/maintainer who can look at it.
> 
> 
> 2. Two unit tests failures due to Spring 4 migration:
> 
> com/cloud/vm/DeploymentPlanningManagerImplTest.java
> 
> com/globo/globodns/cloudstack/resource/GloboDnsResourceTest.java
> 
> 
> Do we have anyone who can help fix the above tests? Deployment planner 
> developers, or globo-dns plugin maintainers?
> 
> 
> 3. In general, the end-to-end testing of plugins. There may be plugins which 
> are not maintained or used anymore, we need discuss how to deal with them 
> moving forward. As a first step we may want to start disable them from the 
> build, especially those failing builds.
> 
> 
> Comments, feedback? Thanks.
> 
> 
> Regards.
> 
> rohit.ya...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 

Upcoming 4.8, 4.9, and master Freeze

[John Burwell]

All,

The 4.8.2.0 and 4.9.1.0 releases have taken more time than expected to 
finalize.  Per our original schedule [1], 4.9.2.0 and 4.10.0.0 were scheduled 
to freeze yesterday (18 September 2016).  I propose the following schedule and 
end-of-life (EOL) changes:

* 4.8.2.0 is still open, but 4.8 EOL is scheduled for 19 September 2016.  I 
propose freezing the 4.8 branch this Sunday, 25 Sept 2016, and extending the 
EOL to 31 October 2016.  This extension will provide 4.8 users with a slightly 
longer support period to compensate the schedule delays.  With one week to test 
and one week for RC voting, the 4.10.0.0 release date would be pushed out to 10 
October 2016.
* Since we are still working to close out 4.9.1.0, I am proposing that we 
combine 4.9.1.0 and 4.9.2.0 into the 4.9.1.0 release, and extend the freeze 
date to 25 Sept 2016 in order to close out open issues.  With one week to test 
and one week for RC voting, the 4.10.0.0 release date would be pushed out to 10 
October 2016.
* Extend the 4.10.0.0 freeze date by one (1) week to this Sunday, 25 Sept 
2016.  With one week to test and one week for RC voting, the 4.10.0.0 release 
date would be pushed out to 10 October 2016.

Assuming these changes are acceptable, i will update the release schedule [1] 
to reflect the new dates and cascade the changes out to future releases by COB 
Monday (19 Sept 2016).

I have captured a list of open PRs and JIRA tickets to target for 4.8.2.0, 
4.9.1.0, and 4.10.0.0 in a Google Sheet [2].  Please review and let me know if 
any additional items should be added.  Of note, we have two potential blockers 
for all three (3) releases — CLOUDSTACK-9489 [3] and CLOUDSTACK-9497 [4].  
Finally, except for blockers, these are best effort targets.  If they are not 
closed out by 25 Sept 2016, the release branches will be frozen and any open 
PRs will be deferred to the next release cycle.

Thanks,
-John

[1]: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/%5BPROPOSAL%5D+2016-2017+Release+Cycle+and+Calendar
[2]: 
https://docs.google.com/spreadsheets/d/1N9Mrg-RQZRch3x2BoRutGQKija_TnQC5tnaNOWy0IuY/edit?usp=sharing
[3]: https://issues.apache.org/jira/browse/CLOUDSTACK-9489
[4]: https://issues.apache.org/jira/browse/CLOUDSTACK-9497


john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

Re: builds.cloudstack.org (new jenkins system)

[John Burwell]

Pierre-Luc,

It is possible to have the new Jenkins authenticate against he ASF LDAP?  Since 
the ASF LDAP reflects who is a committer, we wouldn’t have to manage multiple 
authentication repositories.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Sep 14, 2016, at 1:08 AM, Rajani Karuturi  wrote:
> 
> This is great. Thanks for setting it up PL.
> 
> If possible, could you also move the coverity job[1] to the new
> jenkins please?
> CloudStack coverity report last ran on Jan 25, 2016
> 
> [1]
> http://jenkins.buildacloud.org/job/cloudstack-master-twiceweekly-coverity/
> 
> Thanks,
> ~ Rajani
> http://cloudplatform.accelerite.com/
> 
> On September 14, 2016 at 12:11 AM, Pierre-Luc Dion
> (pdion...@apache.org) wrote:
> Hi,
> 
> we now have a nice URL pointing to the replacement jenkins
> of j.bac.o:
> builds.cloudstack.org
> 
> I'll make sure the enable SSL for user authentication, whoever is
> commiter
> that want admin access to Jenkins, let me know, if you have CI
> system that
> we could leverage via a centralized portal, feel free to post on
> dev@
> 
> Cheers,
> 
> PL

Re: [DISCUSS] Replacing the VR

[John Burwell]

Will,

Typo.  “application model” was meant to be “appliance model”.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Sep 12, 2016, at 4:35 PM, John Burwell <john.burw...@shapeblue.com> wrote:
> 
> Will,
> 
> I agree that we need to replace the VR, but I am not convinced that 
> continuing with the notion of a monolithic application model is a best 
> direction.  The problem with the current model is that it lacks flexibility.  
> Some users only need to deploy DHCP and DNS across a zone where others need a 
> much wider range of services at the pod or cluster level.  With the 
> monolithic appliance, we are forced to build to the lowest common denominator.
> 
> I would like to see the VR’s functions disambiguated likely into containers 
> (Zones/LXC-style rather than requiring the Docker/rkt runtime).  With this 
> subdivision, we could then adopt the service chain model and allow users to 
> compose networks services to better fit their use cases.
> 
> My thinking is that if we are going to through the (continuing) pain of 
> another VR replacement, we should take the opportunity to re-evaluate the 
> entire model.
> 
> Thanks,
> -John
> 
>> 
> john.burw...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
> 
> 
> 
> On Sep 12, 2016, at 4:20 PM, Will Stevens <williamstev...@gmail.com> wrote:
>> 
>> *Disclaimer:* This is a thought experiment and should be treated as such.
>> Please weigh in with the good and bad of this idea...
>> 
>> A couple of us have been discussing the idea of potentially replacing the
>> ACS VR with the VyOS [1] (Open Source Vyatta VM).  There may be a license
>> issue because I think it is licensed under GPL, but for the sake of
>> discussion, let's assume we can overcome any license issues.
>> 
>> I have spent some time recently with the VyOS and I have to admit, I was
>> pretty impressed.  It is simple and intuitive and it gives you a lot more
>> options for auditing the configuration etc...
>> 
>> Items of potential interest:
>> - Clean up our current VR script spaghetti to a simpler more auditable
>> configuration workflow.
>> - Gives a cleaner path for IPv6 support.
>> - Handles VPN configuration via the same configuration interface.
>> - Support for OSPF & BGP.
>> - VPN support through OpenVPN & StrongSwan.
>> - Easily supports HA (redundant routers) through VRRP.
>> - VXLAN support.
>> - Transaction based changes to the VR with rollback on error.
>> 
>> Items that could be difficult to solve:
>> - Userdata password reset workflow and implementation.
>> - Upgrade process.
>> 
>> The VyOS is not the only option if we were to consider this approach.
>> Another option, which I don't know as well, would be CloudRouter (AGPL
>> license) [2] which is purely API driven.
>> 
>> Anyway, would love to hear your thoughts...
>> 
>> Will
>> 
>> [1] https://vyos.io/
>> [2] https://cloudrouter.org/
> 

Re: [DISCUSS] Replacing the VR

[John Burwell]

Will,

I agree that we need to replace the VR, but I am not convinced that continuing 
with the notion of a monolithic application model is a best direction.  The 
problem with the current model is that it lacks flexibility.  Some users only 
need to deploy DHCP and DNS across a zone where others need a much wider range 
of services at the pod or cluster level.  With the monolithic appliance, we are 
forced to build to the lowest common denominator.

I would like to see the VR’s functions disambiguated likely into containers 
(Zones/LXC-style rather than requiring the Docker/rkt runtime).  With this 
subdivision, we could then adopt the service chain model and allow users to 
compose networks services to better fit their use cases.

My thinking is that if we are going to through the (continuing) pain of another 
VR replacement, we should take the opportunity to re-evaluate the entire model.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Sep 12, 2016, at 4:20 PM, Will Stevens  wrote:
> 
> *Disclaimer:* This is a thought experiment and should be treated as such.
> Please weigh in with the good and bad of this idea...
> 
> A couple of us have been discussing the idea of potentially replacing the
> ACS VR with the VyOS [1] (Open Source Vyatta VM).  There may be a license
> issue because I think it is licensed under GPL, but for the sake of
> discussion, let's assume we can overcome any license issues.
> 
> I have spent some time recently with the VyOS and I have to admit, I was
> pretty impressed.  It is simple and intuitive and it gives you a lot more
> options for auditing the configuration etc...
> 
> Items of potential interest:
> - Clean up our current VR script spaghetti to a simpler more auditable
> configuration workflow.
> - Gives a cleaner path for IPv6 support.
> - Handles VPN configuration via the same configuration interface.
> - Support for OSPF & BGP.
> - VPN support through OpenVPN & StrongSwan.
> - Easily supports HA (redundant routers) through VRRP.
> - VXLAN support.
> - Transaction based changes to the VR with rollback on error.
> 
> Items that could be difficult to solve:
> - Userdata password reset workflow and implementation.
> - Upgrade process.
> 
> The VyOS is not the only option if we were to consider this approach.
> Another option, which I don't know as well, would be CloudRouter (AGPL
> license) [2] which is purely API driven.
> 
> Anyway, would love to hear your thoughts...
> 
> Will
> 
> [1] https://vyos.io/
> [2] https://cloudrouter.org/

Re: [GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

[John Burwell]

Sergey,

We are working on a full automated build pipeline that will test against a wide 
range of configurations.  Ideally, the pipeline will work as follows:

 1. PR is submitted -> the PR is built, unit tested, and run through static 
analysis.  Smoke tests are run on a matrix of configurations
 2. The PR is reviewed by two or more committers
 3. When a PR commit receives two or more LGTMs and no -1s, it is enqueued 
to be merged to the target branch
 4. When it’s PR’s turn to be merged, it merged against the target release 
branch and rebuilt (unit tests + static analysis), packaged, and tested (smoke 
test + a set of component tests) on a matrix of configurations
 5. If the PR needs to be forward merged, it is enqueued for the next 
branch and Step 4 is re-executed

In this system, only one PR would be actively merged at a time.  Steps 4 and 5 
are repeated until the PR is merged to master.  This process not only ensures 
that the PR is adequately reviewed and tested, and it also detects introduced 
by merges of adjacent PRs.  blueorganatan is first step in the process which 
provides a way for indicate that a PR is ready for the next step.

We are working towards such a system, but, obviously, there are a lot of pieces 
we need to refine/develop and integrate.  I am working up a release management 
roadmap to capture these ideas in more detail which I hope publish in the near 
future,

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Sep 12, 2016, at 3:29 PM, Sergey Levitskiy  
wrote:
> 
> @swill @jburwell From my, non-committer, point of view introducing fully 
> automated test system integrated with PR submission and leveraging complete 
> list of supported hypervisors is the key to stability. I really like 
> blueorangutain idea and if this can be brought back and also cover full set 
> of integration tests along with packaging that would be awesome. When we 
> develop PR unfortunately we can only test it only with a certain set of 
> hypervisors and network configs so although giving test LGTM it doesn’t cover 
> all possible integration points. I believe most other test results people 
> execute manually and post on PRs are the same.
> 
> 
> On 9/12/16, 11:38 AM, "jburwell"  wrote:
> Even 
>Github user jburwell commented on the issue:
> 
>https://github.com/apache/cloudstack/pull/1658
> 
>@swill where hardware are being varies by PR.  In some cases, we have 
> people running them in their labs and reporting results.  Other cases, it's 
> blueorangatan going through ShapeBlue Jenkins + trillian.  But yes, PRs are 
> getting tested on hardware.
> 
>(Sadly, we are still recovering from a dead storage array, so 
> blueorangatan has been out of commission for a little bit),
> 
> 
>---
>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.
>---
> 
> 
> 

Merging PRs

[John Burwell]

All,

There appears to be some confusion around who can merge a PR and when it should 
occur.  Section 2.3 of bylaws [1] are very clear, any committer may commit code 
to any branch.  As a community, we have agreed that non-security contributions 
should be submitted as a PR, and that a PR must meet the following criteria in 
order to be merged to a release branch:

* At least code review LGTM
* At least test LGTM
* No -1s

There have also been questions about what qualifies as a test LGTM.  Code 
reviewers should expect either new or updated Marvin test cases that verify the 
issue being addressed by the PR.  For my reviews, I consider a valid test LGTM 
to have the following characteristics:

   * All smoke tests run against hardware.  Ideally, against all 3 hypervisors 
when the change is core.
   * A set of additional component tests that cover the the functionality that 
has been modified including tests added for the change

When a PR meets this criteria, any committer may merge a PR using the process 
described in the this wiki topic [2].  As a release manager, I regularly check 
merges to release branches ensure that they meet this threshold.  If I find a 
non-security merge that does not meet this criteria, I will roll it back and 
work with the contributors involved to merged it once the threshold has been 
met.

I plan to update the release section of the wiki in the near future to clarify 
these points to remove crufty/duplicative information.  I apologize for the 
confusion, and hope this email clarifies the merge process until I complete the 
wiki update.

Thanks,
-John

[1]: https://cloudstack.apache.org/bylaws.html
[2]: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6andup-HowtomergeaPullRequest?

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

Re: PR reviews for 4.10.0 release

[John Burwell]

Kris,

Looking at the history of the PR, there appears to be one LGTM for testing the 
PR scope.  Given the size of the change, it seems appropriate to run a 
regression test.  However, there are no results indicating a regression test 
has been run.

I also reviewed the code and left comments to move towards getting a code 
review LGTM.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Sep 6, 2016, at 3:10 PM, Kris Sterckx  wrote:
> 
> Thanks Rajani
> 
> https://github.com/apache/cloudstack/pull/1578 has votes and tests pass.
> 
> What would be the next step ?
> 
> Best,
> 
> Kris
> 
> 
> 
> On 30 August 2016 at 07:24, Rajani Karuturi  wrote:
> 
>> If you could get 2 LGTMs(any one from your team can also review
>> and give LGTM) and if you can run BVT suite on
>> PR(https://github.com/apache/cloudstack/tree/master/test/integration/smoke
>> ),
>> they can be immediately merged.
>> 
>> ~ Rajani
>> http://cloudplatform.accelerite.com/
>> 
>> On August 30, 2016 at 3:47 AM, Kris Sterckx
>> (kris.ster...@nuagenetworks.net) wrote:
>> Hi All,
>> 
>> The Nuage Networks team is investing in ACS 4.10.0 and has
>> several feature
>> PR's outstanding for review :
>> 
>> - https://github.com/apache/cloudstack/pull/1578
>> - https://github.com/apache/cloudstack/pull/1580
>> - https://github.com/apache/cloudstack/pull/1579
>> - https://github.com/apache/cloudstack/pull/1577
>> 
>> How can we better facilitate the review of these PR's ?
>> 
>> Thanks,
>> 
>> - Kris
>> 
>> --
>> Kris Sterckx
>> 
>> CloudStack Development Lead
>> 
>> Nuage Networks
>> 

Re: 4.8.2.0/4.9.1.0 RC Status

[John Burwell]

All,

We are still working to merge the PR necessary to create the 4.8.2.0 and 
4.9.1.0 RCs.  The following is the status of the PRs targeted for 4.8.2.0:

* 1635 [1]: CLOUDSTACK-9451 — one open code review item and needs a test 
LGTM
* 1636 [2]: Fix a quote issue with Spanish L10N (from transifex 
translation) — MERGED
* 1654 [3]: Updating pom.xml version numbers for release 4.8.2.0-SNAPSHOT — 
MERGED
* 1624 [4]: Fixes regarding VOLUME_DELETE events resulting from account 
deletion — needs a test LGTM

The following is the status of the PRs targeted for 4.9.1.0:

* 1621 [5]: [CLOUDSTACK-9444] Fix a little issue from PR1610 if the 
db.properties file hasn't EOL character at the end of file — MERGED
* 1648 [6]: test/integration: fix tearDown order in list_acl_ tests — MERGED
* 1663 [7]/1653 [8]: [LTS/blocker] CLOUDSTACK-6432: Prevent DNS reflection 
attacks — MERGED/CLOSED
* 1660 [9]: CLOUDSTACK-9470: [BLOCKER] Bug in SshHelper affecting 
interaction with vRouter in VmwareResource and HypervDirectConnectResource — 
open code review issue
* 1665 [10]: Changes database upgrade script names to be consistent for the 
4.9.1.0 release — Needs a test LGTM

Any help pulling completing the remaining PRs would be greatly appreciated.

Thanks,
-John

[1]: https://github.com/apache/cloudstack/pull/1635
[2]: https://github.com/apache/cloudstack/pull/1636
[3]: https://github.com/apache/cloudstack/pull/1654
[4]: https://github.com/apache/cloudstack/pull/1624
[5]: https://github.com/apache/cloudstack/pull/1621
[6]: https://github.com/apache/cloudstack/pull/1648
[7]: https://github.com/apache/cloudstack/pull/1663
[8]: https://github.com/apache/cloudstack/pull/1653
[9]: https://github.com/apache/cloudstack/pull/1660
[10]: https://github.com/apache/cloudstack/pull/1665

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Aug 28, 2016, at 11:14 PM, John Burwell <john.burw...@shapeblue.com> wrote:
> 
> All,
> 
> I apologize for being behind getting the 4.8.2.0 and 4.9.1.0 RCs out.  A 
> small part of it was due to the RC release dates falling the weekend after 
> being on vacation, and a large part of it is due to rookie mistakes as a 
> first time RM.  Hopefully, the lessons learned will keep things on-time for 
> the 4.9.2.0 and 4.10.0.0 releases.
> 
> The big lesson learned is that we need to watching the candidate PRs for a 
> release about 7-10 days in advance of a release.  To that end, we have the 
> following are the PRs targeted for 4.8.2.0 and 4.9.1.0 which need to be 
> closed before we can cut an RC:
> 
>* 1635 [1]: CLOUDSTACK-9451
>* 1636 [2]: Fix a quote issue with Spanish L10N (from transifex 
> translation)
>* 1654 [3]: Updating pom.xml version numbers for release 4.8.2.0-SNAPSHOT
>* 1624 [4]: Fixes regarding VOLUME_DELETE events resulting from account 
> deletion
> 
> The following are the PRs targeted for 4.9.1.0 which need to be closed be we 
> can cut an RC:
> 
>* 1621 [5]: [CLOUDSTACK-9444] Fix a little issue from PR1610 if the 
> db.properties file hasn't EOL character at the end of file
>* 1648 [6]: test/integration: fix tearDown order in list_acl_ tests
>* 1663 [7]/1653 [8]: [LTS/blocker] CLOUDSTACK-6432: Prevent DNS reflection 
> attacks (
>* 1660 [9]: CLOUDSTACK-9470: [BLOCKER] Bug in SshHelper affecting 
> interaction with vRouter in VmwareResource and HypervDirectConnectResource
>* 1665 [10]: Changes database upgrade script names to be consistent for 
> the 4.9.1.0 release
> 
> Please let me know if there is a PR or defect you feel must be addressed in 
> order to ship either 4.8.2.0 or 4.9.1.0.  Otherwise, we will be working to 
> get these PRs merged ASAP and cut RCs for voting.
> 
> Thank you for patience as I stumble through this process for the first time,
> -John
> 
> [1]: https://github.com/apache/cloudstack/pull/1635
> [2]: https://github.com/apache/cloudstack/pull/1636
> [3]: https://github.com/apache/cloudstack/pull/1654
> [4]: https://github.com/apache/cloudstack/pull/1624
> [5]: https://github.com/apache/cloudstack/pull/1621
> [6]: https://github.com/apache/cloudstack/pull/1648
> [7]: https://github.com/apache/cloudstack/pull/1663
> [8]: https://github.com/apache/cloudstack/pull/1653
> [9]: https://github.com/apache/cloudstack/pull/1660
> [10]: https://github.com/apache/cloudstack/pull/1665
> 
> 
> john.burw...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
> 
> 
> 

4.8.2.0/4.9.1.0 RC Status

[John Burwell]

All,

I apologize for being behind getting the 4.8.2.0 and 4.9.1.0 RCs out.  A small 
part of it was due to the RC release dates falling the weekend after being on 
vacation, and a large part of it is due to rookie mistakes as a first time RM.  
Hopefully, the lessons learned will keep things on-time for the 4.9.2.0 and 
4.10.0.0 releases.

The big lesson learned is that we need to watching the candidate PRs for a 
release about 7-10 days in advance of a release.  To that end, we have the 
following are the PRs targeted for 4.8.2.0 and 4.9.1.0 which need to be closed 
before we can cut an RC:

* 1635 [1]: CLOUDSTACK-9451
* 1636 [2]: Fix a quote issue with Spanish L10N (from transifex translation)
* 1654 [3]: Updating pom.xml version numbers for release 4.8.2.0-SNAPSHOT
* 1624 [4]: Fixes regarding VOLUME_DELETE events resulting from account 
deletion

The following are the PRs targeted for 4.9.1.0 which need to be closed be we 
can cut an RC:

* 1621 [5]: [CLOUDSTACK-9444] Fix a little issue from PR1610 if the 
db.properties file hasn't EOL character at the end of file
* 1648 [6]: test/integration: fix tearDown order in list_acl_ tests
* 1663 [7]/1653 [8]: [LTS/blocker] CLOUDSTACK-6432: Prevent DNS reflection 
attacks (
* 1660 [9]: CLOUDSTACK-9470: [BLOCKER] Bug in SshHelper affecting 
interaction with vRouter in VmwareResource and HypervDirectConnectResource
* 1665 [10]: Changes database upgrade script names to be consistent for the 
4.9.1.0 release

Please let me know if there is a PR or defect you feel must be addressed in 
order to ship either 4.8.2.0 or 4.9.1.0.  Otherwise, we will be working to get 
these PRs merged ASAP and cut RCs for voting.

Thank you for patience as I stumble through this process for the first time,
-John

[1]: https://github.com/apache/cloudstack/pull/1635
[2]: https://github.com/apache/cloudstack/pull/1636
[3]: https://github.com/apache/cloudstack/pull/1654
[4]: https://github.com/apache/cloudstack/pull/1624
[5]: https://github.com/apache/cloudstack/pull/1621
[6]: https://github.com/apache/cloudstack/pull/1648
[7]: https://github.com/apache/cloudstack/pull/1663
[8]: https://github.com/apache/cloudstack/pull/1653
[9]: https://github.com/apache/cloudstack/pull/1660
[10]: https://github.com/apache/cloudstack/pull/1665


john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

Re: Eliminating Support for Ubuntu 12.04

[John Burwell]

Wido,

My only issue is dropping for any distro between patch releases.  If someone is 
running 4.9.0.0 on Ubuntu 12.04, and they need to update to 4.9.1.0+ (e.g. to 
get a CVE fix), they will be stranded.  This failure seems to fail the Law of 
Least Surprise.  While I recognize that it is unlikely that we have people 
running 4.9 on 12.04, it is impossible to be certain.  Therefore, I vote to 
play it safe, and continue to support it in 4.9 release branch.

For master (i.e. 4.10.0.0), Wido makes a strong case for dropping Ubuntu 12.04. 
 If any users are using Ubuntu 12.04 when 4.10.0 is released, they would have a 
supported release well past the April 2017 EOL since 4.9 is an LTS release.  
Therefore, removing Ubuntu 12.04 support from 4.10.0.0 seems like a Good Thing 
(tm) in terms of simplifying the code and testing matrix.

Can everyone accept that the 4.9 release branch will be the last to support 
Ubuntu 12.04?  If so, we can repoint the PR and merge it.

In terms of Ubuntu 16.04 support, ideally we would support it in 4.9.1.0+.  
However, if I understand Wido correctly, supporting Ubuntu 12.04 and 16.04 in 
the same branch is very difficult or impossible.  Am I correct in my 
understanding?

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Aug 23, 2016, at 6:14 AM, Wido den Hollander <w...@widodh.nl> wrote:
> 
>> 
>> Op 23 augustus 2016 om 11:38 schreef Rohit Yadav <rohit.ya...@shapeblue.com>:
>> 
>> 
>> Historically, CloudStack's debian/deb packages/repositories have never been 
>> supported by the initial authors. For example, initial ACS version and all 
>> CCP releases never shipped deb packages, nor in our (old and recent) 
>> documentation we promote installation/running CloudStack on Debian/Ubuntu. 
>> Afaik, it was Wido who introduced it because he wanted to run CloudStack on 
>> Ubuntu/Debian-based distro. Also, the packages are something that the 
>> project never shipped or endorsed or supported, so it's up to the 
>> maintainers of various repositories how they are building and hosting 
>> CloudStack packages. Even if we remove the packaging support in our 
>> branch/repository, anyone can build CloudStack for any distro, several 
>> people/projects have packaging related buildsystem/code separated from the 
>> project codebase. Most tutorials that I found are based around Ubuntu 14.04 
>> or CentOS, given that 12.04 is 4+ years old, we might not even have anyone 
>> using CloudStack on it.
>> 
> 
> I highly doubt somebody still runs Ubuntu 12.04 with a recent version of 
> CloudStack.
> 
> 4+ years in Qemu/libvirt time is a very long time.
> 
>> 
>> That said -- I think 4.9 should at least not drop the support yet, just to 
>> let any Ubuntu 12.04 user who may be using it in the wild. If we look at the 
>> PR, the way we're dropping the support is by simply bumping up few package 
>> dependency versions. The issue of supporting or dropping support for Ubuntu 
>> 12.04 lies in those version changes only.
>> 
>> 
>> The more important thing right now is to support at least Ubuntu 16.04 hosts 
>> as KVM guests and usage-server hosts, which is much needed in both 4.9 and 
>> master branch for the upcoming 4.9.1.0 and 4.10.0.0 releases.
>> 
>> 
>> Wido -- would it be acceptable to avoid bumping up the min. package 
>> dependency version, i.e we don't change the pkg dependencies for 
>> cloudstack-agent and keep the version number as it is for lsb-base, 
>> qemu-kvm, libvirt-bin for 4.9 branch. While on 4.10, we can discuss if we 
>> want to drop the support now or plan this later.
>> 
>> 
> 
> Well, yes. But I don't know *what* might break on 12.04. I wrote the PR in 
> May and there must have been a reason for that.
> 
> Feel free to modify the PR and not bump those versions. Packages might work 
> or not, not completely sure.
> 
> Wido
> 
>> Regards.
>> 
>> 
>> From: Wido den Hollander <w...@widodh.nl>
>> Sent: 23 August 2016 11:38:43
>> To: dev@cloudstack.apache.org; John Burwell; us...@cloudstack.apache.org
>> Subject: Re: Eliminating Support for Ubuntu 12.04
>> 
>> 
>>> Op 23 augustus 2016 om 1:02 schreef John Burwell 
>>> <john.burw...@shapeblue.com>:
>>> 
>>> 
>>> All,
>>> 
>>> PR 1647 [1] proposes dropping support for Ubuntu 12.04 from 4.9.2.0+.  The 
>>> primary motivation for its removal is that the age of its libvirt and qemu 
>>> versions greatly complicate maintenance of the KVM integration.  However, 
>>> Ubun

Eliminating Support for Ubuntu 12.04

[John Burwell]

All,

PR 1647 [1] proposes dropping support for Ubuntu 12.04 from 4.9.2.0+.  The 
primary motivation for its removal is that the age of its libvirt and qemu 
versions greatly complicate maintenance of the KVM integration.  However, 
Ubuntu 12.04 will be supported until April 2017 [2]. What would be the impact 
to our user community of removing support for Ubuntu 12.04 before its EOL in 
April 2017?  If we don’t drop support for it in 4.x, would it be acceptable to 
drop support for it in 5.0.0 which is currently scheduled for release at the 
end of 2016 [3]?

If we do chose to drop support for Ubuntu 12.04 in 4.x, I propose that we 
remove it in 4.10.0.0 rather than 4.9.2.0.  First, it is reasonable for users 
to expect that upgrading between patch releases (i.e. 4.9.x.x -> 4.9.x+1.x) 
would not require system changes.  Dropping a distribution would violate such 
an expectation.  Second, 4.9 is an LTS branch.  Therefore, maintaining 12.04 
support in 4.9 would provide LTS users with support for Ubuntu 12.04 until May 
2018 — well after its EOL.  Does this approach seem reasonable if we elect drop 
Ubuntu 12.04 in 4.x?

Thanks,
-John

[1]: https://github.com/apache/cloudstack/pull/1647
[2]: https://wiki.ubuntu.com/Releases
[3]: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/%5BPROPOSAL%5D+2016-2017+Release+Cycle+and+Calendar



john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

4.8.2.0 and 4.9.1.0 Testing

[John Burwell]

All,

Per our release schedule [1], the 4.8 and 4.9 branches enter a soft freeze for 
testing for the 4.8.2.0 and 4.9.1.0 testing effective 14 August 2016 @  
GMT.  During this period, only defects that stabilize changes since the 
previous release should be merged into these release branches.  This test 
period is scheduled to occur from 15 to 20 August 2016 with a release candidate 
being published on or about 21 August 2016 @  GMT.

Thanks,
-John
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

Vacation

[John Burwell]

All,

I will be out on vacation 15-19 August 2016.  I will try to keep an eye on dev@ 
and PRs, but my responses may lag as I will only be checking mail periodically.

Thanks,
-John
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

Re: VPN User/Pass printed in plain text during boot of VRouter

[John Burwell]

Matthew,

Thank you for the report.  I have forwarded this report to security@ for 
further investigation.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Aug 11, 2016, at 8:14 AM, Matthew Smart  wrote:
> 
> Sorry. My subject line was incorrect.
> 
> Hey guys,
> 
> I am new to Cloudstack and Apache (from a dev perspective) so forgive me if 
> this is not the proper place for this... and let me know where I should be 
> reporting issues like this.
> 
> I am getting Remote Access VPN configured in my test environment and in my 
> debugging I noticed that if you view the VRouter's console while it is 
> booting it prints out the vpn usernames and passwords in plaintext.
> 
> I am sure some debug statements just got left in by accident.
> 
> I am running Cloudstack 4.8.0 and using SystemVM Template version 4.6 for KVM.
> 
> Thanks,
> 
> Matthew Smart
> President
> Smart Software Solutions Inc.
> 108 S Pierre St.
> Pierre, SD 57501
> 
> Phone: (605) 280-0383
> Skype: msmart13
> Email: msm...@smartsoftwareinc.com
> 
> 

Re: 4.10.0 release

[John Burwell]

Will and Rajani,

I recall the motivations for the release principles well.  Their primary 
intention was to improve the testing and codify review requirements for commits 
to a release branch.  In my view, this goal does not require that only a few 
people perform merges to release branches.  We should let any committer merge a 
PR that has the requisite LGTMs.  I also believe we need to be a bit nuanced 
about the requirement to test every PR against hardware.  While most PRs 
require this level of testing, we have plenty of PRs that do not impact 
hardware (e.g. UI changes, code cleanups, etc).  I am in favor of refining the 
release principles to say that the test LGTM for any PR that impacts 
provisioning/management of hardware must include hardware tests.  As we monitor 
merges to master, if we find any PRs that do impact these functions that have 
not been tested against hardware then we will roll them back and work with the 
author to complete that testing.

Rohit is currently creating a Jenkins build pipeline that builds a PR, creates 
a test environment using Trillian, and runs the tests.  He is nearly finished.  
When he is done, I get him to push docs to the Trillian repo and open a 
discussion on dev@.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Aug 4, 2016, at 1:29 PM, Will Stevens <wstev...@cloudops.com> wrote:
> 
> Rajani, you have very valid points and they echo my concerns.
> 
> I also agree that the CI (actual testing of PRs against real hardware
> environments) is required in order for a PR to be committed.  This is where
> ALL the work is for the RM in the current process.  As RM, I ended up with
> 10 CI environments running in parallel in order to get testing done to at
> least a basic level.  This type of testing MUST continue or we are at risk
> of falling into old pitfalls around stability.
> 
> John and Paul, how feasible would it be for me to setup an automated
> process for pulling and testing PRs with Trillian?  I have environments
> that I can test on, but I don't have the time to manage 8=10 environments
> testing in parallel by hand.  We need get to the point where PRs are queued
> and the testing of these PRs on real hardware is automated.  The manual
> approach is not viable long term (trust me).  :)
> 
> *Will STEVENS*
> Lead Developer
> 
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
> 
> On Thu, Aug 4, 2016 at 1:19 PM, Rajani Karuturi <raj...@apache.org> wrote:
> 
>> John,
>> We understand the bylaws. But, practically we saw master in an unusable
>> state for many months. This is not just about trust. CloudStack is so vast
>> that its difficult for a single person to test all the affected areas. Many
>> a times, people does not even have enough hardware/knowledge to run
>> integration tests. Bugs which are found at a later point of time have very
>> high cost. Finding that commit which broke something is very hard task.
>> Rolling back is the easiest part of it.
>> 
>> In an ideal world, we could just allow everyone to commit (maybe we could
>> even allow non committers to commit and increase the velocity). But, it did
>> not workout. which is why we have all these rules based on previous
>> learning. For 4.6, we did not start with RM only merges. But, after many
>> failed attempts we came to that conclusion.
>> 
>> Watching the branches and policing is more difficult than allowing only a
>> few people to commit.
>> 
>> I do understand Rohit's concern about RM being bottleneck. The initial idea
>> was we will have more than one RM(may be around 5) so that one of them
>> would be available always. But, given the amount of time it takes to do the
>> RM job, we did not get enough volunteers.
>> 
>> Even now, I dont think its the RM that is the bottleneck. But, its the
>> number of people with real hardware who are willing to run integration
>> tests for the PRs. Most of the efforts of RM goes in setting up test
>> environments, running tests, bringing the results back to PR.
>> 
>> Maybe, we could follow a middle ground like this.
>> We as a community can authorize few more people to merge PRs in addition to
>> RMs.
>> 
>> How do we select these additional volunteers?
>> Any committer can just come forward and declare(in a mail to dev@) that he
>> read the release principles[1] and would like to volunteer to commit.
>> 
>> [1]
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/
>> Release+principles+for+Apache+CloudStack+4.6+and+up
>> 
>> ~Rajani
>&

Re: 4.10.0 release

[John Burwell]

Will,

My understanding of the release principles is that all changes must have a PR 
with the exception of CVE fixes.  Since we must accept CVE fixes in private, 
the 2 LGTM rule is applied on the security@ mailing list and on private JIRA 
security ticket.  I would also say that the release commits (e.g. tags, change 
of Maven versions in the POMs, etc) could also be granted an exception to the 
rule.  Otherwise, yes, my understanding is that everything else requires a PR.  
Do you agree with that interpretation?

Thanks,
-John

P.S. I plan to consolidate the release section of the wiki shortly as we have a 
number of topics that ostensibly conflict with each other.

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Aug 4, 2016, at 12:02 PM, Will Stevens  wrote:
> 
>> john.burw...@shapeblue.com

Re: 4.10.0 release

[John Burwell]

Will,

My point is that Rajani and I’s opinions on this topic (or any other) carry no 
more weight than any other committer.  We have volunteered to herd the cats to 
get releases out door.

What is CI?  Within our community, there are many different definitions.  I go 
with the industry definition — a central system of truth that builds and tests 
every commit.  While I would love to have such a system, it does not currently 
exist across the community (accepting that Travis CI partially implements the 
concept).  Our agreed upon principles do not mention CI.  They only require a 2 
LGTMs (at least one for code and at least one for test).  If we want to change 
it, we need to ensure we have consensus on both the terms and any changes to 
guidelines.

In terms of the two commits mentioned, I will look into them and determine 
whether or not I have any issues.  However, if you (or anyone) has an issue 
with a commit, there is no need to bottleneck around the RMs.  Open a 
discussion on dev@ to clarify/resolve any issues/concerns.  In the unlikely 
event that the we cannot find consensus on issues/concerns, then rollback the 
commit.  

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Aug 4, 2016, at 11:11 AM, Will Stevens <wstev...@cloudops.com> wrote:
> 
> I am not saying that we should not let other people commit.  I am saying
> that we need to be clear about the process we expect them to follow.  John,
> yes, we have the principles that you linked, but are we enforcing them?
> 
> For example, these two commits were made directly to master without any
> associated PR.
> - 546a3f8884398391760b76ddcf02e6bc1f30d642
> - fd7273b446738c0ebfae84189502dbdcd18bfd42
> 
> I know they are required and they should be non-destructive, but they did
> not follow our principles and go through CI, so do we really know.  Is that
> ok?
> 
> This is my point.  If we let anyone commit (which is their right as you
> correctly point out), we need to start enforcing our commit principles.  I
> think it is important to have clarity on this point ASAP so everyone is
> comfortable with these details.
> 
> Cheers,
> 
> *Will STEVENS*
> Lead Developer
> 
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
> 
> On Thu, Aug 4, 2016 at 10:58 AM, John Burwell <john.burw...@shapeblue.com>
> wrote:
> 
>> Rajani and Will,
>> 
>> It is actually not up to the release managers to make such a
>> determination.  Our bylaws state that anyone with a commit bit can commit
>> (or, if necessary, rollback a commit).  By granting someone a commit bit,
>> we have imparted a trust that an individual will protect the integrity of
>> the codebase and work in the best interest of the community.  If someone
>> makes a mistake (which has happened), we can easily rollback a commit.  We
>> have even decided to rollback commits after getting 2 LGTMs on a PR.  Under
>> the Apache Way, committers are encouraged to propel a project forward.
>> Restricting merges to RMs not only restricts velocity and it also limits
>> the energy/contributions of our large committer base.
>> 
>> In terms of the rules below, we have, by consensus, accepted a set of
>> release principles [1] that specify how PRs should be reviewed and accepted
>> for merge to master.   If the guidelines outlined in that document are not
>> followed, we have accepted that another committer may rollback a commit.
>> Rajani and I will be watching the release branches.  If we find commits
>> that do not conform to our accepted merge rules, we will roll them back and
>> work with the committer to fix the issues.
>> 
>> Thanks,
>> -John
>> 
>> [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/
>> Release+principles+for+Apache+CloudStack+4.6+and+up
>> 
>>> 
>> john.burw...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
>> @shapeblue
>> 
>> 
>> 
>> On Aug 4, 2016, at 10:17 AM, Will Stevens <wstev...@cloudops.com> wrote:
>>> 
>>> I will let the RMs for this release weigh in on this, but here are my
>>> thoughts.
>>> 
>>> If we let anyone commit, I think the following rules MUST be followed:
>>> - No commits directly to the repo, which are not a merge of a GitHub Pull
>>> Request.  So every change to the repo should be through `git pr `
>> using
>>> this tool [1].  This ensures everything that gets committed goes through
>>> our CI pipeline and is verified before commit. 

Re: 4.10.0 release

[John Burwell]

Rajani and Will,

It is actually not up to the release managers to make such a determination.  
Our bylaws state that anyone with a commit bit can commit (or, if necessary, 
rollback a commit).  By granting someone a commit bit, we have imparted a trust 
that an individual will protect the integrity of the codebase and work in the 
best interest of the community.  If someone makes a mistake (which has 
happened), we can easily rollback a commit.  We have even decided to rollback 
commits after getting 2 LGTMs on a PR.  Under the Apache Way, committers are 
encouraged to propel a project forward.  Restricting merges to RMs not only 
restricts velocity and it also limits the energy/contributions of our large 
committer base.

In terms of the rules below, we have, by consensus, accepted a set of release 
principles [1] that specify how PRs should be reviewed and accepted for merge 
to master.   If the guidelines outlined in that document are not followed, we 
have accepted that another committer may rollback a commit.  Rajani and I will 
be watching the release branches.  If we find commits that do not conform to 
our accepted merge rules, we will roll them back and work with the committer to 
fix the issues.

Thanks,
-John

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

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Aug 4, 2016, at 10:17 AM, Will Stevens <wstev...@cloudops.com> wrote:
> 
> I will let the RMs for this release weigh in on this, but here are my
> thoughts.
> 
> If we let anyone commit, I think the following rules MUST be followed:
> - No commits directly to the repo, which are not a merge of a GitHub Pull
> Request.  So every change to the repo should be through `git pr ` using
> this tool [1].  This ensures everything that gets committed goes through
> our CI pipeline and is verified before commit.  It also makes it easier for
> us to be able to script the generation of release notes and correlate the
> commit history with other sources (GitHub, Jira, etc).  I will submit a PR
> with tools for generating release notes based on merged GitHub PRs soon...
> - Every PR merged into a previous branch must be forward merged to later
> branches.  This is done using this tool [2] in order to make sure the
> commit hashes are consistent across all branches.  This is for auditability
> and comparing what exists in one branch vs another.
> 
> [1] https://github.com/apache/cloudstack/blob/master/tools/git/git-pr
> [2] https://github.com/apache/cloudstack/blob/master/tools/git/git-fwd-merge
> 
> This is my two cents anyway...
> 
> *Will STEVENS*
> Lead Developer
> 
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
> 
> On Thu, Aug 4, 2016 at 3:43 AM, Rohit Yadav <rohit.ya...@shapeblue.com>
> wrote:
> 
>> I disagree with having only RMs to merge PRs when we're not in freeze. In
>> general we've implicitly honoured this behaviour but it was never voted.
>> Our RMs may not be as active as we want them to be, while they are
>> historically good at writing policies but it's hard to put them in practice
>> and further it's understandable that they may not be able to volunteer
>> enough time and effort to get the PRs sorted.
>> 
>> 
>> Over past months this and similar practices have killed our commit and
>> development momentum, and I think it's not a healthy practice for our
>> community to engage in further. Instead, we can have committers (and in
>> future maybe bots) to merge a PR if they have 2 LGTMs, no objections and
>> test results from both Travis (simulator) and Bubble/BVT/Trillian (tests
>> against at least one and ideally all three hypervisors - KVM, Xen and
>> VMware).
>> 
>> 
>> Regards.
>> 
>> 
>> From: Rajani Karuturi <raj...@apache.org>
>> Sent: 03 August 2016 13:43:54
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.10.0 release
>> 
>> ouch.. looks like my email client stripped all the new lines.
>> Re-sending from webmail
>> 
>> Hi All,
>> These are the proposed dates for 4.10 release (copied from another thread
>> by John Burwell)
>> * Development (master open to features and defect fixes): 1 August 2016 -
>> 11 September 2016
>> * Testing: 12 - 18 September 2016
>> * RC Voting: 19 - 25 September 2016
>> * Release: 26 September 2016
>> 
>> master is open for 4.10.0.
>> It still means that only PRs will be merged and they will be merged only by
>> RMs ( For 4.10.0, its John Burwell a

Re: [PROPOSAL] Early LTS Initial Release

[John Burwell]

Rajani,

As I mentioned in my previous email, the original motivation for a completely 
separate branch was based on objections by some community members that the 
longer, more conservative LTS release cycle would place a drag on the velocity 
of regular releases.  Additionally, users interested in LTS releases voiced 
their desire to have fewer releases a year.  Therefore, where the regular 
release cycle is scheduled to make major releases every 2 months and 
maintenance releases every month, the LTS cycle makes major releases every 6 
months and maintenance releases less frequently (e.g. every 3 months).  These 
longer cycles allow users with longer acceptance test/verification cycles to 
more easily keep up with upgrades.  Completely separate branches and release 
cycles were proposed to serve both use cases (rapid, leading upgrades and more 
traditional maintenance cycles).  

I am open to collapsing LTS into the regular maintenance releases (e.g. 4.9 
simply becomes supported for 20 months instead of 4 months).  Ultimately, I 
would like that decision to be based on user feedback since separate release 
branches/cycles have been previously discussed with no objections [1].  I have 
CC’ed users@ to solicit thoughts from our users on which approach would be 
preferred.

Thanks,
-John

[1]: http://markmail.org/thread/zh43rc6ahs4te46l  

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Aug 2, 2016, at 3:57 AM, Rajani Karuturi <raj...@apache.org> wrote:
> 
> We already maintain the release branches and do regular
> releases(of the past two releases) on them. What are we achieving
> through this LTS model? How is 4.9.1 different from 4.9.0.0_1.0?
> 
> ~ Rajanihttp://cloudplatform.accelerite.com/
> On August 2, 2016 at 2:33 AM, John Burwell
> (john.burw...@shapeblue.com) wrote:Wido,
> 
> As proposed, LTS will be a branch of 4.9.0 with a six (6) week
> period of additional testing (i.e. soak/endurance, scalability,
> and more extensive plugin testing). Therefore, LTS releases will
> be named _ meaning that the first LTS
> release would be 4.9.0.0_1.0. The original motivation for this
> approach was that the regular release cycle performed testing for
> a week which was not enough time to execute long running tests
> (e.g. the entire test suite requires roughly 4 days to run, a
> good endurance/soak test should run for 5-7 days,
> etc). Additionally, there was concern that LTS would impede the
> velocity of the regular release cycle. By decoupling the
> regular and LTS release branches, there would be no opportunity
> for LTS constraints to impede velocity of the regular release
> cycle.
> 
> Since my original proposal, a number of aspects about the release
> cycle have changed. I am open to adjust LTS to simply be an
> extension of the support period on the 4.9.0.0
> release. Personally, I think the risk of the LTS cycle impeding
> regular releases is very low. I also think it would be more
> consistent with the way we have managed long running releases in
> the past. We would still perform the additional test we planned
> for LTS, but it would on the 4.9 release branch rather than a
> separate LTS branch.
> 
> Are there any objections to this change to the way LTS branches
> are managed and releases named? For now, I will leave the LTS
> releases in the schedule as defined in the original
> proposal. If/when we gain consensus on this change, I will
> adjust the schedule.
> 
> Thanks,
> -John
> From: Wido den Hollander
> <w...@widodh.nl ( w...@widodh.nl )>Sent: Friday, July 15, 2016
> 4:15:36 AMTo: dev@cloudstack.apache.org (
> dev@cloudstack.apache.org ); John BurwellSubject: Re: [PROPOSAL]
> Early LTS Initial Release
> Op 13 juli 2016 om 18:25 schreef John Burwell
> <john.burw...@shapeblue.com ( john.burw...@shapeblue.com )>:
> 
> All,
> Since LTS introduces a new release stream, I would like to
> propose that we cut the first LTS quickly to verify that various
> aspects of the release cycle and version number dependent
> components will work properly with the new release naming
> scheme. It will also allow us to flesh out distribution issues
> such as download locations (e.g. for system VMs) and publishing
> LTS documentation alongside regular releases. My thinking is
> that we would push an RC for this release within a week of the
> 4.9.0.0 release. If this additional release is acceptable, I
> will update the release calendar to reflect the following
> changes:
> * LTS 4.9.0.0_1.0* Development/Testing: 1 week after 4.9.0.0
> release* RC Voting: 2 weeks after 4.9.0.0 release* LTS
> 4.9.0.0_2.0* Development/Testing: From 3 to 9 weeks of the
> 4.9.0.0 release* RC Voting: 10t

Next Releases

[John Burwell]

All,

First, thank you to Will for taking on 4.9 and getting it out the door.  I have 
updated the proposed release schedule [1] to reflect the release of 4.9.0 on 1 
August 2016.  Please review the release schedule.  If you have questions or 
issues, please let me know.  I hope we can come to a consensus by the end of 
this week (5 August 2016), and remove the [PROPOSED] from the title.  Once we 
have consensus, I will consolidate the release section of wiki to ensure that 
the process and schedule are clear.

Effective today (1 August 2017), master is open to accept commits for the 
4.10.0.0 release.  For ease of reference, the proposed dates for the 4.10.0 
release are as follows:

* Development (master open to features and defect fixes): 1 August 2016 - 11 
September 2016
* Testing: 12 - 18 September 2016
* RC Voting: 19 - 25 September 2016
* Release: 26 September 2016

In addition, development of the first 4.9 and next 4.8 maintenance releases, 
4.9.1.0 and 4.8.2.0, has also started with the following proposed dates:

* Development (defect fixes only): 1 - 14 August 2016
* Testing: 15 - 21 August 2016
* RC Voting: 16 - 28 August 2016
* Release: 29 August 2016

Please submit defect fixes against the earliest supported branch in which the 
defect occurs.  We will forward merge the fix to newer supported branches.

Finally, development of our first LTS release will start shortly.  We are 
discussing a potential change to the management of LTS.  Hopefully, we will 
resolve this question shortly, and open development on that release as well.

In terms of PR review, I plan to begin reviewing PRs from oldest to newest.  My 
thinking is that the older a PR, the greater the divergence.  Therefore, 
addressing the oldest PRs first decreases the likelihood that we lose 
contributions to bit rot.

Thanks,
-John


[1]: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/%5BPROPOSAL%5D+2016-2017+Release+Cycle+and+Calendar

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

Re: [PROPOSAL] Early LTS Initial Release

[John Burwell]

Wido,


As proposed, LTS will be a branch of 4.9.0 with a six (6) week period of 
additional testing (i.e. soak/endurance, scalability, and more extensive plugin 
testing). Therefore, LTS releases will be named _ 
meaning that the first LTS release would be 4.9.0.0_1.0.  The original 
motivation for this approach was that the regular release cycle performed 
testing for a week which was not enough time to execute long running tests 
(e.g. the entire test suite requires roughly 4 days to run, a good 
endurance/soak test should run for 5-7 days, etc).  Additionally, there was 
concern that LTS would impede the velocity of the regular release cycle.   By 
decoupling the regular and LTS release branches, there would be no opportunity 
for LTS constraints to impede velocity of the regular release cycle.


Since my original proposal, a number of aspects about the release cycle have 
changed.  I am open to adjust LTS to simply be an extension of the support 
period on the 4.9.0.0 release.  Personally, I think the risk of the LTS cycle 
impeding regular releases is very low.  I also think it would be more 
consistent with the way we have managed long running releases in the past.  We 
would still perform the additional test we planned for LTS, but it would on the 
4.9 release branch rather than a separate LTS branch.


Are there any objections to this change to the way LTS branches are managed and 
releases named?  For now, I will leave the LTS releases in the schedule as 
defined in the original proposal.  If/when we gain consensus on this change, I 
will adjust the schedule.


Thanks,

-John


From: Wido den Hollander <w...@widodh.nl>
Sent: Friday, July 15, 2016 4:15:36 AM
To: dev@cloudstack.apache.org; John Burwell
Subject: Re: [PROPOSAL] Early LTS Initial Release


> Op 13 juli 2016 om 18:25 schreef John Burwell <john.burw...@shapeblue.com>:
>
>
> All,
>
> Since LTS introduces a new release stream, I would like to propose that we 
> cut the first LTS quickly to verify that various aspects of the release cycle 
> and version number dependent components will work properly with the new 
> release naming scheme.  It will also allow us to flesh out distribution 
> issues such as download locations (e.g. for system VMs) and publishing LTS 
> documentation alongside regular releases.  My thinking is that we would push 
> an RC for this release within a week of the 4.9.0.0 release.  If this 
> additional release is acceptable, I will update the release calendar to 
> reflect the following changes:
>
> * LTS 4.9.0.0_1.0
>* Development/Testing: 1 week after 4.9.0.0 release
>* RC Voting: 2 weeks after 4.9.0.0 release
> * LTS 4.9.0.0_2.0
>* Development/Testing: From 3 to 9 weeks of the 4.9.0.0 release
>* RC Voting: 10th week after the 4.9.0 release
>

I am fine with 4.9.0 as a LTS.

But why a new vote for 4.9.0.0 as a LTS? Isn't that a bit redundant?

When we say 4.9.0 is good, what doesn't make it good for a LTS?

Wido

> I apologize for the relative dates — we are still waiting for 4.9.0.0 to 
> complete voting.
>
> Thanks,
> -John
> john.burw...@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
>
>
>

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

Re: [VOTE] Apache Cloudstack 4.9.0 RC2

[John Burwell]

All,

I vote +1 (binding).  We have tested 4.9.0 RC2 in the following environments:

• CentOS 6.8 management server + CentOS 6.8 KVM Hosts using NFS primary 
and secondary storage (would allow us to verify/fix the documented libvirt/qemu 
versions)
• CentOS 6.8 management server + vCenter 5.5u3d + ESXi 5.5u3b using NFS 
primary and secondary storage
• CentOS 6.8 management server + vCenter 6.0u2 + ESXi Express Patch 6 
using NFS primary and secondary storage
• CentOS 6.8 management server + XenServer 6.2 SP1 using NFS primary 
and secondary storage
• CentOS 6.8 management server + XenServer 6.5 SP1 using NFS primary 
and secondary storage

For each environment, we have run the following tests:

• All smoke tests
• test_accounts.py
• test_acl_*.py
• test_sharednetwork*.py
• test_add_remove_network.py
• test_advancedsg_networks.py
• test_affinity_groups*.py
• test_cpu_domain_limits.py
• test_cpu_limits.py
• test_cpu_max_limits.py
• test_host_maintenance.py
• test_memory_limits.py
• test_network_offering.py
• test_overcommit.py
• test_persistent_networks.py
• test_ps_domain_limits.py
• test_ps_limits.py
• test_ps_max_limits.py
• test_ps_resize_volume.py
• test_ps_resource_limits_volume.py
• test_resource_limits.py
• test_routers.py
• test_security_groups.py
• test_shared_networks.py
• test_snapshots.py
• test_ss_domain_limits.py
• test_ss_limits.py
• test_ss_max_limits.py
• test_templates.py
• test_update_vm.py
• test_volumes.py
• test_vpc.py

During our tests, we found the following issues, but do not see any of them as 
blockers:

• As Paul and Boris noted, the 
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL in test_vpc_redundant.py 
fails.  We are uncertain as to whether this failure is caused by a defect, a 
problem with the test case, or our test environment.
• We have seen NPEs in the log every 10 minutes attempting to garbage 
collect a non-existent XenServer volume previously attached to a VR.  While 
ugly, it is not leaving unused volumes to consume disk space.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Jul 28, 2016, at 12:55 PM, Paul Angus  wrote:
> 
> I'm getting a pass on KVM for 
> /marvin/test/integration/smoke/test_vpc_redundant.py
> And a FAIL on VMware for the same test, with the same error.
> 
> 2016-07-28 04:00:52,133 - CRITICAL - FAILED: 
> test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL: ['Traceback (most 
> recent call last):\n', '  File "/usr/lib64/python2.7/unittest/case.py", line 
> 369, in run\ntestMethod()\n', '  File 
> "/marvin/test/integration/smoke/test_vpc_redundant.py", line 537, in 
> test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL\n
> self.check_routers_state(1)\n', '  File 
> "/marvin/test/integration/smoke/test_vpc_redundant.py", line 304, in 
> check_routers_state\nself.query_routers(count, showall)\n', '  File 
> "/marvin/test/integration/smoke/test_vpc_redundant.py", line 297, in 
> query_routers\n"Check that %s routers were indeed created" % count)\n', ' 
>  File "/usr/lib64/python2.7/unittest/case.py", line 553, in assertEqual\n
> assertion_func(first, second, msg=msg)\n', '  File 
> "/usr/lib64/python2.7/unittest/case.py", line 546, in _baseAssertEqual\n
> raise self.failureException(msg)\n', 'AssertionError: Check that 1 routers 
> were indeed created\n']
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 
> 
> -Original Message-
> From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of 
> Will Stevens
> Sent: 28 July 2016 17:24
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Apache Cloudstack 4.9.0 RC2
> 
> The teardown issue looks to be environmental.  Apparently the network did not 
> get cleaned up before the network service offering using it was attempted to 
> be deleted.
> 
> I am not sure about the test_vpc_redundent test failure.  I run that test all 
> the time on KVM and have not been getting that problem.  Do you get the same 
> thing if you run it again in your environment?
> 
> *Will STEVENS*
> Lead Developer
> 
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw 
> @CloudOps_
> 
> On Thu, Jul 28, 2016 at 12:00 PM, Boris Stoyanov < 
> boris.stoya...@shapeblue.com> wrote:
> 
>> Hi we’ve run: test_vpc_redundant and got :
>> 
>> 2016-07-28 16:36:29,959 - CRITICAL - FAILED: test_05_rvpc_multi_tiers:
>> ['Traceback (most recent call last):\n', '  File 
>> 

4.9.0 RC2 Status

[John Burwell]

Will,

I am inquiring as to the status of 4.9.0 RC2.  Are there issues we can help 
resolve in order to get it out?  If not, do you have an ETA on when it will be 
cut?  

Thanks,
-John
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

[PROPOSAL] Early LTS Initial Release

[John Burwell]

All,

Since LTS introduces a new release stream, I would like to propose that we cut 
the first LTS quickly to verify that various aspects of the release cycle and 
version number dependent components will work properly with the new release 
naming scheme.  It will also allow us to flesh out distribution issues such as 
download locations (e.g. for system VMs) and publishing LTS documentation 
alongside regular releases.  My thinking is that we would push an RC for this 
release within a week of the 4.9.0.0 release.  If this additional release is 
acceptable, I will update the release calendar to reflect the following changes:

* LTS 4.9.0.0_1.0
* Development/Testing: 1 week after 4.9.0.0 release
* RC Voting: 2 weeks after 4.9.0.0 release
* LTS 4.9.0.0_2.0 
* Development/Testing: From 3 to 9 weeks of the 4.9.0.0 release
* RC Voting: 10th week after the 4.9.0 release

I apologize for the relative dates — we are still waiting for 4.9.0.0 to 
complete voting.

Thanks,
-John
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

Re: [VOTE] Apache Cloudstack 4.9.0 RC1

[John Burwell]

Paul,

Is this condition a regression in previous behavior?

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Jul 10, 2016, at 8:06 AM, Paul Angus  wrote:
> 
> Guys,
> 
> Is it not possible to add the additional entries into db.properties when 
> CloudStack is upgrading rather than manually? If it is possible, then 
> manually intervention is a -1 in my book.
> Sure it's not a big fix required - but it's still required for CloudStack to 
> work in a slick manner.  We're trying to improve the user experience.
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 
> 
> -Original Message-
> From: Milamber [mailto:milam...@apache.org] 
> Sent: 10 July 2016 12:06
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Apache Cloudstack 4.9.0 RC1
> 
> Hello,
> 
> My vote +1 (binding)
> 
> 
> Tests are passed on a virtual topology of servers  (CS over CS)
> (1mgr+2nodes+1nfs) :
> 
> 1/ Fresh install of 4.9.0RC1 (adv net) on Ubuntu 14.04.4 + KVM + NFS : OK 
> Some standard tests with success (create vm, migration, HA, create networks, 
> create user, create ssh key, destroy vm, register template, create snapshot, 
> restore snapshot, create template, ip association, ip release, static nat, 
> firewall rule) Some tests with cloudstack ansible module with sucess too 
> (create network, register templates, create vm, ip, firewall rule)
> 
> 2/ Test upgrade from 4.7.1 to 4.9.0RC1 : OK with the same remarks than Wido 
> (need to add JDBC driver type in db.properties)
> 
> 3/ Tests of all localizations of Web UI of 4.9RC1 : Localization works well 
> except Spanish: the Web UI won't display due of 2 localization strings with a 
> escaped quote (from Transifex)
> 'label.number.of.system.vms': 'Número de VM\\'s del Systema',
> 'label.vm.state': 'Estado de VM\\'s',
> Fixed in the PR1583
> https://github.com/apache/cloudstack/pull/1583
> 
> 
> Perhaps add in the Release notes this 2 issues (jdbc type & spanish l10n)
> 
> Thanks to the RM.
> 
> Milamber
> 
> 
> 
> On 06/07/2016 20:52, Will Stevens wrote:
>> Hi All,
>> 
>> I've created a 4.9.0 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.9.0-RC20160706T1546
>> Commit: 643f75aa9150156b1fb05f339a338614fc7ad3fb
>> 
>> I will be updating the Release Notes with the changes in this release 
>> tomorrow.  If the RC changes, I can adapt the release notes after.
>> 
>> Source release (checksums and signatures are available at the same
>> location):
>> https://dist.apache.org/repos/dist/dev/cloudstack/4.9.0/
>> 
>> PGP release keys (signed using CB818F64):
>> 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)
>> 
>> Thanks,
>> 
>> Will
>> 
> 

Re: [PROPOSAL] 2016-2017 Release Cycle and Calendar

[John Burwell]

Wido,

I don’t think that Rohit is advocating expanding the 4.9.0 scope.  Instead, he 
is saying that proceeding with LTS on 4.8.0.1 would be counterproductive.  
4.8.0 was released in January meaning that 4.9 will contain nearly 6 months of 
defect fixes and enhancements.  Had we cut LTS last Friday, we would have faced 
the choice of attempting to backport all of the defect changes from master to 
LTS or simply not including them.  Therefore, I think we all agree that we 
should release 4.9.0.0 as soon as possible.  My hope is that we can complete 
testing and RC voting by 15 July 2016 in order to cut LTS and move forward with 
the development of 4.10.0.0.  Am I correct in my understanding Rohit and your 
thoughts regarding 4.9?

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Jul 5, 2016, at 5:25 AM, Wido den Hollander <w...@widodh.nl> wrote:
> 
>> 
>> Op 4 juli 2016 om 18:17 schreef Rohit Yadav <rohit.ya...@shapeblue.com>:
>> 
>> 
>> I think 4.9 brings some new features, enhancements and improvements that 
>> people would appreciate in a LTS release. Many of them cannot be simply 
>> backported and 2 weeks will be far shorter to identify, backport and 
>> regression-test all those changes.
>> 
> 
> But that way we keep finding reasons to delay 4.9 and make that the LTS. 4.10 
> afterwards will have other cool features, etc. That will stay.
> 
>> 
>> From my personal experience, I've done a lot of backporting in 4.3, then did 
>> maintenance work in 4.5. I think it's still worth it to wait for few weeks 
>> to get 4.9.0 out of the door and have LTS based on 4.9.0 release.
>> 
>> 
>> If Will is not able to find time to work on 4.9 release, maybe someone else 
>> can takeover and help with the 4.9 release by 15th July (at least get some 
>> RCs up for testing and voting)? LTS can be 4.9.1 etc.
>> 
>> 
>> Regards.
>> 
>> 
>> From: Wido den Hollander <w...@widodh.nl>
>> Sent: 04 July 2016 15:32:45
>> To: dev@cloudstack.apache.org; John Burwell
>> Subject: Re: [PROPOSAL] 2016-2017 Release Cycle and Calendar
>> 
>> 
>>> Op 4 juli 2016 om 6:57 schreef John Burwell <john.burw...@shapeblue.com>:
>>> 
>>> 
>>> All,
>>> 
>>> Following up on a our discussions about LTS [1], post 4.9 releases [2], and 
>>> 5.0.0/6.0.0 [3], I have assembled a release plan for the next 18-20 months 
>>> in the wiki [4].  My original proposal assumed by that 4.9 would be 
>>> released by 1 July.  I have adjusted the timelines assuming that we will 
>>> complete the release by 15 July.  My thinking is that the number of defect 
>>> fixes present in 4.9 and 4.8.1 would require more than 2 weeks of work to 
>>> backport to a 4.8-based LTS.  Therefore, I have shifted the LTS cutoff 
>>> dates from 1 Jan and 1 July to 15 Jan and 15 July.
>>> 
>>> Once we gain consensus on the release cycle and calendar, I will cleanup 
>>> the wiki to move completed release plans to an archive area and remove 
>>> obsolete release process documentation.
>>> 
>> 
>> Looks good to me. It's time that 4.9 is released and shifting to July 15th 
>> looks good.
>> 
>> Overall your release schedule proposal looks good to me, so I'd say +1 on 
>> the proposal.
>> 
>> Wido
>> 
>>> Thanks,
>>> -John
>>> 
>>> [1]: http://markmail.org/thread/zzrjldiryhy3ygfk
>>> [2]: http://markmail.org/thread/7rv3jwz4hzf3yplf
>>> [3]: http://markmail.org/thread/c24hvshz3z4babjb
>>> [4]: 
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/%5BPROPOSAL%5D+2016-2017+Release+Cycle+and+Calendar<https://cwiki.apache.org/confluence/display/CLOUDSTACK/[PROPOSAL]+2016-2017+Release+Cycle+and+Calendar>
>>> 
>>> john.burw...@shapeblue.com
>>> www.shapeblue.com<http://www.shapeblue.com>
>>> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
>>> @shapeblue
>>> 
>>> 
>>> 
>> 
>> rohit.ya...@shapeblue.com 
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue

[PROPOSAL] 2016-2017 Release Cycle and Calendar

[John Burwell]

All,

Following up on a our discussions about LTS [1], post 4.9 releases [2], and 
5.0.0/6.0.0 [3], I have assembled a release plan for the next 18-20 months in 
the wiki [4].  My original proposal assumed by that 4.9 would be released by 1 
July.  I have adjusted the timelines assuming that we will complete the release 
by 15 July.  My thinking is that the number of defect fixes present in 4.9 and 
4.8.1 would require more than 2 weeks of work to backport to a 4.8-based LTS.  
Therefore, I have shifted the LTS cutoff dates from 1 Jan and 1 July to 15 Jan 
and 15 July.

Once we gain consensus on the release cycle and calendar, I will cleanup the 
wiki to move completed release plans to an archive area and remove obsolete 
release process documentation.

Thanks,
-John

[1]: http://markmail.org/thread/zzrjldiryhy3ygfk
[2]: http://markmail.org/thread/7rv3jwz4hzf3yplf
[3]: http://markmail.org/thread/c24hvshz3z4babjb
[4]: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/%5BPROPOSAL%5D+2016-2017+Release+Cycle+and+Calendar

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

Re: 4.9/master Testing Coordination

[John Burwell]

All,

I had hoped to get testing off the ground earlier, but $dayjob duties have 
gotten in the way.  Over the weekend, I am planning to kick off tests of the 
following configurations:

• CentOS 6.8 management server + CentOS 6.8 KVM Hosts using NFS primary 
and secondary storage (would allow us to verify/fix the documented libvirt/qemu 
versions)
• CentOS 6.8 management server + vCenter 5.5u3d + ESXi 5.5u3b using NFS 
primary and secondary storage
• CentOS 6.8 management server + vCenter 6.0u2 + ESXi Express Patch 6 
using NFS primary and secondary storage
• CentOS 6.8 management server + XenServer 6.2 SP1 using NFS primary 
and secondary storage
• CentOS 6.8 management server + XenServer 6.5 SP1 using NFS primary 
and secondary storage

In each of these environments, I plan to run the following tests:

• All smoke tests
• Component Tests
• test_accounts.py
• test_acl_*.py
• test_sharednetwork*.py
• test_add_remove_network.py
• test_advancedsg_networks.py
• test_affinity_groups*.py
• test_cpu_domain_limits.py
• test_cpu_limits.py
• test_cpu_max_limits.py
• test_host_maintenance.py
• test_memory_limits.py
• test_network_offering.py
• test_overcommit.py
• test_persistent_networks.py
• test_ps_domain_limits.py
• test_ps_limits.py
• test_ps_max_limits.py
• test_ps_resize_volume.py
• test_ps_resource_limits_volume.py
• test_resource_limits.py
• test_routers.py
• test_security_groups.py
• test_shared_networks.py
• test_snapshots.py
• test_ss_domain_limits.py
• test_ss_limits.py
• test_ss_max_limits.py
• test_templates.py
• test_update_vm.py
• test_volumes.py
• test_vpc.py

I will start this set, and may adjust based on success rates and runtime.

I hope to post results by COB, Monday (27 June 2016).

Thanks,
-John


> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Jun 20, 2016, at 4:31 PM, John Burwell <john.burw...@shapeblue.com> wrote:
> 
> All,
> 
> I am working to coordinate some testing at ShapeBlue.  I send an update as 
> soon as I have the list of environment and tests we plan to run.
> 
> Thanks,
> -John
> 
>> 
> john.burw...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
> 
> 
> 
> On Jun 20, 2016, at 8:27 AM, Simon Weller <swel...@ena.com> wrote:
>> 
>> 
>> Remi,
>> 
>> 
>> The KVM VXLAN feature uses the standard BridgeVifDriver, as OVS doesn't 
>> support multicast.
>> 
>> 
>> To reproduce this:
>> 
>> 
>> Deploy 4.9 RPMS to Centos 7.2 installation, upgrading a 4.8 install.
>> 
>> Restart existing VPC router pair for a established VPC.
>> 
>> When VPC routers come back up, the guest tier (isolated) network is missing.
>> 
>> 
>> If you deploy a new VPC, the same problem occurs.
>> 
>> 
>> We have confirmed that the same problem exists on a non-redundant VPC router 
>> as well.
>> 
>> 
>> David is working on reproducing this in a bubble. We have reproduced this on 
>> 2 hardware labs thus far.
>> 
>> 
>> - Si
>> 
>> 
>> From: Remi Bergsma <rberg...@schubergphilis.com>
>> Sent: Saturday, June 18, 2016 2:58 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.9/master Testing Coordination
>> 
>> Hi Simon,
>> 
>> Do you have the exact stept to reproduce?
>> To me it sounds like the issue is in either the ovsVifDriver or the VXLAN 
>> stuff. Can you reproduce the scenario in the bubble (with its default 
>> vlan/bridgeVifDriver)?
>> 
>> If there is a clear scenario, I think we should write an integration test 
>> (even if that shows it’s broken).
>> 
>> Regards, Remi
>> 
>> 
>> On 17/06/16 22:47, "Simon Weller" <swel...@ena.com> wrote:
>> 
>>> Here's a quick run down on the configuration(s) we're testing:
>>> 
>>> 
>>> Centos 7.2
>>> 
>>> Advanced Zone with VXLAN on KVM
>>> 
>>> VPC functionality including Private GW, VPN, Static Routes, ACL Lists et al
>>> 
>>> Redundant VPC VRs
>>> 
>>

Re: 4.9/master Testing Coordination

[John Burwell]

t; smoke/test_loadbalance.py \
>>> smoke/test_internal_lb.py \
>>> smoke/test_ssvm.py \
>>> smoke/test_vpc_vpn.py \
>>> smoke/test_privategw_acl.py \
>>> smoke/test_network.py
>>> 
>>> echo "Running tests with required_hardware=false"
>>> nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
>>> tags=advanced,required_hardware=false \
>>> smoke/test_routers.py \
>>> smoke/test_network_acl.py \
>>> smoke/test_reset_vm_on_reboot.py \
>>> smoke/test_vm_life_cycle.py \
>>> smoke/test_service_offerings.py \
>>> smoke/test_network.py \
>>> component/test_vpc_offerings.py \
>>> component/test_vpc_routers.py
>>> 
>>> I need to do some more manual testing...
>>> 
>>> *Will STEVENS*
>>> Lead Developer
>>> 
>>> *CloudOps* *| *Cloud Solutions Experts
>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>> w cloudops.com *|* tw @CloudOps_
>>> 
>>> On Fri, Jun 17, 2016 at 3:45 PM, Tutkowski, Mike <
>>> mike.tutkow...@netapp.com> wrote:
>>> 
>>>> My testing has been performed using XenServer 6.5 and ESXi 5.5.
>>>> 
>>>> I executed all of the tests in test/integration/plugins/solidfire.
>>>> 
>>>> They all came back successful.
>>>> 
>>>> From: John Burwell <john.burw...@shapeblue.com>
>>>> Sent: Friday, June 17, 2016 12:56 PM
>>>> To: dev@cloudstack.apache.org
>>>> Subject: 4.9/master Testing Coordination
>>>> 
>>>> All,
>>>> 
>>>> It is a bit lo-fi, but if you are testing master in preparation for the
>>>> 4.9 RC, could you please share information about the configurations you
>>>> testing (e.g. hypervisors, storage backends, network configurations, etc)?
>>>> Any test results could also be helpful.  The hope is to reduce duplication
>>>> of effort and understand how much of the system has been covered.
>>>> 
>>>> Thanks,
>>>> -John
>>>> john.burw...@shapeblue.com
>>>> www.shapeblue.com<http://www.shapeblue.com>
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> Overview Apache CloudStack contains an authentication module providing 
> “single sign-on” functionality via the SAML data format. Under certain 
> conditions, a
> 
> 
> 
>> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
>> www.shapeblue.com<http://www.shapeblue.com>
>> Overview Apache CloudStack contains an authentication module providing 
>> "single sign-on" functionality via the SAML data format. Under certain 
>> conditions, a
>> 
>> 
>> 
>>>> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
>>>> @shapeblue

4.9/master Testing Coordination

[John Burwell]

All,

It is a bit lo-fi, but if you are testing master in preparation for the 4.9 RC, 
could you please share information about the configurations you testing (e.g. 
hypervisors, storage backends, network configurations, etc)?  Any test results 
could also be helpful.  The hope is to reduce duplication of effort and 
understand how much of the system has been covered.

Thanks,
-John
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue

Re: 4.9.0 Release Status

[John Burwell]

Will,

I will open a thread on dev@ for us to share the configurations we are testing.

Thanks,
-John


john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On Jun 17, 2016, at 2:51 PM, Will Stevens 
<wstev...@cloudops.com<mailto:wstev...@cloudops.com>> wrote:


I currently do not have a good mechanism for people to specify what they have 
tested. I am open to ideas if you have some.

On Jun 17, 2016 2:46 PM, "John Burwell" 
<john.burw...@shapeblue.com<mailto:john.burw...@shapeblue.com>> wrote:
Will,

Do you know which hypervisors, storage plugins, and networking configurations 
have been tested?  It would be nice to avoid a duplication of effort.

Thanks,
-John


john.burw...@shapeblue.com<mailto:john.burw...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com/>
@shapeblue



On Jun 17, 2016, at 2:34 PM, Will Stevens 
<wstev...@cloudops.com<mailto:wstev...@cloudops.com>> wrote:

ENA has been doing some testing and they think they have found an issue, so I 
am waiting on their feedback.

If the community can test master to make sure it is stable for their use case 
that would be appreciated.

Will STEVENS
Lead Developer

CloudOps | Cloud Solutions Experts
420 rue Guy | Montreal | Quebec | H3J 1S6
w cloudops.com<http://cloudops.com/> | tw @CloudOps_

On Fri, Jun 17, 2016 at 2:20 PM, John Burwell 
<john.burw...@shapeblue.com<mailto:john.burw...@shapeblue.com>> wrote:
Will,

Is there any assistance the community can provide with test execution?

Thanks,
-John


john.burw...@shapeblue.com<mailto:john.burw...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com/>
@shapeblue



On Jun 17, 2016, at 1:44 PM, Will Stevens 
<wstev...@cloudops.com<mailto:wstev...@cloudops.com>> wrote:

Testing is being done and I am waiting on results.

Will STEVENS
Lead Developer

CloudOps | Cloud Solutions Experts
420 rue Guy | Montreal | Quebec | H3J 1S6
w cloudops.com<http://cloudops.com/> | tw @CloudOps_

On Fri, Jun 17, 2016 at 1:19 PM, John Burwell 
<john.burw...@shapeblue.com<mailto:john.burw...@shapeblue.com>> wrote:
All,

What is the status of the 4.9.0 release?  Looking at the 4.9.0 JIRA [1], there 
are 23 open tickets.  Do these tickets represent the outstanding work before a 
RC can be cut?  If not, what other tasks remain?

Thanks,
-John

[1]: 
https://issues.apache.org/jira/browse/CLOUDSTACK-9417?jql=project%20%3D%20CLOUDSTACK%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20Reviewable)%20AND%20fixVersion%20%3D%204.9.0<https://issues.apache.org/jira/browse/CLOUDSTACK-9417?jql=project%20=%20CLOUDSTACK%20AND%20status%20in%20(Open,%20%22In%20Progress%22,%20Reopened,%20Reviewable)%20AND%20fixVersion%20=%204.9.0>


john.burw...@shapeblue.com<mailto:john.burw...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com/>
@shapeblue

Re: 4.9.0 Release Status

[John Burwell]

Will,

Do you know which hypervisors, storage plugins, and networking configurations 
have been tested?  It would be nice to avoid a duplication of effort.

Thanks,
-John


john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On Jun 17, 2016, at 2:34 PM, Will Stevens 
<wstev...@cloudops.com<mailto:wstev...@cloudops.com>> wrote:

ENA has been doing some testing and they think they have found an issue, so I 
am waiting on their feedback.

If the community can test master to make sure it is stable for their use case 
that would be appreciated.

Will STEVENS
Lead Developer

CloudOps | Cloud Solutions Experts
420 rue Guy | Montreal | Quebec | H3J 1S6
w cloudops.com<http://cloudops.com/> | tw @CloudOps_

On Fri, Jun 17, 2016 at 2:20 PM, John Burwell 
<john.burw...@shapeblue.com<mailto:john.burw...@shapeblue.com>> wrote:
Will,

Is there any assistance the community can provide with test execution?

Thanks,
-John


john.burw...@shapeblue.com<mailto:john.burw...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com/>
@shapeblue



On Jun 17, 2016, at 1:44 PM, Will Stevens 
<wstev...@cloudops.com<mailto:wstev...@cloudops.com>> wrote:

Testing is being done and I am waiting on results.

Will STEVENS
Lead Developer

CloudOps | Cloud Solutions Experts
420 rue Guy | Montreal | Quebec | H3J 1S6
w cloudops.com<http://cloudops.com/> | tw @CloudOps_

On Fri, Jun 17, 2016 at 1:19 PM, John Burwell 
<john.burw...@shapeblue.com<mailto:john.burw...@shapeblue.com>> wrote:
All,

What is the status of the 4.9.0 release?  Looking at the 4.9.0 JIRA [1], there 
are 23 open tickets.  Do these tickets represent the outstanding work before a 
RC can be cut?  If not, what other tasks remain?

Thanks,
-John

[1]: 
https://issues.apache.org/jira/browse/CLOUDSTACK-9417?jql=project%20%3D%20CLOUDSTACK%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20Reviewable)%20AND%20fixVersion%20%3D%204.9.0<https://issues.apache.org/jira/browse/CLOUDSTACK-9417?jql=project%20=%20CLOUDSTACK%20AND%20status%20in%20(Open,%20%22In%20Progress%22,%20Reopened,%20Reviewable)%20AND%20fixVersion%20=%204.9.0>


john.burw...@shapeblue.com<mailto:john.burw...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com/>
@shapeblue

Re: 4.9.0 Release Status

[John Burwell]

Will,

Is there any assistance the community can provide with test execution?

Thanks,
-John


john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On Jun 17, 2016, at 1:44 PM, Will Stevens 
<wstev...@cloudops.com<mailto:wstev...@cloudops.com>> wrote:

Testing is being done and I am waiting on results.

Will STEVENS
Lead Developer

CloudOps | Cloud Solutions Experts
420 rue Guy | Montreal | Quebec | H3J 1S6
w cloudops.com<http://cloudops.com/> | tw @CloudOps_

On Fri, Jun 17, 2016 at 1:19 PM, John Burwell 
<john.burw...@shapeblue.com<mailto:john.burw...@shapeblue.com>> wrote:
All,

What is the status of the 4.9.0 release?  Looking at the 4.9.0 JIRA [1], there 
are 23 open tickets.  Do these tickets represent the outstanding work before a 
RC can be cut?  If not, what other tasks remain?

Thanks,
-John

[1]: 
https://issues.apache.org/jira/browse/CLOUDSTACK-9417?jql=project%20%3D%20CLOUDSTACK%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20Reviewable)%20AND%20fixVersion%20%3D%204.9.0<https://issues.apache.org/jira/browse/CLOUDSTACK-9417?jql=project%20=%20CLOUDSTACK%20AND%20status%20in%20(Open,%20%22In%20Progress%22,%20Reopened,%20Reviewable)%20AND%20fixVersion%20=%204.9.0>


john.burw...@shapeblue.com<mailto:john.burw...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com/>
@shapeblue

Re: apachecloudstack.net and apachecloudstack.org

[John Burwell]

All,

I like the idea of a new set of CNAMEs for these services, but I am -1 on the 
idea of these apachecloudstack.net CNAMEs.   Like cloudstack.org, I think that 
apachecloudstack.[org|net] should point to cloudstack.apache.org.  Instead, I 
suggest that we create them as part of the canonical namespace for the project 
— cloudstack.apache.org.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On Jun 9, 2016, at 9:45 AM, Erik Weber  wrote:
> 
> On Thu, Jun 9, 2016 at 3:40 PM, Wido den Hollander  wrote:
> 
>> 
>>> Op 9 juni 2016 om 15:21 schreef Pierre-Luc Dion :
>>> 
>>> 
>>> Hi,
>>> 
>>> From the #jenkins slack channel discussion this morning we kind a took a
>>> quick action on getting our hands on domain registration for
>>> apachecloudstack{.org,.net}
>>> 
>>> So, we also did some DNS updated until we have help from INFRA to use
>>> cloudstack.org  which to me make more sense.
>>> 
>>> So we added few dns entry:
>>> 
>>> builds.apachecloudstack.net   => new jenkins to replace
>>> jenkins.buildacloud.org
>>> download.apachecloudstack.net =>  cname to cloudstack.apt-get.eu
>>> artifacts.apachecloudstack.net=> nexus service for the new jenkins
>>> system
>>> 
>>> all apachecloudstack.org point to .net
>>> 
>> 
>> Great! download.apachecloudstack.net is already working I see :)
>> 
>> Now we just have to make sure that some organization will own these domain
>> names instead of a private individual, but that's something for later.
>> 
>> 
> 
> No idea if this is possible within ASF boundaries, but could the ASF own
> them, and provide the PMC access to the management of the zone(s)?
> 
> I believe ASF use Bind (or similar) with management in puppet, but if
> allowed there are cloud solutions that works well and have nice APIs
> (CloudFlare is one).
> 
> 
> -- 
> Erik

4.9.0 Release Status

[John Burwell]

All,

What is the status of the 4.9.0 release?  Looking at the 4.9.0 JIRA [1], there 
are 23 open tickets.  Do these tickets represent the outstanding work before a 
RC can be cut?  If not, what other tasks remain?

Thanks,
-John

[1]: 
https://issues.apache.org/jira/browse/CLOUDSTACK-9417?jql=project%20%3D%20CLOUDSTACK%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20Reviewable)%20AND%20fixVersion%20%3D%204.9.0


john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue

Re: Introduction

[John Burwell]

Welcome to the community, Sanket.

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On Jun 17, 2016, at 6:09 AM, Sanket Thite  wrote:
> 
> Hi All,
> 
> I would like to introduce myself to the community.
> 
> I am Sanket Thite and have recently joined the CloudPlatform team in 
> Accelerite. I have primarily worked on Java/J2EE related technologies and 
> frameworks such as Spring, Hibernate, Struts ,JSF, Web Services (Restful and 
> SOAP) in varied domains. I also have experience on UI related technologies 
> such as HTML, CSS, JavaScript, Ajax, Knockout JS.
> 
> I am keen to work on CloudStack  and make significant contribution to 
> CloudStack community.
> 
> Regards,
> Sanket Thite,
> CloudPlatform, sanket_th...@accelerite.com
> 
> 
> 
> 
> 
> DISCLAIMER
> ==
> This e-mail may contain privileged and confidential information which is the 
> property of Accelerite, a Persistent Systems business. It is intended only 
> for the use of the individual or entity to which it is addressed. If you are 
> not the intended recipient, you are not authorized to read, retain, copy, 
> print, distribute or use this message. If you have received this 
> communication in error, please notify the sender and delete all copies of 
> this message. Accelerite, a Persistent Systems business does not accept any 
> liability for virus infected mails.

Re: 4.9+ release

[John Burwell]

Marco,

As I said in the 5.0.0 thread, I believe that we need to look upon 
architectural improvement as a continuous process.  We have been stymied for 
years around an analysis paralysis that holds that we must address 
architectural issue in 5.0.0.  I believe that we need to start with remove a 
significant amount of technical debt and cruft in 5.0.0 which will lay the 
foundation for larger architectural improvements later in 2017.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On Jun 15, 2016, at 7:48 AM, ma...@exoscale.ch wrote:
> 
> Hi,
> 
> From my CS starter point of view, I agree with John's comment. I would really 
> like to see the next major version with a code & architecture clean-up, 
> especially producing a code architecture in the direction of the Java9 Jigsaw 
> modularity. It would be sad not to take the next specifications into account.
> For the dates, it's good to produce periodically a new release for the 4.X 
> but I don't see how putting one on the first 5.x version can be done before 
> defining what will be it.
> 
> Marco
> 
> -- To introduce myself, I joined Exoscale a few months ago to work on CS code 
> base to suit their needs.
> 
> 
>> On 15 Jun 2016, at 11:31, Rajani Karuturi <raj...@apache.org> wrote:
>> 
>> I like this discussion. But, my original question was not about what should
>> the next release number be?
>> 
>> i was checking if anyone working on anything big and hence want the next
>> release to be 5.0?
>> 
>> ~Rajani
>> 
>> <http://cloudplatform.accelerite.com/>
>> 
>> 
>> On Wed, Jun 15, 2016 at 12:29 PM, Daan Hoogland <daan.hoogl...@gmail.com>
>> wrote:
>> 
>>> maybe I should have answered here instead of the other thread :S
>>> 
>>> I am all with John on this. I can not judge the dates but the overall ideas
>>> are spot on.
>>> 
>>> I now see the API weren't mentioned in this thread I think they should.
>>> 
>>> On Wed, Jun 15, 2016 at 1:53 AM, ilya <ilya.mailing.li...@gmail.com>
>>> wrote:
>>> 
>>>> I agree and support John's comments below.
>>>> 
>>>> Regards
>>>> ilya
>>>> 
>>>> On 6/14/16 2:44 PM, John Burwell wrote:
>>>>> All,
>>>>> 
>>>>> Completely agree with Daan.  Per semantic versioning, a major revision
>>>> increase must introduce a backwards incompatible change in the public
>>> API,
>>>> removal of one of more supported devices, reduction in the list of
>>>> supported distributions.  I agree that when we require Java8+, drop
>>> Ubuntu
>>>> 12.04 support, drop support for an old hypervisor version, etc,  we will
>>>> need to increment the major revision to reflect the fact that the release
>>>> is not backwards compatible.
>>>>> 
>>>>> For 4.10 and LTS 4.9.0_1, I see it as critical that we support running
>>>> on either Java7 or Java8.  In particular, producing an LTS release that
>>>> only supports a JVM that has been unsupported for nearly 18 months would
>>>> make it DOA in many shops.
>>>>> 
>>>>> It seems like it would make sense to have a 5.0.0 release that removed
>>>> support for a number of legacy components (e.g. Xen 6.0 possibly 6.2,
>>>> Java7, CentOS 5, etc), as well as, internal improvements (e.g. simplified
>>>> configuration).  The focus of this release would be to reduce the
>>> footprint
>>>> of codebase, as well as, make a set of backwards incompatible changes
>>> that
>>>> further decouples plugins from core.  We would then plan for a 6.0.0 in
>>>> 4Q2017 to introduce further architectural changes and API revisions.  The
>>>> advantage to this approach is that it breaks up the large refactorings
>>> and
>>>> architectural design changes — allowing us to gain velocity by removing
>>>> legacy components, reducing the risk of these changes, and providing user
>>>> benefit earlier.  Based on the release plan I previously proposed we have
>>>> the following releases remaining in 2016 and in early 2017:
>>>>> 
>>>>> * 4.10 releasing on or about 28 August 2016
>>>>> * 4.11 releasing on or about 23 October 2016
>>>>> * 4.12 releasing on or about 18 December 2016
>>>>> * 4.13 release on or about 5 February 2017
>>>>> 
>>>

Re: 4.9+ release

[John Burwell]

Rajani,

By the rules of semantic versioning (which we follow), incrementing the major 
version should only occur if there there is a change that breaks backwards 
compatibility of the API, removes support for a integrated component, or 
otherwise reduces/removes existing functionality.  Assuming we targeting late 
August 2016 for the next release, it is a bit short notice to introduce such 
changes.  Therefore, the next release should be 4.10.

I have opened a discussion to determine if/when we should have a 5.0.0 release 
in order to provide developers and users with sufficient notice for such 
significant changes.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On Jun 15, 2016, at 5:31 AM, Rajani Karuturi <raj...@apache.org> wrote:
> 
> I like this discussion. But, my original question was not about what should
> the next release number be?
> 
> i was checking if anyone working on anything big and hence want the next
> release to be 5.0?
> 
> ~Rajani
> 
> <http://cloudplatform.accelerite.com/>
> 
> 
> On Wed, Jun 15, 2016 at 12:29 PM, Daan Hoogland <daan.hoogl...@gmail.com>
> wrote:
> 
>> maybe I should have answered here instead of the other thread :S
>> 
>> I am all with John on this. I can not judge the dates but the overall ideas
>> are spot on.
>> 
>> I now see the API weren't mentioned in this thread I think they should.
>> 
>> On Wed, Jun 15, 2016 at 1:53 AM, ilya <ilya.mailing.li...@gmail.com>
>> wrote:
>> 
>>> I agree and support John's comments below.
>>> 
>>> Regards
>>> ilya
>>> 
>>> On 6/14/16 2:44 PM, John Burwell wrote:
>>>> All,
>>>> 
>>>> Completely agree with Daan.  Per semantic versioning, a major revision
>>> increase must introduce a backwards incompatible change in the public
>> API,
>>> removal of one of more supported devices, reduction in the list of
>>> supported distributions.  I agree that when we require Java8+, drop
>> Ubuntu
>>> 12.04 support, drop support for an old hypervisor version, etc,  we will
>>> need to increment the major revision to reflect the fact that the release
>>> is not backwards compatible.
>>>> 
>>>> For 4.10 and LTS 4.9.0_1, I see it as critical that we support running
>>> on either Java7 or Java8.  In particular, producing an LTS release that
>>> only supports a JVM that has been unsupported for nearly 18 months would
>>> make it DOA in many shops.
>>>> 
>>>> It seems like it would make sense to have a 5.0.0 release that removed
>>> support for a number of legacy components (e.g. Xen 6.0 possibly 6.2,
>>> Java7, CentOS 5, etc), as well as, internal improvements (e.g. simplified
>>> configuration).  The focus of this release would be to reduce the
>> footprint
>>> of codebase, as well as, make a set of backwards incompatible changes
>> that
>>> further decouples plugins from core.  We would then plan for a 6.0.0 in
>>> 4Q2017 to introduce further architectural changes and API revisions.  The
>>> advantage to this approach is that it breaks up the large refactorings
>> and
>>> architectural design changes — allowing us to gain velocity by removing
>>> legacy components, reducing the risk of these changes, and providing user
>>> benefit earlier.  Based on the release plan I previously proposed we have
>>> the following releases remaining in 2016 and in early 2017:
>>>> 
>>>> * 4.10 releasing on or about 28 August 2016
>>>> * 4.11 releasing on or about 23 October 2016
>>>> * 4.12 releasing on or about 18 December 2016
>>>> * 4.13 release on or about 5 February 2017
>>>> 
>>>> 4.12 seems to be the sweet spot in the schedule to cut the 5.0.0
>> release
>>> described above.  It would give us sometime to plan and gain consensus
>>> around the changes in both the user and dev communities.  It would also
>>> allow the second LTS release to be based on 5.0.0 — allowing both release
>>> cycles to take advantage of the reduced support requirements and Java8
>>> language features. Based on this proposal, the releases above would
>> change
>>> to the following:
>>>> 
>>>> * 4.10 releasing on or about 28 August 2016
>>>> * 4.11 releasing on or about 23 October 2016
>>>> * 5.0.0 releasing on or about 18 December 2016
>>>> * 5.1.0 release on or about 5 February 2017
>>>> 
>>>> 

Re: Release-Management Question about New API Plug-in

[John Burwell]

Mike,

Anyone can submit a PR against any branch.  If they can get 2 LGTMs for it, it 
will be merged.  After that, you could create a new 4.6 RC, and open a vote for 
it.  While there is nothing procedurally that prevents someone from following 
this process, it is unlikely that the release vote would muster interest to 
pass.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On Jun 16, 2016, at 2:29 AM, Tutkowski, Mike  wrote:
> 
> OK - I can always deliver the plug-in for 4.6 directly to my customers and 
> first check it into the CloudStack repo maybe in 4.10 or later.
> 
>> On Jun 16, 2016, at 12:21 AM, Rajani Karuturi  wrote:
>> 
>> "We will only fix bugs in this release branch, no back porting of new
>> features" -
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up
>> 
>> I would prefer a PR on master for 4.9+
>> 
>> 
>> 
>> ~Rajani
>> 
>> On Thu, Jun 16, 2016 at 7:12 AM, Tutkowski, Mike 
>> wrote:
>> 
>>> Hi,
>>> 
>>> 
>>> This is mainly a release-management question, but - of course - anyone who
>>> knows, please feel free to comment.
>>> 
>>> 
>>> I have been developing a new API plug-in for a customer. The customer is
>>> using CloudStack 4.6.
>>> 
>>> 
>>> I'd like to contribute the plug-in to our official repo, but I'm wondering
>>> if I can open a PR as far back as 4.6 (and, of course, I'd like to have
>>> this plug-in in all subsequent releases, as well).
>>> 
>>> 
>>> Thoughts on this?
>>> 
>>> 
>>> Thanks!
>>> 
>>> Mike
>>> 

Re: [DISCUSS] 5.0.0 and 6.0.0

[John Burwell]

Wido,

Please see my responses in-line below.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On Jun 15, 2016, at 3:54 AM, Wido den Hollander <w...@widodh.nl> wrote:
> 
> You really like typing long e-mails! :)

Not particularly, no.  However, this subject is hard to make small. :(

> 
>> Op 15 juni 2016 om 2:39 schreef John Burwell <john.burw...@shapeblue.com>:
>> 
>> 
>> All,
>> 
>> We have been discussing whether or not the next release would introduce the 
>> need to increment the major revision number from 4 to 5 (i.e. become 5.0.0). 
>>  While I think we are very close to the time to have a 5.0.0 release, I 
>> don’t think the next release will introduce any backwards compatible changes 
>> that necessitate.  However, Wido has brought two important questions — What 
>> are our goals for a 5.0.0 release? When do we think we should target its 
>> release?  I think we should address and gain consensus on these issues now 
>> rather than allow circumstances to answer them for us.
>> 
>> Since I joined the community (back in the 4.1.0 days), 5.0.0 was a mythical, 
>> someday release when CloudStack would have a perfect architecture, build 
>> process, etc. -- a unicorn jumping a rainbow.  I realize that I have fallen 
>> into the trap of seeing 5.0.0 as some endpoint of perfection rather than an 
>> important milestone in the on-going improvement and evolution of the 
>> project.  Thinking it about is the former rather than the later, I realize 
>> that we have a legacy cruft that we need to discard in order to move forward 
>> and architectural design improvements that we must implement to address 
>> emerging infrastructure requirements.  I think we would be wise to separate 
>> these two objectives into a 5.0.0 release (cruft removal/breaking 
>> refactorings) and 6.0.0 (backwards incompatible architectural redesign).  
>> Not only do I see this approach as a risk mitigation, but also as a way to 
>> deliver improvements to users and developers as quickly as possible.
>> 
>> For 5.0.0, my thought is that we would target the following high-level 
>> objectives:
>> 
>> * Drop Java7 and adopt Java8 runtime and language features
>> * Drop support for any hypervisor versions no longer supported by their 
>> vendors or communities
>> * Drop any plugins which are no longer maintained or for which the community 
>> has no means to test
>> * Drop support for any distributions no longer supported by their vendors or 
>> communities
> 
> +1 to these points above.
> 
>> * Define an official support matrix for the project
>> * Adopt a formal policy for sunsetting support of components based on the 
>> end-of-life dates set by their vendors or communities
>> * Refactoring/cleanup of various APIs
>> * Embedded Jetty/uberjar/unified YAML file configuration
>> 
> 
> Not completely sure about a official support matrix, but I get the point.

What are your concerns?

> 
>> While I am sure there are more clean up items, the focus of the release 
>> would be to discard pieces that are in the way on further improvement.
>> 
>> 6.0.0 would be released within 9-12 months of 5.0.0 — giving the community 
>> time to build atop 5.0.0 to redesign/improve the architecture of the system.
>> 
>> I would like to see 5.0.0 released by the end of 2016 or at the beginning of 
>> 2017.  Based on the release plan I previously proposed, we would have the 
>> following releases remaining in 2016 and in early 2017: 
>> 
>> * 4.10 releasing on or about 28 August 2016
>> * 4.11 releasing on or about 23 October 2016
>> * 4.12 releasing on or about 18 December 2016 
>> * 4.13 release on or about 5 February 2017
>> 
>> 4.12 seems to be the sweet spot in the schedule to cut the 5.0.0 release 
>> described above.  It would give us sometime to plan and gain consensus 
>> around the changes in both the user and dev communities.  It would also 
>> allow the second LTS release to be based on 5.0.0 — allowing both release 
>> cycles to take advantage of the reduced support requirements and Java8 
>> language features. Based on this proposal, the releases above would change 
>> to the following:
>> 
>> * 4.10 releasing on or about 28 August 2016
>> * 4.11 releasing on or about 23 October 2016
>> * 5.0.0 releasing on or about 18 December 2016 
>> * 5.1.0 release on or about 5 February 2017
>> 
> 
> My question is mainly who is going to support all versions and maintain them. 
> Developers li

[DISCUSS] 5.0.0 and 6.0.0

[John Burwell]

All,

We have been discussing whether or not the next release would introduce the 
need to increment the major revision number from 4 to 5 (i.e. become 5.0.0).  
While I think we are very close to the time to have a 5.0.0 release, I don’t 
think the next release will introduce any backwards compatible changes that 
necessitate.  However, Wido has brought two important questions — What are our 
goals for a 5.0.0 release? When do we think we should target its release?  I 
think we should address and gain consensus on these issues now rather than 
allow circumstances to answer them for us.

Since I joined the community (back in the 4.1.0 days), 5.0.0 was a mythical, 
someday release when CloudStack would have a perfect architecture, build 
process, etc. -- a unicorn jumping a rainbow.  I realize that I have fallen 
into the trap of seeing 5.0.0 as some endpoint of perfection rather than an 
important milestone in the on-going improvement and evolution of the project.  
Thinking it about is the former rather than the later, I realize that we have a 
legacy cruft that we need to discard in order to move forward and architectural 
design improvements that we must implement to address emerging infrastructure 
requirements.  I think we would be wise to separate these two objectives into a 
5.0.0 release (cruft removal/breaking refactorings) and 6.0.0 (backwards 
incompatible architectural redesign).  Not only do I see this approach as a 
risk mitigation, but also as a way to deliver improvements to users and 
developers as quickly as possible.

For 5.0.0, my thought is that we would target the following high-level 
objectives:

* Drop Java7 and adopt Java8 runtime and language features
* Drop support for any hypervisor versions no longer supported by their vendors 
or communities
* Drop any plugins which are no longer maintained or for which the community 
has no means to test
* Drop support for any distributions no longer supported by their vendors or 
communities
* Define an official support matrix for the project
* Adopt a formal policy for sunsetting support of components based on the 
end-of-life dates set by their vendors or communities
* Refactoring/cleanup of various APIs
* Embedded Jetty/uberjar/unified YAML file configuration

While I am sure there are more clean up items, the focus of the release would 
be to discard pieces that are in the way on further improvement.

6.0.0 would be released within 9-12 months of 5.0.0 — giving the community time 
to build atop 5.0.0 to redesign/improve the architecture of the system.

I would like to see 5.0.0 released by the end of 2016 or at the beginning of 
2017.  Based on the release plan I previously proposed, we would have the 
following releases remaining in 2016 and in early 2017: 

* 4.10 releasing on or about 28 August 2016
* 4.11 releasing on or about 23 October 2016
* 4.12 releasing on or about 18 December 2016 
* 4.13 release on or about 5 February 2017

4.12 seems to be the sweet spot in the schedule to cut the 5.0.0 release 
described above.  It would give us sometime to plan and gain consensus around 
the changes in both the user and dev communities.  It would also allow the 
second LTS release to be based on 5.0.0 — allowing both release cycles to take 
advantage of the reduced support requirements and Java8 language features. 
Based on this proposal, the releases above would change to the following:

* 4.10 releasing on or about 28 August 2016
* 4.11 releasing on or about 23 October 2016
* 5.0.0 releasing on or about 18 December 2016 
* 5.1.0 release on or about 5 February 2017

6.0.0 would be targeted for release in 4Q2017 — providing 9-12 months to design 
and implement architectural improvements.

Thoughts?  Other paths to 5.0.0 and beyond?
-John
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue

Re: 4.9+ release

[John Burwell]

All,

Completely agree with Daan.  Per semantic versioning, a major revision increase 
must introduce a backwards incompatible change in the public API, removal of 
one of more supported devices, reduction in the list of supported 
distributions.  I agree that when we require Java8+, drop Ubuntu 12.04 support, 
drop support for an old hypervisor version, etc,  we will need to increment the 
major revision to reflect the fact that the release is not backwards compatible.

For 4.10 and LTS 4.9.0_1, I see it as critical that we support running on 
either Java7 or Java8.  In particular, producing an LTS release that only 
supports a JVM that has been unsupported for nearly 18 months would make it DOA 
in many shops.

It seems like it would make sense to have a 5.0.0 release that removed support 
for a number of legacy components (e.g. Xen 6.0 possibly 6.2, Java7, CentOS 5, 
etc), as well as, internal improvements (e.g. simplified configuration).  The 
focus of this release would be to reduce the footprint of codebase, as well as, 
make a set of backwards incompatible changes that further decouples plugins 
from core.  We would then plan for a 6.0.0 in 4Q2017 to introduce further 
architectural changes and API revisions.  The advantage to this approach is 
that it breaks up the large refactorings and architectural design changes — 
allowing us to gain velocity by removing legacy components, reducing the risk 
of these changes, and providing user benefit earlier.  Based on the release 
plan I previously proposed we have the following releases remaining in 2016 and 
in early 2017: 

* 4.10 releasing on or about 28 August 2016
* 4.11 releasing on or about 23 October 2016
* 4.12 releasing on or about 18 December 2016 
* 4.13 release on or about 5 February 2017

4.12 seems to be the sweet spot in the schedule to cut the 5.0.0 release 
described above.  It would give us sometime to plan and gain consensus around 
the changes in both the user and dev communities.  It would also allow the 
second LTS release to be based on 5.0.0 — allowing both release cycles to take 
advantage of the reduced support requirements and Java8 language features. 
Based on this proposal, the releases above would change to the following:

* 4.10 releasing on or about 28 August 2016
* 4.11 releasing on or about 23 October 2016
* 5.0.0 releasing on or about 18 December 2016 
* 5.1.0 release on or about 5 February 2017

I am in the process of moving my proposal into the wiki.  If this approach is 
acceptable, I will reflect it there, and open a thread to discuss 5.0.0.

Thanks,
-John


> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On Jun 14, 2016, at 2:02 PM, Paul Angus  wrote:
> 
> +1 Daan.
> 
> My recollection was that major version number changes were only to be 
> triggered by breaks in backward compatibility (API).
> 
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
> Sent: 14 June 2016 14:47
> To: dev 
> Cc: Rajani Karuturi 
> Subject: Re: 4.9+ release
> 
> You know that would require more then one byte for our minor version, Will.
> I would be very pleased to go to 5.0 before that time.
> 
> On Tue, Jun 14, 2016 at 3:43 PM, Will Stevens  wrote:
> 
>> Daan is just trying to get us to version 4.256.  :P
>> 
>> *Will STEVENS*
>> Lead Developer
>> 
>> *CloudOps* *| *Cloud Solutions Experts
>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw 
>> @CloudOps_
>> 
>> On Tue, Jun 14, 2016 at 9:41 AM, Daan Hoogland 
>> 
>> wrote:
>> 
>>> -1 to what Wido said. None of those points warant a major release 
>>> number upgrade. these should all be in 4.10, -.11, -12 etc.
>>> 
>>> major incompatibilities like API refactor, dropping backend support 
>>> for this or that hyporvisor or DB refactor are the things that 
>>> warrant 5.0, IMNSHO
>>> 
>>> On Tue, Jun 14, 2016 at 1:13 PM, Will Stevens 
>>> 
>>> wrote:
>>> 
 +1. :)
 On Jun 14, 2016 5:07 AM, "Wido den Hollander"  wrote:
 
> 
>> Op 14 juni 2016 om 10:55 schreef Rajani Karuturi <
>> raj...@apache.org
 :
>> 
>> 
>> 4.10 or 5.0?
>> 
> 
> I would say 4.10
> 
>> We are in the 4.* release cycle from a long time.
>> Just wanted to check if anyone is planning on major changes 
>> which
> warrants
>> 5.0
>> 
> 
> 5.0 should imho be:
> 
> - Java 8
> - Ubuntu 16.04 / systemd support
> - Drop support for older libvirt versions (KVM)
> - Some killer feature(s)
> 
> Wido
> 
>> ~Rajani
> 
 
>>> 
>>> 
>>> 
>>> --
>>> Daan
>>> 
>> 
> 
> 
> 
> --
> 

Re: XenServer 7

[John Burwell]

All,

Has anyone had a chance to try XenServer 7 since it’s release?  If so, does it 
work?  If not, how broken is it?  My guess would be in agreement with the 
general consensus that a change from CentOS 5 to 7 would not only be breaking, 
but significant.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On May 25, 2016, at 6:33 PM, Tim Mackey  wrote:
> 
> Correct, all modern XenServer distros until 7 were centos 5.x. I doubt any
> xapi changes would break cloudstack, but the plugins should be retested,
> and btw it's also systemd time
> On May 25, 2016 2:39 PM, "Remi Bergsma"  wrote:
> 
> As far as I know previous versions were based on Centos 5 even ;-)
> 
> Regards, Remi
> 
>> On 25 May 2016, at 16:55, Rafael Weingärtner 
> wrote:
>> 
>> Oh, I did know that, thanks for sharing Will.
>> 
>> I was reading their Release notes; it seems that their “major changes”
>> section does not reflect the experience you are getting.
>> 
>> On Wed, May 25, 2016 at 11:42 AM, Will Stevens 
>> wrote:
>> 
>>> CentOS changes a LOT, especially around networking, so I would not be
>>> surprised if it does not work. It still takes me like 20 minutes to
> figure
>>> out what the hell I am doing when I login to CentOS7.  No ifconfig, no
>>> iptables, etc, etc, etc...  They pretty much did a wholesale change of
>>> everything you expect to be there.
>>> 
>>> Lots of testing will have to be done on this and I have not tried to do
>>> that yet...
>>> 
>>> *Will STEVENS*
>>> Lead Developer
>>> 
>>> *CloudOps* *| *Cloud Solutions Experts
>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>> w cloudops.com *|* tw @CloudOps_
>>> 
>>> On Wed, May 25, 2016 at 9:35 AM, Rafael Weingärtner <
>>> rafaelweingart...@gmail.com> wrote:
>>> 
 Considering those scripts you are right; but, my main concerns would be
 regarding some XAPI change. The scripts that we create and inject into
>>> the
 Dom0 should not be that intrusive.
 
 I do not know about the differences between CentOS 6 and 7, but the only
 way I see a script stopping working is that if a program that the script
 uses does not come with the CentOS 7 that is bundled with XenServer or
> if
 that program does not work with CentOS 7 anymore.
 I do not recall every single task that those scripts execute, at the top
>>> of
 my memory I can say that they play with the systems' firewall. They also
 mount, copy, and move some files around. I believe they also remove some
 configurations from the XAPI sometimes.
 
 Looking at the release notes in [1], it seems that none of the scripts
 should stop working. However, to be sure about every single function and
 task that ACS execute on XenServer a batch of tests would be required.
 
 [1]
>>> 
> https://wiki.centos.org/Manuals/ReleaseNotes/CentOS7#head-b02657cf2e223edb2d7946cbc45086d42c2bb41b
 
 
 On Wed, May 25, 2016 at 10:19 AM, Paul Angus 
 wrote:
 
> Rafael
> 
> We don’t purely use XAPI with XenServer.
> XenServer 7 has a CentOS7 dom0 rather than CentOS6.  We do a whole load
 of
> stuff behind the scenes with python and shell scripts a chunk of which
> won't work anymore.
> 
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 
> -Original Message-
> From: Rafael Weingärtner [mailto:rafaelweingart...@gmail.com]
> Sent: 25 May 2016 14:12
> To: dev@cloudstack.apache.org
> Subject: Re: XenServer 7
> 
> Will there be any change on the XAPI? If not, it already works (just
>>> the
> new functions, if any, that will not be used).
> 
> On Wed, May 25, 2016 at 9:59 AM, Paul Angus 
> wrote:
> 
>> Is anyone here working on XenServer 7 support for CloudStack?
>> 
>> 
>> Kind regards,
>> 
>> Paul Angus
>> 
>> 
>> paul.an...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
> 
> 
> --
> Rafael Weingärtner
 
 
 
 --
 Rafael Weingärtner
>> 
>> 
>> 
>> --
>> Rafael Weingärtner

Re: ICLA for contributors

[John Burwell]

Ron,

As part of committer on-boarding, the PMC requires each committer candidate 
have an ASF ICLA in place and verifies the CCLA of their employer.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On Jun 10, 2016, at 10:47 AM, Ron Wheeler <rwhee...@artifact-software.com> 
wrote:
> 
> That is correct from my reading of the Apache page as well.
> I think that your definition of committer and contributor is identical to 
> Apache's.
> 
> 
> Ron
> 
> On 09/06/2016 3:57 PM, John Burwell wrote:
>> All,
>> 
>> I believe Pierre-Luc’s explanation is correct, and that we may have slightly 
>> different definitions of contributor and committer.  Generally, we define a 
>> contributor, we are referring to anyone (committer, PMC member, any person 
>> in the world) who contributes code, documentation, etc to the project.  We 
>> define a committer as a contributor who demonstrated a strong and sustained 
>> commitment to the project.  In recognition of this commitment, committers 
>> are granted the right to commit changes to the project’s public 
>> repositories.  Execution of an ICLA and CCLA are required in order for 
>> someone to become an Apache CloudStack committer.
>> 
>> IANAL, but my understanding is that any individual can contribute to an 
>> Apache project without signing an ICLA/CCLA because a committer with one in 
>> place will perform commit to the repository.  The act of the individual 
>> giving code to the project and a committer reviewing and committing it to 
>> the repository qualifies as rights assignment under by the ASL.  Since 
>> execution of an ICLA/CCLA is a prerequisite for all Apache CloudStack 
>> committers and Apache secures our repositories to only allow committers 
>> read/write access, rights assignment under the ASL for our repositories is 
>> properly enforced/managed.
>> 
>> Thanks,
>> -John
>> 
>> john.burw...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
>> @shapeblue
>> 
>> 
>> On Jun 9, 2016, at 1:46 PM, Pierre-Luc Dion <pdion...@apache.org> wrote:
>>> Hi Ron,
>>> 
>>> As far as I know, ICLA and CCLA is required for commiters, but not required
>>> for non-commiters contributors. I don't know about all details, someone
>>> else in the ML might have more details about this. For sure, you can be a
>>> contributor without submitting code as a anyone in this ML is consider as a
>>> contributor.
>>> 
>>> Cheers,
>>> 
>>> 
>>> On Thu, Jun 9, 2016 at 11:46 AM, Ron Wheeler <rwhee...@artifact-software.com
>>>> wrote:
>>>> As part of a discussion during last weeks meeting in Mpntreal, the
>>>> question was raised about the requirement to have an Individual Contributor
>>>> License Agreement (ICLA) for each contributor.
>>>> 
>>>> http://www.apache.org/licenses/ describes the requirements as follows:
>>>> 
>>>> "The ASF desires that all contributors of ideas, code, or documentation to
>>>> any Apache projects complete, sign, and submit (via fax or email) an
>>>> Individual Contributor License Agreement (ICLA). The purpose of this
>>>> agreement is to clearly define the terms under which intellectual property
>>>> has been contributed to the ASF and thereby allow us to defend the project
>>>> should there be a legal dispute regarding the software at some future time.
>>>> A signed ICLA is required to be on file before an individual is given
>>>> commit rights to an ASF project.
>>>> 
>>>> For a corporation that has assigned employees to work on an Apache
>>>> project, a Corporate CLA (CCLA) is available for contributing intellectual
>>>> property via the corporation, that may have been assigned as part of an
>>>> employment agreement. Note that a Corporate CLA does not remove the need
>>>> for every developer to sign their own ICLA as an individual, to cover any
>>>> of their contributions which are not owned by the corporation signing the
>>>> CCLA."
>>>> 
>>>> There is a split between desirable and mandatory.
>>>> 
>>>> I am not sure that the argument that submitting a PR is a clear sign of
>>>> intent to give up all rights, has ever been tested in a court but it is
>>>> much easier to have an signed ICLA for each contributor.
>>>> 
>>>&

Re: ICLA for contributors

[John Burwell]

All,

I believe Pierre-Luc’s explanation is correct, and that we may have slightly 
different definitions of contributor and committer.  Generally, we define a 
contributor, we are referring to anyone (committer, PMC member, any person in 
the world) who contributes code, documentation, etc to the project.  We define 
a committer as a contributor who demonstrated a strong and sustained commitment 
to the project.  In recognition of this commitment, committers are granted the 
right to commit changes to the project’s public repositories.  Execution of an 
ICLA and CCLA are required in order for someone to become an Apache CloudStack 
committer.

IANAL, but my understanding is that any individual can contribute to an Apache 
project without signing an ICLA/CCLA because a committer with one in place will 
perform commit to the repository.  The act of the individual giving code to the 
project and a committer reviewing and committing it to the repository qualifies 
as rights assignment under by the ASL.  Since execution of an ICLA/CCLA is a 
prerequisite for all Apache CloudStack committers and Apache secures our 
repositories to only allow committers read/write access, rights assignment 
under the ASL for our repositories is properly enforced/managed.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On Jun 9, 2016, at 1:46 PM, Pierre-Luc Dion  wrote:
> 
> Hi Ron,
> 
> As far as I know, ICLA and CCLA is required for commiters, but not required
> for non-commiters contributors. I don't know about all details, someone
> else in the ML might have more details about this. For sure, you can be a
> contributor without submitting code as a anyone in this ML is consider as a
> contributor.
> 
> Cheers,
> 
> 
> On Thu, Jun 9, 2016 at 11:46 AM, Ron Wheeler > wrote:
> 
>> As part of a discussion during last weeks meeting in Mpntreal, the
>> question was raised about the requirement to have an Individual Contributor
>> License Agreement (ICLA) for each contributor.
>> 
>> http://www.apache.org/licenses/ describes the requirements as follows:
>> 
>> "The ASF desires that all contributors of ideas, code, or documentation to
>> any Apache projects complete, sign, and submit (via fax or email) an
>> Individual Contributor License Agreement (ICLA). The purpose of this
>> agreement is to clearly define the terms under which intellectual property
>> has been contributed to the ASF and thereby allow us to defend the project
>> should there be a legal dispute regarding the software at some future time.
>> A signed ICLA is required to be on file before an individual is given
>> commit rights to an ASF project.
>> 
>> For a corporation that has assigned employees to work on an Apache
>> project, a Corporate CLA (CCLA) is available for contributing intellectual
>> property via the corporation, that may have been assigned as part of an
>> employment agreement. Note that a Corporate CLA does not remove the need
>> for every developer to sign their own ICLA as an individual, to cover any
>> of their contributions which are not owned by the corporation signing the
>> CCLA."
>> 
>> There is a split between desirable and mandatory.
>> 
>> I am not sure that the argument that submitting a PR is a clear sign of
>> intent to give up all rights, has ever been tested in a court but it is
>> much easier to have an signed ICLA for each contributor.
>> 
>> A CCLA for each company that is either paying people to work on the
>> project or has a clause in their employment contract giving the company
>> rights to all IP created during their employment is required. This removes
>> any ambiguity about the individual's right to make a PR.
>> 
>> It is a little bit of housekeeping to keep track of the list of
>> contributors with ICLA's. A wiki page listing the contributors is a simple
>> solution.
>> 
>> https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Contributors
>> is what we did at OFBiz.
>> 
>> The ICLA and CCLA is good for all Apache projects.
>> 
>> Ron
>> 
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwhee...@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>> 
>> 

Re: [DISCUSS] Release Cycle

[John Burwell]

All,

Quick correction below: I misquoted the LTS proposal — branches are cut on 1 
January and 1 _July_ (not June).

I apologize for the mistake,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On May 31, 2016, at 12:28 AM, John Burwell <john.burw...@shapeblue.com> wrote:
> 
> All,
> 
> Over the course of the last 6-8 months, we have attempted to release monthly. 
>  We successfully delivered 4.6, 4,7, and 4,8 using this model.  We also 
> established a strong set of CM and review principles to improve the quality 
> of releases [1].  To support users that are unable to upgrade on a monthly 
> basis, we have proposed adding an LTS release cycle that will provide an 18 
> month support window for releases that are cut twice a year (January and 
> June).  We are on track for two types of releases — regular and LTS releases.
> 
> Reflecting on the monthly release cycle, we spent at least 8 days a month 
> preparing and voting out releases.  This cadence left an average of 12 days a 
> month to build features.  In my experience, this cadence impeded efforts to 
> build larger features or address large architectural issues.  Therefore, for 
> regular releases, I propose we elongate the release cycle from one (1) month 
> to two (2) months with the following phases:
> 
>* Development: 6 weeks (42 days)
>* Release Preparation/Test: 1 week (7 days)
>* RC Voting: 1 week (7 days)
> 
> In order to ensure the timeliness of releases and avoid indecision, these 
> timeframes would be hard limits.  Therefore, the development phase would 
> close at 6 weeks — no exceptions.  Finally, we would only support the current 
> and previous regular release.  For example, we would only provide support for 
> 4.8 and 4.9 releases until 4.10 is released when 4.8 would reach end of life. 
>  This cycle would continue to use the same release principles(e.g. master 
> frozen during release preparation/test and RC voting, 2 LGTM per PR, etc).  I 
> believe this longer cycle would provide a regular, responsive release cycle 
> and enough development time to build larger features.
> 
> Per the LTS proposal [2], LTS branches would be cut from the most recent 
> stable release branch as of 1 January and 1 June every year.  Upon creation, 
> each LTS branch would go through a 6 week stabilization/test process.  
> Following their initial release, these branches releases receive applicable 
> blocker, critical, and CVE fixes for 12 months.  Ideally, defect fixes that 
> apply to both LTS and regular releases will be applied to oldest LTS release 
> and forward merged.  Additional LTS maintenance releases will occur based on 
> an as-needed basis — balancing release frequency and stability.
> 
> Based on these two release cycles, regular and LTS, the release calendar for 
> the next twelve (12) months would be as follows:
> 
>* LTS 4.9.0_1 (Release Date: 21 August 2016/EOL: 21 April 2018)
>* Stabilization/Testing: 1 July - 14 August 2016
>* RC Voting: 14-21 August 2016
>* 4.10.0 (Release Date: 28 August 2016/EOL: 18 December 2016)
> * Development: 1 July - 14 August 2016
> * Testing: 14-21 August 2016
>* RC Voting: 21-28 August 2016
>* 4.11.0 (Release Date: 23 October 2016/EOL: 12 February 2017)
>* Development: 28 August - 9 October 2016
>* Testing: 9-16 October 2016
>* RC Voting: 16-23 October 2016
>* 4.12.0 (Release Date: 18 December 2016/EOL: 2 April 2017)
>* Development: 23 October - 4 December 2016
>* Testing: 4-11 December 2016
>* RC Voting: 11-18 December 2016
>* 4.13.0 (Release Date: 12 February 2017/EOL: 4 June 2017)
>* Development: 18 December 2016 - 29 January 2017
>* Testing: 29 January - 5 February 2017
> * RC Voting: 5-12 February 2017
>* LTS 4.12.0_1 (Release Date: 19 February 2017/EOL: 19 October 2018)
>* Stabilization: 1 January - 12 February 2017
>* RC Voting: 19 February 2017
>* 4.14.0 (Release Date: 2 April 2017/EOL: 30 July 2017)
> * Development: 12 February - 26 March 2017
>* Testing: 26 March - 2 April 2017
>* RC Voting: 2-9 April 2017
>* 4.15.0 (Release Date: 24 April 2017/ EOL: TBD)
> * Development: 26 March - 22 May 2017
> * Testing: 22-29 May 2017
>* RC Voting: 29 May - 4 June 2017
>* 4.16.0 (Release Date: 30 July 2017/ EOL: TBD)
> * Development: 4 June - 16 July 2016
> * Testing: 16-23 July 2016
> * RC Voting: 23-30 July 2016
>* LTS 4.15.0_1 (Release Date: 27 August 2017/ EOL: 27 April 2019)
> * Development: 1 July - 13 August 2017
> * Testing: 13-20 August 2017
> * RC Voting: 20-27 August 2017
> 
> A few 

[DISCUSS] Release Cycle

[John Burwell]

All,

Over the course of the last 6-8 months, we have attempted to release monthly.  
We successfully delivered 4.6, 4,7, and 4,8 using this model.  We also 
established a strong set of CM and review principles to improve the quality of 
releases [1].  To support users that are unable to upgrade on a monthly basis, 
we have proposed adding an LTS release cycle that will provide an 18 month 
support window for releases that are cut twice a year (January and June).  We 
are on track for two types of releases — regular and LTS releases.

Reflecting on the monthly release cycle, we spent at least 8 days a month 
preparing and voting out releases.  This cadence left an average of 12 days a 
month to build features.  In my experience, this cadence impeded efforts to 
build larger features or address large architectural issues.  Therefore, for 
regular releases, I propose we elongate the release cycle from one (1) month to 
two (2) months with the following phases:

* Development: 6 weeks (42 days)
* Release Preparation/Test: 1 week (7 days)
* RC Voting: 1 week (7 days)

In order to ensure the timeliness of releases and avoid indecision, these 
timeframes would be hard limits.  Therefore, the development phase would close 
at 6 weeks — no exceptions.  Finally, we would only support the current and 
previous regular release.  For example, we would only provide support for 4.8 
and 4.9 releases until 4.10 is released when 4.8 would reach end of life.  This 
cycle would continue to use the same release principles(e.g. master frozen 
during release preparation/test and RC voting, 2 LGTM per PR, etc).  I believe 
this longer cycle would provide a regular, responsive release cycle and enough 
development time to build larger features.

Per the LTS proposal [2], LTS branches would be cut from the most recent stable 
release branch as of 1 January and 1 June every year.  Upon creation, each LTS 
branch would go through a 6 week stabilization/test process.  Following their 
initial release, these branches releases receive applicable blocker, critical, 
and CVE fixes for 12 months.  Ideally, defect fixes that apply to both LTS and 
regular releases will be applied to oldest LTS release and forward merged.  
Additional LTS maintenance releases will occur based on an as-needed basis — 
balancing release frequency and stability.

Based on these two release cycles, regular and LTS, the release calendar for 
the next twelve (12) months would be as follows:

* LTS 4.9.0_1 (Release Date: 21 August 2016/EOL: 21 April 2018)
* Stabilization/Testing: 1 July - 14 August 2016
* RC Voting: 14-21 August 2016
* 4.10.0 (Release Date: 28 August 2016/EOL: 18 December 2016)
* Development: 1 July - 14 August 2016
* Testing: 14-21 August 2016
* RC Voting: 21-28 August 2016
* 4.11.0 (Release Date: 23 October 2016/EOL: 12 February 2017)
* Development: 28 August - 9 October 2016
* Testing: 9-16 October 2016
* RC Voting: 16-23 October 2016
* 4.12.0 (Release Date: 18 December 2016/EOL: 2 April 2017)
* Development: 23 October - 4 December 2016
* Testing: 4-11 December 2016
* RC Voting: 11-18 December 2016
* 4.13.0 (Release Date: 12 February 2017/EOL: 4 June 2017)
* Development: 18 December 2016 - 29 January 2017
* Testing: 29 January - 5 February 2017
* RC Voting: 5-12 February 2017
* LTS 4.12.0_1 (Release Date: 19 February 2017/EOL: 19 October 2018)
* Stabilization: 1 January - 12 February 2017
* RC Voting: 19 February 2017
* 4.14.0 (Release Date: 2 April 2017/EOL: 30 July 2017)
* Development: 12 February - 26 March 2017
* Testing: 26 March - 2 April 2017
* RC Voting: 2-9 April 2017
* 4.15.0 (Release Date: 24 April 2017/ EOL: TBD)
* Development: 26 March - 22 May 2017
* Testing: 22-29 May 2017
* RC Voting: 29 May - 4 June 2017
* 4.16.0 (Release Date: 30 July 2017/ EOL: TBD)
* Development: 4 June - 16 July 2016
* Testing: 16-23 July 2016
* RC Voting: 23-30 July 2016
* LTS 4.15.0_1 (Release Date: 27 August 2017/ EOL: 27 April 2019)
* Development: 1 July - 13 August 2017
* Testing: 13-20 August 2017
* RC Voting: 20-27 August 2017

A few notes/questions regarding this schedule:

1. The 4.10 cycle officially starts on 1 July to synchronize with the 
beginning of an LTS cycle and to ensure that there is ample time for 4.9 to be 
voted out.  Assuming 4.9 releases before 1 July, the 4.10 development phase 
would still end on 14 August 2016 to maintain a regular cadence.  Therefore, 
the 4.10 development phase will likely be a 1-2 weeks longer than other 
releases.
2. The calendar lined up neatly to have each phase end on a Sunday.  This 
alignment affords developers a weekend to complete any outstanding.  However, 
the downside is that votes may close on Sundays.  An alternative would be to 
round up/down to end phases on Fridays.  Personally, I have no strong feelings 

Re: RM after 4.9

[John Burwell]

All,

I am also willing to be an RM post 4.9, as well as, for LTS.  I will be able to 
serve as an RM through at least the end of 2016.

To kickoff the planning process, I have started a release cycle discussion on 
the list to pin down the schedule for both regular and LTS releases.

Thanks,
-John 

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On May 27, 2016, at 12:00 PM, Tutkowski, Mike  wrote:
> 
> Thanks, Rajani! :)
> 
> From: Rajani Karuturi 
> Sent: Friday, May 27, 2016 8:49 AM
> To: dev@cloudstack.apache.org
> Subject: Re: RM after 4.9
> 
> I volunteer to be the RM for next release
> 
> Thanks
> On 03-May-2016 4:13 AM, "Will Stevens"  wrote:
> 
>> Hello All,
>> As you all know, I am the RM for the 4.9 release.  Unfortunately, this is
>> not a position I will be able to maintain for the long term, so we should
>> start this discussion sooner rather than later.
>> 
>> I am actively working to simplify the RM role by working towards the
>> following goals:
>> - Get the cloudstack repo moved to the 'apache-cloudstack' github org so we
>> can use labels, etc so the community can better organize itself regarding
>> the status of different PRs
>> - Make it easier to setup distributed CI environments so the RM is not
>> responsible for all the CI.
>> - Build tooling to simplify contributing back the results of CI runs.
>> - Improve our set of 'standard tests' to be more complete yet still
>> manageable to be run on every PR.
>> 
>> I will continue to work towards lowering the bar for the RM, but we need to
>> start the conversation of who is next in line as the RM.  :)
>> 
>> Cheers,
>> 
>> Will
>> 

Re: ACS PRs Status - 2016/05/12

[John Burwell]

Will,

Rohit has built a new systemvm template that includes strongswan and quagga.  
He can point you to images, as well as, help with understanding the 
build/release process.

Thanks,
-John

> 
Regards,

John Burwell

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
On May 13, 2016, at 5:54 PM, Will Stevens <wstev...@cloudops.com> wrote:
> 
> Ok, thank you John.  I need to sort out the process for testing and
> releasing a new system VM template.  Another thing to do...
> 
> *Will STEVENS*
> Lead Developer
> 
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
> 
> On Fri, May 13, 2016 at 5:34 PM, John Burwell <john.burw...@shapeblue.com>
> wrote:
> 
>> Will,
>> 
>> 1371 includes new Marvin test cases to verify the operation of OSPF.
>> Bobby Stoyanov will be running these tests, as well as, manual rating of
>> the UI features added to support it.
>> 
>> Thanks,
>> -John
>> 
>> Regards,
>> 
>> John Burwell
>> 
>> john.burw...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
>> @shapeblue
>> On May 12, 2016, at 5:02 PM, Will Stevens <williamstev...@gmail.com>
>> wrote:
>>> 
>>> ACS PRs
>>> 
>>>  - 1537 - master (ready, pending Jenkins)
>>>  - 1514 - 4.7 (pending Jenkins)
>>>  - 1520 - master (ready, pending Jenkins)
>>>  - 1482 - 4.7 (pending Jenkins & LGTM)
>>>  - 1403 - master (pending LGTM, run CI again to be sure)
>>>  - 1532 - master (ready, pending LGTM and Jenkins)
>>>  - 956 - master (ready, pending Jenkins and verification)
>>>  - 1516 - master (ready, pending Travis)
>>>  - 1455 - master (ready, pending LGTM)
>>>  - 1376 - master (ready, pending 1515 conflict)
>>>  - 1280 - master (ready, pending LGTM)
>>>  - 1424 - master (pending LGTM)
>>>  - 1297 - master (pending verification)
>>>  - 1464 - master (pending LGTM)
>>>  - 1410 - 4.7 (ready, pending LGTM)
>>>  - 1486 - 4.7 (ready, pending LGTM)
>>>  - 1436 - master (CI posted, needs review)
>>>  - * 1423 - master + svm (*pending CI)
>>>  - 1371 - master + svm (figure out how to test)
>>>  - 872 - master + svm (pending CI)
>>>  - 866 - master (pending LGTM)
>>>  - 1523 - master (*pending CI)
>>>  - 1304 - master (needs work)
>>>  - 1503 - master (bbl1)
>>>  - 1513 - 4.8 (bbl2)
>>>  - 1450 - 4.7 (ready, pending LGTM)
>>>  - 1331 - 4.7 (cs1)
>>>  - 1470 - 4.7 (being fixed)
>>>  - 1471 - 4.7 (pending comments)
>>>  - 1412 - 4.6 (pending ALL)
>>>  - 1406 - 4.6 (pending LGTM)
>>>  - 1378 - 4.6 (pending LGTM)
>>>  - 1533 - master (pending LGTM)
>>>  - 1491 - 4.7 (ready, pending LGTM)
>>>  - 1360 - master (pending LGTM)
>>>  - 1499 - master (pending ALL)
>>>  - 883 - master (pending ALL)
>>>  - 956 - master (needs work)
>>>  - 846 - master (pending CI)
>>>  - 1244 - master (needs work)
>>>  - 1511 - master (bbl4)
>>>  - 1530 (1351) - master (pending tests)
>>>  - 1519 - 4.7 (needs work)
>>>  - 1437 - master (pending HyperV CI)
>>>  - 985 - master (bbl3)
>>>  - 1269 - master (pending LGTM)
>>>  - 669 - master (pending ALL)
>>>  - 1494 - master (bbl3)
>>>  - 1417 - master (marvin fails to import)
>>>  - 1540 - master (pending LGTM and verification)
>>> 
>>> ​Sorry this update is so late.  I have been pretty buried trying to stay
>> on
>>> top of everything in preparation for the freeze next week.
>>> 
>>> If you have some time *PLEASE* help out with some code review.  We have​
>> 18
>>> PRs that are pending LGTM reviews and most of them are ready to merge
>>> assuming I get some code review.
>>> 
>>> I will be freezing master early next week.  I said Monday, but it will
>>> likely be Tuesday since I expect to have a lot of work trying to get the
>>> last stuff in that has been reviewed.
>>> 
>>> If there are PRs that you think are ready that you think should be in
>> 4.9,
>>> speak now or forever hold your peace.  I am doing my best to keep things
>>> moving and getting the different PRs into a good place...
>>> 
>>> Right now we are down to *161 PRs* so we have definitely made progress.
>> I
>>> think there are another 20 that we could reasonably get in if we do a bit
>>> of a blitz of code review...
>>> 
>>> Cheers,
>>> 
>>> Will
>>> 
>>> PS: I don't know how Remi did this for so long.  I need some sleep...  :P
>> 

Re: [DISCUSS] Moving to Java8

[John Burwell]

Ron,

According to Spring's documentation, Spring 3 only supports running byte code 
compiled for 1.7 on a Java8 VM [1].  Spring 4 is the first release to support 
byte code compiled to 1.8 running on a Java8 VM.  

Our experience with CloudStack 4.5 and master on Java8 has been that it runs, 
but within 36-48 hangs or abends.  Therefore, the first step to getting a 
stable build on JDK8 is to ensure that all our dependencies support it.

Thanks,
-John

[1]: https://spring.io/blog/2013/05/21/spring-framework-4-0-m1-3-2-3-available/

> 
Regards,

John Burwell

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
On May 13, 2016, at 2:04 PM, Ron Wheeler <rwhee...@artifact-software.com> wrote:
> 
> I am not sure what you are using in Spring but I have been using Spring 3.x.x 
> with Java 8 for some time.
> 
> I can believe that Spring 4 is "better" than Spring 3 but you might see if 
> you can separate these two technology upgrades just to keep it simple.
> There is enough in Java 8 to make a pretty big project if you just look at 
> Streams and refactoring interfaces and abstract classes to reduce the amount 
> of code.
> 
> Just a comment from the cheap seats.
> 
> Ron
> 
> 
>> On 13/05/2016 1:10 PM, Rohit Yadav wrote:
>> All,
>> 
>> 
>> I've started some work [pr] that aims to adapt CloudStack to recent changes 
>> in the environments and the ecosystem:
>> 
>> 
>> - Java8, Spring 4.x
>> 
>> - SystemD
>> 
>> - MariaDB and MySQL
>> 
>> - Reduce distro provided package dependency
>> 
>> - Packaging, CI and testing
>> 
>> 
>> These are long term goals but I've identified some concrete goals:
>> 
>> 
>> - Migrate to Java8 both for building codebase and running CloudStack (mgmt 
>> server, usage, agent etc)
>> 
>> - Migrate to Spring 4.x as 3.x is not supported to work with Java7
>> 
>> - Fix CI and packaging to use Java8
>> 
>> - Reduce distro specific package dependency such as Tomcat, since we're 
>> already using Jetty (maven-jetty-plugin) during development we can use 
>> embedded Jetty for mgmt server(s) as well
>> 
>> - Update systemvm template to include Java8 JRE
>> 
>> - Update packaging to support systemd (CentOS7+ has some systemd support and 
>> thanks to Wido's recent PR we would have systemd support for debian packages 
>> in future too)
>> 
>> - Optimize JVM options for long running mgmt server(s), agent(s) and usage 
>> server(s) to run on JRE8
>> 
>> 
>> I've sent a [pr] to show some initial progress in this regard where we've 
>> some outstanding issues but we're able to build/run/test with Java8 + Spring 
>> 4.x and TravisCI has been fixed to use JDK8 as well.
>> 
>> 
>> Testing in general would be a huge requirement for this initiative, 
>> especially testing of all the plugins. Java7 has EOL-ed and Java9 is around 
>> the corner; we've seen good amount of security and memory issues with 
>> Java7/6 and Tomcat6.x; therefore it seems necessary to work on above as we 
>> move towards a LTS release in upcoming months.
>> 
>> 
>> Request for comments, suggestions and guidance. Thanks.
>> 
>> 
>> [pr] https://github.com/apache/cloudstack/pull/1546
>> 
>> 
>> Regards.
>> 
>> Regards,
>> 
>> Rohit Yadav
>> 
>> rohit.ya...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
> 
> 
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> 

Re: [DISCUSS] Moving to Java8

[John Burwell]

All,

Java8 is targeted for post 4.9.  Oracle provides an official PPA for Java6, 
Java7, Java8, and Java9 [1] that supports Ubuntu 14.04.  It is important to 
bear in mind that Java7 was EOL’ed on April 2015 [2].  In my opinion, the 
recent history of Java vulnerabilities dictates that we cannot allow a 
particular distribution’s failure to update their to supported JDK place our 
user community at risk.

Thanks,
-John

[1]: https://launchpad.net/~webupd8team/+archive/ubuntu/java
[2]: http://www.oracle.com/technetwork/java/eol-135779.html

> 
Regards,

John Burwell

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
On May 13, 2016, at 4:37 PM, Erik Weber <terbol...@gmail.com> wrote:
> 
> It only means that we are dropping support for newer ACS versions.
> It most likely won't get into 4.9, which means 14.04 will be supported a
> few more weeks/months.
> 
> We could mention in the 4.9 RN that for the next release (call it 5.0
> because of the change?) will only be supported by $xyz distribution versjons
> 
> -- 
> Erik
> 
> On Fri, May 13, 2016 at 9:10 PM, Wido den Hollander <w...@widodh.nl> wrote:
> 
>> I am in favor of Java 8, but it means we would drop Ubuntu 14.04 support.
>> 
>> That would make life a bit easier though, since Ubuntu 16.04 has systemd
>> and 14.04 still has sysvinit and that make packaging a problem.
>> 
>>> Op 13 mei 2016 om 19:10 schreef Rohit Yadav <rohit.ya...@shapeblue.com>:
>>> 
>>> 
>>> All,
>>> 
>>> 
>>> I've started some work [pr] that aims to adapt CloudStack to recent
>> changes in the environments and the ecosystem:
>>> 
>>> 
>>> - Java8, Spring 4.x
>>> 
>>> - SystemD
>>> 
>>> - MariaDB and MySQL
>>> 
>>> - Reduce distro provided package dependency
>>> 
>>> - Packaging, CI and testing
>>> 
>>> 
>>> These are long term goals but I've identified some concrete goals:
>>> 
>>> 
>>> - Migrate to Java8 both for building codebase and running CloudStack
>> (mgmt server, usage, agent etc)
>>> 
>>> - Migrate to Spring 4.x as 3.x is not supported to work with Java7
>>> 
>>> - Fix CI and packaging to use Java8
>>> 
>>> - Reduce distro specific package dependency such as Tomcat, since we're
>> already using Jetty (maven-jetty-plugin) during development we can use
>> embedded Jetty for mgmt server(s) as well
>>> 
>>> - Update systemvm template to include Java8 JRE
>>> 
>>> - Update packaging to support systemd (CentOS7+ has some systemd support
>> and thanks to Wido's recent PR we would have systemd support for debian
>> packages in future too)
>>> 
>>> - Optimize JVM options for long running mgmt server(s), agent(s) and
>> usage server(s) to run on JRE8
>>> 
>>> 
>>> I've sent a [pr] to show some initial progress in this regard where
>> we've some outstanding issues but we're able to build/run/test with Java8 +
>> Spring 4.x and TravisCI has been fixed to use JDK8 as well.
>>> 
>>> 
>>> Testing in general would be a huge requirement for this initiative,
>> especially testing of all the plugins. Java7 has EOL-ed and Java9 is around
>> the corner; we've seen good amount of security and memory issues with
>> Java7/6 and Tomcat6.x; therefore it seems necessary to work on above as we
>> move towards a LTS release in upcoming months.
>>> 
>>> 
>>> Request for comments, suggestions and guidance. Thanks.
>>> 
>>> 
>>> [pr] https://github.com/apache/cloudstack/pull/1546
>>> 
>>> 
>>> Regards.
>>> 
>>> Regards,
>>> 
>>> Rohit Yadav
>>> 
>>> rohit.ya...@shapeblue.com
>>> www.shapeblue.com
>>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>>> @shapeblue
>> 

Re: Organizing CCCNA16 Hackathon

[John Burwell]

Pierre-Luc and WIll,

While testing and CI are important topics, there may be additional topics of 
high importance to those attending the conference to discuss and work.  
Therefore, I think it is a good idea to collect everyone’s thoughts to ensure 
the priorities of all attendees are addressed.  Additionally, my hope is that 
some advance organization and coordination will allow people to participate 
virtually.

Thanks,
-John

> 
Regards,

John Burwell

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
On May 5, 2016, at 1:32 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
> 
> Thanks John  for that initiative.
> 
> Good idea to start organizing teams and topics since we won't have much
> time on site. As Will said the main theme would be around CI, and we are
> working to get enought hardware and ressource so all teams could have their
> own setup...
> 
> Cheers,
> 
> PL
> 
> On Thu, May 5, 2016 at 12:02 PM, Will Stevens <williamstev...@gmail.com>
> wrote:
> 
>> Hey John,
>> Thanks for the initiative.  We will be focusing the hackathon mainly
>> around testing.  I will be setting up full environments for the teams to
>> work with and those details will be made available on the day of the
>> hackathon.
>> 
>> I think it is a good idea to have a general theme for the hackathon to
>> help focus us on getting actionable work done.
>> 
>> I like the idea of having topics submitted early and teams getting
>> organized prior to the actual hackathon.
>> 
>> Cheers,
>> 
>> Will
>> 
>> On Thu, May 5, 2016 at 10:23 AM, John Burwell <john.burw...@shapeblue.com>
>> wrote:
>> 
>>> All,
>>> 
>>> In advance of the CCNA16 Hackathon on Wednesday, 1 June 2016, it seems
>>> like it would be wise to organize the topics which people are interested in
>>> addressing.  My thought is anyone may suggest a topic and/or register their
>>> interest in a topic.  Also, since there will likely be a number of people
>>> unable to physically attend, we can create a Google Hangout for each
>>> group.  Hopefully, by organizing the topics in advance and broadcasting our
>>> work, we can further extend participation across the community.
>>> 
>>> To begin organizing topics, I have created a public Google Spreadsheet
>>> [1] with columns for group name, organizer/proposer,  interested
>>> participants, and a Hangout URL.  If you would like to propose a topic,
>>> create a new row with the name of the group, your name and email, and a
>>> Hangout URL (instructions[2]).  If you are interested in one or more
>>> topics, please add your name and email to the row.  I would also like to
>>> propose that we record the Hangout sessions (upload location TBD), and that
>>> the organizer of the topic report any results of their efforts with a URL
>>> of the recording back to dev@.
>>> 
>>> Finally, I have included users@ and marketing@ as they may also wish to
>>> participate.
>>> 
>>> Thanks,
>>> -John
>>> 
>>> [1]:
>>> https://docs.google.com/spreadsheets/d/14U0E1YpgZvsBc88SHVojo-XzOLAKs-WFEkMxXlrAl_o/edit#gid=0
>>> [2]: https://support.google.com/hangouts/answer/3111943?hl=en
>>> 
>>> 
>>> 
>>> 
>>> 
>>> john.burw...@shapeblue.com
>>> www.shapeblue.com
>>> @shapeblue
>>> 
>> 
>> 

Organizing CCCNA16 Hackathon

[John Burwell]

All,

In advance of the CCNA16 Hackathon on Wednesday, 1 June 2016, it seems like it 
would be wise to organize the topics which people are interested in addressing. 
 My thought is anyone may suggest a topic and/or register their interest in a 
topic.  Also, since there will likely be a number of people unable to 
physically attend, we can create a Google Hangout for each group.  Hopefully, 
by organizing the topics in advance and broadcasting our work, we can further 
extend participation across the community.

To begin organizing topics, I have created a public Google Spreadsheet [1] with 
columns for group name, organizer/proposer,  interested participants, and a 
Hangout URL.  If you would like to propose a topic, create a new row with the 
name of the group, your name and email, and a Hangout URL (instructions[2]).  
If you are interested in one or more topics, please add your name and email to 
the row.  I would also like to propose that we record the Hangout sessions 
(upload location TBD), and that the organizer of the topic report any results 
of their efforts with a URL of the recording back to dev@.

Finally, I have included users@ and marketing@ as they may also wish to 
participate.

Thanks,
-John

[1]: 
https://docs.google.com/spreadsheets/d/14U0E1YpgZvsBc88SHVojo-XzOLAKs-WFEkMxXlrAl_o/edit#gid=0
[2]: https://support.google.com/hangouts/answer/3111943?hl=en

Regards,

John Burwell

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue

Re: Rafael Weingartner joining the PMC

[John Burwell]

Congrats Rafael.

> 
Regards,

John Burwell

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
On May 2, 2016, at 9:21 AM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote:
> 
> Congrats Rafael.
> 
> Regards,
> Rohit Yadav
> 
> 
> Regards,
> 
> Rohit Yadav
> 
> rohit.ya...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> On Apr 29 2016, at 1:20 am, Rafael Weingärtner <rafaelweingart...@gmail.com> 
> wrote:
> 
> Thank you all for the warm welcome. It is an honor to be part of the Apache
> CloudStack (ACS) committee. I will try to work as much as I can to help the
> PMC, committers, and contributors on improving the ACS. Sometimes I might
> not be as present as others (as it is happening now), but that is due to my
> Ph. D. tasks.
> 
> As soon as I get things back on tracks I make myself more present :)
> 
> On Thu, Apr 28, 2016 at 10:55 AM, Patrick Dube <patrickdub...@gmail.com>
> wrote:
> 
>> Congratulations!
>> 
>> On Thu, Apr 28, 2016 at 8:19 AM, Simon Weller <swel...@ena.com> wrote:
>> 
>>> Congratulations Rafael!
>>> 
>>> - Si
>>> 
>>> 
>>> From: Nux! <n...@li.nux.ro>
>>> Sent: Thursday, April 28, 2016 7:06 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: Rafael Weingartner joining the PMC
>>> 
>>> Congrats Rafael :)
>>> 
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>> 
>>> Nux!
>>> www.nux.ro
>>> 
>>> - Original Message -
>>>> From: "Daan Hoogland" <daan.hoogl...@gmail.com>
>>>> To: "dev" <dev@cloudstack.apache.org>
>>>> Sent: Thursday, 28 April, 2016 11:59:28
>>>> Subject: Rafael Weingartner joining the PMC
>>> 
>>>> People,
>>>> 
>>>> The PMC has ask Rafael to join them to oversee the project and he has
>>>> gracefully accepted. Please join me in congratulating Rafael and wish
>> him
>>>> wisdom in his new task.
>>>> 
>>>> ​on behalve of the PMC,​
>>>> --
>>>> Daan
>>> 
>> 
> 
> --
> Rafael Weingärtner

Re: [ANNOUNCE] New committer: Simon Weller

[John Burwell]

Congrats, Simon.

> 
Regards,

John Burwell

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
On May 2, 2016, at 9:21 AM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote:
> 
> Congrats Simon.
> 
> Regards,
> Rohit Yadav
> 
> 
> Regards,
> 
> Rohit Yadav
> 
> rohit.ya...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> On Apr 28 2016, at 12:53 pm, Erik Weber <terbol...@gmail.com> wrote:
> 
> The Project Management Committee (PMC) for Apache CloudStack
> has asked Simon Weller to become a committer and we are pleased to
> announce that they have accepted.
> 
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch
> submission process. Whether contributions are development-related or
> otherwise, it is a recognition of a contributor's participation in the
> project and commitment to the project and the Apache Way.
> 
> Please join me in congratulating Simon
> 
> --Erik
> on behalf of the CloudStack PMC

Re: [DISCUSS] Emeritus Committer Status

[John Burwell]

Erik,

The following is the response I received from infra about managing emeritus 
committers:

commit bits are...binary bits, they can be 1 or they can be 0. We don’t
operate with trinary bits here, sorry

If you want to have emeritus committers, your best bet is to remove them
from the ldap group and keep a log in your pmc dir of their names.

So, we need to manage a separate list of emeritus committers.  Personally, I 
don’t find that too onerous as I doubt we will have people moving between 
active and emeritus very often.

Thanks,
-John

> 
Regards,

John Burwell

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
On Apr 20, 2016, at 6:11 AM, John Burwell <john.burw...@shapeblue.com> wrote:
> 
> Erik,
> 
> Good question about the mechanics.  I agree that removal of accounts would 
> not be correct.  It should only be the removal/suspension of the CloudStack 
> commit bit and karma.  In terms of LDAP, my (naive) expectation is that since 
> other projects have this status, infra already has a way to manage it.  I 
> will send an email to infra asking them how it is managed for other projects 
> and report back to dev@.
> 
> Thanks,
> -John
> 
>> 
> Regards,
> 
> John Burwell
> 
> john.burw...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
> On Apr 20, 2016, at 4:01 AM, Erik Weber <terbol...@gmail.com> wrote:
>> 
>> On Tue, Apr 19, 2016 at 11:42 PM, John Burwell <john.burw...@shapeblue.com>
>> wrote:
>> 
>>> All,
>>> 
>>> As I am sure many have observed, we have a large number of committers [1]
>>> who are no longer active.  Currently, we no status that continues to
>>> recognize someone’s committer merit while allowing them to declare inactive
>>> in the project.  To address this gap, I am proposed amending our project
>>> bylaws [2] as follows:
>>> 
>>> 
>> +1 to introduce emeritus status
>> 
>> 
>>> 2.3.4  A committer is considered "emeritus" by sending their declaration
>>> to priv...@cloudstack.apache.org<mailto:priv...@cloudstack.apache.org>.
>>> An emeritus committer may return to "active" status by sending their
>>> declaration to priv...@cloudstack.apache.org>> priv...@cloudstack.apache.org>.
>>> No vote is required for a committer change from “emeritus" to “active"
>>> status.
>>> 
>>> 
>> What exactly does going emeritus mean?
>> 
>> Removal of commit bit/access on the account? Disabling/removal of account?
>> I am -1 for the latter, as people might have used their apache.org email
>> address elsewhere or might be committers elsewhere disallowing us from
>> doing this, but I can be +1 for removing karma/commit bit.
>> 
>> 
>> 
>>> 2.3.5 "Active committters" are all non-emeritus committers.
>>> 
>>> These clauses were inspired by the Apache Cocoon [3] bylaws [4].  To be
>>> clear, a committer never loses their merit, and only a committer can decide
>>> to go emeritus.  Since merit is never lost, a emeritus committer may return
>>> to active status at anytime by simply informing the PMC of their intention
>>> to be active again.  No one can require that committer change to emeritus
>>> status.
>>> 
>>> On the website, we would place emeritus committers in a separate section —
>>> allowing users to more easily identify those that are actively
>>> participating in the project.
>>> 
>>> 
>> I am not sure how we keep this updated in an automated way. If we remove
>> emeritus members from the LDAP group, we have a way to fetch active ones,
>> but no way to fetch inactive/emeritus.
>> 
>> Haven't asked infra, but perhaps it could be possible to add an emeritus
>> ldap group or something like that
>> 
>> -- 
>> Erik
> 

Re: [DISCUSS] Emeritus Committer Status

[John Burwell]

Daan,

I disagree with automatically placing someone in emeritus status.  I think it 
is very important that some explicitly requests the status.

Thanks,
-John

> 
Regards,

John Burwell

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
On Apr 20, 2016, at 8:01 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:
> 
> Guys, one thing is to ping their apache known forwarding address if we
> suspect they are no longer active. Some might have still addresses of
> former employers listed and those are emeritus when found, if I may have
> that opinion.

Re: [DISCUSS] Emeritus Committer Status

[John Burwell]

Erik,

Good question about the mechanics.  I agree that removal of accounts would not 
be correct.  It should only be the removal/suspension of the CloudStack commit 
bit and karma.  In terms of LDAP, my (naive) expectation is that since other 
projects have this status, infra already has a way to manage it.  I will send 
an email to infra asking them how it is managed for other projects and report 
back to dev@.

Thanks,
-John

> 
Regards,

John Burwell

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
On Apr 20, 2016, at 4:01 AM, Erik Weber <terbol...@gmail.com> wrote:
> 
> On Tue, Apr 19, 2016 at 11:42 PM, John Burwell <john.burw...@shapeblue.com>
> wrote:
> 
>> All,
>> 
>> As I am sure many have observed, we have a large number of committers [1]
>> who are no longer active.  Currently, we no status that continues to
>> recognize someone’s committer merit while allowing them to declare inactive
>> in the project.  To address this gap, I am proposed amending our project
>> bylaws [2] as follows:
>> 
>> 
> +1 to introduce emeritus status
> 
> 
>> 2.3.4  A committer is considered "emeritus" by sending their declaration
>> to priv...@cloudstack.apache.org<mailto:priv...@cloudstack.apache.org>.
>>  An emeritus committer may return to "active" status by sending their
>> declaration to priv...@cloudstack.apache.org> priv...@cloudstack.apache.org>.
>>  No vote is required for a committer change from “emeritus" to “active"
>> status.
>> 
>> 
> What exactly does going emeritus mean?
> 
> Removal of commit bit/access on the account? Disabling/removal of account?
> I am -1 for the latter, as people might have used their apache.org email
> address elsewhere or might be committers elsewhere disallowing us from
> doing this, but I can be +1 for removing karma/commit bit.
> 
> 
> 
>> 2.3.5 "Active committters" are all non-emeritus committers.
>> 
>> These clauses were inspired by the Apache Cocoon [3] bylaws [4].  To be
>> clear, a committer never loses their merit, and only a committer can decide
>> to go emeritus.  Since merit is never lost, a emeritus committer may return
>> to active status at anytime by simply informing the PMC of their intention
>> to be active again.  No one can require that committer change to emeritus
>> status.
>> 
>> On the website, we would place emeritus committers in a separate section —
>> allowing users to more easily identify those that are actively
>> participating in the project.
>> 
>> 
> I am not sure how we keep this updated in an automated way. If we remove
> emeritus members from the LDAP group, we have a way to fetch active ones,
> but no way to fetch inactive/emeritus.
> 
> Haven't asked infra, but perhaps it could be possible to add an emeritus
> ldap group or something like that
> 
> -- 
> Erik

[DISCUSS] Emeritus Committer Status

[John Burwell]

All,

As I am sure many have observed, we have a large number of committers [1] who 
are no longer active.  Currently, we no status that continues to recognize 
someone’s committer merit while allowing them to declare inactive in the 
project.  To address this gap, I am proposed amending our project bylaws [2] as 
follows:

2.3.4  A committer is considered "emeritus" by sending their declaration to 
priv...@cloudstack.apache.org<mailto:priv...@cloudstack.apache.org>.
  An emeritus committer may return to "active" status by sending their 
declaration to 
priv...@cloudstack.apache.org<mailto:priv...@cloudstack.apache.org>.
  No vote is required for a committer change from “emeritus" to “active" status.

2.3.5 "Active committters" are all non-emeritus committers.

These clauses were inspired by the Apache Cocoon [3] bylaws [4].  To be clear, 
a committer never loses their merit, and only a committer can decide to go 
emeritus.  Since merit is never lost, a emeritus committer may return to active 
status at anytime by simply informing the PMC of their intention to be active 
again.  No one can require that committer change to emeritus status.

On the website, we would place emeritus committers in a separate section — 
allowing users to more easily identify those that are actively participating in 
the project.

Thoughts?
-John

[1]: http://cloudstack.apache.org/who.html
[2]: https://cloudstack.apache.org/bylaws.html
[3]: http://cocoon.apache.org/
[4]: 
http://code.metager.de/source/xref/apache/cocoon/commons/bylaws/bylaws.txt#14

Regards,

John Burwell

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue

Re: Introduction

[John Burwell]

Welcome to the community, Rashimi.

> 
Regards,

John Burwell

john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
On Apr 8, 2016, at 1:03 PM, Ahmad Emneina <aemne...@gmail.com> wrote:
> 
> Welcome Rashmi, look forward to seeing great contributions!
> 
> Ahmad E
> 
>> On Apr 7, 2016, at 9:58 PM, Rashmi Dixit <rashmi_di...@accelerite.com> wrote:
>> 
>> Hello!
>> 
>> I am Rashmi Dixit and have recently joined the CloudPlatform team in 
>> Accelerite. I have worked on a hybrid cloud management solution supporting 
>> hypervisors such as KVM, Xen, VMware, HyperV and public clouds such as EC2. 
>> My areas of interest are User Interface, networking.
>> 
>> I am really looking forward to contributing on CloudStack.
>> 
>> See you around!
>> Rashmi
>> 
>> Rashmi Dixit
>> Principal Product Engineer | CloudPlatform | www.accelerite.com
>> 
>> 
>> 
>> 
>> DISCLAIMER
>> ==
>> This e-mail may contain privileged and confidential information which is the 
>> property of Accelerite, a Persistent Systems business. It is intended only 
>> for the use of the individual or entity to which it is addressed. If you are 
>> not the intended recipient, you are not authorized to read, retain, copy, 
>> print, distribute or use this message. If you have received this 
>> communication in error, please notify the sender and delete all copies of 
>> this message. Accelerite, a Persistent Systems business does not accept any 
>> liability for virus infected mails.

Re: [VOTE] Move 'apache/cloudstack' -> 'apache-cloudstack/cloudstack'

[John Burwell]

+1 (binding)

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:  +44 (20) 3603 0542 | s: +1 (571) 403-2411 
<tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:  john.burw...@shapeblue.com | t: 
<mailto:john.burw...@shapeblue.com%20|%20t:> |  w:  
www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:image224cd5.png@37c44612.4baba82c]


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




On Mar 21, 2016, at 4:13 AM, Suresh Sadhu <suresh.sa...@accelerite.com> wrote:
>
> +1.
>
> Regards
> Sadhu
>
> -Original Message-
> From: Bharat Kumar [mailto:bharat.ku...@accelerite.com]
> Sent: Monday, March 21, 2016 11:57 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [VOTE] Move 'apache/cloudstack' -> 'apache-cloudstack/cloudstack'
>
> +1
> --Bharat
>
> On 21 Mar 2016 11:51 am, Kishan Kavala <kishan.kav...@accelerite.com> wrote:
> +1 for the move.
>
> Regards,
> Kishan Kavala
> Chief Product Engineer,
> CloudPlatform Development, Accelerite.
> www.accelerite.com<http://www.accelerite.com>
>
> -Original Message-
> From: chunfeng tian [mailto:tianyunqu...@gmail.com]
> Sent: 20 March 2016 05:22 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Move 'apache/cloudstack' -> 'apache-cloudstack/cloudstack'
>
> +1
>
> On Sun, Mar 20, 2016 at 1:51 PM, Mattmann, Chris A (3980) < 
> chris.a.mattm...@jpl.nasa.gov> wrote:
>
>> +1..
>>
>> ++
>> Chris Mattmann, Ph.D.
>> Chief Architect
>> Instrument Software and Science Data Systems Section (398) NASA Jet
>> Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 168-519, Mailstop: 168-527
>> Email: chris.a.mattm...@nasa.gov
>> WWW: http://sunset.usc.edu/~mattmann/
>> ++
>> Director, Information Retrieval and Data Science Group (IRDS) Adjunct
>> Associate Professor, Computer Science Department University of
>> Southern California, Los Angeles, CA 90089 USA
>> WWW: http://irds.usc.edu/
>> ++
>>
>>
>>
>>
>>
>> -Original Message-
>> From: Will Stevens <williamstev...@gmail.com>
>> Reply-To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
>> Date: Friday, March 18, 2016 at 3:44 PM
>> To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
>> Subject: [VOTE] Move 'apache/cloudstack' -> 'apache-cloudstack/cloudstack'
>>
>>> We are discussing this proposal in 3 or 4 threads, so I will not try
>>> to recap everything. Instead I will try to give a brief overview of
>>> the problem and a proposal for solving it.
>>>
>>> *Problem:*
>>> The Apache CloudStack community needs additional github permissions
>>> in order to integrate CI for the purpose of maintaining code quality.
>>> The ASF does not have enough granular control via the 'apache' github
>>> organization to give the 'apache/cloudstack' repository the needed
>>> permissions.
>>>
>>> *Proposal:*
>>> Transfer ownership of the 'apache/cloudstack' mirrored repository out
>>> of the 'apache' github organization into the 'apache-cloudstack'
>>> github organization (which I have already setup and started inviting users 
>>> to).
>>> Both members of the ACS community and the ASF board will have 'owner'
>>> permissions on this new organization. This will allow for
>>> permissions to be applied specifically to the 'apache-cloudstack'
>>> orga

Re: [IMPORTANT] Huge Github PR Backlog

[John Burwell]

All,

While I am stating the obvious, but we must remember that commit/PR flow is the 
lifeblood our community. Over the past the month, there have been zero 
contributions to master [1] against 180 open PRs. As Simon points out, the 
longer the PR sits, the farther it diverges — increasing the risk that the 
submitter will give up and we will lose valuable work. It is also very 
difficult to cultivate new contributors if their PRs are not addressed in a 
timely manner.

While I think the work being done on CI is extremely valuable and vital in the 
long term, it seems appropriate that we decouple it from PR review and merge. 
Looking through the wiki, we have great instructions on the mechanics of 
properly merging a PR [2], but it provides little guidance about the steps to 
be performed to complete a PR review. Fleshing out these guidelines will not 
only provide us with a manual process we can use until a CI infrastructure is 
available, it will also allow us to verify the process implement by CI. 
Currently, we require 2 LGTM votes — at least one for code review and at least 
one for testing. To my mind, a code review LGTM should include successfully 
passing the following items:

1. Verifying the branch passes all static analysis checks (currently checked by 
Travis)
2. Verifying the branch passes all unit tests (currently checked by Travis)
3. Manual inspection of the code for issues such as architectural and class 
design issues, Java best practices, concurrency problems, and unit test 
completeness
4. Any new Maven dependencies in redist modules have a license compatible with 
the ASL, have no open CVEs, and do not unnecessarily duplicate functionality of 
an existing dependency

For a test LGTM, the branch should be checked out and verified to run. In 
addition to running tests, the PR should be review to ensure that it updates 
existing Marvin tests and/or adds new Marvin test cases to cover the changes. 
It should then pass any Marvin tests added or modified for the change, as well 
as, all unit tests. I think it would be beneficial to identify the set 
acceptance tests that should pass dependent on the nature of the PR. For 
example, if a PR affects KVM, there should be a basic set of tests that should 
pass in order to the PR to be merged to master. Ideally, we would run all 
tests. Unfortunately, the entire suite takes ~7 hours to run making it 
impractical to run for every test. Hopefully, with the CI infrastructure and 
test improvements, it will eventually become feasible. The following are the 
acceptance test impact areas that come to mind:

1. Core (always run no matter what the change)
2. KVM
3. VMWare
4. XenServer
5. Basic Networking
6. Advanced Networking/VR
7. NFS
8. iSCSI
9. VPC

These categories may not be the best or there may be more. Initially, I would 
propose simply listed them in the wiki or providing a simple script. We can 
then go back and take the time to update the category(ies) in Marvin. The goal 
is to ensure we consistently test PRs and we set clear/realistic expectations 
for contributors. It also far more likely that contributors will run these 
tests in advance if they it is clearly explained which tests should pass.

I am willing to take up the effort to update the wiki with the process, as well 
as, working through the acceptance test lists. I need feedback on an initial 
list of categories — I think erring towards too few rather too many would be a 
wise approach. With that information, I will expand the existing topic to 
include the testing information, as well as, the code review expectations.

While I believe it will be very helpful to flesh the PR review process, I don’t 
think any of these steps should hold back PR review. As Remi pointed out (and 
did as release manager), code reviewing and running a base set of Marvin tests 
would be an excellent starting point to start getting the flow moving 
immediately. We can apply the improvements from CI and expanded review 
guidelines as they become available.

Thanks,
-John

[1]: 
https://github.com/apache/cloudstack/graphs/contributors?from=2016-02-15=2016-03-18=c
[2]: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61311655

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:  +44 (20) 3603 0542 | s: +1 (571) 403-2411 
<tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:  john.burw...@shapeblue.com | t: 
<mailto:john.burw...@shapeblue.com%20|%20t:> |  w:  
www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:image126380.png@e29adf1a.4a908ea2]


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

Re: External fork of Cloudstack (was Re: [GitHub] cloudstack pull request: Is the project attempting a fork on Githu...)

[John Burwell]

All,

+1 to Will’s proposal/approach. All we are really talking about is rehoming the 
apache/cloudstack repository mirror to cloudstack/cloudstack. The canonical 
repository would remain the official Apache git repository hosted on Apache 
owned hardware. Therefore, we would maintain our current PR merge process [1] 
that merges the PR branch locally and pushes it to the Apache git repository. 
If re-home the Github mirror, I think it should remain read-only mirror where 
we have the ability to grant privileges to our CI system to close PRs.

I would also add that currently, the cloudstack organization is owned by 
individuals who happen to be Apache CloudStack PMC members and committers. In 
my opinion, in order for it to work in the long term, we would need a 
governance policy that transferred ownership to our PMC or Apache Infra. Our 
interest is not the create a fork, but provide our community with the ability 
to exploit an extremely powerful tool for collaboration and source management.

Finally, I believing having a dedicated cloudstack Github organization may be a 
means to expand the community. Currently, we have no place to easily host 
subprojects (e.g. cloudmonkey, marvin, etc). With a dedicated organization, we 
could consider inviting other complementary projects such configuration 
management recipes/playbooks and language clients to place their repos in the 
cloudstack organization. For users, they would have a central, community 
sponsored place to find all things cloudstack and we further improve our 
collaboration with the authors/maintainers of these projects.

In short, I think Will lays out the approach very clearly. There is **no** 
intention or action to fork Apache CloudStack. Instead, we simply want to 
re-home apache/cloudstack repository mirror to cloudstack/cloudstack without 
changing any other processes. Most importantly, this change can be made without 
compromising the provenance of the codebase because, as we do today, commits 
would only occur on the Apache git repo.

Thanks,
-John

[1]: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61311655

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:  +44 (20) 3603 0542 | s: +1 (571) 403-2411 
<tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:  john.burw...@shapeblue.com | t: 
<mailto:john.burw...@shapeblue.com%20|%20t:> |  w:  
www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:image6929de.png@d359d3b7.49a57074]


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




On Mar 18, 2016, at 3:40 AM, Sebastien Goasguen <run...@gmail.com> wrote:
>
> Top posting because keeping track is going to be hard.
>
>
> Remi and I have talked several times with David about GitHub access and so 
> far the answer has been no.
>
> There are several issues in my understanding:
>
> - apache on github is one single org, so if you get some write permission in 
> the org then you could potentially harm other projects. that means that ASF 
> needs to figure out how to use github teams to map our projects inside a 
> single org (follow me…). They appear to be working on it, but no ETA on when 
> this will happen.
>
> - location of the canonical repo. This in large a legal issue. If CloudStack 
> were sued at some point, can we prove without doubt who made the commit. 
> Until now, ASF has the canonical repo on its own hardware which means all 
> sorts of logs including push logs. Some folks at the ASF think that with a 
> project on github they would not get the same level of guaranteed provenance. 
> ( I have tried to argue about it, some folks don’t think it is an issue, but 
> others do).
>
>
> The bottom line for me:
>
> -We are the ASF, the board is there for guidance but we, the communities and 
> the ASF members need to tell the board what we need/want.
>
> -I want github, I am heari

Re: [PROPOSAL] Minimum Viable CI Integration

[John Burwell]

Will,

Will this request grant us all of the permissions we need to manage the flow 
PRs automatically? If we cannot get the access we require, could we propose to 
and vote as a community for a new Github organization (e.g. cloudstack) which 
is owned and controlled by our community?

Thanks,
-John

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:  +44 (20) 3603 0542 | s: +1 (571) 403-2411 
<tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:  john.burw...@shapeblue.com | t: 
<mailto:john.burw...@shapeblue.com%20|%20t:> |  w:  
www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:imaged5a9b6.png@1320cd79.4b95e882]


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




On Mar 10, 2016, at 6:03 PM, Will Stevens <wstev...@cloudops.com> wrote:
>
> I have made the request. Here is the Jira ticket:
> https://issues.apache.org/jira/browse/INFRA-11429
>
> Here is the content of the request...
>
> ---
>
> This request is for personal access tokens with the following permission be
> added to the https://github.com/apache/cloudstack repository in order for
> the apache cloudstack community to be able to implement Continuious
> Integration.
>
> Permission: (https://github.com/settings/tokens)
> - `repo:status` - Grants read/write access to public and private repository
> commit statuses. This scope is only necessary to grant other users or
> services access to private repository commit statuses without granting
> access to the code.
>
> With this permission the token owner will be able to view the
> apache/cloudstack repo and will be able to create and update the status of
> a pull request. This is the same type of permission used by the current
> TravisCI integration, but will allow the community to feedback the status
> of distributed CI runs on physical hardware. Here is more detail on the
> Status functionality: https://developer.github.com/v3/repos/statuses/
>
> We would like the following apache/cloudstack community members be sent
> their own personal access tokens since they will be providing physical
> hardware for doing CI for apache/cloudstack and would like the results of
> these CI runs to be posted back to the community so the release managers on
> the project can better assess the impact of the different pull requests.
>
> Will Stevens <wstev...@cloudops.com>
> Paul Angus <paul.an...@shapeblue.com>
> Bharat Kumar <bharat.ku...@accelerite.com>
> Remi Bergsma <rberg...@schubergphilis.com>
>
> By providing each individual their own access token, you maintain fine
> grain control of their access to modify pull request statuses from their CI
> and you can revoke individual tokens if there is ever a concern.
>
> Some more context around this request...
>
> The Apache CloudStack community has been struggling with code quality
> issues due to the lack of CI and the wide breadth of features. Because of
> the scale of the project, no single organization or community member has
> the hardware to fully test the extent of the functionality provided by the
> product. This in combination with the attempt to increase the release
> cadence, the lack of full CI coverage is becoming a painful reality.
>
> I have developed a very simple CLI tool called `upr` (
> https://github.com/swill/upr) which can be easily integrated into any CI
> implementation used by the different organizations/individuals to post back
> the status of their CI runs to the community.
>
> Please feel free to engage with us on the dev@cloudstack.apache.org mailing
> list if anything is unclear or if you have questions.
>
> ---
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *

Re: [PROPOSAL] LTS Release Cycle

[John Burwell]

Rene,

I apologize for lag in my reply — I have been a bit consumed by the $dayjob 
lately.

At any given time, the two most recent LTS releases receive full support (back 
port of blocker/critical fixes + CVE patches). The oldest LTS release only 
receives CVE patches. Given the infrequency of CVE patches, there would very 
little effort required for the oldest LTS release. I will update the proposal 
to change the active number from 2 to 3. However, in terms of effort, the 2 
most recent releases will represent the nearly all of the LTS effort. The 
primary motivation for having the third overlapping LTS release is to provide 
users that require longer update cycles (e.g. 18 months) a bridge to upgrade.

Thanks,
-John

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:  +44 (20) 3603 0542 | s: +1 (571) 403-2411 
<tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:  john.burw...@shapeblue.com | t: 
<mailto:john.burw...@shapeblue.com%20|%20t:> |  w:  
www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:imagece4572.png@b6bb1072.42b186b6]


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




On Feb 8, 2016, at 5:46 AM, Rene Moser <m...@renemoser.net> wrote:
>
> John,
>
> Something is not clear to me about the frequency of new LTS releases and
> support time range.
>
> You wrote in the proposal, that we branch off for a new LTS version 2
> times a year, but only 2 LTS versions will in active maintained at any
> time, but supported for 20 months.
>
> This conflicting in my mind.
>
> This means we do not branch off _every_ year twice? Otherwise we would
> have 3 releases within 12 months 1.1/1.7/1.1. And the support will be
> only ~13 months for max as we do not maintain 3 releases.
>
> What I am missing?
>
> René
>
>
> On Tue, 02 Feb 2016 16:40:42 GMT, John wrote:
>> All,
>>
>> Based on the feedback from Ilya, Erik, and Daan, I have updated my
>> original LTS proposal to clarify that LTS releases are official project
>> deliverables, commit traceability across branches, and RM approval of PRs:
>>
>> ## START ##
>>
>> Motivation
>> ==
>>
>> The current monthly release cycle addresses the needs of users focused
>> on deploying new functionality as quickly as possible. It does not
>> address the needs of users oriented towards stability rather than new
>> functionality. These users typically employ QA processes to comply with
>> corporate policy and/or regulatory requirements. To maintain a growing,
>> thriving community, we must address the needs of both user types.
>> Therefore, I propose that we overlay a LTS release cycle onto the
>> monthly release cycle to address the needs of stability-oriented users
>> with minimal to no impact on the monthly release cycle. This proposed
>> LTS release cycle has the following goals:
>>
>> * Prefer Stability to New Functionality: Deliver releases that only
>> address defects and CVEs. This narrowly focused change scope greatly
>> reduces the upgrade risk/operational impact and shorter internal QA cycles.
>> * Reliable Release Lifetimes: Embracing a time-based release strategy,
>> the LTS release cycle will provide users with a reliable support time
>> frames. Users can use these time frames provide users with an 20 month
>> window in which to plan upgrades.
>> * Support Sustainability: With a defined end of support for LTS
>> releases and a maximum of two (2) LTS releases under active maintenance
>> at any given time, community members can better plan their commitments
>> to release support activities. We also have a agreed upon policy for
>> release end-of-life (EOL) to debate about continuing work on old releases.
>>
>> LTS rele

Re: Results of a IPv6 brainstorm day

[John Burwell]

Wido,

Curious if you have been able to make any progress on this work. Have you been 
able to move it forward? If not, what kind of help would you need?

Thanks,
-John

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:  +44 (20) 3603 0542 | s: +1 (571) 403-2411 
<tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:  john.burw...@shapeblue.com | t: 
<mailto:john.burw...@shapeblue.com%20|%20t:> |  w:  
www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:imagefbc38a.png@a8508906.4c973695]


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




On Dec 22, 2015, at 5:17 AM, Wido den Hollander <w...@widodh.nl> wrote:
>
>
>
> On 12/22/2015 04:35 AM, Ian Rae wrote:
>> Great to hear, next time I am happy to commit an engineer from CloudOps to
>> participate. We have done quite a bit of work around VPC and also need to
>> solve for IPv6 soon.
>>
>> Thanks for sharing, great initiative/goal and I will make sure the CloudOps
>> team reviews and supports this.
>>
>
> Great! The first challenge will be to get the core of ACS aware of IPv6.
> Pass IP addresses is InetAddress instead of a String, etc, etc.
>
> I don't know if a very big team can work on this without very short
> communication between the different people.
>
> But again, any help is appreciated! We need this to go in.
>
> Wido
>
>> On Friday, December 18, 2015, Wido den Hollander <w...@widodh.nl> wrote:
>>
>>> Hi,
>>>
>>> Yesterday we from PCextreme, Leaseweb and Schuberg Phillis sat down for
>>> a IPv6 brainstorm session.
>>>
>>> We asked a good IPv6 consultant (Sander Steffann) to join us to help us
>>> identify some glitches in our ideas.
>>>
>>> We had two ideas:
>>> -
>>>
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
>>> -
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+VPC+Router
>>>
>>> Overall, our ideas looked good, our main concern was security grouping.
>>> How to prevent clients from spoofing and such.
>>>
>>> I updated the spec for the Basic Networking with those ideas.
>>>
>>> A few things worth noting:
>>> - Link-Local traffic should be allowed for specific ICMPv6-only. No UDP
>>> or TCP!
>>> - A DUID can not be trusted. We need a tagger on the HV which adds the
>>> MAC address as DHCPv6 option 37.
>>> - SLAAC can not be used. DHCPv6+IA only
>>> - We can assign multiple IPs and Prefixes via DHCPv6
>>> - ISC Kea seems very nice as a DHCPv6 server: http://kea.isc.org/wiki
>>>
>>> A few RFCs which might be worth reading:
>>> - https://www.ietf.org/rfc/rfc4890.txt
>>> - https://tools.ietf.org/html/rfc6939
>>> - https://tools.ietf.org/html/rfc4861
>>>
>>> We will start to work on this, but the CloudStack core is still very,
>>> very, very IPv4 minded and this will need a lot of refactoring.
>>>
>>> However, once you understand IPv6 better it is much more simple then
>>> IPv4 imho.
>>>
>>> The end goal is that CloudStack can run on IPv6-only without ANY IPv4.
>>>
>>> What also resulted from this day:
>>> - Basic Networking can probably be merged with Advanced Networking with
>>> Direct Attached
>>> - Isolated Networks are about the same as a VPC
>>> - We might be able to ditch the SSVM in most situations
>>>
>>> Any way, enough work to do!
>>>
>>> Wido
>>>
>>
>>

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

Re: [PROPOSAL] LTS Release Cycle

[John Burwell]

All,

Based on the feedback from Ilya, Erik, and Daan, I have updated my original LTS 
proposal to clarify that LTS releases are official project deliverables, commit 
traceability across branches, and RM approval of PRs:

## START ##

Motivation
==

The current monthly release cycle addresses the needs of users focused on 
deploying new functionality as quickly as possible.  It does not address the 
needs of users oriented towards stability rather than new functionality.  These 
users typically employ QA processes to comply with corporate policy and/or 
regulatory requirements.  To maintain a growing, thriving community, we must 
address the needs of both user types.  Therefore, I propose that we overlay a 
LTS release cycle onto the monthly release cycle to address the needs of 
stability-oriented users with minimal to no impact on the monthly release 
cycle.  This proposed LTS release cycle has the following goals:

  * Prefer Stability to New Functionality: Deliver releases that only address 
defects and CVEs.  This narrowly focused change scope greatly reduces the 
upgrade risk/operational impact and shorter internal QA cycles.
  * Reliable Release Lifetimes: Embracing a time-based release strategy, the 
LTS release cycle will provide users with a reliable support time frames.  
Users can use these time frames provide users with an 20 month window in which 
to plan upgrades.
  * Support Sustainability: With a defined end of support for LTS releases and 
a maximum of two (2) LTS releases under active maintenance at any given time, 
community members can better plan their commitments to release support 
activities.  We also have a agreed upon policy for release end-of-life (EOL) to 
debate about continuing work on old releases.

LTS releases would be official project releases.  Therefore, they would be 
subject to same release voting requirements and available from the project 
downloads page.

Proposed Process


LTS release branches will be cut twice year on 1 Jan and 1 July based the tag 
of the most recent monthly release.  The branch will be named _LTS and each LTS release will be versioned in the form of _.  For example, if we cut an LTS branch based on 
4.7.0, the branch would be named 4.7.0_LTS and the version of the first LTS 
release would be 4.7.0_0, the second would be 4.7.0_1, etc.  This release 
naming convention differentiates LTS and monthly releases, communicates the 
version on which the LTS release is based, and allows the maintenance releases 
for monthly releases without version number contention/conflict.  Finally, like 
master, an LTS branch would be always deployable following its initial release. 
 While it is unlikely that LTS users would deploy from the branch, the quality 
discipline of this requirement will benefit the long term stability of LTS 
releases.  Like master, all PRs targeting an LTS branch would require two LGTMs 
(one code review and one independent test), as well as, an LGTM from the branch 
RM.  A combined code review/test LGTM and an RM LGTM would be acceptable.

The following are the types of changes that would permitted and guarantees 
provided to users:

  * No features or enhancements would be backported to LTS release branches.
  * Database changes would be limited to those required to address the 
backported defect fixes.
  * Support for the release/version of the following components from the 
release on which the LTS is based throughout the entire release cycle:
* MySQL/MariaDB
* JDK/JRE
* Linux distributions
  * API compatibility for between all LTS revisions.  API changes would be 
limited to those required to fix defects or address security issues.

An LTS release would have a twenty (20) month lifetime from the date the 
release branch is cut.  This support period allows up to two (2) months of 
branch stabilization before initial release with a minimum of eighteen (18) 
months of availability for deployment.  The twenty (20) month LTS lifecycle 
would be divided into following support periods:

  * 0-2 months (average): Stablization of the LTS branch with fixes based on 
defects discovered from functional, regression, endurance, and scalability 
testing.
  * 2-14 months: backport blocker and critical priority defect fixes in the 
scope of the LTS branch functionality; fix all blocker and critical priority 
defects identified on the LTS branch
  * 14-20 months: backport only CVE fixes in the scope of the LTS branch 
functionality; fix all blocker priority defects identified on the LTS branch

Defect fixes that originate in an LTS branch would be pulled forward to master 
only.  Finally, an LTS branch should be release the fewest times necessary to 
deliver fixes in a relatively timely manner.  Therefore, LTS releases will be 
triggered based on the number of pending of fixes and their severity with no 
defect fix awaiting release more than forty-five (45) days.  CVE fixes would 
trigger the immediate release of 

Re: Quick note about $dayjob

[John Burwell]

Sebastian,

Thank you for your years of dedication and leadership. Best of luck with the 
new company — may many unicorns be in your future.

Thanks,
-John

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:  +44 (20) 3603 0542 | s: +1 (571) 403-2411 
<tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:  john.burw...@shapeblue.com | t: 
<mailto:john.burw...@shapeblue.com%20|%20t:> |  w:  
www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:imagebbb2c0.png@aa835779.42873b70]


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




On Jan 26, 2016, at 7:57 PM, Ian Rae <i...@cloudops.com> wrote:
>
> See - thanks for all your service, hard work, patience and above all,
> collaboration!!!
>
> On Tue, Jan 26, 2016 at 9:30 AM, Sebastien Goasguen <run...@gmail.com>
> wrote:
>
>> Hi folks,
>>
>> As some of you might have guessed I am changing $dayjob.
>>
>> This is an exciting time for me, but it also means that I will become less
>> involved with CloudStack. ( I said *less* involved, did not say I was going
>> to disappear). I have informed the PMC and offered to stop my VP role ahead
>> of the March deadline. As you know we have a one-year rotation for the VP
>> role. However if the PMC does not see a problem with it I will gladly
>> continue until March.
>>
>> I will keep this brief but I wanted to let you know so that you don’t
>> wonder why my involvement in recent releases and votes has decreased.
>>
>> It is an exciting time for CloudStack as well, with ever greater releases
>> ( in large part to Remi, Wilder and a few others), a strong proposal to
>> offer LTS and the commitment from Accelerite.
>>
>> Change is good, challenges are opportunities says Sensei Wu from Ninjago :)
>>
>> PS:
>> If you wonder, I am launching my own container startup called Skippbox. I
>> will grant myself a shameless plug, and if you know anyone interested in
>> containers and kubernetes I sure could use some help (
>> https://github.com/skippbox , http://www.skippbox.com/blog/), github
>> stars and PRs :)
>>
>> Cheers,
>>
>> -Sebastien
>
>
>
>
> --
> Ian Rae
> CEO | PDG
> c: 514.944.4008
>
> CloudOps | Cloud Infrastructure and Networking Solutions
> www.cloudops.com | 420 rue Guy | Montreal | Canada | H3J 1S6

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

Re: [DISCUSSION] Collab for Spring 2016

[John Burwell]

All,

+1 to a collab in Montreal. I like the idea of 2-3 days of coding organized as 
a series of birds-of-feather type sessions. People post 
features/enhancements/topics of interest for a particular area, and those that 
are interested join them to hack through it. No slides to prepare, no passive 
sessions — active collaboration and coding.

Thanks,
-John

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:  +44 (20) 3603 0542 | s: +1 (571) 403-2411 
<tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:  john.burw...@shapeblue.com | t: 
<mailto:john.burw...@shapeblue.com%20|%20t:> |  w:  
www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:image744ef9.png@76a420d2.4c9c9c5b]


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




On Jan 27, 2016, at 4:56 AM, Raja Pullela <raja.pull...@citrix.com> wrote:
>
> +1 for the two day collab - a day of hackathon and a day of meetings/events.
>
> -Original Message-
> From: ilya [mailto:ilya.mailing.li...@gmail.com]
> Sent: Wednesday, January 27, 2016 2:34 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSSION] Collab for Spring 2016
>
> +1 on North America Collab, Montreal is awesome :)
>
> I dont think i will get a trip sponsored to Brazil (too much liability).
>
>
>
> On 1/26/16 11:50 AM, Ian Rae wrote:
>> Happy to host in Montreal. We should have enough space at our offices,
>> and I have some other locations we could use if we are more than 100.
>>
>> Ian
>>
>> On Mon, Jan 18, 2016 at 5:01 PM, Will Stevens <wstev...@cloudops.com> wrote:
>>
>>> I like this idea as well because it gets more of the participants
>>> focusing on the actual code. I think it will make the hackathon more
>>> useful for the project this way.
>>>
>>> *Will STEVENS*
>>> Lead Developer
>>>
>>> *CloudOps* *| *Cloud Solutions Experts
>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw
>>> @CloudOps_
>>>
>>> On Mon, Jan 18, 2016 at 4:53 PM, Mike Tutkowski <
>>> mike.tutkow...@solidfire.com> wrote:
>>>
>>>> So you're thinking a Hackathon day and a day of presentations?
>>>>
>>>> That seems reasonable.
>>>>
>>>> On Monday, January 18, 2016, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>>>>
>>>>> 2 days or more so we could have an hackathon or a day where we
>>>>> could
>>>> spend
>>>>> collaborative time working on cloudstack ?
>>>>> I liked the hackathon of previous events but they were usually
>>>>> during
>>>> time
>>>>> of interesting talks so I think it would be nice to split them but
>>>> within
>>>>> the same event.
>>>>>
>>>>> PL
>>>>>
>>>>>
>>>>> On Mon, Jan 18, 2016 at 1:52 PM, Mike Tutkowski <
>>>>> mike.tutkow...@solidfire.com <javascript:;>> wrote:
>>>>>
>>>>>> I'd be interested in a couple events this year pretty much
>>>>>> wherever
>>>> they
>>>>>> are. I have a couple ideas for new presentations that I think will
>>>>>> be
>>>> of
>>>>>> interest to people.
>>>>>>
>>>>>> It's typically easier for me to get permission for longer-distance
>>>> trips
>>>>> if
>>>>>> the event is longer (I expect that is common). We might want to
>>>> consider
>>>>>> two-day events for these get-togethers this year.
>>>>>

Re: [ANNOUNCE] New PMC member: Boris Roman Schrijver

[John Burwell]

Congrats and welcome, Boris.

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:  +44 (20) 3603 0542 | s: +1 (571) 403-2411 
<tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:  john.burw...@shapeblue.com | t: 
<mailto:john.burw...@shapeblue.com%20|%20t:> |  w:  
www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:imagedbd90a.png@e024ae47.4c87aa38]


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




On Jan 21, 2016, at 9:15 AM, Suresh Sadhu <suresh.sa...@citrix.com> wrote:
>
> Congrats Boris!!
>
> On 1/19/16 4:15 AM, Wilder Rodrigues wrote:
>> The Project Management Committee (PMC) for Apache CloudStack is
>> pleased to announce that Boris Roman Schrijver has accepted our invitation 
>> to join the PMC.
>>
>> Please join me in congratulating him.
>>
>> On behalf of the Apache CloudStack PMC Wilder Rodrigues
>>

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

Re: disable github notifications ?

[John Burwell]

All,

+1 to keeping the notifications coming to dev@ as it is the hub and record of 
all project development activity. A simple mail filter helps me sort out the 
notification traffic from general conversation. My filters send any message 
containing my username (@jburwell) directly to my inbox — further helping me 
prioritize notifications.

Thanks,
-John

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:  +44 (20) 3603 0542 | s: +1 (571) 403-2411 
<tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:  john.burw...@shapeblue.com | t: 
<mailto:john.burw...@shapeblue.com%20|%20t:> |  w:  
www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:imaged5e496.png@17f3c447.499eff8a]


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




On Jan 27, 2016, at 7:00 PM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:
>
> I'm with Remi on this
>
> Biligual auto correct use. Read at your own risico
> Op 27 jan. 2016 5:15 PM schreef "Remi Bergsma" <rberg...@schubergphilis.com
>> :
>
>> I say we keep the notifications. GitHub is about development and this is
>> the dev list, right? It really helps keeping track of what is going on.
>> It's way faster than clicking all PRs in GitHub IMHO.
>>
>> Any email client since the 1990s can do mail filtering so if it's too
>> much, simply filter it to another folder.
>>
>> Regards, Remi
>>
>>
>> Sent from my iPhone
>>
>>> On 27 Jan 2016, at 16:00, sebgoa <run...@gmail.com> wrote:
>>>
>>> Hi folks,
>>>
>>> Shall we disable github notifications to dev@ ?
>>>
>>> It has become quite noisy.
>>>
>>> On the other end you see all the comments fly by...
>>>
>>> -sebastien
>>

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

Re: [PROPOSAL] LTS Release Cycle

[John Burwell]

All,

LTS branches will be maintained for 20 months. In that time, some defects will 
be fixed in an LTS branch and forward merged. Some defects will be identified 
in master, and we will need to determine whether or not they should be pulled 
back to one or more of the active LTS branches. As master evolves, there will 
not always be a straight line from LTS to master. Requiring a direct path 
between LTS branches and master would either severely constrain the development 
of master or compromise the stability expected by LTS users. We should also not 
assume that all backports will be merges/cherry picks — some will be 
re-implementations due to divergence over time. Like the Ubuntu and Red Hat 
maintenance cycles, the proposal places the burden of determining the best 
approach to defect backporting on LTS maintainers to avoid impacting the 
velocity of feature development. While we should prefer fixing in LTS merging 
forward, the reality is that maintaining long running maintenance branches will 
require some cherry picking and re-implementation of defects due to the length 
of the support window.

It’s also important to note I propose only pulling back blockers and critical 
severity defects within the scope of the LTS’ functionality from master. The 
goal of LTS is not to fix every defect. It is to fix those defects that impact 
system stability or severely degrade functionality. Previously, we conflated 
feature development and maintenance into a single set of release branches using 
the same release cycle. With the monthly releases, users have a path to acquire 
new functionality independent of bug fix/maintenance efforts — removing 
potential justification to pull back new features or enhancements. As we have 
discussed this proposal, I think it should be amended to require that all PRs 
to an LTS branch include an LGTM from the LTS branch RM to ensure that only 
defects that fit within the narrowly defined constraints.

Based on our history, I share your concerns about cherry picking abuse, and 
have attempt to design the proposal to address them. I believe that the tighter 
constraints on the defects that are allowed to be backported, a clearly defined 
policy about the LTS release cycle schedule, and monthly releases will allow us 
to avoid the mistakes of the past.

Thanks,
-John

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:  +44 (20) 3603 0542 | s: +1 (571) 403-2411 
<tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:  john.burw...@shapeblue.com | t: 
<mailto:john.burw...@shapeblue.com%20|%20t:> |  w:  
www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:imagefafe75.png@d43a0b58.41a20f1c]


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




On Jan 19, 2016, at 6:14 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:
>
> Jeff, That we did before. I don't think that's good enough. It must be the
> same commit as far as I'm concerned. Any conflict will be made explicit in
> a merge commit that way.
>
> On Tue, Jan 19, 2016 at 12:08 PM, Jeff Hair <j...@greenqloud.com> wrote:
>
>> Maybe require all cherry-picks to use the -x option, which puts the
>> original commit hash in the cherry-picked commit message?
>>
>> On Tue, Jan 19, 2016 at 10:53 AM, Remi Bergsma <
>> rberg...@schubergphilis.com>
>> wrote:
>>
>>> On a certain night when a release had been cut and there was some worry
>>> about a security fix not being included. The root cause was that we
>>> cherry-picked that fix and as a result its commit hash had changed. Hence
>>> we couldn’t find it.
>>>
>>> I’d recommend using forward merging instead of back porting aka
>>> cherry-picking, so the commit hashes stay the same and fixes are easily
>>> traceable.
>>>
>>> Just my $0.02.
>>>
>>> Regards,
>

Re: [DISCUSS][PROPOSE] use of optional instead of null

[John Burwell]

Daan,

The problem lies within Java itself and the decision not to allow for typed 
nulls.  Therefore, writing safe code requires a certain degree null checking.   
There are also circumstances where a null is the correct representation.  For 
example, there are optional numeric values who can only be properly represented 
by null when they are not defined.  I think the following would be a good start 
towards achieving the goal of not returning null:

1. For strings, return blank (i.e. “”) for the missing case
2. For collections, return an empty representation (e.g. 
Collections.emptySet(), Collections.emptyList(), etc)
3. Introduce a Nullable interface and create null implementation of 
classes we control
4. For enumerations, provide a NONE value for the missing case

In my experience, one of the best ways to reduce null issues is to implement 
argument checking, particularly on constructors using Guava’s 
Preconditions.checkArgument.  Not only does it help ensure that inputs to 
classes fit the expected constraints, but it fails early — easing the root 
cause identification.

Thanks,
-John

> On Jan 17, 2016, at 8:20 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:
>
> Thanks John, I agree that the solution from your gist is a good one in
> several circumstances as well. It doesn't completely invalidate both other
> solutions completely, though.
> so now we have three
> 1. exceptions instead of nulls
> 2. optionals
> 3. nullables
>
> Not sure how to continue from here, except that I think we need to remove
> all null returns where objects are expected.
>
>
> On Sat, Jan 16, 2016 at 1:56 PM, John Burwell <john.burw...@shapeblue.com>
> wrote:
>
>> Daan,
>>
>> I completely agree that returning null is bad. Not only does it yield a
>> ton of useless null checks, it creates leaky abstractions by spreading the
>> handling of the missing case out beyond the boundary of the class/subsystem.
>>
>> As a big proponent of the Null Object Pattern [1], I really wanted to like
>> Optional. It is a great concept in functional languages. So, I tried using
>> it in three (3) different projects since 2011. In all three systems, I
>> would say that, at best, it was no better than returning null, and, in
>> other cases, worse. Since Optional.get throws an exception when the wrapped
>> value is null, all optional accesses must be defensively checked so the
>> code base is littered with code like the following:
>>
>> if (value.isPresent()) {
>> return value.get();
>> }
>>
>> So, basically, you end up replacing null checks and NPEs with isPresent
>> checks and a Guava exception. As a bonus, when exceptions occurred in
>> production, we had explain the meaning of them. The quickest explanation —
>> “They are the new NPE”. For all new developers on the projects, we had one
>> more thing to explain to them which, again, was asking them to do something
>> differently with no added value. Based on these experiences, I prefer null
>> checks to optional.
>>
>> While it is more effort (i.e. more code), I have gone back to using the
>> Null Object Pattern implemented in this manner [2]. Not only does this
>> approach avoid NPEs, it also explicitly defines the behavior for the
>> missing case. For more complex examples, it can be unit tested to ensure
>> the missing case behaves as expected.
>>
>> Thanks,
>> -John
>>
>> [1]: https://en.wikipedia.org/wiki/Null_Object_pattern
>> [2]: https://gist.github.com/jburwell/f5162ad2d2de32c842b3
>>
>>>
>>
>> [image: ShapeBlue] <http://www.shapeblue.com>
>> John Burwell
>> ShapeBlue
>> d:  *+44 (20) 3603 0542 | s: +1 (571) 403-2411 *
>> <+44%20(20)%203603%200542%20%7C%20s:%20+1%20(571)%20403-2411>
>> e:  *john.burw...@shapeblue.com | t: *
>> <john.burw...@shapeblue.com%20%7C%20t:>  |  w:  *www.shapeblue.com*
>> <http://www.shapeblue.com>
>> a:  53 Chandos Place, Covent Garden London WC2N 4HS UK
>> 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.
>> 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
>> op

Re: [PROPOSAL] LTS Release Cycle

[John Burwell]

Daan and Erik,

@Erik Reading through the proposal, I realize that I was not explicit. LTS 
releases would be official ASF releases following the same voting procedures as 
any other release. Also, realized that I have a bit a math fail in my proposal. 
The cut dates are intended to be six (6) months apart. Therefore, the cut dates 
should be 1 January and 1 June. Therefore, I propose that we cut the first LTS 
branch from the most recent monthly release as of 1 June 2016.

@Daan As many people reflected in the previous discussion about release 
cadence, many users are wedged between enduring workarounds for significant 
defects and a level of upgrade risk that is not acceptable to them. For these 
users, releases are in use for 12-18 months which means that they are often 
forced to accept some significant workarounds to keep their systems stable 
(e.g. 4.5.2 VMWare users can’t use DRS with advanced networking due to VR being 
rebooted on DRS migrations). Keeping all of the previous monthly releases 
updated with important bug fixes is not tenable. LTS allows us to maintain a 
release branch to support users who must run a release for a 12-18 months 
without having to compromise their operational capability to preserve system 
stability.

In terms of the merge strategy, nothing about the current process would change. 
Defects would be fixed on the branch where they occurred and then forward 
ported to master. For each maintained LTS branch less than 14 months old, only 
blocker and critical defects that fall within the LTS’ branch scope would be 
pulled back from master. Therefore, the number of defects backported should be 
relatively small. Any defects found and fixed in an LTS branch would be forward 
ported to master. I will clarify the proposal to establish this merge pattern 
to ensure that LTS does not violate or impede the flow of defect fixes on 
master and maintained monthly releases.

Thanks,
-John

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:  +44 (20) 3603 0542 | s: +1 (571) 403-2411 
<tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:  john.burw...@shapeblue.com | t: 
<mailto:john.burw...@shapeblue.com%20|%20t:> |  w:  
www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:imageff218b.png@a664b8fc.4fa0ac20]


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




On Jan 16, 2016, at 5:07 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:
>
> +0, John, I admire your efforts but I would like to see a proposal more in
> line with our present process for PR merging and releasing. For 4.5 we have
> a bootstrap problem, here so that would reauire a transistion period
> (unless we start branding our LTS on 4.7) I also don see the neccesity for
> anything beyond tiny version. I think it is confusing. So I would prefer
> going for 4.7.1 ...2 ...3 etc or 4.5.4 ...5 ...6 if you wish. And next I am
> not attracted to the back-porting bit. We should make sure bugs are fixed
> on the commit that caused them and then forward ported to any branch that
> needs them, including master and LTS.
>
> That all said, I see a feasible plan so please go ahead.
>
> On Fri, Jan 15, 2016 at 10:26 PM, Erik Weber <terbol...@gmail.com> wrote:
>
>> On Fri, Jan 15, 2016 at 7:48 PM, John Burwell <john.burw...@shapeblue.com>
>> wrote:
>>
>>> Motivation
>>> 
>>>
>>> The current monthly release cycle addresses the needs of users focused on
>>> deploying new functionality as quickly as possible. It does not address
>> the
>>> needs of users oriented towards stability rather than new functionality.
>>> These users typically employ QA processes to comply with corporate policy
>>> and/or regulatory requirements. To maintain a growing, thriving
>> community,
>>> we must address the needs of both user types

Re: [PROPOSAL] LTS Release Cycle

[John Burwell]

Ilya,

Unless we have a bug fix that addresses a significant, widespread system 
stability problem or a high priority/impact security issue, an LTS will roll up 
a number of fixes.   Each release would receive the full system test to verify 
that the patch set does not introduce regression defects.  I believe that most 
LTS users want a few releases as necessary to keep their systems up-to-date and 
stable because each upgrade carries operational risk and downtime.  Therefore, 
the process should strive to make as a few releases as necessary to achieve 
this goal.

Thanks,
-John

> On Jan 15, 2016, at 3:22 PM, ilya <ilya.mailing.li...@gmail.com> wrote:
>
> John
>
> Thank you for taking time writing out the LTS proposal.
>
>> Broad community support is vital to guarantee the twenty (20) month
>> support period for each LTS branch. Given the ebbs and flows of
>> contribution and committer priorities, ShapeBlue will provide a release
>> manager, as well as, engineering support to fill any contribution gaps
>> to ensure that the community fulfills LTS commitments.
>
> You guys rock!!
>
> I'm +1 on this,
>
> Can you please expand on the QA side of LTS. Since this is more around
> long term bug/security fix - i'd think - the testing will be minimal, to
> the scope that fix applies - which will speed up the release process in
> general. What are your thoughts on this?
>
>
> Thanks
> ilya
>
>
>
>
>
> On 1/15/16 10:48 AM, John Burwell wrote:
>> Motivation
>> 
>>
>> The current monthly release cycle addresses the needs of users focused
>> on deploying new functionality as quickly as possible. It does not
>> address the needs of users oriented towards stability rather than new
>> functionality. These users typically employ QA processes to comply with
>> corporate policy and/or regulatory requirements. To maintain a growing,
>> thriving community, we must address the needs of both user types.
>> Therefore, I propose that we overlay a LTS release cycle onto the
>> monthly release cycle to address the needs of stability-oriented users
>> with minimal to no impact on the monthly release cycle. This proposed
>> LTS release cycle has the following goals:
>>
>> * Prefer Stability to New Functionality: Deliver releases that only
>> address defects and CVEs. This narrowly focused change scope greatly
>> reduces the upgrade risk/operational impact and shorter internal QA cycles.
>> * Reliable Release Lifetimes: Embracing a time-based release strategy,
>> the LTS release cycle will provide users with a reliable support time
>> frames. Users can use these time frames provide users with an 20 month
>> window in which to plan upgrades.
>> * Support Sustainability: With a defined end of support for LTS releases
>> and a maximum of two (2) LTS releases under active maintenance at any
>> given time, community members can better plan their commitments to
>> release support activities. We also have a agreed upon policy for
>> release end-of-life (EOL) to debate about continuing work on old releases.
>>
>> Proposed Process
>> ==
>>
>> LTS release branches will be cut twice year on 1 Jan and 1 July from the
>> tag of the most recent monthly release. The branch will be named > version>-LTS and each LTS release will be versioned in the form of > version>-. For example, if we cut an LTS branch
>> based on 4.7.0, the branch would be named 4.7.0-LTS and the version of
>> the first LTS release would be 4.7.0-0, the second would be 4.7.0-1,
>> etc. This release naming convention differentiates LTS and monthly
>> releases, communicates the version on which the LTS release is based,
>> and allows the maintenance releases for monthly releases without version
>> number contention/conflict. Finally, like master, an LTS branch would be
>> always deployable following its initial release. While it is unlikely
>> that LTS users would deploy from the branch, the quality discipline of
>> this requirement will benefit the long term stability of LTS releases.
>> All PRs targeting an LTS would require two LGTMs in order to be merged.
>>
>> The following are the types of changes that would permitted and
>> guarantees provided to users:
>>
>> * No features or enhancements would be backported to LTS release branches.
>> * Database changes would be limited to those required to address the
>> backported defect fixes.
>> * Support for the release/version of the following components from the
>> release on which the LTS is based throughout the entire release cycle:
>> * MySQL/MariaDB
>> * JDK/JRE
>> * 

Re: [DISCUSS][PROPOSE] use of optional instead of null

[John Burwell]

Daan,

I completely agree that returning null is bad. Not only does it yield a ton of 
useless null checks, it creates leaky abstractions by spreading the handling of 
the missing case out beyond the boundary of the class/subsystem.

As a big proponent of the Null Object Pattern [1], I really wanted to like 
Optional. It is a great concept in functional languages. So, I tried using it 
in three (3) different projects since 2011. In all three systems, I would say 
that, at best, it was no better than returning null, and, in other cases, 
worse. Since Optional.get throws an exception when the wrapped value is null, 
all optional accesses must be defensively checked so the code base is littered 
with code like the following:

if (value.isPresent()) {
return value.get();
}

So, basically, you end up replacing null checks and NPEs with isPresent checks 
and a Guava exception. As a bonus, when exceptions occurred in production, we 
had explain the meaning of them. The quickest explanation — “They are the new 
NPE”. For all new developers on the projects, we had one more thing to explain 
to them which, again, was asking them to do something differently with no added 
value. Based on these experiences, I prefer null checks to optional.

While it is more effort (i.e. more code), I have gone back to using the Null 
Object Pattern implemented in this manner [2]. Not only does this approach 
avoid NPEs, it also explicitly defines the behavior for the missing case. For 
more complex examples, it can be unit tested to ensure the missing case behaves 
as expected.

Thanks,
-John

[1]: https://en.wikipedia.org/wiki/Null_Object_pattern
[2]: https://gist.github.com/jburwell/f5162ad2d2de32c842b3

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:  +44 (20) 3603 0542 | s: +1 (571) 403-2411 
<tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:  john.burw...@shapeblue.com | t: 
<mailto:john.burw...@shapeblue.com%20|%20t:> |  w:  
www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:image6e2aab.png@2caaed35.4cb517dd]


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




On Nov 17, 2015, at 11:16 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:
>
> LS,
>
> As a spin off from a discussion in a PR where it is no longer relevant I
> made another PR to show the principle of the use of Optionals[1]
> <https://github.com/apache/cloudstack/pull/1060>
>
> Miguel from Schuberg Philis has been proposing this as replacement of the
> bad practice of returning null in methods and I agree. In seldom cases it
> might be more expedient to throw an exception, most notably when a null is
> returned but no check against is done in the calling method. In those cases
> throwing a CloudRuntimeException would be an easier way to go then the
> pattern in this PR. This is a runtime exception however so maybe creating
> an explicit one is more appropriate in those places.
>
> Anyway I want to propose to move to using the pattern from the PR from now
> on.
>
> ​[1] https://github.com/apache/cloudstack/pull/1060​
>
> ​thoughts?​
> --
> Daan

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

[PROPOSAL] LTS Release Cycle

[John Burwell]

 is an 
unacceptable security risk.
3. Update the wiki and website to explain the new release cycle and help users 
decide which release type suits their needs
4. Define an initial test plan for LTS stabilization
5. Agree on the definitions of ticket severities

In order to address these items and start on a regular rhythm, I propose that 
first LTS cycle begin on 1 July 2015. In the interim, we would continue to ship 
critical bug fixes from the 4.5 release as this release seems to be the most 
commonly deployed in the community.

Together, the monthly and LTS release cycles address the needs of the entire 
Apache CloudStack user community. I believe that the process described in the 
proposal will yield releases that meet the needs of users requiring release 
stability without adversely affecting the velocity of the monthly release cycle.

Thanks,
-John

[1]: http://www.oracle.com/technetwork/java/eol-135779.html


[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:  +44 (20) 3603 0542 | s: +1 (571) 403-2411 
<tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:  john.burw...@shapeblue.com | t: 
<mailto:john.burw...@shapeblue.com%20|%20t:> |  w:  
www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:imagef869f6.png@4b2b18aa.44bcb591]


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




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

Re: LTS release or not

[John Burwell]

All,

It seems that there is general agreement on the following:

1. There are users that need periodic releases that only focus on stability to 
minimize change and deployment risk (i.e. LTS releases)
2. There are users that need frequent releases that deliver new capabilities 
(i.e. monthly releases)
3. These two release types are not mutually exclusive and can be developed in a 
complementary manner
4. Assuming community has the resources available, we would like to deliver 
both monthly and LTS releases

For a sometime, ShapeBlue have been considering a proposal to supplement the 
monthly release cycle with an LTS release cycle. We believe that offering both 
monthly and LTS releases will make CloudStack more attractive to new users, as 
well as, addressing the requirements of all current CloudStack users. I expect 
to publish an LTS proposal within the next day or so that includes most, if not 
all, of the points discussed on this thread. Hopefully, we will quickly gain 
consensus on an LTS release cycle, and begin doing the work necessary to 
deliver high quality LTS releases.

Thanks,
-John

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:  +44 (20) 3603 0542 | s: +1 (571) 403-2411 
<tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:  john.burw...@shapeblue.com | t: 
<mailto:john.burw...@shapeblue.com%20|%20t:> |  w:  
www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:image5c2903.png@05139e21.40b48007]


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




On Jan 12, 2016, at 2:43 PM, Nux! <n...@li.nux.ro> wrote:
>
> Remi,
>
> Yes, that, that's great then, thanks.
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
>> From: "Remi Bergsma" <rberg...@schubergphilis.com>
>> To: dev@cloudstack.apache.org
>> Sent: Tuesday, 12 January, 2016 19:04:55
>> Subject: Re: LTS release or not
>
>> Hi Lucian,
>>
>> Are you referring to the forward merging?
>> That has been scripted:
>> https://github.com/apache/cloudstack/blob/master/tools/git/git-fwd-merge
>>
>> There may be conflicts at some point, but that also happens with 
>> cherry-picking.
>>
>> If you mean something else I probably missed your point, sorry.
>>
>> Regards,
>> Remi
>>
>>
>>
>>
>> On 12/01/16 17:17, "Nux!" <n...@li.nux.ro> wrote:
>>
>>> Guys, I am not a coder to appreciate how sustainable this would be.
>>>
>>> Who around here with actual java skills thinks this is achievable in a
>>> reasonable way? Cause if it's not we're just wasting time.
>>>
>>> Lucian
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>> - Original Message -
>>>> From: "Remi Bergsma" <rberg...@schubergphilis.com>
>>>> To: dev@cloudstack.apache.org
>>>> Sent: Tuesday, 12 January, 2016 15:36:52
>>>> Subject: Re: LTS release or not
>>>
>>>> Hi,
>>>>
>>>> The method Daan describes can be done from 4.6 and on. It’s about merging 
>>>> a PR
>>>> with a fix, and forward merging it. Not about actually releasing 
>>>> immediately.
>>>>
>>>> If the bug has always been there, one would merge to 4.6, merge forward to 
>>>> newer
>>>> releases (and finally master) and then back port (aka cherry-pick) to 4.5.
>>>>
>>>> Regards,
>>>> Remi
>>>>
>>>>
>>>>
>>>> On 12/01/16 15:55, "Ron Wheel

Re: [DISCUSS] Move to Github

[John Burwell]

All,

I am +1 to make Github the “repo of record” for the record. I believe it has 
been suggested to keep a secondary, read-only mirror of the repo on ASF which 
seems like a prudent, low effort backup.

Personally, I think both Confluence and Github are fairly poor wiki 
implementations. Therefore, I am +0 on moving the wiki to Github so long as we 
can maintain the content that has already been created. While some of the 
content in the existing wiki is a bit out of date, I think it would be a 
mistake to “throw the baby out with the bathwater”. So long as moving the wiki 
to Github doesn’t mean starting over, it makes little difference to me if it is 
Confluence or Github.

I am no fan of JIRA. I think it is clunky, bloated, and overly complicated — 
particularly in its default configuration. It also requires additional 
registration and approval for users to interact with the project which I deeply 
dislike. However, as much as I dislike JIRA, my experience with Github issues 
has been worse. Where JIRA attempts to do too much, Github issues simply can’t 
do many things. In particular, we need the following features in a ticketing 
system which are not currently provided by Github Issues:

1. Private Tickets: We must have an avenue for security researchers, 
developers, and users to responsibly inform the project about security issues 
and track resolution. This process is necessarily confined to the reporter and 
security team until a resolution is found.
2. Attachments: A vital part of resolving issues are screenshots and logs. 
While people can gist or imgur this information, it is cumbersome. Many of 
these systems also purge information after some period of time — removing 
important information from long lived, unresolved ticket and/or reducing their 
historical value. I don’t know about others, but I search through ticket 
history a few times a week to understand the history of issues and when they 
have been fixed. I often look at the attachments to determine whether or not 
the issue I am debugging matches the ticket.
3. History Import: While less important than the previous two items, a single 
source to comprehend history is very useful. Our current JIRA is a rich corpus 
of project’s previous problems and their resolutions. Splitting that corpus 
across two repositories would be a step backwards in my mind.

I would imagine there are additional gaps between JIRA and Github Issues 
functionality as Github Issues is an extremely simplistic ticking system. For 
these reasons, I am -1 on moving to Github Issues.

Thanks,
-John

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:  +44 (20) 3603 0542 | s: +1 (571) 403-2411 
<tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:  john.burw...@shapeblue.com | t: 
<mailto:john.burw...@shapeblue.com%20|%20t:> |  w:  
www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:image7b7e2d.png@57e35166.4d8951a3]


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




On Jan 3, 2016, at 2:12 PM, Sebastien Goasguen <run...@gmail.com> wrote:
>
>
>> On Jan 3, 2016, at 4:28 PM, humbed...@gmail.com wrote:
>>
>>
>>
>> On 2016-01-03 12:25, Sebastien Goasguen <run...@gmail.com> wrote:
>>> Bringing this one discuss thread to the top of the ML to get stronger 
>>> consensus.
>>>
>>> We need it if we want to request a move to GitHub.
>>>
>>> Note that this is not about leaving the ASF, it is about using GitHub to 
>>> its full potential.
>>>
>>> The ASF board is investigating ways for a project to use Github and still 
>>> maintain strong provenance of commits to keep the high quality and 
>>> provenance standards of ASF code.
>>>
>>> If we get consensus we can request to the board to be part of the 
>>> “trial” and move to Github.
>>
>> So

Re: Let’s discuss database upgrades

[John Burwell]

All,

I completely agree with Wido that the notion of the ACS version (e.g. 4.6.0, 
4.6.1, 4.7.0, etc) should be a purely logical concept.  It points to particular 
git hash, a version of the database schema, etc.  I also agree that supporting 
downgrade is a fools errand as many database schema changes are destructive.

My largest issue with our upgrade process is that it requires management server 
downtime (leaving out the system VM efor the moment).  On a 4-6 month release 
cycle, a few maintenance windows a year is livable.  However, monthly 
maintenance windows becomes more and more onerous.  Consider the number of 
maintenance windows AWS opens where all or part of its services are completely 
unavailable.  Therefore, our tooling needs to favor additive, non-destructive 
schema changes that allow database upgrades to be applied while an older 
version of the management is still running.  Combined with a clustered 
management server configuration, a CloudStack user to could upgrade their 
database schema then perform rolling upgrade of their management servers 
without taking any downtime.  By policy, we should only perform changes that 
require downtime (e.g. changes to the clustering protocol, destructive/offline 
schema changes, etc) in major versions (and potentially critical 
security/stability bug fixes).  While it would be extra effort, developing a 
DSL for describing migrations would allow the tool to relieve developers from 
worrying destructive/additive changes, as well as, understanding if/when 
database changes must be made offline.  Finally, in order to execute upgrades 
separately from the management server upgrade, the upgrade tooling and 
execution must be pulled out of the management server and into a standalone 
utility.

Another issue is that we don’t use our database tooling in development in the 
same way as users in production.  Anecdotally, developers vary in the way they 
upgrade their development databases based on their personal workflow.  We are 
committing one of the biggest operational sins — having a special process that 
is rarely executed.  Therefore, I agree with Daan that which ever tool we 
select, it should support a workflow that is efficient for both development and 
operations.  We should be eating our own dog food everyday.

I have two issues with FlywayDB.  First, it assumes that wall time will 
synchronized and monotonically increasing.  When things get out of order, they 
tend to fail quietly — causing subtle corruption.  Second, and most 
importantly, it assumes a linearly increasing set of releases.  This model 
works wonderfully for the deployment of internally developed web applications, 
but it does not work for software such as CloudStack.  As has been pointed out, 
minor revision are released after minor releases (e.g. 4.5.3 after 4.6.0).  As 
Daan has also pointed out, in a perfect world, database changes would only 
occur in major or minor releases.  However, in reality, some critical bug fixes 
require database schema changes.  It it not acceptable to deny users critical 
defect fixes because we either cannot or will not make database changes in 
minor revisions.  In its current form, FlywayDB is unable to handle this 
situation because it does not know how interleave the 4.5.3 schema changes into 
the 4.6.0 stream (or 4.7.0 or 4.8.0) since it branched off.

While I think the Chimp proposal could use some refinement, the basic idea of 
using directed, acyclic graph (DAG) to establish a chain of database mutations 
addresses the non-linearizable nature of our release process.  Essentially, it 
is borrowing the model established by git to create a log schema 
transformations.  Coupling a DAG with content hashing to identify each change 
(e.g. the SHA1 of the author, change date, and migration content),  the set of 
changes required to transform a schema to another version can be determined at 
runtime.   Most importantly, in the same way the git can determine that two 
revisions cannot be automatically merged, such a tool can deterministically 
fail if/when upgrades from one version to the another is not possible.  To me, 
a database schema management tool that leveraged the git tree to manage history 
and calculate the set of changes required to upgrade from one version to 
another would represent the gold standard.  I find this approach so powerful 
because it would leverage the standard git revision tracking semantics to 
identify database changes, the rebase/merge workflow to identify and resolve 
schema upgrade conflicts, and release tagging.

In summary, I do not believe that an off-the-shelf tool supports combination of 
non-linear upgrade paths and online database migration we require.  Therefore, 
we will need to develop tooling of own.  To me, the question is whether 
building a new tool from scratch or contributing to existing project represent 
the shortest path to meeting these requirements.

Thanks,
-John


> On Jan 3, 2016, at 6:07 

Re: [DISCUSS] KVM HA with IPMI Fencing

[John Burwell]

eck.  Conceptually, I really like the idea of checking for disk activity via 
the control plane using the volume.  The most significant I see is reusing our 
abstractions to query information from the infrastructure and placing the 
activity check implementation in the storage driver where it belongs.  However, 
implementing the capability may introduce more problems than it solves.  As an 
example, NFS would likely require the introduction of system VMs to mount NFS 
volumes and collect file information -- introducing another set of failure 
scenarios that would complicate the design and operation of the system.  
Therefore, I think we should investigate an implementation of this activity 
check though CloudStack's Volume abstraction to determine if we can implement 
it without incurring unacceptable complexity and compromising system 
reliability.

If the activity check cannot be reliabily performed via the control plane, the 
FS specifies that activity checks will be performed by adjacent node in the 
cluster.  This approach assumes that all hosts in the cluster have access to 
the same underlying NFS mount.  These checks should only be performed by hosts 
with a HA state of AVAILABLE.  In the event a host performing an activity check 
encounters an error during the check operation (e.g. unable to read the NFS 
mount), the HA state of the checking host would be transitioned to SUSPECT.  
Finally, as specified, the activity check relies on the clocks between the 
management server, host, and NFS server being in sync.  Using a relative check 
that watched a file for a timestamp change within a specified number of seconds 
would eliminate this time drift issue.  To avoid live-locking of activity check 
threads in the HA resource management service,  we may want to consider 
implementing activity checks request-reply model with a reply timeout.

Per the FS, the KVM Host HA provider recovers a host by power cycling hosts 
that fail activity checks.  Before performing the power cycle, the provider 
would refresh the power state and verify it is ON before restarting the host.  
The power state refresh protects against a race condition between the actual 
power state of the host changing and the control plane recognizing the state 
change.  The handling the ON->OFF and OFF->ON power state transitions will 
handle waiting for the power cycle to complete and resetting the HA state FSM.  
Finally, if the host power cycle operation fails, the HA state of the host 
would be transitioned to FAILED.

Clustered Management Servers


Currently, management server clustering divides the host ownership across 
management servers.  This ownership is a static calculation that does not 
rebalance when a management server is added or removed from a cluster.  Most 
critically, there is no handoff of host ownership when a management server 
fails.  For the HA resource management service to operate reliabily, we must 
address these gaps in the host ownership model.  Additionally, the HA resource 
management server would require clustering to support ownership of partitions 
(e.g. zones, pods, and clusters) to properly manage the HA state of partitions 
and perform partition-scoped operations.  Given the scope of this topic, I 
believe it should be address in greater depth in a separate thread/FS.

Conclusion
=

With some refinement, I believe we can add a powerful and resilent HA/fencing 
capability to the CloudStack control plane.  It would not only support KVM Host 
HA, but any other resource type managed by the control plane.  I think it would 
be best to decompose the effort into four parts — Host Power Management, HA 
Resource Management Service, KVM Host HA Provider, and management server 
clustering improvements.

Thoughts?
-John

[1]: https://github.com/shevek/ipmi4j


[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:   | s: <tel:|%20s:>   |  m:  703-873-7089

e:  john.burw...@shapeblue.com | t: 
703-566-9597<mailto:john.burw...@shapeblue.com%20|%20t:%20703-566-9597>  |  
w:  www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:imagef000cc.png@59bed1a5.47a8c759]


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

Re: Package Repositories

[John Burwell]

Sebastian,

As I mentioned in my initial message, the public ShapeBlue repositories [1] are 
noredist builds of release baselines with no additional patches or changes.  My 
understanding is that the project cannot officially distribute the noredist 
plugins due to inability of the community to distribute libraries required by 
these components.  If my understanding is correct, I don’t think a community 
managed package repos could contain packages with this components.

I am +1 to the categories.  I am +1 to the making packages official project 
deliverables that are voted out.  Users clear prefer to install via packages.  
It seems like applying the full attention of the community to test them would 
certainly a good thing for users.

Thanks,
-John

[1]: http://packages.shapeblue.com/cloudstack/upstream

—
John Burwell
VP Software Engineering


USA: (571) 403-2411 | UK: +44 20 3603 0542
john.burw...@shapeblue.com | www.shapeblue.com | Twitter: @ShapeBlue
ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS

> On Nov 30, 2015, at 11:44 AM, sebgoa <run...@gmail.com> wrote:
>
>
> On Nov 30, 2015, at 11:28 AM, Paul Angus <paul.an...@shapeblue.com> wrote:
>
>> Sebastien,
>>
>> Can you confirm that users can expect to find the noredist build of the rpms 
>> and debs at apt-get.eu ?
>>
>
> I don't know
>
> What I understood from Rohit, is that the "shapeblue" repo also contains pkgs 
> that are hot-fixed and have features back ported.
> In that sense it is quite a different repo than apt-get which only has pkg 
> for each release.
>
>
>>
>>
>>
>> Paul Angus
>> VP Technology ,   ShapeBlue Ltd
>> s:   02036170528   |  t: @cloudyangus  |  m: +44 
>> 7711418784
>> e:   paul.an...@shapeblue.com  |  w: www.shapeblue.com
>>   53 Chandos Place, Covent Garden, London WC2N 4HS. UK
>>
>> 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.
>> 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.
>>
>>
>> -Original Message-
>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> Sent: 30 November 2015 10:24
>> To: dev <dev@cloudstack.apache.org>
>> Subject: Re: Package Repositories
>>
>> +1 all the way, sebastien
>>
>> On Mon, Nov 30, 2015 at 11:20 AM, Nux! <n...@li.nux.ro> wrote:
>>
>>> +1 your categories.
>>>
>>> Also +1 for the unified thing under cloudstack.apache.org domain.
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>> - Original Message -
>>>> From: "sebgoa" <run...@gmail.com>
>>>> To: dev@cloudstack.apache.org
>>>> Sent: Monday, 30 November, 2015 10:08:59
>>>> Subject: Re: Package Repositories
>>>
>>>> Hi folks, we need to resolve this.
>>>>
>>>> 1-But I have to start with one comment:
>>>> Apache open office releases binaries, users don't compile from source.
>>> So it is
>>>> possible within ASF to officially release binaries.
>>>>
>>>> 2-We have several initiatives around repos, apt-get.eu (Wido),
>>> shapeblue repos,
>>>> Nux mirrors and image templates.
>>>> Seems everyone agrees we need a tag team to coordinate all of it and
>>> offer a
>>>> unified front.
>>>>
>>>> 3-This unified front is great, but it won't happen this week, it
>>>> will
>>> take time
>>>> and dedication.
>>>>
>>>> 4-The small issue we are facing is about 3 lines in an HTML file on
>>>> our

Package Repositories

[John Burwell]

All,

A conversation emerged on a PR [1] regarding how package repositories should 
listed on the downloads page [2].  This PR was prompted by a change on the page 
which removed reference to the ShapeBlue repositories.  The PR proposes listing 
all "3rd-Party Distributions" in a separate section in the same manner as the 
Apache Cassandra [3] project — clearly stating that the package repositories 
are not endorsed by the community.  Objections were raised that the 
apt-get.eu<http://apt-get.eu> repository is a “blessed” community repository, 
and therefore, not a third party repository.  To the best of my knowledge (and 
my ability to search the mailing list archives), I can not find a vote that 
changed the project deliverables to include distribution packages or a 
particular repository for them.  Furthermore, the vote for 4.6.0 was only for 
the source deliverable — not distribution packages.  As such the packages 
contained in the apt-get.eu<http://apt-get.eu> repository are no more “blessed” 
or endorsed than any other packages distributed by other parties.

In my opinion, favoring one 3rd-party repository over another is detrimental to 
the community.  We should either list all maintained 3rd-party package 
repositories or we should list none at all.   By maintained, I mean a 
repository that meets the following criteria:


  *   All contained packages are built from project release tags
  *   The packages contained in the repository are up-to-date with latest 
release tags

The only variations in the packages across “maintained” repositories should be 
the plugins from the CloudStack source tree included in the package.  In order 
to be listed on the downloads page, a repository must meet this definition and 
provide a brief description of the repository’s purpose.

Some on the PR discussion asked about the purpose and composition of the 
packages in the ShapeBlue repository.  The packages in the ShapeBlue repository 
are noredist builds of community release tags.  They contain no additional 
patches or changes.  This repository was created to provide users with an 
convenient/familiar way to install the noredist build of a release.

Finally, as I have stated elsewhere, I think the project should build 
distribution packages signed by the project and distributed from official 
package repositories.  However, we must come to a consensus as community this 
change in deliverables and work out a variety of issues (e.g. supported 
platforms, repository management, signing, etc) to ensure that users receive 
well-tested, community voted packages.  Finally, it seems like there will be a 
role for 3rd-party repositories now and in the future.  Listing all available 
3rd-party repos as I propose would be convenient for users, and ensure fairness 
to all contributors.

Thanks,
-John

[1]: https://github.com/apache/cloudstack-www/pull/20
[2]: http://cloudstack.apache.org/downloads.html
[3]: http://cassandra.apache.org/download/

---
John Burwell (@john_burwell)
VP of Software Engineering, ShapeBlue
(571) 403-2411 | +44 20 3603 0542
http://www.shapeblue.com | @ShapeBlue
53 Chandos Place, Covent Garden, London, WC2N 4HS



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.