date:20160112

Build failed in Jenkins: build-master-slowbuild #2966

2016-01-12 Thread jenkins

See 

--
[...truncated 28723 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[1.742s]
[INFO] Apache CloudStack . SUCCESS [2.101s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.789s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [19.585s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:31.166s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.099s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [52.363s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [28.280s]
[INFO] Apache CloudStack API . SUCCESS [1:48.599s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.046s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [30.421s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.087s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [28.456s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [24.764s]
[INFO] Apache CloudStack Core  SUCCESS [1:22.577s]
[INFO] Apache CloudStack Agents .. SUCCESS [36.403s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [37.368s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.024s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:07.613s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [40.933s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.745s]
[INFO] Apache CloudStack Server .. SUCCESS [4:10.085s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [37.826s]
[INFO] Apache CloudStack Usage Server  SUCCESS [44.684s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:22.906s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.070s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.442s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [53.806s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [47.379s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [31.170s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.170s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [26.278s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [20.241s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [35.120s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.118s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [7.587s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [0.973s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.730s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.365s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[37.016s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.785s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.759s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [14.681s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[17.096s]
[INFO] Apache Cloud

[GitHub] cloudstack pull request: CLOUDSTACK-9203 Implement security group ...

2016-01-12 Thread ustcweizhou

Github user ustcweizhou commented on the pull request:

https://github.com/apache/cloudstack/pull/1297#issuecomment-170847583
  
this does not work if there are multiple shared network in advanced zone 
with sg.
I will fix it.



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

Build failed in Jenkins: build-systemvm64-master #715

2016-01-12 Thread jenkins

See 

Changes:

[wrodrigues] CLOUDSTACK-9213 - Formatting the code

[wrodrigues] CLOUDSTACK-9213 - Split the ACL rules using comma instead of dash.

[aopgenoort] Fix mariadb related listCapacity bug (CLOUDSTACK-8966)

[bvandenheuvel] Factor in inaccurancy of System.nanoTime

[Remi Bergsma] Admin cannot see VMs on port forwarding page

[Remi Bergsma] CLOUDSTACK-9220 Sort list of domains on Domain tab in UI

--
[...truncated 1202 lines...]
Fetching file:   4% ||  10.2MB   1.2MB/s ETA:   0:02:57
Fetching file:   5% |o   |  11.1MB   1.2MB/s ETA:   0:02:54
Fetching file:   5% |o   |  12.6MB   1.2MB/s ETA:   0:02:49
Fetching file:   6% |o   |  13.3MB   1.3MB/s ETA:   0:02:46
Fetching file:   6% |o   |  15.1MB   1.3MB/s ETA:   0:02:39
Fetching file:   7% |o   |  15.5MB   1.3MB/s ETA:   0:02:36
Fetching file:   8% |o   |  17.8MB   1.4MB/s ETA:   0:02:26
Fetching file:   9% |oo  |  20.0MB   1.5MB/s ETA:   0:02:16
Fetching file:  10% |oo  |  22.2MB   1.6MB/s ETA:   0:02:07
Fetching file:  11% |oo  |  24.4MB   1.7MB/s ETA:   0:01:58
Fetching file:  12% |oo  |  26.6MB   1.8MB/s ETA:   0:01:51
Fetching file:  13% |ooo |  28.9MB   1.8MB/s ETA:   0:01:44
Fetching file:  14% |ooo |  31.1MB   1.9MB/s ETA:   0:01:38
Fetching file:  15% |ooo |  33.3MB   2.0MB/s ETA:   0:01:33
Fetching file:  16% |ooo |  35.5MB   2.1MB/s ETA:   0:01:28
Fetching file:  17% ||  37.7MB   2.2MB/s ETA:   0:01:23
Fetching file:  18% ||  40.0MB   2.3MB/s ETA:   0:01:19
Fetching file:  19% ||  42.2MB   2.4MB/s ETA:   0:01:15
Fetching file:  20% ||  44.4MB   2.5MB/s ETA:   0:01:12
Fetching file:  21% |o   |  46.6MB   2.5MB/s ETA:   0:01:09
Fetching file:  22% |o   |  48.8MB   2.6MB/s ETA:   0:01:06
Fetching file:  23% |o   |  51.1MB   2.7MB/s ETA:   0:01:03
Fetching file:  24% |o   |  53.3MB   2.7MB/s ETA:   0:01:01
Fetching file:  25% |oo  |  55.5MB   2.8MB/s ETA:   0:00:59
Fetching file:  26% |oo  |  57.7MB   2.8MB/s ETA:   0:00:58
Fetching file:  27% |oo  |  59.9MB   2.9MB/s ETA:   0:00:56
Fetching file:  28% |oo  |  62.2MB   2.9MB/s ETA:   0:00:54
Fetching file:  29% |oo  |  64.4MB   3.0MB/s ETA:   0:00:53
Fetching file:  30% |ooo |  66.6MB   3.0MB/s ETA:   0:00:51
Fetching file:  31% |ooo |  68.8MB   3.1MB/s ETA:   0:00:50
Fetching file:  32% |ooo |  71.0MB   3.1MB/s ETA:   0:00:48
Fetching file:  33% |ooo |  73.3MB   3.2MB/s ETA:   0:00:47
Fetching file:  34% ||  75.5MB   3.2MB/s ETA:   0:00:45
Fetching file:  35% ||  77.7MB   3.2MB/s ETA:   0:00:44
Fetching file:  36% ||  79.9MB   3.3MB/s ETA:   0:00:43
Fetching file:  37% ||  82.1MB   3.3MB/s ETA:   0:00:42
Fetching file:  38% |o   |  84.4MB   3.3MB/s ETA:   0:00:41
Fetching file:  39% |o   |  86.6MB   3.4MB/s ETA:   0:00:40
Fetching file:  40% |o   |  88.8MB   3.4MB/s ETA:   0:00:38
Fetching file:  41% |o   |  91.0MB   3.5MB/s ETA:   0:00:37
Fetching file:  42% |oo  |  93.2MB   3.5MB/s ETA:   0:00:36
Fetching file:  43% |oo  |  95.5MB   3.5MB/s ETA:   0:00:35
Fetching file:  44% |oo  |  97.7MB   3.5MB/s ETA:   0:00:35
Fetching file:  45% |oo  |  99.9MB   3.6MB/s ETA:   0:00:34
Fetching file:  46% |ooo | 102.1MB   3.6MB/s ETA:   0:00:33
Fetching file:  47% |ooo | 104.3MB   3.6MB/s ETA:   0:00:32
Fetching file:  48% |ooo | 106.6MB   3.7MB/s ETA:   0:00:31
Fetching file:  49% |ooo | 108.8MB   3.7MB/s ETA:   0:00:30
Fetching file:  50% || 111.0MB   3.7MB/s ETA:   0:00:29
Fetching file:  51% || 113.2MB   3.8MB/s ETA:   0:00:28
Fetching file:  52% || 115.4MB   3.8MB/s ETA:   0:00:28
Fetching file:  53% || 117.7MB   3.8MB/s ETA:   0:00:27
Fetching file:  54% || 119.9MB   3.8MB/s ETA:   0:00:26
Fetching file:  55% |o   | 122.1MB   3.8MB/s ETA:   0:00:25
Fetching file:  56% |o   | 124.3MB   3.9MB/s ETA:   0:00:25
Fetching file:  57% |o

[GitHub] cloudstack pull request: [4.7] FIX Site2SiteVPN on redundant VPC

2016-01-12 Thread michaelandersen

Github user michaelandersen commented on the pull request:

https://github.com/apache/cloudstack/pull/1276#issuecomment-170863132
  
ping @sanju1010 @wido @terbolous 


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

Isolation in Advanced Zone using PVLANs

2016-01-12 Thread Keerthiraja SJ

https://cwiki.apache.org/confluence/display/CLOUDSTACK/PVLAN+for+isolation+within+a+VLAN

With reference to above WiKi tried out to setup PVLAN it didn't work on 4.5
/ 4.6 / 4.7

Where I could see ovs plugin issue.

This is been already identified not sure on which tracker we are following.

But still I could see the problem exists in 4.6 & 4.7 too.


Is anyone tested this futures in 4.6 & 4.7


Thanks,
Keerthi

[GitHub] cloudstack pull request: Followup fix for #1162: Add support for n...

2016-01-12 Thread ProjectMoon

GitHub user ProjectMoon opened a pull request:

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

Followup fix for #1162: Add support for not (re)starting server after 
cloud-setup-management.

This is a follow-up fix for pull request #1162, which added a `--no-start` 
option to cloudstack-setup-management. It is necessary for further script 
execution under systemd, otherwise the service aborts.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/greenqloud/cloudstack pr-fix-mgmt-setup

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1330.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1330


commit 43279d11d025221c5d4e83b15e61c78b0d047d3e
Author: Pall Helgason 
Date:   2015-12-08T13:28:08Z

FOCUS-25 moving stop of management in config inside if loop




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

[KVM] CPU sockets reported incorrectly

2016-01-12 Thread Nux!

Hi,

Since forever the CPU sockets have been reported incorrectly by ACS, apparently 
the number reported by "virsh nodeinfo" is not the one to use, but a 
multiplication of reported sockets and numa cells.
More info at https://issues.apache.org/jira/browse/CLOUDSTACK-9226

It'd be great if someone could change the reporting to match that.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

[GitHub] cloudstack pull request: Followup fix for #1162: Add support for n...

2016-01-12 Thread DaanHoogland

Github user DaanHoogland commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1330#discussion_r49442629
  
--- Diff: python/lib/cloudutils/serviceConfigServer.py ---
@@ -138,9 +138,8 @@ def checkHostName():
 except:
 pass
 
-self.syscfg.svo.stopService("cloudstack-management")
-
 if self.syscfg.env.noStart == False:
+self.syscfg.svo.stopService("cloudstack-management")
--- End diff --

so if nostart is false (start is true ??) the service is stopped. Am I 
understanding this wrong? it seems like we don't want this here and not 
unconditionally either but only if nostart is true.


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

[GitHub] cloudstack pull request: Followup fix for #1162: Add support for n...

2016-01-12 Thread ProjectMoon

Github user ProjectMoon commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1330#discussion_r49445279
  
--- Diff: python/lib/cloudutils/serviceConfigServer.py ---
@@ -138,9 +138,8 @@ def checkHostName():
 except:
 pass
 
-self.syscfg.svo.stopService("cloudstack-management")
-
 if self.syscfg.env.noStart == False:
+self.syscfg.svo.stopService("cloudstack-management")
--- End diff --

This is the original behavior of the script, before `--no-start` was added. 
When `--no-start` is NOT specified, the script tries to make sure that the 
service is stopped before starting it again.


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

Build failed in Jenkins: build-master-slowbuild #2967

2016-01-12 Thread jenkins

See 

--
[...truncated 28723 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[2.060s]
[INFO] Apache CloudStack . SUCCESS [3.105s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [1.099s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [20.174s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:29.940s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.110s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [54.132s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [28.297s]
[INFO] Apache CloudStack API . SUCCESS [1:49.510s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.132s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [30.060s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.085s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [28.562s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [24.868s]
[INFO] Apache CloudStack Core  SUCCESS [1:20.848s]
[INFO] Apache CloudStack Agents .. SUCCESS [36.744s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [35.933s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.474s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:06.535s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [41.028s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.617s]
[INFO] Apache CloudStack Server .. SUCCESS [4:14.330s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [36.732s]
[INFO] Apache CloudStack Usage Server  SUCCESS [45.177s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:22.647s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.103s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.436s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [53.786s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [48.375s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [29.577s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.512s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [25.341s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [22.949s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [35.333s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.395s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [8.182s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [1.020s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.742s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.768s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[35.902s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.639s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.415s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [16.354s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.635s]
[INFO] Apache Cloud

[GitHub] cloudstack pull request: Followup fix for #1162: Add support for n...

2016-01-12 Thread davidamorimfaria

Github user davidamorimfaria commented on the pull request:

https://github.com/apache/cloudstack/pull/1330#issuecomment-170898189
  
LGTM


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

[GitHub] cloudstack pull request: [4.7] FIX Site2SiteVPN on redundant VPC

2016-01-12 Thread DaanHoogland

Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1276#issuecomment-170902066
  
tested on a two kvm, as in the bubble, setup:
```
# less /tmp/MarvinLogs/test_vpc_vpn_Q1BTHP/results.txt
Test Site 2 Site VPN Across redundant VPCs ... === TestName: 
test_01_redundant_vpc_site2site_vpn | Status : SUCCESS ===
ok
Test Remote Access VPN in VPC ... === TestName: 
test_01_vpc_remote_access_vpn | Status : SUCCESS ===
ok
Test Site 2 Site VPN Across VPCs ... === TestName: 
test_01_vpc_site2site_vpn | Status : SUCCESS ===
ok

--
Ran 3 tests in 2166.200s

OK
```

LGTM


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: LTS release or not

2016-01-12 Thread Ron Wheeler

Depending on how far back the problem originated, this may not be 
practical.
The code might have been massaged many times or code may have been 
written that depends on the buggy behaviour.


If the bug "was always there" but no one had figured out the exploit, it 
might not be possible to identify any particular commit at all.


Would your solution trigger a whole bunch of new releases - 4.4.x, 
4.5.y, 4.6.z, 4.7.1, etc. or would the fix just be applied to the branch 
and noted while we wait for enough to accumulate to trigger a new 
release? Who would want to work on 4.4.x release?


The amount of testing required to support all that backporting would 
certainly deter people from fixing old bugs!


No code is bug free so I am not sure how bad it is to say that a bug 
will only be fixed in the LTS and current release.


System administrators can then decide if the bug is worth an update to 
the fixed version or should be fixed on the release that they currently 
run,  causing a local fork that they will deal with during their next 
upgrade cycle.



Ron


On 12/01/2016 2:18 AM, Daan Hoogland wrote:

ok, one last €0,01: any bug should be fixed not on the branch but on the
commit it was introduced in and thenn be merged forward. It can then be
merged into any branch that contains the offending commit and there is no
longer any difference between LTS or anything else. Am I speaking
Kardeshian? I am really surprised no one in this list sees source code and
release management this way.

On Mon, Jan 11, 2016 at 5:34 PM, Ron Wheeler 
wrote:
There may have to be some rules about patches such as
"You may not apply any bug fix to a minor release that will break the
upgrade path."
So 4.6.0, 4.6.1 and 4.6.2 can all be upgraded to 4.7.0 or the latest 4.7.x
If a user absolutely needs a fix that breaks this, then it is their
problem to upgrade to 4.7.x rather than building a long-term problem into a
stable branch.
At some point no one will be happy with the latest 4.6.x and everyone will
upgraded.

Any user that applies the offending patch to 4.6.2 should know that they
have created their own misery and will have to work out the upgrade at some
point or continue their private fork forever.

There is nothing wrong to saying that "Bug xx is only fixed in version
4.8.0 and later".
Even if version 4.6.5 came out a month after 4.8.0, bug xx is not fixed.
No piece of software is bug-free so we are really discussing what happens
once a bug is found and a fix is available.
4.6.5 will run exactly like it did before the bug was found.

Bugs that will cause update issues will trigger a new major release.
If the current supported releases are 4.6.2 and 4.7.1 then the bug will
cause a 4.8.0 to come into existence with an upgrade path that goes from
4.6.2 to 4.7.0 (or 4.7.1 which should be the identical upgrade) to 4.8.0


My 2 cents!
Ron




On 11/01/2016 10:23 AM, Rene Moser wrote:


Hi Remi

On 01/11/2016 04:16 PM, Remi Bergsma wrote:


Maintaining LTS is harder than it seems. For example with upgrading. You
can only upgrade to versions that are released _after_ the specific LTS
version. This due to the way upgrades work. If you release 4.7.7 when we’re
on say 4.10, you cannot upgrade to 4.8 or 4.9. The same for 4.5: 4.5.4
cannot upgrade to any 4.6, 4.7 or 4.8 because it simply didn’t exist when
these versions were released. (4.5.3 has been accounted for so that does
work this time). If you want to keep doing 4.5 releases 18 months from now,
that’s going to be a real issue. Users probably won’t understand and expect
it to work. And yes, we will change the upgrading procedures but it’s not
there yet.


Out of curiosity. I thought about patch relases like this scheme 4.5.2.x
for LTS. This would work right?

Regards
René



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102







--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Build failed in Jenkins: build-master-slowbuild #2968

2016-01-12 Thread jenkins

See 

--
[...truncated 28723 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[1.738s]
[INFO] Apache CloudStack . SUCCESS [2.055s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.856s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [19.674s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:31.171s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.106s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [52.970s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [27.785s]
[INFO] Apache CloudStack API . SUCCESS [1:48.770s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.203s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [29.818s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.082s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [28.008s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [25.084s]
[INFO] Apache CloudStack Core  SUCCESS [1:22.136s]
[INFO] Apache CloudStack Agents .. SUCCESS [36.426s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [36.387s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.274s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:09.558s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [41.893s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.227s]
[INFO] Apache CloudStack Server .. SUCCESS [4:12.383s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [36.736s]
[INFO] Apache CloudStack Usage Server  SUCCESS [44.351s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:21.846s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.073s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.437s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [54.157s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [48.688s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [29.769s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.288s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [30.870s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [20.548s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [36.095s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.624s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [8.202s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [0.970s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [27.001s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.511s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[36.789s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.656s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.842s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [15.653s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.758s]
[INFO] Apache Cloud

Re: LTS release or not

2016-01-12 Thread Remi Bergsma

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 Wheeler"  wrote:

>Depending on how far back the problem originated, this may not be 
>practical.
>The code might have been massaged many times or code may have been 
>written that depends on the buggy behaviour.
>
>If the bug "was always there" but no one had figured out the exploit, it 
>might not be possible to identify any particular commit at all.
>
>Would your solution trigger a whole bunch of new releases - 4.4.x, 
>4.5.y, 4.6.z, 4.7.1, etc. or would the fix just be applied to the branch 
>and noted while we wait for enough to accumulate to trigger a new 
>release? Who would want to work on 4.4.x release?
>
>The amount of testing required to support all that backporting would 
>certainly deter people from fixing old bugs!
>
>No code is bug free so I am not sure how bad it is to say that a bug 
>will only be fixed in the LTS and current release.
>
>System administrators can then decide if the bug is worth an update to 
>the fixed version or should be fixed on the release that they currently 
>run,  causing a local fork that they will deal with during their next 
>upgrade cycle.
>
>
>Ron
>
>
>On 12/01/2016 2:18 AM, Daan Hoogland wrote:
>> ok, one last €0,01: any bug should be fixed not on the branch but on the
>> commit it was introduced in and thenn be merged forward. It can then be
>> merged into any branch that contains the offending commit and there is no
>> longer any difference between LTS or anything else. Am I speaking
>> Kardeshian? I am really surprised no one in this list sees source code and
>> release management this way.
>>
>> On Mon, Jan 11, 2016 at 5:34 PM, Ron Wheeler >> wrote:
>>> There may have to be some rules about patches such as
>>> "You may not apply any bug fix to a minor release that will break the
>>> upgrade path."
>>> So 4.6.0, 4.6.1 and 4.6.2 can all be upgraded to 4.7.0 or the latest 4.7.x
>>> If a user absolutely needs a fix that breaks this, then it is their
>>> problem to upgrade to 4.7.x rather than building a long-term problem into a
>>> stable branch.
>>> At some point no one will be happy with the latest 4.6.x and everyone will
>>> upgraded.
>>>
>>> Any user that applies the offending patch to 4.6.2 should know that they
>>> have created their own misery and will have to work out the upgrade at some
>>> point or continue their private fork forever.
>>>
>>> There is nothing wrong to saying that "Bug xx is only fixed in version
>>> 4.8.0 and later".
>>> Even if version 4.6.5 came out a month after 4.8.0, bug xx is not fixed.
>>> No piece of software is bug-free so we are really discussing what happens
>>> once a bug is found and a fix is available.
>>> 4.6.5 will run exactly like it did before the bug was found.
>>>
>>> Bugs that will cause update issues will trigger a new major release.
>>> If the current supported releases are 4.6.2 and 4.7.1 then the bug will
>>> cause a 4.8.0 to come into existence with an upgrade path that goes from
>>> 4.6.2 to 4.7.0 (or 4.7.1 which should be the identical upgrade) to 4.8.0
>>>
>>>
>>> My 2 cents!
>>> Ron
>>>
>>>
>>>
>>>
>>> On 11/01/2016 10:23 AM, Rene Moser wrote:
>>>
 Hi Remi

 On 01/11/2016 04:16 PM, Remi Bergsma wrote:

> Maintaining LTS is harder than it seems. For example with upgrading. You
> can only upgrade to versions that are released _after_ the specific LTS
> version. This due to the way upgrades work. If you release 4.7.7 when 
> we’re
> on say 4.10, you cannot upgrade to 4.8 or 4.9. The same for 4.5: 4.5.4
> cannot upgrade to any 4.6, 4.7 or 4.8 because it simply didn’t exist when
> these versions were released. (4.5.3 has been accounted for so that does
> work this time). If you want to keep doing 4.5 releases 18 months from 
> now,
> that’s going to be a real issue. Users probably won’t understand and 
> expect
> it to work. And yes, we will change the upgrading procedures but it’s not
> there yet.
>
 Out of curiosity. I thought about patch relases like this scheme 4.5.2.x
 for LTS. This would work right?

 Regards
 René


>>> --
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email: rwhee...@artifact-software.com
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>>
>>>
>>
>
>
>-- 
>Ron Wheeler
>President
>Artifact Software Inc
>email: rwhee...@artifact-software.com
>skype: ronaldmwheeler
>phone: 866-970-2435, ext 102
>

Re: LTS release or not

2016-01-12 Thread Nux!

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" 
> 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 Wheeler"  wrote:
> 
>>Depending on how far back the problem originated, this may not be
>>practical.
>>The code might have been massaged many times or code may have been
>>written that depends on the buggy behaviour.
>>
>>If the bug "was always there" but no one had figured out the exploit, it
>>might not be possible to identify any particular commit at all.
>>
>>Would your solution trigger a whole bunch of new releases - 4.4.x,
>>4.5.y, 4.6.z, 4.7.1, etc. or would the fix just be applied to the branch
>>and noted while we wait for enough to accumulate to trigger a new
>>release? Who would want to work on 4.4.x release?
>>
>>The amount of testing required to support all that backporting would
>>certainly deter people from fixing old bugs!
>>
>>No code is bug free so I am not sure how bad it is to say that a bug
>>will only be fixed in the LTS and current release.
>>
>>System administrators can then decide if the bug is worth an update to
>>the fixed version or should be fixed on the release that they currently
>>run,  causing a local fork that they will deal with during their next
>>upgrade cycle.
>>
>>
>>Ron
>>
>>
>>On 12/01/2016 2:18 AM, Daan Hoogland wrote:
>>> ok, one last €0,01: any bug should be fixed not on the branch but on the
>>> commit it was introduced in and thenn be merged forward. It can then be
>>> merged into any branch that contains the offending commit and there is no
>>> longer any difference between LTS or anything else. Am I speaking
>>> Kardeshian? I am really surprised no one in this list sees source code and
>>> release management this way.
>>>
>>> On Mon, Jan 11, 2016 at 5:34 PM, Ron Wheeler >>> wrote:
 There may have to be some rules about patches such as
 "You may not apply any bug fix to a minor release that will break the
 upgrade path."
 So 4.6.0, 4.6.1 and 4.6.2 can all be upgraded to 4.7.0 or the latest 4.7.x
 If a user absolutely needs a fix that breaks this, then it is their
 problem to upgrade to 4.7.x rather than building a long-term problem into a
 stable branch.
 At some point no one will be happy with the latest 4.6.x and everyone will
 upgraded.

 Any user that applies the offending patch to 4.6.2 should know that they
 have created their own misery and will have to work out the upgrade at some
 point or continue their private fork forever.

 There is nothing wrong to saying that "Bug xx is only fixed in version
 4.8.0 and later".
 Even if version 4.6.5 came out a month after 4.8.0, bug xx is not fixed.
 No piece of software is bug-free so we are really discussing what happens
 once a bug is found and a fix is available.
 4.6.5 will run exactly like it did before the bug was found.

 Bugs that will cause update issues will trigger a new major release.
 If the current supported releases are 4.6.2 and 4.7.1 then the bug will
 cause a 4.8.0 to come into existence with an upgrade path that goes from
 4.6.2 to 4.7.0 (or 4.7.1 which should be the identical upgrade) to 4.8.0


 My 2 cents!
 Ron




 On 11/01/2016 10:23 AM, Rene Moser wrote:

> Hi Remi
>
> On 01/11/2016 04:16 PM, Remi Bergsma wrote:
>
>> Maintaining LTS is harder than it seems. For example with upgrading. You
>> can only upgrade to versions that are released _after_ the specific LTS
>> version. This due to the way upgrades work. If you release 4.7.7 when 
>> we’re
>> on say 4.10, you cannot upgrade to 4.8 or 4.9. The same for 4.5: 4.5.4
>> cannot upgrade to any 4.6, 4.7 or 4.8 because it simply didn’t exist when
>> these versions were released. (4.5.3 has been accounted for so that does
>> work this time). If you want to keep doing 4.5 releases 18 months from 
>> now,
>> that’s going to be a real issue. Users probably won’t understand and 
>> expect
>> it to work. And yes, we will change the upgrading procedures but it’s not
>> there yet.
>>
> Out of curiosity. I thought about patch relases like this scheme 4.5.2.x
> for LTS. This would work right?
>
> Regards
>>

Thoughts on Citrix announcement yesterday

2016-01-12 Thread Sebastien Goasguen

Hi everyone (cross-posting),

Yesterday Citrix announced that it sold its CloudPlatform business to 
Accelerite from Persistent Systems [1]

As you know CloudPlatform is Citrix’s commercial distribution of Apache 
CloudStack. I wanted to share a few thoughts on what this means for CloudStack.

One of the core tenet of the Apache Software Foundation is non-affiliation to 
companies, as such all of us on these lists participate and contribute to 
CloudStack as individuals. While the majority of us who are contributing daily 
to CloudStack are actually doing it as part of our day jobs we still voice our 
opinions as individuals and companies do not (and should not) have influence on 
what we do. This is one of the things that makes ASF great. This is also one of 
the reasons why the ASF  and us as a project will not comment on this 
announcement. It is Citrix’s business, not ours.

That said, Citrix gave CloudStack to the ASF back in 2012 and contributed 
heavily in the early days to its development and maintenance. We should be 
thankful to Citrix for donating this software and helping the community grow. 
Giving it to the ASF was also the move that allows us to keep on going like 
“business” as usual. We as a project do not depend on Citrix. Hence Citrix 
selling its CloudPlatform business does not change our day to day.

Over the years it is fair to say that Citrix involvement through the many 
individuals participating on these lists as diminished, with the vast majority 
of the work now carried on by others. If we were to do a ASF “faux-pas” and 
actually check affiliation of the folks that are doing most of the development 
and release work, we would see other companies than Citrix. Companies offering 
CloudStack services but also and mostly CloudStack users, a few doing it as a 
hobby and most because their company uses it. This is open source at its core, 
folks using a software, loving it, loving their peers, and contributing back 
for the benefit of everyone.

It is impossible for me to say what Accelerite will do, I have had no contact 
with them so far and did not know this sale was coming. Neither do I know what 
will happen to all the fine Citrix engineers that were still working on 
CloudStack. Whatever they do, I wish them the best and thank them for the 
dedication to our project over the years. Early indication from the press 
release seems to indicate that Accelerite will engage with us. If they do, we 
will welcome them like any contributors to an ASF project. With openness, 
transparency and respect (the Apache way).

I do want to mention that I think this may be an opportunity for CloudStack. 
Observers might think that our project is dead because of Citrix selling its 
business, but they would be mis-informed about the nature of ASF projects. I 
actually believe the contrary and think this will be a time where more users 
and potentially companies will engage more actively. They will see that the 
route to a successful Cloud is through engaging and becoming part of our 
community. They will also finally stop thinking that CloudStack is a Citrix 
product and that might be the kicker that brings them on board.

Finally, being a technical guy, I like to focus on technical things. We have 
done some great strides over the past 8 months, we have stabilized CloudStack 
and are now releasing faster than ever, we have dockerized, we have pluginized, 
we have had several events... In september we will go to Brazil for CCC. Brazil 
is seeing a huge growth in CloudStack adoption.

We still have a ton to do, from removing technical debt, fixing security 
issues, improving packaging, making CloudStack ever more easier to develop and 
use. This has not changed. We have some very important discussions going on 
around LTS and GitHub hosting. If anything I think the container movement is a 
bigger threat to our project than Citrix’s announcement. As companies start to 
embrace the container ecosystem and building containerized applications, what 
happens to CloudStack ? How does CloudStack work in a container world ? The 
same question are valid for OpenStack by the way, I just don’t buy into the 
Magnum effort, but I digress :)

So thank you Citrix, we hope to welcome Accelerite and let’s keep on Stacking,

[1] 
https://www.citrix.com/blogs/2016/01/11/a-new-home-accelerite-to-acquire-cloudplatform/

-Sebastien
VP Apache CloudStack

Re: Thoughts on Citrix announcement yesterday

2016-01-12 Thread Nux!

Hi Sebastien,

Thanks for your thoughts! I for one am being optimistic about this change.

I'm also not worried about containers, I think you've spent too much time among 
hammers and now everything looks like a nail. :-)

There is a massive load of stuff that at the moment needs (data centre) 
virtualisation and Cloudstack is in a better shape than ever to take care of 
that.

So long Citrix and thanks for all the fish!
Hello Accelerite!

My 2 pence,
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Sebastien Goasguen" 
> To: dev@cloudstack.apache.org, us...@cloudstack.apache.org, 
> market...@cloudstack.apache.org,
> priv...@cloudstack.apache.org
> Sent: Tuesday, 12 January, 2016 16:20:44
> Subject: Thoughts on Citrix announcement yesterday

> Hi everyone (cross-posting),
> 
> Yesterday Citrix announced that it sold its CloudPlatform business to 
> Accelerite
> from Persistent Systems [1]
> 
> As you know CloudPlatform is Citrix’s commercial distribution of Apache
> CloudStack. I wanted to share a few thoughts on what this means for 
> CloudStack.
> 
> One of the core tenet of the Apache Software Foundation is non-affiliation to
> companies, as such all of us on these lists participate and contribute to
> CloudStack as individuals. While the majority of us who are contributing daily
> to CloudStack are actually doing it as part of our day jobs we still voice our
> opinions as individuals and companies do not (and should not) have influence 
> on
> what we do. This is one of the things that makes ASF great. This is also one 
> of
> the reasons why the ASF  and us as a project will not comment on this
> announcement. It is Citrix’s business, not ours.
> 
> That said, Citrix gave CloudStack to the ASF back in 2012 and contributed
> heavily in the early days to its development and maintenance. We should be
> thankful to Citrix for donating this software and helping the community grow.
> Giving it to the ASF was also the move that allows us to keep on going like
> “business” as usual. We as a project do not depend on Citrix. Hence Citrix
> selling its CloudPlatform business does not change our day to day.
> 
> Over the years it is fair to say that Citrix involvement through the many
> individuals participating on these lists as diminished, with the vast majority
> of the work now carried on by others. If we were to do a ASF “faux-pas” and
> actually check affiliation of the folks that are doing most of the development
> and release work, we would see other companies than Citrix. Companies offering
> CloudStack services but also and mostly CloudStack users, a few doing it as a
> hobby and most because their company uses it. This is open source at its core,
> folks using a software, loving it, loving their peers, and contributing back
> for the benefit of everyone.
> 
> It is impossible for me to say what Accelerite will do, I have had no contact
> with them so far and did not know this sale was coming. Neither do I know what
> will happen to all the fine Citrix engineers that were still working on
> CloudStack. Whatever they do, I wish them the best and thank them for the
> dedication to our project over the years. Early indication from the press
> release seems to indicate that Accelerite will engage with us. If they do, we
> will welcome them like any contributors to an ASF project. With openness,
> transparency and respect (the Apache way).
> 
> I do want to mention that I think this may be an opportunity for CloudStack.
> Observers might think that our project is dead because of Citrix selling its
> business, but they would be mis-informed about the nature of ASF projects. I
> actually believe the contrary and think this will be a time where more users
> and potentially companies will engage more actively. They will see that the
> route to a successful Cloud is through engaging and becoming part of our
> community. They will also finally stop thinking that CloudStack is a Citrix
> product and that might be the kicker that brings them on board.
> 
> Finally, being a technical guy, I like to focus on technical things. We have
> done some great strides over the past 8 months, we have stabilized CloudStack
> and are now releasing faster than ever, we have dockerized, we have 
> pluginized,
> we have had several events... In september we will go to Brazil for CCC. 
> Brazil
> is seeing a huge growth in CloudStack adoption.
> 
> We still have a ton to do, from removing technical debt, fixing security 
> issues,
> improving packaging, making CloudStack ever more easier to develop and use.
> This has not changed. We have some very important discussions going on around
> LTS and GitHub hosting. If anything I think the container movement is a bigger
> threat to our project than Citrix’s announcement. As companies start to 
> embrace
> the container ecosystem and building containerized applications, what happens
> to CloudStack ? How does CloudStack

Re: LTS release or not

2016-01-12 Thread Sebastien Goasguen

About LTS.

Here are some of the Mesos releases:

+## Releases ##
+
+ * Apache Mesos 0.23.1 (2015-09-21)
+ * Apache Mesos 0.22.2 (2015-09-23)
+ * Apache Mesos 0.21.2 (2015-09-24)
+ * Apache Mesos 0.25.0 (2015-10-09)
+ * Apache Mesos 0.26.0 (2015-12-10)

quite frequent.

Anyone cares to check their policies and CI…?


> On Jan 12, 2016, at 1:11 AM, ilya  wrote:
> 
> Hi Rene
> 
> 
> In short BIG +1, for longer summary, please read below
> 
> 
> PS: For LTS - you mean "Long Term Support" i assume.
> 
> We would be interested in seeing the support of 4.5 longer as well, as
> we are happy with what we got so far and dont have a burning need to
> upgrade yet.
> 
> Upgrade would also require serious testing across the board, so LTS
> release can buy us more time.
> 
> This is my opinion, Marcus would probably have a different opinion on this.
> 
> -
> 
> Side note:
> I had a somewhat similar endeavor few years back that attempted to solve
> this challenge. Though it was not just around "Long Term Support", but
> geared more towards "I need latest bug fix and feature now, I dont have
> 8+ months to wait".
> 
> I called the project CloudSand.
> 
> Back then, i was mostly focusing on ACS + VMware Integration, as the
> code existed in master branch but not in 4.1. Also did a small talk
> about it back in 2013 @ CCC in SF Bay area.
> 
> https://www.youtube.com/watch?v=4wuEPoxVlBM
> 
> You can see it under www.cloudsand.com  - though now no longer
> maintained due to $dayjob$ restrictions (its complicated).
> 
> Either way, i'm in strong support of this initiative. I'm thinking just
> about anyone with fairly sized infrastructure - might do the same, why
> not merge the efforts?
> 
> Things to consider (this is strictly my opinion):
> 1) Pull/merge requests must be reviewed with scrutiny, we dont want LTS
> to be a test bed, but rather a stable build
> 2) Database changes should be avoided unless someone wants to maintain
> upgrade path, i just think it would be easier to just not pull commits
> that require DB change
> 3) End user should be able to upgrade to latest official ACS version
> without any issues or switch between - there should be no lock in..
> 
> I'd like to help with this effort, but don't know how much time i can
> dedicate to this effort.
> 
> Regards,
> ilya
> 
> 
> 
> On 1/9/16 2:51 PM, Rene Moser wrote:
>> Hi
>> 
>> I recently started a discussion about the current release process. You
>> may have noticed that CloudStack had a few releases in the last 2 months.
>> 
>> My concerns were that many CloudStack users will be confused about these
>> many releases (which one to take? Are fixes backported? How long will it
>> receive fixes? Do I have to upgrade?).
>> 
>> We leads me to the question: Does CloudStack need an LTS version? To me
>> it would make sense in many ways:
>> 
>> * Users in restrictive cloud environments can choose LTS for getting
>> backwards compatible bug fixes only.
>> 
>> * Users in agile cloud environments can choose latest stable and getting
>> new features fast.
>> 
>> * CloudStack developers must only maintain the latest stable (mainline)
>> and the LTS version.
>> 
>> * CloudStack developers and mainline users can accept, that mainline may
>> break environments but will receive fast forward fixes.
>> 
>> To me this would make a lot of sense. I am actually thinking about
>> maintaining 4.5 as a LTS by myself.
>> 
>> Any thoughts? +1/-1?
>> 
>> Regards
>> René
>>

[GitHub] cloudstack pull request: NicProfileHelperImpl NullpointerException...

2016-01-12 Thread remibergsma

Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1328#issuecomment-170984088
  
LGTM, based on this test:

```
test_01_vpc_privategw_acl 
(integration.smoke.test_privategw_acl.TestPrivateGwACL) ... === TestName: 
test_01_vpc_privategw_acl | Status : SUCCESS ===
ok
test_02_vpc_privategw_static_routes 
(integration.smoke.test_privategw_acl.TestPrivateGwACL) ... === TestName: 
test_02_vpc_privategw_static_routes | Status : SUCCESS ===
ok
test_03_vpc_privategw_restart_vpc_cleanup 
(integration.smoke.test_privategw_acl.TestPrivateGwACL) ... === TestName: 
test_03_vpc_privategw_restart_vpc_cleanup | Status : SUCCESS ===
ok
test_04_rvpc_privategw_static_routes 
(integration.smoke.test_privategw_acl.TestPrivateGwACL) ... === TestName: 
test_04_rvpc_privategw_static_routes | Status : SUCCESS ===
ok

--
Ran 4 tests in 3549.796s

OK
```


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

Build failed in Jenkins: build-master-slowbuild #2969

2016-01-12 Thread jenkins

See 

--
[...truncated 28723 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[1.745s]
[INFO] Apache CloudStack . SUCCESS [2.065s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.809s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [19.395s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:30.006s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.105s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.767s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [28.097s]
[INFO] Apache CloudStack API . SUCCESS [1:49.197s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.906s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [29.643s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.087s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [28.284s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [25.354s]
[INFO] Apache CloudStack Core  SUCCESS [1:21.564s]
[INFO] Apache CloudStack Agents .. SUCCESS [36.241s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [36.131s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.528s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:07.430s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [41.761s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.331s]
[INFO] Apache CloudStack Server .. SUCCESS [4:14.906s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [37.772s]
[INFO] Apache CloudStack Usage Server  SUCCESS [45.446s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:22.235s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.069s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.427s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [54.752s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [47.730s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [30.119s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.578s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [26.701s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [20.763s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [34.557s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.378s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [8.310s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [0.965s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.878s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.145s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[36.191s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.520s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.711s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [16.757s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.840s]
[INFO] Apache Cloud

[GitHub] cloudstack pull request: CLOUDSTACK-9132: API createVolume takes e...

2016-01-12 Thread mike-tutkowski

Github user mike-tutkowski commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1319#discussion_r49493043
  
--- Diff: server/src/com/cloud/storage/VolumeApiServiceImpl.java ---
@@ -476,6 +476,25 @@ public VolumeVO doInTransaction(TransactionStatus 
status) {
 });
 }
 
+/**
+ * Retrieves the volume name from CreateVolumeCmd object.
+ *
+ * If the retrieved volume name is null, empty or blank, then A random 
name
+ * will be generated using getRandomVolumeName method.
+ *
+ * @param cmd
+ * @return Either the retrieved name or a random name.
+ */
+public String getVolumeNameFromCommand(CreateVolumeCmd cmd) {
+String userSpecifiedName = cmd.getVolumeName();
+
+if 
(org.apache.commons.lang.StringUtils.isBlank(userSpecifiedName)) {
--- End diff --

The code LGTM (I did not test it...just reviewed the code). My only comment 
is on this line. Curious why we don't provide the import at the top as is 
standard in CloudStack. Not a big deal, but it makes it easier to see at a 
glance what all packages are involved. Perhaps there is another StringUtils 
being imported, so this had to be done here?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: LTS release or not

2016-01-12 Thread Remi Bergsma

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!"  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" 
>> 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 Wheeler"  wrote:
>> 
>>>Depending on how far back the problem originated, this may not be
>>>practical.
>>>The code might have been massaged many times or code may have been
>>>written that depends on the buggy behaviour.
>>>
>>>If the bug "was always there" but no one had figured out the exploit, it
>>>might not be possible to identify any particular commit at all.
>>>
>>>Would your solution trigger a whole bunch of new releases - 4.4.x,
>>>4.5.y, 4.6.z, 4.7.1, etc. or would the fix just be applied to the branch
>>>and noted while we wait for enough to accumulate to trigger a new
>>>release? Who would want to work on 4.4.x release?
>>>
>>>The amount of testing required to support all that backporting would
>>>certainly deter people from fixing old bugs!
>>>
>>>No code is bug free so I am not sure how bad it is to say that a bug
>>>will only be fixed in the LTS and current release.
>>>
>>>System administrators can then decide if the bug is worth an update to
>>>the fixed version or should be fixed on the release that they currently
>>>run,  causing a local fork that they will deal with during their next
>>>upgrade cycle.
>>>
>>>
>>>Ron
>>>
>>>
>>>On 12/01/2016 2:18 AM, Daan Hoogland wrote:
 ok, one last €0,01: any bug should be fixed not on the branch but on the
 commit it was introduced in and thenn be merged forward. It can then be
 merged into any branch that contains the offending commit and there is no
 longer any difference between LTS or anything else. Am I speaking
 Kardeshian? I am really surprised no one in this list sees source code and
 release management this way.

 On Mon, Jan 11, 2016 at 5:34 PM, Ron Wheeler 
  wrote:
> There may have to be some rules about patches such as
> "You may not apply any bug fix to a minor release that will break the
> upgrade path."
> So 4.6.0, 4.6.1 and 4.6.2 can all be upgraded to 4.7.0 or the latest 4.7.x
> If a user absolutely needs a fix that breaks this, then it is their
> problem to upgrade to 4.7.x rather than building a long-term problem into 
> a
> stable branch.
> At some point no one will be happy with the latest 4.6.x and everyone will
> upgraded.
>
> Any user that applies the offending patch to 4.6.2 should know that they
> have created their own misery and will have to work out the upgrade at 
> some
> point or continue their private fork forever.
>
> There is nothing wrong to saying that "Bug xx is only fixed in version
> 4.8.0 and later".
> Even if version 4.6.5 came out a month after 4.8.0, bug xx is not fixed.
> No piece of software is bug-free so we are really discussing what happens
> once a bug is found and a fix is available.
> 4.6.5 will run exactly like it did before the bug was found.
>
> Bugs that will cause update issues will trigger a new major release.
> If the current supported releases are 4.6.2 and 4.7.1 then the bug will
> cause a 4.8.0 to come into existence with an upgrade path that goes from
> 4.6.2 to 4.7.0 (or 4.7.1 which should be the identical upgrade) to 4.8.0
>
>
> My 2 cents!
> Ron
>
>
>
>
> On 11/01/2016 10:23 AM, Rene Moser wrote:
>
>> Hi Remi
>>
>> On 01/11/2016 04:16 PM, Remi Bergsma wrote:
>>
>>> Maintaining LTS is harder than it seems. For example with upgrading. You
>>> can only upgrade to versions that are released _after_ the specific LTS
>>> version. This due to the way upgrades work. If you release 4.7.7 when 
>>> we’re
>>> on say 4.10, you cannot upgrade to 4.8 or 4.9. The same for 4.5: 4.5.4
>>> cannot upgrade to any 4.6, 4.7 or 4.8 because it simply didn’t exist 
>>> when
>>>

[GitHub] cloudstack pull request: CLOUDSTACK-9132: API createVolume takes e...

2016-01-12 Thread nitin-maharana

Github user nitin-maharana commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1319#discussion_r49498039
  
--- Diff: server/src/com/cloud/storage/VolumeApiServiceImpl.java ---
@@ -476,6 +476,25 @@ public VolumeVO doInTransaction(TransactionStatus 
status) {
 });
 }
 
+/**
+ * Retrieves the volume name from CreateVolumeCmd object.
+ *
+ * If the retrieved volume name is null, empty or blank, then A random 
name
+ * will be generated using getRandomVolumeName method.
+ *
+ * @param cmd
+ * @return Either the retrieved name or a random name.
+ */
+public String getVolumeNameFromCommand(CreateVolumeCmd cmd) {
+String userSpecifiedName = cmd.getVolumeName();
+
+if 
(org.apache.commons.lang.StringUtils.isBlank(userSpecifiedName)) {
--- End diff --

@mike-tutkowski : Exactly there is one more StringUtils. If you put this it 
will conflict. I tried in that way but it gives error.


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

[GitHub] cloudstack pull request: CLOUDSTACK-9132: API createVolume takes e...

2016-01-12 Thread mike-tutkowski

Github user mike-tutkowski commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1319#discussion_r49498772
  
--- Diff: server/src/com/cloud/storage/VolumeApiServiceImpl.java ---
@@ -476,6 +476,25 @@ public VolumeVO doInTransaction(TransactionStatus 
status) {
 });
 }
 
+/**
+ * Retrieves the volume name from CreateVolumeCmd object.
+ *
+ * If the retrieved volume name is null, empty or blank, then A random 
name
+ * will be generated using getRandomVolumeName method.
+ *
+ * @param cmd
+ * @return Either the retrieved name or a random name.
+ */
+public String getVolumeNameFromCommand(CreateVolumeCmd cmd) {
+String userSpecifiedName = cmd.getVolumeName();
+
+if 
(org.apache.commons.lang.StringUtils.isBlank(userSpecifiedName)) {
--- End diff --

Cool...then it all looks good to me.

Unfortunately, at the time being, I have my dev system in a state that 
would make it difficult and time consuming for me to test this.

If you do require a tester, please let me know. It might take a few days, 
though, before I finish up my current project and can put this code on my 
system.

Thanks


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: LTS release or not

2016-01-12 Thread Nux!

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" 
> 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!"  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" 
>>> 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 Wheeler"  wrote:
>>> 
Depending on how far back the problem originated, this may not be
practical.
The code might have been massaged many times or code may have been
written that depends on the buggy behaviour.

If the bug "was always there" but no one had figured out the exploit, it
might not be possible to identify any particular commit at all.

Would your solution trigger a whole bunch of new releases - 4.4.x,
4.5.y, 4.6.z, 4.7.1, etc. or would the fix just be applied to the branch
and noted while we wait for enough to accumulate to trigger a new
release? Who would want to work on 4.4.x release?

The amount of testing required to support all that backporting would
certainly deter people from fixing old bugs!

No code is bug free so I am not sure how bad it is to say that a bug
will only be fixed in the LTS and current release.

System administrators can then decide if the bug is worth an update to
the fixed version or should be fixed on the release that they currently
run,  causing a local fork that they will deal with during their next
upgrade cycle.


Ron


On 12/01/2016 2:18 AM, Daan Hoogland wrote:
> ok, one last €0,01: any bug should be fixed not on the branch but on the
> commit it was introduced in and thenn be merged forward. It can then be
> merged into any branch that contains the offending commit and there is no
> longer any difference between LTS or anything else. Am I speaking
> Kardeshian? I am really surprised no one in this list sees source code and
> release management this way.
>
> On Mon, Jan 11, 2016 at 5:34 PM, Ron Wheeler 
> > wrote:
>> There may have to be some rules about patches such as
>> "You may not apply any bug fix to a minor release that will break the
>> upgrade path."
>> So 4.6.0, 4.6.1 and 4.6.2 can all be upgraded to 4.7.0 or the latest 
>> 4.7.x
>> If a user absolutely needs a fix that breaks this, then it is their
>> problem to upgrade to 4.7.x rather than building a long-term problem 
>> into a
>> stable branch.
>> At some point no one will be happy with the latest 4.6.x and everyone 
>> will
>> upgraded.
>>
>> Any user that applies the offending patch to 4.6.2 should know that they
>> have created their own misery and will have to work out the upgrade at 
>> some
>> point or continue their private fork forever.
>>
>> There is nothing wrong to saying that "Bug xx is only fixed in version
>> 4.8.0 and later".
>> Even if version 4.6.5 came out a month after 4.8.0, bug xx is not fixed.
>> No piece of software is bug-free so we are really discussing what happens
>> once a bug is found and a fix is available.
>> 4.6.5 will run exactly like it did before the bug was found.
>>
>> Bugs that will cause update issues will trigger a new major release.
>> If the current supported releases are 4.6.2 and 4.7.1 then the bug will
>> cause a 4.8.0 to come into existence with an upgrade path that goes from
>> 4.6.2 to 4.7.0 (or 4.7.1 which should be the identical upgrade) to 4.8.0
>>
>>
>> My 2 cents!
>> Ron
>>
>>
>>
>>
>> On 11/01/2016 10:23 AM, Rene Moser wrote:
>>
>>> Hi Remi
>>>
>>> On 01/11/2016 0

[GitHub] cloudstack pull request: CLOUDSTACK-9160: Remove unused folder(s)/...

2016-01-12 Thread rodrigo93

Github user rodrigo93 commented on the pull request:

https://github.com/apache/cloudstack/pull/1238#issuecomment-171046691
  
Nice @borisroman, can you send it to test it again?
It seems that Jenkins is not working...


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

[GitHub] cloudstack pull request: Fix Sync of template.properties in Swift

2016-01-12 Thread syed

GitHub user syed opened a pull request:

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

Fix Sync of template.properties in Swift

When using Swift as a secondary storage, we create a template.properties 
file which stores the metadata about the template. Currently the data which is 
present in the file is incorrect which leads to templates becoming unavailable 
after they are downloaded. This fix makes sure that the template.properties has 
the correct "path" set so that templates are available. 

I've also done a bit of cleanup and made the code bit more clean. 


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/syed/cloudstack swift-restart-fix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1331.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1331


commit 1b9ff622f2b9a38e65e31c7f803fd8d283f5d36f
Author: Syed 
Date:   2015-12-14T22:37:28Z

Fix Sync of template.properties in Swift




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

[GitHub] cloudstack pull request: Add ability to download templates in Swif...

2016-01-12 Thread syed

GitHub user syed opened a pull request:

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

Add ability to download templates in Swift

This PR adds the ability to download templates when using Swift as a 
secondary storage. Uses the "temp_url" feature of Swift so that tempates can be 
downloaded without authenticaiton. 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/syed/cloudstack swift-download

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1332.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1332


commit 0015d94f4ef185ecee94c00a4b8cf1e019b62276
Author: Syed 
Date:   2015-12-14T22:32:56Z

Add ability to download templates in Swift




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

Build failed in Jenkins: build-master-slowbuild #2970

2016-01-12 Thread jenkins

See 

--
[...truncated 28723 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[1.766s]
[INFO] Apache CloudStack . SUCCESS [2.041s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.793s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [19.097s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:30.729s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.099s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.895s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [27.106s]
[INFO] Apache CloudStack API . SUCCESS [1:59.054s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.509s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [29.303s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.088s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [27.791s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [24.949s]
[INFO] Apache CloudStack Core  SUCCESS [1:21.489s]
[INFO] Apache CloudStack Agents .. SUCCESS [36.304s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [37.216s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.296s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:07.201s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [39.878s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.488s]
[INFO] Apache CloudStack Server .. SUCCESS [4:12.127s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [37.595s]
[INFO] Apache CloudStack Usage Server  SUCCESS [43.540s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:21.000s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.066s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.466s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [54.973s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [48.647s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [29.670s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.012s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [25.656s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [21.229s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [34.718s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.680s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [7.665s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [0.975s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.418s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.649s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[37.205s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.443s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.237s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [16.832s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.796s]
[INFO] Apache Cloud

cloudstack devs at fosdem?

2016-01-12 Thread Laszlo Hornyak

Hi List,

Anyone planing to visit fosdem this year? It would be great to meet there.

Best regards,
Laszlo

-- 

EOF

Build failed in Jenkins: build-master-slowbuild #2971

2016-01-12 Thread jenkins

See 

--
[...truncated 28733 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[1.774s]
[INFO] Apache CloudStack . SUCCESS [2.149s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.771s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [19.094s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:29.427s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.103s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.946s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [27.569s]
[INFO] Apache CloudStack API . SUCCESS [1:58.669s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.589s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [31.483s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.084s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [27.815s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [25.686s]
[INFO] Apache CloudStack Core  SUCCESS [1:22.247s]
[INFO] Apache CloudStack Agents .. SUCCESS [36.255s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [36.592s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.056s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:07.924s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [40.997s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.422s]
[INFO] Apache CloudStack Server .. SUCCESS [4:13.935s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [37.044s]
[INFO] Apache CloudStack Usage Server  SUCCESS [43.888s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:22.013s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.068s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.435s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [54.086s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [49.212s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [29.586s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.408s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [32.182s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [20.634s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [35.234s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [13.120s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [8.208s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [1.023s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.395s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.702s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[35.360s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.342s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.160s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [14.947s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.532s]
[INFO] Apache Cloud

Build failed in Jenkins: build-master-slowbuild #2972

2016-01-12 Thread jenkins

See 

--
[...truncated 28723 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[2.805s]
[INFO] Apache CloudStack . SUCCESS [2.920s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.973s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [19.281s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:29.505s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.158s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.580s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [27.767s]
[INFO] Apache CloudStack API . SUCCESS [1:48.718s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.838s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [30.439s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.095s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [27.832s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [24.686s]
[INFO] Apache CloudStack Core  SUCCESS [1:21.027s]
[INFO] Apache CloudStack Agents .. SUCCESS [36.345s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [36.437s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [13.961s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:05.756s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [40.973s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.071s]
[INFO] Apache CloudStack Server .. SUCCESS [4:11.355s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [37.807s]
[INFO] Apache CloudStack Usage Server  SUCCESS [43.698s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:20.937s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.071s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.512s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [55.124s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [48.268s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [30.029s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.505s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [30.890s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [22.808s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [36.518s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.469s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [8.325s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [0.972s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.522s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.630s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[35.528s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.765s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.377s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [16.208s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.931s]
[INFO] Apache Cloud

[GitHub] cloudstack pull request: CLOUDSTACK-9132: API createVolume takes e...

2016-01-12 Thread nitin-maharana

Github user nitin-maharana commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1319#discussion_r49551329
  
--- Diff: server/src/com/cloud/storage/VolumeApiServiceImpl.java ---
@@ -476,6 +476,25 @@ public VolumeVO doInTransaction(TransactionStatus 
status) {
 });
 }
 
+/**
+ * Retrieves the volume name from CreateVolumeCmd object.
+ *
+ * If the retrieved volume name is null, empty or blank, then A random 
name
+ * will be generated using getRandomVolumeName method.
+ *
+ * @param cmd
+ * @return Either the retrieved name or a random name.
+ */
+public String getVolumeNameFromCommand(CreateVolumeCmd cmd) {
+String userSpecifiedName = cmd.getVolumeName();
+
+if 
(org.apache.commons.lang.StringUtils.isBlank(userSpecifiedName)) {
--- End diff --

Yes, you can test the change. But I have tested this on my environment. Its 
working fine. Thanks.


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

[GitHub] cloudstack pull request: CLOUDSTACK-9198: Virtual router gets depl...

2016-01-12 Thread anshul1886

Github user anshul1886 commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1278#discussion_r49552290
  
--- Diff: server/src/com/cloud/network/router/NetworkHelperImpl.java ---
@@ -509,7 +511,9 @@ public DomainRouterVO deployRouter(final 
RouterDeploymentDefinition routerDeploy
 
 if (startRouter) {
 try {
-router = startVirtualRouter(router, 
_accountMgr.getSystemUser(), _accountMgr.getSystemAccount(), 
routerDeploymentDefinition.getParams());
+final Account caller = 
CallContext.current().getCallingAccount();
--- End diff --

@GabrielBrascher Extracting those lines in a method will remove the 
contextual information from them and will impact the understanding in future so 
it is done this way.


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

[GitHub] cloudstack pull request: CLOUDSTACK-9198: Virtual router gets depl...

2016-01-12 Thread anshul1886

Github user anshul1886 commented on the pull request:

https://github.com/apache/cloudstack/pull/1278#issuecomment-171169936
  
@GabrielBrascher System User can start VR on disabled Pod.


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

[GitHub] cloudstack pull request: CLOUDSTACK-8867: Added retry logic to rec...

2016-01-12 Thread anshul1886

Github user anshul1886 commented on the pull request:

https://github.com/apache/cloudstack/pull/1269#issuecomment-171172466
  
@GabrielBrascher That block of code is in synchronised block.  


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

Build failed in Jenkins: build-master-slowbuild #2973

2016-01-12 Thread jenkins

See 

--
[...truncated 28723 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[2.759s]
[INFO] Apache CloudStack . SUCCESS [3.081s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.979s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [18.887s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:29.708s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.115s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.869s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [28.119s]
[INFO] Apache CloudStack API . SUCCESS [1:47.859s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.652s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [30.548s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.096s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [27.963s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [25.039s]
[INFO] Apache CloudStack Core  SUCCESS [1:20.329s]
[INFO] Apache CloudStack Agents .. SUCCESS [36.176s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [36.494s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.114s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:07.268s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [40.570s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.245s]
[INFO] Apache CloudStack Server .. SUCCESS [4:15.595s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [37.714s]
[INFO] Apache CloudStack Usage Server  SUCCESS [44.497s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:20.884s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.069s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.430s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [53.409s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [47.942s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [31.481s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.491s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [25.685s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [20.426s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [35.460s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.267s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [8.089s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [0.971s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.816s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.786s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[35.427s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.159s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [24.026s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [16.741s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.845s]
[INFO] Apache Cloud

[GitHub] cloudstack pull request: CLOUDSTACK-9132: API createVolume takes e...

2016-01-12 Thread nitin-maharana

Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/1319#issuecomment-171184133
  
@remibergsma @DaanHoogland : It has got 4 LGTMs. Is it going to be merged? 
Should it be reviewed by some more people? Thanks.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Thoughts on Citrix announcement yesterday

2016-01-12 Thread Wei ZHOU

Thanks Citrix for the large contributions !

As far as I know, some core members left Citrix in the last two years. I
think this deal does not have big impact for us.

-Wei


2016-01-12 17:20 GMT+01:00 Sebastien Goasguen :

> Hi everyone (cross-posting),
>
> Yesterday Citrix announced that it sold its CloudPlatform business to
> Accelerite from Persistent Systems [1]
>
> As you know CloudPlatform is Citrix’s commercial distribution of Apache
> CloudStack. I wanted to share a few thoughts on what this means for
> CloudStack.
>
> One of the core tenet of the Apache Software Foundation is non-affiliation
> to companies, as such all of us on these lists participate and contribute
> to CloudStack as individuals. While the majority of us who are contributing
> daily to CloudStack are actually doing it as part of our day jobs we still
> voice our opinions as individuals and companies do not (and should not)
> have influence on what we do. This is one of the things that makes ASF
> great. This is also one of the reasons why the ASF  and us as a project
> will not comment on this announcement. It is Citrix’s business, not ours.
>
> That said, Citrix gave CloudStack to the ASF back in 2012 and contributed
> heavily in the early days to its development and maintenance. We should be
> thankful to Citrix for donating this software and helping the community
> grow. Giving it to the ASF was also the move that allows us to keep on
> going like “business” as usual. We as a project do not depend on Citrix.
> Hence Citrix selling its CloudPlatform business does not change our day to
> day.
>
> Over the years it is fair to say that Citrix involvement through the many
> individuals participating on these lists as diminished, with the vast
> majority of the work now carried on by others. If we were to do a ASF
> “faux-pas” and actually check affiliation of the folks that are doing most
> of the development and release work, we would see other companies than
> Citrix. Companies offering CloudStack services but also and mostly
> CloudStack users, a few doing it as a hobby and most because their company
> uses it. This is open source at its core, folks using a software, loving
> it, loving their peers, and contributing back for the benefit of everyone.
>
> It is impossible for me to say what Accelerite will do, I have had no
> contact with them so far and did not know this sale was coming. Neither do
> I know what will happen to all the fine Citrix engineers that were still
> working on CloudStack. Whatever they do, I wish them the best and thank
> them for the dedication to our project over the years. Early indication
> from the press release seems to indicate that Accelerite will engage with
> us. If they do, we will welcome them like any contributors to an ASF
> project. With openness, transparency and respect (the Apache way).
>
> I do want to mention that I think this may be an opportunity for
> CloudStack. Observers might think that our project is dead because of
> Citrix selling its business, but they would be mis-informed about the
> nature of ASF projects. I actually believe the contrary and think this will
> be a time where more users and potentially companies will engage more
> actively. They will see that the route to a successful Cloud is through
> engaging and becoming part of our community. They will also finally stop
> thinking that CloudStack is a Citrix product and that might be the kicker
> that brings them on board.
>
> Finally, being a technical guy, I like to focus on technical things. We
> have done some great strides over the past 8 months, we have stabilized
> CloudStack and are now releasing faster than ever, we have dockerized, we
> have pluginized, we have had several events... In september we will go to
> Brazil for CCC. Brazil is seeing a huge growth in CloudStack adoption.
>
> We still have a ton to do, from removing technical debt, fixing security
> issues, improving packaging, making CloudStack ever more easier to develop
> and use. This has not changed. We have some very important discussions
> going on around LTS and GitHub hosting. If anything I think the container
> movement is a bigger threat to our project than Citrix’s announcement. As
> companies start to embrace the container ecosystem and building
> containerized applications, what happens to CloudStack ? How does
> CloudStack work in a container world ? The same question are valid for
> OpenStack by the way, I just don’t buy into the Magnum effort, but I
> digress :)
>
> So thank you Citrix, we hope to welcome Accelerite and let’s keep on
> Stacking,
>
> [1]
> https://www.citrix.com/blogs/2016/01/11/a-new-home-accelerite-to-acquire-cloudplatform/
>
> -Sebastien
> VP Apache CloudStack

40 matches

Mail list logo