Build failed in Jenkins: build-master-jdk18 #42

[jenkins]

See 

Changes:

[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

--
[...truncated 2672 lines...]
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-plugin-hypervisor-xenserver ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-plugin-hypervisor-xenserver ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 4 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ 
cloud-plugin-hypervisor-xenserver ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 95 source files to 

[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-plugin-hypervisor-xenserver ---
[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:3.2:testCompile (default-testCompile) @ 
cloud-plugin-hypervisor-xenserver ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 7 source files to 

[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ 
cloud-plugin-hypervisor-xenserver ---
[INFO] Surefire report directory: 


---
 T E S T S
---
Running 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer56FP1WrapperTest
log4j:WARN No appenders could be found for logger 
(com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool).
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: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.338 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer56FP1WrapperTest
Running com.cloud.hypervisor.xenserver.resource.wrapper.XenServer610WrapperTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.936 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer610WrapperTest
Running com.cloud.hypervisor.xenserver.resource.wrapper.XcpServerWrapperTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.183 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XcpServerWrapperTest
Running com.cloud.hypervisor.xenserver.resource.wrapper.XenServer56WrapperTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.338 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer56WrapperTest
Running 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer620SP1WrapperTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.291 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer620SP1WrapperTest
Running com.cloud.hypervisor.xenserver.resource.wrapper.XenServer620WrapperTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.037 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer620WrapperTest
Running com.cloud.hypervisor.xenserver.resource.wrapper.CitrixRequestWrapperTest
Tests run: 77, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.708 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.CitrixRequestWrapperTest

Results :

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

[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Plugin - Hypervisor KVM 4.6.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
cloud-plugin-hypervisor-kvm ---
[INFO] Deleting 

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

 (includes = [target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-plugin-hypervisor-kvm ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-plugin-hypervisor-kvm ---

[GitHub] cloudstack pull request: Refactor/libvirt resource

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/233#issuecomment-102951817
  
Hi @kishankavala,

I will have a look at that, although that's pretty weird since I have 
tested on a KVM environment as well. Don't see why the bean would have been 
injected for me and not for you.

Have you done a full clean/install of the latest source?

Cheers,
Wilder


---
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: Preparing for 4.6

[Stephen Turner]

I don't like squashed commits either. Merging a branch on github lets the 
reviewer switch between seeing the overall diff, and seeing the individual 
commits' diffs. (And to answer the other point, also allows the author to make 
a pull request comment, different from any of the individual commits' comments).

When reviewing on github, I normally start with the overall diff, but I like to 
be able to switch into the individual ones too, to understand the motivation 
for particular parts separately. So I think you get the best of both worlds 
that way.

-- 
Stephen Turner


-Original Message-
From: Rajani Karuturi [mailto:raj...@apache.org] 
Sent: 16 May 2015 03:38
To: dev@cloudstack.apache.org
Subject: Re: Preparing for 4.6

-1 for squashed commits. I agree to what Daan said. Feature branch merge is 
more convenient than squashed single commit.
If it was a small feature which involved single dev squashing is still ok.
But, a big no when it comes to big feature/refactoring involving effort from 
multiple people and multiple reviews.


On Sat, May 16, 2015 at 3:21 AM, Mike Tutkowski < mike.tutkow...@solidfire.com> 
wrote:

Those comments may or may not be useful anymore. What they describe may have 
been superseded by a subsequent commit.

On Fri, May 15, 2015 at 3:12 PM, Daan Hoogland >
wrote:

> those comments will then have to be squashed s well, to this i put a -1.
If
> those comments where usefull at review-time they will be usefull in 
> the future as well.
>
> Op vr 15 mei 2015 om 19:29 schreef Marcus >:
>
> > I'm not sure it is any different. Either you have a giant block of 
> > code that represents a bunch of little commits, or a giant block 
> > that is one commit. We don't want to merge little chunks to master 
> > that don't fully implement the feature.
> >
> > To the extent that features and goals can be split up, yes, we don't
want
> > those features squashed together, or even submitted together, 
> > squashed
or
> > not. An example of this is in combining formatting/syntax fixes with 
> > functional changes, I have tried to review such pull requests and it 
> > is very difficult to see what is going on in a 1k line request when 
> > 2/3 of
> the
> > changes are just reformatting noise.
> >
> > Ideally the code is reviewed at the commit level as each small 
> > commit
> goes
> > from the developer's workstation to the dev branch, but I don't see 
> > a
way
> > around reviewing the same amount of code in a pull request that
> represents
> > multiple small commits vs one squashed commit. You do get more
visibility
> > into the comments, though.
> >
> > I suppose a way to get both would be to branch master, do a pull 
> > request from your dev branch to that branch, at which point it is 
> > reviewed, then squash merge that back into master.
> > On May 15, 2015 8:55 AM, "Daan Hoogland" >
> wrote:
> >
> > > Sebastien, I don't think commits in a big feature should be squashed.
> It
> > > hinders review if to big chunks are submitted at once.
> > >
> > > Op vr 15 mei 2015 om 11:27 schreef Sebastien Goasguen <
> run...@gmail.com 
> > >:
> > >
> > > > Folks,
> > > >
> > > > As we prepare to try a new process for 4.6 release it would be 
> > > > nice
> to
> > > > start paying attention to master.
> > > >
> > > > - Good commit messages
> > > > - Reference to a JIRA bug
> > > > - Squashing commits ( cc/ wilder :))
> > > >
> > > > While you can apply patches directly, good practice is to apply 
> > > > the
> > patch
> > > > to a branch and then merge that branch into master.
> > > >
> > > > Before we start enforcing some of these things more strongly, 
> > > > please
> > keep
> > > > it in mind.
> > > >
> > > > thanks,
> > > >
> > > > -sebastien
> > >
> >
>



--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com 
o: 303.746.7302
Advancing the way the world uses the cloud
*™*



--
~Rajani
Sent from my Windows Phone

[GitHub] cloudstack pull request: Refactor/libvirt resource

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/233#issuecomment-102954888
  
Hi @karuturi,

I had a look and it has more to do with the hard coded paths in the code 
(which were already present) and the setup of the machine where the Java8 
builds run.

Good it failed, because that code has never been tested before.

I will make the test better and push a fix asap.

Thanks for the heads up.

Cheers,
Wilder 


---
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: Preparing for 4.6

[Wilder Rodrigues]

-1 for squashed commits on refactor/new features work. ;)

If we have, let’s say, 2 commits, I think that would be fine to squash. But if 
someone has the courage to refactor 7 thousand lines of code on +30 commits, by 
squashing would difficult the review

In addition, if those 2 commits are part of 2 different bugs, I would actually 
have them in different PRs.

The best case scenario: 1 commit to fix the bug and 1 commit for the unit tests 
added. If that’s about refactor/new feature, I wouldn’t bother about squashing.

My 2 cents.

Cheers,
Wilder


> On 18 May 2015, at 09:48, Stephen Turner  wrote:
> 
> I don't like squashed commits either. Merging a branch on github lets the 
> reviewer switch between seeing the overall diff, and seeing the individual 
> commits' diffs. (And to answer the other point, also allows the author to 
> make a pull request comment, different from any of the individual commits' 
> comments).
> 
> When reviewing on github, I normally start with the overall diff, but I like 
> to be able to switch into the individual ones too, to understand the 
> motivation for particular parts separately. So I think you get the best of 
> both worlds that way.
> 
> -- 
> Stephen Turner
> 
> 
> -Original Message-
> From: Rajani Karuturi [mailto:raj...@apache.org] 
> Sent: 16 May 2015 03:38
> To: dev@cloudstack.apache.org
> Subject: Re: Preparing for 4.6
> 
> -1 for squashed commits. I agree to what Daan said. Feature branch merge is 
> more convenient than squashed single commit.
> If it was a small feature which involved single dev squashing is still ok.
> But, a big no when it comes to big feature/refactoring involving effort from 
> multiple people and multiple reviews.
> 
> 
> On Sat, May 16, 2015 at 3:21 AM, Mike Tutkowski < 
> mike.tutkow...@solidfire.com> wrote:
> 
> Those comments may or may not be useful anymore. What they describe may have 
> been superseded by a subsequent commit.
> 
> On Fri, May 15, 2015 at 3:12 PM, Daan Hoogland  >
> wrote:
> 
>> those comments will then have to be squashed s well, to this i put a -1.
> If
>> those comments where usefull at review-time they will be usefull in 
>> the future as well.
>> 
>> Op vr 15 mei 2015 om 19:29 schreef Marcus  >:
>> 
>>> I'm not sure it is any different. Either you have a giant block of 
>>> code that represents a bunch of little commits, or a giant block 
>>> that is one commit. We don't want to merge little chunks to master 
>>> that don't fully implement the feature.
>>> 
>>> To the extent that features and goals can be split up, yes, we don't
> want
>>> those features squashed together, or even submitted together, 
>>> squashed
> or
>>> not. An example of this is in combining formatting/syntax fixes with 
>>> functional changes, I have tried to review such pull requests and it 
>>> is very difficult to see what is going on in a 1k line request when 
>>> 2/3 of
>> the
>>> changes are just reformatting noise.
>>> 
>>> Ideally the code is reviewed at the commit level as each small 
>>> commit
>> goes
>>> from the developer's workstation to the dev branch, but I don't see 
>>> a
> way
>>> around reviewing the same amount of code in a pull request that
>> represents
>>> multiple small commits vs one squashed commit. You do get more
> visibility
>>> into the comments, though.
>>> 
>>> I suppose a way to get both would be to branch master, do a pull 
>>> request from your dev branch to that branch, at which point it is 
>>> reviewed, then squash merge that back into master.
>>> On May 15, 2015 8:55 AM, "Daan Hoogland"  >
>> wrote:
>>> 
 Sebastien, I don't think commits in a big feature should be squashed.
>> It
 hinders review if to big chunks are submitted at once.
 
 Op vr 15 mei 2015 om 11:27 schreef Sebastien Goasguen <
>> run...@gmail.com 
 :
 
> Folks,
> 
> As we prepare to try a new process for 4.6 release it would be 
> nice
>> to
> start paying attention to master.
> 
> - Good commit messages
> - Reference to a JIRA bug
> - Squashing commits ( cc/ wilder :))
> 
> While you can apply patches directly, good practice is to apply 
> the
>>> patch
> to a branch and then merge that branch into master.
> 
> Before we start enforcing some of these things more strongly, 
> please
>>> keep
> it in mind.
> 
> thanks,
> 
> -sebastien
 
>>> 
>> 
> 
> 
> 
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com 
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*
> 
> 
> 
> --
> ~Rajani
> Sent from my Windows Phone

Re: Preparing for 4.6

[Rene Moser]

Hi

On 15.05.2015 11:27, Sebastien Goasguen wrote:
> Folks,
> 
> As we prepare to try a new process for 4.6 release it would be nice to start 
> paying attention to master.
> 
> - Good commit messages

The question is, what makes a commit message good? Maybe this helps:

http://chris.beams.io/posts/git-commit/

> - Reference to a JIRA bug

Must there be a JIRA bug? I did some commits without jira bugs in the
past. But I noticed that those are not "tracked" in the changelog of the
new release. So should there be a policy (is there?) that there must be
a jira bug for fixes?

> - Squashing commits ( cc/ wilder :))

This really depends. I would not generally prefer squashing commits.

The example of
https://github.com/apache/cloudstack/commits/master?page=2 is more an
example of "bad" commit messages.

If you look at the commits, they make sense but the commit message
indicates that they cover similar work in different aspects, which they
actually don't.

But if you look at this example here
https://github.com/ansible/ansible-modules-extras/commits/devel?author=gregdek
where you can see dozens of similar commits, those should be squashed.

Yours
René



signature.asc
Description: OpenPGP digital signature

Re: Preparing for 4.6

[Erik Weber]

On Mon, May 18, 2015 at 10:26 AM, Rene Moser  wrote:

> Hi
>
> On 15.05.2015 11:27, Sebastien Goasguen wrote:
> > Folks,
> >
> > As we prepare to try a new process for 4.6 release it would be nice to
> start paying attention to master.
> >
> > - Good commit messages
>
> The question is, what makes a commit message good? Maybe this helps:
>
> http://chris.beams.io/posts/git-commit/
>
> > - Reference to a JIRA bug
>
> Must there be a JIRA bug? I did some commits without jira bugs in the
> past. But I noticed that those are not "tracked" in the changelog of the
> new release. So should there be a policy (is there?) that there must be
> a jira bug for fixes?
>
>
I believe there should be a JIRA bug for most things. JIRA is a good place
to document why you're doing something, it's also easy to use as a source
for release notes as you discovered.
It's also good practice to document bugs/fixes, it's generally easier to
find JIRA bugs than it is to find commit messages - especially for
non-developers / newbies.

For major code commits (new features, important fixes, security fixes) I'd
say it should be a requirement, but I don't know if it already is or not.



> > - Squashing commits ( cc/ wilder :))
>
> This really depends. I would not generally prefer squashing commits.
>
> The example of
> https://github.com/apache/cloudstack/commits/master?page=2 is more an
> example of "bad" commit messages.
>
> If you look at the commits, they make sense but the commit message
> indicates that they cover similar work in different aspects, which they
> actually don't.
>
> But if you look at this example here
>
> https://github.com/ansible/ansible-modules-extras/commits/devel?author=gregdek
> where you can see dozens of similar commits, those should be squashed.
>
>

+1 to squashing related commits where it makes sense to do so
-1 to a general rule of squashing the whole PR

-- 
Erik

RE: Preparing for 4.6

[Stephen Turner]

In my XenCenter dev team at Citrix, we have the policy of requiring a ticket 
number on every commit. If we find a bug and there isn't already a ticket, we 
create a ticket before committing the fix. I guess I've just dug through 
history too many times to understand why something that appears wrong was done, 
only to find an inadequate description at the end of the trail.

-- 
Stephen Turner


-Original Message-
From: Erik Weber [mailto:terbol...@gmail.com] 
Sent: 18 May 2015 09:32
To: dev
Subject: Re: Preparing for 4.6

On Mon, May 18, 2015 at 10:26 AM, Rene Moser  wrote:

> Hi
>
> On 15.05.2015 11:27, Sebastien Goasguen wrote:
> > Folks,
> >
> > As we prepare to try a new process for 4.6 release it would be nice 
> > to
> start paying attention to master.
> >
> > - Good commit messages
>
> The question is, what makes a commit message good? Maybe this helps:
>
> http://secure-web.cisco.com/1cOtAU9lruLvoJl9SBdNSTHN6eyvml6nO5JlwT8_V2
> d_Y7wsnHAV3NiHTOya0cRQyt1WuG_fzithwjk4Qu-l3usM-B_yzy7V4qaxtoDIlEixysid
> QZ0ZbuK0YMNgknwBUaRUBJYNkjfGoppsXIpUXcmRvOH565otFMCmJUX2mfkrj_z5Vwm0wh
> PDqu2ZkGk1a/http%3A%2F%2Fchris.beams.io%2Fposts%2Fgit-commit%2F
>
> > - Reference to a JIRA bug
>
> Must there be a JIRA bug? I did some commits without jira bugs in the 
> past. But I noticed that those are not "tracked" in the changelog of 
> the new release. So should there be a policy (is there?) that there 
> must be a jira bug for fixes?
>
>
I believe there should be a JIRA bug for most things. JIRA is a good place to 
document why you're doing something, it's also easy to use as a source for 
release notes as you discovered.
It's also good practice to document bugs/fixes, it's generally easier to find 
JIRA bugs than it is to find commit messages - especially for non-developers / 
newbies.

For major code commits (new features, important fixes, security fixes) I'd say 
it should be a requirement, but I don't know if it already is or not.



> > - Squashing commits ( cc/ wilder :))
>
> This really depends. I would not generally prefer squashing commits.
>
> The example of
> https://github.com/apache/cloudstack/commits/master?page=2 is more an 
> example of "bad" commit messages.
>
> If you look at the commits, they make sense but the commit message 
> indicates that they cover similar work in different aspects, which 
> they actually don't.
>
> But if you look at this example here
>
> https://github.com/ansible/ansible-modules-extras/commits/devel?author
> =gregdek where you can see dozens of similar commits, those should be 
> squashed.
>
>

+1 to squashing related commits where it makes sense to do so
-1 to a general rule of squashing the whole PR

--
Erik

Re: Preparing for 4.6

[Rajani Karuturi]

That is a problem with linear history while its not actually linear.

If you look at the DAG, its reflects the actual

$ git log --graph --pretty=short
* commit 256e227cd5be63186a989e2c99ded0da5e7dea71
| Author: Rohit Yadav 
|
| schema: fix foreign key checks for 3.0.7 to 4.1.0 upgrade path
|
* commit b1f2e598e83e8ec018ae993f918accb0199b9237
| Author: Gaurav Aradhye 
|
| CLOUDSTACK-8468: Correct test case in test_bugs.py
|
* commit c7d2e444d2981464dd115d1030371cde2fdaeb68
| Author: wilderrodrigues 
|
| Fixing license header in a file added during the LibVirt refactor
|   - New class is MigrateKVMAsync
|
*   commit 45c0fa2faa7b5f0b2b2f2863cde7ad5e786115fa
|\  Merge: 60b6dc1 f575206
| | Author: wilderrodrigues 
| |
| | Merge branch 'refactor/libvirt_resource' of
https://github.com/schubergphilis/cloudstack
| |
| * commit f575206ad4348fb7fc0fe312a1e797bac23d011b
| | Author: wilderrodrigues 
| |
| | Fixing testModifySshKeysCommand in the LibvirtComputingResourceTest
class
| |   - The test was okay, but when running in an environment where a
/root/.ssh/id_rsa existed, it would return true then fail
| |   - We now mock the calls to methods that return the key paths,
instead of relying in the static variables
| |
| * commit b284b841929c74a8e5273f8a31a26ed9bba5d139
| | Author: wilderrodrigues 
| |
| | Fixing method call on KVMGuru to reach StorageSubSystemCommand
| |
| * commit 74ad48db55d141f697b6e8235e7ac472d844dd57
| | Author: wilderrodrigues 
| |
| | Refactoring the LibvirtComputingResource
| |   - Adding LibvirtStartCommandWrapper
| |   - 8 unit tests added
| |   - KVM hypervisor plugin with 23.2% coverage
| |



~Rajani

On Sat, May 16, 2015 at 1:41 PM, Sebastien Goasguen 
wrote:

> So I was looking at the libvirt commit from wilder:
>
> https://github.com/apache/cloudstack/commits/master?page=2
>
> is that what we want ?
>
>
> > On May 16, 2015, at 4:37 AM, Rajani Karuturi  wrote:
> >
> > -1 for squashed commits. I agree to what Daan said. Feature branch merge
> is
> > more convenient than squashed single commit.
> > If it was a small feature which involved single dev squashing is still
> ok.
> > But, a big no when it comes to big feature/refactoring involving effort
> > from multiple people and multiple reviews.
> >
> >
> > On Sat, May 16, 2015 at 3:21 AM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> > Those comments may or may not be useful anymore. What they describe may
> > have been superseded by a subsequent commit.
> >
> > On Fri, May 15, 2015 at 3:12 PM, Daan Hoogland  > >
> > wrote:
> >
> >> those comments will then have to be squashed s well, to this i put a -1.
> > If
> >> those comments where usefull at review-time they will be usefull in the
> >> future as well.
> >>
> >> Op vr 15 mei 2015 om 19:29 schreef Marcus  > >:
> >>
> >>> I'm not sure it is any different. Either you have a giant block of code
> >>> that represents a bunch of little commits, or a giant block that is one
> >>> commit. We don't want to merge little chunks to master that don't fully
> >>> implement the feature.
> >>>
> >>> To the extent that features and goals can be split up, yes, we don't
> > want
> >>> those features squashed together, or even submitted together, squashed
> > or
> >>> not. An example of this is in combining formatting/syntax fixes with
> >>> functional changes, I have tried to review such pull requests and it is
> >>> very difficult to see what is going on in a 1k line request when 2/3 of
> >> the
> >>> changes are just reformatting noise.
> >>>
> >>> Ideally the code is reviewed at the commit level as each small commit
> >> goes
> >>> from the developer's workstation to the dev branch, but I don't see a
> > way
> >>> around reviewing the same amount of code in a pull request that
> >> represents
> >>> multiple small commits vs one squashed commit. You do get more
> > visibility
> >>> into the comments, though.
> >>>
> >>> I suppose a way to get both would be to branch master, do a pull
> request
> >>> from your dev branch to that branch, at which point it is reviewed,
> then
> >>> squash merge that back into master.
> >>> On May 15, 2015 8:55 AM, "Daan Hoogland"  > >
> >> wrote:
> >>>
>  Sebastien, I don't think commits in a big feature should be squashed.
> >> It
>  hinders review if to big chunks are submitted at once.
> 
>  Op vr 15 mei 2015 om 11:27 schreef Sebastien Goasguen <
> >> run...@gmail.com 
>  :
> 
> > Folks,
> >
> > As we prepare to try a new process for 4.6 release it would be nice
> >> to
> > start paying attention to master.
> >
> > - Good commit messages
> > - Reference to a JIRA bug
> > - Squashing commits ( cc/ wilder :))
> >
> > While you can apply patches directly, good practice is to apply the
> >>> patch
> > to a branch and then merge that branch into master.
> >
> > Before we start enforcing some of these things more strongly, please

Re: Preparing for 4.6

[Wilder Rodrigues]

Hi there,

I agree with the Jira ticket for the "new features, important fixes, security 
fixes"

But I don’t think only about "new features, important fixes, security fixes”. I 
put most of my time in make the code better and tested, for what we call 
refactoring/rewriting/redesigning. Should we also create Jira issues for that 
and mark them as Improvement?

Taking into account the [VPC] Virtual Router, Citrix Resource Base and Libvirt 
Computing Resource refactoring, we had only internal issues on Jira. However, 
the changes have been documented on the 4.5/4.6 sections of the Apache / 
Developers / Design Documents wiki:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactor+for+Redundant+Virtual+Router+Implementation
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactoring+XenServer+Hypervisor+Plugin

The Libvirt documentation is on its way, since the PR was pushed only last week.

Cheers,
Wilder


On 18 May 2015, at 10:39, Stephen Turner 
mailto:stephen.tur...@citrix.com>> wrote:

In my XenCenter dev team at Citrix, we have the policy of requiring a ticket 
number on every commit. If we find a bug and there isn't already a ticket, we 
create a ticket before committing the fix. I guess I've just dug through 
history too many times to understand why something that appears wrong was done, 
only to find an inadequate description at the end of the trail.

--
Stephen Turner


-Original Message-
From: Erik Weber [mailto:terbol...@gmail.com]
Sent: 18 May 2015 09:32
To: dev
Subject: Re: Preparing for 4.6

On Mon, May 18, 2015 at 10:26 AM, Rene Moser 
mailto:m...@renemoser.net>> wrote:

Hi

On 15.05.2015 11:27, Sebastien Goasguen wrote:
Folks,

As we prepare to try a new process for 4.6 release it would be nice
to
start paying attention to master.

- Good commit messages

The question is, what makes a commit message good? Maybe this helps:

http://secure-web.cisco.com/1cOtAU9lruLvoJl9SBdNSTHN6eyvml6nO5JlwT8_V2
d_Y7wsnHAV3NiHTOya0cRQyt1WuG_fzithwjk4Qu-l3usM-B_yzy7V4qaxtoDIlEixysid
QZ0ZbuK0YMNgknwBUaRUBJYNkjfGoppsXIpUXcmRvOH565otFMCmJUX2mfkrj_z5Vwm0wh
PDqu2ZkGk1a/http%3A%2F%2Fchris.beams.io%2Fposts%2Fgit-commit%2F

- Reference to a JIRA bug

Must there be a JIRA bug? I did some commits without jira bugs in the
past. But I noticed that those are not "tracked" in the changelog of
the new release. So should there be a policy (is there?) that there
must be a jira bug for fixes?


I believe there should be a JIRA bug for most things. JIRA is a good place to 
document why you're doing something, it's also easy to use as a source for 
release notes as you discovered.
It's also good practice to document bugs/fixes, it's generally easier to find 
JIRA bugs than it is to find commit messages - especially for non-developers / 
newbies.

For major code commits (new features, important fixes, security fixes) I'd say 
it should be a requirement, but I don't know if it already is or not.



- Squashing commits ( cc/ wilder :))

This really depends. I would not generally prefer squashing commits.

The example of
https://github.com/apache/cloudstack/commits/master?page=2 is more an
example of "bad" commit messages.

If you look at the commits, they make sense but the commit message
indicates that they cover similar work in different aspects, which
they actually don't.

But if you look at this example here

https://github.com/ansible/ansible-modules-extras/commits/devel?author
=gregdek where you can see dozens of similar commits, those should be
squashed.



+1 to squashing related commits where it makes sense to do so
-1 to a general rule of squashing the whole PR

--
Erik

Re: Preparing for 4.6

[Rene Moser]

Hi Stephan

On 18.05.2015 10:39, Stephen Turner wrote:
> In my XenCenter dev team at Citrix, we have the policy of requiring a ticket 
> number on every commit. If we find a bug and there isn't already a ticket, we 
> create a ticket before committing the fix. I guess I've just dug through 
> history too many times to understand why something that appears wrong was 
> done, only to find an inadequate description at the end of the trail.

IMHO understanding why commit x changed is more a problem of the commit
message or description.

If I pick a random fix commit in the linux kernel,
https://github.com/torvalds/linux/commit/5c1ac56b51b9d222ab202dec1ac2f4215346129d
you see this small fix and a detailed description, why.

Personally I do not like the dependency to network related, centraliced
ticket tracking system for understanding code changes of a distributed SCM.

But I do see the advantage in seeing what has been reported to be broken
and what commit fixes this bug. But the commit description should be
fairly detailed, why a commit changed something.

However since the changelog for the users is actually not generated from
the git log, it makes totally sense to open a ticket before fixing bugs,
to get all fixes covered in the changelog.

Yours
René



signature.asc
Description: OpenPGP digital signature

RE: Preparing for 4.6

[Stephen Turner]

Speaking for my XenCenter team again, for things like that we would have an 
improvement ticket, pointing to the wiki page.

By the way, this also allows us to schedule the work on our sprint, but we had 
the policy even before we were doing Scrum. In a large, distributed, volunteer 
organisation, I would argue that it's even more important to be able to trace 
the change back to its reason, now and later.

-- 
Stephen Turner


-Original Message-
From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com] 
Sent: 18 May 2015 10:11
To: dev@cloudstack.apache.org
Subject: Re: Preparing for 4.6

Hi there,

I agree with the Jira ticket for the "new features, important fixes, security 
fixes"

But I don’t think only about "new features, important fixes, security fixes”. I 
put most of my time in make the code better and tested, for what we call 
refactoring/rewriting/redesigning. Should we also create Jira issues for that 
and mark them as Improvement?

Taking into account the [VPC] Virtual Router, Citrix Resource Base and Libvirt 
Computing Resource refactoring, we had only internal issues on Jira. However, 
the changes have been documented on the 4.5/4.6 sections of the Apache / 
Developers / Design Documents wiki:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactor+for+Redundant+Virtual+Router+Implementation
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactoring+XenServer+Hypervisor+Plugin

The Libvirt documentation is on its way, since the PR was pushed only last week.

Cheers,
Wilder


On 18 May 2015, at 10:39, Stephen Turner 
mailto:stephen.tur...@citrix.com>> wrote:

In my XenCenter dev team at Citrix, we have the policy of requiring a ticket 
number on every commit. If we find a bug and there isn't already a ticket, we 
create a ticket before committing the fix. I guess I've just dug through 
history too many times to understand why something that appears wrong was done, 
only to find an inadequate description at the end of the trail.

--
Stephen Turner


-Original Message-
From: Erik Weber [mailto:terbol...@gmail.com]
Sent: 18 May 2015 09:32
To: dev
Subject: Re: Preparing for 4.6

On Mon, May 18, 2015 at 10:26 AM, Rene Moser 
mailto:m...@renemoser.net>> wrote:

Hi

On 15.05.2015 11:27, Sebastien Goasguen wrote:
Folks,

As we prepare to try a new process for 4.6 release it would be nice to start 
paying attention to master.

- Good commit messages

The question is, what makes a commit message good? Maybe this helps:

http://secure-web.cisco.com/1cOtAU9lruLvoJl9SBdNSTHN6eyvml6nO5JlwT8_V2
d_Y7wsnHAV3NiHTOya0cRQyt1WuG_fzithwjk4Qu-l3usM-B_yzy7V4qaxtoDIlEixysid
QZ0ZbuK0YMNgknwBUaRUBJYNkjfGoppsXIpUXcmRvOH565otFMCmJUX2mfkrj_z5Vwm0wh
PDqu2ZkGk1a/http%3A%2F%2Fchris.beams.io%2Fposts%2Fgit-commit%2F

- Reference to a JIRA bug

Must there be a JIRA bug? I did some commits without jira bugs in the past. But 
I noticed that those are not "tracked" in the changelog of the new release. So 
should there be a policy (is there?) that there must be a jira bug for fixes?


I believe there should be a JIRA bug for most things. JIRA is a good place to 
document why you're doing something, it's also easy to use as a source for 
release notes as you discovered.
It's also good practice to document bugs/fixes, it's generally easier to find 
JIRA bugs than it is to find commit messages - especially for non-developers / 
newbies.

For major code commits (new features, important fixes, security fixes) I'd say 
it should be a requirement, but I don't know if it already is or not.



- Squashing commits ( cc/ wilder :))

This really depends. I would not generally prefer squashing commits.

The example of
https://github.com/apache/cloudstack/commits/master?page=2 is more an example 
of "bad" commit messages.

If you look at the commits, they make sense but the commit message indicates 
that they cover similar work in different aspects, which they actually don't.

But if you look at this example here

https://github.com/ansible/ansible-modules-extras/commits/devel?author
=gregdek where you can see dozens of similar commits, those should be squashed.



+1 to squashing related commits where it makes sense to do so
-1 to a general rule of squashing the whole PR

--
Erik

Re: Preparing for 4.6

[Abhinandan Prateek]

> On 18-May-2015, at 2:02 pm, Erik Weber  wrote:
>
> On Mon, May 18, 2015 at 10:26 AM, Rene Moser  wrote:
>
>> Hi
>>
>> On 15.05.2015 11:27, Sebastien Goasguen wrote:
>>> Folks,
>>>
>>> As we prepare to try a new process for 4.6 release it would be nice to
>> start paying attention to master.
>>>
>>> - Good commit messages
>>
>> The question is, what makes a commit message good? Maybe this helps:
>>
>> http://chris.beams.io/posts/git-commit/
>>
>>> - Reference to a JIRA bug
>>
>> Must there be a JIRA bug? I did some commits without jira bugs in the
>> past. But I noticed that those are not "tracked" in the changelog of the
>> new release. So should there be a policy (is there?) that there must be
>> a jira bug for fixes?
>>
>>
> I believe there should be a JIRA bug for most things. JIRA is a good place
> to document why you're doing something, it's also easy to use as a source
> for release notes as you discovered.
> It's also good practice to document bugs/fixes, it's generally easier to
> find JIRA bugs than it is to find commit messages - especially for
> non-developers / newbies.
>
> For major code commits (new features, important fixes, security fixes) I'd
> say it should be a requirement, but I don't know if it already is or not.
>

+1
This was sort of a unwritten rule that any commit should have a Jira id. That 
way it is easier to track across releases and also it is easier to know the 
what the commit is solving/fixing.


>
>>> - Squashing commits ( cc/ wilder :))
>>
>> This really depends. I would not generally prefer squashing commits.
>>
>> The example of
>> https://github.com/apache/cloudstack/commits/master?page=2 is more an
>> example of "bad" commit messages.
>>
>> If you look at the commits, they make sense but the commit message
>> indicates that they cover similar work in different aspects, which they
>> actually don't.
>>
>> But if you look at this example here
>>
>> https://github.com/ansible/ansible-modules-extras/commits/devel?author=gregdek
>> where you can see dozens of similar commits, those should be squashed.
>>
>>
>
> +1 to squashing related commits where it makes sense to do so
> -1 to a general rule of squashing the whole PR
>
> --
> Erik

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

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

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

Re: Preparing for 4.6

[Wilder Rodrigues]

Okay,

+1 for create the ACS Jira issue for improvements as well.

Since Xen and Libvirt redesign will be on 4.6 - and are already documented - I 
will just create 2 issues so we have a way of keeping track of them.

Cheers,
Wilder


On 18 May 2015, at 11:16, Stephen Turner 
mailto:stephen.tur...@citrix.com>> wrote:

Speaking for my XenCenter team again, for things like that we would have an 
improvement ticket, pointing to the wiki page.

By the way, this also allows us to schedule the work on our sprint, but we had 
the policy even before we were doing Scrum. In a large, distributed, volunteer 
organisation, I would argue that it's even more important to be able to trace 
the change back to its reason, now and later.

--
Stephen Turner


-Original Message-
From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com]
Sent: 18 May 2015 10:11
To: dev@cloudstack.apache.org
Subject: Re: Preparing for 4.6

Hi there,

I agree with the Jira ticket for the "new features, important fixes, security 
fixes"

But I don’t think only about "new features, important fixes, security fixes”. I 
put most of my time in make the code better and tested, for what we call 
refactoring/rewriting/redesigning. Should we also create Jira issues for that 
and mark them as Improvement?

Taking into account the [VPC] Virtual Router, Citrix Resource Base and Libvirt 
Computing Resource refactoring, we had only internal issues on Jira. However, 
the changes have been documented on the 4.5/4.6 sections of the Apache / 
Developers / Design Documents wiki:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactor+for+Redundant+Virtual+Router+Implementation
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactoring+XenServer+Hypervisor+Plugin

The Libvirt documentation is on its way, since the PR was pushed only last week.

Cheers,
Wilder


On 18 May 2015, at 10:39, Stephen Turner 
mailto:stephen.tur...@citrix.com>>
 wrote:

In my XenCenter dev team at Citrix, we have the policy of requiring a ticket 
number on every commit. If we find a bug and there isn't already a ticket, we 
create a ticket before committing the fix. I guess I've just dug through 
history too many times to understand why something that appears wrong was done, 
only to find an inadequate description at the end of the trail.

--
Stephen Turner


-Original Message-
From: Erik Weber [mailto:terbol...@gmail.com]
Sent: 18 May 2015 09:32
To: dev
Subject: Re: Preparing for 4.6

On Mon, May 18, 2015 at 10:26 AM, Rene Moser 
mailto:m...@renemoser.net>> 
wrote:

Hi

On 15.05.2015 11:27, Sebastien Goasguen wrote:
Folks,

As we prepare to try a new process for 4.6 release it would be nice to start 
paying attention to master.

- Good commit messages

The question is, what makes a commit message good? Maybe this helps:

http://secure-web.cisco.com/1cOtAU9lruLvoJl9SBdNSTHN6eyvml6nO5JlwT8_V2
d_Y7wsnHAV3NiHTOya0cRQyt1WuG_fzithwjk4Qu-l3usM-B_yzy7V4qaxtoDIlEixysid
QZ0ZbuK0YMNgknwBUaRUBJYNkjfGoppsXIpUXcmRvOH565otFMCmJUX2mfkrj_z5Vwm0wh
PDqu2ZkGk1a/http%3A%2F%2Fchris.beams.io%2Fposts%2Fgit-commit%2F

- Reference to a JIRA bug

Must there be a JIRA bug? I did some commits without jira bugs in the past. But 
I noticed that those are not "tracked" in the changelog of the new release. So 
should there be a policy (is there?) that there must be a jira bug for fixes?


I believe there should be a JIRA bug for most things. JIRA is a good place to 
document why you're doing something, it's also easy to use as a source for 
release notes as you discovered.
It's also good practice to document bugs/fixes, it's generally easier to find 
JIRA bugs than it is to find commit messages - especially for non-developers / 
newbies.

For major code commits (new features, important fixes, security fixes) I'd say 
it should be a requirement, but I don't know if it already is or not.



- Squashing commits ( cc/ wilder :))

This really depends. I would not generally prefer squashing commits.

The example of
https://github.com/apache/cloudstack/commits/master?page=2 is more an example 
of "bad" commit messages.

If you look at the commits, they make sense but the commit message indicates 
that they cover similar work in different aspects, which they actually don't.

But if you look at this example here

https://github.com/ansible/ansible-modules-extras/commits/devel?author
=gregdek where you can see dozens of similar commits, those should be squashed.



+1 to squashing related commits where it makes sense to do so
-1 to a general rule of squashing the whole PR

--
Erik

RE: Preparing for 4.6

[Stephen Turner]

Yes, a really detailed commit comment like that Linux one can work too, and I 
would be happy if I found that when doing code archaeology. But I guess I find 
that most of the time, a Jira ticket is a better place to hold that 
information. Somehow the developer is encouraged to write more, and it can also 
contain screenshots of the error, discussion with other developers, etc.

-- 
Stephen Turner


-Original Message-
From: Rene Moser [mailto:m...@renemoser.net] 
Sent: 18 May 2015 10:13
To: dev@cloudstack.apache.org
Subject: Re: Preparing for 4.6

Hi Stephan

On 18.05.2015 10:39, Stephen Turner wrote:
> In my XenCenter dev team at Citrix, we have the policy of requiring a ticket 
> number on every commit. If we find a bug and there isn't already a ticket, we 
> create a ticket before committing the fix. I guess I've just dug through 
> history too many times to understand why something that appears wrong was 
> done, only to find an inadequate description at the end of the trail.

IMHO understanding why commit x changed is more a problem of the commit message 
or description.

If I pick a random fix commit in the linux kernel, 
https://github.com/torvalds/linux/commit/5c1ac56b51b9d222ab202dec1ac2f4215346129d
you see this small fix and a detailed description, why.

Personally I do not like the dependency to network related, centraliced ticket 
tracking system for understanding code changes of a distributed SCM.

But I do see the advantage in seeing what has been reported to be broken and 
what commit fixes this bug. But the commit description should be fairly 
detailed, why a commit changed something.

However since the changelog for the users is actually not generated from the 
git log, it makes totally sense to open a ticket before fixing bugs, to get all 
fixes covered in the changelog.

Yours
René

Re: Preparing for 4.6

[Sebastien Goasguen]

I am also in favor of text changelog in the root.

Creating JIRA for everything may lead to bad tickets anyway.

What is also nice is a quick changelog. The habit would be for everyone to 
remember to update the change log when they do a commit (and agree on a format 
for it)...



> On May 18, 2015, at 11:27 AM, Wilder Rodrigues 
>  wrote:
> 
> Okay,
> 
> +1 for create the ACS Jira issue for improvements as well.
> 
> Since Xen and Libvirt redesign will be on 4.6 - and are already documented - 
> I will just create 2 issues so we have a way of keeping track of them.
> 
> Cheers,
> Wilder
> 
> 
> On 18 May 2015, at 11:16, Stephen Turner 
> mailto:stephen.tur...@citrix.com>> wrote:
> 
> Speaking for my XenCenter team again, for things like that we would have an 
> improvement ticket, pointing to the wiki page.
> 
> By the way, this also allows us to schedule the work on our sprint, but we 
> had the policy even before we were doing Scrum. In a large, distributed, 
> volunteer organisation, I would argue that it's even more important to be 
> able to trace the change back to its reason, now and later.
> 
> --
> Stephen Turner
> 
> 
> -Original Message-
> From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com]
> Sent: 18 May 2015 10:11
> To: dev@cloudstack.apache.org
> Subject: Re: Preparing for 4.6
> 
> Hi there,
> 
> I agree with the Jira ticket for the "new features, important fixes, security 
> fixes"
> 
> But I don’t think only about "new features, important fixes, security fixes”. 
> I put most of my time in make the code better and tested, for what we call 
> refactoring/rewriting/redesigning. Should we also create Jira issues for that 
> and mark them as Improvement?
> 
> Taking into account the [VPC] Virtual Router, Citrix Resource Base and 
> Libvirt Computing Resource refactoring, we had only internal issues on Jira. 
> However, the changes have been documented on the 4.5/4.6 sections of the 
> Apache / Developers / Design Documents wiki:
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactor+for+Redundant+Virtual+Router+Implementation
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactoring+XenServer+Hypervisor+Plugin
> 
> The Libvirt documentation is on its way, since the PR was pushed only last 
> week.
> 
> Cheers,
> Wilder
> 
> 
> On 18 May 2015, at 10:39, Stephen Turner 
> mailto:stephen.tur...@citrix.com>>
>  wrote:
> 
> In my XenCenter dev team at Citrix, we have the policy of requiring a ticket 
> number on every commit. If we find a bug and there isn't already a ticket, we 
> create a ticket before committing the fix. I guess I've just dug through 
> history too many times to understand why something that appears wrong was 
> done, only to find an inadequate description at the end of the trail.
> 
> --
> Stephen Turner
> 
> 
> -Original Message-
> From: Erik Weber [mailto:terbol...@gmail.com]
> Sent: 18 May 2015 09:32
> To: dev
> Subject: Re: Preparing for 4.6
> 
> On Mon, May 18, 2015 at 10:26 AM, Rene Moser 
> mailto:m...@renemoser.net>> 
> wrote:
> 
> Hi
> 
> On 15.05.2015 11:27, Sebastien Goasguen wrote:
> Folks,
> 
> As we prepare to try a new process for 4.6 release it would be nice to start 
> paying attention to master.
> 
> - Good commit messages
> 
> The question is, what makes a commit message good? Maybe this helps:
> 
> http://secure-web.cisco.com/1cOtAU9lruLvoJl9SBdNSTHN6eyvml6nO5JlwT8_V2
> d_Y7wsnHAV3NiHTOya0cRQyt1WuG_fzithwjk4Qu-l3usM-B_yzy7V4qaxtoDIlEixysid
> QZ0ZbuK0YMNgknwBUaRUBJYNkjfGoppsXIpUXcmRvOH565otFMCmJUX2mfkrj_z5Vwm0wh
> PDqu2ZkGk1a/http%3A%2F%2Fchris.beams.io%2Fposts%2Fgit-commit%2F
> 
> - Reference to a JIRA bug
> 
> Must there be a JIRA bug? I did some commits without jira bugs in the past. 
> But I noticed that those are not "tracked" in the changelog of the new 
> release. So should there be a policy (is there?) that there must be a jira 
> bug for fixes?
> 
> 
> I believe there should be a JIRA bug for most things. JIRA is a good place to 
> document why you're doing something, it's also easy to use as a source for 
> release notes as you discovered.
> It's also good practice to document bugs/fixes, it's generally easier to find 
> JIRA bugs than it is to find commit messages - especially for non-developers 
> / newbies.
> 
> For major code commits (new features, important fixes, security fixes) I'd 
> say it should be a requirement, but I don't know if it already is or not.
> 
> 
> 
> - Squashing commits ( cc/ wilder :))
> 
> This really depends. I would not generally prefer squashing commits.
> 
> The example of
> https://github.com/apache/cloudstack/commits/master?page=2 is more an example 
> of "bad" commit messages.
> 
> If you look at the commits, they make sense but the commit message indicates 
> that they cover similar work in different aspects, which they actually don't.
> 
> But if you look at this exampl

Re: Preparing for 4.6

[Erik Weber]

On a related note, commits should reference the  JIRA ticket as well.

-- 
Erik

On Mon, May 18, 2015 at 11:27 AM, Wilder Rodrigues <
wrodrig...@schubergphilis.com> wrote:

> Okay,
>
> +1 for create the ACS Jira issue for improvements as well.
>
> Since Xen and Libvirt redesign will be on 4.6 - and are already documented
> - I will just create 2 issues so we have a way of keeping track of them.
>
> Cheers,
> Wilder
>
>
> On 18 May 2015, at 11:16, Stephen Turner  > wrote:
>
> Speaking for my XenCenter team again, for things like that we would have
> an improvement ticket, pointing to the wiki page.
>
> By the way, this also allows us to schedule the work on our sprint, but we
> had the policy even before we were doing Scrum. In a large, distributed,
> volunteer organisation, I would argue that it's even more important to be
> able to trace the change back to its reason, now and later.
>
> --
> Stephen Turner
>
>
> -Original Message-
> From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com]
> Sent: 18 May 2015 10:11
> To: dev@cloudstack.apache.org
> Subject: Re: Preparing for 4.6
>
> Hi there,
>
> I agree with the Jira ticket for the "new features, important fixes,
> security fixes"
>
> But I don’t think only about "new features, important fixes, security
> fixes”. I put most of my time in make the code better and tested, for what
> we call refactoring/rewriting/redesigning. Should we also create Jira
> issues for that and mark them as Improvement?
>
> Taking into account the [VPC] Virtual Router, Citrix Resource Base and
> Libvirt Computing Resource refactoring, we had only internal issues on
> Jira. However, the changes have been documented on the 4.5/4.6 sections of
> the Apache / Developers / Design Documents wiki:
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactor+for+Redundant+Virtual+Router+Implementation
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactoring+XenServer+Hypervisor+Plugin
>
> The Libvirt documentation is on its way, since the PR was pushed only last
> week.
>
> Cheers,
> Wilder
>
>
> On 18 May 2015, at 10:39, Stephen Turner  >
> wrote:
>
> In my XenCenter dev team at Citrix, we have the policy of requiring a
> ticket number on every commit. If we find a bug and there isn't already a
> ticket, we create a ticket before committing the fix. I guess I've just dug
> through history too many times to understand why something that appears
> wrong was done, only to find an inadequate description at the end of the
> trail.
>
> --
> Stephen Turner
>
>
> -Original Message-
> From: Erik Weber [mailto:terbol...@gmail.com]
> Sent: 18 May 2015 09:32
> To: dev
> Subject: Re: Preparing for 4.6
>
> On Mon, May 18, 2015 at 10:26 AM, Rene Moser  m...@renemoser.net>> wrote:
>
> Hi
>
> On 15.05.2015 11:27, Sebastien Goasguen wrote:
> Folks,
>
> As we prepare to try a new process for 4.6 release it would be nice to
> start paying attention to master.
>
> - Good commit messages
>
> The question is, what makes a commit message good? Maybe this helps:
>
> http://secure-web.cisco.com/1cOtAU9lruLvoJl9SBdNSTHN6eyvml6nO5JlwT8_V2
> d_Y7wsnHAV3NiHTOya0cRQyt1WuG_fzithwjk4Qu-l3usM-B_yzy7V4qaxtoDIlEixysid
> QZ0ZbuK0YMNgknwBUaRUBJYNkjfGoppsXIpUXcmRvOH565otFMCmJUX2mfkrj_z5Vwm0wh
> PDqu2ZkGk1a/http%3A%2F%2Fchris.beams.io%2Fposts%2Fgit-commit%2F
>
> - Reference to a JIRA bug
>
> Must there be a JIRA bug? I did some commits without jira bugs in the
> past. But I noticed that those are not "tracked" in the changelog of the
> new release. So should there be a policy (is there?) that there must be a
> jira bug for fixes?
>
>
> I believe there should be a JIRA bug for most things. JIRA is a good place
> to document why you're doing something, it's also easy to use as a source
> for release notes as you discovered.
> It's also good practice to document bugs/fixes, it's generally easier to
> find JIRA bugs than it is to find commit messages - especially for
> non-developers / newbies.
>
> For major code commits (new features, important fixes, security fixes) I'd
> say it should be a requirement, but I don't know if it already is or not.
>
>
>
> - Squashing commits ( cc/ wilder :))
>
> This really depends. I would not generally prefer squashing commits.
>
> The example of
> https://github.com/apache/cloudstack/commits/master?page=2 is more an
> example of "bad" commit messages.
>
> If you look at the commits, they make sense but the commit message
> indicates that they cover similar work in different aspects, which they
> actually don't.
>
> But if you look at this example here
>
> https://github.com/ansible/ansible-modules-extras/commits/devel?author
> =gregdek where you can see dozens of similar commits, those should be
> squashed.
>
>
>
> +1 to squashing related commits where it makes sense to do so
> -1 to a gene

Re: Preparing for 4.6

[Daan Hoogland]

I don't like the writing of a changelog in the root, it is in git already.
The comments should be good and describing the changes. The changes should
be small enough to be described adequately in a short changelog. That's why
I don't like squashing anything but the very trivial.

Op ma 18 mei 2015 om 11:50 schreef Erik Weber :

> On a related note, commits should reference the  JIRA ticket as well.
>
> --
> Erik
>
> On Mon, May 18, 2015 at 11:27 AM, Wilder Rodrigues <
> wrodrig...@schubergphilis.com> wrote:
>
> > Okay,
> >
> > +1 for create the ACS Jira issue for improvements as well.
> >
> > Since Xen and Libvirt redesign will be on 4.6 - and are already
> documented
> > - I will just create 2 issues so we have a way of keeping track of them.
> >
> > Cheers,
> > Wilder
> >
> >
> > On 18 May 2015, at 11:16, Stephen Turner  > > wrote:
> >
> > Speaking for my XenCenter team again, for things like that we would have
> > an improvement ticket, pointing to the wiki page.
> >
> > By the way, this also allows us to schedule the work on our sprint, but
> we
> > had the policy even before we were doing Scrum. In a large, distributed,
> > volunteer organisation, I would argue that it's even more important to be
> > able to trace the change back to its reason, now and later.
> >
> > --
> > Stephen Turner
> >
> >
> > -Original Message-
> > From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com]
> > Sent: 18 May 2015 10:11
> > To: dev@cloudstack.apache.org
> > Subject: Re: Preparing for 4.6
> >
> > Hi there,
> >
> > I agree with the Jira ticket for the "new features, important fixes,
> > security fixes"
> >
> > But I don’t think only about "new features, important fixes, security
> > fixes”. I put most of my time in make the code better and tested, for
> what
> > we call refactoring/rewriting/redesigning. Should we also create Jira
> > issues for that and mark them as Improvement?
> >
> > Taking into account the [VPC] Virtual Router, Citrix Resource Base and
> > Libvirt Computing Resource refactoring, we had only internal issues on
> > Jira. However, the changes have been documented on the 4.5/4.6 sections
> of
> > the Apache / Developers / Design Documents wiki:
> >
> >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactor+for+Redundant+Virtual+Router+Implementation
> >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactoring+XenServer+Hypervisor+Plugin
> >
> > The Libvirt documentation is on its way, since the PR was pushed only
> last
> > week.
> >
> > Cheers,
> > Wilder
> >
> >
> > On 18 May 2015, at 10:39, Stephen Turner  > >
> > wrote:
> >
> > In my XenCenter dev team at Citrix, we have the policy of requiring a
> > ticket number on every commit. If we find a bug and there isn't already a
> > ticket, we create a ticket before committing the fix. I guess I've just
> dug
> > through history too many times to understand why something that appears
> > wrong was done, only to find an inadequate description at the end of the
> > trail.
> >
> > --
> > Stephen Turner
> >
> >
> > -Original Message-
> > From: Erik Weber [mailto:terbol...@gmail.com]
> > Sent: 18 May 2015 09:32
> > To: dev
> > Subject: Re: Preparing for 4.6
> >
> > On Mon, May 18, 2015 at 10:26 AM, Rene Moser  > m...@renemoser.net>> wrote:
> >
> > Hi
> >
> > On 15.05.2015 11:27, Sebastien Goasguen wrote:
> > Folks,
> >
> > As we prepare to try a new process for 4.6 release it would be nice to
> > start paying attention to master.
> >
> > - Good commit messages
> >
> > The question is, what makes a commit message good? Maybe this helps:
> >
> > http://secure-web.cisco.com/1cOtAU9lruLvoJl9SBdNSTHN6eyvml6nO5JlwT8_V2
> > d_Y7wsnHAV3NiHTOya0cRQyt1WuG_fzithwjk4Qu-l3usM-B_yzy7V4qaxtoDIlEixysid
> > QZ0ZbuK0YMNgknwBUaRUBJYNkjfGoppsXIpUXcmRvOH565otFMCmJUX2mfkrj_z5Vwm0wh
> > PDqu2ZkGk1a/http%3A%2F%2Fchris.beams.io%2Fposts%2Fgit-commit%2F
> >
> > - Reference to a JIRA bug
> >
> > Must there be a JIRA bug? I did some commits without jira bugs in the
> > past. But I noticed that those are not "tracked" in the changelog of the
> > new release. So should there be a policy (is there?) that there must be a
> > jira bug for fixes?
> >
> >
> > I believe there should be a JIRA bug for most things. JIRA is a good
> place
> > to document why you're doing something, it's also easy to use as a source
> > for release notes as you discovered.
> > It's also good practice to document bugs/fixes, it's generally easier to
> > find JIRA bugs than it is to find commit messages - especially for
> > non-developers / newbies.
> >
> > For major code commits (new features, important fixes, security fixes)
> I'd
> > say it should be a requirement, but I don't know if it already is or not.
> >
> >
> >
> > - Squashing commits ( cc/ wilder :))
> >
> > This really depends. I would not ge

Re: Preparing for 4.6

[Sebastien Goasguen]

> On May 18, 2015, at 1:14 PM, Daan Hoogland  wrote:
> 
> I don't like the writing of a changelog in the root, it is in git already.

Even in a release tarball ?

> The comments should be good and describing the changes. The changes should
> be small enough to be described adequately in a short changelog. That's why
> I don't like squashing anything but the very trivial.
> 
> Op ma 18 mei 2015 om 11:50 schreef Erik Weber :
> 
>> On a related note, commits should reference the  JIRA ticket as well.
>> 
>> --
>> Erik
>> 
>> On Mon, May 18, 2015 at 11:27 AM, Wilder Rodrigues <
>> wrodrig...@schubergphilis.com> wrote:
>> 
>>> Okay,
>>> 
>>> +1 for create the ACS Jira issue for improvements as well.
>>> 
>>> Since Xen and Libvirt redesign will be on 4.6 - and are already
>> documented
>>> - I will just create 2 issues so we have a way of keeping track of them.
>>> 
>>> Cheers,
>>> Wilder
>>> 
>>> 
>>> On 18 May 2015, at 11:16, Stephen Turner >> > wrote:
>>> 
>>> Speaking for my XenCenter team again, for things like that we would have
>>> an improvement ticket, pointing to the wiki page.
>>> 
>>> By the way, this also allows us to schedule the work on our sprint, but
>> we
>>> had the policy even before we were doing Scrum. In a large, distributed,
>>> volunteer organisation, I would argue that it's even more important to be
>>> able to trace the change back to its reason, now and later.
>>> 
>>> --
>>> Stephen Turner
>>> 
>>> 
>>> -Original Message-
>>> From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com]
>>> Sent: 18 May 2015 10:11
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: Preparing for 4.6
>>> 
>>> Hi there,
>>> 
>>> I agree with the Jira ticket for the "new features, important fixes,
>>> security fixes"
>>> 
>>> But I don’t think only about "new features, important fixes, security
>>> fixes”. I put most of my time in make the code better and tested, for
>> what
>>> we call refactoring/rewriting/redesigning. Should we also create Jira
>>> issues for that and mark them as Improvement?
>>> 
>>> Taking into account the [VPC] Virtual Router, Citrix Resource Base and
>>> Libvirt Computing Resource refactoring, we had only internal issues on
>>> Jira. However, the changes have been documented on the 4.5/4.6 sections
>> of
>>> the Apache / Developers / Design Documents wiki:
>>> 
>>> 
>>> 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactor+for+Redundant+Virtual+Router+Implementation
>>> 
>>> 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactoring+XenServer+Hypervisor+Plugin
>>> 
>>> The Libvirt documentation is on its way, since the PR was pushed only
>> last
>>> week.
>>> 
>>> Cheers,
>>> Wilder
>>> 
>>> 
>>> On 18 May 2015, at 10:39, Stephen Turner >> >
>>> wrote:
>>> 
>>> In my XenCenter dev team at Citrix, we have the policy of requiring a
>>> ticket number on every commit. If we find a bug and there isn't already a
>>> ticket, we create a ticket before committing the fix. I guess I've just
>> dug
>>> through history too many times to understand why something that appears
>>> wrong was done, only to find an inadequate description at the end of the
>>> trail.
>>> 
>>> --
>>> Stephen Turner
>>> 
>>> 
>>> -Original Message-
>>> From: Erik Weber [mailto:terbol...@gmail.com]
>>> Sent: 18 May 2015 09:32
>>> To: dev
>>> Subject: Re: Preparing for 4.6
>>> 
>>> On Mon, May 18, 2015 at 10:26 AM, Rene Moser >> m...@renemoser.net>> wrote:
>>> 
>>> Hi
>>> 
>>> On 15.05.2015 11:27, Sebastien Goasguen wrote:
>>> Folks,
>>> 
>>> As we prepare to try a new process for 4.6 release it would be nice to
>>> start paying attention to master.
>>> 
>>> - Good commit messages
>>> 
>>> The question is, what makes a commit message good? Maybe this helps:
>>> 
>>> http://secure-web.cisco.com/1cOtAU9lruLvoJl9SBdNSTHN6eyvml6nO5JlwT8_V2
>>> d_Y7wsnHAV3NiHTOya0cRQyt1WuG_fzithwjk4Qu-l3usM-B_yzy7V4qaxtoDIlEixysid
>>> QZ0ZbuK0YMNgknwBUaRUBJYNkjfGoppsXIpUXcmRvOH565otFMCmJUX2mfkrj_z5Vwm0wh
>>> PDqu2ZkGk1a/http%3A%2F%2Fchris.beams.io%2Fposts%2Fgit-commit%2F
>>> 
>>> - Reference to a JIRA bug
>>> 
>>> Must there be a JIRA bug? I did some commits without jira bugs in the
>>> past. But I noticed that those are not "tracked" in the changelog of the
>>> new release. So should there be a policy (is there?) that there must be a
>>> jira bug for fixes?
>>> 
>>> 
>>> I believe there should be a JIRA bug for most things. JIRA is a good
>> place
>>> to document why you're doing something, it's also easy to use as a source
>>> for release notes as you discovered.
>>> It's also good practice to document bugs/fixes, it's generally easier to
>>> find JIRA bugs than it is to find commit messages - especially for
>>> non-developers / newbies.
>>> 
>>> For major code commits (new features, important fixes, security fixes)
>> I'd
>>> say it sh

Re: Preparing for 4.6

[Daan Hoogland]

the release tarball is a repo snapshot. do you want a generated changelog?

Op ma 18 mei 2015 om 13:30 schreef Sebastien Goasguen :

>
> > On May 18, 2015, at 1:14 PM, Daan Hoogland 
> wrote:
> >
> > I don't like the writing of a changelog in the root, it is in git
> already.
>
> Even in a release tarball ?
>
> > The comments should be good and describing the changes. The changes
> should
> > be small enough to be described adequately in a short changelog. That's
> why
> > I don't like squashing anything but the very trivial.
> >
> > Op ma 18 mei 2015 om 11:50 schreef Erik Weber :
> >
> >> On a related note, commits should reference the  JIRA ticket as well.
> >>
> >> --
> >> Erik
> >>
> >> On Mon, May 18, 2015 at 11:27 AM, Wilder Rodrigues <
> >> wrodrig...@schubergphilis.com> wrote:
> >>
> >>> Okay,
> >>>
> >>> +1 for create the ACS Jira issue for improvements as well.
> >>>
> >>> Since Xen and Libvirt redesign will be on 4.6 - and are already
> >> documented
> >>> - I will just create 2 issues so we have a way of keeping track of
> them.
> >>>
> >>> Cheers,
> >>> Wilder
> >>>
> >>>
> >>> On 18 May 2015, at 11:16, Stephen Turner  >>> > wrote:
> >>>
> >>> Speaking for my XenCenter team again, for things like that we would
> have
> >>> an improvement ticket, pointing to the wiki page.
> >>>
> >>> By the way, this also allows us to schedule the work on our sprint, but
> >> we
> >>> had the policy even before we were doing Scrum. In a large,
> distributed,
> >>> volunteer organisation, I would argue that it's even more important to
> be
> >>> able to trace the change back to its reason, now and later.
> >>>
> >>> --
> >>> Stephen Turner
> >>>
> >>>
> >>> -Original Message-
> >>> From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com]
> >>> Sent: 18 May 2015 10:11
> >>> To: dev@cloudstack.apache.org
> >>> Subject: Re: Preparing for 4.6
> >>>
> >>> Hi there,
> >>>
> >>> I agree with the Jira ticket for the "new features, important fixes,
> >>> security fixes"
> >>>
> >>> But I don’t think only about "new features, important fixes, security
> >>> fixes”. I put most of my time in make the code better and tested, for
> >> what
> >>> we call refactoring/rewriting/redesigning. Should we also create Jira
> >>> issues for that and mark them as Improvement?
> >>>
> >>> Taking into account the [VPC] Virtual Router, Citrix Resource Base and
> >>> Libvirt Computing Resource refactoring, we had only internal issues on
> >>> Jira. However, the changes have been documented on the 4.5/4.6 sections
> >> of
> >>> the Apache / Developers / Design Documents wiki:
> >>>
> >>>
> >>>
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactor+for+Redundant+Virtual+Router+Implementation
> >>>
> >>>
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactoring+XenServer+Hypervisor+Plugin
> >>>
> >>> The Libvirt documentation is on its way, since the PR was pushed only
> >> last
> >>> week.
> >>>
> >>> Cheers,
> >>> Wilder
> >>>
> >>>
> >>> On 18 May 2015, at 10:39, Stephen Turner  >>> >
> >>> wrote:
> >>>
> >>> In my XenCenter dev team at Citrix, we have the policy of requiring a
> >>> ticket number on every commit. If we find a bug and there isn't
> already a
> >>> ticket, we create a ticket before committing the fix. I guess I've just
> >> dug
> >>> through history too many times to understand why something that appears
> >>> wrong was done, only to find an inadequate description at the end of
> the
> >>> trail.
> >>>
> >>> --
> >>> Stephen Turner
> >>>
> >>>
> >>> -Original Message-
> >>> From: Erik Weber [mailto:terbol...@gmail.com]
> >>> Sent: 18 May 2015 09:32
> >>> To: dev
> >>> Subject: Re: Preparing for 4.6
> >>>
> >>> On Mon, May 18, 2015 at 10:26 AM, Rene Moser   >>> m...@renemoser.net>> wrote:
> >>>
> >>> Hi
> >>>
> >>> On 15.05.2015 11:27, Sebastien Goasguen wrote:
> >>> Folks,
> >>>
> >>> As we prepare to try a new process for 4.6 release it would be nice to
> >>> start paying attention to master.
> >>>
> >>> - Good commit messages
> >>>
> >>> The question is, what makes a commit message good? Maybe this helps:
> >>>
> >>> http://secure-web.cisco.com/1cOtAU9lruLvoJl9SBdNSTHN6eyvml6nO5JlwT8_V2
> >>> d_Y7wsnHAV3NiHTOya0cRQyt1WuG_fzithwjk4Qu-l3usM-B_yzy7V4qaxtoDIlEixysid
> >>> QZ0ZbuK0YMNgknwBUaRUBJYNkjfGoppsXIpUXcmRvOH565otFMCmJUX2mfkrj_z5Vwm0wh
> >>> PDqu2ZkGk1a/http%3A%2F%2Fchris.beams.io%2Fposts%2Fgit-commit%2F
> >>>
> >>> - Reference to a JIRA bug
> >>>
> >>> Must there be a JIRA bug? I did some commits without jira bugs in the
> >>> past. But I noticed that those are not "tracked" in the changelog of
> the
> >>> new release. So should there be a policy (is there?) that there must
> be a
> >>> jira bug for fixes?
> >>>
> >>>
> >>> I believe there should be a JIRA bug for most things. JIRA is a good
> >> place
> >>

[JENKINS] Java 8 job doesn't use Java 8 at all

[Wilder Rodrigues]

Hi guys,

After [a guy] reported that the Java 8 build was broken due to a failure in an 
Unit Test, I traced the route cause and tried to build ACS using the OpenJDK 
1.8 in my test environment. Unfortunately, it did not work due to an error when 
loading the Mockito classes :

Error: java.io.IOException: invalid constant type: 18

After that, I had a look at the Jenkins  build logs and found out the following:


[build-master-jdk18] $ 
/home/jenkins/acs/tools/hudson.tasks.Maven_MavenInstallation/maven-3.1.1/bin/mvn
 --version
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 
15:22:22+)
Maven home: 
/home/jenkins/acs/tools/hudson.tasks.Maven_MavenInstallation/maven-3.1.1
Java version: 1.7.0_75, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.10.0-123.20.1.el7.x86_64", arch: "amd64", family: 
"unix"

Based on the output, we are not even using Java 8 for the build called JDK18.

Before making any assumption and sending this email, I had a look at the slave 
node with Daan and we found out that OpenJDK 1.8 is not even installed:

javac - status is auto.
 link currently points to 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/javac
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/javac - 
priority 170075
 slave appletviewer: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/appletviewer
 slave apt: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/apt
 slave extcheck: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/extcheck
 slave idlj: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/idlj
 slave jar: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/jar
 slave jarsigner: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/jarsigner
 slave javadoc: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/javadoc
 slave javah: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/javah
 slave javap: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/javap
 slave jcmd: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/jcmd
 slave jconsole: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/jconsole
 slave jdb: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/jdb
 slave jhat: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/jhat
 slave jinfo: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/jinfo
 slave jmap: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/jmap
 slave jps: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/jps
 slave jrunscript: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/jrunscript
 slave jsadebugd: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/jsadebugd
 slave jstack: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/jstack
 slave jstat: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/jstat
 slave jstatd: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/jstatd
 slave native2ascii: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/native2ascii
 slave policytool: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/policytool
 slave rmic: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/rmic
 slave schemagen: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/schemagen
 slave serialver: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/serialver
 slave wsgen: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/wsgen
 slave wsimport: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/wsimport
 slave xjc: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64/bin/xjc
 slave java_sdk_exports: 
/usr/lib/jvm-exports/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64
 slave java_sdk: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64
 slave appletviewer.1.gz: 
/usr/share/man/man1/appletviewer-java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64.1.gz
 slave apt.1.gz: 
/usr/share/man/man1/apt-java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64.1.gz
 slave extcheck.1.gz: 
/usr/share/man/man1/extcheck-java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64.1.gz
 slave jar.1.gz: 
/usr/share/man/man1/jar-java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64.1.gz
 slave jarsigner.1.gz: 
/usr/share/man/man1/jarsigner-java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64.1.gz
 slave javac.1.gz: 
/usr/share/man/man1/javac-java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64.1.gz
 slave javadoc.1.gz: 
/usr/share/man/man1/javadoc-java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64.1.gz
 slave javah.1.gz: 
/usr/share/man/man1/javah-java-1.7.0-openjdk-1.7.0.75-2.5.4.2

[GitHub] cloudstack pull request: Systemvm: Disable services that slow down...

[remibergsma]

GitHub user remibergsma opened a pull request:

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

Systemvm: Disable services that slow down boot

The console-setup service brings a nice font to the console, but why would 
we want to use it. In most cases it takes a <10 seconds to set it up. When 
using nested hypervising, I found this takes much longer time that causes tests 
to time-out. I'd suggest turning off these unused services. They are not 
required for the services the systemvm provides.


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

$ git pull https://github.com/remibergsma/cloudstack systemvm_services

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

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


commit 95e7673a55455736ae736b029197487ba1acfe62
Author: Remi Bergsma 
Date:   2015-05-18T11:38:46Z

Systemvm: Disable services that slow down boot

The console-setup service brings a nice font to the console, but why would 
we want to use it. In most cases it takes a <10 seconds to set it up. When 
using nested hypervising, I found this takes much longer time that causes tests 
to time-out. I'd suggest turning off these services. They are not required for 
the services the systemvm provides.




---
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: Systemvm: Disable services that slow down...

[DaanHoogland]

Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/254#issuecomment-103043166
  
seems like it could be applied to 4.4 and 4.5 as well. the pull-builder 
fails however. I think it is unrelated but it is in kvm.


---
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: Fixing the testGetHostStatsCommand test u...

[wilderrodrigues]

GitHub user wilderrodrigues opened a pull request:

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

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

Fixing typo on LibvirtRequestWrapper
  - Replace linbvirtCommands by libvirtCommands on LibvirtRequestWrapper

@DaanHoogland @bhaisaab @karuturi @kishankavala 

This PR contains a fix for the Unit Test. I'm mocking the path so it will 
not fail if the machine where the test is running contains garbage on a given 
directory

@kishankavala, it has been again tested and a KVM datacenter can be easily 
deployed. Please, before testing it, make sure you do a full build of the 
source.

Cheers,
Wilder

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

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

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

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


commit 4f62e582eee7f7ab0b7b576a98bc1a42adf95d76
Author: wilderrodrigues 
Date:   2015-05-18T12:30:36Z

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

Fixing typo on LibvirtRequestWrapper
  - Replace linbvirtCommands by libvirtCommands on LibvirtRequestWrapper




---
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: Systemvm: Disable services that slow down...

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/254#issuecomment-103050221
  
The PR is failing due to a timeout error on Travis. This timeout problem is 
occurring not so often, and when it does it's not really related the content of 
the PR.

I think 30 minutes is not enough. When the build passes, it usually takes 
something about 29 minutes.

Actually, the job is just stopped, see bellow:

Still running (30 of 30): ./tools/travis/before_script.sh
Timeout (30 minutes) reached. Terminating "./tools/travis/before_script.sh"
The command "travis_wait 30 ./tools/travis/before_script.sh" failed and 
exited with 1 during .
Your build has been stopped.

So, it looks good to me.

@bhaisaab, how could we increase the Travis timeout?

Cheers,
Wilder


---
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: Fixing the testGetHostStatsCommand test u...

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/255#issuecomment-103062657
  
@DaanHoogland  @bhaisaab,

Build and Travis are happy. Could you please review/close it?

Cheers,
Wilder


---
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: Systemvm: Disable services that slow down...

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/254#issuecomment-103074746
  
The KVM unit tests error was fixed on PR 255

Unexpected exception, expected but 
was

This PR looks good and I tested it against my KVM environment with 
tests_account.py and test_vm_lifecycle.py


---
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: Systemvm: Disable services that slow down...

[asfgit]

Github user asfgit closed the pull request at:

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


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

Build failed in Jenkins: build-master-jdk18 #43

[jenkins]

See 

Changes:

[github] Systemvm: Disable services that slow down boot

--
[...truncated 2665 lines...]
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-plugin-hypervisor-xenserver ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-plugin-hypervisor-xenserver ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 4 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ 
cloud-plugin-hypervisor-xenserver ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 95 source files to 

[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-plugin-hypervisor-xenserver ---
[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:3.2:testCompile (default-testCompile) @ 
cloud-plugin-hypervisor-xenserver ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 7 source files to 

[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ 
cloud-plugin-hypervisor-xenserver ---
[INFO] Surefire report directory: 


---
 T E S T S
---
Running 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer56FP1WrapperTest
log4j:WARN No appenders could be found for logger 
(com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool).
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: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.443 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer56FP1WrapperTest
Running com.cloud.hypervisor.xenserver.resource.wrapper.XenServer610WrapperTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.892 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer610WrapperTest
Running com.cloud.hypervisor.xenserver.resource.wrapper.XcpServerWrapperTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.17 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XcpServerWrapperTest
Running com.cloud.hypervisor.xenserver.resource.wrapper.XenServer56WrapperTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.267 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer56WrapperTest
Running 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer620SP1WrapperTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.187 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer620SP1WrapperTest
Running com.cloud.hypervisor.xenserver.resource.wrapper.XenServer620WrapperTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.049 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer620WrapperTest
Running com.cloud.hypervisor.xenserver.resource.wrapper.CitrixRequestWrapperTest
Tests run: 77, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.951 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.CitrixRequestWrapperTest

Results :

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

[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Plugin - Hypervisor KVM 4.6.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
cloud-plugin-hypervisor-kvm ---
[INFO] Deleting 

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

 (includes = [target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-plugin-hypervisor-kvm ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-plugin-hypervisor-kvm ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-plugin-hypervisor-kvm ---
[debug] execute co

RE: delete local storage pool on cloudstack 4.4.3

[Somesh Naidu]

Star Guo,

While I wasn't been able to have a look at the error/image you shared, I 
believe the issue is due to the orphaned entries in the table 
*storage_pool_host_ref*. Remove that and you should be good. Also make sure to 
remove the entry in *op_host_capacity* for this storage pool.

Somesh
CloudPlatform Escalations
Citrix Systems, Inc.


-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] 
Sent: Thursday, May 14, 2015 9:26 PM
To: dev@cloudstack.apache.org
Subject: Re: delete local storage pool on cloudstack 4.4.3

Can you take a peek into the management server log file and see if any
exceptions are reported?

Thanks

On Thu, May 14, 2015 at 7:06 PM, Star Guo  wrote:

> Hi, here is: http://pan.baidu.com/s/1kTxgbor
>
> Thanks!
>
> Best Regards,
> Star Guo
>
> ==
>
> Hi,
>
> Images are stripped from messages to the CS mailing list.
>
> Could you put the images on Imgur and send out the URLs?
>
> Thanks!
> Mike
>
> On Thu, May 14, 2015 at 6:42 PM, Star Guo  wrote:
>
> > Yes. I add a timestamp to the removed column, the local storage.
> >
> > I run " list storagepools " by cloudmonkey and the local storage is no
> > list. However,the Infrastructure on the web UI is no data (just as
> > attachment images).
> >
> > I rollback the update in mysql db (set NULL to the column), and then
> > Infrastructure on the web UI is recover to me.
> >
> > So, it shows if I want to delete the local storage I just do an update
> > is not enough. Thanks for help.
> >
> > Best Regards,
> > Star Guo
> >
> > 
> >
> > I'm not sure I follow.
> >
> > Are you saying if you add a timestamp to the Removed column, the
> > Primary Storage no longer appears in the Infrastructure tab? If so, I
> > was thinking that's the behavior you desired.
> >
> > If that's not what you were hoping for, perhaps you can explain in
> > more detail.
> >
> > Thanks!
> >
> > On Thu, May 14, 2015 at 12:04 AM, Star Guo  wrote:
> >
> > > Dear Mike,
> > >
> > > I update the storage pool remove time with timestamp，but it can not
> > > load the whole information in "Inforastructure" . I rollback the
> > > update and it is ok.
> > >
> > > Best Regards,
> > > Star Guo
> > >
> > > -邮件原件-
> > > 发件人: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > > 发送时间: 2015年5月13日 5:43
> > > 收件人: dev@cloudstack.apache.org
> > > 主题: Re: delete local storage pool on cloudstack 4.4.3
> > >
> > > Sounds like a bug perhaps, but you could always manually update the
> > > cloud.storage_pool table to mark it as removed.
> > >
> > > If you have successfully removed primary storage in the past, you
> > > could probably use that as an example row for how to update the
> > > applicable row remotely.
> > >
> > > On Tuesday, May 12, 2015, Star Guo  wrote:
> > >
> > > > Hi, everyone,
> > > >
> > > >I run cloudstack 4.4.3 with kvm and I just enable localstorage
> > > > in
> > > > zone1 by cloudmonkey after zone1 is in running state. Local
> > > > Storage of KVM host is found.
> > > >And now I disable local storage in zone1 by cloudmonkey, but
> > > > the local storage even in it. How can I remove local storage ?
> > > > (Restart MS
> > > just ok?
> > > > Or
> > > > Agent Service?)
> > > >Thanks a lot!
> > > >
> > > > Best Regards,
> > > > Star Guo
> > > >
> > > >
> > >
> > > --
> > > *Mike Tutkowski*
> > > *Senior CloudStack Developer, SolidFire Inc.*
> > > e: mike.tutkow...@solidfire.com
> > > o: 303.746.7302
> > > Advancing the way the world uses the cloud
> > > *™*
> > >
> > >
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > *™*
> >
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*
>
>


-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
*™*

[GitHub] cloudstack pull request: Systemvm: Disable services that slow down...

[remibergsma]

Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/254#issuecomment-103111320
  
@DaanHoogland Yes, merging to 4.5 and 4.4 would be nice.


---
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: Systemvm: Disable services that slow down...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/254#issuecomment-10315
  
@remibergsma good stuff, we should have it on 4.4/4.5.

@wilderrodrigues I don't know, perhaps open a ticket on ASF Infra's JIRA? 
Since ASF are a paid customer, they should increase the default timeouts. 
Recommend increasing the timeout to 90 mins instead of 50 mins.


---
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: Fixing the testGetHostStatsCommand test u...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/255#issuecomment-103151365
  
LGTM.


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

[GitHub] cloudstack pull request: Fixing the testGetHostStatsCommand test u...

[asfgit]

Github user asfgit closed the pull request at:

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


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

Build failed in Jenkins: build-master-jdk18 #44

[jenkins]

See 

Changes:

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

--
[...truncated 2665 lines...]
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-plugin-hypervisor-xenserver ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-plugin-hypervisor-xenserver ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 4 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ 
cloud-plugin-hypervisor-xenserver ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 95 source files to 

[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-plugin-hypervisor-xenserver ---
[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:3.2:testCompile (default-testCompile) @ 
cloud-plugin-hypervisor-xenserver ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 7 source files to 

[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ 
cloud-plugin-hypervisor-xenserver ---
[INFO] Surefire report directory: 


---
 T E S T S
---
Running 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer56FP1WrapperTest
log4j:WARN No appenders could be found for logger 
(com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool).
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: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.122 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer56FP1WrapperTest
Running com.cloud.hypervisor.xenserver.resource.wrapper.XenServer610WrapperTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.86 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer610WrapperTest
Running com.cloud.hypervisor.xenserver.resource.wrapper.XcpServerWrapperTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.166 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XcpServerWrapperTest
Running com.cloud.hypervisor.xenserver.resource.wrapper.XenServer56WrapperTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.232 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer56WrapperTest
Running 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer620SP1WrapperTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.157 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer620SP1WrapperTest
Running com.cloud.hypervisor.xenserver.resource.wrapper.XenServer620WrapperTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.XenServer620WrapperTest
Running com.cloud.hypervisor.xenserver.resource.wrapper.CitrixRequestWrapperTest
Tests run: 77, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.873 sec - in 
com.cloud.hypervisor.xenserver.resource.wrapper.CitrixRequestWrapperTest

Results :

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

[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Plugin - Hypervisor KVM 4.6.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
cloud-plugin-hypervisor-kvm ---
[INFO] Deleting 

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

 (includes = [target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-plugin-hypervisor-kvm ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-plugin-hypervisor-kvm ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-plugin-hypervisor-kvm ---
[deb

Re: VPC Firewall Rule Limitations

[Christopher Falk]

Thanks Marcus, 

I get the tier model in principle, and for pure web apps with a web->app->db 
tier model it makes good sense. However we have many hosting clients using VPC 
with a single tier so that they can use the IPsec tunnels, and sometimes only a 
subset of the instances should have access in through the firewall. 

A typical corporate firewall environment, replicated in a VPC, might have a DMZ 
tier with different types of public-facing servers (mail, web, etc.) with 
different required rule sets, and a LAN tier with controlled access from the 
DMZ. 

I think CloudStack could keep the tier model intact but make it more useful and 
secure in different scenarios. 

Chris 


- Original Message -

From: "Marcus"  
To: dev@cloudstack.apache.org 
Sent: Friday, May 15, 2015 3:16:48 AM 
Subject: Re: VPC Firewall Rule Limitations 

It's possible to do, but there's some work involved. We'd have to modify 
the table that stores the rules, then pass that in the ACL commands that 
change the iptables rules. 

It goes against the idea of tiers, though. A tier is supposed to represent 
a given function, your mail server and web server should probably be in 
separate tiers, or your mail sever should also be a web server, and your 
web server also a mail server, if they are to be in the same tier. 

On Wed, May 13, 2015 at 10:47 AM, Christopher Falk < 
christopher.f...@reliablenetworks.com> wrote: 

> Hi all, 
> 
> I've run into some limitations in the firewall rule capabilities in the 
> VPC side that I'm hoping could be addressed in a future release. For VPC 
> networks, when configuring ACL for tiers you can only manage tier-wide 
> destinations for inbound or sources for outbound. 
> 
> What would it take to build in more granularity to these options? 
> 
> For example, in a tier with one web server and one mail server, I have to 
> allow Inbound, from 0.0.0.0/0, on TCP 25, 80, 443 etc. This opens these 
> ports to *all* instances in the tier, assuming they don't have their own 
> OS-level firewalls running. Now of course only instances with Static NAT 
> configured will pass traffic but that still permits port 25 to the web 
> server and 80/443 to the FTP even if I don't want that. 
> 
> Typical firewall rule sets allow source/destination to be specified, so 
> that we could open port 25 to the FTP server IP only, and port 80/443 to 
> the web server only. 
> 
> The current rules are confusing for a new user with networking background. 
> You have to understand that when selecting "Ingress" your specified CIDR is 
> a *source* but when specifying "Egress" it is the destination CIDR. 
> 
> Thanks for the consideration, 
> 
> Christopher Falk 
> Director, Technical Operations 
> www.reliablenetworks.com 
> 

[GitHub] cloudstack pull request: ui: add custom error handling page

[bhaisaab]

GitHub user bhaisaab opened a pull request:

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

ui: add custom error handling page

This just catches any exception and avoid showing stacktrace.

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

$ git pull https://github.com/apache/cloudstack custom-error-page

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

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


commit f2fc87c6d5d109929e5afbff0e30cbe34a28421e
Author: Rohit Yadav 
Date:   2015-05-18T21:09:11Z

ui: add custom error handling page

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: ui: add custom error handling page

[DaanHoogland]

Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/256#issuecomment-103220844
  
LGTM, why for 4.5 will you merge forward?


---
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: ui: add custom error handling page

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/256#issuecomment-103228420
  
yeah, will merge on both 4.5/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: ui: add custom error handling page

[DaanHoogland]

Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/256#issuecomment-103228536
  
ok, I will push to 4.5

Op di 19 mei 2015 om 00:10 schreef Rohit Yadav :

> yeah, will merge on both 4.5/master :)
>
> —
> 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.
---

[GitHub] cloudstack pull request: ui: add custom error handling page

[DaanHoogland]

Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/256#issuecomment-103229050
  
you beat me

Op di 19 mei 2015 om 00:11 schreef Daan Hoogland :

> ok, I will push to 4.5
>
> Op di 19 mei 2015 om 00:10 schreef Rohit Yadav :
>
> yeah, will merge on both 4.5/master :)
>>
>> —
>> 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.
---

[GitHub] cloudstack pull request: ui: add custom error handling page

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: ui: add custom error handling page

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/256#issuecomment-103229305
  
oh, I did not know you were doing it :)
Pushed to master as well.


---
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: ui: add custom error handling page

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/256#issuecomment-103229542
  
@DaanHoogland I could be faster as I use a Github PR merging automation 
alias, you may try this: 
https://github.com/bhaisaab/dotfiles/blob/master/git/gitconfig#L46
Usage: git 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: Systemvm: Disable services that slow down...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/254#issuecomment-103232141
  
Merged on 4.5 and 4.4; I made another fix to include libc:i386, will 
refresh 4.5 systemvmtemplates on packages.shapeblue.com tomorrow.


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

Re: [GitHub] cloudstack pull request: ui: add custom error handling page

[Daan Hoogland]

looks impressive but I think it was the test compile that did me in ;)

Op di 19 mei 2015 om 00:14 schreef bhaisaab :

> Github user bhaisaab commented on the pull request:
>
> https://github.com/apache/cloudstack/pull/256#issuecomment-103229542
>
> @DaanHoogland I could be faster as I use a Github PR merging
> automation alias, you may try this:
> https://github.com/bhaisaab/dotfiles/blob/master/git/gitconfig#L46
> Usage: git 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.
> ---
>

CLOUDSTACK DAY SEATTLE] CFP Deadline June 12

[Likitha Shetty]

Hi everyone,

Just a friendly reminder that the deadline for submitting a proposal for 
CloudStack Day Seattle is Friday, June 12. You can submit your proposal @ 
http://events.linuxfoundation.org/events/cloudstack-seattle/program/cfp .

Thanks,
Likitha

Re: Preparing for 4.6

[Erik Weber]

On Mon, May 18, 2015 at 1:14 PM, Daan Hoogland 
wrote:

> I don't like the writing of a changelog in the root, it is in git already.
>
The comments should be good and describing the changes. The changes should
> be small enough to be described adequately in a short changelog. That's why
> I don't like squashing anything but the very trivial.
>

IMHO, the ChangeLog, Commit message or JIRA Issue we rely on should say
/why/ something is done.
Typically git commit messages often say /what/ has been done.

Here's a recent example (I don't mean to bash that particular commit, it's
just one of the latest commits I found):
https://github.com/apache/cloudstack/commit/9d8a62d0ee379bf8b67405944c86f68587245db6

It states that a package was added, but not why. That makes it hard in the
future to say if it is still needed or not.

A ChangeLog or JIRA issue related to the same commit could say why it had
to be done, coupled with an error message or similar.

Luckily, the majority of commits mention a JIRA issue.

-- 
Erik


>
> Op ma 18 mei 2015 om 11:50 schreef Erik Weber :
>
> > On a related note, commits should reference the  JIRA ticket as well.
> >
> > --
> > Erik
> >
> > On Mon, May 18, 2015 at 11:27 AM, Wilder Rodrigues <
> > wrodrig...@schubergphilis.com> wrote:
> >
> > > Okay,
> > >
> > > +1 for create the ACS Jira issue for improvements as well.
> > >
> > > Since Xen and Libvirt redesign will be on 4.6 - and are already
> > documented
> > > - I will just create 2 issues so we have a way of keeping track of
> them.
> > >
> > > Cheers,
> > > Wilder
> > >
> > >
> > > On 18 May 2015, at 11:16, Stephen Turner  > > > wrote:
> > >
> > > Speaking for my XenCenter team again, for things like that we would
> have
> > > an improvement ticket, pointing to the wiki page.
> > >
> > > By the way, this also allows us to schedule the work on our sprint, but
> > we
> > > had the policy even before we were doing Scrum. In a large,
> distributed,
> > > volunteer organisation, I would argue that it's even more important to
> be
> > > able to trace the change back to its reason, now and later.
> > >
> > > --
> > > Stephen Turner
> > >
> > >
> > > -Original Message-
> > > From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com]
> > > Sent: 18 May 2015 10:11
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: Preparing for 4.6
> > >
> > > Hi there,
> > >
> > > I agree with the Jira ticket for the "new features, important fixes,
> > > security fixes"
> > >
> > > But I don’t think only about "new features, important fixes, security
> > > fixes”. I put most of my time in make the code better and tested, for
> > what
> > > we call refactoring/rewriting/redesigning. Should we also create Jira
> > > issues for that and mark them as Improvement?
> > >
> > > Taking into account the [VPC] Virtual Router, Citrix Resource Base and
> > > Libvirt Computing Resource refactoring, we had only internal issues on
> > > Jira. However, the changes have been documented on the 4.5/4.6 sections
> > of
> > > the Apache / Developers / Design Documents wiki:
> > >
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactor+for+Redundant+Virtual+Router+Implementation
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactoring+XenServer+Hypervisor+Plugin
> > >
> > > The Libvirt documentation is on its way, since the PR was pushed only
> > last
> > > week.
> > >
> > > Cheers,
> > > Wilder
> > >
> > >
> > > On 18 May 2015, at 10:39, Stephen Turner  > > >
> > > wrote:
> > >
> > > In my XenCenter dev team at Citrix, we have the policy of requiring a
> > > ticket number on every commit. If we find a bug and there isn't
> already a
> > > ticket, we create a ticket before committing the fix. I guess I've just
> > dug
> > > through history too many times to understand why something that appears
> > > wrong was done, only to find an inadequate description at the end of
> the
> > > trail.
> > >
> > > --
> > > Stephen Turner
> > >
> > >
> > > -Original Message-
> > > From: Erik Weber [mailto:terbol...@gmail.com]
> > > Sent: 18 May 2015 09:32
> > > To: dev
> > > Subject: Re: Preparing for 4.6
> > >
> > > On Mon, May 18, 2015 at 10:26 AM, Rene Moser   > > m...@renemoser.net>> wrote:
> > >
> > > Hi
> > >
> > > On 15.05.2015 11:27, Sebastien Goasguen wrote:
> > > Folks,
> > >
> > > As we prepare to try a new process for 4.6 release it would be nice to
> > > start paying attention to master.
> > >
> > > - Good commit messages
> > >
> > > The question is, what makes a commit message good? Maybe this helps:
> > >
> > > http://secure-web.cisco.com/1cOtAU9lruLvoJl9SBdNSTHN6eyvml6nO5JlwT8_V2
> > > d_Y7wsnHAV3NiHTOya0cRQyt1WuG_fzithwjk4Qu-l3usM-B_yzy7V4qaxtoDIlEixysid
> > > QZ0ZbuK0YMNgknwBUaRUBJYNkjfGoppsXIpUXcmRvOH565otFMCmJUX2mfkrj_z5Vwm0wh
> > > PDqu

[GitHub] cloudstack pull request: Implementation for the ability to disable...

[devdeep]

GitHub user devdeep opened a pull request:

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

Implementation for the ability to disable a storage pool for provisioning 
of new volumes.

Implementation for the ability to disable a storage pool for provisioning 
of new volumes. Following changes are implemented
1. Disable or enable a pool with the updateStoragePool api. A new 'enabled' 
parameter added for the same.
2. When a pool is disabled the state of the pool is updated to 'Disabled' 
in the db. On enabling it is updated back to 'Up'. Alert is raised when a pool 
is disabled or enabled.
3. Updated other storage providers to also honor the disabled state.
4. A disabled pool is skipped by allocators for provisioning of new volumes.
5. Since the allocators skip a disabled pool for provisioning of volumes, 
the volumes are also not listed as a destination for volume migration.
6. Marvin automation tests for testing the feature.


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

$ git pull https://github.com/devdeep/cloudstack-1 disable_storagepool2

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

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


commit 83c8b2cea95f6803799315d2919d1b1961b2a64c
Author: Devdeep Singh 
Date:   2015-05-05T12:54:04Z

Implementation for the ability to disable a storage pool for provisioning
of new volumes. Following changes are implemented
1. Disable or enable a pool with the updateStoragePool api. A new 'enabled'
   parameter added for the same.
2. When a pool is disabled the state of the pool is updated to 'Disabled'
   in the db. On enabling it is updated back to 'Up'. Alert is raised when
   a pool is disabled or enabled.
3. Updated other storage providers to also honour the disabled state.
4. A disabled pool is skipped by allocators for provisioing of new volumes.
5. Since the allocators skip a disabled pool for provisioning of volumes,
   the volumes are also not listed as a destination for volume migration.

commit 70a22cfe997d7bf660d7198326342148397d95e7
Author: Sowmya Krishnan 
Date:   2015-05-06T10:34:51Z

Tests for Disable Storage Provisioning




---
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: Implementation for the ability to disable...

[terbolous]

Github user terbolous commented on the pull request:

https://github.com/apache/cloudstack/pull/257#issuecomment-103369983
  
I love this feature! Is there a related Jira issue and/or FS spec for it?

What happens if a user tries to resize a volume that resides on a disabled 
storage pool?


---
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: Implementation for the ability to disable...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/257#issuecomment-103371847
  
@devdeep thanks probably one of the frequently asked features, LGTM. I'll 
wait and merge when travis goes green.


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