date:20130423


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

Review request for cloudstack, Devdeep Singh, Sateesh Chodapuneedi, and Min 
Chen.


Description
---

CLOUDSTACK-2087: Destroying the instance is not decrementing the primary 
storage usage [Resource Count table - No of volumes is not got decremented] 


This addresses bug CLOUDSTACK-2087.


Diffs
-

  server/src/com/cloud/vm/VirtualMachineManagerImpl.java c1f3f15 

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


Testing
---

Tests:
1. Deploy an instance from a user account.
2. Check the updated resource count (primary storage and volume).
3. Destroy the same instance.
4. Verify the decremented resource count from the account detailView.  


Thanks,

Sanjay Tripathi

Re: Review Request: CLOUDSTACK-2087: Destroying the instance is not decrementing the primary storage usage [Resource Count table - No of volumes is not got decremented]

2013-04-23 Thread Nitin Mehta


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



server/src/com/cloud/vm/VirtualMachineManagerImpl.java
https://reviews.apache.org/r/10725/#comment40435

Would restore vm increment these limits again ?




server/src/com/cloud/vm/VirtualMachineManagerImpl.java
https://reviews.apache.org/r/10725/#comment40436

What about the resource limit for the vm ? where is that getting 
decremented. Are these consistent ?


- Nitin Mehta


On April 23, 2013, 8:42 a.m., Sanjay Tripathi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/10725/
 ---
 
 (Updated April 23, 2013, 8:42 a.m.)
 
 
 Review request for cloudstack, Devdeep Singh, Sateesh Chodapuneedi, and Min 
 Chen.
 
 
 Description
 ---
 
 CLOUDSTACK-2087: Destroying the instance is not decrementing the primary 
 storage usage [Resource Count table - No of volumes is not got decremented] 
 
 
 This addresses bug CLOUDSTACK-2087.
 
 
 Diffs
 -
 
   server/src/com/cloud/vm/VirtualMachineManagerImpl.java c1f3f15 
 
 Diff: https://reviews.apache.org/r/10725/diff/
 
 
 Testing
 ---
 
 Tests:
 1. Deploy an instance from a user account.
 2. Check the updated resource count (primary storage and volume).
 3. Destroy the same instance.
 4. Verify the decremented resource count from the account detailView.  
 
 
 Thanks,
 
 Sanjay Tripathi

Re: Review Request: CLOUDSTACK-2087: Destroying the instance is not decrementing the primary storage usage [Resource Count table - No of volumes is not got decremented]



 On April 23, 2013, 8:48 a.m., Nitin Mehta wrote:
  server/src/com/cloud/vm/VirtualMachineManagerImpl.java, line 447
  https://reviews.apache.org/r/10725/diff/1/?file=283382#file283382line447
 
  Would restore vm increment these limits again ?
 

Are you talking about resotreVM or recoverVM?
In case of restoreVM, it is resetting the VM by deleting old root volume and 
allocating duplicate root volume, so we don't have to check for limits here.
In case of recoverVM, this API option is available only if the root disk is not 
yet expunged, so it will not increment primary storage limits.


 On April 23, 2013, 8:48 a.m., Nitin Mehta wrote:
  server/src/com/cloud/vm/VirtualMachineManagerImpl.java, line 448
  https://reviews.apache.org/r/10725/diff/1/?file=283382#file283382line448
 
  What about the resource limit for the vm ? where is that getting 
  decremented. Are these consistent ?

Other resource limits related to VM like vm_instance, cpu, memory etc are 
getting decremented once the destroyVM API returns the result successfully. 
CloudStack waits for expunging of VM to decrement the storage limits like 
Volume, primary storage.


- Sanjay


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


On April 23, 2013, 8:42 a.m., Sanjay Tripathi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/10725/
 ---
 
 (Updated April 23, 2013, 8:42 a.m.)
 
 
 Review request for cloudstack, Devdeep Singh, Sateesh Chodapuneedi, and Min 
 Chen.
 
 
 Description
 ---
 
 CLOUDSTACK-2087: Destroying the instance is not decrementing the primary 
 storage usage [Resource Count table - No of volumes is not got decremented] 
 
 
 This addresses bug CLOUDSTACK-2087.
 
 
 Diffs
 -
 
   server/src/com/cloud/vm/VirtualMachineManagerImpl.java c1f3f15 
 
 Diff: https://reviews.apache.org/r/10725/diff/
 
 
 Testing
 ---
 
 Tests:
 1. Deploy an instance from a user account.
 2. Check the updated resource count (primary storage and volume).
 3. Destroy the same instance.
 4. Verify the decremented resource count from the account detailView.  
 
 
 Thanks,
 
 Sanjay Tripathi

Re: Review Request: CLOUDSTACK-2087: Destroying the instance is not decrementing the primary storage usage [Resource Count table - No of volumes is not got decremented]


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

(Updated April 23, 2013, 9:29 a.m.)


Review request for cloudstack, Devdeep Singh, Nitin Mehta, Sateesh 
Chodapuneedi, and Min Chen.


Description
---

CLOUDSTACK-2087: Destroying the instance is not decrementing the primary 
storage usage [Resource Count table - No of volumes is not got decremented] 


This addresses bug CLOUDSTACK-2087.


Diffs
-

  server/src/com/cloud/vm/VirtualMachineManagerImpl.java c1f3f15 

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


Testing
---

Tests:
1. Deploy an instance from a user account.
2. Check the updated resource count (primary storage and volume).
3. Destroy the same instance.
4. Verify the decremented resource count from the account detailView.  


Thanks,

Sanjay Tripathi

Re: New PMC Member: Prasanna Santhanam

2013-04-23 Thread Abhinandan Prateek

Congrats Prasanna !

On 22/04/13 9:21 PM, Chip Childers chip.child...@sungard.com wrote:

Hi folks

The Project Management Committee (PMC) for Apache CloudStack
has asked Prasanna Santhanam to become a member of the PMC and
we are pleased to announce that he has accepted.

Please join me in congratulating Prasanna!

Regards,

--Chip
on behalf of the CloudStack PMC

Re: New PMC Member: Prasanna Santhanam

2013-04-23 Thread Jayapal Reddy Uradi

Congrats Prasanna.

-Jayapal

On 23-Apr-2013, at 12:47 PM, Ram Ganesh ram.gan...@citrix.com wrote:

 Congrats Prasanna.
 
 Regards,
 RamG
 
 -Original Message-
 From: L Radhakrishna Rao [mailto:satishsaga...@gmail.com]
 Sent: 23 April 2013 12:42
 To: dev@cloudstack.apache.org
 Subject: Re: New PMC Member: Prasanna Santhanam
 
 Congratulations!!!
 
 
 On Tue, Apr 23, 2013 at 11:17 AM, Isaac Chiang
 isaacchi...@gmail.comwrote:
 
 Congratulations!!
 
 Isaac
 
 
 On Tue, Apr 23, 2013 at 1:30 PM, Dave Cahill dcah...@midokura.com
 wrote:
 
 Congrats Prasanna, much deserved. :)
 
 Dave.
 
 
 On Tue, Apr 23, 2013 at 2:23 PM, Devdeep Singh
 devdeep.si...@citrix.com
 wrote:
 
 Congrats Prasanna.
 
 Regards,
 Devdeep
 
 -Original Message-
 From: Chip Childers [mailto:chip.child...@sungard.com]
 Sent: Monday, April 22, 2013 9:21 PM
 To: dev@cloudstack.apache.org
 Subject: New PMC Member: Prasanna Santhanam
 
 Hi folks
 
 The Project Management Committee (PMC) for Apache CloudStack
 has
 asked
 Prasanna Santhanam to become a member of the PMC and we are
 pleased
 to
 announce that he has accepted.
 
 Please join me in congratulating Prasanna!
 
 Regards,
 
 --Chip
 on behalf of the CloudStack PMC

Review Request: CLOUDSTACK-2147: Missing configuration variable max.project.cpus in configuration table


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

Review request for cloudstack, Devdeep Singh, Chip Childers, and Min Chen.


Description
---

CLOUDSTACK-2147: Missing configuration variable max.project.cpus in 
configuration table.

Removed the max.project.cpus, max.project.memory, max.account.cpus, 
max.account.memory from schema-40to410.sql file as the feature to limit these 
values got shifted to 4.2.


This addresses bug CLOUDSTACK-2147.


Diffs
-

  setup/db/db/schema-40to410.sql 3fbd075 

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


Testing
---

Tests:
1. Setup CloudStack environment.
2. Go to Infrastructure tab.
3. Verified that max.project.cpus parameter is not present along with other 
parameters.


Thanks,

Sanjay Tripathi

Re: Review Request: CLOUDSTACK-2147: Missing configuration variable max.project.cpus in configuration table


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

(Updated April 23, 2013, 10:41 a.m.)


Review request for cloudstack, Devdeep Singh, Chip Childers, and Min Chen.


Description
---

CLOUDSTACK-2147: Missing configuration variable max.project.cpus in 
configuration table.

Removed the max.project.cpus, max.project.memory, max.account.cpus, 
max.account.memory from schema-40to410.sql file as the feature to limit these 
values got shifted to 4.2.


This addresses bug CLOUDSTACK-2147.


Diffs (updated)
-

  setup/db/db/schema-40to410.sql 3fbd075 

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


Testing
---

Tests:
1. Setup CloudStack environment.
2. Go to Infrastructure tab.
3. Verified that max.project.cpus parameter is not present along with other 
parameters.


Thanks,

Sanjay Tripathi

[ACS41][Patch Request]

CLOUDSTACK-2147 : Missing configuration variable max.project.cpus in 
configuration table.

--Sanjay

From: Sanjay Tripathi [mailto:nore...@reviews.apache.org] On Behalf Of Sanjay 
Tripathi
Sent: Tuesday, April 23, 2013 3:56 PM
To: Min Chen; Chip Childers; Devdeep Singh
Cc: cloudstack; Sanjay Tripathi
Subject: Review Request: CLOUDSTACK-2147: Missing configuration variable 
max.project.cpus in configuration table

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

Review request for cloudstack, Devdeep Singh, Chip Childers, and Min Chen.
By Sanjay Tripathi.
Description

CLOUDSTACK-2147: Missing configuration variable max.project.cpus in 
configuration table.

Removed the max.project.cpus, max.project.memory, max.account.cpus, 
max.account.memory from schema-40to410.sql file as the feature to limit these 
values got shifted to 4.2.

Testing

Tests:

1. Setup CloudStack environment.

2. Go to Infrastructure tab.

3. Verified that max.project.cpus parameter is not present along with other 
parameters.

Bugs: CLOUDSTACK-2147
Diffs

  *   setup/db/db/schema-40to410.sql (3fbd075)

View Diffhttps://reviews.apache.org/r/10726/diff/

Review Request: Updated the user permission to acquire ip

2013-04-23 Thread Jayapal Reddy


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

Review request for cloudstack, Abhinandan Prateek and Murali Reddy.


Description
---

Updated the user permissions check


This addresses bug CLOUDSTACK-2134.


Diffs
-

  server/src/com/cloud/network/NetworkServiceImpl.java ac2ac45 

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


Testing
---

Unit tested on basic and advanced zone


Thanks,

Jayapal Reddy

RE: New PMC Member: Prasanna Santhanam

2013-04-23 Thread Hugo Trippaers

Congrats Prasanna!  :-)

 -Original Message-
 From: Chip Childers [mailto:chip.child...@sungard.com]
 Sent: Monday, April 22, 2013 5:51 PM
 To: dev@cloudstack.apache.org
 Subject: New PMC Member: Prasanna Santhanam

 Hi folks

 The Project Management Committee (PMC) for Apache CloudStack has
 asked Prasanna Santhanam to become a member of the PMC and we are
 pleased to announce that he has accepted.

 Please join me in congratulating Prasanna!

 Regards,

 --Chip
 on behalf of the CloudStack PMC

Re: New PMC Member: Prasanna Santhanam

2013-04-23 Thread Go Chiba

Congrats Prasanna!


On Tue, Apr 23, 2013 at 8:10 PM, Hugo Trippaers 
htrippa...@schubergphilis.com wrote:

 Congrats Prasanna!  :-)

  -Original Message-
  From: Chip Childers [mailto:chip.child...@sungard.com]
  Sent: Monday, April 22, 2013 5:51 PM
  To: dev@cloudstack.apache.org
  Subject: New PMC Member: Prasanna Santhanam
 
  Hi folks
 
  The Project Management Committee (PMC) for Apache CloudStack has
  asked Prasanna Santhanam to become a member of the PMC and we are
  pleased to announce that he has accepted.
 
  Please join me in congratulating Prasanna!
 
  Regards,
 
  --Chip
  on behalf of the CloudStack PMC




-- 
千葉 豪  Go Chiba
E-mail:go.ch...@gmail.com

Re: Review Request: CLOUDSTACK-1647: IP Reservation should not happen if the guest-vm cidr and network cidr is not same but their start ip and end ip are same.

2013-04-23 Thread Saksham Srivastava


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

(Updated April 23, 2013, 11:17 a.m.)


Review request for cloudstack, Murali Reddy and Sateesh Chodapuneedi.


Description
---

In cases where the start ip and end ip of guest vm cidr and network cidr are 
same, even when the cidrs appear to be different,the reservation procedure 
should not go through and user should get a message mentioning that.
Added extra check for the same with proper alert message.


This addresses bug CLOUDSTACK-1647.


Diffs (updated)
-

  server/src/com/cloud/network/NetworkServiceImpl.java ac2ac45 
  utils/src/com/cloud/utils/net/NetUtils.java 5988dd5 
  utils/test/com/cloud/utils/net/NetUtilsTest.java 28bd71f 

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


Testing
---

CIDR : 10.0.144.0/20, Network CIDR : null, guestVmCidr : 10.0.151.0/20 = 
Reservation is not applied.
CIDR : 10.0.144.0/21, Network CIDR : 10.0.144.0/20, guestVmCidr : 10.0.151.0/20 
= Existing Reservation is not affected.


Thanks,

Saksham Srivastava

RE: [DISCUSS] ACS Release 4 month v/s 6 month

2013-04-23 Thread Hugo Trippaers

I would favor sticking to the current 4 month release cycle. We have only been 
doing it once and I think we need to have some more experience before changing 
this.

For me another important factor is the amount of features that are coming into 
the system at this moment. With a four month release cycle I would have to wait 
a maximum of four months on the new feature, with 6 months its even longer. If 
we want to get our features out there I think we need to release as often as 
possible so everybody can enjoy the features.  I'd rather leave out a few 
features to ease the burden on QA than delay the release.

The same feature thing also has another issue, as David pointed out. The longer 
the development cycle, the more features with hit master. That means more 
testing complexity and an even greater risk when you want to upgrade to a new 
version. And I'm not only talking about our tests, but any user will want to 
test a release before it hits his/her production systems. Make the releases to 
complex and they might be skipped because of testing complexity. From a user 
perspective I'd rather upgrade 3 times a year with a smaller change set than 
two time a year with a bigger changeset. Actually I'd rather upgrade 12 times a 
year with a very small changeset, but that's a dream for the future.

Last but not least, if we start delaying releases because we don't have the 
automated test capacity, we will never get it. I believe a bit of pressure goes 
a long way to ensuring we will have automated tests. If everybody that is 
working on features spends just a little bit of time on testing, it's done in 
no time at all. If you look at what happened during this release cycle 4.0 to 
4.1, I'm really impressed by the level of automation that is already there. And 
much of the groundwork has been completed as well so making future test is 
going to be even easier.

Cheers,

Hugo

 -Original Message-
 From: Sebastien Goasguen [mailto:run...@gmail.com]
 Sent: Tuesday, April 23, 2013 9:31 AM
 To: dev@cloudstack.apache.org
 Cc: cloudstack-...@incubator.apache.org; Chip Childers
 Subject: Re: [DISCUSS] ACS Release 4 month v/s 6 month
 
 
 On Apr 23, 2013, at 1:32 AM, Nitin Mehta nitin.me...@citrix.com wrote:
 
  David - You have some compelling logic :) Given the debate about 4
  month to 6 month, lets make an educated decision
 
  First - Lets hear from the release managers as to what they have to
  say about the last 2 releases. What went well and what didn't. Chip - ?
  Second - If we plan to do a 6 month release what would be the
  timelines in place ? Like time allocated for what features going in
  the release, feature discussion and coding, bug fixing, testing,
  documentation etc. If I get a rough idea on that for the 6 month
  release it would help me understand the differences.
 
  At this point I would still +1 a 6 month release because it gives me
  good time to discuss, code, unit test and bake my feature.
 
 We agreed on a time based release cycle, not a feature based one.
 
 Moving from 4 to 6 just means that a feature will get delayed 2 months,
 giving even more time to finish it and test it properly.
 
 IMHO, improving quality and reducing QA time comes from increasing
 testing/review at commit time and making sure feature branches do not
 diverge from master (too much).
 
 I'd rather aim for having releases that have incremental changes and an easy
 upgrade path than a longer release cycle in order to give more time for big
 changes that will disrupt upgrade and operations.
 
 I also agree with David that we have only gone through the 4 months cycle
 once (4.1) and this release has some major refactoring. We at least need to
 do it once or twice more to see if there is a real issue.
 
 -sebastien
 
 
  From my experience
  at this point this definitely makes more sense.
  We can revisit the time line after a couple releases as we all become
  more accustomed with the processes in place.
 
  Thanks,
  -Nitin
 
  On 23/04/13 8:21 AM, David Nalley da...@gnsa.us wrote:
 
  On Mon, Apr 22, 2013 at 5:19 PM, Animesh Chaturvedi
  animesh.chaturv...@citrix.com wrote:
  Folks
 
  We started discussing 4 month v/s 6 month release cycle in a another
  thread [1]. Since the subject of that thread was different,
  community may not have participated in this important discussion
  fully. I am  are bringing this discussion to its own thread. Here is
  the summary so far please refer to [1] for more details.
 
  Summary of discussion:
  - Animesh pointed out the technical debt that we have accumulated so
  far needs extra time to resolve
  - David, Chip favor shorter release cycle of 4 month and keeping
  master always stable and in good quality and enhancing automation as
  a solution to reduce QA manual effort. A focused defect fixing
  activity may be needed to reduce technical debt
  - Will brought up several points in the discussion: He called out
  heavy dependence on manual QA for a release and

Guest Network in Advance.

2013-04-23 Thread Sean Truman

All,

Is it possible for me to define a guest network lets say 10.8.0.x/24 Tagged
with VLAN of 500 and then another guest network with 10.9.0.x/24 with VLAN
of 600?

The idea is to provide VM isolation but for the entire CIDR..

v/r
Sean

RE: New PMC Member: Prasanna Santhanam

Congratulations Prasanna!

--Sanjay

 -Original Message-
 From: Chip Childers [mailto:chip.child...@sungard.com]
 Sent: Monday, April 22, 2013 9:21 PM
 To: dev@cloudstack.apache.org
 Subject: New PMC Member: Prasanna Santhanam

 Hi folks

 The Project Management Committee (PMC) for Apache CloudStack has
 asked Prasanna Santhanam to become a member of the PMC and we are
 pleased to announce that he has accepted.

 Please join me in congratulating Prasanna!

 Regards,

 --Chip
 on behalf of the CloudStack PMC

BroadcastDomainType and other enums in Networks.java

2013-04-23 Thread Daan Hoogland

H,

Working on getting a Nicira hosted  private gateway for VPCs, I noticed that at 
some points the enums IsolationType and BroadcastDomainType are used 
interchangeably. These do not contain exactly the same values. Can they be 
unified (by me)? Or would I be breaking to much?

As an illustration, this code comes from PrivateNetworkGuru:

nic.setIsolationUri(IsolationType.Vlan.toUri(ip.getBroadcastUri()));
nic.setBroadcastUri(IsolationType.Vlan.toUri(ip.getBroadcastUri()));

kind regards,
Daan Hoogland

Re: Guest Network in Advance.

2013-04-23 Thread Sean Truman

So I would just provide 500-500 as the range in the guest for the first
CIDR and 600-600 in the 2nd CIDR?

v/r
Sean


On Tue, Apr 23, 2013 at 7:15 AM, Saksham Srivastava 
saksham.srivast...@citrix.com wrote:

 Yes creating multiple vlans with different CIDRs is possible.

 Thanks,
 Saksham

 On Tuesday 23 April 2013 05:14 PM, Sean Truman wrote:
  All,
 
  Is it possible for me to define a guest network lets say 10.8.0.x/24
 Tagged
  with VLAN of 500 and then another guest network with 10.9.0.x/24 with
 VLAN
  of 600?
 
  The idea is to provide VM isolation but for the entire CIDR..
 
  v/r
  Sean

RE: BroadcastDomainType and other enums in Networks.java

2013-04-23 Thread Daan Hoogland

In addition to this I would like to remove the use of a numeric vlan as string 
from the system and replace it with a URI (!not being a URL!) Is there  any 
technical objection or other reason not to this?

-Original Message-
From: Daan Hoogland [mailto:dhoogl...@schubergphilis.com] 
Sent: dinsdag 23 april 2013 14:11
To: dev@cloudstack.apache.org
Subject: BroadcastDomainType and other enums in Networks.java

H,

Working on getting a Nicira hosted  private gateway for VPCs, I noticed that at 
some points the enums IsolationType and BroadcastDomainType are used 
interchangeably. These do not contain exactly the same values. Can they be 
unified (by me)? Or would I be breaking to much?

As an illustration, this code comes from PrivateNetworkGuru:

nic.setIsolationUri(IsolationType.Vlan.toUri(ip.getBroadcastUri()));
nic.setBroadcastUri(IsolationType.Vlan.toUri(ip.getBroadcastUri()));

kind regards,
Daan Hoogland

Re: [DISCUSS] ACS Release 4 month v/s 6 month

2013-04-23 Thread Joe Brockmeier

On Mon, Apr 22, 2013, at 04:19 PM, Animesh Chaturvedi wrote:
  - Joe agrees partly in release overhead being significant for major
  release

This is only a partial summary of what I've said before. Yes, I think
there's overhead in a release that's really non-flexible. 

However, we've really not given a four-month release a proper shot yet.
As already mentioned - our first release cycle was all about getting the
infra up in place. The second one was punctuated by graduation and other
things that kept it from being as smooth as it could have been.

The 4.2 cycle would be the first one we really have a shot at a normal
release cycle. 

Am I 100% convinced in a four-month cycle? Not yet, but I am convinced
it's a goal we should be aiming for, and I don't think we get there by
going to a six-month cycle until we're ready. We get there by aiming
for four-month cycles and improving until we reach the ability to do a
four-month cycle. 

+1 to a four month cycle. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: Release Verification Tool - if you're interested

On Tue, Apr 23, 2013 at 9:36 AM, Chip Childers
chip.child...@sungard.com wrote:
 Hi all,

 Going through the process of validating the RC's (and several validation
 rounds before announcing an RC), I got tired of manually following the
 steps in our release testing process [1].

 Some of the steps do require that you manually work with the release,
 however many of the up-front steps are easily scripted.  I put together
 a generic framework for defining and running a set of release
 verification instructions yesterday, including the definition of the
 CloudStack release verification steps as the example configuration [2].

 Feel free to use it if you think it would help you (especially the RM's
 that may have to re-spin an RC over and over to ensure that it's right).

 -chip

 [1]
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure

 [2] https://github.com/chipchilders/cloudstack-release-verification-tool

And here's an example of running it for the latest 4.1.0 VOTE:

# ./verify-release.py -i instructions.conf -v 4.1.0 -c
7048baaa4417880db690cba4a620af06276dd040

RUNNING COMMAND: rm -Rf /tmp/cloudstack
RUNNING COMMAND: rm -Rf ~/.m2
RUNNING COMMAND: mkdir /tmp/cloudstack
RUNNING COMMAND: wget --no-check-certificate -q
https://dist.apache.org/repos/dist/release/cloudstack/KEYS
RUNNING COMMAND: wget --no-check-certificate -q
https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/apache-cloudstack-4.1.0-src.tar.bz2
RUNNING COMMAND: wget --no-check-certificate -q
https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/apache-cloudstack-4.1.0-src.tar.bz2.asc
RUNNING COMMAND: wget --no-check-certificate -q
https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/apache-cloudstack-4.1.0-src.tar.bz2.md5
RUNNING COMMAND: wget --no-check-certificate -q
https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/apache-cloudstack-4.1.0-src.tar.bz2.sha
RUNNING COMMAND: gpg --verify apache-cloudstack-4.1.0-src.tar.bz2.asc
RUNNING COMMAND: gpg --print-md MD5
apache-cloudstack-4.1.0-src.tar.bz2 | diff -
apache-cloudstack-4.1.0-src.tar.bz2.md5
RUNNING COMMAND: gpg --print-md SHA512
apache-cloudstack-4.1.0-src.tar.bz2 | diff -
apache-cloudstack-4.1.0-src.tar.bz2.sha
RUNNING COMMAND: mkdir /tmp/cloudstack/git
RUNNING COMMAND: mkdir /tmp/cloudstack/tree
RUNNING COMMAND: git clone -q
https://git-wip-us.apache.org/repos/asf/cloudstack.git
/tmp/cloudstack/git
RUNNING COMMAND: git archive --prefix=/tmp/cloudstack/tree/
7048baaa4417880db690cba4a620af06276dd040 | tar Pxf -
RUNNING COMMAND: tar xvfj apache-cloudstack-4.1.0-src.tar.bz2
RUNNING COMMAND: diff -r /tmp/cloudstack/apache-cloudstack-4.1.0-src
/tmp/cloudstack/tree
RUNNING COMMAND: mvn --projects='org.apache.cloudstack:cloudstack'
org.apache.rat:apache-rat-plugin:0.8:check
RUNNING COMMAND: mvn -P developer,systemvm clean install
RUNNING COMMAND: mvn -P developer -pl developer,tools/devcloud -Ddeploydb
AUTOMATED TESTING RESULTS:
[PASS] rm -Rf /tmp/cloudstack
[PASS] rm -Rf ~/.m2
[PASS] mkdir /tmp/cloudstack
[PASS] wget --no-check-certificate -q
https://dist.apache.org/repos/dist/release/cloudstack/KEYS
[PASS] wget --no-check-certificate -q
https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/apache-cloudstack-4.1.0-src.tar.bz2
[PASS] wget --no-check-certificate -q
https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/apache-cloudstack-4.1.0-src.tar.bz2.asc
[PASS] wget --no-check-certificate -q
https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/apache-cloudstack-4.1.0-src.tar.bz2.md5
[PASS] wget --no-check-certificate -q
https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/apache-cloudstack-4.1.0-src.tar.bz2.sha
[PASS] gpg --verify apache-cloudstack-4.1.0-src.tar.bz2.asc
[PASS] gpg --print-md MD5 apache-cloudstack-4.1.0-src.tar.bz2 | diff -
apache-cloudstack-4.1.0-src.tar.bz2.md5
[PASS] gpg --print-md SHA512 apache-cloudstack-4.1.0-src.tar.bz2 |
diff - apache-cloudstack-4.1.0-src.tar.bz2.sha
[PASS] mkdir /tmp/cloudstack/git
[PASS] mkdir /tmp/cloudstack/tree
[PASS] git clone -q
https://git-wip-us.apache.org/repos/asf/cloudstack.git
/tmp/cloudstack/git
[PASS] git archive --prefix=/tmp/cloudstack/tree/
7048baaa4417880db690cba4a620af06276dd040 | tar Pxf -
[PASS] tar xvfj apache-cloudstack-4.1.0-src.tar.bz2
[PASS] diff -r /tmp/cloudstack/apache-cloudstack-4.1.0-src /tmp/cloudstack/tree
[PASS] mvn --projects='org.apache.cloudstack:cloudstack'
org.apache.rat:apache-rat-plugin:0.8:check
[PASS] mvn -P developer,systemvm clean install
[PASS] mvn -P developer -pl developer,tools/devcloud -Ddeploydb
POST AUTOMATION STEPS:


You now need to start the CloudStack management server via: mvn -pl
:cloud-client-ui jetty:run

Once the management server starts on your local machine, execute the
following commands to bring up a basic zone using the devcloud2 VM:

  Deploy DevCloud (make sure mysql-connector-python is installed and
that the management server is running)
  $ mvn -P developer -pl tools/devcloud -Ddeploysvr

  Or, if the above does not work, maybe

Re: [DOCS][TRANSLATIONS] Upate

2013-04-23 Thread Gavin Lee

Following Milamber's guide , below process I used for
4.1.xmessage.properties on zh_CN:
1. git pull for the latest messages_zh_CN.properties
2. native2ascii -reverse messages_zh_CN.properties
/tmp/zh_CN.properties.native -encoding utf8
3. copy to the CloudStack_UI transifex project: cp/tmp/zh_CN.properties.native /
txprj/acsui/translations/CloudStack_UI.41xmessageproperties
4. tx push -l zh_CN -r CloudStack_UI.41xmessageproperties -t
5. Do translation on transifex, there are some untranslated items when
syncing with en.properties
6. tx pull -a


Then convert to ascii with unicode, the i18nedit tools throws exception, I
tried native2ascii command as below and UI display correctly:
native2ascii -encoding UTF-8 zh_CN.properties messages_zh_CN.properties

Are the whole processes above correct or not?




On Tue, Apr 23, 2013 at 12:01 AM, Sebastien Goasguen run...@gmail.comwrote:

 Milamber, I made you a manager of the transifex project so you can help
 fixing those issues.

 -sebastien

 On Apr 22, 2013, at 11:10 AM, Milamber milam...@apache.org wrote:

 
 
  Le 17/04/2013 07:26, Sebastien Goasguen a ecrit :
  On Apr 16, 2013, at 11:10 AM, Milambermilam...@apache.org  wrote:
 
 
  Le 16/04/2013 13:41, Gavin Lee a ecrit :
  Yes, Traditional Chinese moving very quickly.
  Hopefully, the other languages can have more contributors.
 
  For the UI part, I saw the characters are not recognizable (browser
  encoding setting: auto detect   Unicode UTF-8):
  ja: http://snag.gy/AVsbU.jpg
  zh_CN: http://snag.gy/MxbBS.jpg
  This screenshots shows some characters with a incorrect encoding (try
 to display a char as a ISO-8859-1 (or japanese charset) but the encoding is
 a UTF-8, I think)
 
  With Sebgoa, we have correct all UI ressource file to have only one
 encoding charset in this files (ASCII with unicode). The transifex data
 isn't up-to-date.
 
  Sebgoa, I think we must upload the last version of this (all)
 resources files (except FR already done) from branch 4.1 to transifex.
  The last version of resources files is ASCII with unicode for *all
 chars* in each file, and now transifex keep the unicode char (check with FR
 download for use)
 
  Mistake: transifex don't support uploaded unicode chars.
 
  The way the original workflow was:
  -Upload new versions of the resources file in english
  -Translators create a new language in transifex.
  -Download new language resources file
  -Fix encoding
 
  For the fix encoding step, we can use this (unix and JDK) commands for
 each language:
 
  CODELANG=it_IT
 
 FILE_TRANSIFEX=for_use_CloudStack_UI_41xmessageproperties_${CODELANG}.properties
  FILE_RES=messages_${CODELANG}.properties
 
  # Convert to ascii with unicode (native2ascii is a JDK tool)
  native2ascii ${FILE_TRANSIFEX} /tmp/${FILE_RES}.ascii-with-unicode
 
  # sort key, add a double-backslash before the quote char ( ' == \\' )
  grep -v ^# /tmp/${FILE_RES}.ascii-with-unicode | sort -f | uniq | sed
 s/'/\'/g 
 /tmp/${FILE_RES}.ascii-with-unicode_doublebackslashquote
 
  # Define Apache Licence Header (one long line)
  AL2_STRING=# Licensed to the Apache Software Foundation (ASF) under
 one\n# or more contributor license agreements.  See the NOTICE file\n#
 distributed with this work for additional information\n# regarding
 copyright ownership.  The ASF licenses this file\n# to you under the Apache
 License, Version 2.0 (the\n# \License\); you may not use this file except
 in compliance\n# with the License.  You may obtain a copy of the License
 at\n#\n#   http://www.apache.org/licenses/LICENSE-2.0\n#\n# Unless
 required by applicable law or agreed to in writing,\n# software distributed
 under the License is distributed on an\n# \AS IS\ BASIS, WITHOUT
 WARRANTIES OR CONDITIONS OF ANY\n# KIND, either express or implied.  See
 the License for the\n# specific language governing permissions and
 limitations\n# under the License.
 
  # Re-introduce the AL2 header
  echo -e $AL2_STRING | cat -
 /tmp/${FILE_RES}.ascii-with-unicode_doublebackslashquote 
 ./FOR_REPO_${FILE_RES}
 
 
 
  So I never uploaded the language specific resource file to transifex.
 Won't we have a problem that they won't stay in sync with the en-US
 resource file, if it gets changed ?
 
  On upload, Transifex seems only get the matching key with source
 language.
 
 
  In any case I uploaded the ja-JP resource file and the result on
 transifex is less than optimal, check the unreviewed strings, there is a
 mix of encoding.
 
  We needs to revert the native to ascii convert.
  We can use this steps for each language before uploading on transifex :
 
  CODELANG=ja
  FILE_RES=messages_${CODELANG}.properties
 
  # Revert convert
  native2ascii -reverse ${FILE_RES} /tmp/${FILE_RES}.native1
 
  # Remove double backslashes before quote
  sed s/\\\'/'/g /tmp/${FILE_RES}.native1  ${FILE_RES}.native
 
 
  I've tested this commandes for download/upload with French language, and
 just for download with ko_KR, it_IT, ca, ja, pt_BR.
 
 
  I can

RE: [VOTE] Apache CloudStack 4.1.0 (second round)

2013-04-23 Thread Hugo Trippaers

All,

-1 :-(

Found a small issue in packaging.sh. It did not work with the nonoss build and 
a version number without SNAPSHOT. See ticket CLOUDSTACK-2152.

Fixed with commit f9c6d01cfb90aa7c5bac5c5be20a7a16e30a9aec and 
df2e0108ea312e3061cd7e00d2cf4c5eaf5431fb

Cheers,

Hugo

 -Original Message-
 From: Chip Childers [mailto:chip.child...@sungard.com]
 Sent: Tuesday, April 23, 2013 2:05 AM
 To: dev@cloudstack.apache.org
 Subject: [VOTE] Apache CloudStack 4.1.0 (second round)
 
 Hi All,
 
 I've created a 4.1.0 release, with the following artifacts up for a
 vote:
 
 Changes from the first round of voting:
 Marcus found an RPM build issue when -SNAPSHOT is removed from our
 mvn pom.xml files, and submitted a patch for it (commit-sh 73b7fa9d).
 
 Git Branch and Commit SH:
 https://git-wip-
 us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.1
 Commit: 7048baaa4417880db690cba4a620af06276dd040
 
 List of changes:
 https://git-wip-
 us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.1
 
 Source release (checksums and signatures are available at the same
 location):
 https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/
 
 PGP release keys (signed using A99A5D58):
 https://dist.apache.org/repos/dist/release/cloudstack/KEYS
 
 Testing instructions are here:
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+pr
 ocedure
 
 Vote will be open for 72 hours.
 
 For sanity in tallying the vote, can PMC members please be sure to indicate
 (binding) with their vote?
 
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)

Re: [DISCUSS] ACS Release 4 month v/s 6 month

The problem (I am beginning to realize) with extending the release is
the temptation to cram in more features. May be use the collab
conference to improve release management aspects. What we did right
in 4.1, what went wrong, how to better plan 5.0. And that can happen
with a 4 or 6 month cycle. I understand the exclusive nature of this
but I do think that everything must/should be brought back to the
lists judiciously. 

To me making our release cadence easier to follow is an important step
towards bringing in more contributions. If that happens soon the
better - offline or online. Either way the effect is going to be felt
on the list since release management affects everyone.

IMO, even with a time-based release we need to think of things like:
 - Is this proposal targeted for the next release going to be
   disruptive to others
 - Are we changing architecture aspects of the system - that work must
   happen well in advance.
 - What features are possibly stalled by architecture work/refactors
   etc.
 - When to pull the plug on proposals to make it to the next release.
   Or do we just consume everything until code freeze
 - What gets manual tested, what gets automated. Are we reviewing our
   test plans?

It seems like anything that's had a discussion and a wiki page under
4.2 release is already targeted for that release now. Just go look at
it. It's massive! :)

On Mon, Apr 22, 2013 at 08:13:55PM -0700, Edison Su wrote:
 +1, on the automation test. When will we have good automation test?

After a long-winded struggle from our startup days - automated tests
are _finally_ becoming a priority. That in itself is a great leap
forward for us as a project. Until now I'd say testing hasn't received
the same love as the love for adding new features. But it'll take us a
release or two to build up those test suites strong enough to ensure
that our releases are not delayed. Time is nigh to think along the
lines of testability of features being merged, proposed and churned in
our topic branches.

I'd like to see the day when our threads on release management grow
shorter than those done as reviews for patches and topic branches. We
need to seriously start paying attention to:
 - The work happening around in those silos (topic branches).
 - And to the bugs users have been reporting. 
 - Reviews of test plans is going to have to be considered seriously
 - During those reviews think about automating the QA tests. If
   framework support doesn't exist, extend the test framework to
   support that.

It's great that we at least begin to add tests when we need our
feature merged now. Where we need to get to is start thinking about
testability from the beginning of feature planning. All of this if we
do even with a reasonable efficiency I think 4 months should be
doable.

-- 
Prasanna.,


Powered by BigRock.com

Re: [VOTE] Apache CloudStack 4.1.0 (second round)

On Tue, Apr 23, 2013 at 02:08:46PM +, Hugo Trippaers wrote:
 All,
 
 -1 :-(
 
 Found a small issue in packaging.sh. It did not work with the nonoss
 build and a version number without SNAPSHOT. See ticket
 CLOUDSTACK-2152.
 
 Fixed with commit f9c6d01cfb90aa7c5bac5c5be20a7a16e30a9aec and
 df2e0108ea312e3061cd7e00d2cf4c5eaf5431fb
 
 Cheers,
 
 Hugo

Grrmph, Should we begin voting only when the following are ensured:

a. builds fine (oss and nonoss)
b. packages fine (oss and nonoss)
c. All jenkins jobs are stable

Thoughts?

-- 
Prasanna.,


Powered by BigRock.com

Re: [VOTE] Apache CloudStack 4.1.0 (second round)

On Tue, Apr 23, 2013 at 07:50:39PM +0530, Prasanna Santhanam wrote:
 On Tue, Apr 23, 2013 at 02:08:46PM +, Hugo Trippaers wrote:
  All,
  
  -1 :-(
  
  Found a small issue in packaging.sh. It did not work with the nonoss
  build and a version number without SNAPSHOT. See ticket
  CLOUDSTACK-2152.
  
  Fixed with commit f9c6d01cfb90aa7c5bac5c5be20a7a16e30a9aec and
  df2e0108ea312e3061cd7e00d2cf4c5eaf5431fb
  
  Cheers,
  
  Hugo
 
 Grrmph, Should we begin voting only when the following are ensured:
 
 a. builds fine (oss and nonoss)
 b. packages fine (oss and nonoss)
 c. All jenkins jobs are stable

Yes, in fact I'm going to take a bit longer with the next round.  I want
to do oss / nonoss builds + packaging testing on RHEL and Ubuntu.

I do check the jenkins jobs are clear before cutting though.

What we don't see in jenkins are the issues found with removing SNAPSHOT
from our version number, because of the way that these jobs are
currently coded (also due to the preference stated to re-version back to
the SNAPSHOT version in the repo as part of spinning out the RC...
i.e.: one commit that we use to vote against that removes SNAPSHOT and
one immediately after that reverts that change).

-chip

[CANCELLED][VOTE] Apache CloudStack 4.1.0 (second round)

Meh...  Cancelling this vote due to the packaging issues that Hugo
found.  I'm going to test packaging of oss and non-oss on RHEL and
Ubuntu before re-starting the vote.

Wido is busy this week, but asked that someone specifically confirm the
DEB packaging for the awsapi module.  I'd love if someone could step up
and re-confirm that the DEB packaging works for that module in the
current 4.1 HEAD revision.  Any takers?

Re: Review Request: CLOUDSTACK-2147: Missing configuration variable max.project.cpus in configuration table

2013-04-23 Thread ASF Subversion and Git Services


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


Commit 799d906ac99cc739929dc64874b03acd66d68772 in branch refs/heads/4.1 from 
Chip Childers chip.child...@gmail.com
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=799d906 ]

CLOUDSTACK-2147: Missing configuration variable max.project.cpus in 
configuration table


- ASF Subversion and Git Services


On April 23, 2013, 10:41 a.m., Sanjay Tripathi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/10726/
 ---
 
 (Updated April 23, 2013, 10:41 a.m.)
 
 
 Review request for cloudstack, Devdeep Singh, Chip Childers, and Min Chen.
 
 
 Description
 ---
 
 CLOUDSTACK-2147: Missing configuration variable max.project.cpus in 
 configuration table.
 
 Removed the max.project.cpus, max.project.memory, max.account.cpus, 
 max.account.memory from schema-40to410.sql file as the feature to limit these 
 values got shifted to 4.2.
 
 
 This addresses bug CLOUDSTACK-2147.
 
 
 Diffs
 -
 
   setup/db/db/schema-40to410.sql 3fbd075 
 
 Diff: https://reviews.apache.org/r/10726/diff/
 
 
 Testing
 ---
 
 Tests:
 1. Setup CloudStack environment.
 2. Go to Infrastructure tab.
 3. Verified that max.project.cpus parameter is not present along with other 
 parameters.
 
 
 Thanks,
 
 Sanjay Tripathi

Re: Review Request: CLOUDSTACK-2147: Missing configuration variable max.project.cpus in configuration table


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

Ship it!


Ship It!

- Chip Childers


On April 23, 2013, 10:41 a.m., Sanjay Tripathi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/10726/
 ---
 
 (Updated April 23, 2013, 10:41 a.m.)
 
 
 Review request for cloudstack, Devdeep Singh, Chip Childers, and Min Chen.
 
 
 Description
 ---
 
 CLOUDSTACK-2147: Missing configuration variable max.project.cpus in 
 configuration table.
 
 Removed the max.project.cpus, max.project.memory, max.account.cpus, 
 max.account.memory from schema-40to410.sql file as the feature to limit these 
 values got shifted to 4.2.
 
 
 This addresses bug CLOUDSTACK-2147.
 
 
 Diffs
 -
 
   setup/db/db/schema-40to410.sql 3fbd075 
 
 Diff: https://reviews.apache.org/r/10726/diff/
 
 
 Testing
 ---
 
 Tests:
 1. Setup CloudStack environment.
 2. Go to Infrastructure tab.
 3. Verified that max.project.cpus parameter is not present along with other 
 parameters.
 
 
 Thanks,
 
 Sanjay Tripathi

Re: [ACS41][Patch Request]

On Tue, Apr 23, 2013 at 10:42:53AM +, Sanjay Tripathi wrote:
 CLOUDSTACK-2147 : Missing configuration variable max.project.cpus in 
 configuration table.
 
 --Sanjay

Applied.  Thanks!

Re: [VOTE] Apache CloudStack 4.1.0 (second round)

On Tue, Apr 23, 2013 at 10:25:13AM -0400, Chip Childers wrote:
 On Tue, Apr 23, 2013 at 07:50:39PM +0530, Prasanna Santhanam wrote:
  On Tue, Apr 23, 2013 at 02:08:46PM +, Hugo Trippaers wrote:
   All,
   
   -1 :-(
   
   Found a small issue in packaging.sh. It did not work with the nonoss
   build and a version number without SNAPSHOT. See ticket
   CLOUDSTACK-2152.
   
   Fixed with commit f9c6d01cfb90aa7c5bac5c5be20a7a16e30a9aec and
   df2e0108ea312e3061cd7e00d2cf4c5eaf5431fb
   
   Cheers,
   
   Hugo
  
  Grrmph, Should we begin voting only when the following are ensured:
  
  a. builds fine (oss and nonoss)
  b. packages fine (oss and nonoss)
  c. All jenkins jobs are stable
 
 Yes, in fact I'm going to take a bit longer with the next round.  I want
 to do oss / nonoss builds + packaging testing on RHEL and Ubuntu.
 

Thanks Chip - job [1] packages OSS and [2] tests the package by
configuring the server on a base rhel6.3 VM with puppet. So OSS is
taken care of for RHEL.

[1] http://jenkins.buildacloud.org/job/package-rhel63-4.1/
[2] http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-packaging/

 I do check the jenkins jobs are clear before cutting though.
 
 What we don't see in jenkins are the issues found with removing SNAPSHOT
 from our version number, because of the way that these jobs are
 currently coded (also due to the preference stated to re-version back to
 the SNAPSHOT version in the repo as part of spinning out the RC...
 i.e.: one commit that we use to vote against that removes SNAPSHOT and
 one immediately after that reverts that change).
 
 -chip

-- 
Prasanna.,


Powered by BigRock.com

Re: [VOTE] Apache CloudStack 4.1.0 (second round)

On Tue, Apr 23, 2013 at 08:30:41PM +0530, Prasanna Santhanam wrote:
 On Tue, Apr 23, 2013 at 10:25:13AM -0400, Chip Childers wrote:
  On Tue, Apr 23, 2013 at 07:50:39PM +0530, Prasanna Santhanam wrote:
   On Tue, Apr 23, 2013 at 02:08:46PM +, Hugo Trippaers wrote:
All,

-1 :-(

Found a small issue in packaging.sh. It did not work with the nonoss
build and a version number without SNAPSHOT. See ticket
CLOUDSTACK-2152.

Fixed with commit f9c6d01cfb90aa7c5bac5c5be20a7a16e30a9aec and
df2e0108ea312e3061cd7e00d2cf4c5eaf5431fb

Cheers,

Hugo
   
   Grrmph, Should we begin voting only when the following are ensured:
   
   a. builds fine (oss and nonoss)
   b. packages fine (oss and nonoss)
   c. All jenkins jobs are stable
  
  Yes, in fact I'm going to take a bit longer with the next round.  I want
  to do oss / nonoss builds + packaging testing on RHEL and Ubuntu.
  
 
 Thanks Chip - job [1] packages OSS and [2] tests the package by
 configuring the server on a base rhel6.3 VM with puppet. So OSS is
 taken care of for RHEL.
 
 [1] http://jenkins.buildacloud.org/job/package-rhel63-4.1/
 [2] http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-packaging/

The problem we hit was a packaging logic fork that doesn't get hit
normally...  specifically version without SNAPSHOT.

(BTW, glad that DNS got setup)

Building Cloudstack 4.0.1 Ubuntu (Debian) install packages

2013-04-23 Thread Jim L.

Hi,

I have been trying to build the Ubuntu/Debian install packages for
Cloudstack 4.0.1 with VMWare enabled (mvn install -Dnonoss).  The maven
build shows success, but then building the actual install packages does not
include the VMWare jar files, apparently.

I've tried to hand-stitch together a working Cloudstack 4.0.1 release on
an Ubuntu system by placing the VMWare snapshot jar file into
/usr/share/java and also including the VMWare-specific jar files
(vmware-apputils.jar, vmware-vim25.jar, vmware-vim.jar);  this was after
running apt-get install of the packages I created on the target system.  Up
to now, I have been unsuccessful, so I assume there must be some sort of
embedded properties file that signifies if VMWare is an enabled plugin.

Has anyone been successful building Cloudstack 4.0.1 with VMWare support
and then deploying it to Ubuntu 12.04?

Thanks -- Jim L.

Re: [ACS41] Catalana.out needs log rotate

2013-04-23 Thread Ahmad Emneina

+1 to consolidating and or log rotation addition.

Ahmad

On Apr 23, 2013, at 4:39 AM, Hugo Trippaers htrippa...@schubergphilis.com 
wrote:

 I would vote for ditching the CONSOLE log completely.  It's useful to see the 
 startup messages from catalina (tomcat), but we should put all cloudstack 
 logs in the management log (or agent/usage). I see not much use in 
 duplicating the logs in both the management.log and the catalina.out.
 
 Cheers,
 
 Hugo
 
 -Original Message-
 From: Musayev, Ilya [mailto:imusa...@webmd.net]
 Sent: Tuesday, April 23, 2013 6:00 AM
 To: dev@cloudstack.apache.org; Kelven Yang
 Subject: RE: [ACS41] Catalana.out needs log rotate
 
 This should work, and we can make it part of RPM/DEB builds.
 
 1. Create this file
 /etc/logrotate.d/tomcat
 
 2. Copy the following contents into the above file
 /var/log/cloudstack/management/catalina.out { copytruncate daily rotate 7
 compress missingok size 5M }
 
 -Original Message-
 From: Musayev, Ilya [mailto:imusa...@webmd.net]
 Sent: Monday, April 22, 2013 11:53 PM
 To: Kelven Yang; dev@cloudstack.apache.org
 Subject: RE: [ACS41] Catalana.out needs log rotate
 
 In that case, we can use native system log rotate daemon.
 
 If no objections, I can take this on.
 
 
 -Original Message-
 From: Kelven Yang [mailto:kelven.y...@citrix.com]
 Sent: Monday, April 22, 2013 9:08 PM
 To: dev@cloudstack.apache.org; Musayev, Ilya
 Subject: Re: [ACS41] Catalana.out needs log rotate
 
 For log4j log files, we are using the rotation facility offered by log4j.
 catalina.out may be a problem here, I think it is created in using shell
 redirection
 
 Kelven
 
 On 4/22/13 5:34 PM, Musayev, Ilya imusa...@webmd.net wrote:
 
 Catalana.out on a lightly used demo ACS41 is 166mb in size in less than
 2 weeks old implementation running on centos6.3
 
 How does log rotate  work?  Would anyone know if we are using Linux
 based log rotate or some other engine?
 
 Thanks
 Ilya

Re: Release Verification Tool - if you're interested

2013-04-23 Thread John Burwell

Chip,

I just attempted to use the release verification script on Ubuntu 12.04.2 LTS 
with the stock instructions.conf file provided in the git repo, and I receiving 
the following error:

root@zone1:/opt/release-verification-tool# ./verify-release.py -i 
instructions.conf -v 4.1.0 -c 7048baaa4417880db690cba4a620af06276dd040
RUNNING COMMAND: rm -Rf /tmp/cloudstack
RUNNING COMMAND: rm -Rf ~/.m2
RUNNING COMMAND: mkdir /tmp/cloudstack
RUNNING COMMAND: wget --no-check-certificate -q 
https://dist.apache.org/repos/dist/release/cloudstack/KEYS
RUNNING COMMAND: wget --no-check-certificate -q 
https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/apache-cloudstack-4.1.0-src.tar.bz2
RUNNING COMMAND: wget --no-check-certificate -q 
https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/apache-cloudstack-4.1.0-src.tar.bz2.asc
RUNNING COMMAND: wget --no-check-certificate -q 
https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/apache-cloudstack-4.1.0-src.tar.bz2.md5
RUNNING COMMAND: wget --no-check-certificate -q 
https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/apache-cloudstack-4.1.0-src.tar.bz2.sha
RUNNING COMMAND: gpg --verify apache-cloudstack-4.1.0-src.tar.bz2.asc
OUTPUT:
AUTOMATED TESTING RESULTS:
[PASS]  rm -Rf /tmp/cloudstack
[PASS]  rm -Rf ~/.m2
[PASS]  mkdir /tmp/cloudstack
[PASS]  wget --no-check-certificate -q 
https://dist.apache.org/repos/dist/release/cloudstack/KEYS
[PASS]  wget --no-check-certificate -q 
https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/apache-cloudstack-4.1.0-src.tar.bz2
[PASS]  wget --no-check-certificate -q 
https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/apache-cloudstack-4.1.0-src.tar.bz2.asc
[PASS]  wget --no-check-certificate -q 
https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/apache-cloudstack-4.1.0-src.tar.bz2.md5
[PASS]  wget --no-check-certificate -q 
https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/apache-cloudstack-4.1.0-src.tar.bz2.sha
[FAILED]gpg --verify apache-cloudstack-4.1.0-src.tar.bz2.asc
[SKIPPED]   gpg --print-md MD5 apache-cloudstack-${version}-src.tar.bz2 | 
diff - apache-cloudstack-${version}-src.tar.bz2.md5
[SKIPPED]   gpg --print-md SHA512 apache-cloudstack-${version}-src.tar.bz2 
| diff - apache-cloudstack-${version}-src.tar.bz2.sha
[SKIPPED]   mkdir /tmp/cloudstack/git
[SKIPPED]   mkdir /tmp/cloudstack/tree
[SKIPPED]   git clone -q 
https://git-wip-us.apache.org/repos/asf/cloudstack.git /tmp/cloudstack/git
[SKIPPED]   git archive --prefix=/tmp/cloudstack/tree/ ${commit-sh} | tar 
Pxf -
[SKIPPED]   tar xvfj apache-cloudstack-${version}-src.tar.bz2
[SKIPPED]   diff -r /tmp/cloudstack/apache-cloudstack-${version}-src 
/tmp/cloudstack/tree
[SKIPPED]   mvn --projects='org.apache.cloudstack:cloudstack' 
org.apache.rat:apache-rat-plugin:0.8:check
[SKIPPED]   mvn -P developer,systemvm clean install
[SKIPPED]   mvn -P developer -pl developer,tools/devcloud -Ddeploydb
Traceback (most recent call last):
  File ./verify-release.py, line 121, in module
main(sys.argv[1:])
  File ./verify-release.py, line 118, in main
x.print_results()
  File ./verify-release.py, line 85, in print_results
print [ + self.FAIL + action[result] + self.ENDC + ]\t + 
action[command]

When I execute `gpg --verify apache-cloudstack-4.1.0-src.tar.bz2.asc` in 
/tmp/cloudstack, I get the following error:

root@zone1:/tmp/cloudstack# gpg --verify apache-cloudstack-4.1.0-src.tar.bz2.asc
gpg: Signature made Mon 22 Apr 2013 04:45:37 PM PDT using RSA key ID A99A5D58
gpg: Can't check signature: public key not found

What am I doing wrong?
-John

On Apr 23, 2013, at 9:44 AM, Chip Childers chip.child...@sungard.com wrote:

 7048baaa4417880db690cba4a620af06276dd040

Re: Release Verification Tool - if you're interested

On Tue, Apr 23, 2013 at 11:51:02AM -0400, John Burwell wrote:
 root@zone1:/tmp/cloudstack# gpg --verify 
 apache-cloudstack-4.1.0-src.tar.bz2.asc
 gpg: Signature made Mon 22 Apr 2013 04:45:37 PM PDT using RSA key ID A99A5D58
 gpg: Can't check signature: public key not found
 
 What am I doing wrong?

You have to have imported the KEYS file previously...  so just do:

wget --no-check-certificate 
https://dist.apache.org/repos/dist/release/cloudstack/KEYS /tmp/KEYS
gpg --import /tmp/KEYS

[PATCH REQUEST][ACS41] CLOUDSTACK-2154: create account command

If there are no objections I'd like to include CLOUDSTACK-2154 into
the 4.1 release. While createAccount returns the response with all the
necessary account related information, cloudmonkey, marvin and
apidocs are told (via annotation) that the createAccount returns a
user response. More details are in the bug report.

The commit to cherry-pick on master is
a792d3a3aab6c5e2cec014395b801b0d1e207779

Thanks,

-- 
Prasanna.,


Powered by BigRock.com

[ACS51][NETWORK][DIAGRAM] Needs review and feedback

2013-04-23 Thread Musayev, Ilya

I'm working on best practices for setting up ACS with Advanced Network and 
vSphere.

If possible, please briefly review this very good looking diagram and comment 
on what I may have missed.

Pretext: I specifically left out the common used ports for ACS, since I'm 
putting all of ACS infrastructure on 1 locked down network.

http://oi38.tinypic.com/ildstf.jpg

Feedback is welcome,

Thanks
ilya

[RESULT][VOTE][ACS402] Apache CloudStack 4.0.2 (Third Round)

2013-04-23 Thread Joe Brockmeier

After 72 hours, the vote for CloudStack 4.0.2 *passes* with 5 +1 binding
votes and 2 +1 votes:

+1 (binding)

* David Nalley
* Chip Childers
* Hugo Trippaers
* Sebastien Goasguen
* Marcus Sorensen

+1 

* Simon Weller
* Gavin Lee

There were no -1 or +0 votes cast. 

I will be publishing the release today, and will put out the release
announcement tomorrow after the mirrors have had a chance to catch up.

Thanks to everyone for participating! 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

[REMINDER] Weekly IRC Meeting Tomorrow at 17:00 UTC

2013-04-23 Thread Joe Brockmeier

Hey all,

A friendly reminder, we have a weekly IRC meeting scheduled for tomorrow
(24 April 2013) at 17:00 UTC [1]. 

The standing agenda is here:
https://cwiki.apache.org/CLOUDSTACK/irc-meetings-logs-and-minutes.html

Please join us in #cloudstack-meeting on Freenode. If you're not a
regular IRC user, you can use the webchat: http://webchat.freenode.net/

It's useful if everyone arrives at the meeting time and stays on topic.
Please try to arrive at or very close to 17:00 UTC and be sure to follow
the topics as they're discussed, and add EOF or something similar when
you're done speaking. 

Meeting summaries are posted immediately after the meeting, you can find
older meeting logs here:

http://wilderness.apache.org/archives/#logs-cloudstack-meeting

[1] http://is.gd/e11nUH

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Error running Ddeploysvr

I pulled from the apache master (
https://git-wip-us.apache.org/repos/asf/cloudstack.git) yesterday and the
latest commit that I have is: bdd5634924db84144c05887c6552c89aa4e78051

I have the code compiling correctly and I am able to start the server.

When I try to do: mvn -P developer -pl tools/devcloud -Ddeploysvr -X

I get the error at the bottom.

Troubleshooting I have done so far...
- I have two version of python on my CentOs system.  2.6 and 2.7
- I have installed 'tools/marvin/dist/Marvin-0.1.0.tar.gz' on both the 2.6
and 2.7 versions of python
- I am still getting the 'ImportError: No module named requests', so I
installed the 'requests' module for both the 2.6 and 2.7 versions of python
(which resolves that error).
- If I run 'python2.7 ../marvin/marvin/deployDataCenter.py -i devcloud.cfg'
directly, I also get this same error.

I would like to get back into development, so I would like to get this
resolved.  Any help would be appreciated.

Thanks,

Will

---

[DEBUG] -- end configuration --
[DEBUG] Executing command line: python ../marvin/marvin/deployDataCenter.py
-i devcloud.cfg
Traceback (most recent call last):
  File ../marvin/marvin/deployDataCenter.py, line 469, in module
deploy.deploy()
  File ../marvin/marvin/deployDataCenter.py, line 452, in deploy
self.loadCfg()
  File ../marvin/marvin/deployDataCenter.py, line 409, in loadCfg
apiKey, securityKey = self.registerApiKey()
  File ../marvin/marvin/deployDataCenter.py, line 349, in registerApiKey
listuserRes = self.testClient.getApiClient().listUsers(listuser)
  File
/mnt/hgfs/palo_alto/incubator-cloudstack/tools/marvin/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 428, in listUsers
response = self.connection.make_request(command, response)
AttributeError: 'cloudConnection' object has no attribute 'make_request'
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 13.959s
[INFO] Finished at: Tue Apr 23 12:45:16 EDT 2013
[INFO] Final Memory: 20M/50M
[INFO]

[ERROR] Failed to execute goal
org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (default) on project
cloud-devcloud: Command execution failed. Process exited with an error: 1
(Exit value: 1) - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (default) on project
cloud-devcloud: Command execution failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Command
execution failed.
at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:362)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.apache.commons.exec.ExecuteException: Process exited with an
error: 1 (Exit value: 1)
at
org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:377)
at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:160)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:610)
at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:352)
... 21 more
[ERROR]
[ERROR]
[ERROR] For more information about the errors and possible

Re: Error running Ddeploysvr

You will need to update marvin since I changed the
cloudstackConnection class last week to get POST requests to work.

When you startup the server using jetty:run you can do a marvin.sync
as follows:

$ sudo mvn -Pdeveloper,sync -Dendpoint=localhost -pl :cloud-marvin

This assumes you have pip installed on your machine for python 2.7.

If that doesn't work simply do
$ pip uninstall -y marvin
$ pip install tools/marvin/dist/Marvin-0.1.0.tar.gz

-- 
Prasanna.,

On Tue, Apr 23, 2013 at 01:03:25PM -0400, Will Stevens wrote:
 I pulled from the apache master (
 https://git-wip-us.apache.org/repos/asf/cloudstack.git) yesterday and the
 latest commit that I have is: bdd5634924db84144c05887c6552c89aa4e78051
 
 I have the code compiling correctly and I am able to start the server.
 
 When I try to do: mvn -P developer -pl tools/devcloud -Ddeploysvr -X
 
 I get the error at the bottom.
 
 Troubleshooting I have done so far...
 - I have two version of python on my CentOs system.  2.6 and 2.7
 - I have installed 'tools/marvin/dist/Marvin-0.1.0.tar.gz' on both the 2.6
 and 2.7 versions of python
 - I am still getting the 'ImportError: No module named requests', so I
 installed the 'requests' module for both the 2.6 and 2.7 versions of python
 (which resolves that error).
 - If I run 'python2.7 ../marvin/marvin/deployDataCenter.py -i devcloud.cfg'
 directly, I also get this same error.
 
 I would like to get back into development, so I would like to get this
 resolved.  Any help would be appreciated.
 
 Thanks,
 
 Will
 
 ---
 
 [DEBUG] -- end configuration --
 [DEBUG] Executing command line: python ../marvin/marvin/deployDataCenter.py
 -i devcloud.cfg
 Traceback (most recent call last):
   File ../marvin/marvin/deployDataCenter.py, line 469, in module
 deploy.deploy()
   File ../marvin/marvin/deployDataCenter.py, line 452, in deploy
 self.loadCfg()
   File ../marvin/marvin/deployDataCenter.py, line 409, in loadCfg
 apiKey, securityKey = self.registerApiKey()
   File ../marvin/marvin/deployDataCenter.py, line 349, in registerApiKey
 listuserRes = self.testClient.getApiClient().listUsers(listuser)
   File
 /mnt/hgfs/palo_alto/incubator-cloudstack/tools/marvin/marvin/cloudstackAPI/cloudstackAPIClient.py,
 line 428, in listUsers
 response = self.connection.make_request(command, response)
 AttributeError: 'cloudConnection' object has no attribute 'make_request'
 [INFO]
 
 [INFO] BUILD FAILURE
 [INFO]
 
 [INFO] Total time: 13.959s
 [INFO] Finished at: Tue Apr 23 12:45:16 EDT 2013
 [INFO] Final Memory: 20M/50M
 [INFO]
 
 [ERROR] Failed to execute goal
 org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (default) on project
 cloud-devcloud: Command execution failed. Process exited with an error: 1
 (Exit value: 1) - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
 goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (default) on project
 cloud-devcloud: Command execution failed.
 at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
 at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 at
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
 at
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
 at
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
 at
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
 at
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
 at
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
 Caused by: org.apache.maven.plugin.MojoExecutionException: Command
 execution failed.
 at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:362)
 at

Re: Error running Ddeploysvr

On Tue, Apr 23, 2013 at 10:40:58PM +0530, Prasanna Santhanam wrote:
 You will need to update marvin since I changed the
 cloudstackConnection class last week to get POST requests to work.
 
 When you startup the server using jetty:run you can do a marvin.sync
 as follows:
 
 
typo:
$ sudo mvn -Pdeveloper,marvin.sync -Dendpoint=localhost -pl :cloud-marvin
* marvin.sync 


Powered by BigRock.com

Re: Error running Ddeploysvr

Thanks for responding Prasanna.  Because I am working on CentOs, python2.6
is the default python install.  I have python2.7 installed, but I have to
access it with python2.7 instead of python.  I believe there are actually
problems with CentOs if I change the 'python' command to point to python2.7
(so I have been told, but I will try it).

Is it possible to run this marvin.sync command from the command line
specifying the version of python to use?

Thanks,

Will

ps - this fails right now because python2.6 is my default:

[root@cs4-devcloud incubator-cloudstack]# mvn -Pdeveloper,marvin.sync
-Dendpoint=localhost -pl :cloud-marvin
Listening for transport dt_socket at address: 8787
[INFO] Scanning for projects...
[INFO]

[INFO]

[INFO] Building Apache CloudStack marvin 4.2.0-SNAPSHOT
[INFO]

[INFO]
[INFO] --- exec-maven-plugin:1.2.1:exec (generate-sources) @ cloud-marvin
---
Traceback (most recent call last):
  File codegenerator.py, line 412, in module
cg.generateCodeFromJSON(endpointUrl)
  File codegenerator.py, line 366, in generateCodeFromJSON
apiStream = urllib2.urlopen(endpointUrl)
  File /usr/lib64/python2.6/urllib2.py, line 126, in urlopen
return _opener.open(url, data, timeout)
  File /usr/lib64/python2.6/urllib2.py, line 391, in open
response = self._open(req, data)
  File /usr/lib64/python2.6/urllib2.py, line 409, in _open
'_open', req)
  File /usr/lib64/python2.6/urllib2.py, line 369, in _call_chain
result = func(*args)
  File /usr/lib64/python2.6/urllib2.py, line 1190, in http_open
return self.do_open(httplib.HTTPConnection, req)
  File /usr/lib64/python2.6/urllib2.py, line 1165, in do_open
raise URLError(err)
urllib2.URLError: urlopen error [Errno 111] Connection refused
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 3.432s
[INFO] Finished at: Tue Apr 23 13:34:31 EDT 2013
[INFO] Final Memory: 13M/32M
[INFO]

[ERROR] Failed to execute goal
org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (generate-sources) on
project cloud-marvin: Command execution failed. Process exited with an
error: 1 (Exit value: 1) - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException


On Tue, Apr 23, 2013 at 1:16 PM, Prasanna Santhanam t...@apache.org wrote:

 On Tue, Apr 23, 2013 at 10:40:58PM +0530, Prasanna Santhanam wrote:
  You will need to update marvin since I changed the
  cloudstackConnection class last week to get POST requests to work.
 
  When you startup the server using jetty:run you can do a marvin.sync
  as follows:
 
 
 typo:
 $ sudo mvn -Pdeveloper,marvin.sync -Dendpoint=localhost -pl :cloud-marvin
 * marvin.sync

 
 Powered by BigRock.com

Re: Error running Ddeploysvr

Changed my default python to 2.7 and tried again (error below)...

I will try to uninstall and reinstall marvin...

[root@cs4-devcloud incubator-cloudstack]# mvn -Pdeveloper,marvin.sync
-Dendpoint=localhost -pl :cloud-marvin
Listening for transport dt_socket at address: 8787
[INFO] Scanning for projects...
[INFO]

[INFO]

[INFO] Building Apache CloudStack marvin 4.2.0-SNAPSHOT
[INFO]

[INFO]
[INFO] --- exec-maven-plugin:1.2.1:exec (generate-sources) @ cloud-marvin
---
Traceback (most recent call last):
  File codegenerator.py, line 412, in module
cg.generateCodeFromJSON(endpointUrl)
  File codegenerator.py, line 366, in generateCodeFromJSON
apiStream = urllib2.urlopen(endpointUrl)
  File /usr/local/lib/python2.7/urllib2.py, line 127, in urlopen
return _opener.open(url, data, timeout)
  File /usr/local/lib/python2.7/urllib2.py, line 404, in open
response = self._open(req, data)
  File /usr/local/lib/python2.7/urllib2.py, line 422, in _open
'_open', req)
  File /usr/local/lib/python2.7/urllib2.py, line 382, in _call_chain
result = func(*args)
  File /usr/local/lib/python2.7/urllib2.py, line 1214, in http_open
return self.do_open(httplib.HTTPConnection, req)
  File /usr/local/lib/python2.7/urllib2.py, line 1184, in do_open
raise URLError(err)
urllib2.URLError: urlopen error [Errno 111] Connection refused
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 3.585s
[INFO] Finished at: Tue Apr 23 13:53:56 EDT 2013
[INFO] Final Memory: 13M/32M
[INFO]

[ERROR] Failed to execute goal
org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (generate-sources) on
project cloud-marvin: Command execution failed. Process exited with an
error: 1 (Exit value: 1) - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException



On Tue, Apr 23, 2013 at 1:39 PM, Will Stevens wstev...@cloudops.com wrote:

 Thanks for responding Prasanna.  Because I am working on CentOs, python2.6
 is the default python install.  I have python2.7 installed, but I have to
 access it with python2.7 instead of python.  I believe there are actually
 problems with CentOs if I change the 'python' command to point to python2.7
 (so I have been told, but I will try it).

 Is it possible to run this marvin.sync command from the command line
 specifying the version of python to use?

 Thanks,

 Will

 ps - this fails right now because python2.6 is my default:

 [root@cs4-devcloud incubator-cloudstack]# mvn -Pdeveloper,marvin.sync
 -Dendpoint=localhost -pl :cloud-marvin
 Listening for transport dt_socket at address: 8787
 [INFO] Scanning for projects...
 [INFO]

 [INFO]
 
 [INFO] Building Apache CloudStack marvin 4.2.0-SNAPSHOT
 [INFO]
 
 [INFO]
 [INFO] --- exec-maven-plugin:1.2.1:exec (generate-sources) @ cloud-marvin
 ---
 Traceback (most recent call last):
   File codegenerator.py, line 412, in module
 cg.generateCodeFromJSON(endpointUrl)
   File codegenerator.py, line 366, in generateCodeFromJSON
 apiStream = urllib2.urlopen(endpointUrl)
   File /usr/lib64/python2.6/urllib2.py, line 126, in urlopen
 return _opener.open(url, data, timeout)
   File /usr/lib64/python2.6/urllib2.py, line 391, in open
 response = self._open(req, data)
   File /usr/lib64/python2.6/urllib2.py, line 409, in _open
 '_open', req)
   File /usr/lib64/python2.6/urllib2.py, line 369, in _call_chain
 result = func(*args)
   File /usr/lib64/python2.6/urllib2.py, line 1190, in http_open
 return self.do_open(httplib.HTTPConnection, req)
   File /usr/lib64/python2.6/urllib2.py, line 1165, in do_open
 raise URLError(err)
 urllib2.URLError: urlopen error [Errno 111] Connection refused
 [INFO]
 
 [INFO] BUILD FAILURE
 [INFO]
 
 [INFO] Total time: 3.432s
 [INFO] Finished at: Tue Apr 23 13:34:31 EDT 2013
 [INFO] Final Memory: 13M/32M
 [INFO]
 
 [ERROR] Failed to execute goal
 org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (generate-sources) on
 project cloud-marvin: Command execution failed. Process exited with an

RE: [DISCUSS] ACS Release 4 month v/s 6 month

2013-04-23 Thread Will Chan

Again, I am not disputing that more features will make it in given Dave's 
argument.  In fact, I'm not really that keen on using the fixed cost of release 
mgmt. for the reason of the move as well.   Heck, I'm not even sure a 6 month 
cycle would fix any of the issues that have already been outlined but it'd be 
nice to try.  However, I do know a couple of things:

1. We all want CS releases to be of certain quality.  It needs to work and 
upgrades need to work.
2. ACS still relies too heavily on manual testing and most of it unfortunately 
comes from 1 company.  We cannot be dependent on another company's schedule to 
ensure ACS has gone through enough proper testing to achieve (1). 
3. Most importantly, the extra 2 months will give QA more time, give features 
more time to settle in, and more automated tests to be written for existing 
features as well.  I agree with Dave that more feature will come in.  So what?  
If they are not of good enough quality, we don't release it as part of the ACS 
release.  However, that extra 2 month will give earlier written features more 
time to be potentially tested and used by people so that we fix the most 
egregious bugs before we ship it.  It will also better accommodate people's 
schedule so they can fix bugs for their features.  

Personally, so far, I feel 4 months seems a bit rushed.

Will

 -Original Message-
 From: David Nalley [mailto:da...@gnsa.us]
 Sent: Monday, April 22, 2013 7:52 PM
 To: dev@cloudstack.apache.org
 Cc: cloudstack-...@incubator.apache.org
 Subject: Re: [DISCUSS] ACS Release 4 month v/s 6 month
 
 On Mon, Apr 22, 2013 at 5:19 PM, Animesh Chaturvedi
 animesh.chaturv...@citrix.com wrote:
  Folks
 
  We started discussing 4 month v/s 6 month release cycle in a another
 thread [1]. Since the subject of that thread was different, community may
 not have participated in this important discussion fully. I am  are bringing
 this discussion to its own thread. Here is the summary so far please refer to
 [1] for more details.
 
  Summary of discussion:
  - Animesh pointed out the technical debt that we have accumulated so
  far needs extra time to resolve
  - David, Chip favor shorter release cycle of 4 month and keeping
  master always stable and in good quality and enhancing automation as a
  solution to reduce QA manual effort. A focused defect fixing activity
  may be needed to reduce technical debt
  - Will brought up several points in the discussion: He called out heavy
 dependence on manual QA for a release and pointed out that manual QA
 may not be always available to match up ACS release schedule. Release
 overhead for 4 month release is still high and suggest that moving to 6
 month will save on release overhead and that  time can be used for
 strengthening automation.
   - Joe agrees partly in release overhead being significant for major
  release
 
  If I missed out  any important point please feel free to bring into the
 thread.
 
  There were some other discussion in [1] on release planning conference
 and chip's clarification on time based v/s feature based releases but we will
 not discuss those in this thread. Community has agreed to time-based
 release already.
 
  [1] http://markmail.org/thread/6suq2fhltdvgvcxd
 
 
 
 Hi Animesh:
 
 I thought I would add a few comments. To the folks reading - I apologize for
 the length. If you haven't started yet, you may want to get some coffee/tea.
 You've been warned. :)
 
 I think there are two concerns people think about when talking about
 changing the length of the release cycle.
 
 The first concern is workload. Generating a release has a certain fixed
 amount of overhead. Writing release notes, running votes, and a key part of
 the discussion currently is the QA cycle. Currently a large portion of our QA
 cycle is manual testing, which means we need lots of fingers on keyboards
 to get it done.
 
 The other concern is quality. We always want to try and put our best foot
 forward, and minimize bugs, yet the very act of developing software, and
 especially developing new features, introduces bugs.
 
 Before I start telling you my reasoning, I want to lay out something that
 only hit me tonight. We've talked about how extending the release cycle
 only extends the length of development. We've talked about keeping the
 length of the development period (e.g. pre-code freeze) the same, and
 essentially only extending the amount of time for QA.
 That works for the first release after a move from 4 to 6 months. It falls
 apart there after though. The problem is that at code freeze we branch.
 Master immediately becomes open for future feature development, and
 you've just extended it by an additional 2 months, because your cycle is
 that much longer.
 
 I personally don't think that either concern is addressed well by lengthening
 the cycle. Let me explain why
 
 On the quality front - the immediate threat to quality is instability inserted
 by additional development/new

Re: Error running Ddeploysvr

I have changed my 'python' reference to point to my 2.7 version (which
seems to be working).

When I start the server and then run this in another terminal window I get
this:

[root@cs4-devcloud incubator-cloudstack]# mvn -Pdeveloper,marvin.sync
-Dendpoint=localhost -pl :cloud-marvin
ERROR: transport error 202: bind failed: Address already in use
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized
[../../../src/share/back/debugInit.c:690]
FATAL ERROR in native method: JDWP No transports initialized,
jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
Aborted

I have also tried using the actual IP of my server instead of localhost
(but it gives the same error).  I will need to figure out what is blocking
it here.

Thanks again...


On Tue, Apr 23, 2013 at 1:55 PM, Prasanna Santhanam t...@apache.org wrote:

 The error you are seeing is because you need the management server
 running in a separate shell. What marvin.sync does is it discovers
 APIs on a running management server, generates marvin classes and
 updates the marvin to latest for python to discover it.

 The CentOS python 2.6 is certainly a problem. What you could do is
 install python2.7 and alias python to python2.7. That way when you run
 it from mvn you call python2.7 and things like yum don't break.

 Thanks,

 --
 Prasanna.,

 On Tue, Apr 23, 2013 at 01:39:15PM -0400, Will Stevens wrote:
  Thanks for responding Prasanna.  Because I am working on CentOs,
 python2.6
  is the default python install.  I have python2.7 installed, but I have to
  access it with python2.7 instead of python.  I believe there are actually
  problems with CentOs if I change the 'python' command to point to
 python2.7
  (so I have been told, but I will try it).
 
  Is it possible to run this marvin.sync command from the command line
  specifying the version of python to use?
 
  Thanks,
 
  Will
 
  ps - this fails right now because python2.6 is my default:
 
  [root@cs4-devcloud incubator-cloudstack]# mvn -Pdeveloper,marvin.sync
  -Dendpoint=localhost -pl :cloud-marvin
  Listening for transport dt_socket at address: 8787
  [INFO] Scanning for projects...
  [INFO]
 
  [INFO]
  
  [INFO] Building Apache CloudStack marvin 4.2.0-SNAPSHOT
  [INFO]
  
  [INFO]
  [INFO] --- exec-maven-plugin:1.2.1:exec (generate-sources) @ cloud-marvin
  ---
  Traceback (most recent call last):
File codegenerator.py, line 412, in module
  cg.generateCodeFromJSON(endpointUrl)
File codegenerator.py, line 366, in generateCodeFromJSON
  apiStream = urllib2.urlopen(endpointUrl)
File /usr/lib64/python2.6/urllib2.py, line 126, in urlopen
  return _opener.open(url, data, timeout)
File /usr/lib64/python2.6/urllib2.py, line 391, in open
  response = self._open(req, data)
File /usr/lib64/python2.6/urllib2.py, line 409, in _open
  '_open', req)
File /usr/lib64/python2.6/urllib2.py, line 369, in _call_chain
  result = func(*args)
File /usr/lib64/python2.6/urllib2.py, line 1190, in http_open
  return self.do_open(httplib.HTTPConnection, req)
File /usr/lib64/python2.6/urllib2.py, line 1165, in do_open
  raise URLError(err)
  urllib2.URLError: urlopen error [Errno 111] Connection refused
  [INFO]
  
  [INFO] BUILD FAILURE
  [INFO]
  
  [INFO] Total time: 3.432s
  [INFO] Finished at: Tue Apr 23 13:34:31 EDT 2013
  [INFO] Final Memory: 13M/32M
  [INFO]
  
  [ERROR] Failed to execute goal
  org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (generate-sources) on
  project cloud-marvin: Command execution failed. Process exited with an
  error: 1 (Exit value: 1) - [Help 1]
  [ERROR]
  [ERROR] To see the full stack trace of the errors, re-run Maven with the
 -e
  switch.
  [ERROR] Re-run Maven using the -X switch to enable full debug logging.
  [ERROR]
  [ERROR] For more information about the errors and possible solutions,
  please read the following articles:
  [ERROR] [Help 1]
  http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
 
 
  On Tue, Apr 23, 2013 at 1:16 PM, Prasanna Santhanam t...@apache.org
 wrote:
 
   On Tue, Apr 23, 2013 at 10:40:58PM +0530, Prasanna Santhanam wrote:
You will need to update marvin since I changed the
cloudstackConnection class last week to get POST requests to work.
   
When you startup the server using jetty:run you can do a marvin.sync
as follows:
   
   
   typo:
   $ sudo mvn -Pdeveloper,marvin.sync -Dendpoint=localhost -pl
 :cloud-marvin
   * marvin.sync
  
   
   Powered by BigRock.com

Re: Error running Ddeploysvr

On Tue, Apr 23, 2013 at 02:05:03PM -0400, Will Stevens wrote:
 I have changed my 'python' reference to point to my 2.7 version (which
 seems to be working).
 
 When I start the server and then run this in another terminal window I get
 this:
 
 [root@cs4-devcloud incubator-cloudstack]# mvn -Pdeveloper,marvin.sync
 -Dendpoint=localhost -pl :cloud-marvin
 ERROR: transport error 202: bind failed: Address already in use
 ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
 JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized
 [../../../src/share/back/debugInit.c:690]
 FATAL ERROR in native method: JDWP No transports initialized,
 jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
 Aborted
 
 I have also tried using the actual IP of my server instead of localhost
 (but it gives the same error).  I will need to figure out what is blocking
 it here.
 
 Thanks again...

You probably have MAVEN_OPTS configured to open a port for debuggers to
attach to.  This is normally not a problem, but it means that two mvn
processes can't open the same port.  Either export a new MAVEN_OPTS just
prior to running the second shell's commands OR disable debugging in
maven completely.

I hit this before as well...

Re: [DISCUSS] ACS Release 4 month v/s 6 month

On Tue, Apr 23, 2013 at 10:55:50AM -0700, Will Chan wrote:
 Again, I am not disputing that more features will make it in given Dave's 
 argument.  In fact, I'm not really that keen on using the fixed cost of 
 release mgmt. for the reason of the move as well.   Heck, I'm not even sure a 
 6 month cycle would fix any of the issues that have already been outlined but 
 it'd be nice to try.  However, I do know a couple of things:
 
 1. We all want CS releases to be of certain quality.  It needs to work and 
 upgrades need to work.

+1 - Absolutely

 2. ACS still relies too heavily on manual testing and most of it 
 unfortunately comes from 1 company.  We cannot be dependent on another 
 company's schedule to ensure ACS has gone through enough proper testing to 
 achieve (1). 

Also agreed, but this only relates to release schedule for regression
and upgrade testing really.  Feature testing is something that should /
can be handled prior to a merge in my mind.

 3. Most importantly, the extra 2 months will give QA more time, give features 
 more time to settle in, and more automated tests to be written for existing 
 features as well.  I agree with Dave that more feature will come in.  So 
 what?  If they are not of good enough quality, we don't release it as part of 
 the ACS release.  However, that extra 2 month will give earlier written 
 features more time to be potentially tested and used by people so that we fix 
 the most egregious bugs before we ship it.  It will also better accommodate 
 people's schedule so they can fix bugs for their features.  
 

How do you see the release schedule laying out with multiple releases
over the course of time?  What overlaps exist?

We *really should not* plan on blocking new features from coming into
master as they are completed.  That's just an inhibitor to progress.
Given that assumption, I fail to see how the we would be doing anything
*but* increasing the overall change size by increasing the time between
feature releases.  That leads to increased cost of release.

 Personally, so far, I feel 4 months seems a bit rushed.
 
 Will

Re: Review Request: Remove 2k limitation for user data on a deployVMCmd issued as an HTTP POST request

Vijay - Min applied the patch in the branch http_post. I made changes
to your test to make it use libraries from marvin appropriately. Don't
hesitate to go change marvin if it makes sense to next time.

What I'm seeing is that in your examples you've attached - you send
all the request for deployVMCmd as POST whereas I imagine the user
would only want to send his userdata as POST and the rest of the
arguments to deployVM as GET. Is this not the case?

I'm doing :
deployVM [ GET(template = builtin, service = Small, zone = myzone) and POST(
userdata = 2ksizeData) ]

while you're doing

deployVM [ POST(template = builtin, service = Small, zone = myzone, userdata =
2kSizeData) ]

It's not clear how this POST data should go from the spec. Can you
please clarify? Is it sensible to make either style work? Do we flout
any RFC?

Thanks,

--
Prasanna.,

On Tue, Apr 23, 2013 at 04:08:14AM -, Prasanna Santhanam wrote:

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

The patch doesn't apply for me:

~/workspace/cloudstack/incubator-cloudstack/patch(branch:master) ?? git am -s
10294.patch

Applying: CLOUDSTACK-1086: DeployVirtualMachine userdata enhancements
error: patch failed:
api/src/org/apache/cloudstack/api/command/user/vm/DeployVMCmd.java:312
error: api/src/org/apache/cloudstack/api/command/user/vm/DeployVMCmd.java:
patch does not apply
error: patch failed: server/test/com/cloud/vm/dao/UserVmDaoImplTest.java:20
error: server/test/com/cloud/vm/dao/UserVmDaoImplTest.java: patch does not
apply
error: patch failed: setup/db/db/schema-410to420.sql:777
error: setup/db/db/schema-410to420.sql: patch does not apply
/Users/tsp/workspace/cloudstack/incubator-cloudstack/.git/rebase-apply/patch:1153:
new blank line at EOF.
+
Patch failed at 0001 CLOUDSTACK-1086: DeployVirtualMachine userdata
enhancements
When you have resolved this problem run git am --resolved.
If you would prefer to skip this patch, instead run git am --skip.
To restore the original branch and stop patching run git am --abort.

I'm trying to run your marvin test and see what the issue is in sending
through post data. All commands now take postdata as a parameter.

- Prasanna Santhanam

On April 23, 2013, 1:57 a.m., Venkata Siva Vijayendra Bhamidipati wrote:

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

(Updated April 23, 2013, 1:57 a.m.)

Review request for cloudstack, Chip Childers, Hugo Trippaers, Kelven Yang,
and Min Chen.

Description
---

Please refer to
https://cwiki.apache.org/confluence/display/CLOUDSTACK/DeployVirtualMachine+userdata+enhancements
for a background on the requirements driving this patch.

This patch hasn't been extensively tested yet, and I will update this
request with more info. I am uploading a first diff for initial
review/comments.

This addresses bug CLOUDSTACK-1086.

Diffs
-

api/src/com/cloud/vm/UserVmService.java aa21136
api/src/org/apache/cloudstack/api/BaseCmd.java 42c0680
api/src/org/apache/cloudstack/api/command/user/vm/DeployVMCmd.java
70c0159
api/src/org/apache/cloudstack/api/command/user/vm/UpdateVMCmd.java
ff8fff1
core/src/com/cloud/vm/UserVmVO.java a16eaf9
server/src/com/cloud/api/ApiDispatcher.java 925d90a
server/src/com/cloud/api/ApiServer.java d842819
server/src/com/cloud/api/ApiServerService.java 12d8b52
server/src/com/cloud/api/ApiServlet.java 03bfb5f
server/src/com/cloud/vm/UserVmManagerImpl.java 1843f60
server/test/com/cloud/vm/MockUserVmManagerImpl.java 0d0a8f4
server/test/com/cloud/vm/dao/UserVmDaoImplTest.java 0936180
server/test/com/cloud/vm/dao/UserVmDaoTestConfiguration.java PRE-CREATION
server/test/resources/UserVMDaoTestContext.xml PRE-CREATION
setup/db/db/schema-410to420.sql 10cdbba
test/integration/component/test_deploy_vm_with_userdata.py PRE-CREATION

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

Testing
---

Manual testing done with scripts generating large/small userdata during
creation of VMs, with both GET and POST requests confirmed to work
correctly, on both integration port and the 8080 port.

Basic Marvin test to create a VM with user data has been written. Since
marvin doesn't yet support POSTable APIs, as soon as that is made available
for create/update VM operations, marvin tests will be written for the same.
Requesting that this be noted as an AI for

Re: [PATCH REQUEST][ACS41] CLOUDSTACK-2154: create account command

On Tue, Apr 23, 2013 at 09:28:22PM +0530, Prasanna Santhanam wrote:
 If there are no objections I'd like to include CLOUDSTACK-2154 into
 the 4.1 release. While createAccount returns the response with all the
 necessary account related information, cloudmonkey, marvin and
 apidocs are told (via annotation) that the createAccount returns a
 user response. More details are in the bug report.
 
 The commit to cherry-pick on master is
 a792d3a3aab6c5e2cec014395b801b0d1e207779
 
 Thanks,
 
 -- 
 Prasanna.,
 
 
 Powered by BigRock.com
 


It was actually 2712ddda26551117fea0149a7a5f7aceeedac3b1 on master, but
I've pulled it into 4.1 now.

Re: [DISCUSS] Making simple installs easier.

2013-04-23 Thread Chiradeep Vittal



On 4/21/13 3:21 PM, David Nalley da...@gnsa.us wrote:

Hi folks.

I've been thinking about our install process lately.

We currently require folks to muck about with firewall settings, NFS
settings, network configuration, etc.
This makes configuration painful, our docs VERY platform specific, and
easily prone to mistakes which result in failure to get things to
work. Even the 'install.sh' from the 3.0.x and earlier days doesn't do
enough. What I want to do is get rid of sections 2-4 of the quick
install guide, and replace it with - 'run this one or two lines worth
of commands' (http://s.apache.org/runbook)

My natural reaction was to reach for puppet - but I am not sure that's
the right answer. To do things right, I'd need several puppet modules
like stdlib, puppetlabs-firewall, etc, which is a fair bit of
overhread - and oh, yeah, need to install the puppet client. I think
Chef is probably in a similar problem space. I don't want to resort to
shell scripts of python - config management tools know the difference
between apt and yum, and can still get a package installed with one
declaration, same thing with firewall rules. Is something like Ansible
or SaltStack a better choice?? I don't see it right now if it is, but
I don't have much experience with either of those two.

The all-in-one installation process I'd like to see:

Install your host OS
Install an meta-RPM/Deb that either (installs everything, or
alternatively configures a repo - or just installs the repo and the
stuff I need to install with)
Run a command that activates one of these config tools - configures
the machine, installs the packages I need, and gets me to the point
where I'm ready to login and go through the beautiful new user gui
setup stuff.

I still want to keep the documentation around, it's invaluable for
experienced users and more complex deployments - but right now it's
far too much overhead (probably an hour or two) to get things
installed and setup to the point where you are ready to run the
'Welcome to CloudStack GUI' if you just want to try CloudStack out.

So why am I writing this email instead of diving in and solving this
problem? Well honestly, I'd like some external opinions. I want to
make sure that I am not seeing a 'nail' simply because I have a hammer
in my hand. How can we most easily do this? So - how do we make the
'brand-new' user experience much better? We develop a platform for
orchestration of complex systems, this should be a solved problem.

--David

+1 for the initiative.
If I look at Apache Hadoop's single node operation documentation[1], it is
considerably simpler.
Apache Tomcat installation is also fairly trivial.

[1] http://hadoop.apache.org/docs/stable/single_node_setup.html

[OFFLINE] Mostly offline tomorrow, April 24

I'll be mostly offline tomorrow, April 24th.

Status from me on 4.1.0:

Second round of voting was cancelled.  I believe I've resolved the DEB
packaging issues, and am in the process of testing.  If testing is
successful, I'll also update the installation docs for the non-oss build
process for DEB packages before cutting another RC to vote on.

Expect that VOTE tonight or tomorrow sometime.

-chip

Re: Error running Ddeploysvr