[4.6] KVM Build issues

[Erik Weber]

I keep getting this when trying to build the latest master, anyone know of
a fix?

---
 T E S T S
---
Running org.apache.cloudstack.utils.linux.MemStatTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.036
sec - in org.apache.cloudstack.utils.linux.MemStatTest
Running com.cloud.hypervisor.kvm.resource.LibvirtVifDriverTest
log4j:WARN No appenders could be found for logger
(com.cloud.hypervisor.kvm.resource.LibvirtComputingResource).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig
for more info.
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.478
sec - in com.cloud.hypervisor.kvm.resource.LibvirtVifDriverTest
Running com.cloud.hypervisor.kvm.resource.LibvirtSecretDefTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009
sec - in com.cloud.hypervisor.kvm.resource.LibvirtSecretDefTest
Running com.cloud.hypervisor.kvm.resource.LibvirtVMDefTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014
sec - in com.cloud.hypervisor.kvm.resource.LibvirtVMDefTest
Running com.cloud.hypervisor.kvm.resource.LibvirtComputingResourceTest
libvirt: XML-RPC error : unable to connect to server at
'127.0.0.100:16509': Connection refused
Tests run: 143, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
2.664 sec <<< FAILURE! - in
com.cloud.hypervisor.kvm.resource.LibvirtComputingResourceTest
testMigrateCommand(com.cloud.hypervisor.kvm.resource.LibvirtComputingResourceTest)
 Time elapsed: 0.27 sec  <<< FAILURE!
java.lang.AssertionError: Expected exception: java.lang.UnsatisfiedLinkError
at 
org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:32)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at 
org.mockito.internal.runners.JUnit45AndHigherRunnerImpl.run(JUnit45AndHigherRunnerImpl.java:37)
at 
org.mockito.runners.MockitoJUnitRunner.run(MockitoJUnitRunner.java:62)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

Running com.cloud.hypervisor.kvm.resource.LibvirtDomainXMLParserTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011
sec - in com.cloud.hypervisor.kvm.resource.LibvirtDomainXMLParserTest
Running com.cloud.hypervisor.kvm.resource.LibvirtStoragePoolDefTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004
sec - in com.cloud.hypervisor.kvm.resource.LibvirtStoragePoolDefTest
Running com.cloud.hypervisor.kvm.storage.KVMStorageProcessorTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
- in com.cloud.hypervisor.kvm.storage.KVMStorageProcessorTest

Results :

Failed tests:
  LibvirtComputingResourceTest.testMigrateCommand Expected exception:
java.lang.UnsatisfiedLinkError


-- 

Erik

Re: [4.6] KVM Build issues

[Rafael Fonseca]

Hi Eric,

I've stumbled into the same issue, already reported it to Wilder, who is
having a look at fixing this the proper way :)
It happens because you have some native KVM libraries installed.
You can either skiptests to get the packaging built or you can change what
the test expects if you want to run the other tests as well.
To fix it for now, just run
 sed -i -e 's/(expected = UnsatisfiedLinkError.class)//'
./plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/LibvirtComputingResourceTest.java

:)

On Mon, Jun 1, 2015 at 9:18 AM, Erik Weber  wrote:

> I keep getting this when trying to build the latest master, anyone know of
> a fix?
>
> ---
>  T E S T S
> ---
> Running org.apache.cloudstack.utils.linux.MemStatTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.036
> sec - in org.apache.cloudstack.utils.linux.MemStatTest
> Running com.cloud.hypervisor.kvm.resource.LibvirtVifDriverTest
> log4j:WARN No appenders could be found for logger
> (com.cloud.hypervisor.kvm.resource.LibvirtComputingResource).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig
> for more info.
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.478
> sec - in com.cloud.hypervisor.kvm.resource.LibvirtVifDriverTest
> Running com.cloud.hypervisor.kvm.resource.LibvirtSecretDefTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009
> sec - in com.cloud.hypervisor.kvm.resource.LibvirtSecretDefTest
> Running com.cloud.hypervisor.kvm.resource.LibvirtVMDefTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014
> sec - in com.cloud.hypervisor.kvm.resource.LibvirtVMDefTest
> Running com.cloud.hypervisor.kvm.resource.LibvirtComputingResourceTest
> libvirt: XML-RPC error : unable to connect to server at
> '127.0.0.100:16509': Connection refused
> Tests run: 143, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 2.664 sec <<< FAILURE! - in
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResourceTest
>
> testMigrateCommand(com.cloud.hypervisor.kvm.resource.LibvirtComputingResourceTest)
>  Time elapsed: 0.27 sec  <<< FAILURE!
> java.lang.AssertionError: Expected exception:
> java.lang.UnsatisfiedLinkError
> at
> org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:32)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.mockito.internal.runners.JUnit45AndHigherRunnerImpl.run(JUnit45AndHigherRunnerImpl.java:37)
> at
> org.mockito.runners.MockitoJUnitRunner.run(MockitoJUnitRunner.java:62)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
>
> Running com.cloud.hypervisor.kvm.resource.LibvirtDomainXMLParserTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011
> sec - in com.cloud.hypervisor.kvm.resource.LibvirtDomainXMLParserTest
> Running com.cloud.hypervisor.kvm.resource.LibvirtStoragePoolDefTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004
> sec - in com.cloud.hypervisor.kvm.resource.LibvirtStoragePoolDefTest
> Running com.cloud.hypervisor.kvm.storage.KVMStorageProcessorTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
> - in com.cloud.hypervisor.kvm.storage.KVMStorageProcessorTest
>
> Results :
>
> Failed tests:
>   LibvirtComputingResourceTest.testMigrateCommand Expected exception:
> java.lang.UnsatisfiedLinkError
>
>
> --
>
> Erik
>

Re: [4.6] KVM Build issues

[Erik Weber]

Thanks Rafael,

Don't know what libraries that would be, the only thing installed I could
see is libvirt-client (which is needed by puppet).

I'll try your fix :-)

-- 
Erik

On Mon, Jun 1, 2015 at 10:17 AM, Rafael Fonseca 
wrote:

> Hi Eric,
>
> I've stumbled into the same issue, already reported it to Wilder, who is
> having a look at fixing this the proper way :)
> It happens because you have some native KVM libraries installed.
> You can either skiptests to get the packaging built or you can change what
> the test expects if you want to run the other tests as well.
> To fix it for now, just run
>  sed -i -e 's/(expected = UnsatisfiedLinkError.class)//'
>
> ./plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/LibvirtComputingResourceTest.java
>
> :)
>
> On Mon, Jun 1, 2015 at 9:18 AM, Erik Weber  wrote:
>
> > I keep getting this when trying to build the latest master, anyone know
> of
> > a fix?
> >
> > ---
> >  T E S T S
> > ---
> > Running org.apache.cloudstack.utils.linux.MemStatTest
> > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.036
> > sec - in org.apache.cloudstack.utils.linux.MemStatTest
> > Running com.cloud.hypervisor.kvm.resource.LibvirtVifDriverTest
> > log4j:WARN No appenders could be found for logger
> > (com.cloud.hypervisor.kvm.resource.LibvirtComputingResource).
> > log4j:WARN Please initialize the log4j system properly.
> > log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig
> > for more info.
> > Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.478
> > sec - in com.cloud.hypervisor.kvm.resource.LibvirtVifDriverTest
> > Running com.cloud.hypervisor.kvm.resource.LibvirtSecretDefTest
> > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009
> > sec - in com.cloud.hypervisor.kvm.resource.LibvirtSecretDefTest
> > Running com.cloud.hypervisor.kvm.resource.LibvirtVMDefTest
> > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014
> > sec - in com.cloud.hypervisor.kvm.resource.LibvirtVMDefTest
> > Running com.cloud.hypervisor.kvm.resource.LibvirtComputingResourceTest
> > libvirt: XML-RPC error : unable to connect to server at
> > '127.0.0.100:16509': Connection refused
> > Tests run: 143, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> > 2.664 sec <<< FAILURE! - in
> > com.cloud.hypervisor.kvm.resource.LibvirtComputingResourceTest
> >
> >
> testMigrateCommand(com.cloud.hypervisor.kvm.resource.LibvirtComputingResourceTest)
> >  Time elapsed: 0.27 sec  <<< FAILURE!
> > java.lang.AssertionError: Expected exception:
> > java.lang.UnsatisfiedLinkError
> > at
> >
> org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:32)
> > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> > at
> >
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> > at
> >
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> > at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> > at
> > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> > at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> > at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> > at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> > at
> >
> org.mockito.internal.runners.JUnit45AndHigherRunnerImpl.run(JUnit45AndHigherRunnerImpl.java:37)
> > at
> > org.mockito.runners.MockitoJUnitRunner.run(MockitoJUnitRunner.java:62)
> > at
> >
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> > at
> >
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> > at
> >
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> > at
> >
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> > at
> >
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> > at
> >
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> > at
> > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> >
> > Running com.cloud.hypervisor.kvm.resource.LibvirtDomainXMLParserTest
> > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011
> > sec - in com.cloud.hypervisor.kvm.resource.LibvirtDomainXMLParserTest
> > Running com.cloud.hypervisor.kvm.resource.LibvirtStoragePoolDefTest
> > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004
> > sec - in com.cloud.hypervisor.kvm.resource.LibvirtStoragePoolDefTest
> > Running com.clo

Re: [4.6] KVM Build issues

[Erik Weber]

While talking on building and errors, I get this when trying to build
noredist:

[INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ cloud-core ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 394 source files to
/var/lib/jenkins/workspace/cloudstack-package-rpm-master-noredist/dist/rpmbuild/BUILD/cloudstack-4.6.0-SNAPSHOT/core/target/classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] 
/var/lib/jenkins/workspace/cloudstack-package-rpm-master-noredist/dist/rpmbuild/BUILD/cloudstack-4.6.0-SNAPSHOT/core/src/com/cloud/agent/resource/virtualnetwork/ConfigHelper.java:[622,50]
error: incompatible types
[INFO] 1 error

Any idea what that could be?

-- 

Erik



On Mon, Jun 1, 2015 at 10:27 AM, Erik Weber  wrote:

> Thanks Rafael,
>
> Don't know what libraries that would be, the only thing installed I could
> see is libvirt-client (which is needed by puppet).
>
> I'll try your fix :-)
>
> --
> Erik
>
>
> On Mon, Jun 1, 2015 at 10:17 AM, Rafael Fonseca 
> wrote:
>
>> Hi Eric,
>>
>> I've stumbled into the same issue, already reported it to Wilder, who is
>> having a look at fixing this the proper way :)
>> It happens because you have some native KVM libraries installed.
>> You can either skiptests to get the packaging built or you can change what
>> the test expects if you want to run the other tests as well.
>> To fix it for now, just run
>>  sed -i -e 's/(expected = UnsatisfiedLinkError.class)//'
>>
>> ./plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/LibvirtComputingResourceTest.java
>>
>> :)
>>
>> On Mon, Jun 1, 2015 at 9:18 AM, Erik Weber  wrote:
>>
>> > I keep getting this when trying to build the latest master, anyone know
>> of
>> > a fix?
>> >
>> > ---
>> >  T E S T S
>> > ---
>> > Running org.apache.cloudstack.utils.linux.MemStatTest
>> > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.036
>> > sec - in org.apache.cloudstack.utils.linux.MemStatTest
>> > Running com.cloud.hypervisor.kvm.resource.LibvirtVifDriverTest
>> > log4j:WARN No appenders could be found for logger
>> > (com.cloud.hypervisor.kvm.resource.LibvirtComputingResource).
>> > log4j:WARN Please initialize the log4j system properly.
>> > log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig
>> > for more info.
>> > Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.478
>> > sec - in com.cloud.hypervisor.kvm.resource.LibvirtVifDriverTest
>> > Running com.cloud.hypervisor.kvm.resource.LibvirtSecretDefTest
>> > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009
>> > sec - in com.cloud.hypervisor.kvm.resource.LibvirtSecretDefTest
>> > Running com.cloud.hypervisor.kvm.resource.LibvirtVMDefTest
>> > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014
>> > sec - in com.cloud.hypervisor.kvm.resource.LibvirtVMDefTest
>> > Running com.cloud.hypervisor.kvm.resource.LibvirtComputingResourceTest
>> > libvirt: XML-RPC error : unable to connect to server at
>> > '127.0.0.100:16509': Connection refused
>> > Tests run: 143, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
>> > 2.664 sec <<< FAILURE! - in
>> > com.cloud.hypervisor.kvm.resource.LibvirtComputingResourceTest
>> >
>> >
>> testMigrateCommand(com.cloud.hypervisor.kvm.resource.LibvirtComputingResourceTest)
>> >  Time elapsed: 0.27 sec  <<< FAILURE!
>> > java.lang.AssertionError: Expected exception:
>> > java.lang.UnsatisfiedLinkError
>> > at
>> >
>> org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:32)
>> > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>> > at
>> >
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>> > at
>> >
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>> > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>> > at
>> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>> > at
>> > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>> > at
>> org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>> > at
>> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>> > at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>> > at
>> >
>> org.mockito.internal.runners.JUnit45AndHigherRunnerImpl.run(JUnit45AndHigherRunnerImpl.java:37)
>> > at
>> > org.mockito.runners.MockitoJUnitRunner.run(MockitoJUnitRunner.java:62)
>> > at
>> >
>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>> > at
>> >
>> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>> >   

Re: [VOTE] release candidate 4.4.4

[Daan Hoogland]

Guess we'll be making a new rc. The value can be 0.0.0 for my part, it must
be an operator decision to set the MinVRVersion if it must be higher. It
will always be an upgrade matter and any seeded template should be accepted
as per the installation notes. Of course the other side of the issue is
whether a version will work at all. The operator can create a version of
the template with their own versioning scheme, however. I should be writing
all this in another {DISCUSS]-thread.

cancelling the RC to add code for Bruno's requirement.

Op ma 1 jun. 2015 om 08:35 schreef Milamber :

>
> Please note: I my case, there isn't an upgrade, I have the issue with
> 4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
> 4.4-RC20150529T2004)
>
>
>
>
> On 01/06/2015 07:22, Erik Weber wrote:
> > If it means that all upgrades are unable to do VR related tasks (
> starting
> > VMs for one.. ), I'd call that regression and redo.
> > Relying on all our users to do manual fixing just because we don't want
> to
> > call off the RC is bad IMHO.
> >
> >
>
>

Re: [VOTE] release candidate 4.4.4

[Remi Bergsma]

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

Regards,
Remi


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

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

Re: [VOTE] release candidate 4.4.4

[Daan Hoogland]

So we will have to include an update in every release and we will probably
forget about that pretty soon.

Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma :

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

Re: [RFC] SAML2 plugin improvements

[Erik Weber]

Thanks for the update Rohit.

Is this merged to master?

If you want I can setup one (or more) account(s) for you in our pre
production environment, so that you can test it with your development code.
Contact me offlist if that's something you'd want.

If it's merged to master I can do a test.

-- 
Erik

On Fri, May 29, 2015 at 6:49 PM, Rohit Yadav 
wrote:

> Hi,
>
> Just want to share that SAML plugin now supports HTTP-POST and
> HTTP-Redirect bindings and in my local setup it seems to be working with
> Shibboleth and also with SSOCircle, OpenFiede and TestShib:
> https://github.com/apache/cloudstack/commits/saml-production-grade
>
> Erik - the current SAML implementation aims to support SAML v2.0 spec and
> qualify samlint.org compatibility guide. I’m not sure about ADFS and how
> compatible it is with SAML 2.0. In theory, you can also use Microsoft AD
> with Shibboleth. If you plan on using it with ADFS, can you test this
> branch and suggest errors you encounter?
>
> I’m testing with available opensource IdPs such as Shibboleth IdP and
> public IdP servers such as SSOCircle, OpenFiede, OneLogin etc. In case
> you're planning to use the SAML auth plugin in your environment, please
> share your feedback and use-cases so the plugin implementation can be more
> general purpose and support a wide variety of IdP servers. Thanks.
>
> > On 12-May-2015, at 10:02 pm, Erik Weber  wrote:
> >
> > I don't actually remember the specifics, and I've scratched the lab.
> >
> > But I think there was an issue with fetching the metadata (from the IdP)
> > atleast.
> >
> > Plus, ADFS is claims based, I don't know if the current SAML 2.0
> > implementation in CloudStack is claims aware or not?
> >
> >
> > --
> > Erik
> >
> > On Tue, May 12, 2015 at 9:46 PM, Rohit Yadav 
> > wrote:
> >
> >> Hi Erik,
> >>
> >> Thanks for your feedback, can you share more details about your
> use-case.
> >> I remember we had a discussion where we tried to make it work, but don’t
> >> remember why it failed for your environment. What SAML bindings do we
> need
> >> to support to make it work with MS ADFS any other subtle details?
> >>
> >>> On 12-May-2015, at 6:33 pm, Erik Weber  wrote:
> >>>
> >>> Great news Rohit,
> >>>
> >>> Would love to see it support Microsoft ADFS as IdP.
> >>>
> >>>
> >>> Erik
> >>>
> >>> Den tirsdag 12. mai 2015 skrev Rohit Yadav 
> >>> følgende:
> >>>
>  Hi all,
> 
>  Based on the feedback several friends in the community on different
>  use-cases of using a federated login system based on SAML2 with
> >> CloudStack,
>  I’m soon planning to address them in the SAML plugin implement
> focusing
> >> on
>  pain points around interoperability, IdP support, security and ease of
> >> use.
> 
>  I’ve updated the specification to reflect some of those aspects I’ve
>  gathered in last few months:
> 
> 
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SAML+2.0+Plugin#SAML2.0Plugin-Version2:InProgress
> 
>  Please advise improvements you would like to see, or share pain points
>  with the current implementation. Thanks.
> 
>  Regards,
>  Rohit Yadav
>  Software Architect, ShapeBlue
>  M. +91 88 262 30892 | rohit.ya...@shapeblue.com 
>  Blog: bhaisaab.org | Twitter: @_bhaisaab
> 
> 
> 
>  Find out more about ShapeBlue and our range of CloudStack related
> >> services
> 
>  IaaS Cloud Design & Build<
>  http://shapeblue.com/iaas-cloud-design-and-build//>
>  CSForge – rapid IaaS deployment framework<
> http://shapeblue.com/csforge/
> >>>
>  CloudStack Consulting
>  CloudStack Software Engineering<
>  http://shapeblue.com/cloudstack-software-engineering/>
>  CloudStack Infrastructure Support<
>  http://shapeblue.com/cloudstack-infrastructure-support/>
>  CloudStack Bootcamp Training Courses<
>  http://shapeblue.com/cloudstack-training/>
> 
>  This email and any attachments to it may be confidential and are
> >> intended
>  solely for the use of the individual to whom it is addressed. Any
> views
> >> or
>  opinions expressed are solely those of the author and do not
> necessarily
>  represent those of Shape Blue Ltd or related companies. If you are not
> >> the
>  intended recipient of this email, you must neither take any action
> based
>  upon its contents, nor copy or show it to anyone. Please contact the
> >> sender
>  if you believe you have received this email in error. Shape Blue Ltd
> is
> >> a
>  company incorporated in England & Wales. ShapeBlue Services India LLP
> >> is a
>  company incorporated in India and is operated under license from Shape
> >> Blue
>  Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in
> >> Brasil
>  and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty
> Ltd
> >> is
>  a company registered by The Republic of South Africa 

Re: [RFC] SAML2 plugin improvements

[Rohit Yadav]

Hi Erik,

I’ll send a pull request when I’ve addressed most of the improvements, here’s 
the branch you can build from: 
https://github.com/apache/cloudstack/tree/saml-production-grade

This has same set of global settings, APIs and doc/usage, so no changes on the 
outside so far. If you need any help let me know here or offlist.

> On 01-Jun-2015, at 12:08 pm, Erik Weber  wrote:
>
> Thanks for the update Rohit.
>
> Is this merged to master?
>
> If you want I can setup one (or more) account(s) for you in our pre
> production environment, so that you can test it with your development code.
> Contact me offlist if that's something you'd want.
>
> If it's merged to master I can do a test.
>
> --
> Erik
>
> On Fri, May 29, 2015 at 6:49 PM, Rohit Yadav 
> wrote:
>
>> Hi,
>>
>> Just want to share that SAML plugin now supports HTTP-POST and
>> HTTP-Redirect bindings and in my local setup it seems to be working with
>> Shibboleth and also with SSOCircle, OpenFiede and TestShib:
>> https://github.com/apache/cloudstack/commits/saml-production-grade
>>
>> Erik - the current SAML implementation aims to support SAML v2.0 spec and
>> qualify samlint.org compatibility guide. I’m not sure about ADFS and how
>> compatible it is with SAML 2.0. In theory, you can also use Microsoft AD
>> with Shibboleth. If you plan on using it with ADFS, can you test this
>> branch and suggest errors you encounter?
>>
>> I’m testing with available opensource IdPs such as Shibboleth IdP and
>> public IdP servers such as SSOCircle, OpenFiede, OneLogin etc. In case
>> you're planning to use the SAML auth plugin in your environment, please
>> share your feedback and use-cases so the plugin implementation can be more
>> general purpose and support a wide variety of IdP servers. Thanks.
>>
>>> On 12-May-2015, at 10:02 pm, Erik Weber  wrote:
>>>
>>> I don't actually remember the specifics, and I've scratched the lab.
>>>
>>> But I think there was an issue with fetching the metadata (from the IdP)
>>> atleast.
>>>
>>> Plus, ADFS is claims based, I don't know if the current SAML 2.0
>>> implementation in CloudStack is claims aware or not?
>>>
>>>
>>> --
>>> Erik
>>>
>>> On Tue, May 12, 2015 at 9:46 PM, Rohit Yadav 
>>> wrote:
>>>
 Hi Erik,

 Thanks for your feedback, can you share more details about your
>> use-case.
 I remember we had a discussion where we tried to make it work, but don’t
 remember why it failed for your environment. What SAML bindings do we
>> need
 to support to make it work with MS ADFS any other subtle details?

> On 12-May-2015, at 6:33 pm, Erik Weber  wrote:
>
> Great news Rohit,
>
> Would love to see it support Microsoft ADFS as IdP.
>
>
> Erik
>
> Den tirsdag 12. mai 2015 skrev Rohit Yadav 
> følgende:
>
>> Hi all,
>>
>> Based on the feedback several friends in the community on different
>> use-cases of using a federated login system based on SAML2 with
 CloudStack,
>> I’m soon planning to address them in the SAML plugin implement
>> focusing
 on
>> pain points around interoperability, IdP support, security and ease of
 use.
>>
>> I’ve updated the specification to reflect some of those aspects I’ve
>> gathered in last few months:
>>
>>

>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SAML+2.0+Plugin#SAML2.0Plugin-Version2:InProgress
>>
>> Please advise improvements you would like to see, or share pain points
>> with the current implementation. Thanks.
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +91 88 262 30892 | rohit.ya...@shapeblue.com 
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>
>>
>> Find out more about ShapeBlue and our range of CloudStack related
 services
>>
>> IaaS Cloud Design & Build<
>> http://shapeblue.com/iaas-cloud-design-and-build//>
>> CSForge – rapid IaaS deployment framework<
>> http://shapeblue.com/csforge/
>
>> CloudStack Consulting
>> CloudStack Software Engineering<
>> http://shapeblue.com/cloudstack-software-engineering/>
>> CloudStack Infrastructure Support<
>> http://shapeblue.com/cloudstack-infrastructure-support/>
>> CloudStack Bootcamp Training Courses<
>> http://shapeblue.com/cloudstack-training/>
>>
>> This email and any attachments to it may be confidential and are
 intended
>> solely for the use of the individual to whom it is addressed. Any
>> views
 or
>> opinions expressed are solely those of the author and do not
>> necessarily
>> represent those of Shape Blue Ltd or related companies. If you are not
 the
>> intended recipient of this email, you must neither take any action
>> based
>> upon its contents, nor copy or show it to anyone. Please contact the
 sender
>> if you believe you have received this email in error. Sh

Re: [RFC] SAML2 plugin improvements

[Erik Weber]

Thanks. Will give it a try.

-- 
Erik

On Mon, Jun 1, 2015 at 12:17 PM, Rohit Yadav 
wrote:

> Hi Erik,
>
> I’ll send a pull request when I’ve addressed most of the improvements,
> here’s the branch you can build from:
> https://github.com/apache/cloudstack/tree/saml-production-grade
>
> This has same set of global settings, APIs and doc/usage, so no changes on
> the outside so far. If you need any help let me know here or offlist.
>
> > On 01-Jun-2015, at 12:08 pm, Erik Weber  wrote:
> >
> > Thanks for the update Rohit.
> >
> > Is this merged to master?
> >
> > If you want I can setup one (or more) account(s) for you in our pre
> > production environment, so that you can test it with your development
> code.
> > Contact me offlist if that's something you'd want.
> >
> > If it's merged to master I can do a test.
> >
> > --
> > Erik
> >
> > On Fri, May 29, 2015 at 6:49 PM, Rohit Yadav 
> > wrote:
> >
> >> Hi,
> >>
> >> Just want to share that SAML plugin now supports HTTP-POST and
> >> HTTP-Redirect bindings and in my local setup it seems to be working with
> >> Shibboleth and also with SSOCircle, OpenFiede and TestShib:
> >> https://github.com/apache/cloudstack/commits/saml-production-grade
> >>
> >> Erik - the current SAML implementation aims to support SAML v2.0 spec
> and
> >> qualify samlint.org compatibility guide. I’m not sure about ADFS and
> how
> >> compatible it is with SAML 2.0. In theory, you can also use Microsoft AD
> >> with Shibboleth. If you plan on using it with ADFS, can you test this
> >> branch and suggest errors you encounter?
> >>
> >> I’m testing with available opensource IdPs such as Shibboleth IdP and
> >> public IdP servers such as SSOCircle, OpenFiede, OneLogin etc. In case
> >> you're planning to use the SAML auth plugin in your environment, please
> >> share your feedback and use-cases so the plugin implementation can be
> more
> >> general purpose and support a wide variety of IdP servers. Thanks.
> >>
> >>> On 12-May-2015, at 10:02 pm, Erik Weber  wrote:
> >>>
> >>> I don't actually remember the specifics, and I've scratched the lab.
> >>>
> >>> But I think there was an issue with fetching the metadata (from the
> IdP)
> >>> atleast.
> >>>
> >>> Plus, ADFS is claims based, I don't know if the current SAML 2.0
> >>> implementation in CloudStack is claims aware or not?
> >>>
> >>>
> >>> --
> >>> Erik
> >>>
> >>> On Tue, May 12, 2015 at 9:46 PM, Rohit Yadav <
> rohit.ya...@shapeblue.com>
> >>> wrote:
> >>>
>  Hi Erik,
> 
>  Thanks for your feedback, can you share more details about your
> >> use-case.
>  I remember we had a discussion where we tried to make it work, but
> don’t
>  remember why it failed for your environment. What SAML bindings do we
> >> need
>  to support to make it work with MS ADFS any other subtle details?
> 
> > On 12-May-2015, at 6:33 pm, Erik Weber  wrote:
> >
> > Great news Rohit,
> >
> > Would love to see it support Microsoft ADFS as IdP.
> >
> >
> > Erik
> >
> > Den tirsdag 12. mai 2015 skrev Rohit Yadav <
> rohit.ya...@shapeblue.com>
> > følgende:
> >
> >> Hi all,
> >>
> >> Based on the feedback several friends in the community on different
> >> use-cases of using a federated login system based on SAML2 with
>  CloudStack,
> >> I’m soon planning to address them in the SAML plugin implement
> >> focusing
>  on
> >> pain points around interoperability, IdP support, security and ease
> of
>  use.
> >>
> >> I’ve updated the specification to reflect some of those aspects I’ve
> >> gathered in last few months:
> >>
> >>
> 
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SAML+2.0+Plugin#SAML2.0Plugin-Version2:InProgress
> >>
> >> Please advise improvements you would like to see, or share pain
> points
> >> with the current implementation. Thanks.
> >>
> >> Regards,
> >> Rohit Yadav
> >> Software Architect, ShapeBlue
> >> M. +91 88 262 30892 | rohit.ya...@shapeblue.com 
> >> Blog: bhaisaab.org | Twitter: @_bhaisaab
> >>
> >>
> >>
> >> Find out more about ShapeBlue and our range of CloudStack related
>  services
> >>
> >> IaaS Cloud Design & Build<
> >> http://shapeblue.com/iaas-cloud-design-and-build//>
> >> CSForge – rapid IaaS deployment framework<
> >> http://shapeblue.com/csforge/
> >
> >> CloudStack Consulting
> >> CloudStack Software Engineering<
> >> http://shapeblue.com/cloudstack-software-engineering/>
> >> CloudStack Infrastructure Support<
> >> http://shapeblue.com/cloudstack-infrastructure-support/>
> >> CloudStack Bootcamp Training Courses<
> >> http://shapeblue.com/cloudstack-training/>
> >>
> >> This email and any attachments to it may be confidential and are
>  intended
> >> solely for the use of the individual to whom it is address

[GitHub] cloudstack pull request: default system vm template version

[DaanHoogland]

GitHub user DaanHoogland opened a pull request:

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

default system vm template version



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

$ git pull https://github.com/DaanHoogland/cloudstack 4.4

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

https://github.com/apache/cloudstack/pull/338.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 #338


commit d4bbbffcb5837244950392307398d3c38b20a0b1
Author: Daan Hoogland 
Date:   2015-06-01T11:14:00Z

default system vm template version




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

Re: [VOTE] release candidate 4.4.4

[Daan Hoogland]

If no objections I will reset the default to 4.4.1 (the lowest required
version) include Rafaels pr for kvm/centos packaging and create a new rc.

Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland :

> So we will have to include an update in every release and we will probably
> forget about that pretty soon.
>
> Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma :
>
>> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release, and 4.5.0
>> for 4.5.x etc. This is also close to what was hard-coded before.
>>
>> Regards,
>> Remi
>>
>>
>> 2015-06-01 11:33 GMT+02:00 Daan Hoogland :
>>
>> > Guess we'll be making a new rc. The value can be 0.0.0 for my part, it
>> must
>> > be an operator decision to set the MinVRVersion if it must be higher. It
>> > will always be an upgrade matter and any seeded template should be
>> accepted
>> > as per the installation notes. Of course the other side of the issue is
>> > whether a version will work at all. The operator can create a version of
>> > the template with their own versioning scheme, however. I should be
>> writing
>> > all this in another {DISCUSS]-thread.
>> >
>> > cancelling the RC to add code for Bruno's requirement.
>> >
>> > Op ma 1 jun. 2015 om 08:35 schreef Milamber :
>> >
>> > >
>> > > Please note: I my case, there isn't an upgrade, I have the issue with
>> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
>> > > 4.4-RC20150529T2004)
>> > >
>> > >
>> > >
>> > >
>> > > On 01/06/2015 07:22, Erik Weber wrote:
>> > > > If it means that all upgrades are unable to do VR related tasks (
>> > > starting
>> > > > VMs for one.. ), I'd call that regression and redo.
>> > > > Relying on all our users to do manual fixing just because we don't
>> want
>> > > to
>> > > > call off the RC is bad IMHO.
>> > > >
>> > > >
>> > >
>> > >
>> >
>>
>

[GitHub] cloudstack pull request: default system vm template version

[remibergsma]

Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/338#issuecomment-107404710
  
LGTM. Once Travis is OK with it, I'll merge.


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

Re: [VOTE] release candidate 4.4.4

[Milamber]

Hello Daan,

No objections. And thanks for the new RC.

Milamber

On 01/06/2015 12:17, Daan Hoogland wrote:

If no objections I will reset the default to 4.4.1 (the lowest required
version) include Rafaels pr for kvm/centos packaging and create a new rc.

Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland :


So we will have to include an update in every release and we will probably
forget about that pretty soon.

Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma :


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

Regards,
Remi


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


Guess we'll be making a new rc. The value can be 0.0.0 for my part, it

must

be an operator decision to set the MinVRVersion if it must be higher. It
will always be an upgrade matter and any seeded template should be

accepted

as per the installation notes. Of course the other side of the issue is
whether a version will work at all. The operator can create a version of
the template with their own versioning scheme, however. I should be

writing

all this in another {DISCUSS]-thread.

cancelling the RC to add code for Bruno's requirement.

Op ma 1 jun. 2015 om 08:35 schreef Milamber :


Please note: I my case, there isn't an upgrade, I have the issue with
4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
4.4-RC20150529T2004)




On 01/06/2015 07:22, Erik Weber wrote:

If it means that all upgrades are unable to do VR related tasks (

starting

VMs for one.. ), I'd call that regression and redo.
Relying on all our users to do manual fixing just because we don't

want

to

call off the RC is bad IMHO.

Modifying the Debian libvirt profile

[Nux!]

Hi,

I'm facing some problems with connectivity to the VR and want to change it's 
NIC from virtio to e1000, to test something.
Can someone point me to where I could edit this in the cloudstack agent?

Cheers,
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: Regular total loss of connectivity

[Nux!]

Thanks Simon,

link up/down has not helped, setting tso etc off on the link has not helped 
either.
Connectivity is lost as usual after ~4 hours.

I found some suggestions to try and use the e1000 nic instead of virtio, will 
do that.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Simon Weller" 
> To: "dev" , "Cloudstack Users List" 
> 
> Sent: Sunday, 31 May, 2015 22:36:56
> Subject: Re: Regular total loss of connectivity

> If you ifdown the interface on the router and then ifup it again, does the arp
> problem resolve itself?
> 
> We've seen a similar issue before caused by malicious/heavy traffic related to
> this bug:
> 
> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/997978
> 
> - Si
> 
> From: Nux! 
> Sent: Sunday, May 31, 2015 4:25 PM
> To: dev; Cloudstack Users List
> Subject: Regular total loss of connectivity
> 
> Hi,
> 
> Following a power cut, one of my cloudstack deployments is having a really 
> weird
> problem that I cannot seem to solve on my own.
> Every 3 hours all the public IPs on the VR stop responding from the Internet.
> From the VR they are of course all reachable.
> In the same VLAN as the public IPs there is another physical server, this one
> can also access the VMs on their IPs just fine.
> 
> The provider has not found the problem and hints at problems with the cloud
> platform, however cloudstack worked just fine until the power cut, not to
> mention the problem persists through HV and ACS upgrades.
> 
> I'm thinking network side arp issues or something like this, alas I am not 
> that
> good with network stuff and don't have access to it anyway.
> 
> If I reboot the VR once or twice the IPs start working again and the VMs are
> accessible from the internet.
> 
> Ideas?
> 
> Env: CentOS 6, KVM, ACS 44 to 4.5.1, Adv zone
> 
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

Re: [VOTE] release candidate 4.4.4

[Erik Weber]

Sounds reasonable to me.

-- 
Erik

On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland 
wrote:

> If no objections I will reset the default to 4.4.1 (the lowest required
> version) include Rafaels pr for kvm/centos packaging and create a new rc.
>
> Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland  >:
>
> > So we will have to include an update in every release and we will
> probably
> > forget about that pretty soon.
> >
> > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma :
> >
> >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release, and
> 4.5.0
> >> for 4.5.x etc. This is also close to what was hard-coded before.
> >>
> >> Regards,
> >> Remi
> >>
> >>
> >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland :
> >>
> >> > Guess we'll be making a new rc. The value can be 0.0.0 for my part, it
> >> must
> >> > be an operator decision to set the MinVRVersion if it must be higher.
> It
> >> > will always be an upgrade matter and any seeded template should be
> >> accepted
> >> > as per the installation notes. Of course the other side of the issue
> is
> >> > whether a version will work at all. The operator can create a version
> of
> >> > the template with their own versioning scheme, however. I should be
> >> writing
> >> > all this in another {DISCUSS]-thread.
> >> >
> >> > cancelling the RC to add code for Bruno's requirement.
> >> >
> >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber :
> >> >
> >> > >
> >> > > Please note: I my case, there isn't an upgrade, I have the issue
> with
> >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
> >> > > 4.4-RC20150529T2004)
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On 01/06/2015 07:22, Erik Weber wrote:
> >> > > > If it means that all upgrades are unable to do VR related tasks (
> >> > > starting
> >> > > > VMs for one.. ), I'd call that regression and redo.
> >> > > > Relying on all our users to do manual fixing just because we don't
> >> want
> >> > > to
> >> > > > call off the RC is bad IMHO.
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >>
> >
>

[GitHub] cloudstack pull request: default system vm template version

[remibergsma]

Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/338#issuecomment-107418442
  
Merged. @DaanHoogland please close PR.


---
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: Update debian packaging

[rsafonseca]

GitHub user rsafonseca opened a pull request:

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

Update debian packaging

This fixes build issue with  
http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-package-deb/
Reduce source package size (was including .git)
Fix a couple of dpkg-buildpackage warnings
Remove dependency on changing version on changelog to be able to build 
package after changing pom.xml
Remove nasty hack for snapshot versions on debian/rules

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

$ git pull https://github.com/rsafonseca/cloudstack debfixes44

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

https://github.com/apache/cloudstack/pull/339.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 #339


commit 3fe1c6d681e740c0f3bf30d36450ae9f3e911e8b
Author: Rafael da Fonseca 
Date:   2015-06-01T11:39:08Z

Update debian packaging




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

Third party VR / L2 support

[Christian]

Hi Sebastien,

Thank you for publishing the roadmap.


> Replace VR with h/w (srx, asa etc)


A question for all - What are the implications of expanding this feature
to support s/w appliances, such as the ASA/CSR 1000V ?


This is something that I have been implementing manually to date because:

> Improve VR, VR agent, API for VR   :)



It involves a little bit of 'creative networking' in order to suppress the
CS virtual router. Any improvements in this area would be very useful.
Even a QuickCloudNoServices-like offering for isolated networks would be
great. I¹m aware that this can be created manually, but I¹m not convinced
that this is a supported configuration.


Pushing this concept further, I¹d like to see support for Layer 2 isolated
networks. I use these for running virtual L2 devices under CS simply by
creating dummy IP address ranges and ignoring them. Again, I have to
suppress the VR, because it¹s not needed at L2.


I¹ve been doing a fair bit to push the limits of networking in CloudStack
over the last year using just VLANs and the standard API calls . I¹m happy
to answer any questions anyone may have.


Best regards,

-Christian

--
Christian Lafferty




On 31/05/2015 05:08, "Sebastien Goasguen"  wrote:

>Hi folks,
>
>Several folks on this list representing their company¹s interest shared
>with me their fixes/features plans and hopes.
>
>I believe we can use this to build a solid roadmap for our project,
>something that we have never had.
>
>I captured a lot of bullet items and tried to categorize them to start
>building a roadmap.
>
>You can see the document on our wiki at:
>
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Roadmap
>
>I would like to call everyone to make this page a great living document
>that will be up to date and help us drive cloudstack forward.
>
>First order of business would be to add description to each item and if
>you are working on it or would like to help out, write your name down !
>
>
>Cheers,
>
>
>-Sebastien

Re: [VOTE] release candidate 4.4.4

[Rafael Fonseca]

Hey Daan,
I've also created a PR for fixing a couple of deb packaging issues for 4.4
Have a look here:
https://github.com/apache/cloudstack/pull/339


On Mon, Jun 1, 2015 at 2:02 PM, Erik Weber  wrote:

> Sounds reasonable to me.
>
> --
> Erik
>
> On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland 
> wrote:
>
> > If no objections I will reset the default to 4.4.1 (the lowest required
> > version) include Rafaels pr for kvm/centos packaging and create a new rc.
> >
> > Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <
> daan.hoogl...@gmail.com
> > >:
> >
> > > So we will have to include an update in every release and we will
> > probably
> > > forget about that pretty soon.
> > >
> > > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma :
> > >
> > >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release, and
> > 4.5.0
> > >> for 4.5.x etc. This is also close to what was hard-coded before.
> > >>
> > >> Regards,
> > >> Remi
> > >>
> > >>
> > >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland :
> > >>
> > >> > Guess we'll be making a new rc. The value can be 0.0.0 for my part,
> it
> > >> must
> > >> > be an operator decision to set the MinVRVersion if it must be
> higher.
> > It
> > >> > will always be an upgrade matter and any seeded template should be
> > >> accepted
> > >> > as per the installation notes. Of course the other side of the issue
> > is
> > >> > whether a version will work at all. The operator can create a
> version
> > of
> > >> > the template with their own versioning scheme, however. I should be
> > >> writing
> > >> > all this in another {DISCUSS]-thread.
> > >> >
> > >> > cancelling the RC to add code for Bruno's requirement.
> > >> >
> > >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber :
> > >> >
> > >> > >
> > >> > > Please note: I my case, there isn't an upgrade, I have the issue
> > with
> > >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
> > >> > > 4.4-RC20150529T2004)
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > On 01/06/2015 07:22, Erik Weber wrote:
> > >> > > > If it means that all upgrades are unable to do VR related tasks
> (
> > >> > > starting
> > >> > > > VMs for one.. ), I'd call that regression and redo.
> > >> > > > Relying on all our users to do manual fixing just because we
> don't
> > >> want
> > >> > > to
> > >> > > > call off the RC is bad IMHO.
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> >
>

Re: Regular total loss of connectivity

[Simon Weller]

Is this VR in a redundant pair? If so, does stopping the master and allowing 
the slave to take over allow the flow of traffic to resume?



From: Nux! 
Sent: Monday, June 1, 2015 6:45 AM
To: dev@cloudstack.apache.org
Cc: Cloudstack Users List
Subject: Re: Regular total loss of connectivity

Thanks Simon,

link up/down has not helped, setting tso etc off on the link has not helped 
either.
Connectivity is lost as usual after ~4 hours.

I found some suggestions to try and use the e1000 nic instead of virtio, will 
do that.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Simon Weller" 
> To: "dev" , "Cloudstack Users List" 
> 
> Sent: Sunday, 31 May, 2015 22:36:56
> Subject: Re: Regular total loss of connectivity

> If you ifdown the interface on the router and then ifup it again, does the arp
> problem resolve itself?
>
> We've seen a similar issue before caused by malicious/heavy traffic related to
> this bug:
>
> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/997978
>
> - Si
> 
> From: Nux! 
> Sent: Sunday, May 31, 2015 4:25 PM
> To: dev; Cloudstack Users List
> Subject: Regular total loss of connectivity
>
> Hi,
>
> Following a power cut, one of my cloudstack deployments is having a really 
> weird
> problem that I cannot seem to solve on my own.
> Every 3 hours all the public IPs on the VR stop responding from the Internet.
> From the VR they are of course all reachable.
> In the same VLAN as the public IPs there is another physical server, this one
> can also access the VMs on their IPs just fine.
>
> The provider has not found the problem and hints at problems with the cloud
> platform, however cloudstack worked just fine until the power cut, not to
> mention the problem persists through HV and ACS upgrades.
>
> I'm thinking network side arp issues or something like this, alas I am not 
> that
> good with network stuff and don't have access to it anyway.
>
> If I reboot the VR once or twice the IPs start working again and the VMs are
> accessible from the internet.
>
> Ideas?
>
> Env: CentOS 6, KVM, ACS 44 to 4.5.1, Adv zone
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro

Re: [VOTE] release candidate 4.4.4

[Daan Hoogland]

I noticed, will look at travis and merge

Op ma 1 jun. 2015 om 14:27 schreef Rafael Fonseca :

> Hey Daan,
> I've also created a PR for fixing a couple of deb packaging issues for 4.4
> Have a look here:
> https://github.com/apache/cloudstack/pull/339
>
>
> On Mon, Jun 1, 2015 at 2:02 PM, Erik Weber  wrote:
>
> > Sounds reasonable to me.
> >
> > --
> > Erik
> >
> > On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland 
> > wrote:
> >
> > > If no objections I will reset the default to 4.4.1 (the lowest required
> > > version) include Rafaels pr for kvm/centos packaging and create a new
> rc.
> > >
> > > Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <
> > daan.hoogl...@gmail.com
> > > >:
> > >
> > > > So we will have to include an update in every release and we will
> > > probably
> > > > forget about that pretty soon.
> > > >
> > > > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma :
> > > >
> > > >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release, and
> > > 4.5.0
> > > >> for 4.5.x etc. This is also close to what was hard-coded before.
> > > >>
> > > >> Regards,
> > > >> Remi
> > > >>
> > > >>
> > > >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland :
> > > >>
> > > >> > Guess we'll be making a new rc. The value can be 0.0.0 for my
> part,
> > it
> > > >> must
> > > >> > be an operator decision to set the MinVRVersion if it must be
> > higher.
> > > It
> > > >> > will always be an upgrade matter and any seeded template should be
> > > >> accepted
> > > >> > as per the installation notes. Of course the other side of the
> issue
> > > is
> > > >> > whether a version will work at all. The operator can create a
> > version
> > > of
> > > >> > the template with their own versioning scheme, however. I should
> be
> > > >> writing
> > > >> > all this in another {DISCUSS]-thread.
> > > >> >
> > > >> > cancelling the RC to add code for Bruno's requirement.
> > > >> >
> > > >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber  >:
> > > >> >
> > > >> > >
> > > >> > > Please note: I my case, there isn't an upgrade, I have the issue
> > > with
> > > >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
> > > >> > > 4.4-RC20150529T2004)
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > On 01/06/2015 07:22, Erik Weber wrote:
> > > >> > > > If it means that all upgrades are unable to do VR related
> tasks
> > (
> > > >> > > starting
> > > >> > > > VMs for one.. ), I'd call that regression and redo.
> > > >> > > > Relying on all our users to do manual fixing just because we
> > don't
> > > >> want
> > > >> > > to
> > > >> > > > call off the RC is bad IMHO.
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>

Re: [VOTE] release candidate 4.4.4

[Andrija Panic]

Daan, Rafael,

what about Rafael's https://github.com/apache/cloudstack/pull/308 - it need
to be reviewsed by security time - fine, but can we merge this, and undo
alter, if necessary ?

On 1 June 2015 at 14:26, Rafael Fonseca  wrote:

> Hey Daan,
> I've also created a PR for fixing a couple of deb packaging issues for 4.4
> Have a look here:
> https://github.com/apache/cloudstack/pull/339
>
>
> On Mon, Jun 1, 2015 at 2:02 PM, Erik Weber  wrote:
>
> > Sounds reasonable to me.
> >
> > --
> > Erik
> >
> > On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland 
> > wrote:
> >
> > > If no objections I will reset the default to 4.4.1 (the lowest required
> > > version) include Rafaels pr for kvm/centos packaging and create a new
> rc.
> > >
> > > Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <
> > daan.hoogl...@gmail.com
> > > >:
> > >
> > > > So we will have to include an update in every release and we will
> > > probably
> > > > forget about that pretty soon.
> > > >
> > > > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma :
> > > >
> > > >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release, and
> > > 4.5.0
> > > >> for 4.5.x etc. This is also close to what was hard-coded before.
> > > >>
> > > >> Regards,
> > > >> Remi
> > > >>
> > > >>
> > > >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland :
> > > >>
> > > >> > Guess we'll be making a new rc. The value can be 0.0.0 for my
> part,
> > it
> > > >> must
> > > >> > be an operator decision to set the MinVRVersion if it must be
> > higher.
> > > It
> > > >> > will always be an upgrade matter and any seeded template should be
> > > >> accepted
> > > >> > as per the installation notes. Of course the other side of the
> issue
> > > is
> > > >> > whether a version will work at all. The operator can create a
> > version
> > > of
> > > >> > the template with their own versioning scheme, however. I should
> be
> > > >> writing
> > > >> > all this in another {DISCUSS]-thread.
> > > >> >
> > > >> > cancelling the RC to add code for Bruno's requirement.
> > > >> >
> > > >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber  >:
> > > >> >
> > > >> > >
> > > >> > > Please note: I my case, there isn't an upgrade, I have the issue
> > > with
> > > >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
> > > >> > > 4.4-RC20150529T2004)
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > On 01/06/2015 07:22, Erik Weber wrote:
> > > >> > > > If it means that all upgrades are unable to do VR related
> tasks
> > (
> > > >> > > starting
> > > >> > > > VMs for one.. ), I'd call that regression and redo.
> > > >> > > > Relying on all our users to do manual fixing just because we
> > don't
> > > >> want
> > > >> > > to
> > > >> > > > call off the RC is bad IMHO.
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>



-- 

Andrija Panić

Re: [VOTE] release candidate 4.4.4

[Erik Weber]

Do we have travis jobs to test packaging?

-- 
Erik

On Mon, Jun 1, 2015 at 2:32 PM, Daan Hoogland 
wrote:

> I noticed, will look at travis and merge
>
> Op ma 1 jun. 2015 om 14:27 schreef Rafael Fonseca :
>
> > Hey Daan,
> > I've also created a PR for fixing a couple of deb packaging issues for
> 4.4
> > Have a look here:
> > https://github.com/apache/cloudstack/pull/339
> >
> >
> > On Mon, Jun 1, 2015 at 2:02 PM, Erik Weber  wrote:
> >
> > > Sounds reasonable to me.
> > >
> > > --
> > > Erik
> > >
> > > On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland  >
> > > wrote:
> > >
> > > > If no objections I will reset the default to 4.4.1 (the lowest
> required
> > > > version) include Rafaels pr for kvm/centos packaging and create a new
> > rc.
> > > >
> > > > Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <
> > > daan.hoogl...@gmail.com
> > > > >:
> > > >
> > > > > So we will have to include an update in every release and we will
> > > > probably
> > > > > forget about that pretty soon.
> > > > >
> > > > > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma :
> > > > >
> > > > >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release,
> and
> > > > 4.5.0
> > > > >> for 4.5.x etc. This is also close to what was hard-coded before.
> > > > >>
> > > > >> Regards,
> > > > >> Remi
> > > > >>
> > > > >>
> > > > >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland  >:
> > > > >>
> > > > >> > Guess we'll be making a new rc. The value can be 0.0.0 for my
> > part,
> > > it
> > > > >> must
> > > > >> > be an operator decision to set the MinVRVersion if it must be
> > > higher.
> > > > It
> > > > >> > will always be an upgrade matter and any seeded template should
> be
> > > > >> accepted
> > > > >> > as per the installation notes. Of course the other side of the
> > issue
> > > > is
> > > > >> > whether a version will work at all. The operator can create a
> > > version
> > > > of
> > > > >> > the template with their own versioning scheme, however. I should
> > be
> > > > >> writing
> > > > >> > all this in another {DISCUSS]-thread.
> > > > >> >
> > > > >> > cancelling the RC to add code for Bruno's requirement.
> > > > >> >
> > > > >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber <
> milam...@apache.org
> > >:
> > > > >> >
> > > > >> > >
> > > > >> > > Please note: I my case, there isn't an upgrade, I have the
> issue
> > > > with
> > > > >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from git
> tag
> > > > >> > > 4.4-RC20150529T2004)
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > On 01/06/2015 07:22, Erik Weber wrote:
> > > > >> > > > If it means that all upgrades are unable to do VR related
> > tasks
> > > (
> > > > >> > > starting
> > > > >> > > > VMs for one.. ), I'd call that regression and redo.
> > > > >> > > > Relying on all our users to do manual fixing just because we
> > > don't
> > > > >> want
> > > > >> > > to
> > > > >> > > > call off the RC is bad IMHO.
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>

[GitHub] cloudstack pull request: Update debian packaging

[DaanHoogland]

Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/339#issuecomment-107433082
  
getting impatient; debian packaging is not testied in travic and asfbot 
says go; merging


---
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-8530: KVM hosts without active...

[bhaisaab]

GitHub user bhaisaab opened a pull request:

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

CLOUDSTACK-8530: KVM hosts without active agents should be in Disconnected 
state

KVM hosts which are up but their agents are shutdown should be put
in disconnected state. This would avoid getting the VMs HA'd and other 
commands
such as deploying a VM will exclude that host and save us from errors.

The improvement is that, we first try to contact the KVM host itself. If it 
fails
we assume that it's disconnected, and then ask its KVM neighbours if they 
can
check its status. If all of the KVM neighbours tell us that it's Down and 
we're
unable to reach the KVM host, then the host is possibly down. In case any 
of the
KVM neighbours tell us that it's Up but we're unable to reach the KVM host 
then
we can be sure that the agent is offline but the host is running.

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

$ git pull https://github.com/apache/cloudstack CLOUDSTACK-8530

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

https://github.com/apache/cloudstack/pull/340.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 #340


commit 43a0b6bb064f607196bdf84819e1b472e4a705fb
Author: Rohit Yadav 
Date:   2015-06-01T12:53:58Z

CLOUDSTACK-8530: KVM hosts without active agents should be in Disconnected 
state

KVM hosts which are actuall up, but if their agents are shutdown should be 
put
in disconnected state. This would avoid getting the VMs HA'd and other 
commands
such as deploying a VM will exclude that host and save us from errors.

The improvement is that, we first try to contact the KVM host itself. If it 
fails
we assume that it's disconnected, and then ask its KVM neighbours if they 
can
check its status. If all of the KVM neighbours tell us that it's Down and 
we're
unable to reach the KVM host, then the host is possibly down. In case any 
of the
KVM neighbours tell us that it's Up but we're unable to reach the KVM host 
then
we can be sure that the agent is offline but the host is running.

Signed-off-by: Rohit Yadav 




---
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-8530: KVM hosts without active...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/340#issuecomment-107434772
  
Issue: https://issues.apache.org/jira/browse/CLOUDSTACK-8530


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

Re: [VOTE] release candidate 4.4.4

[Daan Hoogland]

Op ma 1 jun. 2015 om 14:37 schreef Erik Weber :

> Do we have travis jobs to test packaging?
>
No, not in travis. in jenkins for rpm, yes. for deb, I think these are
broken for a while now.


>
> --
> Erik
>
>

[GitHub] cloudstack pull request: Version evaluated with native tools inste...

[rsafonseca]

GitHub user rsafonseca opened a pull request:

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

Version evaluated with native tools instead of maven

I think i saw a build failure yesterday on buildacloud.com due to missing 
plexus libs invoking the mvn command.
Can't seem to pinpoint it now, but this fixes it if it reoccurs, and also 
makes this specific task much faster.

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

$ git pull https://github.com/rsafonseca/cloudstack debfixes

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

https://github.com/apache/cloudstack/pull/341.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 #341


commit 55ff2bdf213b8bd38064135c40bf36241a82fa7f
Author: Rafael da Fonseca 
Date:   2015-06-01T13:01:37Z

Version evaluated with native tools instead of maven




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

Re: [VOTE] release candidate 4.4.4

[Rafael Fonseca]

This will fix the deb tests on jenkins permanently :)
The packaging always needed a manual update in deb/changelog after a change
in pom.xml version. If this step was forgotten or skipped, it would break.
Fixed for now and forever hopefully :)

On Mon, Jun 1, 2015 at 3:07 PM, Daan Hoogland 
wrote:

> Op ma 1 jun. 2015 om 14:37 schreef Erik Weber :
>
> > Do we have travis jobs to test packaging?
> >
> No, not in travis. in jenkins for rpm, yes. for deb, I think these are
> broken for a while now.
>
>
> >
> > --
> > Erik
> >
> >
>

[GitHub] cloudstack pull request: Mocking the Connect object used in the Li...

[wilderrodrigues]

GitHub user wilderrodrigues opened a pull request:

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

Mocking the Connect object used in the LibvirtMigrateCommandWrapper.

  - When executing the tests in an environment where Libvirt is also 
installed, it caused errors.

Hi @bhaisaab and @rsafonseca,

The Connect class is now being mocked, which means it will not load any 
native library.

Build environment:

[root@kvm3 cloudstack]# uname -a
Linux kvm3 3.10.0-229.1.2.el7.x86_64 #1 SMP Fri Mar 27 03:04:26 UTC 2015 
x86_64 x86_64 x86_64 GNU/Linux

[root@kvm3 cloudstack]# cat /etc/centos-release
CentOS Linux release 7.1.1503 (Core)

[root@kvm3 cloudstack]# virsh --version=long 
Virsh command line tool of libvirt 1.2.8
See web site at http://libvirt.org/

Compiled with support for:
 Hypervisors: QEMU/KVM LXC ESX Test
 Networking: Remote Network Bridging Interface netcf Nwfilter VirtualPort
 Storage: Dir Disk Filesystem SCSI Multipath iSCSI LVM Gluster
 Miscellaneous: Daemon Nodedev SELinux Secrets Debug DTrace Readline Modular

Command executed: mvn -P developer,systemvm clean install

[INFO] 

[INFO] BUILD SUCCESS
[INFO] 

[INFO] Total time: 16:50.546s
[INFO] Finished at: Mon Jun 01 09:04:28 EDT 2015
[INFO] Final Memory: 103M/671M
[INFO] 

[root@kvm3 cloudstack]#

Cheers,
Wilder

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

$ git pull https://github.com/schubergphilis/cloudstack 
fix/testMigrateCommand

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

https://github.com/apache/cloudstack/pull/342.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 #342


commit 2c5ddc0ccd806d1fd43f8eb96587a86fe242724d
Author: wilderrodrigues 
Date:   2015-06-01T12:45:43Z

Mocking the Connect object used in the LibvirtMigrateCommandWrapper.
  - When executing the tests in an environment where Libvirt is also 
installed, it caused errors.




---
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: Mocking the Connect object used in the Li...

[rsafonseca]

Github user rsafonseca commented on the pull request:

https://github.com/apache/cloudstack/pull/342#issuecomment-107454748
  
LGTM :D 
Will test it out later! Thanks for this :)


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

Re: [VOTE] release candidate 4.4.4

[Rafael Fonseca]

Hi Andrija,

The first fix i had proposed might not have been a problem, besides the
security issue.
I have now updated the PR to fix the security issue, but tests for other
authentication methods must be performed before a merge.
I think Rohit is looking into testing the SAML plugin with it, if it's ok i
guess it can be merged, if not, it will still have to be made compatible
with those auth plugins.
If you'd like i can give you a small patch to fix session management in
your environment, you can patch in place after installation, so easy to do
:)



On Mon, Jun 1, 2015 at 2:34 PM, Andrija Panic 
wrote:

> Daan, Rafael,
>
> what about Rafael's https://github.com/apache/cloudstack/pull/308 - it
> need
> to be reviewsed by security time - fine, but can we merge this, and undo
> alter, if necessary ?
>
> On 1 June 2015 at 14:26, Rafael Fonseca  wrote:
>
> > Hey Daan,
> > I've also created a PR for fixing a couple of deb packaging issues for
> 4.4
> > Have a look here:
> > https://github.com/apache/cloudstack/pull/339
> >
> >
> > On Mon, Jun 1, 2015 at 2:02 PM, Erik Weber  wrote:
> >
> > > Sounds reasonable to me.
> > >
> > > --
> > > Erik
> > >
> > > On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland  >
> > > wrote:
> > >
> > > > If no objections I will reset the default to 4.4.1 (the lowest
> required
> > > > version) include Rafaels pr for kvm/centos packaging and create a new
> > rc.
> > > >
> > > > Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <
> > > daan.hoogl...@gmail.com
> > > > >:
> > > >
> > > > > So we will have to include an update in every release and we will
> > > > probably
> > > > > forget about that pretty soon.
> > > > >
> > > > > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma :
> > > > >
> > > > >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release,
> and
> > > > 4.5.0
> > > > >> for 4.5.x etc. This is also close to what was hard-coded before.
> > > > >>
> > > > >> Regards,
> > > > >> Remi
> > > > >>
> > > > >>
> > > > >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland  >:
> > > > >>
> > > > >> > Guess we'll be making a new rc. The value can be 0.0.0 for my
> > part,
> > > it
> > > > >> must
> > > > >> > be an operator decision to set the MinVRVersion if it must be
> > > higher.
> > > > It
> > > > >> > will always be an upgrade matter and any seeded template should
> be
> > > > >> accepted
> > > > >> > as per the installation notes. Of course the other side of the
> > issue
> > > > is
> > > > >> > whether a version will work at all. The operator can create a
> > > version
> > > > of
> > > > >> > the template with their own versioning scheme, however. I should
> > be
> > > > >> writing
> > > > >> > all this in another {DISCUSS]-thread.
> > > > >> >
> > > > >> > cancelling the RC to add code for Bruno's requirement.
> > > > >> >
> > > > >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber <
> milam...@apache.org
> > >:
> > > > >> >
> > > > >> > >
> > > > >> > > Please note: I my case, there isn't an upgrade, I have the
> issue
> > > > with
> > > > >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from git
> tag
> > > > >> > > 4.4-RC20150529T2004)
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > On 01/06/2015 07:22, Erik Weber wrote:
> > > > >> > > > If it means that all upgrades are unable to do VR related
> > tasks
> > > (
> > > > >> > > starting
> > > > >> > > > VMs for one.. ), I'd call that regression and redo.
> > > > >> > > > Relying on all our users to do manual fixing just because we
> > > don't
> > > > >> want
> > > > >> > > to
> > > > >> > > > call off the RC is bad IMHO.
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>
>
>
> --
>
> Andrija Panić
>

Re: [VOTE] release candidate 4.4.4

[Andrija Panic]

:) please do - send the patch.

Thanks Rafael

On 1 June 2015 at 15:16, Rafael Fonseca  wrote:

> Hi Andrija,
>
> The first fix i had proposed might not have been a problem, besides the
> security issue.
> I have now updated the PR to fix the security issue, but tests for other
> authentication methods must be performed before a merge.
> I think Rohit is looking into testing the SAML plugin with it, if it's ok i
> guess it can be merged, if not, it will still have to be made compatible
> with those auth plugins.
> If you'd like i can give you a small patch to fix session management in
> your environment, you can patch in place after installation, so easy to do
> :)
>
>
>
> On Mon, Jun 1, 2015 at 2:34 PM, Andrija Panic 
> wrote:
>
> > Daan, Rafael,
> >
> > what about Rafael's https://github.com/apache/cloudstack/pull/308 - it
> > need
> > to be reviewsed by security time - fine, but can we merge this, and undo
> > alter, if necessary ?
> >
> > On 1 June 2015 at 14:26, Rafael Fonseca  wrote:
> >
> > > Hey Daan,
> > > I've also created a PR for fixing a couple of deb packaging issues for
> > 4.4
> > > Have a look here:
> > > https://github.com/apache/cloudstack/pull/339
> > >
> > >
> > > On Mon, Jun 1, 2015 at 2:02 PM, Erik Weber 
> wrote:
> > >
> > > > Sounds reasonable to me.
> > > >
> > > > --
> > > > Erik
> > > >
> > > > On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland <
> daan.hoogl...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > If no objections I will reset the default to 4.4.1 (the lowest
> > required
> > > > > version) include Rafaels pr for kvm/centos packaging and create a
> new
> > > rc.
> > > > >
> > > > > Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <
> > > > daan.hoogl...@gmail.com
> > > > > >:
> > > > >
> > > > > > So we will have to include an update in every release and we will
> > > > > probably
> > > > > > forget about that pretty soon.
> > > > > >
> > > > > > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma :
> > > > > >
> > > > > >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release,
> > and
> > > > > 4.5.0
> > > > > >> for 4.5.x etc. This is also close to what was hard-coded before.
> > > > > >>
> > > > > >> Regards,
> > > > > >> Remi
> > > > > >>
> > > > > >>
> > > > > >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland <
> daan.hoogl...@gmail.com
> > >:
> > > > > >>
> > > > > >> > Guess we'll be making a new rc. The value can be 0.0.0 for my
> > > part,
> > > > it
> > > > > >> must
> > > > > >> > be an operator decision to set the MinVRVersion if it must be
> > > > higher.
> > > > > It
> > > > > >> > will always be an upgrade matter and any seeded template
> should
> > be
> > > > > >> accepted
> > > > > >> > as per the installation notes. Of course the other side of the
> > > issue
> > > > > is
> > > > > >> > whether a version will work at all. The operator can create a
> > > > version
> > > > > of
> > > > > >> > the template with their own versioning scheme, however. I
> should
> > > be
> > > > > >> writing
> > > > > >> > all this in another {DISCUSS]-thread.
> > > > > >> >
> > > > > >> > cancelling the RC to add code for Bruno's requirement.
> > > > > >> >
> > > > > >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber <
> > milam...@apache.org
> > > >:
> > > > > >> >
> > > > > >> > >
> > > > > >> > > Please note: I my case, there isn't an upgrade, I have the
> > issue
> > > > > with
> > > > > >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from git
> > tag
> > > > > >> > > 4.4-RC20150529T2004)
> > > > > >> > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > On 01/06/2015 07:22, Erik Weber wrote:
> > > > > >> > > > If it means that all upgrades are unable to do VR related
> > > tasks
> > > > (
> > > > > >> > > starting
> > > > > >> > > > VMs for one.. ), I'd call that regression and redo.
> > > > > >> > > > Relying on all our users to do manual fixing just because
> we
> > > > don't
> > > > > >> want
> > > > > >> > > to
> > > > > >> > > > call off the RC is bad IMHO.
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> >
> > Andrija Panić
> >
>



-- 

Andrija Panić

Re: Regular total loss of connectivity

[Nux!]

Nope, it's a regular, non-redundant VR.

I've switched to using e1000 instead of virtio, waiting for a few hours, so how 
it pans out. :-)

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Simon Weller" 
> To: dev@cloudstack.apache.org
> Cc: "Cloudstack Users List" 
> Sent: Monday, 1 June, 2015 13:32:26
> Subject: Re: Regular total loss of connectivity

> Is this VR in a redundant pair? If so, does stopping the master and allowing 
> the
> slave to take over allow the flow of traffic to resume?
> 
> 
> 
> From: Nux! 
> Sent: Monday, June 1, 2015 6:45 AM
> To: dev@cloudstack.apache.org
> Cc: Cloudstack Users List
> Subject: Re: Regular total loss of connectivity
> 
> Thanks Simon,
> 
> link up/down has not helped, setting tso etc off on the link has not helped
> either.
> Connectivity is lost as usual after ~4 hours.
> 
> I found some suggestions to try and use the e1000 nic instead of virtio, will 
> do
> that.
> 
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Simon Weller" 
>> To: "dev" , "Cloudstack Users List"
>> 
>> Sent: Sunday, 31 May, 2015 22:36:56
>> Subject: Re: Regular total loss of connectivity
> 
>> If you ifdown the interface on the router and then ifup it again, does the 
>> arp
>> problem resolve itself?
>>
>> We've seen a similar issue before caused by malicious/heavy traffic related 
>> to
>> this bug:
>>
>> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/997978
>>
>> - Si
>> 
>> From: Nux! 
>> Sent: Sunday, May 31, 2015 4:25 PM
>> To: dev; Cloudstack Users List
>> Subject: Regular total loss of connectivity
>>
>> Hi,
>>
>> Following a power cut, one of my cloudstack deployments is having a really 
>> weird
>> problem that I cannot seem to solve on my own.
>> Every 3 hours all the public IPs on the VR stop responding from the Internet.
>> From the VR they are of course all reachable.
>> In the same VLAN as the public IPs there is another physical server, this one
>> can also access the VMs on their IPs just fine.
>>
>> The provider has not found the problem and hints at problems with the cloud
>> platform, however cloudstack worked just fine until the power cut, not to
>> mention the problem persists through HV and ACS upgrades.
>>
>> I'm thinking network side arp issues or something like this, alas I am not 
>> that
>> good with network stuff and don't have access to it anyway.
>>
>> If I reboot the VR once or twice the IPs start working again and the VMs are
>> accessible from the internet.
>>
>> Ideas?
>>
>> Env: CentOS 6, KVM, ACS 44 to 4.5.1, Adv zone
>>
>> Lucian
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
> > www.nux.ro

Re: [VOTE] release candidate 4.4.4

[Daan Hoogland]

Andrija, Rafael, I took a few minutes to look at it. It doesn't apply even
after some simple tinkering. Hope you will once forgive me for not taking
this in the next RC. baking it now

Op ma 1 jun. 2015 om 15:22 schreef Andrija Panic :

> :) please do - send the patch.
>
> Thanks Rafael
>
> On 1 June 2015 at 15:16, Rafael Fonseca  wrote:
>
> > Hi Andrija,
> >
> > The first fix i had proposed might not have been a problem, besides the
> > security issue.
> > I have now updated the PR to fix the security issue, but tests for other
> > authentication methods must be performed before a merge.
> > I think Rohit is looking into testing the SAML plugin with it, if it's
> ok i
> > guess it can be merged, if not, it will still have to be made compatible
> > with those auth plugins.
> > If you'd like i can give you a small patch to fix session management in
> > your environment, you can patch in place after installation, so easy to
> do
> > :)
> >
> >
> >
> > On Mon, Jun 1, 2015 at 2:34 PM, Andrija Panic 
> > wrote:
> >
> > > Daan, Rafael,
> > >
> > > what about Rafael's https://github.com/apache/cloudstack/pull/308 - it
> > > need
> > > to be reviewsed by security time - fine, but can we merge this, and
> undo
> > > alter, if necessary ?
> > >
> > > On 1 June 2015 at 14:26, Rafael Fonseca  wrote:
> > >
> > > > Hey Daan,
> > > > I've also created a PR for fixing a couple of deb packaging issues
> for
> > > 4.4
> > > > Have a look here:
> > > > https://github.com/apache/cloudstack/pull/339
> > > >
> > > >
> > > > On Mon, Jun 1, 2015 at 2:02 PM, Erik Weber 
> > wrote:
> > > >
> > > > > Sounds reasonable to me.
> > > > >
> > > > > --
> > > > > Erik
> > > > >
> > > > > On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland <
> > daan.hoogl...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > If no objections I will reset the default to 4.4.1 (the lowest
> > > required
> > > > > > version) include Rafaels pr for kvm/centos packaging and create a
> > new
> > > > rc.
> > > > > >
> > > > > > Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <
> > > > > daan.hoogl...@gmail.com
> > > > > > >:
> > > > > >
> > > > > > > So we will have to include an update in every release and we
> will
> > > > > > probably
> > > > > > > forget about that pretty soon.
> > > > > > >
> > > > > > > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma  >:
> > > > > > >
> > > > > > >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x
> release,
> > > and
> > > > > > 4.5.0
> > > > > > >> for 4.5.x etc. This is also close to what was hard-coded
> before.
> > > > > > >>
> > > > > > >> Regards,
> > > > > > >> Remi
> > > > > > >>
> > > > > > >>
> > > > > > >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland <
> > daan.hoogl...@gmail.com
> > > >:
> > > > > > >>
> > > > > > >> > Guess we'll be making a new rc. The value can be 0.0.0 for
> my
> > > > part,
> > > > > it
> > > > > > >> must
> > > > > > >> > be an operator decision to set the MinVRVersion if it must
> be
> > > > > higher.
> > > > > > It
> > > > > > >> > will always be an upgrade matter and any seeded template
> > should
> > > be
> > > > > > >> accepted
> > > > > > >> > as per the installation notes. Of course the other side of
> the
> > > > issue
> > > > > > is
> > > > > > >> > whether a version will work at all. The operator can create
> a
> > > > > version
> > > > > > of
> > > > > > >> > the template with their own versioning scheme, however. I
> > should
> > > > be
> > > > > > >> writing
> > > > > > >> > all this in another {DISCUSS]-thread.
> > > > > > >> >
> > > > > > >> > cancelling the RC to add code for Bruno's requirement.
> > > > > > >> >
> > > > > > >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber <
> > > milam...@apache.org
> > > > >:
> > > > > > >> >
> > > > > > >> > >
> > > > > > >> > > Please note: I my case, there isn't an upgrade, I have the
> > > issue
> > > > > > with
> > > > > > >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from
> git
> > > tag
> > > > > > >> > > 4.4-RC20150529T2004)
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > On 01/06/2015 07:22, Erik Weber wrote:
> > > > > > >> > > > If it means that all upgrades are unable to do VR
> related
> > > > tasks
> > > > > (
> > > > > > >> > > starting
> > > > > > >> > > > VMs for one.. ), I'd call that regression and redo.
> > > > > > >> > > > Relying on all our users to do manual fixing just
> because
> > we
> > > > > don't
> > > > > > >> want
> > > > > > >> > > to
> > > > > > >> > > > call off the RC is bad IMHO.
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Andrija Panić
> > >
> >
>
>
>
> --
>
> Andrija Panić
>

[VOTE] release candidate 4.4.4 (4.4-RC20150601T1542)

[Daan Hoogland]

Hi All,

I've created a 4.4.4 release, with the following artifacts up for a vote:

Git Branch and Commit
SH:https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/
4.4-RC20150601T1542
Commit: b087514317e9fce350c2dcee6bb5b21fb70c1eb8

List of 
changes:https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/tags/4.4.4

Source release (checksums and signatures are available at the same
location):https://dist.apache.org/repos/dist/dev/cloudstack/4.4.4/

PGP release keys (signed using
5AABEBEA):https://dist.apache.org/repos/dist/release/cloudstack/KEYS
Vote will be open for 72 hours.

For sanity in tallying the vote, can PMC members please be sure to
indicate "(binding)" with their vote?

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Re: [VOTE] release candidate 4.4.4

[Rafael Fonseca]

No prob Daan :)
Like it said, it still needs some testing before merging as is into the
code base.
If you don't care much about that security issue (the risk of a XSS attack
to get your sessionkey, for which the attacker would also need network
access to your server, which he normally wouldn't if you took minimum care
of securing it :) ), this patch restores old behavior to use cookies for
session persistence:

(just did this now and didn't test, but there should be no issues)
(you can also take a backup of cloudStack.js just in case ;) )


cat << 'EOF' > patch.file
*** ui/scripts/cloudStack.js2015-06-01 15:41:54.98600 +0200
--- /usr/share/cloudstack-management/webapps/client/scripts/cloudStack.js
2015-06-01 15:41:51.41000 +0200
***
*** 117,131 
  }
  return cookieValue;
  };
! unBoxCookieValue('sessionkey');
! // if sessionkey cookie exists use this to set
g_sessionKey
! // and destroy sessionkey cookie
! if ($.cookie('sessionkey')) {
! g_sessionKey = $.cookie('sessionkey');
! $.cookie('sessionkey', null);
! } else {
! g_sessionKey = unBoxCookieValue('JSESSIONID');
! }
  g_role = unBoxCookieValue('role');
  g_userid = unBoxCookieValue('userid');
  g_domainid = unBoxCookieValue('domainid');
--- 117,123 
  }
  return cookieValue;
  };
! g_sessionKey = unBoxCookieValue('sessionkey');
  g_role = unBoxCookieValue('role');
  g_userid = unBoxCookieValue('userid');
  g_domainid = unBoxCookieValue('domainid');
***
*** 234,239 
--- 226,234 
  g_timezone = loginresponse.timezone;
  g_userfullname = loginresponse.firstname + ' ' +
loginresponse.lastname;

+ $.cookie('sessionKey', g_sessionKey, {
+ expires: 1
+ });
  $.cookie('username', g_username, {
  expires: 1
  });
EOF
patch /usr/share/cloudstack-management/webapps/client/scripts/cloudStack.js
-i patch.file

On Mon, Jun 1, 2015 at 3:41 PM, Daan Hoogland 
wrote:

> Andrija, Rafael, I took a few minutes to look at it. It doesn't apply even
> after some simple tinkering. Hope you will once forgive me for not taking
> this in the next RC. baking it now
>
> Op ma 1 jun. 2015 om 15:22 schreef Andrija Panic  >:
>
> > :) please do - send the patch.
> >
> > Thanks Rafael
> >
> > On 1 June 2015 at 15:16, Rafael Fonseca  wrote:
> >
> > > Hi Andrija,
> > >
> > > The first fix i had proposed might not have been a problem, besides the
> > > security issue.
> > > I have now updated the PR to fix the security issue, but tests for
> other
> > > authentication methods must be performed before a merge.
> > > I think Rohit is looking into testing the SAML plugin with it, if it's
> > ok i
> > > guess it can be merged, if not, it will still have to be made
> compatible
> > > with those auth plugins.
> > > If you'd like i can give you a small patch to fix session management in
> > > your environment, you can patch in place after installation, so easy to
> > do
> > > :)
> > >
> > >
> > >
> > > On Mon, Jun 1, 2015 at 2:34 PM, Andrija Panic  >
> > > wrote:
> > >
> > > > Daan, Rafael,
> > > >
> > > > what about Rafael's https://github.com/apache/cloudstack/pull/308 -
> it
> > > > need
> > > > to be reviewsed by security time - fine, but can we merge this, and
> > undo
> > > > alter, if necessary ?
> > > >
> > > > On 1 June 2015 at 14:26, Rafael Fonseca 
> wrote:
> > > >
> > > > > Hey Daan,
> > > > > I've also created a PR for fixing a couple of deb packaging issues
> > for
> > > > 4.4
> > > > > Have a look here:
> > > > > https://github.com/apache/cloudstack/pull/339
> > > > >
> > > > >
> > > > > On Mon, Jun 1, 2015 at 2:02 PM, Erik Weber 
> > > wrote:
> > > > >
> > > > > > Sounds reasonable to me.
> > > > > >
> > > > > > --
> > > > > > Erik
> > > > > >
> > > > > > On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland <
> > > daan.hoogl...@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > If no objections I will reset the default to 4.4.1 (the lowest
> > > > required
> > > > > > > version) include Rafaels pr for kvm/centos packaging and
> create a
> > > new
> > > > > rc.
> > > > > > >
> > > > > > > Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <
> > > > > > daan.hoogl...@gmail.com
> > > > > > > >:
> > > > > > >
> > > > > > > > So we will have to include an update in every release and we
> > will
> > > > > > > probably
> > > > > > > > forget about that pretty soon.
> > > > >

[GitHub] cloudstack pull request: Mocking the Connect object used in the Li...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/342#issuecomment-107522610
  
Travis is green, merging now.



---
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: Mocking the Connect object used in the Li...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/342#issuecomment-107523248
  
@rsafonseca oh wait, since you testing it. I'll wait for you to come back.


---
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: Version evaluated with native tools inste...

[bhaisaab]

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

https://github.com/apache/cloudstack/pull/341#discussion_r31430386
  
--- Diff: debian/rules ---
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
-VERSION := $(shell mvn 
org.apache.maven.plugins:maven-help-plugin:2.1.1:evaluate 
-Dexpression=project.version | grep -v "\[")
+VERSION := $(shell awk 'f{print;f=0} /cloudstack/{f=1}' 
pom.xml| sed -e 's/<[^>]*>//g'  -e 's/^[ \t]*//')
--- End diff --

Looks like this will be faster, though the previous version is more 
understandable so I would prefer to keep the previous one. We don't build 
packages often and it's usually Jenkins doing the heavy lifting.


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

jenkins disk full ?

[Pierre-Luc Dion]

Can someone that have access to the principal jenkins server to check disk
space left?

getting this error on few slave, the one I've check does not have disk full


Thread has died

java.io.IOException: No space left on device
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:318)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:316)
at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149)
at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233)
at java.io.BufferedWriter.close(BufferedWriter.java:266)
at hudson.util.AtomicFileWriter.close(AtomicFileWriter.java:94)
at hudson.util.AtomicFileWriter.commit(AtomicFileWriter.java:109)
at hudson.util.TextFile.write(TextFile.java:121)
at hudson.model.Job.saveNextBuildNumber(Job.java:274)
at hudson.model.Job.assignBuildNumber(Job.java:332)
at hudson.model.Run.(Run.java:286)
at hudson.model.AbstractBuild.(AbstractBuild.java:167)
at hudson.model.Build.(Build.java:92)
at hudson.model.FreeStyleBuild.(FreeStyleBuild.java:34)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at jenkins.model.lazy.LazyBuildMixIn.newBuild(LazyBuildMixIn.java:186)
at hudson.model.AbstractProject.newBuild(AbstractProject.java:1000)
at 
hudson.model.AbstractProject.createExecutable(AbstractProject.java:1193)
at 
hudson.model.AbstractProject.createExecutable(AbstractProject.java:143)
at hudson.model.Executor.run(Executor.java:213)

more info 



ref: 
http://jenkins.buildacloud.org/computer/cca-slave-02/executors/0/causeOfDeath



Thanks!

Re: Errors while packaging master

[Pierre-Luc Dion]

I think I fixed the problem with :
https://github.com/apache/cloudstack/pull/337
jenkins is broken for now, but was working locally.


On Sun, May 31, 2015 at 8:33 PM, Pierre-Luc Dion 
wrote:

> Doesn't seams to have been fixed on master branch. Look like the build
> slave on j.bac.o is broken and if running manually ./package.sh -d centos63
> it fail with the following error:
>
> error: File not found:
> /home/jenkins/cloudstack/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/etc/cloudstack/management/commons-logging.properties
>
> RPM build errors:
>
> File not found:
> /home/jenkins/cloudstack/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/etc/cloudstack/management/commons-logging.properties
>
> RPM Build Failed
>
>
>
> Regards,
>
> On Tue, May 12, 2015 at 4:06 PM, Erik Weber  wrote:
>
>> Anyone able to build the centos63 packages on master? Seems broken after
>> awsapi removal and 4.5 merge.
>>
>> Atleast I keep getting errors.
>>
>> Trying to fix it, but it takes time to rebuild and fetch new ones.
>>
>> --
>> Erik
>>
>> On Tue, May 12, 2015 at 1:28 PM, Erik Weber  wrote:
>>
>> > Anyone else get this? Happens when i do "bash package.sh -d centos63"
>> >
>> > + ln -sf /var/cache/cloudstack/management/temp
>> >
>> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/share/cloudstack-management/temp
>> > + ln -sf /var/cache/cloudstack/management/work
>> >
>> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/share/cloudstack-management/work
>> > + /bin/touch
>> >
>> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/var/log/cloudstack/management/catalina.out
>> > + install -D client/target/utilities/bin/cloud-migrate-databases
>> >
>> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-migrate-databases
>> > + install -D client/target/utilities/bin/cloud-set-guest-password
>> >
>> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-set-guest-password
>> > + install -D client/target/utilities/bin/cloud-set-guest-sshkey
>> >
>> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-set-guest-sshkey
>> > + install -D client/target/utilities/bin/cloud-setup-databases
>> >
>> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-setup-databases
>> > + install -D client/target/utilities/bin/cloud-setup-encryption
>> >
>> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-setup-encryption
>> > + install -D client/target/utilities/bin/cloud-setup-management
>> >
>> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-setup-management
>> > + install -D client/target/utilities/bin/cloud-setup-baremetal
>> >
>> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-setup-baremetal
>> > + install -D client/target/utilities/bin/cloud-sysvmadm
>> >
>> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-sysvmadm
>> > + install -D client/target/utilities/bin/cloud-update-xenserver-licenses
>> >
>> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-update-xenserver-licenses
>> > + '%{_cloudstackmanagementconf}'
>> > /var/tmp/rpm-tmp.nuuOOp: line 93: fg: no job control
>> > error: Bad exit status from /var/tmp/rpm-tmp.nuuOOp (%install)
>> >
>>
>
>

Re: Errors while packaging master

[Rohit Yadav]

Hi,

It seems this issue was recently fixed on master. I had fixed the packaging 
build after removing awsapi, but a 4.5 merge on master may have introduced some 
issues.

> On 12-May-2015, at 10:06 pm, Erik Weber  wrote:
>
> Anyone able to build the centos63 packages on master? Seems broken after 
> awsapi removal and 4.5 merge.
>
> Atleast I keep getting errors.
>
> Trying to fix it, but it takes time to rebuild and fetch new ones.
>
> --
> Erik
>
> On Tue, May 12, 2015 at 1:28 PM, Erik Weber  wrote:
> Anyone else get this? Happens when i do "bash package.sh -d centos63"
>
> + ln -sf /var/cache/cloudstack/management/temp 
> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/share/cloudstack-management/temp
> + ln -sf /var/cache/cloudstack/management/work 
> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/share/cloudstack-management/work
> + /bin/touch 
> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/var/log/cloudstack/management/catalina.out
> + install -D client/target/utilities/bin/cloud-migrate-databases 
> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-migrate-databases
> + install -D client/target/utilities/bin/cloud-set-guest-password 
> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-set-guest-password
> + install -D client/target/utilities/bin/cloud-set-guest-sshkey 
> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-set-guest-sshkey
> + install -D client/target/utilities/bin/cloud-setup-databases 
> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-setup-databases
> + install -D client/target/utilities/bin/cloud-setup-encryption 
> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-setup-encryption
> + install -D client/target/utilities/bin/cloud-setup-management 
> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-setup-management
> + install -D client/target/utilities/bin/cloud-setup-baremetal 
> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-setup-baremetal
> + install -D client/target/utilities/bin/cloud-sysvmadm 
> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-sysvmadm
> + install -D client/target/utilities/bin/cloud-update-xenserver-licenses 
> /home/jenkins/.jenkins/jobs/cloudstack-4.6-fix-extractable-rpm/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.6.0-SNAPSHOT.el6.x86_64/usr/bin/cloudstack-update-xenserver-licenses
> + '%{_cloudstackmanagementconf}'
> /var/tmp/rpm-tmp.nuuOOp: line 93: fg: no job control
> error: Bad exit status from /var/tmp/rpm-tmp.nuuOOp (%install)
>

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



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

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

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

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

[Daan Hoogland]

erratum:

The link in below mail for the git branch points to the wrong branch,
the text is pointing to the right branch:

https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20150601T1542



Op ma 1 jun. 2015 om 15:49 schreef Daan Hoogland :

> Hi All,
>
> I've created a 4.4.4 release, with the following artifacts up for a vote:
>
> Git Branch and Commit 
> SH:https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/
>  
> 4.4-RC20150601T1542
> Commit: b087514317e9fce350c2dcee6bb5b21fb70c1eb8
>
> List of 
> changes:https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/tags/4.4.4
>
> Source release (checksums and signatures are available at the same
> location):https://dist.apache.org/repos/dist/dev/cloudstack/4.4.4/
>
> PGP release keys (signed using 
> 5AABEBEA):https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> Vote will be open for 72 hours.
>
> For sanity in tallying the vote, can PMC members please be sure to indicate 
> "(binding)" with their vote?
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
>

Re: please help trying to change the ip of my secondary storage

[Guntis Liepins]

I had the same problem.  I changed SecSt address according to
instructions. I noticed that SecSt has old ip address in properties 
under Infrastructure->SecondaryStorage and CloudStack uses old IP to
mount SecSt and snapshots ar failing.
I found out that CloudStack DB has table cloud.image_store which 
contains SecSt URL too.
Look at she table with SELECT * FROM cloud.image_store; 
You have to update URL parameter in this table also. 
It is not documented , but it seems it worked for me.
I suppose it is documentation bug, but man, this was pain...

Re: Regular total loss of connectivity

[Nux!]

Ok, no luck with e1000 either, connectivity is lost after 4 hours (14400 sec). 
That can't be random.

Any ideas?

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Nux!" 
> To: us...@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Sent: Monday, 1 June, 2015 14:35:09
> Subject: Re: Regular total loss of connectivity

> Nope, it's a regular, non-redundant VR.
> 
> I've switched to using e1000 instead of virtio, waiting for a few hours, so 
> how
> it pans out. :-)
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Simon Weller" 
>> To: dev@cloudstack.apache.org
>> Cc: "Cloudstack Users List" 
>> Sent: Monday, 1 June, 2015 13:32:26
>> Subject: Re: Regular total loss of connectivity
> 
>> Is this VR in a redundant pair? If so, does stopping the master and allowing 
>> the
>> slave to take over allow the flow of traffic to resume?
>> 
>> 
>> 
>> From: Nux! 
>> Sent: Monday, June 1, 2015 6:45 AM
>> To: dev@cloudstack.apache.org
>> Cc: Cloudstack Users List
>> Subject: Re: Regular total loss of connectivity
>> 
>> Thanks Simon,
>> 
>> link up/down has not helped, setting tso etc off on the link has not helped
>> either.
>> Connectivity is lost as usual after ~4 hours.
>> 
>> I found some suggestions to try and use the e1000 nic instead of virtio, 
>> will do
>> that.
>> 
>> Lucian
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
>> www.nux.ro
>> 
>> - Original Message -
>>> From: "Simon Weller" 
>>> To: "dev" , "Cloudstack Users List"
>>> 
>>> Sent: Sunday, 31 May, 2015 22:36:56
>>> Subject: Re: Regular total loss of connectivity
>> 
>>> If you ifdown the interface on the router and then ifup it again, does the 
>>> arp
>>> problem resolve itself?
>>>
>>> We've seen a similar issue before caused by malicious/heavy traffic related 
>>> to
>>> this bug:
>>>
>>> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/997978
>>>
>>> - Si
>>> 
>>> From: Nux! 
>>> Sent: Sunday, May 31, 2015 4:25 PM
>>> To: dev; Cloudstack Users List
>>> Subject: Regular total loss of connectivity
>>>
>>> Hi,
>>>
>>> Following a power cut, one of my cloudstack deployments is having a really 
>>> weird
>>> problem that I cannot seem to solve on my own.
>>> Every 3 hours all the public IPs on the VR stop responding from the 
>>> Internet.
>>> From the VR they are of course all reachable.
>>> In the same VLAN as the public IPs there is another physical server, this 
>>> one
>>> can also access the VMs on their IPs just fine.
>>>
>>> The provider has not found the problem and hints at problems with the cloud
>>> platform, however cloudstack worked just fine until the power cut, not to
>>> mention the problem persists through HV and ACS upgrades.
>>>
>>> I'm thinking network side arp issues or something like this, alas I am not 
>>> that
>>> good with network stuff and don't have access to it anyway.
>>>
>>> If I reboot the VR once or twice the IPs start working again and the VMs are
>>> accessible from the internet.
>>>
>>> Ideas?
>>>
>>> Env: CentOS 6, KVM, ACS 44 to 4.5.1, Adv zone
>>>
>>> Lucian
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
> > > www.nux.ro

Re: Regular total loss of connectivity

[Simon Weller]

What does arp show you on the VR when this occurs?
Can you isolate this VR to a different physical host and upstream switch?
If you leave a ping going to some external ip (e.g. 8.8.8.8) from the VR, do 
you still lose connectivity?


From: Nux! 
Sent: Monday, June 1, 2015 12:15 PM
To: us...@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: Regular total loss of connectivity

Ok, no luck with e1000 either, connectivity is lost after 4 hours (14400 sec). 
That can't be random.

Any ideas?

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Nux!" 
> To: us...@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Sent: Monday, 1 June, 2015 14:35:09
> Subject: Re: Regular total loss of connectivity

> Nope, it's a regular, non-redundant VR.
>
> I've switched to using e1000 instead of virtio, waiting for a few hours, so 
> how
> it pans out. :-)
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
>> From: "Simon Weller" 
>> To: dev@cloudstack.apache.org
>> Cc: "Cloudstack Users List" 
>> Sent: Monday, 1 June, 2015 13:32:26
>> Subject: Re: Regular total loss of connectivity
>
>> Is this VR in a redundant pair? If so, does stopping the master and allowing 
>> the
>> slave to take over allow the flow of traffic to resume?
>>
>>
>> 
>> From: Nux! 
>> Sent: Monday, June 1, 2015 6:45 AM
>> To: dev@cloudstack.apache.org
>> Cc: Cloudstack Users List
>> Subject: Re: Regular total loss of connectivity
>>
>> Thanks Simon,
>>
>> link up/down has not helped, setting tso etc off on the link has not helped
>> either.
>> Connectivity is lost as usual after ~4 hours.
>>
>> I found some suggestions to try and use the e1000 nic instead of virtio, 
>> will do
>> that.
>>
>> Lucian
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>> - Original Message -
>>> From: "Simon Weller" 
>>> To: "dev" , "Cloudstack Users List"
>>> 
>>> Sent: Sunday, 31 May, 2015 22:36:56
>>> Subject: Re: Regular total loss of connectivity
>>
>>> If you ifdown the interface on the router and then ifup it again, does the 
>>> arp
>>> problem resolve itself?
>>>
>>> We've seen a similar issue before caused by malicious/heavy traffic related 
>>> to
>>> this bug:
>>>
>>> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/997978
>>>
>>> - Si
>>> 
>>> From: Nux! 
>>> Sent: Sunday, May 31, 2015 4:25 PM
>>> To: dev; Cloudstack Users List
>>> Subject: Regular total loss of connectivity
>>>
>>> Hi,
>>>
>>> Following a power cut, one of my cloudstack deployments is having a really 
>>> weird
>>> problem that I cannot seem to solve on my own.
>>> Every 3 hours all the public IPs on the VR stop responding from the 
>>> Internet.
>>> From the VR they are of course all reachable.
>>> In the same VLAN as the public IPs there is another physical server, this 
>>> one
>>> can also access the VMs on their IPs just fine.
>>>
>>> The provider has not found the problem and hints at problems with the cloud
>>> platform, however cloudstack worked just fine until the power cut, not to
>>> mention the problem persists through HV and ACS upgrades.
>>>
>>> I'm thinking network side arp issues or something like this, alas I am not 
>>> that
>>> good with network stuff and don't have access to it anyway.
>>>
>>> If I reboot the VR once or twice the IPs start working again and the VMs are
>>> accessible from the internet.
>>>
>>> Ideas?
>>>
>>> Env: CentOS 6, KVM, ACS 44 to 4.5.1, Adv zone
>>>
>>> Lucian
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
> > > www.nux.ro

Re: Regular total loss of connectivity

[Rafael Fonseca]

There are also a few kvm bugs which could be related, what kernel and
qemu-kvm versions are you running?

Rafael

On Mon, Jun 1, 2015 at 7:23 PM, Simon Weller  wrote:

> What does arp show you on the VR when this occurs?
> Can you isolate this VR to a different physical host and upstream switch?
> If you leave a ping going to some external ip (e.g. 8.8.8.8) from the VR,
> do you still lose connectivity?
>
> 
> From: Nux! 
> Sent: Monday, June 1, 2015 12:15 PM
> To: us...@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: Regular total loss of connectivity
>
> Ok, no luck with e1000 either, connectivity is lost after 4 hours (14400
> sec). That can't be random.
>
> Any ideas?
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: "Nux!" 
> > To: us...@cloudstack.apache.org
> > Cc: dev@cloudstack.apache.org
> > Sent: Monday, 1 June, 2015 14:35:09
> > Subject: Re: Regular total loss of connectivity
>
> > Nope, it's a regular, non-redundant VR.
> >
> > I've switched to using e1000 instead of virtio, waiting for a few hours,
> so how
> > it pans out. :-)
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
> >
> > - Original Message -
> >> From: "Simon Weller" 
> >> To: dev@cloudstack.apache.org
> >> Cc: "Cloudstack Users List" 
> >> Sent: Monday, 1 June, 2015 13:32:26
> >> Subject: Re: Regular total loss of connectivity
> >
> >> Is this VR in a redundant pair? If so, does stopping the master and
> allowing the
> >> slave to take over allow the flow of traffic to resume?
> >>
> >>
> >> 
> >> From: Nux! 
> >> Sent: Monday, June 1, 2015 6:45 AM
> >> To: dev@cloudstack.apache.org
> >> Cc: Cloudstack Users List
> >> Subject: Re: Regular total loss of connectivity
> >>
> >> Thanks Simon,
> >>
> >> link up/down has not helped, setting tso etc off on the link has not
> helped
> >> either.
> >> Connectivity is lost as usual after ~4 hours.
> >>
> >> I found some suggestions to try and use the e1000 nic instead of
> virtio, will do
> >> that.
> >>
> >> Lucian
> >>
> >> --
> >> Sent from the Delta quadrant using Borg technology!
> >>
> >> Nux!
> >> www.nux.ro
> >>
> >> - Original Message -
> >>> From: "Simon Weller" 
> >>> To: "dev" , "Cloudstack Users List"
> >>> 
> >>> Sent: Sunday, 31 May, 2015 22:36:56
> >>> Subject: Re: Regular total loss of connectivity
> >>
> >>> If you ifdown the interface on the router and then ifup it again, does
> the arp
> >>> problem resolve itself?
> >>>
> >>> We've seen a similar issue before caused by malicious/heavy traffic
> related to
> >>> this bug:
> >>>
> >>> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/997978
> >>>
> >>> - Si
> >>> 
> >>> From: Nux! 
> >>> Sent: Sunday, May 31, 2015 4:25 PM
> >>> To: dev; Cloudstack Users List
> >>> Subject: Regular total loss of connectivity
> >>>
> >>> Hi,
> >>>
> >>> Following a power cut, one of my cloudstack deployments is having a
> really weird
> >>> problem that I cannot seem to solve on my own.
> >>> Every 3 hours all the public IPs on the VR stop responding from the
> Internet.
> >>> From the VR they are of course all reachable.
> >>> In the same VLAN as the public IPs there is another physical server,
> this one
> >>> can also access the VMs on their IPs just fine.
> >>>
> >>> The provider has not found the problem and hints at problems with the
> cloud
> >>> platform, however cloudstack worked just fine until the power cut, not
> to
> >>> mention the problem persists through HV and ACS upgrades.
> >>>
> >>> I'm thinking network side arp issues or something like this, alas I am
> not that
> >>> good with network stuff and don't have access to it anyway.
> >>>
> >>> If I reboot the VR once or twice the IPs start working again and the
> VMs are
> >>> accessible from the internet.
> >>>
> >>> Ideas?
> >>>
> >>> Env: CentOS 6, KVM, ACS 44 to 4.5.1, Adv zone
> >>>
> >>> Lucian
> >>>
> >>> --
> >>> Sent from the Delta quadrant using Borg technology!
> >>>
> >>> Nux!
> > > > www.nux.ro
>

[GitHub] cloudstack pull request: Mocking the Connect object used in the Li...

[rsafonseca]

Github user rsafonseca commented on the pull request:

https://github.com/apache/cloudstack/pull/342#issuecomment-107663305
  
[INFO] Apache CloudStack Plugin - Hypervisor KVM . SUCCESS [6.987s]

Perfect :)


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

[Mike C]

On 2015-05-19 04:13, Rohit Yadav wrote:

Were able to fix the issue? Do we need to update
agent/bindir/libvirtqemuhook.in with Wei’s fix?
I can confirm the below patch fixes the issue I was having. Thank you 
for the help in getting this resolved.


Forgive the delay on my response, work got crazy and I had to drop 
testing for awhile.


-- Mike Crosson

On 2015-05-11 03:02, Wei ZHOU wrote:

Hi Mike,

Please apply the following patch to cloudstack, and copy the file
agent/bindir/libvirtqemuhook.in to repace /etc/libvirt/hooks/qemu on 
your

hosts

--start

diff --git a/agent/bindir/libvirtqemuhook.in b/agent/bindir/
libvirtqemuhook.in
index 7bf9634..a895280 100755
--- a/agent/bindir/libvirtqemuhook.in
+++ b/agent/bindir/libvirtqemuhook.in
@@ -16,6 +16,7 @@
 # specific language governing permissions and limitations
 # under the License.
 import sys
+import re
 from xml.dom.minidom import parse
 from cloudutils.configFileOps import configFileOps
 from cloudutils.networkConfig import networkConfig
@@ -24,21 +25,29 @@ def isOldStyleBridge(brName):
return True
 else:
return False
+def isNewStyleBridge(brName):
+if re.match(r"br(\w+)-(\d+)", brName) == None:
+   return False
+else:
+   return True
 def getGuestNetworkDevice():
 netlib = networkConfig()
 cfo = configFileOps("/etc/cloudstack/agent/agent.properties")
 guestDev = cfo.getEntry("guest.network.device")
 enslavedDev = netlib.getEnslavedDev(guestDev, 1)
-return enslavedDev
+return enslavedDev.split(".")[0]
 def handleMigrateBegin():
 try:
 domain = parse(sys.stdin)
 for interface in domain.getElementsByTagName("interface"):
 source = interface.getElementsByTagName("source")[0]
 bridge = source.getAttribute("bridge")
-if not isOldStyleBridge(bridge):
+if isOldStyleBridge(bridge):
+vlanId = bridge.replace("cloudVirBr","")
+elif isNewStyleBridge(bridge):
+vlanId = re.sub(r"br(\w+)-","",bridge)
+else:
 continue
-vlanId = bridge.replace("cloudVirBr","")
 phyDev = getGuestNetworkDevice()
 newBrName="br" + phyDev + "-" + vlanId
 source.setAttribute("bridge", newBrName)

-end-

Kind regards,
Wei


2015-05-10 7:35 GMT+02:00 Mike C :


On 2015-05-08 20:07, Marcus wrote:


Can you confirm that those bridges and bond devices exist prior to
attempting migration, and that the VMs are attached to them and work?
Perhaps a 'brctl show' and 'virsh dumpxml'. Those look like they 
should be
cloudstack-generated guest network bridges and libvirt is complaining 
they

don't exist

Everything as far as I can tell is working minus this migration. I 
have a

few virtual routers running on this machine and VMs, each environment
running on the box seems to be doing working just fine. The base 
mgmtbr0,
cloudbr0, cloudbr1 all come up at boot prior to CloudStack and are 
working.


Command output is below.

Also: the router seems to have been restarted and was allocated on the
machine I was trying to migrate it to. Trying to migrate it back 
resulted

in the same error message.

-- Mike


# brctl show
bridge name bridge id   STP enabled interfaces
breth0-1209 8000.6805ca095d7f   no  
eth0.1209
breth0-1221 8000.6805ca095d7f   no  
eth0.1221

vnet0
vnet3
cloud0  8000.fe00a9fe0380   no  vnet1
cloudbr08000.6805ca095d7f   no  
eth0.1100

vnet2
cloudbr18000.6805ca095d7f   no  
eth0.1200

mgmtbr0 8000.002564b522ef   no  eth1
virbr0  8000.   yes

# virsh dumpxml r-93-XML

  r-93-VM
  5269e919-564a-4986-92c1-07464e99e3ce
  Debian GNU/Linux 7(64-bit)
  262144
  262144
  1
  
500
  
  
/machine
  
  
hvm


  
  



  
  
  
  
  destroy
  restart
  destroy
  
/usr/bin/kvm-spice

  
  
  
  
  unit='0'/>



  
  
  
  
  
  unit='0'/>



  
  


  


  
  


  
  


  
  
  


  
  
  
  
  


  
  
  
  
  
  


  
  
  


  
  
  
  
  


  
  
  


  
  
  


  
  
  
  


  



listen='172.16.16.31'>

  


  
  
  


  

  
  

[GitHub] cloudstack pull request: Mocking the Connect object used in the Li...

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/342#issuecomment-107672506
  
Awesome!!! :)

Thanks for testing.

@Roh it: could you please merge it? :)

Cheers,
Wilder

Sent from my iPhone

On 01 Jun 2015, at 20:25, Rafael da Fonseca 
mailto:notificati...@github.com>> wrote:


[INFO] Apache CloudStack Plugin - Hypervisor KVM . SUCCESS [6.987s]

Perfect :)

—
Reply to this email directly or view it on 
GitHub.



---
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: jenkins disk full ?

[Srikanteswararao talluri]

There is no space .

/dev/xvdf1   50G   47G 0 100% /var/lib/jenkins/workspace

I have cleaned up builds for 'fastsimulatorbuild' job which were using 9G.
Modified the job to delete old builds and artefacts after 30 builds/30days.


~Talluri

On Mon, Jun 1, 2015 at 8:14 PM, Pierre-Luc Dion  wrote:

> Can someone that have access to the principal jenkins server to check disk
> space left?
>
> getting this error on few slave, the one I've check does not have disk full
>
>
> Thread has died
>
> java.io.IOException: No space left on device
> at java.io.FileOutputStream.writeBytes(Native Method)
> at java.io.FileOutputStream.write(FileOutputStream.java:318)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:316)
> at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149)
> at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233)
> at java.io.BufferedWriter.close(BufferedWriter.java:266)
> at hudson.util.AtomicFileWriter.close(AtomicFileWriter.java:94)
> at hudson.util.AtomicFileWriter.commit(AtomicFileWriter.java:109)
> at hudson.util.TextFile.write(TextFile.java:121)
> at hudson.model.Job.saveNextBuildNumber(Job.java:274)
> at hudson.model.Job.assignBuildNumber(Job.java:332)
> at hudson.model.Run.(Run.java:286)
> at hudson.model.AbstractBuild.(AbstractBuild.java:167)
> at hudson.model.Build.(Build.java:92)
> at hudson.model.FreeStyleBuild.(FreeStyleBuild.java:34)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> at
> jenkins.model.lazy.LazyBuildMixIn.newBuild(LazyBuildMixIn.java:186)
> at hudson.model.AbstractProject.newBuild(AbstractProject.java:1000)
> at
> hudson.model.AbstractProject.createExecutable(AbstractProject.java:1193)
> at
> hudson.model.AbstractProject.createExecutable(AbstractProject.java:143)
> at hudson.model.Executor.run(Executor.java:213)
>
> more info 
>
>
>
> ref:
> http://jenkins.buildacloud.org/computer/cca-slave-02/executors/0/causeOfDeath
>
>
>
> Thanks!
>

[GitHub] cloudstack pull request: Mocking the Connect object used in the Li...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/342#issuecomment-107674315
  
@wilderrodrigues done, merged on master.


---
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: Mocking the Connect object used in the Li...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-8530: KVM hosts without active...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/340#issuecomment-107674771
  
pinging KVM and HA gurus to help review this @kishankavala @wilderrodrigues 
@remibergsma @mlsorensen @abhinandanprateek @devdeep and others
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.
---

Build failed in Jenkins: build-4.5 #478

[jenkins]

See 

Changes:

[Rohit Yadav] schema: Encode URL safe random vnc password string

--
[...truncated 2977 lines...]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-plugin-network-internallb ---
[INFO] Compiling 6 source files to 

[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ 
cloud-plugin-network-elb ---
[INFO] Surefire report directory: 


---
 T E S T S
---
[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ 
cloud-plugin-hypervisor-hyperv ---
[INFO] Surefire report directory: 


---
 T E S T S
---
Running com.cloud.network.lb.LoadBalanceRuleHandlerTest

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Plugin - Network Netscaler 4.5.2-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
cloud-plugin-network-netscaler ---
[INFO] Deleting 

 (includes = [**/*], excludes = [])
[INFO] Deleting 

 (includes = [target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-plugin-network-netscaler ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-plugin-network-palo-alto ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-plugin-network-palo-alto ---
[INFO] Compiling 2 source files to 

[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-plugin-network-netscaler ---
log4j:WARN No appenders could be found for logger 
(com.cloud.network.lb.LoadBalanceRuleHandler).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-plugin-network-netscaler ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.717 sec
Running com.cloud.network.lb.ElasticLoadBalancerManagerImplTest
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
cloud-plugin-network-netscaler ---
[INFO] Compiling 12 source files to 

Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.358 sec

Results :

Tests run: 15, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Plugin - Network Nicira NVP 4.5.2-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
cloud-plugin-network-nvp ---
[INFO] Deleting 

 (includes = [**/*], excludes = [])
[INFO] Deleting 

 (includes = [target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-plugin-network-nvp ---
[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ 
cloud-plugin-network-inter

[GitHub] cloudstack pull request: CLOUDSTACK-8530: KVM hosts without active...

[mlsorensen]

Github user mlsorensen commented on the pull request:

https://github.com/apache/cloudstack/pull/340#issuecomment-107684409
  
Looks fine to me.

On Mon, Jun 1, 2015 at 12:13 PM, Rohit Yadav 
wrote:

> pinging KVM and HA gurus to help review this @kishankavala
>  @wilderrodrigues
>  @remibergsma
>  @mlsorensen
>  @abhinandanprateek
>  @devdeep
>  and others
> thanks :)
>
> —
> Reply to this email directly or view it on GitHub
> .
>



---
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: jenkins disk full ?

[Pierre-Luc Dion]

thanks  Srikanteswararao, it worked  and we have centos63 rpm now for
master branch!



*Pierre-Luc DION*
Architecte de Solution Cloud | Cloud Solutions Architect
t 855.652.5683

*CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_

On Mon, Jun 1, 2015 at 3:09 PM, Srikanteswararao talluri  wrote:

> There is no space .
>
> /dev/xvdf1   50G   47G 0 100% /var/lib/jenkins/workspace
>
> I have cleaned up builds for 'fastsimulatorbuild' job which were using 9G.
> Modified the job to delete old builds and artefacts after 30 builds/30days.
>
>
> ~Talluri
>
> On Mon, Jun 1, 2015 at 8:14 PM, Pierre-Luc Dion 
> wrote:
>
> > Can someone that have access to the principal jenkins server to check
> disk
> > space left?
> >
> > getting this error on few slave, the one I've check does not have disk
> full
> >
> >
> > Thread has died
> >
> > java.io.IOException: No space left on device
> > at java.io.FileOutputStream.writeBytes(Native Method)
> > at java.io.FileOutputStream.write(FileOutputStream.java:318)
> > at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> > at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:316)
> > at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149)
> > at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233)
> > at java.io.BufferedWriter.close(BufferedWriter.java:266)
> > at hudson.util.AtomicFileWriter.close(AtomicFileWriter.java:94)
> > at hudson.util.AtomicFileWriter.commit(AtomicFileWriter.java:109)
> > at hudson.util.TextFile.write(TextFile.java:121)
> > at hudson.model.Job.saveNextBuildNumber(Job.java:274)
> > at hudson.model.Job.assignBuildNumber(Job.java:332)
> > at hudson.model.Run.(Run.java:286)
> > at hudson.model.AbstractBuild.(AbstractBuild.java:167)
> > at hudson.model.Build.(Build.java:92)
> > at hudson.model.FreeStyleBuild.(FreeStyleBuild.java:34)
> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > Method)
> > at
> >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> > at
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> > at
> java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> > at
> > jenkins.model.lazy.LazyBuildMixIn.newBuild(LazyBuildMixIn.java:186)
> > at
> hudson.model.AbstractProject.newBuild(AbstractProject.java:1000)
> > at
> > hudson.model.AbstractProject.createExecutable(AbstractProject.java:1193)
> > at
> > hudson.model.AbstractProject.createExecutable(AbstractProject.java:143)
> > at hudson.model.Executor.run(Executor.java:213)
> >
> > more info 
> >
> >
> >
> > ref:
> >
> http://jenkins.buildacloud.org/computer/cca-slave-02/executors/0/causeOfDeath
> >
> >
> >
> > Thanks!
> >
>

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

[Milamber]

Hello,

The new RC works fine, but if I would like upgrade to 4.5.1, the No 
Upgrade Path error come.


That is on the Release Notes? Or that is a bug? Or wait the 4.5.2?

Milamber


===
2015-06-01 21:38:59,233 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) 
Grabbing lock to check for database upgrade.
2015-06-01 21:38:59,354 DEBUG [c.c.u.d.VersionDaoImpl] (main:null) 
Checking to see if the database is at a version before it was the 
version table is created
2015-06-01 21:38:59,414 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) 
DB version = 4.4.4 Code Version = 4.5.1
2015-06-01 21:38:59,416 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) 
Database upgrade must be performed from 4.4.4 to 4.5.1
2015-06-01 21:38:59,416 ERROR [c.c.u.DatabaseUpgradeChecker] (main:null) 
There is no upgrade path from 4.4.4 to 4.5.1

===


On 01/06/2015 14:49, Daan Hoogland wrote:

Hi All,

I've created a 4.4.4 release, with the following artifacts up for a vote:

Git Branch and Commit
SH:https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/
4.4-RC20150601T1542
Commit: b087514317e9fce350c2dcee6bb5b21fb70c1eb8

List of 
changes:https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/tags/4.4.4

Source release (checksums and signatures are available at the same
location):https://dist.apache.org/repos/dist/dev/cloudstack/4.4.4/

PGP release keys (signed using
5AABEBEA):https://dist.apache.org/repos/dist/release/cloudstack/KEYS
Vote will be open for 72 hours.

For sanity in tallying the vote, can PMC members please be sure to
indicate "(binding)" with their vote?

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

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

[Daan Hoogland]

It is to be fixed in 4.5 not in 4.4.

Op ma 1 jun. 2015 om 23:07 schreef Milamber :

> Hello,
>
> The new RC works fine, but if I would like upgrade to 4.5.1, the No
> Upgrade Path error come.
>
> That is on the Release Notes? Or that is a bug? Or wait the 4.5.2?
>
> Milamber
>
>
> ===
> 2015-06-01 21:38:59,233 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
> Grabbing lock to check for database upgrade.
> 2015-06-01 21:38:59,354 DEBUG [c.c.u.d.VersionDaoImpl] (main:null)
> Checking to see if the database is at a version before it was the
> version table is created
> 2015-06-01 21:38:59,414 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
> DB version = 4.4.4 Code Version = 4.5.1
> 2015-06-01 21:38:59,416 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
> Database upgrade must be performed from 4.4.4 to 4.5.1
> 2015-06-01 21:38:59,416 ERROR [c.c.u.DatabaseUpgradeChecker] (main:null)
> There is no upgrade path from 4.4.4 to 4.5.1
> ===
>
>
> On 01/06/2015 14:49, Daan Hoogland wrote:
> > Hi All,
> >
> > I've created a 4.4.4 release, with the following artifacts up for a vote:
> >
> > Git Branch and Commit
> > SH:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/
> > <
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20150526T2323
> >4.4-RC20150601T1542
> > Commit: b087514317e9fce350c2dcee6bb5b21fb70c1eb8
> >
> > List of changes:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/tags/4.4.4
> >
> > Source release (checksums and signatures are available at the same
> > location):https://dist.apache.org/repos/dist/dev/cloudstack/4.4.4/
> >
> > PGP release keys (signed using
> > 5AABEBEA):https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> > Vote will be open for 72 hours.
> >
> > For sanity in tallying the vote, can PMC members please be sure to
> > indicate "(binding)" with their vote?
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
>
>

Re: Regular total loss of connectivity

[Nux!]

I was using latest stock EL6 , but now am trying kernel 4.x and qemu-rhev from 
ovirt.org.

Thanks,
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Rafael Fonseca" 
> To: dev@cloudstack.apache.org
> Cc: us...@cloudstack.apache.org
> Sent: Monday, 1 June, 2015 18:42:23
> Subject: Re: Regular total loss of connectivity

> There are also a few kvm bugs which could be related, what kernel and
> qemu-kvm versions are you running?
> 
> Rafael
> 
> On Mon, Jun 1, 2015 at 7:23 PM, Simon Weller  wrote:
> 
>> What does arp show you on the VR when this occurs?
>> Can you isolate this VR to a different physical host and upstream switch?
>> If you leave a ping going to some external ip (e.g. 8.8.8.8) from the VR,
>> do you still lose connectivity?
>>
>> 
>> From: Nux! 
>> Sent: Monday, June 1, 2015 12:15 PM
>> To: us...@cloudstack.apache.org
>> Cc: dev@cloudstack.apache.org
>> Subject: Re: Regular total loss of connectivity
>>
>> Ok, no luck with e1000 either, connectivity is lost after 4 hours (14400
>> sec). That can't be random.
>>
>> Any ideas?
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>> - Original Message -
>> > From: "Nux!" 
>> > To: us...@cloudstack.apache.org
>> > Cc: dev@cloudstack.apache.org
>> > Sent: Monday, 1 June, 2015 14:35:09
>> > Subject: Re: Regular total loss of connectivity
>>
>> > Nope, it's a regular, non-redundant VR.
>> >
>> > I've switched to using e1000 instead of virtio, waiting for a few hours,
>> so how
>> > it pans out. :-)
>> >
>> > --
>> > Sent from the Delta quadrant using Borg technology!
>> >
>> > Nux!
>> > www.nux.ro
>> >
>> > - Original Message -
>> >> From: "Simon Weller" 
>> >> To: dev@cloudstack.apache.org
>> >> Cc: "Cloudstack Users List" 
>> >> Sent: Monday, 1 June, 2015 13:32:26
>> >> Subject: Re: Regular total loss of connectivity
>> >
>> >> Is this VR in a redundant pair? If so, does stopping the master and
>> allowing the
>> >> slave to take over allow the flow of traffic to resume?
>> >>
>> >>
>> >> 
>> >> From: Nux! 
>> >> Sent: Monday, June 1, 2015 6:45 AM
>> >> To: dev@cloudstack.apache.org
>> >> Cc: Cloudstack Users List
>> >> Subject: Re: Regular total loss of connectivity
>> >>
>> >> Thanks Simon,
>> >>
>> >> link up/down has not helped, setting tso etc off on the link has not
>> helped
>> >> either.
>> >> Connectivity is lost as usual after ~4 hours.
>> >>
>> >> I found some suggestions to try and use the e1000 nic instead of
>> virtio, will do
>> >> that.
>> >>
>> >> Lucian
>> >>
>> >> --
>> >> Sent from the Delta quadrant using Borg technology!
>> >>
>> >> Nux!
>> >> www.nux.ro
>> >>
>> >> - Original Message -
>> >>> From: "Simon Weller" 
>> >>> To: "dev" , "Cloudstack Users List"
>> >>> 
>> >>> Sent: Sunday, 31 May, 2015 22:36:56
>> >>> Subject: Re: Regular total loss of connectivity
>> >>
>> >>> If you ifdown the interface on the router and then ifup it again, does
>> the arp
>> >>> problem resolve itself?
>> >>>
>> >>> We've seen a similar issue before caused by malicious/heavy traffic
>> related to
>> >>> this bug:
>> >>>
>> >>> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/997978
>> >>>
>> >>> - Si
>> >>> 
>> >>> From: Nux! 
>> >>> Sent: Sunday, May 31, 2015 4:25 PM
>> >>> To: dev; Cloudstack Users List
>> >>> Subject: Regular total loss of connectivity
>> >>>
>> >>> Hi,
>> >>>
>> >>> Following a power cut, one of my cloudstack deployments is having a
>> really weird
>> >>> problem that I cannot seem to solve on my own.
>> >>> Every 3 hours all the public IPs on the VR stop responding from the
>> Internet.
>> >>> From the VR they are of course all reachable.
>> >>> In the same VLAN as the public IPs there is another physical server,
>> this one
>> >>> can also access the VMs on their IPs just fine.
>> >>>
>> >>> The provider has not found the problem and hints at problems with the
>> cloud
>> >>> platform, however cloudstack worked just fine until the power cut, not
>> to
>> >>> mention the problem persists through HV and ACS upgrades.
>> >>>
>> >>> I'm thinking network side arp issues or something like this, alas I am
>> not that
>> >>> good with network stuff and don't have access to it anyway.
>> >>>
>> >>> If I reboot the VR once or twice the IPs start working again and the
>> VMs are
>> >>> accessible from the internet.
>> >>>
>> >>> Ideas?
>> >>>
>> >>> Env: CentOS 6, KVM, ACS 44 to 4.5.1, Adv zone
>> >>>
>> >>> Lucian
>> >>>
>> >>> --
>> >>> Sent from the Delta quadrant using Borg technology!
>> >>>
>> >>> Nux!
>> > > > www.nux.ro

Re: Regular total loss of connectivity

[Nux!]

Arp remains unchanged when it happens, I only have one host.
I'll try the ping thing next.

Thanks
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Simon Weller" 
> To: us...@cloudstack.apache.org, dev@cloudstack.apache.org
> Sent: Monday, 1 June, 2015 18:23:13
> Subject: Re: Regular total loss of connectivity

> What does arp show you on the VR when this occurs?
> Can you isolate this VR to a different physical host and upstream switch?
> If you leave a ping going to some external ip (e.g. 8.8.8.8) from the VR, do 
> you
> still lose connectivity?
> 
> 
> From: Nux! 
> Sent: Monday, June 1, 2015 12:15 PM
> To: us...@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: Regular total loss of connectivity
> 
> Ok, no luck with e1000 either, connectivity is lost after 4 hours (14400 sec).
> That can't be random.
> 
> Any ideas?
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Nux!" 
>> To: us...@cloudstack.apache.org
>> Cc: dev@cloudstack.apache.org
>> Sent: Monday, 1 June, 2015 14:35:09
>> Subject: Re: Regular total loss of connectivity
> 
>> Nope, it's a regular, non-redundant VR.
>>
>> I've switched to using e1000 instead of virtio, waiting for a few hours, so 
>> how
>> it pans out. :-)
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>> - Original Message -
>>> From: "Simon Weller" 
>>> To: dev@cloudstack.apache.org
>>> Cc: "Cloudstack Users List" 
>>> Sent: Monday, 1 June, 2015 13:32:26
>>> Subject: Re: Regular total loss of connectivity
>>
>>> Is this VR in a redundant pair? If so, does stopping the master and 
>>> allowing the
>>> slave to take over allow the flow of traffic to resume?
>>>
>>>
>>> 
>>> From: Nux! 
>>> Sent: Monday, June 1, 2015 6:45 AM
>>> To: dev@cloudstack.apache.org
>>> Cc: Cloudstack Users List
>>> Subject: Re: Regular total loss of connectivity
>>>
>>> Thanks Simon,
>>>
>>> link up/down has not helped, setting tso etc off on the link has not helped
>>> either.
>>> Connectivity is lost as usual after ~4 hours.
>>>
>>> I found some suggestions to try and use the e1000 nic instead of virtio, 
>>> will do
>>> that.
>>>
>>> Lucian
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>> - Original Message -
 From: "Simon Weller" 
 To: "dev" , "Cloudstack Users List"
 
 Sent: Sunday, 31 May, 2015 22:36:56
 Subject: Re: Regular total loss of connectivity
>>>
 If you ifdown the interface on the router and then ifup it again, does the 
 arp
 problem resolve itself?

 We've seen a similar issue before caused by malicious/heavy traffic 
 related to
 this bug:

 https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/997978

 - Si
 
 From: Nux! 
 Sent: Sunday, May 31, 2015 4:25 PM
 To: dev; Cloudstack Users List
 Subject: Regular total loss of connectivity

 Hi,

 Following a power cut, one of my cloudstack deployments is having a really 
 weird
 problem that I cannot seem to solve on my own.
 Every 3 hours all the public IPs on the VR stop responding from the 
 Internet.
 From the VR they are of course all reachable.
 In the same VLAN as the public IPs there is another physical server, this 
 one
 can also access the VMs on their IPs just fine.

 The provider has not found the problem and hints at problems with the cloud
 platform, however cloudstack worked just fine until the power cut, not to
 mention the problem persists through HV and ACS upgrades.

 I'm thinking network side arp issues or something like this, alas I am not 
 that
 good with network stuff and don't have access to it anyway.

 If I reboot the VR once or twice the IPs start working again and the VMs 
 are
 accessible from the internet.

 Ideas?

 Env: CentOS 6, KVM, ACS 44 to 4.5.1, Adv zone

 Lucian

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
> > > > www.nux.ro

RE: [Feature] Cloudstack KVM with RBD

[Star Guo]

Yes, I just find snapshot.backup.rightafter in
./server/src/com/cloud/configuration/Config.java, but no be used in others
.java.
When will it be used in roadmap ?

Best Regards,
Star Guo

=

Il 28/05/2015 03:18, Star Guo ha scritto:
> However, when I do some volume operation, such as create snapshot, 
> create template, template deploy ect, it also take some time to finish 
> because copy data between primary storage and secondary storage.
> So I think that if we support the same rbd as secondary storage, and 
> use ceph COW feature, it may reduce the time and just some seconds. 
> (OpenStack can make glance and cinder as the same rbd)

I think that the issue is related to this, too:
https://issues.apache.org/jira/browse/CLOUDSTACK-4858
(marked as Unresolved)

--
Gerolamo Valcamonica

--
Gerolamo Valcamonica

Build failed in Jenkins: simulator-singlerun #1194

[jenkins]

See 

--
[...truncated 1808 lines...]
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on simu

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

[jenkins]

See 

Changes:

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Removing the CheckStateCommand form the IF statement on 
LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Fixing assertion on the tests that are execting exceptions

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Renaming LibvirtConnectionWrapper to LibvirtUtilitiesHelper

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Refactoring the LibvirtComputingResource

[wrodrigues] Fixing method call on KVMGuru to reach StorageSubSystemCommand

[wrodrigues] Fixing testModifySshKeysCommand in the 
LibvirtComputingResourceTest class

[abhinandan.prateek] adding mysql dependency for usage

[abhinandan.prateek] adding simple logging for java version dependency

[Gaurav Aradhye] CLOUDSTACK-8466: Fixed import error in 
testpath_snapshot_limits.py

[abhinandan.prateek] CLOUDSTACK-8467: set version to unknown instead of null

[wrodrigues] Fixing license header in a file added during the LibVirt refactor

[Gaurav Aradhye] CLOUDSTACK-8468: Correct test case in test_bugs.py

[koushik] CLOUDSTACK-8301: Enable configuring local storage use for system VMs 
at zone level

[Rohit Yadav] schema: fix foreign key checks for 3.0.7 to 4.1.0 upgrade path

[Rohit Yadav] debian: allow tomcat7 as optional dependency

[Rohit Yadav] listPortForwardingRules: fix typo in doc

[koushik] CLOUDSTACK-8301: Enable configuring local storage use for system VMs 
at zone level

[koushik] CLOUDSTACK-8471:Automation for feature Enable configuring local 
storage use for system VMs at zone level

[Gaurav Aradhye] CLOUDSTACK-8476: Disabling Zone, Pod, Cluster: --Test cases 
for testing the behaviour of resources running on zone and admin/non-admin user 
after disabling the Zone

[github] Systemvm: Disable services that slow down boot

[Rohit Yadav] systemvmtemplate: install libc6:i386 for 64bit template

[Rohit Yadav] Fixing the testGetHostStatsCommand test under 
LibvirtComputingResourceTest. - Removed the expected value from the Test 
annotation - Mocking the bash path in order to avoid environment/OS issues

[Rohit Yadav] ui: add custom error handling page

[Rohit Yadav] rat: add license header to error.jsp

[Gaurav Aradhye] CLOUDSTACK-8481: Adding test cases for validating global limit 
on concurrent snapshots

[Rohit Yadav] Tests for Disable Storage Provisioning

[Rohit Yadav] Implementation for the ability to disable a storage pool for 
provisioning

[Gaurav Aradhye] CLOUDSTACK-8482: Enhacing recurring snapshots test cases

[isoutham] Allow forward to fix port forwarding rules

[koushik] CLOUDSTACK-8301: Enable configuring local storage use for system VMs 
at zone level

[koushik] CLOUDSTACK-8301: Enable configuring local storage use for system VMs 
at zone level

[koushik] CLOUDSTACK-8471:Automation for feature Enable configuring local 
storage use for system VMs at zone level

[koushik] CLOUDSTACK-8301: Enable configuring local storage use for system VMs 
at zone level. This commit contains the UI changes for the feature.

[Gaurav Aradhye] CLOUDSTACK-8394: Skipping recurring snapshot test cases for 
Hyperv and LXC

[Rohit Yadav] Changing the JUnit runner in order to avoid problems with Java 8 
- All tests passed using different approaches - Maven with parameters: 
-Dmaven.compiler.source=1.8 -Dmaven.compiler.target=1.8 - Maven without 
parameters

[wido] CLOUDSTACK-8489: Set smbios information for guest

[Raj

Build failed in Jenkins: simulator-singlerun #1195

[jenkins]

See 

--
Started by upstream project "build-master-simulator" build number 2013
originally caused by:
 Started by upstream project "build-master" build number 2348
 originally caused by:
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
  Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on simulator in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=400
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=400
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > /usr/bin/git --version # timeout=400
 > /usr/bin/git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git 
 > +refs/heads/*:refs/remo

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

[jenkins]

See 

--
[...truncated 27277 lines...]
[INFO] No sources to compile
[INFO] 
[INFO] >>> findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ 
cloud-quickcloud >>>
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.0:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.0: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.142s]
[INFO] Apache CloudStack . SUCCESS [2.318s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.995s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [22.878s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:35.689s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.110s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [51.529s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [29.592s]
[INFO] Apache CloudStack API . SUCCESS [1:55.713s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [18.156s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [33.196s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.096s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [30.715s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [24.511s]
[INFO] Apache CloudStack Core  SUCCESS [1:20.648s]
[INFO] Apache CloudStack Agents .. SUCCESS [35.536s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [37.472s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [17.677s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:12.685s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [40.022s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [28.921s]
[INFO] Apache CloudStack Server .. SUCCESS [4:14.706s]
[INFO] Apache CloudStack Usage Server  SUCCESS [56.112s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:23.618s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.072s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.456s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [56.201s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [52.940s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [4:30.295s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [49.919s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [39.716s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [39.513s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [1:15.960s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [15.462s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [7.416s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [1.086s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [30.225s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[24.663s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[37.943s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [19.751s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [24.256s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [17.183s]
[INFO] Apache CloudStack Plugin - Host Anti-Aff

[GitHub] cloudstack pull request: Modification in setupClass to skip testca...

[pritisarap12]

GitHub user pritisarap12 opened a pull request:

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

Modification in setupClass to skip testcases rather than throwing exception 

Skip the testcase which is throwing an exception on "Exceeding connection 
limit to NetScaler device"

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

$ git pull https://github.com/pritisarap12/cloudstack 
Regrassion-testing-test_netscaler_lb_algo

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

https://github.com/apache/cloudstack/pull/343.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 #343


commit 3dcfa82de109264a724b5aeca0809271295727a6
Author: pritisarap12 
Date:   2015-06-02T05:34:34Z

Modification in setupClass to skip testcases rather than throwing an
exception on "Exceeding connection limit to Netscaler device"




---
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-8487 : Add vMotion related tes...

[abhinavroy02]

Github user abhinavroy02 commented on the pull request:

https://github.com/apache/cloudstack/pull/268#issuecomment-107814688
  
@gauravaradhye Incorporated the review comments. Please check.


---
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: Modification in setupClass to skip testca...

[gauravaradhye]

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

https://github.com/apache/cloudstack/pull/343#discussion_r31494908
  
--- Diff: test/integration/component/test_netscaler_lb_algo.py ---
@@ -76,8 +78,12 @@ def setUpClass(cls):
 cls.testdata["service_offering"]
 )
 except Exception as e:
-cls.tearDownClass()
-raise Exception("Warning: Exception in setUpClass: %s" % e)
+if cls.exception_string in e:
--- End diff --

Do case insensitive string comparisons to be safe. Change wherever 
applicable.


---
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-8487 : Add vMotion related tes...

[abhinavroy02]

Github user abhinavroy02 commented on the pull request:

https://github.com/apache/cloudstack/pull/268#issuecomment-107824748
  
Attaching test execution logs 

This Test Path tests vMotion for NFS as well as VMFS within cluster, ... 
=== TestName: 
test_01_vm_and_volumes_live_migration_for_vmware_vmfs_1___VMFSwithin_clusterwindows__
 | Status : EXCEPTION ===
ok
This Test Path tests vMotion for NFS as well as VMFS within cluster, ... 
=== TestName: 
test_01_vm_and_volumes_live_migration_for_vmware_vmfs_2___VMFSwithin_clusterwindows__
 | Status : EXCEPTION ===
ok
This Test Path tests vMotion for NFS as well as VMFS within cluster, ... 
=== TestName: 
test_01_vm_and_volumes_live_migration_for_vmware_vmfs_3___VMFSacross_clusterlinux__
 | Status : SUCCESS ===
ok
This Test Path tests vMotion for NFS as well as VMFS within cluster, ... 
=== TestName: 
test_01_vm_and_volumes_live_migration_for_vmware_vmfs_4___VMFSacross_clusterwindows__
 | Status : EXCEPTION ===
ok
This Test Path tests vMotion for NFS as well as VMFS within cluster, ... 
=== TestName: 
test_01_vm_and_volumes_live_migration_for_vmware_vmfs_5___NetworkFilesystemwithin_clusterlinux__
 | Status : EXCEPTION ===
ok
This Test Path tests vMotion for NFS as well as VMFS within cluster, ... 
=== TestName: 
test_01_vm_and_volumes_live_migration_for_vmware_vmfs_6___NetworkFilesystemwithin_clusterwindows__
 | Status : EXCEPTION ===
ok
This Test Path tests vMotion for NFS as well as VMFS within cluster, ... 
=== TestName: 
test_01_vm_and_volumes_live_migration_for_vmware_vmfs_7___NetworkFilesystemacross_clusterlinux__
 | Status : SUCCESS ===
ok
This Test Path tests vMotion for NFS as well as VMFS within cluster, ... 
=== TestName: 
test_01_vm_and_volumes_live_migration_for_vmware_vmfs_8___NetworkFilesystemacross_clusterwindows__
 | Status : EXCEPTION ===
ok
This Test Path tests vMotion for VM in local storage within cluster, ... 
SKIP: The setup doesn't have local storage enabled
This Test Path tests vMotion for VM in local storage within cluster, ... 
SKIP: The setup doesn't have local storage enabled
This Test Path tests vMotion for VM in local storage within cluster, ... 
SKIP: The setup doesn't have local storage enabled
This Test Path tests vMotion for VM in local storage within cluster, ... 
SKIP: The setup doesn't have local storage enabled
This Test Path tests vMotion for NFS as well as VMFS within cluster, ... 
SKIP: The setup doesn't have enough zone wide primary storages of VMFS type, we 
need atleast 2
This Test Path tests vMotion for NFS as well as VMFS within cluster, ... 
SKIP: The setup doesn't have enough zone wide primary storages of VMFS type, we 
need atleast 2
This Test Path tests vMotion for NFS as well as VMFS within cluster, ... 
SKIP: The setup doesn't have enough zone wide primary storages of VMFS type, we 
need atleast 2
This Test Path tests vMotion for NFS as well as VMFS within cluster, ... 
SKIP: The setup doesn't have enough zone wide primary storages of VMFS type, we 
need atleast 2
This Test Path tests vMotion for NFS as well as VMFS within cluster, ... 
SKIP: The setup doesn't have enough zone wide primary storages of 
NetworkFilesystem type, we need atleast 2
This Test Path tests vMotion for NFS as well as VMFS within cluster, ... 
SKIP: The setup doesn't have enough zone wide primary storages of 
NetworkFilesystem type, we need atleast 2
This Test Path tests vMotion for NFS as well as VMFS within cluster, ... 
SKIP: The setup doesn't have enough zone wide primary storages of 
NetworkFilesystem type, we need atleast 2
This Test Path tests vMotion for NFS as well as VMFS within cluster, ... 
SKIP: The setup doesn't have enough zone wide primary storages of 
NetworkFilesystem type, we need atleast 2
This Test Path tests vMotion from NFS ok---> VMFS , within cluster ... === 
TestName: 
test_04_vm_and_volumes_live_migration_for_vmware_across_nfs_vmfs_1___within_clusterlinux__
 | Status : EXCEPTION ===
ok
This Test Path tests vMotion from NFS ok---> VMFS , within cluster ... === 
TestName: 
test_04_vm_and_volumes_live_migration_for_vmware_across_nfs_vmfs_2___within_clusterwindows__
 | Status : EXCEPTION ===
ok
This Test Path tests vMotion from NFS ok---> VMFS , within cluster ... 
SKIP: The setup doesn't have enough pools or enough hosts. To run these tests 
the setup must have atleast 2 clusters, each having min 2 host 2 vmfs storage 
pools and 2 nfs storage pools
This Test Path tests vMotion from NFS ok---> VMFS , within cluster ... 
SKIP: The setup doesn't have enough pools or enough hosts. To run these tests 
the setup must have atleast 2 clusters, each having min 2 host 2 vmfs storage 
pools and 2 nfs storage pools
Test scenarios like : ... === TestName: 
test_05_vm_and_volumes_live_migration_for_vmware_ne

[GitHub] cloudstack pull request: CLOUDSTACK-8487 : Add vMotion related tes...

[gauravaradhye]

Github user gauravaradhye commented on the pull request:

https://github.com/apache/cloudstack/pull/268#issuecomment-107824833
  
This looks good and all review comments have been incorporated. Merging 
this.


---
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: Modification in setupClass to skip testca...

[pritisarap12]

Github user pritisarap12 commented on the pull request:

https://github.com/apache/cloudstack/pull/343#issuecomment-107824912
  
Done with the review changes.


---
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-8487 : Add vMotion related tes...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: simulator-singlerun #1196

[jenkins]

See 

--
Started by upstream project "build-master-simulator" build number 2014
originally caused by:
 Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on simulator in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=400
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=400
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > /usr/bin/git --version # timeout=400
 > /usr/bin/git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:735)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:983)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1016)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1258)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528)
at hudson.model.Run.execute(Run.java:1759)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
Caused by: hudson.plugins.git.GitException: Command "/usr/bin/git fetch --tags 
--progress https://git-wip-us.apache.org/repos/asf/cloudstack.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: error:  while accessing 
https://git-wip-us.apache.org/repos/asf/cloudstack.git/info/refs

fatal: HTTP request failed

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1591)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1379)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:86)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:324)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:121)
at hudson.remoting.UserRequest.perform(UserRequest.java:49)
at hudson.remoting.Request$2.run(Request.java:324)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
at ..remote call to simulator(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:221)
at hudson.remoting.Channel.call(Channel.java:752)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor375.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at sun.proxy.$Proxy46.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:733)
... 11 more
ERROR: Error fetching remote repo 'origin'
[xUnit] [INFO] - Starting to record.
[xUnit] [INFO] - Processing JUnit
[xUnit] [INFO] - [JUnit] - 1 test report file(s) were found with the pattern 
'xunit.xml' relative to 
' for the testing 
framework 'JUnit'.
[xUnit] [ERROR] - Test reports were found but not all of them are new. Did all 
the tests run?
  *  is 1 
mo 1 day old

[xUnit] [INFO] - Failing BUILD.
[xUnit] [INFO] - There are errors when processing test results.
[xUnit] [INFO] - Skipping tests recording.
[xUnit] [INFO] - Stop build.

Build failed in Jenkins: simulator-singlerun #1197

[jenkins]

See 

--
Started by upstream project "build-master-simulator" build number 2015
originally caused by:
 Started by upstream project "build-master" build number 2349
 originally caused by:
  Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on simulator in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=400
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=400
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > /usr/bin/git --version # timeout=400
 > /usr/bin/git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:735)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:983)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1016)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1258)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528)
at hudson.model.Run.execute(Run.java:1759)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
Caused by: hudson.plugins.git.GitException: Command "/usr/bin/git fetch --tags 
--progress https://git-wip-us.apache.org/repos/asf/cloudstack.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: error:  while accessing 
https://git-wip-us.apache.org/repos/asf/cloudstack.git/info/refs

fatal: HTTP request failed

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1591)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1379)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:86)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:324)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:121)
at hudson.remoting.UserRequest.perform(UserRequest.java:49)
at hudson.remoting.Request$2.run(Request.java:324)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
at ..remote call to simulator(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:221)
at hudson.remoting.Channel.call(Channel.java:752)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor375.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at sun.proxy.$Proxy46.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:733)
... 11 more
ERROR: Error fetching remote repo 'origin'
[xUnit] [INFO] - Starting to record.
[xUnit] [INFO] - Processing JUnit
[xUnit] [INFO] - [JUnit] - 1 test report file(s) were found with the pattern 
'xunit.xml' relative to 
' for the testing 
framework 'JUnit'.
[xUnit] [ERROR] - Test reports were found but not all of them are new. Did all 
the tests run?
  *  is 1 
mo 1 day old

[xUnit] [INFO] - Failing BUILD.
[xUnit] [INFO] - There are errors when processing test results.
[xUni