[jira] [Created] (CLOUDSTACK-69) Hibernate jars should be removed

[Mice Xia (JIRA)]

Mice Xia created CLOUDSTACK-69:
--

 Summary: Hibernate jars should be removed
 Key: CLOUDSTACK-69
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-69
 Project: CloudStack
  Issue Type: Bug
  Components: AWSAPI
Affects Versions: pre-4.0.0
Reporter: Mice Xia
 Fix For: pre-4.0.0


Due to license issue, hibernate jars should be removed from cloud-deps.rpm, 
awsapi module does not depend on them anymore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

combining vmware-base and plugin/hypervisor/vmware?

[Hugo Trippaers]

Heya,

Anybody against moving all sources from vmware-base to 
plugin/hypervisors/vmware? It seems more logical to combine these two trees and 
make it a single plugin.

Cheers,

Hugo

RE: VM instance cannot aquire IP via DHCP when run on other host with Virtual Router/??????

[Nguyễn Đình Việt]

Hi guy,
I  try creating many VMs from other templates included: Ubuntu, CentOS, Windows 
2k with the same scerano then i have the same result too. When I migrate XP VM 
from host 1 to host 2 then it can obtain IP address from VR and can not  obtain 
IP address when I migrate it back to host 1.




Thanks & Best Regards.


-Original Message-
From: srivatsav.prasa...@gmail.com [mailto:srivatsav.prasa...@gmail.com] On 
Behalf Of prasanna
Sent: Sunday, September 09, 2012 8:07 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: VM instance cannot aquire IP via DHCP when run on other host with 
Virtual Router/??

On 8 September 2012 09:58, Nguyễn Đình Việt  wrote:
> Hi,
> I run 2 VM on 2 different hosts (VM XP run on host 1, VM hyperv run on host 
> 2, and VR running on host 2, VR's ip address is 10.1.1.1. All host running on 
> the same VLAN), only VM hyperv obtained IP address from VR.  This is result 
> in /var/log/message on VR:
>

Can you try and deploy the HyperV VM on both hosts? If the VMs (one on
VR host and one on different host) from the same template don't get
DHCPed you have to check your VLANs. If not there could be a problem
with the template. Is your XP template sysprepped?


> Sep  8 04:12:13 r-468-VM cloud: edithosts: update 02:00:27:b0:00:35 10.1.1.90 
> XP to hosts
> Sep  8 04:12:13 r-468-VM cloud: /root/edithosts.sh: setting default router 
> for 10.1.1.90 to 10.1.1.1
> Sep  8 04:12:13 r-468-VM cloud: /root/edithosts.sh: setting dns server for 
> 10.1.1.90 to 10.1.1.1
> Sep  8 04:12:44 r-468-VM cloud: edithosts: update 02:00:04:d3:00:3a 
> 10.1.1.107 hyperv to hosts
> Sep  8 04:12:44 r-468-VM cloud: /root/edithosts.sh: setting default router 
> for 10.1.1.107 to 10.1.1.1
> Sep  8 04:12:44 r-468-VM cloud: /root/edithosts.sh: setting dns server for 
> 10.1.1.107 to 10.1.1.1
>

> When I use renew ip address command on VM XP (run on host 1, other with VR)  
> and tcpdump command on VR then I don't receive any DHCP packet from VM XP.

Hmm - It looks like both the VMs have been given IPs by cloudstack -
10.1.1.107 and 10.1.1.90. Okay - it could be a problem with the XP
template. Are you able to get IPs for templates other than XP with the
same scenario?


smime.p7s
Description: S/MIME cryptographic signature

Need detail cloudstack networking document ???

[Nguyễn Đình Việt]

Hi guy,

I can not find any document that describe detail about cloudstack networking
(architecture, description, function of networking offering... on GUI). Can u
send me ?

Thanks and bestregards!


smime.p7s
Description: S/MIME cryptographic signature

Re: Review Request: CS-10219 Add option to set login attempts to portal.

[Nitin Mehta]

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

Ship it!


Ship It!

- Nitin Mehta


On Sept. 7, 2012, 11:46 a.m., saksham srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6858/
> ---
> 
> (Updated Sept. 7, 2012, 11:46 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh, Nitin Mehta, and Alena 
> Prokharchyk.
> 
> 
> Description
> ---
> 
> Added global setting login.attempts.allowed which defines the maximum 
> incorrect password attempts allowed.
> Also after the maximum attempts are reached the user account is disabled.
> 
> 
> This addresses bug CS-10219.
> 
> 
> Diffs
> -
> 
>   core/src/com/cloud/user/UserAccountVO.java 5e7c018 
>   server/src/com/cloud/configuration/Config.java ebcd070 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java f9da08d 
>   server/src/com/cloud/user/AccountManagerImpl.java 38153f3 
>   setup/db/create-schema.sql fa933e3 
>   setup/db/db/schema-302to40.sql aaf23e6 
> 
> Diff: https://reviews.apache.org/r/6858/diff/
> 
> 
> Testing
> ---
> 
> Verified locally.
> 
> 
> Thanks,
> 
> saksham srivastava
> 
>

Re: Review Request: CS-10219 Add option to set login attempts to portal.

[Nitin Mehta]

> On Sept. 7, 2012, 10:29 a.m., Nitin Mehta wrote:
> > server/src/com/cloud/user/AccountManagerImpl.java, line 1876
> > 
> >
> > Can you suggest him corrective action ? Like contacting him an admin or 
> > resetting his password. What options does he have.
> > I think there should be an alert generated to alert the admin that the 
> > user got locked. Also there should be an option to try infinitely like we 
> > have today.(may be setting it to -1). Its not fair to ask u to implement it 
> > right away but please file a bug for this.
> >
> 
> saksham srivastava wrote:
> Improved the message, will create a related bug and also update it on 
> Wiki page for Login attempts

If you dont mind can you please create the bug right away :) and let me know


- Nitin


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


On Sept. 7, 2012, 11:46 a.m., saksham srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6858/
> ---
> 
> (Updated Sept. 7, 2012, 11:46 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh, Nitin Mehta, and Alena 
> Prokharchyk.
> 
> 
> Description
> ---
> 
> Added global setting login.attempts.allowed which defines the maximum 
> incorrect password attempts allowed.
> Also after the maximum attempts are reached the user account is disabled.
> 
> 
> This addresses bug CS-10219.
> 
> 
> Diffs
> -
> 
>   core/src/com/cloud/user/UserAccountVO.java 5e7c018 
>   server/src/com/cloud/configuration/Config.java ebcd070 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java f9da08d 
>   server/src/com/cloud/user/AccountManagerImpl.java 38153f3 
>   setup/db/create-schema.sql fa933e3 
>   setup/db/db/schema-302to40.sql aaf23e6 
> 
> Diff: https://reviews.apache.org/r/6858/diff/
> 
> 
> Testing
> ---
> 
> Verified locally.
> 
> 
> Thanks,
> 
> saksham srivastava
> 
>

Re: Review Request: CS-16104: Improve restart network behaviour for basic network

[Murali Reddy]

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

Ship it!


Ship It!

- Murali Reddy


On Aug. 27, 2012, 11:10 a.m., Rohit Yadav wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6781/
> ---
> 
> (Updated Aug. 27, 2012, 11:10 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Alena Prokharchyk, and 
> Chiradeep Vittal.
> 
> 
> Description
> ---
> 
> Patch as per discussion on ML and http://bugs.cloudstack.org/browse/CS-16104
> 
> For git am:
> Download original patch: http://patchbin.baagi.org/p?id=yfawv5
> 
> 
> This addresses bug CS-16104.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/network/NetworkManagerImpl.java 817075e 
>   server/src/com/cloud/vm/dao/DomainRouterDao.java 01e3258 
>   server/src/com/cloud/vm/dao/DomainRouterDaoImpl.java 175d3f2 
>   server/src/com/cloud/vm/dao/VMInstanceDao.java 2cf3d75 
>   server/src/com/cloud/vm/dao/VMInstanceDaoImpl.java 571b5d1 
>   ui/scripts/network.js ec32c49 
> 
> Diff: https://reviews.apache.org/r/6781/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rohit Yadav
> 
>

[jira] [Created] (CLOUDSTACK-70) Improve Network Restart Behaviour for Basic Zone: Restarting Network Fails

[Rohit Yadav (JIRA)]

Rohit Yadav created CLOUDSTACK-70:
-

 Summary: Improve Network Restart Behaviour for Basic Zone: 
Restarting Network Fails
 Key: CLOUDSTACK-70
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-70
 Project: CloudStack
  Issue Type: Bug
Reporter: Rohit Yadav
Assignee: Rohit Yadav


Bug: http://bugs.cloudstack.org/browse/CS-16104
Review: https://reviews.apache.org/r/6781/

Proposed restart behaviour for basic network (keeping in sync with its 
behaviour in advance network):

Note: CS should check if there are any hosts in all Pods and deploy VR in only 
those which have any host as it's pod based.

a. Cleanup selected: cleanup=true
 - Running VRs: Stops and deletes them, recreates and starts new VRs.
 - Stopped VRs: Deletes them, recreates and starts new VRs.
 - Deleted VRs: Recreates and starts new VRs.

b. Cleanup not selected: cleanup=false
 - Running VRs: Checks/skip, proceeds.
 - Stopped VRs: Checks/prepares, starts them.
 - Deleted VRs: Checks/prepares, starts new VRs. 

Patch (clean=false the code skips running VMs)
For Apache master:
http://bhaisaab.org/patches/cloudstack/0001-CS-16104-Improve-restart-network-behaviour-for-basic-apache-master.patch
For 3.0.x:
http://bhaisaab.org/patches/cloudstack/0001-CS-16104-Improve-restart-network-behaviour-for-basic.patch



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Review Request: CS16171 : Cannot attach ISO on VMware VM due to Invalid datastore path error

[Murali Reddy]

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

Ship it!


Ship It!

- Murali Reddy


On Sept. 4, 2012, 5:47 a.m., Koushik Das wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6827/
> ---
> 
> (Updated Sept. 4, 2012, 5:47 a.m.)
> 
> 
> Review request for cloudstack, Murali Reddy and Kelven Yang.
> 
> 
> Description
> ---
> 
> Issue happens as incorrect datastore name is passed while attaching ISO, 
> passing correct name.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  ba71faf 
> 
> Diff: https://reviews.apache.org/r/6827/diff/
> 
> 
> Testing
> ---
> 
> Verified that attach/detach works for an ISO on Vmware
> 
> 
> Thanks,
> 
> Koushik Das
> 
>

[jira] [Resolved] (CLOUDSTACK-70) Improve Network Restart Behaviour for Basic Zone: Restarting Network Fails

[Rohit Yadav (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohit Yadav resolved CLOUDSTACK-70.
---

Resolution: Fixed

Fixed in master.

commit ecd1ac214c34007214557c4191a803a55ded29f5
Author: Rohit Yadav 
Date:   Mon Aug 27 16:32:38 2012 +0530


> Improve Network Restart Behaviour for Basic Zone: Restarting Network Fails
> --
>
> Key: CLOUDSTACK-70
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-70
> Project: CloudStack
>  Issue Type: Bug
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>
> Bug: http://bugs.cloudstack.org/browse/CS-16104
> Review: https://reviews.apache.org/r/6781/
> Proposed restart behaviour for basic network (keeping in sync with its 
> behaviour in advance network):
> Note: CS should check if there are any hosts in all Pods and deploy VR in 
> only those which have any host as it's pod based.
> a. Cleanup selected: cleanup=true
>  - Running VRs: Stops and deletes them, recreates and starts new VRs.
>  - Stopped VRs: Deletes them, recreates and starts new VRs.
>  - Deleted VRs: Recreates and starts new VRs.
> b. Cleanup not selected: cleanup=false
>  - Running VRs: Checks/skip, proceeds.
>  - Stopped VRs: Checks/prepares, starts them.
>  - Deleted VRs: Checks/prepares, starts new VRs. 
> Patch (clean=false the code skips running VMs)
> For Apache master:
> http://bhaisaab.org/patches/cloudstack/0001-CS-16104-Improve-restart-network-behaviour-for-basic-apache-master.patch
> For 3.0.x:
> http://bhaisaab.org/patches/cloudstack/0001-CS-16104-Improve-restart-network-behaviour-for-basic.patch

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Review Request: CS16171 : Cannot attach ISO on VMware VM due to Invalid datastore path error

[Murali Reddy]

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

Ship it!


Ship It!

- Murali Reddy


On Sept. 4, 2012, 5:47 a.m., Koushik Das wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6827/
> ---
> 
> (Updated Sept. 4, 2012, 5:47 a.m.)
> 
> 
> Review request for cloudstack, Murali Reddy and Kelven Yang.
> 
> 
> Description
> ---
> 
> Issue happens as incorrect datastore name is passed while attaching ISO, 
> passing correct name.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  ba71faf 
> 
> Diff: https://reviews.apache.org/r/6827/diff/
> 
> 
> Testing
> ---
> 
> Verified that attach/detach works for an ISO on Vmware
> 
> 
> Thanks,
> 
> Koushik Das
> 
>

Re: Review Request: CS-10219 Add option to set login attempts to portal.

[saksham srivastava]

> On Sept. 7, 2012, 10:29 a.m., Nitin Mehta wrote:
> > server/src/com/cloud/user/AccountManagerImpl.java, line 1876
> > 
> >
> > Can you suggest him corrective action ? Like contacting him an admin or 
> > resetting his password. What options does he have.
> > I think there should be an alert generated to alert the admin that the 
> > user got locked. Also there should be an option to try infinitely like we 
> > have today.(may be setting it to -1). Its not fair to ask u to implement it 
> > right away but please file a bug for this.
> >
> 
> saksham srivastava wrote:
> Improved the message, will create a related bug and also update it on 
> Wiki page for Login attempts
> 
> Nitin Mehta wrote:
> If you dont mind can you please create the bug right away :) and let me 
> know

Created issue : http://bugs.cloudstack.org/browse/CS-16314


- saksham


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


On Sept. 7, 2012, 11:46 a.m., saksham srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6858/
> ---
> 
> (Updated Sept. 7, 2012, 11:46 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh, Nitin Mehta, and Alena 
> Prokharchyk.
> 
> 
> Description
> ---
> 
> Added global setting login.attempts.allowed which defines the maximum 
> incorrect password attempts allowed.
> Also after the maximum attempts are reached the user account is disabled.
> 
> 
> This addresses bug CS-10219.
> 
> 
> Diffs
> -
> 
>   core/src/com/cloud/user/UserAccountVO.java 5e7c018 
>   server/src/com/cloud/configuration/Config.java ebcd070 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java f9da08d 
>   server/src/com/cloud/user/AccountManagerImpl.java 38153f3 
>   setup/db/create-schema.sql fa933e3 
>   setup/db/db/schema-302to40.sql aaf23e6 
> 
> Diff: https://reviews.apache.org/r/6858/diff/
> 
> 
> Testing
> ---
> 
> Verified locally.
> 
> 
> Thanks,
> 
> saksham srivastava
> 
>

Re: Review Request: Fix for AWSAPI contains hibernate configurations

[mice xia]

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

Ship it!


Ship It!

- mice xia


On Sept. 8, 2012, 7:40 a.m., Rajesh Battala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6967/
> ---
> 
> (Updated Sept. 8, 2012, 7:40 a.m.)
> 
> 
> Review request for cloudstack, David Nalley and edison su.
> 
> 
> Description
> ---
> 
> Removed awsapi/conf/CloudStack.cfg.xml 
> Modified cloud.spec to remove CloudStack.cfg.xml and hibernate config 
> references
> 
> 
> This addresses bug CLOUDSTACK-52.
> 
> 
> Diffs
> -
> 
>   awsapi/conf/CloudStack.cfg.xml 511e68f 
>   cloud.spec ab445ff 
> 
> Diff: https://reviews.apache.org/r/6967/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rajesh Battala
> 
>

CS not running in devcloud

[sebgoa]

Hi,

I pulled a fresh copy from master, built with maven, then ant clean-all 
build-all
I am running devcloud on localhost port .
I did ant rdeploy, ant redploydb, ant rdebug.

Everything thing seems to go fine.

then when I access http://localhost:8080/client  I get an error:

 [java] SEVERE: Servlet.service() for servlet jsp threw exception
  [sshexec] 
  [sshexec]  [java] java.lang.NoSuchMethodError: 
javax.servlet.jsp.tagext.TagAttributeInfo.(Ljava/lang/String;ZLjava/lang/String;ZZLjava/lang/String;ZZLjava/lang/String;Ljava/lang/String;)V
  [sshexec] 
  [sshexec]  [java] at 
org.apache.jasper.compiler.TagLibraryInfoImpl.createAttribute(TagLibraryInfoImpl.java:588)
  [sshexec] 
  [sshexec]  [java] at 
org.apache.jasper.compiler.TagLibraryInfoImpl.createTagInfo(TagLibraryInfoImpl.java:398)
  [sshexec] 
  [sshexec]  [java] at 
org.apache.jasper.compiler.TagLibraryInfoImpl.parseTLD(TagLibraryInfoImpl.java:251)
  [sshexec] 
  [sshexec]  [java] at 
org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:181)
  [sshexec] 
  [sshexec]  [java] at 
org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:386)
  [sshexec]  [java] at 
org.apache.jasper.compiler.Parser.parseDirective(Parser.java:450)
  [sshexec]  [java] at 
org.apache.jasper.compiler.Parser.parseElements(Parser.java:1397)
  [sshexec]  [java] at 
org.apache.jasper.compiler.Parser.parse(Parser.java:130)
  [sshexec]  [java] at 
org.apache.jasper.compiler.ParserController.doParse(ParserController.java:255)
  [sshexec]  [java] at 
org.apache.jasper.compiler.ParserController.parse(ParserController.java:103)
  [sshexec]  [java] at 
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:185)
  [sshexec]  [java] at 
org.apache.jasper.compiler.Compiler.compile(Compiler.java:347)
  [sshexec]  [java] at 
org.apache.jasper.compiler.Compiler.compile(Compiler.java:327)
  [sshexec]  [java] at 
org.apache.jasper.compiler.Compiler.compile(Compiler.java:314)
  [sshexec]  [java] at 
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
  [sshexec]  [java] at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:326)
  [sshexec]  [java] at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
  [sshexec]  [java] at 
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
  [sshexec]  [java] at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
  [sshexec]  [java] at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
  [sshexec]  [java] at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
  [sshexec]  [java] at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
  [sshexec]  [java] at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
  [sshexec]  [java] at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
  [sshexec]  [java] at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
  [sshexec]  [java] at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:554)
  [sshexec]  [java] at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
  [sshexec]  [java] at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
  [sshexec]  [java] at 
org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
  [sshexec]  [java] at 
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:732)
  [sshexec]  [java] at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2262)
  [sshexec]  [java] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
  [sshexec]  [java] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
  [sshexec]  [java] at java.lang.Thread.run(Thread.java:679)

And I was planning on doing a demo in 2 hours :(

Any help much appreciated,

-Sebastien

Re: CS not running in devcloud

[prasanna]

Does installing jakarta-taglibs-standard fix this? The ASF testing
thread showed a similar error.

On 10 September 2012 15:32, sebgoa  wrote:
> Hi,
>
> I pulled a fresh copy from master, built with maven, then ant clean-all 
> build-all
> I am running devcloud on localhost port .
> I did ant rdeploy, ant redploydb, ant rdebug.
>
> Everything thing seems to go fine.
>
> then when I access http://localhost:8080/client  I get an error:
>
>  [java] SEVERE: Servlet.service() for servlet jsp threw exception
>   [sshexec]
>   [sshexec]  [java] java.lang.NoSuchMethodError: 
> javax.servlet.jsp.tagext.TagAttributeInfo.(Ljava/lang/String;ZLjava/lang/String;ZZLjava/lang/String;ZZLjava/lang/String;Ljava/lang/String;)V
>   [sshexec]
>   [sshexec]  [java] at 
> org.apache.jasper.compiler.TagLibraryInfoImpl.createAttribute(TagLibraryInfoImpl.java:588)
>   [sshexec]
>   [sshexec]  [java] at 
> org.apache.jasper.compiler.TagLibraryInfoImpl.createTagInfo(TagLibraryInfoImpl.java:398)
>   [sshexec]
>   [sshexec]  [java] at 
> org.apache.jasper.compiler.TagLibraryInfoImpl.parseTLD(TagLibraryInfoImpl.java:251)
>   [sshexec]
>   [sshexec]  [java] at 
> org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:181)
>   [sshexec]
>   [sshexec]  [java] at 
> org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:386)
>   [sshexec]  [java] at 
> org.apache.jasper.compiler.Parser.parseDirective(Parser.java:450)
>   [sshexec]  [java] at 
> org.apache.jasper.compiler.Parser.parseElements(Parser.java:1397)
>   [sshexec]  [java] at 
> org.apache.jasper.compiler.Parser.parse(Parser.java:130)
>   [sshexec]  [java] at 
> org.apache.jasper.compiler.ParserController.doParse(ParserController.java:255)
>   [sshexec]  [java] at 
> org.apache.jasper.compiler.ParserController.parse(ParserController.java:103)
>   [sshexec]  [java] at 
> org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:185)
>   [sshexec]  [java] at 
> org.apache.jasper.compiler.Compiler.compile(Compiler.java:347)
>   [sshexec]  [java] at 
> org.apache.jasper.compiler.Compiler.compile(Compiler.java:327)
>   [sshexec]  [java] at 
> org.apache.jasper.compiler.Compiler.compile(Compiler.java:314)
>   [sshexec]  [java] at 
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
>   [sshexec]  [java] at 
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:326)
>   [sshexec]  [java] at 
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
>   [sshexec]  [java] at 
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
>   [sshexec]  [java] at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>   [sshexec]  [java] at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   [sshexec]  [java] at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   [sshexec]  [java] at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>   [sshexec]  [java] at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>   [sshexec]  [java] at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>   [sshexec]  [java] at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>   [sshexec]  [java] at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:554)
>   [sshexec]  [java] at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>   [sshexec]  [java] at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
>   [sshexec]  [java] at 
> org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
>   [sshexec]  [java] at 
> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:732)
>   [sshexec]  [java] at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2262)
>   [sshexec]  [java] at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>   [sshexec]  [java] at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>   [sshexec]  [java] at java.lang.Thread.run(Thread.java:679)
>
> And I was planning on doing a demo in 2 hours :(
>
> Any help much appreciated,
>
> -Sebastien
>
>
>
>

[jira] [Assigned] (CLOUDSTACK-22) Sign the release artifacts

[Pradeep Soundararajan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pradeep Soundararajan reassigned CLOUDSTACK-22:
---

Assignee: Chip Childers  (was: Pradeep Soundararajan)

> Sign the release artifacts
> --
>
> Key: CLOUDSTACK-22
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-22
> Project: CloudStack
>  Issue Type: Task
>Reporter: Ewan Mellor
>Assignee: Chip Childers
>Priority: Blocker
> Fix For: pre-4.0.0
>
>
> The release artifacts need to be signed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

RE: [jira] [Assigned] (CLOUDSTACK-22) Sign the release artifacts

[Pradeep Soundararajan]

Hi Chip,

Assigned this ticket to you :)

Thanks,
Pradeep.S


-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com] 
Sent: Friday, September 07, 2012 6:43 PM
To: cloudstack-dev@incubator.apache.org; Alex Huang; Pradeep Soundararajan
Subject: Re: [jira] [Assigned] (CLOUDSTACK-22) Sign the release artifacts

Alex / Pradeep,

I was assuming that this particular task would be completed by those of us that 
already added keys to the KEYS file:  John, David, Wido and myself.  Also, 
IIRC, the signatures have to be from committers with access to the ASF svn repo 
from a process perspective.  I guess we could do it a slightly different way, 
via an acs file patch to include Pradeep.

I'm more than happy to have this task assigned to me though...

-chip

On Fri, Sep 7, 2012 at 1:27 AM, Alex Huang (JIRA)  wrote:
>
>  [ 
> https://issues.apache.org/jira/browse/CLOUDSTACK-22?page=com.atlassian
> .jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Alex Huang reassigned CLOUDSTACK-22:
> 
>
> Assignee: Pradeep Soundararajan  (was: frank zhang)
>
>> Sign the release artifacts
>> --
>>
>> Key: CLOUDSTACK-22
>> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-22
>> Project: CloudStack
>>  Issue Type: Task
>>Reporter: Ewan Mellor
>>Assignee: Pradeep Soundararajan
>>Priority: Blocker
>> Fix For: pre-4.0.0
>>
>>
>> The release artifacts need to be signed.
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA 
> administrators For more information on JIRA, see: 
> http://www.atlassian.com/software/jira
>

Re: CS not running in devcloud

[sebgoa]

On Sep 10, 2012, at 12:05 PM, prasanna wrote:

> Does installing jakarta-taglibs-standard fix this? The ASF testing
> thread showed a similar error.

It might, but that package does not install properly with macports.
I will get back to the list once I get it figured out.

thanks,

-sebastien

> 
> On 10 September 2012 15:32, sebgoa  wrote:
>> Hi,
>> 
>> I pulled a fresh copy from master, built with maven, then ant clean-all 
>> build-all
>> I am running devcloud on localhost port .
>> I did ant rdeploy, ant redploydb, ant rdebug.
>> 
>> Everything thing seems to go fine.
>> 
>> then when I access http://localhost:8080/client  I get an error:
>> 
>> [java] SEVERE: Servlet.service() for servlet jsp threw exception
>>  [sshexec]
>>  [sshexec]  [java] java.lang.NoSuchMethodError: 
>> javax.servlet.jsp.tagext.TagAttributeInfo.(Ljava/lang/String;ZLjava/lang/String;ZZLjava/lang/String;ZZLjava/lang/String;Ljava/lang/String;)V
>>  [sshexec]
>>  [sshexec]  [java] at 
>> org.apache.jasper.compiler.TagLibraryInfoImpl.createAttribute(TagLibraryInfoImpl.java:588)
>>  [sshexec]
>>  [sshexec]  [java] at 
>> org.apache.jasper.compiler.TagLibraryInfoImpl.createTagInfo(TagLibraryInfoImpl.java:398)
>>  [sshexec]
>>  [sshexec]  [java] at 
>> org.apache.jasper.compiler.TagLibraryInfoImpl.parseTLD(TagLibraryInfoImpl.java:251)
>>  [sshexec]
>>  [sshexec]  [java] at 
>> org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:181)
>>  [sshexec]
>>  [sshexec]  [java] at 
>> org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:386)
>>  [sshexec]  [java] at 
>> org.apache.jasper.compiler.Parser.parseDirective(Parser.java:450)
>>  [sshexec]  [java] at 
>> org.apache.jasper.compiler.Parser.parseElements(Parser.java:1397)
>>  [sshexec]  [java] at 
>> org.apache.jasper.compiler.Parser.parse(Parser.java:130)
>>  [sshexec]  [java] at 
>> org.apache.jasper.compiler.ParserController.doParse(ParserController.java:255)
>>  [sshexec]  [java] at 
>> org.apache.jasper.compiler.ParserController.parse(ParserController.java:103)
>>  [sshexec]  [java] at 
>> org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:185)
>>  [sshexec]  [java] at 
>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:347)
>>  [sshexec]  [java] at 
>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:327)
>>  [sshexec]  [java] at 
>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:314)
>>  [sshexec]  [java] at 
>> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
>>  [sshexec]  [java] at 
>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:326)
>>  [sshexec]  [java] at 
>> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
>>  [sshexec]  [java] at 
>> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
>>  [sshexec]  [java] at 
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>>  [sshexec]  [java] at 
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>>  [sshexec]  [java] at 
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>  [sshexec]  [java] at 
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>>  [sshexec]  [java] at 
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>>  [sshexec]  [java] at 
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>>  [sshexec]  [java] at 
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>>  [sshexec]  [java] at 
>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:554)
>>  [sshexec]  [java] at 
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>>  [sshexec]  [java] at 
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
>>  [sshexec]  [java] at 
>> org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
>>  [sshexec]  [java] at 
>> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:732)
>>  [sshexec]  [java] at 
>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2262)
>>  [sshexec]  [java] at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>>  [sshexec]  [java] at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>>  [sshexec]  [java] at java.lang.Thread.run(Thread.java:679)
>> 
>> And I wa

Review Request: apache 4.0 docs

[Radhika PC]

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

Review request for cloudstack.


Description
---

This patch includes defect fixes and the new feature documentation: 
site-to-site vpn, inter-vlan routing, and autoscale. The issues pointed out for 
the Review Request #6328 has also been fixed. Updated the ASF license header 
for other files.


Diffs
-

  docs/en-US/Book_Info_Admin.xml PRE-CREATION 
  docs/en-US/LDAPserver-for-user-authentication.xml 5fcb300 
  docs/en-US/about-clusters.xml e328cba 
  docs/en-US/about-hosts.xml 956c695 
  docs/en-US/about-physical-networks.xml 8edb9e0 
  docs/en-US/about-pods.xml ed3520c 
  docs/en-US/about-primary-storage.xml 68d7a25 
  docs/en-US/about-secondary-storage.xml c4df0b8 
  docs/en-US/about-security-groups.xml PRE-CREATION 
  docs/en-US/about-virtual-networks.xml 2fc6ba9 
  docs/en-US/about-working-with-vms.xml 47153e2 
  docs/en-US/about-zones.xml a05a9a6 
  docs/en-US/accessing-vms.xml d69d021 
  docs/en-US/accounts-users-domains.xml 8549129 
  docs/en-US/accounts.xml 5292a9c 
  docs/en-US/acquire-new-ip-for-vpc.xml PRE-CREATION 
  docs/en-US/add-additional-guest-network.xml 57e7ffd 
  docs/en-US/add-clusters-kvm-xenserver.xml PRE-CREATION 
  docs/en-US/add-clusters-ovm.xml PRE-CREATION 
  docs/en-US/add-clusters-vsphere.xml PRE-CREATION 
  docs/en-US/add-gateway-vpc.xml PRE-CREATION 
  docs/en-US/add-ingress-egress-rules.xml 964045f 
  docs/en-US/add-iso.xml f56d10c 
  docs/en-US/add-load-balancer-rule.xml ddbce95 
  docs/en-US/add-loadbalancer-rule-vpc.xml PRE-CREATION 
  docs/en-US/add-more-clusters.xml PRE-CREATION 
  docs/en-US/add-portforward-rule-vpc.xml PRE-CREATION 
  docs/en-US/add-primary-storage.xml PRE-CREATION 
  docs/en-US/add-secondary-storage.xml PRE-CREATION 
  docs/en-US/add-security-group.xml e4c8b3c 
  docs/en-US/add-tier.xml PRE-CREATION 
  docs/en-US/add-vm-to-tier.xml PRE-CREATION 
  docs/en-US/add-vpc.xml PRE-CREATION 
  docs/en-US/advanced-zone-configuration.xml 85909e3 
  docs/en-US/advanced-zone-guest-ip-addresses.xml b5d10a0 
  docs/en-US/advanced-zone-network-traffic-types.xml 9f475cf 
  docs/en-US/advanced-zone-physical-network-configuration.xml 4c44c7d 
  docs/en-US/advanced-zone-public-ip-addresses.xml eeb9404 
  docs/en-US/alerts.xml f903023 
  docs/en-US/api-overview.xml PRE-CREATION 
  docs/en-US/attach-iso-to-vm.xml 30e5d51 
  docs/en-US/automatic-snapshot-creation-retention.xml ee4cf73 
  docs/en-US/autoscale.xml PRE-CREATION 
  docs/en-US/basic-zone-configuration.xml 18afa84 
  docs/en-US/basic-zone-guest-ip-addresses.xml d1d9135 
  docs/en-US/basic-zone-network-traffic-types.xml fa3be0f 
  docs/en-US/basic-zone-physical-network-configuration.xml 83833a7 
  docs/en-US/best-practices-for-vms.xml a67add4 
  docs/en-US/change-database-config.xml PRE-CREATION 
  docs/en-US/change-network-offering-on-guest-network.xml 98f1b63 
  docs/en-US/change-ssvm-service-offering.xml PRE-CREATION 
  docs/en-US/changing-root-password.xml 0d2333a 
  docs/en-US/changing-secondary-storage-ip.xml 7e146de 
  docs/en-US/changing-service-offering-for-vm.xml 5a42912 
  docs/en-US/changing-vm-name-os-group.xml f16ffda 
  docs/en-US/cloud-infrastructure-concepts.xml 58f8844 
  docs/en-US/cloud-infrastructure-overview.xml 5b467a3 
  docs/en-US/cloudstack_admin.xml c80c94f 
  docs/en-US/cluster-add-xenserver-kvm.xml PRE-CREATION 
  docs/en-US/cluster-add.xml 5210bd8 
  docs/en-US/compute-disk-service-offerings.xml 2469dfe 
  docs/en-US/concepts.xml 1912c23 
  docs/en-US/configure-acl.xml PRE-CREATION 
  docs/en-US/configure-guest-traffic-in-advanced-zone.xml 95df473 
  docs/en-US/configure-snmp-rhel.xml PRE-CREATION 
  docs/en-US/configure-usage-server.xml d167a49 
  docs/en-US/configure-vpc.xml PRE-CREATION 
  docs/en-US/configure-vpn.xml 9e059f7 
  docs/en-US/console-proxy.xml df29c42 
  docs/en-US/convert-hyperv-vm-to-template.xml c6294d4 
  docs/en-US/create-template-from-existing-vm.xml c22b7ec 
  docs/en-US/create-template-from-snapshot.xml 3075032 
  docs/en-US/create-templates-overview.xml 818b42d 
  docs/en-US/create-vpn-connection-vpc.xml PRE-CREATION 
  docs/en-US/create-vpn-customer-gateway.xml PRE-CREATION 
  docs/en-US/create-vpn-gateway-for-vpc.xml PRE-CREATION 
  docs/en-US/create-vr-network-offering.xml PRE-CREATION 
  docs/en-US/create-windows-template.xml f8dbc79 
  docs/en-US/creating-compute-offerings.xml 56679a4 
  docs/en-US/creating-network-offerings.xml ab56920 
  docs/en-US/creating-new-volumes.xml 62181b9 
  docs/en-US/creating-vms.xml dc37dbb 
  docs/en-US/default-account-resource-limit.xml abc313f 
  docs/en-US/delete-reset-vpn.xml PRE-CREATION 
  docs/en-US/deleting-vms.xml 1f1ee95 
  docs/en-US/deployment-architecture-overview.xml 6a67a2c 
  docs/en-US/detach-move-volumes.xml a00e15f 
  docs/en-US/developer-guide.xml c4bdf39 
  docs/en-US/enable-d

Re: ant clean-all build-all error. org.apache.axis2.tool.ant.AntCodegenTask cannot be found

[Wido den Hollander]

On 09/10/2012 07:50 AM, coudstacks wrote:

[root@cloudstack incubator-cloudstack]# mvn -P deps -pl deps


Could you try:

$ mvn install -P deps

And make sure you are using at least maven 3!

Wido


[INFO] Scanning for projects...
[INFO] 
[INFO] Building Apache CloudStack Dependencies
[INFO]task-segment: [install]
[INFO] 
[WARNING] The parameter expression: 'project.build.resources' used in mojo: 
'process' has been deprecated. Use 'project.resources' instead.
[INFO] [remote-resources:process {execution: default}]
Downloading: 
http://libvirt.org/maven2/org/libvirt/libvirt/0.4.8/libvirt-0.4.8.pom
1K downloaded  (libvirt-0.4.8.pom)
Downloading: 
http://repo1.maven.org/maven2/com/caringo/client/CAStorSDK/1.3.1-CS40/CAStorSDK-1.3.1-CS40.pom
3K downloaded  (CAStorSDK-1.3.1-CS40.pom)
Downloading: 
http://repo1.maven.org/maven2/org/sonatype/oss/oss-parent/7/oss-parent-7.pom
4K downloaded  (oss-parent-7.pom)
Downloading: 
http://repo1.maven.org/maven2/org/jvnet/hudson/jmdns/2.1/jmdns-2.1.pom
2K downloaded  (jmdns-2.1.pom)
Downloading: http://repo1.maven.org/maven2/log4j/log4j/1.2.14/log4j-1.2.14.pom
2K downloaded  (log4j-1.2.14.pom)
Downloading: 
http://ws.zones.apache.org/repository2/org/apache/woden/woden/1.0M8/woden-1.0M8.pom
[WARNING] Unable to get resource 'org.apache.woden:woden:pom:1.0M8' from 
repository apache-ws-snapshots2 (http://ws.zones.apache.org/repository2): Error 
transferring file: Connection timed out
Downloading: 
http://tomcat.apache.org/dev/dist/m2-repository/org/apache/woden/woden/1.0M8/woden-1.0M8.pom
[INFO] Unable to find resource 'org.apache.woden:woden:pom:1.0M8' in repository 
tomcat-repository (http://tomcat.apache.org/dev/dist/m2-repository)
Downloading: 
http://repo1.maven.org/eclipse/org/apache/woden/woden/1.0M8/woden-1.0M8.pom
[INFO] Unable to find resource 'org.apache.woden:woden:pom:1.0M8' in repository 
eclipse-repo (http://repo1.maven.org/eclipse)
Downloading: 
https://maven-repository.dev.java.net/nonav/repository//org.apache.woden/poms/woden-1.0M8.pom
[WARNING] Unable to get resource 'org.apache.woden:woden:pom:1.0M8' from 
repository java.net (https://maven-repository.dev.java.net/nonav/repository/): 
Error transferring file: maven-repository.dev.java.net
Downloading: 
http://repo1.maven.org/maven2/org/apache/woden/woden/1.0M8/woden-1.0M8.pom
[WARNING] Unable to get resource 'org.apache.woden:woden:pom:1.0M8' from 
repository central (http://repo1.maven.org/maven2): Error transferring file: 
Connection reset
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve dependencies for one or more projects in the reactor. 
Reason: Unable to get dependency information: Unable to read the metadata file 
for artifact 'org.apache.woden:woden-api:jar': Cannot find parent: 
org.apache.woden:woden for project: null:woden-api:jar:null for project 
null:woden-api:jar:null
   org.apache.woden:woden-api:jar:1.0M8
from the specified remote repositories:
   eclipse-repo (http://repo1.maven.org/eclipse),
   apache.snapshots (http://repository.apache.org/snapshots),
   central (http://repo1.maven.org/maven2),
   tomcat-repository (http://tomcat.apache.org/dev/dist/m2-repository),
   java.net (https://maven-repository.dev.java.net/nonav/repository/),
   apache-ws-snapshots2 (http://ws.zones.apache.org/repository2)
Path to dependency:
 1) org.apache.cloudstack:cloud-deps:jar:4.0.0-SNAPSHOT
 2) org.apache.axis2:axis2-ant-plugin:jar:1.4.1
 3) org.apache.axis2:axis2-codegen:jar:1.4.1
 4) org.apache.axis2:axis2-kernel:jar:1.4.1

Unable to download the artifact from any repository
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 38 seconds
[INFO] Finished at: Mon Sep 10 13:48:03 CST 2012
[INFO] Final Memory: 26M/63M
[INFO] 


At 2012-09-09 02:17:37,"Chip Childers"  wrote:

From the project root dir:

mvn -P deps -pl deps

That will get you the required dependencies.

On Sat, Sep 8, 2012 at 1:31 PM,   wrote:

mavan  can not configurate  build-environment correctly.



[root@xxx x]# ant clean-all
Buildfile: build.xml
  [echo] Using build parameters from 
/mnt/cloudstack/build/build-cloud.properties
  [echo] Using company info from /mnt/cloudstack/build/cloud.properties
  [echo] Using override file from /mnt/cloudstack/build/replace.properties
  [echo] Using build parameters from 
/mnt/cloudstack/build/build-cloud.properties
  [echo] Using company info from /mnt/cloudstack/build/cloud.propertie

[jira] [Assigned] (CLOUDSTACK-47) axis2 warfile in source tree

[Pradeep Soundararajan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pradeep Soundararajan reassigned CLOUDSTACK-47:
---

Assignee: Chip Childers  (was: Pradeep Soundararajan)

Could you please take care of this. 

> axis2 warfile in source tree
> 
>
> Key: CLOUDSTACK-47
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-47
> Project: CloudStack
>  Issue Type: Bug
>  Components: AWSAPI
>Affects Versions: pre-4.0.0
>Reporter: John Kinsella
>Assignee: Chip Childers
>Priority: Blocker
>  Labels: binary
>
> While looking at release candidate, noticed there's 2 copies of axis2.war:
> ./awsapi/axis2.war
> ./deps/awsapi-lib/axis2.war
> I believe these will need to be removed as there shouldn't be binaries in the 
> source tree.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

RE: VM instance cannot aquire IP via DHCP when run on other host with Virtual Router/??????

[Nguyễn Đình Việt]

Hi guy,
My network is divided VLAN and CS server (MS, hosts) belong to the same special 
VLAN. All host and MS are pluged into the same physical switch and this switch 
use a hub (plug and play, not create VLAN). But when I create Cloudstack 
advance zone, I don't define VLAN ID in Public Traffic create step because I 
think all host and MS in the same vlan and physical switch then they can 
communicate normaly. This can affect the problem that I'm having? VLAN ID in 
Public Traffic create step is required in VLAN network environment?


-Original Message-
From: viet...@viettel.com.vn [mailto:viet...@viettel.com.vn] 
Sent: Monday, September 10, 2012 2:53 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: VM instance cannot aquire IP via DHCP when run on other host with 
Virtual Router/??


Hi guy,
I  try creating many VMs from other templates included: Ubuntu, CentOS, Windows 
2k with the same scerano then i have the same result too. When I migrate XP VM 
from host 1 to host 2 then it can obtain IP address from VR and can not  obtain 
IP address when I migrate it back to host 1.




Thanks & Best Regards.


-Original Message-
From: srivatsav.prasa...@gmail.com [mailto:srivatsav.prasa...@gmail.com] On 
Behalf Of prasanna
Sent: Sunday, September 09, 2012 8:07 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: VM instance cannot aquire IP via DHCP when run on other host with 
Virtual Router/??

On 8 September 2012 09:58, Nguyễn Đình Việt  wrote:
> Hi,
> I run 2 VM on 2 different hosts (VM XP run on host 1, VM hyperv run on host 
> 2, and VR running on host 2, VR's ip address is 10.1.1.1. All host running on 
> the same VLAN), only VM hyperv obtained IP address from VR.  This is result 
> in /var/log/message on VR:
>

Can you try and deploy the HyperV VM on both hosts? If the VMs (one on
VR host and one on different host) from the same template don't get
DHCPed you have to check your VLANs. If not there could be a problem
with the template. Is your XP template sysprepped?


> Sep  8 04:12:13 r-468-VM cloud: edithosts: update 02:00:27:b0:00:35 10.1.1.90 
> XP to hosts
> Sep  8 04:12:13 r-468-VM cloud: /root/edithosts.sh: setting default router 
> for 10.1.1.90 to 10.1.1.1
> Sep  8 04:12:13 r-468-VM cloud: /root/edithosts.sh: setting dns server for 
> 10.1.1.90 to 10.1.1.1
> Sep  8 04:12:44 r-468-VM cloud: edithosts: update 02:00:04:d3:00:3a 
> 10.1.1.107 hyperv to hosts
> Sep  8 04:12:44 r-468-VM cloud: /root/edithosts.sh: setting default router 
> for 10.1.1.107 to 10.1.1.1
> Sep  8 04:12:44 r-468-VM cloud: /root/edithosts.sh: setting dns server for 
> 10.1.1.107 to 10.1.1.1
>

> When I use renew ip address command on VM XP (run on host 1, other with VR)  
> and tcpdump command on VR then I don't receive any DHCP packet from VM XP.

Hmm - It looks like both the VMs have been given IPs by cloudstack -
10.1.1.107 and 10.1.1.90. Okay - it could be a problem with the XP
template. Are you able to get IPs for templates other than XP with the
same scenario?


smime.p7s
Description: S/MIME cryptographic signature

Amazon EC2 API version compatibility in Cloudstack

[Pedro Navarro Pérez]

Hi all,

First of all I'd like to introduce ourselves, Bruno (CC'ed) and me
would like to collaborate in testing and developing the Amazon EC2 API
in Cloudstack.

We know that at the moment Cloudstack is compatible with Amazon E2 api
version 2010-11-15. We've done some preliminary tests in Cloudstack
4.0 with the latest version of Amazon SDK and it does not work
properly. So, we'd like to know if there will be efforts to make
Cloudstack compatible with latest version of Amazon EC2 API, and how
we can collaborate?

Thanks

Re: Amazon EC2 API version compatibility in Cloudstack

[Prasanna Santhanam]

On Mon, Sep 10, 2012 at 07:56:01AM -0400, Pedro Navarro Pérez wrote:
> Hi all,
> 
> First of all I'd like to introduce ourselves, Bruno (CC'ed) and me
> would like to collaborate in testing and developing the Amazon EC2 API
> in Cloudstack.
> 
> We know that at the moment Cloudstack is compatible with Amazon E2 api
> version 2010-11-15. We've done some preliminary tests in Cloudstack
> 4.0 with the latest version of Amazon SDK and it does not work
> properly. So, we'd like to know if there will be efforts to make
> Cloudstack compatible with latest version of Amazon EC2 API, and how
> we can collaborate?
> 
> Thanks

Welcome to the list Pedro and Bruno! Work is underway on fixing the
AWS API support. This work will most likey be in a post-4.0 release.
The Query API right now is not fully functional and folks on the list
are actively working on fixing it. I'll let them speak for this soon
as they get a chance. We're happy to have extra help at hand. The
patches to this list are sent through apache reviewboard. Do sign-up
at reviews.apache.org.

Currently the project is busy with the imminent release task for the
first incubator release of Apache CloudStack. So hang on a bit until
we begin to see more action on this front. We should see a seperate
branch where the AWS API work happens soon.

Meanwhile - We've chosen to run the ec2 test suite provided by
jClouds. It covers a good bit of ground for a quick compatibility
check.  


Thanks!

-- 
Prasanna.,

Re: VM instance cannot aquire IP via DHCP when run on other host with Virtual Router/??????

[prasanna]

On 10 September 2012 16:22, Nguyễn Đình Việt  wrote:
> Hi guy,
> My network is divided VLAN and CS server (MS, hosts) belong to the same 
> special VLAN. All host and MS are pluged into the same physical switch and 
> this switch use a hub (plug and play, not create VLAN). But when I create 
> Cloudstack advance zone, I don't define VLAN ID in Public Traffic create step 
> because I think all host and MS in the same vlan and physical switch then 
> they can communicate normaly. This can affect the problem that I'm having? 
> VLAN ID in Public Traffic create step is required in VLAN network environment?

Not sure what you mean by special VLAN? Default VLAN 1 on the switch?
The public traffic in CloudStack can go over untagged network.
However, for the guest VLAN range that cloudstack asks you to
configure what was given?


-- 
Prasanna.,

Review Request: Fix POM in test

[Rohit Yadav]

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

Review request for cloudstack, Prasanna Santhanam and Wido den Hollander.


Description
---

Fixes mvn deps for test

mvn -P deps :)

Download original patch: http://patchbin.baagi.org/p?id=zc1naa


Diffs
-

  deps/pom.xml 239e1f1 
  pom.xml dc74335 
  test/pom.xml 53e0bcd 

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


Testing
---


Thanks,

Rohit Yadav

Re: Review Request: Fix POM in test

[Prasanna Santhanam]

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

Ship it!


Ship It!

- Prasanna Santhanam


On Sept. 10, 2012, 12:45 p.m., Rohit Yadav wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6980/
> ---
> 
> (Updated Sept. 10, 2012, 12:45 p.m.)
> 
> 
> Review request for cloudstack, Prasanna Santhanam and Wido den Hollander.
> 
> 
> Description
> ---
> 
> Fixes mvn deps for test
> 
> mvn -P deps :)
> 
> Download original patch: http://patchbin.baagi.org/p?id=zc1naa
> 
> 
> Diffs
> -
> 
>   deps/pom.xml 239e1f1 
>   pom.xml dc74335 
>   test/pom.xml 53e0bcd 
> 
> Diff: https://reviews.apache.org/r/6980/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rohit Yadav
> 
>

Re: [DISCUSS] Should we deprecate the Jenkins build-cloudstack-master job?

[Wido den Hollander]

On 09/08/2012 08:27 PM, Chip Childers wrote:

build-cloudstack-master isn't working.  Should it be fixed or
deprecated in favor of build-cloudstack-master-maven?



I'm +1.

We are seeing a move to maven and I'm getting tired of my mailbox being 
spammed by Jenkins.


Wido

[jira] [Commented] (CLOUDSTACK-47) axis2 warfile in source tree

[Mice Xia (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451951#comment-13451951
 ] 

Mice Xia commented on CLOUDSTACK-47:


axis2.war can be fetched directly  by maven, but I'm not sure if this is the 
ASF way.


   org.apache.axis2
   axis2-webapp
   1.5.1


> axis2 warfile in source tree
> 
>
> Key: CLOUDSTACK-47
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-47
> Project: CloudStack
>  Issue Type: Bug
>  Components: AWSAPI
>Affects Versions: pre-4.0.0
>Reporter: John Kinsella
>Assignee: Chip Childers
>Priority: Blocker
>  Labels: binary
>
> While looking at release candidate, noticed there's 2 copies of axis2.war:
> ./awsapi/axis2.war
> ./deps/awsapi-lib/axis2.war
> I believe these will need to be removed as there shouldn't be binaries in the 
> source tree.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-69) Hibernate jars should be removed

[Mice Xia (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451953#comment-13451953
 ] 

Mice Xia commented on CLOUDSTACK-69:


commit in master 0d02e33d3154be3feb87c91e027389f0f8a64fec

> Hibernate jars should be removed
> 
>
> Key: CLOUDSTACK-69
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-69
> Project: CloudStack
>  Issue Type: Bug
>  Components: AWSAPI
>Affects Versions: pre-4.0.0
>Reporter: Mice Xia
> Fix For: pre-4.0.0
>
>
> Due to license issue, hibernate jars should be removed from cloud-deps.rpm, 
> awsapi module does not depend on them anymore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CLOUDSTACK-69) Hibernate jars should be removed

[Mice Xia (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mice Xia reassigned CLOUDSTACK-69:
--

Assignee: Mice Xia

> Hibernate jars should be removed
> 
>
> Key: CLOUDSTACK-69
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-69
> Project: CloudStack
>  Issue Type: Bug
>  Components: AWSAPI
>Affects Versions: pre-4.0.0
>Reporter: Mice Xia
>Assignee: Mice Xia
> Fix For: pre-4.0.0
>
>
> Due to license issue, hibernate jars should be removed from cloud-deps.rpm, 
> awsapi module does not depend on them anymore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Ubuntu build server issue

[Chip Childers]

Edison,

I think the build server that jenkins.cloudstack.org uses for Ubuntu
is broken / offline.  Since this is using a Citrix AWS account, I
think you (or someone else with access) might need to take a look.

Here's the relevant log from the latest ubuntu build attempt:

Supervisor: Waiting for processes start, should be 1, but 1
ubuntu12.04: /root/cloudstack/build/clone.sh: 1:
/root/cloudstack/build/commons.sh: Syntax error: "(" unexpected
ubuntu12.04: sh /root/cloudstack/build/clone.sh failed
ubuntu12.04:   File "client.py", line 170, in main
ubuntu12.04: cloneSource()
ubuntu12.04:File "client.py", line 34, in cloneSource
ubuntu12.04: bash(['sh', abspath('clone.sh')])
ubuntu12.04:File "/root/cloudstack/build/common.py", line 28, in __init__
ubuntu12.04: self.run()
ubuntu12.04:File "/root/cloudstack/build/common.py", line 54, in run
ubuntu12.04: raise  BashFailureException("%s failed"%self.args)
ubuntu12.04: Error, return code is 1Command 'ssh root@ubuntu1204 "cd
/root/cloudstack/build && python client.py && cd -"' returned non-zero
exit status 1
  File "hudsonbuild.py", line 301, in 
main()
   File "hudsonbuild.py", line 290, in main
waitForAllThreadsEnd()
   File "hudsonbuild.py", line 276, in waitForAllThreadsEnd
raise subprocess.CalledProcessError(p.returncode, p.cmd)
Build step 'Execute shell' marked build as failure
Archiving artifacts
Recording fingerprints
Finished: FAILURE

[jira] [Commented] (CLOUDSTACK-52) AWSAPI contains hibernate configurations

[Mice Xia (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451963#comment-13451963
 ] 

Mice Xia commented on CLOUDSTACK-52:


commit in master d9c03a55cfd482d2aa7a254e83ee75e7eaa02f7d

> AWSAPI contains hibernate configurations
> 
>
> Key: CLOUDSTACK-52
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-52
> Project: CloudStack
>  Issue Type: Bug
>  Components: AWSAPI
>Affects Versions: pre-4.0.0
>Reporter: David Nalley
>Assignee: Rajesh Battala
>Priority: Minor
>  Labels: deprecated
> Fix For: pre-4.0.0
>
>
> AWSAPI contains hibernate configuration files - since we no longer use 
> hibernate we should remove this. 
> awsapi/conf/CloudStack.cfg.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [DISCUSS] Should we deprecate the Jenkins build-cloudstack-master job?

[Chip Childers]

On Mon, Sep 10, 2012 at 9:01 AM, Wido den Hollander  wrote:
> On 09/08/2012 08:27 PM, Chip Childers wrote:
>>
>> build-cloudstack-master isn't working.  Should it be fixed or
>> deprecated in favor of build-cloudstack-master-maven?
>>
>
> I'm +1.
>
> We are seeing a move to maven and I'm getting tired of my mailbox being
> spammed by Jenkins.
>
> Wido
>

I've disabled that job, and will delete it at a future time (if nobody objects).

-chip

Re: combining vmware-base and plugin/hypervisor/vmware?

[Chip Childers]

On Mon, Sep 10, 2012 at 3:23 AM, Hugo Trippaers
 wrote:
> Heya,
>
> Anybody against moving all sources from vmware-base to 
> plugin/hypervisors/vmware? It seems more logical to combine these two trees 
> and make it a single plugin.
>
> Cheers,
>
> Hugo

Hey Hugo,

There might be a reason to keep it broken out.  For example, let's say
that I wanted to build a different plugin type that uses the VMware
API.

-chip

Re: [DISCUSS] Should we deprecate the Jenkins build-cloudstack-master job?

[Olivier Lamy]

+1

2012/9/8 Chip Childers :
> build-cloudstack-master isn't working.  Should it be fixed or
> deprecated in favor of build-cloudstack-master-maven?
>
> -chip



-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: [DISCUSS] Should we deprecate the Jenkins build-cloudstack-master job?

[Prasanna Santhanam]

On Mon, Sep 10, 2012 at 09:01:59AM -0400, Wido den Hollander wrote:
> On 09/08/2012 08:27 PM, Chip Childers wrote:
> > build-cloudstack-master isn't working.  Should it be fixed or
> > deprecated in favor of build-cloudstack-master-maven?
> >
> 
> I'm +1.
> 
> We are seeing a move to maven and I'm getting tired of my mailbox being 
> spammed by Jenkins.
> 

Just got the latest build to pass with help from Rohit Yadav. The
latest build is a success.  

+1 - for a single build job however.

-- 
Prasanna.,

Re: Review Request: Fix for AWSAPI contains hibernate configurations

[Rajesh Battala]

> On Sept. 10, 2012, 10 a.m., mice xia wrote:
> > Ship It!

Thanks for the review and comitting it.


- Rajesh


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


On Sept. 8, 2012, 7:40 a.m., Rajesh Battala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6967/
> ---
> 
> (Updated Sept. 8, 2012, 7:40 a.m.)
> 
> 
> Review request for cloudstack, David Nalley and edison su.
> 
> 
> Description
> ---
> 
> Removed awsapi/conf/CloudStack.cfg.xml 
> Modified cloud.spec to remove CloudStack.cfg.xml and hibernate config 
> references
> 
> 
> This addresses bug CLOUDSTACK-52.
> 
> 
> Diffs
> -
> 
>   awsapi/conf/CloudStack.cfg.xml 511e68f 
>   cloud.spec ab445ff 
> 
> Diff: https://reviews.apache.org/r/6967/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rajesh Battala
> 
>

RE: [jira] [Assigned] (CLOUDSTACK-27) JARs are still present in the tools directory

[Pradeep Soundararajan]

Please recommend, so this ticket has to be addressed as the same way we have 
addressed Third party dependencies removal?

Thanks,
Pradeep.S

-Original Message-
From: Alex Huang (JIRA) [mailto:j...@apache.org] 
Sent: Friday, September 07, 2012 10:55 AM
To: cloudstack-dev@incubator.apache.org
Subject: [jira] [Assigned] (CLOUDSTACK-27) JARs are still present in the tools 
directory


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang reassigned CLOUDSTACK-27:


Assignee: Pradeep Soundararajan

> JARs are still present in the tools directory
> -
>
> Key: CLOUDSTACK-27
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-27
> Project: CloudStack
>  Issue Type: Bug
>  Components: Test Tools
>Affects Versions: pre-4.0.0
>Reporter: David Nalley
>Assignee: Pradeep Soundararajan
>Priority: Blocker
> Fix For: pre-4.0.0
>
>
> As a general rule binaries should not live in the source tree. The tools 
> directory still has the following jars present. 
> ./tools/gcc/compiler.jar
> ./tools/junit/junit-4.8.1.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-swing.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-apache-bsf.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-apache-log4j.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-commons-net.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-apache-regexp.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-trax.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-jmf.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-javamail.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-jai.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-junit.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-jsch.jar
> ./tools/ant/apache-ant-1.7.1/lib/xercesImpl.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-jdepend.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-apache-oro.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-antlr.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-nodeps.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-commons-logging.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-netrexx.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-weblogic.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-starteam.jar
> ./tools/ant/apache-ant-1.7.1/lib/xml-apis.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-apache-resolver.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-testutil.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-stylebook.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-launcher.jar
> ./tools/ant/apache-ant-1.7.1/lib/ant-apache-bcel.jar
> ./tools/ant/apache-ant-1.7.1/etc/ant-bootstrap.jar

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators 
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [DISCUSS] Should we deprecate the Jenkins build-cloudstack-master job?

[Rohit Yadav]

On 10-Sep-2012, at 7:09 PM, Prasanna Santhanam  
wrote:

> On Mon, Sep 10, 2012 at 09:01:59AM -0400, Wido den Hollander wrote:
>> On 09/08/2012 08:27 PM, Chip Childers wrote:
>>> build-cloudstack-master isn't working.  Should it be fixed or
>>> deprecated in favor of build-cloudstack-master-maven?
>>> 
>> 
>> I'm +1.
>> 
>> We are seeing a move to maven and I'm getting tired of my mailbox being 
>> spammed by Jenkins.
>> 
> 
> Just got the latest build to pass with help from Rohit Yadav. The
> latest build is a success.  
> 
> +1 - for a single build job however.

+1, let's fix maven!

> 
> -- 
> Prasanna.,

[jira] [Assigned] (CLOUDSTACK-26) Jars still present in the what would be RC1

[Chip Childers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chip Childers reassigned CLOUDSTACK-26:
---

Assignee: Chip Childers  (was: Prachi Damle)

> Jars still present in the what would be RC1
> ---
>
> Key: CLOUDSTACK-26
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-26
> Project: CloudStack
>  Issue Type: Bug
>  Components: AWSAPI
>Affects Versions: pre-4.0.0
>Reporter: David Nalley
>Assignee: Chip Childers
>Priority: Blocker
>  Labels: release
> Fix For: pre-4.0.0
>
>
> As a general rule binaries should not be present in the source tree. AWSAPI 
> has the following jars in the tree. 
> ./awsapi/modules/axis2-spring-1.6.2.jar
> ./awsapi/modules/axis2-kernel-1.6.2.jar
> ./awsapi/modules/axis2-jaxws-1.6.2.jar
> ./awsapi/modules/axis2-jaxbri-1.6.2.jar
> ./awsapi/modules/axis2-corba-1.6.2.jar
> ./awsapi/modules/axis2-adb-codegen-1.6.2.jar
> ./awsapi/modules/axis2-xmlbeans-1.6.2.jar
> ./awsapi/modules/axis2-mtompolicy-1.6.2.jar
> ./awsapi/modules/axis2-transport-local-1.6.2.jar
> ./awsapi/modules/axis2-codegen-1.6.2.jar
> ./awsapi/modules/axis2-transport-http-1.6.2.jar
> ./awsapi/modules/axis2-jibx-1.6.2.jar
> ./awsapi/modules/axis2-clustering-1.6.2.jar
> ./awsapi/modules/axis2-java2wsdl-1.6.2.jar
> ./awsapi/modules/axis2-adb-1.6.2.jar
> ./awsapi/modules/axis2-saaj-1.6.2.jar
> ./awsapi/modules/axis2-metadata-1.6.2.jar
> ./awsapi/modules/axis2-ant-plugin-1.6.2.jar
> ./awsapi/modules/axis2-json-1.6.2.jar
> ./awsapi/modules/axis2-soapmonitor-servlet-1.6.2.jar
> ./awsapi/modules/axis2-fastinfoset-1.6.2.jar

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-69) Hibernate jars should be removed

[Chip Childers (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13452014#comment-13452014
 ] 

Chip Childers commented on CLOUDSTACK-69:
-

Mice,

Can we mark this bug as resolved then?

-chip

> Hibernate jars should be removed
> 
>
> Key: CLOUDSTACK-69
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-69
> Project: CloudStack
>  Issue Type: Bug
>  Components: AWSAPI
>Affects Versions: pre-4.0.0
>Reporter: Mice Xia
>Assignee: Mice Xia
> Fix For: pre-4.0.0
>
>
> Due to license issue, hibernate jars should be removed from cloud-deps.rpm, 
> awsapi module does not depend on them anymore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-69) Hibernate jars should be removed

[Mice Xia (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13452021#comment-13452021
 ] 

Mice Xia commented on CLOUDSTACK-69:


please wait a moment, wscript should also be modified or rpmbuild will complain

> Hibernate jars should be removed
> 
>
> Key: CLOUDSTACK-69
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-69
> Project: CloudStack
>  Issue Type: Bug
>  Components: AWSAPI
>Affects Versions: pre-4.0.0
>Reporter: Mice Xia
>Assignee: Mice Xia
> Fix For: pre-4.0.0
>
>
> Due to license issue, hibernate jars should be removed from cloud-deps.rpm, 
> awsapi module does not depend on them anymore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CLOUDSTACK-26) Jars still present in the what would be RC1

[Chip Childers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chip Childers resolved CLOUDSTACK-26.
-

Resolution: Fixed

committed to master at cbd4cb3fb9294a12f23492fa5d2481058b5bc329

> Jars still present in the what would be RC1
> ---
>
> Key: CLOUDSTACK-26
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-26
> Project: CloudStack
>  Issue Type: Bug
>  Components: AWSAPI
>Affects Versions: pre-4.0.0
>Reporter: David Nalley
>Assignee: Chip Childers
>Priority: Blocker
>  Labels: release
> Fix For: pre-4.0.0
>
>
> As a general rule binaries should not be present in the source tree. AWSAPI 
> has the following jars in the tree. 
> ./awsapi/modules/axis2-spring-1.6.2.jar
> ./awsapi/modules/axis2-kernel-1.6.2.jar
> ./awsapi/modules/axis2-jaxws-1.6.2.jar
> ./awsapi/modules/axis2-jaxbri-1.6.2.jar
> ./awsapi/modules/axis2-corba-1.6.2.jar
> ./awsapi/modules/axis2-adb-codegen-1.6.2.jar
> ./awsapi/modules/axis2-xmlbeans-1.6.2.jar
> ./awsapi/modules/axis2-mtompolicy-1.6.2.jar
> ./awsapi/modules/axis2-transport-local-1.6.2.jar
> ./awsapi/modules/axis2-codegen-1.6.2.jar
> ./awsapi/modules/axis2-transport-http-1.6.2.jar
> ./awsapi/modules/axis2-jibx-1.6.2.jar
> ./awsapi/modules/axis2-clustering-1.6.2.jar
> ./awsapi/modules/axis2-java2wsdl-1.6.2.jar
> ./awsapi/modules/axis2-adb-1.6.2.jar
> ./awsapi/modules/axis2-saaj-1.6.2.jar
> ./awsapi/modules/axis2-metadata-1.6.2.jar
> ./awsapi/modules/axis2-ant-plugin-1.6.2.jar
> ./awsapi/modules/axis2-json-1.6.2.jar
> ./awsapi/modules/axis2-soapmonitor-servlet-1.6.2.jar
> ./awsapi/modules/axis2-fastinfoset-1.6.2.jar

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CLOUDSTACK-47) axis2 warfile in source tree

[Chip Childers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chip Childers resolved CLOUDSTACK-47.
-

Resolution: Fixed

committed to master at cbd4cb3fb9294a12f23492fa5d2481058b5bc329

> axis2 warfile in source tree
> 
>
> Key: CLOUDSTACK-47
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-47
> Project: CloudStack
>  Issue Type: Bug
>  Components: AWSAPI
>Affects Versions: pre-4.0.0
>Reporter: John Kinsella
>Assignee: Chip Childers
>Priority: Blocker
>  Labels: binary
>
> While looking at release candidate, noticed there's 2 copies of axis2.war:
> ./awsapi/axis2.war
> ./deps/awsapi-lib/axis2.war
> I believe these will need to be removed as there shouldn't be binaries in the 
> source tree.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [1/3] git commit: Added gitignore for deps/*.jar so that the files are not added back into the source tree.

[David Nalley]

Any reason not to expand this to *.jar?

--David

On Mon, Sep 10, 2012 at 10:39 AM,   wrote:
> Updated Branches:
>   refs/heads/master 0d02e33d3 -> fc8fc2a5c
>
>
> Added gitignore for deps/*.jar so that the files are not added
> back into the source tree.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/repo
> Commit: 
> http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/commit/fc8fc2a5
> Tree: 
> http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/tree/fc8fc2a5
> Diff: 
> http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/diff/fc8fc2a5
>
> Branch: refs/heads/master
> Commit: fc8fc2a5c630f1214f823bb46472727ac4988a69
> Parents: cbd4cb3
> Author: Chip Childers 
> Authored: Mon Sep 10 10:38:42 2012 -0400
> Committer: Chip Childers 
> Committed: Mon Sep 10 10:38:42 2012 -0400
>
> --
>  .gitignore |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/fc8fc2a5/.gitignore
> --
> diff --git a/.gitignore b/.gitignore
> index 8a38aee..e5bd155 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -44,3 +44,4 @@ deps/cloud.userlibraries
>  git-remote-https.exe.stackdump
>  *.swp
>  tools/devcloud/devcloudbox/.vagrant
> +deps/*.jar
>

Re: VM instance cannot aquire IP via DHCP when run on other host with Virtual Router/??????

[VietNd4]

That mean, all hosts and MS belong to a VLAN (examp VLAN 100 with IP address 
192.168.1.0/24, not default VLAN 1, MS and host have only 1 NIC card, all 
traffice through this NIC card). And CS public range is 192.160.1.0/24 but i 
don't fill VLAN ID field at Public Traffice step when create zone (mean Public 
range address with VLAN field set to untagged). I configured guest VLAN range 
when create  zone (range 100-200). has problem in my configuration ?



- Original Message -
From: prasanna 
Date: Monday, September 10, 2012 7:30 pm
Subject: Re: VM instance cannot aquire IP via DHCP when run on other host with 
Virtual Router/??

> On 10 September 2012 16:22, Nguyễn Đình Việt 
>  wrote:
> > Hi guy,
> > My network is divided VLAN and CS server (MS, hosts) belong to 
> the same special VLAN. All host and MS are pluged into the same 
> physical switch and this switch use a hub (plug and play, not 
> create VLAN). But when I create Cloudstack advance zone, I don't 
> define VLAN ID in Public Traffic create step because I think all 
> host and MS in the same vlan and physical switch then they can 
> communicate normaly. This can affect the problem that I'm having? 
> VLAN ID in Public Traffic create step is required in VLAN network 
> environment?
> Not sure what you mean by special VLAN? Default VLAN 1 on the switch?
> The public traffic in CloudStack can go over untagged network.
> However, for the guest VLAN range that cloudstack asks you to
> configure what was given?
> 
> 
> -- 
> Prasanna.,
>

[jira] [Reopened] (CLOUDSTACK-26) Jars still present in the what would be RC1

[Chip Childers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chip Childers reopened CLOUDSTACK-26:
-


This commit broke the junit builds.  I'm looking at the build process now.

> Jars still present in the what would be RC1
> ---
>
> Key: CLOUDSTACK-26
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-26
> Project: CloudStack
>  Issue Type: Bug
>  Components: AWSAPI
>Affects Versions: pre-4.0.0
>Reporter: David Nalley
>Assignee: Chip Childers
>Priority: Blocker
>  Labels: release
> Fix For: pre-4.0.0
>
>
> As a general rule binaries should not be present in the source tree. AWSAPI 
> has the following jars in the tree. 
> ./awsapi/modules/axis2-spring-1.6.2.jar
> ./awsapi/modules/axis2-kernel-1.6.2.jar
> ./awsapi/modules/axis2-jaxws-1.6.2.jar
> ./awsapi/modules/axis2-jaxbri-1.6.2.jar
> ./awsapi/modules/axis2-corba-1.6.2.jar
> ./awsapi/modules/axis2-adb-codegen-1.6.2.jar
> ./awsapi/modules/axis2-xmlbeans-1.6.2.jar
> ./awsapi/modules/axis2-mtompolicy-1.6.2.jar
> ./awsapi/modules/axis2-transport-local-1.6.2.jar
> ./awsapi/modules/axis2-codegen-1.6.2.jar
> ./awsapi/modules/axis2-transport-http-1.6.2.jar
> ./awsapi/modules/axis2-jibx-1.6.2.jar
> ./awsapi/modules/axis2-clustering-1.6.2.jar
> ./awsapi/modules/axis2-java2wsdl-1.6.2.jar
> ./awsapi/modules/axis2-adb-1.6.2.jar
> ./awsapi/modules/axis2-saaj-1.6.2.jar
> ./awsapi/modules/axis2-metadata-1.6.2.jar
> ./awsapi/modules/axis2-ant-plugin-1.6.2.jar
> ./awsapi/modules/axis2-json-1.6.2.jar
> ./awsapi/modules/axis2-soapmonitor-servlet-1.6.2.jar
> ./awsapi/modules/axis2-fastinfoset-1.6.2.jar

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] [Assigned] (CLOUDSTACK-27) JARs are still present in the tools directory

[Chip Childers]

For each jar file, the question is when is it needed?

If it's a development-time convenience, then we should document how to
get it and what it's used for (but remove it from the tree).

If it's a compile or test-time requirement, then we need to get it
pulled down via the deps pom.xml.

-chip

On Mon, Sep 10, 2012 at 10:28 AM, Pradeep Soundararajan
 wrote:
> Please recommend, so this ticket has to be addressed as the same way we have 
> addressed Third party dependencies removal?
>
> Thanks,
> Pradeep.S
>
> -Original Message-
> From: Alex Huang (JIRA) [mailto:j...@apache.org]
> Sent: Friday, September 07, 2012 10:55 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: [jira] [Assigned] (CLOUDSTACK-27) JARs are still present in the 
> tools directory
>
>
>  [ 
> https://issues.apache.org/jira/browse/CLOUDSTACK-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>  ]
>
> Alex Huang reassigned CLOUDSTACK-27:
> 
>
> Assignee: Pradeep Soundararajan
>
>> JARs are still present in the tools directory
>> -
>>
>> Key: CLOUDSTACK-27
>> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-27
>> Project: CloudStack
>>  Issue Type: Bug
>>  Components: Test Tools
>>Affects Versions: pre-4.0.0
>>Reporter: David Nalley
>>Assignee: Pradeep Soundararajan
>>Priority: Blocker
>> Fix For: pre-4.0.0
>>
>>
>> As a general rule binaries should not live in the source tree. The tools 
>> directory still has the following jars present.
>> ./tools/gcc/compiler.jar
>> ./tools/junit/junit-4.8.1.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-swing.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-apache-bsf.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-apache-log4j.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-commons-net.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-apache-regexp.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-trax.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-jmf.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-javamail.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-jai.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-junit.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-jsch.jar
>> ./tools/ant/apache-ant-1.7.1/lib/xercesImpl.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-jdepend.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-apache-oro.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-antlr.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-nodeps.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-commons-logging.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-netrexx.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-weblogic.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-starteam.jar
>> ./tools/ant/apache-ant-1.7.1/lib/xml-apis.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-apache-resolver.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-testutil.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-stylebook.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-launcher.jar
>> ./tools/ant/apache-ant-1.7.1/lib/ant-apache-bcel.jar
>> ./tools/ant/apache-ant-1.7.1/etc/ant-bootstrap.jar
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators 
> For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [1/3] git commit: Added gitignore for deps/*.jar so that the files are not added back into the source tree.

[Chip Childers]

We're not quite there yet, but yes...  after we remove the remaining
jars.  The tools directory is the outstanding issue right now.

On Mon, Sep 10, 2012 at 10:55 AM, David Nalley  wrote:
> Any reason not to expand this to *.jar?
>
> --David
>
> On Mon, Sep 10, 2012 at 10:39 AM,   wrote:
>> Updated Branches:
>>   refs/heads/master 0d02e33d3 -> fc8fc2a5c
>>
>>
>> Added gitignore for deps/*.jar so that the files are not added
>> back into the source tree.
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/repo
>> Commit: 
>> http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/commit/fc8fc2a5
>> Tree: 
>> http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/tree/fc8fc2a5
>> Diff: 
>> http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/diff/fc8fc2a5
>>
>> Branch: refs/heads/master
>> Commit: fc8fc2a5c630f1214f823bb46472727ac4988a69
>> Parents: cbd4cb3
>> Author: Chip Childers 
>> Authored: Mon Sep 10 10:38:42 2012 -0400
>> Committer: Chip Childers 
>> Committed: Mon Sep 10 10:38:42 2012 -0400
>>
>> --
>>  .gitignore |1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/fc8fc2a5/.gitignore
>> --
>> diff --git a/.gitignore b/.gitignore
>> index 8a38aee..e5bd155 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -44,3 +44,4 @@ deps/cloud.userlibraries
>>  git-remote-https.exe.stackdump
>>  *.swp
>>  tools/devcloud/devcloudbox/.vagrant
>> +deps/*.jar
>>
>

Re: [1/3] git commit: Added gitignore for deps/*.jar so that the files are not added back into the source tree.

[David Nalley]

So putting something in .gitignore shouldn't affect any existing files
in the tree IIRC, but will stop new ones from (re)appearing.

On Mon, Sep 10, 2012 at 11:13 AM, Chip Childers
 wrote:
> We're not quite there yet, but yes...  after we remove the remaining
> jars.  The tools directory is the outstanding issue right now.
>
> On Mon, Sep 10, 2012 at 10:55 AM, David Nalley  wrote:
>> Any reason not to expand this to *.jar?
>>
>> --David
>>
>> On Mon, Sep 10, 2012 at 10:39 AM,   wrote:
>>> Updated Branches:
>>>   refs/heads/master 0d02e33d3 -> fc8fc2a5c
>>>
>>>
>>> Added gitignore for deps/*.jar so that the files are not added
>>> back into the source tree.
>>>
>>>
>>> Project: http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/repo
>>> Commit: 
>>> http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/commit/fc8fc2a5
>>> Tree: 
>>> http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/tree/fc8fc2a5
>>> Diff: 
>>> http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/diff/fc8fc2a5
>>>
>>> Branch: refs/heads/master
>>> Commit: fc8fc2a5c630f1214f823bb46472727ac4988a69
>>> Parents: cbd4cb3
>>> Author: Chip Childers 
>>> Authored: Mon Sep 10 10:38:42 2012 -0400
>>> Committer: Chip Childers 
>>> Committed: Mon Sep 10 10:38:42 2012 -0400
>>>
>>> --
>>>  .gitignore |1 +
>>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>> --
>>>
>>>
>>> http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/fc8fc2a5/.gitignore
>>> --
>>> diff --git a/.gitignore b/.gitignore
>>> index 8a38aee..e5bd155 100644
>>> --- a/.gitignore
>>> +++ b/.gitignore
>>> @@ -44,3 +44,4 @@ deps/cloud.userlibraries
>>>  git-remote-https.exe.stackdump
>>>  *.swp
>>>  tools/devcloud/devcloudbox/.vagrant
>>> +deps/*.jar
>>>
>>

[jira] [Closed] (CLOUDSTACK-52) AWSAPI contains hibernate configurations

[Rajesh Battala (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajesh Battala closed CLOUDSTACK-52.



> AWSAPI contains hibernate configurations
> 
>
> Key: CLOUDSTACK-52
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-52
> Project: CloudStack
>  Issue Type: Bug
>  Components: AWSAPI
>Affects Versions: pre-4.0.0
>Reporter: David Nalley
>Assignee: Rajesh Battala
>Priority: Minor
>  Labels: deprecated
> Fix For: pre-4.0.0
>
>
> AWSAPI contains hibernate configuration files - since we no longer use 
> hibernate we should remove this. 
> awsapi/conf/CloudStack.cfg.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CLOUDSTACK-69) Hibernate jars should be removed

[Mice Xia (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mice Xia resolved CLOUDSTACK-69.


Resolution: Fixed

commit 6318e88c7d6042b182dd4f52870a4e02461f2f24 for cloud.spec and wscript_build
verified in my own build environment

> Hibernate jars should be removed
> 
>
> Key: CLOUDSTACK-69
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-69
> Project: CloudStack
>  Issue Type: Bug
>  Components: AWSAPI
>Affects Versions: pre-4.0.0
>Reporter: Mice Xia
>Assignee: Mice Xia
> Fix For: pre-4.0.0
>
>
> Due to license issue, hibernate jars should be removed from cloud-deps.rpm, 
> awsapi module does not depend on them anymore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Poll (was Re: IRC Meeting Times)

[Daniel Kulp]

On Sep 8, 2012, at 12:37 PM, John Kinsella  wrote:

> The minutes from each of the meetings so far have been posted to the dev 
> list, and the minutes and full irc logs are in the wiki.
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IRC+Meetings+%28Logs+and+Minutes%29

Reading through the minutes, can I make a suggestion:

It might be good to provide links from the bullets on the list to the related 
discussions in the mail archives so people can jump directly to the 
discussions.   Filling in those links can also help make sure that discussions 
are started for anything that should have a discussion.

The main "Red Flag" to me was the line:

 AGREED: continue using waf to build rpm package  (jlkinsel, 17:24:57)

As soon as I saw "AGREED", a little red flag popped up in my head wondering if 
a decision had been made on IRC that should have been done on the list.   I 
believe this had been discussed to death on the list already (need to double 
check, very busy list) and a quick link to show that would definitely been 
helpful.


Dan




> 
> John
> 
> On Sep 8, 2012, at 9:28 AM, Noah Slater 
> mailto:nsla...@tumbolia.org>> wrote:
> 
> Do you have a plan for posting minutes to the mailing lists?
> 
> Holding meetings on IRC is fine, but important information, discussions,
> and decisions must me taken (or announced) on the mailing lists. It is
> important to have a permanent record of project progress. Both from a
> foundation perspective, legal perspective, and community perspective. (Not
> everyone who might wish to contribute can or wishes to use IRC.)
> 
> On Fri, Sep 7, 2012 at 2:20 AM, Joe Brockmeier 
> mailto:j...@zonker.net>> wrote:
> 
> Argh. Link here:
> 
> http://doodle.com/65avd6m2ppmea8rz
> 
> On Thu, Sep 6, 2012, at 05:22 PM, Joe Brockmeier wrote:
> Poll here, please vote! I'll leave this up for a few days.
> 
> Thanks,
> 
> Joe
> --
> Joe Brockmeier
> j...@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
> 
> --
> Joe Brockmeier
> j...@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
> 
> 
> 
> 
> --
> NS
> 
> Stratosec - Secure Infrastructure as a Service
> o: 415.315.9385
> @johnlkinsella
> 

-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

RE: Poll (was Re: IRC Meeting Times)

[Alex Huang]

> The main "Red Flag" to me was the line:
> 
>  AGREED: continue using waf to build rpm package  (jlkinsel, 17:24:57)
> 
> As soon as I saw "AGREED", a little red flag popped up in my head wondering
> if a decision had been made on IRC that should have been done on the list.   I
> believe this had been discussed to death on the list already (need to double
> check, very busy list) and a quick link to show that would definitely been
> helpful.

Daniel,

That's a really good point.  Here the agreement was that waf is the temporary 
solution to continue to use to get 4.0 release out.  It's not an agreement on 
long term direction of CloudStack.  Does it still count as a decision?  I mean 
there's tons of these types of "decisions" made during the IRC?  For example, 
who's going to help with what work.  Todo lists being generated.  Etc.  Do 
these all count as decisions?  

--Alex

[jira] [Assigned] (CLOUDSTACK-66) /tools/bugs-wiki is obsolete

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang reassigned CLOUDSTACK-66:


Assignee: Pradeep Soundararajan

> /tools/bugs-wiki is obsolete
> 
>
> Key: CLOUDSTACK-66
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-66
> Project: CloudStack
>  Issue Type: Bug
>Reporter: sebastien goasguen
>Assignee: Pradeep Soundararajan
>Priority: Minor
>
> tools/bugs-wiki contains two python scripts to search bugs.cloudstack.org and 
> wiki.cloudstack.org. They rely on a ~2004 SOAPpy module. At a minimum this 
> needs to be fixed. The search-wiki.py uses the wrong confluence wsdl. Both 
> scripts need to be updated to the new JIRA and wiki instances.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-66) /tools/bugs-wiki is obsolete

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang updated CLOUDSTACK-66:
-

Fix Version/s: pre-4.0.0

> /tools/bugs-wiki is obsolete
> 
>
> Key: CLOUDSTACK-66
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-66
> Project: CloudStack
>  Issue Type: Bug
>Reporter: sebastien goasguen
>Assignee: Pradeep Soundararajan
>Priority: Minor
> Fix For: pre-4.0.0
>
>
> tools/bugs-wiki contains two python scripts to search bugs.cloudstack.org and 
> wiki.cloudstack.org. They rely on a ~2004 SOAPpy module. At a minimum this 
> needs to be fixed. The search-wiki.py uses the wrong confluence wsdl. Both 
> scripts need to be updated to the new JIRA and wiki instances.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-62) console proxy does not support any keymaps besides us, jp

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang updated CLOUDSTACK-62:
-

Fix Version/s: 4.1.0

> console proxy does not support any keymaps besides us, jp
> -
>
> Key: CLOUDSTACK-62
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-62
> Project: CloudStack
>  Issue Type: Bug
>  Components: VNC Proxy
>Reporter: XxYton
>Priority: Minor
> Fix For: 4.1.0
>
>
> ajaxviewer.js supports only English and Japanese keymaps.
> There should be better support for different keymaps.
> Right now it's hard to implement new keymap layouts as ajaxviewer.js has no 
> modular code for keymap logic.
> Basically it's just US plus JP-hack.
> Optimum would be to have separate folder with one descriptor file per keymap 
> so that user can add own keymaps easily like translation files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

RE: ant clean-all build-all error. org.apache.axis2.tool.ant.AntCodegenTask cannot be found

[Edison Su]

There are two steps:
1. mvn -P deps
2. ant build-all
We will fully migrate to maven in the next few weeks. 

> -Original Message-
> From: yuel...@163.com [mailto:yuel...@163.com] On Behalf Of
> cloudsta...@163.com
> Sent: Saturday, September 08, 2012 10:32 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: ant clean-all build-all error.
> org.apache.axis2.tool.ant.AntCodegenTask cannot be found
> 
> mavan  can not configurate  build-environment correctly.
> 
> 
> 
> [root@xxx x]# ant clean-all
> Buildfile: build.xml
>  [echo] Using build parameters from /mnt/cloudstack/build/build-
> cloud.properties
>  [echo] Using company info from
> /mnt/cloudstack/build/cloud.properties
>  [echo] Using override file from
> /mnt/cloudstack/build/replace.properties
>  [echo] Using build parameters from /mnt/cloudstack/build/build-
> cloud.properties
>  [echo] Using company info from
> /mnt/cloudstack/build/cloud.properties
>  [echo] Using override file from
> /mnt/cloudstack/build/replace.properties
> 
> BUILD FAILED
> /mnt/cloudstack/build.xml:48: The following error occurred while
> executing this line:
> /mnt/cloudstack/build/build-aws-api.xml:34: taskdef class
> org.apache.axis2.tool.ant.AntCodegenTask cannot be found
> 
> Total time: 1 second

[jira] [Updated] (CLOUDSTACK-37) Warning while installing templates with cloud-install-sys-tmplt script line 108: [: missing `]' ]

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang updated CLOUDSTACK-37:
-

Fix Version/s: pre-4.0.0

> Warning while installing templates with cloud-install-sys-tmplt script  line 
> 108: [: missing `]' ]
> --
>
> Key: CLOUDSTACK-37
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-37
> Project: CloudStack
>  Issue Type: Bug
>  Components: Install and Setup
>Affects Versions: pre-4.0.0
>Reporter: Sailaja Mada
>Assignee: edison su
>Priority: Minor
> Fix For: pre-4.0.0
>
>
> Steps:
> 1. Install with rpm build
> 2. Tried to install system template using  cloud-install-sys-tmplt script.
> Observation:
> Error observed :
> /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt: 
> line 108: [: missing `]' 
> Extra space need to be added to the script before ']' with if condition to 
> avoid this error. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CLOUDSTACK-36) Warning while installing with RPM build [ cp: cannot stat `/usr/share/cloud/bridge/conf/hibernate.cfg.xml': No such file or directory]

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang reassigned CLOUDSTACK-36:


Assignee: Pradeep Soundararajan  (was: edison su)

> Warning while installing with RPM build [ cp: cannot stat 
> `/usr/share/cloud/bridge/conf/hibernate.cfg.xml': No such file or directory]
> --
>
> Key: CLOUDSTACK-36
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-36
> Project: CloudStack
>  Issue Type: Bug
>  Components: Install and Setup
>Affects Versions: pre-4.0.0
>Reporter: Sailaja Mada
>Assignee: Pradeep Soundararajan
>Priority: Minor
> Fix For: pre-4.0.0
>
>
> Steps:
> Tried to Install the rpm build.
> Observation:
> [root@ms3 ASF40]# rpm -Uvh *.rpm
> Preparing...### [100%]
>1:cloud-utils### [  8%]
>2:cloud-deps ### [ 17%]
>3:cloud-core ### [ 25%]
>4:cloud-server   ### [ 33%]
>5:cloud-python   ### [ 42%]
>6:cloud-setup### [ 50%]
>7:cloud-aws-api  ### [ 58%]
>8:cloud-agent-scripts### [ 67%]
>9:cloud-client-ui### [ 75%]
>   10:cloud-client   ### [ 83%]
> cp: cannot stat `/usr/share/cloud/bridge/conf/hibernate.cfg.xml': No such 
> file or directory
>   11:cloud-agent-libs   ### [ 92%]
>   12:cloud-cli  ### [100%]
> [root@ms3 ASF40]#
> Expected Result :
> Install should proceed with no issues.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-36) Warning while installing with RPM build [ cp: cannot stat `/usr/share/cloud/bridge/conf/hibernate.cfg.xml': No such file or directory]

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang updated CLOUDSTACK-36:
-

Fix Version/s: pre-4.0.0

> Warning while installing with RPM build [ cp: cannot stat 
> `/usr/share/cloud/bridge/conf/hibernate.cfg.xml': No such file or directory]
> --
>
> Key: CLOUDSTACK-36
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-36
> Project: CloudStack
>  Issue Type: Bug
>  Components: Install and Setup
>Affects Versions: pre-4.0.0
>Reporter: Sailaja Mada
>Assignee: Pradeep Soundararajan
>Priority: Minor
> Fix For: pre-4.0.0
>
>
> Steps:
> Tried to Install the rpm build.
> Observation:
> [root@ms3 ASF40]# rpm -Uvh *.rpm
> Preparing...### [100%]
>1:cloud-utils### [  8%]
>2:cloud-deps ### [ 17%]
>3:cloud-core ### [ 25%]
>4:cloud-server   ### [ 33%]
>5:cloud-python   ### [ 42%]
>6:cloud-setup### [ 50%]
>7:cloud-aws-api  ### [ 58%]
>8:cloud-agent-scripts### [ 67%]
>9:cloud-client-ui### [ 75%]
>   10:cloud-client   ### [ 83%]
> cp: cannot stat `/usr/share/cloud/bridge/conf/hibernate.cfg.xml': No such 
> file or directory
>   11:cloud-agent-libs   ### [ 92%]
>   12:cloud-cli  ### [100%]
> [root@ms3 ASF40]#
> Expected Result :
> Install should proceed with no issues.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-67) Resizing

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang updated CLOUDSTACK-67:
-

Fix Version/s: 4.1.0

> Resizing
> 
>
> Key: CLOUDSTACK-67
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-67
> Project: CloudStack
>  Issue Type: Improvement
>Reporter: XxYton
> Fix For: 4.1.0
>
>
> Resizing of volumes and instances is not possible right now.
> Instance resizing should be done without rebooting the VM if supported by 
> hypervisor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-65) compiler.jar in /tools/gcc

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang updated CLOUDSTACK-65:
-

Fix Version/s: pre-4.0.0

> compiler.jar in /tools/gcc
> --
>
> Key: CLOUDSTACK-65
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-65
> Project: CloudStack
>  Issue Type: Bug
>Reporter: sebastien goasguen
> Fix For: pre-4.0.0
>
>
> The Google Closure Compiler (gcc) is being shipped in /tools/gcc . Probably 
> needs to be removed, but it's unclear what it is being used for.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-25) Allow Virtual Load Balancer with basic zone

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang updated CLOUDSTACK-25:
-

Fix Version/s: 4.1.0

> Allow Virtual Load Balancer with basic zone
> ---
>
> Key: CLOUDSTACK-25
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-25
> Project: CloudStack
>  Issue Type: Improvement
>Reporter: Caleb Call
> Fix For: 4.1.0
>
>
> Currently, using a virtual lb is not allowed when using a basic zone.  This 
> would be a great feature to have for companies that don't have hardware load 
> balancers.  I'm told this was an option in the 2.x branch but got left out of 
> 3.x.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-24) Multiples IP's on Private LAN with Nat 1:1

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang updated CLOUDSTACK-24:
-

Fix Version/s: 4.1.0

> Multiples IP's on Private LAN with Nat 1:1
> --
>
> Key: CLOUDSTACK-24
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-24
> Project: CloudStack
>  Issue Type: Improvement
>  Components: Network Controller
>Reporter: Facundo Guerrero
>  Labels: features
> Fix For: 4.1.0
>
>
> I would be a great feature to have the possibility to add "floating Ip's" in 
> the private network and nat 1:1 to a public IP.
> It's not necessary to add a secondary network interface on the VM, in the OS 
> we add a virtual interface and assign the Private IP and NAT 1:1 with a 
> public IP.
> With this we can use the webserver's, postfix, and other software with 
> different public ip's

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CLOUDSTACK-65) compiler.jar in /tools/gcc

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang reassigned CLOUDSTACK-65:


Assignee: Sonny Chhen

It's probably being used by java script.

> compiler.jar in /tools/gcc
> --
>
> Key: CLOUDSTACK-65
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-65
> Project: CloudStack
>  Issue Type: Bug
>Reporter: sebastien goasguen
>Assignee: Sonny Chhen
> Fix For: pre-4.0.0
>
>
> The Google Closure Compiler (gcc) is being shipped in /tools/gcc . Probably 
> needs to be removed, but it's unclear what it is being used for.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-64) jar in /tools/junit needs to be removed

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang updated CLOUDSTACK-64:
-

Fix Version/s: pre-4.0.0

> jar in /tools/junit needs to be removed
> ---
>
> Key: CLOUDSTACK-64
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-64
> Project: CloudStack
>  Issue Type: Bug
>Reporter: sebastien goasguen
>Priority: Blocker
> Fix For: pre-4.0.0
>
>
> /tools/junit/junit-4.8.1.jar needs to be removed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CLOUDSTACK-64) jar in /tools/junit needs to be removed

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang reassigned CLOUDSTACK-64:


Assignee: Pradeep Soundararajan

> jar in /tools/junit needs to be removed
> ---
>
> Key: CLOUDSTACK-64
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-64
> Project: CloudStack
>  Issue Type: Bug
>Reporter: sebastien goasguen
>Assignee: Pradeep Soundararajan
>Priority: Blocker
> Fix For: pre-4.0.0
>
>
> /tools/junit/junit-4.8.1.jar needs to be removed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CLOUDSTACK-63) ant binary in /tools/ant/apache-ant-1.7.1 needs to be removed

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang reassigned CLOUDSTACK-63:


Assignee: Pradeep Soundararajan

> ant binary in /tools/ant/apache-ant-1.7.1 needs to be removed
> -
>
> Key: CLOUDSTACK-63
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-63
> Project: CloudStack
>  Issue Type: Bug
>Reporter: sebastien goasguen
>Assignee: Pradeep Soundararajan
>Priority: Blocker
> Fix For: pre-4.0.0
>
>
> There is an old ant install in /tools/ant

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-63) ant binary in /tools/ant/apache-ant-1.7.1 needs to be removed

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang updated CLOUDSTACK-63:
-

Fix Version/s: pre-4.0.0

> ant binary in /tools/ant/apache-ant-1.7.1 needs to be removed
> -
>
> Key: CLOUDSTACK-63
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-63
> Project: CloudStack
>  Issue Type: Bug
>Reporter: sebastien goasguen
>Assignee: Pradeep Soundararajan
>Priority: Blocker
> Fix For: pre-4.0.0
>
>
> There is an old ant install in /tools/ant

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-55) Ensure we are complying with ASF guidelines for export control

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang updated CLOUDSTACK-55:
-

Fix Version/s: (was: 4.0.0)
   pre-4.0.0

> Ensure we are complying with ASF guidelines for export control
> --
>
> Key: CLOUDSTACK-55
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-55
> Project: CloudStack
>  Issue Type: Task
>Affects Versions: 4.0.0
>Reporter: David Nalley
>Assignee: David Nalley
>Priority: Blocker
> Fix For: pre-4.0.0
>
>
> CloudStack uses crypto, which is export controlled. Ensure we comply with the 
> ASF/US Government guidelines. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CLOUDSTACK-45) deps/awsapi-lib/rampart-lib

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang reassigned CLOUDSTACK-45:


Assignee: Prachi Damle

> deps/awsapi-lib/rampart-lib 
> 
>
> Key: CLOUDSTACK-45
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-45
> Project: CloudStack
>  Issue Type: Bug
>  Components: AWSAPI
>Affects Versions: pre-4.0.0
>Reporter: David Nalley
>Assignee: Prachi Damle
>Priority: Blocker
> Fix For: pre-4.0.0
>
>
> deps/awsapi-lib/rampart-lib contains a number of binaries (jars) that need to 
> be removed. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-45) deps/awsapi-lib/rampart-lib

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang updated CLOUDSTACK-45:
-

Fix Version/s: (was: 4.0.0)
   pre-4.0.0

> deps/awsapi-lib/rampart-lib 
> 
>
> Key: CLOUDSTACK-45
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-45
> Project: CloudStack
>  Issue Type: Bug
>  Components: AWSAPI
>Affects Versions: pre-4.0.0
>Reporter: David Nalley
>Assignee: Prachi Damle
>Priority: Blocker
> Fix For: pre-4.0.0
>
>
> deps/awsapi-lib/rampart-lib contains a number of binaries (jars) that need to 
> be removed. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CLOUDSTACK-43) Jenkins build process needs to allow for setting the appropriate version number within the built JARs.

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang reassigned CLOUDSTACK-43:


Assignee: Pradeep Soundararajan

> Jenkins build process needs to allow for setting the appropriate version 
> number within the built JARs.
> --
>
> Key: CLOUDSTACK-43
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-43
> Project: CloudStack
>  Issue Type: Bug
>Affects Versions: pre-4.0.0
>Reporter: Chip Childers
>Assignee: Pradeep Soundararajan
>Priority: Critical
> Fix For: pre-4.0.0
>
>
> The Jenkins binary build processes are producing JAR files that contain 
> version numbers like 4.0.0-SNAPSHOT.  We need a way to set a parameter within 
> the build to set the version from SNAPSHOT to RC1 or even drop the 
> pre-release identifier entirely (so that we can generate an actual release).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CLOUDSTACK-44) Jenkins build process needs to use the correct version number for the tar.gz file name and the RPM/DEB package versions.

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang reassigned CLOUDSTACK-44:


Assignee: Pradeep Soundararajan

> Jenkins build process needs to use the correct version number for the tar.gz 
> file name and the RPM/DEB package versions.
> 
>
> Key: CLOUDSTACK-44
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-44
> Project: CloudStack
>  Issue Type: Bug
>Affects Versions: pre-4.0.0
>Reporter: Chip Childers
>Assignee: Pradeep Soundararajan
>Priority: Critical
> Fix For: pre-4.0.0
>
>
> The Jenkins binary build processes are producing version numbers for the 
> packages and the tar.gz archive that use 4.0.[buildnumber].  We need a way to 
> change this, so that the version string is controlled and matches our 
> documented release numbering process.
> The job build number should be embedded somewhere, but I think there's a 
> specific place for that within the spec and deb config files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CLOUDSTACK-41) Binary package license issue

[Alex Huang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Huang reassigned CLOUDSTACK-41:


Assignee: Pradeep Soundararajan

> Binary package license issue
> 
>
> Key: CLOUDSTACK-41
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-41
> Project: CloudStack
>  Issue Type: Bug
>Affects Versions: pre-4.0.0
>Reporter: Chip Childers
>Assignee: Pradeep Soundararajan
>Priority: Blocker
> Fix For: pre-4.0.0
>
>
> The install.sh script that's bundled with the tar.gz distro of RPM and DEB 
> packages doesn't contain the ASF license header.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Poll (was Re: IRC Meeting Times)

[Noah Slater]

There are no hard and fast rules. (Which makes it tricky to get right.)

The goal here is to make the project transparent (permanent mail archives,
posting IRC logs) and open (the most amount of people can contribute). The
problem with IRC is that usually works against those goals.

The logs sidestep that, partly. It would be better if you posted your logs
to the mailing list though. (So there is a permanent record of them.) The
wiki is good (at least it is on ASF infra) but I believe (and I may be
wrong) that the mailing list is preferred for conversational items.

The open thing is problematic. People must be able to interact with the
project via the mailing list. And they must be able to weigh in on topics,
and help to make decisions. We cannot put barriers up that exclude them.
(Either by choosing specific time to meet, or a specific location.) That's
why important (stress on "important") decisions must not be made on IRC.

So it comes down to a judgement call, I guess.

If you're sorting out task lists, and somebody is saying that they will do
X or Y, then that is obviously fine. But if you're deciding on features, or
tickets, or patches, then it should be brought to the mailing list. That
doesn't mean you can't talk about it on IRC. Or even come to a conclusion
on IRC. But it must be presented to the mailing list as the outcome of a
discussion which has been brought to the list.

Bad:

- Agreed we would not accept the patch on CLOUDSTACK-4566

Good:

- Concerns raised about CLOUDSTACK-4566, noted on the ticket

Another thing that might help is the distinction between a project decision
and a person decision. A project decision might start with "CloudStack will
not..." A personal decision might start with "I will..."

This is an important distinction, because most of the things committers
will be doing will be personal decisions. Whether to merge a patch, work on
a feature, and so on. For things like that, consider the principals of lazy
consensus and assent through silence. [1] That is, assume what you're about
to do is okay, announce it, and then do it. No need to *ask permission* for
stuff.

So, for your meetings. It's fine if you're reporting that people are
intending to DO stuff. But probably not too great if you are announcing
that project level decisions are being made. (Remember that project level
decisions might, in fact, include stuff like merging patches, or adding
features. While it is generally favourable to operate according to "it's
easier to ask for forgiveness than permission", sometimes commits, or
tickets, or whatever, will be challenged, and that's when it needs to come
to the lists.)

Sorry if this isn't as terse as you were hoping. It's a complex issue. We
struggled with it for years with CouchDB. It's more of an art than a
science. We actually have a collection of very active IRC channels. And we
discuss things frequently. But we will usually summarise what was
discussed, and lay out a plan of action for individual committers. (As
opposed to, for example, saying "CouchDB has decided to...")

Keep the goals in mind, and try to do the right thing.

[1] http://www.apache.org/foundation/voting.html

On Mon, Sep 10, 2012 at 5:32 PM, Alex Huang  wrote:

> > The main "Red Flag" to me was the line:
> >
> >  AGREED: continue using waf to build rpm package  (jlkinsel, 17:24:57)
> >
> > As soon as I saw "AGREED", a little red flag popped up in my head
> wondering
> > if a decision had been made on IRC that should have been done on the
> list.   I
> > believe this had been discussed to death on the list already (need to
> double
> > check, very busy list) and a quick link to show that would definitely
> been
> > helpful.
>
> Daniel,
>
> That's a really good point.  Here the agreement was that waf is the
> temporary solution to continue to use to get 4.0 release out.  It's not an
> agreement on long term direction of CloudStack.  Does it still count as a
> decision?  I mean there's tons of these types of "decisions" made during
> the IRC?  For example, who's going to help with what work.  Todo lists
> being generated.  Etc.  Do these all count as decisions?
>
> --Alex
>



-- 
NS

[jira] [Closed] (CLOUDSTACK-41) Binary package license issue

[edison su (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

edison su closed CLOUDSTACK-41.
---

Resolution: Fixed

> Binary package license issue
> 
>
> Key: CLOUDSTACK-41
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-41
> Project: CloudStack
>  Issue Type: Bug
>Affects Versions: pre-4.0.0
>Reporter: Chip Childers
>Assignee: Pradeep Soundararajan
>Priority: Blocker
> Fix For: pre-4.0.0
>
>
> The install.sh script that's bundled with the tar.gz distro of RPM and DEB 
> packages doesn't contain the ASF license header.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: cleaning up patch disks

[Marcus Sorensen]

My initial idea on tackling this is that we shouldn't be using unique
names for the patch disk. We could use a name like vm instance uuid +
'patch' (this seems to go against the methodologies used everwhere
else, but since they seem to be untracked and one-time-use at this
point maybe that doesn't matter), or generate a non-random uuid
somehow based on the system vm name or some other attribute unique to
that system VM (suggestions welcome). Then if it already exists we
just format and use the existing patch disk, otherwise we create it as
normal.

This seems like the most reasonable way to make sure we're not leaving
orphaned disks behind on every system VM reboot/crash. Or perhaps they
should just be tracked as member volumes in the database (I'm not sure
what the original reasoning was for how it's done now), but maybe a
static name for the patch disk is a reasonable triage at this point?

On Sun, Sep 9, 2012 at 10:31 PM, Marcus Sorensen  wrote:
> I've got an issue with the CLVM on KVM support, it seems that the
> patch disks are created on the fly when a system VM is started. If I
> reboot a system VM 5 times I'll end up with 5 patch disks. I'm the one
> who submitted the CLVM patch, and I don't see that there's much
> difference between what we're doing with CLVM and what it does for
> everything else, so I thought I'd ask:
>
> Is this an issue for other backing stores as well (accumulating patch
> disks for system VMs)? If not where is it handled?
>
> Any suggestions on how to go about fixing it? I see I could
> potentially hack into StopCommand, rebootVM/cleanupVM/stopVM, detect
> the patch disk and lvremove it, but then again if it doesn't go down
> on purpose (say a host crash) I'll still be leaking patch disks.
>
> Is it safe to assume that any patch disk that's not currently open is
> safe to delete (these are generated on the fly and not really tracked
> anywhere in the database, right?)

Re: Review Request: CLOUDSTACK-10:Deleting a disconnected primary storage results in partial removed state

[Alena Prokharchyk]

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


With the current implementation the pool has to be marked as removed prior to 
starting the removal process. Otherwise it makes it available for new volumes 
creation while the pool is going through removing stage.

The correct fix would be:

* introduce the "state" field for the storage pool. Having 3 values for this 
state should be sufficient enough by now: Created, Removing, Removed. Created 
would be the initial state
* when delete is called for the storage pool, update the pool with Removing 
state, don't update the Removed field yet. Check all the cloudStack storage 
operations to ensure that the storage pool in Removing state can't be used for 
any operations requiring storage access
* After the removal is successful, update state to Removed, and set Removed 
field to not null date value.

Also make sure that:

* deleteStorage api can be called on the storage pool with Removing state. 
* better introduce state machine for storage state management, it will make 
code more readable. 

- Alena Prokharchyk


On Sept. 4, 2012, 3:10 p.m., Gavin Lee wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6900/
> ---
> 
> (Updated Sept. 4, 2012, 3:10 p.m.)
> 
> 
> Review request for cloudstack and Alena Prokharchyk.
> 
> 
> Description
> ---
> 
> Keep the remove operation transactional which avoid partial updated when 
> exception occurs.
> 
> 
> This addresses bug CLOUDSTACK-10.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/storage/StorageManagerImpl.java 50a78db 
> 
> Diff: https://reviews.apache.org/r/6900/diff/
> 
> 
> Testing
> ---
> 
> tested and verified the fix works correctly.
> 
> 
> Thanks,
> 
> Gavin Lee
> 
>

[jira] [Commented] (CLOUDSTACK-62) console proxy does not support any keymaps besides us, jp

[edison su (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13452152#comment-13452152
 ] 

edison su commented on CLOUDSTACK-62:
-

The keyboard stuff is little bit complicated than a simple map, actually it's a 
tuple of (browser, hypervisor, keyboard), but anyway we do need a framework 
that people can easily add new keyboard mapping.
Will you like to help us on it?

> console proxy does not support any keymaps besides us, jp
> -
>
> Key: CLOUDSTACK-62
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-62
> Project: CloudStack
>  Issue Type: Bug
>  Components: VNC Proxy
>Reporter: XxYton
>Priority: Minor
> Fix For: 4.1.0
>
>
> ajaxviewer.js supports only English and Japanese keymaps.
> There should be better support for different keymaps.
> Right now it's hard to implement new keymap layouts as ajaxviewer.js has no 
> modular code for keymap logic.
> Basically it's just US plus JP-hack.
> Optimum would be to have separate folder with one descriptor file per keymap 
> so that user can add own keymaps easily like translation files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

RE: Ubuntu build server issue

[Edison Su]

It's fixed.

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Monday, September 10, 2012 6:24 AM
> To: Edison Su
> Cc: cloudstack-dev@incubator.apache.org
> Subject: Ubuntu build server issue
> 
> Edison,
> 
> I think the build server that jenkins.cloudstack.org uses for Ubuntu
> is broken / offline.  Since this is using a Citrix AWS account, I
> think you (or someone else with access) might need to take a look.
> 
> Here's the relevant log from the latest ubuntu build attempt:
> 
> Supervisor: Waiting for processes start, should be 1, but 1
> ubuntu12.04: /root/cloudstack/build/clone.sh: 1:
> /root/cloudstack/build/commons.sh: Syntax error: "(" unexpected
> ubuntu12.04: sh /root/cloudstack/build/clone.sh failed
> ubuntu12.04:   File "client.py", line 170, in main
> ubuntu12.04: cloneSource()
> ubuntu12.04:File "client.py", line 34, in cloneSource
> ubuntu12.04: bash(['sh', abspath('clone.sh')])
> ubuntu12.04:File "/root/cloudstack/build/common.py", line 28, in
> __init__
> ubuntu12.04: self.run()
> ubuntu12.04:File "/root/cloudstack/build/common.py", line 54, in
> run
> ubuntu12.04: raise  BashFailureException("%s failed"%self.args)
> ubuntu12.04: Error, return code is 1Command 'ssh root@ubuntu1204 "cd
> /root/cloudstack/build && python client.py && cd -"' returned non-zero
> exit status 1
>   File "hudsonbuild.py", line 301, in 
> main()
>File "hudsonbuild.py", line 290, in main
> waitForAllThreadsEnd()
>File "hudsonbuild.py", line 276, in waitForAllThreadsEnd
> raise subprocess.CalledProcessError(p.returncode, p.cmd)
> Build step 'Execute shell' marked build as failure
> Archiving artifacts
> Recording fingerprints
> Finished: FAILURE

[jira] [Assigned] (CLOUDSTACK-45) deps/awsapi-lib/rampart-lib

[Chip Childers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chip Childers reassigned CLOUDSTACK-45:
---

Assignee: Chip Childers  (was: Prachi Damle)

> deps/awsapi-lib/rampart-lib 
> 
>
> Key: CLOUDSTACK-45
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-45
> Project: CloudStack
>  Issue Type: Bug
>  Components: AWSAPI
>Affects Versions: pre-4.0.0
>Reporter: David Nalley
>Assignee: Chip Childers
>Priority: Blocker
> Fix For: pre-4.0.0
>
>
> deps/awsapi-lib/rampart-lib contains a number of binaries (jars) that need to 
> be removed. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-45) deps/awsapi-lib/rampart-lib

[Chip Childers (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13452159#comment-13452159
 ] 

Chip Childers commented on CLOUDSTACK-45:
-

I'm actively working on this.

> deps/awsapi-lib/rampart-lib 
> 
>
> Key: CLOUDSTACK-45
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-45
> Project: CloudStack
>  Issue Type: Bug
>  Components: AWSAPI
>Affects Versions: pre-4.0.0
>Reporter: David Nalley
>Assignee: Chip Childers
>Priority: Blocker
> Fix For: pre-4.0.0
>
>
> deps/awsapi-lib/rampart-lib contains a number of binaries (jars) that need to 
> be removed. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Poll (was Re: IRC Meeting Times)

[Daniel Kulp]

On Sep 10, 2012, at 12:32 PM, Alex Huang  wrote:

>> The main "Red Flag" to me was the line:
>> 
>> AGREED: continue using waf to build rpm package  (jlkinsel, 17:24:57)
>> 
>> As soon as I saw "AGREED", a little red flag popped up in my head wondering
>> if a decision had been made on IRC that should have been done on the list.   
>> I
>> believe this had been discussed to death on the list already (need to double
>> check, very busy list) and a quick link to show that would definitely been
>> helpful.
> 
> That's a really good point.  Here the agreement was that waf is the temporary 
> solution to continue to use to get 4.0 release out.  It's not an agreement on 
> long term direction of CloudStack.  Does it still count as a decision?  I 
> mean there's tons of these types of "decisions" made during the IRC?  For 
> example, who's going to help with what work.  Todo lists being generated.  
> Etc.  Do these all count as decisions?  


As Noah stated, it's kind of a gray area and is something you'll likely need to 
adjust as you move forward, learn what works and doesn't, etc…   A lot of it 
can depend exactly on how it's presented in the minutes/log.   If it was 
presented more like:

No one present has time to look at other options for RPM packaging right now so 
planning on sticking with waf for now.

then it wouldn't have raised any red flags to me at all.  That shows that its 
more of a "remain status quo" for now, but also allows others that were not on 
the irc chat to say "hey, I have some time, can I help out with that" or 
something.   Keeps the door open.The "AGREED" wording just seems to imply 
"we're doing this, discussion closed" type thing which really isn't the case.


-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

[jira] [Closed] (CLOUDSTACK-36) Warning while installing with RPM build [ cp: cannot stat `/usr/share/cloud/bridge/conf/hibernate.cfg.xml': No such file or directory]

[edison su (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

edison su closed CLOUDSTACK-36.
---

Resolution: Fixed

Fixed in the latest RPM

> Warning while installing with RPM build [ cp: cannot stat 
> `/usr/share/cloud/bridge/conf/hibernate.cfg.xml': No such file or directory]
> --
>
> Key: CLOUDSTACK-36
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-36
> Project: CloudStack
>  Issue Type: Bug
>  Components: Install and Setup
>Affects Versions: pre-4.0.0
>Reporter: Sailaja Mada
>Assignee: Pradeep Soundararajan
>Priority: Minor
> Fix For: pre-4.0.0
>
>
> Steps:
> Tried to Install the rpm build.
> Observation:
> [root@ms3 ASF40]# rpm -Uvh *.rpm
> Preparing...### [100%]
>1:cloud-utils### [  8%]
>2:cloud-deps ### [ 17%]
>3:cloud-core ### [ 25%]
>4:cloud-server   ### [ 33%]
>5:cloud-python   ### [ 42%]
>6:cloud-setup### [ 50%]
>7:cloud-aws-api  ### [ 58%]
>8:cloud-agent-scripts### [ 67%]
>9:cloud-client-ui### [ 75%]
>   10:cloud-client   ### [ 83%]
> cp: cannot stat `/usr/share/cloud/bridge/conf/hibernate.cfg.xml': No such 
> file or directory
>   11:cloud-agent-libs   ### [ 92%]
>   12:cloud-cli  ### [100%]
> [root@ms3 ASF40]#
> Expected Result :
> Install should proceed with no issues.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Poll (was Re: IRC Meeting Times)

[Noah Slater]

That is a much better point than I was able to come up with. Thanks Daniel!
:D

On Mon, Sep 10, 2012 at 6:29 PM, Daniel Kulp  wrote:

>
> On Sep 10, 2012, at 12:32 PM, Alex Huang  wrote:
>
> >> The main "Red Flag" to me was the line:
> >>
> >> AGREED: continue using waf to build rpm package  (jlkinsel, 17:24:57)
> >>
> >> As soon as I saw "AGREED", a little red flag popped up in my head
> wondering
> >> if a decision had been made on IRC that should have been done on the
> list.   I
> >> believe this had been discussed to death on the list already (need to
> double
> >> check, very busy list) and a quick link to show that would definitely
> been
> >> helpful.
> >
> > That's a really good point.  Here the agreement was that waf is the
> temporary solution to continue to use to get 4.0 release out.  It's not an
> agreement on long term direction of CloudStack.  Does it still count as a
> decision?  I mean there's tons of these types of "decisions" made during
> the IRC?  For example, who's going to help with what work.  Todo lists
> being generated.  Etc.  Do these all count as decisions?
>
>
> As Noah stated, it's kind of a gray area and is something you'll likely
> need to adjust as you move forward, learn what works and doesn't, etc…   A
> lot of it can depend exactly on how it's presented in the minutes/log.   If
> it was presented more like:
>
> No one present has time to look at other options for RPM packaging right
> now so planning on sticking with waf for now.
>
> then it wouldn't have raised any red flags to me at all.  That shows that
> its more of a "remain status quo" for now, but also allows others that were
> not on the irc chat to say "hey, I have some time, can I help out with
> that" or something.   Keeps the door open.The "AGREED" wording just
> seems to imply "we're doing this, discussion closed" type thing which
> really isn't the case.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>


-- 
NS

RE: Poll (was Re: IRC Meeting Times)

[Alex Huang]

> -Original Message-
> From: Daniel Kulp [mailto:dk...@apache.org]
> Sent: Monday, September 10, 2012 10:29 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Poll (was Re: IRC Meeting Times)
> 
> 
> On Sep 10, 2012, at 12:32 PM, Alex Huang  wrote:
> 
> >> The main "Red Flag" to me was the line:
> >>
> >> AGREED: continue using waf to build rpm package  (jlkinsel, 17:24:57)
> >>
> >> As soon as I saw "AGREED", a little red flag popped up in my head
> wondering
> >> if a decision had been made on IRC that should have been done on the list.
> I
> >> believe this had been discussed to death on the list already (need to
> >> double check, very busy list) and a quick link to show that would
> >> definitely been helpful.
> >
> > That's a really good point.  Here the agreement was that waf is the
> temporary solution to continue to use to get 4.0 release out.  It's not an
> agreement on long term direction of CloudStack.  Does it still count as a
> decision?  I mean there's tons of these types of "decisions" made during the
> IRC?  For example, who's going to help with what work.  Todo lists being
> generated.  Etc.  Do these all count as decisions?
> 
> 
> As Noah stated, it's kind of a gray area and is something you'll likely need 
> to
> adjust as you move forward, learn what works and doesn't, etc...   A lot of it
> can depend exactly on how it's presented in the minutes/log.   If it was
> presented more like:
> 
> No one present has time to look at other options for RPM packaging right
> now so planning on sticking with waf for now.
> 
> then it wouldn't have raised any red flags to me at all.  That shows that its
> more of a "remain status quo" for now, but also allows others that were not
> on the irc chat to say "hey, I have some time, can I help out with that" or
> something.   Keeps the door open.The "AGREED" wording just seems to
> imply "we're doing this, discussion closed" type thing which really isn't the
> case.
> 

OK.  That makes it very clear.  Thanks, Daniel.  I thought it might have just 
been the wording on that statement and it's good to get a confirmation.

--Alex

Re: Review Request: apache 4.0 docs

[Chiradeep Vittal]

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


Autoscale is not in 4.0

- Chiradeep Vittal


On Sept. 10, 2012, 10:21 a.m., Radhika PC wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6978/
> ---
> 
> (Updated Sept. 10, 2012, 10:21 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Description
> ---
> 
> This patch includes defect fixes and the new feature documentation: 
> site-to-site vpn, inter-vlan routing, and autoscale. The issues pointed out 
> for the Review Request #6328 has also been fixed. Updated the ASF license 
> header for other files.
> 
> 
> Diffs
> -
> 
>   docs/en-US/Book_Info_Admin.xml PRE-CREATION 
>   docs/en-US/LDAPserver-for-user-authentication.xml 5fcb300 
>   docs/en-US/about-clusters.xml e328cba 
>   docs/en-US/about-hosts.xml 956c695 
>   docs/en-US/about-physical-networks.xml 8edb9e0 
>   docs/en-US/about-pods.xml ed3520c 
>   docs/en-US/about-primary-storage.xml 68d7a25 
>   docs/en-US/about-secondary-storage.xml c4df0b8 
>   docs/en-US/about-security-groups.xml PRE-CREATION 
>   docs/en-US/about-virtual-networks.xml 2fc6ba9 
>   docs/en-US/about-working-with-vms.xml 47153e2 
>   docs/en-US/about-zones.xml a05a9a6 
>   docs/en-US/accessing-vms.xml d69d021 
>   docs/en-US/accounts-users-domains.xml 8549129 
>   docs/en-US/accounts.xml 5292a9c 
>   docs/en-US/acquire-new-ip-for-vpc.xml PRE-CREATION 
>   docs/en-US/add-additional-guest-network.xml 57e7ffd 
>   docs/en-US/add-clusters-kvm-xenserver.xml PRE-CREATION 
>   docs/en-US/add-clusters-ovm.xml PRE-CREATION 
>   docs/en-US/add-clusters-vsphere.xml PRE-CREATION 
>   docs/en-US/add-gateway-vpc.xml PRE-CREATION 
>   docs/en-US/add-ingress-egress-rules.xml 964045f 
>   docs/en-US/add-iso.xml f56d10c 
>   docs/en-US/add-load-balancer-rule.xml ddbce95 
>   docs/en-US/add-loadbalancer-rule-vpc.xml PRE-CREATION 
>   docs/en-US/add-more-clusters.xml PRE-CREATION 
>   docs/en-US/add-portforward-rule-vpc.xml PRE-CREATION 
>   docs/en-US/add-primary-storage.xml PRE-CREATION 
>   docs/en-US/add-secondary-storage.xml PRE-CREATION 
>   docs/en-US/add-security-group.xml e4c8b3c 
>   docs/en-US/add-tier.xml PRE-CREATION 
>   docs/en-US/add-vm-to-tier.xml PRE-CREATION 
>   docs/en-US/add-vpc.xml PRE-CREATION 
>   docs/en-US/advanced-zone-configuration.xml 85909e3 
>   docs/en-US/advanced-zone-guest-ip-addresses.xml b5d10a0 
>   docs/en-US/advanced-zone-network-traffic-types.xml 9f475cf 
>   docs/en-US/advanced-zone-physical-network-configuration.xml 4c44c7d 
>   docs/en-US/advanced-zone-public-ip-addresses.xml eeb9404 
>   docs/en-US/alerts.xml f903023 
>   docs/en-US/api-overview.xml PRE-CREATION 
>   docs/en-US/attach-iso-to-vm.xml 30e5d51 
>   docs/en-US/automatic-snapshot-creation-retention.xml ee4cf73 
>   docs/en-US/autoscale.xml PRE-CREATION 
>   docs/en-US/basic-zone-configuration.xml 18afa84 
>   docs/en-US/basic-zone-guest-ip-addresses.xml d1d9135 
>   docs/en-US/basic-zone-network-traffic-types.xml fa3be0f 
>   docs/en-US/basic-zone-physical-network-configuration.xml 83833a7 
>   docs/en-US/best-practices-for-vms.xml a67add4 
>   docs/en-US/change-database-config.xml PRE-CREATION 
>   docs/en-US/change-network-offering-on-guest-network.xml 98f1b63 
>   docs/en-US/change-ssvm-service-offering.xml PRE-CREATION 
>   docs/en-US/changing-root-password.xml 0d2333a 
>   docs/en-US/changing-secondary-storage-ip.xml 7e146de 
>   docs/en-US/changing-service-offering-for-vm.xml 5a42912 
>   docs/en-US/changing-vm-name-os-group.xml f16ffda 
>   docs/en-US/cloud-infrastructure-concepts.xml 58f8844 
>   docs/en-US/cloud-infrastructure-overview.xml 5b467a3 
>   docs/en-US/cloudstack_admin.xml c80c94f 
>   docs/en-US/cluster-add-xenserver-kvm.xml PRE-CREATION 
>   docs/en-US/cluster-add.xml 5210bd8 
>   docs/en-US/compute-disk-service-offerings.xml 2469dfe 
>   docs/en-US/concepts.xml 1912c23 
>   docs/en-US/configure-acl.xml PRE-CREATION 
>   docs/en-US/configure-guest-traffic-in-advanced-zone.xml 95df473 
>   docs/en-US/configure-snmp-rhel.xml PRE-CREATION 
>   docs/en-US/configure-usage-server.xml d167a49 
>   docs/en-US/configure-vpc.xml PRE-CREATION 
>   docs/en-US/configure-vpn.xml 9e059f7 
>   docs/en-US/console-proxy.xml df29c42 
>   docs/en-US/convert-hyperv-vm-to-template.xml c6294d4 
>   docs/en-US/create-template-from-existing-vm.xml c22b7ec 
>   docs/en-US/create-template-from-snapshot.xml 3075032 
>   docs/en-US/create-templates-overview.xml 818b42d 
>   docs/en-US/create-vpn-connection-vpc.xml PRE-CREATION 
>   docs/en-US/create-vpn-customer-gateway.xml PRE-CREATION 
>   docs/en-US/create-vpn-gateway-for-vpc.xml PRE-CREATION 
>   docs/en-US/create-vr-network-offering.xml PR

Re: Need detail cloudstack networking document ???

[Chiradeep Vittal]

Have you checked http://docs.cloudstack.org/CloudStack_Documentation

On 9/10/12 12:53 AM, "Nguyễn Đình Việt"  wrote:

>Hi guy,
>
>I can not find any document that describe detail about cloudstack
>networking
>(architecture, description, function of networking offering... on GUI).
>Can u
>send me ?
>
>Thanks and bestregards!

RE: cleaning up patch disks

[Edison Su]

> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Sunday, September 09, 2012 9:32 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: cleaning up patch disks
> 
> I've got an issue with the CLVM on KVM support, it seems that the
> patch disks are created on the fly when a system VM is started. If I
> reboot a system VM 5 times I'll end up with 5 patch disks. I'm the one
> who submitted the CLVM patch, and I don't see that there's much
> difference between what we're doing with CLVM and what it does for
> everything else, so I thought I'd ask:
> 
> Is this an issue for other backing stores as well (accumulating patch
> disks for system VMs)? If not where is it handled?


It's a bug, that patch disks are not cleaned up after system vm got stopped.

> 
> Any suggestions on how to go about fixing it? I see I could
> potentially hack into StopCommand, rebootVM/cleanupVM/stopVM, detect
> the patch disk and lvremove it, but then again if it doesn't go down
> on purpose (say a host crash) I'll still be leaking patch disks.
> 
> Is it safe to assume that any patch disk that's not currently open is
> safe to delete (these are generated on the fly and not really tracked
> anywhere in the database, right?)

If it's created on shared storage shared by multiple KVM hosts, then it's not 
easy to know, this patch disk is opened or not.
Normally, we can delete that patch disk for every 
stopcommand/stopvm/rebootvm/cleanupvm command.
If host is crashed, CS manager will send a command to other hosts in the 
cluster to clean up the VM, so we have the chance to clean up the patch disk 
anyway.
As you said in another mail, we can use the name schema: vm-name-patch-disk for 
patch disk. 
Patch are welcome!

Re: Review Request: CLOUDSTACK-10:Deleting a disconnected primary storage results in partial removed state

[edison su]

> On Sept. 10, 2012, 5:10 p.m., Alena Prokharchyk wrote:
> > With the current implementation the pool has to be marked as removed prior 
> > to starting the removal process. Otherwise it makes it available for new 
> > volumes creation while the pool is going through removing stage.
> > 
> > The correct fix would be:
> > 
> > * introduce the "state" field for the storage pool. Having 3 values for 
> > this state should be sufficient enough by now: Created, Removing, Removed. 
> > Created would be the initial state
> > * when delete is called for the storage pool, update the pool with Removing 
> > state, don't update the Removed field yet. Check all the cloudStack storage 
> > operations to ensure that the storage pool in Removing state can't be used 
> > for any operations requiring storage access
> > * After the removal is successful, update state to Removed, and set Removed 
> > field to not null date value.
> > 
> > Also make sure that:
> > 
> > * deleteStorage api can be called on the storage pool with Removing state. 
> > * better introduce state machine for storage state management, it will make 
> > code more readable.

Hold on for a while, it will be fixed in the new storage code.


- edison


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


On Sept. 4, 2012, 3:10 p.m., Gavin Lee wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6900/
> ---
> 
> (Updated Sept. 4, 2012, 3:10 p.m.)
> 
> 
> Review request for cloudstack and Alena Prokharchyk.
> 
> 
> Description
> ---
> 
> Keep the remove operation transactional which avoid partial updated when 
> exception occurs.
> 
> 
> This addresses bug CLOUDSTACK-10.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/storage/StorageManagerImpl.java 50a78db 
> 
> Diff: https://reviews.apache.org/r/6900/diff/
> 
> 
> Testing
> ---
> 
> tested and verified the fix works correctly.
> 
> 
> Thanks,
> 
> Gavin Lee
> 
>

Re: cleaning up patch disks

[Marcus Sorensen]

thanks, so this affects all hypervisors/storage backends that use the
patch disk, or should I code my solution specific to KVM?

On Mon, Sep 10, 2012 at 11:43 AM, Edison Su  wrote:
>
>
>> -Original Message-
>> From: Marcus Sorensen [mailto:shadow...@gmail.com]
>> Sent: Sunday, September 09, 2012 9:32 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: cleaning up patch disks
>>
>> I've got an issue with the CLVM on KVM support, it seems that the
>> patch disks are created on the fly when a system VM is started. If I
>> reboot a system VM 5 times I'll end up with 5 patch disks. I'm the one
>> who submitted the CLVM patch, and I don't see that there's much
>> difference between what we're doing with CLVM and what it does for
>> everything else, so I thought I'd ask:
>>
>> Is this an issue for other backing stores as well (accumulating patch
>> disks for system VMs)? If not where is it handled?
>
>
> It's a bug, that patch disks are not cleaned up after system vm got stopped.
>
>>
>> Any suggestions on how to go about fixing it? I see I could
>> potentially hack into StopCommand, rebootVM/cleanupVM/stopVM, detect
>> the patch disk and lvremove it, but then again if it doesn't go down
>> on purpose (say a host crash) I'll still be leaking patch disks.
>>
>> Is it safe to assume that any patch disk that's not currently open is
>> safe to delete (these are generated on the fly and not really tracked
>> anywhere in the database, right?)
>
> If it's created on shared storage shared by multiple KVM hosts, then it's not 
> easy to know, this patch disk is opened or not.
> Normally, we can delete that patch disk for every 
> stopcommand/stopvm/rebootvm/cleanupvm command.
> If host is crashed, CS manager will send a command to other hosts in the 
> cluster to clean up the VM, so we have the chance to clean up the patch disk 
> anyway.
> As you said in another mail, we can use the name schema: vm-name-patch-disk 
> for patch disk.
> Patch are welcome!
>

RE: VM instance cannot aquire IP via DHCP when run on other host with Virtual Router/??????

[Anthony Xu]

Sounds like a VLAN configuration issue in physical switch, the switch drops 
VLAN package.
Port may need to be configured as VLAN trunk.

Anthony

-Original Message-
From: viet...@viettel.com.vn [mailto:viet...@viettel.com.vn] 
Sent: Monday, September 10, 2012 3:52 AM
To: cloudstack-dev@incubator.apache.org
Subject: RE: VM instance cannot aquire IP via DHCP when run on other host with 
Virtual Router/??

Hi guy,
My network is divided VLAN and CS server (MS, hosts) belong to the same special 
VLAN. All host and MS are pluged into the same physical switch and this switch 
use a hub (plug and play, not create VLAN). But when I create Cloudstack 
advance zone, I don't define VLAN ID in Public Traffic create step because I 
think all host and MS in the same vlan and physical switch then they can 
communicate normaly. This can affect the problem that I'm having? VLAN ID in 
Public Traffic create step is required in VLAN network environment?


-Original Message-
From: viet...@viettel.com.vn [mailto:viet...@viettel.com.vn] 
Sent: Monday, September 10, 2012 2:53 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: VM instance cannot aquire IP via DHCP when run on other host with 
Virtual Router/??


Hi guy,
I  try creating many VMs from other templates included: Ubuntu, CentOS, Windows 
2k with the same scerano then i have the same result too. When I migrate XP VM 
from host 1 to host 2 then it can obtain IP address from VR and can not  obtain 
IP address when I migrate it back to host 1.




Thanks & Best Regards.


-Original Message-
From: srivatsav.prasa...@gmail.com [mailto:srivatsav.prasa...@gmail.com] On 
Behalf Of prasanna
Sent: Sunday, September 09, 2012 8:07 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: VM instance cannot aquire IP via DHCP when run on other host with 
Virtual Router/??

On 8 September 2012 09:58, Nguyễn Đình Việt  wrote:
> Hi,
> I run 2 VM on 2 different hosts (VM XP run on host 1, VM hyperv run on host 
> 2, and VR running on host 2, VR's ip address is 10.1.1.1. All host running on 
> the same VLAN), only VM hyperv obtained IP address from VR.  This is result 
> in /var/log/message on VR:
>

Can you try and deploy the HyperV VM on both hosts? If the VMs (one on
VR host and one on different host) from the same template don't get
DHCPed you have to check your VLANs. If not there could be a problem
with the template. Is your XP template sysprepped?


> Sep  8 04:12:13 r-468-VM cloud: edithosts: update 02:00:27:b0:00:35 10.1.1.90 
> XP to hosts
> Sep  8 04:12:13 r-468-VM cloud: /root/edithosts.sh: setting default router 
> for 10.1.1.90 to 10.1.1.1
> Sep  8 04:12:13 r-468-VM cloud: /root/edithosts.sh: setting dns server for 
> 10.1.1.90 to 10.1.1.1
> Sep  8 04:12:44 r-468-VM cloud: edithosts: update 02:00:04:d3:00:3a 
> 10.1.1.107 hyperv to hosts
> Sep  8 04:12:44 r-468-VM cloud: /root/edithosts.sh: setting default router 
> for 10.1.1.107 to 10.1.1.1
> Sep  8 04:12:44 r-468-VM cloud: /root/edithosts.sh: setting dns server for 
> 10.1.1.107 to 10.1.1.1
>

> When I use renew ip address command on VM XP (run on host 1, other with VR)  
> and tcpdump command on VR then I don't receive any DHCP packet from VM XP.

Hmm - It looks like both the VMs have been given IPs by cloudstack -
10.1.1.107 and 10.1.1.90. Okay - it could be a problem with the XP
template. Are you able to get IPs for templates other than XP with the
same scenario?

RE: cleaning up patch disks

[Edison Su]

> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Monday, September 10, 2012 10:49 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: cleaning up patch disks
> 
> thanks, so this affects all hypervisors/storage backends that use the
> patch disk, or should I code my solution specific to KVM?

It's only for KVM.

> 
> On Mon, Sep 10, 2012 at 11:43 AM, Edison Su 
> wrote:
> >
> >
> >> -Original Message-
> >> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> >> Sent: Sunday, September 09, 2012 9:32 PM
> >> To: cloudstack-dev@incubator.apache.org
> >> Subject: cleaning up patch disks
> >>
> >> I've got an issue with the CLVM on KVM support, it seems that the
> >> patch disks are created on the fly when a system VM is started. If I
> >> reboot a system VM 5 times I'll end up with 5 patch disks. I'm the
> one
> >> who submitted the CLVM patch, and I don't see that there's much
> >> difference between what we're doing with CLVM and what it does for
> >> everything else, so I thought I'd ask:
> >>
> >> Is this an issue for other backing stores as well (accumulating
> patch
> >> disks for system VMs)? If not where is it handled?
> >
> >
> > It's a bug, that patch disks are not cleaned up after system vm got
> stopped.
> >
> >>
> >> Any suggestions on how to go about fixing it? I see I could
> >> potentially hack into StopCommand, rebootVM/cleanupVM/stopVM, detect
> >> the patch disk and lvremove it, but then again if it doesn't go down
> >> on purpose (say a host crash) I'll still be leaking patch disks.
> >>
> >> Is it safe to assume that any patch disk that's not currently open
> is
> >> safe to delete (these are generated on the fly and not really
> tracked
> >> anywhere in the database, right?)
> >
> > If it's created on shared storage shared by multiple KVM hosts, then
> it's not easy to know, this patch disk is opened or not.
> > Normally, we can delete that patch disk for every
> stopcommand/stopvm/rebootvm/cleanupvm command.
> > If host is crashed, CS manager will send a command to other hosts in
> the cluster to clean up the VM, so we have the chance to clean up the
> patch disk anyway.
> > As you said in another mail, we can use the name schema: vm-name-
> patch-disk for patch disk.
> > Patch are welcome!
> >

Help needed with Maven

[Chip Childers]

Hi all,

So I ended up deleting all of the contents of the
deps/awsapi-lib/rampart folder, but we need the previous contents to
be bundled as part of the build process.  I'm almost there, but I've
gotten myself stuck and I need help from someone who knows Maven a bit
better than I do.

We need to get the rahas-1.5.mar and rampart-1.5.mar files into
deps/awsapi-lib/modules for things like "ant deploy-server" to work.
To that end, I'm adding the following dependencies to the awsapi pom:


  com.apache.rampart
  rahas
  1.5
  mar


  com.apache.rampart
  rampart
  1.5
  mar


When I run mvn -U -P awsapi, I get this error at the end:

[ERROR] Failed to execute goal on project cloud-awsapi: Could not
resolve dependencies for project
org.apache.cloudstack:cloud-awsapi:jar:4.0.0-SNAPSHOT: The following
artifacts could not be resolved: com.apache.rampart:rahas:mar:1.5,
com.apache.rampart:rampart:mar:1.5: Could not find artifact
com.apache.rampart:rahas:mar:1.5 in central
(http://repo1.maven.org/maven2) -> [Help 1]

My confusion is that I can find the artifacts that we need on
http://search.maven.org/ with no problems!  I've tried removing the
"mar" type, but that doesn't work either.

Any advice?

-chip

Re: List of New Features in 4.0

[Chip Childers]

Moved to the dev list:

On Mon, Sep 10, 2012 at 2:22 PM, Vijay Venkatachalam
 wrote:
> For Autoscale feature, the re-licensing of NetScaler SDK Jar is held up in 
> the Citrix legal :-( , and meanwhile, can I send patches with the latest 
> NetScaler jar files
> (still without the new license) to the autoscale branch alone (not master)?  
> We have about 10 pending patches waiting for inclusion.

There are 2 issues with that.

First, we are moving ALL jar / mar / war files out of the code repo,
so please don't try to put one back in (even on a branch).

The second issue is that we should not be moving backwards on the
state of our licensing compliance.  If the NetScaler jar is still a
non-Apache 2 compatible license (per ASF standards on this), then it
needs to be thought of as an optional build target.  We need to be
able have an optional build flag to include it after the user
downloads the file manually somehow (probably the same way we do
others like this:  install-non-oss.sh ).

-chip

> I haven't checked the 4.0 code, but it seems that all NetScaler support is 
> removed from 4.0 master (besides autoscale), Am I right here? Is this pending 
> the NetScaler SDK jar re-licensing?
>
> Thanks,
> Vijay V.
>
>> -Original Message-
>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>> Sent: Monday, September 10, 2012 10:53 PM
>> To: CloudStack Users
>> Subject: Re: List of New Features in 4.0
>>
>> Autoscaling is still pending a merge and is unlikely to make it into 4.0.
>>
>> On 9/10/12 9:49 AM, "Shanker Balan"  wrote:
>>
>> >On 10-Sep-2012, at 8:10 PM, James Jeffrey 
>> wrote:
>> >
>> >> Hello,
>> >>
>> >> Sorry if it already exists - I've looked but failed to find. Is there
>> >>a list of new features in 4.0 please?
>> >>
>> >
>> >AFAIK, the 2 significant features are VPC and autoscaling. Maybe the
>> >release manager(s) can comment further.
>> >
>> >Hth
>> >@shankerbalan
>> >
>
>

Re: RE: VM instance cannot aquire IP via DHCP when run on other host with Virtual Router/??????

[VietNd4]

oh. i don't think so. because all my hosts and Management server are configured 
in the same VLAN, they can access  normaly to internet or other vlan. And my 
problem is when VMs run on other host with VR then they can not acquire IP 
address from VR, VMs run on the same with VR work fine.

Is it any attention when setting up advance networking in the VLAN environment? 
I have tried many times and this problem always repeats. Have you any idea for 
my problem ? .Thanks

- Original Message -
From: Anthony Xu 
Date: Tuesday, September 11, 2012 1:07 am
Subject: RE: VM instance cannot aquire IP via DHCP when run on other host with 
Virtual Router/??

> Sounds like a VLAN configuration issue in physical switch, the 
> switch drops VLAN package.
> Port may need to be configured as VLAN trunk.
> 
> Anthony
> 
> -Original Message-
> From: viet...@viettel.com.vn [mailto:viet...@viettel.com.vn] 
> Sent: Monday, September 10, 2012 3:52 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: VM instance cannot aquire IP via DHCP when run on 
> other host with Virtual Router/??
> 
> Hi guy,
> My network is divided VLAN and CS server (MS, hosts) belong to the 
> same special VLAN. All host and MS are pluged into the same 
> physical switch and this switch use a hub (plug and play, not 
> create VLAN). But when I create Cloudstack advance zone, I don't 
> define VLAN ID in Public Traffic create step because I think all 
> host and MS in the same vlan and physical switch then they can 
> communicate normaly. This can affect the problem that I'm having? 
> VLAN ID in Public Traffic create step is required in VLAN network 
> environment?
> 
> -Original Message-
> From: viet...@viettel.com.vn [mailto:viet...@viettel.com.vn] 
> Sent: Monday, September 10, 2012 2:53 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: VM instance cannot aquire IP via DHCP when run on 
> other host with Virtual Router/??
> 
> 
> Hi guy,
> I  try creating many VMs from other templates included: Ubuntu, 
> CentOS, Windows 2k with the same scerano then i have the same 
> result too. When I migrate XP VM from host 1 to host 2 then it can 
> obtain IP address from VR and can not  obtain IP address when I 
> migrate it back to host 1.
> 
> 
> 
> 
> Thanks & Best Regards.
> 
> 
> -Original Message-
> From: srivatsav.prasa...@gmail.com 
> [mailto:srivatsav.prasa...@gmail.com] On Behalf Of prasanna
> Sent: Sunday, September 09, 2012 8:07 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: VM instance cannot aquire IP via DHCP when run on 
> other host with Virtual Router/??
> 
> On 8 September 2012 09:58, Nguyễn Đình Việt 
>  wrote:
> > Hi,
> > I run 2 VM on 2 different hosts (VM XP run on host 1, VM hyperv 
> run on host 2, and VR running on host 2, VR's ip address is 
> 10.1.1.1. All host running on the same VLAN), only VM hyperv 
> obtained IP address from VR.  This is result in /var/log/message on 
> VR:>
> 
> Can you try and deploy the HyperV VM on both hosts? If the VMs (one on
> VR host and one on different host) from the same template don't get
> DHCPed you have to check your VLANs. If not there could be a problem
> with the template. Is your XP template sysprepped?
> 
> 
> > Sep  8 04:12:13 r-468-VM cloud: edithosts: update 
> 02:00:27:b0:00:35 10.1.1.90 XP to hosts
> > Sep  8 04:12:13 r-468-VM cloud: /root/edithosts.sh: setting 
> default router for 10.1.1.90 to 10.1.1.1
> > Sep  8 04:12:13 r-468-VM cloud: /root/edithosts.sh: setting dns 
> server for 10.1.1.90 to 10.1.1.1
> > Sep  8 04:12:44 r-468-VM cloud: edithosts: update 
> 02:00:04:d3:00:3a 10.1.1.107 hyperv to hosts
> > Sep  8 04:12:44 r-468-VM cloud: /root/edithosts.sh: setting 
> default router for 10.1.1.107 to 10.1.1.1
> > Sep  8 04:12:44 r-468-VM cloud: /root/edithosts.sh: setting dns 
> server for 10.1.1.107 to 10.1.1.1
> >
> 
> > When I use renew ip address command on VM XP (run on host 1, 
> other with VR)  and tcpdump command on VR then I don't receive any 
> DHCP packet from VM XP.
> 
> Hmm - It looks like both the VMs have been given IPs by cloudstack -
> 10.1.1.107 and 10.1.1.90. Okay - it could be a problem with the XP
> template. Are you able to get IPs for templates other than XP with the
> same scenario?
>

RE: List of New Features in 4.0

[Alex Huang]

Hi,

I've put together a high level release page so everyone can get information.  
Please add and edit as you see fit.  See [1].

--Alex

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.0+Release