Re: Review Request 21628: CLOUDSTACK-6282: Automated network API Tests and uploaded patch
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21628/ --- (Updated May 29, 2014, 6:13 a.m.) Review request for cloudstack and Santhosh Edukulla. Changes --- Updated latest patch after removing all the whitespaces and extra lines whereever applicable. Review the same and do the needful Bugs: CLOUDSTACK-6282 https://issues.apache.org/jira/browse/CLOUDSTACK-6282 Repository: cloudstack-git Description --- Automated network API Tests and uploaded patch Diffs (updated) - test/integration/component/test_escalations_networks.py PRE-CREATION tools/marvin/marvin/config/test_data.py 52be02d tools/marvin/marvin/lib/base.py a301e25 Diff: https://reviews.apache.org/r/21628/diff/ Testing --- Executed all the Network tests and uploaded the results file File Attachments results.txt https://reviews.apache.org/media/uploaded/files/2014/05/19/0574d454-3aae-4cf4-9c45-af8fc678b487__results.txt Results https://reviews.apache.org/media/uploaded/files/2014/05/23/12f03114-aeeb-4856-9450-cce2826c75c3__NetworksResults.txt Thanks, Monis Majeed
[ANNOUNCE] Saksham Srivastava as committer
The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
[ACS 4.3] listUsageRecords API bug related to CLOUDSTACK-6472
Dear guys
I found a bug about listUsageRecords API in 4.3 related to a issue
CLOUDSTACK-6472 and made a patch. Would you review the patch and
correct me if I am wrong?
Sam Schmit push a commit about NPEs/Null UUIDs at May 5th but I think
his commit is not enough.
commit e8047e11db7ef2bdc44bbedfdc47e63c55f080c5
Author: Sam Schmit sam.sch...@appcore.com
Date: Mon May 5 16:38:23 2014 -0500
CLOUDSTACK-6472 (4.3 specific) listUsageRecords: Pull
information from removed items as well, fixing NPEs/Null UUIDs with
usage API calls.
Signed-off-by: Sebastien Goasguen run...@gmail.com
When I called listUsageRecords against CloudStack 4.3 management
server that was build at latest 4.3 branch, usage records about
destroyed instances of usage type 1 and 2 lacked 'virtualmachineid' as
below.
{
account: sgcadm,
accountid: f9e4e1ca-69fd-4ae3-b70c-15bbcc13406e,
description: mycluster-front allocated (ServiceOffering: 13)
(Template: 203),
domainid: 84dd635d-fb99-4895-b199-7d777aa144d5,
enddate: 2014-05-20'T'08:59:59+09:00,
name: mycluster-front,
offeringid: e5137018-8fca-4e4a-a79e-9e4d1707e079,
rawusage: 0.223611,
startdate: 2014-05-19'T'09:00:00+09:00,
templateid: 1ebdc71e-dcbe-4d3e-82d3-d31897f78d4c,
type: KVM,
usage: 0.223611 Hrs,
usageid: 09f3d7d6-3c6a-4326-b3d3-fb51506e669d,
usagetype: 2,
zoneid: c2ba1354-0c15-4284-bdba-4f201767362d
},
Hence, it is unable to refer to any destroyed instance id. I patched
createUsageResponse method like this.
diff --git a/server/src/com/cloud/api/ApiResponseHelper.java
b/server/src/com/cloud/api/ApiResponseHelper.java
index 7718fc1..cbf3914 100755
--- a/server/src/com/cloud/api/ApiResponseHelper.java
+++ b/server/src/com/cloud/api/ApiResponseHelper.java
@@ -3304,7 +3304,7 @@ public class ApiResponseHelper implements
ResponseGenerator {
usageRecResponse.setUsage(usageRecord.getUsageDisplay());
usageRecResponse.setUsageType(usageRecord.getUsageType());
if (usageRecord.getVmInstanceId() != null) {
-VMInstanceVO vm =
_entityMgr.findById(VMInstanceVO.class,
usageRecord.getVmInstanceId());
+VMInstanceVO vm =
_entityMgr.findByIdIncludingRemoved(VMInstanceVO.class,
usageRecord.getVmInstanceId());
if (vm != null) {
usageRecResponse.setVirtualMachineId(vm.getUuid());
}
After that, listUsageRecords API contains 'virtualmachineid' whether
or not instances are destroyed. Here is a result.
{
account: sgcadm,
accountid: f9e4e1ca-69fd-4ae3-b70c-15bbcc13406e,
description: mycluster-front allocated (ServiceOffering: 13)
(Template: 203),
domainid: 84dd635d-fb99-4895-b199-7d777aa144d5,
enddate: 2014-05-20'T'08:59:59+09:00,
name: mycluster-front,
offeringid: e5137018-8fca-4e4a-a79e-9e4d1707e079,
rawusage: 0.223611,
startdate: 2014-05-19'T'09:00:00+09:00,
templateid: 1ebdc71e-dcbe-4d3e-82d3-d31897f78d4c,
type: KVM,
usage: 0.223611 Hrs,
usageid: 09f3d7d6-3c6a-4326-b3d3-fb51506e669d,
usagetype: 2,
virtualmachineid: 09f3d7d6-3c6a-4326-b3d3-fb51506e669d,
zoneid: c2ba1354-0c15-4284-bdba-4f201767362d
},
I think this is an expectecd behaviour, so please review and test this
patch.
Best Regards
--
Hiroki Ohashi
Re: [ACS 4.3] listUsageRecords API bug related to CLOUDSTACK-6472
On May 29, 2014, at 9:26 AM, Hiroki Ohashi hiroki.s...@gmail.com wrote:
Dear guys
I found a bug about listUsageRecords API in 4.3 related to a issue
CLOUDSTACK-6472 and made a patch. Would you review the patch and
correct me if I am wrong?
Sam Schmit push a commit about NPEs/Null UUIDs at May 5th but I think
his commit is not enough.
commit e8047e11db7ef2bdc44bbedfdc47e63c55f080c5
Author: Sam Schmit sam.sch...@appcore.com
Date: Mon May 5 16:38:23 2014 -0500
CLOUDSTACK-6472 (4.3 specific) listUsageRecords: Pull
information from removed items as well, fixing NPEs/Null UUIDs with
usage API calls.
Signed-off-by: Sebastien Goasguen run...@gmail.com
When I called listUsageRecords against CloudStack 4.3 management
server that was build at latest 4.3 branch, usage records about
destroyed instances of usage type 1 and 2 lacked 'virtualmachineid' as
below.
{
account: sgcadm,
accountid: f9e4e1ca-69fd-4ae3-b70c-15bbcc13406e,
description: mycluster-front allocated (ServiceOffering: 13)
(Template: 203),
domainid: 84dd635d-fb99-4895-b199-7d777aa144d5,
enddate: 2014-05-20'T'08:59:59+09:00,
name: mycluster-front,
offeringid: e5137018-8fca-4e4a-a79e-9e4d1707e079,
rawusage: 0.223611,
startdate: 2014-05-19'T'09:00:00+09:00,
templateid: 1ebdc71e-dcbe-4d3e-82d3-d31897f78d4c,
type: KVM,
usage: 0.223611 Hrs,
usageid: 09f3d7d6-3c6a-4326-b3d3-fb51506e669d,
usagetype: 2,
zoneid: c2ba1354-0c15-4284-bdba-4f201767362d
},
Hence, it is unable to refer to any destroyed instance id. I patched
createUsageResponse method like this.
diff --git a/server/src/com/cloud/api/ApiResponseHelper.java
b/server/src/com/cloud/api/ApiResponseHelper.java
index 7718fc1..cbf3914 100755
--- a/server/src/com/cloud/api/ApiResponseHelper.java
+++ b/server/src/com/cloud/api/ApiResponseHelper.java
@@ -3304,7 +3304,7 @@ public class ApiResponseHelper implements
ResponseGenerator {
usageRecResponse.setUsage(usageRecord.getUsageDisplay());
usageRecResponse.setUsageType(usageRecord.getUsageType());
if (usageRecord.getVmInstanceId() != null) {
-VMInstanceVO vm =
_entityMgr.findById(VMInstanceVO.class,
usageRecord.getVmInstanceId());
+VMInstanceVO vm =
_entityMgr.findByIdIncludingRemoved(VMInstanceVO.class,
usageRecord.getVmInstanceId());
if (vm != null) {
usageRecResponse.setVirtualMachineId(vm.getUuid());
}
Looks like an omission to me, I went ahead and patched it:
commit 24e03bed560feb959a61126b76c2d6971e77092e
Author: Sebastien Goasguen run...@gmail.com
Date: Thu May 29 09:48:46 2014 +0200
Fix usage response, patch by Hiroki Ohashi
We can always revert if people don't agree.
Can you pull the latest 4.3 and try it.
Thanks for the patch. you can always attach a patch at http://reviews.apache.org
and follow the instructions at http://cloudstack.apache.org/developers.html
After that, listUsageRecords API contains 'virtualmachineid' whether
or not instances are destroyed. Here is a result.
{
account: sgcadm,
accountid: f9e4e1ca-69fd-4ae3-b70c-15bbcc13406e,
description: mycluster-front allocated (ServiceOffering: 13)
(Template: 203),
domainid: 84dd635d-fb99-4895-b199-7d777aa144d5,
enddate: 2014-05-20'T'08:59:59+09:00,
name: mycluster-front,
offeringid: e5137018-8fca-4e4a-a79e-9e4d1707e079,
rawusage: 0.223611,
startdate: 2014-05-19'T'09:00:00+09:00,
templateid: 1ebdc71e-dcbe-4d3e-82d3-d31897f78d4c,
type: KVM,
usage: 0.223611 Hrs,
usageid: 09f3d7d6-3c6a-4326-b3d3-fb51506e669d,
usagetype: 2,
virtualmachineid: 09f3d7d6-3c6a-4326-b3d3-fb51506e669d,
zoneid: c2ba1354-0c15-4284-bdba-4f201767362d
},
I think this is an expectecd behaviour, so please review and test this
patch.
Best Regards
--
Hiroki Ohashi
RE: [ANNOUNCE] Saksham Srivastava as committer
Congrats Saksham -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, May 29, 2014 12:18 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
RE: [ANNOUNCE] Saksham Srivastava as committer
Congrats Saksham!! -Original Message- From: Anshul Gangwar [mailto:anshul.gang...@citrix.com] Sent: 29 May 2014 13:32 To: dev@cloudstack.apache.org Subject: RE: [ANNOUNCE] Saksham Srivastava as committer Congrats Saksham -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, May 29, 2014 12:18 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
RE: [ANNOUNCE] Saksham Srivastava as committer
Hearty Congrats Saksham! -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, May 29, 2014 12:18 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
Re: VPC's VR missing public NIC eth1
Will try, thx. Not sure good question - when is 4.4 scheduled to be
releases - few months, or more ?
Thanks
On 29 May 2014 06:15, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.comwrote:
Hi Andrija,
Same issue with public vlan tagged got fixed, CLOUDSTACK-5505.
Thanks,
Jayapal
On 29-May-2014, at 9:38 AM, Jayapal Reddy Uradi
jayapalreddy.ur...@citrix.com
wrote:
Hi Adrija,
From the logs, the public subnet is untagged.
I think this issue is coming for the untagged public vlan in 4.3.
1.
{com.cloud.agent.api.PlugNicCommand:{nic:{deviceId:1,networkRateMbps:9,defaultNic:true,uuid:e6b734d4-3302-4113-8ec7-5c205c90959a,ip:46.232.180.248,netmask:255.255.255.0,gateway:46.232.180.1,mac:06:5e:e8:00:00:27,broadcastType:Vlan,type:Public,broadcastUri:vlan://untagged,isolationUri:vlan://untagged,isSecurityGroupEnabled:false,name:breth1-500},
2.
3.
instanceName:r-779-VM,vmType:DomainRouter,wait:0}},{com.cloud.agent.api.routing.IpAssocVpcCommand:{ipAddresses:[{accountId:2,publicIp:46.232.180.248,sourceNat:true,add:true,oneToOneNat:false,firstIP:false,broadcastUri:untagged,vlanGateway:46.232.180.1,vlanNetmask:255.255.255.0,vifMacAddress:06:5e:e8:00:00:27,networkRate:9,trafficType:Public,networkName:breth1-500}],accessDetails:
From the logs VR logs, the ipassoc script got the interface id as null.
May 28 12:37:33 r-794-VM cloud: vpc_ipassoc.sh:Waiting for interface
ethnull to appear, 0 seconds
Thanks,
Jayapal
On 29-May-2014, at 1:08 AM, Andrija Panic andrija.pa...@gmail.com
mailto:andrija.pa...@gmail.com wrote:
Thanks Daan,
my problem is that I'm in production for 3rd day now, and restoring DB
and
downgrading back to 4.2.1 doesn't seem as option for me at the moment,
since I would loose new acounts and single VMs, etc...
Thanks,
Andrija
On 28 May 2014 21:34, Daan Hoogland daan.hoogl...@gmail.commailto:
daan.hoogl...@gmail.com wrote:
Andrija,
nevertheless it sounds familiar. I will be back in the office on
monday and ask around.
On Wed, May 28, 2014 at 9:23 PM, Andrija Panic andrija.pa...@gmail.com
mailto:andrija.pa...@gmail.com
wrote:
Hi Daan,
I don't think this is my issue, at least I don't make use of private
gateway - this is just simple as: create new VPC from scratch - Public
IP
is not assigned to VR eth1 interface inside VR...
I have filed the bug:
https://issues.apache.org/jira/browse/CLOUDSTACK-6801
This same thing happened previously to Andrei Mikhailovsky:
http://mail-archives.apache.org/mod_mbox/cloudstack-users/201405.mbox/%3C33347835.250.1399336340785.JavaMail.andrei@tuchka%3Eand
it is not resolved
Thanks,
Andrija
On 28 May 2014 21:01, Daan Hoogland daan.hoogl...@gmail.com wrote:
Andrija,
this sound like something we seen as well.
can you check if this is it :
https://issues.apache.org/jira/browse/CLOUDSTACK-6485
thanks,
Daan
On Wed, May 28, 2014 at 3:30 PM, Andrija Panic andrija.pa...@gmail.com
wrote:
Hi there,
I'm having big time problems with Public IP missing from VPC VR's
eth1,
after upgrade to ACS 4.3.1 - did not found this filed as bug so
far...and
it worked all fine on ACS 4.2.1.
No help so far from user mailing list...
Below is a detailed explanation, and logs from inside VR, and from
management (all fine with management logs...)
If anybody can help, I would very much appriciate this, since now I
have
bunch fo VPC unoperational...
Thanks
-- Forwarded message --
From: Andrija Panic andrija.pa...@gmail.com
Date: 28 May 2014 14:50
Subject: Re: VPC's VR missing public NIC eth1
To: us...@cloudstack.apache.org
and as I said eth1 is present:
root@r-794-VM:~# cat /proc/net/dev
Inter-| Receive|
Transmit
face |bytespackets errs drop fifo frame compressed
multicast|bytes
packets errs drop fifo colls carrier compressed
eth3: 11484 131000 0 0 0
11590
131000 0 0 0
lo: 214 2000 0 0 0
214
2000 0 0 0
eth2: 32970 544000 0 0 0
2084
24000 0 0 0
eth1: 0 0000 0 0 0
0
0000 0 0 0
eth0: 1502071319000 0 0 0
264232
1180000 0 0 0
On 28 May 2014 14:47, Andrija Panic andrija.pa...@gmail.com wrote:
Also, from /var/log/messages/ inside VR:
This is a major show stopper - all our VPCs are unusable complete.
Anybody... ?
May 28 12:37:33 r-794-VM cloud: vpc_ipassoc.sh:Waiting for interface
ethnull to appear, 0 seconds
May 28 12:37:34 r-794-VM cloud: vpc_ipassoc.sh:Waiting for interface
ethnull to
Re: VPC's VR missing public NIC eth1
Andrija, we plan to release it soon. It depends on how quickly issues
in it are fixed. The branch has been created, so you could test it and
report on it if you have an env to spare.
On Thu, May 29, 2014 at 10:09 AM, Andrija Panic andrija.pa...@gmail.com wrote:
Will try, thx. Not sure good question - when is 4.4 scheduled to be
releases - few months, or more ?
Thanks
On 29 May 2014 06:15, Jayapal Reddy Uradi
jayapalreddy.ur...@citrix.comwrote:
Hi Andrija,
Same issue with public vlan tagged got fixed, CLOUDSTACK-5505.
Thanks,
Jayapal
On 29-May-2014, at 9:38 AM, Jayapal Reddy Uradi
jayapalreddy.ur...@citrix.com
wrote:
Hi Adrija,
From the logs, the public subnet is untagged.
I think this issue is coming for the untagged public vlan in 4.3.
1.
{com.cloud.agent.api.PlugNicCommand:{nic:{deviceId:1,networkRateMbps:9,defaultNic:true,uuid:e6b734d4-3302-4113-8ec7-5c205c90959a,ip:46.232.180.248,netmask:255.255.255.0,gateway:46.232.180.1,mac:06:5e:e8:00:00:27,broadcastType:Vlan,type:Public,broadcastUri:vlan://untagged,isolationUri:vlan://untagged,isSecurityGroupEnabled:false,name:breth1-500},
2.
3.
instanceName:r-779-VM,vmType:DomainRouter,wait:0}},{com.cloud.agent.api.routing.IpAssocVpcCommand:{ipAddresses:[{accountId:2,publicIp:46.232.180.248,sourceNat:true,add:true,oneToOneNat:false,firstIP:false,broadcastUri:untagged,vlanGateway:46.232.180.1,vlanNetmask:255.255.255.0,vifMacAddress:06:5e:e8:00:00:27,networkRate:9,trafficType:Public,networkName:breth1-500}],accessDetails:
From the logs VR logs, the ipassoc script got the interface id as null.
May 28 12:37:33 r-794-VM cloud: vpc_ipassoc.sh:Waiting for interface
ethnull to appear, 0 seconds
Thanks,
Jayapal
On 29-May-2014, at 1:08 AM, Andrija Panic andrija.pa...@gmail.com
mailto:andrija.pa...@gmail.com wrote:
Thanks Daan,
my problem is that I'm in production for 3rd day now, and restoring DB
and
downgrading back to 4.2.1 doesn't seem as option for me at the moment,
since I would loose new acounts and single VMs, etc...
Thanks,
Andrija
On 28 May 2014 21:34, Daan Hoogland daan.hoogl...@gmail.commailto:
daan.hoogl...@gmail.com wrote:
Andrija,
nevertheless it sounds familiar. I will be back in the office on
monday and ask around.
On Wed, May 28, 2014 at 9:23 PM, Andrija Panic andrija.pa...@gmail.com
mailto:andrija.pa...@gmail.com
wrote:
Hi Daan,
I don't think this is my issue, at least I don't make use of private
gateway - this is just simple as: create new VPC from scratch - Public
IP
is not assigned to VR eth1 interface inside VR...
I have filed the bug:
https://issues.apache.org/jira/browse/CLOUDSTACK-6801
This same thing happened previously to Andrei Mikhailovsky:
http://mail-archives.apache.org/mod_mbox/cloudstack-users/201405.mbox/%3C33347835.250.1399336340785.JavaMail.andrei@tuchka%3Eand
it is not resolved
Thanks,
Andrija
On 28 May 2014 21:01, Daan Hoogland daan.hoogl...@gmail.com wrote:
Andrija,
this sound like something we seen as well.
can you check if this is it :
https://issues.apache.org/jira/browse/CLOUDSTACK-6485
thanks,
Daan
On Wed, May 28, 2014 at 3:30 PM, Andrija Panic andrija.pa...@gmail.com
wrote:
Hi there,
I'm having big time problems with Public IP missing from VPC VR's
eth1,
after upgrade to ACS 4.3.1 - did not found this filed as bug so
far...and
it worked all fine on ACS 4.2.1.
No help so far from user mailing list...
Below is a detailed explanation, and logs from inside VR, and from
management (all fine with management logs...)
If anybody can help, I would very much appriciate this, since now I
have
bunch fo VPC unoperational...
Thanks
-- Forwarded message --
From: Andrija Panic andrija.pa...@gmail.com
Date: 28 May 2014 14:50
Subject: Re: VPC's VR missing public NIC eth1
To: us...@cloudstack.apache.org
and as I said eth1 is present:
root@r-794-VM:~# cat /proc/net/dev
Inter-| Receive|
Transmit
face |bytespackets errs drop fifo frame compressed
multicast|bytes
packets errs drop fifo colls carrier compressed
eth3: 11484 131000 0 0 0
11590
131000 0 0 0
lo: 214 2000 0 0 0
214
2000 0 0 0
eth2: 32970 544000 0 0 0
2084
24000 0 0 0
eth1: 0 0000 0 0 0
0
0000 0 0 0
eth0: 1502071319000 0 0 0
264232
1180000 0 0 0
On 28 May 2014 14:47, Andrija Panic andrija.pa...@gmail.com wrote:
Also, from /var/log/messages/ inside VR:
RE: [ANNOUNCE] Saksham Srivastava as committer
Many many congratulations Saksham! -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, May 29, 2014 12:18 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
Re: VPC's VR missing public NIC eth1
Daan, thanks for info. And one final question - is it possible to change
Public vlan/range from untagged to tagged - editing vlan table and
making change, does not really make changes after I restart VPC router...
THanks
On 29 May 2014 10:15, Daan Hoogland daan.hoogl...@gmail.com wrote:
Andrija, we plan to release it soon. It depends on how quickly issues
in it are fixed. The branch has been created, so you could test it and
report on it if you have an env to spare.
On Thu, May 29, 2014 at 10:09 AM, Andrija Panic andrija.pa...@gmail.com
wrote:
Will try, thx. Not sure good question - when is 4.4 scheduled to be
releases - few months, or more ?
Thanks
On 29 May 2014 06:15, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com
wrote:
Hi Andrija,
Same issue with public vlan tagged got fixed, CLOUDSTACK-5505.
Thanks,
Jayapal
On 29-May-2014, at 9:38 AM, Jayapal Reddy Uradi
jayapalreddy.ur...@citrix.com
wrote:
Hi Adrija,
From the logs, the public subnet is untagged.
I think this issue is coming for the untagged public vlan in 4.3.
1.
{com.cloud.agent.api.PlugNicCommand:{nic:{deviceId:1,networkRateMbps:9,defaultNic:true,uuid:e6b734d4-3302-4113-8ec7-5c205c90959a,ip:46.232.180.248,netmask:255.255.255.0,gateway:46.232.180.1,mac:06:5e:e8:00:00:27,broadcastType:Vlan,type:Public,broadcastUri:vlan://untagged,isolationUri:vlan://untagged,isSecurityGroupEnabled:false,name:breth1-500},
2.
3.
instanceName:r-779-VM,vmType:DomainRouter,wait:0}},{com.cloud.agent.api.routing.IpAssocVpcCommand:{ipAddresses:[{accountId:2,publicIp:46.232.180.248,sourceNat:true,add:true,oneToOneNat:false,firstIP:false,broadcastUri:untagged,vlanGateway:46.232.180.1,vlanNetmask:255.255.255.0,vifMacAddress:06:5e:e8:00:00:27,networkRate:9,trafficType:Public,networkName:breth1-500}],accessDetails:
From the logs VR logs, the ipassoc script got the interface id as
null.
May 28 12:37:33 r-794-VM cloud: vpc_ipassoc.sh:Waiting for interface
ethnull to appear, 0 seconds
Thanks,
Jayapal
On 29-May-2014, at 1:08 AM, Andrija Panic andrija.pa...@gmail.com
mailto:andrija.pa...@gmail.com wrote:
Thanks Daan,
my problem is that I'm in production for 3rd day now, and restoring DB
and
downgrading back to 4.2.1 doesn't seem as option for me at the moment,
since I would loose new acounts and single VMs, etc...
Thanks,
Andrija
On 28 May 2014 21:34, Daan Hoogland daan.hoogl...@gmail.commailto:
daan.hoogl...@gmail.com wrote:
Andrija,
nevertheless it sounds familiar. I will be back in the office on
monday and ask around.
On Wed, May 28, 2014 at 9:23 PM, Andrija Panic
andrija.pa...@gmail.com
mailto:andrija.pa...@gmail.com
wrote:
Hi Daan,
I don't think this is my issue, at least I don't make use of private
gateway - this is just simple as: create new VPC from scratch -
Public
IP
is not assigned to VR eth1 interface inside VR...
I have filed the bug:
https://issues.apache.org/jira/browse/CLOUDSTACK-6801
This same thing happened previously to Andrei Mikhailovsky:
http://mail-archives.apache.org/mod_mbox/cloudstack-users/201405.mbox/%3C33347835.250.1399336340785.JavaMail.andrei@tuchka%3Eand
it is not resolved
Thanks,
Andrija
On 28 May 2014 21:01, Daan Hoogland daan.hoogl...@gmail.com wrote:
Andrija,
this sound like something we seen as well.
can you check if this is it :
https://issues.apache.org/jira/browse/CLOUDSTACK-6485
thanks,
Daan
On Wed, May 28, 2014 at 3:30 PM, Andrija Panic
andrija.pa...@gmail.com
wrote:
Hi there,
I'm having big time problems with Public IP missing from VPC VR's
eth1,
after upgrade to ACS 4.3.1 - did not found this filed as bug so
far...and
it worked all fine on ACS 4.2.1.
No help so far from user mailing list...
Below is a detailed explanation, and logs from inside VR, and from
management (all fine with management logs...)
If anybody can help, I would very much appriciate this, since now I
have
bunch fo VPC unoperational...
Thanks
-- Forwarded message --
From: Andrija Panic andrija.pa...@gmail.com
Date: 28 May 2014 14:50
Subject: Re: VPC's VR missing public NIC eth1
To: us...@cloudstack.apache.org
and as I said eth1 is present:
root@r-794-VM:~# cat /proc/net/dev
Inter-| Receive|
Transmit
face |bytespackets errs drop fifo frame compressed
multicast|bytes
packets errs drop fifo colls carrier compressed
eth3: 11484 131000 0 0 0
11590
131000 0 0 0
lo: 214 2000 0 0 0
214
2000 0 0 0
eth2: 32970 54400
RE: [ANNOUNCE] Saksham Srivastava as committer
Congratulations Saksham !! :) -Original Message- From: Likitha Shetty [mailto:likitha.she...@citrix.com] Sent: Thursday, May 29, 2014 1:50 PM To: dev@cloudstack.apache.org Subject: RE: [ANNOUNCE] Saksham Srivastava as committer Many many congratulations Saksham! -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, May 29, 2014 12:18 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
Re: [ACS 4.3] listUsageRecords API bug related to CLOUDSTACK-6472
sebgoa
2014-05-29 16:52 GMT+09:00 sebgoa run...@gmail.com:
On May 29, 2014, at 9:26 AM, Hiroki Ohashi hiroki.s...@gmail.com wrote:
Dear guys
I found a bug about listUsageRecords API in 4.3 related to a issue
CLOUDSTACK-6472 and made a patch. Would you review the patch and
correct me if I am wrong?
Sam Schmit push a commit about NPEs/Null UUIDs at May 5th but I think
his commit is not enough.
commit e8047e11db7ef2bdc44bbedfdc47e63c55f080c5
Author: Sam Schmit sam.sch...@appcore.com
Date: Mon May 5 16:38:23 2014 -0500
CLOUDSTACK-6472 (4.3 specific) listUsageRecords: Pull
information from removed items as well, fixing NPEs/Null UUIDs with
usage API calls.
Signed-off-by: Sebastien Goasguen run...@gmail.com
When I called listUsageRecords against CloudStack 4.3 management
server that was build at latest 4.3 branch, usage records about
destroyed instances of usage type 1 and 2 lacked 'virtualmachineid' as
below.
{
account: sgcadm,
accountid: f9e4e1ca-69fd-4ae3-b70c-15bbcc13406e,
description: mycluster-front allocated (ServiceOffering: 13)
(Template: 203),
domainid: 84dd635d-fb99-4895-b199-7d777aa144d5,
enddate: 2014-05-20'T'08:59:59+09:00,
name: mycluster-front,
offeringid: e5137018-8fca-4e4a-a79e-9e4d1707e079,
rawusage: 0.223611,
startdate: 2014-05-19'T'09:00:00+09:00,
templateid: 1ebdc71e-dcbe-4d3e-82d3-d31897f78d4c,
type: KVM,
usage: 0.223611 Hrs,
usageid: 09f3d7d6-3c6a-4326-b3d3-fb51506e669d,
usagetype: 2,
zoneid: c2ba1354-0c15-4284-bdba-4f201767362d
},
Hence, it is unable to refer to any destroyed instance id. I patched
createUsageResponse method like this.
diff --git a/server/src/com/cloud/api/ApiResponseHelper.java
b/server/src/com/cloud/api/ApiResponseHelper.java
index 7718fc1..cbf3914 100755
--- a/server/src/com/cloud/api/ApiResponseHelper.java
+++ b/server/src/com/cloud/api/ApiResponseHelper.java
@@ -3304,7 +3304,7 @@ public class ApiResponseHelper implements
ResponseGenerator {
usageRecResponse.setUsage(usageRecord.getUsageDisplay());
usageRecResponse.setUsageType(usageRecord.getUsageType());
if (usageRecord.getVmInstanceId() != null) {
-VMInstanceVO vm =
_entityMgr.findById(VMInstanceVO.class,
usageRecord.getVmInstanceId());
+VMInstanceVO vm =
_entityMgr.findByIdIncludingRemoved(VMInstanceVO.class,
usageRecord.getVmInstanceId());
if (vm != null) {
usageRecResponse.setVirtualMachineId(vm.getUuid());
}
Looks like an omission to me, I went ahead and patched it:
commit 24e03bed560feb959a61126b76c2d6971e77092e
Author: Sebastien Goasguen run...@gmail.com
Date: Thu May 29 09:48:46 2014 +0200
Fix usage response, patch by Hiroki Ohashi
We can always revert if people don't agree.
Can you pull the latest 4.3 and try it.
Thanks! I will try it.
Thanks for the patch. you can always attach a patch at
http://reviews.apache.org
and follow the instructions at http://cloudstack.apache.org/developers.html
OK, I will follow the instruction next time.
After that, listUsageRecords API contains 'virtualmachineid' whether
or not instances are destroyed. Here is a result.
{
account: sgcadm,
accountid: f9e4e1ca-69fd-4ae3-b70c-15bbcc13406e,
description: mycluster-front allocated (ServiceOffering: 13)
(Template: 203),
domainid: 84dd635d-fb99-4895-b199-7d777aa144d5,
enddate: 2014-05-20'T'08:59:59+09:00,
name: mycluster-front,
offeringid: e5137018-8fca-4e4a-a79e-9e4d1707e079,
rawusage: 0.223611,
startdate: 2014-05-19'T'09:00:00+09:00,
templateid: 1ebdc71e-dcbe-4d3e-82d3-d31897f78d4c,
type: KVM,
usage: 0.223611 Hrs,
usageid: 09f3d7d6-3c6a-4326-b3d3-fb51506e669d,
usagetype: 2,
virtualmachineid: 09f3d7d6-3c6a-4326-b3d3-fb51506e669d,
zoneid: c2ba1354-0c15-4284-bdba-4f201767362d
},
I think this is an expectecd behaviour, so please review and test this
patch.
Best Regards
--
Hiroki Ohashi
Best Regards
--
Hiroki Ohashi
Re: VPC's VR missing public NIC eth1
Well, on the same eth1 device I have both untagged packets and tagged one
(vlan 500) having reall access to public IPs/network.
So I would need to replace untagged with 500 somewhere inside
database...not sure where, that's the question :)
Thanks.
On 29 May 2014 10:53, Daan Hoogland daan.hoogl...@gmail.com wrote:
untagged means that no vlan-id is assigned. 'tagged' doesn't exist. I
am not sure how your topography looks. Giving you a clue to solve it
now would be guessing. That said, my guess is your public net needs a
vlan assigned. I am not sure if it is your public physical net
(updatePhysicalNetwork) or your guestnetwork (re-create i'm afraid)
best of luck,
On Thu, May 29, 2014 at 10:21 AM, Andrija Panic andrija.pa...@gmail.com
wrote:
Daan, thanks for info. And one final question - is it possible to change
Public vlan/range from untagged to tagged - editing vlan table and
making change, does not really make changes after I restart VPC router...
THanks
On 29 May 2014 10:15, Daan Hoogland daan.hoogl...@gmail.com wrote:
Andrija, we plan to release it soon. It depends on how quickly issues
in it are fixed. The branch has been created, so you could test it and
report on it if you have an env to spare.
On Thu, May 29, 2014 at 10:09 AM, Andrija Panic
andrija.pa...@gmail.com
wrote:
Will try, thx. Not sure good question - when is 4.4 scheduled to be
releases - few months, or more ?
Thanks
On 29 May 2014 06:15, Jayapal Reddy Uradi
jayapalreddy.ur...@citrix.com
wrote:
Hi Andrija,
Same issue with public vlan tagged got fixed, CLOUDSTACK-5505.
Thanks,
Jayapal
On 29-May-2014, at 9:38 AM, Jayapal Reddy Uradi
jayapalreddy.ur...@citrix.com
wrote:
Hi Adrija,
From the logs, the public subnet is untagged.
I think this issue is coming for the untagged public vlan in 4.3.
1.
{com.cloud.agent.api.PlugNicCommand:{nic:{deviceId:1,networkRateMbps:9,defaultNic:true,uuid:e6b734d4-3302-4113-8ec7-5c205c90959a,ip:46.232.180.248,netmask:255.255.255.0,gateway:46.232.180.1,mac:06:5e:e8:00:00:27,broadcastType:Vlan,type:Public,broadcastUri:vlan://untagged,isolationUri:vlan://untagged,isSecurityGroupEnabled:false,name:breth1-500},
2.
3.
instanceName:r-779-VM,vmType:DomainRouter,wait:0}},{com.cloud.agent.api.routing.IpAssocVpcCommand:{ipAddresses:[{accountId:2,publicIp:46.232.180.248,sourceNat:true,add:true,oneToOneNat:false,firstIP:false,broadcastUri:untagged,vlanGateway:46.232.180.1,vlanNetmask:255.255.255.0,vifMacAddress:06:5e:e8:00:00:27,networkRate:9,trafficType:Public,networkName:breth1-500}],accessDetails:
From the logs VR logs, the ipassoc script got the interface id as
null.
May 28 12:37:33 r-794-VM cloud: vpc_ipassoc.sh:Waiting for
interface
ethnull to appear, 0 seconds
Thanks,
Jayapal
On 29-May-2014, at 1:08 AM, Andrija Panic andrija.pa...@gmail.com
mailto:andrija.pa...@gmail.com wrote:
Thanks Daan,
my problem is that I'm in production for 3rd day now, and
restoring DB
and
downgrading back to 4.2.1 doesn't seem as option for me at the
moment,
since I would loose new acounts and single VMs, etc...
Thanks,
Andrija
On 28 May 2014 21:34, Daan Hoogland daan.hoogl...@gmail.com
mailto:
daan.hoogl...@gmail.com wrote:
Andrija,
nevertheless it sounds familiar. I will be back in the office on
monday and ask around.
On Wed, May 28, 2014 at 9:23 PM, Andrija Panic
andrija.pa...@gmail.com
mailto:andrija.pa...@gmail.com
wrote:
Hi Daan,
I don't think this is my issue, at least I don't make use of
private
gateway - this is just simple as: create new VPC from scratch -
Public
IP
is not assigned to VR eth1 interface inside VR...
I have filed the bug:
https://issues.apache.org/jira/browse/CLOUDSTACK-6801
This same thing happened previously to Andrei Mikhailovsky:
http://mail-archives.apache.org/mod_mbox/cloudstack-users/201405.mbox/%3C33347835.250.1399336340785.JavaMail.andrei@tuchka%3Eand
it is not resolved
Thanks,
Andrija
On 28 May 2014 21:01, Daan Hoogland daan.hoogl...@gmail.com
wrote:
Andrija,
this sound like something we seen as well.
can you check if this is it :
https://issues.apache.org/jira/browse/CLOUDSTACK-6485
thanks,
Daan
On Wed, May 28, 2014 at 3:30 PM, Andrija Panic
andrija.pa...@gmail.com
wrote:
Hi there,
I'm having big time problems with Public IP missing from VPC VR's
eth1,
after upgrade to ACS 4.3.1 - did not found this filed as bug so
far...and
it worked all fine on ACS 4.2.1.
No help so far from user mailing list...
Below is a detailed explanation, and logs from inside VR, and from
management (all fine with management
Re: VPC's VR missing public NIC eth1
On Thu, May 29, 2014 at 10:57 AM, Andrija Panic andrija.pa...@gmail.com wrote: 500 is 500 the vlan of your guestnetwork or your physical network? You wouldn't want to have two nets with vlan 500! -- Daan
Re: [ACS 4.3] listUsageRecords API bug related to CLOUDSTACK-6472
The fix is already in 4.4
commit 3a3457e7132d22f52aa38179d40a6eb9b0b29677
Author: Sam Schmit sam.sch...@appcore.com
AuthorDate: Fri May 2 13:07:34 2014 -0500
Commit: Daan Hoogland d...@onecht.net
CommitDate: Tue May 6 17:46:20 2014 +0200
CLOUDSTACK-6472 listUsageRecords: Pull information from removed items as
well, fixing NPEs/Null UUIDs with usage API calls.
M server/src/com/cloud/api/ApiResponseHelper.java
@sebgoa
i think it would be better to include bug id in the commit messages as thats
the only way to track all the commits for a defect.
~Rajani
On 29-May-2014, at 2:25 pm, Daan Hoogland daan.hoogl...@gmail.com wrote:
Hiroki,
Did you have a look at 4.4 or master as well? tell us when it works,
so we can cherry-pick the fix to later versions.
On Thu, May 29, 2014 at 10:25 AM, Hiroki Ohashi hiroki.s...@gmail.com wrote:
sebgoa
2014-05-29 16:52 GMT+09:00 sebgoa run...@gmail.com:
On May 29, 2014, at 9:26 AM, Hiroki Ohashi hiroki.s...@gmail.com wrote:
Dear guys
I found a bug about listUsageRecords API in 4.3 related to a issue
CLOUDSTACK-6472 and made a patch. Would you review the patch and
correct me if I am wrong?
Sam Schmit push a commit about NPEs/Null UUIDs at May 5th but I think
his commit is not enough.
commit e8047e11db7ef2bdc44bbedfdc47e63c55f080c5
Author: Sam Schmit sam.sch...@appcore.com
Date: Mon May 5 16:38:23 2014 -0500
CLOUDSTACK-6472 (4.3 specific) listUsageRecords: Pull
information from removed items as well, fixing NPEs/Null UUIDs with
usage API calls.
Signed-off-by: Sebastien Goasguen run...@gmail.com
When I called listUsageRecords against CloudStack 4.3 management
server that was build at latest 4.3 branch, usage records about
destroyed instances of usage type 1 and 2 lacked 'virtualmachineid' as
below.
{
account: sgcadm,
accountid: f9e4e1ca-69fd-4ae3-b70c-15bbcc13406e,
description: mycluster-front allocated (ServiceOffering: 13)
(Template: 203),
domainid: 84dd635d-fb99-4895-b199-7d777aa144d5,
enddate: 2014-05-20'T'08:59:59+09:00,
name: mycluster-front,
offeringid: e5137018-8fca-4e4a-a79e-9e4d1707e079,
rawusage: 0.223611,
startdate: 2014-05-19'T'09:00:00+09:00,
templateid: 1ebdc71e-dcbe-4d3e-82d3-d31897f78d4c,
type: KVM,
usage: 0.223611 Hrs,
usageid: 09f3d7d6-3c6a-4326-b3d3-fb51506e669d,
usagetype: 2,
zoneid: c2ba1354-0c15-4284-bdba-4f201767362d
},
Hence, it is unable to refer to any destroyed instance id. I patched
createUsageResponse method like this.
diff --git a/server/src/com/cloud/api/ApiResponseHelper.java
b/server/src/com/cloud/api/ApiResponseHelper.java
index 7718fc1..cbf3914 100755
--- a/server/src/com/cloud/api/ApiResponseHelper.java
+++ b/server/src/com/cloud/api/ApiResponseHelper.java
@@ -3304,7 +3304,7 @@ public class ApiResponseHelper implements
ResponseGenerator {
usageRecResponse.setUsage(usageRecord.getUsageDisplay());
usageRecResponse.setUsageType(usageRecord.getUsageType());
if (usageRecord.getVmInstanceId() != null) {
-VMInstanceVO vm =
_entityMgr.findById(VMInstanceVO.class,
usageRecord.getVmInstanceId());
+VMInstanceVO vm =
_entityMgr.findByIdIncludingRemoved(VMInstanceVO.class,
usageRecord.getVmInstanceId());
if (vm != null) {
usageRecResponse.setVirtualMachineId(vm.getUuid());
}
Looks like an omission to me, I went ahead and patched it:
commit 24e03bed560feb959a61126b76c2d6971e77092e
Author: Sebastien Goasguen run...@gmail.com
Date: Thu May 29 09:48:46 2014 +0200
Fix usage response, patch by Hiroki Ohashi
We can always revert if people don't agree.
Can you pull the latest 4.3 and try it.
Thanks! I will try it.
Thanks for the patch. you can always attach a patch at
http://reviews.apache.org
and follow the instructions at http://cloudstack.apache.org/developers.html
OK, I will follow the instruction next time.
After that, listUsageRecords API contains 'virtualmachineid' whether
or not instances are destroyed. Here is a result.
{
account: sgcadm,
accountid: f9e4e1ca-69fd-4ae3-b70c-15bbcc13406e,
description: mycluster-front allocated (ServiceOffering: 13)
(Template: 203),
domainid: 84dd635d-fb99-4895-b199-7d777aa144d5,
enddate: 2014-05-20'T'08:59:59+09:00,
name: mycluster-front,
offeringid: e5137018-8fca-4e4a-a79e-9e4d1707e079,
rawusage: 0.223611,
startdate: 2014-05-19'T'09:00:00+09:00,
templateid: 1ebdc71e-dcbe-4d3e-82d3-d31897f78d4c,
type: KVM,
usage: 0.223611 Hrs,
usageid: 09f3d7d6-3c6a-4326-b3d3-fb51506e669d,
usagetype: 2,
virtualmachineid: 09f3d7d6-3c6a-4326-b3d3-fb51506e669d,
zoneid: c2ba1354-0c15-4284-bdba-4f201767362d
},
I think this is an expectecd behaviour, so please review and test this
patch.
Re: [ANNOUNCE] Saksham Srivastava as committer
Congratulations Saksham.. ~Rajani On 29-May-2014, at 2:19 pm, Sailaja Mada sailaja.m...@citrix.com wrote: Congratulations Saksham. -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: 29 May 2014 12:18 To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
Re: VPC's VR missing public NIC eth1
It's like this: I have public subnet /24. half is dedicated for Guest traffic (vlan 500) and the second half is dedicated to Public traffic/network (no vlan tags, that is untagged packets) Both vlan500 and untagged packets travel over physical eth1 interface on hypervisors and can reach Internet. Thanks, On 29 May 2014 11:06, Daan Hoogland daan.hoogl...@gmail.com wrote: On Thu, May 29, 2014 at 10:57 AM, Andrija Panic andrija.pa...@gmail.com wrote: 500 is 500 the vlan of your guestnetwork or your physical network? You wouldn't want to have two nets with vlan 500! -- Daan -- Andrija Panić -- http://admintweets.com --
Re: [ACS 4.3] listUsageRecords API bug related to CLOUDSTACK-6472
On May 29, 2014, at 11:20 AM, Rajani Karuturi rajani.karut...@citrix.com
wrote:
The fix is already in 4.4
commit 3a3457e7132d22f52aa38179d40a6eb9b0b29677
Author: Sam Schmit sam.sch...@appcore.com
AuthorDate: Fri May 2 13:07:34 2014 -0500
Commit: Daan Hoogland d...@onecht.net
CommitDate: Tue May 6 17:46:20 2014 +0200
CLOUDSTACK-6472 listUsageRecords: Pull information from removed items as
well, fixing NPEs/Null UUIDs with usage API calls.
M server/src/com/cloud/api/ApiResponseHelper.java
still need to check if this fix in 4.4 is complete. Hiroki's change was to 4.3
branch. I did not check 4.4.
@sebgoa
i think it would be better to include bug id in the commit messages as thats
the only way to track all the commits for a defect.
yes my bad, did not take time to look up the bug id.
~Rajani
On 29-May-2014, at 2:25 pm, Daan Hoogland daan.hoogl...@gmail.com wrote:
Hiroki,
Did you have a look at 4.4 or master as well? tell us when it works,
so we can cherry-pick the fix to later versions.
On Thu, May 29, 2014 at 10:25 AM, Hiroki Ohashi hiroki.s...@gmail.com
wrote:
sebgoa
2014-05-29 16:52 GMT+09:00 sebgoa run...@gmail.com:
On May 29, 2014, at 9:26 AM, Hiroki Ohashi hiroki.s...@gmail.com wrote:
Dear guys
I found a bug about listUsageRecords API in 4.3 related to a issue
CLOUDSTACK-6472 and made a patch. Would you review the patch and
correct me if I am wrong?
Sam Schmit push a commit about NPEs/Null UUIDs at May 5th but I think
his commit is not enough.
commit e8047e11db7ef2bdc44bbedfdc47e63c55f080c5
Author: Sam Schmit sam.sch...@appcore.com
Date: Mon May 5 16:38:23 2014 -0500
CLOUDSTACK-6472 (4.3 specific) listUsageRecords: Pull
information from removed items as well, fixing NPEs/Null UUIDs with
usage API calls.
Signed-off-by: Sebastien Goasguen run...@gmail.com
When I called listUsageRecords against CloudStack 4.3 management
server that was build at latest 4.3 branch, usage records about
destroyed instances of usage type 1 and 2 lacked 'virtualmachineid' as
below.
{
account: sgcadm,
accountid: f9e4e1ca-69fd-4ae3-b70c-15bbcc13406e,
description: mycluster-front allocated (ServiceOffering: 13)
(Template: 203),
domainid: 84dd635d-fb99-4895-b199-7d777aa144d5,
enddate: 2014-05-20'T'08:59:59+09:00,
name: mycluster-front,
offeringid: e5137018-8fca-4e4a-a79e-9e4d1707e079,
rawusage: 0.223611,
startdate: 2014-05-19'T'09:00:00+09:00,
templateid: 1ebdc71e-dcbe-4d3e-82d3-d31897f78d4c,
type: KVM,
usage: 0.223611 Hrs,
usageid: 09f3d7d6-3c6a-4326-b3d3-fb51506e669d,
usagetype: 2,
zoneid: c2ba1354-0c15-4284-bdba-4f201767362d
},
Hence, it is unable to refer to any destroyed instance id. I patched
createUsageResponse method like this.
diff --git a/server/src/com/cloud/api/ApiResponseHelper.java
b/server/src/com/cloud/api/ApiResponseHelper.java
index 7718fc1..cbf3914 100755
--- a/server/src/com/cloud/api/ApiResponseHelper.java
+++ b/server/src/com/cloud/api/ApiResponseHelper.java
@@ -3304,7 +3304,7 @@ public class ApiResponseHelper implements
ResponseGenerator {
usageRecResponse.setUsage(usageRecord.getUsageDisplay());
usageRecResponse.setUsageType(usageRecord.getUsageType());
if (usageRecord.getVmInstanceId() != null) {
-VMInstanceVO vm =
_entityMgr.findById(VMInstanceVO.class,
usageRecord.getVmInstanceId());
+VMInstanceVO vm =
_entityMgr.findByIdIncludingRemoved(VMInstanceVO.class,
usageRecord.getVmInstanceId());
if (vm != null) {
usageRecResponse.setVirtualMachineId(vm.getUuid());
}
Looks like an omission to me, I went ahead and patched it:
commit 24e03bed560feb959a61126b76c2d6971e77092e
Author: Sebastien Goasguen run...@gmail.com
Date: Thu May 29 09:48:46 2014 +0200
Fix usage response, patch by Hiroki Ohashi
We can always revert if people don't agree.
Can you pull the latest 4.3 and try it.
Thanks! I will try it.
Thanks for the patch. you can always attach a patch at
http://reviews.apache.org
and follow the instructions at http://cloudstack.apache.org/developers.html
OK, I will follow the instruction next time.
After that, listUsageRecords API contains 'virtualmachineid' whether
or not instances are destroyed. Here is a result.
{
account: sgcadm,
accountid: f9e4e1ca-69fd-4ae3-b70c-15bbcc13406e,
description: mycluster-front allocated (ServiceOffering: 13)
(Template: 203),
domainid: 84dd635d-fb99-4895-b199-7d777aa144d5,
enddate: 2014-05-20'T'08:59:59+09:00,
name: mycluster-front,
offeringid: e5137018-8fca-4e4a-a79e-9e4d1707e079,
rawusage: 0.223611,
startdate: 2014-05-19'T'09:00:00+09:00,
templateid: 1ebdc71e-dcbe-4d3e-82d3-d31897f78d4c,
type: KVM,
usage: 0.223611 Hrs,
usageid:
Re: VPC's VR missing public NIC eth1
I don't think editing DB table will work. -Jayapal On 29-May-2014, at 2:52 PM, Andrija Panic andrija.pa...@gmail.com wrote: It's like this: I have public subnet /24. half is dedicated for Guest traffic (vlan 500) and the second half is dedicated to Public traffic/network (no vlan tags, that is untagged packets) Both vlan500 and untagged packets travel over physical eth1 interface on hypervisors and can reach Internet. Thanks, On 29 May 2014 11:06, Daan Hoogland daan.hoogl...@gmail.com wrote: On Thu, May 29, 2014 at 10:57 AM, Andrija Panic andrija.pa...@gmail.com wrote: 500 is 500 the vlan of your guestnetwork or your physical network? You wouldn't want to have two nets with vlan 500! -- Daan -- Andrija Panić -- http://admintweets.com --
Need help with simstack vagrant box
Hello CloudStack forum,
We are following the steps mentioned:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Create+config+management+recipes+to+install+CloudStack
https://github.com/runseb/simstack to bring up a cloudstack dev instance.
After running vagrant up and vagrant reload —provision command, we notice that
cloud stack is not up yet! After SSH into the vagrant box, we notice that there
is not cloudstack java process running. Has anyone brought simstack
successfully?
Here is the excerpts from the vagrant reload:
== default: Attempting graceful shutdown of VM...
== default: Clearing any previously set forwarded ports...
== default: Clearing any previously set network interfaces...
== default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
== default: Forwarding ports...
default: 8080 = 8080 (adapter 1)
default: 8081 = 8081 (adapter 1)
default: 7080 = 7080 (adapter 1)
default: 8000 = 8000 (adapter 1)
default: 80 = 8001 (adapter 1)
default: 22 = (adapter 1)
== default: Running 'pre-boot' VM customizations...
== default: Booting VM...
== default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:
default: SSH username: vagrant
default: SSH auth method: private key
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
== default: Machine booted and ready!
== default: Checking for guest additions in VM...
== default: Setting hostname...
== default: Mounting shared folders...
default: /srv = /Volumes/ActOnMagic/simstack/salt/roots
default: /vagrant = /Volumes/ActOnMagic/simstack
== default: Running provisioner: shell...
default: Running: inline script
== default: Running provisioner: ansible...
ANSIBLE_FORCE_COLOR=true ANSIBLE_HOST_KEY_CHECKING=false PYTHONUNBUFFERED=1
ansible-playbook --private-key=/Users/madang/.vagrant.d/insecure_private_key
--user=vagrant --limit='default' --inventory-file=/Vo
….
TASK: [php-fpm | Copy php-fpm configuration] **
127.0.0.1 ESTABLISH CONNECTION FOR USER: vagrant
127.0.0.1 EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o',
'ControlPersist=60s', '-o',
'ControlPath=/Users/madang/.ansible/cp/ansible-ssh-%h-%p-%r', '-o',
'StrictHostKeyChecking=no', '-o', 'Port=', '-o',
'IdentityFile=/Users/madang/.vagrant.d/insecure_private_key', '-o',
'KbdInteractiveAuthentication=no', '-o',
'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey',
'-o', 'PasswordAuthentication=no', '-o', 'User=vagrant', '-o',
'ConnectTimeout=10', '127.0.0.1', /bin/sh -c 'mkdir -p
$HOME/.ansible/tmp/ansible-tmp-1401356524.77-108295687200060 chmod a+rx
$HOME/.ansible/tmp/ansible-tmp-1401356524.77-108295687200060 echo
$HOME/.ansible/tmp/ansible-tmp-1401356524.77-108295687200060']
127.0.0.1 EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o',
'ControlPersist=60s', '-o',
'ControlPath=/Users/madang/.ansible/cp/ansible-ssh-%h-%p-%r', '-o',
'StrictHostKeyChecking=no', '-o', 'Port=', '-o',
'IdentityFile=/Users/madang/.vagrant.d/insecure_private_key', '-o',
'KbdInteractiveAuthentication=no', '-o',
'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey',
'-o', 'PasswordAuthentication=no', '-o', 'User=vagrant', '-o',
'ConnectTimeout=10', '127.0.0.1', u'/bin/sh -c \'sudo -k sudo -H -S -p
[sudo via ansible, key=dyyespcdwcthzzkmglnauwbwpyujxupu] password: -u root
/bin/sh -c \'\'\'echo SUDO-SUCCESS-dyyespcdwcthzzkmglnauwbwpyujxupu; rc=0; [
-r /etc/php-fpm.d/wordpress.conf ] || rc=2; [ -f
/etc/php-fpm.d/wordpress.conf ] || rc=1; [ -d /etc/php-fpm.d/wordpress.conf
] echo 3 exit 0; (/usr/bin/md5sum /etc/php-fpm.d/wordpress.conf
2/dev/null) || (/sbin/md5sum -q /etc/php-fpm.d/wordpress.conf 2/dev/null) ||
(/usr/bin/digest -a md5 /etc/php-fpm.d/wordpress.conf 2/dev/null) ||
(/sbin/md5 -q /etc/php-fpm.d/wordpress.conf 2/dev/null) || (/usr/bin/md5 -n
/etc/php-fpm.d/wordpress.conf 2/dev/null) || (/bin/md5 -q
/etc/php-fpm.d/wordpress.conf 2/dev/null) || (/usr/bin/csum -h MD5
/etc/php-fpm.d/wordpress.conf 2/dev/null) || (/bin/csum -h MD5
/etc/php-fpm.d/wordpress.conf 2/dev/null) || (echo ${rc}
/etc/php-fpm.d/wordpress.conf)\'\'\'\'']
127.0.0.1 PUT /tmp/tmpez2Yze TO
/home/vagrant/.ansible/tmp/ansible-tmp-1401356524.77-108295687200060/file
127.0.0.1 EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o',
'ControlPersist=60s', '-o',
'ControlPath=/Users/madang/.ansible/cp/ansible-ssh-%h-%p-%r', '-o',
'StrictHostKeyChecking=no', '-o', 'Port=', '-o',
'IdentityFile=/Users/madang/.vagrant.d/insecure_private_key', '-o',
'KbdInteractiveAuthentication=no', '-o',
'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey',
'-o',
Re: VPC's VR missing public NIC eth1
Are these two traffic types in one physical net? or two physical nets on the same interface (seems wrong). On Thu, May 29, 2014 at 11:35 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: I don't think editing DB table will work. -Jayapal On 29-May-2014, at 2:52 PM, Andrija Panic andrija.pa...@gmail.com wrote: It's like this: I have public subnet /24. half is dedicated for Guest traffic (vlan 500) and the second half is dedicated to Public traffic/network (no vlan tags, that is untagged packets) Both vlan500 and untagged packets travel over physical eth1 interface on hypervisors and can reach Internet. Thanks, On 29 May 2014 11:06, Daan Hoogland daan.hoogl...@gmail.com wrote: On Thu, May 29, 2014 at 10:57 AM, Andrija Panic andrija.pa...@gmail.com wrote: 500 is 500 the vlan of your guestnetwork or your physical network? You wouldn't want to have two nets with vlan 500! -- Daan -- Andrija Panić -- http://admintweets.com -- -- Daan
RE: [ANNOUNCE] Saksham Srivastava as committer
Congratulations Saksham. --Sanjay -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, May 29, 2014 12:18 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
Re: [ACS 4.3] listUsageRecords API bug related to CLOUDSTACK-6472
Hi Daan, Rajani
I looked at a code of master and 4.4 branch. findById is used at line
3031 of master branch and line 3299 of 4.4 branch, so I think this
leads to an same problem.
The code snippets of master and 4.4 branch are below.
[master] server/src/com/cloud/api/ApiResponseHelper.java
2987 @Override
2988 public UsageRecordResponse createUsageResponse(Usage usageRecord) {
2989 UsageRecordResponse usageRecResponse = new
UsageRecordResponse();
2990
2991 Account account =
ApiDBUtils.findAccountById(usageRecord.getAccountId());
2992 if (account.getType() == Account.ACCOUNT_TYPE_PROJECT) {
2993 //find the project
2994 Project project =
ApiDBUtils.findProjectByProjectAccountId(account.getId());
2995 usageRecResponse.setProjectId(project.getUuid());
2996 usageRecResponse.setProjectName(project.getName());
2997 } else {
2998 usageRecResponse.setAccountId(account.getUuid());
2999 usageRecResponse.setAccountName(account.getAccountName());
3000 }
3001
3002 Domain domain =
ApiDBUtils.findDomainById(usageRecord.getDomainId());
3003 if (domain != null) {
3004 usageRecResponse.setDomainId(domain.getUuid());
3005 }
3006
3007 if (usageRecord.getZoneId() != null) {
3008 DataCenter zone =
ApiDBUtils.findZoneById(usageRecord.getZoneId());
3009 if (zone != null) {
3010 usageRecResponse.setZoneId(zone.getUuid());
3011 }
3012 }
3013 usageRecResponse.setDescription(usageRecord.getDescription());
3014 usageRecResponse.setUsage(usageRecord.getUsageDisplay());
3015 usageRecResponse.setUsageType(usageRecord.getUsageType());
3016 if (usageRecord.getVmInstanceId() != null) {
3017 VMInstanceVO vm =
_entityMgr.findByIdIncludingRemoved(VMInstanceVO.class,
usageRecord.getVmInstanceId());
3018 if (vm != null) {
3019 usageRecResponse.setVirtualMachineId(vm.getUuid());
3020 }
3021 }
3022 usageRecResponse.setVmName(usageRecord.getVmName());
3023 if (usageRecord.getTemplateId() != null) {
3024 VMTemplateVO template =
ApiDBUtils.findTemplateById(usageRecord.getTemplateId());
3025 if (template != null) {
3026 usageRecResponse.setTemplateId(template.getUuid());
3027 }
3028 }
3029
3030 if (usageRecord.getUsageType() ==
UsageTypes.RUNNING_VM || usageRecord.getUsageType() ==
UsageTypes.ALLOCATED_VM) {
3031 ServiceOfferingVO svcOffering =
_entityMgr.findById(ServiceOfferingVO.class,
usageRecord.getOfferingId().toString());
3032 //Service Offering Id
3033 usageRecResponse.setOfferingId(svcOffering.getUuid());
3034 //VM Instance ID
3035 VMInstanceVO vm =
_entityMgr.findByIdIncludingRemoved(VMInstanceVO.class,
usageRecord.getUsageId().toString());
3036 if (vm != null) {
3037 usageRecResponse.setUsageId(vm.getUuid());
3038 }
3039 //Hypervisor Type
3040 usageRecResponse.setType(usageRecord.getType());
3041
[ACS 4.4] server/src/com/cloud/api/ApiResponseHelper.java
3255 @Override
3256 public UsageRecordResponse createUsageResponse(Usage usageRecord) {
3257 UsageRecordResponse usageRecResponse = new
UsageRecordResponse();
3258
3259 Account account =
ApiDBUtils.findAccountById(usageRecord.getAccountId());
3260 if (account.getType() == Account.ACCOUNT_TYPE_PROJECT) {
3261 //find the project
3262 Project project =
ApiDBUtils.findProjectByProjectAccountId(account.getId());
3263 usageRecResponse.setProjectId(project.getUuid());
3264 usageRecResponse.setProjectName(project.getName());
3265 } else {
3266 usageRecResponse.setAccountId(account.getUuid());
3267 usageRecResponse.setAccountName(account.getAccountName());
3268 }
3269
3270 Domain domain =
ApiDBUtils.findDomainById(usageRecord.getDomainId());
3271 if (domain != null) {
3272 usageRecResponse.setDomainId(domain.getUuid());
3273 }
3274
3275 if (usageRecord.getZoneId() != null) {
3276 DataCenter zone =
ApiDBUtils.findZoneById(usageRecord.getZoneId());
3277 if (zone != null) {
3278 usageRecResponse.setZoneId(zone.getUuid());
3279 }
3280 }
3281 usageRecResponse.setDescription(usageRecord.getDescription());
3282 usageRecResponse.setUsage(usageRecord.getUsageDisplay());
3283
Re: Need help with simstack vagrant box
On May 29, 2014, at 11:48 AM, Madan Ganesh V madangan...@me.com wrote: Hello CloudStack forum, We are following the steps mentioned: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Create+config+management+recipes+to+install+CloudStack https://github.com/runseb/simstack to bring up a cloudstack dev instance. After running vagrant up and vagrant reload —provision command, we notice that cloud stack is not up yet! After SSH into the vagrant box, we notice that there is not cloudstack java process running. Has anyone brought simstack successfully? simstack is a side project of mine and by no means any type of official release of cloudstack. I just made a push to disable the ansible provisioning you are seeing (deploying wordpress), and revert to basic cloudstack source compilation using the bootstrap-ubuntu.sh script. So pull again and try it. Just have a look at that bash script if you want to figure out how to compile things. But basically you are on your own :) -Sebastien Here is the excerpts from the vagrant reload: == default: Attempting graceful shutdown of VM... == default: Clearing any previously set forwarded ports... == default: Clearing any previously set network interfaces... == default: Preparing network interfaces based on configuration... default: Adapter 1: nat == default: Forwarding ports... default: 8080 = 8080 (adapter 1) default: 8081 = 8081 (adapter 1) default: 7080 = 7080 (adapter 1) default: 8000 = 8000 (adapter 1) default: 80 = 8001 (adapter 1) default: 22 = (adapter 1) == default: Running 'pre-boot' VM customizations... == default: Booting VM... == default: Waiting for machine to boot. This may take a few minutes... default: SSH address: 127.0.0.1: default: SSH username: vagrant default: SSH auth method: private key default: Warning: Connection timeout. Retrying... default: Warning: Connection timeout. Retrying... default: Warning: Connection timeout. Retrying... default: Warning: Connection timeout. Retrying... == default: Machine booted and ready! == default: Checking for guest additions in VM... == default: Setting hostname... == default: Mounting shared folders... default: /srv = /Volumes/ActOnMagic/simstack/salt/roots default: /vagrant = /Volumes/ActOnMagic/simstack == default: Running provisioner: shell... default: Running: inline script == default: Running provisioner: ansible... ANSIBLE_FORCE_COLOR=true ANSIBLE_HOST_KEY_CHECKING=false PYTHONUNBUFFERED=1 ansible-playbook --private-key=/Users/madang/.vagrant.d/insecure_private_key --user=vagrant --limit='default' --inventory-file=/Vo …. TASK: [php-fpm | Copy php-fpm configuration] ** 127.0.0.1 ESTABLISH CONNECTION FOR USER: vagrant 127.0.0.1 EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o', 'ControlPersist=60s', '-o', 'ControlPath=/Users/madang/.ansible/cp/ansible-ssh-%h-%p-%r', '-o', 'StrictHostKeyChecking=no', '-o', 'Port=', '-o', 'IdentityFile=/Users/madang/.vagrant.d/insecure_private_key', '-o', 'KbdInteractiveAuthentication=no', '-o', 'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o', 'PasswordAuthentication=no', '-o', 'User=vagrant', '-o', 'ConnectTimeout=10', '127.0.0.1', /bin/sh -c 'mkdir -p $HOME/.ansible/tmp/ansible-tmp-1401356524.77-108295687200060 chmod a+rx $HOME/.ansible/tmp/ansible-tmp-1401356524.77-108295687200060 echo $HOME/.ansible/tmp/ansible-tmp-1401356524.77-108295687200060'] 127.0.0.1 EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o', 'ControlPersist=60s', '-o', 'ControlPath=/Users/madang/.ansible/cp/ansible-ssh-%h-%p-%r', '-o', 'StrictHostKeyChecking=no', '-o', 'Port=', '-o', 'IdentityFile=/Users/madang/.vagrant.d/insecure_private_key', '-o', 'KbdInteractiveAuthentication=no', '-o', 'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o', 'PasswordAuthentication=no', '-o', 'User=vagrant', '-o', 'ConnectTimeout=10', '127.0.0.1', u'/bin/sh -c \'sudo -k sudo -H -S -p [sudo via ansible, key=dyyespcdwcthzzkmglnauwbwpyujxupu] password: -u root /bin/sh -c \'\'\'echo SUDO-SUCCESS-dyyespcdwcthzzkmglnauwbwpyujxupu; rc=0; [ -r /etc/php-fpm.d/wordpress.conf ] || rc=2; [ -f /etc/php-fpm.d/wordpress.conf ] || rc=1; [ -d /etc/php-fpm.d/wordpress.conf ] echo 3 exit 0; (/usr/bin/md5sum /etc/php-fpm.d/wordpress.conf 2/dev/null) || (/sbin/md5sum -q /etc/php-fpm.d/wordpress.conf 2/dev/null) || (/usr/bin/digest -a md5 /etc/php-fpm.d/wordpress.conf 2/dev/null) || (/sbin/md5 -q /etc/php-fpm.d/wordpress.conf 2/dev/null) || (/usr/bin/md5 -n /etc/php-fpm.d/wordpress.conf 2/dev/null) || (/bin/md5 -q /etc/php-fpm.d/wordpress.conf 2/dev/null) || (/usr/bin/csum -h MD5 /etc/php-fpm.d/wordpress.conf 2/dev/null) || (/bin/csum -h MD5 /etc/php-fpm.d/wordpress.conf 2/dev/null)
Re: VPC's VR missing public NIC eth1
They are 2 traffic types on 1 physical net (that is both tagged vlan 500, and untagged packets travel over same KVM bridge, and over eth1 to outside world)... On 29 May 2014 12:04, Daan Hoogland daan.hoogl...@gmail.com wrote: Are these two traffic types in one physical net? or two physical nets on the same interface (seems wrong). On Thu, May 29, 2014 at 11:35 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: I don't think editing DB table will work. -Jayapal On 29-May-2014, at 2:52 PM, Andrija Panic andrija.pa...@gmail.com wrote: It's like this: I have public subnet /24. half is dedicated for Guest traffic (vlan 500) and the second half is dedicated to Public traffic/network (no vlan tags, that is untagged packets) Both vlan500 and untagged packets travel over physical eth1 interface on hypervisors and can reach Internet. Thanks, On 29 May 2014 11:06, Daan Hoogland daan.hoogl...@gmail.com wrote: On Thu, May 29, 2014 at 10:57 AM, Andrija Panic andrija.pa...@gmail.com wrote: 500 is 500 the vlan of your guestnetwork or your physical network? You wouldn't want to have two nets with vlan 500! -- Daan -- Andrija Panić -- http://admintweets.com -- -- Daan -- Andrija Panić -- http://admintweets.com --
[ACS4.4] [Issue] Unable to create a autoscalevmprofile
Hi All,
I was trying to create a autoscalevmprofile with a sample data for a test
case. Can anyone help me to know is there anything I'm missing in the input
parameters ?
I get a nullpointer error is it due to the missing deployParams parameter ?
I'm running this test on simulator.
self.account_1A = Account.create(
self.apiclient,
self.services[account1A],
admin=False,
domainid=self.domain_1.id
)
self.userapiclient_1A =
self.testClient.getUserApiClient(self.user_1A.username,
self.domain_1.name)
self.service_offering = ServiceOffering.create(
self.apiclient,
self.services[service_offering][small]
)
self.zone = get_zone(self.apiclient, testClient.getZoneForTests())
list_users = User.list(
self.apiclient,
listall=self.services[listall],
account=self.account_1A.name,
domainid=self.domain_1.id
)
self.template = get_template(self.apiclient, self.zone.id,
self.services[ostype])
counterparam = { snmpcommunity: public, snmpport: 161}
autoscalevm_profile_1A = Autoscale.createAutoscaleVmProfile(
self.userapiclient_1A,
serviceofferingid=self.service_offering.id,
zoneid=
self.zone.id,
templateid=
self.template.id,
autoscaleuserid=list_users[0].id,
destroyvmgraceperiod='100',
counterparam=counterparam
)
I get this error in the logs :
ERROR [c.c.a.ApiServer] (25349580@qtp-22625812-44:ctx-76e14380 ctx-e717232f
ctx-7cea9dc0) unhandled exception executing api command:
[Ljava.lang.String;@17c7c4d
java.lang.NullPointerException
at
org.apache.cloudstack.api.command.user.vm.DeployVMCmd.getEntityOwnerId(DeployVMCmd.java:411)
at
com.cloud.api.dispatch.ParamProcessWorker.doAccessChecks(ParamProcessWorker.java:227)
at
com.cloud.api.dispatch.ParamProcessWorker.processParameters(ParamProcessWorker.java:221)
at
com.cloud.api.dispatch.ParamProcessWorker.handle(ParamProcessWorker.java:93)
at
com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37)
at
com.cloud.network.as.AutoScaleManagerImpl.createAutoScaleVmProfile(AutoScaleManagerImpl.java:373)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy254.createAutoScaleVmProfile(Unknown Source)
at
org.apache.cloudstack.api.command.user.autoscale.CreateAutoScaleVmProfileCmd.create(CreateAutoScaleVmProfileCmd.java:263)
at
com.cloud.api.dispatch.CommandCreationWorker.handle(CommandCreationWorker.java:47)
at
com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37)
at
com.cloud.api.ApiDispatcher.dispatchCreateCmd(ApiDispatcher.java:74)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:614)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:506)
at
com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330)
at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
at
RE: seeing Unknown parameters : ctxdetails for addResourceDetail/removeResourceDetail
We still see Unknown parameters... huge number of logs in server log. May be, we can make this as configurable or dump to some other log say misc log, if mandatory params are not sent as per request, dump to the log and return, if arg types and arguments as per validation are wrong, then dump. But dumping every unknown param, real issues get lost with these huge log set rolling when debugging. Regards, Santhosh From: Nitin Mehta [nitin.me...@citrix.com] Sent: Monday, May 19, 2014 2:42 AM To: Antonio Fornié Casarrubios; cloudstack Subject: Re: seeing Unknown parameters : ctxdetails for addResourceDetail/removeResourceDetail Thanks Anotnio. That’s what I have been saying from the beginning. IMHO, I don’t see much value in having this, but I am really concerned with the performance of the apis especially in production setups. For this reason can we please remove this worker or at the very least have a setting to not have it turned on by default ? -Nitin From: Antonio Fornié Casarrubios antonio.for...@gmail.commailto:antonio.for...@gmail.com Date: Sunday 18 May 2014 4:22 PM To: cloudstack dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Cc: Nitin Mehta nitin.me...@citrix.commailto:nitin.me...@citrix.com Subject: Re: seeing Unknown parameters : ctxdetails for addResourceDetail/removeResourceDetail If the parameter is correct then it should not be in the logs as unknown. And so it should be added to the worker in the list of parameters that the worker will never blame. That is the fix. Right? Perhaps it is not considered good that everytime a new parameter is added to the api requests it has to be included in the worker. In that case then perhaps it's better to just completely remove the worker itself. Thansk, cheers Antonio El 16/05/2014 23:21, Min Chen min.c...@citrix.commailto:min.c...@citrix.com escribió: Ctxdetails complained in your warning log is one of internal parameters added by ApiDispatcher, and is not publicly presented in the API Cmd class. For those parameters, they are not errors in the request and nothing to be fixed. Thanks -min On 5/14/14 12:46 AM, Antonio Fornié Casarrubios antonio.for...@gmail.commailto:antonio.for...@gmail.com wrote: The errors in the requests are created by these well known clients, that's why they should be fixed. It's not that the admin misspelled a param, it's more that the code that creates the requests (the js in the web ui, cloudmonkey, Marvin or any other...) Cheers antonio 2014-05-14 3:05 GMT+02:00 Nitin Mehta nitin.me...@citrix.commailto:nitin.me...@citrix.com: Daan - MS logs are visible only to the admin and not a general user. So are you saying this is for admin to debug in case he misspelled a param ? I feel that this shouldn’t be ON by default and whether such logic should be part of CS core ? I also find it difficult to understand that in production the admin would commit such basic mistakes. I am assuming that he/she would be a power user and would be using well known clients - say cmd line or UI to fire apis against CS. Thanks, -Nitin On 13/05/14 1:58 PM, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: It is usefull for users that misspell a parameter and expect behavior related to it. not just in development. On Tue, May 13, 2014 at 7:24 PM, Nitin Mehta nitin.me...@citrix.commailto:nitin.me...@citrix.com wrote: I introduced the parameter ctxdetails which carries all the context details (currently all the first class entities and their corresponding interface mapping). This would be done for each of the api and hence seen for all apis. I saw the code in ParamGenericValidationWorker and will fix this. Filed a bug CLOUDSTACK-6658 But I am curious why we have this code at all ? It checks whether the params passed for the api are an exact match (nothing more nothing less) to the params we expect and if not throws only a warning as seen below. While it might be good for a developer setup it decreases the performance for production systems I believe. Thanks, -Nitin On 13/05/14 3:01 AM, Koushik Das koushik@citrix.commailto:koushik@citrix.com wrote: I am seeing the same for many commands. So this is not specific to add/removeResourceDetail 2014-05-09 18:17:39,477 WARN [c.c.a.d.ParamGenericValidationWorker] (API-Job-Executor-24:job-28 ctx-6eaab5d7) Received unknown parameters for command updateNetworkServiceProvider. Unknown parameters : ctxdetails 2014-05-09 18:17:42,584 WARN [c.c.a.d.ParamGenericValidationWorker] (API-Job-Executor-25:job-29 ctx-9c9f87f4) Received unknown parameters for command updatePhysicalNetwork. Unknown parameters : ctxdetails 2014-05-12 11:13:29,079 WARN [c.c.a.d.ParamGenericValidationWorker] (API-Job-Executor-1:job-3 ctx-146e0b74) Received unknown parameters for command createPhysicalNetwork. Unknown parameters : ctxdetails 2014-05-12
RE: [PROPOSAL] - Change Primary IP Address
Wido, It's something I'll look into over time however there are a few more complexities to overcome with a basic zone. Once Advanced has been done hopefully Basic will follow shortly behind. Alex Hitchins | 07788 423 969 | 01892 523 587 -Original Message- From: Wido den Hollander [mailto:w...@widodh.nl] Sent: 28 May 2014 22:09 To: dev@cloudstack.apache.org Subject: Re: [PROPOSAL] - Change Primary IP Address On 05/28/2014 04:36 PM, Alex Hitchins wrote: All, I'd like to submit the below proposal. This can also be found here : https://cwiki.apache.org/confluence/display/CLOUDSTACK/New+API+call+to +chang e+Primary+IP+address+after+VM+creation+in+Advanced+Zones I've started looking into this project although before anything is written I'd like community thoughts and feedback. Why only Advanced? I think this feature would benefit Basic Zone networks as well. I know that a lot of public cloud offerings use the Basic Zone networking and would love to see this feature. Wido Subject: New API call to change Primary IP address after VM creation in Advanced Zones. Background: Currently the only way to change the IP address (via the API) is to drop a NIC attached to the VM and then add a new NIC with the desired new IP address. The process is as follows: 1. Add Temp NIC 2. Make Temp NIC default 3. Remove original NIC 4. Add NIC on same network as NIC removed in step 3, specifying IP as you add it 5. Make newly added NIC default 6. Remove Temp NIC This process works however it will mean the VM will see a new MAC address which could mean additional configuration is required. The existing API calls (removeIPFromNic addIpToNic) only allow the user to modify the secondary IP addresses. This proposal is to create a new API call allowing the user to reset the IP address without the need to remove and add a new NIC. Requirements: 1. Add a new API call under the NIC section for root admin users, allowing them to specify a new IP address for a given NIC e.g. amendIpToNic ( int nicId, string oldIpAddress, string newIpAddress ) 2. The system should check to ensure the new IP address that is being applied isn't already in use on the network. 3. The API call on success will require the virtual machine to be restarted for DHCP to be refreshed. 4. The functionality should apply to Advanced Zones. Comments: While we will perform a cursory check to see that the IP address isn't already in use, no other checks will be made. It will still be up to the domain administrator to manage IP allocation. Alex Hitchins -- E: a...@alexhitchins.com W: alexhitchins.com M: 07788 423 969 T: 01892 523 587
Re: Review Request 21628: CLOUDSTACK-6282: Automated network API Tests and uploaded patch
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21628/#review44256 --- Commit cdf4047ce823edcdd73f9a1562abc9c27f473557 in cloudstack's branch refs/heads/master from monism [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cdf4047 ] CLOUDSTACK-6282-Added Autometed test for network APIs after incorporating review comments - ASF Subversion and Git Services On May 29, 2014, 6:13 a.m., Monis Majeed wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21628/ --- (Updated May 29, 2014, 6:13 a.m.) Review request for cloudstack and Santhosh Edukulla. Bugs: CLOUDSTACK-6282 https://issues.apache.org/jira/browse/CLOUDSTACK-6282 Repository: cloudstack-git Description --- Automated network API Tests and uploaded patch Diffs - test/integration/component/test_escalations_networks.py PRE-CREATION tools/marvin/marvin/config/test_data.py 52be02d tools/marvin/marvin/lib/base.py a301e25 Diff: https://reviews.apache.org/r/21628/diff/ Testing --- Executed all the Network tests and uploaded the results file File Attachments results.txt https://reviews.apache.org/media/uploaded/files/2014/05/19/0574d454-3aae-4cf4-9c45-af8fc678b487__results.txt Results https://reviews.apache.org/media/uploaded/files/2014/05/23/12f03114-aeeb-4856-9450-cce2826c75c3__NetworksResults.txt Thanks, Monis Majeed
RE: [ANNOUNCE] Saksham Srivastava as committer
Congratulations Saksham.. Thanks, Vaibhav -Original Message- From: Sanjay Tripathi [mailto:sanjay.tripa...@citrix.com] Sent: 29 May 2014 15:39 To: dev@cloudstack.apache.org Subject: RE: [ANNOUNCE] Saksham Srivastava as committer Congratulations Saksham. --Sanjay -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, May 29, 2014 12:18 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
Re: Erro: No remote endpoint to send command, check if host or ssvm is down?
Hi, Before I ran any kind of command I decided to dive a little deeper into this issue. So, I checked the systemvm.iso that is inside CS MS. and it turned out that it has the jars for the CS agent 4.3.0. However, I also checked the systemvm.iso that is in the xen hosts in /usr/share/xcp/packages/iso/. That .iso also has the jars for the 4.3.0 agent. So, I do not get why my systems VMs have the jar for the 4.1.1 version. Can somebody explain me the process, like when the jars that are in the systemvm.iso are copied to the system vm? which scripts do that? is there any way to debug that process? I do not understand how the jars from 4.1.1 version are in the Systemvm of 4.3.0 version. On Wed, May 28, 2014 at 6:16 PM, Min Chen min.c...@citrix.com wrote: I don't know the exact cmd line to clear that, and I have always used XenCenter UI to do that, where clear tags in General tabs. Thanks -min On 5/28/14 2:11 PM, Rafael Weingartner rafaelweingart...@gmail.com wrote: by clear, you mean xe vdi-destroy uuid=vdi of systemvm.iso? So, I just need to stop the management servers, run that in every cluster that I have and everything should be fine? On Wed, May 28, 2014 at 5:42 PM, Min Chen min.c...@citrix.com wrote: You should clear old systemvm.iso from xen server so that new systemvm.iso built can be deployed there. Thanks -min On 5/28/14 12:42 PM, Rafael Weingartner rafaelweingart...@gmail.com wrote: Another interesting fact: All the jars, cloud-**.jar are label as if they were 4.1.1 version. Is that right? On Wed, May 28, 2014 at 4:01 PM, Rafael Weingartner rafaelweingart...@gmail.com wrote: Just an update. I have just checked my console proxy VM, which is also with -- in agent state at insfrastructureSystem VM page. The agente is running there, however its state is --. I also looked into the source code, and the class org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource is located in a jar called cloud-secondary-storage which is not in the directory /usr/local/cloud/systemvm that contains the jars used to run the agent. Neither in my SSVM nor in Console proxy VM that jar exist. I do not get, I cannot be the only one with this problem. It seems that this jar is missing into the system vm template. On Wed, May 28, 2014 at 2:45 PM, Rafael Weingartner rafaelweingart...@gmail.com wrote: thanks, I checked the /var/log/cloud/cloud.out, And I found this error: ERROR AgentShell:607 - Unable to start agent: Resource class not found: org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource due to: java.lang.ClassNotFoundException: org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource Unable to start agent: Resource class not found: org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource due to: java.lang.ClassNotFoundException: org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource It seems that there is a jar dependency missing. On Wed, May 28, 2014 at 2:31 PM, Min Chen min.c...@citrix.com wrote: Your UI indicates that agent is not running on your SSVM, it should show as 'Running', that is why your cloud.host does not have an entry for your new SSVM, thus we cannot find a remote host to send command to. Agent is a java code running inside your SSVM, you should see what error you encountered in starting agent in your ssvm from cloud.out file in SSVM log. Thanks -min On 5/28/14 10:20 AM, Rafael Weingartner rafaelweingart...@gmail.com wrote: What agent are you talking about? Is it an app that run into the SSVM? I am using xenserver and XCP as the hypervisor. I looked into the CS UI, infrastructureSystem VMs and the column that has some values about the agent-state has a -- in it. Is it normal? At the end, should the SSVM have an entry into the host table? On Wed, May 28, 2014 at 2:05 PM, Min Chen min.c...@citrix.com wrote: Check if agent is running your ssvm. Thanks -min On 5/28/14 7:26 AM, Rafael Weingartner rafaelweingart...@gmail.com wrote: Hi all, sorry, to bother you again with this thread. Could at least someone that has the CS 4.3.0 deployed try to download a volume and/or a template? Could someone also check the database, table ³cloud.host² and look if there is an entry there for the running SSVM and console proxy VM? On Mon, May 26, 2014 at 4:42 PM, Rafael Weingartner rafaelweingart...@gmail.com wrote: Hi folks, I am sending this to the dev list as well, hence I am not sure if it is or not a bug. Sorry if I am mistaken. So, after I upgraded CS from 4.1.1 to 4.3.0, everything seemed to be working just fine, however, whenever I try to
Re: Review Request 20316: CLOUDSTACK-1466: Adding automation test cases for Primary Storage Limits
On May 8, 2014, 5:06 p.m., Santhosh Edukulla wrote: tools/marvin/marvin/lib/common.py, line 1103 https://reviews.apache.org/r/20316/diff/2/?file=567838#file567838line1103 Please dont add asserts to lib functions, just check the output in test code and take it accordingly. Assert is inside try catch block, so exception won't be raised directly from library. We are returning FAIL in case of exception, along with the exception message. On May 8, 2014, 5:06 p.m., Santhosh Edukulla wrote: tools/marvin/marvin/lib/common.py, line 1122 https://reviews.apache.org/r/20316/diff/2/?file=567838#file567838line1122 Please remove asserts from libs. It is inside try catch block. On May 8, 2014, 5:06 p.m., Santhosh Edukulla wrote: tools/marvin/marvin/lib/common.py, line 1203 https://reviews.apache.org/r/20316/diff/2/?file=567838#file567838line1203 This as well can be added to base.py. Maintaining too much common functions dependent upon base.py libraries is current overhead, VirtualMachine_obj.getState(args) can give us is expunged or stopped or started etc. When VM is expunged, we do not get its state as Expunged. List API throws exception in this case as it does not find the VM id. Hence this case is not a candidate for getState function in base.py On May 8, 2014, 5:06 p.m., Santhosh Edukulla wrote: tools/marvin/marvin/lib/common.py, line 1185 https://reviews.apache.org/r/20316/diff/2/?file=567838#file567838line1185 Can we move this function inside Snapshot class only? Moved inside snapshot class On May 8, 2014, 5:06 p.m., Santhosh Edukulla wrote: test/integration/component/test_ps_domain_limits.py, line 51 https://reviews.apache.org/r/20316/diff/2/?file=567831#file567831line51 Also, we can do a quick code walkthrough to understand the flow. It will help to do it more thoroughly. We can do a gtm. Sure - Gaurav --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20316/#review42477 --- On April 24, 2014, 11:01 p.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20316/ --- (Updated April 24, 2014, 11:01 p.m.) Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla. Bugs: CLOUDSTACK-1466 https://issues.apache.org/jira/browse/CLOUDSTACK-1466 Repository: cloudstack-git Description --- Adding test suits in Primary Storage Limits test cases. 1)Root/Domain admin limits 2)Domain Limits 3)Resize volume 4)Project Limits 5)Maximum Limits Diffs - test/integration/component/test_ps_domain_limits.py PRE-CREATION test/integration/component/test_ps_limits.py PRE-CREATION test/integration/component/test_ps_max_limits.py PRE-CREATION test/integration/component/test_ps_project_limits.py PRE-CREATION test/integration/component/test_ps_resize_volume.py PRE-CREATION tools/marvin/marvin/codes.py 4d44c58 tools/marvin/marvin/lib/base.py d753098 tools/marvin/marvin/lib/common.py 8868d2d Diff: https://reviews.apache.org/r/20316/diff/ Testing --- Yes Thanks, Gaurav Aradhye
Re: seeing Unknown parameters : ctxdetails for addResourceDetail/removeResourceDetail
grep -v is your friend (or grep -ev even) On Thu, May 29, 2014 at 2:06 PM, Santhosh Edukulla santhosh.eduku...@citrix.com wrote: We still see Unknown parameters... huge number of logs in server log. May be, we can make this as configurable or dump to some other log say misc log, if mandatory params are not sent as per request, dump to the log and return, if arg types and arguments as per validation are wrong, then dump. But dumping every unknown param, real issues get lost with these huge log set rolling when debugging. Regards, Santhosh From: Nitin Mehta [nitin.me...@citrix.com] Sent: Monday, May 19, 2014 2:42 AM To: Antonio Fornié Casarrubios; cloudstack Subject: Re: seeing Unknown parameters : ctxdetails for addResourceDetail/removeResourceDetail Thanks Anotnio. That’s what I have been saying from the beginning. IMHO, I don’t see much value in having this, but I am really concerned with the performance of the apis especially in production setups. For this reason can we please remove this worker or at the very least have a setting to not have it turned on by default ? -Nitin From: Antonio Fornié Casarrubios antonio.for...@gmail.commailto:antonio.for...@gmail.com Date: Sunday 18 May 2014 4:22 PM To: cloudstack dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Cc: Nitin Mehta nitin.me...@citrix.commailto:nitin.me...@citrix.com Subject: Re: seeing Unknown parameters : ctxdetails for addResourceDetail/removeResourceDetail If the parameter is correct then it should not be in the logs as unknown. And so it should be added to the worker in the list of parameters that the worker will never blame. That is the fix. Right? Perhaps it is not considered good that everytime a new parameter is added to the api requests it has to be included in the worker. In that case then perhaps it's better to just completely remove the worker itself. Thansk, cheers Antonio El 16/05/2014 23:21, Min Chen min.c...@citrix.commailto:min.c...@citrix.com escribió: Ctxdetails complained in your warning log is one of internal parameters added by ApiDispatcher, and is not publicly presented in the API Cmd class. For those parameters, they are not errors in the request and nothing to be fixed. Thanks -min On 5/14/14 12:46 AM, Antonio Fornié Casarrubios antonio.for...@gmail.commailto:antonio.for...@gmail.com wrote: The errors in the requests are created by these well known clients, that's why they should be fixed. It's not that the admin misspelled a param, it's more that the code that creates the requests (the js in the web ui, cloudmonkey, Marvin or any other...) Cheers antonio 2014-05-14 3:05 GMT+02:00 Nitin Mehta nitin.me...@citrix.commailto:nitin.me...@citrix.com: Daan - MS logs are visible only to the admin and not a general user. So are you saying this is for admin to debug in case he misspelled a param ? I feel that this shouldn’t be ON by default and whether such logic should be part of CS core ? I also find it difficult to understand that in production the admin would commit such basic mistakes. I am assuming that he/she would be a power user and would be using well known clients - say cmd line or UI to fire apis against CS. Thanks, -Nitin On 13/05/14 1:58 PM, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: It is usefull for users that misspell a parameter and expect behavior related to it. not just in development. On Tue, May 13, 2014 at 7:24 PM, Nitin Mehta nitin.me...@citrix.commailto:nitin.me...@citrix.com wrote: I introduced the parameter ctxdetails which carries all the context details (currently all the first class entities and their corresponding interface mapping). This would be done for each of the api and hence seen for all apis. I saw the code in ParamGenericValidationWorker and will fix this. Filed a bug CLOUDSTACK-6658 But I am curious why we have this code at all ? It checks whether the params passed for the api are an exact match (nothing more nothing less) to the params we expect and if not throws only a warning as seen below. While it might be good for a developer setup it decreases the performance for production systems I believe. Thanks, -Nitin On 13/05/14 3:01 AM, Koushik Das koushik@citrix.commailto:koushik@citrix.com wrote: I am seeing the same for many commands. So this is not specific to add/removeResourceDetail 2014-05-09 18:17:39,477 WARN [c.c.a.d.ParamGenericValidationWorker] (API-Job-Executor-24:job-28 ctx-6eaab5d7) Received unknown parameters for command updateNetworkServiceProvider. Unknown parameters : ctxdetails 2014-05-09 18:17:42,584 WARN [c.c.a.d.ParamGenericValidationWorker] (API-Job-Executor-25:job-29 ctx-9c9f87f4) Received unknown parameters for command updatePhysicalNetwork. Unknown parameters : ctxdetails 2014-05-12 11:13:29,079 WARN
Re: [ACS4.4] [Issue] Unable to create a autoscalevmprofile
Megha,
in my current 4.4 line 411 of DeployVMCmd reads
if (accountId == null) {
hence it doesn't refer a pointer at that line.
which version are you using to get this:
java.lang.NullPointerException
at
org.apache.cloudstack.api.command.user.vm.DeployVMCmd.getEntityOwnerId(DeployVMCmd.java:411)
On Thu, May 29, 2014 at 12:53 PM, Meghna Kale meghna.k...@sungardas.com wrote:
Hi All,
I was trying to create a autoscalevmprofile with a sample data for a test
case. Can anyone help me to know is there anything I'm missing in the input
parameters ?
I get a nullpointer error is it due to the missing deployParams parameter ?
I'm running this test on simulator.
self.account_1A = Account.create(
self.apiclient,
self.services[account1A],
admin=False,
domainid=self.domain_1.id
)
self.userapiclient_1A =
self.testClient.getUserApiClient(self.user_1A.username,
self.domain_1.name)
self.service_offering = ServiceOffering.create(
self.apiclient,
self.services[service_offering][small]
)
self.zone = get_zone(self.apiclient, testClient.getZoneForTests())
list_users = User.list(
self.apiclient,
listall=self.services[listall],
account=self.account_1A.name,
domainid=self.domain_1.id
)
self.template = get_template(self.apiclient, self.zone.id,
self.services[ostype])
counterparam = { snmpcommunity: public, snmpport: 161}
autoscalevm_profile_1A = Autoscale.createAutoscaleVmProfile(
self.userapiclient_1A,
serviceofferingid=self.service_offering.id,
zoneid=
self.zone.id,
templateid=
self.template.id,
autoscaleuserid=list_users[0].id,
destroyvmgraceperiod='100',
counterparam=counterparam
)
I get this error in the logs :
ERROR [c.c.a.ApiServer] (25349580@qtp-22625812-44:ctx-76e14380 ctx-e717232f
ctx-7cea9dc0) unhandled exception executing api command:
[Ljava.lang.String;@17c7c4d
java.lang.NullPointerException
at
org.apache.cloudstack.api.command.user.vm.DeployVMCmd.getEntityOwnerId(DeployVMCmd.java:411)
at
com.cloud.api.dispatch.ParamProcessWorker.doAccessChecks(ParamProcessWorker.java:227)
at
com.cloud.api.dispatch.ParamProcessWorker.processParameters(ParamProcessWorker.java:221)
at
com.cloud.api.dispatch.ParamProcessWorker.handle(ParamProcessWorker.java:93)
at
com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37)
at
com.cloud.network.as.AutoScaleManagerImpl.createAutoScaleVmProfile(AutoScaleManagerImpl.java:373)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy254.createAutoScaleVmProfile(Unknown Source)
at
org.apache.cloudstack.api.command.user.autoscale.CreateAutoScaleVmProfileCmd.create(CreateAutoScaleVmProfileCmd.java:263)
at
com.cloud.api.dispatch.CommandCreationWorker.handle(CommandCreationWorker.java:47)
at
com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37)
at
Review Request 22019: CLOUDSTACK-6732: [OVS][UI] Network Service Providers page displays two ovs providers
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22019/ --- Review request for cloudstack, Brian Federle and Jessica Wang. Bugs: CLOUDSTACK-6732 https://issues.apache.org/jira/browse/CLOUDSTACK-6732 Repository: cloudstack-git Description --- Fixed: CLOUDSTACK-6732: [OVS][UI] Network Service Providers page displays two ovs providers Diffs - ui/scripts/system.js 67e01f1 Diff: https://reviews.apache.org/r/22019/diff/ Testing --- Thanks, Gabor Apati-Nagy
Re: [DISCUSS] Proposal to submit NuageVsp plugin support in CloudStack 4.5
Hi, Looks like the attachment was stripped. So, please find the proposal below: *Introduction:* We are planning to develop NuageVsp networking plugin that will bring Nuage VSP network virtualization technology to CloudStack. *Feature Summary:* For the Nuage VSP Plugin, we plan to support following network model/service combination 1. Advanced Isolated network mode: DHCP Static NAT SourceNAT Firewall VirtualConnectivity 2. VPC network mode: DHCP Static NAT SourceNAT NetworkACL VirtualConnectivity The initial implementation targets the Xen Server hypervisor *Advantages:* All the network isolation and routing is handled by the Nuage SDN Solution. Routing of the packets happen at hypervisor itself. Virtual Router is not used for routing the packets. The VIrtual Router VM is spawned only for Password Reset funtionality. The Nuage solution also helps significantly improve the agility and scale if the CS deployment as compared to any Virtual Router based deployment. *Architecture and Design description:* A Nuage VSP plugin will be developed to add Nuage network virtualization into CloudStack NuageVspNetworkGuru This network guru is implemented to a) Create/Delete logical topology in VSP b) Create/Delete VM NuageVspElement a) Create/Delete Firewall and Egress rule in VSP b) Create/Delete Static NAT NuageVspVpcElement a) Create/Delete NetworkACL b) Spawn/Delete VR NuageVspManagerImpl a) Create a default VPC offering b) Handle sync to clean up the stale entities in VSP Could you please review the proposal and let me know if I need to provide any more information for the proposal to be accepted. Thanks, Suresh On Friday, May 23, 2014 6:42:21 PM UTC-7, David Nalley wrote: On Fri, May 23, 2014 at 8:33 PM, cloudstack-ci cloudstack...@nuagenetworks.net wrote: Hi, I am Suresh Ramamurthy working for Nuage Networks(http://www.nuagenetworks.net/). We would like to submit a proposal for our plugin support in Cloudstack 4.5. We have documented the details of our proposal in the attached design document. Could you please review the proposal and send us your feedback. Thanks, Suresh Hi Suresh: Attachments are stripped from the mailing list. Please consider posting the content of your document on our wiki and linking to it: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Home --David
RE: [ANNOUNCE] Saksham Srivastava as committer
Congrats Saksham. Regards, Rayees -Original Message- From: Sailaja Mada [mailto:sailaja.m...@citrix.com] Sent: Thursday, May 29, 2014 1:49 AM To: dev@cloudstack.apache.org Subject: RE: [ANNOUNCE] Saksham Srivastava as committer Congratulations Saksham. -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: 29 May 2014 12:18 To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
Re: [ANNOUNCE] Saksham Srivastava as committer
Good job! On Thu, May 29, 2014 at 8:49 AM, Rayees Namathponnan rayees.namathpon...@citrix.com wrote: Congrats Saksham. Regards, Rayees -Original Message- From: Sailaja Mada [mailto:sailaja.m...@citrix.com] Sent: Thursday, May 29, 2014 1:49 AM To: dev@cloudstack.apache.org Subject: RE: [ANNOUNCE] Saksham Srivastava as committer Congratulations Saksham. -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: 29 May 2014 12:18 To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
[GitHub] cloudstack-docs-rn pull request: updated formatting to be consiste...
GitHub user swill opened a pull request: https://github.com/apache/cloudstack-docs-rn/pull/14 updated formatting to be consistent with the rest of the docs You can merge this pull request into a Git repository by running: $ git pull https://github.com/cloudops/cloudstack-docs-rn swill Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack-docs-rn/pull/14.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #14 commit 03770d3d826079b8d67eff145b2d5b1a2165c315 Author: Will Stevens wstev...@cloudops.com Date: 2014-05-29T15:48:17Z updated formatting to be consistent with the rest of the docs --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack-docs-rn pull request: updated formatting to be consiste...
Github user asfgit closed the pull request at: https://github.com/apache/cloudstack-docs-rn/pull/14 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
RE: [PROPOSAL] - Change Primary IP Address
CloudStack supports 'cloud' workloads and 'enterprise' workloads as has been highlighted numerous times recently in e-mails comparing CloudStack to OpenStack. Yes 'cloudy' workloads should not need this, but enterprise workloads most definitely do. This is something which regularly comes up on the user lists Regards Geoff Higginbottom D: +44 20 3603 0542 | S: +44 20 3603 0540 | M: +447968161581 geoff.higginbot...@shapeblue.com -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: 29 May 2014 05:27 To: dev@cloudstack.apache.org Subject: Re: [PROPOSAL] - Change Primary IP Address Curious: What is the reason to change the primary IP? Quite un-cloudy. @Wido: changing the IP in basic zone is quite involved, not just changing a dnsmasq entry. From: Wido den Hollander w...@widodh.nlmailto:w...@widodh.nl Reply-To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Date: Wednesday, May 28, 2014 at 2:08 PM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: [PROPOSAL] - Change Primary IP Address On 05/28/2014 04:36 PM, Alex Hitchins wrote: All, I'd like to submit the below proposal. This can also be found here : https://cwiki.apache.org/confluence/display/CLOUDSTACK/New+API+call+to+chang e+Primary+IP+address+after+VM+creation+in+Advanced+Zones I've started looking into this project although before anything is written I'd like community thoughts and feedback. Why only Advanced? I think this feature would benefit Basic Zone networks as well. I know that a lot of public cloud offerings use the Basic Zone networking and would love to see this feature. Wido Subject: New API call to change Primary IP address after VM creation in Advanced Zones. Background: Currently the only way to change the IP address (via the API) is to drop a NIC attached to the VM and then add a new NIC with the desired new IP address. The process is as follows: 1. Add Temp NIC 2. Make Temp NIC default 3. Remove original NIC 4. Add NIC on same network as NIC removed in step 3, specifying IP as you add it 5. Make newly added NIC default 6. Remove Temp NIC This process works however it will mean the VM will see a new MAC address which could mean additional configuration is required. The existing API calls (removeIPFromNic addIpToNic) only allow the user to modify the secondary IP addresses. This proposal is to create a new API call allowing the user to reset the IP address without the need to remove and add a new NIC. Requirements: 1. Add a new API call under the NIC section for root admin users, allowing them to specify a new IP address for a given NIC e.g. amendIpToNic ( int nicId, string oldIpAddress, string newIpAddress ) 2. The system should check to ensure the new IP address that is being applied isn't already in use on the network. 3. The API call on success will require the virtual machine to be restarted for DHCP to be refreshed. 4. The functionality should apply to Advanced Zones. Comments: While we will perform a cursory check to see that the IP address isn't already in use, no other checks will be made. It will still be up to the domain administrator to manage IP allocation. Alex Hitchins -- E: a...@alexhitchins.commailto:a...@alexhitchins.com W: alexhitchins.com M: 07788 423 969 T: 01892 523 587 Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: Erro: No remote endpoint to send command, check if host or ssvm is down?
UPDATE: I finally cracked it. Even though the systemvm.iso files were updated into the xen servers, there was a .vhd file that is created into the local storage of the servers that are running the system VMs that contains the systemvm.iso files. Therefore, I had to stop the CS MSs delete those .vhd files from the local storage of my xenservers and everything was good to go. Thanks for your support Min ;) On Thu, May 29, 2014 at 10:03 AM, Rafael Weingartner rafaelweingart...@gmail.com wrote: Hi, Before I ran any kind of command I decided to dive a little deeper into this issue. So, I checked the systemvm.iso that is inside CS MS. and it turned out that it has the jars for the CS agent 4.3.0. However, I also checked the systemvm.iso that is in the xen hosts in /usr/share/xcp/packages/iso/. That .iso also has the jars for the 4.3.0 agent. So, I do not get why my systems VMs have the jar for the 4.1.1 version. Can somebody explain me the process, like when the jars that are in the systemvm.iso are copied to the system vm? which scripts do that? is there any way to debug that process? I do not understand how the jars from 4.1.1 version are in the Systemvm of 4.3.0 version. On Wed, May 28, 2014 at 6:16 PM, Min Chen min.c...@citrix.com wrote: I don't know the exact cmd line to clear that, and I have always used XenCenter UI to do that, where clear tags in General tabs. Thanks -min On 5/28/14 2:11 PM, Rafael Weingartner rafaelweingart...@gmail.com wrote: by clear, you mean xe vdi-destroy uuid=vdi of systemvm.iso? So, I just need to stop the management servers, run that in every cluster that I have and everything should be fine? On Wed, May 28, 2014 at 5:42 PM, Min Chen min.c...@citrix.com wrote: You should clear old systemvm.iso from xen server so that new systemvm.iso built can be deployed there. Thanks -min On 5/28/14 12:42 PM, Rafael Weingartner rafaelweingart...@gmail.com wrote: Another interesting fact: All the jars, cloud-**.jar are label as if they were 4.1.1 version. Is that right? On Wed, May 28, 2014 at 4:01 PM, Rafael Weingartner rafaelweingart...@gmail.com wrote: Just an update. I have just checked my console proxy VM, which is also with -- in agent state at insfrastructureSystem VM page. The agente is running there, however its state is --. I also looked into the source code, and the class org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource is located in a jar called cloud-secondary-storage which is not in the directory /usr/local/cloud/systemvm that contains the jars used to run the agent. Neither in my SSVM nor in Console proxy VM that jar exist. I do not get, I cannot be the only one with this problem. It seems that this jar is missing into the system vm template. On Wed, May 28, 2014 at 2:45 PM, Rafael Weingartner rafaelweingart...@gmail.com wrote: thanks, I checked the /var/log/cloud/cloud.out, And I found this error: ERROR AgentShell:607 - Unable to start agent: Resource class not found: org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource due to: java.lang.ClassNotFoundException: org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource Unable to start agent: Resource class not found: org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource due to: java.lang.ClassNotFoundException: org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource It seems that there is a jar dependency missing. On Wed, May 28, 2014 at 2:31 PM, Min Chen min.c...@citrix.com wrote: Your UI indicates that agent is not running on your SSVM, it should show as 'Running', that is why your cloud.host does not have an entry for your new SSVM, thus we cannot find a remote host to send command to. Agent is a java code running inside your SSVM, you should see what error you encountered in starting agent in your ssvm from cloud.out file in SSVM log. Thanks -min On 5/28/14 10:20 AM, Rafael Weingartner rafaelweingart...@gmail.com wrote: What agent are you talking about? Is it an app that run into the SSVM? I am using xenserver and XCP as the hypervisor. I looked into the CS UI, infrastructureSystem VMs and the column that has some values about the agent-state has a -- in it. Is it normal? At the end, should the SSVM have an entry into the host table? On Wed, May 28, 2014 at 2:05 PM, Min Chen min.c...@citrix.com wrote: Check if agent is running your ssvm. Thanks -min On 5/28/14 7:26 AM, Rafael Weingartner rafaelweingart...@gmail.com wrote: Hi all, sorry, to bother you again with this thread. Could at least someone that has the CS 4.3.0 deployed try to download a volume and/or a template? Could someone also
Re: [ACS 4.3] listUsageRecords API bug related to CLOUDSTACK-6472
H Hiroki,
those calls are for ServiceOfferingVO not for VMInstanceVO. So they
are not the same issue but that doesn't mean that we shouldn't those
the be counted when deleted either.
On Thu, May 29, 2014 at 12:11 PM, Hiroki Ohashi hiroki.s...@gmail.com wrote:
Hi Daan, Rajani
I looked at a code of master and 4.4 branch. findById is used at line
3031 of master branch and line 3299 of 4.4 branch, so I think this
leads to an same problem.
The code snippets of master and 4.4 branch are below.
[master] server/src/com/cloud/api/ApiResponseHelper.java
2987 @Override
2988 public UsageRecordResponse createUsageResponse(Usage usageRecord)
{
2989 UsageRecordResponse usageRecResponse = new
UsageRecordResponse();
2990
2991 Account account =
ApiDBUtils.findAccountById(usageRecord.getAccountId());
2992 if (account.getType() == Account.ACCOUNT_TYPE_PROJECT) {
2993 //find the project
2994 Project project =
ApiDBUtils.findProjectByProjectAccountId(account.getId());
2995 usageRecResponse.setProjectId(project.getUuid());
2996 usageRecResponse.setProjectName(project.getName());
2997 } else {
2998 usageRecResponse.setAccountId(account.getUuid());
2999 usageRecResponse.setAccountName(account.getAccountName());
3000 }
3001
3002 Domain domain =
ApiDBUtils.findDomainById(usageRecord.getDomainId());
3003 if (domain != null) {
3004 usageRecResponse.setDomainId(domain.getUuid());
3005 }
3006
3007 if (usageRecord.getZoneId() != null) {
3008 DataCenter zone =
ApiDBUtils.findZoneById(usageRecord.getZoneId());
3009 if (zone != null) {
3010 usageRecResponse.setZoneId(zone.getUuid());
3011 }
3012 }
3013 usageRecResponse.setDescription(usageRecord.getDescription());
3014 usageRecResponse.setUsage(usageRecord.getUsageDisplay());
3015 usageRecResponse.setUsageType(usageRecord.getUsageType());
3016 if (usageRecord.getVmInstanceId() != null) {
3017 VMInstanceVO vm =
_entityMgr.findByIdIncludingRemoved(VMInstanceVO.class,
usageRecord.getVmInstanceId());
3018 if (vm != null) {
3019 usageRecResponse.setVirtualMachineId(vm.getUuid());
3020 }
3021 }
3022 usageRecResponse.setVmName(usageRecord.getVmName());
3023 if (usageRecord.getTemplateId() != null) {
3024 VMTemplateVO template =
ApiDBUtils.findTemplateById(usageRecord.getTemplateId());
3025 if (template != null) {
3026 usageRecResponse.setTemplateId(template.getUuid());
3027 }
3028 }
3029
3030 if (usageRecord.getUsageType() ==
UsageTypes.RUNNING_VM || usageRecord.getUsageType() ==
UsageTypes.ALLOCATED_VM) {
3031 ServiceOfferingVO svcOffering =
_entityMgr.findById(ServiceOfferingVO.class,
usageRecord.getOfferingId().toString());
3032 //Service Offering Id
3033 usageRecResponse.setOfferingId(svcOffering.getUuid());
3034 //VM Instance ID
3035 VMInstanceVO vm =
_entityMgr.findByIdIncludingRemoved(VMInstanceVO.class,
usageRecord.getUsageId().toString());
3036 if (vm != null) {
3037 usageRecResponse.setUsageId(vm.getUuid());
3038 }
3039 //Hypervisor Type
3040 usageRecResponse.setType(usageRecord.getType());
3041
[ACS 4.4] server/src/com/cloud/api/ApiResponseHelper.java
3255 @Override
3256 public UsageRecordResponse createUsageResponse(Usage usageRecord)
{
3257 UsageRecordResponse usageRecResponse = new
UsageRecordResponse();
3258
3259 Account account =
ApiDBUtils.findAccountById(usageRecord.getAccountId());
3260 if (account.getType() == Account.ACCOUNT_TYPE_PROJECT) {
3261 //find the project
3262 Project project =
ApiDBUtils.findProjectByProjectAccountId(account.getId());
3263 usageRecResponse.setProjectId(project.getUuid());
3264 usageRecResponse.setProjectName(project.getName());
3265 } else {
3266 usageRecResponse.setAccountId(account.getUuid());
3267 usageRecResponse.setAccountName(account.getAccountName());
3268 }
3269
3270 Domain domain =
ApiDBUtils.findDomainById(usageRecord.getDomainId());
3271 if (domain != null) {
3272 usageRecResponse.setDomainId(domain.getUuid());
3273 }
3274
3275 if (usageRecord.getZoneId() != null) {
3276 DataCenter zone =
RE: [DISCUSS] Brocade network plugin to orchestrate Brocade VCS cluster for CloudStack 4.5
Hi, Can you please review the proposal and let me know if I need to add anything else here? Thanks Regards, Ritu S. -Original Message- From: Ritu Sabharwal [mailto:rsabh...@brocade.com] Sent: Tuesday, May 27, 2014 10:34 AM To: dev@cloudstack.apache.org Subject: RE: [DISCUSS] Brocade network plugin to orchestrate Brocade VCS cluster for CloudStack 4.5 We are targeting this for CloudStack 4.5 release. Thanks Regards, Ritu S. -Original Message- From: Ritu Sabharwal [mailto:rsabh...@brocade.com] Sent: Friday, May 23, 2014 11:59 AM To: dev@cloudstack.apache.org Cc: Prakash Kaligotla Subject: [DISCUSS] Brocade network plugin to orchestrate Brocade VCS cluster Hi CS Developers, I am Ritu Sabharwal from Brocade Communications Systems. I am leading an effort to implement CloudStack Network Plugin ( named Brocade VCS plugin) to orchestrate Brocade VCS cluster. We are using 4.3 as the base for development. Initially, the plugin will focus on L2 services. The plugin would automatically orchestrate Brocade's VCS cluster when VMs are created and attached to Network. The tenant isolation is provided via VLAN. When Isolated networks are created from CloudStack and allocated VLAN, the same VLANs need to be propagated to the VCS cluster as well, so that when a VLAN-tagged packet arrives on a switch-port, the switch know which ports to flood the packet. The Brocade VCS Plugin will orchestrate VCS directly using NETCONF. In order to find the switch-ports that are connected to the hypervisor hosts, the plugin would implement the Pluggable interface and expose Pluggable service API for the admin to provide the traffic-label to switch-port mapping. We will write a NetworkGuru and override the implement() method to: 1.Configure a VLAN interface on VCS. 2.Configure the interface port on VCS. 3.Configure VLAN membership on the interfaces. Please provide comments and feedback for this proposal. Thanks Regards, Ritu S.
Re: [ANNOUNCE] Saksham Srivastava as committer
welcome Saksham, go get On Thu, May 29, 2014 at 4:58 PM, Marcus shadow...@gmail.com wrote: Good job! On Thu, May 29, 2014 at 8:49 AM, Rayees Namathponnan rayees.namathpon...@citrix.com wrote: Congrats Saksham. Regards, Rayees -Original Message- From: Sailaja Mada [mailto:sailaja.m...@citrix.com] Sent: Thursday, May 29, 2014 1:49 AM To: dev@cloudstack.apache.org Subject: RE: [ANNOUNCE] Saksham Srivastava as committer Congratulations Saksham. -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: 29 May 2014 12:18 To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC -- Daan
Re: seeing Unknown parameters : ctxdetails for addResourceDetail/removeResourceDetail
Antonio - Can you please remove this worker ? I had filed a bug https://issues.apache.org/jira/browse/CLOUDSTACK-6658 for the same Thanks, -Nitin On 29/05/14 5:06 AM, Santhosh Edukulla santhosh.eduku...@citrix.com wrote: We still see Unknown parameters... huge number of logs in server log. May be, we can make this as configurable or dump to some other log say misc log, if mandatory params are not sent as per request, dump to the log and return, if arg types and arguments as per validation are wrong, then dump. But dumping every unknown param, real issues get lost with these huge log set rolling when debugging. Regards, Santhosh From: Nitin Mehta [nitin.me...@citrix.com] Sent: Monday, May 19, 2014 2:42 AM To: Antonio Fornié Casarrubios; cloudstack Subject: Re: seeing Unknown parameters : ctxdetails for addResourceDetail/removeResourceDetail Thanks Anotnio. That’s what I have been saying from the beginning. IMHO, I don’t see much value in having this, but I am really concerned with the performance of the apis especially in production setups. For this reason can we please remove this worker or at the very least have a setting to not have it turned on by default ? -Nitin From: Antonio Fornié Casarrubios antonio.for...@gmail.commailto:antonio.for...@gmail.com Date: Sunday 18 May 2014 4:22 PM To: cloudstack dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Cc: Nitin Mehta nitin.me...@citrix.commailto:nitin.me...@citrix.com Subject: Re: seeing Unknown parameters : ctxdetails for addResourceDetail/removeResourceDetail If the parameter is correct then it should not be in the logs as unknown. And so it should be added to the worker in the list of parameters that the worker will never blame. That is the fix. Right? Perhaps it is not considered good that everytime a new parameter is added to the api requests it has to be included in the worker. In that case then perhaps it's better to just completely remove the worker itself. Thansk, cheers Antonio El 16/05/2014 23:21, Min Chen min.c...@citrix.commailto:min.c...@citrix.com escribió: Ctxdetails complained in your warning log is one of internal parameters added by ApiDispatcher, and is not publicly presented in the API Cmd class. For those parameters, they are not errors in the request and nothing to be fixed. Thanks -min On 5/14/14 12:46 AM, Antonio Fornié Casarrubios antonio.for...@gmail.commailto:antonio.for...@gmail.com wrote: The errors in the requests are created by these well known clients, that's why they should be fixed. It's not that the admin misspelled a param, it's more that the code that creates the requests (the js in the web ui, cloudmonkey, Marvin or any other...) Cheers antonio 2014-05-14 3:05 GMT+02:00 Nitin Mehta nitin.me...@citrix.commailto:nitin.me...@citrix.com: Daan - MS logs are visible only to the admin and not a general user. So are you saying this is for admin to debug in case he misspelled a param ? I feel that this shouldn’t be ON by default and whether such logic should be part of CS core ? I also find it difficult to understand that in production the admin would commit such basic mistakes. I am assuming that he/she would be a power user and would be using well known clients - say cmd line or UI to fire apis against CS. Thanks, -Nitin On 13/05/14 1:58 PM, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: It is usefull for users that misspell a parameter and expect behavior related to it. not just in development. On Tue, May 13, 2014 at 7:24 PM, Nitin Mehta nitin.me...@citrix.commailto:nitin.me...@citrix.com wrote: I introduced the parameter ctxdetails which carries all the context details (currently all the first class entities and their corresponding interface mapping). This would be done for each of the api and hence seen for all apis. I saw the code in ParamGenericValidationWorker and will fix this. Filed a bug CLOUDSTACK-6658 But I am curious why we have this code at all ? It checks whether the params passed for the api are an exact match (nothing more nothing less) to the params we expect and if not throws only a warning as seen below. While it might be good for a developer setup it decreases the performance for production systems I believe. Thanks, -Nitin On 13/05/14 3:01 AM, Koushik Das koushik@citrix.commailto:koushik@citrix.com wrote: I am seeing the same for many commands. So this is not specific to add/removeResourceDetail 2014-05-09 18:17:39,477 WARN [c.c.a.d.ParamGenericValidationWorker] (API-Job-Executor-24:job-28 ctx-6eaab5d7) Received unknown parameters for command updateNetworkServiceProvider. Unknown parameters : ctxdetails 2014-05-09 18:17:42,584 WARN [c.c.a.d.ParamGenericValidationWorker] (API-Job-Executor-25:job-29 ctx-9c9f87f4) Received unknown parameters for command updatePhysicalNetwork. Unknown parameters : ctxdetails 2014-05-12
Re: seeing Unknown parameters : ctxdetails for addResourceDetail/removeResourceDetail
If removing the worker means that unknown parameters are never logged i am -1 removing it. On Thu, May 29, 2014 at 7:25 PM, Nitin Mehta nitin.me...@citrix.com wrote: Antonio - Can you please remove this worker ? I had filed a bug https://issues.apache.org/jira/browse/CLOUDSTACK-6658 for the same Thanks, -Nitin On 29/05/14 5:06 AM, Santhosh Edukulla santhosh.eduku...@citrix.com wrote: We still see Unknown parameters... huge number of logs in server log. May be, we can make this as configurable or dump to some other log say misc log, if mandatory params are not sent as per request, dump to the log and return, if arg types and arguments as per validation are wrong, then dump. But dumping every unknown param, real issues get lost with these huge log set rolling when debugging. Regards, Santhosh From: Nitin Mehta [nitin.me...@citrix.com] Sent: Monday, May 19, 2014 2:42 AM To: Antonio Fornié Casarrubios; cloudstack Subject: Re: seeing Unknown parameters : ctxdetails for addResourceDetail/removeResourceDetail Thanks Anotnio. That’s what I have been saying from the beginning. IMHO, I don’t see much value in having this, but I am really concerned with the performance of the apis especially in production setups. For this reason can we please remove this worker or at the very least have a setting to not have it turned on by default ? -Nitin From: Antonio Fornié Casarrubios antonio.for...@gmail.commailto:antonio.for...@gmail.com Date: Sunday 18 May 2014 4:22 PM To: cloudstack dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Cc: Nitin Mehta nitin.me...@citrix.commailto:nitin.me...@citrix.com Subject: Re: seeing Unknown parameters : ctxdetails for addResourceDetail/removeResourceDetail If the parameter is correct then it should not be in the logs as unknown. And so it should be added to the worker in the list of parameters that the worker will never blame. That is the fix. Right? Perhaps it is not considered good that everytime a new parameter is added to the api requests it has to be included in the worker. In that case then perhaps it's better to just completely remove the worker itself. Thansk, cheers Antonio El 16/05/2014 23:21, Min Chen min.c...@citrix.commailto:min.c...@citrix.com escribió: Ctxdetails complained in your warning log is one of internal parameters added by ApiDispatcher, and is not publicly presented in the API Cmd class. For those parameters, they are not errors in the request and nothing to be fixed. Thanks -min On 5/14/14 12:46 AM, Antonio Fornié Casarrubios antonio.for...@gmail.commailto:antonio.for...@gmail.com wrote: The errors in the requests are created by these well known clients, that's why they should be fixed. It's not that the admin misspelled a param, it's more that the code that creates the requests (the js in the web ui, cloudmonkey, Marvin or any other...) Cheers antonio 2014-05-14 3:05 GMT+02:00 Nitin Mehta nitin.me...@citrix.commailto:nitin.me...@citrix.com: Daan - MS logs are visible only to the admin and not a general user. So are you saying this is for admin to debug in case he misspelled a param ? I feel that this shouldn’t be ON by default and whether such logic should be part of CS core ? I also find it difficult to understand that in production the admin would commit such basic mistakes. I am assuming that he/she would be a power user and would be using well known clients - say cmd line or UI to fire apis against CS. Thanks, -Nitin On 13/05/14 1:58 PM, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: It is usefull for users that misspell a parameter and expect behavior related to it. not just in development. On Tue, May 13, 2014 at 7:24 PM, Nitin Mehta nitin.me...@citrix.commailto:nitin.me...@citrix.com wrote: I introduced the parameter ctxdetails which carries all the context details (currently all the first class entities and their corresponding interface mapping). This would be done for each of the api and hence seen for all apis. I saw the code in ParamGenericValidationWorker and will fix this. Filed a bug CLOUDSTACK-6658 But I am curious why we have this code at all ? It checks whether the params passed for the api are an exact match (nothing more nothing less) to the params we expect and if not throws only a warning as seen below. While it might be good for a developer setup it decreases the performance for production systems I believe. Thanks, -Nitin On 13/05/14 3:01 AM, Koushik Das koushik@citrix.commailto:koushik@citrix.com wrote: I am seeing the same for many commands. So this is not specific to add/removeResourceDetail 2014-05-09 18:17:39,477 WARN [c.c.a.d.ParamGenericValidationWorker] (API-Job-Executor-24:job-28 ctx-6eaab5d7) Received unknown parameters for command updateNetworkServiceProvider. Unknown parameters : ctxdetails 2014-05-09 18:17:42,584 WARN
RE: Feature Frezee date for 4.5 release.
Hi Daan, We are tracking to deliver our plugin (Brocade Network plugin for VDX switches) as per earlier communication of feature freeze for 4.5 release on mid-August. Based on your proposal for moving in the code freeze to mid-June is too early for us to provide the support for this release. I request to keep the timelines to mid-August so that we can provide VDX support from Brocade in 4.5 release. Thanks Regards, Ritu S. -Original Message- From: Ritu Sabharwal [mailto:rsabh...@brocade.com] Sent: Monday, May 19, 2014 10:32 AM To: dev@cloudstack.apache.org Cc: Alex Huang Subject: RE: Feature Frezee date for 4.5 release. Thanks Daan! I will send a proposal email soon for the plugin soon to the mailing list . Thanks Regards, Ritu S. -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Saturday, May 17, 2014 2:39 AM To: dev Cc: Alex Huang Subject: Re: Feature Frezee date for 4.5 release. 4.4 ffd + 4m = about half august On Sat, May 17, 2014 at 4:26 AM, Ritu Sabharwal rsabh...@brocade.com wrote: Hi Alex, What is the Feature freeze date for 4.5 release? We are planning for a plugin so wanted to make our project plan accordingly. Thanks regards, Ritu S. -- Daan
Re: Feature Frezee date for 4.5 release.
Good reason, and I would certainly retract my proposal if it wouldn't mean that a lot of new features will come in last minute. You won't have to be done earlier. So let me amend my proposal On Thu, May 29, 2014 at 7:30 PM, Ritu Sabharwal rsabh...@brocade.com wrote: Hi Daan, We are tracking to deliver our plugin (Brocade Network plugin for VDX switches) as per earlier communication of feature freeze for 4.5 release on mid-August. Based on your proposal for moving in the code freeze to mid-June is too early for us to provide the support for this release. I request to keep the timelines to mid-August so that we can provide VDX support from Brocade in 4.5 release. Thanks Regards, Ritu S. -Original Message- From: Ritu Sabharwal [mailto:rsabh...@brocade.com] Sent: Monday, May 19, 2014 10:32 AM To: dev@cloudstack.apache.org Cc: Alex Huang Subject: RE: Feature Frezee date for 4.5 release. Thanks Daan! I will send a proposal email soon for the plugin soon to the mailing list . Thanks Regards, Ritu S. -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Saturday, May 17, 2014 2:39 AM To: dev Cc: Alex Huang Subject: Re: Feature Frezee date for 4.5 release. 4.4 ffd + 4m = about half august On Sat, May 17, 2014 at 4:26 AM, Ritu Sabharwal rsabh...@brocade.com wrote: Hi Alex, What is the Feature freeze date for 4.5 release? We are planning for a plugin so wanted to make our project plan accordingly. Thanks regards, Ritu S. -- Daan -- Daan
Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze
Seeing what objections there might be I want to amend my proposal to 1. move forward feature freeze not on the coming but on the next release. 2. set feature proposal dealine for the coming release on 19th of June flames? other thoughts? Daan On Wed, May 28, 2014 at 8:17 AM, Ritu Sabharwal rsabh...@brocade.com wrote: Thanks Daan for the clarification! -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Tuesday, May 27, 2014 1:56 PM To: dev Subject: Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze What I mean is that to prevent the date of oct '14 moving we need to move the feature freeze forward. so we have more time to create the release. On Tue, May 27, 2014 at 10:45 PM, Ritu Sabharwal rsabh...@brocade.com wrote: When you say release schedule shift, does it mean 4.5 release target is moved from Oct '14 to a forward date? Thanks Regards, Ritu S. -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Monday, May 26, 2014 5:26 AM To: dev Subject: [ACS45][ACS50][PROPOSAL] move forward feature freeze LS, When I seeing once again our release schedule shift, I think we have no option but to move feature freeze for the next release forward. This is the only way it seems we can reduce the complexity of the total sum of changes. Therefore it is the only way we can prevent lapsing even more in time without risking reduced quality of our next release. So I propose to move feature freeze forward by a month to be at the 19th of June (instead of July). I don't think we need to strictly move code freeze forward as well but vigilance onto added features will be necessary. -- Daan -- Daan -- Daan
RE: Feature Frezee date for 4.5 release.
Hi Daan, Read your amended proposal. Just to clarify, does it mean the feature proposal deadline is 19th June and the feature code complete, testing and merging to master branch is mid-August? Thanks Regards, Ritu S. -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Thursday, May 29, 2014 10:41 AM To: dev Cc: Alex Huang; Prakash Kaligotla Subject: Re: Feature Frezee date for 4.5 release. Good reason, and I would certainly retract my proposal if it wouldn't mean that a lot of new features will come in last minute. You won't have to be done earlier. So let me amend my proposal On Thu, May 29, 2014 at 7:30 PM, Ritu Sabharwal rsabh...@brocade.com wrote: Hi Daan, We are tracking to deliver our plugin (Brocade Network plugin for VDX switches) as per earlier communication of feature freeze for 4.5 release on mid-August. Based on your proposal for moving in the code freeze to mid-June is too early for us to provide the support for this release. I request to keep the timelines to mid-August so that we can provide VDX support from Brocade in 4.5 release. Thanks Regards, Ritu S. -Original Message- From: Ritu Sabharwal [mailto:rsabh...@brocade.com] Sent: Monday, May 19, 2014 10:32 AM To: dev@cloudstack.apache.org Cc: Alex Huang Subject: RE: Feature Frezee date for 4.5 release. Thanks Daan! I will send a proposal email soon for the plugin soon to the mailing list . Thanks Regards, Ritu S. -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Saturday, May 17, 2014 2:39 AM To: dev Cc: Alex Huang Subject: Re: Feature Frezee date for 4.5 release. 4.4 ffd + 4m = about half august On Sat, May 17, 2014 at 4:26 AM, Ritu Sabharwal rsabh...@brocade.com wrote: Hi Alex, What is the Feature freeze date for 4.5 release? We are planning for a plugin so wanted to make our project plan accordingly. Thanks regards, Ritu S. -- Daan -- Daan
Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze
Perhaps we need to review/replace the release plan as a whole, find something that will get us on track and keep us on track. On Thu, May 29, 2014 at 11:45 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Seeing what objections there might be I want to amend my proposal to 1. move forward feature freeze not on the coming but on the next release. 2. set feature proposal dealine for the coming release on 19th of June flames? other thoughts? Daan On Wed, May 28, 2014 at 8:17 AM, Ritu Sabharwal rsabh...@brocade.com wrote: Thanks Daan for the clarification! -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Tuesday, May 27, 2014 1:56 PM To: dev Subject: Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze What I mean is that to prevent the date of oct '14 moving we need to move the feature freeze forward. so we have more time to create the release. On Tue, May 27, 2014 at 10:45 PM, Ritu Sabharwal rsabh...@brocade.com wrote: When you say release schedule shift, does it mean 4.5 release target is moved from Oct '14 to a forward date? Thanks Regards, Ritu S. -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Monday, May 26, 2014 5:26 AM To: dev Subject: [ACS45][ACS50][PROPOSAL] move forward feature freeze LS, When I seeing once again our release schedule shift, I think we have no option but to move feature freeze for the next release forward. This is the only way it seems we can reduce the complexity of the total sum of changes. Therefore it is the only way we can prevent lapsing even more in time without risking reduced quality of our next release. So I propose to move feature freeze forward by a month to be at the 19th of June (instead of July). I don't think we need to strictly move code freeze forward as well but vigilance onto added features will be necessary. -- Daan -- Daan -- Daan
Re: [ANNOUNCE] Saksham Srivastava as committer
Congrats Saksham :) On 28/05/14 11:47 PM, sebgoa run...@gmail.com wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
Re: Feature Frezee date for 4.5 release.
feature should be done (in it's branch) by 19th july. merging and fixing issues may take to mid august. On Thu, May 29, 2014 at 8:08 PM, Ritu Sabharwal rsabh...@brocade.com wrote: Hi Daan, Read your amended proposal. Just to clarify, does it mean the feature proposal deadline is 19th June and the feature code complete, testing and merging to master branch is mid-August? Thanks Regards, Ritu S. -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Thursday, May 29, 2014 10:41 AM To: dev Cc: Alex Huang; Prakash Kaligotla Subject: Re: Feature Frezee date for 4.5 release. Good reason, and I would certainly retract my proposal if it wouldn't mean that a lot of new features will come in last minute. You won't have to be done earlier. So let me amend my proposal On Thu, May 29, 2014 at 7:30 PM, Ritu Sabharwal rsabh...@brocade.com wrote: Hi Daan, We are tracking to deliver our plugin (Brocade Network plugin for VDX switches) as per earlier communication of feature freeze for 4.5 release on mid-August. Based on your proposal for moving in the code freeze to mid-June is too early for us to provide the support for this release. I request to keep the timelines to mid-August so that we can provide VDX support from Brocade in 4.5 release. Thanks Regards, Ritu S. -Original Message- From: Ritu Sabharwal [mailto:rsabh...@brocade.com] Sent: Monday, May 19, 2014 10:32 AM To: dev@cloudstack.apache.org Cc: Alex Huang Subject: RE: Feature Frezee date for 4.5 release. Thanks Daan! I will send a proposal email soon for the plugin soon to the mailing list . Thanks Regards, Ritu S. -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Saturday, May 17, 2014 2:39 AM To: dev Cc: Alex Huang Subject: Re: Feature Frezee date for 4.5 release. 4.4 ffd + 4m = about half august On Sat, May 17, 2014 at 4:26 AM, Ritu Sabharwal rsabh...@brocade.com wrote: Hi Alex, What is the Feature freeze date for 4.5 release? We are planning for a plugin so wanted to make our project plan accordingly. Thanks regards, Ritu S. -- Daan -- Daan -- Daan
Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze
That is what I want with this thread, yes. Please counter propose or amend as you like. On Thu, May 29, 2014 at 8:11 PM, Marcus shadow...@gmail.com wrote: Perhaps we need to review/replace the release plan as a whole, find something that will get us on track and keep us on track. On Thu, May 29, 2014 at 11:45 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Seeing what objections there might be I want to amend my proposal to 1. move forward feature freeze not on the coming but on the next release. 2. set feature proposal dealine for the coming release on 19th of June flames? other thoughts? Daan On Wed, May 28, 2014 at 8:17 AM, Ritu Sabharwal rsabh...@brocade.com wrote: Thanks Daan for the clarification! -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Tuesday, May 27, 2014 1:56 PM To: dev Subject: Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze What I mean is that to prevent the date of oct '14 moving we need to move the feature freeze forward. so we have more time to create the release. On Tue, May 27, 2014 at 10:45 PM, Ritu Sabharwal rsabh...@brocade.com wrote: When you say release schedule shift, does it mean 4.5 release target is moved from Oct '14 to a forward date? Thanks Regards, Ritu S. -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Monday, May 26, 2014 5:26 AM To: dev Subject: [ACS45][ACS50][PROPOSAL] move forward feature freeze LS, When I seeing once again our release schedule shift, I think we have no option but to move feature freeze for the next release forward. This is the only way it seems we can reduce the complexity of the total sum of changes. Therefore it is the only way we can prevent lapsing even more in time without risking reduced quality of our next release. So I propose to move feature freeze forward by a month to be at the 19th of June (instead of July). I don't think we need to strictly move code freeze forward as well but vigilance onto added features will be necessary. -- Daan -- Daan -- Daan -- Daan
Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze
In an effort to help keep our releases from getting out of hand, I think we should consider moving the Feature Proposal deadline up, as well. My main concern is that many people have three CloudStack-related threads executing right now, though: 1) People are still testing 4.4. 2) People are developing for 4.5. 3) People are now expected to think in detail earlier about the features they'd like to place in 4.6. On Thu, May 29, 2014 at 12:58 PM, Daan Hoogland daan.hoogl...@gmail.comwrote: That is what I want with this thread, yes. Please counter propose or amend as you like. On Thu, May 29, 2014 at 8:11 PM, Marcus shadow...@gmail.com wrote: Perhaps we need to review/replace the release plan as a whole, find something that will get us on track and keep us on track. On Thu, May 29, 2014 at 11:45 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Seeing what objections there might be I want to amend my proposal to 1. move forward feature freeze not on the coming but on the next release. 2. set feature proposal dealine for the coming release on 19th of June flames? other thoughts? Daan On Wed, May 28, 2014 at 8:17 AM, Ritu Sabharwal rsabh...@brocade.com wrote: Thanks Daan for the clarification! -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Tuesday, May 27, 2014 1:56 PM To: dev Subject: Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze What I mean is that to prevent the date of oct '14 moving we need to move the feature freeze forward. so we have more time to create the release. On Tue, May 27, 2014 at 10:45 PM, Ritu Sabharwal rsabh...@brocade.com wrote: When you say release schedule shift, does it mean 4.5 release target is moved from Oct '14 to a forward date? Thanks Regards, Ritu S. -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Monday, May 26, 2014 5:26 AM To: dev Subject: [ACS45][ACS50][PROPOSAL] move forward feature freeze LS, When I seeing once again our release schedule shift, I think we have no option but to move feature freeze for the next release forward. This is the only way it seems we can reduce the complexity of the total sum of changes. Therefore it is the only way we can prevent lapsing even more in time without risking reduced quality of our next release. So I propose to move feature freeze forward by a month to be at the 19th of June (instead of July). I don't think we need to strictly move code freeze forward as well but vigilance onto added features will be necessary. -- Daan -- Daan -- Daan -- Daan -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloudhttp://solidfire.com/solution/overview/?video=play *™*
[ACS4.4] Cherry pick 63090434b1cb4e7b87f0e024fbbc644faee863f7
Hi Daan, Can you please cherry-pick 63090434b1cb4e7b87f0e024fbbc644faee863f7 to 4.4, system template always create with name master instead of current git branch Regards, Rayees
RE: [ANNOUNCE] Saksham Srivastava as committer
Congrats Saksham -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Wednesday, May 28, 2014 11:48 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
License to be signed for contributing to CloudStack
Hi, I wanted to know if there are any license to be signed by individuals or corporates to contribute to CloudStack. Thanks Regards, Ritu S.
Re: License to be signed for contributing to CloudStack
Ritu, Many companies donate their code to apache cloudstack. There is no license to sign, however there is Intellectual Property Clearance process you need to go through. From what i recall, you describe what it is you would like to donate, we put it to a vote and once approved the code is merged. Here is an example http://osdir.com/ml/general.incubator.apache.org/2013-01/msg00309.html More folks can chime in and explain. Regards ilya On 5/29/14, 3:10 PM, Ritu Sabharwal wrote: Hi, I wanted to know if there are any license to be signed by individuals or corporates to contribute to CloudStack. Thanks Regards, Ritu S.
Re: License to be signed for contributing to CloudStack
On Thu, May 29, 2014 at 6:10 PM, Ritu Sabharwal rsabh...@brocade.com wrote: Hi, I wanted to know if there are any license to be signed by individuals or corporates to contribute to CloudStack. Thanks Regards, Ritu S. So, it depends. If you or your company is donating a significant contribution of code that was developed outside of the project; you probably need to go through IP Clearance. That typically involves a Software Grant Agreement or Contributor License Agreement. If you or your company are donating code that was developed inside the project, you probably don't need to sign anything unless it's a very large contribution. Also note that committers must sign an individual contributor license agreement for their account to be created. --David
RE: [ANNOUNCE] Saksham Srivastava as committer
Congrats Saksham !! -Original Message- From: Vaibhav Gupta [mailto:vaibhav.gu...@citrix.com] Sent: Thursday, May 29, 2014 6:03 PM To: dev@cloudstack.apache.org Subject: RE: [ANNOUNCE] Saksham Srivastava as committer Congratulations Saksham.. Thanks, Vaibhav -Original Message- From: Sanjay Tripathi [mailto:sanjay.tripa...@citrix.com] Sent: 29 May 2014 15:39 To: dev@cloudstack.apache.org Subject: RE: [ANNOUNCE] Saksham Srivastava as committer Congratulations Saksham. --Sanjay -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, May 29, 2014 12:18 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
Re: [ANNOUNCE] Saksham Srivastava as committer
Congrats Saksham! Regards, Gaurav On Fri, May 30, 2014 at 9:28 AM, Sanjeev Neelarapu sanjeev.neelar...@citrix.com wrote: Congrats Saksham !! -Original Message- From: Vaibhav Gupta [mailto:vaibhav.gu...@citrix.com] Sent: Thursday, May 29, 2014 6:03 PM To: dev@cloudstack.apache.org Subject: RE: [ANNOUNCE] Saksham Srivastava as committer Congratulations Saksham.. Thanks, Vaibhav -Original Message- From: Sanjay Tripathi [mailto:sanjay.tripa...@citrix.com] Sent: 29 May 2014 15:39 To: dev@cloudstack.apache.org Subject: RE: [ANNOUNCE] Saksham Srivastava as committer Congratulations Saksham. --Sanjay -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, May 29, 2014 12:18 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
Re: Need help with simstack vagrant box
Thanks Sebastien for the clarification. Cheers, Madan On 29 May 2014 at 3:42:55 pm, sebgoa (run...@gmail.com) wrote: On May 29, 2014, at 11:48 AM, Madan Ganesh V madangan...@me.com wrote: Hello CloudStack forum, We are following the steps mentioned: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Create+config+management+recipes+to+install+CloudStack https://github.com/runseb/simstack to bring up a cloudstack dev instance. After running vagrant up and vagrant reload —provision command, we notice that cloud stack is not up yet! After SSH into the vagrant box, we notice that there is not cloudstack java process running. Has anyone brought simstack successfully? simstack is a side project of mine and by no means any type of official release of cloudstack. I just made a push to disable the ansible provisioning you are seeing (deploying wordpress), and revert to basic cloudstack source compilation using the bootstrap-ubuntu.sh script. So pull again and try it. Just have a look at that bash script if you want to figure out how to compile things. But basically you are on your own :) -Sebastien Here is the excerpts from the vagrant reload: == default: Attempting graceful shutdown of VM... == default: Clearing any previously set forwarded ports... == default: Clearing any previously set network interfaces... == default: Preparing network interfaces based on configuration... default: Adapter 1: nat == default: Forwarding ports... default: 8080 = 8080 (adapter 1) default: 8081 = 8081 (adapter 1) default: 7080 = 7080 (adapter 1) default: 8000 = 8000 (adapter 1) default: 80 = 8001 (adapter 1) default: 22 = (adapter 1) == default: Running 'pre-boot' VM customizations... == default: Booting VM... == default: Waiting for machine to boot. This may take a few minutes... default: SSH address: 127.0.0.1: default: SSH username: vagrant default: SSH auth method: private key default: Warning: Connection timeout. Retrying... default: Warning: Connection timeout. Retrying... default: Warning: Connection timeout. Retrying... default: Warning: Connection timeout. Retrying... == default: Machine booted and ready! == default: Checking for guest additions in VM... == default: Setting hostname... == default: Mounting shared folders... default: /srv = /Volumes/ActOnMagic/simstack/salt/roots default: /vagrant = /Volumes/ActOnMagic/simstack == default: Running provisioner: shell... default: Running: inline script == default: Running provisioner: ansible... ANSIBLE_FORCE_COLOR=true ANSIBLE_HOST_KEY_CHECKING=false PYTHONUNBUFFERED=1 ansible-playbook --private-key=/Users/madang/.vagrant.d/insecure_private_key --user=vagrant --limit='default' --inventory-file=/Vo …. TASK: [php-fpm | Copy php-fpm configuration] ** 127.0.0.1 ESTABLISH CONNECTION FOR USER: vagrant 127.0.0.1 EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o', 'ControlPersist=60s', '-o', 'ControlPath=/Users/madang/.ansible/cp/ansible-ssh-%h-%p-%r', '-o', 'StrictHostKeyChecking=no', '-o', 'Port=', '-o', 'IdentityFile=/Users/madang/.vagrant.d/insecure_private_key', '-o', 'KbdInteractiveAuthentication=no', '-o', 'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o', 'PasswordAuthentication=no', '-o', 'User=vagrant', '-o', 'ConnectTimeout=10', '127.0.0.1', /bin/sh -c 'mkdir -p $HOME/.ansible/tmp/ansible-tmp-1401356524.77-108295687200060 chmod a+rx $HOME/.ansible/tmp/ansible-tmp-1401356524.77-108295687200060 echo $HOME/.ansible/tmp/ansible-tmp-1401356524.77-108295687200060'] 127.0.0.1 EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o', 'ControlPersist=60s', '-o', 'ControlPath=/Users/madang/.ansible/cp/ansible-ssh-%h-%p-%r', '-o', 'StrictHostKeyChecking=no', '-o', 'Port=', '-o', 'IdentityFile=/Users/madang/.vagrant.d/insecure_private_key', '-o', 'KbdInteractiveAuthentication=no', '-o', 'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o', 'PasswordAuthentication=no', '-o', 'User=vagrant', '-o', 'ConnectTimeout=10', '127.0.0.1', u'/bin/sh -c \'sudo -k sudo -H -S -p [sudo via ansible, key=dyyespcdwcthzzkmglnauwbwpyujxupu] password: -u root /bin/sh -c \'\'\'echo SUDO-SUCCESS-dyyespcdwcthzzkmglnauwbwpyujxupu; rc=0; [ -r /etc/php-fpm.d/wordpress.conf ] || rc=2; [ -f /etc/php-fpm.d/wordpress.conf ] || rc=1; [ -d /etc/php-fpm.d/wordpress.conf ] echo 3 exit 0; (/usr/bin/md5sum /etc/php-fpm.d/wordpress.conf 2/dev/null) || (/sbin/md5sum -q /etc/php-fpm.d/wordpress.conf 2/dev/null) || (/usr/bin/digest -a md5 /etc/php-fpm.d/wordpress.conf 2/dev/null) || (/sbin/md5 -q /etc/php-fpm.d/wordpress.conf 2/dev/null) || (/usr/bin/md5 -n /etc/php-fpm.d/wordpress.conf 2/dev/null) || (/bin/md5 -q
RE: [ANNOUNCE] Saksham Srivastava as committer
Thanks everyone !! Regards, Saksham -Original Message- From: Gaurav Aradhye [mailto:gaurav.arad...@clogeny.com] Sent: Friday, May 30, 2014 9:35 AM To: dev@cloudstack.apache.org Subject: Re: [ANNOUNCE] Saksham Srivastava as committer Congrats Saksham! Regards, Gaurav On Fri, May 30, 2014 at 9:28 AM, Sanjeev Neelarapu sanjeev.neelar...@citrix.com wrote: Congrats Saksham !! -Original Message- From: Vaibhav Gupta [mailto:vaibhav.gu...@citrix.com] Sent: Thursday, May 29, 2014 6:03 PM To: dev@cloudstack.apache.org Subject: RE: [ANNOUNCE] Saksham Srivastava as committer Congratulations Saksham.. Thanks, Vaibhav -Original Message- From: Sanjay Tripathi [mailto:sanjay.tripa...@citrix.com] Sent: 29 May 2014 15:39 To: dev@cloudstack.apache.org Subject: RE: [ANNOUNCE] Saksham Srivastava as committer Congratulations Saksham. --Sanjay -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, May 29, 2014 12:18 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
Re: [ACS4.4] [Issue] Unable to create a autoscalevmprofile
Hi Daan,
I'm testing on 4.4-forward-iam branch.
Thanks
Meghna.
On Thu, May 29, 2014 at 6:56 PM, Daan Hoogland daan.hoogl...@gmail.com
wrote:
Megha,
in my current 4.4 line 411 of DeployVMCmd reads
if (accountId == null) {
hence it doesn't refer a pointer at that line.
which version are you using to get this:
java.lang.NullPointerException
at
org.apache.cloudstack.api.command.user.vm.DeployVMCmd.getEntityOwnerId(DeployVMCmd.java:411)
On Thu, May 29, 2014 at 12:53 PM, Meghna Kale meghna.k...@sungardas.com
wrote:
Hi All,
I was trying to create a autoscalevmprofile with a sample data for a test
case. Can anyone help me to know is there anything I'm missing in the
input
parameters ?
I get a nullpointer error is it due to the missing deployParams
parameter ?
I'm running this test on simulator.
self.account_1A = Account.create(
self.apiclient,
self.services[account1A],
admin=False,
domainid=self.domain_1.id
)
self.userapiclient_1A =
self.testClient.getUserApiClient(self.user_1A.username,
self.domain_1.name)
self.service_offering = ServiceOffering.create(
self.apiclient,
self.services[service_offering][small]
)
self.zone = get_zone(self.apiclient, testClient.getZoneForTests())
list_users = User.list(
self.apiclient,
listall=self.services[listall],
account=self.account_1A.name,
domainid=self.domain_1.id
)
self.template = get_template(self.apiclient, self.zone.id,
self.services[ostype])
counterparam = { snmpcommunity: public, snmpport: 161}
autoscalevm_profile_1A = Autoscale.createAutoscaleVmProfile(
self.userapiclient_1A,
serviceofferingid=self.service_offering.id,
zoneid=
self.zone.id,
templateid=
self.template.id,
autoscaleuserid=list_users[0].id,
destroyvmgraceperiod='100',
counterparam=counterparam
)
I get this error in the logs :
ERROR [c.c.a.ApiServer] (25349580@qtp-22625812-44:ctx-76e14380
ctx-e717232f
ctx-7cea9dc0) unhandled exception executing api command:
[Ljava.lang.String;@17c7c4d
java.lang.NullPointerException
at
org.apache.cloudstack.api.command.user.vm.DeployVMCmd.getEntityOwnerId(DeployVMCmd.java:411)
at
com.cloud.api.dispatch.ParamProcessWorker.doAccessChecks(ParamProcessWorker.java:227)
at
com.cloud.api.dispatch.ParamProcessWorker.processParameters(ParamProcessWorker.java:221)
at
com.cloud.api.dispatch.ParamProcessWorker.handle(ParamProcessWorker.java:93)
at
com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37)
at
com.cloud.network.as.AutoScaleManagerImpl.createAutoScaleVmProfile(AutoScaleManagerImpl.java:373)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy254.createAutoScaleVmProfile(Unknown
Source)
at
org.apache.cloudstack.api.command.user.autoscale.CreateAutoScaleVmProfileCmd.create(CreateAutoScaleVmProfileCmd.java:263)
