[GitHub] cloudstack-docs pull request: Added instructions for how to contri...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack-docs/pull/3


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

Re: Review Request 21904: CLOUDSTACK-6726: Fixing BVT test case test_network.py

[Gaurav Aradhye]

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


Santhosh, can you please review this?

- Gaurav Aradhye


On May 26, 2014, 1:16 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21904/
> ---
> 
> (Updated May 26, 2014, 1:16 p.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6726
> https://issues.apache.org/jira/browse/CLOUDSTACK-6726
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The list_nat_rules method called after deleting the NAT rule should be 
> included within "assertRaises". We are looking for exception here.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_network.py f81e95f 
> 
> Diff: https://reviews.apache.org/r/21904/diff/
> 
> 
> Testing
> ---
> 
> Yes. Tested on VMware.
> 
> Log:
> Test for port forwarding on source NAT ... === TestName: 
> test_01_port_fwd_on_src_nat | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 1470.458s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 21904: CLOUDSTACK-6726: Fixing BVT test case test_network.py

[Santhosh Edukulla]

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

Ship it!


Ship It!

- Santhosh Edukulla


On May 26, 2014, 7:46 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21904/
> ---
> 
> (Updated May 26, 2014, 7:46 a.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6726
> https://issues.apache.org/jira/browse/CLOUDSTACK-6726
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The list_nat_rules method called after deleting the NAT rule should be 
> included within "assertRaises". We are looking for exception here.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_network.py f81e95f 
> 
> Diff: https://reviews.apache.org/r/21904/diff/
> 
> 
> Testing
> ---
> 
> Yes. Tested on VMware.
> 
> Log:
> Test for port forwarding on source NAT ... === TestName: 
> test_01_port_fwd_on_src_nat | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 1470.458s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Review Request 21923: CLOUDSTACK-5342: Fix for failure in adding network to VM

[Gaurav Aradhye]

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

Review request for cloudstack and Santhosh Edukulla.


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


Repository: cloudstack-git


Description
---

Few test cases are failing while adding NIC to VM, because if add nic operation 
is done immediately after remove nic operation on the same VM, it fails. This 
is identified as qemu issue. But we can handle it through test case by avoiding 
this by spawning new VM wherever required. Adding delay doesn't help.
Please go through discussion 
(https://issues.apache.org/jira/browse/CLOUDSTACK-5342) for more info.


Diffs
-

  test/integration/component/test_add_remove_network.py c17293d 
  tools/marvin/marvin/lib/base.py c975c37 

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


Testing
---

Yes.

Log:
Add network to running VM ... SKIP: skip
Add network to stopped VM ... === TestName: 
test_02_add_nw_stopped_vm_1_isolated | Status : SUCCESS ===
ok
Add network to stopped VM ... === TestName: test_02_add_nw_stopped_vm_2_shared 
| Status : SUCCESS ===
ok
Add same network multiple times to running VM ... === TestName: 
test_03_add_nw_multiple_times_1_isolated | Status : SUCCESS ===
ok
Add same network multiple times to running VM ... === TestName: 
test_03_add_nw_multiple_times_2_shared | Status : SUCCESS ===
ok
Add VPC network to running VM belonging to isolated network ... === TestName: 
test_04_vpc_nw_running_vm_1_isolated | Status : SUCCESS ===
ok
Add network and ip address to running VM ... === TestName: 
test_06_add_nw_ipaddress_running_vm | Status : SUCCESS ===
ok

--
Ran 7 tests in 902.523s

OK (SKIP=1)


Thanks,

Gaurav Aradhye

Re: [ACS44][PROPOSAL] old blocker bugs

[Daan Hoogland]

Sudha, Animesh,

You talk of process. No process will work unless it is executed on
list. Setting priorities for a release candidate should therefor
happen on list. What I propose is that a reporter always set their
ticket to prio critical and then argues on list that it should be a
blocker. This way people are aware of what blockers there are. As to
your proposals Sudha:

- I don't think SLAs (should) mean anything to an opensource
development community. setting them is a paper or even a digital
tiger. However what you are saying is, if enforced, even more severe
an intervention then my lowering of prios after one week.
- I like your report proposal very much and would be very gratefull if
you where to take this task.
- publishing is already done in jira:
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12323265
We can clean up this dashboard some more but it has been functioning
quite nicely for me.

kind regards,
Daan

On Mon, May 26, 2014 at 8:53 PM, Animesh Chaturvedi
 wrote:
> Daan
>
> I concur with Sudha we should not change the priority of individual defects 
> without technical reasons. The outgoing defect rate is much lower for this 
> time of the release and certainly is a concern as you have raised. We should 
> publish daily list of blockers and ask for status update.
>
> You can also do bulk edit for open tickets and ask for updates, I will also 
> nudge a few folks here.
>
> thanks
> Animesh
>
>> -Original Message-
>> From: Sudha Ponnaganti [mailto:sudha.ponnaga...@citrix.com]
>> Sent: Monday, May 26, 2014 9:21 AM
>> To: dev@cloudstack.apache.org
>> Subject: RE: [ACS44][PROPOSAL] old blocker bugs
>>
>>
>> -1 on the proposal to lower priority of defects based on timeframe. These
>> are blockers for features and some for release as well.  We should not be
>> modifying the priority of defect unless the original reporter or RM agrees to
>> do so for technical reasons but not because these are not touched by
>> anyone. As this is community based development environment, someone
>> need to pick up and get the context and fix it which might be taking time.
>> Understand that community should be aware of these blockers on daily
>> basis and pick those up faster and fix them within reasonable SLAs.
>> Unfortunately we do not have any SLAs. It is dangerous proposal to reduce
>> priority without review of technical impact of the defect.
>>
>> Following process improvement would help to address this issue:
>>
>> - Set  SLAs for a more streamlined approach towards addressing defects
>> within reasonable timeframe.  For  eg blockers should be fixed within 24
>> hours, critical within 72 hours etc.
>> - Send daily reports to ML on the blockers to provide more visibility (I can
>> take up this task).
>> - republish definition of defect priority so community is aware on the proper
>> categorization of defects (I can publish this as well on wiki.
>>
>> Thanks
>> /Sudha
>>
>>
>> -Original Message-
>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> Sent: Monday, May 26, 2014 5:11 AM
>> To: dev
>> Subject: Re: [ACS44][PROPOSAL] old blocker bugs
>>
>> Not well formatted but is this what you want?
>>
>> Key Summary Reporter Assignee Updated
>> CLOUDSTACK-6754
>>
>> SSVM not responding with S3 secondary sotre
>>
>> Pavan Kumar Bandarupally Min Chen 26/May/14 Actions
>> CLOUDSTACK-6755
>>
>> [OVS] Can't create more than 7 GRE tunnel networks in xen cluster
>>
>> Sanjeev N Murali Reddy 23/May/14
>> Actions
>> CLOUDSTACK-6623
>>
>> Register template does not work as expected, when deploying simulator and
>> xen zones simultaneously on a single management server.
>>
>> Bharat Kumar edison su 22/May/14
>> Actions
>> CLOUDSTACK-6603
>>
>> [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3
>> to 4.4
>>
>> manasaveloori Rajesh Battala 22/May/14
>> Actions
>> CLOUDSTACK-6662
>>
>> New XenServer host is not activated due to no agent connection
>>
>> Daan Hoogland Anthony Xu 22/May/14
>> Actions
>> CLOUDSTACK-6730
>>
>> [Automation] test_egress_fw_rules test case failing while applying FW rule
>>
>> Rayees Namathponnan Rayees Namathponnan 22/May/14 Actions
>> CLOUDSTACK-6710
>>
>> [Automation] VM snapshot failing with NPE in vmware
>>
>> Rayees Namathponnan Likitha Shetty 21/May/14 Actions
>> CLOUDSTACK-6602
>>
>> [UI] createNetworkACL API action param value passed incorrectly
>>
>> Jayapal Reddy Jessica Wang 20/May/14
>> Actions
>> CLOUDSTACK-6675
>>
>> NPE while executing updatePortForwardingRule
>>
>> Chandan Purushothama Alena Prokharchyk 20/May/14 Actions
>> CLOUDSTACK-6673
>>
>> cloudstack-setup-management make a chmod 777 on /root
>>
>> Milamber Unassigned 19/May/14
>> Actions
>> CLOUDSTACK-6644
>>
>> Unable to attach Volume to a VM as a System User
>>
>> Chandan Purushothama edison su 19/May/14 Actions
>> CLOUDSTACK-6599
>>
>> Template/Volume URLs expiration functionality not working
>>
>> Nitin Mehta Nitin Mehta 19/May/14
>> Actions
>> CLOUDSTACK-6674
>>

Re: Can we use "In Progress" state when we start working on an issue

[Daan Hoogland]

thanks Animesh,

and I would also like to stress to resolve, reassign or stop progress
if appropriate.

regards,
Daan

On Mon, May 26, 2014 at 10:27 PM, Animesh Chaturvedi
 wrote:
> Folks
>
> One  thing as former RM I have struggled with is visibility of whether an 
> issue is being worked upon rather than being just assigned. JIRA has a simple 
> nice thing called "In Progress" please make use of it. When you start working 
> on an issue I suggest please change the state to "In Progress". It is a big 
> reassurance to RM that the issue is being worked upon and RM can go nudge 
> other open items.
>
> Thanks
> Animesh
>
>



-- 
Daan

Re: Review Request 21853: Fixed CLOUDSTACK-6756: usage id is not being returned for an ip in deleted ip range

[ASF Subversion and Git Services]

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


Commit df42ce903d399cf30055e55bc24b84fbc0b563a9 in cloudstack's branch 
refs/heads/4.4 from Rajani Karuturi
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=df42ce9 ]

Fixed CLOUDSTACK-6756: usage id is not being returned for an ip in deleted ip 
range


- ASF Subversion and Git Services


On May 27, 2014, 4:45 a.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21853/
> ---
> 
> (Updated May 27, 2014, 4:45 a.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-6756
> https://issues.apache.org/jira/browse/CLOUDSTACK-6756
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> added removed columns for user_ip_address and vlan tables to soft delete the 
> entries.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/dc/Vlan.java ac9acda 
>   api/src/com/cloud/network/IpAddress.java f831e27 
>   engine/components-api/src/com/cloud/network/addr/PublicIp.java a20e345 
>   engine/schema/src/com/cloud/dc/VlanVO.java ff103b9 
>   engine/schema/src/com/cloud/network/dao/IPAddressVO.java de2d934 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 14e29cb 
>   setup/db/db/schema-430to440.sql 3b525c4 
> 
> Diff: https://reviews.apache.org/r/21853/diff/
> 
> 
> Testing
> ---
> 
> manually tested it.
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

Re: [ACS4.4] cherry-pick commit 2ab7bcade2f37cb17e071a6154fdae1d80e4ff99

[Daan Hoogland]

On Tue, May 27, 2014 at 7:33 AM, Rajani Karuturi
 wrote:
> 2ab7bcade2f37cb17e071a6154fdae1d80e4ff99


is in

-- 
Daan

Re: [ACS4.4] cherry-pick

[Daan Hoogland]

two pulled,

please note two managerial issues in the one by Saurav:
a trailing space behind the fi in systemvm/scripts/run.sh
a new shell script without license header: systemvm/scripts/utils.sh

regards

On Tue, May 27, 2014 at 7:34 AM, Jayapal Reddy Uradi
 wrote:
> Hi Daan,
>
> Please cherry-pick the following commits to 4.4.
>
> commit 37a3a65c7c7f083a5536c078a1c8436ef9e14597
> Author: Jayapal 
> Date:   Mon May 26 15:10:35 2014 +0530
> CLOUDSTACK-6761: Fixed removing proxy arp rule on deleting static nat or 
> PF rule on ip
>
> commit 587ee544f2d8223599e5ee8c56f926ebf7882b8c
> Author: Saurav Lahiri 
> Date:   Tue Apr 15 12:08:11 2014 +
> CLOUDSTACK-6328: run.sh check if an existing java process is running, 
> before spawining new ones
> Signed-off-by: Jayapal 
>
> Thanks,
> Jayapal



-- 
Daan

Re: Review Request 21429: CLOUDSTACK-6663: Agent fails to start on some setups if last nic on host in nic list doesn't contain unicast address

[ASF Subversion and Git Services]

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


Commit 92bc68d1f14a22f1a5b6bbf87ed349f5b440b149 in cloudstack's branch 
refs/heads/4.4 from Anshul Gangwar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=92bc68d ]

CLOUDSTACK-6663: Fixed Hyper-V agent fails to start on some setups. During 
startup agent tries
to get nic info of 0.0.0.0. To get it, it iterates through all nics and return 
the last NIC in
the list if it doesn't match with any IP address. In case last NIC doesn't have 
unicastAddress,
Hyper-V agent will fail to start. We don't need IP address during 
initialization. It get
initialized with startupcommand later.


- ASF Subversion and Git Services


On May 14, 2014, 8:02 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21429/
> ---
> 
> (Updated May 14, 2014, 8:02 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6663
> https://issues.apache.org/jira/browse/CLOUDSTACK-6663
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Before starting Hyper-V agent we initialize HypervResourceController. We try 
> to initialize it with IP address 0.0.0.0. We try to get nic info of 0.0.0.0. 
> To get nic info we iterate through all nics and return the last NIC in the 
> list if it doesn't match with any IP address. So in case last NIC doesn't 
> have unicastAddress, Hyper-V agent will fail to start.
> 
> We don't need IP address during initialization. It get initialized with 
> startupcommand later
> 
> 
> Diffs
> -
> 
>   plugins/hypervisors/hyperv/DotNet/ServerResource/AgentShell/AgentService.cs 
> 9d66a5c 
> 
> Diff: https://reviews.apache.org/r/21429/diff/
> 
> 
> Testing
> ---
> 
> Hyper-V Agent starts up without any problem.
> Created the basic Hyper-V setup and it works fine
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: [ACS44] Cherry pick for CLOUDSTACK-6663

[Daan Hoogland]

On Tue, May 27, 2014 at 8:40 AM, Anshul Gangwar
 wrote:
> b85f687cd7f12cd14a1feeb80593ba55e05b2fa8


is in

-- 
Daan

Re: Review Request 21923: CLOUDSTACK-5342: Fix for failure in adding network to VM

[Santhosh Edukulla]

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

Ship it!


Ship It!

- Santhosh Edukulla


On May 27, 2014, 8:03 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21923/
> ---
> 
> (Updated May 27, 2014, 8:03 a.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-5342
> https://issues.apache.org/jira/browse/CLOUDSTACK-5342
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Few test cases are failing while adding NIC to VM, because if add nic 
> operation is done immediately after remove nic operation on the same VM, it 
> fails. This is identified as qemu issue. But we can handle it through test 
> case by avoiding this by spawning new VM wherever required. Adding delay 
> doesn't help.
> Please go through discussion 
> (https://issues.apache.org/jira/browse/CLOUDSTACK-5342) for more info.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_add_remove_network.py c17293d 
>   tools/marvin/marvin/lib/base.py c975c37 
> 
> Diff: https://reviews.apache.org/r/21923/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> Log:
> Add network to running VM ... SKIP: skip
> Add network to stopped VM ... === TestName: 
> test_02_add_nw_stopped_vm_1_isolated | Status : SUCCESS ===
> ok
> Add network to stopped VM ... === TestName: 
> test_02_add_nw_stopped_vm_2_shared | Status : SUCCESS ===
> ok
> Add same network multiple times to running VM ... === TestName: 
> test_03_add_nw_multiple_times_1_isolated | Status : SUCCESS ===
> ok
> Add same network multiple times to running VM ... === TestName: 
> test_03_add_nw_multiple_times_2_shared | Status : SUCCESS ===
> ok
> Add VPC network to running VM belonging to isolated network ... === TestName: 
> test_04_vpc_nw_running_vm_1_isolated | Status : SUCCESS ===
> ok
> Add network and ip address to running VM ... === TestName: 
> test_06_add_nw_ipaddress_running_vm | Status : SUCCESS ===
> ok
> 
> --
> Ran 7 tests in 902.523s
> 
> OK (SKIP=1)
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: [ACS4.4] cherry-pick

[Jayapal Reddy Uradi]

Hi Daan,

The two issue fixed in below commit, please cherry-pick it to 4.4
c535b894840e1a625186f7c62796e80950293221

Thanks,
Jayapal

On 27-May-2014, at 2:12 PM, Daan Hoogland 
 wrote:

> two pulled,
> 
> please note two managerial issues in the one by Saurav:
> a trailing space behind the fi in systemvm/scripts/run.sh
> a new shell script without license header: systemvm/scripts/utils.sh
> 
> regards
> 
> On Tue, May 27, 2014 at 7:34 AM, Jayapal Reddy Uradi
>  wrote:
>> Hi Daan,
>> 
>> Please cherry-pick the following commits to 4.4.
>> 
>> commit 37a3a65c7c7f083a5536c078a1c8436ef9e14597
>> Author: Jayapal 
>> Date:   Mon May 26 15:10:35 2014 +0530
>>CLOUDSTACK-6761: Fixed removing proxy arp rule on deleting static nat or 
>> PF rule on ip
>> 
>> commit 587ee544f2d8223599e5ee8c56f926ebf7882b8c
>> Author: Saurav Lahiri 
>> Date:   Tue Apr 15 12:08:11 2014 +
>>CLOUDSTACK-6328: run.sh check if an existing java process is running, 
>> before spawining new ones
>>Signed-off-by: Jayapal 
>> 
>> Thanks,
>> Jayapal
> 
> 
> 
> -- 
> Daan

Re: Review Request 21904: CLOUDSTACK-6726: Fixing BVT test case test_network.py

[ASF Subversion and Git Services]

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


Commit 3e3dc7327179cf8b8a45a66e93c20ddcfa02b603 in cloudstack's branch 
refs/heads/master from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3e3dc73 ]

CLOUDSTACK-6726: Fixing BVT test case test_network.py


- ASF Subversion and Git Services


On May 26, 2014, 7:46 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21904/
> ---
> 
> (Updated May 26, 2014, 7:46 a.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6726
> https://issues.apache.org/jira/browse/CLOUDSTACK-6726
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The list_nat_rules method called after deleting the NAT rule should be 
> included within "assertRaises". We are looking for exception here.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_network.py f81e95f 
> 
> Diff: https://reviews.apache.org/r/21904/diff/
> 
> 
> Testing
> ---
> 
> Yes. Tested on VMware.
> 
> Log:
> Test for port forwarding on source NAT ... === TestName: 
> test_01_port_fwd_on_src_nat | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 1470.458s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 21912: CLOUDSTACK-6764: [Marvin] Accomodating networkid parameter while deploying VM in advanced zone and account contains more than one network

[ASF Subversion and Git Services]

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


Commit fa05cfbc7839077bfae6390125de87602f51bbac in cloudstack's branch 
refs/heads/master from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fa05cfb ]

CLOUDSTACK-6764: Marvin - Accomodating networkid parameter while deploying VM 
in advanced zone and account contains mor than one network


- ASF Subversion and Git Services


On May 26, 2014, 1:55 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21912/
> ---
> 
> (Updated May 26, 2014, 1:55 p.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6764
> https://issues.apache.org/jira/browse/CLOUDSTACK-6764
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> When network id is passed while deploying VM in advanced zone, it is not 
> passed to method "access_ssh_over_nat", hence associating public ip address 
> fails with "more than one network exists in account". Network id must be 
> passed to "PublicIPAddress.create" method in this case.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/lib/base.py c975c37 
> 
> Diff: https://reviews.apache.org/r/21912/diff/
> 
> 
> Testing
> ---
> 
> Yes. Tested both  - test cases which pass network id while deploying VM, and 
> those which do not pass.
> 
> 
> test_add_remove_networks test cases result: (Tests above scenario perfectly)
> Add network to running VM ... SKIP: skip
> Add network to stopped VM ... === TestName: 
> test_02_add_nw_stopped_vm_1_isolated | Status : SUCCESS ===
> ok
> Add network to stopped VM ... === TestName: 
> test_02_add_nw_stopped_vm_2_shared | Status : SUCCESS ===
> ok
> Add same network multiple times to running VM ... === TestName: 
> test_03_add_nw_multiple_times_1_isolated | Status : SUCCESS ===
> ok
> Add same network multiple times to running VM ... === TestName: 
> test_03_add_nw_multiple_times_2_shared | Status : SUCCESS ===
> ok
> Add VPC network to running VM belonging to isolated network ... === TestName: 
> test_04_vpc_nw_running_vm_1_isolated | Status : SUCCESS ===
> ok
> Add network and ip address to running VM ... === TestName: 
> test_06_add_nw_ipaddress_running_vm | Status : SUCCESS ===
> ok
> 
> --
> Ran 7 tests in 902.523s
> 
> OK (SKIP=1)
> 
> 
> BVT test suite - test_vm_life_cycle: (Does not pass network id)
> Test Stop Virtual Machine ... === TestName: test_01_stop_vm | Status : 
> SUCCESS ===
> ok
> Test Start Virtual Machine ... === TestName: test_02_start_vm | Status : 
> SUCCESS ===
> ok
> Test Reboot Virtual Machine ... === TestName: test_03_reboot_vm | Status : 
> SUCCESS ===
> ok
> Test destroy Virtual Machine ... === TestName: test_06_destroy_vm | Status : 
> SUCCESS ===
> ok
> Test recover Virtual Machine ... === TestName: test_07_restore_vm | Status : 
> SUCCESS ===
> ok
> Test migrate VM ... === TestName: test_08_migrate_vm | Status : SUCCESS ===
> ok
> Test destroy(expunge) Virtual Machine ... === TestName: test_09_expunge_vm | 
> Status : SUCCESS ===
> ok
> Test for attach and detach ISO to virtual machine ... === TestName: 
> test_10_attachAndDetach_iso | Status : SUCCESS ===
> ok
> 
> --
> Ran 8 tests in 778.989s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 21923: CLOUDSTACK-5342: Fix for failure in adding network to VM

[ASF Subversion and Git Services]

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


Commit 0cc826aa53286f66232d6287aa05341f0138cdd1 in cloudstack's branch 
refs/heads/master from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0cc826a ]

CLOUDSTACK-5342: Fix for failure in adding network to VM


- ASF Subversion and Git Services


On May 27, 2014, 8:03 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21923/
> ---
> 
> (Updated May 27, 2014, 8:03 a.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-5342
> https://issues.apache.org/jira/browse/CLOUDSTACK-5342
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Few test cases are failing while adding NIC to VM, because if add nic 
> operation is done immediately after remove nic operation on the same VM, it 
> fails. This is identified as qemu issue. But we can handle it through test 
> case by avoiding this by spawning new VM wherever required. Adding delay 
> doesn't help.
> Please go through discussion 
> (https://issues.apache.org/jira/browse/CLOUDSTACK-5342) for more info.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_add_remove_network.py c17293d 
>   tools/marvin/marvin/lib/base.py c975c37 
> 
> Diff: https://reviews.apache.org/r/21923/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> Log:
> Add network to running VM ... SKIP: skip
> Add network to stopped VM ... === TestName: 
> test_02_add_nw_stopped_vm_1_isolated | Status : SUCCESS ===
> ok
> Add network to stopped VM ... === TestName: 
> test_02_add_nw_stopped_vm_2_shared | Status : SUCCESS ===
> ok
> Add same network multiple times to running VM ... === TestName: 
> test_03_add_nw_multiple_times_1_isolated | Status : SUCCESS ===
> ok
> Add same network multiple times to running VM ... === TestName: 
> test_03_add_nw_multiple_times_2_shared | Status : SUCCESS ===
> ok
> Add VPC network to running VM belonging to isolated network ... === TestName: 
> test_04_vpc_nw_running_vm_1_isolated | Status : SUCCESS ===
> ok
> Add network and ip address to running VM ... === TestName: 
> test_06_add_nw_ipaddress_running_vm | Status : SUCCESS ===
> ok
> 
> --
> Ran 7 tests in 902.523s
> 
> OK (SKIP=1)
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 21912: CLOUDSTACK-6764: [Marvin] Accomodating networkid parameter while deploying VM in advanced zone and account contains more than one network

[ASF Subversion and Git Services]

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


Commit 50d4963d5366f1c13c58b58ac3a4bac6f99973e6 in cloudstack's branch 
refs/heads/4.4-forward from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=50d4963 ]

CLOUDSTACK-6764: Marvin - Accomodating networkid parameter while deploying VM 
in advanced zone and account contains mor than one network


- ASF Subversion and Git Services


On May 26, 2014, 1:55 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21912/
> ---
> 
> (Updated May 26, 2014, 1:55 p.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6764
> https://issues.apache.org/jira/browse/CLOUDSTACK-6764
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> When network id is passed while deploying VM in advanced zone, it is not 
> passed to method "access_ssh_over_nat", hence associating public ip address 
> fails with "more than one network exists in account". Network id must be 
> passed to "PublicIPAddress.create" method in this case.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/lib/base.py c975c37 
> 
> Diff: https://reviews.apache.org/r/21912/diff/
> 
> 
> Testing
> ---
> 
> Yes. Tested both  - test cases which pass network id while deploying VM, and 
> those which do not pass.
> 
> 
> test_add_remove_networks test cases result: (Tests above scenario perfectly)
> Add network to running VM ... SKIP: skip
> Add network to stopped VM ... === TestName: 
> test_02_add_nw_stopped_vm_1_isolated | Status : SUCCESS ===
> ok
> Add network to stopped VM ... === TestName: 
> test_02_add_nw_stopped_vm_2_shared | Status : SUCCESS ===
> ok
> Add same network multiple times to running VM ... === TestName: 
> test_03_add_nw_multiple_times_1_isolated | Status : SUCCESS ===
> ok
> Add same network multiple times to running VM ... === TestName: 
> test_03_add_nw_multiple_times_2_shared | Status : SUCCESS ===
> ok
> Add VPC network to running VM belonging to isolated network ... === TestName: 
> test_04_vpc_nw_running_vm_1_isolated | Status : SUCCESS ===
> ok
> Add network and ip address to running VM ... === TestName: 
> test_06_add_nw_ipaddress_running_vm | Status : SUCCESS ===
> ok
> 
> --
> Ran 7 tests in 902.523s
> 
> OK (SKIP=1)
> 
> 
> BVT test suite - test_vm_life_cycle: (Does not pass network id)
> Test Stop Virtual Machine ... === TestName: test_01_stop_vm | Status : 
> SUCCESS ===
> ok
> Test Start Virtual Machine ... === TestName: test_02_start_vm | Status : 
> SUCCESS ===
> ok
> Test Reboot Virtual Machine ... === TestName: test_03_reboot_vm | Status : 
> SUCCESS ===
> ok
> Test destroy Virtual Machine ... === TestName: test_06_destroy_vm | Status : 
> SUCCESS ===
> ok
> Test recover Virtual Machine ... === TestName: test_07_restore_vm | Status : 
> SUCCESS ===
> ok
> Test migrate VM ... === TestName: test_08_migrate_vm | Status : SUCCESS ===
> ok
> Test destroy(expunge) Virtual Machine ... === TestName: test_09_expunge_vm | 
> Status : SUCCESS ===
> ok
> Test for attach and detach ISO to virtual machine ... === TestName: 
> test_10_attachAndDetach_iso | Status : SUCCESS ===
> ok
> 
> --
> Ran 8 tests in 778.989s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 21904: CLOUDSTACK-6726: Fixing BVT test case test_network.py

[ASF Subversion and Git Services]

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


Commit 3125ae5c6a7a286a4891755e0d8d57bfc6e7ce97 in cloudstack's branch 
refs/heads/4.4-forward from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3125ae5 ]

CLOUDSTACK-6726: Fixing BVT test case test_network.py


- ASF Subversion and Git Services


On May 26, 2014, 7:46 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21904/
> ---
> 
> (Updated May 26, 2014, 7:46 a.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6726
> https://issues.apache.org/jira/browse/CLOUDSTACK-6726
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The list_nat_rules method called after deleting the NAT rule should be 
> included within "assertRaises". We are looking for exception here.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_network.py f81e95f 
> 
> Diff: https://reviews.apache.org/r/21904/diff/
> 
> 
> Testing
> ---
> 
> Yes. Tested on VMware.
> 
> Log:
> Test for port forwarding on source NAT ... === TestName: 
> test_01_port_fwd_on_src_nat | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 1470.458s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 21923: CLOUDSTACK-5342: Fix for failure in adding network to VM

[ASF Subversion and Git Services]

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


Commit 24ef79aef82b69015c6e552258c4829d5a15a9d8 in cloudstack's branch 
refs/heads/4.4-forward from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=24ef79a ]

CLOUDSTACK-5342: Fix for failure in adding network to VM


- ASF Subversion and Git Services


On May 27, 2014, 8:03 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21923/
> ---
> 
> (Updated May 27, 2014, 8:03 a.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-5342
> https://issues.apache.org/jira/browse/CLOUDSTACK-5342
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Few test cases are failing while adding NIC to VM, because if add nic 
> operation is done immediately after remove nic operation on the same VM, it 
> fails. This is identified as qemu issue. But we can handle it through test 
> case by avoiding this by spawning new VM wherever required. Adding delay 
> doesn't help.
> Please go through discussion 
> (https://issues.apache.org/jira/browse/CLOUDSTACK-5342) for more info.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_add_remove_network.py c17293d 
>   tools/marvin/marvin/lib/base.py c975c37 
> 
> Diff: https://reviews.apache.org/r/21923/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> Log:
> Add network to running VM ... SKIP: skip
> Add network to stopped VM ... === TestName: 
> test_02_add_nw_stopped_vm_1_isolated | Status : SUCCESS ===
> ok
> Add network to stopped VM ... === TestName: 
> test_02_add_nw_stopped_vm_2_shared | Status : SUCCESS ===
> ok
> Add same network multiple times to running VM ... === TestName: 
> test_03_add_nw_multiple_times_1_isolated | Status : SUCCESS ===
> ok
> Add same network multiple times to running VM ... === TestName: 
> test_03_add_nw_multiple_times_2_shared | Status : SUCCESS ===
> ok
> Add VPC network to running VM belonging to isolated network ... === TestName: 
> test_04_vpc_nw_running_vm_1_isolated | Status : SUCCESS ===
> ok
> Add network and ip address to running VM ... === TestName: 
> test_06_add_nw_ipaddress_running_vm | Status : SUCCESS ===
> ok
> 
> --
> Ran 7 tests in 902.523s
> 
> OK (SKIP=1)
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: [ACS4.4] cherry-pick

[Daan Hoogland]

thank Jayapal, pulled

On Tue, May 27, 2014 at 11:03 AM, Jayapal Reddy Uradi
 wrote:
> Hi Daan,
>
> The two issue fixed in below commit, please cherry-pick it to 4.4
> c535b894840e1a625186f7c62796e80950293221
>
> Thanks,
> Jayapal
>
> On 27-May-2014, at 2:12 PM, Daan Hoogland 
>  wrote:
>
>> two pulled,
>>
>> please note two managerial issues in the one by Saurav:
>> a trailing space behind the fi in systemvm/scripts/run.sh
>> a new shell script without license header: systemvm/scripts/utils.sh
>>
>> regards
>>
>> On Tue, May 27, 2014 at 7:34 AM, Jayapal Reddy Uradi
>>  wrote:
>>> Hi Daan,
>>>
>>> Please cherry-pick the following commits to 4.4.
>>>
>>> commit 37a3a65c7c7f083a5536c078a1c8436ef9e14597
>>> Author: Jayapal 
>>> Date:   Mon May 26 15:10:35 2014 +0530
>>>CLOUDSTACK-6761: Fixed removing proxy arp rule on deleting static nat or 
>>> PF rule on ip
>>>
>>> commit 587ee544f2d8223599e5ee8c56f926ebf7882b8c
>>> Author: Saurav Lahiri 
>>> Date:   Tue Apr 15 12:08:11 2014 +
>>>CLOUDSTACK-6328: run.sh check if an existing java process is running, 
>>> before spawining new ones
>>>Signed-off-by: Jayapal 
>>>
>>> Thanks,
>>> Jayapal
>>
>>
>>
>> --
>> Daan
>



-- 
Daan

Review Request 21924: [Automation]Fixed Regression issues in Xenserver and KVM runs

[Harikrishna Patnala]

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

Review request for cloudstack, Koushik Das and Santhosh Edukulla.


Bugs: CLOUDSTACK-6768, CLOUDSTACK-6769, CLOUDSTACK-6770, CLOUDSTACK-6773, 
CLOUDSTACK-6774, CLOUDSTACK-6776, and CLOUDSTACK-6777
https://issues.apache.org/jira/browse/CLOUDSTACK-6768
https://issues.apache.org/jira/browse/CLOUDSTACK-6769
https://issues.apache.org/jira/browse/CLOUDSTACK-6770
https://issues.apache.org/jira/browse/CLOUDSTACK-6773
https://issues.apache.org/jira/browse/CLOUDSTACK-6774
https://issues.apache.org/jira/browse/CLOUDSTACK-6776
https://issues.apache.org/jira/browse/CLOUDSTACK-6777


Repository: cloudstack-git


Description
---

Fixed Regression issues mentioned in following test failures

[Automation] [Xenserver]
1)  integration.smoke.test_scale_vm - CLOUDSTACK-6768

2)  integration.smoke.test_iso - CLOUDSTACK-6769

3)  integration.smoke.test_primary_storage - CLOUDSTACK-6770

4)  integration.smoke.test_secondary_storage - CLOUDSTACK-6773

[Automation][KVM]
1)  integration.smoke.test_iso - CLOUDSTACK-6774

2)  integration.smoke.test_non_contigiousvlan - CLOUDSTACK-6776

3)  integration.smoke.test_primary_storage - CLOUDSTACK-6770

4)  test_secondary_storage – CLOUDSTACK-6777


Diffs
-

  test/integration/smoke/test_iso.py 5821ec7 
  test/integration/smoke/test_non_contigiousvlan.py a84e62f 
  test/integration/smoke/test_primary_storage.py 3147d86 
  test/integration/smoke/test_scale_vm.py f0ec534 
  test/integration/smoke/test_secondary_storage.py 90304b3 

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


Testing
---


Thanks,

Harikrishna Patnala

cloudmonkey : UnicodeDecodeError

[pradeep s]

Hi,

I am trying to create a zone with unicode chars in its name using
cloudmonkey.

# cloudmonkey create zone dns1= dns2= internaldns1=
name=monkeyÀçîô

Following error is throw:.
Traceback (most recent call last):
  File "/usr/bin/cloudmonkey", line 9, in 
load_entry_point('cloudmonkey==5.1.0', 'console_scripts',
'cloudmonkey')()
  File
"/usr/lib/python2.6/site-packages/cloudmonkey-5.1.0-py2.6.egg/cloudmonkey/cloudmonkey.py",
line 560, in main
shell.onecmd(' '.join(args))
  File "/usr/lib64/python2.6/cmd.py", line 219, in onecmd
return func(arg)
  File
"/usr/lib/python2.6/site-packages/cloudmonkey-5.1.0-py2.6.egg/cloudmonkey/cloudmonkey.py",
line 126, in grammar_closure
if self.pipe_runner("%s %s" % (verb, args)):
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 79:
ordinal not in range(128)

However i can create a zone with unicode chars through UI.
Does cloudmonkey support parameter values with unicode chars??


Regards,
Pradeep

Cherry pick

[Gabor Apati-Nagy]

Hi Daan,

Can you please cherry-pick the following to 4.4 from 4.4-forward?

3f1dc2534fc57376c596e616ca3e8e76754b209d
Thu, 22 May 2014 17:44:45 +0100
CLOUDSTACK-6565: [UI] New Zones tab for Templates and ISOs

Thanks,
Gabor

Re: Review Request 21924: [Automation]Fixed issues in Xenserver and KVM runs

[Harikrishna Patnala]

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

(Updated May 27, 2014, 10:54 a.m.)


Review request for cloudstack, Koushik Das and Santhosh Edukulla.


Summary (updated)
-

[Automation]Fixed issues in Xenserver and KVM runs


Bugs: CLOUDSTACK-6768, CLOUDSTACK-6769, CLOUDSTACK-6770, CLOUDSTACK-6773, 
CLOUDSTACK-6774, CLOUDSTACK-6776, and CLOUDSTACK-6777
https://issues.apache.org/jira/browse/CLOUDSTACK-6768
https://issues.apache.org/jira/browse/CLOUDSTACK-6769
https://issues.apache.org/jira/browse/CLOUDSTACK-6770
https://issues.apache.org/jira/browse/CLOUDSTACK-6773
https://issues.apache.org/jira/browse/CLOUDSTACK-6774
https://issues.apache.org/jira/browse/CLOUDSTACK-6776
https://issues.apache.org/jira/browse/CLOUDSTACK-6777


Repository: cloudstack-git


Description (updated)
---

Fixed issues mentioned in following test failures

[Automation] [Xenserver]
1)  integration.smoke.test_scale_vm - CLOUDSTACK-6768

2)  integration.smoke.test_iso - CLOUDSTACK-6769

3)  integration.smoke.test_primary_storage - CLOUDSTACK-6770

4)  integration.smoke.test_secondary_storage - CLOUDSTACK-6773

[Automation][KVM]
1)  integration.smoke.test_iso - CLOUDSTACK-6774

2)  integration.smoke.test_non_contigiousvlan - CLOUDSTACK-6776

3)  integration.smoke.test_primary_storage - CLOUDSTACK-6770

4)  test_secondary_storage – CLOUDSTACK-6777


Diffs
-

  test/integration/smoke/test_iso.py 5821ec7 
  test/integration/smoke/test_non_contigiousvlan.py a84e62f 
  test/integration/smoke/test_primary_storage.py 3147d86 
  test/integration/smoke/test_scale_vm.py f0ec534 
  test/integration/smoke/test_secondary_storage.py 90304b3 

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


Testing
---


Thanks,

Harikrishna Patnala

Re: Review Request 21901: L10N:001-Fixed the legacy hard-coding issues

[Vetrivel Chinnasamy]

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

(Updated May 27, 2014, 10:58 a.m.)


Review request for cloudstack and Brian Federle.


Changes
---

This patch is created with below 2 commit diffs.

1) commit 0a1b98b1a9f715e91eaa4635c02374434da6d6ac
   Author: vetrivelc 
   Date:   Tue May 27 13:21:04 2014 +0530
   L10N:002-Fixed hardcoding issues
   Signed-off-by: vetrivelc 

2) commit 987bd92922dd8c1e4138e9e31b53ba3dfae81a29
   Author: vetrivelc 
   Date:   Fri May 23 21:48:30 2014 +0530
   Fixed the hardcoding issues
   Signed-off-by: vetrivelc 


Repository: cloudstack-git


Description
---

Externalized the hard coded strings in JavaScript files and added them to 
messages.properties files. Also appended the link dictionary.jsp with the 
externalized strings.


Diffs
-

  client/WEB-INF/classes/resources/messages.properties eff2c3e 
  systemvm/js/cloud.logger.js 751627e 
  ui/dictionary.jsp 9cc030a 
  ui/modules/vnmcAsa1000v/vnmcAsa1000v.js 621c52a 
  ui/scripts/accounts.js a789084 
  ui/scripts/configuration.js 1a88224 
  ui/scripts/events.js 2731cb6 
  ui/scripts/network.js f934f21 
  ui/scripts/sharedFunctions.js 2cfc89f 
  ui/scripts/storage.js 2660aa5 
  ui/scripts/system.js 67e01f1 
  ui/scripts/templates.js 67cc2fb 
  ui/scripts/ui-custom/physicalResources.js 06fcca7 
  ui/scripts/ui-custom/regions.js 986e009 
  ui/scripts/ui/dialog.js 34cec7b 
  ui/scripts/ui/widgets/listView.js be40d33 
  ui/scripts/vpc.js 020b9d7 

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


Testing
---

Tested in local environment by replacing the fixed file.


File Attachments (updated)


Patch - 2 Commits
  
https://reviews.apache.org/media/uploaded/files/2014/05/27/4d2b3c2f-246b-49a6-a528-8c95eecbfba8__001002-L10N-Hardcoding_Fix.patch


Thanks,

Vetrivel Chinnasamy

Re: Review Request 21924: [Automation] Disabling the failed test cases in XenServer and KVM runs

[Harikrishna Patnala]

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

(Updated May 27, 2014, 11:02 a.m.)


Review request for cloudstack, Koushik Das and Santhosh Edukulla.


Summary (updated)
-

[Automation] Disabling the failed test cases in XenServer and KVM runs


Bugs: CLOUDSTACK-6768, CLOUDSTACK-6769, CLOUDSTACK-6770, CLOUDSTACK-6773, 
CLOUDSTACK-6774, CLOUDSTACK-6776, and CLOUDSTACK-6777
https://issues.apache.org/jira/browse/CLOUDSTACK-6768
https://issues.apache.org/jira/browse/CLOUDSTACK-6769
https://issues.apache.org/jira/browse/CLOUDSTACK-6770
https://issues.apache.org/jira/browse/CLOUDSTACK-6773
https://issues.apache.org/jira/browse/CLOUDSTACK-6774
https://issues.apache.org/jira/browse/CLOUDSTACK-6776
https://issues.apache.org/jira/browse/CLOUDSTACK-6777


Repository: cloudstack-git


Description (updated)
---

[Automation] Disabling the failed test cases mentioned in the following tickets

[Automation] [Xenserver]
1)  integration.smoke.test_scale_vm - CLOUDSTACK-6768

2)  integration.smoke.test_iso - CLOUDSTACK-6769

3)  integration.smoke.test_primary_storage - CLOUDSTACK-6770

4)  integration.smoke.test_secondary_storage - CLOUDSTACK-6773

[Automation][KVM]
1)  integration.smoke.test_iso - CLOUDSTACK-6774

2)  integration.smoke.test_non_contigiousvlan - CLOUDSTACK-6776

3)  integration.smoke.test_primary_storage - CLOUDSTACK-6770

4)  test_secondary_storage – CLOUDSTACK-6777


Diffs (updated)
-

  test/integration/smoke/test_iso.py 5821ec7 
  test/integration/smoke/test_non_contigiousvlan.py a84e62f 
  test/integration/smoke/test_primary_storage.py 3147d86 
  test/integration/smoke/test_scale_vm.py f0ec534 
  test/integration/smoke/test_secondary_storage.py 90304b3 

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


Testing
---


Thanks,

Harikrishna Patnala

Re: Review Request 21924: [Automation] Disabling the failed test cases in XenServer and KVM runs

[Abhinandan Prateek]

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

Ship it!


Ship It!

- Abhinandan Prateek


On May 27, 2014, 11:02 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21924/
> ---
> 
> (Updated May 27, 2014, 11:02 a.m.)
> 
> 
> Review request for cloudstack, Koushik Das and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6768, CLOUDSTACK-6769, CLOUDSTACK-6770, CLOUDSTACK-6773, 
> CLOUDSTACK-6774, CLOUDSTACK-6776, and CLOUDSTACK-6777
> https://issues.apache.org/jira/browse/CLOUDSTACK-6768
> https://issues.apache.org/jira/browse/CLOUDSTACK-6769
> https://issues.apache.org/jira/browse/CLOUDSTACK-6770
> https://issues.apache.org/jira/browse/CLOUDSTACK-6773
> https://issues.apache.org/jira/browse/CLOUDSTACK-6774
> https://issues.apache.org/jira/browse/CLOUDSTACK-6776
> https://issues.apache.org/jira/browse/CLOUDSTACK-6777
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> [Automation] Disabling the failed test cases mentioned in the following 
> tickets
> 
> [Automation] [Xenserver]
> 1)integration.smoke.test_scale_vm - CLOUDSTACK-6768
> 
> 2)integration.smoke.test_iso - CLOUDSTACK-6769
> 
> 3)integration.smoke.test_primary_storage - CLOUDSTACK-6770
> 
> 4)integration.smoke.test_secondary_storage - CLOUDSTACK-6773
> 
> [Automation][KVM]
> 1)integration.smoke.test_iso - CLOUDSTACK-6774
> 
> 2)integration.smoke.test_non_contigiousvlan - CLOUDSTACK-6776
> 
> 3)integration.smoke.test_primary_storage - CLOUDSTACK-6770
> 
> 4)test_secondary_storage – CLOUDSTACK-6777
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_iso.py 5821ec7 
>   test/integration/smoke/test_non_contigiousvlan.py a84e62f 
>   test/integration/smoke/test_primary_storage.py 3147d86 
>   test/integration/smoke/test_scale_vm.py f0ec534 
>   test/integration/smoke/test_secondary_storage.py 90304b3 
> 
> Diff: https://reviews.apache.org/r/21924/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Dual CIDR VPN

[Alex Hitchins]

Hello all,

I've been looking at an issue regards to multi CIDR support for VPN
connections. The CloudStack interface suggested this should work (just
separate with a comma) however this would fail validation. I've amended the
isCidrValid method to take comma separated values however wanted to shout
out to see if anyone has a running a dual cidr VPN setup.

If I post this change up on the review board, is it worth Daan cherry
picking? I have altered the unit test to test more combinations.


Alex Hitchins
-- 
E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

[ACS44] Re: Cherry pick

[Daan Hoogland]

Gabor,

this looks like a feature defined at th 2nd of may (after feature
freeze) It is purely javascript and I don't see any tests defined.
Also it contains a lot of trailing spaces and other space showing up
red in my git show display. You'll have to do more to convince me to
cherry-pick it, I'm afraid.

kind regards,
Daan

On Tue, May 27, 2014 at 12:51 PM, Gabor Apati-Nagy
 wrote:
> Hi Daan,
>
> Can you please cherry-pick the following to 4.4 from 4.4-forward?
>
> 3f1dc2534fc57376c596e616ca3e8e76754b209d
> Thu, 22 May 2014 17:44:45 +0100
> CLOUDSTACK-6565: [UI] New Zones tab for Templates and ISOs
>
> Thanks,
> Gabor
>



-- 
Daan

Review Request 21926: CLOUDSTACK-6782: Egress FW rules test cases - Format unicode to string before string matching

[Gaurav Aradhye]

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

Review request for cloudstack and Santhosh Edukulla.


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


Repository: cloudstack-git


Description
---

Test cases are failing because unicode data does not match with string.
E.g. Script result is [u'100'] is not matching with ['100']

Current code converts it to string but when the result is a list, then we have 
to convert each item to string. Formatting list to string does not help.


Diffs
-

  test/integration/component/test_egress_fw_rules.py a42caa9 

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


Testing
---

Yes.

Log:
Test By-default the communication from guest n/w to public n/w is NOT allowed. 
... === TestName: test_01_1_egress_fr1 | Status : SUCCESS ===
ok

--
Ran 1 test in 523.654s

OK


Thanks,

Gaurav Aradhye

Re: Plugin Changes 4.3 to 4.4

[Matt Spurlin]

My api plugin shows up when CloudStack is loading module contexts, but
it does not appear in the API list in the command listApis. I also
have lines in my log that state "getting api commands of service"
followed by the names of my modules.

On Fri, May 23, 2014 at 11:11 PM, Chris Suich  wrote:
> I'm not quite sure I follow. Are you able to access the API directly,
> but it isn't showing up in CloudMonkey? Do your APIs show up if you
> look at the API list at
> "http://:8096/api?command=listApis"?
>
> On Fri, May 23, 2014 at 5:10 PM, Matt Spurlin  
> wrote:
>> I have a plugin that was working previously in 4.3. It uses new plugin
>> discovery system, so as long as it is on the classpath it is loaded.
>> In 4.4 however I am not able to get the APIs to appear in CloudMonkey.
>> It appears to be loading just fine, but my root admin account cannot
>> access the APIs. Does anyone have any suggestions?
>
>
>
> --
> Chris Suich
> 919-334-8193
> csui...@gmail.com

[ACS 4.4] Cherry-pick for CLOUDSTACK-6783

[Wido den Hollander]

Hi Daan,

Could you cherry-pick 7415a27184c84bce23b1739a7c4d609e2c2e37db from 
4.4-forward to the 4.4 branch?


This resolves CLOUDSTACK-6783

Thank you!

Wido

Re: [ACS 4.4] Cherry-pick for CLOUDSTACK-6783

[Daan Hoogland]

On Tue, May 27, 2014 at 4:23 PM, Wido den Hollander  wrote:
> 7415a27184c84bce23b1739a7c4d609e2c2e37db


done

-- 
Daan

Review Request 21927: Fixed integration.smoke.test_portable_publicip.TestPortablePublicIPRange.test_createPortablePublicIPRange

[Rajani Karuturi]

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

Review request for cloudstack, Abhinandan Prateek and Murali Reddy.


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


Repository: cloudstack-git


Description
---

there are multiple @Id columns in the ipaddressvo which was causing a wrong 
remove query and the test case failed.


Diffs
-

  engine/schema/src/com/cloud/network/dao/IPAddressVO.java 816e063 

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


Testing
---

ran the following
$nosetests --with-marvin --marvin-config=setup/dev/advanced.cfg -a 
tags=simulator test/integration/smoke/test_portable_publicip.py

output:
Test to acquire a provisioned public ip range ... === TestName: 
test_createPortablePublicIPAcquire | Status : SUCCESS ===
ok
Test to create a portable public ip range ... === TestName: 
test_createPortablePublicIPRange | Status : SUCCESS ===
ok

--
Ran 2 tests in 49.172s

OK


Thanks,

Rajani Karuturi

Re: [PROPOSAL] Using continuous integration to maintain our code quality...

[Chip Childers]

On Mon, May 26, 2014 at 3:12 PM, Animesh Chaturvedi
 wrote:
>
>>
>> I'll also state for the record, that I will -1 any decision that leads us to
>> depend on a single company's infrastructure as a project level policy. That
>> said, having it available from Citrix for use is a great thing for that 
>> company
>> to donate!  It's going to be difficult to balance our development needs with
>> our need to remain vendor neutral / independent.
>>
>> -chip
> [Animesh] Chip Alex has called this out in Q&A section of [1]
>
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Development+Process
>

Correct, and my statement stands.  I'm -1 on any policy within the
project that enforces the use of a single company's resources if they
are only controlled by that company.  Let's see how we can move this
to the ASF (and tweak / tune based on a better understanding of usage)
before considering it a project "policy".

-chip

RE: [PROPOSAL] Using continuous integration to maintain our code quality...

[Alex Huang]

Sorry for the late replies on this folks.  I've been away for my $dayjob at 
Citrix.  Let me try to see if I can make clear what I see as 
objections/questions/understandings and address them one by one.  If I got them 
wrong, let me know and please clarify what you're asking.

@Sebastien
> Why don't Citrix developers show us how they would do it in the open ? Right 
> now it's all hidden.
I take this to indicate that there's a misunderstanding that this is a Citrix 
policy that the Citrix developers are following currently in secret and we're 
trying to ask the community to follow as well.

The fact is Citrix has no such policy currently and I'm trying to get Citrix 
management to agree to this checkin policy because of how poorly the previous 
releases have been going as well.  I proposed this mainly because I see that 
because the project is so broad in scope that without a CI system to give 
people a fundamental comfort that they didn't break anything, it will be very 
difficult for the project to move forward.  If Citrix developers were doing 
this before, we wouldn't have seen some of the reverts and large number of RCs 
in current and previous releases.

@Chip and @Hugo
 
> Correct, and my statement stands.  I'm -1 on any policy within the project
> that enforces the use of a single company's resources if they are only
> controlled by that company.  Let's see how we can move this to the ASF (and
> tweak / tune based on a better understanding of usage) before considering
> it a project "policy".

I think that's fair.  And if anything in this proposal that I worried about, 
this is it.  The problem for me is we haven't gotten there for ASF infra in two 
years and I'm worried that given the problems we're seeing with 4.4, we will 
lose momentum if we simply wait.  I'm perfectly fine with exploring ways to 
find a middle ground.  For example, if Citrix is to open the infrastructure to 
community (I would need to find some way to convince Citrix), is that 
acceptable?  Opening it to the public would still mean the on-going cost is 
provided by Citrix so it's not truly independent of Citrix.  I'm open to any 
suggestions to move us forward faster here.

@Hugo
> Anyway part of being a committer is the responsibility to make a correct 
> decision when and how to commit to the central code base, this includes 
> deciding when running automation tests is appropriate. You know i’m in favor 
> of quality controls and i am a strong proponent of testing before committing, 
> but each committer has his own responsibility in this and has to show he/she 
> takes this seriously.

While I do trust the committers to be responsible (which is what I gather from 
the above quote), the problem is that the project is too broad and deep.  Just 
being responsible is not enough to ensure that quality is not adversely 
affected.  As a committer, I rather give up a bit of my liberties than to see 
the community produce poor quality releases.  That's why I made this proposal.

BTW, I especially apologize for the late reply on this email.  I think your 
email illustrated Sebastien and Chip's points as well but it came in to my 
inbox really late due to the mailing list problems so it was buried under a 
bunch of other emails.

Let me know what we can do, particularly on the how we can make this an 
independent process quickly.

--Alex

Re: [PROPOSAL] Using continuous integration to maintain our code quality...

[David Nalley]

> @Chip and @Hugo
>
>> Correct, and my statement stands.  I'm -1 on any policy within the project
>> that enforces the use of a single company's resources if they are only
>> controlled by that company.  Let's see how we can move this to the ASF (and
>> tweak / tune based on a better understanding of usage) before considering
>> it a project "policy".
>
> I think that's fair.  And if anything in this proposal that I worried about, 
> this is it.  The problem for me is we haven't gotten there for ASF infra in 
> two years and I'm worried that given the problems we're seeing with 4.4, we 
> will lose momentum if we simply wait.  I'm perfectly fine with exploring ways 
> to find a middle ground.  For example, if Citrix is to open the 
> infrastructure to community (I would need to find some way to convince 
> Citrix), is that acceptable?  Opening it to the public would still mean the 
> on-going cost is provided by Citrix so it's not truly independent of Citrix.  
> I'm open to any suggestions to move us forward faster here.
>

Like Chip, I am very concerned with this being dependent on a single
company, even if its the company that employs me. It isn't
sustainable, it excludes others from contributing, and makes the
project less independent because it depends on a single company's
infrastructure.

I'm also unclear on the answer to the question in the FAQ. The first
time I read it, I got the impression that you were happy to bring it
up on hardware at the ASF if the ASF wanted to own it. The second time
I read it I wondered if you meant that Citrix was going to attempt to
donate hardware.

Finally - what do you think you need from ASF infra to make this happen?

--David

RE: [PROPOSAL] Using continuous integration to maintain our code quality...

[Alex Huang]

> Like Chip, I am very concerned with this being dependent on a single
> company, even if its the company that employs me. It isn't sustainable, it
> excludes others from contributing, and makes the project less independent
> because it depends on a single company's infrastructure.

Agreed there.

> 
> I'm also unclear on the answer to the question in the FAQ. The first time I
> read it, I got the impression that you were happy to bring it up on hardware
> at the ASF if the ASF wanted to own it. The second time I read it I wondered
> if you meant that Citrix was going to attempt to donate hardware.
> 
Sorry if I did not make that clear.  I meant the scripts/code that we wrote are 
checked in publicly and we're willing to help set it up if ASF provided the 
hardware.  I have not approach Citrix on donating the actual hardware.  
Although I can approach them if it speeds up the adoption process.

> Finally - what do you think you need from ASF infra to make this happen?
> 

It's currently about 10 servers with two networks.  One network is static with 
IPMI to PXE boot the machines.  The other network is the actual data network 
that CloudStack uses.  That's actually just enough for XenServer and KVM.  In 
order to accommodate for HyperV, Bare Metal, LXC, (which we do not have any 
test cases in the automation suits currently) we will need even more machines.  
We might be able to use nested virtualization for the hypervisors to maintain 
server count at ten or a little more than ten but we haven't explore that yet.  

The CI process is up and running on those machines but because we didn't have 
CI running on master before, automation tests that were passing for 4.3 are now 
broken again on 4.4. and master.  I think Sudha already reported on the list 
that QA is busy trying to fix all the automation tests to bring CI on 
4.4-forward and master back to 100% pass rate.  Unfortunately, it's been 
delaying our effort to put this out in the public and let the community try 
this themselves.

--Alex

Re: Review Request 21776: AWSAPI: cloudstack api on POST requests (instead GET), ssl enabling fixed

[Chiradeep Vittal]

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


Due to all the whitespace and if-block formatting changes, I couldn't find the 
actually relevant changes.
Can you eliminate whitespace and other reformatting?

- Chiradeep Vittal


On May 26, 2014, 2:32 p.m., Dmitry Batkovich wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21776/
> ---
> 
> (Updated May 26, 2014, 2:32 p.m.)
> 
> 
> Review request for cloudstack, Chiradeep Vittal and daan Hoogland.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> * CloudStackClient.java http request mechanism replaced from GET requests to 
> POST for supporting EC2 requests larger than 2KB
> * SSL enabling fixed in EC2Engine.java
> 
> continuation of https://reviews.apache.org/r/17586/
> 
> 
> Diffs
> -
> 
>   awsapi/conf/ec2-service.properties.in 82f5ad8 
>   awsapi/src/com/cloud/bridge/service/core/ec2/EC2Engine.java cd20214 
>   awsapi/src/com/cloud/bridge/util/JsonAccessor.java 2a94dea 
>   awsapi/src/com/cloud/bridge/util/JsonElementUtil.java PRE-CREATION 
>   awsapi/src/com/cloud/bridge/util/JsonElementUtil.java 2d8afb5 
>   awsapi/src/com/cloud/stack/CloudStackApi.java b7a1210 
>   awsapi/src/com/cloud/stack/CloudStackClient.java 03eba96 
>   awsapi/src/com/cloud/stack/CloudStackClientException.java PRE-CREATION 
>   awsapi/src/com/cloud/stack/CloudStackClientException.java ac1b3ef 
>   awsapi/src/com/cloud/stack/CloudStackCommand.java 8d6aa68 
>   awsapi/src/com/cloud/stack/CloudStackQueryBuilder.java PRE-CREATION 
>   awsapi/test/com/cloud/gate/util/CloudStackClientTestCase.java 826cb3a 
>   awsapi/test/com/cloud/gate/util/JsonAccessorTestCase.java 8603e59 
>   awsapi/test/com/cloud/gate/util/JsonElementUtilTestCase.java PRE-CREATION 
>   awsapi/test/com/cloud/gate/util/JsonElementUtilTestCase.java 8b4f267 
> 
> Diff: https://reviews.apache.org/r/21776/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dmitry Batkovich
> 
>

Re: Review Request 21773: sysctl improvements regarding nf_conntrack_max, panic and nonlocal_bind

[Chiradeep Vittal]

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


I like the idea of taking action on OOM in the VR/systemvm. However there is a 
missing (very important) piece: the VR stays unconfigured. So, it should 
actually stop, not reboot in order for the management server to take notice and 
perform HA.

- Chiradeep Vittal


On May 26, 2014, 2:34 p.m., Joris van Lieshout wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21773/
> ---
> 
> (Updated May 26, 2014, 2:34 p.m.)
> 
> 
> Review request for cloudstack, Chiradeep Vittal, daan Hoogland, edison su, 
> Hugo Trippaers, and Sheng Yang.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> net.ipv4.ip_nonlocal_bind = 1
> For smooth transition on redundant routers in case of a failover
> 
> kernel.panic = 10
> kernel.panic_on_oops = 1
> vm.panic_on_oom = 1
> This way, if the instance oops/ooms, it dies in a way that ACS sees it and 
> can act on it
> 
> net.nf_conntrack_max = 100
> net.netfilter.nf_conntrack_max = 100
> also up the limit of nf_conntrack for more performance
> 
> 
> Diffs
> -
> 
>   systemvm/patches/debian/config/etc/sysctl.conf 586d5bd 
> 
> Diff: https://reviews.apache.org/r/21773/diff/
> 
> 
> Testing
> ---
> 
> we are running these settings in our beta and prod env for months allready, 
> with good results.
> 
> 
> Thanks,
> 
> Joris van Lieshout
> 
>

Re: [DISCUSS] vpc gateway networks are guestnetworks

[Chiradeep Vittal]

Hi Daan,

Sounds interesting! Could I beg you to post some images / figures and more text 
so that I can understand better?

Thanks
—
Chiradeep

From: Daan Hoogland mailto:daan.hoogl...@gmail.com>>
Date: Monday, May 26, 2014 at 3:39 AM
To: Chiradeep Vittal 
mailto:chiradeep.vit...@citrix.com>>
Cc: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>, Sheng Yang 
mailto:sheng.y...@citrix.com>>, Alex Huang 
mailto:alex.hu...@citrix.com>>, 
"dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, Jayapal Reddy 
Uradi mailto:jayapalreddy.ur...@citrix.com>>
Subject: Re: [DISCUSS] vpc gateway networks are guestnetworks

Chiradeep,

I read the vpc-peering option again and it seems not to give us
enough. We want a superset of this feature where more then two vpc can
be connected to the same intervpc network. Use cases are
- have a single monitor and other management devices for several
applications in different vpcs
- have a promotion mechanism across test/acceptance/prod/postprod environments
- (as long as we don't have redundant vpc routers) have a management
environment connected to two vpc's to manage fail-over/dr scenario's

using all peer to peer connections for this can get rather mashy.
What do you think?

Daan


On Fri, May 23, 2014 at 10:56 PM, Daan Hoogland 
mailto:daan.hoogl...@gmail.com>> wrote:
As you can see it isn’t trivial.
I guess you refer to the overlapping cidrs. I am afraid that some
responsibility here will have to lay with the domain admin(s). If we
limit inter vpc networks to one domain we can enforce the ip ranges
not to overlap.

the routing problem is tackled by a next hop field near the cidr.

I am sure I am missing some other non trivial challenges.

On Fri, May 23, 2014 at 7:23 PM, Chiradeep Vittal
mailto:chiradeep.vit...@citrix.com>> wrote:
I guess the ‘proper’ way to have done this would be to have a
‘createPrivateGateway’ API that is independent of the vpc and a
attachPrivateGateway that attaches it to the vpc.

Re: next hop, I’d like to see an FS for this feature. It seems to me that it
is very similar to VPC peering (http://goo.gl/Y7tNkM).
As you can see it isn’t trivial.

From: Daan Hoogland mailto:daan.hoogl...@gmail.com>>
Date: Friday, May 23, 2014 at 2:06 AM
To: Chiradeep Vittal 
mailto:chiradeep.vit...@citrix.com>>, Alena 
Prokharchyk
mailto:alena.prokharc...@citrix.com>>, Sheng Yang 
mailto:sheng.y...@citrix.com>>, Alex
Huang mailto:alex.hu...@citrix.com>>
Cc: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: [DISCUSS] vpc gateway networks are guestnetworks

Hi,

please considder this ugly peace of my work I am now compiling into
cloudstack master VpcManagerImpl.createVpcPrivateGateway(..) that will
fix a bug:

 {   // experimental block, this is a hack
 // set vpc id in network to null
 // might be needed for all types of broadcast domains
 // the ugly hack is that vpc gateway nets are created as
guest network
 // while they are not.
 // A more permanent solution would be to define a type of
'gatewaynetwork'
 // so that handling code is not mixed between the two
 NetworkVO gatewaynet = _ntwkDao.findById(privateNtwk.getId());
 gatewaynet.setVpcId(vpcId);
 _ntwkDao.persist(gatewaynet);
 }

the problem I want to solve is that vpc routers, when restarting
assign the ip of the gateway to their gw-interface [1]. this is a ip
conflict and it has bitten us. My first take was to create the network
without passing the vpc id but that lead to all kinds of errors so I
reverted. It seemed cleaner then this solution I am scheming for now.
If this doesn't lead to obvious errors in my environment I will commit
and be happy to again revert when integration tests fail. It is in any
case not a permanent solution.

Question: should the network for gateways be a special type that is
handled almost the same as guest network (except for in this case) or
is more refactoring needed?
in any case I think this is something that will have to be dealt with soon.

One consideration on the side: I want to add a next-hop field to the
cidrs on the gateway so that it is possible to create a network with
more vpcs that direct traffic to each other. The use case for this is
a vpc for a customers mangement network connected to one for
production and one for acceptance and one 

please flame, criticize or pose your questions

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

--
Daan




--
Daan



--
Daan

RE: How does Jenkins test new plugin for new device support?

[Ritu Sabharwal]

Hello,

Can someone please answer  this question for me?

Thanks & Regards,
Ritu S.

-Original Message-
From: Ritu Sabharwal [mailto:rsabh...@brocade.com] 
Sent: Wednesday, May 21, 2014 2:28 PM
To: dev@cloudstack.apache.org
Subject: How does Jenkins test new plugin for new device support?

Hi,

I am adding a new plugin for supporting new device.
Once the code is reviewed and committed to Git, would Jenkins run the automated 
tests only for the management server and not the plugin code because it would 
not have the new hardware to test it with.

How does that happen ?

Thanks & Regards,
Ritu S.

RE: [DISCUSS] Brocade network plugin to orchestrate Brocade VCS cluster for CloudStack 4.5

[Ritu Sabharwal]

We are targeting this for CloudStack 4.5 release.

Thanks & Regards,
Ritu S.

-Original Message-
From: Ritu Sabharwal [mailto:rsabh...@brocade.com] 
Sent: Friday, May 23, 2014 11:59 AM
To: dev@cloudstack.apache.org
Cc: Prakash Kaligotla
Subject: [DISCUSS] Brocade network plugin to orchestrate Brocade VCS cluster

Hi CS Developers,



I am Ritu Sabharwal from Brocade Communications Systems.



I am leading an effort to implement CloudStack Network Plugin ( named Brocade 
VCS plugin) to orchestrate Brocade VCS cluster. We are using 4.3 as the base 
for development.



Initially, the plugin will focus on L2 services. The plugin would automatically 
orchestrate Brocade's VCS cluster when VMs are created and attached to Network.



The tenant isolation is provided via VLAN. When Isolated networks are created 
from CloudStack and allocated VLAN, the same VLANs need to be propagated to the 
VCS cluster as well, so that when a VLAN-tagged packet arrives on a 
switch-port, the switch know which ports to flood the packet.

The Brocade VCS Plugin will orchestrate VCS directly using NETCONF.



In order to find the switch-ports that are connected to the hypervisor hosts, 
the plugin would implement the Pluggable interface and expose Pluggable service 
API for the admin to provide the traffic-label to switch-port mapping.



We will write a NetworkGuru and override the implement() method to:

1.Configure a VLAN interface on VCS.

2.Configure the interface port on VCS.

3.Configure VLAN membership on the interfaces.



Please provide comments and feedback for this proposal.



Thanks & Regards,

Ritu S.

Re: Review Request 21926: CLOUDSTACK-6782: Egress FW rules test cases - Format unicode to string before string matching

[Santhosh Edukulla]

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

Ship it!


Ship It!

- Santhosh Edukulla


On May 27, 2014, 1:14 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21926/
> ---
> 
> (Updated May 27, 2014, 1:14 p.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6782
> https://issues.apache.org/jira/browse/CLOUDSTACK-6782
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Test cases are failing because unicode data does not match with string.
> E.g. Script result is [u'100'] is not matching with ['100']
> 
> Current code converts it to string but when the result is a list, then we 
> have to convert each item to string. Formatting list to string does not help.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_egress_fw_rules.py a42caa9 
> 
> Diff: https://reviews.apache.org/r/21926/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> Log:
> Test By-default the communication from guest n/w to public n/w is NOT 
> allowed. ... === TestName: test_01_1_egress_fr1 | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 523.654s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

CloudStack DC and NoVA User Group Meetup - June 2nd, 2014

[Karen Vuong]

Hi all,



The CloudStack DC and NoVA User Group will be holding a CloudStack meetup
on Monday, June 2nd in Washington D.C. If you’re in the area, check out a
session on OpenContrail + CloudStack  by Bruno Rijsman.



Details:



Date: Monday, June 2nd, 2014

Time: 6:00pm – 8:30pm



Address:

Financial Industry Regulatory Authority (FINRA)

1735 K. St. NW.

Washington, D.C., US



To sign up and for more information, visit:
http://www.meetup.com/CloudStack-DC-and-NoVA-User-Group/events/182674672/



If you have any questions, please feel free to ask me!



Thanks,

Karen

Re: Review Request 21776: AWSAPI: cloudstack api on POST requests (instead GET), ssl enabling fixed

[Dmitry Batkovich]

> On May 27, 2014, 4:58 p.m., Chiradeep Vittal wrote:
> > Due to all the whitespace and if-block formatting changes, I couldn't find 
> > the actually relevant changes.
> > Can you eliminate whitespace and other reformatting?

OK, I have created new review and attach you as reviewer


- Dmitry


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


On May 26, 2014, 2:32 p.m., Dmitry Batkovich wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21776/
> ---
> 
> (Updated May 26, 2014, 2:32 p.m.)
> 
> 
> Review request for cloudstack, Chiradeep Vittal and daan Hoogland.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> * CloudStackClient.java http request mechanism replaced from GET requests to 
> POST for supporting EC2 requests larger than 2KB
> * SSL enabling fixed in EC2Engine.java
> 
> continuation of https://reviews.apache.org/r/17586/
> 
> 
> Diffs
> -
> 
>   awsapi/conf/ec2-service.properties.in 82f5ad8 
>   awsapi/src/com/cloud/bridge/service/core/ec2/EC2Engine.java cd20214 
>   awsapi/src/com/cloud/bridge/util/JsonAccessor.java 2a94dea 
>   awsapi/src/com/cloud/bridge/util/JsonElementUtil.java PRE-CREATION 
>   awsapi/src/com/cloud/bridge/util/JsonElementUtil.java 2d8afb5 
>   awsapi/src/com/cloud/stack/CloudStackApi.java b7a1210 
>   awsapi/src/com/cloud/stack/CloudStackClient.java 03eba96 
>   awsapi/src/com/cloud/stack/CloudStackClientException.java PRE-CREATION 
>   awsapi/src/com/cloud/stack/CloudStackClientException.java ac1b3ef 
>   awsapi/src/com/cloud/stack/CloudStackCommand.java 8d6aa68 
>   awsapi/src/com/cloud/stack/CloudStackQueryBuilder.java PRE-CREATION 
>   awsapi/test/com/cloud/gate/util/CloudStackClientTestCase.java 826cb3a 
>   awsapi/test/com/cloud/gate/util/JsonAccessorTestCase.java 8603e59 
>   awsapi/test/com/cloud/gate/util/JsonElementUtilTestCase.java PRE-CREATION 
>   awsapi/test/com/cloud/gate/util/JsonElementUtilTestCase.java 8b4f267 
> 
> Diff: https://reviews.apache.org/r/21776/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dmitry Batkovich
> 
>

Re: Review Request 21776: AWSAPI: cloudstack api on POST requests (instead GET), ssl enabling fixed

[Chiradeep Vittal]

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


In EC2engine.java, I still see code blocks such as if (foo) \n blargh() 
reformatted to if (foo) blargh

Please add prachidamle as a reviewer

- Chiradeep Vittal


On May 26, 2014, 2:32 p.m., Dmitry Batkovich wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21776/
> ---
> 
> (Updated May 26, 2014, 2:32 p.m.)
> 
> 
> Review request for cloudstack, Chiradeep Vittal and daan Hoogland.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> * CloudStackClient.java http request mechanism replaced from GET requests to 
> POST for supporting EC2 requests larger than 2KB
> * SSL enabling fixed in EC2Engine.java
> 
> continuation of https://reviews.apache.org/r/17586/
> 
> 
> Diffs
> -
> 
>   awsapi/conf/ec2-service.properties.in 82f5ad8 
>   awsapi/src/com/cloud/bridge/service/core/ec2/EC2Engine.java cd20214 
>   awsapi/src/com/cloud/bridge/util/JsonAccessor.java 2a94dea 
>   awsapi/src/com/cloud/bridge/util/JsonElementUtil.java PRE-CREATION 
>   awsapi/src/com/cloud/bridge/util/JsonElementUtil.java 2d8afb5 
>   awsapi/src/com/cloud/stack/CloudStackApi.java b7a1210 
>   awsapi/src/com/cloud/stack/CloudStackClient.java 03eba96 
>   awsapi/src/com/cloud/stack/CloudStackClientException.java PRE-CREATION 
>   awsapi/src/com/cloud/stack/CloudStackClientException.java ac1b3ef 
>   awsapi/src/com/cloud/stack/CloudStackCommand.java 8d6aa68 
>   awsapi/src/com/cloud/stack/CloudStackQueryBuilder.java PRE-CREATION 
>   awsapi/test/com/cloud/gate/util/CloudStackClientTestCase.java 826cb3a 
>   awsapi/test/com/cloud/gate/util/JsonAccessorTestCase.java 8603e59 
>   awsapi/test/com/cloud/gate/util/JsonElementUtilTestCase.java PRE-CREATION 
>   awsapi/test/com/cloud/gate/util/JsonElementUtilTestCase.java 8b4f267 
> 
> Diff: https://reviews.apache.org/r/21776/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dmitry Batkovich
> 
>

Re: devcloud script deployDataCentre.py not working

[sebgoa]

I tried devcloud2 on a fresh 4.4.

the deploy scripts fails with:

$ python ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
Traceback (most recent call last):
  File "../marvin/marvin/deployDataCenter.py", line 579, in 
deploy.deploy()
  File "../marvin/marvin/deployDataCenter.py", line 563, in deploy
self.createZones(self.config.zones)
  File "../marvin/marvin/deployDataCenter.py", line 425, in createZones
self.createPods(zone.pods, zoneId, networkid)
  File "../marvin/marvin/deployDataCenter.py", line 142, in createPods
vmwareDc=pod.vmwaredc)
  File "../marvin/marvin/deployDataCenter.py", line 87, in createClusters
cluster.hypervisor)
  File "../marvin/marvin/deployDataCenter.py", line 53, in addHosts
self.apiClient.addHost(hostcmd)
  File 
"/Users/sebgoa/Documents/gitforks/cloudstack-asf/cloudstack/tools/marvin/marvin/cloudstackAPI/cloudstackAPIClient.py",
 line 1492, in addHost
response = self.connection.marvinRequest(command, response_type=response, 
method=method)
  File 
"/Users/sebgoa/Documents/gitforks/cloudstack-asf/cloudstack/tools/marvin/marvin/cloudstackConnection.py",
 line 272, in marvinRequest
response = jsonHelper.getResultObj(response.json(), response_type)
  File 
"/Users/sebgoa/Documents/gitforks/cloudstack-asf/cloudstack/tools/marvin/marvin/jsonHelper.py",
 line 148, in getResultObj
raise cloudstackException.cloudstackAPIException(respname, errMsg)
cloudstackException.cloudstackAPIException: Execute cmd: addhost failed, due 
to: errorCode: 530, errorText:Cannot transit agent status with event 
AgentDisconnected for host 1, mangement server id is 1,Unable to transition to 
a new state from Creating via AgentDisconnected


and the mgt server logs are:

WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-05a16b6a) Unable to 
setup
com.cloud.utils.exception.CloudRuntimeException: Cannot create directory 
/opt/cloud/bin on XenServer hosts
at 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.setupServer(CitrixResourceBase.java:4850)
at 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4678)
at 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:494)
at 
com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOssResource.java:182)
at 
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
WARN  [c.c.h.x.d.XcpServerDiscoverer] (48940041@qtp-1783796402-5:ctx-3d757b56 
ctx-9031fd34 ctx-e9224a2c) Unable to setup agent 1 due to Cannot create 
directory /opt/cloud/bin on XenServer hosts
INFO  [c.c.u.e.CSExceptionErrorCode] (48940041@qtp-1783796402-5:ctx-3d757b56 
ctx-9031fd34 ctx-e9224a2c) Could not find exception: 
com.cloud.exception.ConnectionException in error code list for exceptions
WARN  [c.c.a.m.AgentManagerImpl] (48940041@qtp-1783796402-5:ctx-3d757b56 
ctx-9031fd34 ctx-e9224a2c) Monitor XcpServerDiscoverer says there is an error 
in the connect process for 1 due to Reinitialize agent after setup.
INFO  [c.c.a.m.AgentManagerImpl] (48940041@qtp-1783796402-5:ctx-3d757b56 
ctx-9031fd34 ctx-e9224a2c) Host 1 is disconnecting with event AgentDisconnected
WARN  [c.c.r.ResourceManagerImpl] (48940041@qtp-1783796402-5:ctx-3d757b56 
ctx-9031fd34 ctx-e9224a2c) Unable to connect due to 
com.cloud.exception.ConnectionException: Reinitialize agent after setup.
at 
com.cloud.hypervisor.xen.discoverer.XcpServerDiscoverer.processConnect(XcpServerDiscoverer.java:656)
at 
com.cloud.agent.manager.AgentManagerImpl.notifyMonitorsOfConnection(AgentManagerImpl.java:514)
at 
com.cloud.agent.manager.AgentManager

marvin master changes in 4.4-forward

[Marcus]

I was troubleshooting some marvin issues today, and noticed that
deployDataCenter.py is completely rewritten in master. That's fine, but
then I went to make a 4.4-specific patch for an issue, and found that the
rewrite is in 4.4-forward, so I can't really create a commit anywhere to be
cherrypicked into 4.4.

I wondered why this commit was put into 4.4-forward when it seems like a
refactor (should be bugfixes only, right?), but the commit doesn't say much:

commit 404ac549bfd84e97c756009f214e74cdb73548de
Author: SrikanteswaraRao Talluri 
Date:   Mon Apr 28 14:55:11 2014 +0530

Marvin + test changes from master Signed-off-by: SrikanteswaraRao
Talluri 

Signed-off-by: SrikanteswaraRao Talluri 

Re: Review Request 21776: AWSAPI: cloudstack api on POST requests (instead GET), ssl enabling fixed

[Dmitry Batkovich]

> On May 27, 2014, 6:55 p.m., Chiradeep Vittal wrote:
> > In EC2engine.java, I still see code blocks such as if (foo) \n blargh() 
> > reformatted to if (foo) blargh
> > 
> > Please add prachidamle as a reviewer

In new review? https://reviews.apache.org/r/21936/


- Dmitry


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


On May 26, 2014, 2:32 p.m., Dmitry Batkovich wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21776/
> ---
> 
> (Updated May 26, 2014, 2:32 p.m.)
> 
> 
> Review request for cloudstack, Chiradeep Vittal and daan Hoogland.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> * CloudStackClient.java http request mechanism replaced from GET requests to 
> POST for supporting EC2 requests larger than 2KB
> * SSL enabling fixed in EC2Engine.java
> 
> continuation of https://reviews.apache.org/r/17586/
> 
> 
> Diffs
> -
> 
>   awsapi/conf/ec2-service.properties.in 82f5ad8 
>   awsapi/src/com/cloud/bridge/service/core/ec2/EC2Engine.java cd20214 
>   awsapi/src/com/cloud/bridge/util/JsonAccessor.java 2a94dea 
>   awsapi/src/com/cloud/bridge/util/JsonElementUtil.java PRE-CREATION 
>   awsapi/src/com/cloud/bridge/util/JsonElementUtil.java 2d8afb5 
>   awsapi/src/com/cloud/stack/CloudStackApi.java b7a1210 
>   awsapi/src/com/cloud/stack/CloudStackClient.java 03eba96 
>   awsapi/src/com/cloud/stack/CloudStackClientException.java PRE-CREATION 
>   awsapi/src/com/cloud/stack/CloudStackClientException.java ac1b3ef 
>   awsapi/src/com/cloud/stack/CloudStackCommand.java 8d6aa68 
>   awsapi/src/com/cloud/stack/CloudStackQueryBuilder.java PRE-CREATION 
>   awsapi/test/com/cloud/gate/util/CloudStackClientTestCase.java 826cb3a 
>   awsapi/test/com/cloud/gate/util/JsonAccessorTestCase.java 8603e59 
>   awsapi/test/com/cloud/gate/util/JsonElementUtilTestCase.java PRE-CREATION 
>   awsapi/test/com/cloud/gate/util/JsonElementUtilTestCase.java 8b4f267 
> 
> Diff: https://reviews.apache.org/r/21776/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dmitry Batkovich
> 
>

[ACS4.3] Cherry pick commit 008b029a29460d883ac7d645877e6f4f2945b1e1 - CLOUDSTACK-5891

[ilya musayev]

Not certain who RM is for minor 4.3.0.x release, please cherry pick this 
commit from 4.4 branch.


If no-one responds, and i hear no objections, i will do this later tonight.

Summary:
CloudStack 4.3.0 does not honor cpu.corespersocket=x template setting 
for vmware
CLOUDSTACK-5891.[VMware] If a template has been registered and 
"cpu.corespersocket...


Commit:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=008b029a29460d883ac7d645877e6f4f2945b1e1



The commit is a bug fix with 3 lines of code:

+ // Check for multi-cores per socket settings
+String coresPerSocket = 
vmSpec.getDetails().get("cpu.corespersocket");

+if (coresPerSocket != null) {
+ vmConfigSpec.setNumCoresPerSocket(NumbersUtil.parseInt(coresPerSocket, 
1));

+}
+

Re: [ACS4.3] Cherry pick commit 008b029a29460d883ac7d645877e6f4f2945b1e1 - CLOUDSTACK-5891

[sebgoa]

On May 27, 2014, at 9:46 PM, ilya musayev  wrote:

> Not certain who RM is for minor 4.3.0.x release, please cherry pick this 
> commit from 4.4 branch.

go ahead there is no assign RM for 4.3 minor
> 
> If no-one responds, and i hear no objections, i will do this later tonight.
> 
> Summary:
> CloudStack 4.3.0 does not honor cpu.corespersocket=x template setting for 
> vmware
> CLOUDSTACK-5891.[VMware] If a template has been registered and 
> "cpu.corespersocket...
> 
> Commit:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=008b029a29460d883ac7d645877e6f4f2945b1e1
> 
> 
> 
> The commit is a bug fix with 3 lines of code:
> 
> + // Check for multi-cores per socket settings
> +String coresPerSocket = 
> vmSpec.getDetails().get("cpu.corespersocket");
> +if (coresPerSocket != null) {
> + vmConfigSpec.setNumCoresPerSocket(NumbersUtil.parseInt(coresPerSocket, 1));
> +}
> +

Re: Review Request 21776: AWSAPI: cloudstack api on POST requests (instead GET), ssl enabling fixed

[Chiradeep Vittal]

> On May 27, 2014, 6:55 p.m., Chiradeep Vittal wrote:
> > In EC2engine.java, I still see code blocks such as if (foo) \n blargh() 
> > reformatted to if (foo) blargh
> > 
> > Please add prachidamle as a reviewer
> 
> Dmitry Batkovich wrote:
> In new review? https://reviews.apache.org/r/21936/

Ah, ok. RB lets you update the old review. It said "updated 4 minutes ago", so 
I assumed it was an update to the original review request


- Chiradeep


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


On May 26, 2014, 2:32 p.m., Dmitry Batkovich wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21776/
> ---
> 
> (Updated May 26, 2014, 2:32 p.m.)
> 
> 
> Review request for cloudstack, Chiradeep Vittal and daan Hoogland.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> * CloudStackClient.java http request mechanism replaced from GET requests to 
> POST for supporting EC2 requests larger than 2KB
> * SSL enabling fixed in EC2Engine.java
> 
> continuation of https://reviews.apache.org/r/17586/
> 
> 
> Diffs
> -
> 
>   awsapi/conf/ec2-service.properties.in 82f5ad8 
>   awsapi/src/com/cloud/bridge/service/core/ec2/EC2Engine.java cd20214 
>   awsapi/src/com/cloud/bridge/util/JsonAccessor.java 2a94dea 
>   awsapi/src/com/cloud/bridge/util/JsonElementUtil.java PRE-CREATION 
>   awsapi/src/com/cloud/bridge/util/JsonElementUtil.java 2d8afb5 
>   awsapi/src/com/cloud/stack/CloudStackApi.java b7a1210 
>   awsapi/src/com/cloud/stack/CloudStackClient.java 03eba96 
>   awsapi/src/com/cloud/stack/CloudStackClientException.java PRE-CREATION 
>   awsapi/src/com/cloud/stack/CloudStackClientException.java ac1b3ef 
>   awsapi/src/com/cloud/stack/CloudStackCommand.java 8d6aa68 
>   awsapi/src/com/cloud/stack/CloudStackQueryBuilder.java PRE-CREATION 
>   awsapi/test/com/cloud/gate/util/CloudStackClientTestCase.java 826cb3a 
>   awsapi/test/com/cloud/gate/util/JsonAccessorTestCase.java 8603e59 
>   awsapi/test/com/cloud/gate/util/JsonElementUtilTestCase.java PRE-CREATION 
>   awsapi/test/com/cloud/gate/util/JsonElementUtilTestCase.java 8b4f267 
> 
> Diff: https://reviews.apache.org/r/21776/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dmitry Batkovich
> 
>

Re: Review Request 21776: AWSAPI: cloudstack api on POST requests (instead GET), ssl enabling fixed

[Dmitry Batkovich]

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

(Updated May 27, 2014, 8:03 p.m.)


Review request for cloudstack, Chiradeep Vittal and daan Hoogland.


Repository: cloudstack-git


Description
---

* CloudStackClient.java http request mechanism replaced from GET requests to 
POST for supporting EC2 requests larger than 2KB
* SSL enabling fixed in EC2Engine.java

continuation of https://reviews.apache.org/r/17586/


Diffs (updated)
-

  awsapi/conf/ec2-service.properties.in 82f5ad8 
  awsapi/src/com/cloud/bridge/service/core/ec2/EC2Engine.java cd20214 
  awsapi/src/com/cloud/bridge/util/JsonAccessor.java 2a94dea 
  awsapi/src/com/cloud/bridge/util/JsonElementUtil.java PRE-CREATION 
  awsapi/src/com/cloud/stack/CloudStackApi.java b7a1210 
  awsapi/src/com/cloud/stack/CloudStackClient.java 03eba96 
  awsapi/src/com/cloud/stack/CloudStackClientException.java PRE-CREATION 
  awsapi/src/com/cloud/stack/CloudStackCommand.java 8d6aa68 
  awsapi/src/com/cloud/stack/CloudStackQueryBuilder.java PRE-CREATION 
  awsapi/test/com/cloud/gate/util/CloudStackClientTestCase.java 826cb3a 
  awsapi/test/com/cloud/gate/util/JsonAccessorTestCase.java 8603e59 
  awsapi/test/com/cloud/gate/util/JsonElementUtilTestCase.java PRE-CREATION 

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


Testing
---


Thanks,

Dmitry Batkovich

Re: Review Request 21776: AWSAPI: cloudstack api on POST requests (instead GET), ssl enabling fixed

[Dmitry Batkovich]

> On May 27, 2014, 6:55 p.m., Chiradeep Vittal wrote:
> > In EC2engine.java, I still see code blocks such as if (foo) \n blargh() 
> > reformatted to if (foo) blargh
> > 
> > Please add prachidamle as a reviewer
> 
> Dmitry Batkovich wrote:
> In new review? https://reviews.apache.org/r/21936/
> 
> Chiradeep Vittal wrote:
> Ah, ok. RB lets you update the old review. It said "updated 4 minutes 
> ago", so I assumed it was an update to the original review request
>

ok, I updated this old review and add reviewer


- Dmitry


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


On May 27, 2014, 8:04 p.m., Dmitry Batkovich wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21776/
> ---
> 
> (Updated May 27, 2014, 8:04 p.m.)
> 
> 
> Review request for cloudstack, Chiradeep Vittal, daan Hoogland, and Prachi 
> Damle.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> * CloudStackClient.java http request mechanism replaced from GET requests to 
> POST for supporting EC2 requests larger than 2KB
> * SSL enabling fixed in EC2Engine.java
> 
> continuation of https://reviews.apache.org/r/17586/
> 
> 
> Diffs
> -
> 
>   awsapi/conf/ec2-service.properties.in 82f5ad8 
>   awsapi/src/com/cloud/bridge/service/core/ec2/EC2Engine.java cd20214 
>   awsapi/src/com/cloud/bridge/util/JsonAccessor.java 2a94dea 
>   awsapi/src/com/cloud/bridge/util/JsonElementUtil.java PRE-CREATION 
>   awsapi/src/com/cloud/stack/CloudStackApi.java b7a1210 
>   awsapi/src/com/cloud/stack/CloudStackClient.java 03eba96 
>   awsapi/src/com/cloud/stack/CloudStackClientException.java PRE-CREATION 
>   awsapi/src/com/cloud/stack/CloudStackCommand.java 8d6aa68 
>   awsapi/src/com/cloud/stack/CloudStackQueryBuilder.java PRE-CREATION 
>   awsapi/test/com/cloud/gate/util/CloudStackClientTestCase.java 826cb3a 
>   awsapi/test/com/cloud/gate/util/JsonAccessorTestCase.java 8603e59 
>   awsapi/test/com/cloud/gate/util/JsonElementUtilTestCase.java PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/21776/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dmitry Batkovich
> 
>

Re: Review Request 21776: AWSAPI: cloudstack api on POST requests (instead GET), ssl enabling fixed

[Dmitry Batkovich]

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

(Updated May 27, 2014, 8:04 p.m.)


Review request for cloudstack, Chiradeep Vittal, daan Hoogland, and Prachi 
Damle.


Repository: cloudstack-git


Description
---

* CloudStackClient.java http request mechanism replaced from GET requests to 
POST for supporting EC2 requests larger than 2KB
* SSL enabling fixed in EC2Engine.java

continuation of https://reviews.apache.org/r/17586/


Diffs
-

  awsapi/conf/ec2-service.properties.in 82f5ad8 
  awsapi/src/com/cloud/bridge/service/core/ec2/EC2Engine.java cd20214 
  awsapi/src/com/cloud/bridge/util/JsonAccessor.java 2a94dea 
  awsapi/src/com/cloud/bridge/util/JsonElementUtil.java PRE-CREATION 
  awsapi/src/com/cloud/stack/CloudStackApi.java b7a1210 
  awsapi/src/com/cloud/stack/CloudStackClient.java 03eba96 
  awsapi/src/com/cloud/stack/CloudStackClientException.java PRE-CREATION 
  awsapi/src/com/cloud/stack/CloudStackCommand.java 8d6aa68 
  awsapi/src/com/cloud/stack/CloudStackQueryBuilder.java PRE-CREATION 
  awsapi/test/com/cloud/gate/util/CloudStackClientTestCase.java 826cb3a 
  awsapi/test/com/cloud/gate/util/JsonAccessorTestCase.java 8603e59 
  awsapi/test/com/cloud/gate/util/JsonElementUtilTestCase.java PRE-CREATION 

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


Testing
---


Thanks,

Dmitry Batkovich

Re: Review Request 21429: CLOUDSTACK-6663: Agent fails to start on some setups if last nic on host in nic list doesn't contain unicast address

[Ishfaq Malik]

Hi there

I shouldn't be in this mailing list. I have no interaction with cloudstack.
Could someone please remove me as I can't see how to.

Regards

Ish




On 27 May 2014 09:44, ASF Subversion and Git Services <
asf...@urd.zones.apache.org> wrote:

>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21429/#review43957
> ---
>
>
> Commit 92bc68d1f14a22f1a5b6bbf87ed349f5b440b149 in cloudstack's branch
> refs/heads/4.4 from Anshul Gangwar
> [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=92bc68d ]
>
> CLOUDSTACK-6663: Fixed Hyper-V agent fails to start on some setups. During
> startup agent tries
> to get nic info of 0.0.0.0. To get it, it iterates through all nics and
> return the last NIC in
> the list if it doesn't match with any IP address. In case last NIC doesn't
> have unicastAddress,
> Hyper-V agent will fail to start. We don't need IP address during
> initialization. It get
> initialized with startupcommand later.
>
>
> - ASF Subversion and Git Services
>
>
> On May 14, 2014, 8:02 a.m., Anshul Gangwar wrote:
> >
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/21429/
> > ---
> >
> > (Updated May 14, 2014, 8:02 a.m.)
> >
> >
> > Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> >
> >
> > Bugs: CLOUDSTACK-6663
> > https://issues.apache.org/jira/browse/CLOUDSTACK-6663
> >
> >
> > Repository: cloudstack-git
> >
> >
> > Description
> > ---
> >
> > Before starting Hyper-V agent we initialize HypervResourceController. We
> try to initialize it with IP address 0.0.0.0. We try to get nic info of
> 0.0.0.0. To get nic info we iterate through all nics and return the last
> NIC in the list if it doesn't match with any IP address. So in case last
> NIC doesn't have unicastAddress, Hyper-V agent will fail to start.
> >
> > We don't need IP address during initialization. It get initialized with
> startupcommand later
> >
> >
> > Diffs
> > -
> >
> >
> plugins/hypervisors/hyperv/DotNet/ServerResource/AgentShell/AgentService.cs
> 9d66a5c
> >
> > Diff: https://reviews.apache.org/r/21429/diff/
> >
> >
> > Testing
> > ---
> >
> > Hyper-V Agent starts up without any problem.
> > Created the basic Hyper-V setup and it works fine
> >
> >
> > Thanks,
> >
> > Anshul Gangwar
> >
> >
>
>


-- 

Ishfaq Malik
Department: VOIP Support
Company: Packnet Limited
t: +44 (0)845 004 4994
f: +44 (0)161 660 9825
e: i...@pack-net.co.uk
w: http://www.pack-net.co.uk

Registered Address: PACKNET LIMITED, Duplex 2, Ducie House
37 Ducie Street
Manchester, M1 2JW
COMPANY REG NO. 04920552

Re: [DISCUSS] vpc gateway networks are guestnetworks

[Daan Hoogland]

Absolutely, will be next week I am afraid.

On Tue, May 27, 2014 at 7:04 PM, Chiradeep Vittal
 wrote:
> Hi Daan,
>
> Sounds interesting! Could I beg you to post some images / figures and more
> text so that I can understand better?
>
> Thanks
> —
> Chiradeep
>
> From: Daan Hoogland 
> Date: Monday, May 26, 2014 at 3:39 AM
> To: Chiradeep Vittal 
> Cc: Alena Prokharchyk , Sheng Yang
> , Alex Huang ,
> "dev@cloudstack.apache.org" , Jayapal Reddy Uradi
> 
> Subject: Re: [DISCUSS] vpc gateway networks are guestnetworks
>
> Chiradeep,
>
> I read the vpc-peering option again and it seems not to give us
> enough. We want a superset of this feature where more then two vpc can
> be connected to the same intervpc network. Use cases are
> - have a single monitor and other management devices for several
> applications in different vpcs
> - have a promotion mechanism across test/acceptance/prod/postprod
> environments
> - (as long as we don't have redundant vpc routers) have a management
> environment connected to two vpc's to manage fail-over/dr scenario's
>
> using all peer to peer connections for this can get rather mashy.
> What do you think?
>
> Daan
>
>
> On Fri, May 23, 2014 at 10:56 PM, Daan Hoogland 
> wrote:
>
> As you can see it isn’t trivial.
>
> I guess you refer to the overlapping cidrs. I am afraid that some
> responsibility here will have to lay with the domain admin(s). If we
> limit inter vpc networks to one domain we can enforce the ip ranges
> not to overlap.
>
> the routing problem is tackled by a next hop field near the cidr.
>
> I am sure I am missing some other non trivial challenges.
>
> On Fri, May 23, 2014 at 7:23 PM, Chiradeep Vittal
>  wrote:
>
> I guess the ‘proper’ way to have done this would be to have a
> ‘createPrivateGateway’ API that is independent of the vpc and a
> attachPrivateGateway that attaches it to the vpc.
>
> Re: next hop, I’d like to see an FS for this feature. It seems to me that it
> is very similar to VPC peering (http://goo.gl/Y7tNkM).
> As you can see it isn’t trivial.
>
> From: Daan Hoogland 
> Date: Friday, May 23, 2014 at 2:06 AM
> To: Chiradeep Vittal , Alena Prokharchyk
> , Sheng Yang , Alex
> Huang 
> Cc: "dev@cloudstack.apache.org" 
> Subject: [DISCUSS] vpc gateway networks are guestnetworks
>
> Hi,
>
> please considder this ugly peace of my work I am now compiling into
> cloudstack master VpcManagerImpl.createVpcPrivateGateway(..) that will
> fix a bug:
>
>  {   // experimental block, this is a hack
>  // set vpc id in network to null
>  // might be needed for all types of broadcast domains
>  // the ugly hack is that vpc gateway nets are created as
> guest network
>  // while they are not.
>  // A more permanent solution would be to define a type of
> 'gatewaynetwork'
>  // so that handling code is not mixed between the two
>  NetworkVO gatewaynet = _ntwkDao.findById(privateNtwk.getId());
>  gatewaynet.setVpcId(vpcId);
>  _ntwkDao.persist(gatewaynet);
>  }
>
> the problem I want to solve is that vpc routers, when restarting
> assign the ip of the gateway to their gw-interface [1]. this is a ip
> conflict and it has bitten us. My first take was to create the network
> without passing the vpc id but that lead to all kinds of errors so I
> reverted. It seemed cleaner then this solution I am scheming for now.
> If this doesn't lead to obvious errors in my environment I will commit
> and be happy to again revert when integration tests fail. It is in any
> case not a permanent solution.
>
> Question: should the network for gateways be a special type that is
> handled almost the same as guest network (except for in this case) or
> is more refactoring needed?
> in any case I think this is something that will have to be dealt with soon.
>
> One consideration on the side: I want to add a next-hop field to the
> cidrs on the gateway so that it is possible to create a network with
> more vpcs that direct traffic to each other. The use case for this is
> a vpc for a customers mangement network connected to one for
> production and one for acceptance and one 
>
> please flame, criticize or pose your questions
>
> [1] https://issues.apache.org/jira/browse/CLOUDSTACK-6485
>
> --
> Daan
>
>
>
>
> --
> Daan
>
>
>
>
> --
> Daan
>



-- 
Daan

custom uuid of first class objects

[Marcus]

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Ability+to+control+the+external+id+of+first+class+objects

I'm trying to understand why this is admin only, given that it verifies
that the UUID is unique for the resource it seems it would be safe to allow
any user to supply their preferred UUID.

Re: custom uuid of first class objects

[Marcus]

I think I see. It doesn't enforce that UUIDs be unique, just that ACTIVE
(non-removed) UUIDs are unique. Therefore I suppose the intent was that you
don't want someone else stealing a removed UUID that might have belonged to
someone else.


On Tue, May 27, 2014 at 2:15 PM, Marcus  wrote:

>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Ability+to+control+the+external+id+of+first+class+objects
>
> I'm trying to understand why this is admin only, given that it verifies
> that the UUID is unique for the resource it seems it would be safe to allow
> any user to supply their preferred UUID.
>

Re: devcloud script deployDataCentre.py not working

[Daan Hoogland]

looks like my issue, I haven't been able to find the cause yet.

On Tue, May 27, 2014 at 9:02 PM, sebgoa  wrote:
> I tried devcloud2 on a fresh 4.4.
>
> the deploy scripts fails with:
>
> $ python ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
> Traceback (most recent call last):
>   File "../marvin/marvin/deployDataCenter.py", line 579, in 
> deploy.deploy()
>   File "../marvin/marvin/deployDataCenter.py", line 563, in deploy
> self.createZones(self.config.zones)
>   File "../marvin/marvin/deployDataCenter.py", line 425, in createZones
> self.createPods(zone.pods, zoneId, networkid)
>   File "../marvin/marvin/deployDataCenter.py", line 142, in createPods
> vmwareDc=pod.vmwaredc)
>   File "../marvin/marvin/deployDataCenter.py", line 87, in createClusters
> cluster.hypervisor)
>   File "../marvin/marvin/deployDataCenter.py", line 53, in addHosts
> self.apiClient.addHost(hostcmd)
>   File 
> "/Users/sebgoa/Documents/gitforks/cloudstack-asf/cloudstack/tools/marvin/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 1492, in addHost
> response = self.connection.marvinRequest(command, response_type=response, 
> method=method)
>   File 
> "/Users/sebgoa/Documents/gitforks/cloudstack-asf/cloudstack/tools/marvin/marvin/cloudstackConnection.py",
>  line 272, in marvinRequest
> response = jsonHelper.getResultObj(response.json(), response_type)
>   File 
> "/Users/sebgoa/Documents/gitforks/cloudstack-asf/cloudstack/tools/marvin/marvin/jsonHelper.py",
>  line 148, in getResultObj
> raise cloudstackException.cloudstackAPIException(respname, errMsg)
> cloudstackException.cloudstackAPIException: Execute cmd: addhost failed, due 
> to: errorCode: 530, errorText:Cannot transit agent status with event 
> AgentDisconnected for host 1, mangement server id is 1,Unable to transition 
> to a new state from Creating via AgentDisconnected
>
>
> and the mgt server logs are:
>
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-05a16b6a) Unable to 
> setup
> com.cloud.utils.exception.CloudRuntimeException: Cannot create directory 
> /opt/cloud/bin on XenServer hosts
> at 
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.setupServer(CitrixResourceBase.java:4850)
> at 
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4678)
> at 
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:494)
> at 
> com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOssResource.java:182)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> WARN  [c.c.h.x.d.XcpServerDiscoverer] (48940041@qtp-1783796402-5:ctx-3d757b56 
> ctx-9031fd34 ctx-e9224a2c) Unable to setup agent 1 due to Cannot create 
> directory /opt/cloud/bin on XenServer hosts
> INFO  [c.c.u.e.CSExceptionErrorCode] (48940041@qtp-1783796402-5:ctx-3d757b56 
> ctx-9031fd34 ctx-e9224a2c) Could not find exception: 
> com.cloud.exception.ConnectionException in error code list for exceptions
> WARN  [c.c.a.m.AgentManagerImpl] (48940041@qtp-1783796402-5:ctx-3d757b56 
> ctx-9031fd34 ctx-e9224a2c) Monitor XcpServerDiscoverer says there is an error 
> in the connect process for 1 due to Reinitialize agent after setup.
> INFO  [c.c.a.m.AgentManagerImpl] (48940041@qtp-1783796402-5:ctx-3d757b56 
> ctx-9031fd34 ctx-e9224a2c) Host 1 is disconnecting with event 
> AgentDisconnected
> WARN  [c.c.r.ResourceManagerImpl] (48940041@qtp-1783796402-5:ctx-3d757b56 
> ctx-9031fd34 ctx-e9224a2c) Unable to connect due to
> com.cloud.exception.ConnectionException: Reinitiali

Re: marvin master changes in 4.4-forward

[Daan Hoogland]

Marcus,

I don't see why only fixes should go in 4.4. It should have been
announced before feature freeze but there might be good reasons to
refactor if it improves maintainability or removes bugs. You can
revert the related commit and apply yours. or mix them.

regards

[GitHub] cloudstack-docs-install pull request: cleaned up formatting in all...

[swill]

GitHub user swill opened a pull request:

https://github.com/apache/cloudstack-docs-install/pull/13

cleaned up formatting in all the files

In addition to cleaning up the formatting in all the files, I also removed 
the deprecated 'managing_networks.rst' file.

I did not make any content changes, only formatting changes.

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

$ git pull https://github.com/cloudops/cloudstack-docs-install swill

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

https://github.com/apache/cloudstack-docs-install/pull/13.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #13


commit d1f729f21d8c320db5af4ad261b21a250355aa60
Author: Will Stevens 
Date:   2014-05-27T20:41:54Z

cleaned up formatting in all the files and removed the deprecated 
'managing_networks.rst' file




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

RE: [ACS45][ACS50][PROPOSAL] move forward feature freeze

[Ritu Sabharwal]

When  you say release schedule shift, does it mean 4.5 release target is moved 
from Oct '14 to a forward date?

Thanks & Regards,
Ritu S.

-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
Sent: Monday, May 26, 2014 5:26 AM
To: dev
Subject: [ACS45][ACS50][PROPOSAL] move forward feature freeze

LS,

When I seeing once again our release schedule shift, I think we have no option 
but to move feature freeze for the next release forward.
This is the only way it seems we can reduce the complexity of the total sum of 
changes. Therefore it is the only way we can prevent lapsing even more in time 
without risking reduced quality of our next release.
So I propose to move feature freeze forward by a month to be at the 19th of 
June (instead of July). I don't think we need to strictly move code freeze 
forward as well but vigilance onto added features will be necessary.

--
Daan

[GitHub] cloudstack-docs-admin pull request: updated the conf file so the l...

[swill]

GitHub user swill opened a pull request:

https://github.com/apache/cloudstack-docs-admin/pull/14

updated the conf file so the local theme is the same as the online theme

this helps document contributors know exactly what the themed doc will look 
like online.

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

$ git pull https://github.com/cloudops/cloudstack-docs-admin swill

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

https://github.com/apache/cloudstack-docs-admin/pull/14.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #14


commit dea0bf5a127f7e6367b5d72b471d01b1d6832fc1
Author: Will Stevens 
Date:   2014-05-27T20:47:49Z

updated the conf file so the theme is the same when you build locally as it 
is online




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

Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze

[Daan Hoogland]

What I mean is that to prevent the date of oct '14 moving we need to
move the feature freeze forward. so we have more time to create the
release.

On Tue, May 27, 2014 at 10:45 PM, Ritu Sabharwal  wrote:
> When  you say release schedule shift, does it mean 4.5 release target is 
> moved from Oct '14 to a forward date?
>
> Thanks & Regards,
> Ritu S.
>
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Monday, May 26, 2014 5:26 AM
> To: dev
> Subject: [ACS45][ACS50][PROPOSAL] move forward feature freeze
>
> LS,
>
> When I seeing once again our release schedule shift, I think we have no 
> option but to move feature freeze for the next release forward.
> This is the only way it seems we can reduce the complexity of the total sum 
> of changes. Therefore it is the only way we can prevent lapsing even more in 
> time without risking reduced quality of our next release.
> So I propose to move feature freeze forward by a month to be at the 19th of 
> June (instead of July). I don't think we need to strictly move code freeze 
> forward as well but vigilance onto added features will be necessary.
>
> --
> Daan



-- 
Daan

Re: marvin master changes in 4.4-forward

[Marcus]

My impression was that we should change as little as possible once a
release is cut. We fix bugs, but we don't change code just to make it more
maintainable, for fear of introducing more bugs or regressing the known
state of the release.

That aside, this fix is fairly minor so I'll probably just drop it. The
only question that remains is what people should do going forward when a
change needs to be made to an RC branch that is incompatible with its
"-forward" branch.


On Tue, May 27, 2014 at 2:23 PM, Daan Hoogland wrote:

> Marcus,
>
> I don't see why only fixes should go in 4.4. It should have been
> announced before feature freeze but there might be good reasons to
> refactor if it improves maintainability or removes bugs. You can
> revert the related commit and apply yours. or mix them.
>
> regards
>

Re: marvin master changes in 4.4-forward

[Daan Hoogland]

I share that last concern. I have seen a lot of commits on the branch
not matched by cherry-pick requests.

On Tue, May 27, 2014 at 11:16 PM, Marcus  wrote:
> My impression was that we should change as little as possible once a
> release is cut. We fix bugs, but we don't change code just to make it more
> maintainable, for fear of introducing more bugs or regressing the known
> state of the release.
>
> That aside, this fix is fairly minor so I'll probably just drop it. The
> only question that remains is what people should do going forward when a
> change needs to be made to an RC branch that is incompatible with its
> "-forward" branch.
>
>
> On Tue, May 27, 2014 at 2:23 PM, Daan Hoogland wrote:
>
>> Marcus,
>>
>> I don't see why only fixes should go in 4.4. It should have been
>> announced before feature freeze but there might be good reasons to
>> refactor if it improves maintainability or removes bugs. You can
>> revert the related commit and apply yours. or mix them.
>>
>> regards
>>



-- 
Daan

Review Request 21946: CLOUDSTACK-6392 system template always create with name "master" instead of specific branch

[Rayees Namathponnan]

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

Review request for cloudstack and Abhinandan Prateek.


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


Repository: cloudstack-git


Description
---

Create system vm from jenkins.buildacloud.org
in 4.4 System vm always create with same name 
"systemvm64template-master-xen.vhd"
it should be create with name "systemvm64template-4.4-xen.vhd"


Diffs
-

  tools/appliance/build.sh a228e26 

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


Testing
---

Tested below piece of code from source tree 

branch=

if [ -z "$branch" ] ; then
  branch=`git status | grep '# On branch' | awk '{print $4}'`
fi

if [ -z "$branch" ] ; then
branch=unknown
fi

echo "Branch"
echo $branch


Thanks,

Rayees Namathponnan

[ACS 4.4] Blocker and Critical Defects 5/27

[Sudha Ponnaganti]

There are 8 blockers and 77 critical defects outstanding
Dashboard 
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12323265

Blocker Defect List:

KeySummary Assignee
CLOUDSTACK-6779  [OVS] Expunging VM (deleting vif) deletes all the 
rules from ovs bridge flow tableMurali Reddy
CLOUDSTACK-6755  [OVS] Can't create more than 7 GRE tunnel networks in 
xen cluster Murali Reddy
CLOUDSTACK-6710  [Automation] VM snapshot failing with NPE in vmware  
Likitha Shetty
CLOUDSTACK-6644  Unable to attach Volume to a VM as a System User   
  Min Chen
CLOUDSTACK-6623  Register template does not work as expected, when 
deploying simulator and xen zones simultaneously on a single management server. 
  edison su
CLOUDSTACK-6603  [Upgrade]DB Exception while Autoscale monitoring after 
upgrading from 4.3 to 4.4 Rajesh Battala
CLOUDSTACK-6602  [UI] createNetworkACL API action param value passed 
incorrectly   Jessica Wang
CLOUDSTACK-6599  Template/Volume URLs expiration functionality not 
working  Nitin Mehta

Re: [ACS 4.4] Blocker and Critical Defects 5/27

[Min Chen]

CLOUDSTACK-6644 was filed before I disabled IAM feature on 4.4. I have
updated the bug to retest with latest code.

Thanks
-min

On 5/27/14 3:21 PM, "Sudha Ponnaganti"  wrote:

>There are 8 blockers and 77 critical defects outstanding
>Dashboard 
>https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12323265
>
>Blocker Defect List:
>
>KeySummary Assignee
>CLOUDSTACK-6779  [OVS] Expunging VM (deleting vif) deletes all
>the rules from ovs bridge flow tableMurali Reddy
>CLOUDSTACK-6755  [OVS] Can't create more than 7 GRE tunnel
>networks in xen cluster Murali Reddy
>CLOUDSTACK-6710  [Automation] VM snapshot failing with NPE in
>vmware  Likitha Shetty
>CLOUDSTACK-6644  Unable to attach Volume to a VM as a System User
>Min Chen
>CLOUDSTACK-6623  Register template does not work as expected,
>when deploying simulator and xen zones simultaneously on a single
>management server.   edison su
>CLOUDSTACK-6603  [Upgrade]DB Exception while Autoscale monitoring
>after upgrading from 4.3 to 4.4 Rajesh Battala
>CLOUDSTACK-6602  [UI] createNetworkACL API action param value
>passed incorrectly   Jessica Wang
>CLOUDSTACK-6599  Template/Volume URLs expiration functionality
>not working  Nitin Mehta

Re: [PROPOSAL] Using continuous integration to maintain our code quality...

[David Nalley]

On Tue, May 27, 2014 at 12:52 PM, Alex Huang  wrote:
>> Like Chip, I am very concerned with this being dependent on a single
>> company, even if its the company that employs me. It isn't sustainable, it
>> excludes others from contributing, and makes the project less independent
>> because it depends on a single company's infrastructure.
>
> Agreed there.
>
>>
>> I'm also unclear on the answer to the question in the FAQ. The first time I
>> read it, I got the impression that you were happy to bring it up on hardware
>> at the ASF if the ASF wanted to own it. The second time I read it I wondered
>> if you meant that Citrix was going to attempt to donate hardware.
>>
> Sorry if I did not make that clear.  I meant the scripts/code that we wrote 
> are checked in publicly and we're willing to help set it up if ASF provided 
> the hardware.  I have not approach Citrix on donating the actual hardware.  
> Although I can approach them if it speeds up the adoption process.
>
>> Finally - what do you think you need from ASF infra to make this happen?
>>
>
> It's currently about 10 servers with two networks.  One network is static 
> with IPMI to PXE boot the machines.  The other network is the actual data 
> network that CloudStack uses.  That's actually just enough for XenServer and 
> KVM.  In order to accommodate for HyperV, Bare Metal, LXC, (which we do not 
> have any test cases in the automation suits currently) we will need even more 
> machines.  We might be able to use nested virtualization for the hypervisors 
> to maintain server count at ten or a little more than ten but we haven't 
> explore that yet.
>
> The CI process is up and running on those machines but because we didn't have 
> CI running on master before, automation tests that were passing for 4.3 are 
> now broken again on 4.4. and master.  I think Sudha already reported on the 
> list that QA is busy trying to fix all the automation tests to bring CI on 
> 4.4-forward and master back to 100% pass rate.  Unfortunately, it's been 
> delaying our effort to put this out in the public and let the community try 
> this themselves.
>
> --Alex
>

So the board just approved a 3 month budget, but the new board will
have to take up the remainder of the FY budget shortly after coming
into office. Perhaps worth coming up with an estimate of what this
will cost/need and getting it to president@ before that new budget is
taken up.

--David

Re: How does Jenkins test new plugin for new device support?

[Prasanna Santhanam]

Ritu - you're correct. The plugin code at this point does not get
tested by our CI without the hardware. It has been the onus of the
contributor of the plugin to test against the hardware. 

Because the project cannot afford to purchase, deploy and test against
every piece of hardware we depend on the volunteer community to help
out. You are encouraged to write Marvin tests/unit tests against your
hardware and submit them to the repo along with the plugin code. In
the event of the CI system including the hardware at least these tests
can be run.

Meanwhile, the project is discussing on hardware requirements in
another thread which you responded to that AlexH @ Citrix started. If
your company is interested in donating hardware to the ASF for the
testing of its plugin, please keep an eye on how you can donate the
same so your plugin may be tested adequately

On Tue, May 27, 2014 at 10:27:05AM -0700, Ritu Sabharwal wrote:
> Hello,
> 
> Can someone please answer  this question for me?
> 
> Thanks & Regards,
> Ritu S.
> 
> -Original Message-
> From: Ritu Sabharwal [mailto:rsabh...@brocade.com] 
> Sent: Wednesday, May 21, 2014 2:28 PM
> To: dev@cloudstack.apache.org
> Subject: How does Jenkins test new plugin for new device support?
> 
> Hi,
> 
> I am adding a new plugin for supporting new device.
> Once the code is reviewed and committed to Git, would Jenkins run the 
> automated tests only for the management server and not the plugin code 
> because it would not have the new hardware to test it with.
> 
> How does that happen ?
> 
> Thanks & Regards,
> Ritu S.

-- 
Prasanna.,


Powered by BigRock.com

[ACS4.4] cherry-pick commit c91780449ae13d40ba9a2acfc5e0e6176f1beaee

[Rajani Karuturi]

Hi Daan,
Can you cherry-pick commit c91780449ae13d40ba9a2acfc5e0e6176f1beaee from 
4.4-forward to 4.4?
This fixes bug CLOUDSTACK-6781  

~Rajani

Re: Review Request 21946: CLOUDSTACK-6392 system template always create with name "master" instead of specific branch

[Abhinandan Prateek]

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

Ship it!


Ship It!

- Abhinandan Prateek


On May 27, 2014, 9:49 p.m., Rayees Namathponnan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21946/
> ---
> 
> (Updated May 27, 2014, 9:49 p.m.)
> 
> 
> Review request for cloudstack and Abhinandan Prateek.
> 
> 
> Bugs: CLOUDSTACK-6392
> https://issues.apache.org/jira/browse/CLOUDSTACK-6392
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Create system vm from jenkins.buildacloud.org
> in 4.4 System vm always create with same name 
> "systemvm64template-master-xen.vhd"
> it should be create with name "systemvm64template-4.4-xen.vhd"
> 
> 
> Diffs
> -
> 
>   tools/appliance/build.sh a228e26 
> 
> Diff: https://reviews.apache.org/r/21946/diff/
> 
> 
> Testing
> ---
> 
> Tested below piece of code from source tree 
> 
> branch=
> 
> if [ -z "$branch" ] ; then
>   branch=`git status | grep '# On branch' | awk '{print $4}'`
> fi
> 
> if [ -z "$branch" ] ; then
> branch=unknown
> fi
> 
> echo "Branch"
> echo $branch
> 
> 
> Thanks,
> 
> Rayees Namathponnan
> 
>

Re: Review Request 21946: CLOUDSTACK-6392 system template always create with name "master" instead of specific branch

[ASF Subversion and Git Services]

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


Commit 5f11c2e0be06ff1580ee7898b6316a4d61412db8 in cloudstack's branch 
refs/heads/master from rayeesn
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5f11c2e ]

CLOUDSTACK-6392: system template always create with name master instead of 
specific branch

Signed-off-by: Abhinandan Prateek 


- ASF Subversion and Git Services


On May 27, 2014, 9:49 p.m., Rayees Namathponnan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21946/
> ---
> 
> (Updated May 27, 2014, 9:49 p.m.)
> 
> 
> Review request for cloudstack and Abhinandan Prateek.
> 
> 
> Bugs: CLOUDSTACK-6392
> https://issues.apache.org/jira/browse/CLOUDSTACK-6392
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Create system vm from jenkins.buildacloud.org
> in 4.4 System vm always create with same name 
> "systemvm64template-master-xen.vhd"
> it should be create with name "systemvm64template-4.4-xen.vhd"
> 
> 
> Diffs
> -
> 
>   tools/appliance/build.sh a228e26 
> 
> Diff: https://reviews.apache.org/r/21946/diff/
> 
> 
> Testing
> ---
> 
> Tested below piece of code from source tree 
> 
> branch=
> 
> if [ -z "$branch" ] ; then
>   branch=`git status | grep '# On branch' | awk '{print $4}'`
> fi
> 
> if [ -z "$branch" ] ; then
> branch=unknown
> fi
> 
> echo "Branch"
> echo $branch
> 
> 
> Thanks,
> 
> Rayees Namathponnan
> 
>

Re: Review Request 21946: CLOUDSTACK-6392 system template always create with name "master" instead of specific branch

[ASF Subversion and Git Services]

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


Commit 63090434b1cb4e7b87f0e024fbbc644faee863f7 in cloudstack's branch 
refs/heads/4.4-forward from rayeesn
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6309043 ]

CLOUDSTACK-6392: system template always create with name master instead of 
specific branch

Signed-off-by: Abhinandan Prateek 


- ASF Subversion and Git Services


On May 27, 2014, 9:49 p.m., Rayees Namathponnan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21946/
> ---
> 
> (Updated May 27, 2014, 9:49 p.m.)
> 
> 
> Review request for cloudstack and Abhinandan Prateek.
> 
> 
> Bugs: CLOUDSTACK-6392
> https://issues.apache.org/jira/browse/CLOUDSTACK-6392
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Create system vm from jenkins.buildacloud.org
> in 4.4 System vm always create with same name 
> "systemvm64template-master-xen.vhd"
> it should be create with name "systemvm64template-4.4-xen.vhd"
> 
> 
> Diffs
> -
> 
>   tools/appliance/build.sh a228e26 
> 
> Diff: https://reviews.apache.org/r/21946/diff/
> 
> 
> Testing
> ---
> 
> Tested below piece of code from source tree 
> 
> branch=
> 
> if [ -z "$branch" ] ; then
>   branch=`git status | grep '# On branch' | awk '{print $4}'`
> fi
> 
> if [ -z "$branch" ] ; then
> branch=unknown
> fi
> 
> echo "Branch"
> echo $branch
> 
> 
> Thanks,
> 
> Rayees Namathponnan
> 
>

Review Request 21971: [Automation] Disabling the failed test cases in Xenserver and KVM runs

[Harikrishna Patnala]

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

Review request for cloudstack, Abhinandan Prateek and Koushik Das.


Bugs: CLOUDSTACK-6769 and CLOUDSTACK-6774
https://issues.apache.org/jira/browse/CLOUDSTACK-6769
https://issues.apache.org/jira/browse/CLOUDSTACK-6774


Repository: cloudstack-git


Description
---

[Automation] Disabling the failed test cases mentioned in the following tickets

integration.smoke.test_iso - CLOUDSTACK-6769, CLOUDSTACK-6774


Diffs
-

  test/integration/smoke/test_iso.py 93f436f 

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


Testing
---


Thanks,

Harikrishna Patnala

RE: [ACS45][ACS50][PROPOSAL] move forward feature freeze

[Ritu Sabharwal]

Thanks Daan for the clarification!

-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
Sent: Tuesday, May 27, 2014 1:56 PM
To: dev
Subject: Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze

What I mean is that to prevent the date of oct '14 moving we need to move the 
feature freeze forward. so we have more time to create the release.

On Tue, May 27, 2014 at 10:45 PM, Ritu Sabharwal  wrote:
> When  you say release schedule shift, does it mean 4.5 release target is 
> moved from Oct '14 to a forward date?
>
> Thanks & Regards,
> Ritu S.
>
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Monday, May 26, 2014 5:26 AM
> To: dev
> Subject: [ACS45][ACS50][PROPOSAL] move forward feature freeze
>
> LS,
>
> When I seeing once again our release schedule shift, I think we have no 
> option but to move feature freeze for the next release forward.
> This is the only way it seems we can reduce the complexity of the total sum 
> of changes. Therefore it is the only way we can prevent lapsing even more in 
> time without risking reduced quality of our next release.
> So I propose to move feature freeze forward by a month to be at the 19th of 
> June (instead of July). I don't think we need to strictly move code freeze 
> forward as well but vigilance onto added features will be necessary.
>
> --
> Daan



--
Daan

RE: How does Jenkins test new plugin for new device support?

[Ritu Sabharwal]

Hi Prasanna,

Thanks for the reply. I will keep a watch on other communication thread for 
hardware.

Thanks & Regards,
Ritu S.

-Original Message-
From: Prasanna Santhanam [mailto:t...@apache.org] 
Sent: Tuesday, May 27, 2014 10:24 PM
To: dev@cloudstack.apache.org
Cc: Alex Huang
Subject: Re: How does Jenkins test new plugin for new device support?

Ritu - you're correct. The plugin code at this point does not get tested by our 
CI without the hardware. It has been the onus of the contributor of the plugin 
to test against the hardware. 

Because the project cannot afford to purchase, deploy and test against every 
piece of hardware we depend on the volunteer community to help out. You are 
encouraged to write Marvin tests/unit tests against your hardware and submit 
them to the repo along with the plugin code. In the event of the CI system 
including the hardware at least these tests can be run.

Meanwhile, the project is discussing on hardware requirements in another thread 
which you responded to that AlexH @ Citrix started. If your company is 
interested in donating hardware to the ASF for the testing of its plugin, 
please keep an eye on how you can donate the same so your plugin may be tested 
adequately

On Tue, May 27, 2014 at 10:27:05AM -0700, Ritu Sabharwal wrote:
> Hello,
> 
> Can someone please answer  this question for me?
> 
> Thanks & Regards,
> Ritu S.
> 
> -Original Message-
> From: Ritu Sabharwal [mailto:rsabh...@brocade.com]
> Sent: Wednesday, May 21, 2014 2:28 PM
> To: dev@cloudstack.apache.org
> Subject: How does Jenkins test new plugin for new device support?
> 
> Hi,
> 
> I am adding a new plugin for supporting new device.
> Once the code is reviewed and committed to Git, would Jenkins run the 
> automated tests only for the management server and not the plugin code 
> because it would not have the new hardware to test it with.
> 
> How does that happen ?
> 
> Thanks & Regards,
> Ritu S.

--
Prasanna.,


Powered by BigRock.com

Re: Review Request 21971: [Automation] Disabling the failed test cases in Xenserver and KVM runs

[Abhinandan Prateek]

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

Ship it!


Ship It!

- Abhinandan Prateek


On May 28, 2014, 6:14 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21971/
> ---
> 
> (Updated May 28, 2014, 6:14 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-6769 and CLOUDSTACK-6774
> https://issues.apache.org/jira/browse/CLOUDSTACK-6769
> https://issues.apache.org/jira/browse/CLOUDSTACK-6774
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> [Automation] Disabling the failed test cases mentioned in the following 
> tickets
> 
> integration.smoke.test_iso - CLOUDSTACK-6769, CLOUDSTACK-6774
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_iso.py 93f436f 
> 
> Diff: https://reviews.apache.org/r/21971/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request 21971: [Automation] Disabling the failed test cases in Xenserver and KVM runs

[Prasanna Santhanam]

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


Why are you disabling the test? The bug reports indicate a problem in the setup 
of the SSVM's network. The SSVM is unable to download the ISO because of an 
unreachable network. That's got nothing to do with the test itself. 

- Prasanna Santhanam


On May 28, 2014, 6:14 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21971/
> ---
> 
> (Updated May 28, 2014, 6:14 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-6769 and CLOUDSTACK-6774
> https://issues.apache.org/jira/browse/CLOUDSTACK-6769
> https://issues.apache.org/jira/browse/CLOUDSTACK-6774
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> [Automation] Disabling the failed test cases mentioned in the following 
> tickets
> 
> integration.smoke.test_iso - CLOUDSTACK-6769, CLOUDSTACK-6774
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_iso.py 93f436f 
> 
> Diff: https://reviews.apache.org/r/21971/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

[GitHub] cloudstack-docs-install pull request: cleaned up formatting in all...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack-docs-install/pull/13


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

[GitHub] cloudstack-docs-admin pull request: updated the conf file so the l...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack-docs-admin/pull/14


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