Re: Review Request 24696: Only attempt to shrink volume in test if CLVM is in use

[SrikanteswaraRao Talluri]

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

Ship it!


Ship It!

- SrikanteswaraRao Talluri


On Sept. 2, 2014, 1:38 p.m., John Dilley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24696/
> ---
> 
> (Updated Sept. 2, 2014, 1:38 p.m.)
> 
> 
> Review request for cloudstack, Santhosh Edukulla and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-7228
> https://issues.apache.org/jira/browse/CLOUDSTACK-7228
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Currently only CLVM supports shrinking volumes. This patch will only attempt 
> to shrink a volume if CLVM is in use.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_volumes.py e2e0d76 
> 
> Diff: https://reviews.apache.org/r/24696/diff/
> 
> 
> Testing
> ---
> 
> Tested on XenServer to check that the test now passes.
> 
> 
> Thanks,
> 
> John Dilley
> 
>

Re: Review Request 24696: Only attempt to shrink volume in test if CLVM is in use

[SrikanteswaraRao Talluri]

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


Pushed to master : 9b783d19ad7e784d3751f4eaa2a672401d122a01

- SrikanteswaraRao Talluri


On Sept. 2, 2014, 1:38 p.m., John Dilley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24696/
> ---
> 
> (Updated Sept. 2, 2014, 1:38 p.m.)
> 
> 
> Review request for cloudstack, Santhosh Edukulla and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-7228
> https://issues.apache.org/jira/browse/CLOUDSTACK-7228
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Currently only CLVM supports shrinking volumes. This patch will only attempt 
> to shrink a volume if CLVM is in use.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_volumes.py e2e0d76 
> 
> Diff: https://reviews.apache.org/r/24696/diff/
> 
> 
> Testing
> ---
> 
> Tested on XenServer to check that the test now passes.
> 
> 
> Thanks,
> 
> John Dilley
> 
>

Re: Cherry-picking fix that may change 4.3.1 schema

[Sebastien Goasguen]

On Sep 2, 2014, at 11:59 PM, Rajani Karuturi  wrote:

> this was to your suggestion of "a separate tool that does (rolling)
> upgrades" which i think is a new proposal. I should have made it clear in
> my mail about it and should have started it with "right way according to
> me".
> 
> "right way to do things" is in no way against iterative development. May be
> at a stage one would realise it was not the right way.
> 
> Anyways, thanks for the gyan. I would stay away from any such discussions
> in future.
> 

Please don't. Discussion is important and sometimes they are hard.

We are dealing with several important changes right now (git, CI, db, releases 
etc..) and we need to keep at it.

Folks will have different opinions and express them differently but we need to 
keep discussing to make progress :)

> ~Rajani
> 
> 
> On Tue, Sep 2, 2014 at 9:26 PM, Rohit Yadav 
> wrote:
> 
>> 
>> On 02-Sep-2014, at 5:40 pm, Rajani Karuturi  wrote:
>>> The right way to do this is to do commit to commit migrations and use
>> some
>>> db versioning tools like liquibase or flywaydb which will execute the new
>>> change sets. We discussed this before and IIRC, someone started working
>> on
>>> it.
>> 
>> This is not a proposal thread to introduce new tools and I would certainly
>> avoid the “right way to do things” as I’m a fan of iterative development.
>> 
>> I’m interested in a concrete solution to the concrete issue I raised.
>> Here’s how I will do it:
>> 
>> - Fix the issue on 4.3.1, cherry pick and get rid of the 4.3.0 to 4.4.0
>> upgrade path
>> - Put the db changes in upgrade path from 4.3.0 to 4.3.1, on 4.3 branch
>> - Add an upgrade path from 4.3.1 to 4.4.1 on 4.4 branch which counts for
>> the above change
>> - On 4.4 branch, in the upgrade (db upgrader) map there won’t be an
>> upgrade path from 4.3.1 for any class except for the map entry where
>> version is 4.3.1
>> - Users who upgrade to 4.3.1 can upgrade only to 4.4.1 (they don’t have a
>> choice) and the upgrade path will exist only in 4.4.1 and later releases
>> 
>> I think if I do the above, no one will have any issue. I’m sharing them to
>> run by you all in case you find any issue?
>> 
>>> 
>>> 
>>> On Tue, Sep 2, 2014 at 20:58 PM, Rohit Yadav 
>>> wrote:
>>> 
>>> 
>>> On 02-Sep-2014, at 5:07 pm, Francois Gaudreault <
>> fgaudrea...@cloudops.com
>>> > wrote:
 I see. Well, I think we were impacted by that too, and we made the
>>> decision to move on 4.4.1-snap (even if it's technically less stable?)
>> and
>>> then upgrade to 4.4.1 GA (next week?)
 
 I personally don't think pulling back DB changes in lower releases is a
>>> good idea :S
 
 But that's only my opinion :)
>>> 
>>> I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like
>> to
>>> stick to that only. I understand there are too many numbers, versions and
>>> branches to follow, so please if you can try to understand the issue;
>>> 
>>> This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756
>> requires
>>> that there are some extra columns in the database to do book keeping when
>>> delete ips so you don’t actually delete db/table rows.
>>> 
>>> The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
>>> 
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
>>> 
>>> But, we already have 4.4.0 release and db upgrade paths are always in the
>>> next release versions.
>>> 
>>> So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does
>> not
>>> care about 4.4.0 schema changes. There is only an upgrade path from 4.3.0
>>> to 4.3.1. So, the limitation is that people won’t be able to upgrade from
>>> 4.3.1 to 4.4.0, because 4.4.0 is already released.
>>> 
>>> If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can
>> put
>>> the fix from the JIRA issue on 4.3 branch so the issue is fixed for
>> 4.3.1.
>>> The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we release
>>> 4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.1 on 4.4
>>> branch such that
>>> 
>>> The abstract issue is — we’ll have such issue in future, how do we fix
>> it.
>>> I suggested — we make a separate tool that does (rolling) upgrades.
>>> 
>>> 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/

Jenkins build is back to normal : build-master-noredist #3443

[jenkins]

See 

Commit cd8af6a

[Hugo Trippaers]

Min,

I’m checking some findbugs reports and found the following piece of code in 
VolumeDataStoreVO (line 352):

public void setRefCnt(Long refCnt) {
if (refCnt > 0) {
refCnt--;
}
else {
s_logger.warn("We should not try to decrement a zero reference 
count even though our code has guarded");
}
}


This doesn’t seem to make a lot of sense to me as the refCnt field doesn’t get 
set in this function. Could you have a look as you committed this and might 
know what the intended behavior is?

Cheers,

Hugo

Re: Cherry-picking fix that may change 4.3.1 schema

[Sebastien Goasguen]

On Sep 2, 2014, at 11:28 AM, Rohit Yadav  wrote:

> 
> On 02-Sep-2014, at 5:07 pm, Francois Gaudreault  
> wrote:
>> I see. Well, I think we were impacted by that too, and we made the decision 
>> to move on 4.4.1-snap (even if it's technically less stable?) and then 
>> upgrade to 4.4.1 GA (next week?)
>> 
>> I personally don't think pulling back DB changes in lower releases is a good 
>> idea :S
>> 
>> But that's only my opinion :)
> 
> I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like to 
> stick to that only. I understand there are too many numbers, versions and 
> branches to follow, so please if you can try to understand the issue;

I think Francois understands the issue (in terms of the bug been talked about), 
and his solution has been to move to 4.4.1-snap. It is a different type of 
solution than a solution at the code/release level but if it works for 
him..fine :)

> 
> This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756 requires 
> that there are some extra columns in the database to do book keeping when 
> delete ips so you don’t actually delete db/table rows.
> 
> The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
> 
> But, we already have 4.4.0 release and db upgrade paths are always in the 
> next release versions.
> 
> So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does not 
> care about 4.4.0 schema changes. There is only an upgrade path from 4.3.0 to 
> 4.3.1. So, the limitation is that people won’t be able to upgrade from 4.3.1 
> to 4.4.0, because 4.4.0 is already released.
> 
> If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can put 
> the fix from the JIRA issue on 4.3 branch so the issue is fixed for 4.3.1. 
> The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we release 4.4.1 
> after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.1 on 4.4 branch 
> such that
> 
> The abstract issue is — we’ll have such issue in future, how do we fix it. I 
> suggested — we make a separate tool that does (rolling) upgrades.
> 

So two things:

-How to fix now
-How to fix later (if we want to keep some type of long term release branches)

I am ready to release 4.3.1 so if we put an upgrade path from 4.3.1 to 4.4.1 , 
that's fine with me, especially if there is precedent of database changes in 
the 4.2.x series.

> 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 still unstable: simulator-singlerun #270

[jenkins]

See 

Re: Cherry-picking fix that may change 4.3.1 schema

[Daan Hoogland]

4.3.1 to 4.4.1 then should contain all effort that is also in 4.3.0 to 4.4.0

I don't look forward to the work but it is doable.

What bothers me most is that we are putting so much enegy into 4.3.1 at the
moment while 4.4.1 is about to be rc'd.

--
an anonymous commit to commit upgrade advocate / release manager


On Wed, Sep 3, 2014 at 9:39 AM, Sebastien Goasguen  wrote:

>
> On Sep 2, 2014, at 11:28 AM, Rohit Yadav 
> wrote:
>
> >
> > On 02-Sep-2014, at 5:07 pm, Francois Gaudreault <
> fgaudrea...@cloudops.com> wrote:
> >> I see. Well, I think we were impacted by that too, and we made the
> decision to move on 4.4.1-snap (even if it's technically less stable?) and
> then upgrade to 4.4.1 GA (next week?)
> >>
> >> I personally don't think pulling back DB changes in lower releases is a
> good idea :S
> >>
> >> But that's only my opinion :)
> >
> > I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like
> to stick to that only. I understand there are too many numbers, versions
> and branches to follow, so please if you can try to understand the issue;
>
> I think Francois understands the issue (in terms of the bug been talked
> about), and his solution has been to move to 4.4.1-snap. It is a different
> type of solution than a solution at the code/release level but if it works
> for him..fine :)
>
> >
> > This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756
> requires that there are some extra columns in the database to do book
> keeping when delete ips so you don’t actually delete db/table rows.
> >
> > The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
> >
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
> >
> > But, we already have 4.4.0 release and db upgrade paths are always in
> the next release versions.
> >
> > So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does
> not care about 4.4.0 schema changes. There is only an upgrade path from
> 4.3.0 to 4.3.1. So, the limitation is that people won’t be able to upgrade
> from 4.3.1 to 4.4.0, because 4.4.0 is already released.
> >
> > If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can
> put the fix from the JIRA issue on 4.3 branch so the issue is fixed for
> 4.3.1. The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we
> release 4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.1
> on 4.4 branch such that
> >
> > The abstract issue is — we’ll have such issue in future, how do we fix
> it. I suggested — we make a separate tool that does (rolling) upgrades.
> >
>
> So two things:
>
> -How to fix now
> -How to fix later (if we want to keep some type of long term release
> branches)
>
> I am ready to release 4.3.1 so if we put an upgrade path from 4.3.1 to
> 4.4.1 , that's fine with me, especially if there is precedent of database
> changes in the 4.2.x series.
>
> > 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.
>
>


-- 
Daan

Jenkins build is still unstable: simulator-singlerun #271

[jenkins]

See 

Review Request 25292: CLOUDSTACK-6898: [Hyper-V] fixed rdp console freezing during reboot.

[Anshul Gangwar]

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

Review request for cloudstack and Devdeep Singh.


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


Repository: cloudstack-git


Description
---



Console was freezing because we read data from socket in blocking mode.
During reboot it was blocking infintely.
To fix issue, now we are reading data in non-blocking mode.
In non-blocking mode I set the timeout to 5 seconds.


Diffs
-

  services/console-proxy-rdp/rdpconsole/src/main/java/streamer/SyncLink.java 
94281d2 
  
services/console-proxy-rdp/rdpconsole/src/main/java/streamer/apr/AprSocketSource.java
 0298349 

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


Testing
---

tested console is working fine during reboot. Now it freezes 5-6 seconds before 
becoming responsive again.


Thanks,

Anshul Gangwar

Re: Review Request 25289: CLOUDSTACK-7474-Failed-to-start-MS-with-java7-version

[Rajani Karuturi]

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



client/tomcatconf/classpath.conf.in


Can we get the JAVA_HOME from installed java instead of hardcoding it? The 
path may be different for different os versions or distributions. 

something similar to what we already did at 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=c468228fe807c621decc5919dadae9bcbb38c753

May we should move this to a common file like setenv.sh and use it 
everywhere.


- Rajani Karuturi


On Sept. 3, 2014, 6:25 a.m., Rayees Namathponnan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25289/
> ---
> 
> (Updated Sept. 3, 2014, 6:25 a.m.)
> 
> 
> Review request for cloudstack, Frank Zhang and Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-7474
> https://issues.apache.org/jira/browse/CLOUDSTACK-7474
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Step 1: Deploy new RHEL 6.3 machine
> Step 2 : Install MS
> Step 3: run deploy script and start MS
> 
> Result 
> 
> Installation completed successfully,  both java7 and java got installed as 
> part of MS installation, but MS failed to start java version erro
> 
> we need to load java7 while start MS
> 
> 
> Diffs
> -
> 
>   client/tomcatconf/classpath.conf.in 3ae0fb4 
> 
> Diff: https://reviews.apache.org/r/25289/diff/
> 
> 
> Testing
> ---
> 
> Yes
> 
> 
> Thanks,
> 
> Rayees Namathponnan
> 
>

Jenkins build is still unstable: simulator-singlerun #272

[jenkins]

See 

Review Request 25293: Test script to verify vm deployment with two networks in SG enabled advanced zone

[sanjeev n]

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

Review request for cloudstack, suresh sadhu, Santhosh Edukulla, and 
SrikanteswaraRao Talluri.


Repository: cloudstack-git


Description
---

Test script to verify vm deployment with two networks in SG enabled advanced 
zone.
Involves following steps:
1.Deploy SG enabled advanced zone with only 4 ip addresses in guest ip range 
using simulator
2.Deploy one guest vm in the default shared guest network so that all the IP 
addresses will be consumed
3.Add another guest network in the zone created at step1
4.Deploy vm without passing the network id. It should pick the network with 
sufficient resources


Diffs
-

  test/integration/component/test_advancedsg_networks.py 85ab697 
  tools/marvin/marvin/config/test_data.py b658b01 

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


Testing
---

@Desc: VM Cannot deploy to second network in advanced SG network ... === 
TestName: test_34_DeployVM_in_SecondSGNetwork | Status : SUCCESS ===
ok

--
Ran 1 test in 343.198s

OK


Thanks,

sanjeev n

Re: Cherry-picking fix that may change 4.3.1 schema

[Sebastien Goasguen]

On Sep 3, 2014, at 4:32 AM, Daan Hoogland  wrote:

> 4.3.1 to 4.4.1 then should contain all effort that is also in 4.3.0 to 4.4.0
> 
> I don't look forward to the work but it is doable.
> 
> What bothers me most is that we are putting so much enegy into 4.3.1 at the
> moment while 4.4.1 is about to be rc'd.

Who is putting energy in 4.3.1 ? me a bit, and Rohit+Ian who helped with Travis 
(even though it's not 4.3.1 specific).

I am more concerned about the energy spent cleaning up a release branch which 
never benefits the next release...

-sebastien

> 
> --
> an anonymous commit to commit upgrade advocate / release manager
> 
> 
> On Wed, Sep 3, 2014 at 9:39 AM, Sebastien Goasguen  wrote:
> 
>> 
>> On Sep 2, 2014, at 11:28 AM, Rohit Yadav 
>> wrote:
>> 
>>> 
>>> On 02-Sep-2014, at 5:07 pm, Francois Gaudreault <
>> fgaudrea...@cloudops.com> wrote:
 I see. Well, I think we were impacted by that too, and we made the
>> decision to move on 4.4.1-snap (even if it's technically less stable?) and
>> then upgrade to 4.4.1 GA (next week?)
 
 I personally don't think pulling back DB changes in lower releases is a
>> good idea :S
 
 But that's only my opinion :)
>>> 
>>> I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like
>> to stick to that only. I understand there are too many numbers, versions
>> and branches to follow, so please if you can try to understand the issue;
>> 
>> I think Francois understands the issue (in terms of the bug been talked
>> about), and his solution has been to move to 4.4.1-snap. It is a different
>> type of solution than a solution at the code/release level but if it works
>> for him..fine :)
>> 
>>> 
>>> This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756
>> requires that there are some extra columns in the database to do book
>> keeping when delete ips so you don’t actually delete db/table rows.
>>> 
>>> The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
>>> 
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
>>> 
>>> But, we already have 4.4.0 release and db upgrade paths are always in
>> the next release versions.
>>> 
>>> So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does
>> not care about 4.4.0 schema changes. There is only an upgrade path from
>> 4.3.0 to 4.3.1. So, the limitation is that people won’t be able to upgrade
>> from 4.3.1 to 4.4.0, because 4.4.0 is already released.
>>> 
>>> If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can
>> put the fix from the JIRA issue on 4.3 branch so the issue is fixed for
>> 4.3.1. The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we
>> release 4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.1
>> on 4.4 branch such that
>>> 
>>> The abstract issue is — we’ll have such issue in future, how do we fix
>> it. I suggested — we make a separate tool that does (rolling) upgrades.
>>> 
>> 
>> So two things:
>> 
>> -How to fix now
>> -How to fix later (if we want to keep some type of long term release
>> branches)
>> 
>> I am ready to release 4.3.1 so if we put an upgrade path from 4.3.1 to
>> 4.4.1 , that's fine with me, especially if there is precedent of database
>> changes in the 4.2.x series.
>> 
>>> 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 c

Jenkins build is still unstable: simulator-singlerun #273

[jenkins]

See 

Re: Clarification on github or and TravisCI

[Sebastien Goasguen]

On Sep 2, 2014, at 12:31 PM, Stephen Turner  wrote:

> So just to be clear, Sebastien, does that mean it's acceptable for 
> non-committers to submit their code for review via a Github pull request, 
> instead of using ReviewBoard? (I hope so: I think that will make the process 
> easier and so encourage contributions).
> 

It's doable but have not yet discussed and voted if we wanted to make it an 
official mechanism.

(so here, now you are confused :) )

> -- 
> Stephen Turner
> 
> 
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com] 
> Sent: 02 September 2014 17:19
> To: dev@cloudstack.apache.org
> Subject: Clarification on github or and TravisCI
> 
> As some of you may have noticed github PR has been turned on for our main 
> repo (it was already the case for the docs repo).
> 
> In addition, TravisCI config files have been added to master and 4.3 (not yet 
> for 4.4).
> 
> https://travis-ci.org/apache/cloudstack/builds
> 
> The Travis jobs, compile cloudstack and deploy the simulator to run the smoke 
> tests.
> 
> This is an *experimentation* to see how we can change our commit mechanism 
> (pr vs. RB) as well as add CI for every commit.
> We moved forward with this without a proposal or former vote to get a feel 
> for it and see if it could help.
> 
> Basically, every pr from a personal fork of cloudstack will trigger a Travis 
> job and the PR will show the Travis job status. 
> The main idea of course being that if the tests pass they we can merge.
> 
> I personally see it as an addition to Jenkins jobs not a replacement and a 
> quick way to get free CI while we get our act together with a real infra.
> 
> Comments and help (with tests and travis config) welcome, of course feel free 
> to start sending pr that way knowing that this is still an experiment.
> 
> ps: thanks to Ian and Rohit for getting it working.
> 
> -sebastien

RE: Realhostip service extended till Sep 30th

[Mihaela Stoica]

If you are using the latest cloudstack build from master or 4.4 branch, you can 
upload custom certificates via the UI, instead of invoking the 
UploadCustomCertificate API directly.

We changed the "SSL Certificate" dialog to allow uploading chained SSL 
certificates, see 
CLOUDSTACK-6695.



Thanks,

Mihaela



-Original Message-
From: Nitin Mehta [mailto:nitin.me...@citrix.com]
Sent: 02 September 2014 22:26
To: dev@cloudstack.apache.org; Animesh Chaturvedi; us...@cloudstack.apache.org; 
users...@cloudstack.apache.org
Cc: Amogh Vasekar
Subject: Re: Realhostip service extended till Sep 30th



Created another wiki [1] for troubleshooting and information on the 
implementation details.

[1]

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Troubleshooting+-+up

loading+custom+domain+certificate+instead+of+using+realhostip.com







Thanks,

-Nitin



On 05/06/14 7:03 PM, "Nitin Mehta" 
mailto:nitin.me...@citrix.com>> wrote:



>Please find wiki [1] containing the procedure to replace realhostip.com

>with Your own custom domain name.

>

>[1]

>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Procedure+to+Replac

>e

>+realhostip.com+with+Your+Own+Domain+Name

>

>

>Thanks,

>-Nitin

>

>On 05/06/14 4:23 PM, "Animesh Chaturvedi" 
>mailto:animesh.chaturv...@citrix.com>>

>wrote:

>

>>

>>Folks

>>

>>I wanted to provide an update on shutting down of RealhostIp service.

>>Citrix has decided to move the date by one quarter and the new date will

>>be Sep 30th.  The new dates allow users of CloudStack additional time for

>>updating their infrastructure. While testing Realhostip fixes additional

>>product issues were found which are tracked in following three defects

>>CLOUDSTACK-6499 [1], CLOUDSTACK-6599 [2], CLOUDSTACK-6824 [3] . These

>>defects are fixed in 4.4 and master branch. Please verify in your setups.

>>If you are on older version of CloudStack do plan on upgrading to 4.4 .

>>Additional details on fixes are available in JIRA.  Updated wiki with

>>steps will be published shortly.

>>

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

>>[2] https://issues.apache.org/jira/browse/CLOUDSTACK-6599

>>[3] https://issues.apache.org/jira/browse/CLOUDSTACK-6824

>>

>>

>>Thanks

>>Animesh

>>

>>

>>

>>

>>> -Original Message-

>>> From: John Kinsella [mailto:j...@stratosec.co]

>>> Sent: Thursday, April 17, 2014 8:35 AM

>>> To: mailto:us...@cloudstack.apache.org>>; 
>>> users...@cloudstack.apache.org;

>>> mailto:dev@cloudstack.apache.org>>

>>> Subject: REMINDER RealhostIP going away

>>>

>>> Reminder, folks - please migrate off RealhostIP.com or you¹re going to

>>>get a

>>> nasty surprise this summer. More info at link below.

>>>

>>>

>>>https://blogs.apache.org/cloudstack/entry/RealhostIP_service_is_being_re

>>>t

>>> ired

>

Re: Clarification on github or and TravisCI

[Ian Duffy]

> It's doable but have not yet discussed and voted if we wanted to make it
an official mechanism.

Would love to see it happen. I recall review board being a massive pain
point for a few reasons:

1) Large patches fail to upload, especially if they contain images. I
recall sending many patches by email
2) Manual merging for the committer. Its a stage for extra mistake. Github
will instantly inform you if an auto merge can be completed.
3) CI on each request. (Huge quality gain.)


On 3 September 2014 11:56, Sebastien Goasguen  wrote:

>
> On Sep 2, 2014, at 12:31 PM, Stephen Turner 
> wrote:
>
> > So just to be clear, Sebastien, does that mean it's acceptable for
> non-committers to submit their code for review via a Github pull request,
> instead of using ReviewBoard? (I hope so: I think that will make the
> process easier and so encourage contributions).
> >
>
> It's doable but have not yet discussed and voted if we wanted to make it
> an official mechanism.
>
> (so here, now you are confused :) )
>
> > --
> > Stephen Turner
> >
> >
> > -Original Message-
> > From: Sebastien Goasguen [mailto:run...@gmail.com]
> > Sent: 02 September 2014 17:19
> > To: dev@cloudstack.apache.org
> > Subject: Clarification on github or and TravisCI
> >
> > As some of you may have noticed github PR has been turned on for our
> main repo (it was already the case for the docs repo).
> >
> > In addition, TravisCI config files have been added to master and 4.3
> (not yet for 4.4).
> >
> > https://travis-ci.org/apache/cloudstack/builds
> >
> > The Travis jobs, compile cloudstack and deploy the simulator to run the
> smoke tests.
> >
> > This is an *experimentation* to see how we can change our commit
> mechanism (pr vs. RB) as well as add CI for every commit.
> > We moved forward with this without a proposal or former vote to get a
> feel for it and see if it could help.
> >
> > Basically, every pr from a personal fork of cloudstack will trigger a
> Travis job and the PR will show the Travis job status.
> > The main idea of course being that if the tests pass they we can merge.
> >
> > I personally see it as an addition to Jenkins jobs not a replacement and
> a quick way to get free CI while we get our act together with a real infra.
> >
> > Comments and help (with tests and travis config) welcome, of course feel
> free to start sending pr that way knowing that this is still an experiment.
> >
> > ps: thanks to Ian and Rohit for getting it working.
> >
> > -sebastien
>
>

Re: Clarification on github or and TravisCI

[Erik Weber]

On Wed, Sep 3, 2014 at 1:15 PM, Ian Duffy  wrote:

> > It's doable but have not yet discussed and voted if we wanted to make it
> an official mechanism.
>
> Would love to see it happen. I recall review board being a massive pain
> point for a few reasons:
>
>
+1
as a non-committer it is far easier to cope with the github way of doing
things.

-- 
Erik

API calls and keys

[Giri Prasad]

Hello,

 I am using a html/php script to read in userid, password and domain id from 
the user.  Using CloudStackClient.php, I am able to call most of the api's, 
like list vm's, and the output seems correct.

 And I want to use some API's via   like:

http://XXX.XXX.XXX.5:8080/client/api?command=startVirtualMachine&id=----
http://XXX.XXX.XXX.5:8080/client/api?command=stopVirtualMachine&id=----
http://XXX.XXX.XXX.5:8080/client/console?cmd=access&vm=----

I need to add dynamically the apikey and signature:

&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ
&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D

since apikey and signature are required, are there, any api's, where I can 
dynamically, get it from the CS infra, and use the return values, for building 
the apiKey and signature part of the url. 


I need to get the apikey and signature dynamically, for a specific user 
(userid/passwd), and then use it, for building the url.


Thanks & Regards,
Giri

Without apikeys and signature:
401unable to 
verify user credentials and/or request 
signature

console?cmd=access
Access denied. Invalid web session or API key in request

RE: jsonObj is not defined. UI development problem.

[Ilia Shakitko]

Hi Gabor,

Thank you very much for your reply. Yeah, I spent quite some time on it and 
it's not so straight forward. So it would be nice if contributor could assist 
us here.
I've tried to contact the main contributor for that file, but have no answer 
for quite long time :\

Very good find you made with the ACL rules tab, btw.


Kind regards,

Ilia Shakitko
Innovation Engineer
LeaseWeb Technologies B.V.

T: +31 20 316 0235
M:
E: i.shaki...@tech.leaseweb.com
W: http://www.leaseweb.com

Luttenbergweg 8, 1101 EC Amsterdam, The Netherlands


-Original Message-
From: Gabor Apati-Nagy [mailto:gabor.apati-n...@citrix.com]
Sent: maandag, 01 september, 2014 17:48
To: dev@cloudstack.apache.org
Subject: RE: jsonObj is not defined. UI development problem.

Hi Ilia,

I looked into this and although I did not try to make the changes myself, it 
turned out that the error you are getting is already there on the ACL rules tab.

I raised a Jira ticket for investigation. It seems to me that your solution 
should work as is, once the issue with "data: args.jsonObj.tags" is fixed.
I have not taken further steps but you are more than welcome to investigate 
this :)

I have filed the following bug for now:
https://issues.apache.org/jira/browse/CLOUDSTACK-7462

Cheers,
Gabor

-Original Message-
From: Ilia Shakitko [mailto:i.shaki...@tech.leaseweb.com]
Sent: 01 September 2014 13:52
To: dev@cloudstack.apache.org
Subject: RE: jsonObj is not defined. UI development problem.

Can somebody help me in that? I’ve tried to contact Jessica Wang (main changer 
in that ui part, but haven’t got an answer yet)


Kind regards,

Ilia Shakitko
Innovation Engineer
LeaseWeb Technologies B.V.

T: +31 20 316 0235

E: i.shaki...@tech.leaseweb.com
W: www.leaseweb.com

Luttenbergweg 8, 1101 EC Amsterdam, The Netherlands


From: Ilia Shakitko
Sent: woensdag, 27 augustus, 2014 11:54
To: dev@cloudstack.apache.org
Subject: jsonObj is not defined. UI development problem.

I am working on some ui changes in cloudstack. And I am adding some lines (to 
display tags for SecurityGroupRules) in network.js: line #4670 (before actions: 
{ destroy: { …  on line #4814):

tags: cloudStack.api.tags({
resourceType: 'SecurityGroupRule',
contextId: 'multiRule'
}),

I made it 1 to 1 with FirewallRule. But it doesn’t work. I spend quite a lot of 
time on trying to figure out why. It renders the window, but without anything: 
http://clip2net.com/s/iO0mAh (http://clip2net.com/s/iO0mWk) So as I understood 
debugging the code, it runs in issues in sharedFunctions.js file when it tries 
to read “jsonObj” but it’s empty (http://clip2net.com/s/iO0lwy). I couldn’t 
figure out why is it empty and where do I fill it with data from “context”…

Could you help me with correct direction? What am I missing? ☺


Kind regards,
Ilia Shakitko
Innovation Engineer
LeaseWeb Technologies B.V.

T: +31 20 316 0235

E: i.shaki...@tech.leaseweb.com
W: www.leaseweb.com

Luttenbergweg 8, 1101 EC Amsterdam, The Netherlands

Re: Cherry-picking fix that may change 4.3.1 schema

[David Nalley]

On Wed, Sep 3, 2014 at 3:02 AM, Sebastien Goasguen  wrote:
>
> On Sep 2, 2014, at 11:59 PM, Rajani Karuturi  wrote:
>
>> this was to your suggestion of "a separate tool that does (rolling)
>> upgrades" which i think is a new proposal. I should have made it clear in
>> my mail about it and should have started it with "right way according to
>> me".
>>
>> "right way to do things" is in no way against iterative development. May be
>> at a stage one would realise it was not the right way.
>>
>> Anyways, thanks for the gyan. I would stay away from any such discussions
>> in future.
>>
>
> Please don't. Discussion is important and sometimes they are hard.
>
> We are dealing with several important changes right now (git, CI, db, 
> releases etc..) and we need to keep at it.
>
> Folks will have different opinions and express them differently but we need 
> to keep discussing to make progress :)
>

Yes; please - don't stop discussing such things.
Occasionally there are disagreements and there are frustrations, but
thats part of the process; such discussions are valuable.

--David

Re: Clarification on github or and TravisCI

[David Nalley]

On Wed, Sep 3, 2014 at 7:15 AM, Ian Duffy  wrote:
>> It's doable but have not yet discussed and voted if we wanted to make it
> an official mechanism.
>
> Would love to see it happen. I recall review board being a massive pain
> point for a few reasons:
>
> 1) Large patches fail to upload, especially if they contain images. I
> recall sending many patches by email
> 2) Manual merging for the committer. Its a stage for extra mistake. Github
> will instantly inform you if an auto merge can be completed.
> 3) CI on each request. (Huge quality gain.)
>

Even better if we move to RTC - and every patch/commit hits that workflow.

--David

Re: Review Request 25187: test_delete_account and test_releaseIP failing in advanced zone

[Alex Brett]

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

(Updated Sept. 3, 2014, 3:17 p.m.)


Review request for cloudstack, Ashutosh Kelkar, Santhosh Edukulla, and 
SrikanteswaraRao Talluri.


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


Repository: cloudstack-git


Description
---

CLOUDSTACK-4840 changed test_data.py to make the lbrule publicport be 22,
instead of . In doing so, this caused the following tests to fail, as they
hit a problem where they tried to use port 22 for both the lbrule and for other
purposes:
integration.smoke.test_network.TestDeleteAccount.test_delete_account
integration.smoke.test_network.TestReleaseIP.test_releaseIP

The reason the change appears to have been made was that in
test_lb_secondary_ip.py, despite setting up the load balancer using lbrule, the
tests then used the SSH port from natrule to try and access the VM. By changing
lbrule to use port 22 (the same as natrule) this avoided the problem.

This patch updates test_lb_secondary_ip.py to use the SSH port in lbrule where
necessary to access the VMs, and reverts the change to test_data.py


Diffs
-

  test/integration/component/test_lb_secondary_ip.py f54caa6 
  tools/marvin/marvin/config/test_data.py fca2442 

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


Testing
---

Ran tests in test_lb_secondary_ip.py with changes in place, verified results 
equivalent to those seen on regular regression runs.
Ran test_delete_account and test_releaseIP to verify these now pass as expected.


Thanks,

Alex Brett

Re: API calls and keys

[abhisek basu]

You need to generate the signature; sample code us here: 
http://abhisekbasu.wordpress.com/2013/11/19/how-to-generate-signature-for-cloudstack-api/

You may also consider using login api in your scenario.

Sent from my iPhone

> On 3 Sep 2014, at 8:11 pm, "Giri Prasad"  wrote:
> 
> Hello,
> 
> I am using a html/php script to read in userid, password and domain id from 
> the user.  Using CloudStackClient.php, I am able to call most of the api's, 
> like list vm's, and the output seems correct.
> 
> And I want to use some API's via   like:
> 
> http://XXX.XXX.XXX.5:8080/client/api?command=startVirtualMachine&id=----
> http://XXX.XXX.XXX.5:8080/client/api?command=stopVirtualMachine&id=----
> http://XXX.XXX.XXX.5:8080/client/console?cmd=access&vm=----
> 
> I need to add dynamically the apikey and signature:
> 
> &apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ
> &signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
> 
> since apikey and signature are required, are there, any api's, where I can 
> dynamically, get it from the CS infra, and use the return values, for 
> building the apiKey and signature part of the url. 
> 
> 
> I need to get the apikey and signature dynamically, for a specific user 
> (userid/passwd), and then use it, for building the url.
> 
> 
> Thanks & Regards,
> Giri
> 
> Without apikeys and signature:
>  cloud-stack-version="4.1.1">401unable to 
> verify user credentials and/or request 
> signature
> 
> console?cmd=access
> Access denied. Invalid web session or API key in request

Review Request 25301: CLOUDSTACK-7442: Fixed template permission issue in test_project_resources.py

[Gaurav Aradhye]

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

Review request for cloudstack, sanjeev n, Santhosh Edukulla, and 
SrikanteswaraRao Talluri.


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


Repository: cloudstack-git


Description
---

The template was registered with admin api client, hence it failed to find the 
project in the domain while updating the permissions.

The permissions can only be updated if the resource is present in the same 
domain as that of the owner account of the template.

Registered the template with the api client of the account in which the project 
is added, so that the permissions for template can  successfully be updated for 
the project.


Diffs
-

  test/integration/component/test_project_resources.py e769860 

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


Testing
---

Yes.

Log:
Test use of private template in a project ... === TestName: 
test_05_use_private_template_in_project | Status : SUCCESS ===
ok

--
Ran 1 test in 674.081s

OK


Thanks,

Gaurav Aradhye

Re: Commit cd8af6a

[Min Chen]

Thanks Hugo for pointing that out. That is a bug caused by copy-and-paste,
the code should be in decrRefCnt routine like other SnapshotDataStoreVO
and TemplateDataStoreVO.
I will fix this in a minute.

-min


On 9/3/14 12:30 AM, "Hugo Trippaers"  wrote:

>Min,
>
>I¹m checking some findbugs reports and found the following piece of code
>in VolumeDataStoreVO (line 352):
>
>public void setRefCnt(Long refCnt) {
>if (refCnt > 0) {
>refCnt--;
>}
>else {
>s_logger.warn("We should not try to decrement a zero
>reference count even though our code has guarded");
>}
>}
>
>
>This doesn¹t seem to make a lot of sense to me as the refCnt field
>doesn¹t get set in this function. Could you have a look as you committed
>this and might know what the intended behavior is?
>
>Cheers,
>
>Hugo

wiki on systemvm.iso

[Nitin Mehta]

I created a short write up on systemvm.iso to the best of my knowledge. 
Devs/Users can use this to understand how systemvm.iso is propagated and use it 
to debug their setup.
Since its propagation depends on each hypervisor I might have missed few things 
so please review and correct it.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/SystemVm.iso

Thanks,
-Nitin

Cloudstack Build Failed

[Deepal Jayasekara]

Hi All,
 We are working on a cloudstack based project named "Resource Aware and
Policy Based VM Scheduling in Medium-scale Clouds". Our group is really new
to Cloudstack and currently trying to build and install cloudstack from
source. We followed the documentation at docs.cloudstack.apache.org and
tried building from source. But we encountered a build error with maven,
but could not identify what caused the error. We really appreciate if
anybody can help us fix this issue as soon as possible. I guess this error
comes from a maven plugin, but have no idea what causes this and how to
solve this issue. We tried to install this on Ubuntu 14.04 with tomcat6 and
8 as well as with openjdk6 and oracle-jdk-8. We have also tried to install
on Ubuntu 12.04 with tomcat6 and openjdk6. Any help would be highly
appreciated.

Thank you.

-- 
___
[image: photo]
*Deepal Jayasekara*
Undergraduate, Department Of Computer Science And Engineering
University of Moratuwa, Sri Lanka
| mobile: +94712070097  | blog: *insiderattack.blogspot.com
*
   

Cloudstack Build Failing

[Deepal Jayasekara]

Hi All,

We are working on a cloudstack based project named "Resource Aware and
Policy Based VM Scheduling in Medium-scale Clouds". Our group is really new
to Cloudstack and currently trying to build and install cloudstack from
source. We followed the documentation at docs.cloudstack.apache.org and
tried building from source. But we encountered a build error with maven,
but could not identify what caused the error.

Following question at stackoverflow shows the error we encountered with:
http://stackoverflow.com/questions/25646091/failed-to-execute-goal-org-codehaus-mojoexec-maven-plugin1-2-1exec

We really appreciate if anybody can help us fix this issue as soon as
possible. I guess this error comes from a maven plugin, but have no idea
what causes this and how to solve this issue. We tried to install this on
Ubuntu 14.04 with tomcat6 and 8 as well as with openjdk6 and oracle-jdk-8.
We have also tried to install on Ubuntu 12.04 with tomcat6 and openjdk6.
Any help would be highly appreciated.

Thank you

-- 
___
[image: photo]
*Deepal Jayasekara*
Undergraduate, Department Of Computer Science And Engineering
University of Moratuwa, Sri Lanka
| mobile: +94712070097  | blog: *insiderattack.blogspot.com
*
   

Re: Review Request 25235: vGPU service offering upgrade test automation

[sailaja mada]

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

(Updated Sept. 3, 2014, 6:12 p.m.)


Review request for cloudstack, Doug Clark, John Dilley, and Sanjay Tripathi.


Changes
---

Review comments are included.


Repository: cloudstack-git


Description
---

vGPU service offering upgrade test automation


Diffs (updated)
-

  test/integration/component/test_deploy_vgpu_vm.py eb0bade 

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


Testing (updated)
---

Yes. All the testcases are executed with XenServer hypervisor.


Thanks,

sailaja mada

Re: Commit cd8af6a

[Daan Hoogland]

H Min,

what is this fix for?


On Wed, Sep 3, 2014 at 8:20 PM, Min Chen  wrote:

> Fix is checked into master branch. Can I back port it to 4.4?
>
> Thanks
> -min
>
> On 9/3/14 9:42 AM, "Min Chen"  wrote:
>
> >Thanks Hugo for pointing that out. That is a bug caused by copy-and-paste,
> >the code should be in decrRefCnt routine like other SnapshotDataStoreVO
> >and TemplateDataStoreVO.
> >I will fix this in a minute.
> >
> >-min
> >
> >
> >On 9/3/14 12:30 AM, "Hugo Trippaers"  wrote:
> >
> >>Min,
> >>
> >>I¹m checking some findbugs reports and found the following piece of code
> >>in VolumeDataStoreVO (line 352):
> >>
> >>public void setRefCnt(Long refCnt) {
> >>if (refCnt > 0) {
> >>refCnt--;
> >>}
> >>else {
> >>s_logger.warn("We should not try to decrement a zero
> >>reference count even though our code has guarded");
> >>}
> >>}
> >>
> >>
> >>This doesn¹t seem to make a lot of sense to me as the refCnt field
> >>doesn¹t get set in this function. Could you have a look as you committed
> >>this and might know what the intended behavior is?
> >>
> >>Cheers,
> >>
> >>Hugo
> >
>
>


-- 
Daan

Re: Commit cd8af6a

[Min Chen]

Fix is checked into master branch. Can I back port it to 4.4?

Thanks
-min

On 9/3/14 9:42 AM, "Min Chen"  wrote:

>Thanks Hugo for pointing that out. That is a bug caused by copy-and-paste,
>the code should be in decrRefCnt routine like other SnapshotDataStoreVO
>and TemplateDataStoreVO.
>I will fix this in a minute.
>
>-min
>
>
>On 9/3/14 12:30 AM, "Hugo Trippaers"  wrote:
>
>>Min,
>>
>>I¹m checking some findbugs reports and found the following piece of code
>>in VolumeDataStoreVO (line 352):
>>
>>public void setRefCnt(Long refCnt) {
>>if (refCnt > 0) {
>>refCnt--;
>>}
>>else {
>>s_logger.warn("We should not try to decrement a zero
>>reference count even though our code has guarded");
>>}
>>}
>>
>>
>>This doesn¹t seem to make a lot of sense to me as the refCnt field
>>doesn¹t get set in this function. Could you have a look as you committed
>>this and might know what the intended behavior is?
>>
>>Cheers,
>>
>>Hugo
>

Re: Commit cd8af6a

[Min Chen]

This is a bug that will impact reference counting only for old volume on
NFS to S3 object store migration.

Thanks
-min

On 9/3/14 11:25 AM, "Daan Hoogland"  wrote:

>H Min,
>
>what is this fix for?
>
>
>On Wed, Sep 3, 2014 at 8:20 PM, Min Chen  wrote:
>
>> Fix is checked into master branch. Can I back port it to 4.4?
>>
>> Thanks
>> -min
>>
>> On 9/3/14 9:42 AM, "Min Chen"  wrote:
>>
>> >Thanks Hugo for pointing that out. That is a bug caused by
>>copy-and-paste,
>> >the code should be in decrRefCnt routine like other SnapshotDataStoreVO
>> >and TemplateDataStoreVO.
>> >I will fix this in a minute.
>> >
>> >-min
>> >
>> >
>> >On 9/3/14 12:30 AM, "Hugo Trippaers"  wrote:
>> >
>> >>Min,
>> >>
>> >>I¹m checking some findbugs reports and found the following piece of
>>code
>> >>in VolumeDataStoreVO (line 352):
>> >>
>> >>public void setRefCnt(Long refCnt) {
>> >>if (refCnt > 0) {
>> >>refCnt--;
>> >>}
>> >>else {
>> >>s_logger.warn("We should not try to decrement a zero
>> >>reference count even though our code has guarded");
>> >>}
>> >>}
>> >>
>> >>
>> >>This doesn¹t seem to make a lot of sense to me as the refCnt field
>> >>doesn¹t get set in this function. Could you have a look as you
>>committed
>> >>this and might know what the intended behavior is?
>> >>
>> >>Cheers,
>> >>
>> >>Hugo
>> >
>>
>>
>
>
>-- 
>Daan

Re: Commit cd8af6a

[Daan Hoogland]

guess you should go ahead and backport.


On Wed, Sep 3, 2014 at 8:28 PM, Min Chen  wrote:

> This is a bug that will impact reference counting only for old volume on
> NFS to S3 object store migration.
>
> Thanks
> -min
>
> On 9/3/14 11:25 AM, "Daan Hoogland"  wrote:
>
> >H Min,
> >
> >what is this fix for?
> >
> >
> >On Wed, Sep 3, 2014 at 8:20 PM, Min Chen  wrote:
> >
> >> Fix is checked into master branch. Can I back port it to 4.4?
> >>
> >> Thanks
> >> -min
> >>
> >> On 9/3/14 9:42 AM, "Min Chen"  wrote:
> >>
> >> >Thanks Hugo for pointing that out. That is a bug caused by
> >>copy-and-paste,
> >> >the code should be in decrRefCnt routine like other SnapshotDataStoreVO
> >> >and TemplateDataStoreVO.
> >> >I will fix this in a minute.
> >> >
> >> >-min
> >> >
> >> >
> >> >On 9/3/14 12:30 AM, "Hugo Trippaers"  wrote:
> >> >
> >> >>Min,
> >> >>
> >> >>I¹m checking some findbugs reports and found the following piece of
> >>code
> >> >>in VolumeDataStoreVO (line 352):
> >> >>
> >> >>public void setRefCnt(Long refCnt) {
> >> >>if (refCnt > 0) {
> >> >>refCnt--;
> >> >>}
> >> >>else {
> >> >>s_logger.warn("We should not try to decrement a zero
> >> >>reference count even though our code has guarded");
> >> >>}
> >> >>}
> >> >>
> >> >>
> >> >>This doesn¹t seem to make a lot of sense to me as the refCnt field
> >> >>doesn¹t get set in this function. Could you have a look as you
> >>committed
> >> >>this and might know what the intended behavior is?
> >> >>
> >> >>Cheers,
> >> >>
> >> >>Hugo
> >> >
> >>
> >>
> >
> >
> >--
> >Daan
>
>


-- 
Daan

Jenkins build is still unstable: simulator-singlerun #274

[jenkins]

See 

[REVIEW] CLOUDSTACK-7468 in master

[Will Stevens]

Here is a link to the issue:
https://issues.apache.org/jira/browse/CLOUDSTACK-7468

This fix has been committed in the 4.4 branch already.  I have pushed a
feature branch called 'CLOUDSTACK-7468' to the ASF repo which is a branch
off master with the fix applied.  The fix for master is here:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5d11385

I am not sure how the release manager is for 4.5, but can someone please
review and commit the fix into master?

Thanks,

*Will STEVENS*
Lead Developer

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

Jenkins build is still unstable: simulator-singlerun #275

[jenkins]

See 

Re: Review Request 25289: CLOUDSTACK-7474-Failed-to-start-MS-with-java7-version

[Frank Zhang]

> On Sept. 3, 2014, 9:32 a.m., Rajani Karuturi wrote:
> > client/tomcatconf/classpath.conf.in, line 37
> > 
> >
> > Can we get the JAVA_HOME from installed java instead of hardcoding it? 
> > The path may be different for different os versions or distributions. 
> > 
> > something similar to what we already did at 
> > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=c468228fe807c621decc5919dadae9bcbb38c753
> > 
> > May we should move this to a common file like setenv.sh and use it 
> > everywhere.

+1


- Frank


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


On Sept. 3, 2014, 6:25 a.m., Rayees Namathponnan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25289/
> ---
> 
> (Updated Sept. 3, 2014, 6:25 a.m.)
> 
> 
> Review request for cloudstack, Frank Zhang and Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-7474
> https://issues.apache.org/jira/browse/CLOUDSTACK-7474
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Step 1: Deploy new RHEL 6.3 machine
> Step 2 : Install MS
> Step 3: run deploy script and start MS
> 
> Result 
> 
> Installation completed successfully,  both java7 and java got installed as 
> part of MS installation, but MS failed to start java version erro
> 
> we need to load java7 while start MS
> 
> 
> Diffs
> -
> 
>   client/tomcatconf/classpath.conf.in 3ae0fb4 
> 
> Diff: https://reviews.apache.org/r/25289/diff/
> 
> 
> Testing
> ---
> 
> Yes
> 
> 
> Thanks,
> 
> Rayees Namathponnan
> 
>

Re: wiki on systemvm.iso

[Marcus]

Thank you for this. It has been a common question than many people have
just had to figure out.
On Sep 3, 2014 11:40 AM, "Nitin Mehta"  wrote:

> I created a short write up on systemvm.iso to the best of my knowledge.
> Devs/Users can use this to understand how systemvm.iso is propagated and
> use it to debug their setup.
> Since its propagation depends on each hypervisor I might have missed few
> things so please review and correct it.
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SystemVm.iso
>
> Thanks,
> -Nitin
>

Jenkins build is still unstable: simulator-singlerun #276

[jenkins]

See 

Re: Review Request 25289: CLOUDSTACK-7474-Failed-to-start-MS-with-java7-version

[Rayees Namathponnan]

> On Sept. 3, 2014, 9:32 a.m., Rajani Karuturi wrote:
> > client/tomcatconf/classpath.conf.in, line 37
> > 
> >
> > Can we get the JAVA_HOME from installed java instead of hardcoding it? 
> > The path may be different for different os versions or distributions. 
> > 
> > something similar to what we already did at 
> > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=c468228fe807c621decc5919dadae9bcbb38c753
> > 
> > May we should move this to a common file like setenv.sh and use it 
> > everywhere.
> 
> Frank Zhang wrote:
> +1

Hi Rajani,

I checked your change list, if your machine in running with default java 
version is 1.6,  this will always return 1.6 and management server will fails 
to start 


Even usage sever will be an issue in 4.5, if your machine is runnign with 
java1.6
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=packaging/centos63/cloud-usage.rc;h=8434e4d568a066d0766d055847725b1779eb33c4;hp=617037995755024a8c9d5e492bb56b7cc938e48f;hb=c468228fe807c621decc5919dadae9bcbb38c753;hpb=75c9a20c7773c268c02fb006d1a7820cb427c94c


Regards,
Rayees


- Rayees


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


On Sept. 3, 2014, 6:25 a.m., Rayees Namathponnan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25289/
> ---
> 
> (Updated Sept. 3, 2014, 6:25 a.m.)
> 
> 
> Review request for cloudstack, Frank Zhang and Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-7474
> https://issues.apache.org/jira/browse/CLOUDSTACK-7474
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Step 1: Deploy new RHEL 6.3 machine
> Step 2 : Install MS
> Step 3: run deploy script and start MS
> 
> Result 
> 
> Installation completed successfully,  both java7 and java got installed as 
> part of MS installation, but MS failed to start java version erro
> 
> we need to load java7 while start MS
> 
> 
> Diffs
> -
> 
>   client/tomcatconf/classpath.conf.in 3ae0fb4 
> 
> Diff: https://reviews.apache.org/r/25289/diff/
> 
> 
> Testing
> ---
> 
> Yes
> 
> 
> Thanks,
> 
> Rayees Namathponnan
> 
>

Jenkins build is still unstable: simulator-singlerun #277

[jenkins]

See 

Re: Review Request 25289: CLOUDSTACK-7474-Failed-to-start-MS-with-java7-version

[Alex Brett]

> On Sept. 3, 2014, 9:32 a.m., Rajani Karuturi wrote:
> > client/tomcatconf/classpath.conf.in, line 37
> > 
> >
> > Can we get the JAVA_HOME from installed java instead of hardcoding it? 
> > The path may be different for different os versions or distributions. 
> > 
> > something similar to what we already did at 
> > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=c468228fe807c621decc5919dadae9bcbb38c753
> > 
> > May we should move this to a common file like setenv.sh and use it 
> > everywhere.
> 
> Frank Zhang wrote:
> +1
> 
> Rayees Namathponnan wrote:
> Hi Rajani,
> 
> I checked your change list, if your machine in running with default java 
> version is 1.6,  this will always return 1.6 and management server will fails 
> to start 
> 
> 
> Even usage sever will be an issue in 4.5, if your machine is runnign with 
> java1.6
> 
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=packaging/centos63/cloud-usage.rc;h=8434e4d568a066d0766d055847725b1779eb33c4;hp=617037995755024a8c9d5e492bb56b7cc938e48f;hb=c468228fe807c621decc5919dadae9bcbb38c753;hpb=75c9a20c7773c268c02fb006d1a7820cb427c94c
> 
> 
> Regards,
> Rayees

To expand on this a little bit - in RHEL 6.3 if you have both Java 1.6 and Java 
7 installed, the default behaviour with the alternatives mechanism makes 1.6 
the default Java instance (you can manually set 1.7 as the default, but this is 
an extra step). This means that the management server / KVM agent then fail to 
work.

In 6.5 if you have both then by default Java 7 is used, and all works fine (not 
sure about 6.4 or 7, I've not tested them).


- Alex


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


On Sept. 3, 2014, 6:25 a.m., Rayees Namathponnan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25289/
> ---
> 
> (Updated Sept. 3, 2014, 6:25 a.m.)
> 
> 
> Review request for cloudstack, Frank Zhang and Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-7474
> https://issues.apache.org/jira/browse/CLOUDSTACK-7474
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Step 1: Deploy new RHEL 6.3 machine
> Step 2 : Install MS
> Step 3: run deploy script and start MS
> 
> Result 
> 
> Installation completed successfully,  both java7 and java got installed as 
> part of MS installation, but MS failed to start java version erro
> 
> we need to load java7 while start MS
> 
> 
> Diffs
> -
> 
>   client/tomcatconf/classpath.conf.in 3ae0fb4 
> 
> Diff: https://reviews.apache.org/r/25289/diff/
> 
> 
> Testing
> ---
> 
> Yes
> 
> 
> Thanks,
> 
> Rayees Namathponnan
> 
>

Jenkins build is still unstable: simulator-singlerun #278

[jenkins]

See 

Re: Review Request 25289: CLOUDSTACK-7474-Failed-to-start-MS-with-java7-version

[David Nalley]

On Wed, Sep 3, 2014 at 7:40 PM, Alex Brett  wrote:
>
>
>> On Sept. 3, 2014, 9:32 a.m., Rajani Karuturi wrote:
>> > client/tomcatconf/classpath.conf.in, line 37
>> > 
>> >
>> > Can we get the JAVA_HOME from installed java instead of hardcoding it? 
>> > The path may be different for different os versions or distributions.
>> >
>> > something similar to what we already did at 
>> > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=c468228fe807c621decc5919dadae9bcbb38c753
>> >
>> > May we should move this to a common file like setenv.sh and use it 
>> > everywhere.
>>
>> Frank Zhang wrote:
>> +1
>>
>> Rayees Namathponnan wrote:
>> Hi Rajani,
>>
>> I checked your change list, if your machine in running with default java 
>> version is 1.6,  this will always return 1.6 and management server will 
>> fails to start
>>
>>
>> Even usage sever will be an issue in 4.5, if your machine is runnign 
>> with java1.6
>> 
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=packaging/centos63/cloud-usage.rc;h=8434e4d568a066d0766d055847725b1779eb33c4;hp=617037995755024a8c9d5e492bb56b7cc938e48f;hb=c468228fe807c621decc5919dadae9bcbb38c753;hpb=75c9a20c7773c268c02fb006d1a7820cb427c94c
>>
>>
>> Regards,
>> Rayees
>
> To expand on this a little bit - in RHEL 6.3 if you have both Java 1.6 and 
> Java 7 installed, the default behaviour with the alternatives mechanism makes 
> 1.6 the default Java instance (you can manually set 1.7 as the default, but 
> this is an extra step). This means that the management server / KVM agent 
> then fail to work.
>
> In 6.5 if you have both then by default Java 7 is used, and all works fine 
> (not sure about 6.4 or 7, I've not tested them).
>
>
>

Perhaps we add a Conflicts with java 1.6 - it would be somewhat ugly,
and if you run into it  you would need to know to yum remove, but that
would keep you from having an installation at all rather than
expecting it to work and trying to debug.

Re: Review Request 24882: CLOUDSTACK-6282 - Added skip condition when hypervisor is hyper-v for tests which are not applicable for hyper-v

[Alex Brett]

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



test/integration/component/test_escalations_ipaddresses.py


Is there a reason for making this change - getHypervisorInfo is generally 
what is used elsewhere rather than the hypervisor property of services?

(getHypervisorInfo has the benefit that if we ever need to start testing 
mixed clouds we can make sure it returns the type we want this particular test 
to run on, rather than the single value in services)



test/integration/component/test_escalations_isos.py


I don't see anything from cloudstackException or SshClient being used in 
this file - any reason to add imports for them?



test/integration/component/test_escalations_isos.py


Other things in the file use PASS from marvin.codes so this should still be 
imported.



test/integration/component/test_escalations_isos.py


This will break unless you change the existing usages of time.sleep to just 
sleep (personally I'd leave it as import time though).



test/integration/component/test_escalations_isos.py


Not your bug, but the wording here is poor - should probably be "Not enough 
zones exist to copy iso" or similar.


- Alex Brett


On Aug. 20, 2014, 4:22 a.m., Vinay Varma wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24882/
> ---
> 
> (Updated Aug. 20, 2014, 4:22 a.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6282
> https://issues.apache.org/jira/browse/CLOUDSTACK-6282
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6282 - Added skip condition when hypervisor is hyper-v for tests 
> which are not applicable for hyper-v
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_escalations_instances.py 1b72b2f 
>   test/integration/component/test_escalations_ipaddresses.py 6c9b24b 
>   test/integration/component/test_escalations_isos.py a0fa333 
>   test/integration/component/test_escalations_networks.py 56f61b4 
>   test/integration/component/test_escalations_snapshots.py af493a1 
>   test/integration/component/test_escalations_volumes.py d1dae12 
> 
> Diff: https://reviews.apache.org/r/24882/diff/
> 
> 
> Testing
> ---
> 
> Executed the tests and attached are the log files for each of the files 
> changed.
> 
> 
> File Attachments
> 
> 
> InstancesResults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/08/20/4ac84a27-fc7c-4b8c-9509-d75a350b53a3__InstancesResults.txt
> IPAddressesResults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/08/20/14aad713-9256-44ed-a9e2-d7225c5c975c__IPAddressesResults.txt
> IsoResults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/08/20/516de1c8-09d0-4e07-abe4-3483463750c3__IsoResults.txt
> SnapshotsResults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/08/20/46f2a6c3-f0f7-4397-918e-bb8df1d63e97__SnapshotsResults.txt
> VolumeResults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/08/20/28d59100-315b-45e8-9aaa-b60982571637__VolumeResults.txt
> NetworksResults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/08/20/869b26e2-9fc2-44cf-bbc1-fc13fd60bc58__NetworksResults.txt
> 
> 
> Thanks,
> 
> Vinay Varma
> 
>

RE: Review Request 25289: CLOUDSTACK-7474-Failed-to-start-MS-with-java7-version

[Alex Brett]

On 04 September 2014 00:45, David Nalley [da...@gnsa.us] wrote:
> On Wed, Sep 3, 2014 at 7:40 PM, Alex Brett  wrote:
>> To expand on this a little bit - in RHEL 6.3 if you have both Java 1.6 and 
>> Java 7 installed, the default behaviour with the alternatives mechanism 
>> makes 1.6 the default Java instance (you can manually set 1.7 as the 
>> default, but this is an extra step). This means that the management server / 
>> KVM agent then fail to work.
>>
>> In 6.5 if you have both then by default Java 7 is used, and all works fine 
>> (not sure about 6.4 or 7, I've not tested them).
>>
>
> Perhaps we add a Conflicts with java 1.6 - it would be somewhat ugly,
> and if you run into it  you would need to know to yum remove, but that
> would keep you from having an installation at all rather than
> expecting it to work and trying to debug.
>

I'd have thought this would prove problematic over upgrade - as you'd have a 
conflict that the new version would need to have 1.6 removed, but you can't do 
that without removing your old version first. There's also the issue of if the 
user wants to have both around for other tools they're running on the same 
machine.

Some solutions that don't break upgrade that I can see are:
* Rayees change in the review to point directly at Java 7, with the caveat that 
this might have some cross platform issues
* Somehow automating the alternatives mechanism, i.e. doing a check as part of 
management server startup somewhere that if the default Java is 1.6, setting it 
to be Java 7 (which we know should be installed by the RPM dependencies) - a 
little ugly as we are changing a user's default underneath them, and may also 
have cross platform issues
* Require use of 6.5 (or possibly 6.4 if the version that has works) instead of 
6.3 - we do already say to install all hotfixes etc, which in theory means 
people should be there (yum update / upgrade on a 6.3 system will make it 
6.5+), though I think we know in practise a lot of users aren't as they prefer 
to keep things at a stable state or only apply very specific updates. I guess 
this would be done by specifying a minimum Java version required that is only 
in the appropriate release or later.
* Don't actually block it in the RPM, but check in the init script what version 
of Java we're going to end up picking up, and if it's 1.6 fail with a clear 
error message suggesting the user changes the default - still means the 
management server / agent won't start after upgrade, but is at least a 
reasonably easy fix.

Alex

Re: Review Request 25289: CLOUDSTACK-7474-Failed-to-start-MS-with-java7-version

[David Nalley]

On Wed, Sep 3, 2014 at 8:12 PM, Alex Brett  wrote:
> On 04 September 2014 00:45, David Nalley [da...@gnsa.us] wrote:
>> On Wed, Sep 3, 2014 at 7:40 PM, Alex Brett  wrote:
>>> To expand on this a little bit - in RHEL 6.3 if you have both Java 1.6 and 
>>> Java 7 installed, the default behaviour with the alternatives mechanism 
>>> makes 1.6 the default Java instance (you can manually set 1.7 as the 
>>> default, but this is an extra step). This means that the management server 
>>> / KVM agent then fail to work.
>>>
>>> In 6.5 if you have both then by default Java 7 is used, and all works fine 
>>> (not sure about 6.4 or 7, I've not tested them).
>>>
>>
>> Perhaps we add a Conflicts with java 1.6 - it would be somewhat ugly,
>> and if you run into it  you would need to know to yum remove, but that
>> would keep you from having an installation at all rather than
>> expecting it to work and trying to debug.
>>
>
> I'd have thought this would prove problematic over upgrade - as you'd have a 
> conflict that the new version would need to have 1.6 removed, but you can't 
> do that without removing your old version first. There's also the issue of if 
> the user wants to have both around for other tools they're running on the 
> same machine.
>

Both valid points.

> Some solutions that don't break upgrade that I can see are:
> * Rayees change in the review to point directly at Java 7, with the caveat 
> that this might have some cross platform issues

Yes, but cross-platform issues - there are people running on platforms
besides what we package for; and with JDKs other than what we assume
in our package scripts. Hardcoding is bad all the way around.

> * Somehow automating the alternatives mechanism, i.e. doing a check as part 
> of management server startup somewhere that if the default Java is 1.6, 
> setting it to be Java 7 (which we know should be installed by the RPM 
> dependencies) - a little ugly as we are changing a user's default underneath 
> them, and may also have cross platform issues

Ugh, please no, changing underlying platform without very clearly
communicating it is bad. We'll invoke the ire of every BOFH using
CloudStack :)

> * Require use of 6.5 (or possibly 6.4 if the version that has works) instead 
> of 6.3 - we do already say to install all hotfixes etc, which in theory means 
> people should be there (yum update / upgrade on a 6.3 system will make it 
> 6.5+), though I think we know in practise a lot of users aren't as they 
> prefer to keep things at a stable state or only apply very specific updates. 
> I guess this would be done by specifying a minimum Java version required that 
> is only in the appropriate release or later.

This is easy in CentOS; but more painful in RHEL. We could easily
Require: centos-release-6.5 or redhat-release (with an if statement if
centos-release doesn't provide redhat-release, but I think it does)

> * Don't actually block it in the RPM, but check in the init script what 
> version of Java we're going to end up picking up, and if it's 1.6 fail with a 
> clear error message suggesting the user changes the default - still means the 
> management server / agent won't start after upgrade, but is at least a 
> reasonably easy fix.
>

This is probably most reasonable of all of the solutions IMO.


> Alex

Jenkins build is still unstable: simulator-singlerun #279

[jenkins]

See 

Jenkins build is still unstable: simulator-singlerun #280

[jenkins]

See 

Re: Review Request 22799: Golden (Base) Primary Storage feature

[Mike Tutkowski]

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


Just checking in again to see where we're at with this feature. Tim?

- Mike Tutkowski


On July 20, 2014, 9:56 p.m., Hieu LE wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22799/
> ---
> 
> (Updated July 20, 2014, 9:56 p.m.)
> 
> 
> Review request for cloudstack, Mike Tutkowski and Tim Mackey.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> As discussed in mailing list, this patch is applied for golden primary 
> storage in [1].
> I have changed the term from "golden" to "base" because there are some 
> functions and variables in CloudStack also use "base" for base image.
> This patch only apply for Xen Server.
> 
> [1]: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Golden+Primary+Storage
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/deploy/DeployDestination.java 
> 4ded5ebe7a18252da471ee25019856f2b2f772e0 
>   api/src/com/cloud/storage/StoragePool.java 
> 8e03c3348f3a6dd3156ab9e440126ea317957dc0 
>   api/src/com/cloud/template/VirtualMachineTemplate.java 
> 599212bb039fdbb78511019e8f0a6ea4b4a84440 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 
> ae5d6f05b6b52f60b151369a641cb11fcbb558af 
>   api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java 
> 2350f6b389203e2c6cc2182fe03fe9a95e936b81 
>   
> api/src/org/apache/cloudstack/api/command/admin/storage/CreateStoragePoolCmd.java
>  ae44bc9373232d242e4ebdcf76844969f0fe69fc 
>   
> api/src/org/apache/cloudstack/api/command/admin/storage/ListStoragePoolsCmd.java
>  ed123db 
>   
> api/src/org/apache/cloudstack/api/command/admin/storage/UpdateStoragePoolCmd.java
>  3d1a77353257c814efaf60875ffdf99603bc414e 
>   
> api/src/org/apache/cloudstack/api/command/user/template/RegisterTemplateCmd.java
>  f478c9bc8eebf867a03deb4add1bf695ac3ec0ad 
>   api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java 
> 3571866fe74dca9aa5fe0d11373313eab97e94ac 
>   api/src/org/apache/cloudstack/api/response/TemplateResponse.java 
> 3e21043e339103c021d3c9e767acac8b3837f760 
>   core/src/com/cloud/agent/api/CheckPoolBelongToHostAnswer.java PRE-CREATION 
>   core/src/com/cloud/agent/api/CheckPoolBelongToHostCommand.java PRE-CREATION 
>   core/src/org/apache/cloudstack/storage/to/PrimaryDataStoreTO.java 
> 29e53b0d9581f764a17ea285606213d2c045b029 
>   core/src/org/apache/cloudstack/storage/to/TemplateObjectTO.java 
> b201c386f4975913f13c575d7685e50cedc7d92f 
>   
> core/test/org/apache/cloudstack/api/agent/test/BackupSnapshotCommandTest.java 
> 33361e87265df05e00bfa6dba810d2b68ae8d923 
>   core/test/org/apache/cloudstack/api/agent/test/CheckNetworkAnswerTest.java 
> 66feaecb5ef20053db50956e2801fec096a350c9 
>   core/test/org/apache/cloudstack/api/agent/test/SnapshotCommandTest.java 
> 114c8854d1504436523aa99c78bf2b4d84a12077 
>   
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/PrimaryDataStoreParameters.java
>  1dbff59a8911ad8f0933ef17a2c2b1d3e33523b9 
>   
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/StoragePoolAllocator.java
>  dfdbd8ab92c47799f6ad23637fa63e030f0be968 
>   
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/VolumeInfo.java
>  f93f4efac83c565cd33eb7eb67dcaca335f1c226 
>   engine/components-api/src/com/cloud/deploy/DeploymentPlanningManager.java 
> ee6721ab445a5222d0087dc9170e0b58f9eef91a 
>   engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
> 4aa5fc80d9660d2f985db98124c33465bd99767f 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/cloud/entity/api/VMEntityManagerImpl.java
>  b1ac2f853374d6f1ddd9087919dbc16db0433f59 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  6256e2526ef9bd4632a5e3873c4d9531eb301c7f 
>   engine/schema/src/com/cloud/storage/VMTemplateVO.java 
> 9a77cbf873aa9e422985fbcdc0ae7e18b8c78d4c 
>   engine/schema/src/com/cloud/storage/VolumeVO.java 
> e328253a596891029c2b55bea81b7ead425251ee 
>   
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
>  a976bfbf6fe46306d20ad939c335bba6b9b7be54 
>   
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
>  92793f1fb1a08a455a78667ba4a39ae162378360 
>   
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/StoragePoolVO.java
>  1508ce0b28c83968c25d9601b6dae34e1a73dbb0 
>   
> engine/storage/image/src/org/apache/cloudstack/storage/image/store/TemplateObject.java
>  7288d454c30fdb81445e43549145f1f2da8533e4 
>   
> engine/storage/src/org/apache/cloudstack/storage/allocator/ClusterScopeStoragePoolAllocator.java
>  ea084c7555

Jenkins build is still unstable: simulator-singlerun #281

[jenkins]

See 

Re: Review Request 25293: Test script to verify vm deployment with two networks in SG enabled advanced zone

[suresh sadhu]

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

Ship it!


Ship It!

- suresh sadhu


On Sept. 3, 2014, 9:58 a.m., sanjeev n wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25293/
> ---
> 
> (Updated Sept. 3, 2014, 9:58 a.m.)
> 
> 
> Review request for cloudstack, suresh sadhu, Santhosh Edukulla, and 
> SrikanteswaraRao Talluri.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Test script to verify vm deployment with two networks in SG enabled advanced 
> zone.
> Involves following steps:
> 1.Deploy SG enabled advanced zone with only 4 ip addresses in guest ip range 
> using simulator
> 2.Deploy one guest vm in the default shared guest network so that all the IP 
> addresses will be consumed
> 3.Add another guest network in the zone created at step1
> 4.Deploy vm without passing the network id. It should pick the network with 
> sufficient resources
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_advancedsg_networks.py 85ab697 
>   tools/marvin/marvin/config/test_data.py b658b01 
> 
> Diff: https://reviews.apache.org/r/25293/diff/
> 
> 
> Testing
> ---
> 
> @Desc: VM Cannot deploy to second network in advanced SG network ... === 
> TestName: test_34_DeployVM_in_SecondSGNetwork | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 343.198s
> 
> OK
> 
> 
> Thanks,
> 
> sanjeev n
> 
>

Re: Review Request 25293: Test script to verify vm deployment with two networks in SG enabled advanced zone

[suresh sadhu]

> On Sept. 4, 2014, 4:05 a.m., suresh sadhu wrote:
> > Ship It!

addressed the preview  review comments and looks good to me.


- suresh


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


On Sept. 3, 2014, 9:58 a.m., sanjeev n wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25293/
> ---
> 
> (Updated Sept. 3, 2014, 9:58 a.m.)
> 
> 
> Review request for cloudstack, suresh sadhu, Santhosh Edukulla, and 
> SrikanteswaraRao Talluri.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Test script to verify vm deployment with two networks in SG enabled advanced 
> zone.
> Involves following steps:
> 1.Deploy SG enabled advanced zone with only 4 ip addresses in guest ip range 
> using simulator
> 2.Deploy one guest vm in the default shared guest network so that all the IP 
> addresses will be consumed
> 3.Add another guest network in the zone created at step1
> 4.Deploy vm without passing the network id. It should pick the network with 
> sufficient resources
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_advancedsg_networks.py 85ab697 
>   tools/marvin/marvin/config/test_data.py b658b01 
> 
> Diff: https://reviews.apache.org/r/25293/diff/
> 
> 
> Testing
> ---
> 
> @Desc: VM Cannot deploy to second network in advanced SG network ... === 
> TestName: test_34_DeployVM_in_SecondSGNetwork | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 343.198s
> 
> OK
> 
> 
> Thanks,
> 
> sanjeev n
> 
>

Jenkins build is still unstable: simulator-singlerun #282

[jenkins]

See 

Re: Commit cd8af6a

[Min Chen]

Backported to 4.4 branch.

-min

From: Daan Hoogland mailto:daan.hoogl...@gmail.com>>
Date: Wednesday, September 3, 2014 11:52 AM
To: dev mailto:dev@cloudstack.apache.org>>, Min Chen 
mailto:min.c...@citrix.com>>
Subject: Re: Commit cd8af6a

guess you should go ahead and backport.


On Wed, Sep 3, 2014 at 8:28 PM, Min Chen 
mailto:min.c...@citrix.com>> wrote:
This is a bug that will impact reference counting only for old volume on
NFS to S3 object store migration.

Thanks
-min

On 9/3/14 11:25 AM, "Daan Hoogland" 
mailto:daan.hoogl...@gmail.com>> wrote:

>H Min,
>
>what is this fix for?
>
>
>On Wed, Sep 3, 2014 at 8:20 PM, Min Chen 
>mailto:min.c...@citrix.com>> wrote:
>
>> Fix is checked into master branch. Can I back port it to 4.4?
>>
>> Thanks
>> -min
>>
>> On 9/3/14 9:42 AM, "Min Chen" 
>> mailto:min.c...@citrix.com>> wrote:
>>
>> >Thanks Hugo for pointing that out. That is a bug caused by
>>copy-and-paste,
>> >the code should be in decrRefCnt routine like other SnapshotDataStoreVO
>> >and TemplateDataStoreVO.
>> >I will fix this in a minute.
>> >
>> >-min
>> >
>> >
>> >On 9/3/14 12:30 AM, "Hugo Trippaers" 
>> >mailto:h...@trippaers.nl>> wrote:
>> >
>> >>Min,
>> >>
>> >>I¹m checking some findbugs reports and found the following piece of
>>code
>> >>in VolumeDataStoreVO (line 352):
>> >>
>> >>public void setRefCnt(Long refCnt) {
>> >>if (refCnt > 0) {
>> >>refCnt--;
>> >>}
>> >>else {
>> >>s_logger.warn("We should not try to decrement a zero
>> >>reference count even though our code has guarded");
>> >>}
>> >>}
>> >>
>> >>
>> >>This doesn¹t seem to make a lot of sense to me as the refCnt field
>> >>doesn¹t get set in this function. Could you have a look as you
>>committed
>> >>this and might know what the intended behavior is?
>> >>
>> >>Cheers,
>> >>
>> >>Hugo
>> >
>>
>>
>
>
>--
>Daan




--
Daan

Build failed in Jenkins: cloudstack-4.4-maven-build-noredist #368

[jenkins]

See 


Changes:

[min.chen] CLOUDSTACK-6236:fix a copy-and-paste error for decrRefCnt in

--
[...truncated 2618 lines...]
[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 82 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.518 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.193 sec
Running com.cloud.alert.AlertControlsUnitTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.052 sec
Running com.cloud.capacity.CapacityManagerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.14 sec
Running com.cloud.resourcelimit.ResourceLimitManagerImplTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running com.cloud.network.firewall.FirewallManagerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0 sec
Running com.cloud.network.UpdatePhysicalNetworkTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.206 sec
Running com.cloud.network.CreatePrivateNetworkTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.143 sec
Running com.cloud.network.NetworkModelTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.111 sec
Running com.cloud.network.security.SecurityGroupManagerImplTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.854 sec
Running com.cloud.network.security.SecurityGroupQueueTest
Total jobs dequeued = 10, num queued=1003 queue current size=993
Num Vms= 50 Queue size = 50
Num Vms= 2 Queue size = 2 time=1315 ms
Num Vms= 5000 Queue size = 5000 time=985 ms
Num Vms= 1 Queue size = 1 time=1 ms
Num Vms= 100 Queue size = 100 time=1044 ms
Total jobs dequeued = 10, num queued=1010 queue current size=1000
Total jobs dequeued = 1, num queued=1001 queue current size=1000
Total jobs dequeued = 10, num queued=1000 queue current size=990
Total jobs dequeued = 10, num queued=10 queue current size=0
Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.047 sec <<< 
FAILURE!
Running com.cloud.network.vpc.VpcManagerImplTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec
Running com.cloud.network.DedicateGuestVlanRangesTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec
Running com.cloud.network.lb.AssignLoadBalancerTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.106 sec
Running com.cloud.network.dao.NetworkDaoTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running com.cloud.vm.DeploymentPlanningManagerImplTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.897 sec
Running com.cloud.vm.snapshot.VMSnapshotManagerTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.172 sec
Running com.cloud.vm.UserVmManagerTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.558 sec
Running com.cloud.configuration.ValidateIpRangeTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.045 sec
Running com.cloud.configuration.ConfigurationManagerTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.113 sec
Running com.cloud.server.ConfigurationServerImplTest
Tests run: 3, Failures: 0, Errors: 0, Skipp

[GitHub] cloudstack-docs-admin pull request: Update templates.rst

[baiqj]

Github user baiqj commented on the pull request:


https://github.com/apache/cloudstack-docs-admin/pull/18#issuecomment-54411743
  
my email is linux...@gmail.com
thanks


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

Re: Review Request 24794: Review request for CLOUDSTACK-6169 - assignVirtualMachine leaves associated tags assigned to old account

[Namita Chaudhari]

Gentle reminder..


On Mon, Aug 18, 2014 at 3:24 PM, Namita Chaudhari <
namita.chaudh...@sungard.com> wrote:

>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24794/
> ---
>
> Review request for cloudstack and Marcus Sorensen.
>
>
> Bugs: CLOUDSTACK-6169 and
> https://issues.apache.org/jira/browse/CLOUDSTACK-6169
> https://issues.apache.org/jira/browse/CLOUDSTACK-6169
>
> https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-6169
>
>
> Repository: cloudstack-git
>
>
> Description
> ---
>
> CLOUDSTACK-6169 - assignVirtualMachine leaves associated tags assigned to
> old account
>
> When a VM is assigned from one account to another, the tags associated to
> the VM points to the new account and not old one.
>
>
> Diffs
> -
>
>   engine/schema/src/com/cloud/tags/ResourceTagVO.java ea1
>   engine/schema/src/com/cloud/tags/dao/ResourceTagDao.java fffe2a47
>   engine/schema/src/com/cloud/tags/dao/ResourceTagsDaoImpl.java 3611999
>   server/src/com/cloud/vm/UserVmManagerImpl.java e5de11f
>
> Diff: https://reviews.apache.org/r/24794/diff/
>
>
> Testing
> ---
>
> Yes.
>
>
> Thanks,
>
> Namita Chaudhari
>
>


-- 

*Namita Chaudhari* ● Engineer - Product Development ● SunGard Availability
Services, India. ● 2nd Floor, Wing 4, Cluster D, MIDC Kharadi Knowledge
Park, Pune - 411 014 ● Email: namita.chaudh...@sungardas.com
 ● www.sungardas.in



[image: Description: cid:image019.png@01CF48EC.6617C7F0]  [image:
Description: cid:image020.png@01CF48EC.6617C7F0]  [image: Description:
cid:image021.png@01CF48EC.6617C7F0]  [image: Description:
cid:image022.png@01CF48EC.6617C7F0]  [image: Description:
cid:image023.png@01CF48EC.6617C7F0]  [image: Description:
cid:image024.png@01CF48EC.6617C7F0]

Jenkins build is still unstable: simulator-singlerun #283

[jenkins]

See