[jira] [Resolved] (CLOUDSTACK-7199) [Automation] test_multiple_ips_per_nic failng due to missing attributes
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Girish Shilamkar resolved CLOUDSTACK-7199.
--
Resolution: Fixed
> [Automation] test_multiple_ips_per_nic failng due to missing attributes
>
>
> Key: CLOUDSTACK-7199
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7199
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
>Priority: Critical
> Fix For: 4.5.0
>
>
> Below test cases failing in automation runs in vmware
> integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_network_restart_cleanup_false_3_VPC
> Error Message
> Error Message
> 'TestNetworkRules' object has no attribute 'vpc_off'
> >> begin captured stdout << -
> === TestName: test_add_static_nat_rule_3_VPC | Status : EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_add_static_nat_rule_3_VPC
> (integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
> STARTED : TC: test_add_static_nat_rule_3_VPC :::
> test_add_static_nat_rule_3_VPC
> (integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
> Payload: {'username':
> 'test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W',
> 'domainid': u'de3e8c70-16da-11e4-a7b2-52b2d980df8a', 'firstname': 'test',
> 'lastname': 'test', 'response': 'json', 'apiKey':
> u'xkp61NgHs4tG3PrK7WvtPKVU7Wd17aQ0zhZY1ku4LwqycZRISeJsJG-MrhjUaY-bfPcyxxIDpeIAItlm7RW2kQ',
> 'command': 'createAccount', 'accounttype': 0, 'signature':
> '1ecQbYqO6bDFi7aMhuKVMiMFKLA=', 'password': 'password', 'email':
> 'test-acco...@test.com'}
> test_add_static_nat_rule_3_VPC
> (integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
> Sending GET Cmd : createAccount===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.223.49.197
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?username=test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W&domainid=de3e8c70-16da-11e4-a7b2-52b2d980df8a&firstname=test&lastname=test&email=test-account%40test.com&apiKey=xkp61NgHs4tG3PrK7WvtPKVU7Wd17aQ0zhZY1ku4LwqycZRISeJsJG-MrhjUaY-bfPcyxxIDpeIAItlm7RW2kQ&command=createAccount&accounttype=0&signature=1ecQbYqO6bDFi7aMhuKVMiMFKLA%3D&password=password&response=json
> HTTP/1.1" 200 1734
> test_add_static_nat_rule_3_VPC
> (integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
> Response : {primarystorageavailable : u'Unlimited', domain : u'ROOT',
> domainid : u'de3e8c70-16da-11e4-a7b2-52b2d980df8a', vpclimit : u'Unlimited',
> iplimit : u'Unlimited', volumelimit : u'Unlimited', memorytotal : 0,
> secondarystorageavailable : u'Unlimited', vmtotal : 0, cputotal : 0, vpctotal
> : 0, id : u'de5493f9-9060-4130-bf07-c6f43c46e597', cpuavailable :
> u'Unlimited', snapshotlimit : u'Unlimited', networklimit : u'Unlimited',
> iptotal : 0, volumetotal : 0, projectlimit : u'Unlimited', state :
> u'enabled', networktotal : 0, accounttype : 0, networkavailable :
> u'Unlimited', primarystoragetotal : 0, templatelimit : u'Unlimited',
> snapshottotal : 0, templateavailable : u'Unlimited', vmlimit : u'Unlimited',
> vpcavailable : u'Unlimited', memoryavailable : u'Unlimited',
> secondarystoragetotal : 0, templatetotal : 0, projecttotal : 0, user :
> [{username :
> u'test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W',
> account :
> u'test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W',
> domainid : u'de3e8c70-16da-11e4-a7b2-52b2d980df8a', firstname : u'test',
> created : u'2014-07-29T05:54:32-0700', lastname : u'test', domain : u'ROOT',
> id : u'128e219b-d09e-471b-8fc7-87769f39c731', iscallerchilddomain : False,
> state : u'enabled', accounttype : 0, email : u'test-acco...@test.com',
> isdefault : False, accountid : u'de5493f9-9060-4130-bf07-c6f43c46e597'}],
> groups : [], projectavailable : u'Unlimited', isdefault : False,
> primarystoragelimit : u'Unlimited', secondarystoragelimit : u'Unlimited',
> volumeavailable : u'Unlimited', name :
> u'test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W',
> vmavailable : u'Unlimited', ipavailable : u'Unlimited', memorylimit :
> u'Unlimited', cpulimit : u'Unlimited', snapshotavailable : u'Unlimited'}
> test_add_static_nat_rule_3_VPC
> (integration.component.test_
[jira] [Assigned] (CLOUDSTACK-7199) [Automation] test_multiple_ips_per_nic failng due to missing attributes
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Girish Shilamkar reassigned CLOUDSTACK-7199:
Assignee: Girish Shilamkar
> [Automation] test_multiple_ips_per_nic failng due to missing attributes
>
>
> Key: CLOUDSTACK-7199
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7199
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
>Priority: Critical
> Fix For: 4.5.0
>
>
> Below test cases failing in automation runs in vmware
> integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_network_restart_cleanup_false_3_VPC
> Error Message
> Error Message
> 'TestNetworkRules' object has no attribute 'vpc_off'
> >> begin captured stdout << -
> === TestName: test_add_static_nat_rule_3_VPC | Status : EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_add_static_nat_rule_3_VPC
> (integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
> STARTED : TC: test_add_static_nat_rule_3_VPC :::
> test_add_static_nat_rule_3_VPC
> (integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
> Payload: {'username':
> 'test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W',
> 'domainid': u'de3e8c70-16da-11e4-a7b2-52b2d980df8a', 'firstname': 'test',
> 'lastname': 'test', 'response': 'json', 'apiKey':
> u'xkp61NgHs4tG3PrK7WvtPKVU7Wd17aQ0zhZY1ku4LwqycZRISeJsJG-MrhjUaY-bfPcyxxIDpeIAItlm7RW2kQ',
> 'command': 'createAccount', 'accounttype': 0, 'signature':
> '1ecQbYqO6bDFi7aMhuKVMiMFKLA=', 'password': 'password', 'email':
> 'test-acco...@test.com'}
> test_add_static_nat_rule_3_VPC
> (integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
> Sending GET Cmd : createAccount===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.223.49.197
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?username=test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W&domainid=de3e8c70-16da-11e4-a7b2-52b2d980df8a&firstname=test&lastname=test&email=test-account%40test.com&apiKey=xkp61NgHs4tG3PrK7WvtPKVU7Wd17aQ0zhZY1ku4LwqycZRISeJsJG-MrhjUaY-bfPcyxxIDpeIAItlm7RW2kQ&command=createAccount&accounttype=0&signature=1ecQbYqO6bDFi7aMhuKVMiMFKLA%3D&password=password&response=json
> HTTP/1.1" 200 1734
> test_add_static_nat_rule_3_VPC
> (integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
> Response : {primarystorageavailable : u'Unlimited', domain : u'ROOT',
> domainid : u'de3e8c70-16da-11e4-a7b2-52b2d980df8a', vpclimit : u'Unlimited',
> iplimit : u'Unlimited', volumelimit : u'Unlimited', memorytotal : 0,
> secondarystorageavailable : u'Unlimited', vmtotal : 0, cputotal : 0, vpctotal
> : 0, id : u'de5493f9-9060-4130-bf07-c6f43c46e597', cpuavailable :
> u'Unlimited', snapshotlimit : u'Unlimited', networklimit : u'Unlimited',
> iptotal : 0, volumetotal : 0, projectlimit : u'Unlimited', state :
> u'enabled', networktotal : 0, accounttype : 0, networkavailable :
> u'Unlimited', primarystoragetotal : 0, templatelimit : u'Unlimited',
> snapshottotal : 0, templateavailable : u'Unlimited', vmlimit : u'Unlimited',
> vpcavailable : u'Unlimited', memoryavailable : u'Unlimited',
> secondarystoragetotal : 0, templatetotal : 0, projecttotal : 0, user :
> [{username :
> u'test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W',
> account :
> u'test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W',
> domainid : u'de3e8c70-16da-11e4-a7b2-52b2d980df8a', firstname : u'test',
> created : u'2014-07-29T05:54:32-0700', lastname : u'test', domain : u'ROOT',
> id : u'128e219b-d09e-471b-8fc7-87769f39c731', iscallerchilddomain : False,
> state : u'enabled', accounttype : 0, email : u'test-acco...@test.com',
> isdefault : False, accountid : u'de5493f9-9060-4130-bf07-c6f43c46e597'}],
> groups : [], projectavailable : u'Unlimited', isdefault : False,
> primarystoragelimit : u'Unlimited', secondarystoragelimit : u'Unlimited',
> volumeavailable : u'Unlimited', name :
> u'test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W',
> vmavailable : u'Unlimited', ipavailable : u'Unlimited', memorylimit :
> u'Unlimited', cpulimit : u'Unlimited', snapshotavailable : u'Unlimited'}
> test_add_static_nat_rule_3_VPC
> (integration.co
[jira] [Commented] (CLOUDSTACK-7199) [Automation] test_multiple_ips_per_nic failng due to missing attributes
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078986#comment-14078986
]
ASF subversion and git services commented on CLOUDSTACK-7199:
-
Commit ec10e8db27e9f3a60a3d74053c5260d87616a3fa in cloudstack's branch
refs/heads/master from [~gpshilamkar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ec10e8d ]
CLOUDSTACK-7199: Fixed test_multiple_ips_per_nic.py test failures
> [Automation] test_multiple_ips_per_nic failng due to missing attributes
>
>
> Key: CLOUDSTACK-7199
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7199
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.5.0
>
>
> Below test cases failing in automation runs in vmware
> integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_network_restart_cleanup_false_3_VPC
> Error Message
> Error Message
> 'TestNetworkRules' object has no attribute 'vpc_off'
> >> begin captured stdout << -
> === TestName: test_add_static_nat_rule_3_VPC | Status : EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_add_static_nat_rule_3_VPC
> (integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
> STARTED : TC: test_add_static_nat_rule_3_VPC :::
> test_add_static_nat_rule_3_VPC
> (integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
> Payload: {'username':
> 'test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W',
> 'domainid': u'de3e8c70-16da-11e4-a7b2-52b2d980df8a', 'firstname': 'test',
> 'lastname': 'test', 'response': 'json', 'apiKey':
> u'xkp61NgHs4tG3PrK7WvtPKVU7Wd17aQ0zhZY1ku4LwqycZRISeJsJG-MrhjUaY-bfPcyxxIDpeIAItlm7RW2kQ',
> 'command': 'createAccount', 'accounttype': 0, 'signature':
> '1ecQbYqO6bDFi7aMhuKVMiMFKLA=', 'password': 'password', 'email':
> 'test-acco...@test.com'}
> test_add_static_nat_rule_3_VPC
> (integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
> Sending GET Cmd : createAccount===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.223.49.197
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?username=test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W&domainid=de3e8c70-16da-11e4-a7b2-52b2d980df8a&firstname=test&lastname=test&email=test-account%40test.com&apiKey=xkp61NgHs4tG3PrK7WvtPKVU7Wd17aQ0zhZY1ku4LwqycZRISeJsJG-MrhjUaY-bfPcyxxIDpeIAItlm7RW2kQ&command=createAccount&accounttype=0&signature=1ecQbYqO6bDFi7aMhuKVMiMFKLA%3D&password=password&response=json
> HTTP/1.1" 200 1734
> test_add_static_nat_rule_3_VPC
> (integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
> Response : {primarystorageavailable : u'Unlimited', domain : u'ROOT',
> domainid : u'de3e8c70-16da-11e4-a7b2-52b2d980df8a', vpclimit : u'Unlimited',
> iplimit : u'Unlimited', volumelimit : u'Unlimited', memorytotal : 0,
> secondarystorageavailable : u'Unlimited', vmtotal : 0, cputotal : 0, vpctotal
> : 0, id : u'de5493f9-9060-4130-bf07-c6f43c46e597', cpuavailable :
> u'Unlimited', snapshotlimit : u'Unlimited', networklimit : u'Unlimited',
> iptotal : 0, volumetotal : 0, projectlimit : u'Unlimited', state :
> u'enabled', networktotal : 0, accounttype : 0, networkavailable :
> u'Unlimited', primarystoragetotal : 0, templatelimit : u'Unlimited',
> snapshottotal : 0, templateavailable : u'Unlimited', vmlimit : u'Unlimited',
> vpcavailable : u'Unlimited', memoryavailable : u'Unlimited',
> secondarystoragetotal : 0, templatetotal : 0, projecttotal : 0, user :
> [{username :
> u'test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W',
> account :
> u'test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W',
> domainid : u'de3e8c70-16da-11e4-a7b2-52b2d980df8a', firstname : u'test',
> created : u'2014-07-29T05:54:32-0700', lastname : u'test', domain : u'ROOT',
> id : u'128e219b-d09e-471b-8fc7-87769f39c731', iscallerchilddomain : False,
> state : u'enabled', accounttype : 0, email : u'test-acco...@test.com',
> isdefault : False, accountid : u'de5493f9-9060-4130-bf07-c6f43c46e597'}],
> groups : [], projectavailable : u'Unlimited', isdefault : False,
> primarystoragelimit : u'Unlimited', secondarystoragelimit : u'Unlimited',
> volumeavailable : u'Unlimited', name :
> u'test-account-TestV
[jira] [Commented] (CLOUDSTACK-7200) [LDAP] importUsersCmd for a group fails incase any member of a group is not an user
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078982#comment-14078982 ] ASF subversion and git services commented on CLOUDSTACK-7200: - Commit 5fa2d1c7ca26d199f0dcd499db8db245c2593a5b in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5fa2d1c ] Fixed Bug: CLOUDSTACK-7200 [LDAP] importUsersCmd for a group fails incase any member of a group is not an user > [LDAP] importUsersCmd for a group fails incase any member of a group is not > an user > --- > > Key: CLOUDSTACK-7200 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7200 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > Labels: ldap > Fix For: 4.5.0 > > > If the group has all users, import is successful. > Import fails if the group has any member other than type 'user' -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7201) migrate volume with live migrate = true allows migration across cluster or fails with NPE
Devdeep Singh created CLOUDSTACK-7201: - Summary: migrate volume with live migrate = true allows migration across cluster or fails with NPE Key: CLOUDSTACK-7201 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7201 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Devdeep Singh Assignee: Devdeep Singh Priority: Critical migrate volume with livemigrate=true allows migrating the volume across clusters in case of Hyper-V. In case of XS, we are throwing an NPE although the migration correctly fails. Steps: = 0. Create a set up with at least 2 clusters 1. Deploy a VM with data disk 2. As admin, while VM is running migrate volume to another shared pool in another cluster (cloudmonkey) > migrate volume livemigrate=true storageid= > volumeid= Expected Result: This shouldn't be allowed, we should fail the API with proper error message, allowing us to migrate volume only to storage pool within the same cluster, unless it is a zone wide storage pool. (If we want to achieve across cluster migration, we should use migrateVitualMachine with storage live migration) Result in Hyper-V = We end up with the volume migrated to another cluster storage pool while the VM is running off the original cluster storage pool. We should not allow this to happen. Result in XS 6.2 Migration correctly fails with error message but we also throw an NPE. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7200) [LDAP] importUsersCmd for a group fails incase any member of a group is not an user
Rajani Karuturi created CLOUDSTACK-7200: --- Summary: [LDAP] importUsersCmd for a group fails incase any member of a group is not an user Key: CLOUDSTACK-7200 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7200 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Rajani Karuturi Assignee: Rajani Karuturi Fix For: 4.5.0 If the group has all users, import is successful. Import fails if the group has any member other than type 'user' -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-4986) Analysing and implementing Code Coverage for Integration Tests
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla closed CLOUDSTACK-4986. --- > Analysing and implementing Code Coverage for Integration Tests > -- > > Key: CLOUDSTACK-4986 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4986 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Infra >Reporter: Santhosh Kumar Edukulla >Assignee: Santhosh Kumar Edukulla > > Currently, we have facility to use and run sonar for analyzing code > coverage numbers for CS using unit tests. We need to enhance it to support > analysis for integration tests coverage as well. Basically, this will give > coverage numbers for both integration and unit tests. > 1.It seems we already have a code coverage numbers using sonar as below. It > currently shows only the numbers for unit tests. > https://analysis.apache.org/dashboard/index/100206 > 2. The below link has an explanation for using it for both for integration > and unit tests. > http://docs.codehaus.org/display/SONAR/Code+Coverage+by+Integration+Tests+for+Java+Project > 3. Many links suggests it has good decision coverage facility compared to > other coverage tools. > http://onlysoftware.wordpress.com/2012/12/19/code-coverage-tools-jacoco-cobertura-emma-comparison-in-sonar/ > Logging this bug to track this effort and changes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6910) Phase 1: tagging of test cases
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla resolved CLOUDSTACK-6910. - Resolution: Fixed > Phase 1: tagging of test cases > -- > > Key: CLOUDSTACK-6910 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6910 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Abhinandan Prateek >Assignee: Santhosh Kumar Edukulla >Priority: Critical > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6910) Phase 1: tagging of test cases
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla closed CLOUDSTACK-6910. --- > Phase 1: tagging of test cases > -- > > Key: CLOUDSTACK-6910 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6910 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Abhinandan Prateek >Assignee: Santhosh Kumar Edukulla >Priority: Critical > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-4986) Analysing and implementing Code Coverage for Integration Tests
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla resolved CLOUDSTACK-4986. - Resolution: Fixed > Analysing and implementing Code Coverage for Integration Tests > -- > > Key: CLOUDSTACK-4986 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4986 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Infra >Reporter: Santhosh Kumar Edukulla >Assignee: Santhosh Kumar Edukulla > > Currently, we have facility to use and run sonar for analyzing code > coverage numbers for CS using unit tests. We need to enhance it to support > analysis for integration tests coverage as well. Basically, this will give > coverage numbers for both integration and unit tests. > 1.It seems we already have a code coverage numbers using sonar as below. It > currently shows only the numbers for unit tests. > https://analysis.apache.org/dashboard/index/100206 > 2. The below link has an explanation for using it for both for integration > and unit tests. > http://docs.codehaus.org/display/SONAR/Code+Coverage+by+Integration+Tests+for+Java+Project > 3. Many links suggests it has good decision coverage facility compared to > other coverage tools. > http://onlysoftware.wordpress.com/2012/12/19/code-coverage-tools-jacoco-cobertura-emma-comparison-in-sonar/ > Logging this bug to track this effort and changes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6980) UI for RegisterTemplate API does not expose requireshvm parameter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-6980. - Resolution: Fixed > UI for RegisterTemplate API does not expose requireshvm parameter > - > > Key: CLOUDSTACK-6980 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6980 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Kishan Kavala >Assignee: Rajani Karuturi >Priority: Critical > > requireshvm parameter should be false for LXC templates. > UI does not provide option to set this parameter to false for > RegisterTemplate API -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-7198) Message "Failed to determine router FQDN" thrown in agent log,
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sheng Yang closed CLOUDSTACK-7198.
--
Resolution: Fixed
The result clearly state execution successful and answer is true. I don't see
it's anywhere scary.
The detail information are obtained from cmdline execution, which has nothing
to do with execution success or not. It's needed for debug purpose, to know
exactly what's happened in scripts in case something goes wrong.
Apache2 only issue some warnings in this case, nowhere near suggesting start
failure.
> Message "Failed to determine router FQDN" thrown in agent log,
>
>
> Key: CLOUDSTACK-7198
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7198
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
> Environment: KVM (RHEL 6.3)
>Reporter: Rayees Namathponnan
> Fix For: 4.5.0
>
>
> Below message thrown in agent log multiple times, while calling
> SetupGuestNetworkCommand API
> This message is scary, not sure the impact from user point of view, even
> though the command return true,
> This issue observed in KVM automation , Router : SetupGuestNetworkCommand
> fails while Restarting web server
> 2014-07-29 00:00:13,040 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-2:null) Execution is successful.
> 2014-07-29 00:00:13,041 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Seq 1-6688126921621898335: { Ans: , MgmtId: 29
> 066118877352, via: 1, Ver: v1, Flags: 0,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"","wait":0}}] }
> 2014-07-29 00:00:13,077 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Request:Seq 1-6688126921621898336: { Cmd , Mgm
> tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","
> networkDomain":"cs52auto.advanced","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false
> ,"pxeDisable":true,"nicUuid":"32a59d71-03b6-424d-af2c-94e709d0d998","uuid":"96990ed8-d58c-4c21-beb6-e0d092b92e34","ip":"10.1.1.
> 1","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:65:3e:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri
> ":"vlan://2329","isolationUri":"vlan://2329","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","gue
> st.vlan.tag":"2329","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.255","router.ip":"169.254.1.213","router.name":"r
> -150-VM"},"wait":0}}] }
> 2014-07-29 00:00:13,078 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Processing command: com.cloud.agent.api.SetupGu
> estNetworkCommand
> 2014-07-29 00:00:13,084 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Executing: /usr/share/cloud
> stack-common/scripts/network/domr/router_proxy.sh vpc_guestnw.sh
> 169.254.1.213 -D -M 02:00:65:3e:00:02 -d eth2 -i 10.1.1.1 -g
> 10.1.1.1 -m 24 -n 10.1.1.0 -e cs52auto.advanced
> 2014-07-29 00:00:13,220 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Processing command: com.cloud.agent.api.GetVmDi
> skStatsCommand
> 2014-07-29 00:00:17,575 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Execution is successful.
> 2014-07-29 00:00:17,576 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Seq 1-6688126921621898336: { Ans: , MgmtId: 29
> 066118877352, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"Restarting DNS
> forwarder an
> d DHCP server: dnsmasq.\nRestarting web server: apache2 ... waiting apache2:
> Could not reliably determine the server's fully qu
> alified domain name, using 127.0.0.1 for ServerName\napache2: Could not
> reliably determine the server's fully qualified domain
> name, using 127.0.0.1 for ServerName\n.\n","wait":0}}] }
> 2014-07-29 00:00:17,581 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Request:Seq 1-6688126921621898338: { Cmd , Mgm
> tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.RebootCommand":{"vmName":"i-80-146-VM","wait":0}}]
> }
> 2014-07-29 00:00:17,582 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Processing command: com.cloud.agent.api.RebootC
> ommand
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-5212) [UI]Need Support for the LXC for the Report sockets CS-4908
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-5212. - Resolution: Fixed > [UI]Need Support for the LXC for the Report sockets CS-4908 > --- > > Key: CLOUDSTACK-5212 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5212 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Kiran Koneti >Assignee: Rajani Karuturi >Priority: Critical > Fix For: 4.4.0 > > > For the report sockets feature we need to provide support for the LXC > hypervisor.The support is not yet added. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-5664) XEN patch/hotfix certification - after XS 6.0.2 XS602E030 patch installation VMs deployed before patch installation does not acquire new rules set
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5664: --- Fix Version/s: (was: 4.2.0) 4.5.0 > XEN patch/hotfix certification - after XS 6.0.2 XS602E030 patch installation > VMs deployed before patch installation does not acquire new rules set > --- > > Key: CLOUDSTACK-5664 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5664 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: angeline shen >Assignee: Anthony Xu >Priority: Critical > Fix For: 4.5.0 > > Attachments: 513SMlog, 513xensource.log, 513xenstored-access.log, > 513xenstored-access.log.1, 513xenstored-access.log.2, > 513xenstored-access.log.3, 514SMlog, 514xensource.log, > 514xenstored-access.log, management-server.log.gz > > > XEN hotfix installation procedure > 1. Hosts master slave installed with > XS 6.0.2 base + Hotfix XS602E001 to XS602E029 + CSPs > 2. Basic zone with cluster of above master & slave hosts > security group default with NO security rules > Deploy two VMs > 3. MS: master host put to maintenance mode - VMs migrate to slave host > 4. MS: unmanage cluster > 5. master host: install hotfix XS602E030 + CSP , reboot master > 6. MS: master host cancel maintenance mode > 7. MS: manage cluster > 8. MS: slave host put to maintenance mode - VMs migrate to master host > 9. MS: Add security rules: ingress TCP 1 - 80900.0.0.0/0 > ingress ICMP -1 -10.0.0.0/0 > egress TCP1 - 80900.0.0.0/0 > egress ICMP -1 -10.0.0.0/0 > 10. MS: slave host cancel maintenance mode > 11. stop/start SSVMVR > 12. Deploy two more VMs > Test result: > VMs deployed after HotFix XS602E030 installation correctly acquired 4 new > ingress + egress rules > VMs deployed before HotFix XS602E030 installation did not acquire 4 new > ingress & egress rules - error > Also there are errors encountered when attempt to apply these rules to old > VMs: > 2013-12-27 12:14:37,294 DEBUG [cloud.async.AsyncJobManagerImpl] > (Job-Executor-21:job-21 = [ 94abc9ec-19fc-4d8b-916c-531e161c8525 ]) Done > executing > org.apache.cloudstack.api.command.user.securitygroup.AuthorizeSecurityGroupIngressCmd > for job-21 = [ 94abc9ec-19fc-4d8b-916c-531e161c8525 ] > 2013-12-27 12:14:37,471 WARN [xen.resource.CitrixResourceBase] > (DirectAgent-204:null) callHostPlugin failed for cmd: network_rules with args > seqno: 8, vmIP: 10.223.51.30, deflated: true, secIps: 0:, vmID: 5, vmMAC: > 06:37:9c:00:00:10, vmName: i-2-5-VM, rules: > eJzztCpJLrAytLIwsDSwMtADQ30DHT/XiBAFAGbLBq8=, signature: > 8683b82a9b77d8ece0dd135304fbdb8a, due to There was a failure communicating > with the plugin. > 2013-12-27 12:14:37,472 WARN [agent.manager.DirectAgentAttache] > (DirectAgent-204:null) Seq 1-1198391355: Exception Caught while executing > command > com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for > cmd: network_rules with args seqno: 8, vmIP: 10.223.51.30, deflated: true, > secIps: 0:, vmID: 5, vmMAC: 06:37:9c:00:00:10, vmName: i-2-5-VM, rules: > eJzztCpJLrAytLIwsDSwMtADQ30DHT/XiBAFAGbLBq8=, signature: > 8683b82a9b77d8ece0dd135304fbdb8a, due to There was a failure communicating > with the plugin. > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.callHostPlugin(CitrixResourceBase.java:4181) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5775) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:565) > at > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59) > at > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at
[jira] [Updated] (CLOUDSTACK-5664) XEN patch/hotfix certification - after XS 6.0.2 XS602E030 patch installation VMs deployed before patch installation does not acquire new rules set
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5664: --- Assignee: Anthony Xu > XEN patch/hotfix certification - after XS 6.0.2 XS602E030 patch installation > VMs deployed before patch installation does not acquire new rules set > --- > > Key: CLOUDSTACK-5664 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5664 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: angeline shen >Assignee: Anthony Xu >Priority: Critical > Fix For: 4.5.0 > > Attachments: 513SMlog, 513xensource.log, 513xenstored-access.log, > 513xenstored-access.log.1, 513xenstored-access.log.2, > 513xenstored-access.log.3, 514SMlog, 514xensource.log, > 514xenstored-access.log, management-server.log.gz > > > XEN hotfix installation procedure > 1. Hosts master slave installed with > XS 6.0.2 base + Hotfix XS602E001 to XS602E029 + CSPs > 2. Basic zone with cluster of above master & slave hosts > security group default with NO security rules > Deploy two VMs > 3. MS: master host put to maintenance mode - VMs migrate to slave host > 4. MS: unmanage cluster > 5. master host: install hotfix XS602E030 + CSP , reboot master > 6. MS: master host cancel maintenance mode > 7. MS: manage cluster > 8. MS: slave host put to maintenance mode - VMs migrate to master host > 9. MS: Add security rules: ingress TCP 1 - 80900.0.0.0/0 > ingress ICMP -1 -10.0.0.0/0 > egress TCP1 - 80900.0.0.0/0 > egress ICMP -1 -10.0.0.0/0 > 10. MS: slave host cancel maintenance mode > 11. stop/start SSVMVR > 12. Deploy two more VMs > Test result: > VMs deployed after HotFix XS602E030 installation correctly acquired 4 new > ingress + egress rules > VMs deployed before HotFix XS602E030 installation did not acquire 4 new > ingress & egress rules - error > Also there are errors encountered when attempt to apply these rules to old > VMs: > 2013-12-27 12:14:37,294 DEBUG [cloud.async.AsyncJobManagerImpl] > (Job-Executor-21:job-21 = [ 94abc9ec-19fc-4d8b-916c-531e161c8525 ]) Done > executing > org.apache.cloudstack.api.command.user.securitygroup.AuthorizeSecurityGroupIngressCmd > for job-21 = [ 94abc9ec-19fc-4d8b-916c-531e161c8525 ] > 2013-12-27 12:14:37,471 WARN [xen.resource.CitrixResourceBase] > (DirectAgent-204:null) callHostPlugin failed for cmd: network_rules with args > seqno: 8, vmIP: 10.223.51.30, deflated: true, secIps: 0:, vmID: 5, vmMAC: > 06:37:9c:00:00:10, vmName: i-2-5-VM, rules: > eJzztCpJLrAytLIwsDSwMtADQ30DHT/XiBAFAGbLBq8=, signature: > 8683b82a9b77d8ece0dd135304fbdb8a, due to There was a failure communicating > with the plugin. > 2013-12-27 12:14:37,472 WARN [agent.manager.DirectAgentAttache] > (DirectAgent-204:null) Seq 1-1198391355: Exception Caught while executing > command > com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for > cmd: network_rules with args seqno: 8, vmIP: 10.223.51.30, deflated: true, > secIps: 0:, vmID: 5, vmMAC: 06:37:9c:00:00:10, vmName: i-2-5-VM, rules: > eJzztCpJLrAytLIwsDSwMtADQ30DHT/XiBAFAGbLBq8=, signature: > 8683b82a9b77d8ece0dd135304fbdb8a, due to There was a failure communicating > with the plugin. > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.callHostPlugin(CitrixResourceBase.java:4181) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5775) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:565) > at > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59) > at > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:67
[jira] [Updated] (CLOUDSTACK-7198) Message "Failed to determine router FQDN" thrown in agent log,
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan updated CLOUDSTACK-7198:
Summary: Message "Failed to determine router FQDN" thrown in agent log,
(was: [Automation] Router : SetupGuestNetworkCommand fails while Restarting web
server)
> Message "Failed to determine router FQDN" thrown in agent log,
>
>
> Key: CLOUDSTACK-7198
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7198
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
> Environment: KVM (RHEL 6.3)
>Reporter: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.5.0
>
>
> Below message thrown in agent log multiple times, while calling
> SetupGuestNetworkCommand API
> This message is scary, not sure the impact from user point of view, even
> though the command return true,
> This issue observed in KVM automation , Router : SetupGuestNetworkCommand
> fails while Restarting web server
> 2014-07-29 00:00:13,040 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-2:null) Execution is successful.
> 2014-07-29 00:00:13,041 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Seq 1-6688126921621898335: { Ans: , MgmtId: 29
> 066118877352, via: 1, Ver: v1, Flags: 0,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"","wait":0}}] }
> 2014-07-29 00:00:13,077 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Request:Seq 1-6688126921621898336: { Cmd , Mgm
> tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","
> networkDomain":"cs52auto.advanced","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false
> ,"pxeDisable":true,"nicUuid":"32a59d71-03b6-424d-af2c-94e709d0d998","uuid":"96990ed8-d58c-4c21-beb6-e0d092b92e34","ip":"10.1.1.
> 1","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:65:3e:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri
> ":"vlan://2329","isolationUri":"vlan://2329","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","gue
> st.vlan.tag":"2329","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.255","router.ip":"169.254.1.213","router.name":"r
> -150-VM"},"wait":0}}] }
> 2014-07-29 00:00:13,078 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Processing command: com.cloud.agent.api.SetupGu
> estNetworkCommand
> 2014-07-29 00:00:13,084 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Executing: /usr/share/cloud
> stack-common/scripts/network/domr/router_proxy.sh vpc_guestnw.sh
> 169.254.1.213 -D -M 02:00:65:3e:00:02 -d eth2 -i 10.1.1.1 -g
> 10.1.1.1 -m 24 -n 10.1.1.0 -e cs52auto.advanced
> 2014-07-29 00:00:13,220 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Processing command: com.cloud.agent.api.GetVmDi
> skStatsCommand
> 2014-07-29 00:00:17,575 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Execution is successful.
> 2014-07-29 00:00:17,576 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Seq 1-6688126921621898336: { Ans: , MgmtId: 29
> 066118877352, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"Restarting DNS
> forwarder an
> d DHCP server: dnsmasq.\nRestarting web server: apache2 ... waiting apache2:
> Could not reliably determine the server's fully qu
> alified domain name, using 127.0.0.1 for ServerName\napache2: Could not
> reliably determine the server's fully qualified domain
> name, using 127.0.0.1 for ServerName\n.\n","wait":0}}] }
> 2014-07-29 00:00:17,581 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Request:Seq 1-6688126921621898338: { Cmd , Mgm
> tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.RebootCommand":{"vmName":"i-80-146-VM","wait":0}}]
> }
> 2014-07-29 00:00:17,582 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Processing command: com.cloud.agent.api.RebootC
> ommand
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Reopened] (CLOUDSTACK-7198) Message "Failed to determine router FQDN" thrown in agent log,
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan reopened CLOUDSTACK-7198:
-
> Message "Failed to determine router FQDN" thrown in agent log,
>
>
> Key: CLOUDSTACK-7198
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7198
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
> Environment: KVM (RHEL 6.3)
>Reporter: Rayees Namathponnan
> Fix For: 4.5.0
>
>
> Below message thrown in agent log multiple times, while calling
> SetupGuestNetworkCommand API
> This message is scary, not sure the impact from user point of view, even
> though the command return true,
> This issue observed in KVM automation , Router : SetupGuestNetworkCommand
> fails while Restarting web server
> 2014-07-29 00:00:13,040 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-2:null) Execution is successful.
> 2014-07-29 00:00:13,041 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Seq 1-6688126921621898335: { Ans: , MgmtId: 29
> 066118877352, via: 1, Ver: v1, Flags: 0,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"","wait":0}}] }
> 2014-07-29 00:00:13,077 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Request:Seq 1-6688126921621898336: { Cmd , Mgm
> tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","
> networkDomain":"cs52auto.advanced","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false
> ,"pxeDisable":true,"nicUuid":"32a59d71-03b6-424d-af2c-94e709d0d998","uuid":"96990ed8-d58c-4c21-beb6-e0d092b92e34","ip":"10.1.1.
> 1","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:65:3e:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri
> ":"vlan://2329","isolationUri":"vlan://2329","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","gue
> st.vlan.tag":"2329","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.255","router.ip":"169.254.1.213","router.name":"r
> -150-VM"},"wait":0}}] }
> 2014-07-29 00:00:13,078 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Processing command: com.cloud.agent.api.SetupGu
> estNetworkCommand
> 2014-07-29 00:00:13,084 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Executing: /usr/share/cloud
> stack-common/scripts/network/domr/router_proxy.sh vpc_guestnw.sh
> 169.254.1.213 -D -M 02:00:65:3e:00:02 -d eth2 -i 10.1.1.1 -g
> 10.1.1.1 -m 24 -n 10.1.1.0 -e cs52auto.advanced
> 2014-07-29 00:00:13,220 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Processing command: com.cloud.agent.api.GetVmDi
> skStatsCommand
> 2014-07-29 00:00:17,575 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Execution is successful.
> 2014-07-29 00:00:17,576 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Seq 1-6688126921621898336: { Ans: , MgmtId: 29
> 066118877352, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"Restarting DNS
> forwarder an
> d DHCP server: dnsmasq.\nRestarting web server: apache2 ... waiting apache2:
> Could not reliably determine the server's fully qu
> alified domain name, using 127.0.0.1 for ServerName\napache2: Could not
> reliably determine the server's fully qualified domain
> name, using 127.0.0.1 for ServerName\n.\n","wait":0}}] }
> 2014-07-29 00:00:17,581 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Request:Seq 1-6688126921621898338: { Cmd , Mgm
> tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.RebootCommand":{"vmName":"i-80-146-VM","wait":0}}]
> }
> 2014-07-29 00:00:17,582 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Processing command: com.cloud.agent.api.RebootC
> ommand
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (CLOUDSTACK-7198) Message "Failed to determine router FQDN" thrown in agent log,
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078454#comment-14078454
]
Rayees Namathponnan edited comment on CLOUDSTACK-7198 at 7/30/14 4:40 AM:
--
Reopening this ticket,
was (Author: rayeesn):
its my mistake, miss integrated with logs, closing for now
> Message "Failed to determine router FQDN" thrown in agent log,
>
>
> Key: CLOUDSTACK-7198
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7198
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
> Environment: KVM (RHEL 6.3)
>Reporter: Rayees Namathponnan
> Fix For: 4.5.0
>
>
> Below message thrown in agent log multiple times, while calling
> SetupGuestNetworkCommand API
> This message is scary, not sure the impact from user point of view, even
> though the command return true,
> This issue observed in KVM automation , Router : SetupGuestNetworkCommand
> fails while Restarting web server
> 2014-07-29 00:00:13,040 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-2:null) Execution is successful.
> 2014-07-29 00:00:13,041 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Seq 1-6688126921621898335: { Ans: , MgmtId: 29
> 066118877352, via: 1, Ver: v1, Flags: 0,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"","wait":0}}] }
> 2014-07-29 00:00:13,077 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Request:Seq 1-6688126921621898336: { Cmd , Mgm
> tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","
> networkDomain":"cs52auto.advanced","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false
> ,"pxeDisable":true,"nicUuid":"32a59d71-03b6-424d-af2c-94e709d0d998","uuid":"96990ed8-d58c-4c21-beb6-e0d092b92e34","ip":"10.1.1.
> 1","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:65:3e:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri
> ":"vlan://2329","isolationUri":"vlan://2329","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","gue
> st.vlan.tag":"2329","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.255","router.ip":"169.254.1.213","router.name":"r
> -150-VM"},"wait":0}}] }
> 2014-07-29 00:00:13,078 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Processing command: com.cloud.agent.api.SetupGu
> estNetworkCommand
> 2014-07-29 00:00:13,084 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Executing: /usr/share/cloud
> stack-common/scripts/network/domr/router_proxy.sh vpc_guestnw.sh
> 169.254.1.213 -D -M 02:00:65:3e:00:02 -d eth2 -i 10.1.1.1 -g
> 10.1.1.1 -m 24 -n 10.1.1.0 -e cs52auto.advanced
> 2014-07-29 00:00:13,220 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Processing command: com.cloud.agent.api.GetVmDi
> skStatsCommand
> 2014-07-29 00:00:17,575 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Execution is successful.
> 2014-07-29 00:00:17,576 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Seq 1-6688126921621898336: { Ans: , MgmtId: 29
> 066118877352, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"Restarting DNS
> forwarder an
> d DHCP server: dnsmasq.\nRestarting web server: apache2 ... waiting apache2:
> Could not reliably determine the server's fully qu
> alified domain name, using 127.0.0.1 for ServerName\napache2: Could not
> reliably determine the server's fully qualified domain
> name, using 127.0.0.1 for ServerName\n.\n","wait":0}}] }
> 2014-07-29 00:00:17,581 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Request:Seq 1-6688126921621898338: { Cmd , Mgm
> tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.RebootCommand":{"vmName":"i-80-146-VM","wait":0}}]
> }
> 2014-07-29 00:00:17,582 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Processing command: com.cloud.agent.api.RebootC
> ommand
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7198) [Automation] Router : SetupGuestNetworkCommand fails while Restarting web server
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan updated CLOUDSTACK-7198:
Description:
Below message thrown in agent log multiple times, while calling
SetupGuestNetworkCommand API
This message is scary, not sure the impact from user point of view, even though
the command return true,
This issue observed in KVM automation , Router : SetupGuestNetworkCommand fails
while Restarting web server
2014-07-29 00:00:13,040 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-2:null) Execution is successful.
2014-07-29 00:00:13,041 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:null)
Seq 1-6688126921621898335: { Ans: , MgmtId: 29
066118877352, via: 1, Ver: v1, Flags: 0,
[{"com.cloud.agent.api.Answer":{"result":true,"details":"","wait":0}}] }
2014-07-29 00:00:13,077 DEBUG [cloud.agent.Agent] (agentRequest-Handler-3:null)
Request:Seq 1-6688126921621898336: { Cmd , Mgm
tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
[{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","
networkDomain":"cs52auto.advanced","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false
,"pxeDisable":true,"nicUuid":"32a59d71-03b6-424d-af2c-94e709d0d998","uuid":"96990ed8-d58c-4c21-beb6-e0d092b92e34","ip":"10.1.1.
1","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:65:3e:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri
":"vlan://2329","isolationUri":"vlan://2329","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","gue
st.vlan.tag":"2329","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.255","router.ip":"169.254.1.213","router.name":"r
-150-VM"},"wait":0}}] }
2014-07-29 00:00:13,078 DEBUG [cloud.agent.Agent] (agentRequest-Handler-3:null)
Processing command: com.cloud.agent.api.SetupGu
estNetworkCommand
2014-07-29 00:00:13,084 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-3:null) Executing: /usr/share/cloud
stack-common/scripts/network/domr/router_proxy.sh vpc_guestnw.sh 169.254.1.213
-D -M 02:00:65:3e:00:02 -d eth2 -i 10.1.1.1 -g
10.1.1.1 -m 24 -n 10.1.1.0 -e cs52auto.advanced
2014-07-29 00:00:13,220 DEBUG [cloud.agent.Agent] (agentRequest-Handler-1:null)
Processing command: com.cloud.agent.api.GetVmDi
skStatsCommand
2014-07-29 00:00:17,575 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-3:null) Execution is successful.
2014-07-29 00:00:17,576 DEBUG [cloud.agent.Agent] (agentRequest-Handler-3:null)
Seq 1-6688126921621898336: { Ans: , MgmtId: 29
066118877352, via: 1, Ver: v1, Flags: 110,
[{"com.cloud.agent.api.Answer":{"result":true,"details":"Restarting DNS
forwarder an
d DHCP server: dnsmasq.\nRestarting web server: apache2 ... waiting apache2:
Could not reliably determine the server's fully qu
alified domain name, using 127.0.0.1 for ServerName\napache2: Could not
reliably determine the server's fully qualified domain
name, using 127.0.0.1 for ServerName\n.\n","wait":0}}] }
2014-07-29 00:00:17,581 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:null)
Request:Seq 1-6688126921621898338: { Cmd , Mgm
tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
[{"com.cloud.agent.api.RebootCommand":{"vmName":"i-80-146-VM","wait":0}}]
}
2014-07-29 00:00:17,582 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:null)
Processing command: com.cloud.agent.api.RebootC
ommand
was:
This issue observed in KVM automation , Router : SetupGuestNetworkCommand fails
while Restarting web server
2014-07-29 00:00:13,040 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-2:null) Execution is successful.
2014-07-29 00:00:13,041 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:null)
Seq 1-6688126921621898335: { Ans: , MgmtId: 29
066118877352, via: 1, Ver: v1, Flags: 0,
[{"com.cloud.agent.api.Answer":{"result":true,"details":"","wait":0}}] }
2014-07-29 00:00:13,077 DEBUG [cloud.agent.Agent] (agentRequest-Handler-3:null)
Request:Seq 1-6688126921621898336: { Cmd , Mgm
tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
[{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","
networkDomain":"cs52auto.advanced","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false
,"pxeDisable":true,"nicUuid":"32a59d71-03b6-424d-af2c-94e709d0d998","uuid":"96990ed8-d58c-4c21-beb6-e0d092b92e34","ip":"10.1.1.
1","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:65:3e:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri
":"vlan://2329","isolationUri":"vlan://2329","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","gue
st.vlan.tag":"2329","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.255","router.ip":"169.254.1.213","router.name":"r
-150-VM"},"wait":0}}] }
2014-07-29 00:00:13,078 DEBUG [cloud.agent.A
[jira] [Updated] (CLOUDSTACK-7198) Message "Failed to determine router FQDN" thrown in agent log,
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan updated CLOUDSTACK-7198:
Priority: Major (was: Critical)
> Message "Failed to determine router FQDN" thrown in agent log,
>
>
> Key: CLOUDSTACK-7198
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7198
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
> Environment: KVM (RHEL 6.3)
>Reporter: Rayees Namathponnan
> Fix For: 4.5.0
>
>
> Below message thrown in agent log multiple times, while calling
> SetupGuestNetworkCommand API
> This message is scary, not sure the impact from user point of view, even
> though the command return true,
> This issue observed in KVM automation , Router : SetupGuestNetworkCommand
> fails while Restarting web server
> 2014-07-29 00:00:13,040 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-2:null) Execution is successful.
> 2014-07-29 00:00:13,041 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Seq 1-6688126921621898335: { Ans: , MgmtId: 29
> 066118877352, via: 1, Ver: v1, Flags: 0,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"","wait":0}}] }
> 2014-07-29 00:00:13,077 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Request:Seq 1-6688126921621898336: { Cmd , Mgm
> tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","
> networkDomain":"cs52auto.advanced","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false
> ,"pxeDisable":true,"nicUuid":"32a59d71-03b6-424d-af2c-94e709d0d998","uuid":"96990ed8-d58c-4c21-beb6-e0d092b92e34","ip":"10.1.1.
> 1","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:65:3e:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri
> ":"vlan://2329","isolationUri":"vlan://2329","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","gue
> st.vlan.tag":"2329","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.255","router.ip":"169.254.1.213","router.name":"r
> -150-VM"},"wait":0}}] }
> 2014-07-29 00:00:13,078 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Processing command: com.cloud.agent.api.SetupGu
> estNetworkCommand
> 2014-07-29 00:00:13,084 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Executing: /usr/share/cloud
> stack-common/scripts/network/domr/router_proxy.sh vpc_guestnw.sh
> 169.254.1.213 -D -M 02:00:65:3e:00:02 -d eth2 -i 10.1.1.1 -g
> 10.1.1.1 -m 24 -n 10.1.1.0 -e cs52auto.advanced
> 2014-07-29 00:00:13,220 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Processing command: com.cloud.agent.api.GetVmDi
> skStatsCommand
> 2014-07-29 00:00:17,575 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Execution is successful.
> 2014-07-29 00:00:17,576 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Seq 1-6688126921621898336: { Ans: , MgmtId: 29
> 066118877352, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"Restarting DNS
> forwarder an
> d DHCP server: dnsmasq.\nRestarting web server: apache2 ... waiting apache2:
> Could not reliably determine the server's fully qu
> alified domain name, using 127.0.0.1 for ServerName\napache2: Could not
> reliably determine the server's fully qualified domain
> name, using 127.0.0.1 for ServerName\n.\n","wait":0}}] }
> 2014-07-29 00:00:17,581 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Request:Seq 1-6688126921621898338: { Cmd , Mgm
> tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.RebootCommand":{"vmName":"i-80-146-VM","wait":0}}]
> }
> 2014-07-29 00:00:17,582 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Processing command: com.cloud.agent.api.RebootC
> ommand
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7169) VR_Rolling_Upgarde: command execution order changed when we restart the network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078656#comment-14078656 ] Sheng Yang commented on CLOUDSTACK-7169: VR aggregation didn't change the order. The order of network restart and reboot router is different by themselves. I would check it. > VR_Rolling_Upgarde: command execution order changed when we restart the > network > - > > Key: CLOUDSTACK-7169 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7169 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: sadhu suresh >Assignee: Sheng Yang >Priority: Critical > > when we reboot the VR, the order is proper (i.e ip assoc first then later > firewall rule next) but when restart the network ,the order has changed > i.e we are programming firewall before ipassoc. > 1.configure advanced zone with vmware > 2.deploy a vm > 3.acquire a public IP and configure the LB rule > 4. restart the router > 5. once the router is up ,check the command execution order > 6.again perform the network restart > 7.check the configured order > actual result: > step 4:(incase of router restart) - the order is ok as per expected (i.e > programming firewall after ipassoc) > Step 6:(restart network) > Here order has changed and it s programming firewall rule before ipassoc > please check the VR*.cfg > root@cen62307 ~]# cat VR-18351526-c087-48b9-8f8b-10b2c3f8a07e.cfg > #Apache CloudStack Virtual Router Config File > > 1.0 > > > /opt/cloud/bin/firewall_ingress.sh -F -a 10.147.49.200:tcp:22:22:0.0.0.0/0:, > > > /opt/cloud/bin/ipassoc.sh -A -s -f -l 10.147.49.189/24 -c eth2 -g 10.147.49.1 > > > /opt/cloud/bin/ipassoc.sh -A -l 10.147.49.200/24 -c eth2 -g 10.147.49.1 > > > /etc/haproxy/haproxy.cfg.new.1406117121933 > global > log 127.0.0.1:3914 local0 warning > maxconn 4096 > maxpipes 1024 > chroot /var/lib/haproxy > user haproxy > group haproxy > daemon > defaults > log global > modetcp > option dontlognull > retries 3 > option redispatch > option forwardfor > option forceclose > timeout connect5000 > timeout client 5 > timeout server 5 > listen stats_on_public 10.147.49.189:8081 > mode http > option httpclose > stats enable > stats uri /admin?stats > stats realm Haproxy\ Statistics > stats authadmin1:AdMiN123 > listen 10_147_49_189-22 10.147.49.189:22 > balance roundrobin > server 10_147_49_189-22_0 10.1.1.2:22 check > listen 10_147_49_200-22 10.147.49.200:22 > balance roundrobin > server 10_147_49_200-22_0 10.1.1.105:22 check > > > /opt/cloud/bin/loadbalancer.sh -i 10.147.41.29 -f > /etc/haproxy/haproxy.cfg.new.1406117121933 -a > 10.147.49.189:22:,10.147.49.200:22:, -s 10.147.49.189:8081:0/0:,, > > > /opt/cloud/bin/ipassoc.sh -A -s -f -l 10.147.49.189/24 -c eth2 -g 10.147.49.1 > >
[jira] [Resolved] (CLOUDSTACK-67) Resizing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski resolved CLOUDSTACK-67. -- Resolution: Fixed > Resizing > > > Key: CLOUDSTACK-67 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-67 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: XxYton >Assignee: Mike Tutkowski > Fix For: Future > > > Resizing of volumes and instances is not possible right now. > Instance resizing should be done without rebooting the VM if supported by > hypervisor. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-67) Resizing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski closed CLOUDSTACK-67. > Resizing > > > Key: CLOUDSTACK-67 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-67 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: XxYton >Assignee: Mike Tutkowski > Fix For: Future > > > Resizing of volumes and instances is not possible right now. > Instance resizing should be done without rebooting the VM if supported by > hypervisor. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-67) Resizing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078643#comment-14078643 ] Mike Tutkowski commented on CLOUDSTACK-67: -- Yes, volume resizing is now intended to work on XenServer, ESX, and KVM. It does not work when the VM is online for XenServer, however (limitation in XenServer). > Resizing > > > Key: CLOUDSTACK-67 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-67 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: XxYton >Assignee: Mike Tutkowski > Fix For: Future > > > Resizing of volumes and instances is not possible right now. > Instance resizing should be done without rebooting the VM if supported by > hypervisor. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7180) [Automation] listHostsForMigration API throwing NullPointerException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078583#comment-14078583
]
Prachi Damle commented on CLOUDSTACK-7180:
--
Gaurav,
This is the line in code where the NPE is getting thrown:
s_logger.debug("Looking for speed=" + (offering.getCpu() *
offering.getSpeed()) + "Mhz, Ram=" + offering.getRamSize());
So do you see the ServiceOffering in the setup having null CPU/Speed/Ram?
> [Automation] listHostsForMigration API throwing NullPointerException
>
>
> Key: CLOUDSTACK-7180
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7180
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.5.0
> Environment: KVM Basic zone
>Reporter: Gaurav Aradhye
>Assignee: Prachi Damle
> Labels: automation
> Fix For: 4.5.0
>
>
> I have two hosts in a cluster.
> VM is in deployed on a host.
> listHostsForMigration API for this virtual machine is throwing
> nullPointerException.
> Log:
> 2014-07-25 00:15:24,270 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-10:ctx-efc4c9bc) ===START=== 10.223.240.194 -- GET
> signature=Rk8pWUV2LRuKDbU8ZuprqB7H2IY%3D&apiKey=dO
> CC5kHhVyiFCXvA6KHJnD9d_UKcjGhiaZDp62nQgrrJNMgCeRNK0iQ_KbE_irqXpGOjzJ3WT6I-K1gBpaf3qg&command=listHosts&response=json&virtualmachineid=e97cea8e-7d69-40ec-a580-1ff9a8d00
> c16
> 2014-07-25 00:15:24,283 DEBUG [c.c.s.ManagementServerImpl]
> (catalina-exec-10:ctx-efc4c9bc ctx-ca51a091 ctx-2a80b5a3) Searching for all
> hosts in cluster 1 for migrating
> VM VM[User|i-142-128-VM]
> 2014-07-25 00:15:24,287 DEBUG [o.a.c.a.HostAntiAffinityProcessor]
> (catalina-exec-10:ctx-efc4c9bc ctx-ca51a091 ctx-2a80b5a3) Processing affinity
> group aff_grp_T5X8R9 fo
> r VM Id: 128
> 2014-07-25 00:15:24,290 DEBUG [c.c.a.m.a.i.FirstFitAllocator]
> (catalina-exec-10:ctx-efc4c9bc ctx-ca51a091 ctx-2a80b5a3) Looking for hosts
> in dc: 1 pod:1 cluster:1
> 2014-07-25 00:15:24,293 DEBUG [c.c.a.m.a.i.FirstFitAllocator]
> (catalina-exec-10:ctx-efc4c9bc ctx-ca51a091 ctx-2a80b5a3) FirstFitAllocator
> has 2 hosts to check for allo
> cation: [Host[-2-Routing], Host[-1-Routing]]
> 2014-07-25 00:15:24,298 DEBUG [c.c.a.m.a.i.FirstFitAllocator]
> (catalina-exec-10:ctx-efc4c9bc ctx-ca51a091 ctx-2a80b5a3) Found 2 hosts for
> allocation after prioritizati
> on: [Host[-2-Routing], Host[-1-Routing]]
> 2014-07-25 00:15:24,298 ERROR [c.c.a.ApiServer]
> (catalina-exec-10:ctx-efc4c9bc ctx-ca51a091 ctx-2a80b5a3) unhandled exception
> executing api command: [Ljava.lang.String
> ;@5d847d08
> java.lang.NullPointerException
> at
> com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:253)
> at
> com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:182)
> at
> com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1229)
> 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.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.$Proxy213.listHostsForMigrationOfVM(Unknown Source)
> at
> org.apache.cloudstack.api.command.admin.host.ListHostsCmd.execute(ListHostsCmd.java:189)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517)
> at
> com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudst
[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078553#comment-14078553 ] Anthony Xu commented on CLOUDSTACK-7184: CS talks to other host and run check_heartbeat.sh in other host to make sure the host self-fence. But it highly depends on all hosts in cluster having synced time, NTP is recommended for XS hosts. please check the time in hosts in the cluster, if time is not synced, that would be the cause for this issue. Anthony > HA should wait for at least 'xen.heartbeat.interval' sec before starting HA > on vm's when host is marked down > > > Key: CLOUDSTACK-7184 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server, XenServer >Affects Versions: 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3 with XenServer 6.2 hypervisors >Reporter: Remi Bergsma >Priority: Blocker > > Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did > discover this and marked the host as down, and immediately started HA. Just > 18 seconds later the hypervisor returned and we ended up with 5 vm's that > were running on two hypervisors at the same time. > This, of course, resulted in file system corruption and the loss of the vm's. > One side of the story is why XenServer allowed this to happen (will not > bother you with this one). The CloudStack side of the story: HA should only > start after at least xen.heartbeat.interval seconds. If the host is down long > enough, the Xen heartbeat script will fence the hypervisor and prevent > corruption. If it is not down long enough, nothing should happen. > Logs (short): > 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) > . > 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] > (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on > the VMs > . > 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager > Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = > AgentDisconnected, Host id = 505, name = mccpvmXX] > cs marks host down: 2014-07-25 05:03:31,920 > cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7199) [Automation] test_multiple_ips_per_nic failng due to missing attributes
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078497#comment-14078497
]
Rayees Namathponnan commented on CLOUDSTACK-7199:
-
Below test cases failing due to this
integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_delete_vm_1_ISOLATED
integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_delete_vm_3_VPC
integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_network_restart_cleanup_false_1_ISOLATED
integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_network_restart_cleanup_false_3_VPC
integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_network_restart_cleanup_true_1_ISOLATED
integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_network_restart_cleanup_true_3_VPC
integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_reboot_router_VM_1_ISOLATED
integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_reboot_router_VM_3_VPC
integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_recover_vm_1_ISOLATED
integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_recover_vm_3_VPC
integration.component.test_multiple_ips_per_nic.TestBasicOperations.test_add_ip_to_nic_1_ISOLATED
integration.component.test_multiple_ips_per_nic.TestBasicOperations.test_add_ip_to_nic_3_VPC
integration.component.test_multiple_ips_per_nic.TestBasicOperations.test_list_nics_1_ISOLATED
integration.component.test_multiple_ips_per_nic.TestBasicOperations.test_list_nics_3_VPC
integration.component.test_multiple_ips_per_nic.TestBasicOperations.test_operations_non_root_admin_api_client_1_ISOLATED
integration.component.test_multiple_ips_per_nic.TestBasicOperations.test_operations_non_root_admin_api_client_3_VPC
integration.component.test_multiple_ips_per_nic.TestBasicOperations.test_remove_ip_from_nic_1_ISOLATED
integration.component.test_multiple_ips_per_nic.TestBasicOperations.test_remove_ip_from_nic_3_VPC
integration.component.test_multiple_ips_per_nic.TestNetworkRules.test_add_PF_rule_1_ISOLATED
integration.component.test_multiple_ips_per_nic.TestNetworkRules.test_add_PF_rule_3_VPC
integration.component.test_multiple_ips_per_nic.TestNetworkRules.test_add_static_nat_rule_1_ISOLATED
integration.component.test_multiple_ips_per_nic.TestNetworkRules.test_add_static_nat_rule_2_SHARED
integration.component.test_multiple_ips_per_nic.TestNetworkRules.test_add_static_nat_rule_3_VPC
integration.component.test_multiple_ips_per_nic.TestNetworkRules.test_delete_PF_nat_rule_1_ISOLATED
integration.component.test_multiple_ips_per_nic.TestNetworkRules.test_delete_PF_nat_rule_3_VPC
integration.component.test_multiple_ips_per_nic.TestNetworkRules.test_disable_static_nat_1_ISOLATED
integration.component.test_multiple_ips_per_nic.TestNetworkRules.test_disable_static_nat_3_VPC
integration.component.test_multiple_ips_per_nic.TestNetworkRules.test_disassociate_ip_mapped_to_secondary_ip_through_PF_rule_1_ISOLATED
integration.component.test_multiple_ips_per_nic.TestNetworkRules.test_disassociate_ip_mapped_to_secondary_ip_through_PF_rule_3_VPC
> [Automation] test_multiple_ips_per_nic failng due to missing attributes
>
>
> Key: CLOUDSTACK-7199
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7199
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.5.0
>
>
> Below test cases failing in automation runs in vmware
> integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_network_restart_cleanup_false_3_VPC
> Error Message
> Error Message
> 'TestNetworkRules' object has no attribute 'vpc_off'
> >> begin captured stdout << -
> === TestName: test_add_static_nat_rule_3_VPC | Status : EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_add_static_nat_rule_3_VPC
> (integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
> STARTED : TC: test_add_static_nat_rule_3_VPC :::
> test_add_static_nat_rule_3_VPC
> (integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
> Payload: {'username':
> 'test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W',
> 'domainid': u'de3e8c70-16da-11e4-a7b2-52b2d980df8a', 'firstname': 'test',
> 'lastname': 'test', 'response': 'json', 'apiKey':
> u'xkp61NgHs4t
[jira] [Updated] (CLOUDSTACK-7199) [Automation] test_multiple_ips_per_nic failng due to missing attributes
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan updated CLOUDSTACK-7199:
Description:
Below test cases failing in automation runs in vmware
integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_network_restart_cleanup_false_3_VPC
Error Message
Error Message
'TestNetworkRules' object has no attribute 'vpc_off'
>> begin captured stdout << -
=== TestName: test_add_static_nat_rule_3_VPC | Status : EXCEPTION ===
- >> end captured stdout << --
>> begin captured logging <<
test_add_static_nat_rule_3_VPC
(integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
STARTED : TC: test_add_static_nat_rule_3_VPC :::
test_add_static_nat_rule_3_VPC
(integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
Payload: {'username':
'test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W',
'domainid': u'de3e8c70-16da-11e4-a7b2-52b2d980df8a', 'firstname': 'test',
'lastname': 'test', 'response': 'json', 'apiKey':
u'xkp61NgHs4tG3PrK7WvtPKVU7Wd17aQ0zhZY1ku4LwqycZRISeJsJG-MrhjUaY-bfPcyxxIDpeIAItlm7RW2kQ',
'command': 'createAccount', 'accounttype': 0, 'signature':
'1ecQbYqO6bDFi7aMhuKVMiMFKLA=', 'password': 'password', 'email':
'test-acco...@test.com'}
test_add_static_nat_rule_3_VPC
(integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
Sending GET Cmd : createAccount===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.49.197
requests.packages.urllib3.connectionpool: DEBUG: "GET
/client/api?username=test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W&domainid=de3e8c70-16da-11e4-a7b2-52b2d980df8a&firstname=test&lastname=test&email=test-account%40test.com&apiKey=xkp61NgHs4tG3PrK7WvtPKVU7Wd17aQ0zhZY1ku4LwqycZRISeJsJG-MrhjUaY-bfPcyxxIDpeIAItlm7RW2kQ&command=createAccount&accounttype=0&signature=1ecQbYqO6bDFi7aMhuKVMiMFKLA%3D&password=password&response=json
HTTP/1.1" 200 1734
test_add_static_nat_rule_3_VPC
(integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
Response : {primarystorageavailable : u'Unlimited', domain : u'ROOT', domainid
: u'de3e8c70-16da-11e4-a7b2-52b2d980df8a', vpclimit : u'Unlimited', iplimit :
u'Unlimited', volumelimit : u'Unlimited', memorytotal : 0,
secondarystorageavailable : u'Unlimited', vmtotal : 0, cputotal : 0, vpctotal :
0, id : u'de5493f9-9060-4130-bf07-c6f43c46e597', cpuavailable : u'Unlimited',
snapshotlimit : u'Unlimited', networklimit : u'Unlimited', iptotal : 0,
volumetotal : 0, projectlimit : u'Unlimited', state : u'enabled', networktotal
: 0, accounttype : 0, networkavailable : u'Unlimited', primarystoragetotal : 0,
templatelimit : u'Unlimited', snapshottotal : 0, templateavailable :
u'Unlimited', vmlimit : u'Unlimited', vpcavailable : u'Unlimited',
memoryavailable : u'Unlimited', secondarystoragetotal : 0, templatetotal : 0,
projecttotal : 0, user : [{username :
u'test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W',
account :
u'test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W',
domainid : u'de3e8c70-16da-11e4-a7b2-52b2d980df8a', firstname : u'test',
created : u'2014-07-29T05:54:32-0700', lastname : u'test', domain : u'ROOT', id
: u'128e219b-d09e-471b-8fc7-87769f39c731', iscallerchilddomain : False, state :
u'enabled', accounttype : 0, email : u'test-acco...@test.com', isdefault :
False, accountid : u'de5493f9-9060-4130-bf07-c6f43c46e597'}], groups : [],
projectavailable : u'Unlimited', isdefault : False, primarystoragelimit :
u'Unlimited', secondarystoragelimit : u'Unlimited', volumeavailable :
u'Unlimited', name :
u'test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W',
vmavailable : u'Unlimited', ipavailable : u'Unlimited', memorylimit :
u'Unlimited', cpulimit : u'Unlimited', snapshotavailable : u'Unlimited'}
test_add_static_nat_rule_3_VPC
(integration.component.test_multiple_ips_per_nic.TestNetworkRules): DEBUG:
creating a VPC network in the account:
test-account-TestVmNetworkOperations-test_add_static_nat_rule_3_VPC-71766W
test_add_static_nat_rule_3_VPC
(integration.component.test_multiple_ips_per_nic.TestNetworkRules): CRITICAL:
EXCEPTION: test_add_static_nat_rule_3_VPC: ['Traceback (most recent call
last):\n', ' File "/usr/local/lib/python2.7/unittest/case.py", line 318, in
run\ntestMethod()\n', ' File
"/usr/local/lib/python2.7/site-packages/ddt.py", line 114, in wrapper\n
return func(self, *args, **kwargs)\n', ' File
"/data/Repo2/qa/cloudstack/test/integration/component/test_multiple_ips_per_nic.py",
line 735, in test_add_static_nat_rule\nnetwork = createNetwork(self,
[jira] [Resolved] (CLOUDSTACK-7179) [Automation] Router deployment failing while calling "patchviasocket.pl" during router configuration
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan resolved CLOUDSTACK-7179.
-
Resolution: Cannot Reproduce
Cannot reproduce this issue in latest run
> [Automation] Router deployment failing while calling "patchviasocket.pl"
> during router configuration
>
>
> Key: CLOUDSTACK-7179
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7179
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.5.0
> Environment: KVM RHEL 6.3
>Reporter: Rayees Namathponnan
>Assignee: Rayees Namathponnan
>Priority: Blocker
> Fix For: 4.5.0
>
>
> This issue is observed in automation environment, there are many router
> deployment failure, this issue observed while programming "patchviasocket.pl"
> 2014-07-23 22:50:23,660 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-5:null) Executing:
> /usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/patchviasocket.pl -n
> r-384-VM -p
> %template=domP%name=r-384-VM%eth2ip=10.223.122.84%eth2mask=255.255.255.192%gateway=10.223.122.65%eth0ip=10.1.1.1%eth0mask=255.255.255.0%domain=csfeauto.advanced%cidrsize=24%dhcprange=10.1.1.1%eth1ip=169.254.1.76%eth1mask=255.255.0.0%type=router%disable_rp_filter=true%dns1=8.8.8.8
> 2014-07-23 22:50:24,973 DEBUG
> [resource.virtualnetwork.VirtualRoutingResource]
> (agentRequest-Handler-3:null) Trying to connect to 169.254.3.89
> 2014-07-23 22:50:27,974 DEBUG
> [resource.virtualnetwork.VirtualRoutingResource]
> (agentRequest-Handler-3:null) Could not connect to 169.254.3.89
> 2014-07-23 22:50:28,661 WARN [kvm.resource.LibvirtComputingResource]
> (Script-7:null) Interrupting script.
> 2014-07-23 22:50:28,662 WARN [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-5:null) Timed out:
> /usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/patchviasocket.pl -n
> r-384-VM -p
> %template=domP%name=r-384-VM%eth2ip=10.223.122.84%eth2mask=255.255.255.192%gateway=10.223.122.65%eth0ip=10.1.1.1%eth0mask=255.255.255.0%domain=csfeauto.advanced%cidrsize=24%dhcprange=10.1.1.1%eth1ip=169.254.1.76%eth1mask=255.255.0.0%type=router%disable_rp_filter=true%dns1=8.8.8.8
> . Output is:
> 2014-07-23 22:50:28,662 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-5:null) passcmd failed:timeout
> 2014-07-23 22:52:56,323 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Request:Seq 1-586986832060423: { Cmd ,
> MgmtId: 29066118877352, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"checkBeforeCleanup":true,"vmName":"r-384-VM","wait":0}}]
> }
> 2014-07-23 22:52:56,323 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Processing command:
> com.cloud.agent.api.StopCommand
> 2014-07-23 22:52:56,326 DEBUG [kvm.resource.LibvirtConnection]
> (agentRequest-Handler-3:null) can't find connection: KVM, for vm: r-384-VM,
> continue
> 2014-07-23 22:52:56,328 DEBUG [kvm.resource.LibvirtConnection]
> (agentRequest-Handler-3:null) can't find connection: LXC, for vm: r-384-VM,
> continue
> 2014-07-23 22:52:56,328 DEBUG [kvm.resource.LibvirtConnection]
> (agentRequest-Handler-3:null) can't find which hypervisor the vm used , then
> use the default hypervisor
> 2014-07-23 22:52:56,330 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Failed to get vm status in case of
> checkboforecleanup is true
> org.libvirt.LibvirtException: Domain not found: no domain with matching name
> 'r-384-VM'
> at org.libvirt.ErrorHandler.processError(Unknown Source)
> at org.libvirt.Connect.processError(Unknown Source)
> at org.libvirt.Connect.processError(Unknown Source)
> at org.libvirt.Connect.domainLookupByName(Unknown Source)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3506)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1276)
> at com.cloud.agent.Agent.processRequest(Agent.java:501)
> at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808)
> at com.cloud.utils.nio.Task.run(Task.java:84)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2014-07-23 22:52:56,332 DEBUG [kvm.resource.LibvirtConnection]
> (agentRequest-Handler-3:null)
[jira] [Created] (CLOUDSTACK-7199) [Automation] test_multiple_ips_per_nic failng due to missing attributes
Rayees Namathponnan created CLOUDSTACK-7199: --- Summary: [Automation] test_multiple_ips_per_nic failng due to missing attributes Key: CLOUDSTACK-7199 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7199 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Rayees Namathponnan Priority: Critical Fix For: 4.5.0 Below test cases failing in automation runs in vmware integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_network_restart_cleanup_false_3_VPC Error Message 'TestVmNetworkOperations' object has no attribute 'vpc_off' >> begin captured stdout << - === TestName: test_network_restart_cleanup_false_3_VPC | Status : EXCEPTION === -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-7198) [Automation] Router : SetupGuestNetworkCommand fails while Restarting web server
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan closed CLOUDSTACK-7198.
---
Resolution: Not a Problem
its my mistake, miss integrated with logs, closing for now
> [Automation] Router : SetupGuestNetworkCommand fails while Restarting web
> server
>
>
> Key: CLOUDSTACK-7198
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7198
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
> Environment: KVM (RHEL 6.3)
>Reporter: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.5.0
>
>
> This issue observed in KVM automation , Router : SetupGuestNetworkCommand
> fails while Restarting web server
> 2014-07-29 00:00:13,040 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-2:null) Execution is successful.
> 2014-07-29 00:00:13,041 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Seq 1-6688126921621898335: { Ans: , MgmtId: 29
> 066118877352, via: 1, Ver: v1, Flags: 0,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"","wait":0}}] }
> 2014-07-29 00:00:13,077 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Request:Seq 1-6688126921621898336: { Cmd , Mgm
> tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","
> networkDomain":"cs52auto.advanced","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false
> ,"pxeDisable":true,"nicUuid":"32a59d71-03b6-424d-af2c-94e709d0d998","uuid":"96990ed8-d58c-4c21-beb6-e0d092b92e34","ip":"10.1.1.
> 1","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:65:3e:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri
> ":"vlan://2329","isolationUri":"vlan://2329","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","gue
> st.vlan.tag":"2329","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.255","router.ip":"169.254.1.213","router.name":"r
> -150-VM"},"wait":0}}] }
> 2014-07-29 00:00:13,078 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Processing command: com.cloud.agent.api.SetupGu
> estNetworkCommand
> 2014-07-29 00:00:13,084 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Executing: /usr/share/cloud
> stack-common/scripts/network/domr/router_proxy.sh vpc_guestnw.sh
> 169.254.1.213 -D -M 02:00:65:3e:00:02 -d eth2 -i 10.1.1.1 -g
> 10.1.1.1 -m 24 -n 10.1.1.0 -e cs52auto.advanced
> 2014-07-29 00:00:13,220 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Processing command: com.cloud.agent.api.GetVmDi
> skStatsCommand
> 2014-07-29 00:00:17,575 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Execution is successful.
> 2014-07-29 00:00:17,576 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Seq 1-6688126921621898336: { Ans: , MgmtId: 29
> 066118877352, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"Restarting DNS
> forwarder an
> d DHCP server: dnsmasq.\nRestarting web server: apache2 ... waiting apache2:
> Could not reliably determine the server's fully qu
> alified domain name, using 127.0.0.1 for ServerName\napache2: Could not
> reliably determine the server's fully qualified domain
> name, using 127.0.0.1 for ServerName\n.\n","wait":0}}] }
> 2014-07-29 00:00:17,581 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Request:Seq 1-6688126921621898338: { Cmd , Mgm
> tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.RebootCommand":{"vmName":"i-80-146-VM","wait":0}}]
> }
> 2014-07-29 00:00:17,582 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Processing command: com.cloud.agent.api.RebootC
> ommand
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7198) [Automation] Router : SetupGuestNetworkCommand fails while Restarting web server
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078379#comment-14078379
]
Rayees Namathponnan commented on CLOUDSTACK-7198:
-
https://citrix.sharefile.com/d/sa97c00fbe2744cd9
For Logs
> [Automation] Router : SetupGuestNetworkCommand fails while Restarting web
> server
>
>
> Key: CLOUDSTACK-7198
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7198
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
> Environment: KVM (RHEL 6.3)
>Reporter: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.5.0
>
>
> This issue observed in KVM automation , Router : SetupGuestNetworkCommand
> fails while Restarting web server
> 2014-07-29 00:00:13,040 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-2:null) Execution is successful.
> 2014-07-29 00:00:13,041 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Seq 1-6688126921621898335: { Ans: , MgmtId: 29
> 066118877352, via: 1, Ver: v1, Flags: 0,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"","wait":0}}] }
> 2014-07-29 00:00:13,077 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Request:Seq 1-6688126921621898336: { Cmd , Mgm
> tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","
> networkDomain":"cs52auto.advanced","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false
> ,"pxeDisable":true,"nicUuid":"32a59d71-03b6-424d-af2c-94e709d0d998","uuid":"96990ed8-d58c-4c21-beb6-e0d092b92e34","ip":"10.1.1.
> 1","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:65:3e:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri
> ":"vlan://2329","isolationUri":"vlan://2329","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","gue
> st.vlan.tag":"2329","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.255","router.ip":"169.254.1.213","router.name":"r
> -150-VM"},"wait":0}}] }
> 2014-07-29 00:00:13,078 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Processing command: com.cloud.agent.api.SetupGu
> estNetworkCommand
> 2014-07-29 00:00:13,084 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Executing: /usr/share/cloud
> stack-common/scripts/network/domr/router_proxy.sh vpc_guestnw.sh
> 169.254.1.213 -D -M 02:00:65:3e:00:02 -d eth2 -i 10.1.1.1 -g
> 10.1.1.1 -m 24 -n 10.1.1.0 -e cs52auto.advanced
> 2014-07-29 00:00:13,220 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-1:null) Processing command: com.cloud.agent.api.GetVmDi
> skStatsCommand
> 2014-07-29 00:00:17,575 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Execution is successful.
> 2014-07-29 00:00:17,576 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Seq 1-6688126921621898336: { Ans: , MgmtId: 29
> 066118877352, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":true,"details":"Restarting DNS
> forwarder an
> d DHCP server: dnsmasq.\nRestarting web server: apache2 ... waiting apache2:
> Could not reliably determine the server's fully qu
> alified domain name, using 127.0.0.1 for ServerName\napache2: Could not
> reliably determine the server's fully qualified domain
> name, using 127.0.0.1 for ServerName\n.\n","wait":0}}] }
> 2014-07-29 00:00:17,581 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Request:Seq 1-6688126921621898338: { Cmd , Mgm
> tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.RebootCommand":{"vmName":"i-80-146-VM","wait":0}}]
> }
> 2014-07-29 00:00:17,582 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Processing command: com.cloud.agent.api.RebootC
> ommand
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-7198) [Automation] Router : SetupGuestNetworkCommand fails while Restarting web server
Rayees Namathponnan created CLOUDSTACK-7198:
---
Summary: [Automation] Router : SetupGuestNetworkCommand fails
while Restarting web server
Key: CLOUDSTACK-7198
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7198
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Affects Versions: 4.5.0
Environment: KVM (RHEL 6.3)
Reporter: Rayees Namathponnan
Priority: Critical
Fix For: 4.5.0
This issue observed in KVM automation , Router : SetupGuestNetworkCommand fails
while Restarting web server
2014-07-29 00:00:13,040 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-2:null) Execution is successful.
2014-07-29 00:00:13,041 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:null)
Seq 1-6688126921621898335: { Ans: , MgmtId: 29
066118877352, via: 1, Ver: v1, Flags: 0,
[{"com.cloud.agent.api.Answer":{"result":true,"details":"","wait":0}}] }
2014-07-29 00:00:13,077 DEBUG [cloud.agent.Agent] (agentRequest-Handler-3:null)
Request:Seq 1-6688126921621898336: { Cmd , Mgm
tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
[{"com.cloud.agent.api.SetupGuestNetworkCommand":{"dhcpRange":"10.1.1.1","
networkDomain":"cs52auto.advanced","isRedundant":false,"add":false,"nic":{"deviceId":2,"networkRateMbps":200,"defaultNic":false
,"pxeDisable":true,"nicUuid":"32a59d71-03b6-424d-af2c-94e709d0d998","uuid":"96990ed8-d58c-4c21-beb6-e0d092b92e34","ip":"10.1.1.
1","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:65:3e:00:02","broadcastType":"Vlan","type":"Guest","broadcastUri
":"vlan://2329","isolationUri":"vlan://2329","isSecurityGroupEnabled":false},"accessDetails":{"router.guest.ip":"10.1.1.1","gue
st.vlan.tag":"2329","guest.network.gateway":"10.1.1.1","guest.bridge":"10.1.1.255","router.ip":"169.254.1.213","router.name":"r
-150-VM"},"wait":0}}] }
2014-07-29 00:00:13,078 DEBUG [cloud.agent.Agent] (agentRequest-Handler-3:null)
Processing command: com.cloud.agent.api.SetupGu
estNetworkCommand
2014-07-29 00:00:13,084 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-3:null) Executing: /usr/share/cloud
stack-common/scripts/network/domr/router_proxy.sh vpc_guestnw.sh 169.254.1.213
-D -M 02:00:65:3e:00:02 -d eth2 -i 10.1.1.1 -g
10.1.1.1 -m 24 -n 10.1.1.0 -e cs52auto.advanced
2014-07-29 00:00:13,220 DEBUG [cloud.agent.Agent] (agentRequest-Handler-1:null)
Processing command: com.cloud.agent.api.GetVmDi
skStatsCommand
2014-07-29 00:00:17,575 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-3:null) Execution is successful.
2014-07-29 00:00:17,576 DEBUG [cloud.agent.Agent] (agentRequest-Handler-3:null)
Seq 1-6688126921621898336: { Ans: , MgmtId: 29
066118877352, via: 1, Ver: v1, Flags: 110,
[{"com.cloud.agent.api.Answer":{"result":true,"details":"Restarting DNS
forwarder an
d DHCP server: dnsmasq.\nRestarting web server: apache2 ... waiting apache2:
Could not reliably determine the server's fully qu
alified domain name, using 127.0.0.1 for ServerName\napache2: Could not
reliably determine the server's fully qualified domain
name, using 127.0.0.1 for ServerName\n.\n","wait":0}}] }
2014-07-29 00:00:17,581 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:null)
Request:Seq 1-6688126921621898338: { Cmd , Mgm
tId: 29066118877352, via: 1, Ver: v1, Flags: 100111,
[{"com.cloud.agent.api.RebootCommand":{"vmName":"i-80-146-VM","wait":0}}]
}
2014-07-29 00:00:17,582 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:null)
Processing command: com.cloud.agent.api.RebootC
ommand
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7011) [Automation] No logs being generated because Logs are created as root instead of cloud user
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-7011: Assignee: Rayees Namathponnan (was: Nitin Mehta) > [Automation] No logs being generated because Logs are created as root instead > of cloud user > --- > > Key: CLOUDSTACK-7011 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7011 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.4.0 > Environment: 4.4-forward > RPM build >Reporter: Rayees Namathponnan >Assignee: Rayees Namathponnan >Priority: Critical > Fix For: 4.4.0 > > > Steps to reproduce > 1 ) Create RPM build from centos > 2) Install MS > 3) Uninstall MS and Delete MS > 4) Install MS again > 5) Setup MS > Expected result > Installation should be succeeded, and during setup MS, logs should be > captured in MS log > Result > MS log user is root and nothing capturing in MS log, see the permission below > -rw-rw-r--. 1 cloud cloud 12518422 Jun 30 09:50 access_log.2014-06-30.txt > -rw-rw-r--. 1 cloud cloud 38500897 Jun 30 09:50 apilog.log > -rw-r--r--. 1 root root 0 Jun 30 00:27 api-server.log > -rw-rw-r--. 1 cloud cloud0 Jun 30 00:27 catalina.2014-06-30.log > -rw-r--r--. 1 cloud cloud 24646600 Jun 30 09:50 catalina.out > -rw-rw-r--. 1 cloud cloud0 Jun 30 00:27 host-manager.2014-06-30.log > -rw-rw-r--. 1 cloud cloud 874 Jun 30 00:43 localhost.2014-06-30.log > -rw-r--r--. 1 root root 0 Jun 30 00:27 management-server.log > -rw-rw-r--. 1 cloud cloud0 Jun 30 00:27 manager.2014-06-30.log > -rw-r--r--. 1 root root 4479 Jun 30 00:27 setupManagement.log -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6866) First Class object hiding feature is not working for VirtualMachine and Networks resources
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk reassigned CLOUDSTACK-6866: - Assignee: Alena Prokharchyk > First Class object hiding feature is not working for VirtualMachine and > Networks resources > -- > > Key: CLOUDSTACK-6866 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6866 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.4.0 > Environment: Observed it on 4.4 branch. >Reporter: Girish Chaudhari >Assignee: Alena Prokharchyk > > Using Admin user, the Display flag can be applied for Virtual Machine and > Networks resources. But when the list API get called on the respective > resources, it is returning wrong results. The object get hided from normal > users as well from Admin user. > I haven't check rest of the mentioned first class resources yet. > Expected results: > The resource which is marked with Display flag as '0' (False) should be hided > from normal user only, not from the Admin user -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6168) vm.instancename.flag inefficient
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk resolved CLOUDSTACK-6168. --- Resolution: Fixed > vm.instancename.flag inefficient > > > Key: CLOUDSTACK-6168 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6168 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: Cloudstack 4.2.1 on >Reporter: JF Vincent >Assignee: Alena Prokharchyk > Fix For: 4.5.0 > > > have set vm.instancename.flag to YES, restarted the management server > -> started a new instance in my KVM zone with or without any display name => > no change on instance name on hypervisor. > -> started a new instance in my vCenter zone with a display name madrid. > Instance name on ESXi is just madrid and not i-xx--madrid. > Regards > JF -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-375) Unable to delete physical network - because there are other networks attached
[
https://issues.apache.org/jira/browse/CLOUDSTACK-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alena Prokharchyk reassigned CLOUDSTACK-375:
Assignee: Alena Prokharchyk
> Unable to delete physical network - because there are other networks attached
> -
>
> Key: CLOUDSTACK-375
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-375
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.0.0, 4.1.0, 4.2.0
> Environment: CS 4.1
> CentOS6.3
>Reporter: ilya musayev
>Assignee: Alena Prokharchyk
> Labels: Network
> Fix For: 4.4.0
>
>
> Unable to delete physical network - because there are other networks attached
> Attempted to do a complete cleanup of the setup and start fresh.. I was able
> to delete hosts, cluster and pod but when i get to delete the Zone, i need to
> first delete the Physical Network. The physical network has other networks
> under L2/L3 switch (Guest, Management and Storage) with no IP addresses
> assigned or visible.
> When i attempt to delete the Physical Network, i get the error "The Physical
> Network is not deletable because there are networks associated to this
> physical network"
> 2012-10-18 18:40:56,824 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-4:null) submit async job-21, details: AsyncJobVO {id:21,
> userId: 2, accountId: 2, sessionKey: null, instanceType: PhysicalNetwork,
> instanceId: null, cmd: com.cloud.api.commands.DeletePhysicalNetworkCmd,
> cmdOriginator: null, cmdInfo:
> {"id":"b44e7b2c-27bc-41c7-837c-f0c37a9a85d6","response":"json","sessionkey":"f8xnTzQ2eSRR33zf93kijnlDg+w\u003d","ctxUserId":"2","_":"1350600056737","ctxAccountId":"2","ctxStartEventId":"85"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 345051904793,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2012-10-18 18:40:56,843 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-1:job-21) Executing
> com.cloud.api.commands.DeletePhysicalNetworkCmd for job-21
> 2012-10-18 18:40:56,923 ERROR [cloud.api.ApiDispatcher]
> (Job-Executor-1:job-21) Exception while executing DeletePhysicalNetworkCmd:
> com.cloud.utils.exception.CloudRuntimeException: The Physical Network is not
> deletable because there are networks associated to this physical network
> at
> com.cloud.network.NetworkManagerImpl.checkIfPhysicalNetworkIsDeletable(NetworkManagerImpl.java:5541)
> at
> com.cloud.network.NetworkManagerImpl.deletePhysicalNetwork(NetworkManagerImpl.java:5434)
> at
> com.cloud.utils.component.ComponentLocator$InterceptorDispatcher.intercept(ComponentLocator.java:1231)
> at
> com.cloud.api.commands.DeletePhysicalNetworkCmd.execute(DeletePhysicalNetworkCmd.java:74)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:138)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:432)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> I however cannot delete the other networks or anything underneath those
> networks - nothing is available that can be deleted.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6168) vm.instancename.flag inefficient
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078116#comment-14078116 ] ASF subversion and git services commented on CLOUDSTACK-6168: - Commit 3d34a136a6b7d0a36838069d2fe29d59e1df9798 in cloudstack's branch refs/heads/master from [~alena1108] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3d34a13 ] CLOUDSTACK-6168: fixed the description for global config "vm.instancename.flag" - the flag is applicable for VMware hypervisor only > vm.instancename.flag inefficient > > > Key: CLOUDSTACK-6168 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6168 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: Cloudstack 4.2.1 on >Reporter: JF Vincent >Assignee: Alena Prokharchyk > Fix For: 4.5.0 > > > have set vm.instancename.flag to YES, restarted the management server > -> started a new instance in my KVM zone with or without any display name => > no change on instance name on hypervisor. > -> started a new instance in my vCenter zone with a display name madrid. > Instance name on ESXi is just madrid and not i-xx--madrid. > Regards > JF -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6168) vm.instancename.flag inefficient
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078081#comment-14078081
]
Alena Prokharchyk commented on CLOUDSTACK-6168:
---
vm.instancename.flag applies just to vmWare hypervisor. The logic is the
following:
if (_instanceNameFlag && hypervisor.equals(HypervisorType.VMware)) {
logic for vmWare
if (hostName == null) {
if (displayName != null) { if displayName is passed in,
then the host name on vmWare hypervisor will be set to displayName
(instance.name is ignored)
hostName = displayName;
} else { --only if
display name is equals to NULL, then we will generate the vm's host name as
i-xx--"instance.name"
hostName = generateHostName(uuidName);
}
}
} else { -- for all other hypervisors, _instanceNameFlag doesn't
have any affect
if (hostName == null) {
//Generate name using uuid and instance.name global config
hostName = generateHostName(uuidName);
}
}
I will update the doc for "vm.instancename.flag" saying that this parameter
applies to instances starting on VmWare hypervisor only.
> vm.instancename.flag inefficient
>
>
> Key: CLOUDSTACK-6168
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6168
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: Cloudstack 4.2.1 on
>Reporter: JF Vincent
>Assignee: Alena Prokharchyk
> Fix For: 4.5.0
>
>
> have set vm.instancename.flag to YES, restarted the management server
> -> started a new instance in my KVM zone with or without any display name =>
> no change on instance name on hypervisor.
> -> started a new instance in my vCenter zone with a display name madrid.
> Instance name on ESXi is just madrid and not i-xx--madrid.
> Regards
> JF
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6886) Cannot add SDX Netscaler device
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Stevens resolved CLOUDSTACK-6886. -- Resolution: Fixed Fix Version/s: 4.3.1 4.5.0 4.4.0 The master branch (4.5), the 4.4 branch (4.4.1) and the 4.3.1 branch have all been updated with this fix. > Cannot add SDX Netscaler device > --- > > Key: CLOUDSTACK-6886 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6886 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.3.0 > Environment: CloudStack 4.3 build with noredist packages >Reporter: Pierre-Luc Dion >Assignee: Will Stevens > Fix For: 4.4.0, 4.5.0, 4.3.1 > > Attachments: cs4.3_SDXfail.png > > > on CloudStack 4.3 with noredist packages, Adding a Netscaler device in > Network Service Providers as "NetScaler SDX LoadBalancer" type failed with > following error message: > "Failed to enable ssl feature on load balancer due to null" > Test perform using CloudStack webui. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6886) Cannot add SDX Netscaler device
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078029#comment-14078029 ] Will Stevens commented on CLOUDSTACK-6886: -- I have committed a fix on 'master' (4.5), the 4.4 branch (4.4.1) and Seb cherry picked the fix back into the 4.3.1 branch. I am going to mark this issue as resolved... > Cannot add SDX Netscaler device > --- > > Key: CLOUDSTACK-6886 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6886 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.3.0 > Environment: CloudStack 4.3 build with noredist packages >Reporter: Pierre-Luc Dion >Assignee: Will Stevens > Attachments: cs4.3_SDXfail.png > > > on CloudStack 4.3 with noredist packages, Adding a Netscaler device in > Network Service Providers as "NetScaler SDX LoadBalancer" type failed with > following error message: > "Failed to enable ssl feature on load balancer due to null" > Test perform using CloudStack webui. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-67) Resizing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk reassigned CLOUDSTACK-67: --- Assignee: Mike Tutkowski Mike, I believe volume resize is now supported for KVM, VMware, XenServer? Can you please confirm and close the bug if thats true. > Resizing > > > Key: CLOUDSTACK-67 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-67 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: XxYton >Assignee: Mike Tutkowski > Fix For: Future > > > Resizing of volumes and instances is not possible right now. > Instance resizing should be done without rebooting the VM if supported by > hypervisor. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-240) Create-Tag feature is not avialable for VPN Customer Gateway
[ https://issues.apache.org/jira/browse/CLOUDSTACK-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk updated CLOUDSTACK-240: - Fix Version/s: (was: Future) 4.5.0 > Create-Tag feature is not avialable for VPN Customer Gateway > - > > Key: CLOUDSTACK-240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-240 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI >Affects Versions: pre-4.0.0 >Reporter: prashant kumar mishra >Priority: Minor > Fix For: 4.5.0 > > > There is no option to tag VPN Customer Gateway. > Steps to check > -- > -- > 1-Go to network tab > 2-From select view select VPN Customer Gateway > 3- Click on add VPN Customer Gateway > 5-Select the VPN Customer Gateway > 6-there is no option to create/add Tag for VPN Customer Gateway > Release Planning: > Dev List Discussion: Unknown > Functional Spec: N/A > Feature Branch: Unknown > Documentation: Not needed > QA: Needs to be tested -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6886) Cannot add SDX Netscaler device
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078002#comment-14078002 ] ASF subversion and git services commented on CLOUDSTACK-6886: - Commit 877c2d2f6dbc94aa3e093da101f48751e5668f26 in cloudstack's branch refs/heads/4.4 from [~wstevens] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=877c2d2 ] CLOUDSTACK-6886: fixed netscaler sdx issue with the ssl feature > Cannot add SDX Netscaler device > --- > > Key: CLOUDSTACK-6886 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6886 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.3.0 > Environment: CloudStack 4.3 build with noredist packages >Reporter: Pierre-Luc Dion >Assignee: Will Stevens > Attachments: cs4.3_SDXfail.png > > > on CloudStack 4.3 with noredist packages, Adding a Netscaler device in > Network Service Providers as "NetScaler SDX LoadBalancer" type failed with > following error message: > "Failed to enable ssl feature on load balancer due to null" > Test perform using CloudStack webui. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-1093) Deprecate current api server and developer a REST compliant API Server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk updated CLOUDSTACK-1093: -- Issue Type: Improvement (was: Bug) > Deprecate current api server and developer a REST compliant API Server > -- > > Key: CLOUDSTACK-1093 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1093 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav > Fix For: Future > > > Deprecate current apis and api server over next 1-2 years and develop a REST > compliant api server using JAX-RS or better technologies. The server should > be a separate component and not another monolithic entities inside CloudStack. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-3414) [UI] [DOC] Inform Admin that Physical Netwok traffic label update requires Management Server restart
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alena Prokharchyk updated CLOUDSTACK-3414:
--
Summary: [UI] [DOC] Inform Admin that Physical Netwok traffic label update
requires Management Server restart (was: Physical Netwok traffic lable update
requires Management Server restart )
> [UI] [DOC] Inform Admin that Physical Netwok traffic label update requires
> Management Server restart
> -
>
> Key: CLOUDSTACK-3414
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3414
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Doc, UI
>Affects Versions: 4.2.0
>Reporter: Sailaja Mada
> Fix For: Future
>
>
> Setup : VMWARE Adv Zone.
> Note: This issue may not be specific to VMWARE
> Steps:
> 1. Tried to configure Adv Zone with VMWARE
> 2. Configure Physical network 1 with Management Traffic with invalid traffic
> label ( Ex: vSwitch0,,vmwaresvs)
> 3. Configure Physical network 2 with public & guest Traffic with correct
> DVSwitch traffic label ( Ex: newdv1,,vmwaredvs)
> 4. Now System VM's are failed to start as it failed to create network for
> Mgmt traffic.
> 2013-07-09 14:00:50,521 INFO [vmware.resource.VmwareResource]
> (DirectAgent-7:10.102.192.18) Prepare NIC device based on NicTO:
> {"deviceId":0,"networkRateMbps":-1,"defaultNic":false,"uuid":"789e034d-e287-4389-beac-29a10326c0ea","mac":"02:00:41:48:00:05","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false}
> 2013-07-09 14:00:50,525 INFO [vmware.resource.VmwareResource]
> (DirectAgent-7:10.102.192.18) Prepare network on vmwaresvs
> P[vSwitch0,,vmwaresvs:untagged] with name prefix: cloud.private
> 2013-07-09 14:00:50,525 WARN [vmware.resource.VmwareResource]
> (DirectAgent-7:10.102.192.18) Unrecognized broadcast type in VmwareResource,
> type: LinkLocal. Use vlan info from labeling: untagged
> 2013-07-09 14:00:50,552 ERROR [vmware.mo.HypervisorHostHelper]
> (DirectAgent-7:10.102.192.18) Unable to find vSwitchvSwitch0,,vmwaresvs
> 2013-07-09 14:00:50,553 WARN [vmware.resource.VmwareResource]
> (DirectAgent-7:10.102.192.18) StartCommand failed due to Exception:
> java.lang.Exception
> Message: Unable to find vSwitchvSwitch0,,vmwaresvs
> java.lang.Exception: Unable to find vSwitchvSwitch0,,vmwaresvs
> at
> com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:830)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:2923)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2687)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:479)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-07-09 14:00:50,556 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-7:null) Seq 1-763953202: Cancelling because one of the answers
> is false and it is stop on error.
> 2013-07-09 14:00:50,557 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-7:null) Seq 1-763953202: Response Received:
> 6. Now updated Mgmt traffic label to vSwitch0.
> 7. DB got updated automatically .
> 8. But System Vm's are still failed to start with this
> 9. Restarted Management server (server cloudstack-management stop/ start)
> 10. Now system VM's are up with network name vSwitch0.
> Expected results :
> 1. Changes to Physical network traffic labels should be dynamic,
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6168) vm.instancename.flag inefficient
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk updated CLOUDSTACK-6168: -- Fix Version/s: (was: Future) 4.5.0 > vm.instancename.flag inefficient > > > Key: CLOUDSTACK-6168 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6168 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: Cloudstack 4.2.1 on >Reporter: JF Vincent >Assignee: Alena Prokharchyk > Fix For: 4.5.0 > > > have set vm.instancename.flag to YES, restarted the management server > -> started a new instance in my KVM zone with or without any display name => > no change on instance name on hypervisor. > -> started a new instance in my vCenter zone with a display name madrid. > Instance name on ESXi is just madrid and not i-xx--madrid. > Regards > JF -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-4743) VPC: applyStaticRoutes/createPrivateGatway/deletePrivateGateway - read from vpc_service_map table instead of relying on hardcoded values
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk updated CLOUDSTACK-4743: -- Issue Type: Improvement (was: Bug) > VPC: applyStaticRoutes/createPrivateGatway/deletePrivateGateway - read from > vpc_service_map table instead of relying on hardcoded values > > > Key: CLOUDSTACK-4743 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4743 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.1 >Reporter: Alena Prokharchyk > Fix For: Future > > > Following needs to be fixed: > == > 1) Add VPC to the list of services for VPC. This service will determine if > StaticRoute/PrivateGateway can be applied > 2) When apply those services on VPC, check vpc_service_map table. > 3) During the db upgrade, add missing service/provider combination to > vpc_service_map. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-3471) Provide an API to extract the log statements of a given jobid
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk updated CLOUDSTACK-3471: -- Issue Type: Improvement (was: Bug) > Provide an API to extract the log statements of a given jobid > - > > Key: CLOUDSTACK-3471 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3471 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: pre-4.0.0, 4.0.0, 4.1.0 >Reporter: Prasanna Santhanam > Fix For: Future > > > With the job-id in the logs having no link to the external world that is > interacting with the cloudstack API it is not easy to correlate a failure with > a specific job. > With the inclusion of uuids in the management server logs it would be nice to > provide an API extractJobLog that takes a jobid = as parameter so as to > extract all log statements of the job. This will be an admin only API and > ideally a plugin that can be turned off in favour of better log > monitoring/analyis systems. > Having the log makes is useful to link our automated test failures with the > log > from the management server using a simple API call. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6318) Cloudstack upgrade takes long time on big cloud_usage databases
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk resolved CLOUDSTACK-6318. --- Resolution: Won't Fix Resolving as won't fix. DB upgrade should be considered to be completed only when both databases - cloud and cloud_usage are updated. If we postpone cloud_usage db upgrade, it can cause all kinds of problems during the usage record updates. To address "cloud-usage might take longer to update, but is in most of the installation not that critical" - for the environments where usage installation is not critical, this problem - long time update for cloud_usage due to lots of data - won't occur at all. As those environments most likely won't have usage running if usage is irrelevant for them. For the environments where usage matters, we should be consistent with the db upgrade process. > Cloudstack upgrade takes long time on big cloud_usage databases > --- > > Key: CLOUDSTACK-6318 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6318 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.2.0 >Reporter: Andreas Fuchs >Assignee: Alena Prokharchyk >Priority: Minor > Fix For: Future > > > when updating cloudstack on an environement which is already running for a > certain time and has a bigger ammount of instances cloud_usage db will become > quite big. > in this situaion the schema updates for the databases can take quite a long > time, during this time cloudstack management is offline. > proposal: > cloudstack-managent does only schema updates on cloud db > cloudstack-usage does the scema updates on cloud_usage > this way cloudstack-management will be back online after the update much > quicker and only dependant of the size of cloud db > cloud-usage might take longer to update, but is in most of the installation > not that critical -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6168) vm.instancename.flag inefficient
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk reassigned CLOUDSTACK-6168: - Assignee: Alena Prokharchyk > vm.instancename.flag inefficient > > > Key: CLOUDSTACK-6168 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6168 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: Cloudstack 4.2.1 on >Reporter: JF Vincent >Assignee: Alena Prokharchyk > Fix For: Future > > > have set vm.instancename.flag to YES, restarted the management server > -> started a new instance in my KVM zone with or without any display name => > no change on instance name on hypervisor. > -> started a new instance in my vCenter zone with a display name madrid. > Instance name on ESXi is just madrid and not i-xx--madrid. > Regards > JF -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6318) Cloudstack upgrade takes long time on big cloud_usage databases
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk reassigned CLOUDSTACK-6318: - Assignee: Alena Prokharchyk > Cloudstack upgrade takes long time on big cloud_usage databases > --- > > Key: CLOUDSTACK-6318 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6318 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.2.0 >Reporter: Andreas Fuchs >Assignee: Alena Prokharchyk >Priority: Minor > Fix For: Future > > > when updating cloudstack on an environement which is already running for a > certain time and has a bigger ammount of instances cloud_usage db will become > quite big. > in this situaion the schema updates for the databases can take quite a long > time, during this time cloudstack management is offline. > proposal: > cloudstack-managent does only schema updates on cloud db > cloudstack-usage does the scema updates on cloud_usage > this way cloudstack-management will be back online after the update much > quicker and only dependant of the size of cloud db > cloud-usage might take longer to update, but is in most of the installation > not that critical -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7173) Resizing of data volume is throwing java NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077683#comment-14077683
]
Alex Brett commented on CLOUDSTACK-7173:
Review posted at https://reviews.apache.org/r/24050/
> Resizing of data volume is throwing java NPE
>
>
> Key: CLOUDSTACK-7173
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7173
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Volumes
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: log.tar.gz
>
>
> Repro steps :
> 1. Create a Vm with data disk
> 2 . try to resize the data disk
> Bug :
> Resize will fail Ms log shows :
> 2014-07-23 05:34:53,366 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-5:ctx-2f1038c6 job-300/job-301) Unable to complete
> AsyncJobVO {id:301, userId: 2, accountId: 2, instanceType: null, instanceId:
> null, cmd: com.cloud.storage.VmWorkResizeVolume, cmdInfo:
> rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtSZXNpemVWb2x1bWVU03zH0Fe-ggIAB0oAC2N1cnJlbnRTaXplSgAHbmV3U2l6ZVoACHNocmlua09rSgAIdm9sdW1lSWRMAApuZXdNYXhJb3BzdAAQTGphdmEvbGFuZy9Mb25nO0wACm5ld01pbklvcHNxAH4AAUwAFG5ld1NlcnZpY2VPZmZlcmluZ0lkcQB-AAF4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACACZ0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbAFABQAAACtwcHNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAABA,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 233845177509765, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Wed Jul 23 05:34:53 EDT 2014}, job origin:300
> java.lang.NullPointerException
> at
> com.cloud.storage.VmWorkResizeVolume.getNewMinIops(VmWorkResizeVolume.java:59)
> at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(VolumeApiServiceImpl.java:2630)
> 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:601)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2654)
> 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:601)
> 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.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 $Proxy183.handleVmWorkJob(Unknown Source)
> at
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:507)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:464)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.
[jira] [Commented] (CLOUDSTACK-7173) Resizing of data volume is throwing java NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077663#comment-14077663
]
Alex Brett commented on CLOUDSTACK-7173:
Looking in the code, there's a few variables here that are Long objects rather
than a long primitive, yet have getters that return long primitives. The
problem we're hitting here is something is calling getNewMinIops(), which is
trying to cast a null Long value to a long, thus raising an NPE.
The call being made here is to provide it to something that is expecting a Long
object, so I think the fix is as simple as changing the getters to return a
Long rather than a long. I'll put a patch together that does this...
> Resizing of data volume is throwing java NPE
>
>
> Key: CLOUDSTACK-7173
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7173
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Volumes
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: log.tar.gz
>
>
> Repro steps :
> 1. Create a Vm with data disk
> 2 . try to resize the data disk
> Bug :
> Resize will fail Ms log shows :
> 2014-07-23 05:34:53,366 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-5:ctx-2f1038c6 job-300/job-301) Unable to complete
> AsyncJobVO {id:301, userId: 2, accountId: 2, instanceType: null, instanceId:
> null, cmd: com.cloud.storage.VmWorkResizeVolume, cmdInfo:
> rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtSZXNpemVWb2x1bWVU03zH0Fe-ggIAB0oAC2N1cnJlbnRTaXplSgAHbmV3U2l6ZVoACHNocmlua09rSgAIdm9sdW1lSWRMAApuZXdNYXhJb3BzdAAQTGphdmEvbGFuZy9Mb25nO0wACm5ld01pbklvcHNxAH4AAUwAFG5ld1NlcnZpY2VPZmZlcmluZ0lkcQB-AAF4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACACZ0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbAFABQAAACtwcHNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAABA,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 233845177509765, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Wed Jul 23 05:34:53 EDT 2014}, job origin:300
> java.lang.NullPointerException
> at
> com.cloud.storage.VmWorkResizeVolume.getNewMinIops(VmWorkResizeVolume.java:59)
> at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(VolumeApiServiceImpl.java:2630)
> 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:601)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2654)
> 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:601)
> 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.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 $Proxy183.handleVmWorkJob(Unknown Source)
> at
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:507)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
>
