date:20120919

Did he say which distribution? I recently submitted a fix for cent 6.3, it
wasn't setting up the cgconfig service.

I second drumming cloud-setup-agent. If you look at the management server
log you should see the exact command/arcs being sent to the host. Copy that
and run it manually to see where it fails.
On Sep 19, 2012 12:23 AM, Kelcey Jamison-Damage kel...@bbits.ca wrote:

 Have you tried running cloud-setup-agent on the host? If so what is its
 output?

 Are you building 3.0.2 or 4.0 source?



 Busy Dev busyd...@gmail.com wrote:

 Thanks - I checked my KVM host and that directory already exists.
 
 
 
 On Wed, Sep 19, 2012 at 1:07 AM, KAWAI Hiroaki ka...@stratosphere.co.jp
 wrote:
 
  Hi,
  I run into the same problem. On KVM host OS, try:
 
  mkdir /var/lib/libvirt/images/
 
  logging will be added with patch https://reviews.apache.org/r/**7153/
 https://reviews.apache.org/r/7153/
 
 
 
  (2012/09/19 14:00), Busy Dev wrote:
 
  I've been able to setup my development environment and am now trying to
  setup the management server.  However, when I launch Cloudstack, I am
  unable to add a KVM host.
 
  The error in the log file
 
  2012-09-19 00:50:48,883 INFO  [utils.component.**ComponentLocator]
  (main:null) Unable to find components.xml
  2012-09-19 00:50:48,884 INFO  [utils.component.**ComponentLocator]
  (main:null) Skipping configuration using components.xml
  2012-09-19 00:50:48,885 INFO  [cloud.agent.AgentShell] (main:null)
  Implementation Version is 4.0.0.48.20120918191610
  2012-09-19 00:50:48,885 INFO  [cloud.agent.AgentShell] (main:null)
  agent.properties found at /etc/cloud/agent/agent.**properties
  2012-09-19 00:50:48,886 INFO  [cloud.agent.AgentShell] (main:null)
  Defaulting to using properties file for storage
  2012-09-19 00:50:48,888 INFO  [cloud.agent.AgentShell] (main:null)
  Defaulting to the constant time backoff algorithm
  2012-09-19 00:50:48,949 INFO  [cloud.agent.Agent] (main:null) id is
  2012-09-19 00:50:49,055 INFO
[resource.virtualnetwork.**VirtualRoutingResource] (main:null)
  VirtualRoutingResource _scriptDir to use: scripts/network/domr/kvm
  2012-09-19 00:50:50,048 INFO  [kvm.resource.**LibvirtComputingResource]
  (main:null) No libvirt.vif.driver specififed. Defaults to
 BridgeVifDriver.
  2012-09-19 00:50:50,080 INFO  [cloud.agent.Agent] (main:null) Agent
 [id =
  new : type = LibvirtComputingResource : zone = 1 : pod = 1 : workers =
 5 :
  host = 192.168.1.8 : port = 8250
  2012-09-19 00:50:50,093 INFO  [utils.nio.NioClient]
 (Agent-Selector:null)
  Connecting to 192.168.1.8:8250
  2012-09-19 00:50:50,285 INFO  [utils.nio.NioClient]
 (Agent-Selector:null)
  SSL: Handshake done
  2012-09-19 00:50:50,635 WARN  [utils.nio.Task] (Agent-Handler-1:null)
  Caught the following exception but pushing on
  java.lang.NullPointerException
   at
  com.cloud.hypervisor.kvm.**storage.LibvirtStorageAdaptor.**
  createStoragePool(**LibvirtStorageAdaptor.java:**562)
   at
  com.cloud.hypervisor.kvm.**storage.KVMStoragePoolManager.**
  createStoragePool(**KVMStoragePoolManager.java:57)
   at
  com.cloud.hypervisor.kvm.**resource.**LibvirtComputingResource.**
  initialize(**LibvirtComputingResource.java:**3243)
   at com.cloud.agent.Agent.**sendStartup(Agent.java:320)
   at com.cloud.agent.Agent$**ServerHandler.doTask(Agent.**
  java:850)
   at com.cloud.utils.nio.Task.run(**Task.java:83)
   at
  java.util.concurrent.**ThreadPoolExecutor.runWorker(**
  ThreadPoolExecutor.java:1110)
   at
  java.util.concurrent.**ThreadPoolExecutor$Worker.run(**
  ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.**java:679)
 
 
  Thanks for your help.

Re: Still cannot add KVM host

Drumming? I meant running!
On Sep 19, 2012 12:49 AM, Marcus Sorensen shadow...@gmail.com wrote:

 Did he say which distribution? I recently submitted a fix for cent 6.3, it
 wasn't setting up the cgconfig service.

 I second drumming cloud-setup-agent. If you look at the management server
 log you should see the exact command/arcs being sent to the host. Copy that
 and run it manually to see where it fails.
 On Sep 19, 2012 12:23 AM, Kelcey Jamison-Damage kel...@bbits.ca wrote:

 Have you tried running cloud-setup-agent on the host? If so what is its
 output?

 Are you building 3.0.2 or 4.0 source?



 Busy Dev busyd...@gmail.com wrote:

 Thanks - I checked my KVM host and that directory already exists.
 
 
 
 On Wed, Sep 19, 2012 at 1:07 AM, KAWAI Hiroaki ka...@stratosphere.co.jp
 wrote:
 
  Hi,
  I run into the same problem. On KVM host OS, try:
 
  mkdir /var/lib/libvirt/images/
 
  logging will be added with patch https://reviews.apache.org/r/**7153/
 https://reviews.apache.org/r/7153/
 
 
 
  (2012/09/19 14:00), Busy Dev wrote:
 
  I've been able to setup my development environment and am now trying
 to
  setup the management server.  However, when I launch Cloudstack, I
 am
  unable to add a KVM host.
 
  The error in the log file
 
  2012-09-19 00:50:48,883 INFO  [utils.component.**ComponentLocator]
  (main:null) Unable to find components.xml
  2012-09-19 00:50:48,884 INFO  [utils.component.**ComponentLocator]
  (main:null) Skipping configuration using components.xml
  2012-09-19 00:50:48,885 INFO  [cloud.agent.AgentShell] (main:null)
  Implementation Version is 4.0.0.48.20120918191610
  2012-09-19 00:50:48,885 INFO  [cloud.agent.AgentShell] (main:null)
  agent.properties found at /etc/cloud/agent/agent.**properties
  2012-09-19 00:50:48,886 INFO  [cloud.agent.AgentShell] (main:null)
  Defaulting to using properties file for storage
  2012-09-19 00:50:48,888 INFO  [cloud.agent.AgentShell] (main:null)
  Defaulting to the constant time backoff algorithm
  2012-09-19 00:50:48,949 INFO  [cloud.agent.Agent] (main:null) id is
  2012-09-19 00:50:49,055 INFO
[resource.virtualnetwork.**VirtualRoutingResource] (main:null)
  VirtualRoutingResource _scriptDir to use: scripts/network/domr/kvm
  2012-09-19 00:50:50,048 INFO
  [kvm.resource.**LibvirtComputingResource]
  (main:null) No libvirt.vif.driver specififed. Defaults to
 BridgeVifDriver.
  2012-09-19 00:50:50,080 INFO  [cloud.agent.Agent] (main:null) Agent
 [id =
  new : type = LibvirtComputingResource : zone = 1 : pod = 1 : workers
 = 5 :
  host = 192.168.1.8 : port = 8250
  2012-09-19 00:50:50,093 INFO  [utils.nio.NioClient]
 (Agent-Selector:null)
  Connecting to 192.168.1.8:8250
  2012-09-19 00:50:50,285 INFO  [utils.nio.NioClient]
 (Agent-Selector:null)
  SSL: Handshake done
  2012-09-19 00:50:50,635 WARN  [utils.nio.Task] (Agent-Handler-1:null)
  Caught the following exception but pushing on
  java.lang.NullPointerException
   at
  com.cloud.hypervisor.kvm.**storage.LibvirtStorageAdaptor.**
  createStoragePool(**LibvirtStorageAdaptor.java:**562)
   at
  com.cloud.hypervisor.kvm.**storage.KVMStoragePoolManager.**
  createStoragePool(**KVMStoragePoolManager.java:57)
   at
  com.cloud.hypervisor.kvm.**resource.**LibvirtComputingResource.**
  initialize(**LibvirtComputingResource.java:**3243)
   at com.cloud.agent.Agent.**sendStartup(Agent.java:320)
   at com.cloud.agent.Agent$**ServerHandler.doTask(Agent.**
  java:850)
   at com.cloud.utils.nio.Task.run(**Task.java:83)
   at
  java.util.concurrent.**ThreadPoolExecutor.runWorker(**
  ThreadPoolExecutor.java:1110)
   at
  java.util.concurrent.**ThreadPoolExecutor$Worker.run(**
  ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.**java:679)
 
 
  Thanks for your help.

Re: Still cannot add KVM host

2012-09-19 Thread Wido den Hollander




On 19-09-12 09:00, Kelceydamage@bbits wrote:

Nah, I think drumming works better.

But yeah, no mention was made of which host os is in use. I'm kind of guessing 
Ubuntu.



I still have to fix the docs regarding this.

Recently I've changed some behaviour of the Agent since it was writing 
to agent.properties.


cloud-setup-agent needs to be tuned down as well since it shouldn't 
touch any network settings.


If you look at the recent Jenkins jobs for building docs you can see 
updated docs for preparing a hypervisor, but adding the Agent itself 
hasn't been covered yet.


All that has to happen is populate a correct agent.properties and 
everything will work afterwards, this is what cloud-setup-agent will 
also do.


For now, put these lines in your agent.properties:

guest.network.device=vlanbr672
private.network.device=vlanbr670
public.network.device=vlanbr672
resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource
guid=RANDOM UUID
zone=1
pod=1
cluster=1
local.storage.uuid=RANDOM UUID
domr.scripts.dir=scripts/network/domr/kvm

Just generate a UUID for the guid and local storage and start the agent 
afterwards.


Make sure the network labels match your labels configured inside the 
management server.


Wido


Sent from my iPhone

On Sep 18, 2012, at 11:50 PM, Marcus Sorensen shadow...@gmail.com wrote:


Drumming? I meant running!
On Sep 19, 2012 12:49 AM, Marcus Sorensen shadow...@gmail.com wrote:


Did he say which distribution? I recently submitted a fix for cent 6.3, it
wasn't setting up the cgconfig service.

I second drumming cloud-setup-agent. If you look at the management server
log you should see the exact command/arcs being sent to the host. Copy that
and run it manually to see where it fails.
On Sep 19, 2012 12:23 AM, Kelcey Jamison-Damage kel...@bbits.ca wrote:


Have you tried running cloud-setup-agent on the host? If so what is its
output?

Are you building 3.0.2 or 4.0 source?



Busy Dev busyd...@gmail.com wrote:


Thanks - I checked my KVM host and that directory already exists.



On Wed, Sep 19, 2012 at 1:07 AM, KAWAI Hiroaki ka...@stratosphere.co.jp
wrote:


Hi,
I run into the same problem. On KVM host OS, try:

mkdir /var/lib/libvirt/images/

logging will be added with patch https://reviews.apache.org/r/**7153/

https://reviews.apache.org/r/7153/




(2012/09/19 14:00), Busy Dev wrote:


I've been able to setup my development environment and am now trying

to

setup the management server.  However, when I launch Cloudstack, I

am

unable to add a KVM host.

The error in the log file

2012-09-19 00:50:48,883 INFO  [utils.component.**ComponentLocator]
(main:null) Unable to find components.xml
2012-09-19 00:50:48,884 INFO  [utils.component.**ComponentLocator]
(main:null) Skipping configuration using components.xml
2012-09-19 00:50:48,885 INFO  [cloud.agent.AgentShell] (main:null)
Implementation Version is 4.0.0.48.20120918191610
2012-09-19 00:50:48,885 INFO  [cloud.agent.AgentShell] (main:null)
agent.properties found at /etc/cloud/agent/agent.**properties
2012-09-19 00:50:48,886 INFO  [cloud.agent.AgentShell] (main:null)
Defaulting to using properties file for storage
2012-09-19 00:50:48,888 INFO  [cloud.agent.AgentShell] (main:null)
Defaulting to the constant time backoff algorithm
2012-09-19 00:50:48,949 INFO  [cloud.agent.Agent] (main:null) id is
2012-09-19 00:50:49,055 INFO
  [resource.virtualnetwork.**VirtualRoutingResource] (main:null)
VirtualRoutingResource _scriptDir to use: scripts/network/domr/kvm
2012-09-19 00:50:50,048 INFO

[kvm.resource.**LibvirtComputingResource]

(main:null) No libvirt.vif.driver specififed. Defaults to

BridgeVifDriver.

2012-09-19 00:50:50,080 INFO  [cloud.agent.Agent] (main:null) Agent

[id =

new : type = LibvirtComputingResource : zone = 1 : pod = 1 : workers

= 5 :

host = 192.168.1.8 : port = 8250
2012-09-19 00:50:50,093 INFO  [utils.nio.NioClient]

(Agent-Selector:null)

Connecting to 192.168.1.8:8250
2012-09-19 00:50:50,285 INFO  [utils.nio.NioClient]

(Agent-Selector:null)

SSL: Handshake done
2012-09-19 00:50:50,635 WARN  [utils.nio.Task] (Agent-Handler-1:null)
Caught the following exception but pushing on
java.lang.NullPointerException
 at
com.cloud.hypervisor.kvm.**storage.LibvirtStorageAdaptor.**
createStoragePool(**LibvirtStorageAdaptor.java:**562)
 at
com.cloud.hypervisor.kvm.**storage.KVMStoragePoolManager.**
createStoragePool(**KVMStoragePoolManager.java:57)
 at
com.cloud.hypervisor.kvm.**resource.**LibvirtComputingResource.**
initialize(**LibvirtComputingResource.java:**3243)
 at com.cloud.agent.Agent.**sendStartup(Agent.java:320)
 at com.cloud.agent.Agent$**ServerHandler.doTask(Agent.**
java:850)
 at com.cloud.utils.nio.Task.run(**Task.java:83)
 at
java.util.concurrent.**ThreadPoolExecutor.runWorker(**
ThreadPoolExecutor.java:1110)
 at
java.util.concurrent.**ThreadPoolExecutor$Worker.run(**
ThreadPoolExecutor.java:603)
 at

[jira] [Commented] (CLOUDSTACK-4) Complete installation guide in XML

2012-09-19 Thread Wido den Hollander (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458496#comment-13458496
 ] 

Wido den Hollander commented on CLOUDSTACK-4:
-

I'm still working on the Agent and Hypervisor docs. This got delayed, but I 
should be able to make progress on it again next week.

 Complete installation guide in XML
 --

 Key: CLOUDSTACK-4
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4
 Project: CloudStack
  Issue Type: Bug
  Components: Doc
Affects Versions: 4.0.0
Reporter: Jessica Tomechak
Assignee: Jessica Tomechak
 Fix For: pre-4.0.0


 Some sections of the 3.x installation guide are not present in the 4.x 
 installation guide. Need to add complete docbook XML files in the /docs 
 directory.

--
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] [Closed] (CLOUDSTACK-128) Delete Account Job is not waiting for the Network Destruction to complete before marking the Account as removed in the Database


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

Rohit Yadav closed CLOUDSTACK-128.
--

Resolution: Fixed


Duplicate of:
https://issues.apache.org/jira/browse/CLOUDSTACK-125 (which is duplicate of 84)


 Delete Account Job is not waiting for the Network Destruction to complete 
 before marking the Account as removed in the Database
 ---

 Key: CLOUDSTACK-128
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-128
 Project: CloudStack
  Issue Type: Bug
  Components: Management Server
Affects Versions: pre-4.0.0
Reporter: Chandan Purushothama
Assignee: Devdeep Singh
 Fix For: pre-4.0.0


 ===
 Steps to Reproduce:
 ===
 1. Create an Account. Log into as the Account's User.
 2. Create an Isolated Guest Network using 
 DefaultNetworkOfferingwithSourceNATService Network Offering.
 3. Deploy a VM in that Isolated Guest Network.
 4. Log out of the Account
 5. Login as ROOT domain Admin.
 6. Delete the Account created in Step1.
 ===
 Observations:
 ===
 
 Unable to destroy the Guest Network:
 
 2012-09-17 11:26:00,744 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-12:job-21) Successfully released network resources for the vm 
 VM[DomainRouter|r-17-ASF]
 2012-09-17 11:26:00,744 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-12:job-21) Successfully released storage resources for the vm 
 VM[DomainRouter|r-17-ASF]
 2012-09-17 11:26:00,748 DEBUG [vm.dao.VMInstanceDaoImpl] 
 (Job-Executor-12:job-21) Unable to update VM[DomainRouter|r-17-ASF]: DB 
 Data={Host=1; State=Stopping; updated=5; time=Mon Sep 17 11:26:00 PDT 2012} 
 New Data: {Host=null; State=Stopped; updated=5; time=Mon Sep 17 11:26:00 PDT 
 2012} Stale Data: {Host=1; State=Stopping; updated=4; time=Mon Sep 17 
 11:25:11 PDT 2012}
 2012-09-17 11:26:00,748 WARN [cloud.network.NetworkManagerImpl] 
 (Job-Executor-12:job-21) Unable to complete shutdown of the network elements 
 due to element: VirtualRouter
 2012-09-17 11:26:00,756 DEBUG [cloud.network.NetworkManagerImpl] 
 (Job-Executor-12:job-21) Network is not not in the correct state to be 
 destroyed: Implemented
 2012-09-17 11:26:00,756 WARN [cloud.user.AccountManagerImpl] 
 (Job-Executor-12:job-21) Unable to destroy network Ntwk[210|Guest|8] as a 
 part of account id=6 cleanup.
 ===
 Delete Account Job:
 ===
 [root@asfmgmt ~]# grep -i job-21 
 /var/log/cloud/management/management-server.log
 2012-09-17 11:23:35,394 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (catalina-exec-16:null) submit async job-21, details: AsyncJobVO {id:21, 
 userId: 2, accountId: 2, sessionKey: null, instanceType: Account, instanceId: 
 null, cmd: com.cloud.api.commands.DeleteAccountCmd, cmdOriginator: null, 
 cmdInfo: 
 {response:json,id:e4438e90-4e5d-446a-b274-57f235b2e0ae,sessionkey:u6LWTaW5070wtlr1F3LOD5CWBE8\u003d,ctxUserId:2,_:1347906467807,ctxAccountId:2,ctxStartEventId:138},
  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
 processStatus: 0, resultCode: 0, result: null, initMsid: 7471666038533, 
 completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
 2012-09-17 11:23:35,398 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-12:job-21) Executing com.cloud.api.commands.DeleteAccountCmd 
 for job-21
 2012-09-17 11:23:35,421 DEBUG [cloud.user.AccountManagerImpl] 
 (Job-Executor-12:job-21) Removed account 6
 2012-09-17 11:23:35,444 DEBUG [cloud.user.AccountManagerImpl] 
 (Job-Executor-12:job-21) Successfully deleted snapshots directories for all 
 volumes under account 6 across all zones
 2012-09-17 11:23:35,448 DEBUG [cloud.user.AccountManagerImpl] 
 (Job-Executor-12:job-21) Expunging # of vms (accountId=6): 1
 2012-09-17 11:23:35,465 DEBUG [cloud.capacity.CapacityManagerImpl] 
 (Job-Executor-12:job-21) VM state transitted from :Running to Stopping with 
 event: StopRequestedvm's original host id: 1 new host id: 1 host id before 
 state transition: 1
 2012-09-17 11:23:35,467 DEBUG [agent.transport.Request] 
 (Job-Executor-12:job-21) Seq 1-402924740: Sending { Cmd , MgmtId: 
 7471666038533, via: 1, Ver: v1, Flags: 100111, 
 [{StopCommand:{isProxy:false,vmName:i-6-16-ASF,wait:0}}] }
 2012-09-17 11:23:35,467 DEBUG [agent.transport.Request] 
 (Job-Executor-12:job-21) Seq 1-402924740: Executing: { Cmd , MgmtId: 
 7471666038533, via: 1, Ver: v1, Flags: 100111, 
 [{StopCommand:{isProxy:false,vmName:i-6-16-ASF,wait:0}}] }
 2012-09-17 11:23:59,949 DEBUG [agent.transport.Request] 
 (Job-Executor-12:job-21) Seq 1-402924740: Received: { Ans: , MgmtId: 
 7471666038533, via: 1, Ver: v1, Flags:

[jira] [Reopened] (CLOUDSTACK-128) Delete Account Job is not waiting for the Network Destruction to complete before marking the Account as removed in the Database


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

Rohit Yadav reopened CLOUDSTACK-128:



 Delete Account Job is not waiting for the Network Destruction to complete 
 before marking the Account as removed in the Database
 ---

 Key: CLOUDSTACK-128
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-128
 Project: CloudStack
  Issue Type: Bug
  Components: Management Server
Affects Versions: pre-4.0.0
Reporter: Chandan Purushothama
Assignee: Devdeep Singh
 Fix For: pre-4.0.0


 ===
 Steps to Reproduce:
 ===
 1. Create an Account. Log into as the Account's User.
 2. Create an Isolated Guest Network using 
 DefaultNetworkOfferingwithSourceNATService Network Offering.
 3. Deploy a VM in that Isolated Guest Network.
 4. Log out of the Account
 5. Login as ROOT domain Admin.
 6. Delete the Account created in Step1.
 ===
 Observations:
 ===
 
 Unable to destroy the Guest Network:
 
 2012-09-17 11:26:00,744 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-12:job-21) Successfully released network resources for the vm 
 VM[DomainRouter|r-17-ASF]
 2012-09-17 11:26:00,744 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-12:job-21) Successfully released storage resources for the vm 
 VM[DomainRouter|r-17-ASF]
 2012-09-17 11:26:00,748 DEBUG [vm.dao.VMInstanceDaoImpl] 
 (Job-Executor-12:job-21) Unable to update VM[DomainRouter|r-17-ASF]: DB 
 Data={Host=1; State=Stopping; updated=5; time=Mon Sep 17 11:26:00 PDT 2012} 
 New Data: {Host=null; State=Stopped; updated=5; time=Mon Sep 17 11:26:00 PDT 
 2012} Stale Data: {Host=1; State=Stopping; updated=4; time=Mon Sep 17 
 11:25:11 PDT 2012}
 2012-09-17 11:26:00,748 WARN [cloud.network.NetworkManagerImpl] 
 (Job-Executor-12:job-21) Unable to complete shutdown of the network elements 
 due to element: VirtualRouter
 2012-09-17 11:26:00,756 DEBUG [cloud.network.NetworkManagerImpl] 
 (Job-Executor-12:job-21) Network is not not in the correct state to be 
 destroyed: Implemented
 2012-09-17 11:26:00,756 WARN [cloud.user.AccountManagerImpl] 
 (Job-Executor-12:job-21) Unable to destroy network Ntwk[210|Guest|8] as a 
 part of account id=6 cleanup.
 ===
 Delete Account Job:
 ===
 [root@asfmgmt ~]# grep -i job-21 
 /var/log/cloud/management/management-server.log
 2012-09-17 11:23:35,394 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (catalina-exec-16:null) submit async job-21, details: AsyncJobVO {id:21, 
 userId: 2, accountId: 2, sessionKey: null, instanceType: Account, instanceId: 
 null, cmd: com.cloud.api.commands.DeleteAccountCmd, cmdOriginator: null, 
 cmdInfo: 
 {response:json,id:e4438e90-4e5d-446a-b274-57f235b2e0ae,sessionkey:u6LWTaW5070wtlr1F3LOD5CWBE8\u003d,ctxUserId:2,_:1347906467807,ctxAccountId:2,ctxStartEventId:138},
  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
 processStatus: 0, resultCode: 0, result: null, initMsid: 7471666038533, 
 completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
 2012-09-17 11:23:35,398 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-12:job-21) Executing com.cloud.api.commands.DeleteAccountCmd 
 for job-21
 2012-09-17 11:23:35,421 DEBUG [cloud.user.AccountManagerImpl] 
 (Job-Executor-12:job-21) Removed account 6
 2012-09-17 11:23:35,444 DEBUG [cloud.user.AccountManagerImpl] 
 (Job-Executor-12:job-21) Successfully deleted snapshots directories for all 
 volumes under account 6 across all zones
 2012-09-17 11:23:35,448 DEBUG [cloud.user.AccountManagerImpl] 
 (Job-Executor-12:job-21) Expunging # of vms (accountId=6): 1
 2012-09-17 11:23:35,465 DEBUG [cloud.capacity.CapacityManagerImpl] 
 (Job-Executor-12:job-21) VM state transitted from :Running to Stopping with 
 event: StopRequestedvm's original host id: 1 new host id: 1 host id before 
 state transition: 1
 2012-09-17 11:23:35,467 DEBUG [agent.transport.Request] 
 (Job-Executor-12:job-21) Seq 1-402924740: Sending { Cmd , MgmtId: 
 7471666038533, via: 1, Ver: v1, Flags: 100111, 
 [{StopCommand:{isProxy:false,vmName:i-6-16-ASF,wait:0}}] }
 2012-09-17 11:23:35,467 DEBUG [agent.transport.Request] 
 (Job-Executor-12:job-21) Seq 1-402924740: Executing: { Cmd , MgmtId: 
 7471666038533, via: 1, Ver: v1, Flags: 100111, 
 [{StopCommand:{isProxy:false,vmName:i-6-16-ASF,wait:0}}] }
 2012-09-17 11:23:59,949 DEBUG [agent.transport.Request] 
 (Job-Executor-12:job-21) Seq 1-402924740: Received: { Ans: , MgmtId: 
 7471666038533, via: 1, Ver: v1, Flags: 110, { StopAnswer } }
 2012-09-17 11:23:59,950 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-12:job-21)

[jira] [Comment Edited] (CLOUDSTACK-112) Adding XenServer Host Fails

2012-09-19 Thread Devdeep Singh (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458518#comment-13458518
 ] 

Devdeep Singh edited comment on CLOUDSTACK-112 at 9/19/12 8:11 PM:
---

Tried the scenario against a 6.0.2 host and I am not able to reproduce the 
problem.

Can you check if there is an entry in the host_details table by the name 
storage.network.device1 for the host. If so, was the setup upgraded from an 
older version?

  was (Author: devdeep):
Tried the scenario against a 6.0.2 host and I am not able to reproduce the 
problem.

Can you check if there is an entry in the host_details table by the name 
storage.network.device1 for the host. If so, what the setup upgraded from an 
older version?
  
 Adding XenServer Host Fails
 ---

 Key: CLOUDSTACK-112
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-112
 Project: CloudStack
  Issue Type: Bug
  Components: XenServer
Affects Versions: pre-4.0.0
Reporter: Jonas Vachal
Assignee: Devdeep Singh
  Labels: xenserver
 Fix For: pre-4.0.0


 Adding a new XenServer 6.0.2 host fails.
 The management log reports:
 2012-09-16 08:47:03,149 INFO  [cloud.resource.ResourceManagerImpl] 
 (catalina-exec-7:null) Trying to add a new host at http://10.1.10.51 in data 
 center 3
 2012-09-16 08:47:03,218 DEBUG [xen.resource.XenServerConnectionPool] 
 (catalina-exec-7:null) Slave logon to 10.1.10.51
 2012-09-16 08:47:03,248 DEBUG [xen.resource.XenServerConnectionPool] 
 (catalina-exec-7:null) Logging on as the master to 10.1.10.51
 2012-09-16 08:47:03,401 INFO  [xen.discoverer.XcpServerDiscoverer] 
 (catalina-exec-7:null) Found host localhost ip=10.1.10.51 product 
 version=6.0.2
 2012-09-16 08:47:03,713 DEBUG [xen.resource.CitrixResourceBase] 
 (catalina-exec-7:null) Management network is on 
 pif=a5a64b7a-2d53-9632-8b8e-5dd988f083b2
 2012-09-16 08:47:03,735 WARN  [xen.resource.CitrixResourceBase] 
 (catalina-exec-7:null) Unable to get host information for 10.1.10.51
 java.lang.NullPointerException
   at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.getHostInfo(CitrixResourceBase.java:4331)
   at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.initialize(CitrixResourceBase.java:4460)
   at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.initialize(XenServer56Resource.java:328)
   at 
 com.cloud.resource.ResourceManagerImpl.createHostAndAgent(ResourceManagerImpl.java:1598)
   at 
 com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:720)
   at 
 com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:544)
   at com.cloud.api.commands.AddHostCmd.execute(AddHostCmd.java:140)
   at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:138)
   at com.cloud.api.ApiServer.queueCommand(ApiServer.java:543)
   at com.cloud.api.ApiServer.handleRequest(ApiServer.java:422)
   at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:304)
   at com.cloud.api.ApiServlet.doGet(ApiServlet.java:63)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
   at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
   at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
   at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
   at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
   at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
   at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
   at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
   at 
 org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
   at 
 org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721)
   at 
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2268)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.java:679)
 2012-09-16 08:47:03,741 WARN  [xen.resource.CitrixResourceBase] 
 (catalina-exec-7:null) Unable to get host information for 10.1.10.51
 2012-09-16 08:47:03,741

[jira] [Commented] (CLOUDSTACK-132) Mash up marvin into an interactive auto-completing API shell for CloudStack

2012-09-19 Thread sebastien goasguen (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458526#comment-13458526
 ] 

sebastien goasguen commented on CLOUDSTACK-132:
---

Is ipython not enough. You have auto-completion there:

In [4]: from marvin.cloudstackAPI import *
In [5]: listA
listAccounts   listAlerts listAsyncJobs  

 Mash up marvin into an interactive auto-completing API shell for CloudStack
 ---

 Key: CLOUDSTACK-132
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-132
 Project: CloudStack
  Issue Type: New Feature
  Components: Test Tools
Affects Versions: 4.0.0, pre-4.0.0
Reporter: Prasanna Santhanam
Assignee: Prasanna Santhanam
 Fix For: 4.1.0


 The marvin libraries contain the capability to convert marvin into an 
 interactive shell for CloudStack. Every cloud provider has an auto-completing 
 shell and cloudstack lacks options for this now. This should involve 
 refactoring all the marvin libraries to allow for auto-completion of APIs.
 Furthermore the ability to autocomplete the entities like templates, images, 
 virtualmachines need to exist as a part of such a shell to make it useful at 
 cloudscale

--
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-107) Network domain guest suffix is not getting programmed as part of hostnames on Guest VMs that are part of Isolated and Shared Guest Networks

2012-09-19 Thread Mice Xia (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458533#comment-13458533
 ] 

Mice Xia commented on CLOUDSTACK-107:
-

How to avoid updating /etc/resolve.conf 

in RHEL/CentOS, 
adding PEERDNS=no in ifcfg-ethx

in ubuntu
setting supersede domain-name in /etc/dhclient.conf 

in Windows
hostname cannot be set by DHCP due to the protocol of microsoft, (verified on 
windows 2003), while domain name/dns server can be successfully set on each NIC.

Observed different behaviors in windows and linux, not sure if it's the correct 
way to impose one domainName/searchDomain to all VM's nics; can we mark it as a 
known issue and leave it to end users to set prefered domain name?





 Network domain guest suffix is not getting programmed as part of hostnames on 
 Guest VMs that are part of Isolated and Shared Guest Networks
 ---

 Key: CLOUDSTACK-107
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-107
 Project: CloudStack
  Issue Type: Bug
  Components: Management Server
Affects Versions: pre-4.0.0
Reporter: Chandan Purushothama
Assignee: Mice Xia
 Fix For: 4.0.0


 ===
 Observations on the User VMs present on Isolated and Shared Guest Networks:
 ===
 **Observe the hostname --fqdn Information on the Guest VMs **
 [root@atoms-regnet-shdnet-vm2 ~]# ip route
 10.223.137.128/26 dev eth1  proto kernel  scope link  src 10.223.137.133
 10.1.1.0/24 dev eth0  proto kernel  scope link  src 10.1.1.134
 169.254.0.0/16 dev eth1  scope link
 default via 10.1.1.1 dev eth0
 [root@atoms-regnet-shdnet-vm2 ~]# ifconfig
 eth0  Link encap:Ethernet  HWaddr 02:00:59:14:00:03
   inet addr:10.1.1.134  Bcast:10.1.1.255  Mask:255.255.255.0
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:8463 errors:0 dropped:0 overruns:0 frame:0
   TX packets:8676 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:7452424 (7.1 MiB)  TX bytes:639913 (624.9 KiB)
 eth1  Link encap:Ethernet  HWaddr 06:F8:3E:00:00:2C
   inet addr:10.223.137.133  Bcast:10.223.137.191  Mask:255.255.255.192
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:16260 errors:0 dropped:0 overruns:0 frame:0
   TX packets:30005 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:1080956 (1.0 MiB)  TX bytes:7215858 (6.8 MiB)
 loLink encap:Local Loopback
   inet addr:127.0.0.1  Mask:255.0.0.0
   UP LOOPBACK RUNNING  MTU:16436  Metric:1
   RX packets:87 errors:0 dropped:0 overruns:0 frame:0
   TX packets:87 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:12034 (11.7 KiB)  TX bytes:12034 (11.7 KiB)
 [root@atoms-regnet-shdnet-vm2 ~]# ip route
 10.223.137.128/26 dev eth1  proto kernel  scope link  src 10.223.137.133
 10.1.1.0/24 dev eth0  proto kernel  scope link  src 10.1.1.134
 169.254.0.0/16 dev eth1  scope link
 default via 10.1.1.1 dev eth0
 [root@atoms-regnet-shdnet-vm2 ~]# hostname
 atoms-regnet-shdnet-vm2
 [root@atoms-regnet-shdnet-vm2 ~]# hostname --fqdn
 hostname: Unknown host
 [root@atoms-regnet-shdnet-vm2 ~]# cat /etc/hosts
 # Do not remove the following line, or various programs
 # that require network functionality will fail.
 127.0.0.1   localhost.localdomain localhost
 ::1 localhost6.localdomain6 localhost6
 [root@atoms-regnet-shdnet-vm2 ~]# exit
 logout
 Connection to 10.223.137.133 closed.
 [root@atoms-shdnet-regnet-vm3 ~]#
 [root@atoms-shdnet-regnet-vm3 ~]#
 [root@atoms-shdnet-regnet-vm3 ~]#
 [root@atoms-shdnet-regnet-vm3 ~]# ifconfig
 eth0  Link encap:Ethernet  HWaddr 06:15:2E:00:00:2A
   inet addr:10.223.137.131  Bcast:10.223.137.191  Mask:255.255.255.192
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:49444 errors:0 dropped:0 overruns:0 frame:0
   TX packets:35070 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:15282991 (14.5 MiB)  TX bytes:6945191 (6.6 MiB)
 eth1  Link encap:Ethernet  HWaddr 02:00:1B:9C:00:04
   inet addr:10.1.1.175  Bcast:10.1.1.255  Mask:255.255.255.0
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:129 errors:0 dropped:0 overruns:0 frame:0
   TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:6119 (5.9 KiB)  TX bytes:768

Re: Problems building with maven

2012-09-19 Thread Rohit Yadav

Try two things on your bash/zsh:
export MAVEN_OPTS=-Xmx1024m #(to make sure mvn does not run out of memory)
Pull the latest master; git pull origin master

Try again with -X, mvn -P reps -X (this enables debugging for you).

If this still fails, probably you've the incorrect recently introduced xalan 
dependency.
wget and copy all the xalan 2.7.1 pom, jar, checksum etc. to your 
~/.m2/repository//org/apache/xalan/xalan/2.7.1/
http://mvnrepository.com/artifact/xalan/xalan/2.7.1

or just download the jar file and run: (not the recommended way but it should 
work)
mvn install:install-file -Dfile=xalan.jar   -DgroupId=org.apache.xalan  
-DartifactId=xalan-Dversion=2.7.1   -Dpackaging=jar


On 19-Sep-2012, at 3:12 PM, Pedro Navarro Pérez pedn...@gmail.com wrote:

 Hi all,
 
 I've done a clean git clone (branch master), and followed the Maven
 instructions and I'm getting the next errors when executing mvn -P
 deps:
 
 
 [INFO] -
 [ERROR] COMPILATION ERROR :
 [INFO] -
 [ERROR] error: error reading
 /root/.m2/repository/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.jar;
 error in opening zip file
 [INFO] 1 error
 [INFO] -
 [INFO] 
 
 [INFO] Reactor Summary:
 [INFO]
 [INFO] Apache CloudStack . SUCCESS [6.316s]
 [INFO] Apache CloudStack Utils ... SUCCESS [5.893s]
 [INFO] Apache CloudStack API . SUCCESS [2.418s]
 [INFO] Apache XenSource XAPI . SUCCESS [0.791s]
 [INFO] Apache CloudStack Core  SUCCESS [1.260s]
 [INFO] Apache CloudStack Agents .. SUCCESS [2.068s]
 [INFO] Apache CloudStack SystemVM Patches  SUCCESS [2.240s]
 [INFO] Apache CloudStack Console Proxy ... SUCCESS [4.168s]
 [INFO] Apache CloudStack Server .. SUCCESS [2.003s]
 [INFO] Apache CloudStack Usage Server  SUCCESS [0.650s]
 [INFO] Apache CloudStack Plugin POM .. SUCCESS [0.228s]
 [INFO] Apache CloudStack Plugin - User Concentrated Pod Deployment
 Planner  SUCCESS [0.826s]
 [INFO] Apache CloudStack Plugin - User Dispersing Deployment Planner
 SUCCESS [0.406s]
 [INFO] Apache CloudStack Plugin - Host Allocator Random .. SUCCESS [0.879s]
 [INFO] Apache CloudStack Plugin - Hypervisor OracleVM  SUCCESS [1.089s]
 [INFO] Apache CloudStack Plugin - Open vSwitch ... SUCCESS [1.179s]
 [INFO] Apache CloudStack Plugin - Hypervisor Xen . SUCCESS [0.584s]
 [INFO] Apache CloudStack Plugin - Hypervisor KVM . SUCCESS [1.226s]
 [INFO] Apache CloudStack Plugin - Network Elastic Load Balancer
 SUCCESS [0.390s]
 [INFO] Apache CloudStack Plugin - Network Nicira NVP . SUCCESS [0.495s]
 [INFO] Apache CloudStack Plugin - Storage Allocator Random  SUCCESS [0.430s]
 [INFO] Apache CloudStack Plugin - User Authenticator LDAP  SUCCESS [0.440s]
 [INFO] Apache CloudStack Plugin - User Authenticator MD5 . SUCCESS [0.717s]
 [INFO] Apache CloudStack Plugin - User Authenticator Plain Text
 SUCCESS [0.554s]
 [INFO] Apache CloudStack VMware Base . SUCCESS [1.007s]
 [INFO] Apache CloudStack AWS API Bridge .. FAILURE [1:28.658s]
 [INFO] Apache CloudStack Test  SKIPPED
 [INFO] Apache CloudStack Dependencies  SKIPPED
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 [INFO] Total time: 2:08.957s
 [INFO] Finished at: Tue Sep 18 19:56:54 CEST 2012
 [INFO] Final Memory: 23M/58M
 [INFO] 
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile
 (default-compile) on project cloud-awsapi: Compilation failure
 [ERROR] error: error reading
 /root/.m2/repository/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.jar;
 error in opening zip file
 [ERROR] - [Help 1]
 [ERROR]
 [ERROR] To see the full stack trace of the errors, re-run Maven with
 the -e switch.
 [ERROR] Re-run Maven using the -X switch to enable full debug logging.
 [ERROR]
 [ERROR] For more information about the errors and possible solutions,
 please read the following articles:
 [ERROR] [Help 1]
 http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
 
 
 When activating debug, the next fatal error is shown:
 
 [DEBUG] 
 ===
 [WARNING] The POM for org.apache.xalan:xalan:jar:2.7.1 is invalid,
 transitive dependencies (if any) will not be available: 1 problem was
 encountered while building the effective

Re: Problems building with maven

2012-09-19 Thread Pedro Navarro Pérez

It worked ! thanks for your help!.

On Wed, Sep 19, 2012 at 12:08 PM, Rohit Yadav rohit.ya...@citrix.com wrote:
 Try two things on your bash/zsh:
 export MAVEN_OPTS=-Xmx1024m #(to make sure mvn does not run out of memory)
 Pull the latest master; git pull origin master

 Try again with -X, mvn -P reps -X (this enables debugging for you).

 If this still fails, probably you've the incorrect recently introduced xalan 
 dependency.
 wget and copy all the xalan 2.7.1 pom, jar, checksum etc. to your 
 ~/.m2/repository//org/apache/xalan/xalan/2.7.1/
 http://mvnrepository.com/artifact/xalan/xalan/2.7.1

 or just download the jar file and run: (not the recommended way but it should 
 work)
 mvn install:install-file -Dfile=xalan.jar   -DgroupId=org.apache.xalan  
 -DartifactId=xalan-Dversion=2.7.1   -Dpackaging=jar


 On 19-Sep-2012, at 3:12 PM, Pedro Navarro Pérez pedn...@gmail.com wrote:

 Hi all,

 I've done a clean git clone (branch master), and followed the Maven
 instructions and I'm getting the next errors when executing mvn -P
 deps:


 [INFO] -
 [ERROR] COMPILATION ERROR :
 [INFO] -
 [ERROR] error: error reading
 /root/.m2/repository/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.jar;
 error in opening zip file
 [INFO] 1 error
 [INFO] -
 [INFO] 
 
 [INFO] Reactor Summary:
 [INFO]
 [INFO] Apache CloudStack . SUCCESS [6.316s]
 [INFO] Apache CloudStack Utils ... SUCCESS [5.893s]
 [INFO] Apache CloudStack API . SUCCESS [2.418s]
 [INFO] Apache XenSource XAPI . SUCCESS [0.791s]
 [INFO] Apache CloudStack Core  SUCCESS [1.260s]
 [INFO] Apache CloudStack Agents .. SUCCESS [2.068s]
 [INFO] Apache CloudStack SystemVM Patches  SUCCESS [2.240s]
 [INFO] Apache CloudStack Console Proxy ... SUCCESS [4.168s]
 [INFO] Apache CloudStack Server .. SUCCESS [2.003s]
 [INFO] Apache CloudStack Usage Server  SUCCESS [0.650s]
 [INFO] Apache CloudStack Plugin POM .. SUCCESS [0.228s]
 [INFO] Apache CloudStack Plugin - User Concentrated Pod Deployment
 Planner  SUCCESS [0.826s]
 [INFO] Apache CloudStack Plugin - User Dispersing Deployment Planner
 SUCCESS [0.406s]
 [INFO] Apache CloudStack Plugin - Host Allocator Random .. SUCCESS [0.879s]
 [INFO] Apache CloudStack Plugin - Hypervisor OracleVM  SUCCESS [1.089s]
 [INFO] Apache CloudStack Plugin - Open vSwitch ... SUCCESS [1.179s]
 [INFO] Apache CloudStack Plugin - Hypervisor Xen . SUCCESS [0.584s]
 [INFO] Apache CloudStack Plugin - Hypervisor KVM . SUCCESS [1.226s]
 [INFO] Apache CloudStack Plugin - Network Elastic Load Balancer
 SUCCESS [0.390s]
 [INFO] Apache CloudStack Plugin - Network Nicira NVP . SUCCESS [0.495s]
 [INFO] Apache CloudStack Plugin - Storage Allocator Random  SUCCESS [0.430s]
 [INFO] Apache CloudStack Plugin - User Authenticator LDAP  SUCCESS [0.440s]
 [INFO] Apache CloudStack Plugin - User Authenticator MD5 . SUCCESS [0.717s]
 [INFO] Apache CloudStack Plugin - User Authenticator Plain Text
 SUCCESS [0.554s]
 [INFO] Apache CloudStack VMware Base . SUCCESS [1.007s]
 [INFO] Apache CloudStack AWS API Bridge .. FAILURE 
 [1:28.658s]
 [INFO] Apache CloudStack Test  SKIPPED
 [INFO] Apache CloudStack Dependencies  SKIPPED
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 [INFO] Total time: 2:08.957s
 [INFO] Finished at: Tue Sep 18 19:56:54 CEST 2012
 [INFO] Final Memory: 23M/58M
 [INFO] 
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile
 (default-compile) on project cloud-awsapi: Compilation failure
 [ERROR] error: error reading
 /root/.m2/repository/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.jar;
 error in opening zip file
 [ERROR] - [Help 1]
 [ERROR]
 [ERROR] To see the full stack trace of the errors, re-run Maven with
 the -e switch.
 [ERROR] Re-run Maven using the -X switch to enable full debug logging.
 [ERROR]
 [ERROR] For more information about the errors and possible solutions,
 please read the following articles:
 [ERROR] [Help 1]
 http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException


 When activating debug, the next fatal error is shown:

 [DEBUG] 
 ===
 [WARNING] The POM for org.apache.xalan:xalan:jar:2.7.1 is

Review Request: STT isolation support for KVM

2012-09-19 Thread Hiroaki Kawai


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

Review request for cloudstack.


Description
---

Adds STT support on KVM host, just like in XenServer. The host os having 
openvswitch and brcompat kernel module will plug the VM to openvswitch port 
through general brctl interface calls.


Diffs
-

  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
 cf4de09 
  scripts/vm/network/vnet/setupLswitch.sh PRE-CREATION 
  server/src/com/cloud/hypervisor/HypervisorGuruBase.java 242852f 

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


Testing
---


Thanks,

Hiroaki Kawai

[jira] [Commented] (CLOUDSTACK-127) Adding VMs to an existing LB rule after upgrading from CS 3.0.2 to ASF 4.0 fails with ResourceUnavailableException: Resource [DataCenter:1] is unreachable: Unable

2012-09-19 Thread Abhinav Roy (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458616#comment-13458616
 ] 

Abhinav Roy commented on CLOUDSTACK-127:


Yes , rebooting the router does work. But this happens everytime after I do a 
upgrade. I have tried this 3-4 times already. So does this mean everytime we 
need to reboot the router after upgrade?
Also why the creation of VMs with the same router succeeds? And why don't we 
see this error before upgrade ?


 Adding VMs to an existing LB rule after upgrading from CS 3.0.2 to ASF 4.0 
 fails with ResourceUnavailableException: Resource [DataCenter:1] is 
 unreachable: Unable to apply ip association on router 
 ---

 Key: CLOUDSTACK-127
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-127
 Project: CloudStack
  Issue Type: Bug
  Components: Network Controller
Affects Versions: pre-4.0.0
 Environment: MS OS : Rhel 6.2
 Hypervisor : Xen 6.0.2
 BUILDs : 3.0.2 and ASF 4.0 [ Git Revision: 
 54f9af1695bc359b02e9fc906b3b335cc0bfec41 Git URL: 
 https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git]
Reporter: Abhinav Roy
Assignee: Sheng Yang
 Fix For: pre-4.0.0

 Attachments: management-server.log, messages, SMlog.10, SMlog.11


 Steps :
 =
 1. Deploy an advanced zone setup with CS 3.0.2
 2. Deploy couple of VMs.
 3. Acquire an IP Address for the Network created and create a LB rule for the 
 VMs created in step2.
 4. Upgrade the setup to ASF 4.0
 5. Create a VM on the existing Network.
 6. Add the VM created in step 5 to the LB rule created in step 3.
 Expected Behaviour :
 =
 All the steps should be successful and no error should be seen.
 Observed Behaviour :
 =
 Step 6 fails with the following exceptions
 2012-09-18 00:32:07,036 DEBUG [network.lb.LoadBalancingRulesManagerImpl] 
 (Job-Executor-7:job-18) Adding VM[User|VM-3] to the load balancer pool
 2012-09-18 00:32:07,130 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-7:job-18) 
 Applying ip association in network Ntwk[204|Guest|7]
 2012-09-18 00:32:07,177 DEBUG [agent.transport.Request] 
 (Job-Executor-7:job-18) Seq 1-2076573728: Sending  { Cmd , MgmtId: 
 160940036302157, via: 1, Ver: v1, Flags: 11, 
 [{routing.IpAssocCommand:{ipAddresses:[{accountId:2,publicIp:10.102.125.69,sourceNat:true,add:true,oneToOneNat:false,firstIP:true,vlanId:untagged,vlanGateway:10.102.125.1,vlanNetmask:255.255.255.0,vifMacAddress:06:4d:b6:00:00:09,networkRate:200,trafficType:Public},{accountId:2,publicIp:10.102.125.66,sourceNat:false,add:true,oneToOneNat:false,firstIP:false,vlanId:untagged,vlanGateway:10.102.125.1,vlanNetmask:255.255.255.0,vifMacAddress:06:b2:8e:00:00:06,networkRate:200,trafficType:Public}],accessDetails:{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:169.254.2.233,router.name:r-4-VM},wait:0}}]
  }
 2012-09-18 00:32:07,177 DEBUG [agent.transport.Request] 
 (Job-Executor-7:job-18) Seq 1-2076573728: Executing:  { Cmd , MgmtId: 
 160940036302157, via: 1, Ver: v1, Flags: 11, 
 [{routing.IpAssocCommand:{ipAddresses:[{accountId:2,publicIp:10.102.125.69,sourceNat:true,add:true,oneToOneNat:false,firstIP:true,vlanId:untagged,vlanGateway:10.102.125.1,vlanNetmask:255.255.255.0,vifMacAddress:06:4d:b6:00:00:09,networkRate:200,trafficType:Public},{accountId:2,publicIp:10.102.125.66,sourceNat:false,add:true,oneToOneNat:false,firstIP:false,vlanId:untagged,vlanGateway:10.102.125.1,vlanNetmask:255.255.255.0,vifMacAddress:06:b2:8e:00:00:06,networkRate:200,trafficType:Public}],accessDetails:{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:169.254.2.233,router.name:r-4-VM},wait:0}}]
  }
 2012-09-18 00:32:07,178 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-6:null) Seq 1-2076573728: Executing request
 2012-09-18 00:32:07,718 ERROR [xen.resource.CitrixResourceBase] 
 (DirectAgent-6:null) Ip Assoc failure on applying one ip due to exception:  
 com.cloud.exception.InternalErrorException: Xen plugin ipassoc failed.
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.assignPublicIpAddress(CitrixResourceBase.java:1934)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:2030)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:421)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:191)

Re: Still cannot add KVM host

Here's the output of cloud-setup-agent and the relevant portion of
agent.log (I installed the agent using the install package from Jensen --
4.0)

[root@kvmhost libvirt]# cloud-setup-agent
Welcome to the CloudStack Agent Setup:
Please input the Management Server Hostname/IP-Address:[192.168.1.8]
Please input the Zone Id:[1]
Please input the Pod Id:[1]
Please input the Cluster Id:[1]
Please choose which network used to create VM:[cloudbr0]
Starting to configure your system:
Configure Cgroup ...  [OK]
Configure SElinux ... [OK]
Configure Network ... [OK]
Configure Libvirt ... [OK]
Configure Firewall ...[OK]
Configure Nfs ... [OK]
Configure cloudAgent ...  [OK]
CloudStack Agent setup is done!
[root@kvmhost libvirt]# service cloud-agent restart
Stopping Cloud Agent:
Starting Cloud Agent:
[root@kvmhost libvirt]# tail -f /var/log/cloud/agent/agent.log
java.lang.NullPointerException
at
com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.createStoragePool(LibvirtStorageAdaptor.java:562)
at
com.cloud.hypervisor.kvm.storage.KVMStoragePoolManager.createStoragePool(KVMStoragePoolManager.java:57)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.initialize(LibvirtComputingResource.java:3243)
at com.cloud.agent.Agent.sendStartup(Agent.java:320)
at com.cloud.agent.Agent$ServerHandler.doTask(Agent.java:850)
at com.cloud.utils.nio.Task.run(Task.java:83)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2012-09-19 06:45:41,986 INFO  [cloud.agent.Agent]
(AgentShutdownThread:null) Stopping the agent: Reason = sig.kill
2012-09-19 06:45:42,027 INFO  [cloud.serializer.GsonHelper]
(AgentShutdownThread:null) Default Builder inited.
2012-09-19 06:46:18,395 INFO  [utils.component.ComponentLocator]
(main:null) Unable to find components.xml
2012-09-19 06:46:18,396 INFO  [utils.component.ComponentLocator]
(main:null) Skipping configuration using components.xml
2012-09-19 06:46:18,396 INFO  [cloud.agent.AgentShell] (main:null)
Implementation Version is 4.0.0.48.20120918191610
2012-09-19 06:46:18,397 INFO  [cloud.agent.AgentShell] (main:null)
agent.properties found at /etc/cloud/agent/agent.properties
2012-09-19 06:46:18,398 INFO  [cloud.agent.AgentShell] (main:null)
Defaulting to using properties file for storage
2012-09-19 06:46:18,399 INFO  [cloud.agent.AgentShell] (main:null)
Defaulting to the constant time backoff algorithm
2012-09-19 06:46:18,460 INFO  [cloud.agent.Agent] (main:null) id is
2012-09-19 06:46:18,563 INFO
 [resource.virtualnetwork.VirtualRoutingResource] (main:null)
VirtualRoutingResource _scriptDir to use: scripts/network/domr/kvm
2012-09-19 06:46:19,554 INFO  [kvm.resource.LibvirtComputingResource]
(main:null) No libvirt.vif.driver specififed. Defaults to BridgeVifDriver.
2012-09-19 06:46:19,585 INFO  [cloud.agent.Agent] (main:null) Agent [id =
new : type = LibvirtComputingResource : zone = 1 : pod = 1 : workers = 5 :
host = 192.168.1.8 : port = 8250
2012-09-19 06:46:19,595 INFO  [utils.nio.NioClient] (Agent-Selector:null)
Connecting to 192.168.1.8:8250
2012-09-19 06:46:19,779 INFO  [utils.nio.NioClient] (Agent-Selector:null)
SSL: Handshake done
2012-09-19 06:46:20,097 WARN  [utils.nio.Task] (Agent-Handler-1:null)
Caught the following exception but pushing on
java.lang.NullPointerException
at
com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.createStoragePool(LibvirtStorageAdaptor.java:562)
at
com.cloud.hypervisor.kvm.storage.KVMStoragePoolManager.createStoragePool(KVMStoragePoolManager.java:57)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.initialize(LibvirtComputingResource.java:3243)
at com.cloud.agent.Agent.sendStartup(Agent.java:320)
at com.cloud.agent.Agent$ServerHandler.doTask(Agent.java:850)
at com.cloud.utils.nio.Task.run(Task.java:83)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)






On Wed, Sep 19, 2012 at 2:22 AM, Kelcey Jamison-Damage kel...@bbits.cawrote:

 Have you tried running cloud-setup-agent on the host? If so what is its
 output?

 Are you building 3.0.2 or 4.0 source?



 Busy Dev busyd...@gmail.com wrote:

 Thanks - I checked my KVM host and that directory already exists.
 
 
 
 On Wed, Sep 19, 2012 at 1:07 AM, KAWAI Hiroaki ka...@stratosphere.co.jp
 wrote:
 
  Hi,
  I run into the same problem. On KVM host OS, try:
 
  mkdir /var/lib/libvirt/images/
 
  logging will be added with patch https://reviews.apache.org/r/**7153/
 https://reviews.apache.org/r/7153/
 
 
 
  (2012/09/19 14:00), Busy Dev wrote:
 
  I've been able to setup my development environment and am now trying to
  setup the management server.  However, when I launch Cloudstack, I am
  unable to add a KVM host.
 
  The error

Re: Still cannot add KVM host

I also checked my agent.properties file and all the settings are there
(with the appropriate values).

On Wed, Sep 19, 2012 at 8:19 AM, Busy Dev busyd...@gmail.com wrote:

 I am using CentOS 6.3.

 I also ran into an issue with cgconfig a while back when I was trying to
 setup 3.02 and had this fix for it in /etc/cgconfig.conf:

 *group virt {
 cpu {
cpu.shares = 9216;
 }
 }*




 On Wed, Sep 19, 2012 at 2:49 AM, Marcus Sorensen shadow...@gmail.comwrote:

 Did he say which distribution? I recently submitted a fix for cent 6.3, it
 wasn't setting up the cgconfig service.

 I second drumming cloud-setup-agent. If you look at the management server
 log you should see the exact command/arcs being sent to the host. Copy
 that
 and run it manually to see where it fails.
 On Sep 19, 2012 12:23 AM, Kelcey Jamison-Damage kel...@bbits.ca
 wrote:

  Have you tried running cloud-setup-agent on the host? If so what is its
  output?
 
  Are you building 3.0.2 or 4.0 source?
 
 
 
  Busy Dev busyd...@gmail.com wrote:
 
  Thanks - I checked my KVM host and that directory already exists.
  
  
  
  On Wed, Sep 19, 2012 at 1:07 AM, KAWAI Hiroaki 
 ka...@stratosphere.co.jp
  wrote:
  
   Hi,
   I run into the same problem. On KVM host OS, try:
  
   mkdir /var/lib/libvirt/images/
  
   logging will be added with patch
 https://reviews.apache.org/r/**7153/
  https://reviews.apache.org/r/7153/
  
  
  
   (2012/09/19 14:00), Busy Dev wrote:
  
   I've been able to setup my development environment and am now
 trying to
   setup the management server.  However, when I launch Cloudstack,
 I am
   unable to add a KVM host.
  
   The error in the log file
  
   2012-09-19 00:50:48,883 INFO  [utils.component.**ComponentLocator]
   (main:null) Unable to find components.xml
   2012-09-19 00:50:48,884 INFO  [utils.component.**ComponentLocator]
   (main:null) Skipping configuration using components.xml
   2012-09-19 00:50:48,885 INFO  [cloud.agent.AgentShell] (main:null)
   Implementation Version is 4.0.0.48.20120918191610
   2012-09-19 00:50:48,885 INFO  [cloud.agent.AgentShell] (main:null)
   agent.properties found at /etc/cloud/agent/agent.**properties
   2012-09-19 00:50:48,886 INFO  [cloud.agent.AgentShell] (main:null)
   Defaulting to using properties file for storage
   2012-09-19 00:50:48,888 INFO  [cloud.agent.AgentShell] (main:null)
   Defaulting to the constant time backoff algorithm
   2012-09-19 00:50:48,949 INFO  [cloud.agent.Agent] (main:null) id is
   2012-09-19 00:50:49,055 INFO
 [resource.virtualnetwork.**VirtualRoutingResource] (main:null)
   VirtualRoutingResource _scriptDir to use: scripts/network/domr/kvm
   2012-09-19 00:50:50,048 INFO
  [kvm.resource.**LibvirtComputingResource]
   (main:null) No libvirt.vif.driver specififed. Defaults to
  BridgeVifDriver.
   2012-09-19 00:50:50,080 INFO  [cloud.agent.Agent] (main:null) Agent
  [id =
   new : type = LibvirtComputingResource : zone = 1 : pod = 1 :
 workers =
  5 :
   host = 192.168.1.8 : port = 8250
   2012-09-19 00:50:50,093 INFO  [utils.nio.NioClient]
  (Agent-Selector:null)
   Connecting to 192.168.1.8:8250
   2012-09-19 00:50:50,285 INFO  [utils.nio.NioClient]
  (Agent-Selector:null)
   SSL: Handshake done
   2012-09-19 00:50:50,635 WARN  [utils.nio.Task]
 (Agent-Handler-1:null)
   Caught the following exception but pushing on
   java.lang.NullPointerException
at
   com.cloud.hypervisor.kvm.**storage.LibvirtStorageAdaptor.**
   createStoragePool(**LibvirtStorageAdaptor.java:**562)
at
   com.cloud.hypervisor.kvm.**storage.KVMStoragePoolManager.**
   createStoragePool(**KVMStoragePoolManager.java:57)
at
   com.cloud.hypervisor.kvm.**resource.**LibvirtComputingResource.**
   initialize(**LibvirtComputingResource.java:**3243)
at com.cloud.agent.Agent.**sendStartup(Agent.java:320)
at com.cloud.agent.Agent$**ServerHandler.doTask(Agent.**
   java:850)
at com.cloud.utils.nio.Task.run(**Task.java:83)
at
   java.util.concurrent.**ThreadPoolExecutor.runWorker(**
   ThreadPoolExecutor.java:1110)
at
   java.util.concurrent.**ThreadPoolExecutor$Worker.run(**
   ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.**java:679)
  
  
   Thanks for your help.

Re: Still cannot add KVM host

That create storage pool failure usually hits me when I have some sort of
primary storage defined which doesn't work. Most recently when I set up a
sharedmountpoint pool without creating the mount directory. Are you sure
that all of your primary storage is available to this host ?
On Sep 19, 2012 6:28 AM, Busy Dev busyd...@gmail.com wrote:

 I also checked my agent.properties file and all the settings are there
 (with the appropriate values).

 On Wed, Sep 19, 2012 at 8:19 AM, Busy Dev busyd...@gmail.com wrote:

  I am using CentOS 6.3.
 
  I also ran into an issue with cgconfig a while back when I was trying to
  setup 3.02 and had this fix for it in /etc/cgconfig.conf:
 
  *group virt {
  cpu {
 cpu.shares = 9216;
  }
  }*
 
 
 
 
  On Wed, Sep 19, 2012 at 2:49 AM, Marcus Sorensen shadow...@gmail.com
 wrote:
 
  Did he say which distribution? I recently submitted a fix for cent 6.3,
 it
  wasn't setting up the cgconfig service.
 
  I second drumming cloud-setup-agent. If you look at the management
 server
  log you should see the exact command/arcs being sent to the host. Copy
  that
  and run it manually to see where it fails.
  On Sep 19, 2012 12:23 AM, Kelcey Jamison-Damage kel...@bbits.ca
  wrote:
 
   Have you tried running cloud-setup-agent on the host? If so what is
 its
   output?
  
   Are you building 3.0.2 or 4.0 source?
  
  
  
   Busy Dev busyd...@gmail.com wrote:
  
   Thanks - I checked my KVM host and that directory already exists.
   
   
   
   On Wed, Sep 19, 2012 at 1:07 AM, KAWAI Hiroaki 
  ka...@stratosphere.co.jp
   wrote:
   
Hi,
I run into the same problem. On KVM host OS, try:
   
mkdir /var/lib/libvirt/images/
   
logging will be added with patch
  https://reviews.apache.org/r/**7153/
   https://reviews.apache.org/r/7153/
   
   
   
(2012/09/19 14:00), Busy Dev wrote:
   
I've been able to setup my development environment and am now
  trying to
setup the management server.  However, when I launch Cloudstack,
  I am
unable to add a KVM host.
   
The error in the log file
   
2012-09-19 00:50:48,883 INFO  [utils.component.**ComponentLocator]
(main:null) Unable to find components.xml
2012-09-19 00:50:48,884 INFO  [utils.component.**ComponentLocator]
(main:null) Skipping configuration using components.xml
2012-09-19 00:50:48,885 INFO  [cloud.agent.AgentShell] (main:null)
Implementation Version is 4.0.0.48.20120918191610
2012-09-19 00:50:48,885 INFO  [cloud.agent.AgentShell] (main:null)
agent.properties found at /etc/cloud/agent/agent.**properties
2012-09-19 00:50:48,886 INFO  [cloud.agent.AgentShell] (main:null)
Defaulting to using properties file for storage
2012-09-19 00:50:48,888 INFO  [cloud.agent.AgentShell] (main:null)
Defaulting to the constant time backoff algorithm
2012-09-19 00:50:48,949 INFO  [cloud.agent.Agent] (main:null) id
 is
2012-09-19 00:50:49,055 INFO
  [resource.virtualnetwork.**VirtualRoutingResource] (main:null)
VirtualRoutingResource _scriptDir to use: scripts/network/domr/kvm
2012-09-19 00:50:50,048 INFO
   [kvm.resource.**LibvirtComputingResource]
(main:null) No libvirt.vif.driver specififed. Defaults to
   BridgeVifDriver.
2012-09-19 00:50:50,080 INFO  [cloud.agent.Agent] (main:null)
 Agent
   [id =
new : type = LibvirtComputingResource : zone = 1 : pod = 1 :
  workers =
   5 :
host = 192.168.1.8 : port = 8250
2012-09-19 00:50:50,093 INFO  [utils.nio.NioClient]
   (Agent-Selector:null)
Connecting to 192.168.1.8:8250
2012-09-19 00:50:50,285 INFO  [utils.nio.NioClient]
   (Agent-Selector:null)
SSL: Handshake done
2012-09-19 00:50:50,635 WARN  [utils.nio.Task]
  (Agent-Handler-1:null)
Caught the following exception but pushing on
java.lang.NullPointerException
 at
com.cloud.hypervisor.kvm.**storage.LibvirtStorageAdaptor.**
createStoragePool(**LibvirtStorageAdaptor.java:**562)
 at
com.cloud.hypervisor.kvm.**storage.KVMStoragePoolManager.**
createStoragePool(**KVMStoragePoolManager.java:57)
 at
com.cloud.hypervisor.kvm.**resource.**LibvirtComputingResource.**
initialize(**LibvirtComputingResource.java:**3243)
 at com.cloud.agent.Agent.**sendStartup(Agent.java:320)
 at com.cloud.agent.Agent$**ServerHandler.doTask(Agent.**
java:850)
 at com.cloud.utils.nio.Task.run(**Task.java:83)
 at
java.util.concurrent.**ThreadPoolExecutor.runWorker(**
ThreadPoolExecutor.java:1110)
 at
java.util.concurrent.**ThreadPoolExecutor$Worker.run(**
ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.**java:679)
   
   
Thanks for your help.

Re: Review Request: STT isolation support for KVM

2012-09-19 Thread Tomoe Sugihara


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


Shouldn't this go into a separate vif driver? I guess you just want to use OVS 
on guest network along with linux bridge for the other networks, though.


- Tomoe Sugihara


On Sept. 19, 2012, 11:30 a.m., Hiroaki Kawai wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/7165/
 ---
 
 (Updated Sept. 19, 2012, 11:30 a.m.)
 
 
 Review request for cloudstack.
 
 
 Description
 ---
 
 Adds STT support on KVM host, just like in XenServer. The host os having 
 openvswitch and brcompat kernel module will plug the VM to openvswitch port 
 through general brctl interface calls.
 
 
 Diffs
 -
 
   
 plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
  cf4de09 
   scripts/vm/network/vnet/setupLswitch.sh PRE-CREATION 
   server/src/com/cloud/hypervisor/HypervisorGuruBase.java 242852f 
 
 Diff: https://reviews.apache.org/r/7165/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Hiroaki Kawai

Re: Still cannot add KVM host

I'll verify that.  I know the secondary storage is available... didn't try
the primary one - but both primary and secondary are located on the same
server.

On Wed, Sep 19, 2012 at 9:54 AM, Marcus Sorensen shadow...@gmail.comwrote:

 That create storage pool failure usually hits me when I have some sort of
 primary storage defined which doesn't work. Most recently when I set up a
 sharedmountpoint pool without creating the mount directory. Are you sure
 that all of your primary storage is available to this host ?
 On Sep 19, 2012 6:28 AM, Busy Dev busyd...@gmail.com wrote:

  I also checked my agent.properties file and all the settings are there
  (with the appropriate values).
 
  On Wed, Sep 19, 2012 at 8:19 AM, Busy Dev busyd...@gmail.com wrote:
 
   I am using CentOS 6.3.
  
   I also ran into an issue with cgconfig a while back when I was trying
 to
   setup 3.02 and had this fix for it in /etc/cgconfig.conf:
  
   *group virt {
   cpu {
  cpu.shares = 9216;
   }
   }*
  
  
  
  
   On Wed, Sep 19, 2012 at 2:49 AM, Marcus Sorensen shadow...@gmail.com
  wrote:
  
   Did he say which distribution? I recently submitted a fix for cent
 6.3,
  it
   wasn't setting up the cgconfig service.
  
   I second drumming cloud-setup-agent. If you look at the management
  server
   log you should see the exact command/arcs being sent to the host. Copy
   that
   and run it manually to see where it fails.
   On Sep 19, 2012 12:23 AM, Kelcey Jamison-Damage kel...@bbits.ca
   wrote:
  
Have you tried running cloud-setup-agent on the host? If so what is
  its
output?
   
Are you building 3.0.2 or 4.0 source?
   
   
   
Busy Dev busyd...@gmail.com wrote:
   
Thanks - I checked my KVM host and that directory already exists.



On Wed, Sep 19, 2012 at 1:07 AM, KAWAI Hiroaki 
   ka...@stratosphere.co.jp
wrote:

 Hi,
 I run into the same problem. On KVM host OS, try:

 mkdir /var/lib/libvirt/images/

 logging will be added with patch
   https://reviews.apache.org/r/**7153/
https://reviews.apache.org/r/7153/



 (2012/09/19 14:00), Busy Dev wrote:

 I've been able to setup my development environment and am now
   trying to
 setup the management server.  However, when I launch
 Cloudstack,
   I am
 unable to add a KVM host.

 The error in the log file

 2012-09-19 00:50:48,883 INFO
  [utils.component.**ComponentLocator]
 (main:null) Unable to find components.xml
 2012-09-19 00:50:48,884 INFO
  [utils.component.**ComponentLocator]
 (main:null) Skipping configuration using components.xml
 2012-09-19 00:50:48,885 INFO  [cloud.agent.AgentShell]
 (main:null)
 Implementation Version is 4.0.0.48.20120918191610
 2012-09-19 00:50:48,885 INFO  [cloud.agent.AgentShell]
 (main:null)
 agent.properties found at /etc/cloud/agent/agent.**properties
 2012-09-19 00:50:48,886 INFO  [cloud.agent.AgentShell]
 (main:null)
 Defaulting to using properties file for storage
 2012-09-19 00:50:48,888 INFO  [cloud.agent.AgentShell]
 (main:null)
 Defaulting to the constant time backoff algorithm
 2012-09-19 00:50:48,949 INFO  [cloud.agent.Agent] (main:null) id
  is
 2012-09-19 00:50:49,055 INFO
   [resource.virtualnetwork.**VirtualRoutingResource] (main:null)
 VirtualRoutingResource _scriptDir to use:
 scripts/network/domr/kvm
 2012-09-19 00:50:50,048 INFO
[kvm.resource.**LibvirtComputingResource]
 (main:null) No libvirt.vif.driver specififed. Defaults to
BridgeVifDriver.
 2012-09-19 00:50:50,080 INFO  [cloud.agent.Agent] (main:null)
  Agent
[id =
 new : type = LibvirtComputingResource : zone = 1 : pod = 1 :
   workers =
5 :
 host = 192.168.1.8 : port = 8250
 2012-09-19 00:50:50,093 INFO  [utils.nio.NioClient]
(Agent-Selector:null)
 Connecting to 192.168.1.8:8250
 2012-09-19 00:50:50,285 INFO  [utils.nio.NioClient]
(Agent-Selector:null)
 SSL: Handshake done
 2012-09-19 00:50:50,635 WARN  [utils.nio.Task]
   (Agent-Handler-1:null)
 Caught the following exception but pushing on
 java.lang.NullPointerException
  at
 com.cloud.hypervisor.kvm.**storage.LibvirtStorageAdaptor.**
 createStoragePool(**LibvirtStorageAdaptor.java:**562)
  at
 com.cloud.hypervisor.kvm.**storage.KVMStoragePoolManager.**
 createStoragePool(**KVMStoragePoolManager.java:57)
  at

 com.cloud.hypervisor.kvm.**resource.**LibvirtComputingResource.**
 initialize(**LibvirtComputingResource.java:**3243)
  at com.cloud.agent.Agent.**sendStartup(Agent.java:320)
  at
 com.cloud.agent.Agent$**ServerHandler.doTask(Agent.**
 java:850)
  at com.cloud.utils.nio.Task.run(**Task.java:83)
  at
 java.util.concurrent.**ThreadPoolExecutor.runWorker(**
 ThreadPoolExecutor.java:1110)
  at

Management server freezes loading vsphere server component

2012-09-19 Thread Pedro Navarro Pérez

Hi all,

I've installed a fresh version of non-oss (from
jenkins.cloudstack.org/job/build-4.0-nonoss-rhel63/) and It freezes
when loading vSphere server:

2012-09-10 22:22:03,139 INFO  [utils.component.ComponentLocator]
(main:null) Instantiating Adapter: VShpereServer

Anyone has the same problem?

Thanks

Re: Management server freezes loading vsphere server component

2012-09-19 Thread Rohit Yadav


On 19-Sep-2012, at 8:27 PM, Pedro Navarro Pérez pedn...@gmail.com wrote:

 Hi all,
 
 I've installed a fresh version of non-oss (from
 jenkins.cloudstack.org/job/build-4.0-nonoss-rhel63/) and It freezes
 when loading vSphere server:
 
 2012-09-10 22:22:03,139 INFO  [utils.component.ComponentLocator]
 (main:null) Instantiating Adapter: VShpereServer
 
 Anyone has the same problem?

For the nonoss plugins to work, you're required to install the nonoss plugins 
dependency jars.

For VMWare, you're required to install vmware-vim, vmware-vim25, 
vmware-apputils jars. CloudStack nonoss expects them in /usr/share/java or 
within classpath.
Since, they are nonoss/proprietary you get them from VMWare/vSphere support.

Even then if that does not work, please share the logs. Find them in 
/var/log/cloud/*

 
 Thanks

Review Request: CLOUDSTACK-84: FIX NPE error in listRouter etc. after deleting a user project.

2012-09-19 Thread Rohit Yadav


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

Review request for cloudstack, Abhinandan Prateek, Kishan Kavala, Nitin Mehta, 
Alena Prokharchyk, and Alex Huang.


Description
---

Domain ACL information should be valid even if account entry is marked
removed. Patch fixes how account is obtained based on accountId, it
finds among those entries which are marked deleted.

In case of project deletion, the project is marked removed first and
then each of its elements are cleared/cleaned/deleted. While deleting
network and router it failed because ACL only checks accounts which are
not marked deleted.

Download original patch and git am patch: 
http://patchbin.baagi.org/p?id=40pdym


This addresses bug CLOUDSTACK-84.


Diffs
-

  server/src/com/cloud/acl/DomainChecker.java 6bc2cd3 
  server/src/com/cloud/user/dao/AccountDao.java 3b7fa66 
  server/src/com/cloud/user/dao/AccountDaoImpl.java 7300bb1 

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


Testing
---


Thanks,

Rohit Yadav

[jira] [Commented] (CLOUDSTACK-84) Getting Null Pointer Excpetion while executing listRouters command after deleting a user project.


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458758#comment-13458758
 ] 

Rohit Yadav commented on CLOUDSTACK-84:
---

On RB: https://reviews.apache.org/r/7168/

 Getting Null Pointer Excpetion while executing listRouters command after 
 deleting a user project.
 -

 Key: CLOUDSTACK-84
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-84
 Project: CloudStack
  Issue Type: Bug
  Components: Network Controller
Affects Versions: pre-4.0.0
 Environment: Management sever : Rhel 6.3
 Setup : Advanced
 Host : XenServer 6.0.2
 Build Details :-
 Git Revision: 03df2fa9dd45c938f72cd1866044b09d1b0cc978
 Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git
Reporter: Abhinav Roy
Assignee: Rohit Yadav
 Fix For: pre-4.0.0

 Attachments: api-server.log, Cloudstack-84.jpg, management-server.log


 Steps to reproduce :
 -
 1. Deploy a CS advanced networking setup.
 2. create a sub-domain 'Domain1' under 'ROOT' domain.
 3. Create 2 users - user1 and user2 under 'Domain1'.
 4. login as user1 and create a project. Add user2 to the project.
 5. Create 2 VMs , one as user1 and the other as user2.
 6. Login as user1(project admin) and delete the project.
 Expected Behaviour :
 --
 The project deletion along with deletion of all the resources associated with 
 the project should be successful and no error should be seen.
 Observed Behaviour :
 --
 1. Got this Exception during project deletion :
 2012-09-12 17:22:30,545 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-26:job-40) 
 Attempting to destroy router 82012-09-12 17:22:30,547 WARN  
 [cloud.network.NetworkManagerImpl] (Job-Executor-26:job-40) Unable to 
 complete destroy of the network due to element: 
 VirtualRoutercom.cloud.exception.PermissionDeniedException: Acct[6-user4] 
 does not have permission to operate with resource VM[DomainRouter|r-8-VM] 
at com.cloud.acl.DomainChecker.checkAccess(DomainChecker.java:128)
 at com.cloud.user.AccountManagerImpl.checkAccess(AccountManagerImpl.java:353) 
at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.destroyRouter(VirtualNetworkApplianceManagerImpl.java:381)
 at 
 com.cloud.network.element.VirtualRouterElement.destroy(VirtualRouterElement.java:641)
 at 
 com.cloud.network.NetworkManagerImpl.destroyNetwork(NetworkManagerImpl.java:3554)
 at 
 com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34)   
  at 
 com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:587) 
at 
 com.cloud.user.AccountManagerImpl.deleteAccount(AccountManagerImpl.java:475)  
   at 
 com.cloud.projects.ProjectManagerImpl.cleanupProject(ProjectManagerImpl.java:305)
 at 
 com.cloud.projects.ProjectManagerImpl.deleteProject(ProjectManagerImpl.java:286)
 at 
 com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34)   
  at 
 com.cloud.projects.ProjectManagerImpl.deleteProject(ProjectManagerImpl.java:265)
 at 
 com.cloud.event.ActionEventCallback.intercept(ActionEventCallback.java:36)
 at 
 com.cloud.api.commands.DeleteProjectCmd.execute(DeleteProjectCmd.java:69) 
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:138)at 
 com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:449)   
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)   
  at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:679)2012-09-12 17:22:30,548 WARN  
 [cloud.user.AccountManagerImpl] (Job-Executor-26:job-40) Unable to destroy 
 network Ntwk[206|Guest|8] as a part of account id=8 cleanup.2012-09-12 
 17:22:30,548 DEBUG [cloud.user.AccountManagerImpl] (Job-Executor-26:job-40) 
 Deleting vpcs for account 8
 2012-09-12 17:22:30,550 DEBUG [cloud.user.AccountManagerImpl] 
 (Job-Executor-26:job-40) Deleting site-to-site VPN customer gateways for 
 account 8
 2012-09-12 17:22:30,551 INFO  [cloud.user.AccountManagerImpl] 
 (Job-Executor-26:job-40) Cleanup for account 8 is needed.
 2. After the deletion was done, when I tried to list the virtual routers, i 
 got the following Null pointer exception
 Exception while executing ListRoutersCmd:

Re: Jira workflow...

2012-09-19 Thread Daniel Kulp


On Sep 17, 2012, at 6:15 PM, David Nalley da...@gnsa.us wrote:

 On Mon, Sep 17, 2012 at 5:47 PM, Alex Huang alex.hu...@citrix.com wrote:
 David,
 
 Is there a way to add a new step to Jira.  I think we should add a In 
 Review step to indicate the bug has been submitted for review for the 
 people who needs to do that.  It shouldn't be Resolved until the review 
 has been done.  I tried to add it but either I don't have permission or I 
 can't find a way to do it.
 
 I don't seem to have a way to fix this either - I will continue
 looking and perhaps ask around. I suspect it requires more infra karma
 than I possess

Slightly surprised.  Both of you are listed as admins for the CLOUDSTACK JIRA 
project.  Thus, I would have expected you to be able to.   In any case, you can 
ping me on irc (dkulp) and I can try and help out.  I've never done anything 
related to workflows in JIRA, but I'm certainly willing to try and figure it 
out.:-)


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

[jira] [Assigned] (CLOUDSTACK-135) Extraneous license file in utils


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

Chip Childers reassigned CLOUDSTACK-135:


Assignee: Chip Childers

 Extraneous license file in utils
 

 Key: CLOUDSTACK-135
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-135
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: David Nalley
Assignee: Chip Childers
 Fix For: 4.0.0


 utils/LICENSE contains an (AFAICT) extraneous copy of ASLv2. This should be 
 handled by the top level LICENSE and NOTICE 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] [Closed] (CLOUDSTACK-135) Extraneous license file in utils


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

Chip Childers closed CLOUDSTACK-135.



 Extraneous license file in utils
 

 Key: CLOUDSTACK-135
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-135
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: David Nalley
Assignee: Chip Childers
 Fix For: 4.0.0


 utils/LICENSE contains an (AFAICT) extraneous copy of ASLv2. This should be 
 handled by the top level LICENSE and NOTICE 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] [Updated] (CLOUDSTACK-104) Failed to update SSL Certificate

2012-09-19 Thread Paco Medina (JIRA)


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

Paco Medina updated CLOUDSTACK-104:
---

Attachment: dump.pcap

TCPDump

  Failed to update SSL Certificate
 -

 Key: CLOUDSTACK-104
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-104
 Project: CloudStack
  Issue Type: Bug
  Components: Management Server
Affects Versions: pre-4.0.0
 Environment: Centos 6.3 and CS 3.0.2
Reporter: Paco Medina
Assignee: Rohit Yadav
Priority: Blocker
 Fix For: pre-4.0.0

 Attachments: dump.pcap


 Hello,
 After many tries, many install from scratch, clean install, there is no way 
 to install SSL certificate for Console VM's.
 Error says :  Failed to update SSL Certificate
 No logs found but the management serveur give a RST.
 I've dump (PCAP), a public host to reproduce the issue.
 Regards,
 Paco Medina

--
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-104) Failed to update SSL Certificate

2012-09-19 Thread Paco Medina (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458786#comment-13458786
 ] 

Paco Medina commented on CLOUDSTACK-104:


I find a workaround. If I connect via SSH and port forward to the mgmt-host or 
other host on the same LAN :

ssh mgmt-host -L 8080:127.0.0.1:8080

The I manage via URL http://127.0.0.1:8080/client and everything was find.

You can see the all API call with tcpdump.

  Failed to update SSL Certificate
 -

 Key: CLOUDSTACK-104
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-104
 Project: CloudStack
  Issue Type: Bug
  Components: Management Server
Affects Versions: pre-4.0.0
 Environment: Centos 6.3 and CS 3.0.2
Reporter: Paco Medina
Assignee: Rohit Yadav
Priority: Blocker
 Fix For: pre-4.0.0

 Attachments: dump.pcap


 Hello,
 After many tries, many install from scratch, clean install, there is no way 
 to install SSL certificate for Console VM's.
 Error says :  Failed to update SSL Certificate
 No logs found but the management serveur give a RST.
 I've dump (PCAP), a public host to reproduce the issue.
 Regards,
 Paco Medina

--
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] [Comment Edited] (CLOUDSTACK-104) Failed to update SSL Certificate

2012-09-19 Thread Paco Medina (JIRA)

[
https://issues.apache.org/jira/browse/CLOUDSTACK-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458786#comment-13458786
]

Paco Medina edited comment on CLOUDSTACK-104 at 9/20/12 3:11 AM:
-

I find a workaround. If I connect via SSH and port forward to the mgmt-host or
other host on the same LAN :

ssh mgmt-host -L 8080:127.0.0.1:8080

Then I manage via URL http://127.0.0.1:8080/client and everything is find.

You can see the all API call with tcpdump.

was (Author: paco_medina):
I find a workaround. If I connect via SSH and port forward to the mgmt-host
or other host on the same LAN :

ssh mgmt-host -L 8080:127.0.0.1:8080

The I manage via URL http://127.0.0.1:8080/client and everything was find.

You can see the all API call with tcpdump.

Failed to update SSL Certificate
-

Key: CLOUDSTACK-104
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-104
Project: CloudStack
Issue Type: Bug
Components: Management Server
Affects Versions: pre-4.0.0
Environment: Centos 6.3 and CS 3.0.2
Reporter: Paco Medina
Assignee: Rohit Yadav
Priority: Blocker
Fix For: pre-4.0.0

Attachments: dump.pcap

Hello,
After many tries, many install from scratch, clean install, there is no way
to install SSL certificate for Console VM's.
Error says : Failed to update SSL Certificate
No logs found but the management serveur give a RST.
I've dump (PCAP), a public host to reproduce the issue.
Regards,
Paco Medina

--
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: Reminder IRC Meeting Tomorrow (Wednesday, 19 September 2012) at 17:00 UTC

2012-09-19 Thread Sudha Ponnaganti

- If we have a date of Oct 5th, Would like to see RC1 delivered on 28th. 
- This is a little deviation from what I read from Ewan's mail related to 
release plan. He mentioned that RC1 would be delivered on 09/06 and we use that 
to run 1 cycle. But all dev work hasn't been complete at that time and I 
consider the drops pre-release candidate drops.
-if we can tag the drop on 28th as RC1 ( of course need to close all the 
pending items in Dev and QA queue by then), QA can run one final cycle  by Oct 
5th

Thanks
/Sudha

-Original Message-
From: Wido den Hollander [mailto:w...@widodh.nl] 
Sent: Tuesday, September 18, 2012 1:54 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Reminder IRC Meeting Tomorrow (Wednesday, 19 September 2012) at 
17:00 UTC



On 18-09-12 22:13, Joe Brockmeier wrote:
 Hi all,

 Just a reminder, we have the weekly IRC meeting tomorrow at 17:00 UTC 
 (that's 13:00 Eastern/10:00 Pacific) in #Cloudstack-Meeting on Freenode.


I won't be able to make it this week, sorry guys!

Just a suggestion I want to make for a topic:

No flame intended to anybody, we're all working very hard, but when is
4.0 RC1 coming out? We can't keep pushing it back.

A date should be set imho.

Wido

 Last week's minutes/log are here:

 Full minutes:
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Meet
 ing+12+September+2012+Minutes
 Full log:
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Meet
 ing+12+September+2012+Log

 (Thanks John!)

 As always - reminder that the meeting is for discussion in real time, 
 but topics needing a project decision are always discussed and decided 
 on the mailing list.

 Thanks!

 Joe

Re: Still cannot add KVM host

I'm using NFS for both primary and secondary (which are hosted by the same
machine that hosts the management server).


On Wed, Sep 19, 2012 at 12:13 PM, Kelceydamage@bbits kel...@bbits.cawrote:

 I just caught that error in the logs too.

 Might I ask what solution your running for primary storage? And how it's
 connected to ACS?

 Sent from my iPhone

 On Sep 19, 2012, at 7:45 AM, Busy Dev busyd...@gmail.com wrote:

  I'll verify that.  I know the secondary storage is available... didn't
 try
  the primary one - but both primary and secondary are located on the same
  server.

Re: Review Request: CLOUDSTACK-43 : Jenkins build process needs to allow for setting the appropriate version number within the built JARs.

2012-09-19 Thread Chip Childers



 On Sept. 14, 2012, 1:26 p.m., Chip Childers wrote:
  Generally, I think that all of the child projects should inherit their 
  version from the parent project's version.  This can be accomplished by 
  referencing the parent version as a variable.  I'm not a maven guy, but I 
  looked at a few samples out there, and this appears to be the right way to 
  go.
  
  However, all that being said...  Edison's comment earlier about this not 
  actually being needed is important. If ant is doing things correctly, then 
  this doesn't actually matter much.  IMO, I would like to see the maven 
  project versions get that inheritance, so that it's already in place for 
  when we convert from ant build tasks to maven builds completely.
  
  Can you make the changes I've suggested (including the note about not 
  modifying the tomcat7 plugin version), and then resubmit the patch?
  
  In the meantime, CLOUDSTACK-43 may be able to be closed already.
  
  Edison, do you agree?
 
 edison su wrote:
 Yes, I agree. right now, we are using ant to build JARs, so the version 
 number in pom.xml doesn't bother us at all. After we switch to use maven to 
 build JARs, we can change the the version number.

Pradeep - The changes I suggested would be good to have ahead of a change to 
use maven for the actual build phase anyway.  Could you make stuff inherit from 
the parent project for version, and correct the tomcat7 plugin version?  I 
think we should pull in the change with those adjustments.


- Chip


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


On Sept. 14, 2012, 12:36 p.m., Pradeep Soundararajan wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/7083/
 ---
 
 (Updated Sept. 14, 2012, 12:36 p.m.)
 
 
 Review request for cloudstack, Chip Childers and edison su.
 
 
 Description
 ---
 
 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). 
 
  Removed the occurrences of SNAPSHOT
 
 
 Diffs
 -
 
   agent/pom.xml a559580 
   api/pom.xml db14775 
   awsapi/pom.xml a583384 
   client/pom.xml 50b85e9 
   cloud.spec 02aa64f 
   console-proxy/pom.xml 8bfb753 
   core/pom.xml 510cb04 
   deps/XenServerJava/pom.xml 1337514 
   deps/pom.xml be30c9a 
   patches/pom.xml d62fc86 
   plugins/deployment-planners/user-concentrated-pod/pom.xml ca2fae1 
   plugins/deployment-planners/user-dispersing/pom.xml 6e1ffc6 
   plugins/file-systems/netapp/pom.xml f10e5a4 
   plugins/host-allocators/random/pom.xml ad66c0e 
   plugins/hypervisors/kvm/pom.xml 2d1a001 
   plugins/hypervisors/ovm/pom.xml a8b23d0 
   plugins/hypervisors/vmware/pom.xml 435ae38 
   plugins/hypervisors/xen/pom.xml bf38e47 
   plugins/network-elements/elastic-loadbalancer/pom.xml c1ab2c5 
   plugins/network-elements/f5/pom.xml 0cba48c 
   plugins/network-elements/juniper-srx/pom.xml 38a2b55 
   plugins/network-elements/midokura-midonet/pom.xml 7f2e2d3 
   plugins/network-elements/netscaler/pom.xml 377e6e0 
   plugins/network-elements/nicira-nvp/pom.xml 37c3a3a 
   plugins/network-elements/ovs/pom.xml 02d455c 
   plugins/pom.xml 206d4a1 
   plugins/storage-allocators/random/pom.xml 6cb60cd 
   plugins/user-authenticators/ldap/pom.xml 7facc3f 
   plugins/user-authenticators/md5/pom.xml 1dac92d 
   plugins/user-authenticators/plain-text/pom.xml a4280a3 
   pom.xml 972d645 
   server/pom.xml f7178d8 
   test/pom.xml f70a89f 
   usage/pom.xml 92e5e72 
   utils/pom.xml e8d7827 
   vmware-base/pom.xml 1dabe83 
   wscript f1c9b62 
   wscript_build 2de698c 
 
 Diff: https://reviews.apache.org/r/7083/diff/
 
 
 Testing
 ---
 
 Able to execute mvn install successfully after the changes...
 
 
 Thanks,
 
 Pradeep Soundararajan

[jira] [Commented] (CLOUDSTACK-104) Failed to update SSL Certificate

[
https://issues.apache.org/jira/browse/CLOUDSTACK-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458813#comment-13458813
]

Rohit Yadav commented on CLOUDSTACK-104:

I think your firewall is blocking ports used by CS management server. Next goto
Global settings-search for host and set it to your IP (in case you have
multiple NICs CS fails to pick the correct mgmt IP and somtimes sets localhost).

From the tcp dump I see
- a GET on
http://cloud-mgmt.ouitech.adm:8080/client/api?command=uploadCustomCertificateresponse=jsonsessionkey=somekeycertificate=somedata
- GET request to listPods, listCapacity, listHosts etc.

From the UI, you should be able to upload a X.509 compliant SSL key from
Infrastructure-topbar. Hope that helps. Let's know if you're still not able
to update SSL key for your mgmt server. Note: this API is to set SSL key for
the mgmt server (https to mgmt server and secure all the traffic from/to the
mgmt server API calls) and not for a user VM.

Failed to update SSL Certificate
-

Attachments: dump.pcap

Re: [ASFCS40][DISCUSS] How should we move forward to resolution on the config files in patches? Was: Re: [ASFCS40] Configuration file licensing followup

2012-09-19 Thread Chip Childers

On Tue, Sep 18, 2012 at 6:16 PM, David Nalley da...@gnsa.us wrote:
 On Tue, Sep 18, 2012 at 12:34 PM, Chip Childers
 chip.child...@sungard.com wrote:
 On Tue, Sep 18, 2012 at 10:28 AM, David Nalley da...@gnsa.us wrote:
 On Tue, Sep 18, 2012 at 10:24 AM, Chip Childers
 chip.child...@sungard.com wrote:
 On Fri, Sep 14, 2012 at 10:55 AM, David Nalley da...@gnsa.us wrote:
 On Fri, Sep 14, 2012 at 8:59 AM, Chip Childers
 chip.child...@sungard.com wrote:
 On Thu, Sep 13, 2012 at 2:41 PM, David Nalley da...@gnsa.us wrote:
 On Thu, Sep 13, 2012 at 2:36 PM, Noah Slater nsla...@tumbolia.org 
 wrote:
 Saying that configuration files, in all cases, are not copywritable 
 because
 that are, on the whole, not as complex as code is like saying that blog
 posts, in all cases, are not copywritable because they are, on the 
 whole,
 not as complex as books.

 The law is much more nuanced than that. There is no way we can say, up
 front, whether a configuration file is protected by copywrite or not. 
 The
 unwillingness to commit to anything on legal-discuss is an indication 
 of
 this. (It was made explicit that with a vague question, there will 
 only be
 vague answers.)

 It might be better to actually document what we have, and then present 
 that
 to legal discuss and take it from there.

 Let's get concrete.

 We should put together a list of each config file path, along with
 information such as:

 * Size of file
 * Complexity (key/value, code snippets, what?)
 * Copyright notice or license header?
 * License of project it (may) have been taken from
 * Origin (Citrix, upstream project, unknown?)

 Once we have a complete picture, I think we can talk about how to 
 proceed.

 (And hopefully propose a guideline for future config files.)

 I certainly do not think we are in a position to write of an entire
 category of data as being uncopywritable.

 I am happy to run this to pursue this with legal too, but I think we 
 need a
 better view of what we're dealing with.

 Thoughts?



 Alright, I'll start working on compiling this.

 --David


 David,

 Do you want to divide and conquer on this task?  I'd be happy to help.

 -chip


 Happy to have the help
 --David


 David,

 I've gotten as far as I can with the list (via the google spreadsheet
 you shared).  I think the next step is to send it out for broader
 review.  We are going to need the help of the folks that might have
 originally added the config file / script to the project.

 -chip

 Sorry I haven't been of much help of late.
 Shall we move it to the wiki?

 --David


 That makes sense.  If you get to it before me, fantastic...  but
 otherwise I'll move it over tomorrow.

 -chip



 It's here:
 https://cwiki.apache.org/CLOUDSTACK/config-file-listing.html

 --David


Hi all,

I've been out sick the last several days, so I didn't get to this
sooner.  I'll start up threads over the next couple of hours on each
of the areas where we need advice / help from others on the list.

-chip

[jira] [Created] (CLOUDSTACK-136) unit test failing on axis-deploy

2012-09-19 Thread David Nalley (JIRA)

David Nalley created CLOUDSTACK-136:
---

 Summary: unit test failing on axis-deploy
 Key: CLOUDSTACK-136
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-136
 Project: CloudStack
  Issue Type: Bug
  Components: Test
Affects Versions: pre-4.0.0
Reporter: David Nalley
Assignee: Rohit Yadav
Priority: Critical
 Fix For: pre-4.0.0


Unit tests for 4.0 are failing at the deploy-axis stage: 

See: http://jenkins.cloudstack.org/job/test-junit-4.0

deploy-axis:

BUILD FAILED
/var/lib/jenkins/workspace/test-junit-4.0/build/build-aws-api.xml:174: src 
'/var/lib/jenkins/workspace/test-junit-4.0/deps/awsapi-lib/axis2-webapp-1.5.1.war'
 doesn't exist.

Total time: 5 minutes 2 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Performance: Percentage of errors greater or equal than 0% sets the build as 
unstable
Performance: Percentage of errors greater or equal than 0% sets the build as 
failure
Performance: Recording JUnit reports 'unittest/TEST-*.xml'
Sending e-mails to: cloudstack-comm...@incubator.apache.org 
murali.re...@citrix.com chip.child...@gmail.com t...@apache.org 
alena.prokharc...@citrix.com disheng...@gmail.com w...@widodh.nl 
alex.hu...@citrix.com sudi...@gmail.com nitin.me...@citrix.com 
sheng.y...@citrix.com edi...@citrix.com jessica.w...@citrix.com 
pra...@cloud.com mice_...@tcloudcomputing.com agneya2...@yahoo.com 
chirad...@apache.org brian.fede...@citrix.com anth...@cloud.com 
pranav.sax...@citrix.com da...@gnsa.us frank.zh...@citrix.com
build-cloudstack-4.0-rhel6.3 is disabled. Triggering skipped
Finished: FAILURE




--
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

[ASFCS40] New source code RC available (4.0.0.RC2)

2012-09-19 Thread Chip Childers

All,

For those of you helping review the source code for legal / policy
compliance, I've posted a new source code only RC here:
http://people.apache.org/~chipchilders/cloudstack/4.0/

As discussed previously on the list, we will rely on community support
to host the binary builds.  This includes the development builds that
are being used by Citrix QA via jenkins.cloudstack.org, and the
hosting of RPM and DEB packages by Wido.

-chip

[jira] [Created] (CLOUDSTACK-137) Establish legal use of patches/systemvm/debian/config/etc/apache2/httpd.conf

Chip Childers created CLOUDSTACK-137:


 Summary: Establish legal use of 
patches/systemvm/debian/config/etc/apache2/httpd.conf
 Key: CLOUDSTACK-137
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-137
 Project: CloudStack
  Issue Type: New Feature
Reporter: Chip Childers
Priority: Blocker


We need to establish if the following file is one of the following:
1) Written specifically for CloudStack
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it.

patches/systemvm/debian/config/etc/apache2/httpd.conf

--
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-137) Establish legal use of patches/systemvm/debian/config/etc/apache2/httpd.conf


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

Chip Childers updated CLOUDSTACK-137:
-

Issue Type: Bug  (was: New Feature)

 Establish legal use of patches/systemvm/debian/config/etc/apache2/httpd.conf
 

 Key: CLOUDSTACK-137
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-137
 Project: CloudStack
  Issue Type: Bug
Reporter: Chip Childers
Priority: Blocker

 We need to establish if the following file is one of the following:
 1) Written specifically for CloudStack
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it.
 patches/systemvm/debian/config/etc/apache2/httpd.conf

--
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] [Created] (CLOUDSTACK-138) Establish legal use of patches/systemvm/debian/config/etc/apache2/ports.conf

Chip Childers created CLOUDSTACK-138:


 Summary: Establish legal use of 
patches/systemvm/debian/config/etc/apache2/ports.conf
 Key: CLOUDSTACK-138
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-138
 Project: CloudStack
  Issue Type: New Feature
Reporter: Chip Childers
Priority: Blocker


We need to establish if the following file is one of the following:
1) Written specifically for CloudStack
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it.

patches/systemvm/debian/config/etc/apache2/httpd.conf

--
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-138) Establish legal use of patches/systemvm/debian/config/etc/apache2/ports.conf


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

Chip Childers updated CLOUDSTACK-138:
-

Description: 
We need to establish if the following file is one of the following:
1) Written specifically for CloudStack
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it.

patches/systemvm/debian/config/etc/apache2/ports.conf

  was:
We need to establish if the following file is one of the following:
1) Written specifically for CloudStack
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it.

patches/systemvm/debian/config/etc/apache2/httpd.conf


 Establish legal use of patches/systemvm/debian/config/etc/apache2/ports.conf
 

 Key: CLOUDSTACK-138
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-138
 Project: CloudStack
  Issue Type: New Feature
Reporter: Chip Childers
Priority: Blocker

 We need to establish if the following file is one of the following:
 1) Written specifically for CloudStack
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it.
 patches/systemvm/debian/config/etc/apache2/ports.conf

--
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-138) Establish legal use of patches/systemvm/debian/config/etc/apache2/ports.conf


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

Chip Childers updated CLOUDSTACK-138:
-

Issue Type: Bug  (was: New Feature)

 Establish legal use of patches/systemvm/debian/config/etc/apache2/ports.conf
 

 Key: CLOUDSTACK-138
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-138
 Project: CloudStack
  Issue Type: Bug
Reporter: Chip Childers
Priority: Blocker

 We need to establish if the following file is one of the following:
 1) Written specifically for CloudStack
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it.
 patches/systemvm/debian/config/etc/apache2/ports.conf

--
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-138) Establish legal use of patches/systemvm/debian/config/etc/apache2/ports.conf


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

Chip Childers updated CLOUDSTACK-138:
-

Affects Version/s: pre-4.0.0

 Establish legal use of patches/systemvm/debian/config/etc/apache2/ports.conf
 

 Key: CLOUDSTACK-138
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-138
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker

 We need to establish if the following file is one of the following:
 1) Written specifically for CloudStack
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it.
 patches/systemvm/debian/config/etc/apache2/ports.conf

--
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-137) Establish legal use of patches/systemvm/debian/config/etc/apache2/httpd.conf


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

Chip Childers updated CLOUDSTACK-137:
-

Affects Version/s: pre-4.0.0

 Establish legal use of patches/systemvm/debian/config/etc/apache2/httpd.conf
 

 Key: CLOUDSTACK-137
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-137
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker

 We need to establish if the following file is one of the following:
 1) Written specifically for CloudStack
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it.
 patches/systemvm/debian/config/etc/apache2/httpd.conf

--
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] [Created] (CLOUDSTACK-139) Can we remove patches/systemvm/debian/config/etc/apache2/vhostexmaple.conf

Chip Childers created CLOUDSTACK-139:


 Summary: Can we remove 
patches/systemvm/debian/config/etc/apache2/vhostexmaple.conf
 Key: CLOUDSTACK-139
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-139
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker


In reviewing the contents of the patches folder, David and I are wondering if 
patches/systemvm/debian/config/etc/apache2/vhostexmaple.conf can be removed.

If not, we need to establish the original source of this file.

--
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-139) Can we remove patches/systemvm/debian/config/etc/apache2/[vhostexmaple.conf, sites-available/default, sites-available/default-ssl]


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

Chip Childers updated CLOUDSTACK-139:
-

Description: 
In reviewing the contents of the patches folder, David and I are wondering if 
the following files can be removed:

patches/systemvm/debian/config/etc/apache2/sites-available/default
patches/systemvm/debian/config/etc/apache2/vhostexmaple.conf
patches/systemvm/debian/config/etc/apache2/sites-available/default-ssl

If not, we need to establish the original source of these files.

  was:
In reviewing the contents of the patches folder, David and I are wondering if 
patches/systemvm/debian/config/etc/apache2/vhostexmaple.conf can be removed.

If not, we need to establish the original source of this file.

Summary: Can we remove 
patches/systemvm/debian/config/etc/apache2/[vhostexmaple.conf, 
sites-available/default, sites-available/default-ssl]  (was: Can we remove 
patches/systemvm/debian/config/etc/apache2/vhostexmaple.conf)

 Can we remove patches/systemvm/debian/config/etc/apache2/[vhostexmaple.conf, 
 sites-available/default, sites-available/default-ssl]
 --

 Key: CLOUDSTACK-139
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-139
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker

 In reviewing the contents of the patches folder, David and I are wondering if 
 the following files can be removed:
 patches/systemvm/debian/config/etc/apache2/sites-available/default
 patches/systemvm/debian/config/etc/apache2/vhostexmaple.conf
 patches/systemvm/debian/config/etc/apache2/sites-available/default-ssl
 If not, we need to establish the original source of these 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] [Created] (CLOUDSTACK-140) Establish legal use of patches/systemvm/debian/config/etc/dnsmasq.conf

Chip Childers created CLOUDSTACK-140:


 Summary: Establish legal use of 
patches/systemvm/debian/config/etc/dnsmasq.conf
 Key: CLOUDSTACK-140
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-140
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker


We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/config/etc/dnsmasq.conf

--
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] [Created] (CLOUDSTACK-141) Establish legal use of patches/systemvm/debian/config/etc/haproxy/haproxy.cfg

Chip Childers created CLOUDSTACK-141:


 Summary: Establish legal use of 
patches/systemvm/debian/config/etc/haproxy/haproxy.cfg
 Key: CLOUDSTACK-141
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-141
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker


We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/config/etc/dnsmasq.conf

--
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-141) Establish legal use of patches/systemvm/debian/config/etc/haproxy/haproxy.cfg


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

Chip Childers updated CLOUDSTACK-141:
-

Description: 
We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/config/etc/haproxy/haproxy.cfg

  was:
We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/config/etc/dnsmasq.conf


 Establish legal use of patches/systemvm/debian/config/etc/haproxy/haproxy.cfg
 -

 Key: CLOUDSTACK-141
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-141
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker

 We need to establish if the following file is one of the following: 
 1) Written specifically for CloudStack 
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license 
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it. 
 patches/systemvm/debian/config/etc/haproxy/haproxy.cfg

--
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] [Created] (CLOUDSTACK-142) Can patches/systemvm/debian/config/etc/httpd/conf/httpd.conf be removed?

Chip Childers created CLOUDSTACK-142:


 Summary: Can 
patches/systemvm/debian/config/etc/httpd/conf/httpd.conf be removed?
 Key: CLOUDSTACK-142
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-142
 Project: CloudStack
  Issue Type: Bug
Reporter: Chip Childers
Priority: Blocker


David notes that Debian doesn't use this file.  Can it be removed?

patches/systemvm/debian/config/etc/httpd/conf/httpd.conf

If not, we need to establish that we can legally use it.

--
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-142) Can patches/systemvm/debian/config/etc/httpd/conf/httpd.conf be removed?


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

Chip Childers updated CLOUDSTACK-142:
-

Affects Version/s: pre-4.0.0

 Can patches/systemvm/debian/config/etc/httpd/conf/httpd.conf be removed?
 

 Key: CLOUDSTACK-142
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-142
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker

 David notes that Debian doesn't use this file.  Can it be removed?
 patches/systemvm/debian/config/etc/httpd/conf/httpd.conf
 If not, we need to establish that we can legally use it.

--
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] [Created] (CLOUDSTACK-143) Establish legal use of patches/systemvm/debian/xe/xen-vcpu-hotplug.rules

Chip Childers created CLOUDSTACK-143:


 Summary: Establish legal use of 
patches/systemvm/debian/xe/xen-vcpu-hotplug.rules
 Key: CLOUDSTACK-143
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-143
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker


We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/config/etc/haproxy/haproxy.cfg

--
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-143) Establish legal use of patches/systemvm/debian/xe/xen-vcpu-hotplug.rules


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

Chip Childers updated CLOUDSTACK-143:
-

Description: 
We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/xe/xen-vcpu-hotplug.rules

  was:
We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/config/etc/haproxy/haproxy.cfg


 Establish legal use of patches/systemvm/debian/xe/xen-vcpu-hotplug.rules
 

 Key: CLOUDSTACK-143
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-143
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker

 We need to establish if the following file is one of the following: 
 1) Written specifically for CloudStack 
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license 
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it. 
 patches/systemvm/debian/xe/xen-vcpu-hotplug.rules

--
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] [Created] (CLOUDSTACK-144) Establish legal use of patches/systemvm/debian/xe/xe-linux-distribution.init

Chip Childers created CLOUDSTACK-144:


 Summary: Establish legal use of 
patches/systemvm/debian/xe/xe-linux-distribution.init
 Key: CLOUDSTACK-144
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-144
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker


We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/xe/xen-vcpu-hotplug.rules

--
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-144) Establish legal use of patches/systemvm/debian/xe/xe-linux-distribution.init


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

Chip Childers updated CLOUDSTACK-144:
-

Description: 
We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/xe/xe-linux-distribution.init

  was:
We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/xe/xen-vcpu-hotplug.rules


 Establish legal use of patches/systemvm/debian/xe/xe-linux-distribution.init
 

 Key: CLOUDSTACK-144
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-144
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker

 We need to establish if the following file is one of the following: 
 1) Written specifically for CloudStack 
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license 
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it. 
 patches/systemvm/debian/xe/xe-linux-distribution.init

--
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-145) Establish legal use of patches/systemvm/debian/config/etc/ssh/sshd_config


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

Chip Childers updated CLOUDSTACK-145:
-

Description: 
We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/config/etc/ssh/sshd_config

  was:
We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/xe/xe-linux-distribution.init


 Establish legal use of patches/systemvm/debian/config/etc/ssh/sshd_config
 -

 Key: CLOUDSTACK-145
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-145
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker

 We need to establish if the following file is one of the following: 
 1) Written specifically for CloudStack 
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license 
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it. 
 patches/systemvm/debian/config/etc/ssh/sshd_config

--
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] [Created] (CLOUDSTACK-145) Establish legal use of patches/systemvm/debian/config/etc/ssh/sshd_config

Chip Childers created CLOUDSTACK-145:


 Summary: Establish legal use of 
patches/systemvm/debian/config/etc/ssh/sshd_config
 Key: CLOUDSTACK-145
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-145
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker


We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/xe/xe-linux-distribution.init

--
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] [Created] (CLOUDSTACK-146) Establish legal use of patches/systemvm/debian/config/etc/vpcdnsmasq.conf

Chip Childers created CLOUDSTACK-146:


 Summary: Establish legal use of 
patches/systemvm/debian/config/etc/vpcdnsmasq.conf
 Key: CLOUDSTACK-146
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-146
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker


We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/config/etc/ssh/sshd_config

--
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-146) Establish legal use of patches/systemvm/debian/config/etc/vpcdnsmasq.conf


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

Chip Childers updated CLOUDSTACK-146:
-

Description: 
We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/config/etc/vpcdnsmasq.conf

  was:
We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/config/etc/ssh/sshd_config


 Establish legal use of patches/systemvm/debian/config/etc/vpcdnsmasq.conf
 -

 Key: CLOUDSTACK-146
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-146
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker

 We need to establish if the following file is one of the following: 
 1) Written specifically for CloudStack 
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license 
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it. 
 patches/systemvm/debian/config/etc/vpcdnsmasq.conf

--
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] [Created] (CLOUDSTACK-147) Establish legal use of patches/systemvm/debian/config/etc/rsyslog.conf

Chip Childers created CLOUDSTACK-147:


 Summary: Establish legal use of 
patches/systemvm/debian/config/etc/rsyslog.conf
 Key: CLOUDSTACK-147
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-147
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker


We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/config/etc/vpcdnsmasq.conf

--
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-147) Establish legal use of patches/systemvm/debian/config/etc/rsyslog.conf


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

Chip Childers updated CLOUDSTACK-147:
-

Description: 
We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/config/etc/rsyslog.conf

  was:
We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/config/etc/vpcdnsmasq.conf


 Establish legal use of patches/systemvm/debian/config/etc/rsyslog.conf
 --

 Key: CLOUDSTACK-147
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-147
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker

 We need to establish if the following file is one of the following: 
 1) Written specifically for CloudStack 
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license 
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it. 
 patches/systemvm/debian/config/etc/rsyslog.conf

--
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-148) Establish legal use of patches/systemvm/debian/config/etc/logrotate.conf


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

Chip Childers updated CLOUDSTACK-148:
-

Description: 
We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/config/etc/logrotate.conf

  was:
We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/config/etc/rsyslog.conf


 Establish legal use of patches/systemvm/debian/config/etc/logrotate.conf
 

 Key: CLOUDSTACK-148
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-148
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker

 We need to establish if the following file is one of the following: 
 1) Written specifically for CloudStack 
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license 
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it. 
 patches/systemvm/debian/config/etc/logrotate.conf

--
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] [Created] (CLOUDSTACK-148) Establish legal use of patches/systemvm/debian/config/etc/logrotate.conf

Chip Childers created CLOUDSTACK-148:


 Summary: Establish legal use of 
patches/systemvm/debian/config/etc/logrotate.conf
 Key: CLOUDSTACK-148
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-148
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker


We need to establish if the following file is one of the following: 
1) Written specifically for CloudStack 
2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
license 
3) Taken (and perhaps modified) from a source that does not have a compatible 
license, and then figure out what to do about it. 

patches/systemvm/debian/config/etc/rsyslog.conf

--
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-136) unit test failing on axis-deploy


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458965#comment-13458965
 ] 

Rohit Yadav commented on CLOUDSTACK-136:


It was a chown issue. Somehow jenkins folders had root user. So, we chown'd 
~/.m2 and jenkins workspace folder. It works now.

 unit test failing on axis-deploy
 

 Key: CLOUDSTACK-136
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-136
 Project: CloudStack
  Issue Type: Bug
  Components: Test
Affects Versions: pre-4.0.0
Reporter: David Nalley
Assignee: Rohit Yadav
Priority: Critical
 Fix For: pre-4.0.0


 Unit tests for 4.0 are failing at the deploy-axis stage: 
 See: http://jenkins.cloudstack.org/job/test-junit-4.0
 deploy-axis:
 BUILD FAILED
 /var/lib/jenkins/workspace/test-junit-4.0/build/build-aws-api.xml:174: src 
 '/var/lib/jenkins/workspace/test-junit-4.0/deps/awsapi-lib/axis2-webapp-1.5.1.war'
  doesn't exist.
 Total time: 5 minutes 2 seconds
 Build step 'Invoke Ant' marked build as failure
 Archiving artifacts
 Recording test results
 Performance: Percentage of errors greater or equal than 0% sets the build as 
 unstable
 Performance: Percentage of errors greater or equal than 0% sets the build as 
 failure
 Performance: Recording JUnit reports 'unittest/TEST-*.xml'
 Sending e-mails to: cloudstack-comm...@incubator.apache.org 
 murali.re...@citrix.com chip.child...@gmail.com t...@apache.org 
 alena.prokharc...@citrix.com disheng...@gmail.com w...@widodh.nl 
 alex.hu...@citrix.com sudi...@gmail.com nitin.me...@citrix.com 
 sheng.y...@citrix.com edi...@citrix.com jessica.w...@citrix.com 
 pra...@cloud.com mice_...@tcloudcomputing.com agneya2...@yahoo.com 
 chirad...@apache.org brian.fede...@citrix.com anth...@cloud.com 
 pranav.sax...@citrix.com da...@gnsa.us frank.zh...@citrix.com
 build-cloudstack-4.0-rhel6.3 is disabled. Triggering skipped
 Finished: FAILURE

--
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-136) unit test failing on axis-deploy


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

Rohit Yadav resolved CLOUDSTACK-136.


Resolution: Fixed

It was a chown issue on the build folder. It's not upto unittests to fails or 
pass.

 unit test failing on axis-deploy
 

 Key: CLOUDSTACK-136
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-136
 Project: CloudStack
  Issue Type: Bug
  Components: Test
Affects Versions: pre-4.0.0
Reporter: David Nalley
Assignee: Rohit Yadav
Priority: Critical
 Fix For: pre-4.0.0


 Unit tests for 4.0 are failing at the deploy-axis stage: 
 See: http://jenkins.cloudstack.org/job/test-junit-4.0
 deploy-axis:
 BUILD FAILED
 /var/lib/jenkins/workspace/test-junit-4.0/build/build-aws-api.xml:174: src 
 '/var/lib/jenkins/workspace/test-junit-4.0/deps/awsapi-lib/axis2-webapp-1.5.1.war'
  doesn't exist.
 Total time: 5 minutes 2 seconds
 Build step 'Invoke Ant' marked build as failure
 Archiving artifacts
 Recording test results
 Performance: Percentage of errors greater or equal than 0% sets the build as 
 unstable
 Performance: Percentage of errors greater or equal than 0% sets the build as 
 failure
 Performance: Recording JUnit reports 'unittest/TEST-*.xml'
 Sending e-mails to: cloudstack-comm...@incubator.apache.org 
 murali.re...@citrix.com chip.child...@gmail.com t...@apache.org 
 alena.prokharc...@citrix.com disheng...@gmail.com w...@widodh.nl 
 alex.hu...@citrix.com sudi...@gmail.com nitin.me...@citrix.com 
 sheng.y...@citrix.com edi...@citrix.com jessica.w...@citrix.com 
 pra...@cloud.com mice_...@tcloudcomputing.com agneya2...@yahoo.com 
 chirad...@apache.org brian.fede...@citrix.com anth...@cloud.com 
 pranav.sax...@citrix.com da...@gnsa.us frank.zh...@citrix.com
 build-cloudstack-4.0-rhel6.3 is disabled. Triggering skipped
 Finished: FAILURE

--
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-118) Status of host resorce stuck in ErrorInMaintenance


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458982#comment-13458982
 ] 

Rohit Yadav commented on CLOUDSTACK-118:


I don't know if this bug is supposed to be fixed before 4.0, so preempting it 
right now. 

 Status of host resorce  stuck in ErrorInMaintenance
 -

 Key: CLOUDSTACK-118
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-118
 Project: CloudStack
  Issue Type: Bug
  Components: Management Server
Affects Versions: pre-4.0.0
 Environment: XS 6.0.2
 MS Rhl6.3
 Git Revision: 03df2fa9dd45c938f72cd1866044b09d1b0cc978
 Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git
Reporter: prashant kumar mishra
Assignee: Rohit Yadav
 Attachments: access_log.2012-09-17.txt, api-server.log, catalina.out, 
 cloud-backup.dmp, management-server.log, management-server.log.2012-09-16.gz


 In a cluster of 2 host if  you try to put master in maintenance mode 
 ,resource state will be stuck in ErrorInMaintenance   
 Step to reproduce:
 -
 --
 1-Create an advance zone-pod-cluster.
 2-Add 2 hosts in same cluster.
 3-Deploy a HA enabled VM .
 4-put host(one which is pool master ) in maintenance mode .
 Expected result : 
 --
 --
 status =UP;
 resource status =maintenance  
 Actual result:
 
 
 status=UP;
 resource state=ErrorInMaintenance

--
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-109) UI - No option available on the UI to edit details of admin account of root domain - network domain suffix for the account cannot be specified currently

2012-09-19 Thread Brian Federle (JIRA)


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

Brian Federle reassigned CLOUDSTACK-109:


Assignee: Jessica Wang  (was: Pranav Saxena)

Jessica, take a look at this. I'm not sure if there's a reason that the edit 
action is disabled for a ROOT admin.

 UI - No option available on the UI to edit details of admin account of root 
 domain - network domain suffix for the account cannot be specified currently
 

 Key: CLOUDSTACK-109
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-109
 Project: CloudStack
  Issue Type: Bug
  Components: UI
Affects Versions: pre-4.0.0
Reporter: Chandan Purushothama
Assignee: Jessica Wang
 Fix For: 4.0.0


 Currently admin account of the ROOT domain cannot specify a network domain 
 suffix for the account as there is no option/button made available for the 
 admin to edit the details of the account and add the network domain suffix 
 Information,
 =
 Git Info:
 =
 Git Revision: 54f9af1695bc359b02e9fc906b3b335cc0bfec41
 Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git

--
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-110) UI - No option available on the UI to edit details of ROOTdomain - network domain suffix for the ROOT domain cannot be specified currently

2012-09-19 Thread Brian Federle (JIRA)


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

Brian Federle reassigned CLOUDSTACK-110:


Assignee: Jessica Wang  (was: Pranav Saxena)

Related to https://issues.apache.org/jira/browse/CLOUDSTACK-109

Jessica, also look at this one...thanks.

 UI - No option available on the UI to edit details of ROOTdomain - network 
 domain suffix for the ROOT domain cannot be specified currently 
 ---

 Key: CLOUDSTACK-110
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-110
 Project: CloudStack
  Issue Type: Bug
  Components: UI
Affects Versions: pre-4.0.0
Reporter: Chandan Purushothama
Assignee: Jessica Wang
 Fix For: pre-4.0.0


 Currently network domain suffix for the ROOT domain cannot be specified, as 
 there is no option/button made available on the UI to edit the details of the 
 ROOT domain and add the network domain suffix Information,
 mysql select * from domain;
 +++---+--+---+-+---+-++-++-++
 | id | parent | name  | uuid | owner | path   
  | level | child_count | next_child_seq | removed | state  | network_domain   
| type   |
 +++---+--+---+-+---+-++-++-++
 |  1 |   NULL | ROOT  | 7e3aea93-fb11-45a6-b3a1-dc2f9aa914dd | 2 | /  
  | 0 |   1 |  2 | NULL| Active | NULL 
| Normal |
 |  2 |  1 | CHILD | e2cc8e71-0277-4a02-9685-63424afb67ae | 2 | 
 /CHILD/ | 1 |   0 |  1 | NULL| Active | 
 child.lab.vmops.com | Normal |
 +++---+--+---+-+---+-++-++-++
 2 rows in set (0.00 sec)
 =
 Git Info:
 =
 Git Revision: 54f9af1695bc359b02e9fc906b3b335cc0bfec41
 Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git

--
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-109) UI - No option available on the UI to edit details of admin account of root domain - network domain suffix for the account cannot be specified currently

2012-09-19 Thread Brian Federle (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458999#comment-13458999
 ] 

Brian Federle commented on CLOUDSTACK-109:
--

This is the section of accounts.js that filters out the edit action, around 
line 1105:

if (jsonObj.accounttype == roleTypeUser || jsonObj.accounttype == 
roleTypeDomainAdmin) {
  //allowedActions.push(updateResourceLimits);
  allowedActions.push(edit);
}

 UI - No option available on the UI to edit details of admin account of root 
 domain - network domain suffix for the account cannot be specified currently
 

 Key: CLOUDSTACK-109
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-109
 Project: CloudStack
  Issue Type: Bug
  Components: UI
Affects Versions: pre-4.0.0
Reporter: Chandan Purushothama
Assignee: Jessica Wang
 Fix For: 4.0.0


 Currently admin account of the ROOT domain cannot specify a network domain 
 suffix for the account as there is no option/button made available for the 
 admin to edit the details of the account and add the network domain suffix 
 Information,
 =
 Git Info:
 =
 Git Revision: 54f9af1695bc359b02e9fc906b3b335cc0bfec41
 Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git

--
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] [Created] (CLOUDSTACK-149) Configure Maven to build deb packages

Rohit Yadav created CLOUDSTACK-149:
--

 Summary: Configure Maven to build deb packages
 Key: CLOUDSTACK-149
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-149
 Project: CloudStack
  Issue Type: New Feature
  Components: Install and Setup
Reporter: Rohit Yadav
Assignee: Rohit Yadav


Configure a maven plugin to package debian packages. Deprecate waf as a 
packaging tool.

--
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-149) Configure Maven to build deb packages


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

Rohit Yadav updated CLOUDSTACK-149:
---

Fix Version/s: 4.1.0

 Configure Maven to build deb packages
 -

 Key: CLOUDSTACK-149
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-149
 Project: CloudStack
  Issue Type: New Feature
  Components: Install and Setup
Reporter: Rohit Yadav
Assignee: Rohit Yadav
 Fix For: 4.1.0


 Configure a maven plugin to package debian packages. Deprecate waf as a 
 packaging tool.

--
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] [Created] (CLOUDSTACK-150) Configure Maven to build rpm packages

Rohit Yadav created CLOUDSTACK-150:
--

 Summary: Configure Maven to build rpm packages
 Key: CLOUDSTACK-150
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-150
 Project: CloudStack
  Issue Type: New Feature
Reporter: Rohit Yadav
Assignee: Rohit Yadav
 Fix For: 4.1.0


Configure a Maven plugin to build rpm packages, deprecate waf for building rpms.

--
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-127) Adding VMs to an existing LB rule after upgrading from CS 3.0.2 to ASF 4.0 fails with ResourceUnavailableException: Resource [DataCenter:1] is unreachable: Unable


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459014#comment-13459014
 ] 

Sheng Yang commented on CLOUDSTACK-127:
---

It's by design, and documented in the upgrade instructions.

The reason here is we need to update the VR to the newer version. The old 
version VR wouldn't guarantee compatibility with new version mgmt server. But 
it's not always broke all the functions. That's why you can see that create VM 
successful, but assoicate new IP failed.

 Adding VMs to an existing LB rule after upgrading from CS 3.0.2 to ASF 4.0 
 fails with ResourceUnavailableException: Resource [DataCenter:1] is 
 unreachable: Unable to apply ip association on router 
 ---

 Key: CLOUDSTACK-127
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-127
 Project: CloudStack
  Issue Type: Bug
  Components: Network Controller
Affects Versions: pre-4.0.0
 Environment: MS OS : Rhel 6.2
 Hypervisor : Xen 6.0.2
 BUILDs : 3.0.2 and ASF 4.0 [ Git Revision: 
 54f9af1695bc359b02e9fc906b3b335cc0bfec41 Git URL: 
 https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git]
Reporter: Abhinav Roy
Assignee: Sheng Yang
 Fix For: pre-4.0.0

 Attachments: management-server.log, messages, SMlog.10, SMlog.11


 Steps :
 =
 1. Deploy an advanced zone setup with CS 3.0.2
 2. Deploy couple of VMs.
 3. Acquire an IP Address for the Network created and create a LB rule for the 
 VMs created in step2.
 4. Upgrade the setup to ASF 4.0
 5. Create a VM on the existing Network.
 6. Add the VM created in step 5 to the LB rule created in step 3.
 Expected Behaviour :
 =
 All the steps should be successful and no error should be seen.
 Observed Behaviour :
 =
 Step 6 fails with the following exceptions
 2012-09-18 00:32:07,036 DEBUG [network.lb.LoadBalancingRulesManagerImpl] 
 (Job-Executor-7:job-18) Adding VM[User|VM-3] to the load balancer pool
 2012-09-18 00:32:07,130 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-7:job-18) 
 Applying ip association in network Ntwk[204|Guest|7]
 2012-09-18 00:32:07,177 DEBUG [agent.transport.Request] 
 (Job-Executor-7:job-18) Seq 1-2076573728: Sending  { Cmd , MgmtId: 
 160940036302157, via: 1, Ver: v1, Flags: 11, 
 [{routing.IpAssocCommand:{ipAddresses:[{accountId:2,publicIp:10.102.125.69,sourceNat:true,add:true,oneToOneNat:false,firstIP:true,vlanId:untagged,vlanGateway:10.102.125.1,vlanNetmask:255.255.255.0,vifMacAddress:06:4d:b6:00:00:09,networkRate:200,trafficType:Public},{accountId:2,publicIp:10.102.125.66,sourceNat:false,add:true,oneToOneNat:false,firstIP:false,vlanId:untagged,vlanGateway:10.102.125.1,vlanNetmask:255.255.255.0,vifMacAddress:06:b2:8e:00:00:06,networkRate:200,trafficType:Public}],accessDetails:{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:169.254.2.233,router.name:r-4-VM},wait:0}}]
  }
 2012-09-18 00:32:07,177 DEBUG [agent.transport.Request] 
 (Job-Executor-7:job-18) Seq 1-2076573728: Executing:  { Cmd , MgmtId: 
 160940036302157, via: 1, Ver: v1, Flags: 11, 
 [{routing.IpAssocCommand:{ipAddresses:[{accountId:2,publicIp:10.102.125.69,sourceNat:true,add:true,oneToOneNat:false,firstIP:true,vlanId:untagged,vlanGateway:10.102.125.1,vlanNetmask:255.255.255.0,vifMacAddress:06:4d:b6:00:00:09,networkRate:200,trafficType:Public},{accountId:2,publicIp:10.102.125.66,sourceNat:false,add:true,oneToOneNat:false,firstIP:false,vlanId:untagged,vlanGateway:10.102.125.1,vlanNetmask:255.255.255.0,vifMacAddress:06:b2:8e:00:00:06,networkRate:200,trafficType:Public}],accessDetails:{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:169.254.2.233,router.name:r-4-VM},wait:0}}]
  }
 2012-09-18 00:32:07,178 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-6:null) Seq 1-2076573728: Executing request
 2012-09-18 00:32:07,718 ERROR [xen.resource.CitrixResourceBase] 
 (DirectAgent-6:null) Ip Assoc failure on applying one ip due to exception:  
 com.cloud.exception.InternalErrorException: Xen plugin ipassoc failed.
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.assignPublicIpAddress(CitrixResourceBase.java:1934)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:2030)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:421)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
 at

[jira] [Commented] (CLOUDSTACK-150) Configure Maven to build rpm packages

2012-09-19 Thread David Nalley (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459017#comment-13459017
 ] 

David Nalley commented on CLOUDSTACK-150:
-

So not arguing with the work you want to do here - but this seems circular to 
me - maven calls rpmbuild which calls maven? 
Why not a compile +install profile that allows you to define where you want 
things to go (think of options like --prefix=path and --bindir=/path in a make 
world). 

And then just calling rpmbuild to call those profiles and assemble the package 
- that would effectively get rid of waf - and mean that the work necessary to 
get deb and rpm into shape is really upstream of the package itself (less work, 
I think) 

--David

 Configure Maven to build rpm packages
 -

 Key: CLOUDSTACK-150
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-150
 Project: CloudStack
  Issue Type: New Feature
Reporter: Rohit Yadav
Assignee: Rohit Yadav
 Fix For: 4.1.0


 Configure a Maven plugin to build rpm packages, deprecate waf for building 
 rpms.

--
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-150) Configure Maven to build rpm packages


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459029#comment-13459029
 ] 

Rohit Yadav commented on CLOUDSTACK-150:


Just to update, I tested a rpm plugin from codehaus, in that case maven calls 
the plugin, plugin generates spec on the fly and rpmbuilds generates rpms. No 
circular roles here.

 Configure Maven to build rpm packages
 -

 Key: CLOUDSTACK-150
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-150
 Project: CloudStack
  Issue Type: New Feature
Reporter: Rohit Yadav
Assignee: Rohit Yadav
 Fix For: 4.1.0


 Configure a Maven plugin to build rpm packages, deprecate waf for building 
 rpms.

--
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-137) Establish legal use of patches/systemvm/debian/config/etc/apache2/httpd.conf


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459051#comment-13459051
 ] 

Joe Brockmeier commented on CLOUDSTACK-137:
---

Assuming this is derived from the Debian package that contains the standard 
Apache configuration files it would be under the Apache 2.0 license: 

http://packages.debian.org/changelogs/pool/main/a/apache2/apache2_2.2.16-6+squeeze7/apache2.2-common.copyright

If created from scratch or modified from that package, we should still be able 
to assume that it is ASL. 



 Establish legal use of patches/systemvm/debian/config/etc/apache2/httpd.conf
 

 Key: CLOUDSTACK-137
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-137
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker

 We need to establish if the following file is one of the following:
 1) Written specifically for CloudStack
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it.
 patches/systemvm/debian/config/etc/apache2/httpd.conf

--
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-138) Establish legal use of patches/systemvm/debian/config/etc/apache2/ports.conf


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459055#comment-13459055
 ] 

Joe Brockmeier commented on CLOUDSTACK-138:
---

Assuming this is derived from the Debian package that contains the standard 
Apache configuration files it would be under the Apache 2.0 license: 

http://packages.debian.org/changelogs/pool/main/a/apache2/apache2_2.2.16-6+squeeze7/apache2.2-common.copyright

Note that it's been lightly modified for CloudStack but appears more or less 
identical to the default ports.conf in the apache2.2-common package in Debian.

Unless there's an objection, though - I believe we can close this one as Apache 
licensed.

 Establish legal use of patches/systemvm/debian/config/etc/apache2/ports.conf
 

 Key: CLOUDSTACK-138
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-138
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker

 We need to establish if the following file is one of the following:
 1) Written specifically for CloudStack
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it.
 patches/systemvm/debian/config/etc/apache2/ports.conf

--
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-139) Can we remove patches/systemvm/debian/config/etc/apache2/[vhostexmaple.conf, sites-available/default, sites-available/default-ssl]


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459066#comment-13459066
 ] 

Joe Brockmeier commented on CLOUDSTACK-139:
---

I think these files are used, but maybe one of the folks who know the internals 
better can correct me. 

However, these files appear to be taken from or derived from the 
apache2.2-common Debian package:

patches/systemvm/debian/config/etc/apache2/sites-available/default 
patches/systemvm/debian/config/etc/apache2/sites-available/default-ssl 

As such, they should be licensed under the ASL 2.0.

This file:

patches/systemvm/debian/config/etc/apache2/vhostexample.conf 

Doesn't appear to be packaged as part of the apache2.2-common package. It may 
be a heavily modified version of one of the example configs or include 
snippets, but it should also be Apache Licensed. 


 Can we remove patches/systemvm/debian/config/etc/apache2/[vhostexmaple.conf, 
 sites-available/default, sites-available/default-ssl]
 --

 Key: CLOUDSTACK-139
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-139
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker

 In reviewing the contents of the patches folder, David and I are wondering if 
 the following files can be removed:
 patches/systemvm/debian/config/etc/apache2/sites-available/default
 patches/systemvm/debian/config/etc/apache2/vhostexmaple.conf
 patches/systemvm/debian/config/etc/apache2/sites-available/default-ssl
 If not, we need to establish the original source of these 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: Still cannot add KVM host

you can also check /var/log/libvirt/libvirtd.log to see what error
libvirt might be throwing about creating storage.

On Wed, Sep 19, 2012 at 10:26 AM, Busy Dev busyd...@gmail.com wrote:
 I'm using NFS for both primary and secondary (which are hosted by the same
 machine that hosts the management server).


 On Wed, Sep 19, 2012 at 12:13 PM, Kelceydamage@bbits kel...@bbits.cawrote:

 I just caught that error in the logs too.

 Might I ask what solution your running for primary storage? And how it's
 connected to ACS?

 Sent from my iPhone

 On Sep 19, 2012, at 7:45 AM, Busy Dev busyd...@gmail.com wrote:

  I'll verify that.  I know the secondary storage is available... didn't
 try
  the primary one - but both primary and secondary are located on the same
  server.

RE: Still cannot add KVM host

2012-09-19 Thread Kelcey Damage (BBITS)

That’s a good point I had a similar issue once and it was because I recycled a 
KVM host, so there were complaints about existing storage domains in the 
libvirt logs. All I had to do was delete the old data in the libvirt config 
folders.

Best of luck

KELCEY DAMAGE 
Infrastructure Systems Architect 
www.backbonetechnology.com 
- 
kel...@bbits.ca 

address: 55 East 7th Ave, Vancouver, BC, V5T 1M4
tel: +1 604 713 8560 ext:114    
fax: +1 604 605 0964 
skype: kelcey.damage 
 


-Original Message-
From: Marcus Sorensen [mailto:shadow...@gmail.com] 
Sent: Wednesday, September 19, 2012 1:38 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Still cannot add KVM host

you can also check /var/log/libvirt/libvirtd.log to see what error libvirt 
might be throwing about creating storage.

On Wed, Sep 19, 2012 at 10:26 AM, Busy Dev busyd...@gmail.com wrote:
 I'm using NFS for both primary and secondary (which are hosted by the 
 same machine that hosts the management server).


 On Wed, Sep 19, 2012 at 12:13 PM, Kelceydamage@bbits kel...@bbits.cawrote:

 I just caught that error in the logs too.

 Might I ask what solution your running for primary storage? And how 
 it's connected to ACS?

 Sent from my iPhone

 On Sep 19, 2012, at 7:45 AM, Busy Dev busyd...@gmail.com wrote:

  I'll verify that.  I know the secondary storage is available... 
  didn't
 try
  the primary one - but both primary and secondary are located on the 
  same server.

[jira] [Commented] (CLOUDSTACK-141) Establish legal use of patches/systemvm/debian/config/etc/haproxy/haproxy.cfg


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459079#comment-13459079
 ] 

Joe Brockmeier commented on CLOUDSTACK-141:
---

The file: 

patches/systemvm/debian/config/etc/haproxy/haproxy.cfg

Would be found in the Debian haproxy source package. It would appear that the 
package includes GPLv2 and LGPLv2. However, the haproxy.cfg that is included in 
ACS is substantially different and looks to have been written from scratch or 
taken from another source - not the Debian package. 

Git log shows this committed Mon Oct 4 17:15:30 2010 -0700 by edison 
edi...@cloud.com.

I believe this file is clear. Assigning to Edison to get a final OK or more 
information.

 Establish legal use of patches/systemvm/debian/config/etc/haproxy/haproxy.cfg
 -

 Key: CLOUDSTACK-141
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-141
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker

 We need to establish if the following file is one of the following: 
 1) Written specifically for CloudStack 
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license 
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it. 
 patches/systemvm/debian/config/etc/haproxy/haproxy.cfg

--
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-141) Establish legal use of patches/systemvm/debian/config/etc/haproxy/haproxy.cfg


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

Joe Brockmeier reassigned CLOUDSTACK-141:
-

Assignee: edison su

It looks like you added this file and it's substantially different than the 
default Debian package. Can you add any information? Thanks!

Joe

 Establish legal use of patches/systemvm/debian/config/etc/haproxy/haproxy.cfg
 -

 Key: CLOUDSTACK-141
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-141
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Assignee: edison su
Priority: Blocker

 We need to establish if the following file is one of the following: 
 1) Written specifically for CloudStack 
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license 
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it. 
 patches/systemvm/debian/config/etc/haproxy/haproxy.cfg

--
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-145) Establish legal use of patches/systemvm/debian/config/etc/ssh/sshd_config


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459098#comment-13459098
 ] 

Joe Brockmeier commented on CLOUDSTACK-145:
---

Summary (tl;dr) - This file *should* be legal to use under an ASLv2 compatible 
license (BSD).

This appears to be a modified version of the sshd_config file shipped by 
OpenBSD, and subsequently packaged for Debian in the openssh-server package 
(see: http://packages.debian.org/squeeze/openssh-server)

The LICENSE file from upstream OpenSSH says:

The licences which components of this software fall under are as
follows.  First, we will summarize and say that all components
are under a BSD licence, or a licence more free than that.

(Further license summaries follow, will paste the entire thing if anyone needs 
to see that.)

The Debian patch to the file is under the GPL, but includes an exception that 
should not affect distribution under an Apache-compatible license if the 
configuration file is even considered copyrightable:

In addition, as a special exception, Matthew Vernon gives permission
to link the code of the Debian patch with any version of the OpenSSH
code which is distributed under a license identical to that listed in
the included Copyright file, and distribute linked combinations
including the two.  You must obey the GNU General Public License in
all respects for all of the code used other than OpenSSH.  If you
modify this file, you may extend this exception to your version of the
file, but you are not obligated to do so.  If you do not wish to do
so, delete this exception statement from your version.

(See: 
http://packages.debian.org/changelogs/pool/main/o/openssh/openssh_5.5p1-6+squeeze2/openssh-server.copyright)

Note that the sshd_config file that's distributed with ASC currently appears to 
be an older and modified version, so this may have been carried forward from 
older releases of OpenSSH. 

 Establish legal use of patches/systemvm/debian/config/etc/ssh/sshd_config
 -

 Key: CLOUDSTACK-145
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-145
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Priority: Blocker

 We need to establish if the following file is one of the following: 
 1) Written specifically for CloudStack 
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license 
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it. 
 patches/systemvm/debian/config/etc/ssh/sshd_config

--
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-141) Establish legal use of patches/systemvm/debian/config/etc/haproxy/haproxy.cfg

2012-09-19 Thread edison su (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459112#comment-13459112
 ] 

edison su commented on CLOUDSTACK-141:
--

patches/systemvm/debian/config/etc/haproxy/haproxy.cfg is definitely created by 
ourself from scratch. 

 Establish legal use of patches/systemvm/debian/config/etc/haproxy/haproxy.cfg
 -

 Key: CLOUDSTACK-141
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-141
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Assignee: edison su
Priority: Blocker

 We need to establish if the following file is one of the following: 
 1) Written specifically for CloudStack 
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license 
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it. 
 patches/systemvm/debian/config/etc/haproxy/haproxy.cfg

--
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] [Closed] (CLOUDSTACK-141) Establish legal use of patches/systemvm/debian/config/etc/haproxy/haproxy.cfg


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

Joe Brockmeier closed CLOUDSTACK-141.
-

   Resolution: Not A Problem
Fix Version/s: pre-4.0.0

Thanks Edison, I think we can close this ticket then.

 Establish legal use of patches/systemvm/debian/config/etc/haproxy/haproxy.cfg
 -

 Key: CLOUDSTACK-141
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-141
 Project: CloudStack
  Issue Type: Bug
Affects Versions: pre-4.0.0
Reporter: Chip Childers
Assignee: edison su
Priority: Blocker
 Fix For: pre-4.0.0


 We need to establish if the following file is one of the following: 
 1) Written specifically for CloudStack 
 2) Taken (and perhaps modified) from a source that has an ASLv2 compatible 
 license 
 3) Taken (and perhaps modified) from a source that does not have a compatible 
 license, and then figure out what to do about it. 
 patches/systemvm/debian/config/etc/haproxy/haproxy.cfg

--
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] [Created] (CLOUDSTACK-152) Routes on the User VM are programmed incorrectly on a VM present on both an Isolated and Shared Guest Networks

2012-09-19 Thread Chandan Purushothama (JIRA)

Chandan Purushothama created CLOUDSTACK-152:
---

 Summary: Routes on the User VM are programmed incorrectly on a VM 
present on both an Isolated and Shared Guest Networks
 Key: CLOUDSTACK-152
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-152
 Project: CloudStack
  Issue Type: Bug
  Components: Management Server
Affects Versions: pre-4.0.0
Reporter: Chandan Purushothama
 Fix For: pre-4.0.0



==
Steps to Reproduce:
==

1. As the Admin of ROOT domain, Create a shared guest network using the 
DefaultNetworkOfferingforSharedNetworks.
2. Login as a Regular User. Create an isolated guest network using the 
DefaultNetworkOfferingwithSourceNATService
3. Register a CentOS6.3_x86_64 ISO
4. Deploy a VM on the Isolated and Shared Guest Network using the ISO. Make 
sure that the Isolated Guest Network is chosen as the default Guest Network.
5. View the VM's Console. Observe that the only IP Address present on the VM is 
the loopback address.
6. Edit the two ifcfg-ethx files present under /etc/sysconfig/network-scripts/. 
Set the ONBOOT parameter to yes.
7. Reboot the VM or restart the network service.
8. Observe the routes on the VM after the Reboot.

==
Observations:
==

[root@B-regnet-shdnet-iso-vm-4 ~]# history
1  ifconfig
2  reboot
3  history
[root@B-regnet-shdnet-iso-vm-4 ~]# ifconfig
eth0  Link encap:Ethernet  HWaddr 02:00:47:BD:00:06
  inet addr:10.1.1.48  Bcast:10.1.1.255  Mask:255.255.255.0
  inet6 addr: fe80::47ff:febd:6/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:2 errors:0 dropped:0 overruns:0 frame:0
  TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:379 (379.0 b)  TX bytes:1116 (1.0 KiB)
  Interrupt:165

eth1  Link encap:Ethernet  HWaddr 06:74:B6:00:00:3A
  inet addr:10.223.137.78  Bcast:10.223.137.127  Mask:255.255.255.192
  inet6 addr: fe80::474:b6ff:fe00:3a/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:108 errors:0 dropped:0 overruns:0 frame:0
  TX packets:84 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:9425 (9.2 KiB)  TX bytes:10289 (10.0 KiB)
  Interrupt:164

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)


**Observe that except the second and the third route all the remaining routes 
are wrong. Notice that 10.1.1.48 is on eth0 while 10.223.137.78 is on eth1**

[root@B-regnet-shdnet-iso-vm-4 ~]# ip route
10.1.1.1 dev eth1  scope link
10.223.137.64/26 dev eth1  proto kernel  scope link  src 10.223.137.78
10.1.1.0/24 dev eth0  proto kernel  scope link  src 10.1.1.48
169.254.0.0/16 dev eth0  scope link  metric 1002
169.254.0.0/16 dev eth1  scope link  metric 1003
default via 10.1.1.1 dev eth1

[root@B-regnet-shdnet-iso-vm-4 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=02:00:47:BD:00:06
NM_CONTROLLED=yes
ONBOOT=yes
TYPE=Ethernet
UUID=b74145e6-eaf5-4b53-b19a-9a4051fa4a75

[root@B-regnet-shdnet-iso-vm-4 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=dhcp
HWADDR=06:74:B6:00:00:3A
NM_CONTROLLED=yes
ONBOOT=yes
TYPE=Ethernet
UUID=a5afb535-0eb0-4196-a324-87aec613f38a

[root@B-regnet-shdnet-iso-vm-4 ~]# cat /etc/redhat-release
CentOS release 6.3 (Final)

===
Git Info:
===

Git Revision: 54f9af1695bc359b02e9fc906b3b335cc0bfec41
Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git

--
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-152) Routes on the User VM are programmed incorrectly on a VM present on both Isolated and Shared Guest Networks

2012-09-19 Thread Chandan Purushothama (JIRA)


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

Chandan Purushothama updated CLOUDSTACK-152:


Summary: Routes on the User VM are programmed incorrectly on a VM present 
on both Isolated and Shared Guest Networks  (was: Routes on the User VM are 
programmed incorrectly on a VM present on both an Isolated and Shared Guest 
Networks)

 Routes on the User VM are programmed incorrectly on a VM present on both 
 Isolated and Shared Guest Networks
 ---

 Key: CLOUDSTACK-152
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-152
 Project: CloudStack
  Issue Type: Bug
  Components: Management Server
Affects Versions: pre-4.0.0
Reporter: Chandan Purushothama
 Fix For: pre-4.0.0


 ==
 Steps to Reproduce:
 ==
 1. As the Admin of ROOT domain, Create a shared guest network using the 
 DefaultNetworkOfferingforSharedNetworks.
 2. Login as a Regular User. Create an isolated guest network using the 
 DefaultNetworkOfferingwithSourceNATService
 3. Register a CentOS6.3_x86_64 ISO
 4. Deploy a VM on the Isolated and Shared Guest Network using the ISO. Make 
 sure that the Isolated Guest Network is chosen as the default Guest Network.
 5. View the VM's Console. Observe that the only IP Address present on the VM 
 is the loopback address.
 6. Edit the two ifcfg-ethx files present under 
 /etc/sysconfig/network-scripts/. Set the ONBOOT parameter to yes.
 7. Reboot the VM or restart the network service.
 8. Observe the routes on the VM after the Reboot.
 ==
 Observations:
 ==
 [root@B-regnet-shdnet-iso-vm-4 ~]# history
 1  ifconfig
 2  reboot
 3  history
 [root@B-regnet-shdnet-iso-vm-4 ~]# ifconfig
 eth0  Link encap:Ethernet  HWaddr 02:00:47:BD:00:06
   inet addr:10.1.1.48  Bcast:10.1.1.255  Mask:255.255.255.0
   inet6 addr: fe80::47ff:febd:6/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:2 errors:0 dropped:0 overruns:0 frame:0
   TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:379 (379.0 b)  TX bytes:1116 (1.0 KiB)
   Interrupt:165
 eth1  Link encap:Ethernet  HWaddr 06:74:B6:00:00:3A
   inet addr:10.223.137.78  Bcast:10.223.137.127  Mask:255.255.255.192
   inet6 addr: fe80::474:b6ff:fe00:3a/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:108 errors:0 dropped:0 overruns:0 frame:0
   TX packets:84 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:9425 (9.2 KiB)  TX bytes:10289 (10.0 KiB)
   Interrupt:164
 loLink encap:Local Loopback
   inet addr:127.0.0.1  Mask:255.0.0.0
   inet6 addr: ::1/128 Scope:Host
   UP LOOPBACK RUNNING  MTU:16436  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
 **Observe that except the second and the third route all the remaining routes 
 are wrong. Notice that 10.1.1.48 is on eth0 while 10.223.137.78 is on eth1**
 [root@B-regnet-shdnet-iso-vm-4 ~]# ip route
 10.1.1.1 dev eth1  scope link
 10.223.137.64/26 dev eth1  proto kernel  scope link  src 10.223.137.78
 10.1.1.0/24 dev eth0  proto kernel  scope link  src 10.1.1.48
 169.254.0.0/16 dev eth0  scope link  metric 1002
 169.254.0.0/16 dev eth1  scope link  metric 1003
 default via 10.1.1.1 dev eth1
 [root@B-regnet-shdnet-iso-vm-4 ~]# cat 
 /etc/sysconfig/network-scripts/ifcfg-eth0
 DEVICE=eth0
 BOOTPROTO=dhcp
 HWADDR=02:00:47:BD:00:06
 NM_CONTROLLED=yes
 ONBOOT=yes
 TYPE=Ethernet
 UUID=b74145e6-eaf5-4b53-b19a-9a4051fa4a75
 [root@B-regnet-shdnet-iso-vm-4 ~]# cat 
 /etc/sysconfig/network-scripts/ifcfg-eth1
 DEVICE=eth1
 BOOTPROTO=dhcp
 HWADDR=06:74:B6:00:00:3A
 NM_CONTROLLED=yes
 ONBOOT=yes
 TYPE=Ethernet
 UUID=a5afb535-0eb0-4196-a324-87aec613f38a
 [root@B-regnet-shdnet-iso-vm-4 ~]# cat /etc/redhat-release
 CentOS release 6.3 (Final)
 ===
 Git Info:
 ===
 Git Revision: 54f9af1695bc359b02e9fc906b3b335cc0bfec41
 Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git

--
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-152) Routes on the User VM are programmed incorrectly on a VM present on both Isolated and Shared Guest Networks

2012-09-19 Thread Chandan Purushothama (JIRA)


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

Chandan Purushothama updated CLOUDSTACK-152:


Attachment: messagesontheUserVM.zip

 Routes on the User VM are programmed incorrectly on a VM present on both 
 Isolated and Shared Guest Networks
 ---

 Key: CLOUDSTACK-152
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-152
 Project: CloudStack
  Issue Type: Bug
  Components: Management Server
Affects Versions: pre-4.0.0
Reporter: Chandan Purushothama
 Fix For: pre-4.0.0

 Attachments: messagesontheUserVM.zip


 ==
 Steps to Reproduce:
 ==
 1. As the Admin of ROOT domain, Create a shared guest network using the 
 DefaultNetworkOfferingforSharedNetworks.
 2. Login as a Regular User. Create an isolated guest network using the 
 DefaultNetworkOfferingwithSourceNATService
 3. Register a CentOS6.3_x86_64 ISO
 4. Deploy a VM on the Isolated and Shared Guest Network using the ISO. Make 
 sure that the Isolated Guest Network is chosen as the default Guest Network.
 5. View the VM's Console. Observe that the only IP Address present on the VM 
 is the loopback address.
 6. Edit the two ifcfg-ethx files present under 
 /etc/sysconfig/network-scripts/. Set the ONBOOT parameter to yes.
 7. Reboot the VM or restart the network service.
 8. Observe the routes on the VM after the Reboot.
 ==
 Observations:
 ==
 [root@B-regnet-shdnet-iso-vm-4 ~]# history
 1  ifconfig
 2  reboot
 3  history
 [root@B-regnet-shdnet-iso-vm-4 ~]# ifconfig
 eth0  Link encap:Ethernet  HWaddr 02:00:47:BD:00:06
   inet addr:10.1.1.48  Bcast:10.1.1.255  Mask:255.255.255.0
   inet6 addr: fe80::47ff:febd:6/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:2 errors:0 dropped:0 overruns:0 frame:0
   TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:379 (379.0 b)  TX bytes:1116 (1.0 KiB)
   Interrupt:165
 eth1  Link encap:Ethernet  HWaddr 06:74:B6:00:00:3A
   inet addr:10.223.137.78  Bcast:10.223.137.127  Mask:255.255.255.192
   inet6 addr: fe80::474:b6ff:fe00:3a/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:108 errors:0 dropped:0 overruns:0 frame:0
   TX packets:84 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:9425 (9.2 KiB)  TX bytes:10289 (10.0 KiB)
   Interrupt:164
 loLink encap:Local Loopback
   inet addr:127.0.0.1  Mask:255.0.0.0
   inet6 addr: ::1/128 Scope:Host
   UP LOOPBACK RUNNING  MTU:16436  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
 **Observe that except the second and the third route all the remaining routes 
 are wrong. Notice that 10.1.1.48 is on eth0 while 10.223.137.78 is on eth1**
 [root@B-regnet-shdnet-iso-vm-4 ~]# ip route
 10.1.1.1 dev eth1  scope link
 10.223.137.64/26 dev eth1  proto kernel  scope link  src 10.223.137.78
 10.1.1.0/24 dev eth0  proto kernel  scope link  src 10.1.1.48
 169.254.0.0/16 dev eth0  scope link  metric 1002
 169.254.0.0/16 dev eth1  scope link  metric 1003
 default via 10.1.1.1 dev eth1
 [root@B-regnet-shdnet-iso-vm-4 ~]# cat 
 /etc/sysconfig/network-scripts/ifcfg-eth0
 DEVICE=eth0
 BOOTPROTO=dhcp
 HWADDR=02:00:47:BD:00:06
 NM_CONTROLLED=yes
 ONBOOT=yes
 TYPE=Ethernet
 UUID=b74145e6-eaf5-4b53-b19a-9a4051fa4a75
 [root@B-regnet-shdnet-iso-vm-4 ~]# cat 
 /etc/sysconfig/network-scripts/ifcfg-eth1
 DEVICE=eth1
 BOOTPROTO=dhcp
 HWADDR=06:74:B6:00:00:3A
 NM_CONTROLLED=yes
 ONBOOT=yes
 TYPE=Ethernet
 UUID=a5afb535-0eb0-4196-a324-87aec613f38a
 [root@B-regnet-shdnet-iso-vm-4 ~]# cat /etc/redhat-release
 CentOS release 6.3 (Final)
 ===
 Git Info:
 ===
 Git Revision: 54f9af1695bc359b02e9fc906b3b335cc0bfec41
 Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git

--
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: Still cannot add KVM host

Thanks.  I'll do that - my KVM host machine was previously part of another
Cloudstack (3.0.2) environment which died on me.


On Wed, Sep 19, 2012 at 4:45 PM, Kelcey Damage (BBITS) kel...@bbits.cawrote:

 That’s a good point I had a similar issue once and it was because I
 recycled a KVM host, so there were complaints about existing storage
 domains in the libvirt logs. All I had to do was delete the old data in the
 libvirt config folders.

 Best of luck

 KELCEY DAMAGE
 Infrastructure Systems Architect
 www.backbonetechnology.com
 -
 kel...@bbits.ca

 address: 55 East 7th Ave, Vancouver, BC, V5T 1M4
 tel: +1 604 713 8560 ext:114
 fax: +1 604 605 0964
 skype: kelcey.damage



 -Original Message-
 From: Marcus Sorensen [mailto:shadow...@gmail.com]
 Sent: Wednesday, September 19, 2012 1:38 PM
 To: cloudstack-dev@incubator.apache.org
 Subject: Re: Still cannot add KVM host

 you can also check /var/log/libvirt/libvirtd.log to see what error libvirt
 might be throwing about creating storage.

 On Wed, Sep 19, 2012 at 10:26 AM, Busy Dev busyd...@gmail.com wrote:
  I'm using NFS for both primary and secondary (which are hosted by the
  same machine that hosts the management server).
 
 
  On Wed, Sep 19, 2012 at 12:13 PM, Kelceydamage@bbits kel...@bbits.ca
 wrote:
 
  I just caught that error in the logs too.
 
  Might I ask what solution your running for primary storage? And how
  it's connected to ACS?
 
  Sent from my iPhone
 
  On Sep 19, 2012, at 7:45 AM, Busy Dev busyd...@gmail.com wrote:
 
   I'll verify that.  I know the secondary storage is available...
   didn't
  try
   the primary one - but both primary and secondary are located on the
   same server.

Re: Still cannot add KVM host

ah, yes you'll want to delete the /etc/libvirt/storage directory
(assuming this is only used for cloudstack), and then restart libvirtd
before setting up the agent. Otherwise it may try to create something
that already exists. the libvirtd logs should show something.

On Wed, Sep 19, 2012 at 4:44 PM, Busy Dev busyd...@gmail.com wrote:
 Thanks.  I'll do that - my KVM host machine was previously part of another
 Cloudstack (3.0.2) environment which died on me.


 On Wed, Sep 19, 2012 at 4:45 PM, Kelcey Damage (BBITS) kel...@bbits.cawrote:

 That’s a good point I had a similar issue once and it was because I
 recycled a KVM host, so there were complaints about existing storage
 domains in the libvirt logs. All I had to do was delete the old data in the
 libvirt config folders.

 Best of luck

 KELCEY DAMAGE
 Infrastructure Systems Architect
 www.backbonetechnology.com
 -
 kel...@bbits.ca

 address: 55 East 7th Ave, Vancouver, BC, V5T 1M4
 tel: +1 604 713 8560 ext:114
 fax: +1 604 605 0964
 skype: kelcey.damage



 -Original Message-
 From: Marcus Sorensen [mailto:shadow...@gmail.com]
 Sent: Wednesday, September 19, 2012 1:38 PM
 To: cloudstack-dev@incubator.apache.org
 Subject: Re: Still cannot add KVM host

 you can also check /var/log/libvirt/libvirtd.log to see what error libvirt
 might be throwing about creating storage.

 On Wed, Sep 19, 2012 at 10:26 AM, Busy Dev busyd...@gmail.com wrote:
  I'm using NFS for both primary and secondary (which are hosted by the
  same machine that hosts the management server).
 
 
  On Wed, Sep 19, 2012 at 12:13 PM, Kelceydamage@bbits kel...@bbits.ca
 wrote:
 
  I just caught that error in the logs too.
 
  Might I ask what solution your running for primary storage? And how
  it's connected to ACS?
 
  Sent from my iPhone
 
  On Sep 19, 2012, at 7:45 AM, Busy Dev busyd...@gmail.com wrote:
 
   I'll verify that.  I know the secondary storage is available...
   didn't
  try
   the primary one - but both primary and secondary are located on the
   same server.

Re: [DOCS] API writer needed

2012-09-19 Thread Jessica Tomechak

Kelcey,
Thanks for your offer of help! I will be happy to work with you as a
resource to answer questions, help triage bugs, or direct your inquiries to
the right engineers. First off, please let me know if you're able to view
the bugbases and locate the relevant bugs.

Jessica T.
CloudStack Tech Pubs

-Original Message-

 From: Kelcey Jamison-Damage [mailto:kel...@bbits.ca]
 Sent: Monday, September 17, 2012 7:24 PM
 To: cloudstack-dev@incubator.apache.org
 Subject: Re: [DOCS] API writer needed

 I don't mind looking through this and seeing if I can pitch in a little.

 David Nalley da...@gnsa.us wrote:

 On Mon, Sep 17, 2012 at 8:29 PM, Jessica Tomechak
 jessica.tomec...@gmail.com wrote:
  There are a lot of open bugs against the CloudStack API reference.
  Historically, the API docs have gone to the bottom of the priority
 queue.
  Is there anyone here who would like to volunteer to fix these bugs? I
  am sure it would be very much appreciated not only by the tech pubs
  team but by everyone who needs to use the CloudStack API.
 
  You can find the bugs in both http://bugs.cloudstack.org and
  http://issues.apache.org/jira/browse/CLOUDSTACK.
 
  Jessica T.
  CloudStack Tech Pubs
 
 This is great low hanging fruit for folks who would like something that
 is easy to get started and yet incredibly high value.
 
 There is also documentation on how to do this:
 https://cwiki.apache.org/CLOUDSTACK/how-to-generate-cloudstack-api-docu
 mentation.html

Re: Revived - Re: [WEBSITE][DOCS] Publican-based docs publishing?

2012-09-19 Thread Jessica Tomechak

+1 for Publican website (you've convinced me!)

Now, who will set up such a website? Do we need to file a ticket with the
infrastructure team? Can it be done in time for 4.0 release?

And can we also place any other HTML there, such as our 400+ pages of API
Reference which isn't generated by Publican?

Jessica T.
CloudStack Tech Pubs



 -Original Message-
 From: Sebastien Goasguen [mailto:run...@gmail.com]
 Sent: Thursday, September 06, 2012 2:44 AM
 To: cloudstack-dev@incubator.apache.org
 Subject: Re: Revived - Re: [WEBSITE][DOCS] Publican-based docs publishing?

 +1 for Publican based docs website


 On Sep 5, 2012, at 5:56 PM, Joe Brockmeier j...@zonker.net wrote:

  Hi all,
 
  Noticed that docs.cloudstack.org is down at the moment, which reminded
  me that we haven't come to a conclusion on this topic.
 
  The options before us are:
 
  - A Publican-generated site from the CloudStack documentation.
  - A docs.cloudstack.org site powered by MindTouch wiki.
 
  The previous discussion is easily skimmable here:
 
  http://markmail.org/thread/j57gbt5g4vtbk2iw
 
  My opinion is that we should go with the Publican-generated site. It's
  much less maintenance and can easily be hosted on Apache infrastructure.
  But, please do look over the earlier thread and if you have an
  interest in participating in CloudStack docs - please do speak up with
  a preference.
 
  Thanks,
 
  Joe
 
  On Thu, Aug 16, 2012, at 02:46 PM, David Nalley wrote:
  Hi folks,
 
  Wanted to toss this out there and get some reaction.
 
  We use Publican to transform our documentation XML into consumable
  formats like HTML, EPUB, PDF, etc.
  Publican has a number of other functions, and one of those is
  publishing a documentation website. I've participated in this with
  other projects, and it seems to be relatively easy. (it's literally
  two commands to build and publish a document) So I started playing
  with this today - and you can take a look at my VERY UNPOLISHED
  results. I only spent a few hours on this today, so there is still
  plenty that needs to happen for this to look presentable, but please
  have a look.
 
  http://people.apache.org/~ke4qqq/docs
 
  A couple of things I'll point out. The interface is completely
  localized in scores of languages - and it will automagically load to
  match your browsers locale provided there are docs in that language.
  To date though we only have zh_CN, and only for a single document.
  You can also manually set your language.
  The TOC on the left is divided by 'product' [1], then by version [2],
  and then document. I will note that you are presented with all of the
  formats that the document was built for (so you'll see HTML,
  HTML-Single, PDF and EPUB and the latter two options are download
  links for the docs.) And that permits you to load your content pretty
  easily.
 
 
  [1] I'd imagine we'd generally only have a single product - Apache
  CloudStack, but perhaps there will be others, like Apache CloudStack
  Contributor Documentation which is separate from user documentation
  [2] Selecting a version shows you all available documents for that
  version in your language of choice
 
  What do folks think of presenting our 'official documentation' in
  this manner? Is it something worth pursuing? I was thinking having
  this be a docs/ subdirectory on the project site (e.g.
  incubator.apache.org/cloudstack/docs, is there a better place for it?
 
  Thoughts, comments, or flames are welcome.
 
  --David
 
  --
  Joe Brockmeier
  j...@zonker.net
  Twitter: @jzb
  http://www.dissociatedpress.net/

[jira] [Comment Edited] (CLOUDSTACK-4) Complete installation guide in XML

2012-09-19 Thread Jessica Tomechak (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458320#comment-13458320
 ] 

Jessica Tomechak edited comment on CLOUDSTACK-4 at 9/20/12 11:06 AM:
-

Community members have signed up to convert several sections. A few sections 
still need a champion. See 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Convert+Installation+Guide+to+Docbook+XML

  was (Author: jtomechak):
See 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Convert+Installation+Guide+to+Docbook+XML
  
 Complete installation guide in XML
 --

 Key: CLOUDSTACK-4
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4
 Project: CloudStack
  Issue Type: Bug
  Components: Doc
Affects Versions: 4.0.0
Reporter: Jessica Tomechak
Assignee: Jessica Tomechak
 Fix For: pre-4.0.0


 Some sections of the 3.x installation guide are not present in the 4.x 
 installation guide. Need to add complete docbook XML files in the /docs 
 directory.

--
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

issue/bug with multiple guest networks?

Cloudstack seems to let you create guest traffic types on multiple
physical networks. However, when I try this with KVM I end up always
bridging to whatever device is used for guest.network.device.

It looks like the issue is in
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java,
in the plug function.

if (nic.getType() == Networks.TrafficType.Guest) {
if (nic.getBroadcastType() == Networks.BroadcastDomainType.Vlan
 !vlanId.equalsIgnoreCase(untagged)) {
String brName = createVlanBr(vlanId, _pifs.get(private));

that is, if nic is a guest traffic type, create its bridge on
private, which is found by searching for guest.network.device. We
are passed the physicalnetwork bridge that we should be using (or at
least the KVM traffic label that should be used for the nic, which is
the same thing, no?) in StartCommand, so I'm not getting why it's
hardcoded to use the guest.network.device.

I'll look at fixing this, but as usual I'd like any background on this
that I can get, so I don't break it for others.

Also, should we not change the cloudVirBr prefix to include a physical
network identifier? It sort of seems like there's support for adding
vlans as well to each guest traffic on each physical network (e.g.
vlan 100-200 on physical network 1, vlan 100-200 on physical network
2, etc), but with the existing naming convention the bridge names will
collide. Perhaps there's more to it than that, but it seems like
changing the naming would be a first step.

Feedback?

RE: issue/bug with multiple guest networks?

2012-09-19 Thread Edison Su

 -Original Message-
 From: Marcus Sorensen [mailto:shadow...@gmail.com]
 Sent: Wednesday, September 19, 2012 5:18 PM
 To: cloudstack-dev@incubator.apache.org
 Subject: issue/bug with multiple guest networks?

 Cloudstack seems to let you create guest traffic types on multiple
 physical networks. However, when I try this with KVM I end up always
 bridging to whatever device is used for guest.network.device.

 It looks like the issue is in
 plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVif
 Driver.java,
 in the plug function.

 if (nic.getType() == Networks.TrafficType.Guest) {
 if (nic.getBroadcastType() ==
 Networks.BroadcastDomainType.Vlan
  !vlanId.equalsIgnoreCase(untagged)) {
 String brName = createVlanBr(vlanId,
 _pifs.get(private));

 that is, if nic is a guest traffic type, create its bridge on
 private, which is found by searching for guest.network.device. We
 are passed the physicalnetwork bridge that we should be using (or at
 least the KVM traffic label that should be used for the nic, which is

Yes, should create bridge based on NicTO.getName(), instead of always on 
private network.

 the same thing, no?) in StartCommand, so I'm not getting why it's
 hardcoded to use the guest.network.device.

It's a bug.

 I'll look at fixing this, but as usual I'd like any background on this
 that I can get, so I don't break it for others.

 Also, should we not change the cloudVirBr prefix to include a physical
 network identifier? It sort of seems like there's support for adding
 vlans as well to each guest traffic on each physical network (e.g.
 vlan 100-200 on physical network 1, vlan 100-200 on physical network
 2, etc), but with the existing naming convention the bridge names will
 collide. Perhaps there's more to it than that, but it seems like
 changing the naming would be a first step.

Can change the name schema to br-device-name-vlan-number: e.g brEth1?

 Feedback?

[jira] [Commented] (CLOUDSTACK-152) Routes on the User VM are programmed incorrectly on a VM present on both Isolated and Shared Guest Networks


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459284#comment-13459284
 ] 

Sheng Yang commented on CLOUDSTACK-152:
---

Please refer to:

http://bugs.cloud.com/show_bug.cgi?id=14042

 Routes on the User VM are programmed incorrectly on a VM present on both 
 Isolated and Shared Guest Networks
 ---

 Key: CLOUDSTACK-152
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-152
 Project: CloudStack
  Issue Type: Bug
  Components: Management Server
Affects Versions: pre-4.0.0
Reporter: Chandan Purushothama
 Fix For: pre-4.0.0

 Attachments: messagesontheUserVM.zip


 ==
 Steps to Reproduce:
 ==
 1. As the Admin of ROOT domain, Create a shared guest network using the 
 DefaultNetworkOfferingforSharedNetworks.
 2. Login as a Regular User. Create an isolated guest network using the 
 DefaultNetworkOfferingwithSourceNATService
 3. Register a CentOS6.3_x86_64 ISO
 4. Deploy a VM on the Isolated and Shared Guest Network using the ISO. Make 
 sure that the Isolated Guest Network is chosen as the default Guest Network.
 5. View the VM's Console. Observe that the only IP Address present on the VM 
 is the loopback address.
 6. Edit the two ifcfg-ethx files present under 
 /etc/sysconfig/network-scripts/. Set the ONBOOT parameter to yes.
 7. Reboot the VM or restart the network service.
 8. Observe the routes on the VM after the Reboot.
 ==
 Observations:
 ==
 [root@B-regnet-shdnet-iso-vm-4 ~]# history
 1  ifconfig
 2  reboot
 3  history
 [root@B-regnet-shdnet-iso-vm-4 ~]# ifconfig
 eth0  Link encap:Ethernet  HWaddr 02:00:47:BD:00:06
   inet addr:10.1.1.48  Bcast:10.1.1.255  Mask:255.255.255.0
   inet6 addr: fe80::47ff:febd:6/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:2 errors:0 dropped:0 overruns:0 frame:0
   TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:379 (379.0 b)  TX bytes:1116 (1.0 KiB)
   Interrupt:165
 eth1  Link encap:Ethernet  HWaddr 06:74:B6:00:00:3A
   inet addr:10.223.137.78  Bcast:10.223.137.127  Mask:255.255.255.192
   inet6 addr: fe80::474:b6ff:fe00:3a/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:108 errors:0 dropped:0 overruns:0 frame:0
   TX packets:84 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:9425 (9.2 KiB)  TX bytes:10289 (10.0 KiB)
   Interrupt:164
 loLink encap:Local Loopback
   inet addr:127.0.0.1  Mask:255.0.0.0
   inet6 addr: ::1/128 Scope:Host
   UP LOOPBACK RUNNING  MTU:16436  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
 **Observe that except the second and the third route all the remaining routes 
 are wrong. Notice that 10.1.1.48 is on eth0 while 10.223.137.78 is on eth1**
 [root@B-regnet-shdnet-iso-vm-4 ~]# ip route
 10.1.1.1 dev eth1  scope link
 10.223.137.64/26 dev eth1  proto kernel  scope link  src 10.223.137.78
 10.1.1.0/24 dev eth0  proto kernel  scope link  src 10.1.1.48
 169.254.0.0/16 dev eth0  scope link  metric 1002
 169.254.0.0/16 dev eth1  scope link  metric 1003
 default via 10.1.1.1 dev eth1
 [root@B-regnet-shdnet-iso-vm-4 ~]# cat 
 /etc/sysconfig/network-scripts/ifcfg-eth0
 DEVICE=eth0
 BOOTPROTO=dhcp
 HWADDR=02:00:47:BD:00:06
 NM_CONTROLLED=yes
 ONBOOT=yes
 TYPE=Ethernet
 UUID=b74145e6-eaf5-4b53-b19a-9a4051fa4a75
 [root@B-regnet-shdnet-iso-vm-4 ~]# cat 
 /etc/sysconfig/network-scripts/ifcfg-eth1
 DEVICE=eth1
 BOOTPROTO=dhcp
 HWADDR=06:74:B6:00:00:3A
 NM_CONTROLLED=yes
 ONBOOT=yes
 TYPE=Ethernet
 UUID=a5afb535-0eb0-4196-a324-87aec613f38a
 [root@B-regnet-shdnet-iso-vm-4 ~]# cat /etc/redhat-release
 CentOS release 6.3 (Final)
 ===
 Git Info:
 ===
 Git Revision: 54f9af1695bc359b02e9fc906b3b335cc0bfec41
 Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git

--
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-152) Routes on the User VM are programmed incorrectly on a VM present on both Isolated and Shared Guest Networks


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

Sheng Yang updated CLOUDSTACK-152:
--

Comment: was deleted

(was: Please refer to:

http://bugs.cloud.com/show_bug.cgi?id=14042)

 Routes on the User VM are programmed incorrectly on a VM present on both 
 Isolated and Shared Guest Networks
 ---

 Key: CLOUDSTACK-152
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-152
 Project: CloudStack
  Issue Type: Bug
  Components: Management Server
Affects Versions: pre-4.0.0
Reporter: Chandan Purushothama
 Fix For: pre-4.0.0

 Attachments: messagesontheUserVM.zip


 ==
 Steps to Reproduce:
 ==
 1. As the Admin of ROOT domain, Create a shared guest network using the 
 DefaultNetworkOfferingforSharedNetworks.
 2. Login as a Regular User. Create an isolated guest network using the 
 DefaultNetworkOfferingwithSourceNATService
 3. Register a CentOS6.3_x86_64 ISO
 4. Deploy a VM on the Isolated and Shared Guest Network using the ISO. Make 
 sure that the Isolated Guest Network is chosen as the default Guest Network.
 5. View the VM's Console. Observe that the only IP Address present on the VM 
 is the loopback address.
 6. Edit the two ifcfg-ethx files present under 
 /etc/sysconfig/network-scripts/. Set the ONBOOT parameter to yes.
 7. Reboot the VM or restart the network service.
 8. Observe the routes on the VM after the Reboot.
 ==
 Observations:
 ==
 [root@B-regnet-shdnet-iso-vm-4 ~]# history
 1  ifconfig
 2  reboot
 3  history
 [root@B-regnet-shdnet-iso-vm-4 ~]# ifconfig
 eth0  Link encap:Ethernet  HWaddr 02:00:47:BD:00:06
   inet addr:10.1.1.48  Bcast:10.1.1.255  Mask:255.255.255.0
   inet6 addr: fe80::47ff:febd:6/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:2 errors:0 dropped:0 overruns:0 frame:0
   TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:379 (379.0 b)  TX bytes:1116 (1.0 KiB)
   Interrupt:165
 eth1  Link encap:Ethernet  HWaddr 06:74:B6:00:00:3A
   inet addr:10.223.137.78  Bcast:10.223.137.127  Mask:255.255.255.192
   inet6 addr: fe80::474:b6ff:fe00:3a/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:108 errors:0 dropped:0 overruns:0 frame:0
   TX packets:84 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:9425 (9.2 KiB)  TX bytes:10289 (10.0 KiB)
   Interrupt:164
 loLink encap:Local Loopback
   inet addr:127.0.0.1  Mask:255.0.0.0
   inet6 addr: ::1/128 Scope:Host
   UP LOOPBACK RUNNING  MTU:16436  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
 **Observe that except the second and the third route all the remaining routes 
 are wrong. Notice that 10.1.1.48 is on eth0 while 10.223.137.78 is on eth1**
 [root@B-regnet-shdnet-iso-vm-4 ~]# ip route
 10.1.1.1 dev eth1  scope link
 10.223.137.64/26 dev eth1  proto kernel  scope link  src 10.223.137.78
 10.1.1.0/24 dev eth0  proto kernel  scope link  src 10.1.1.48
 169.254.0.0/16 dev eth0  scope link  metric 1002
 169.254.0.0/16 dev eth1  scope link  metric 1003
 default via 10.1.1.1 dev eth1
 [root@B-regnet-shdnet-iso-vm-4 ~]# cat 
 /etc/sysconfig/network-scripts/ifcfg-eth0
 DEVICE=eth0
 BOOTPROTO=dhcp
 HWADDR=02:00:47:BD:00:06
 NM_CONTROLLED=yes
 ONBOOT=yes
 TYPE=Ethernet
 UUID=b74145e6-eaf5-4b53-b19a-9a4051fa4a75
 [root@B-regnet-shdnet-iso-vm-4 ~]# cat 
 /etc/sysconfig/network-scripts/ifcfg-eth1
 DEVICE=eth1
 BOOTPROTO=dhcp
 HWADDR=06:74:B6:00:00:3A
 NM_CONTROLLED=yes
 ONBOOT=yes
 TYPE=Ethernet
 UUID=a5afb535-0eb0-4196-a324-87aec613f38a
 [root@B-regnet-shdnet-iso-vm-4 ~]# cat /etc/redhat-release
 CentOS release 6.3 (Final)
 ===
 Git Info:
 ===
 Git Revision: 54f9af1695bc359b02e9fc906b3b335cc0bfec41
 Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git

--
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-152) Routes on the User VM are programmed incorrectly on a VM present on both Isolated and Shared Guest Networks


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459285#comment-13459285
 ] 

Sheng Yang commented on CLOUDSTACK-152:
---

Please refer to http://bugs.cloudstack.org/browse/CS-13836

I think here the wrong guest OS type cause the bug.

 Routes on the User VM are programmed incorrectly on a VM present on both 
 Isolated and Shared Guest Networks
 ---

 Key: CLOUDSTACK-152
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-152
 Project: CloudStack
  Issue Type: Bug
  Components: Management Server
Affects Versions: pre-4.0.0
Reporter: Chandan Purushothama
 Fix For: pre-4.0.0

 Attachments: messagesontheUserVM.zip


 ==
 Steps to Reproduce:
 ==
 1. As the Admin of ROOT domain, Create a shared guest network using the 
 DefaultNetworkOfferingforSharedNetworks.
 2. Login as a Regular User. Create an isolated guest network using the 
 DefaultNetworkOfferingwithSourceNATService
 3. Register a CentOS6.3_x86_64 ISO
 4. Deploy a VM on the Isolated and Shared Guest Network using the ISO. Make 
 sure that the Isolated Guest Network is chosen as the default Guest Network.
 5. View the VM's Console. Observe that the only IP Address present on the VM 
 is the loopback address.
 6. Edit the two ifcfg-ethx files present under 
 /etc/sysconfig/network-scripts/. Set the ONBOOT parameter to yes.
 7. Reboot the VM or restart the network service.
 8. Observe the routes on the VM after the Reboot.
 ==
 Observations:
 ==
 [root@B-regnet-shdnet-iso-vm-4 ~]# history
 1  ifconfig
 2  reboot
 3  history
 [root@B-regnet-shdnet-iso-vm-4 ~]# ifconfig
 eth0  Link encap:Ethernet  HWaddr 02:00:47:BD:00:06
   inet addr:10.1.1.48  Bcast:10.1.1.255  Mask:255.255.255.0
   inet6 addr: fe80::47ff:febd:6/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:2 errors:0 dropped:0 overruns:0 frame:0
   TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:379 (379.0 b)  TX bytes:1116 (1.0 KiB)
   Interrupt:165
 eth1  Link encap:Ethernet  HWaddr 06:74:B6:00:00:3A
   inet addr:10.223.137.78  Bcast:10.223.137.127  Mask:255.255.255.192
   inet6 addr: fe80::474:b6ff:fe00:3a/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:108 errors:0 dropped:0 overruns:0 frame:0
   TX packets:84 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:9425 (9.2 KiB)  TX bytes:10289 (10.0 KiB)
   Interrupt:164
 loLink encap:Local Loopback
   inet addr:127.0.0.1  Mask:255.0.0.0
   inet6 addr: ::1/128 Scope:Host
   UP LOOPBACK RUNNING  MTU:16436  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
 **Observe that except the second and the third route all the remaining routes 
 are wrong. Notice that 10.1.1.48 is on eth0 while 10.223.137.78 is on eth1**
 [root@B-regnet-shdnet-iso-vm-4 ~]# ip route
 10.1.1.1 dev eth1  scope link
 10.223.137.64/26 dev eth1  proto kernel  scope link  src 10.223.137.78
 10.1.1.0/24 dev eth0  proto kernel  scope link  src 10.1.1.48
 169.254.0.0/16 dev eth0  scope link  metric 1002
 169.254.0.0/16 dev eth1  scope link  metric 1003
 default via 10.1.1.1 dev eth1
 [root@B-regnet-shdnet-iso-vm-4 ~]# cat 
 /etc/sysconfig/network-scripts/ifcfg-eth0
 DEVICE=eth0
 BOOTPROTO=dhcp
 HWADDR=02:00:47:BD:00:06
 NM_CONTROLLED=yes
 ONBOOT=yes
 TYPE=Ethernet
 UUID=b74145e6-eaf5-4b53-b19a-9a4051fa4a75
 [root@B-regnet-shdnet-iso-vm-4 ~]# cat 
 /etc/sysconfig/network-scripts/ifcfg-eth1
 DEVICE=eth1
 BOOTPROTO=dhcp
 HWADDR=06:74:B6:00:00:3A
 NM_CONTROLLED=yes
 ONBOOT=yes
 TYPE=Ethernet
 UUID=a5afb535-0eb0-4196-a324-87aec613f38a
 [root@B-regnet-shdnet-iso-vm-4 ~]# cat /etc/redhat-release
 CentOS release 6.3 (Final)
 ===
 Git Info:
 ===
 Git Revision: 54f9af1695bc359b02e9fc906b3b335cc0bfec41
 Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git

--
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: issue/bug with multiple guest networks?

Thanks, I'll fix this. I am assuming that we leave the current method in
place if nicTO.getName fails or some such? Just thinking about when to
default to the getPifs stuff and when to use the name.
On Sep 19, 2012 7:36 PM, Edison Su edison...@citrix.com wrote:

  -Original Message-
  From: Marcus Sorensen [mailto:shadow...@gmail.com]
  Sent: Wednesday, September 19, 2012 5:18 PM
  To: cloudstack-dev@incubator.apache.org
  Subject: issue/bug with multiple guest networks?

  Cloudstack seems to let you create guest traffic types on multiple
  physical networks. However, when I try this with KVM I end up always
  bridging to whatever device is used for guest.network.device.

  It looks like the issue is in
  plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVif
  Driver.java,
  in the plug function.

  if (nic.getType() == Networks.TrafficType.Guest) {
  if (nic.getBroadcastType() ==
  Networks.BroadcastDomainType.Vlan
   !vlanId.equalsIgnoreCase(untagged)) {
  String brName = createVlanBr(vlanId,
  _pifs.get(private));

  that is, if nic is a guest traffic type, create its bridge on
  private, which is found by searching for guest.network.device. We
  are passed the physicalnetwork bridge that we should be using (or at
  least the KVM traffic label that should be used for the nic, which is

 Yes, should create bridge based on NicTO.getName(), instead of always on
 private network.

  the same thing, no?) in StartCommand, so I'm not getting why it's
  hardcoded to use the guest.network.device.

 It's a bug.

  I'll look at fixing this, but as usual I'd like any background on this
  that I can get, so I don't break it for others.

  Also, should we not change the cloudVirBr prefix to include a physical
  network identifier? It sort of seems like there's support for adding
  vlans as well to each guest traffic on each physical network (e.g.
  vlan 100-200 on physical network 1, vlan 100-200 on physical network
  2, etc), but with the existing naming convention the bridge names will
  collide. Perhaps there's more to it than that, but it seems like
  changing the naming would be a first step.

 Can change the name schema to br-device-name-vlan-number: e.g brEth1?

  Feedback?

Re: Still cannot add KVM host

This was the issue! Thanks!  My cloud seems to be up and running.  Now I
just need to import a template and deploy a VM.

Anyone know if the startvm parameter of deployVM is honored by
Cloudstack?  It was documented in 3.0.2 as being a valid parameter but had
no effect on deployVM... the new VM always started.

Thanks everyone for your help.



On Wed, Sep 19, 2012 at 6:51 PM, Marcus Sorensen shadow...@gmail.comwrote:

 ah, yes you'll want to delete the /etc/libvirt/storage directory
 (assuming this is only used for cloudstack), and then restart libvirtd
 before setting up the agent. Otherwise it may try to create something
 that already exists. the libvirtd logs should show something.

 On Wed, Sep 19, 2012 at 4:44 PM, Busy Dev busyd...@gmail.com wrote:
  Thanks.  I'll do that - my KVM host machine was previously part of
 another
  Cloudstack (3.0.2) environment which died on me.
 
 
  On Wed, Sep 19, 2012 at 4:45 PM, Kelcey Damage (BBITS) kel...@bbits.ca
 wrote:
 
  That’s a good point I had a similar issue once and it was because I
  recycled a KVM host, so there were complaints about existing storage
  domains in the libvirt logs. All I had to do was delete the old data in
 the
  libvirt config folders.
 
  Best of luck
 
  KELCEY DAMAGE
  Infrastructure Systems Architect
  www.backbonetechnology.com
 
 -
  kel...@bbits.ca
 
  address: 55 East 7th Ave, Vancouver, BC, V5T 1M4
  tel: +1 604 713 8560 ext:114
  fax: +1 604 605 0964
  skype: kelcey.damage
 
 
 
  -Original Message-
  From: Marcus Sorensen [mailto:shadow...@gmail.com]
  Sent: Wednesday, September 19, 2012 1:38 PM
  To: cloudstack-dev@incubator.apache.org
  Subject: Re: Still cannot add KVM host
 
  you can also check /var/log/libvirt/libvirtd.log to see what error
 libvirt
  might be throwing about creating storage.
 
  On Wed, Sep 19, 2012 at 10:26 AM, Busy Dev busyd...@gmail.com wrote:
   I'm using NFS for both primary and secondary (which are hosted by the
   same machine that hosts the management server).
  
  
   On Wed, Sep 19, 2012 at 12:13 PM, Kelceydamage@bbits kel...@bbits.ca
  wrote:
  
   I just caught that error in the logs too.
  
   Might I ask what solution your running for primary storage? And how
   it's connected to ACS?
  
   Sent from my iPhone
  
   On Sep 19, 2012, at 7:45 AM, Busy Dev busyd...@gmail.com wrote:
  
I'll verify that.  I know the secondary storage is available...
didn't
   try
the primary one - but both primary and secondary are located on the
same server.

Re: Still cannot add KVM host