Re: Review Request 24111: Coverity findings for brocade-plugin

[Santhosh Edukulla]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24111/#review49213
---



plugins/network-elements/brocade-vcs/src/com/cloud/network/brocade/BrocadeVcsApi.java


This particular try\except  is  for an IO exception possible when closing a 
resource, so the message should have some reflection in it. But, when you use 
try-with-resource as mentioned in other issue, this is not required.


- Santhosh Edukulla


On July 30, 2014, 7:44 p.m., Ritu  Sabharwal wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24111/
> ---
> 
> (Updated July 30, 2014, 7:44 p.m.)
> 
> 
> Review request for cloudstack and Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-6823
> https://issues.apache.org/jira/browse/CLOUDSTACK-6823
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixed Coverity findings for brocade-plugin
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/api/response/BrocadeVcsDeviceResponse.java
>  60edbcf 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/network/brocade/BrocadeVcsApi.java
>  d5f06f8 
> 
> Diff: https://reviews.apache.org/r/24111/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ritu  Sabharwal
> 
>

Re: 4.4-forward picked empty

[Daan Hoogland]

Ok, thanks
git cherry didn't pick those three up.

On Thu, Jul 31, 2014 at 12:08 AM, Min Chen  wrote:
> Daan,
>
> That commit is already there in 4.4 branch. See
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=6ba541a
> fb73475758a62a17dae1ec1be088da810.
>
> Thanks
> -min
>
>
>
>
> On 7/30/14 5:33 AM, "Daan Hoogland"  wrote:
>
>>thanks Rajani
>>
>>On Wed, Jul 30, 2014 at 2:20 PM, Rajani Karuturi
>> wrote:
>>> Hi Daan,
>>>
>>>
>>> commit 2ab7bcade2f37cb17e071a6154fdae1d80e4ff99
>>> Author: Rajani Karuturi 
>>> Date:   Fri May 23 15:50:06 2014 +0530
>>>
>>>Fixed CLOUDSTACK-6756: usage id is not being returned for an ip in
>>> deleted ip range
>>>
>>>
>>> This is same as df42ce903d399cf30055e55bc24b84fbc0b563a9 on 4.4
>>>
>>> commit d511847cfedad5478d1b4087c8f97be2c5bf3cc8
>>> Author: Rajani Karuturi 
>>> Date:   Tue Jun 3 16:11:01 2014 +0530
>>>
>>>Fixed Resource leak (RESOURCE_LEAK) 11. overwrite_var: Overwriting
>>> "pstmt" in "pstmt = conn.prepareStatement("INSERT INTO
>>> `cloud`.`ldap_configuration`(hostname, po
>>>
>>>Signed-off-by: Koushik Das 
>>>
>>>
>>> Can be ignored. Fixes are already there.
>>>
>>> ~ Rajani
>>
>>
>>
>>--
>>Daan
>



-- 
Daan

Re: [Summary] checkin process

[Daan Hoogland]

Rajani, we can't cut a new master from 4.4
Leo's work on comparing the branches showed us that. So the new flow will
be limited To master land 4.5+

biligual spelling checker used.read at your own risk
Op 31 jul. 2014 06:22 schreef "Rajani Karuturi" :

> For the git flow:
> 1. We agreed to follow git-flow explained here
> http://nvie.com/posts/a-successful-git-branching-model/
> 2. This is the proposal for first cut
> 2a. rename 'master' to 'develop’
> 2b. branch a new 'master' from ‘4.4’ and update tags with release/4.4.0
> 2c. branch ‘release/4.5' from the develop
> 2d. merge ‘release/4.5' to master once the release voting is done.
> 3. This would be the flow for a hot fix
> 3a. branch off from the release tag on master. in this case it would be
> release/4.4.0
> 3b. commit the fixes in hotfix/4.4.1
> 3c. do the release
> 3d. merge to develop
> 3e. merge to master and update tags
> 3f. delete hot fix branch
> 4. for any LTS release create a support branch when required using
> git-flow support
> 4a. http://stackoverflow.com/a/16866118/201514
>
> using the git-flow git extension available at
> https://github.com/nvie/gitflow can reduce the number of commands/errors
>
> In addition:
> 1. Every commit should have unit tests
> 2. every feature/merge request should have unit and marvin integration
> tests
> 3. A commit should not have check style or find bugs issues
> 4. any coverity issues reported in the new code should be addressed
> immediately
> 5. every developer should run the BVT on the simulator before doing a
> checkin (
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator
> <
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes,+using+Simulator
> >)
>  (This I am not very sure. May be we should let jenkins handle it and
> report integration failures if any?)
> Please add/amend if I missed anything.
>
> Can we call for a vote on this and freeze this without further delay?
>
>
> ~Rajani
>
>
>
>

Re: [Summary] checkin process

[Daan Hoogland]

I answerred this from my phone but it did't get through so here my
comment again:

We can't cut a new master from 4.4 without enormous work. I spend two
days on getting 4.4 in line with 4.4-forward and as Leo has shown the
work for getting all features from master into master will be much
greater. So the proposal should be that we maintain 4.4 as traditional
and start this work flow from 4.5+

As for the additions you gave; these are reviewer guidelines for my
part not requirements to a work flow.

In general I am +1 on putting this to vote.

On Thu, Jul 31, 2014 at 6:22 AM, Rajani Karuturi
 wrote:
> For the git flow:
> 1. We agreed to follow git-flow explained here 
> http://nvie.com/posts/a-successful-git-branching-model/
> 2. This is the proposal for first cut
> 2a. rename 'master' to 'develop’
> 2b. branch a new 'master' from ‘4.4’ and update tags with release/4.4.0
> 2c. branch ‘release/4.5' from the develop
> 2d. merge ‘release/4.5' to master once the release voting is done.
> 3. This would be the flow for a hot fix
> 3a. branch off from the release tag on master. in this case it would be 
> release/4.4.0
> 3b. commit the fixes in hotfix/4.4.1
> 3c. do the release
> 3d. merge to develop
> 3e. merge to master and update tags
> 3f. delete hot fix branch
> 4. for any LTS release create a support branch when required using git-flow 
> support
> 4a. http://stackoverflow.com/a/16866118/201514
>
> using the git-flow git extension available at https://github.com/nvie/gitflow 
> can reduce the number of commands/errors
>
> In addition:
> 1. Every commit should have unit tests
> 2. every feature/merge request should have unit and marvin integration tests
> 3. A commit should not have check style or find bugs issues
> 4. any coverity issues reported in the new code should be addressed 
> immediately
> 5. every developer should run the BVT on the simulator before doing a checkin 
> (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator)
>  (This I am not very sure. May be we should let jenkins handle it and report 
> integration failures if any?)
> Please add/amend if I missed anything.
>
> Can we call for a vote on this and freeze this without further delay?
>
>
> ~Rajani
>
>
>



-- 
Daan

Re: [DISCUSS] git commit proces

[Leo Simons]

On Jul 31, 2014, at 12:55 AM, Sheng Yang  wrote:
> I suppose it would work like this:
> 1. In the original model, every release branch would be deleted after merge
> into develop and master branch. There is no release/4.4.1 or release/4.5
> branch.
> 2. Say we don't follow original model, when one release is released, you
> keep it. Say we have release/4.4 and release/4.5. And currently we're
> working on 4.7 which is develop branch, MASTER is 4.6.
> 3. I have one bug in 4.4, I checked in a fix in 4.4. Release 4.4.1.
> 4. Then, conflict would happen when you merge release/4.4. branch to
> release/4.5. Since the version number changed to 4.4.1. You need to deal
> with version number conflict every time when merge to upper release.
> 5. Suppose you dealt with version number change. New release/4.5 would
> merge release/4.4 which merged release/4.3. Then you want to merge to
> master because there is a fix. Well, dealt with version number change
> conflict again.
> 6. Then, you would need to merge master to develop branch?
> 
> I am little worry about the conflict every time when merge happened. Seems
> version number conflict need to be dealt with everytime, and probably some
> other conflict. The conflict need to be solved may result in more
> error-prone situation.

Well, yes, _that_ would be horrible! :-)

Fortunately a merge only considers things that haven’t been merged before. If V 
means ‘bump version’, given

master -
 \ / \
r/4.5 V1---y--V2  \
\  \
r/4.6\  V3--z---
  \/
fixx---

because V1 is an ancestor of V3, when you merge x into r/4.6, git knows not to 
consider V1 commit again. It knows it only has to consider x. There is no 
conflict due to V1 or V2 at z. If you would do this

master --
 \  \   /
r/4.5 V1-\-V2
  \\ \
r/4.6  V3---\-z——-\--z2--
 \   / \/
fix   x—-   \  /
 \/
fix2  x2--

you will have a merge conflict once, at spot z, where you will have to resolve 
the conflict created by having conflicting ancestors V2 and V3. But you won’t 
have to deal with it at spot z2, since git will remember you already resolved 
that conflict before.

As long as you merge, instead of cherry-pick.

>> For example, the linux kernel has at least two active minor releases at
>> any given time, and many more minor releases and forks going on at that
>> same time, with hundreds (thousands?) of active developers, and even _they_
>> don’t need freezes. Instead the power is in their choices of what they do
>> and do not
> 
> I've worked on Linux kernel for years,

If you have experience with linux’ approach, I’d suggest you just look at 
git-flow as a massively simplified version of roughly that, which is easier to 
get into, something to hold on to while you develop experience and then good 
judgement [1] of when/what/where to merge. A reasonable starting point. Also, 
now I _really_ don’t understand why we have to have this discussion :)

> they do have an strict code freeze.

Well, sure, but the linux freeze is a very _different_ kind of code freeze to 
what cloudstack has been doing :). All that happens is the maintainers decide 
to stop merging things into their RC branches. The wider linux community 
doesn’t skip a beat. Heck, IMHO, if cloudstack were to adopt a more linux-like 
model that would be awesome…but you have to walk before you can run…for some 
reason I suspect this community is not ready to start rejecting commits because 
the first line of their message overruns 72 characters…or because someone’s 
eclipse made unrelated whitespace changes…


cheers,


Leo

[1] http://yarchive.net/comp/linux/git_merges_from_upstream.html
https://lkml.org/lkml/2008/5/21/351
http://lwn.net/Articles/328438/
…etc…

Re: Simulator on master is not building

[Hugo Trippaers]

Heya,

I’m setting up a separate build (build-master-simulator) to test the build 
process of the simulator. At least we’ll be notified if any failures occur in 
the build next time. I don’t think it should be included in the regular build, 
it’s not something we would like to ship to end-users right?

Cheers,

Hugo

On 31 jul. 2014, at 06:54, Koushik Das  wrote:

> Simulator can be included in the default build but it needs to be tested 
> whether simulator plugin can coexist with actual HV plugins in the same MS 
> without any issues. Right now there is an issue which prevents it, refer to 
> https://issues.apache.org/jira/browse/CLOUDSTACK-6623. Once this is fixed it 
> needs to be tested again.
> 
> Also there needs to be a consensus to include it in default profile.
> 
> -Original Message-
> From: Edison Su 
> Sent: Wednesday, 30 July 2014 11:30 PM
> To: dev@cloudstack.apache.org; Koushik Das
> Subject: RE: Simulator on master is not building
> 
> +1, include simulator in the default build, exclude explicitly in the 
> production build.
> 
>> -Original Message-
>> From: Anthony Xu [mailto:xuefei...@citrix.com]
>> Sent: Wednesday, July 30, 2014 10:28 AM
>> To: Koushik Das; dev@cloudstack.apache.org
>> Subject: RE: Simulator on master is not building
>> 
>> We used -Dsimulator to include simulator, it is very easy for 
>> developers to forget it.  Simulator should be built by default , we 
>> may use -Dnosimulator to exclude simulator.
>> 
>> 
>> Anthony
>> 
>> -Original Message-
>> From: Koushik Das
>> Sent: Wednesday, July 30, 2014 3:03 AM
>> To: dev@cloudstack.apache.org
>> Cc: Anthony Xu
>> Subject: RE: Simulator on master is not building
>> 
>> The simulator code should be kept up to date with any changes done in 
>> the core product. If there are any interface changes, necessary 
>> changes should be made in simulator plugin as well along with other 
>> hypervisor plugins. To build simulator code use refer to [1].
>> 
>> -Koushik
>> 
>> [1]
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Simulator+integ
>> r
>> ation
>> 
>> -Original Message-
>> From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com]
>> Sent: Wednesday, 30 July 2014 3:27 PM
>> To: dev@cloudstack.apache.org
>> Cc: Anthony Xu
>> Subject: Simulator on master is not building
>> 
>> I believe for every check-in we decided to run sanity tests on 
>> simulator atleast, currently build for simulator is failing.
>> 
>> 
>> --
>> -- [ERROR] Failed to execute goal 
>> org.apache.maven.plugins:maven-compiler-
>> plugin:2.5.1:compile (default-compile) on project 
>> cloud-plugin-hypervisor-
>> simulator: Compilation failure: Compilation failure:
>> [ERROR]
>> /home/santhosh/softwares/cs_new_master/cloudstack/plugins/hypervisor
>> s/simulator/src/com/cloud/resource/AgentRoutingResource.java:[230,8]
>> error: 'try' without 'catch', 'finally' or resource declarations 
>> [ERROR] 
>> /home/santhosh/softwares/cs_new_master/cloudstack/plugins/hypervisor
>> s/simulator/src/com/cloud/resource/AgentRoutingResource.java:[251,8]
>> error: 'try' without 'catch', 'finally' or resource declarations
>> 
>> 
>> Thanks!
>> Santhosh

RE: Simulator on master is not building

[Santhosh Edukulla]

This is cool.

Santhosh

From: Trippie [trip...@gmail.com] on behalf of Hugo Trippaers 
[h...@trippaers.nl]
Sent: Thursday, July 31, 2014 4:27 AM
To: dev@cloudstack.apache.org
Cc: Edison Su
Subject: Re: Simulator on master is not building

Heya,

I’m setting up a separate build (build-master-simulator) to test the build 
process of the simulator. At least we’ll be notified if any failures occur in 
the build next time. I don’t think it should be included in the regular build, 
it’s not something we would like to ship to end-users right?

Cheers,

Hugo

On 31 jul. 2014, at 06:54, Koushik Das  wrote:

> Simulator can be included in the default build but it needs to be tested 
> whether simulator plugin can coexist with actual HV plugins in the same MS 
> without any issues. Right now there is an issue which prevents it, refer to 
> https://issues.apache.org/jira/browse/CLOUDSTACK-6623. Once this is fixed it 
> needs to be tested again.
>
> Also there needs to be a consensus to include it in default profile.
>
> -Original Message-
> From: Edison Su
> Sent: Wednesday, 30 July 2014 11:30 PM
> To: dev@cloudstack.apache.org; Koushik Das
> Subject: RE: Simulator on master is not building
>
> +1, include simulator in the default build, exclude explicitly in the 
> production build.
>
>> -Original Message-
>> From: Anthony Xu [mailto:xuefei...@citrix.com]
>> Sent: Wednesday, July 30, 2014 10:28 AM
>> To: Koushik Das; dev@cloudstack.apache.org
>> Subject: RE: Simulator on master is not building
>>
>> We used -Dsimulator to include simulator, it is very easy for
>> developers to forget it.  Simulator should be built by default , we
>> may use -Dnosimulator to exclude simulator.
>>
>>
>> Anthony
>>
>> -Original Message-
>> From: Koushik Das
>> Sent: Wednesday, July 30, 2014 3:03 AM
>> To: dev@cloudstack.apache.org
>> Cc: Anthony Xu
>> Subject: RE: Simulator on master is not building
>>
>> The simulator code should be kept up to date with any changes done in
>> the core product. If there are any interface changes, necessary
>> changes should be made in simulator plugin as well along with other
>> hypervisor plugins. To build simulator code use refer to [1].
>>
>> -Koushik
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Simulator+integ
>> r
>> ation
>>
>> -Original Message-
>> From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com]
>> Sent: Wednesday, 30 July 2014 3:27 PM
>> To: dev@cloudstack.apache.org
>> Cc: Anthony Xu
>> Subject: Simulator on master is not building
>>
>> I believe for every check-in we decided to run sanity tests on
>> simulator atleast, currently build for simulator is failing.
>>
>>
>> --
>> -- [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-compiler-
>> plugin:2.5.1:compile (default-compile) on project
>> cloud-plugin-hypervisor-
>> simulator: Compilation failure: Compilation failure:
>> [ERROR]
>> /home/santhosh/softwares/cs_new_master/cloudstack/plugins/hypervisor
>> s/simulator/src/com/cloud/resource/AgentRoutingResource.java:[230,8]
>> error: 'try' without 'catch', 'finally' or resource declarations
>> [ERROR]
>> /home/santhosh/softwares/cs_new_master/cloudstack/plugins/hypervisor
>> s/simulator/src/com/cloud/resource/AgentRoutingResource.java:[251,8]
>> error: 'try' without 'catch', 'finally' or resource declarations
>>
>>
>> Thanks!
>> Santhosh

Wiki : Code Submission and Review Guidelines

[Santhosh Edukulla]

All,

Iam not sure if it is already available, so i added a simple wiki with few 
notes for new submission and review process at the link below.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Code+Submission+and+Review+Guidelines

In case, if there are any issues with the wiki, please feel free to modify and 
add accordingly. If we can add specific examples for few cases helping users to 
follow them appropriately, then it will be more good.

Thanks!
Santhosh

Re: [Summary] checkin process

[Sebastien Goasguen]

On Jul 31, 2014, at 3:39 AM, Daan Hoogland  wrote:

> I answerred this from my phone but it did't get through so here my
> comment again:
> 
> We can't cut a new master from 4.4 without enormous work. I spend two
> days on getting 4.4 in line with 4.4-forward and as Leo has shown the
> work for getting all features from master into master will be much
> greater. So the proposal should be that we maintain 4.4 as traditional
> and start this work flow from 4.5+
> 
> As for the additions you gave; these are reviewer guidelines for my
> part not requirements to a work flow.
> 
> In general I am +1 on putting this to vote.

Has a proposal made it to the wiki ? 
We need one clear proposal with couple backers to bring this forward to a vote ?
Daan, Rajani and Leo, maybe you can edit the wiki ?


> 
> On Thu, Jul 31, 2014 at 6:22 AM, Rajani Karuturi
>  wrote:
>> For the git flow:
>> 1. We agreed to follow git-flow explained here 
>> http://nvie.com/posts/a-successful-git-branching-model/
>> 2. This is the proposal for first cut
>> 2a. rename 'master' to 'develop’
>> 2b. branch a new 'master' from ‘4.4’ and update tags with release/4.4.0
>> 2c. branch ‘release/4.5' from the develop
>> 2d. merge ‘release/4.5' to master once the release voting is done.
>> 3. This would be the flow for a hot fix
>> 3a. branch off from the release tag on master. in this case it would be 
>> release/4.4.0
>> 3b. commit the fixes in hotfix/4.4.1
>> 3c. do the release
>> 3d. merge to develop
>> 3e. merge to master and update tags
>> 3f. delete hot fix branch
>> 4. for any LTS release create a support branch when required using git-flow 
>> support
>> 4a. http://stackoverflow.com/a/16866118/201514
>> 
>> using the git-flow git extension available at 
>> https://github.com/nvie/gitflow can reduce the number of commands/errors
>> 
>> In addition:
>> 1. Every commit should have unit tests
>> 2. every feature/merge request should have unit and marvin integration tests
>> 3. A commit should not have check style or find bugs issues
>> 4. any coverity issues reported in the new code should be addressed 
>> immediately
>> 5. every developer should run the BVT on the simulator before doing a 
>> checkin 
>> (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator)
>> (This I am not very sure. May be we should let jenkins handle it and report 
>> integration failures if any?)
>> Please add/amend if I missed anything.
>> 
>> Can we call for a vote on this and freeze this without further delay?
>> 
>> 
>> ~Rajani
>> 
>> 
>> 
> 
> 
> 
> -- 
> Daan

Re: [Summary] checkin process

[Rajani Karuturi]

to start using git-flow from 4.5+, we need to have the latest stable version 
which can be master and I assumed that would be 4.4
point 2. should be modified assuming no previous releases
>> 2a. branch ‘develop’ from 'master’
>> 2b. branch ‘release/4.5' from the develop
>> 2c. merge ‘release/4.5' to master once the release voting is done.

Are we waiting for Leo to put up a proposal? 

~Rajani



On 31-Jul-2014, at 1:09 pm, Daan Hoogland  wrote:

> I answerred this from my phone but it did't get through so here my
> comment again:
> 
> We can't cut a new master from 4.4 without enormous work. I spend two
> days on getting 4.4 in line with 4.4-forward and as Leo has shown the
> work for getting all features from master into master will be much
> greater. So the proposal should be that we maintain 4.4 as traditional
> and start this work flow from 4.5+
> 
> As for the additions you gave; these are reviewer guidelines for my
> part not requirements to a work flow.
> 
> In general I am +1 on putting this to vote.
> 
> On Thu, Jul 31, 2014 at 6:22 AM, Rajani Karuturi
>  wrote:
>> For the git flow:
>> 1. We agreed to follow git-flow explained here 
>> http://nvie.com/posts/a-successful-git-branching-model/
>> 2. This is the proposal for first cut
>> 2a. rename 'master' to 'develop’
>> 2b. branch a new 'master' from ‘4.4’ and update tags with release/4.4.0
>> 2c. branch ‘release/4.5' from the develop
>> 2d. merge ‘release/4.5' to master once the release voting is done.
>> 3. This would be the flow for a hot fix
>> 3a. branch off from the release tag on master. in this case it would be 
>> release/4.4.0
>> 3b. commit the fixes in hotfix/4.4.1
>> 3c. do the release
>> 3d. merge to develop
>> 3e. merge to master and update tags
>> 3f. delete hot fix branch
>> 4. for any LTS release create a support branch when required using git-flow 
>> support
>> 4a. http://stackoverflow.com/a/16866118/201514
>> 
>> using the git-flow git extension available at 
>> https://github.com/nvie/gitflow can reduce the number of commands/errors
>> 
>> In addition:
>> 1. Every commit should have unit tests
>> 2. every feature/merge request should have unit and marvin integration tests
>> 3. A commit should not have check style or find bugs issues
>> 4. any coverity issues reported in the new code should be addressed 
>> immediately
>> 5. every developer should run the BVT on the simulator before doing a 
>> checkin 
>> (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator)
>> (This I am not very sure. May be we should let jenkins handle it and report 
>> integration failures if any?)
>> Please add/amend if I missed anything.
>> 
>> Can we call for a vote on this and freeze this without further delay?
>> 
>> 
>> ~Rajani
>> 
>> 
>> 
> 
> 
> 
> -- 
> Daan

Re: 4.4-forward usage

[Sebastien Goasguen]

On Jul 30, 2014, at 5:13 PM, David Nalley  wrote:

> On Wed, Jul 30, 2014 at 4:26 PM, Daan Hoogland 
> wrote:
> 
>> On Wed, Jul 30, 2014 at 10:15 PM, Sebastien Goasguen 
>> wrote:
>>> and merge it in other needed branches (master and develop)
>> 
>> 
>> that part will be hard as it will merge all commits (also hotfixes and
>> others) that aren't on the the ancestry of the branch to merge into.
>> So this is only possible if the 4.4 branch is relatively clean.
>> 
>> 
>> 
> Agreed - in many respects the rate of change almost dictates that we'll end
> up with multiple release branches. I worry it's a bit naive to think that
> something as complicated and large as CloudStack, and moving at the
> velocity we do, will end up with only one set of 'master and develop'
> 

I don't think cloudstack is that special. But let's wait to see a proposal to 
all have a common understanding of how this would work.

Right now we have several threads on the same subject.

> --David

Re: [Summary] checkin process

[Sebastien Goasguen]

On Jul 31, 2014, at 4:46 AM, Rajani Karuturi  wrote:

> to start using git-flow from 4.5+, we need to have the latest stable version 
> which can be master and I assumed that would be 4.4
> point 2. should be modified assuming no previous releases
>>> 2a. branch ‘develop’ from 'master’
>>> 2b. branch ‘release/4.5' from the develop
>>> 2c. merge ‘release/4.5' to master once the release voting is done.
> 
> Are we waiting for Leo to put up a proposal? 

Anyone really :)

Someone mentioned: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git

You could add a section on 'gitflow' and basically dump your bullet list.

Then we can edit it and call a vote .


> 
> ~Rajani
> 
> 
> 
> On 31-Jul-2014, at 1:09 pm, Daan Hoogland  wrote:
> 
>> I answerred this from my phone but it did't get through so here my
>> comment again:
>> 
>> We can't cut a new master from 4.4 without enormous work. I spend two
>> days on getting 4.4 in line with 4.4-forward and as Leo has shown the
>> work for getting all features from master into master will be much
>> greater. So the proposal should be that we maintain 4.4 as traditional
>> and start this work flow from 4.5+
>> 
>> As for the additions you gave; these are reviewer guidelines for my
>> part not requirements to a work flow.
>> 
>> In general I am +1 on putting this to vote.
>> 
>> On Thu, Jul 31, 2014 at 6:22 AM, Rajani Karuturi
>>  wrote:
>>> For the git flow:
>>> 1. We agreed to follow git-flow explained here 
>>> http://nvie.com/posts/a-successful-git-branching-model/
>>> 2. This is the proposal for first cut
>>> 2a. rename 'master' to 'develop’
>>> 2b. branch a new 'master' from ‘4.4’ and update tags with release/4.4.0
>>> 2c. branch ‘release/4.5' from the develop
>>> 2d. merge ‘release/4.5' to master once the release voting is done.
>>> 3. This would be the flow for a hot fix
>>> 3a. branch off from the release tag on master. in this case it would be 
>>> release/4.4.0
>>> 3b. commit the fixes in hotfix/4.4.1
>>> 3c. do the release
>>> 3d. merge to develop
>>> 3e. merge to master and update tags
>>> 3f. delete hot fix branch
>>> 4. for any LTS release create a support branch when required using git-flow 
>>> support
>>> 4a. http://stackoverflow.com/a/16866118/201514
>>> 
>>> using the git-flow git extension available at 
>>> https://github.com/nvie/gitflow can reduce the number of commands/errors
>>> 
>>> In addition:
>>> 1. Every commit should have unit tests
>>> 2. every feature/merge request should have unit and marvin integration tests
>>> 3. A commit should not have check style or find bugs issues
>>> 4. any coverity issues reported in the new code should be addressed 
>>> immediately
>>> 5. every developer should run the BVT on the simulator before doing a 
>>> checkin 
>>> (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator)
>>> (This I am not very sure. May be we should let jenkins handle it and report 
>>> integration failures if any?)
>>> Please add/amend if I missed anything.
>>> 
>>> Can we call for a vote on this and freeze this without further delay?
>>> 
>>> 
>>> ~Rajani
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> Daan
> 

Re: [Summary] checkin process

[Rajani Karuturi]

I updated the wiki 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-Gitflow


~Rajani



On 31-Jul-2014, at 2:47 pm, Sebastien Goasguen 
mailto:run...@gmail.com>> wrote:


On Jul 31, 2014, at 4:46 AM, Rajani Karuturi 
mailto:rajani.karut...@citrix.com>> wrote:

to start using git-flow from 4.5+, we need to have the latest stable version 
which can be master and I assumed that would be 4.4
point 2. should be modified assuming no previous releases
2a. branch ‘develop’ from 'master’
2b. branch ‘release/4.5' from the develop
2c. merge ‘release/4.5' to master once the release voting is done.

Are we waiting for Leo to put up a proposal?

Anyone really :)

Someone mentioned: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git

You could add a section on 'gitflow' and basically dump your bullet list.

Then we can edit it and call a vote .



~Rajani



On 31-Jul-2014, at 1:09 pm, Daan Hoogland 
mailto:daan.hoogl...@gmail.com>> wrote:

I answerred this from my phone but it did't get through so here my
comment again:

We can't cut a new master from 4.4 without enormous work. I spend two
days on getting 4.4 in line with 4.4-forward and as Leo has shown the
work for getting all features from master into master will be much
greater. So the proposal should be that we maintain 4.4 as traditional
and start this work flow from 4.5+

As for the additions you gave; these are reviewer guidelines for my
part not requirements to a work flow.

In general I am +1 on putting this to vote.

On Thu, Jul 31, 2014 at 6:22 AM, Rajani Karuturi
mailto:rajani.karut...@citrix.com>> wrote:
For the git flow:
1. We agreed to follow git-flow explained here 
http://nvie.com/posts/a-successful-git-branching-model/
2. This is the proposal for first cut
2a. rename 'master' to 'develop’
2b. branch a new 'master' from ‘4.4’ and update tags with release/4.4.0
2c. branch ‘release/4.5' from the develop
2d. merge ‘release/4.5' to master once the release voting is done.
3. This would be the flow for a hot fix
3a. branch off from the release tag on master. in this case it would be 
release/4.4.0
3b. commit the fixes in hotfix/4.4.1
3c. do the release
3d. merge to develop
3e. merge to master and update tags
3f. delete hot fix branch
4. for any LTS release create a support branch when required using git-flow 
support
4a. http://stackoverflow.com/a/16866118/201514

using the git-flow git extension available at https://github.com/nvie/gitflow 
can reduce the number of commands/errors

In addition:
1. Every commit should have unit tests
2. every feature/merge request should have unit and marvin integration tests
3. A commit should not have check style or find bugs issues
4. any coverity issues reported in the new code should be addressed immediately
5. every developer should run the BVT on the simulator before doing a checkin 
(https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator)
(This I am not very sure. May be we should let jenkins handle it and report 
integration failures if any?)
Please add/amend if I missed anything.

Can we call for a vote on this and freeze this without further delay?


~Rajani






--
Daan

Re: [Summary] checkin process

[Rohit Yadav]

Hi,

Please use this section on the wiki to propose/fix/modify the new proposed 
check-in process:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess

My feedback:

- I don’t want to enforce/adopt the gitflow model "as-is", like not rename 
master branch

- the aim IMO is to make master stable for people to work with, so we don’t 
break it often
- we do feature/bug-fix/any-work in our own branch and 
merge/cherry-pick/what-have-you when it has tests and it is stable (lazy 
definition as per committer’s discretion)

- the git commit cherry-picking/merging should be from firm/stable branches to 
unstable i.e. from release branches (such as 4.x) to master or developer’s own 
branch; the reverse is done only when the work/commits/check-ins are 
tested/firm/stable

We’ve so many threads with so many emails that we’re sort of causing 
split-brain issue for ourselves on this issue.

I’m not sure which one to follow now -- the length of a discussion thread is 
inversely proportional to the interest of community members on the thread.

Let’s start a new vote thread and drop discussion on other threads?

On 31-Jul-2014, at 11:17 am, Sebastien Goasguen  wrote:

>
> On Jul 31, 2014, at 4:46 AM, Rajani Karuturi  
> wrote:
>
>> to start using git-flow from 4.5+, we need to have the latest stable version 
>> which can be master and I assumed that would be 4.4
>> point 2. should be modified assuming no previous releases
 2a. branch ‘develop’ from 'master’
 2b. branch ‘release/4.5' from the develop
 2c. merge ‘release/4.5' to master once the release voting is done.
>>
>> Are we waiting for Leo to put up a proposal?
>
> Anyone really :)
>
> Someone mentioned: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git
>
> You could add a section on 'gitflow' and basically dump your bullet list.
>
> Then we can edit it and call a vote .
>
>
>>
>> ~Rajani
>>
>>
>>
>> On 31-Jul-2014, at 1:09 pm, Daan Hoogland  wrote:
>>
>>> I answerred this from my phone but it did't get through so here my
>>> comment again:
>>>
>>> We can't cut a new master from 4.4 without enormous work. I spend two
>>> days on getting 4.4 in line with 4.4-forward and as Leo has shown the
>>> work for getting all features from master into master will be much
>>> greater. So the proposal should be that we maintain 4.4 as traditional
>>> and start this work flow from 4.5+
>>>
>>> As for the additions you gave; these are reviewer guidelines for my
>>> part not requirements to a work flow.
>>>
>>> In general I am +1 on putting this to vote.
>>>
>>> On Thu, Jul 31, 2014 at 6:22 AM, Rajani Karuturi
>>>  wrote:
 For the git flow:
 1. We agreed to follow git-flow explained here 
 http://nvie.com/posts/a-successful-git-branching-model/
 2. This is the proposal for first cut
 2a. rename 'master' to 'develop’
 2b. branch a new 'master' from ‘4.4’ and update tags with release/4.4.0
 2c. branch ‘release/4.5' from the develop
 2d. merge ‘release/4.5' to master once the release voting is done.
 3. This would be the flow for a hot fix
 3a. branch off from the release tag on master. in this case it would be 
 release/4.4.0
 3b. commit the fixes in hotfix/4.4.1
 3c. do the release
 3d. merge to develop
 3e. merge to master and update tags
 3f. delete hot fix branch
 4. for any LTS release create a support branch when required using 
 git-flow support
 4a. http://stackoverflow.com/a/16866118/201514

 using the git-flow git extension available at 
 https://github.com/nvie/gitflow can reduce the number of commands/errors

 In addition:
 1. Every commit should have unit tests
 2. every feature/merge request should have unit and marvin integration 
 tests
 3. A commit should not have check style or find bugs issues
 4. any coverity issues reported in the new code should be addressed 
 immediately
 5. every developer should run the BVT on the simulator before doing a 
 checkin 
 (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator)
 (This I am not very sure. May be we should let jenkins handle it and 
 report integration failures if any?)
 Please add/amend if I missed anything.

 Can we call for a vote on this and freeze this without further delay?


 ~Rajani



>>>
>>>
>>>
>>> --
>>> Daan
>>
>

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab




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

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Cons

Build failed in Jenkins: build-master-simulator #2

[jenkins]

See 

Changes:

[santhosh.edukulla] Added Coverity Fixes

--
[...truncated 4854 lines...]
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ cloud-quickcloud ---
[INFO] Surefire report directory: 


---
 T E S T S
---

Results :

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

[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Test 4.5.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloud-testclient ---
[INFO] Deleting 
 
(includes = [**/*], excludes = [])
[INFO] Deleting 
 (includes = 
[target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-testclient ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-testclient ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-testclient ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
cloud-testclient ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-testclient ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-testclient ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ cloud-testclient ---
[INFO] Surefire report directory: 


---
 T E S T S
---

Results :

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

[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Developer Mode 4.5.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloud-developer ---
[INFO] Deleting 
 
(includes = [**/*], excludes = [])
[INFO] Deleting 
 
(includes = [target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-developer ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- properties-maven-plugin:1.0-alpha-2:read-project-properties 
(default) @ cloud-developer ---
[WARNING] Ignoring missing properties file: 

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-developer ---
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run (default) @ cloud-developer ---
[INFO] Executing tasks

main:
 [copy] Copying 78 files to 

 [copy] Copying 9 files to 

[INFO] Executed tasks
[INFO] 
[INFO] 
[INFO] Bu

Re: [Summary] checkin process

[Rajani Karuturi]

ahh… we have the same content twice on the wiki. I deleted the duplicate and 
edited it as per the comment from daan.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess

+1 for starting a vote thread



~Rajani



On 31-Jul-2014, at 3:04 pm, Rohit Yadav 
mailto:rohit.ya...@shapeblue.com>> wrote:

Hi,

Please use this section on the wiki to propose/fix/modify the new proposed 
check-in process:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess

My feedback:

- I don’t want to enforce/adopt the gitflow model "as-is", like not rename 
master branch

- the aim IMO is to make master stable for people to work with, so we don’t 
break it often
- we do feature/bug-fix/any-work in our own branch and 
merge/cherry-pick/what-have-you when it has tests and it is stable (lazy 
definition as per committer’s discretion)

- the git commit cherry-picking/merging should be from firm/stable branches to 
unstable i.e. from release branches (such as 4.x) to master or developer’s own 
branch; the reverse is done only when the work/commits/check-ins are 
tested/firm/stable

We’ve so many threads with so many emails that we’re sort of causing 
split-brain issue for ourselves on this issue.

I’m not sure which one to follow now -- the length of a discussion thread is 
inversely proportional to the interest of community members on the thread.

Let’s start a new vote thread and drop discussion on other threads?

On 31-Jul-2014, at 11:17 am, Sebastien Goasguen  wrote:


On Jul 31, 2014, at 4:46 AM, Rajani Karuturi  wrote:

to start using git-flow from 4.5+, we need to have the latest stable version 
which can be master and I assumed that would be 4.4
point 2. should be modified assuming no previous releases
2a. branch ‘develop’ from 'master’
2b. branch ‘release/4.5' from the develop
2c. merge ‘release/4.5' to master once the release voting is done.

Are we waiting for Leo to put up a proposal?

Anyone really :)

Someone mentioned: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git

You could add a section on 'gitflow' and basically dump your bullet list.

Then we can edit it and call a vote .



~Rajani



On 31-Jul-2014, at 1:09 pm, Daan Hoogland  wrote:

I answerred this from my phone but it did't get through so here my
comment again:

We can't cut a new master from 4.4 without enormous work. I spend two
days on getting 4.4 in line with 4.4-forward and as Leo has shown the
work for getting all features from master into master will be much
greater. So the proposal should be that we maintain 4.4 as traditional
and start this work flow from 4.5+

As for the additions you gave; these are reviewer guidelines for my
part not requirements to a work flow.

In general I am +1 on putting this to vote.

On Thu, Jul 31, 2014 at 6:22 AM, Rajani Karuturi
 wrote:
For the git flow:
1. We agreed to follow git-flow explained here 
http://nvie.com/posts/a-successful-git-branching-model/
2. This is the proposal for first cut
2a. rename 'master' to 'develop’
2b. branch a new 'master' from ‘4.4’ and update tags with release/4.4.0
2c. branch ‘release/4.5' from the develop
2d. merge ‘release/4.5' to master once the release voting is done.
3. This would be the flow for a hot fix
3a. branch off from the release tag on master. in this case it would be 
release/4.4.0
3b. commit the fixes in hotfix/4.4.1
3c. do the release
3d. merge to develop
3e. merge to master and update tags
3f. delete hot fix branch
4. for any LTS release create a support branch when required using git-flow 
support
4a. http://stackoverflow.com/a/16866118/201514

using the git-flow git extension available at https://github.com/nvie/gitflow 
can reduce the number of commands/errors

In addition:
1. Every commit should have unit tests
2. every feature/merge request should have unit and marvin integration tests
3. A commit should not have check style or find bugs issues
4. any coverity issues reported in the new code should be addressed immediately
5. every developer should run the BVT on the simulator before doing a checkin 
(https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator)
(This I am not very sure. May be we should let jenkins handle it and report 
integration failures if any?)
Please add/amend if I missed anything.

Can we call for a vote on this and freeze this without further delay?


~Rajani






--
Daan



Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab




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

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting

Review Request 24147: Fixed test cases in test_vpc_vm_life_cycle.py by passing expunge=True

[Gaurav Aradhye]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24147/
---

Review request for cloudstack and Girish Shilamkar.


Repository: cloudstack-git


Description
---

Fixed few test cases in test_vpc_vm_life_cycle.py by passing expunge flag while 
deleting VM and removed the code to wait for vm expungement.


Diffs
-

  test/integration/component/test_vpc_vm_life_cycle.py fd995cd 

Diff: https://reviews.apache.org/r/24147/diff/


Testing
---

Yes.


Thanks,

Gaurav Aradhye

Review Request 24148: Fixed key error in test_snapshots.py

[Gaurav Aradhye]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24148/
---

Review request for cloudstack and Girish Shilamkar.


Repository: cloudstack-git


Description
---

The hypervisor type was not converted to lower(), hence it was not matching 
with the existing key.


Diffs
-

  test/integration/component/test_snapshots.py f874bd3 

Diff: https://reviews.apache.org/r/24148/diff/


Testing
---

Yes.


Thanks,

Gaurav Aradhye

Re: [Summary] checkin process

[Rohit Yadav]

Hi Rajani,

On 31-Jul-2014, at 11:55 am, Rajani Karuturi  wrote:

> ahh… we have the same content twice on the wiki. I deleted the duplicate and 
> edited it as per the comment from daan.
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
>
> +1 for starting a vote thread

Thanks for fixing it, I think anyone can start the first voting thread. I think 
we’ll have iterations and we’ll know community’s take on the proposal.

So, please go ahead and start a voting/discussion thread since you’re the one 
who kickstarted the discussion around the git workflow initially.

Regards.

>
>
>
> ~Rajani
>
>
>
> On 31-Jul-2014, at 3:04 pm, Rohit Yadav 
> mailto:rohit.ya...@shapeblue.com>> wrote:
>
> Hi,
>
> Please use this section on the wiki to propose/fix/modify the new proposed 
> check-in process:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
>
> My feedback:
>
> - I don’t want to enforce/adopt the gitflow model "as-is", like not rename 
> master branch
>
> - the aim IMO is to make master stable for people to work with, so we don’t 
> break it often
> - we do feature/bug-fix/any-work in our own branch and 
> merge/cherry-pick/what-have-you when it has tests and it is stable (lazy 
> definition as per committer’s discretion)
>
> - the git commit cherry-picking/merging should be from firm/stable branches 
> to unstable i.e. from release branches (such as 4.x) to master or developer’s 
> own branch; the reverse is done only when the work/commits/check-ins are 
> tested/firm/stable
>
> We’ve so many threads with so many emails that we’re sort of causing 
> split-brain issue for ourselves on this issue.
>
> I’m not sure which one to follow now -- the length of a discussion thread is 
> inversely proportional to the interest of community members on the thread.
>
> Let’s start a new vote thread and drop discussion on other threads?
>
> On 31-Jul-2014, at 11:17 am, Sebastien Goasguen  wrote:
>
>
> On Jul 31, 2014, at 4:46 AM, Rajani Karuturi  
> wrote:
>
> to start using git-flow from 4.5+, we need to have the latest stable version 
> which can be master and I assumed that would be 4.4
> point 2. should be modified assuming no previous releases
> 2a. branch ‘develop’ from 'master’
> 2b. branch ‘release/4.5' from the develop
> 2c. merge ‘release/4.5' to master once the release voting is done.
>
> Are we waiting for Leo to put up a proposal?
>
> Anyone really :)
>
> Someone mentioned: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git
>
> You could add a section on 'gitflow' and basically dump your bullet list.
>
> Then we can edit it and call a vote .
>
>
>
> ~Rajani
>
>
>
> On 31-Jul-2014, at 1:09 pm, Daan Hoogland  wrote:
>
> I answerred this from my phone but it did't get through so here my
> comment again:
>
> We can't cut a new master from 4.4 without enormous work. I spend two
> days on getting 4.4 in line with 4.4-forward and as Leo has shown the
> work for getting all features from master into master will be much
> greater. So the proposal should be that we maintain 4.4 as traditional
> and start this work flow from 4.5+
>
> As for the additions you gave; these are reviewer guidelines for my
> part not requirements to a work flow.
>
> In general I am +1 on putting this to vote.
>
> On Thu, Jul 31, 2014 at 6:22 AM, Rajani Karuturi
>  wrote:
> For the git flow:
> 1. We agreed to follow git-flow explained here 
> http://nvie.com/posts/a-successful-git-branching-model/
> 2. This is the proposal for first cut
> 2a. rename 'master' to 'develop’
> 2b. branch a new 'master' from ‘4.4’ and update tags with release/4.4.0
> 2c. branch ‘release/4.5' from the develop
> 2d. merge ‘release/4.5' to master once the release voting is done.
> 3. This would be the flow for a hot fix
> 3a. branch off from the release tag on master. in this case it would be 
> release/4.4.0
> 3b. commit the fixes in hotfix/4.4.1
> 3c. do the release
> 3d. merge to develop
> 3e. merge to master and update tags
> 3f. delete hot fix branch
> 4. for any LTS release create a support branch when required using git-flow 
> support
> 4a. http://stackoverflow.com/a/16866118/201514
>
> using the git-flow git extension available at https://github.com/nvie/gitflow 
> can reduce the number of commands/errors
>
> In addition:
> 1. Every commit should have unit tests
> 2. every feature/merge request should have unit and marvin integration tests
> 3. A commit should not have check style or find bugs issues
> 4. any coverity issues reported in the new code should be addressed 
> immediately
> 5. every developer should run the BVT on the simulator before doing a checkin 
> (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator)
> (This I am not very sure. May be we should let jenki

[JENKINS] systemvm templates

[Hugo Trippaers]

Hey,

Citrix off-lined the node used to build systemvm templates a while ago. Today i 
managed to replace it with a new node so systemvm templates should start 
building again.

Cheers,

Hugo

Build failed in Jenkins: build-master-simulator #3

[jenkins]

See 

Changes:

[htrippaers] Fix dependency issue in apidoc, depends on server as that is where 
ApiXmlDocWriter lives

--
[...truncated 4854 lines...]
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ cloud-quickcloud ---
[INFO] Surefire report directory: 


---
 T E S T S
---

Results :

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

[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Test 4.5.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloud-testclient ---
[INFO] Deleting 
 
(includes = [**/*], excludes = [])
[INFO] Deleting 
 (includes = 
[target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-testclient ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-testclient ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-testclient ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
cloud-testclient ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-testclient ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-testclient ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ cloud-testclient ---
[INFO] Surefire report directory: 


---
 T E S T S
---

Results :

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

[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Developer Mode 4.5.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloud-developer ---
[INFO] Deleting 
 
(includes = [**/*], excludes = [])
[INFO] Deleting 
 
(includes = [target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-developer ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- properties-maven-plugin:1.0-alpha-2:read-project-properties 
(default) @ cloud-developer ---
[WARNING] Ignoring missing properties file: 

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-developer ---
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run (default) @ cloud-developer ---
[INFO] Executing tasks

main:
 [copy] Copying 78 files to 

 [copy] Copying 9 files to 

[INFO] Executed tasks
[INFO] 
[INFO] 

[JENKINS] Nodes maintenance

[Hugo Trippaers]

I’ve removed the following nodes because they have been offline for quite a 
while now:

build-hyperv
devcloud-continueos-tests
HyperV2
rpmbuilder

The remaining nodes can pickup most of the jobs, with the exception of all 
windows based jobs.

It anybody willing to host a windows slave for Jenkins so we can build our 
windows agent and CloudStack mdi packages?


Cheers,

Hugo

Re: [JENKINS] Nodes maintenance

[Erik Weber]

On Thu, Jul 31, 2014 at 12:18 PM, Hugo Trippaers  wrote:

> I’ve removed the following nodes because they have been offline for quite
> a while now:
>
> build-hyperv
> devcloud-continueos-tests
> HyperV2
> rpmbuilder
>
> The remaining nodes can pickup most of the jobs, with the exception of all
> windows based jobs.
>
> It anybody willing to host a windows slave for Jenkins so we can build our
> windows agent and CloudStack mdi packages?
>
>

Got any spec requirements for it? Would VM work or should it be bare metal?


-- 
Erik

[VOTE] git workflow

[Rajani Karuturi]

Hi All,

We had long discussions on the git flow.
I tried to capture the summary of it @ 
http://markmail.org/message/j5z7dxjcqxfkfhpj
This is updated on wiki @ 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
 and is up for a vote:

Can you share your opinion on the proposal?

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


Thanks,
~Rajani

Re: [JENKINS] Nodes maintenance

[Hugo Trippaers]

Erik,

I don’t have complete specs yet, but vm or bare metal doesn’t matter at all. So 
anything is good. On the box we need java, jenkins slave service, wix and i 
think visual studio.

This is the procedure we use to build the hyper agent, if the box can run this 
we are good to go:

— copy —
rmdir C:\jenkins\workspace\cloudstack-4.4-hyperv-agent\bin /s /q
rmdir 
C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\ServerResource\CloudStackAgentSetup\bin
 /s /q

cd C:\source\cloudstack
cat .git/config
git clean -fdx
git reset --hard HEAD
git checkout 4.4
git pull --rebase

cd C:\source\cloudstack\plugins\hypervisors\hyperv
C:\Users\Administrator\Downloads\dos2unix-6.0.3-win32-nls\bin\dos2unix.exe 
.\buildagent.sh
C:\cygwin64\bin\mintty --exec 
/cygdrive/c/source/cloudstack/plugins/hypervisors/hyperv/buildagent.sh

cd 
C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\ServerResource\AgentShell\bin

set PACKAGE_NAME=Cloudstack-4.4.0-%BUILD_NUMBER%-hypervagent

mkdir C:\jenkins\workspace\cloudstack-4.4-hyperv-agent\bin\%PACKAGE_NAME%

xcopy Debug C:\jenkins\workspace\cloudstack-4.4-hyperv-agent\bin\%PACKAGE_NAME%

sleep 20

c:\zip\D7Zip.exe -z 
"C:\Jenkins\workspace\cloudstack-4.4-hyperv-agent\bin\%PACKAGE_NAME%.zip" -f 
"C:\Jenkins\workspace\cloudstack-4.4-hyperv-agent\bin\%PACKAGE_NAME%\"
— end copy --

Cheers,

Hugo 


On 31 jul. 2014, at 12:25, Erik Weber  wrote:

> On Thu, Jul 31, 2014 at 12:18 PM, Hugo Trippaers  wrote:
> 
>> I’ve removed the following nodes because they have been offline for quite
>> a while now:
>> 
>> build-hyperv
>> devcloud-continueos-tests
>> HyperV2
>> rpmbuilder
>> 
>> The remaining nodes can pickup most of the jobs, with the exception of all
>> windows based jobs.
>> 
>> It anybody willing to host a windows slave for Jenkins so we can build our
>> windows agent and CloudStack mdi packages?
>> 
>> 
> 
> Got any spec requirements for it? Would VM work or should it be bare metal?
> 
> 
> -- 
> Erik

Build failed in Jenkins: build-master-simulator #5

[jenkins]

See 

Changes:

[santhosh.edukulla] Fixed a simple coverity issue

--
[...truncated 1263 lines...]
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
cloud-engine-components-api ---
[INFO] Compiling 31 source files to 

[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-engine-components-api ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-engine-components-api ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ 
cloud-engine-components-api ---
[INFO] Surefire report directory: 


---
 T E S T S
---

Results :

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

[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Server 4.5.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloud-server ---
[INFO] Deleting 
 
(includes = [**/*], excludes = [])
[INFO] Deleting 
 (includes 
= [target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-server ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ cloud-server 
---
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run (generate-resource) @ cloud-server ---
[INFO] Executing tasks

main:
 [copy] Copying 3 files to 

 [copy] Copying 1 file to 

[INFO] Executed tasks
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-server ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 30 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ cloud-server 
---
[INFO] Compiling 360 source files to 

[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-server ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 29 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-server ---
[INFO] Compiling 92 source files to 

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


---
 T E S T S
---
Running com.cloud.event.EventControlsUnitTest
log4j:WARN No appenders could be found for logger 
(com.cloud.event.EventControlsUnitTest).
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: 0.603 sec
Running com.cloud.keystore.KeystoreTest
org.apache.cloudstack.api.response.UserVmResponse/null/{"id":"3","securitygroup":[],"nic":[],"tags":[],"affinitygroup":[]}
org.apache.cloudstack.api.response.AlertResponse/null/{"id":"100","description":"Hello"}
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.15 sec
Running com.cloud.alert.AlertControlsUnitTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.051 sec
Running com.cloud.capacity.CapacityManagerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.177 sec
Running com.cloud.servlet.StaticResourceServletTest
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.154 sec
Running com.cloud.s

Jenkins build is back to normal : build-master-simulator #6

[jenkins]

See 

Re: [VOTE] git workflow

[Hugo Trippaers]

Rajani,

To make it clear for everyone. This is the vote to adopt this new way of 
working right? Or is it just to get an opinion on the proposal?

If it is indeed the vote to adopt this way of working it means that all 
committers will change how we interact with the branches in the CloudStack git. 
 

It’s is a good thing in my book, but we need to be clear what the expected 
result is when this vote has concluded in 72 hours. 

Cheers,

Hugo


On 31 jul. 2014, at 12:28, Rajani Karuturi  wrote:

> Hi All,
> 
> We had long discussions on the git flow.
> I tried to capture the summary of it @ 
> http://markmail.org/message/j5z7dxjcqxfkfhpj
> This is updated on wiki @ 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
>  and is up for a vote:
> 
> Can you share your opinion on the proposal?
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> 
> Thanks,
> ~Rajani
> 
> 
> 

Re: Simulator on master is not building

[Sebastien Goasguen]

On Jul 31, 2014, at 4:27 AM, Hugo Trippaers  wrote:

> Heya,
> 
> I’m setting up a separate build (build-master-simulator) to test the build 
> process of the simulator. At least we’ll be notified if any failures occur in 
> the build next time. I don’t think it should be included in the regular 
> build, it’s not something we would like to ship to end-users right?
> 

Actually, I would love a simulator package: cloudstack-simulator.



> Cheers,
> 
> Hugo
> 
> On 31 jul. 2014, at 06:54, Koushik Das  wrote:
> 
>> Simulator can be included in the default build but it needs to be tested 
>> whether simulator plugin can coexist with actual HV plugins in the same MS 
>> without any issues. Right now there is an issue which prevents it, refer to 
>> https://issues.apache.org/jira/browse/CLOUDSTACK-6623. Once this is fixed it 
>> needs to be tested again.
>> 
>> Also there needs to be a consensus to include it in default profile.
>> 
>> -Original Message-
>> From: Edison Su 
>> Sent: Wednesday, 30 July 2014 11:30 PM
>> To: dev@cloudstack.apache.org; Koushik Das
>> Subject: RE: Simulator on master is not building
>> 
>> +1, include simulator in the default build, exclude explicitly in the 
>> production build.
>> 
>>> -Original Message-
>>> From: Anthony Xu [mailto:xuefei...@citrix.com]
>>> Sent: Wednesday, July 30, 2014 10:28 AM
>>> To: Koushik Das; dev@cloudstack.apache.org
>>> Subject: RE: Simulator on master is not building
>>> 
>>> We used -Dsimulator to include simulator, it is very easy for 
>>> developers to forget it.  Simulator should be built by default , we 
>>> may use -Dnosimulator to exclude simulator.
>>> 
>>> 
>>> Anthony
>>> 
>>> -Original Message-
>>> From: Koushik Das
>>> Sent: Wednesday, July 30, 2014 3:03 AM
>>> To: dev@cloudstack.apache.org
>>> Cc: Anthony Xu
>>> Subject: RE: Simulator on master is not building
>>> 
>>> The simulator code should be kept up to date with any changes done in 
>>> the core product. If there are any interface changes, necessary 
>>> changes should be made in simulator plugin as well along with other 
>>> hypervisor plugins. To build simulator code use refer to [1].
>>> 
>>> -Koushik
>>> 
>>> [1]
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Simulator+integ
>>> r
>>> ation
>>> 
>>> -Original Message-
>>> From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com]
>>> Sent: Wednesday, 30 July 2014 3:27 PM
>>> To: dev@cloudstack.apache.org
>>> Cc: Anthony Xu
>>> Subject: Simulator on master is not building
>>> 
>>> I believe for every check-in we decided to run sanity tests on 
>>> simulator atleast, currently build for simulator is failing.
>>> 
>>> 
>>> --
>>> -- [ERROR] Failed to execute goal 
>>> org.apache.maven.plugins:maven-compiler-
>>> plugin:2.5.1:compile (default-compile) on project 
>>> cloud-plugin-hypervisor-
>>> simulator: Compilation failure: Compilation failure:
>>> [ERROR]
>>> /home/santhosh/softwares/cs_new_master/cloudstack/plugins/hypervisor
>>> s/simulator/src/com/cloud/resource/AgentRoutingResource.java:[230,8]
>>> error: 'try' without 'catch', 'finally' or resource declarations 
>>> [ERROR] 
>>> /home/santhosh/softwares/cs_new_master/cloudstack/plugins/hypervisor
>>> s/simulator/src/com/cloud/resource/AgentRoutingResource.java:[251,8]
>>> error: 'try' without 'catch', 'finally' or resource declarations
>>> 
>>> 
>>> Thanks!
>>> Santhosh
> 

Re: Simulator on master is not building

[Hugo Trippaers]

On 31 jul. 2014, at 12:44, Sebastien Goasguen  wrote:

> 
> On Jul 31, 2014, at 4:27 AM, Hugo Trippaers  wrote:
> 
>> Heya,
>> 
>> I’m setting up a separate build (build-master-simulator) to test the build 
>> process of the simulator. At least we’ll be notified if any failures occur 
>> in the build next time. I don’t think it should be included in the regular 
>> build, it’s not something we would like to ship to end-users right?
>> 
> 
> Actually, I would love a simulator package: cloudstack-simulator.

Thats less easy than it sounds. Shipping the simulator jar in an rpm is simple 
enough, but making it useable after installing the rpms requires database 
scripts to be run. But something to think about, it could be done.

> 
> 
> 
>> Cheers,
>> 
>> Hugo
>> 
>> On 31 jul. 2014, at 06:54, Koushik Das  wrote:
>> 
>>> Simulator can be included in the default build but it needs to be tested 
>>> whether simulator plugin can coexist with actual HV plugins in the same MS 
>>> without any issues. Right now there is an issue which prevents it, refer to 
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-6623. Once this is fixed 
>>> it needs to be tested again.
>>> 
>>> Also there needs to be a consensus to include it in default profile.
>>> 
>>> -Original Message-
>>> From: Edison Su 
>>> Sent: Wednesday, 30 July 2014 11:30 PM
>>> To: dev@cloudstack.apache.org; Koushik Das
>>> Subject: RE: Simulator on master is not building
>>> 
>>> +1, include simulator in the default build, exclude explicitly in the 
>>> production build.
>>> 
 -Original Message-
 From: Anthony Xu [mailto:xuefei...@citrix.com]
 Sent: Wednesday, July 30, 2014 10:28 AM
 To: Koushik Das; dev@cloudstack.apache.org
 Subject: RE: Simulator on master is not building
 
 We used -Dsimulator to include simulator, it is very easy for 
 developers to forget it.  Simulator should be built by default , we 
 may use -Dnosimulator to exclude simulator.
 
 
 Anthony
 
 -Original Message-
 From: Koushik Das
 Sent: Wednesday, July 30, 2014 3:03 AM
 To: dev@cloudstack.apache.org
 Cc: Anthony Xu
 Subject: RE: Simulator on master is not building
 
 The simulator code should be kept up to date with any changes done in 
 the core product. If there are any interface changes, necessary 
 changes should be made in simulator plugin as well along with other 
 hypervisor plugins. To build simulator code use refer to [1].
 
 -Koushik
 
 [1]
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Simulator+integ
 r
 ation
 
 -Original Message-
 From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com]
 Sent: Wednesday, 30 July 2014 3:27 PM
 To: dev@cloudstack.apache.org
 Cc: Anthony Xu
 Subject: Simulator on master is not building
 
 I believe for every check-in we decided to run sanity tests on 
 simulator atleast, currently build for simulator is failing.
 
 
 --
 -- [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-
 plugin:2.5.1:compile (default-compile) on project 
 cloud-plugin-hypervisor-
 simulator: Compilation failure: Compilation failure:
 [ERROR]
 /home/santhosh/softwares/cs_new_master/cloudstack/plugins/hypervisor
 s/simulator/src/com/cloud/resource/AgentRoutingResource.java:[230,8]
 error: 'try' without 'catch', 'finally' or resource declarations 
 [ERROR] 
 /home/santhosh/softwares/cs_new_master/cloudstack/plugins/hypervisor
 s/simulator/src/com/cloud/resource/AgentRoutingResource.java:[251,8]
 error: 'try' without 'catch', 'finally' or resource declarations
 
 
 Thanks!
 Santhosh
>> 
> 

Re: Review Request 23982: CLOUDSTACK-7192: Skip tests on Hyper-V which don't apply

[Santhosh Edukulla]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23982/#review49217
---



test/integration/smoke/test_nic.py


Instead of taking this check to inside the test case code, please move it 
to setup, that way atleast it is good that test code is independent upon these 
checks? 




test/integration/smoke/test_nic.py


Another issue is does the test case does not hold for hyperv or test case 
code is not applicable? If test case code only, then a different addition for 
hyperv is required?


- Santhosh Edukulla


On July 28, 2014, 2:17 p.m., John Dilley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23982/
> ---
> 
> (Updated July 28, 2014, 2:17 p.m.)
> 
> 
> Review request for cloudstack, sanjeev n and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-7192
> https://issues.apache.org/jira/browse/CLOUDSTACK-7192
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> A number of tests in the following files don't apply to Hyper-V. This patch 
> means they are skipped if an attempt is made to run them.
> 
> test_nic.py
> test_primary_storage.py 
> test_scale_vm.py
> test_snapshots.py
> test_vm_snapshots.py
> test_volumes.py(test7 and test8 only)
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_nic.py dd6de96 
>   test/integration/smoke/test_primary_storage.py 66aec59 
>   test/integration/smoke/test_scale_vm.py b5c89be 
>   test/integration/smoke/test_snapshots.py 8b6fdd1 
>   test/integration/smoke/test_vm_snapshots.py 01626f5 
>   test/integration/smoke/test_volumes.py 6e9ea75 
> 
> Diff: https://reviews.apache.org/r/23982/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> John Dilley
> 
>

Re: [VOTE] git workflow

[Daan Hoogland]

+1

On Thu, Jul 31, 2014 at 12:28 PM, Rajani Karuturi
 wrote:
> Hi All,
>
> We had long discussions on the git flow.
> I tried to capture the summary of it @ 
> http://markmail.org/message/j5z7dxjcqxfkfhpj
> This is updated on wiki @ 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
>  and is up for a vote:
>
> Can you share your opinion on the proposal?
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
>
> Thanks,
> ~Rajani
>
>
>



-- 
Daan

Re: [VOTE] git workflow

[Rohit Yadav]

+1

Hugo, I think we started this voting thread to get opinion on the proposal. I 
feel it may need some iteration and community agreement before we adopt it.

Suggestions, flames and opinions are welcome.

Regards.


On 31-Jul-2014, at 12:43 pm, Hugo Trippaers  wrote:

> Rajani,
>
> To make it clear for everyone. This is the vote to adopt this new way of 
> working right? Or is it just to get an opinion on the proposal?
>
> If it is indeed the vote to adopt this way of working it means that all 
> committers will change how we interact with the branches in the CloudStack 
> git.
>
> It’s is a good thing in my book, but we need to be clear what the expected 
> result is when this vote has concluded in 72 hours.
>
> Cheers,
>
> Hugo
>
>
> On 31 jul. 2014, at 12:28, Rajani Karuturi  wrote:
>
>> Hi All,
>>
>> We had long discussions on the git flow.
>> I tried to capture the summary of it @ 
>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>> This is updated on wiki @ 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
>>  and is up for a vote:
>>
>> Can you share your opinion on the proposal?
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>>
>> Thanks,
>> ~Rajani
>>
>>
>>
>

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab




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

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

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

Re: [VOTE] git workflow

[Rajani Karuturi]

Hi Hugo,

Its mainly to get an opinion on the proposal.
I am expecting all the active committers to take a look at it and raise any 
concerns they have.

If we don’t get any -1’s or edits, we should start on it.
Post voting, if its approved, we should do the required git branch changes as 
suggested in the proposal and all the new checkins are expected to follow the 
new commit flow for 4.5+.

if its not approved, we are either happy with the existing flow or we will have 
some good suggestions with which we may need to start a vote again.


~Rajani



On 31-Jul-2014, at 4:13 pm, Hugo Trippaers  wrote:

> Rajani,
> 
> To make it clear for everyone. This is the vote to adopt this new way of 
> working right? Or is it just to get an opinion on the proposal?
> 
> If it is indeed the vote to adopt this way of working it means that all 
> committers will change how we interact with the branches in the CloudStack 
> git.  
> 
> It’s is a good thing in my book, but we need to be clear what the expected 
> result is when this vote has concluded in 72 hours. 
> 
> Cheers,
> 
> Hugo
> 
> 
> On 31 jul. 2014, at 12:28, Rajani Karuturi  wrote:
> 
>> Hi All,
>> 
>> We had long discussions on the git flow.
>> I tried to capture the summary of it @ 
>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>> This is updated on wiki @ 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
>>  and is up for a vote:
>> 
>> Can you share your opinion on the proposal?
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> 
>> Thanks,
>> ~Rajani
>> 
>> 
>> 
> 

Review Request 24152: CLOUDSTACK-7182: NPE while trying to deploy VMs in parallel in isolated network

[Koushik Das]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24152/
---

Review request for cloudstack, Alena Prokharchyk and Sheng Yang.


Bugs: CLOUDSTACK-7182
https://issues.apache.org/jira/browse/CLOUDSTACK-7182


Repository: cloudstack-git


Description
---

- Check to see if network is implemented changed from 'state == 
Implementing||Implemented' to 'state == Implemented'. The earlier check was a 
hack to prevent the issue described next.
- At the time of implementing network (using implementNetwork() method), if the 
VR needs to be deployed then it follows the same path of regular VM deployment. 
This leads to a nested call to implementNetwork() while preparing VR nics. This 
flow creates issues in dealing with network state transitions. The original 
call puts network in "Implementing" state and then the nested call again tries 
to put it into same state resulting in issues. In order to avoid it, 
implementNetwork() call for VR is replaced with below code.


Diffs
-

  
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
 64a1f3a 

Diff: https://reviews.apache.org/r/24152/diff/


Testing
---

Ran isolated network tests using simulator.
Also ran the following VPC test using simulator:
1. created vpc, VR gets started as part of this
2. created network in the vpc
3. deployed vm in network created in step#2


Thanks,

Koushik Das

Re: [VOTE] git workflow

[Pierre-Luc Dion]

+1

PL


On Thu, Jul 31, 2014 at 7:40 AM, Rajani Karuturi  wrote:

> Hi Hugo,
>
> Its mainly to get an opinion on the proposal.
> I am expecting all the active committers to take a look at it and raise
> any concerns they have.
>
> If we don’t get any -1’s or edits, we should start on it.
> Post voting, if its approved, we should do the required git branch changes
> as suggested in the proposal and all the new checkins are expected to
> follow the new commit flow for 4.5+.
>
> if its not approved, we are either happy with the existing flow or we will
> have some good suggestions with which we may need to start a vote again.
>
>
> ~Rajani
>
>
>
> On 31-Jul-2014, at 4:13 pm, Hugo Trippaers  wrote:
>
> > Rajani,
> >
> > To make it clear for everyone. This is the vote to adopt this new way of
> working right? Or is it just to get an opinion on the proposal?
> >
> > If it is indeed the vote to adopt this way of working it means that all
> committers will change how we interact with the branches in the CloudStack
> git.
> >
> > It’s is a good thing in my book, but we need to be clear what the
> expected result is when this vote has concluded in 72 hours.
> >
> > Cheers,
> >
> > Hugo
> >
> >
> > On 31 jul. 2014, at 12:28, Rajani Karuturi 
> wrote:
> >
> >> Hi All,
> >>
> >> We had long discussions on the git flow.
> >> I tried to capture the summary of it @
> http://markmail.org/message/j5z7dxjcqxfkfhpj
> >> This is updated on wiki @
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
> and is up for a vote:
> >>
> >> Can you share your opinion on the proposal?
> >>
> >> [ ] +1  approve
> >> [ ] +0  no opinion
> >> [ ] -1  disapprove (and reason why)
> >>
> >>
> >> Thanks,
> >> ~Rajani
> >>
> >>
> >>
> >
>
>

Re: [VOTE] git workflow

[Leo Simons]

On Jul 31, 2014, at 12:28 PM, Rajani Karuturi  
wrote:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
...
> is up for a vote:

+1

- Leo

How to speed up testing using BVT/smoke tests with Simulator

[Rohit Yadav]

Hi,

Santosh put together a good wiki page on how to validate local changes using 
our Python/marvin based build verification tests (path: 
test/integration/smoke): 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator

I’ve a mini PC for this and using CloudStack 4.4.0 to build/test CloudStack 
4.4/master branch on it in a VM. Some of us are also exploring free/cheap CI 
services such as Travis, CloudBees etc. which can be used by developers to test 
their check-ins. If anyone of you have tried something like this please share.

This is how I build CloudStack for validating with simulator:
mvn -Pdeveloper -Dsimulator clean install
mvn -Pdeveloper -pl developer -Ddeploydb
mvn -Pdeveloper -pl developer -Ddeploydb-simulator
mvn -pl client jetty:run -Dsimulator

And finally run smoke tests (BVT):
nosetests --with-marvin --marvin-config=setup/dev/advanced.cfg --with-xunit 
--xunit-file=/tmp/bvt_selfservice_cases.xml -a 
tags=advanced,required_hardware=false -w test/integration/smoke 
--hypervisor=simulator

It currently took 50 mins on my setup. How can we speed it up, say by reducing 
global variable timeout settings etc? Should we reduce timeouts etc. in 
deploydb-simulator specific sql files?

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab




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

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack 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.

Build failed in Jenkins: build-master-simulator #14

[jenkins]

See 

--
[...truncated 1265 lines...]
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
cloud-engine-components-api ---
[INFO] Compiling 31 source files to 

[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-engine-components-api ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-engine-components-api ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ 
cloud-engine-components-api ---
[INFO] Surefire report directory: 


---
 T E S T S
---

Results :

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

[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Server 4.5.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloud-server ---
[INFO] Deleting 
 
(includes = [**/*], excludes = [])
[INFO] Deleting 
 (includes 
= [target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-server ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ cloud-server 
---
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run (generate-resource) @ cloud-server ---
[INFO] Executing tasks

main:
 [copy] Copying 3 files to 

 [copy] Copying 1 file to 

[INFO] Executed tasks
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-server ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 30 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ cloud-server 
---
[INFO] Compiling 360 source files to 

[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-server ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 29 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-server ---
[INFO] Compiling 92 source files to 

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


---
 T E S T S
---
Running com.cloud.event.EventControlsUnitTest
log4j:WARN No appenders could be found for logger 
(com.cloud.event.EventControlsUnitTest).
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: 0.664 sec
Running com.cloud.keystore.KeystoreTest
org.apache.cloudstack.api.response.UserVmResponse/null/{"id":"3","securitygroup":[],"nic":[],"tags":[],"affinitygroup":[]}
org.apache.cloudstack.api.response.AlertResponse/null/{"id":"100","description":"Hello"}
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.153 sec
Running com.cloud.alert.AlertControlsUnitTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.041 sec
Running com.cloud.capacity.CapacityManagerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.128 sec
Running com.cloud.servlet.StaticResourceServletTest
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.15 sec
Running com.cloud.servlet.ConsoleProxyServletTest
Tests run: 1, Failures: 0, Errors: 0

RE: [VOTE] git workflow

[Stephen Turner]

+1 from me.

-- 
Stephen Turner


-Original Message-
From: Rajani Karuturi [mailto:rajani.karut...@citrix.com] 
Sent: 31 July 2014 11:28
To: dev
Subject: [VOTE] git workflow

Hi All,

We had long discussions on the git flow.
I tried to capture the summary of it @ 
http://markmail.org/message/j5z7dxjcqxfkfhpj
This is updated on wiki @ 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
 and is up for a vote:

Can you share your opinion on the proposal?

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


Thanks,
~Rajani

Re: [VOTE] git workflow

[Hugo Trippaers]

+1 on the proposal

Cheers,

Hugo


On 31 jul. 2014, at 14:31, Stephen Turner  wrote:

> +1 from me.
> 
> -- 
> Stephen Turner
> 
> 
> -Original Message-
> From: Rajani Karuturi [mailto:rajani.karut...@citrix.com] 
> Sent: 31 July 2014 11:28
> To: dev
> Subject: [VOTE] git workflow
> 
> Hi All,
> 
> We had long discussions on the git flow.
> I tried to capture the summary of it @ 
> http://markmail.org/message/j5z7dxjcqxfkfhpj
> This is updated on wiki @ 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
>  and is up for a vote:
> 
> Can you share your opinion on the proposal?
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> 
> Thanks,
> ~Rajani
> 
> 
> 

Re: [JENKINS] Nodes maintenance

[Erik Weber]

Got it approved, so we can sponsor a machine.

1) is there a specific jenkins version needed or should i use the latest?
2) what firewall ports should be opened (ingress)?
3) does anyone know if the free visual studio version is enough?


Erik


On Thu, Jul 31, 2014 at 12:33 PM, Hugo Trippaers  wrote:

> Erik,
>
> I don’t have complete specs yet, but vm or bare metal doesn’t matter at
> all. So anything is good. On the box we need java, jenkins slave service,
> wix and i think visual studio.
>
> This is the procedure we use to build the hyper agent, if the box can run
> this we are good to go:
>
> — copy —
> rmdir C:\jenkins\workspace\cloudstack-4.4-hyperv-agent\bin /s /q
> rmdir
> C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\ServerResource\CloudStackAgentSetup\bin
> /s /q
>
> cd C:\source\cloudstack
> cat .git/config
> git clean -fdx
> git reset --hard HEAD
> git checkout 4.4
> git pull --rebase
>
> cd C:\source\cloudstack\plugins\hypervisors\hyperv
> C:\Users\Administrator\Downloads\dos2unix-6.0.3-win32-nls\bin\dos2unix.exe
> .\buildagent.sh
> C:\cygwin64\bin\mintty --exec
> /cygdrive/c/source/cloudstack/plugins/hypervisors/hyperv/buildagent.sh
>
> cd
> C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\ServerResource\AgentShell\bin
>
> set PACKAGE_NAME=Cloudstack-4.4.0-%BUILD_NUMBER%-hypervagent
>
> mkdir C:\jenkins\workspace\cloudstack-4.4-hyperv-agent\bin\%PACKAGE_NAME%
>
> xcopy Debug
> C:\jenkins\workspace\cloudstack-4.4-hyperv-agent\bin\%PACKAGE_NAME%
>
> sleep 20
>
> c:\zip\D7Zip.exe -z
> "C:\Jenkins\workspace\cloudstack-4.4-hyperv-agent\bin\%PACKAGE_NAME%.zip"
> -f "C:\Jenkins\workspace\cloudstack-4.4-hyperv-agent\bin\%PACKAGE_NAME%\"
> — end copy --
>
> Cheers,
>
> Hugo
>
>
> On 31 jul. 2014, at 12:25, Erik Weber  wrote:
>
> > On Thu, Jul 31, 2014 at 12:18 PM, Hugo Trippaers 
> wrote:
> >
> >> I’ve removed the following nodes because they have been offline for
> quite
> >> a while now:
> >>
> >> build-hyperv
> >> devcloud-continueos-tests
> >> HyperV2
> >> rpmbuilder
> >>
> >> The remaining nodes can pickup most of the jobs, with the exception of
> all
> >> windows based jobs.
> >>
> >> It anybody willing to host a windows slave for Jenkins so we can build
> our
> >> windows agent and CloudStack mdi packages?
> >>
> >>
> >
> > Got any spec requirements for it? Would VM work or should it be bare
> metal?
> >
> >
> > --
> > Erik
>
>

Re: [VOTE] git workflow

[Sebastien Goasguen]

+1

-sebastien

On Jul 31, 2014, at 8:37 AM, Hugo Trippaers  wrote:

> +1 on the proposal
> 
> Cheers,
> 
> Hugo
> 
> 
> On 31 jul. 2014, at 14:31, Stephen Turner  wrote:
> 
>> +1 from me.
>> 
>> -- 
>> Stephen Turner
>> 
>> 
>> -Original Message-
>> From: Rajani Karuturi [mailto:rajani.karut...@citrix.com] 
>> Sent: 31 July 2014 11:28
>> To: dev
>> Subject: [VOTE] git workflow
>> 
>> Hi All,
>> 
>> We had long discussions on the git flow.
>> I tried to capture the summary of it @ 
>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>> This is updated on wiki @ 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
>>  and is up for a vote:
>> 
>> Can you share your opinion on the proposal?
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> 
>> Thanks,
>> ~Rajani
>> 
>> 
>> 
> 

Review Request 24154: CLOUDSTACK-7215: Make expunge=True as default parameter value while calling destroyVirtualMachine through base library

[Gaurav Aradhye]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24154/
---

Review request for cloudstack and Santhosh Edukulla.


Bugs: CLOUDSTACK-7215
https://issues.apache.org/jira/browse/CLOUDSTACK-7215


Repository: cloudstack-git


Description
---

In almost 90% of the scenarios where VMs are created through test case, VMs are 
added to cleanup list and the delete method is called for them through 
cleanup_resources method in utils.py file.

These VMs remain in destroyed state for long time and keep blocking the 
resources (IP Address etc) and hence the load on the setup on which regression 
build is fired increases.

Making expunge=True as default parameter in destroyVirtualMachine api call 
through base library will make all these VMs expunge quickly making resources 
available for next test cases.

Also, it can be passed as False whenever we don't want VM to expunge 
immediately, and in case when we recover the VM through test case after 
destroying it. Pass expunge=False for all such scenarios.

This will hugely boost the test cases execution speed too.


Diffs
-

  test/integration/component/test_advancedsg_networks.py 2794f96 
  test/integration/component/test_multiple_ips_per_nic.py 24b85df 
  test/integration/component/test_ps_domain_limits.py afb0955 
  test/integration/component/test_ps_limits.py 1993e93 
  test/integration/component/test_vpc_vm_life_cycle.py fd995cd 
  tools/marvin/marvin/lib/base.py 58033c6 

Diff: https://reviews.apache.org/r/24154/diff/


Testing
---

Yes.


Thanks,

Gaurav Aradhye

Re: [VOTE] git workflow

[Mike Tutkowski]

+1

On Thursday, July 31, 2014, Hugo Trippaers  wrote:

> +1 on the proposal
>
> Cheers,
>
> Hugo
>
>
> On 31 jul. 2014, at 14:31, Stephen Turner  > wrote:
>
> > +1 from me.
> >
> > --
> > Stephen Turner
> >
> >
> > -Original Message-
> > From: Rajani Karuturi [mailto:rajani.karut...@citrix.com ]
> > Sent: 31 July 2014 11:28
> > To: dev
> > Subject: [VOTE] git workflow
> >
> > Hi All,
> >
> > We had long discussions on the git flow.
> > I tried to capture the summary of it @
> http://markmail.org/message/j5z7dxjcqxfkfhpj
> > This is updated on wiki @
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
> and is up for a vote:
> >
> > Can you share your opinion on the proposal?
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> >
> > Thanks,
> > ~Rajani
> >
> >
> >
>
>

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

Re: [JENKINS] Nodes maintenance

[Erik Weber]

To answer myself, it's all taken care of


Erik


On Thu, Jul 31, 2014 at 3:21 PM, Erik Weber  wrote:

> Got it approved, so we can sponsor a machine.
>
> 1) is there a specific jenkins version needed or should i use the latest?
> 2) what firewall ports should be opened (ingress)?
> 3) does anyone know if the free visual studio version is enough?
>
>
> Erik
>
>
> On Thu, Jul 31, 2014 at 12:33 PM, Hugo Trippaers 
> wrote:
>
>> Erik,
>>
>> I don’t have complete specs yet, but vm or bare metal doesn’t matter at
>> all. So anything is good. On the box we need java, jenkins slave service,
>> wix and i think visual studio.
>>
>> This is the procedure we use to build the hyper agent, if the box can run
>> this we are good to go:
>>
>> — copy —
>> rmdir C:\jenkins\workspace\cloudstack-4.4-hyperv-agent\bin /s /q
>> rmdir
>> C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\ServerResource\CloudStackAgentSetup\bin
>> /s /q
>>
>> cd C:\source\cloudstack
>> cat .git/config
>> git clean -fdx
>> git reset --hard HEAD
>> git checkout 4.4
>> git pull --rebase
>>
>> cd C:\source\cloudstack\plugins\hypervisors\hyperv
>> C:\Users\Administrator\Downloads\dos2unix-6.0.3-win32-nls\bin\dos2unix.exe
>> .\buildagent.sh
>> C:\cygwin64\bin\mintty --exec
>> /cygdrive/c/source/cloudstack/plugins/hypervisors/hyperv/buildagent.sh
>>
>> cd
>> C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\ServerResource\AgentShell\bin
>>
>> set PACKAGE_NAME=Cloudstack-4.4.0-%BUILD_NUMBER%-hypervagent
>>
>> mkdir C:\jenkins\workspace\cloudstack-4.4-hyperv-agent\bin\%PACKAGE_NAME%
>>
>> xcopy Debug
>> C:\jenkins\workspace\cloudstack-4.4-hyperv-agent\bin\%PACKAGE_NAME%
>>
>> sleep 20
>>
>> c:\zip\D7Zip.exe -z
>> "C:\Jenkins\workspace\cloudstack-4.4-hyperv-agent\bin\%PACKAGE_NAME%.zip"
>> -f "C:\Jenkins\workspace\cloudstack-4.4-hyperv-agent\bin\%PACKAGE_NAME%\"
>> — end copy --
>>
>> Cheers,
>>
>> Hugo
>>
>>
>> On 31 jul. 2014, at 12:25, Erik Weber  wrote:
>>
>> > On Thu, Jul 31, 2014 at 12:18 PM, Hugo Trippaers 
>> wrote:
>> >
>> >> I’ve removed the following nodes because they have been offline for
>> quite
>> >> a while now:
>> >>
>> >> build-hyperv
>> >> devcloud-continueos-tests
>> >> HyperV2
>> >> rpmbuilder
>> >>
>> >> The remaining nodes can pickup most of the jobs, with the exception of
>> all
>> >> windows based jobs.
>> >>
>> >> It anybody willing to host a windows slave for Jenkins so we can build
>> our
>> >> windows agent and CloudStack mdi packages?
>> >>
>> >>
>> >
>> > Got any spec requirements for it? Would VM work or should it be bare
>> metal?
>> >
>> >
>> > --
>> > Erik
>>
>>
>

Re: [ACS44][BUG] SystemVM not working on 4.4

[Antone Heyward]

I have an environment that i upgraded to 4.4 before seeing this where my
system vms will not start. Is there a procedure to upgrade the system vm
templates after the fact? mostly all of the current instances are still
working but users can't create new instances.


On Wed, Jul 30, 2014 at 5:42 AM, Erik Weber  wrote:

> This is work in progress for a guide to fixing broken system vm's, but
> please note that this currently has seen limited testing yet, so take any
> precautions you can.
> https://gist.github.com/terbolous/102ae8edd1cda192561c
>
>
> The best thing you can do before upgrading is to download the new system vm
> template, that way you won't have to mess around inside the old one. You
> would still have to change some database values, but that's far less work.
>
> Erik
>
> On Wed, Jul 30, 2014 at 11:27 AM, Andrei Mikhailovsky 
> wrote:
>
> > Hello guys,
> >
> > I am planning to upgrade my ACS from version 4.2.1 to version 4.4 this
> > weekend. Following the last disastrous upgrade from 4.2.1 to 4.3.0, which
> > also related to the system vm issues, I would like to verify the required
> > steps to have a _working_ ACS following upgrade to 4.4? Reading this
> thread
> > it seems that the documentation is wrong/misleading and that people are
> > having issues with system vms.
> >
> > Could some one post a working set of instructions to fix the system vm
> > issue that people are having?
> >
> > Thanks
> >
> > Andrei
> >
> >
> >
> > - Original Message -
> >
> > From: "Erik Weber" 
> > To: "dev" 
> > Sent: Tuesday, 29 July, 2014 8:08:21 PM
> > Subject: Re: [ACS44][BUG] SystemVM not working on 4.4
> >
> > Frankly I don't know, I didn't focus much on the management server logs.
> >
> > It's easy to check if you're affected by checking the
> > /var/log/cloud/cloud.out on either the ssvm or cpvm for the version
> error.
> >
> > Erik
> >
> >
> > On Tue, Jul 29, 2014 at 8:34 PM, Tanner Danzey 
> wrote:
> >
> > > Is the behavior you are describing here followed by a
> > > "com.cloud.exception.AgentUnavailableException: Resource [Host:13] is
> > > unreachable: Host 13: Unable to start instance due to Unable to get
> > answer
> > > that is of class com.cloud.agent.api.StartAnswer"? We upgraded from 4.3
> > and
> > > found this fun little nugget. Would you be able to advise how to do a
> > > manual MySQL template upgrade with 4.4 templates?
> > >
> > >
> > > On Tue, Jul 29, 2014 at 9:05 AM, Erik Weber 
> wrote:
> > >
> > > > Changing subject as it's not only KVM related.
> > > >
> > > > Am I the only one concerned about the fact that potentially every
> ACS44
> > > > installation, if installed according to doc, is broken?
> > > >
> > > > The last day there's been atleast three people on IRC with similar
> > > symptoms
> > > > (system vms not working), one reverted to 4.3 before I could get
> > him/her
> > > to
> > > > verify it to be the same problem, but two confirmed the java error.
> > > >
> > > > The last one on irc to confirm the issue was an upgrade btw, so it's
> > not
> > > > only new installations that has the issue.
> > > >
> > > > Manually updating java on the ssvm and cpvm is a temporarily fix, but
> > > not a
> > > > good one in the long run.
> > > >
> > > > Downloading the latest 4.4 template from jenkins and updating MySQL
> > > > manually seems to give good working system vms as far as I have
> tested.
> > > >
> > > >
> > > >
> > > > Erik
> > > >
> > > > On Tue, Jul 29, 2014 at 11:53 AM, Daan Hoogland <
> > daan.hoogl...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > given the move from java6 to j7; all
> > > > >
> > > > > On Tue, Jul 29, 2014 at 11:49 AM, Erik Weber 
> > > > wrote:
> > > > > > On Tue, Jul 29, 2014 at 11:41 AM, Wido den Hollander <
> > w...@widodh.nl
> > > >
> > > > > wrote:
> > > > > >
> > > > > >>
> > > > > >>
> > > > > >> On 07/29/2014 02:44 AM, Erik Weber wrote:
> > > > > >>
> > > > > >>> Tried helping Soeren Malchow on irc today, with a new ACS44
> > > > > installation.
> > > > > >>>
> > > > > >>> The docs referenced ACS43 system templates from January, but
> even
> > > by
> > > > > using
> > > > > >>> the late June ones that got uploaded after the heartbleed
> > incident
> > > it
> > > > > >>> still
> > > > > >>> does not work.
> > > > > >>>
> > > > > >>>
> > > > > >> Have you tried the 4.4 templates found here:
> > > > > http://cloudstack.apt-get.eu/
> > > > > >> systemvm/4.4/
> > > > > >>
> > > > > >>
> > > > > >
> > > > > > Not yet, as of the moment I'm more curious of which of our
> > documentet
> > > > > > systemvm templates that needs to be changed.
> > > > > >
> > > > > >
> > > > > > Erik
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Daan
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > *Tanner Danzey*
> > > Systems Engineer
> > > Northstar Technology Group
> > > arkan...@gmail.com / tanner.dan...@northstar-tg.com
> > > (701) 237-9096 x7122
> > >
> >
> >
>



-- 
Antone
@thehyperadvisor
http://thehyperadvisor.com

Re: [VOTE] git workflow

[Will Stevens]

+1

Something that may need to be adjusted...

If two different people are working on different hotfixes for 4.4, lets say
they are for bugs CS-1234 and CS-5678, then in the current model they would
both push their hotfix to 'hotfix/4.4.1'.  This will cause branch naming
collisions which could be hard to work around.  I think we may want to
adopt a hotfix branch name that reflects the bug the hotfix is related to.
 So for the above example, the hotfix branches could be named something
like 'hotfix/4.4.1-cs-1234' and 'hotfix/4.4.1-cs-5678'.  I don't think that
two different committers work should go into the same 'hotfix/4.4.1' branch
to be committed.  I think that will cause way too many issues...

ws


*Will STEVENS*
Lead Developer

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


On Thu, Jul 31, 2014 at 11:03 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> +1
>
> On Thursday, July 31, 2014, Hugo Trippaers  wrote:
>
> > +1 on the proposal
> >
> > Cheers,
> >
> > Hugo
> >
> >
> > On 31 jul. 2014, at 14:31, Stephen Turner  > > wrote:
> >
> > > +1 from me.
> > >
> > > --
> > > Stephen Turner
> > >
> > >
> > > -Original Message-
> > > From: Rajani Karuturi [mailto:rajani.karut...@citrix.com
> ]
> > > Sent: 31 July 2014 11:28
> > > To: dev
> > > Subject: [VOTE] git workflow
> > >
> > > Hi All,
> > >
> > > We had long discussions on the git flow.
> > > I tried to capture the summary of it @
> > http://markmail.org/message/j5z7dxjcqxfkfhpj
> > > This is updated on wiki @
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
> > and is up for a vote:
> > >
> > > Can you share your opinion on the proposal?
> > >
> > > [ ] +1  approve
> > > [ ] +0  no opinion
> > > [ ] -1  disapprove (and reason why)
> > >
> > >
> > > Thanks,
> > > ~Rajani
> > >
> > >
> > >
> >
> >
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*
>

Re: [ACS44][BUG] SystemVM not working on 4.4

[Todd Pigram]

normally, you would add the as systemvm4.4 from the UI prior to upgrade
using the link to the new systemvm corresponding to your hypervisor. Then
perform the upgrade on MS. Once back in the UI, the vRouters will have an
upgrade feature. For Console and SSVM, delete and recreate


On Thu, Jul 31, 2014 at 11:18 AM, Antone Heyward 
wrote:

> I have an environment that i upgraded to 4.4 before seeing this where my
> system vms will not start. Is there a procedure to upgrade the system vm
> templates after the fact? mostly all of the current instances are still
> working but users can't create new instances.
>
>
> On Wed, Jul 30, 2014 at 5:42 AM, Erik Weber  wrote:
>
> > This is work in progress for a guide to fixing broken system vm's, but
> > please note that this currently has seen limited testing yet, so take any
> > precautions you can.
> > https://gist.github.com/terbolous/102ae8edd1cda192561c
> >
> >
> > The best thing you can do before upgrading is to download the new system
> vm
> > template, that way you won't have to mess around inside the old one. You
> > would still have to change some database values, but that's far less
> work.
> >
> > Erik
> >
> > On Wed, Jul 30, 2014 at 11:27 AM, Andrei Mikhailovsky  >
> > wrote:
> >
> > > Hello guys,
> > >
> > > I am planning to upgrade my ACS from version 4.2.1 to version 4.4 this
> > > weekend. Following the last disastrous upgrade from 4.2.1 to 4.3.0,
> which
> > > also related to the system vm issues, I would like to verify the
> required
> > > steps to have a _working_ ACS following upgrade to 4.4? Reading this
> > thread
> > > it seems that the documentation is wrong/misleading and that people are
> > > having issues with system vms.
> > >
> > > Could some one post a working set of instructions to fix the system vm
> > > issue that people are having?
> > >
> > > Thanks
> > >
> > > Andrei
> > >
> > >
> > >
> > > - Original Message -
> > >
> > > From: "Erik Weber" 
> > > To: "dev" 
> > > Sent: Tuesday, 29 July, 2014 8:08:21 PM
> > > Subject: Re: [ACS44][BUG] SystemVM not working on 4.4
> > >
> > > Frankly I don't know, I didn't focus much on the management server
> logs.
> > >
> > > It's easy to check if you're affected by checking the
> > > /var/log/cloud/cloud.out on either the ssvm or cpvm for the version
> > error.
> > >
> > > Erik
> > >
> > >
> > > On Tue, Jul 29, 2014 at 8:34 PM, Tanner Danzey 
> > wrote:
> > >
> > > > Is the behavior you are describing here followed by a
> > > > "com.cloud.exception.AgentUnavailableException: Resource [Host:13] is
> > > > unreachable: Host 13: Unable to start instance due to Unable to get
> > > answer
> > > > that is of class com.cloud.agent.api.StartAnswer"? We upgraded from
> 4.3
> > > and
> > > > found this fun little nugget. Would you be able to advise how to do a
> > > > manual MySQL template upgrade with 4.4 templates?
> > > >
> > > >
> > > > On Tue, Jul 29, 2014 at 9:05 AM, Erik Weber 
> > wrote:
> > > >
> > > > > Changing subject as it's not only KVM related.
> > > > >
> > > > > Am I the only one concerned about the fact that potentially every
> > ACS44
> > > > > installation, if installed according to doc, is broken?
> > > > >
> > > > > The last day there's been atleast three people on IRC with similar
> > > > symptoms
> > > > > (system vms not working), one reverted to 4.3 before I could get
> > > him/her
> > > > to
> > > > > verify it to be the same problem, but two confirmed the java error.
> > > > >
> > > > > The last one on irc to confirm the issue was an upgrade btw, so
> it's
> > > not
> > > > > only new installations that has the issue.
> > > > >
> > > > > Manually updating java on the ssvm and cpvm is a temporarily fix,
> but
> > > > not a
> > > > > good one in the long run.
> > > > >
> > > > > Downloading the latest 4.4 template from jenkins and updating MySQL
> > > > > manually seems to give good working system vms as far as I have
> > tested.
> > > > >
> > > > >
> > > > >
> > > > > Erik
> > > > >
> > > > > On Tue, Jul 29, 2014 at 11:53 AM, Daan Hoogland <
> > > daan.hoogl...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > given the move from java6 to j7; all
> > > > > >
> > > > > > On Tue, Jul 29, 2014 at 11:49 AM, Erik Weber <
> terbol...@gmail.com>
> > > > > wrote:
> > > > > > > On Tue, Jul 29, 2014 at 11:41 AM, Wido den Hollander <
> > > w...@widodh.nl
> > > > >
> > > > > > wrote:
> > > > > > >
> > > > > > >>
> > > > > > >>
> > > > > > >> On 07/29/2014 02:44 AM, Erik Weber wrote:
> > > > > > >>
> > > > > > >>> Tried helping Soeren Malchow on irc today, with a new ACS44
> > > > > > installation.
> > > > > > >>>
> > > > > > >>> The docs referenced ACS43 system templates from January, but
> > even
> > > > by
> > > > > > using
> > > > > > >>> the late June ones that got uploaded after the heartbleed
> > > incident
> > > > it
> > > > > > >>> still
> > > > > > >>> does not work.
> > > > > > >>>
> > > > > > >>>
> > > > > > >> Have you tried the 4.4 templates found here:
> > > 

Jenkins build is back to normal : build-master-simulator #15

[jenkins]

See 

Re: [JENKINS] Nodes maintenance

[Hugo Trippaers]

Much obliged Erik!

Cheers,

Hugo

On 31 jul. 2014, at 17:17, Erik Weber  wrote:

> To answer myself, it's all taken care of
> 
> 
> Erik
> 
> 
> On Thu, Jul 31, 2014 at 3:21 PM, Erik Weber  wrote:
> 
>> Got it approved, so we can sponsor a machine.
>> 
>> 1) is there a specific jenkins version needed or should i use the latest?
>> 2) what firewall ports should be opened (ingress)?
>> 3) does anyone know if the free visual studio version is enough?
>> 
>> 
>> Erik
>> 
>> 
>> On Thu, Jul 31, 2014 at 12:33 PM, Hugo Trippaers 
>> wrote:
>> 
>>> Erik,
>>> 
>>> I don’t have complete specs yet, but vm or bare metal doesn’t matter at
>>> all. So anything is good. On the box we need java, jenkins slave service,
>>> wix and i think visual studio.
>>> 
>>> This is the procedure we use to build the hyper agent, if the box can run
>>> this we are good to go:
>>> 
>>> — copy —
>>> rmdir C:\jenkins\workspace\cloudstack-4.4-hyperv-agent\bin /s /q
>>> rmdir
>>> C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\ServerResource\CloudStackAgentSetup\bin
>>> /s /q
>>> 
>>> cd C:\source\cloudstack
>>> cat .git/config
>>> git clean -fdx
>>> git reset --hard HEAD
>>> git checkout 4.4
>>> git pull --rebase
>>> 
>>> cd C:\source\cloudstack\plugins\hypervisors\hyperv
>>> C:\Users\Administrator\Downloads\dos2unix-6.0.3-win32-nls\bin\dos2unix.exe
>>> .\buildagent.sh
>>> C:\cygwin64\bin\mintty --exec
>>> /cygdrive/c/source/cloudstack/plugins/hypervisors/hyperv/buildagent.sh
>>> 
>>> cd
>>> C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\ServerResource\AgentShell\bin
>>> 
>>> set PACKAGE_NAME=Cloudstack-4.4.0-%BUILD_NUMBER%-hypervagent
>>> 
>>> mkdir C:\jenkins\workspace\cloudstack-4.4-hyperv-agent\bin\%PACKAGE_NAME%
>>> 
>>> xcopy Debug
>>> C:\jenkins\workspace\cloudstack-4.4-hyperv-agent\bin\%PACKAGE_NAME%
>>> 
>>> sleep 20
>>> 
>>> c:\zip\D7Zip.exe -z
>>> "C:\Jenkins\workspace\cloudstack-4.4-hyperv-agent\bin\%PACKAGE_NAME%.zip"
>>> -f "C:\Jenkins\workspace\cloudstack-4.4-hyperv-agent\bin\%PACKAGE_NAME%\"
>>> — end copy --
>>> 
>>> Cheers,
>>> 
>>> Hugo
>>> 
>>> 
>>> On 31 jul. 2014, at 12:25, Erik Weber  wrote:
>>> 
 On Thu, Jul 31, 2014 at 12:18 PM, Hugo Trippaers 
>>> wrote:
 
> I’ve removed the following nodes because they have been offline for
>>> quite
> a while now:
> 
> build-hyperv
> devcloud-continueos-tests
> HyperV2
> rpmbuilder
> 
> The remaining nodes can pickup most of the jobs, with the exception of
>>> all
> windows based jobs.
> 
> It anybody willing to host a windows slave for Jenkins so we can build
>>> our
> windows agent and CloudStack mdi packages?
> 
> 
 
 Got any spec requirements for it? Would VM work or should it be bare
>>> metal?
 
 
 --
 Erik
>>> 
>>> 
>> 

Re: [VOTE] git workflow

[Olivier Lemasle]

+1 on the proposal.

Regards,

--
Olivier Lemasle
Apalia

On Thu, Jul 31, 2014 at 5:22 PM, Will Stevens  wrote:

> +1
>
> Something that may need to be adjusted...
>
> If two different people are working on different hotfixes for 4.4, lets say
> they are for bugs CS-1234 and CS-5678, then in the current model they would
> both push their hotfix to 'hotfix/4.4.1'.  This will cause branch naming
> collisions which could be hard to work around.  I think we may want to
> adopt a hotfix branch name that reflects the bug the hotfix is related to.
>  So for the above example, the hotfix branches could be named something
> like 'hotfix/4.4.1-cs-1234' and 'hotfix/4.4.1-cs-5678'.  I don't think that
> two different committers work should go into the same 'hotfix/4.4.1' branch
> to be committed.  I think that will cause way too many issues...
>
> ws
>
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
>
> On Thu, Jul 31, 2014 at 11:03 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > +1
> >
> > On Thursday, July 31, 2014, Hugo Trippaers  wrote:
> >
> > > +1 on the proposal
> > >
> > > Cheers,
> > >
> > > Hugo
> > >
> > >
> > > On 31 jul. 2014, at 14:31, Stephen Turner  > > > wrote:
> > >
> > > > +1 from me.
> > > >
> > > > --
> > > > Stephen Turner
> > > >
> > > >
> > > > -Original Message-
> > > > From: Rajani Karuturi [mailto:rajani.karut...@citrix.com
> > ]
> > > > Sent: 31 July 2014 11:28
> > > > To: dev
> > > > Subject: [VOTE] git workflow
> > > >
> > > > Hi All,
> > > >
> > > > We had long discussions on the git flow.
> > > > I tried to capture the summary of it @
> > > http://markmail.org/message/j5z7dxjcqxfkfhpj
> > > > This is updated on wiki @
> > >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
> > > and is up for a vote:
> > > >
> > > > Can you share your opinion on the proposal?
> > > >
> > > > [ ] +1  approve
> > > > [ ] +0  no opinion
> > > > [ ] -1  disapprove (and reason why)
> > > >
> > > >
> > > > Thanks,
> > > > ~Rajani
> > > >
> > > >
> > > >
> > >
> > >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > *™*
> >
>



-- 
Olivier Lemasle
Ingénieur Logiciel
*Apalia*™
Mobile: +33-611-69-12-11

*http://www.apalia.net 
olivier.lema...@apalia.net
*

Building of Hyper-V Agent seems broken in 4.4 branch

[Erik Weber]

4.4.0 tag is working correctly, as is master branch.

Any fix or advice appreciated.


Erik

-- compile output 

 Target CoreCompile:
Tool C:\PROGRA~2\MONO-3~1.3\bin\mcs.bat
execution started with arguments: /noconfig /debug:full /debug+ /optimize-
/out:obj\Debug\HypervResource.dll CloudStackTypes.cs IWmiCallsV2.cs
WmiCallsV2.cs Properties\AssemblyInfo.cs HypervResourceController.cs
Utils.cs /target:library /define:"DEBUG;TRACE"
/reference:..\packages\AWSSDK.1.5.23.0\lib\AWSSDK.dll
/reference:..\packages\DotNetZip.1.9.1.8\lib\net20\Ionic.Zip.dll
/reference:..\packages\log4net.2.0.0\lib\net40-full\log4net.dll
/reference:..\packages\Newtonsoft.Json.4.5.11\lib\net40\Newtonsoft.Json.dll
/reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.dll
/reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Configuration.dll
/reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Management.dll
/reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Net.Http.dll
/reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Web.dll
/reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Web.Http.dll
/reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Xml.Linq.dll
/reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Data.DataSetExtensions.dll
/reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\Microsoft.CSharp.dll
/reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Data.dll
/reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Xml.dll
/reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Core.dll
/reference:C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\ServerResource\WmiWrappers\bin\Debug\\WmiWrappers.dll
/warn:4
WmiCallsV2.cs(336,27): error CS0117: `HypervResource.Utils' does not
contain a definition for `ConnectToRemote'
Utils.cs(32,18): (Location of the symbol
related to previous error)
WmiCallsV2.cs(2448,69): error CS0103: The name `jobObj' does not exist in
the current context
HypervResourceController.cs(239,31): error CS0117: `HypervResource.Utils'
does not contain a definition for `ConnectToRemote'
Utils.cs(32,18): (Location of the symbol
related to previous error)
HypervResourceController.cs(250,35): error CS0117: `HypervResource.Utils'
does not contain a definition for `ConnectToRemote'
Utils.cs(32,18): (Location of the symbol
related to previous error)
HypervResourceController.cs(992,27): error CS0117: `HypervResource.Utils'
does not contain a definition for `ConnectToRemote'
Utils.cs(32,18): (Location of the symbol
related to previous error)
HypervResourceController.cs(1284,31): error CS0117: `HypervResource.Utils'
does not contain a definition for `ConnectToRemote'
Utils.cs(32,18): (Location of the symbol
related to previous error)
HypervResourceController.cs(1560,39): error CS0117: `HypervResource.Utils'
does not contain a definition for `ConnectToRemote'
Utils.cs(32,18): (Location of the symbol
related to previous error)
HypervResourceController.cs(1567,35): error CS0117: `HypervResource.Utils'
does not contain a definition for `ConnectToRemote'
Utils.cs(32,18): (Location of the symbol
related to previous error)
Task "Csc" execution -- FAILED
Done building target "CoreCompile" in project
"C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\ServerResource\HypervResource\HypervResource.csproj".--
FAILED
Done building project
"C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\ServerResource\HypervResource\HypervResource.csproj".--
FAILED
Task "MSBuild" execution -- FAILED
Done building target "Build" in project
"C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\ServerResource\ServerResource.sln".--
FAILED
Done building project
"C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\ServerResource\ServerResource.sln".--
FAILED

Build FAILED.
Errors:

C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\ServerResource\ServerResource.sln
(default t

Warning on gpg verify on apache cloudstack 4.4

[benoit lair]

Hello,

I am building acs 4.4, but when i verify the gpg keys, here is the warnign
that i got :

gpg --verify apache-cloudstack-4.4.0-src.tar.bz2.asc
gpg: Signature faite le mer. 16 juil. 2014 14:09:59 CEST avec la cl? RSA ID
AA4736F3
gpg: Bonne signature de ? Daan Hoogland  ?
gpg: ATTENTION: Cette cl? n'est pas certifi?e avec une signature de
confiance !
gpg:Rien ne dit que la signature appartient ? son propri?taire.
Empreinte de cl? principale: 043E 4236 C0B7 CA8C C31E  0381 F9E4 0C89 AA47
36F3


Perhaps a problem with the KEYS ?

Thanks a lot.

Regards, Benoit.

Re: Warning on gpg verify on apache cloudstack 4.4

[benoit lair]

But with the md5 way, no problem this looks good.


2014-07-31 17:49 GMT+02:00 benoit lair :

> Hello,
>
> I am building acs 4.4, but when i verify the gpg keys, here is the warnign
> that i got :
>
> gpg --verify apache-cloudstack-4.4.0-src.tar.bz2.asc
> gpg: Signature faite le mer. 16 juil. 2014 14:09:59 CEST avec la cl? RSA
> ID AA4736F3
> gpg: Bonne signature de ? Daan Hoogland  ?
> gpg: ATTENTION: Cette cl? n'est pas certifi?e avec une signature de
> confiance !
> gpg:Rien ne dit que la signature appartient ? son propri?taire.
> Empreinte de cl? principale: 043E 4236 C0B7 CA8C C31E  0381 F9E4 0C89 AA47
> 36F3
>
>
> Perhaps a problem with the KEYS ?
>
> Thanks a lot.
>
> Regards, Benoit.
>

Re: Warning on gpg verify on apache cloudstack 4.4

[Sebastien Goasguen]

On Jul 31, 2014, at 11:51 AM, benoit lair  wrote:

> But with the md5 way, no problem this looks good.
> 

It is just that Daan's key has not been signed by anybody else yet.

> 
> 2014-07-31 17:49 GMT+02:00 benoit lair :
> 
>> Hello,
>> 
>> I am building acs 4.4, but when i verify the gpg keys, here is the warnign
>> that i got :
>> 
>> gpg --verify apache-cloudstack-4.4.0-src.tar.bz2.asc
>> gpg: Signature faite le mer. 16 juil. 2014 14:09:59 CEST avec la cl? RSA
>> ID AA4736F3
>> gpg: Bonne signature de ? Daan Hoogland  ?
>> gpg: ATTENTION: Cette cl? n'est pas certifi?e avec une signature de
>> confiance !
>> gpg:Rien ne dit que la signature appartient ? son propri?taire.
>> Empreinte de cl? principale: 043E 4236 C0B7 CA8C C31E  0381 F9E4 0C89 AA47
>> 36F3
>> 
>> 
>> Perhaps a problem with the KEYS ?
>> 
>> Thanks a lot.
>> 
>> Regards, Benoit.
>> 

RE: [VOTE] git workflow

[Sudha Ponnaganti]

+1

On Thu, Jul 31, 2014 at 12:28 PM, Rajani Karuturi  
wrote:
> Hi All,
>
> We had long discussions on the git flow.
> I tried to capture the summary of it @ 
> http://markmail.org/message/j5z7dxjcqxfkfhpj
> This is updated on wiki @ 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
>  and is up for a vote:
>
> Can you share your opinion on the proposal?
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
>
> Thanks,
> ~Rajani
>
>
>



--
Daan

Re: Warning on gpg verify on apache cloudstack 4.4

[benoit lair]

Ok, Thanks


2014-07-31 17:58 GMT+02:00 Sebastien Goasguen :

>
> On Jul 31, 2014, at 11:51 AM, benoit lair  wrote:
>
> > But with the md5 way, no problem this looks good.
> >
>
> It is just that Daan's key has not been signed by anybody else yet.
>
> >
> > 2014-07-31 17:49 GMT+02:00 benoit lair :
> >
> >> Hello,
> >>
> >> I am building acs 4.4, but when i verify the gpg keys, here is the
> warnign
> >> that i got :
> >>
> >> gpg --verify apache-cloudstack-4.4.0-src.tar.bz2.asc
> >> gpg: Signature faite le mer. 16 juil. 2014 14:09:59 CEST avec la cl? RSA
> >> ID AA4736F3
> >> gpg: Bonne signature de ? Daan Hoogland  ?
> >> gpg: ATTENTION: Cette cl? n'est pas certifi?e avec une signature de
> >> confiance !
> >> gpg:Rien ne dit que la signature appartient ? son
> propri?taire.
> >> Empreinte de cl? principale: 043E 4236 C0B7 CA8C C31E  0381 F9E4 0C89
> AA47
> >> 36F3
> >>
> >>
> >> Perhaps a problem with the KEYS ?
> >>
> >> Thanks a lot.
> >>
> >> Regards, Benoit.
> >>
>
>

ACS 4.4 - Need Nonoss RPMS

[benoit lair]

Hello,


Does the rpms hosted on http://cloudstack.apt-get.eu/rhel/4.4/ are already
nonoss ?


Thanks for your response.



Regards, Benoit.

Re: ACS 4.4 - Need Nonoss RPMS

[benoit lair]

Ok i have found my response :

--
-- Forwarded message --
From: Paul Angus 
Date: 2014-02-18 9:10 GMT+01:00
Subject: RE: 4.2.0 Installation Guide Section 3.7 "Building Non-OSS"‏
To: "dev@cloudstack.apache.org" 


Michael,

The convenience binaries are non-oss:
http://cloudstack.apt-get.eu/rhel/4.2/

However if you still want to build your own have a look here:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+CloudStack

Look out for Min's note on the 5.1 SDK - you'll need that version of the
jar for 4.2 onward.

Regards

Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
paul.an...@shapeblue.com

-Original Message-
From: Michael Phillips [mailto:mphilli7...@hotmail.com]
Sent: 18 February 2014 04:08
To: dev@cloudstack.apache.org
Subject: 4.2.0 Installation Guide Section 3.7 "Building Non-OSS"‏


2014-07-31 18:07 GMT+02:00 benoit lair :

> Hello,
>
>
> Does the rpms hosted on http://cloudstack.apt-get.eu/rhel/4.4/ are
> already nonoss ?
>
>
> Thanks for your response.
>
>
>
> Regards, Benoit.
>

RE: Simulator on master is not building

[Anthony Xu]

I see, thanks for explanation.

Anthony

-Original Message-
From: Koushik Das 
Sent: Wednesday, July 30, 2014 10:02 PM
To: Anthony Xu; dev@cloudstack.apache.org
Subject: RE: Simulator on master is not building

There is a separate simulator DB where all these VOs are used. These are only 
used in the 'Simulator' resource layer and are not part of core CS logic. Also 
I have written a sample test for new vmsync 
(test/integration/smoke/test_vm_sync.py). Please check it out and let me know 
if there are any issues.

-Koushik

-Original Message-
From: Anthony Xu 
Sent: Wednesday, 30 July 2014 11:37 PM
To: Koushik Das; dev@cloudstack.apache.org
Subject: RE: Simulator on master is not building

Hi Koushik,

fixed the build for simulator.

I just found out Simulator use its own VOes for some VOes, it may not be easy 
for developer to add feature for simulator if the feature needs to change VO, 
for example, the new VMsync logic, I don't think simulator test the new VMsync 
logic. 

If we consider Simulator as a hypervisor, ideally it should use the same VOes 
as other hypersivors. Can you help us understand what's the reason behind this?

Thanks
Anthony







./plugins/hypervisors/simulator/src/com/cloud/simulator/MockVMVO.java
./plugins/hypervisors/simulator/src/com/cloud/simulator/MockSecStorageVO.java
./plugins/hypervisors/simulator/src/com/cloud/simulator/MockVolumeVO.java
./plugins/hypervisors/simulator/src/com/cloud/simulator/MockStoragePoolVO.java
./plugins/hypervisors/simulator/src/com/cloud/simulator/MockHostVO.java
./plugins/hypervisors/simulator/src/com/cloud/simulator/MockConfigurationVO.java
./plugins/hypervisors/simulator/src/com/cloud/simulator/MockSecurityRulesVO.java





-Original Message-
From: Anthony Xu 
Sent: Wednesday, July 30, 2014 10:28 AM
To: Koushik Das; dev@cloudstack.apache.org
Subject: RE: Simulator on master is not building

We used -Dsimulator to include simulator, it is very easy for developers to 
forget it.  Simulator should be built by default , we may use -Dnosimulator to 
exclude simulator.


Anthony

-Original Message-
From: Koushik Das 
Sent: Wednesday, July 30, 2014 3:03 AM
To: dev@cloudstack.apache.org
Cc: Anthony Xu
Subject: RE: Simulator on master is not building

The simulator code should be kept up to date with any changes done in the core 
product. If there are any interface changes, necessary changes should be made 
in simulator plugin as well along with other hypervisor plugins. To build 
simulator code use refer to [1].

-Koushik

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Simulator+integration

-Original Message-
From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com] 
Sent: Wednesday, 30 July 2014 3:27 PM
To: dev@cloudstack.apache.org
Cc: Anthony Xu
Subject: Simulator on master is not building

I believe for every check-in we decided to run sanity tests on simulator 
atleast, currently build for simulator is failing. 

 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) 
on project cloud-plugin-hypervisor-simulator: Compilation failure: Compilation 
failure:
[ERROR] 
/home/santhosh/softwares/cs_new_master/cloudstack/plugins/hypervisors/simulator/src/com/cloud/resource/AgentRoutingResource.java:[230,8]
 error: 'try' without 'catch', 'finally' or resource declarations [ERROR] 
/home/santhosh/softwares/cs_new_master/cloudstack/plugins/hypervisors/simulator/src/com/cloud/resource/AgentRoutingResource.java:[251,8]
 error: 'try' without 'catch', 'finally' or resource declarations


Thanks!
Santhosh

Re: Warning on gpg verify on apache cloudstack 4.4

[Daan Hoogland]

Don't trust that guy.

On Thu, Jul 31, 2014 at 6:06 PM, benoit lair  wrote:
> Ok, Thanks
>
>
> 2014-07-31 17:58 GMT+02:00 Sebastien Goasguen :
>
>>
>> On Jul 31, 2014, at 11:51 AM, benoit lair  wrote:
>>
>> > But with the md5 way, no problem this looks good.
>> >
>>
>> It is just that Daan's key has not been signed by anybody else yet.
>>
>> >
>> > 2014-07-31 17:49 GMT+02:00 benoit lair :
>> >
>> >> Hello,
>> >>
>> >> I am building acs 4.4, but when i verify the gpg keys, here is the
>> warnign
>> >> that i got :
>> >>
>> >> gpg --verify apache-cloudstack-4.4.0-src.tar.bz2.asc
>> >> gpg: Signature faite le mer. 16 juil. 2014 14:09:59 CEST avec la cl? RSA
>> >> ID AA4736F3
>> >> gpg: Bonne signature de ? Daan Hoogland  ?
>> >> gpg: ATTENTION: Cette cl? n'est pas certifi?e avec une signature de
>> >> confiance !
>> >> gpg:Rien ne dit que la signature appartient ? son
>> propri?taire.
>> >> Empreinte de cl? principale: 043E 4236 C0B7 CA8C C31E  0381 F9E4 0C89
>> AA47
>> >> 36F3
>> >>
>> >>
>> >> Perhaps a problem with the KEYS ?
>> >>
>> >> Thanks a lot.
>> >>
>> >> Regards, Benoit.
>> >>
>>
>>



-- 
Daan

Re: [DISCUSS] git commit proces

[Sheng Yang]

On Thu, Jul 31, 2014 at 12:55 AM, Leo Simons 
wrote:

> On Jul 31, 2014, at 12:55 AM, Sheng Yang  wrote:
> > I suppose it would work like this:
> > 1. In the original model, every release branch would be deleted after
> merge
> > into develop and master branch. There is no release/4.4.1 or release/4.5
> > branch.
> > 2. Say we don't follow original model, when one release is released, you
> > keep it. Say we have release/4.4 and release/4.5. And currently we're
> > working on 4.7 which is develop branch, MASTER is 4.6.
> > 3. I have one bug in 4.4, I checked in a fix in 4.4. Release 4.4.1.
> > 4. Then, conflict would happen when you merge release/4.4. branch to
> > release/4.5. Since the version number changed to 4.4.1. You need to deal
> > with version number conflict every time when merge to upper release.
> > 5. Suppose you dealt with version number change. New release/4.5 would
> > merge release/4.4 which merged release/4.3. Then you want to merge to
> > master because there is a fix. Well, dealt with version number change
> > conflict again.
> > 6. Then, you would need to merge master to develop branch?
> >
> > I am little worry about the conflict every time when merge happened.
> Seems
> > version number conflict need to be dealt with everytime, and probably
> some
> > other conflict. The conflict need to be solved may result in more
> > error-prone situation.
>
> Well, yes, _that_ would be horrible! :-)
>
> Fortunately a merge only considers things that haven’t been merged before.
> If V means ‘bump version’, given
>
> master -
>  \ / \
> r/4.5 V1---y--V2  \
> \  \
> r/4.6\  V3--z---
>   \/
> fixx---
>
> because V1 is an ancestor of V3, when you merge x into r/4.6, git knows
> not to consider V1 commit again. It knows it only has to consider x. There
> is no conflict due to V1 or V2 at z. If you would do this
>
> master --
>  \  \   /
> r/4.5 V1-\-V2
>   \\ \
> r/4.6  V3---\-z——-\--z2--
>  \   / \/
> fix   x—-   \  /
>  \/
> fix2  x2--
>
> you will have a merge conflict once, at spot z, where you will have to
> resolve the conflict created by having conflicting ancestors V2 and V3. But
> you won’t have to deal with it at spot z2, since git will remember you
> already resolved that conflict before.
>
> As long as you merge, instead of cherry-pick.
>

If no matter how many times you merged from old release, you would only
need to solve version conflict once, that would be quite nice! Hope this
can get things done well.

Still, in this approach, one error in the old release would affect all the
following releases. That's something we need to be more careful than before.


> >> For example, the linux kernel has at least two active minor releases at
> >> any given time, and many more minor releases and forks going on at that
> >> same time, with hundreds (thousands?) of active developers, and even
> _they_
> >> don’t need freezes. Instead the power is in their choices of what they
> do
> >> and do not
> >
> > I've worked on Linux kernel for years,
>
> If you have experience with linux’ approach, I’d suggest you just look at
> git-flow as a massively simplified version of roughly that, which is easier
> to get into, something to hold on to while you develop experience and then
> good judgement [1] of when/what/where to merge. A reasonable starting
> point. Also, now I _really_ don’t understand why we have to have this
> discussion :)
>

IMO, git-flow is really different from Linux's approach.

Linux kernel never merge between different maintenance versions, and the
maintenance of stable tree is mostly made up of individual patches rather
than merge, using cherry-pick. Only large amount of fixes would need merge
probably.

Linux mainstream utilized merge is for pull in a large set of commits for
either feature or fixes. Not for maintain workflow.

Relative stable code based is maintained by subsystem maintainer, which a
feature would start from. After testing and mature the code, subsystem
maintainer would ask Linus to pull(merge) a specific tree for next merge
window.

To my understand, Linux's approach is much simple and straightforward than
git-flow:
1. Linus give 2 week merge window, merge everything he thinks proper from
subsystem maintainer(thinking about feature branch merge), then cut RC1.
2. No feature would be in after RC1. Linus would only pull fixes from
subsystem maintainer. Then cut on one RC about every 2 weeks.
3. When community think the release is stable enough after a few RC(mostly
around 7), Linus would cut release. Then th

Re: [VOTE] git workflow

[Mark Hinkle]

+1 

Mark


On Jul 31, 2014, at 12:03 PM, Sudha Ponnaganti  
wrote:

> +1
> 
> On Thu, Jul 31, 2014 at 12:28 PM, Rajani Karuturi 
>  wrote:
>> Hi All,
>> 
>> We had long discussions on the git flow.
>> I tried to capture the summary of it @ 
>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>> This is updated on wiki @ 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
>>  and is up for a vote:
>> 
>> Can you share your opinion on the proposal?
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> 
>> Thanks,
>> ~Rajani
>> 
>> 
>> 
> 
> 
> 
> --
> Daan

Re: Review Request 24111: Coverity findings for brocade-plugin

[Ritu Sabharwal]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24111/
---

(Updated July 31, 2014, 5:57 p.m.)


Review request for cloudstack and Hugo Trippaers.


Changes
---

Fixed the open issues.


Bugs: CLOUDSTACK-6823
https://issues.apache.org/jira/browse/CLOUDSTACK-6823


Repository: cloudstack-git


Description
---

Fixed Coverity findings for brocade-plugin


Diffs (updated)
-

  
plugins/network-elements/brocade-vcs/src/com/cloud/api/response/BrocadeVcsDeviceResponse.java
 60edbcf 
  
plugins/network-elements/brocade-vcs/src/com/cloud/network/brocade/BrocadeVcsApi.java
 d5f06f8 

Diff: https://reviews.apache.org/r/24111/diff/


Testing
---


Thanks,

Ritu  Sabharwal

Re: Review Request 24111: Coverity findings for brocade-plugin

[Ritu Sabharwal]

> On July 31, 2014, 7:01 a.m., Santhosh Edukulla wrote:
> > plugins/network-elements/brocade-vcs/src/com/cloud/network/brocade/BrocadeVcsApi.java,
> >  line 482
> > 
> >
> > This particular try\except  is  for an IO exception possible when 
> > closing a resource, so the message should have some reflection in it. But, 
> > when you use try-with-resource as mentioned in other issue, this is not 
> > required.

Fixed this also.


- Ritu


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24111/#review49213
---


On July 31, 2014, 5:57 p.m., Ritu  Sabharwal wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24111/
> ---
> 
> (Updated July 31, 2014, 5:57 p.m.)
> 
> 
> Review request for cloudstack and Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-6823
> https://issues.apache.org/jira/browse/CLOUDSTACK-6823
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixed Coverity findings for brocade-plugin
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/api/response/BrocadeVcsDeviceResponse.java
>  60edbcf 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/network/brocade/BrocadeVcsApi.java
>  d5f06f8 
> 
> Diff: https://reviews.apache.org/r/24111/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ritu  Sabharwal
> 
>

Re: issue with devcloud on 4.3

[Will Stevens]

I am trying to use devcloud to deploy my xenserver (I do this all the
time).  I am getting this same issue with the 4.3 branch.  I am only
running one management server though.  Seb, did you change anything else to
get this working?

On my server I am seeing the following:

[c.c.a.ApiServer] (1577211684@qtp-2141586529-0:ctx-f4c0925b ctx-d359475e)
User signature: /4oTXI4bf/08rcwXMFRzjxIUhSE= is not equaled to computed
signature: nwAfc2oiJMXEw3a+ZeB5IUYebrQ=
In my vmops.log file I have the following:

2014-07-31 13:55:12,301 DEBUG [c.c.a.ApiServlet]
(1577211684@qtp-2141586529-0:ctx-f4c0925b) ===START===  172.16.254.5 -- GET
 
localstorageenabled=true&apiKey=aY95GUE5WstroERiG7-ZSckobEiFSu7jSAL3fck4OaR-dKD4kgDE6kClMPaIa13rXAnD6qfHmqO4B6k74iZpJw&typeInfo=localstorageenabled&typeInfo=domain&typeInfo=domainid&typeInfo=name&typeInfo=guestcidraddress&typeInfo=dns2&typeInfo=dns1&typeInfo=allocationstate&typeInfo=securitygroupenabled&typeInfo=ip6dns2&typeInfo=ip6dns1&typeInfo=networktype&typeInfo=internaldns1&typeInfo=internaldns2&name=dev_zone&guestcidraddress=10.1.1.0%2F24&dns1=8.8.8.8&internaldns1=172.16.254.2&command=createZone&signature=%2F4oTXI4bf%2F08rcwXMFRzjxIUhSE%3D&networktype=Advanced&response=json
2014-07-31 13:55:12,328 INFO  [c.c.a.ApiServer]
(1577211684@qtp-2141586529-0:ctx-f4c0925b
ctx-d359475e) User signature: /4oTXI4bf/08rcwXMFRzjxIUhSE= is not equaled
to computed signature: nwAfc2oiJMXEw3a+ZeB5IUYebrQ=
2014-07-31 13:55:12,336 DEBUG [c.c.a.ApiServlet]
(1577211684@qtp-2141586529-0:ctx-f4c0925b ctx-d359475e) ===END===
 172.16.254.5 -- GET
 
localstorageenabled=true&apiKey=aY95GUE5WstroERiG7-ZSckobEiFSu7jSAL3fck4OaR-dKD4kgDE6kClMPaIa13rXAnD6qfHmqO4B6k74iZpJw&typeInfo=localstorageenabled&typeInfo=domain&typeInfo=domainid&typeInfo=name&typeInfo=guestcidraddress&typeInfo=dns2&typeInfo=dns1&typeInfo=allocationstate&typeInfo=securitygroupenabled&typeInfo=ip6dns2&typeInfo=ip6dns1&typeInfo=networktype&typeInfo=internaldns1&typeInfo=internaldns2&name=dev_zone&guestcidraddress=10.1.1.0%2F24&dns1=8.8.8.8&internaldns1=172.16.254.2&command=createZone&signature=%2F4oTXI4bf%2F08rcwXMFRzjxIUhSE%3D&networktype=Advanced&response=json

Any ideas why this is happening?  I have the 8096 setup in the CS config
(which is what devcloud is configured to use)...

Cheers,

Will







*Will STEVENS*
Lead Developer

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


On Wed, Jan 15, 2014 at 8:52 AM, sebgoa  wrote:

> When using Edison new image and running the mgt server on my localhost, I
> face an issue with deploying the DC with marvin:
>
> $ python ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
> Traceback (most recent call last):
>   File "../marvin/marvin/deployDataCenter.py", line 572, in 
> deploy.deploy()
>   File "../marvin/marvin/deployDataCenter.py", line 556, in deploy
> self.createZones(self.config.zones)
>   File "../marvin/marvin/deployDataCenter.py", line 385, in createZones
> zoneresponse = self.apiClient.createZone(createzone)
>   File
> "/Users/sebgoa/Documents/gitforks/cloudstack/tools/marvin/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 1296, in createZone
> response = self.connection.marvinRequest(command,
> response_type=response, method=method)
>   File
> "/Users/sebgoa/Documents/gitforks/cloudstack/tools/marvin/marvin/cloudstackConnection.py",
> line 272, in marvinRequest
> response = jsonHelper.getResultObj(response.json(), response_type)
>   File
> "/Users/sebgoa/Documents/gitforks/cloudstack/tools/marvin/marvin/jsonHelper.py",
> line 148, in getResultObj
> raise cloudstackException.cloudstackAPIException(respname, errMsg)
> cloudstackException.cloudstackAPIException: Execute cmd: createzone
> failed, due to: errorCode: 401, errorText:unable to verify user credentials
> and/or request signature
>
>
> I built and deploy the db with:
>
> mvn -Pdeveloper,systemvm clean install
> mvn -P developer -pl developer,tools/devcloud -Ddeploydb
>
> run the mgt server with:
>
> mvn -pl client jetty:run
>
> I am using devcloud as an hypervisor as opposed to running the mgt server
> directly in devcloud.
>
> Cloudmonkey works fine so it's not a problem with the api server. The
> deploydatacenter script worked with the simulator.
>
>
>
> -Sebastien

Re: Problem using DevCloud2 with 4.2

[Will Stevens]

I am having the same problem.  I have started from scratch 3 or 4 times now
and still no luck.  I am cleaning my XenServer each time and I am starting
from a fresh build each time with CS.

I am not sure where this bug is coming from.  Did you do anything specific
to get past this bug?

I am using the 4.3 branch...

ws


*Will STEVENS*
Lead Developer

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


On Fri, Sep 27, 2013 at 12:38 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hi,
>
> I haven't tried to use DevCloud2 in a while (generally been setting up CS
> manually). I noticed the following problem when running the typical setup
> script today:
>
> mtutkowski-LT:~ mtutkowski$ cd
> documents/cloudstack/src/cloudstack/tools/devcloud ; python
> ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
> Traceback (most recent call last):
>   File "../marvin/marvin/deployDataCenter.py", line 613, in 
> deploy.deploy()
>   File "../marvin/marvin/deployDataCenter.py", line 598, in deploy
> self.createZones(self.config.zones)
>   File "../marvin/marvin/deployDataCenter.py", line 389, in createZones
> zoneresponse = self.apiClient.createZone(createzone)
>   File
>
> "/Users/mtutkowski/Documents/CloudStack/src/CloudStack/tools/marvin/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 1242, in createZone
> response = self.connection.marvin_request(command,
> response_type=response, method=method)
>   File
>
> "/Users/mtutkowski/Documents/CloudStack/src/CloudStack/tools/marvin/marvin/cloudstackConnection.py",
> line 222, in marvin_request
> response = jsonHelper.getResultObj(response.json(), response_type)
>   File
>
> "/Users/mtutkowski/Documents/CloudStack/src/CloudStack/tools/marvin/marvin/jsonHelper.py",
> line 148, in getResultObj
> raise cloudstackException.cloudstackAPIException(respname, errMsg)
> cloudstackException.cloudstackAPIException: Execute cmd: createzone failed,
> due to: errorCode: 401, errorText:unable to verify user credentials and/or
> request signature
>
> On the management server console side:
>
> INFO  [cloud.api.ApiServer] (1841029180@qtp-1791812015-0:) disabled or
> locked user accessing the api, userid = 2; name = admin; state: disabled;
> accountState: enabled
>
> Has anything changed recently with regards to how we use DevCloud2?
>
> I started with a clean build, cleaned the DB, and had reset DevCloud2 to
> its initial state before running the setup script.
>
> Thanks!
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *™*
>

Re: [VOTE] git workflow

[Sheng Yang]

+0, based on my opinion on another thread "git commit process".

--Sheng

On Thu, Jul 31, 2014 at 10:56 AM, Mark Hinkle 
wrote:

> +1
>
> Mark
>
>
> On Jul 31, 2014, at 12:03 PM, Sudha Ponnaganti <
> sudha.ponnaga...@citrix.com> wrote:
>
> > +1
> >
> > On Thu, Jul 31, 2014 at 12:28 PM, Rajani Karuturi <
> rajani.karut...@citrix.com> wrote:
> >> Hi All,
> >>
> >> We had long discussions on the git flow.
> >> I tried to capture the summary of it @
> >> http://markmail.org/message/j5z7dxjcqxfkfhpj
> >> This is updated on wiki @
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
> and is up for a vote:
> >>
> >> Can you share your opinion on the proposal?
> >>
> >> [ ] +1  approve
> >> [ ] +0  no opinion
> >> [ ] -1  disapprove (and reason why)
> >>
> >>
> >> Thanks,
> >> ~Rajani
> >>
> >>
> >>
> >
> >
> >
> > --
> > Daan
>
>

Re: 32 vs 64 bit systemvm on 43 and secondary NFS storage used / capacity Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Erik Weber]

On Mon, Mar 17, 2014 at 7:02 PM, Animesh Chaturvedi <
animesh.chaturv...@citrix.com> wrote:

>
>
> > -Original Message-
> > From: Ove Ewerlid [mailto:ove.ewer...@oracle.com]
> > Sent: Monday, March 17, 2014 9:09 AM
> > To: dev@cloudstack.apache.org
> > Subject: 32 vs 64 bit systemvm on 43 and secondary NFS storage used /
> > capacity Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> >
> > Has anyone else seen below behavior with 4.3.0 RC 8?
> >
> >   - with 32 bit system VM, the secondary storage is reported as 0/0
> (this is at
> > the agent level, not a GUI or manager issue)
> >
> >   - with 64 bit system VM, the secondary storage is reported OK.
> >
> >
> [Animesh] We have defaulted to 64 bit template for 4.3
>


Guess I should've asked this earlier, but does this mean that 32 bits
template no longer work, unless you do "something"?

Erik

[ACS44] template upgrade code

[Daan Hoogland]

Devs,

It seems there is a big problem in the 4.4 release. The templates need
a new java version but the ms seems to have no logic to automatically
update the templates when found in the system. Is the code from older
updates never generalized, in master or easily protable from 4.3? Can
anyone give me a clue? Am willing to pull my weight on this.

-- 
Daan

[PROPOSAL] systemvm upgrade process

[Pierre-Luc Dion]

since 4.3 the management-server can tell if systemvm and VR require
upgrade, which is great !  but, as of 4.4  it's not working anymore and
 systemvm must be upgrade as well.

And what if their is another hartbleed issue between release requiring
upgrade of systemvm ?

Citrix is providing a Python script to CloudPlatform in order to upgrade
the systemvm template to a latest 4.3from jun 2014, which is not bad. but...


Doing automatic upgrade of system vm is out of scope because of implicated
downtime.

But could it be possible to implement a naming standard of systemvm
template so the management server would detect a newer version of template
and ask for upgrade of systemvm  and VR?

Something like if I have those systemvm templates:
- SystemVM Template (XenServer)
- systemvm-xenserver-4.3
- systemvm-xenserver-4.4

right now in 4.4  it will use systemvm-xenserver-4.3 template which is not
working with acs4.4.

Could the detection of a new template be automated?  like if I have to
upgrade to a newer version withing 4.4, like  systemvm-xenserver-4.4.1 ?

or

Could it be simple to have a Global setting where we define the
systemvm-template to use and by default it would be SystemVM Template (*) ?

unless something like that is already in place?

Thanks,

PL

Re: [VOTE] git workflow

[Alena Prokharchyk]

+1 on the proposal. But I second Rohit and Sheng Yang - we should agree on
all the flow points before we adopt it for CloudStack. We can¹t just
blindly follow http://nvie.com/posts/a-successful-git-branching-model/,
plus some use cases are not explained there as I¹ve pointed in one of my
previous emails.

-Alena.

On 7/31/14, 4:19 AM, "Rohit Yadav"  wrote:

>+1
>
>Hugo, I think we started this voting thread to get opinion on the
>proposal. I feel it may need some iteration and community agreement
>before we adopt it.
>
>Suggestions, flames and opinions are welcome.
>
>Regards.
>
>
>On 31-Jul-2014, at 12:43 pm, Hugo Trippaers  wrote:
>
>> Rajani,
>>
>> To make it clear for everyone. This is the vote to adopt this new way
>>of working right? Or is it just to get an opinion on the proposal?
>>
>> If it is indeed the vote to adopt this way of working it means that all
>>committers will change how we interact with the branches in the
>>CloudStack git.
>>
>> It¹s is a good thing in my book, but we need to be clear what the
>>expected result is when this vote has concluded in 72 hours.
>>
>> Cheers,
>>
>> Hugo
>>
>>
>> On 31 jul. 2014, at 12:28, Rajani Karuturi 
>>wrote:
>>
>>> Hi All,
>>>
>>> We had long discussions on the git flow.
>>> I tried to capture the summary of it @
>>>http://markmail.org/message/j5z7dxjcqxfkfhpj
>>> This is updated on wiki @
>>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedG
>>>itflowbasedCheck-inProcess and is up for a vote:
>>>
>>> Can you share your opinion on the proposal?
>>>
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>>
>>>
>>> Thanks,
>>> ~Rajani
>>>
>>>
>>>
>>
>
>Regards,
>Rohit Yadav
>Software Architect, ShapeBlue
>M. +41 779015219 | rohit.ya...@shapeblue.com
>Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
>
>Find out more about ShapeBlue and our range of CloudStack related services
>
>IaaS Cloud Design &
>Build
>CSForge ­ rapid IaaS deployment framework
>CloudStack Consulting
>CloudStack Infrastructure
>Support
>CloudStack Bootcamp Training
>Courses
>
>This email and any attachments to it may be confidential and are intended
>solely for the use of the individual to whom it is addressed. Any views
>or opinions expressed are solely those of the author and do not
>necessarily represent those of Shape Blue Ltd or related companies. If
>you are not the intended recipient of this email, you must neither take
>any action based upon its contents, nor copy or show it to anyone. Please
>contact the sender if you believe you have received this email in error.
>Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
>Services India LLP is a company incorporated in India and is operated
>under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
>a company incorporated in Brasil and is operated under license from Shape
>Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of
>South Africa and is traded under license from Shape Blue Ltd. ShapeBlue
>is a registered trademark.

Re: [VOTE] git workflow

[Sebastien Goasguen]

On Jul 31, 2014, at 4:33 PM, Alena Prokharchyk  
wrote:

> +1 on the proposal. But I second Rohit and Sheng Yang - we should agree on
> all the flow points before we adopt it for CloudStack. We can¹t just
> blindly follow http://nvie.com/posts/a-successful-git-branching-model/,
> plus some use cases are not explained there as I¹ve pointed in one of my
> previous emails.
> 

Can you add to the wiki page then ? describe the use case that you have in mind 
and explain how to address it.

If we all collaboratively edit that page we should be able to get to a 
consensus and have something that addresses all our current concerns.


> -Alena.
> 
> On 7/31/14, 4:19 AM, "Rohit Yadav"  wrote:
> 
>> +1
>> 
>> Hugo, I think we started this voting thread to get opinion on the
>> proposal. I feel it may need some iteration and community agreement
>> before we adopt it.
>> 
>> Suggestions, flames and opinions are welcome.
>> 
>> Regards.
>> 
>> 
>> On 31-Jul-2014, at 12:43 pm, Hugo Trippaers  wrote:
>> 
>>> Rajani,
>>> 
>>> To make it clear for everyone. This is the vote to adopt this new way
>>> of working right? Or is it just to get an opinion on the proposal?
>>> 
>>> If it is indeed the vote to adopt this way of working it means that all
>>> committers will change how we interact with the branches in the
>>> CloudStack git.
>>> 
>>> It¹s is a good thing in my book, but we need to be clear what the
>>> expected result is when this vote has concluded in 72 hours.
>>> 
>>> Cheers,
>>> 
>>> Hugo
>>> 
>>> 
>>> On 31 jul. 2014, at 12:28, Rajani Karuturi 
>>> wrote:
>>> 
 Hi All,
 
 We had long discussions on the git flow.
 I tried to capture the summary of it @
 http://markmail.org/message/j5z7dxjcqxfkfhpj
 This is updated on wiki @
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedG
 itflowbasedCheck-inProcess and is up for a vote:
 
 Can you share your opinion on the proposal?
 
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)
 
 
 Thanks,
 ~Rajani
 
 
 
>>> 
>> 
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +41 779015219 | rohit.ya...@shapeblue.com
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>> 
>> 
>> 
>> 
>> Find out more about ShapeBlue and our range of CloudStack related services
>> 
>> IaaS Cloud Design &
>> Build
>> CSForge ­ rapid IaaS deployment framework
>> CloudStack Consulting
>> CloudStack Infrastructure
>> Support
>> CloudStack Bootcamp Training
>> Courses
>> 
>> This email and any attachments to it may be confidential and are intended
>> solely for the use of the individual to whom it is addressed. Any views
>> or opinions expressed are solely those of the author and do not
>> necessarily represent those of Shape Blue Ltd or related companies. If
>> you are not the intended recipient of this email, you must neither take
>> any action based upon its contents, nor copy or show it to anyone. Please
>> contact the sender if you believe you have received this email in error.
>> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
>> Services India LLP is a company incorporated in India and is operated
>> under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
>> a company incorporated in Brasil and is operated under license from Shape
>> Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of
>> South Africa and is traded under license from Shape Blue Ltd. ShapeBlue
>> is a registered trademark.
> 

Re: [VOTE] git workflow

[Alena Prokharchyk]

Done, updated the wiki page with my comments. Copy/pasting here:

Open items:
1) Which bugs can be submitted to develop branch directly.
Document http://nvie.com/posts/a-successful-git-branching-model/ mentions
that the
*hotfix branch should be created for the blocker/critical bugs in the
current production release. What about bugs happenning in the *release(the
one that hasn't been released yet)/*develop
branches ? Should we fix them directly in those branches, or should we
branch out off the *release
branch, fix the problem, and merge the fix to *release?
We should decide:
for which bugs the hot fix branch should be cut, and which fixes can go
directly to *develop/*release branches. This criteria has to be defined in
the doc, and be based on the a) bug severity b) number of people who work
on the bug - if more than one, then we cut the new branch c)
feedback/review is needed for the bug d) anything else?

2) I don't agree with the model when the person has to merge his
branch/commit the fix to both develop/master branches. So there are 2
approaches that can be taken:
* Currently proposed approach: ask a person always put 2 fixes - one in
master and one in develop
* Approach I suggest, and its used in the field a lot: Person commits the
fixes to *develop branch, and then there is some job doing automatic merge
from *develop to *master branch after CI on *develop passes

From the past experience, I see that the first (currently proposed)
approach is less desirable as a) sometimes people forget to push changes
into master branch, and then the release manager has to run the merge to
find those missing pieces b) IMPORTANT: it would require to run CI on both
*develop and *master branch with higher frequency, plus the rollbacks in
case of failure need to be done both in develop and master branches. I
would advocate for the following flow:

* submit fixes/merges from release/hotfix branches to *develop branch only
* Run daily(?) CI on develop branch, and do merge delta to master branch
only when CI passes

-Alena.






On 7/31/14, 1:40 PM, "Sebastien Goasguen"  wrote:

>
>On Jul 31, 2014, at 4:33 PM, Alena Prokharchyk
> wrote:
>
>> +1 on the proposal. But I second Rohit and Sheng Yang - we should agree
>>on
>> all the flow points before we adopt it for CloudStack. We can¹t just
>> blindly follow http://nvie.com/posts/a-successful-git-branching-model/,
>> plus some use cases are not explained there as I¹ve pointed in one of my
>> previous emails.
>> 
>
>Can you add to the wiki page then ? describe the use case that you have
>in mind and explain how to address it.
>
>If we all collaboratively edit that page we should be able to get to a
>consensus and have something that addresses all our current concerns.
>
>
>> -Alena.
>> 
>> On 7/31/14, 4:19 AM, "Rohit Yadav"  wrote:
>> 
>>> +1
>>> 
>>> Hugo, I think we started this voting thread to get opinion on the
>>> proposal. I feel it may need some iteration and community agreement
>>> before we adopt it.
>>> 
>>> Suggestions, flames and opinions are welcome.
>>> 
>>> Regards.
>>> 
>>> 
>>> On 31-Jul-2014, at 12:43 pm, Hugo Trippaers  wrote:
>>> 
 Rajani,
 
 To make it clear for everyone. This is the vote to adopt this new way
 of working right? Or is it just to get an opinion on the proposal?
 
 If it is indeed the vote to adopt this way of working it means that
all
 committers will change how we interact with the branches in the
 CloudStack git.
 
 It¹s is a good thing in my book, but we need to be clear what the
 expected result is when this vote has concluded in 72 hours.
 
 Cheers,
 
 Hugo
 
 
 On 31 jul. 2014, at 12:28, Rajani Karuturi

 wrote:
 
> Hi All,
> 
> We had long discussions on the git flow.
> I tried to capture the summary of it @
> http://markmail.org/message/j5z7dxjcqxfkfhpj
> This is updated on wiki @
> 
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-Propose
>dG
> itflowbasedCheck-inProcess and is up for a vote:
> 
> Can you share your opinion on the proposal?
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> 
> Thanks,
> ~Rajani
> 
> 
> 
 
>>> 
>>> Regards,
>>> Rohit Yadav
>>> Software Architect, ShapeBlue
>>> M. +41 779015219 | rohit.ya...@shapeblue.com
>>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>> 
>>> 
>>> 
>>> 
>>> Find out more about ShapeBlue and our range of CloudStack related
>>>services
>>> 
>>> IaaS Cloud Design &
>>> Build
>>> CSForge ­ rapid IaaS deployment
>>>framework
>>> CloudStack Consulting
>>> CloudStack Infrastructure
>>> Support
>>> CloudStack Bootcamp Training
>>> Courses

Re: Problem using DevCloud2 with 4.2

[Mike Tutkowski]

Hey Will,

Unfortunately no, I didn't take any special steps to get around the issue.
I cleaned everything up, tried again and it worked.

Sorry I can't be of more help here.

Talk to you later,
Mike

On Thursday, July 31, 2014, Will Stevens  wrote:

> I am having the same problem.  I have started from scratch 3 or 4 times now
> and still no luck.  I am cleaning my XenServer each time and I am starting
> from a fresh build each time with CS.
>
> I am not sure where this bug is coming from.  Did you do anything specific
> to get past this bug?
>
> I am using the 4.3 branch...
>
> ws
>
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
>
> On Fri, Sep 27, 2013 at 12:38 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com > wrote:
>
> > Hi,
> >
> > I haven't tried to use DevCloud2 in a while (generally been setting up CS
> > manually). I noticed the following problem when running the typical setup
> > script today:
> >
> > mtutkowski-LT:~ mtutkowski$ cd
> > documents/cloudstack/src/cloudstack/tools/devcloud ; python
> > ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
> > Traceback (most recent call last):
> >   File "../marvin/marvin/deployDataCenter.py", line 613, in 
> > deploy.deploy()
> >   File "../marvin/marvin/deployDataCenter.py", line 598, in deploy
> > self.createZones(self.config.zones)
> >   File "../marvin/marvin/deployDataCenter.py", line 389, in createZones
> > zoneresponse = self.apiClient.createZone(createzone)
> >   File
> >
> >
> "/Users/mtutkowski/Documents/CloudStack/src/CloudStack/tools/marvin/marvin/cloudstackAPI/cloudstackAPIClient.py",
> > line 1242, in createZone
> > response = self.connection.marvin_request(command,
> > response_type=response, method=method)
> >   File
> >
> >
> "/Users/mtutkowski/Documents/CloudStack/src/CloudStack/tools/marvin/marvin/cloudstackConnection.py",
> > line 222, in marvin_request
> > response = jsonHelper.getResultObj(response.json(), response_type)
> >   File
> >
> >
> "/Users/mtutkowski/Documents/CloudStack/src/CloudStack/tools/marvin/marvin/jsonHelper.py",
> > line 148, in getResultObj
> > raise cloudstackException.cloudstackAPIException(respname, errMsg)
> > cloudstackException.cloudstackAPIException: Execute cmd: createzone
> failed,
> > due to: errorCode: 401, errorText:unable to verify user credentials
> and/or
> > request signature
> >
> > On the management server console side:
> >
> > INFO  [cloud.api.ApiServer] (1841029180@qtp-1791812015-0:) disabled or
> > locked user accessing the api, userid = 2; name = admin; state: disabled;
> > accountState: enabled
> >
> > Has anything changed recently with regards to how we use DevCloud2?
> >
> > I started with a clean build, cleaned the DB, and had reset DevCloud2 to
> > its initial state before running the setup script.
> >
> > Thanks!
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com 
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud
> > *™*
> >
>


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

[ACS44][KVM][BUG] System VMs not able to start after upgrade from ACS43

[Erik Weber]

Pretty sure I'm seeing this bug[1] with an installation that has been
upgraded from ACS43 to ACS44.

I can see it got commited to 4.4-forward but not commited to 4.4.0 tag as
far as i can see.

Does anyone know of a workaround or fix?


[1] https://issues.apache.org/jira/browse/CLOUDSTACK-6893

-- 
Erik

RE: [ACS44] template upgrade code

[Animesh Chaturvedi]

+ Abhi

> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Thursday, July 31, 2014 12:14 PM
> To: dev
> Subject: [ACS44] template upgrade code
> 
> Devs,
> 
> It seems there is a big problem in the 4.4 release. The templates need a new
> java version but the ms seems to have no logic to automatically update the
> templates when found in the system. Is the code from older updates never
> generalized, in master or easily protable from 4.3? Can anyone give me a
> clue? Am willing to pull my weight on this.
> 
> --
> Daan

Re: [VOTE] git workflow

[Alena Prokharchyk]

Sorry, ignore #2. I’ve read on the model more, and realized that master
branch would reflect the branch that has been released, not the current
release.

So only #1 is yet to be addressed.

-alena.

On 7/31/14, 2:03 PM, "Alena Prokharchyk" 
wrote:

>Done, updated the wiki page with my comments. Copy/pasting here:
>
>Open items:
>1) Which bugs can be submitted to develop branch directly.
>Document http://nvie.com/posts/a-successful-git-branching-model/ mentions
>that the
>*hotfix branch should be created for the blocker/critical bugs in the
>current production release. What about bugs happenning in the *release(the
>one that hasn't been released yet)/*develop
>branches ? Should we fix them directly in those branches, or should we
>branch out off the *release
>branch, fix the problem, and merge the fix to *release?
>We should decide:
>for which bugs the hot fix branch should be cut, and which fixes can go
>directly to *develop/*release branches. This criteria has to be defined in
>the doc, and be based on the a) bug severity b) number of people who work
>on the bug - if more than one, then we cut the new branch c)
>feedback/review is needed for the bug d) anything else?
>
>2) I don't agree with the model when the person has to merge his
>branch/commit the fix to both develop/master branches. So there are 2
>approaches that can be taken:
>* Currently proposed approach: ask a person always put 2 fixes - one in
>master and one in develop
>* Approach I suggest, and its used in the field a lot: Person commits the
>fixes to *develop branch, and then there is some job doing automatic merge
>from *develop to *master branch after CI on *develop passes
>
>From the past experience, I see that the first (currently proposed)
>approach is less desirable as a) sometimes people forget to push changes
>into master branch, and then the release manager has to run the merge to
>find those missing pieces b) IMPORTANT: it would require to run CI on both
>*develop and *master branch with higher frequency, plus the rollbacks in
>case of failure need to be done both in develop and master branches. I
>would advocate for the following flow:
>
>* submit fixes/merges from release/hotfix branches to *develop branch only
>* Run daily(?) CI on develop branch, and do merge delta to master branch
>only when CI passes
>
>-Alena.
>
>
>
>
>
>
>On 7/31/14, 1:40 PM, "Sebastien Goasguen"  wrote:
>
>>
>>On Jul 31, 2014, at 4:33 PM, Alena Prokharchyk
>> wrote:
>>
>>> +1 on the proposal. But I second Rohit and Sheng Yang - we should agree
>>>on
>>> all the flow points before we adopt it for CloudStack. We can¹t just
>>> blindly follow http://nvie.com/posts/a-successful-git-branching-model/,
>>> plus some use cases are not explained there as I¹ve pointed in one of
>>>my
>>> previous emails.
>>> 
>>
>>Can you add to the wiki page then ? describe the use case that you have
>>in mind and explain how to address it.
>>
>>If we all collaboratively edit that page we should be able to get to a
>>consensus and have something that addresses all our current concerns.
>>
>>
>>> -Alena.
>>> 
>>> On 7/31/14, 4:19 AM, "Rohit Yadav"  wrote:
>>> 
 +1
 
 Hugo, I think we started this voting thread to get opinion on the
 proposal. I feel it may need some iteration and community agreement
 before we adopt it.
 
 Suggestions, flames and opinions are welcome.
 
 Regards.
 
 
 On 31-Jul-2014, at 12:43 pm, Hugo Trippaers  wrote:
 
> Rajani,
> 
> To make it clear for everyone. This is the vote to adopt this new way
> of working right? Or is it just to get an opinion on the proposal?
> 
> If it is indeed the vote to adopt this way of working it means that
>all
> committers will change how we interact with the branches in the
> CloudStack git.
> 
> It¹s is a good thing in my book, but we need to be clear what the
> expected result is when this vote has concluded in 72 hours.
> 
> Cheers,
> 
> Hugo
> 
> 
> On 31 jul. 2014, at 12:28, Rajani Karuturi
>
> wrote:
> 
>> Hi All,
>> 
>> We had long discussions on the git flow.
>> I tried to capture the summary of it @
>> http://markmail.org/message/j5z7dxjcqxfkfhpj
>> This is updated on wiki @
>> 
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-Propos
>>e
>>dG
>> itflowbasedCheck-inProcess and is up for a vote:
>> 
>> Can you share your opinion on the proposal?
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> 
>> Thanks,
>> ~Rajani
>> 
>> 
>> 
> 
 
 Regards,
 Rohit Yadav
 Software Architect, ShapeBlue
 M. +41 779015219 | rohit.ya...@shapeblue.com
 Blog: bhaisaab.org | Twitter: @_bhaisaab
 
 
 
 
 Find out more about ShapeBlue and our range of CloudStack related
services
 
 IaaS Cloud Des

RE: How to speed up testing using BVT/smoke tests with Simulator

[Edison Su]

> -Original Message-
> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
> Sent: Thursday, July 31, 2014 5:12 AM
> To: dev@cloudstack.apache.org
> Subject: How to speed up testing using BVT/smoke tests with Simulator
> 
> Hi,
> 
> Santosh put together a good wiki page on how to validate local changes using
> our Python/marvin based build verification tests (path:
> test/integration/smoke):
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check
> -ins+for+your+local+changes%2C+using+Simulator
> 
> I've a mini PC for this and using CloudStack 4.4.0 to build/test CloudStack
> 4.4/master branch on it in a VM. Some of us are also exploring free/cheap CI
> services such as Travis, CloudBees etc. which can be used by developers to
> test their check-ins. If anyone of you have tried something like this please
> share.
Today, I tried to build and test CloudStack on a super powerful machine 
provided by Azure. Imaging, build & test on a 16 Cores, 120G machine, it should 
be awesome, and most importantly, it's FREE. You can get a free MSDN 
subscription from 
https://svn.apache.org/repos/private/committers/donated-licenses/msdn-subscription.html,
 after that, you will get $150 credit monthly in Azure. For build &test only, 
$150 is good enough.

> 
> This is how I build CloudStack for validating with simulator:
> mvn -Pdeveloper -Dsimulator clean install
> mvn -Pdeveloper -pl developer -Ddeploydb
> mvn -Pdeveloper -pl developer -Ddeploydb-simulator
> mvn -pl client jetty:run -Dsimulator
> 
> And finally run smoke tests (BVT):
> nosetests --with-marvin --marvin-config=setup/dev/advanced.cfg --with-
> xunit --xunit-file=/tmp/bvt_selfservice_cases.xml -a
> tags=advanced,required_hardware=false -w test/integration/smoke --
> hypervisor=simulator
> 
> It currently took 50 mins on my setup. How can we speed it up, say by
> reducing global variable timeout settings etc? Should we reduce timeouts etc.
> in deploydb-simulator specific sql files?

There several places we can improve the marvin test:
1. queryAsyncJob waits 5 second for each call, can change to 1s.
2. There are hardcoded sleep in test code, such base.py, search time.sleep
3. global configuration: account.cleanup.interval sets to 600s, so the test 
suite will stop for 10 minutes after running for a while.
3. most importantly, if we can run the test cases in parallel, then speedup 
should be great. Does anybody try to run it in parallel before?

> 
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
> 
> 
> 
> 
> Find out more about ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design & Build build//>
> CSForge - rapid IaaS deployment
> framework
> CloudStack Consulting
> CloudStack Infrastructure Support infrastructure-support/>
> CloudStack Bootcamp Training Courses training/>
> 
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender if
> you believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India LLP is a
> company incorporated in India and is operated under license from Shape
> Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in
> Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty
> Ltd is a company registered by The Republic of South Africa and is traded
> under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Build failed in Jenkins: build-master #1280

[jenkins]

See 

Changes:

[bfederle] createForm, dyanmic input type: Pass in context

--
[...truncated 2697 lines...]
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
cloud-plugin-hypervisor-ovm ---
[INFO] Compiling 18 source files to 

[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-plugin-hypervisor-ovm ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-plugin-hypervisor-ovm ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ 
cloud-plugin-hypervisor-ovm ---
[INFO] Surefire report directory: 


---
 T E S T S
---

Results :

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

[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Plugin - Open vSwitch 4.5.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
cloud-plugin-network-ovs ---
[INFO] Deleting 

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

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

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-plugin-network-ovs ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-plugin-network-ovs ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
cloud-plugin-network-ovs ---
[INFO] Compiling 33 source files to 

[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-plugin-network-ovs ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-plugin-network-ovs ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ 
cloud-plugin-network-ovs ---
[INFO] Surefire report directory: 


---
 T E S T S
---

Results :

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

[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Plugin - Hypervisor XenServer 4.5.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
cloud-plugin-hypervisor-xenserver ---
[INFO] Deleting 

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

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

[INFO] 
[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
[INF

Re: How to speed up testing using BVT/smoke tests with Simulator

[Rohit Yadav]

Hi Edison,

Thanks for the pointers! I’ll try them out and see if there is way to do it on 
Travis/CloudBees as well and I hope other people will religiously start using 
simulator/bvt (at least the basic ones) for their check-ins.

Regards.

On 01-Aug-2014, at 12:15 am, Edison Su  wrote:

>
>
>> -Original Message-
>> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
>> Sent: Thursday, July 31, 2014 5:12 AM
>> To: dev@cloudstack.apache.org
>> Subject: How to speed up testing using BVT/smoke tests with Simulator
>>
>> Hi,
>>
>> Santosh put together a good wiki page on how to validate local changes using
>> our Python/marvin based build verification tests (path:
>> test/integration/smoke):
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check
>> -ins+for+your+local+changes%2C+using+Simulator
>>
>> I've a mini PC for this and using CloudStack 4.4.0 to build/test CloudStack
>> 4.4/master branch on it in a VM. Some of us are also exploring free/cheap CI
>> services such as Travis, CloudBees etc. which can be used by developers to
>> test their check-ins. If anyone of you have tried something like this please
>> share.
> Today, I tried to build and test CloudStack on a super powerful machine 
> provided by Azure. Imaging, build & test on a 16 Cores, 120G machine, it 
> should be awesome, and most importantly, it's FREE. You can get a free MSDN 
> subscription 
> fromhttps://svn.apache.org/repos/private/committers/donated-licenses/msdn-subscription.html,
>  after that, you will get $150 credit monthly in Azure. For build &test only, 
> $150 is good enough.
>
>>
>> This is how I build CloudStack for validating with simulator:
>>mvn -Pdeveloper -Dsimulator clean install
>>mvn -Pdeveloper -pl developer -Ddeploydb
>>mvn -Pdeveloper -pl developer -Ddeploydb-simulator
>>mvn -pl client jetty:run -Dsimulator
>>
>> And finally run smoke tests (BVT):
>> nosetests --with-marvin --marvin-config=setup/dev/advanced.cfg --with-
>> xunit --xunit-file=/tmp/bvt_selfservice_cases.xml -a
>> tags=advanced,required_hardware=false -w test/integration/smoke --
>> hypervisor=simulator
>>
>> It currently took 50 mins on my setup. How can we speed it up, say by
>> reducing global variable timeout settings etc? Should we reduce timeouts etc.
>> in deploydb-simulator specific sql files?
>
> There several places we can improve the marvin test:
> 1. queryAsyncJob waits 5 second for each call, can change to 1s.
> 2. There are hardcoded sleep in test code, such base.py, search time.sleep
> 3. global configuration: account.cleanup.interval sets to 600s, so the test 
> suite will stop for 10 minutes after running for a while.
> 3. most importantly, if we can run the test cases in parallel, then speedup 
> should be great. Does anybody try to run it in parallel before?
>
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +41 779015219 | rohit.ya...@shapeblue.com
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>
>>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design & Build> build//>
>> CSForge - rapid IaaS deployment
>> framework
>> CloudStack Consulting
>> CloudStack Infrastructure Support> infrastructure-support/>
>> CloudStack Bootcamp Training Courses> training/>
>>
>> This email and any attachments to it may be confidential and are intended
>> solely for the use of the individual to whom it is addressed. Any views or
>> opinions expressed are solely those of the author and do not necessarily
>> represent those of Shape Blue Ltd or related companies. If you are not the
>> intended recipient of this email, you must neither take any action based
>> upon its contents, nor copy or show it to anyone. Please contact the sender 
>> if
>> you believe you have received this email in error. Shape Blue Ltd is a
>> company incorporated in England & Wales. ShapeBlue Services India LLP is a
>> company incorporated in India and is operated under license from Shape
>> Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in
>> Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty
>> Ltd is a company registered by The Republic of South Africa and is traded
>> under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab




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

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Infrastructure 
Support

Re: [VOTE] git workflow

[Rohit Yadav]

Comments in-line;

On 31-Jul-2014, at 11:03 pm, Alena Prokharchyk  
wrote:

> Done, updated the wiki page with my comments. Copy/pasting here:
>
> Open items:
> 1) Which bugs can be submitted to develop branch directly.
> Document http://nvie.com/posts/a-successful-git-branching-model/ mentions
> that the
> *hotfix branch should be created for the blocker/critical bugs in the
> current production release. What about bugs happenning in the *release(the
> one that hasn't been released yet)/*develop
> branches ? Should we fix them directly in those branches, or should we
> branch out off the *release
> branch, fix the problem, and merge the fix to *release?

As per nvie;

once cut out release branches should only have bugfixes. So, bugfixes can 
directly land on release branch and then cherry-picked or merge to the develop 
branch.

For bugs on develop branch, the commits can land directly on the develop branch 
or can be worked in a branch checked out from develop and when done merged back.

In my opinion, for any case developers should not work on any of the branches 
(master, release, develop) directly but checkout branch and work on it and 
merge back (or cherry-pick or squash merge) to respective branch only when 
their work is complete, with unit tests and validated using unit testing and 
smoke tests (BVT).

> We should decide:
> for which bugs the hot fix branch should be cut, and which fixes can go
> directly to *develop/*release branches. This criteria has to be defined in
> the doc, and be based on the a) bug severity b) number of people who work
> on the bug - if more than one, then we cut the new branch c)
> feedback/review is needed for the bug d) anything else?

What you suggest is fine. I think couple of areas which can qualify for 
bugfixes (hotfixes) would be related to security, database changes, systemvms, 
agent, hypervisor, network, storage, anything that could be considered a 
blocker.

I’m not sure but I think adopting nvie could possibly affect our release 
process, I would let PMC and experienced RMs to comment on this issue and if 
they would like any modifications to the release process?

On twitter I asked @nvie if he would have any change in the nvie model, he has 
a short reply:
https://twitter.com/nvie/status/494870892917563393

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab




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

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

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

Re: [VOTE] git workflow

[Alena Prokharchyk]

Thank you, Rohit. Couple more things we have to clarify in the wiki. The
doc says "Developer should run the BVT on the simulator before doing a
checkin², but it doesn¹t mention anything about the CI. So here are my
questions:
 
1) CI execution

* on which branches we are planning to run the CI
* with what frequency

2) Reverting the fixes breaking the CI - are we planning to do it? If so,
would it be done automatically after CI run, or developer should do it
himself?


-Alena.

On 7/31/14, 4:28 PM, "Rohit Yadav"  wrote:

>Comments in-line;
>
>On 31-Jul-2014, at 11:03 pm, Alena Prokharchyk
> wrote:
>
>> Done, updated the wiki page with my comments. Copy/pasting here:
>>
>> Open items:
>> 1) Which bugs can be submitted to develop branch directly.
>> Document http://nvie.com/posts/a-successful-git-branching-model/
>>mentions
>> that the
>> *hotfix branch should be created for the blocker/critical bugs in the
>> current production release. What about bugs happenning in the
>>*release(the
>> one that hasn't been released yet)/*develop
>> branches ? Should we fix them directly in those branches, or should we
>> branch out off the *release
>> branch, fix the problem, and merge the fix to *release?
>
>As per nvie;
>
>once cut out release branches should only have bugfixes. So, bugfixes can
>directly land on release branch and then cherry-picked or merge to the
>develop branch.
>
>For bugs on develop branch, the commits can land directly on the develop
>branch or can be worked in a branch checked out from develop and when
>done merged back.
>
>In my opinion, for any case developers should not work on any of the
>branches (master, release, develop) directly but checkout branch and work
>on it and merge back (or cherry-pick or squash merge) to respective
>branch only when their work is complete, with unit tests and validated
>using unit testing and smoke tests (BVT).
>
>> We should decide:
>> for which bugs the hot fix branch should be cut, and which fixes can go
>> directly to *develop/*release branches. This criteria has to be defined
>>in
>> the doc, and be based on the a) bug severity b) number of people who
>>work
>> on the bug - if more than one, then we cut the new branch c)
>> feedback/review is needed for the bug d) anything else?
>
>What you suggest is fine. I think couple of areas which can qualify for
>bugfixes (hotfixes) would be related to security, database changes,
>systemvms, agent, hypervisor, network, storage, anything that could be
>considered a blocker.
>
>I¹m not sure but I think adopting nvie could possibly affect our release
>process, I would let PMC and experienced RMs to comment on this issue and
>if they would like any modifications to the release process?
>
>On twitter I asked @nvie if he would have any change in the nvie model,
>he has a short reply:
>https://twitter.com/nvie/status/494870892917563393
>
>Regards,
>Rohit Yadav
>Software Architect, ShapeBlue
>M. +41 779015219 | rohit.ya...@shapeblue.com
>Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
>
>Find out more about ShapeBlue and our range of CloudStack related services
>
>IaaS Cloud Design &
>Build
>CSForge ­ rapid IaaS deployment framework
>CloudStack Consulting
>CloudStack 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.

Jenkins build is back to normal : build-master #1281

[jenkins]

See 

Re: [PROPOSAL] systemvm upgrade process

[Sheng Yang]

In fact we're think about the ultimate solution for it.
Utilize deb repo.

But we haven't got time to implement it yet. Hope we can get this idea on
track soon.

--Sheng


On Thu, Jul 31, 2014 at 12:52 PM, Pierre-Luc Dion 
wrote:

> since 4.3 the management-server can tell if systemvm and VR require
> upgrade, which is great !  but, as of 4.4  it's not working anymore and
>  systemvm must be upgrade as well.
>
> And what if their is another hartbleed issue between release requiring
> upgrade of systemvm ?
>
> Citrix is providing a Python script to CloudPlatform in order to upgrade
> the systemvm template to a latest 4.3from jun 2014, which is not bad.
> but...
>
>
> Doing automatic upgrade of system vm is out of scope because of implicated
> downtime.
>
> But could it be possible to implement a naming standard of systemvm
> template so the management server would detect a newer version of template
> and ask for upgrade of systemvm  and VR?
>
> Something like if I have those systemvm templates:
> - SystemVM Template (XenServer)
> - systemvm-xenserver-4.3
> - systemvm-xenserver-4.4
>
> right now in 4.4  it will use systemvm-xenserver-4.3 template which is not
> working with acs4.4.
>
> Could the detection of a new template be automated?  like if I have to
> upgrade to a newer version withing 4.4, like  systemvm-xenserver-4.4.1 ?
>
> or
>
> Could it be simple to have a Global setting where we define the
> systemvm-template to use and by default it would be SystemVM Template (*) ?
>
> unless something like that is already in place?
>
> Thanks,
>
> PL
>

Re: [VOTE] git workflow

[Sheng Yang]

On Thu, Jul 31, 2014 at 4:28 PM, Rohit Yadav 
wrote:

> Comments in-line;
>
> On 31-Jul-2014, at 11:03 pm, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
>
> > Done, updated the wiki page with my comments. Copy/pasting here:
> >
> > Open items:
> > 1) Which bugs can be submitted to develop branch directly.
> > Document http://nvie.com/posts/a-successful-git-branching-model/
> mentions
> > that the
> > *hotfix branch should be created for the blocker/critical bugs in the
> > current production release. What about bugs happenning in the
> *release(the
> > one that hasn't been released yet)/*develop
> > branches ? Should we fix them directly in those branches, or should we
> > branch out off the *release
> > branch, fix the problem, and merge the fix to *release?
>
> As per nvie;
>
> once cut out release branches should only have bugfixes. So, bugfixes can
> directly land on release branch and then cherry-picked or merge to the
> develop branch.
>
> For bugs on develop branch, the commits can land directly on the develop
> branch or can be worked in a branch checked out from develop and when done
> merged back.
>
> In my opinion, for any case developers should not work on any of the
> branches (master, release, develop) directly but checkout branch and work
> on it and merge back (or cherry-pick or squash merge) to respective branch
> only when their work is complete, with unit tests and validated using unit
> testing and smoke tests (BVT).
>

Work need to be tested, but create one branch for every bug seems over
doing. Branch in Git suppose to use with substantial changes. I don't think
anyone would like the idea to have 2 commits for every bug fixes(one merge
commit and one real fix). And it's not the case in the original model as
well.

Patch can be tested by other ways, e.g. upload patches to test system, or
introduce e.g. gerrit, which can integrated with Jenkins to run test on
specific review commit, without commit it to the repo, which I really like
to recommended to enforce the testing. Simply branching out wouldn't mean
you would test it.

--Sheng


>
> > We should decide:
> > for which bugs the hot fix branch should be cut, and which fixes can go
> > directly to *develop/*release branches. This criteria has to be defined
> in
> > the doc, and be based on the a) bug severity b) number of people who work
> > on the bug - if more than one, then we cut the new branch c)
> > feedback/review is needed for the bug d) anything else?
>
> What you suggest is fine. I think couple of areas which can qualify for
> bugfixes (hotfixes) would be related to security, database changes,
> systemvms, agent, hypervisor, network, storage, anything that could be
> considered a blocker.
>
> I’m not sure but I think adopting nvie could possibly affect our release
> process, I would let PMC and experienced RMs to comment on this issue and
> if they would like any modifications to the release process?
>
> On twitter I asked @nvie if he would have any change in the nvie model, he
> has a short reply:
> https://twitter.com/nvie/status/494870892917563393
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
>
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India LLP is a
> company incorporated in India and is operated under license from Shape Blue
> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is
> a company registered by The Republic of South Africa and is traded under
> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>

RE: Building of Hyper-V Agent seems broken in 4.4 branch

[Devdeep Singh]

Taking a look at it. Maybe a cherry-pick from 4.4-forward to 4.4 was missed.

Regards,
Devdeep

> -Original Message-
> From: Erik Weber [mailto:terbol...@gmail.com]
> Sent: Thursday, July 31, 2014 9:18 PM
> To: dev
> Subject: Building of Hyper-V Agent seems broken in 4.4 branch
> 
> 4.4.0 tag is working correctly, as is master branch.
> 
> Any fix or advice appreciated.
> 
> 
> Erik
> 
> -- compile output 
> 
>  Target CoreCompile:
> Tool C:\PROGRA~2\MONO-3~1.3\bin\mcs.bat
> execution started with arguments: /noconfig /debug:full /debug+ /optimize-
> /out:obj\Debug\HypervResource.dll CloudStackTypes.cs IWmiCallsV2.cs
> WmiCallsV2.cs Properties\AssemblyInfo.cs HypervResourceController.cs
> Utils.cs /target:library /define:"DEBUG;TRACE"
> /reference:..\packages\AWSSDK.1.5.23.0\lib\AWSSDK.dll
> /reference:..\packages\DotNetZip.1.9.1.8\lib\net20\Ionic.Zip.dll
> /reference:..\packages\log4net.2.0.0\lib\net40-full\log4net.dll
> /reference:..\packages\Newtonsoft.Json.4.5.11\lib\net40\Newtonsoft.Json.
> dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Configura
> tion.dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Managem
> ent.dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Net.Http.
> dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Web.dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Web.Http
> .dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Xml.Linq.
> dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Data.Data
> SetExtensions.dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\Microsoft.CSharp.
> dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Data.dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Xml.dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Core.dll
> /reference:C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\Serve
> rResource\WmiWrappers\bin\Debug\\WmiWrappers.dll
> /warn:4
> WmiCallsV2.cs(336,27): error CS0117: `HypervResource.Utils' does not
> contain a definition for `ConnectToRemote'
> Utils.cs(32,18): (Location of the symbol 
> related to previous
> error)
> WmiCallsV2.cs(2448,69): error CS0103: The name `jobObj' does not exist in
> the current context
> HypervResourceController.cs(239,31): error CS0117: `HypervResource.Utils'
> does not contain a definition for `ConnectToRemote'
> Utils.cs(32,18): (Location of the symbol 
> related to previous
> error)
> HypervResourceController.cs(250,35): error CS0117: `HypervResource.Utils'
> does not contain a definition for `ConnectToRemote'
> Utils.cs(32,18): (Location of the symbol 
> related to previous
> error)
> HypervResourceController.cs(992,27): error CS0117: `HypervResource.Utils'
> does not contain a definition for `ConnectToRemote'
> Utils.cs(32,18): (Location of the symbol 
> related to previous
> error)
> HypervResourceController.cs(1284,31): error CS0117: `HypervResource.Utils'
> does not contain a definition for `ConnectToRemote'
> Utils.cs(32,18): (Location of the symbol 
> related to previous
> error)
> HypervResourceController.cs(1560,39): error CS0117: `HypervResource.Utils'
> does not contain a definition for `ConnectToRemote'
> Utils.cs(32,18): (Location of the symbol 
> related to previous
> error)
> HypervResourceController.cs(1567,35): error CS0117: `HypervResource.Utils'
> does not contain a definition for `ConnectToRemote'
> Utils.cs(32,18): (Location of the symbol 
> related to previous
> error)
> Task "Csc" execution -- FAILED
> Done building target "CoreCompile" in project
> "C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\ServerResource\
> HypervResource\HypervResource.csproj".--
> FAILED
> Done building project
> "C:\source\cloudstack\plugins\hypervisors\

RE: Building of Hyper-V Agent seems broken in 4.4 branch

[Anshul Gangwar]

The commits are not applied in correct order.

This commit 8fb89cdc8e2dff60d49fecd3e51a9bf997061035 is applied after 
ef0cec938165fdf3531f92dc8f4c2930ff95fa5e. The later commit has resolve 
conflicts in cherry-picking. It was not resolved correctly which introduces 
this build failure.

Regards,
Anshul 

-Original Message-
From: Devdeep Singh [mailto:devdeep.si...@citrix.com] 
Sent: Friday, August 01, 2014 10:01 AM
To: dev@cloudstack.apache.org
Subject: RE: Building of Hyper-V Agent seems broken in 4.4 branch

Taking a look at it. Maybe a cherry-pick from 4.4-forward to 4.4 was missed.

Regards,
Devdeep

> -Original Message-
> From: Erik Weber [mailto:terbol...@gmail.com]
> Sent: Thursday, July 31, 2014 9:18 PM
> To: dev
> Subject: Building of Hyper-V Agent seems broken in 4.4 branch
> 
> 4.4.0 tag is working correctly, as is master branch.
> 
> Any fix or advice appreciated.
> 
> 
> Erik
> 
> -- compile output 
> 
>  Target CoreCompile:
> Tool 
> C:\PROGRA~2\MONO-3~1.3\bin\mcs.bat
> execution started with arguments: /noconfig /debug:full /debug+ 
> /optimize- /out:obj\Debug\HypervResource.dll CloudStackTypes.cs 
> IWmiCallsV2.cs WmiCallsV2.cs Properties\AssemblyInfo.cs 
> HypervResourceController.cs Utils.cs /target:library /define:"DEBUG;TRACE"
> /reference:..\packages\AWSSDK.1.5.23.0\lib\AWSSDK.dll
> /reference:..\packages\DotNetZip.1.9.1.8\lib\net20\Ionic.Zip.dll
> /reference:..\packages\log4net.2.0.0\lib\net40-full\log4net.dll
> /reference:..\packages\Newtonsoft.Json.4.5.11\lib\net40\Newtonsoft.Json.
> dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Config
> ura
> tion.dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Manage
> m
> ent.dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Net.Http.
> dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Web.dl
> l
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Web.Ht
> tp
> .dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Xml.Linq.
> dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Data.D
> ata
> SetExtensions.dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\Microsoft.CSharp.
> dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Data.d
> ll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Xml.dl
> l
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Core.d
> ll 
> /reference:C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\Serv
> e rResource\WmiWrappers\bin\Debug\\WmiWrappers.dll
> /warn:4
> WmiCallsV2.cs(336,27): error CS0117: `HypervResource.Utils' does not 
> contain a definition for `ConnectToRemote'
> Utils.cs(32,18): (Location of the 
> symbol related to previous
> error)
> WmiCallsV2.cs(2448,69): error CS0103: The name `jobObj' does not exist 
> in the current context
> HypervResourceController.cs(239,31): error CS0117: `HypervResource.Utils'
> does not contain a definition for `ConnectToRemote'
> Utils.cs(32,18): (Location of the 
> symbol related to previous
> error)
> HypervResourceController.cs(250,35): error CS0117: `HypervResource.Utils'
> does not contain a definition for `ConnectToRemote'
> Utils.cs(32,18): (Location of the 
> symbol related to previous
> error)
> HypervResourceController.cs(992,27): error CS0117: `HypervResource.Utils'
> does not contain a definition for `ConnectToRemote'
> Utils.cs(32,18): (Location of the 
> symbol related to previous
> error)
> HypervResourceController.cs(1284,31): error CS0117: `HypervResource.Utils'
> does not contain a definition for `ConnectToRemote'
> Utils.cs(32,18): (Location of the 
> symbol related to previous
> error)
> HypervResourceController.cs(1560,39): error CS0117: `HypervResource.Utils'
> does not contain a definition for `ConnectToRemote'
> Utils.cs(32,18): (Location of the 
> symbol related to previous
> error)
> HypervResourceCon

Review Request 24174: CLOUDSTACK-7220: fixed hyper-v agent broken in 4.4 branch

[Anshul Gangwar]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24174/
---

Review request for cloudstack, daan Hoogland and Devdeep Singh.


Bugs: CLOUDSTACK-7220
https://issues.apache.org/jira/browse/CLOUDSTACK-7220


Repository: cloudstack-git


Description
---

the commits were not applied in correct order while cherry picking from 
4.4-forward to 4.4


Diffs
-

  
plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/HypervResourceController.cs
 0ad95b8 
  plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/WmiCallsV2.cs 
2f404ff 

Diff: https://reviews.apache.org/r/24174/diff/


Testing
---

verified building on my local setup


Thanks,

Anshul Gangwar

RE: Building of Hyper-V Agent seems broken in 4.4 branch

[Anshul Gangwar]

I have created the patch https://reviews.apache.org/r/24174/ to fix the issue.
Is it ok to go ahead and commit it into 4.4 branch?

Regards,
Anshul

-Original Message-
From: Anshul Gangwar [mailto:anshul.gang...@citrix.com] 
Sent: Friday, August 01, 2014 10:22 AM
To: dev@cloudstack.apache.org
Subject: RE: Building of Hyper-V Agent seems broken in 4.4 branch

The commits are not applied in correct order.

This commit 8fb89cdc8e2dff60d49fecd3e51a9bf997061035 is applied after 
ef0cec938165fdf3531f92dc8f4c2930ff95fa5e. The later commit has resolve 
conflicts in cherry-picking. It was not resolved correctly which introduces 
this build failure.

Regards,
Anshul 

-Original Message-
From: Devdeep Singh [mailto:devdeep.si...@citrix.com]
Sent: Friday, August 01, 2014 10:01 AM
To: dev@cloudstack.apache.org
Subject: RE: Building of Hyper-V Agent seems broken in 4.4 branch

Taking a look at it. Maybe a cherry-pick from 4.4-forward to 4.4 was missed.

Regards,
Devdeep

> -Original Message-
> From: Erik Weber [mailto:terbol...@gmail.com]
> Sent: Thursday, July 31, 2014 9:18 PM
> To: dev
> Subject: Building of Hyper-V Agent seems broken in 4.4 branch
> 
> 4.4.0 tag is working correctly, as is master branch.
> 
> Any fix or advice appreciated.
> 
> 
> Erik
> 
> -- compile output 
> 
>  Target CoreCompile:
> Tool
> C:\PROGRA~2\MONO-3~1.3\bin\mcs.bat
> execution started with arguments: /noconfig /debug:full /debug+
> /optimize- /out:obj\Debug\HypervResource.dll CloudStackTypes.cs 
> IWmiCallsV2.cs WmiCallsV2.cs Properties\AssemblyInfo.cs 
> HypervResourceController.cs Utils.cs /target:library /define:"DEBUG;TRACE"
> /reference:..\packages\AWSSDK.1.5.23.0\lib\AWSSDK.dll
> /reference:..\packages\DotNetZip.1.9.1.8\lib\net20\Ionic.Zip.dll
> /reference:..\packages\log4net.2.0.0\lib\net40-full\log4net.dll
> /reference:..\packages\Newtonsoft.Json.4.5.11\lib\net40\Newtonsoft.Json.
> dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Config
> ura
> tion.dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Manage
> m
> ent.dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Net.Http.
> dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Web.dl
> l
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Web.Ht
> tp
> .dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Xml.Linq.
> dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Data.D
> ata
> SetExtensions.dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\Microsoft.CSharp.
> dll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Data.d
> ll
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Xml.dl
> l
> /reference:C:\PROGRA~2\MONO-3~1.3\lib\mono\4.5\..\xbuild-
> frameworks\.NETFramework\v4.5\RedistList\..\..\..\..\4.5\System.Core.d
> ll
> /reference:C:\source\cloudstack\plugins\hypervisors\hyperv\DotNet\Serv
> e rResource\WmiWrappers\bin\Debug\\WmiWrappers.dll
> /warn:4
> WmiCallsV2.cs(336,27): error CS0117: `HypervResource.Utils' does not 
> contain a definition for `ConnectToRemote'
> Utils.cs(32,18): (Location of the 
> symbol related to previous
> error)
> WmiCallsV2.cs(2448,69): error CS0103: The name `jobObj' does not exist 
> in the current context
> HypervResourceController.cs(239,31): error CS0117: `HypervResource.Utils'
> does not contain a definition for `ConnectToRemote'
> Utils.cs(32,18): (Location of the 
> symbol related to previous
> error)
> HypervResourceController.cs(250,35): error CS0117: `HypervResource.Utils'
> does not contain a definition for `ConnectToRemote'
> Utils.cs(32,18): (Location of the 
> symbol related to previous
> error)
> HypervResourceController.cs(992,27): error CS0117: `HypervResource.Utils'
> does not contain a definition for `ConnectToRemote'
> Utils.cs(32,18): (Location of the 
> symbol related to previous
> error)
> HypervResourceController.cs(1284,31): error CS0117: `HypervResource.Utils'
> does not contain a definition for `ConnectToRemote'

RE: How to speed up testing using BVT/smoke tests with Simulator

[Santhosh Edukulla]

1. yes, test cases currently run in parallel in ci environment, using parallel 
nose commands.

2. There were few  hard codings for sleep, where we removed at some places, 
still there could be few\many out there.

3. 1 sec sleep and poll check is too heavy i believe, for async. So, worst a 
test case can add time of execution by 5 seconds more, compared to succesful 
operation time. 

Santhosh

From: Rohit Yadav [rohit.ya...@shapeblue.com]
Sent: Thursday, July 31, 2014 7:15 PM
To: dev@cloudstack.apache.org
Subject: Re: How to speed up testing using BVT/smoke tests with Simulator

Hi Edison,

Thanks for the pointers! I’ll try them out and see if there is way to do it on 
Travis/CloudBees as well and I hope other people will religiously start using 
simulator/bvt (at least the basic ones) for their check-ins.

Regards.

On 01-Aug-2014, at 12:15 am, Edison Su  wrote:

>
>
>> -Original Message-
>> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
>> Sent: Thursday, July 31, 2014 5:12 AM
>> To: dev@cloudstack.apache.org
>> Subject: How to speed up testing using BVT/smoke tests with Simulator
>>
>> Hi,
>>
>> Santosh put together a good wiki page on how to validate local changes using
>> our Python/marvin based build verification tests (path:
>> test/integration/smoke):
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check
>> -ins+for+your+local+changes%2C+using+Simulator
>>
>> I've a mini PC for this and using CloudStack 4.4.0 to build/test CloudStack
>> 4.4/master branch on it in a VM. Some of us are also exploring free/cheap CI
>> services such as Travis, CloudBees etc. which can be used by developers to
>> test their check-ins. If anyone of you have tried something like this please
>> share.
> Today, I tried to build and test CloudStack on a super powerful machine 
> provided by Azure. Imaging, build & test on a 16 Cores, 120G machine, it 
> should be awesome, and most importantly, it's FREE. You can get a free MSDN 
> subscription 
> fromhttps://svn.apache.org/repos/private/committers/donated-licenses/msdn-subscription.html,
>  after that, you will get $150 credit monthly in Azure. For build &test only, 
> $150 is good enough.
>
>>
>> This is how I build CloudStack for validating with simulator:
>>mvn -Pdeveloper -Dsimulator clean install
>>mvn -Pdeveloper -pl developer -Ddeploydb
>>mvn -Pdeveloper -pl developer -Ddeploydb-simulator
>>mvn -pl client jetty:run -Dsimulator
>>
>> And finally run smoke tests (BVT):
>> nosetests --with-marvin --marvin-config=setup/dev/advanced.cfg --with-
>> xunit --xunit-file=/tmp/bvt_selfservice_cases.xml -a
>> tags=advanced,required_hardware=false -w test/integration/smoke --
>> hypervisor=simulator
>>
>> It currently took 50 mins on my setup. How can we speed it up, say by
>> reducing global variable timeout settings etc? Should we reduce timeouts etc.
>> in deploydb-simulator specific sql files?
>
> There several places we can improve the marvin test:
> 1. queryAsyncJob waits 5 second for each call, can change to 1s.
> 2. There are hardcoded sleep in test code, such base.py, search time.sleep
> 3. global configuration: account.cleanup.interval sets to 600s, so the test 
> suite will stop for 10 minutes after running for a while.
> 3. most importantly, if we can run the test cases in parallel, then speedup 
> should be great. Does anybody try to run it in parallel before?
>
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +41 779015219 | rohit.ya...@shapeblue.com
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>
>>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design & Build> build//>
>> CSForge - rapid IaaS deployment
>> framework
>> CloudStack Consulting
>> CloudStack Infrastructure Support> infrastructure-support/>
>> CloudStack Bootcamp Training Courses> training/>
>>
>> This email and any attachments to it may be confidential and are intended
>> solely for the use of the individual to whom it is addressed. Any views or
>> opinions expressed are solely those of the author and do not necessarily
>> represent those of Shape Blue Ltd or related companies. If you are not the
>> intended recipient of this email, you must neither take any action based
>> upon its contents, nor copy or show it to anyone. Please contact the sender 
>> if
>> you believe you have received this email in error. Shape Blue Ltd is a
>> company incorporated in England & Wales. ShapeBlue Services India LLP is a
>> company incorporated in India and is operated under license from Shape
>> Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in
>> Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty
>> Ltd is a company r

Re: Review Request 24111: Coverity findings for brocade-plugin

[Santhosh Edukulla]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24111/#review49323
---



plugins/network-elements/brocade-vcs/src/com/cloud/network/brocade/BrocadeVcsApi.java


It seems there is no corresponding catch here, did compilation worked?


- Santhosh Edukulla


On July 31, 2014, 5:57 p.m., Ritu  Sabharwal wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24111/
> ---
> 
> (Updated July 31, 2014, 5:57 p.m.)
> 
> 
> Review request for cloudstack and Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-6823
> https://issues.apache.org/jira/browse/CLOUDSTACK-6823
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixed Coverity findings for brocade-plugin
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/api/response/BrocadeVcsDeviceResponse.java
>  60edbcf 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/network/brocade/BrocadeVcsApi.java
>  d5f06f8 
> 
> Diff: https://reviews.apache.org/r/24111/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ritu  Sabharwal
> 
>

Error while building CloudStack

[Priyanka Deepala]

Hiii
  I'm building CS in DevCloud in VitualBox. While building the CS using
  mvn-P developer,systemvm clean install command it's
displaying an error. I attached the screenshot of error in .png image
could someone please help out regarding this issue?

Error while building Cloudstack

[Priyanka Deepala]

Hiii
  I'm building CS in DevCloud in VitualBox. While building the CS using
  mvn-P developer,systemvm clean install command it's
displaying an error. I attached the screenshot of error in .png image
could someone please help out regarding this issue?