[jira] [Commented] (CLOUDSTACK-6151) Local data disk with tag goes to the wrong local storage pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920676#comment-13920676 ] ASF subversion and git services commented on CLOUDSTACK-6151: - Commit a8b34c0c4f99067243524813f136b31cb78c5f78 in cloudstack's branch refs/heads/4.3-forward from [~saksham] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a8b34c0 ] CLOUDSTACK-6151: Local data disk with tag goes to the wrong local storage pool Signed-off-by: Koushik Das kous...@apache.org Local data disk with tag goes to the wrong local storage pool - Key: CLOUDSTACK-6151 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6151 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Saksham Srivastava Assignee: Saksham Srivastava Fix For: 4.4.0 In case of attaching Volume we are not honoring the tags of the volume and the storage pool. Often the disk goes to the wrong local storage pool in case of multiple local storages on a single host. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-3367) When one primary storage fails, all XenServer hosts get rebooted, killing all VMs, even those not on this primary storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920762#comment-13920762 ] France commented on CLOUDSTACK-3367: Just an idea for whomever picks this issue up (if anyone at all :( ). Before killing the whole hypervisor host, maybe live migrate instances who's private storage is still functioning to another hypervisor. When one primary storage fails, all XenServer hosts get rebooted, killing all VMs, even those not on this primary storage. -- Key: CLOUDSTACK-3367 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3367 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, XenServer Affects Versions: 4.1.0, 4.2.0 Environment: CentOS 6.3, XenServer 6.0.2 + all hotfixes, CloudStack 4.1.0 Reporter: France Fix For: Future As the title says: if only one of the primary storages fails, all XenServer hosts get rebooted one by one. Because i have many primary storages, which are/were running fine with other VMs, rebooting XenServer Hipervisor is an overkill. Please disable this or implement just stopping/killing the VMs running on that storage and try to re-attach that storage only. Problem was reported on the mailing list, as well as a workaround for XenServer. So i'm not the only one hit by this bug/feature. Workaround for now is as follows: 1. Modify /opt/xensource/bin/xenheartbeat.sh on all your Hosts, commenting out the two entries which have reboot -f 2. Identify the PID of the script - pidof -x xenheartbeat.sh 3. Restart the Script - kill pid 4. Force reconnect Host from the UI, the script will then re-launch on reconnect -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5946) SSL: Fail to find the generated keystore. Loading fail-safe one to continue.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920778#comment-13920778 ] Vadim Kim. commented on CLOUDSTACK-5946: Since I have empty instance full log is really short: 2014-03-02 00:16:54,257 WARN [utils.nio.Link] (AgentManager-Selector:null) SSL: Fail to find the generated keystore. Loading fail-safe one to continue. 2014-03-02 00:16:55,481 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:null) Found 0 routers to update status. 2014-03-02 00:16:55,482 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:null) Found 0 networks to update RvR status. 2014-03-02 00:16:56,259 WARN [utils.nio.Link] (AgentManager-Selector:null) SSL: Fail to find the generated keystore. Loading fail-safe one to continue. 2014-03-02 00:16:58,261 WARN [utils.nio.Link] (AgentManager-Selector:null) SSL: Fail to find the generated keystore. Loading fail-safe one to continue. 2014-03-02 00:17:00,263 WARN [utils.nio.Link] (AgentManager-Selector:null) SSL: Fail to find the generated keystore. Loading fail-safe one to continue. 2014-03-02 00:17:02,265 WARN [utils.nio.Link] (AgentManager-Selector:null) SSL: Fail to find the generated keystore. Loading fail-safe one to continue. 2014-03-02 00:17:04,267 WARN [utils.nio.Link] (AgentManager-Selector:null) SSL: Fail to find the generated keystore. Loading fail-safe one to continue. 2014-03-02 00:17:06,269 WARN [utils.nio.Link] (AgentManager-Selector:null) SSL: Fail to find the generated keystore. Loading fail-safe one to continue. 2014-03-02 00:17:08,271 WARN [utils.nio.Link] (AgentManager-Selector:null) SSL: Fail to find the generated keystore. Loading fail-safe one to continue. 2014-03-02 00:17:10,274 WARN [utils.nio.Link] (AgentManager-Selector:null) SSL: Fail to find the generated keystore. Loading fail-safe one to continue. 2014-03-02 00:17:12,276 WARN [utils.nio.Link] (AgentManager-Selector:null) SSL: Fail to find the generated keystore. Loading fail-safe one to continue. 2014-03-02 00:17:14,278 WARN [utils.nio.Link] (AgentManager-Selector:null) SSL: Fail to find the generated keystore. Loading fail-safe one to continue. 2014-03-02 00:17:16,279 WARN [utils.nio.Link] (AgentManager-Selector:null) SSL: Fail to find the generated keystore. Loading fail-safe one to continue. 2014-03-02 00:17:18,281 WARN [utils.nio.Link] (AgentManager-Selector:null) SSL: Fail to find the generated keystore. Loading fail-safe one to continue. 2014-03-02 00:17:20,283 WARN [utils.nio.Link] (AgentManager-Selector:null) SSL: Fail to find the generated keystore. Loading fail-safe one to continue. 2014-03-02 00:17:22,285 WARN [utils.nio.Link] (AgentManager-Selector:null) SSL: Fail to find the generated keystore. Loading fail-safe one to continue. 2014-03-02 00:17:24,053 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl] (consoleproxy-1:null) Skip capacity scan due to there is no Primary Storage UPintenance mode 2014-03-02 00:17:24,288 WARN [utils.nio.Link] (AgentManager-Selector:null) SSL: Fail to find the generated keystore. Loading fail-safe one to continue. and so on... SSL: Fail to find the generated keystore. Loading fail-safe one to continue. Key: CLOUDSTACK-5946 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5946 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.1 Environment: CentOS 6.4 x64 Reporter: Vadim Kim. Priority: Minor Management logs are full of this warning. deleting file /etc/cloudstack/management/cloudmanagementserver.keystore seems to fix the problem. System re-crates it later and does not issue warnings anymore -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5080) Hypervisor Capabilities table missing entry for Simulator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920831#comment-13920831 ] ASF subversion and git services commented on CLOUDSTACK-5080: - Commit 844ebab3f65614722fd9cbf61ab9c6f736af7ec0 in cloudstack's branch refs/heads/4.3-forward from [~dgrizzanti] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=844ebab ] CLOUDSTACK-5080: Hypervisor Capabilities table missing entry for Simulator Signed-off-by: Prasanna Santhanam t...@apache.org Hypervisor Capabilities table missing entry for Simulator - Key: CLOUDSTACK-5080 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5080 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: David Grizzanti Assignee: David Grizzanti During db setup for the simulator, there is an entry needed in the hypervisor_capabilities table in order for certain operations in the orchestration environment to work. An insert should be done to this table for the Simulator hypervisor type. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5920) CloudStack IAM Plugin feature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13921130#comment-13921130 ] ASF subversion and git services commented on CLOUDSTACK-5920: - Commit c28450c1cdb51fba035f8f8f864dd0450ea1e099 in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c28450c ] CLOUDSTACK-5920: IAM service plugin. CloudStack IAM Plugin feature - Key: CLOUDSTACK-5920 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5920 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: API, Management Server Affects Versions: 4.3.0 Reporter: Prachi Damle Assignee: Prachi Damle Fix For: 4.4.0 Currently CloudStack provides very limited IAM services and there are several drawbacks within those services: - Offers few roles out of the box (user and admin) with prebaked access control for these roles. There is no way to create additional roles with customized permissions. - Some resources have access control baked into them. E.g., shared networks, projects etc. - We have to create special dedicate APIs to grant permissions to resources. - Also it should be based on a plugin model to be possible to integrate with other RBAC implementations say using AD/LDAP in future Goal for this feature would be to address these limitations and offer true IAM services in a phased manner. As a first phase, we need to separate out the current access control into a separate component and create a standard access check mechanism to be used by the API layer. Also the read/listing APIs need to be refactored accordingly to consider the role based access granting. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5920) CloudStack IAM Plugin feature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13921127#comment-13921127 ] ASF subversion and git services commented on CLOUDSTACK-5920: - Commit d0ae4d9a9f7dc2ef39ee24f09c36f67ccb7502d7 in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d0ae4d9 ] CLOUDSTACK-5920:Add interface to ControlledEntity to return IAM entity type. CloudStack IAM Plugin feature - Key: CLOUDSTACK-5920 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5920 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: API, Management Server Affects Versions: 4.3.0 Reporter: Prachi Damle Assignee: Prachi Damle Fix For: 4.4.0 Currently CloudStack provides very limited IAM services and there are several drawbacks within those services: - Offers few roles out of the box (user and admin) with prebaked access control for these roles. There is no way to create additional roles with customized permissions. - Some resources have access control baked into them. E.g., shared networks, projects etc. - We have to create special dedicate APIs to grant permissions to resources. - Also it should be based on a plugin model to be possible to integrate with other RBAC implementations say using AD/LDAP in future Goal for this feature would be to address these limitations and offer true IAM services in a phased manner. As a first phase, we need to separate out the current access control into a separate component and create a standard access check mechanism to be used by the API layer. Also the read/listing APIs need to be refactored accordingly to consider the role based access granting. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5920) CloudStack IAM Plugin feature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13921129#comment-13921129 ] ASF subversion and git services commented on CLOUDSTACK-5920: - Commit adb29b21402d4b446471c2d2741e09cd7b2106aa in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=adb29b2 ] CLOUDSTACK-5920: IAM service server. CloudStack IAM Plugin feature - Key: CLOUDSTACK-5920 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5920 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: API, Management Server Affects Versions: 4.3.0 Reporter: Prachi Damle Assignee: Prachi Damle Fix For: 4.4.0 Currently CloudStack provides very limited IAM services and there are several drawbacks within those services: - Offers few roles out of the box (user and admin) with prebaked access control for these roles. There is no way to create additional roles with customized permissions. - Some resources have access control baked into them. E.g., shared networks, projects etc. - We have to create special dedicate APIs to grant permissions to resources. - Also it should be based on a plugin model to be possible to integrate with other RBAC implementations say using AD/LDAP in future Goal for this feature would be to address these limitations and offer true IAM services in a phased manner. As a first phase, we need to separate out the current access control into a separate component and create a standard access check mechanism to be used by the API layer. Also the read/listing APIs need to be refactored accordingly to consider the role based access granting. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5920) CloudStack IAM Plugin feature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13921131#comment-13921131 ] ASF subversion and git services commented on CLOUDSTACK-5920: - Commit 63e3eea7905e22cab9466b28a2ab2a80b586aeed in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=63e3eea ] CLOUDSTACK-5920: enable build of IAM services in pom.xml. CloudStack IAM Plugin feature - Key: CLOUDSTACK-5920 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5920 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: API, Management Server Affects Versions: 4.3.0 Reporter: Prachi Damle Assignee: Prachi Damle Fix For: 4.4.0 Currently CloudStack provides very limited IAM services and there are several drawbacks within those services: - Offers few roles out of the box (user and admin) with prebaked access control for these roles. There is no way to create additional roles with customized permissions. - Some resources have access control baked into them. E.g., shared networks, projects etc. - We have to create special dedicate APIs to grant permissions to resources. - Also it should be based on a plugin model to be possible to integrate with other RBAC implementations say using AD/LDAP in future Goal for this feature would be to address these limitations and offer true IAM services in a phased manner. As a first phase, we need to separate out the current access control into a separate component and create a standard access check mechanism to be used by the API layer. Also the read/listing APIs need to be refactored accordingly to consider the role based access granting. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6202) Support signature version 3 in Cloudmonkey
Chiradeep Vittal created CLOUDSTACK-6202: Summary: Support signature version 3 in Cloudmonkey Key: CLOUDSTACK-6202 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6202 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Cloudmonkey Reporter: Chiradeep Vittal Cloudstack has signatureVersion=3 which supports an 'expires' timestamp. This enhances security by making replay attacks less likely. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-5682) Contrail:MS: Sync virtual Machines fails with exception.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Balineni reassigned CLOUDSTACK-5682:
---
Assignee: Suresh Balineni
Contrail:MS: Sync virtual Machines fails with exception.
Key: CLOUDSTACK-5682
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5682
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Contrail, Management Server
Affects Versions: 4.2.0
Environment: Contrail
Reporter: Parth Jagirdar
Assignee: Suresh Balineni
Priority: Critical
2013-12-30 11:14:50,888 WARN [contrail.management.ServerDBSync]
(DBSyncTimer:null) sync virtual-machines
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor75.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
net.juniper.contrail.management.DBSyncGeneric.equal(DBSyncGeneric.java:136)
at
net.juniper.contrail.management.DBSyncGeneric.syncCollections(DBSyncGeneric.java:237)
at
net.juniper.contrail.management.DBSyncGeneric.syncGeneric(DBSyncGeneric.java:280)
at
net.juniper.contrail.management.ServerDBSyncImpl.syncVirtualMachine(ServerDBSyncImpl.java:649)
at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
net.juniper.contrail.management.DBSyncGeneric.sync(DBSyncGeneric.java:95)
at
net.juniper.contrail.management.ServerDBSyncImpl.syncAll(ServerDBSyncImpl.java:123)
at
net.juniper.contrail.management.ContrailManagerImpl.syncNetworkDB(ContrailManagerImpl.java:456)
at
net.juniper.contrail.management.ContrailManagerImpl$DBSyncTask.run(ContrailManagerImpl.java:473)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Caused by: java.lang.NullPointerException
at
net.juniper.contrail.management.ServerDBSyncImpl.buildNicResources(ServerDBSyncImpl.java:766)
at
net.juniper.contrail.management.ServerDBSyncImpl.equalVirtualMachine(ServerDBSyncImpl.java:789)
at sun.reflect.GeneratedMethodAccessor75.invoke(Unknown Source)
... 15 more
2013-12-30 11:14:50,889 INFO [contrail.management.ServerDBSync]
(DBSyncTimer:null) out of sync detected: VirtualMachine
2013-12-30 11:14:50,889 DEBUG [contrail.management.ServerDBSync]
(DBSyncTimer:null) sync check finish: VirtualMachine
2013-12-30 11:14:50,889 DEBUG [contrail.management.ServerDBSync]
(DBSyncTimer:null) sync check start: ServiceInstance
2013-12-30 11:14:50,889 INFO [contrail.api.ApiConnector] (DBSyncTimer:null)
Request: GET, /service-instances
2013-12-30 11:14:50,892 INFO [contrail.api.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2013-12-30 11:14:50,892 DEBUG [contrail.management.ServerDBSync]
(DBSyncTimer:null) sync check finish: ServiceInstance
2013-12-30 11:14:50,892 DEBUG [contrail.management.ServerDBSync]
(DBSyncTimer:null) sync check start: FloatingIp
2013-12-30 11:14:50,903 INFO [contrail.api.ApiConnector] (DBSyncTimer:null)
Request: POST, /fqname-to-id, {type:fl
oating-ip-pool,fq_name:[default-domain,default-project,__default_Public__,PublicIpPool]}
2013-12-30 11:14:50,906 INFO [contrail.api.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 404 Not Found
2013-12-30 11:14:50,906 DEBUG [contrail.management.DBSyncGeneric]
(DBSyncTimer:null) Generic db sync : FloatingIp
2013-12-30 11:14:50,906 DEBUG [contrail.management.DBSyncGeneric]
(DBSyncTimer:null) Sync state checking statsFloatingIp
: create: 0, delete: 0, equal: 0, diff:0
2013-12-30 11:14:50,906 DEBUG [contrail.management.DBSyncGeneric]
(DBSyncTimer:null) DB and VNC objects are in sync : Flo
atingIp
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-5682) Contrail:MS: Sync virtual Machines fails with exception.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Balineni reassigned CLOUDSTACK-5682:
---
Assignee: Parth Jagirdar (was: Suresh Balineni)
Re-verify in 4.3
Contrail:MS: Sync virtual Machines fails with exception.
Key: CLOUDSTACK-5682
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5682
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Contrail, Management Server
Affects Versions: 4.2.0
Environment: Contrail
Reporter: Parth Jagirdar
Assignee: Parth Jagirdar
Priority: Critical
2013-12-30 11:14:50,888 WARN [contrail.management.ServerDBSync]
(DBSyncTimer:null) sync virtual-machines
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor75.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
net.juniper.contrail.management.DBSyncGeneric.equal(DBSyncGeneric.java:136)
at
net.juniper.contrail.management.DBSyncGeneric.syncCollections(DBSyncGeneric.java:237)
at
net.juniper.contrail.management.DBSyncGeneric.syncGeneric(DBSyncGeneric.java:280)
at
net.juniper.contrail.management.ServerDBSyncImpl.syncVirtualMachine(ServerDBSyncImpl.java:649)
at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
net.juniper.contrail.management.DBSyncGeneric.sync(DBSyncGeneric.java:95)
at
net.juniper.contrail.management.ServerDBSyncImpl.syncAll(ServerDBSyncImpl.java:123)
at
net.juniper.contrail.management.ContrailManagerImpl.syncNetworkDB(ContrailManagerImpl.java:456)
at
net.juniper.contrail.management.ContrailManagerImpl$DBSyncTask.run(ContrailManagerImpl.java:473)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Caused by: java.lang.NullPointerException
at
net.juniper.contrail.management.ServerDBSyncImpl.buildNicResources(ServerDBSyncImpl.java:766)
at
net.juniper.contrail.management.ServerDBSyncImpl.equalVirtualMachine(ServerDBSyncImpl.java:789)
at sun.reflect.GeneratedMethodAccessor75.invoke(Unknown Source)
... 15 more
2013-12-30 11:14:50,889 INFO [contrail.management.ServerDBSync]
(DBSyncTimer:null) out of sync detected: VirtualMachine
2013-12-30 11:14:50,889 DEBUG [contrail.management.ServerDBSync]
(DBSyncTimer:null) sync check finish: VirtualMachine
2013-12-30 11:14:50,889 DEBUG [contrail.management.ServerDBSync]
(DBSyncTimer:null) sync check start: ServiceInstance
2013-12-30 11:14:50,889 INFO [contrail.api.ApiConnector] (DBSyncTimer:null)
Request: GET, /service-instances
2013-12-30 11:14:50,892 INFO [contrail.api.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2013-12-30 11:14:50,892 DEBUG [contrail.management.ServerDBSync]
(DBSyncTimer:null) sync check finish: ServiceInstance
2013-12-30 11:14:50,892 DEBUG [contrail.management.ServerDBSync]
(DBSyncTimer:null) sync check start: FloatingIp
2013-12-30 11:14:50,903 INFO [contrail.api.ApiConnector] (DBSyncTimer:null)
Request: POST, /fqname-to-id, {type:fl
oating-ip-pool,fq_name:[default-domain,default-project,__default_Public__,PublicIpPool]}
2013-12-30 11:14:50,906 INFO [contrail.api.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 404 Not Found
2013-12-30 11:14:50,906 DEBUG [contrail.management.DBSyncGeneric]
(DBSyncTimer:null) Generic db sync : FloatingIp
2013-12-30 11:14:50,906 DEBUG [contrail.management.DBSyncGeneric]
(DBSyncTimer:null) Sync state checking statsFloatingIp
: create: 0, delete: 0, equal: 0, diff:0
2013-12-30 11:14:50,906 DEBUG [contrail.management.DBSyncGeneric]
(DBSyncTimer:null) DB and VNC objects are in sync : Flo
atingIp
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6071) Contrail:MS:DB: DBSync exceptions in MS log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Balineni reassigned CLOUDSTACK-6071:
---
Assignee: Suresh Balineni
Contrail:MS:DB: DBSync exceptions in MS log
---
Key: CLOUDSTACK-6071
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6071
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Contrail, Management Server
Affects Versions: 4.2.1
Environment: Contrail
Reporter: Parth Jagirdar
Assignee: Suresh Balineni
Priority: Critical
Fix For: 4.2.1
MS Log,
2014-02-10 12:23:31,122 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,122 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: GET, /floating-ip-pool/33b357b3-4f88-4ae6-af86-fb86afa3
2014-02-10 12:23:31,125 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,126 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: GET, /floating-ip/6a6fa311-e5a0-4dfb-b289-cbad2122a756
2014-02-10 12:23:31,129 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,130 DEBUG [o.a.c.n.c.m.DBSyncGeneric] (DBSyncTimer:null)
Generic db sync : FloatingIp
2014-02-10 12:23:31,141 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: GET, /virtual-network/e6c067bc-bc63-4613-a7af-84d0182ff6d2
2014-02-10 12:23:31,150 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,155 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: PUT, /virtual-network/e6c067bc-bc63-4613-a7af-84d0182ff6d2,
{virtual-network:{virtual_network_properties:{extend_to_external_routers:false,network_id:4},route_target_list:{route_target:[target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002]},network_ipam_refs:[{to:[default-domain,default-project,default-network-ipam],attr:{ipam_subnets:[{subnet:{ip_prefix:10.223.138.64,ip_prefix_len:26},default_gateway:10.223.138.65}]},href:null,uuid:null}],floating_ip_pools:[{to:[default-domain,default-project,__default_Public__,PublicIpPool],attr:null,href:http://10.223.58.3:8082/floating-ip-pool/33b357b3-4f88-4ae6-af86-fb86afa3,uuid:33b357b3-4f88-4ae6-af86-fb86afa3}],routing_instances:[{to:[default-domain,default-project,__default_Public__,__default_Public__],attr:null,href:http://10.223.58.3:8082/routing-instance/74769566-dfce-4b6d-bbb5-db772bccb2f9,uuid:74769566-dfce-4b6d-bbb5-db772bccb2f9}],name:__default_Public__,uuid:e6c067bc-bc63-4613-a7af-84d0182ff6d2,fq_name:[default-domain,default-project,__default_Public__],parent_type:project,parent_uuid:fafebf0e-5d9c-4c99-928d-25ab65bd7ebc}}
2014-02-10 12:23:31,193 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,194 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: GET, /virtual-machine-interface/07c6bdac-7be4-4d88-83ef-6f5ffe2f8b19
2014-02-10 12:23:31,198 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 404 Not Found
2014-02-10 12:23:31,199 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: POST, /virtual-machine-interfaces,
{virtual-machine-interface:{virtual_machine_interface_mac_addresses:{mac_address:[06:e4:2a:00:00:35]},virtual_network_refs:[{to:[default-domain,default-project,__default_Public__],attr:null,href:null,uuid:null}],name:s-11-VM-2,uuid:07c6bdac-7be4-4d88-83ef-6f5ffe2f8b19,fq_name:[s-11-VM,s-11-VM-2],parent_type:virtual-machine}}
2014-02-10 12:23:31,205 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 400 Bad Request
2014-02-10 12:23:31,205 ERROR [n.j.c.a.ApiConnector] (DBSyncTimer:null)
create api request failed: Bad Request
2014-02-10 12:23:31,206 ERROR [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Failure message:
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
html
head
titleError: 400 Bad Request/title
style type=text/css
html {background-color: #eee; font-family: sans;}
body {background-color: #fff; border: 1px solid #ddd;
padding: 15px; margin: 15px;}
pre {background-color: #eee; border: 1px solid #ddd; padding:
5px;}
/style
/head
body
h1Error: 400 Bad Request/h1
pSorry, the requested URL
tt#039;http://10.223.58.3:8082/virtual-machine-interfaces#039;/tt
caused an error:/p
preParent [u#039;s-11-VM#039;] type virtual-machine does not
exist/pre
/body
[jira] [Assigned] (CLOUDSTACK-6071) Contrail:MS:DB: DBSync exceptions in MS log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Balineni reassigned CLOUDSTACK-6071:
---
Assignee: Parth Jagirdar (was: Suresh Balineni)
This no longer exists in 4.3. Please verify in 4.3
Contrail:MS:DB: DBSync exceptions in MS log
---
Key: CLOUDSTACK-6071
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6071
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Contrail, Management Server
Affects Versions: 4.2.1
Environment: Contrail
Reporter: Parth Jagirdar
Assignee: Parth Jagirdar
Priority: Critical
Fix For: 4.2.1
MS Log,
2014-02-10 12:23:31,122 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,122 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: GET, /floating-ip-pool/33b357b3-4f88-4ae6-af86-fb86afa3
2014-02-10 12:23:31,125 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,126 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: GET, /floating-ip/6a6fa311-e5a0-4dfb-b289-cbad2122a756
2014-02-10 12:23:31,129 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,130 DEBUG [o.a.c.n.c.m.DBSyncGeneric] (DBSyncTimer:null)
Generic db sync : FloatingIp
2014-02-10 12:23:31,141 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: GET, /virtual-network/e6c067bc-bc63-4613-a7af-84d0182ff6d2
2014-02-10 12:23:31,150 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,155 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: PUT, /virtual-network/e6c067bc-bc63-4613-a7af-84d0182ff6d2,
{virtual-network:{virtual_network_properties:{extend_to_external_routers:false,network_id:4},route_target_list:{route_target:[target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002]},network_ipam_refs:[{to:[default-domain,default-project,default-network-ipam],attr:{ipam_subnets:[{subnet:{ip_prefix:10.223.138.64,ip_prefix_len:26},default_gateway:10.223.138.65}]},href:null,uuid:null}],floating_ip_pools:[{to:[default-domain,default-project,__default_Public__,PublicIpPool],attr:null,href:http://10.223.58.3:8082/floating-ip-pool/33b357b3-4f88-4ae6-af86-fb86afa3,uuid:33b357b3-4f88-4ae6-af86-fb86afa3}],routing_instances:[{to:[default-domain,default-project,__default_Public__,__default_Public__],attr:null,href:http://10.223.58.3:8082/routing-instance/74769566-dfce-4b6d-bbb5-db772bccb2f9,uuid:74769566-dfce-4b6d-bbb5-db772bccb2f9}],name:__default_Public__,uuid:e6c067bc-bc63-4613-a7af-84d0182ff6d2,fq_name:[default-domain,default-project,__default_Public__],parent_type:project,parent_uuid:fafebf0e-5d9c-4c99-928d-25ab65bd7ebc}}
2014-02-10 12:23:31,193 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,194 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: GET, /virtual-machine-interface/07c6bdac-7be4-4d88-83ef-6f5ffe2f8b19
2014-02-10 12:23:31,198 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 404 Not Found
2014-02-10 12:23:31,199 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: POST, /virtual-machine-interfaces,
{virtual-machine-interface:{virtual_machine_interface_mac_addresses:{mac_address:[06:e4:2a:00:00:35]},virtual_network_refs:[{to:[default-domain,default-project,__default_Public__],attr:null,href:null,uuid:null}],name:s-11-VM-2,uuid:07c6bdac-7be4-4d88-83ef-6f5ffe2f8b19,fq_name:[s-11-VM,s-11-VM-2],parent_type:virtual-machine}}
2014-02-10 12:23:31,205 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 400 Bad Request
2014-02-10 12:23:31,205 ERROR [n.j.c.a.ApiConnector] (DBSyncTimer:null)
create api request failed: Bad Request
2014-02-10 12:23:31,206 ERROR [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Failure message:
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
html
head
titleError: 400 Bad Request/title
style type=text/css
html {background-color: #eee; font-family: sans;}
body {background-color: #fff; border: 1px solid #ddd;
padding: 15px; margin: 15px;}
pre {background-color: #eee; border: 1px solid #ddd; padding:
5px;}
/style
/head
body
h1Error: 400 Bad Request/h1
pSorry, the requested URL
tt#039;http://10.223.58.3:8082/virtual-machine-interfaces#039;/tt
caused an error:/p
preParent
[jira] [Assigned] (CLOUDSTACK-6014) Contrail:MS:syncDomain java.net.ConnectException: Connection refused
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suresh Balineni reassigned CLOUDSTACK-6014: --- Assignee: Suresh Balineni Contrail:MS:syncDomain java.net.ConnectException: Connection refused Key: CLOUDSTACK-6014 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6014 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Contrail, Management Server Affects Versions: 4.2.1 Environment: Master with Contrail and Xen Reporter: Parth Jagirdar Assignee: Suresh Balineni Priority: Critical Fix For: 4.2.1 On a fresh install, Following in seen in MS logs. 2014-01-31 11:35:32,986 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:ctx-8103e482) Found 0 running routers. 2014-01-31 11:35:32,989 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-34cc0ed0) Found 0 routers to update status. 2014-01-31 11:35:32,992 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-34cc0ed0) Found 0 networks to update RvR status. 2014-01-31 11:35:33,877 DEBUG [o.a.c.n.c.m.ContrailManager] (DBSyncTimer:null) DB Sync task is running 2014-01-31 11:35:33,877 DEBUG [o.a.c.n.c.m.ServerDBSync] (DBSyncTimer:null) syncing cloudstack db with vnc 2014-01-31 11:35:33,877 DEBUG [o.a.c.n.c.m.ServerDBSync] (DBSyncTimer:null) sync start: Domain 2014-01-31 11:35:33,881 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null) http connection localhost, 8082 does not exit 2014-01-31 11:35:33,890 WARN [o.a.c.n.c.m.ServerDBSync] (DBSyncTimer:null) syncDomain java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) at java.net.Socket.connect(Socket.java:546) at java.net.Socket.connect(Socket.java:495) at java.net.Socket.init(Socket.java:392) at java.net.Socket.init(Socket.java:206) at net.juniper.contrail.api.ApiConnectorImpl.checkConnection(ApiConnectorImpl.java:127) at net.juniper.contrail.api.ApiConnectorImpl.execute(ApiConnectorImpl.java:156) at net.juniper.contrail.api.ApiConnectorImpl.list(ApiConnectorImpl.java:433) at org.apache.cloudstack.network.contrail.management.ServerDBSyncImpl.syncDomain(ServerDBSyncImpl.java:231) 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:616) at org.apache.cloudstack.network.contrail.management.DBSyncGeneric.sync(DBSyncGeneric.java:112) at org.apache.cloudstack.network.contrail.management.ServerDBSyncImpl.syncAll(ServerDBSyncImpl.java:139) at org.apache.cloudstack.network.contrail.management.ContrailManagerImpl.syncNetworkDB(ContrailManagerImpl.java:429) at org.apache.cloudstack.network.contrail.management.ContrailManagerImpl$DBSyncTask.run(ContrailManagerImpl.java:446) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) 2014-01-31 11:35:33,891 WARN [o.a.c.n.c.m.ServerDBSync] (DBSyncTimer:null) DB Synchronization java.lang.reflect.InvocationTargetException 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:616) at org.apache.cloudstack.network.contrail.management.DBSyncGeneric.sync(DBSyncGeneric.java:112) at org.apache.cloudstack.network.contrail.management.ServerDBSyncImpl.syncAll(ServerDBSyncImpl.java:139) at org.apache.cloudstack.network.contrail.management.ContrailManagerImpl.syncNetworkDB(ContrailManagerImpl.java:429) at org.apache.cloudstack.network.contrail.management.ContrailManagerImpl$DBSyncTask.run(ContrailManagerImpl.java:446) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) Caused by:
[jira] [Assigned] (CLOUDSTACK-6014) Contrail:MS:syncDomain java.net.ConnectException: Connection refused
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suresh Balineni reassigned CLOUDSTACK-6014: --- Assignee: Parth Jagirdar (was: Suresh Balineni) Fixed in 4.3. Please verify. Contrail:MS:syncDomain java.net.ConnectException: Connection refused Key: CLOUDSTACK-6014 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6014 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Contrail, Management Server Affects Versions: 4.2.1 Environment: Master with Contrail and Xen Reporter: Parth Jagirdar Assignee: Parth Jagirdar Priority: Critical Fix For: 4.2.1 On a fresh install, Following in seen in MS logs. 2014-01-31 11:35:32,986 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:ctx-8103e482) Found 0 running routers. 2014-01-31 11:35:32,989 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-34cc0ed0) Found 0 routers to update status. 2014-01-31 11:35:32,992 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-34cc0ed0) Found 0 networks to update RvR status. 2014-01-31 11:35:33,877 DEBUG [o.a.c.n.c.m.ContrailManager] (DBSyncTimer:null) DB Sync task is running 2014-01-31 11:35:33,877 DEBUG [o.a.c.n.c.m.ServerDBSync] (DBSyncTimer:null) syncing cloudstack db with vnc 2014-01-31 11:35:33,877 DEBUG [o.a.c.n.c.m.ServerDBSync] (DBSyncTimer:null) sync start: Domain 2014-01-31 11:35:33,881 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null) http connection localhost, 8082 does not exit 2014-01-31 11:35:33,890 WARN [o.a.c.n.c.m.ServerDBSync] (DBSyncTimer:null) syncDomain java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) at java.net.Socket.connect(Socket.java:546) at java.net.Socket.connect(Socket.java:495) at java.net.Socket.init(Socket.java:392) at java.net.Socket.init(Socket.java:206) at net.juniper.contrail.api.ApiConnectorImpl.checkConnection(ApiConnectorImpl.java:127) at net.juniper.contrail.api.ApiConnectorImpl.execute(ApiConnectorImpl.java:156) at net.juniper.contrail.api.ApiConnectorImpl.list(ApiConnectorImpl.java:433) at org.apache.cloudstack.network.contrail.management.ServerDBSyncImpl.syncDomain(ServerDBSyncImpl.java:231) 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:616) at org.apache.cloudstack.network.contrail.management.DBSyncGeneric.sync(DBSyncGeneric.java:112) at org.apache.cloudstack.network.contrail.management.ServerDBSyncImpl.syncAll(ServerDBSyncImpl.java:139) at org.apache.cloudstack.network.contrail.management.ContrailManagerImpl.syncNetworkDB(ContrailManagerImpl.java:429) at org.apache.cloudstack.network.contrail.management.ContrailManagerImpl$DBSyncTask.run(ContrailManagerImpl.java:446) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) 2014-01-31 11:35:33,891 WARN [o.a.c.n.c.m.ServerDBSync] (DBSyncTimer:null) DB Synchronization java.lang.reflect.InvocationTargetException 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:616) at org.apache.cloudstack.network.contrail.management.DBSyncGeneric.sync(DBSyncGeneric.java:112) at org.apache.cloudstack.network.contrail.management.ServerDBSyncImpl.syncAll(ServerDBSyncImpl.java:139) at org.apache.cloudstack.network.contrail.management.ContrailManagerImpl.syncNetworkDB(ContrailManagerImpl.java:429) at org.apache.cloudstack.network.contrail.management.ContrailManagerImpl$DBSyncTask.run(ContrailManagerImpl.java:446) at java.util.TimerThread.mainLoop(Timer.java:534) at
[jira] [Assigned] (CLOUDSTACK-5899) Contrail:MS: Exceptions in MS logs on a fresh install, syncDomain java.lang.NullPointerException
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suresh Balineni reassigned CLOUDSTACK-5899: --- Assignee: Suresh Balineni Contrail:MS: Exceptions in MS logs on a fresh install, syncDomain java.lang.NullPointerException - Key: CLOUDSTACK-5899 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5899 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Contrail, Management Server Affects Versions: 4.3.0 Environment: Master with Contrail. Reporter: Parth Jagirdar Assignee: Suresh Balineni Priority: Critical Fix For: 4.3.0 2014-01-17 09:30:25,880 INFO [c.c.a.ApiServer] (ApiServer-2:ctx-ce22ce43 ctx-78615dc8) Invalid request, no command sent 2014-01-17 09:30:25,882 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null) Response Status: HTTP/1.1 432 Invalid request, no command sent 2014-01-17 09:30:25,882 WARN [n.j.c.a.ApiConnector] (DBSyncTimer:null) list failed with :Invalid request, no command sent 2014-01-17 09:30:25,882 DEBUG [o.a.c.n.c.m.DBSyncGeneric] (DBSyncTimer:null) Generic db sync : Domain 2014-01-17 09:30:25,883 WARN [o.a.c.n.c.m.ServerDBSync] (DBSyncTimer:null) syncDomain java.lang.NullPointerException at java.util.Collections.sort(Collections.java:175) at org.apache.cloudstack.network.contrail.management.DBSyncGeneric.syncGeneric(DBSyncGeneric.java:295) at org.apache.cloudstack.network.contrail.management.ServerDBSyncImpl.syncDomain(ServerDBSyncImpl.java:232) 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:616) at org.apache.cloudstack.network.contrail.management.DBSyncGeneric.sync(DBSyncGeneric.java:112) at org.apache.cloudstack.network.contrail.management.ServerDBSyncImpl.syncAll(ServerDBSyncImpl.java:139) at org.apache.cloudstack.network.contrail.management.ContrailManagerImpl.syncNetworkDB(ContrailManagerImpl.java:429) at org.apache.cloudstack.network.contrail.management.ContrailManagerImpl$DBSyncTask.run(ContrailManagerImpl.java:446) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) 2014-01-17 09:30:25,884 WARN [o.a.c.n.c.m.ServerDBSync] (DBSyncTimer:null) DB Synchronization java.lang.reflect.InvocationTargetException 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:616) at org.apache.cloudstack.network.contrail.management.DBSyncGeneric.sync(DBSyncGeneric.java:112) at org.apache.cloudstack.network.contrail.management.ServerDBSyncImpl.syncAll(ServerDBSyncImpl.java:139) at org.apache.cloudstack.network.contrail.management.ContrailManagerImpl.syncNetworkDB(ContrailManagerImpl.java:429) at org.apache.cloudstack.network.contrail.management.ContrailManagerImpl$DBSyncTask.run(ContrailManagerImpl.java:446) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) Caused by: java.lang.NullPointerException at java.util.Collections.sort(Collections.java:175) at org.apache.cloudstack.network.contrail.management.DBSyncGeneric.syncGeneric(DBSyncGeneric.java:295) at org.apache.cloudstack.network.contrail.management.ServerDBSyncImpl.syncDomain(ServerDBSyncImpl.java:232) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ... 9 more 2014-01-17 09:30:25,886 DEBUG [o.a.c.n.c.m.ContrailManager] (DBSyncTimer:null) java.lang.reflect.InvocationTargetException 2014-01-17 09:30:25,886 INFO [o.a.c.n.c.m.ContrailManager] (DBSyncTimer:null) Unable to sync network db 2014-01-17 09:30:35,083 DEBUG [c.c.n.l.LBHealthCheckManagerImpl] (LBHealthCheck-1:ctx-06243a77) LB HealthCheck Manager is running and getting the updates from LB providers and updating service status 2014-01-17 09:30:35,087 DEBUG [c.c.n.l.LBHealthCheckManagerImpl] (LBHealthCheck-1:ctx-06243a77) LB HealthCheck Manager is running and getting the updates from LB providers and updating service status 2014-01-17 09:30:39,106 DEBUG [c.c.s.StatsCollector]
[jira] [Assigned] (CLOUDSTACK-5699) If a new network is created as part of create instance, networks table popluated With NULL CIDR/GATEWAY
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Balineni reassigned CLOUDSTACK-5699:
---
Assignee: Suresh Balineni
If a new network is created as part of create instance, networks table
popluated With NULL CIDR/GATEWAY
-
Key: CLOUDSTACK-5699
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5699
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API, Management Server
Affects Versions: 4.2.0
Reporter: Vinod Nair
Assignee: Suresh Balineni
On creating a New Network as part of the Virtual Instance creation, error is
thrown and the virtual instance is not created, but the networks table gets
populated with the Virtual network defined.
The blow exception is seen in the management server logs
2013-12-31 15:21:48,815 DEBUG [cloud.network.NetworkServiceImpl]
(catalina-exec-1:null) Implementing network Ntwk[206|Guest|15] as a part of
network provision for persistent network
2013-12-31 15:21:48,817 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Lock is acquired for network id 206 as a part of
network implement
2013-12-31 15:21:48,817 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Asking ContrailGuru to implement Ntwk[206|Guest|15]
2013-12-31 15:21:48,840 DEBUG [contrail.management.ContrailGuru]
(catalina-exec-1:null) Implement network: VN2, traffic type: Guest
2013-12-31 15:21:48,840 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Request: GET,
/virtual-network/ebb7e51a-9596-41b3-8147-1e4189a1f3d3
2013-12-31 15:21:48,842 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Status: HTTP/1.1 404 Not Found
2013-12-31 15:21:48,842 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Request: GET,
/virtual-network/ebb7e51a-9596-41b3-8147-1e4189a1f3d3
2013-12-31 15:21:48,843 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Status: HTTP/1.1 404 Not Found
2013-12-31 15:21:48,844 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Request: POST, /fqname-to-id,
{type:network-ipam,fq_name:[default-domain,default-project,default-network-ipam]}
2013-12-31 15:21:48,845 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Status: HTTP/1.1 200 OK
2013-12-31 15:21:48,845 DEBUG [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Data: {uuid:
6e057215-1ed7-4889-99bf-626cddf125a5}
2013-12-31 15:21:48,845 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Request: GET,
/network-ipam/6e057215-1ed7-4889-99bf-626cddf125a5
2013-12-31 15:21:48,847 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Status: HTTP/1.1 200 OK
2013-12-31 15:21:48,849 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Request: POST, /virtual-networks,
{virtual-network:{name:VN2,uuid:ebb7e51a-9596-41b3-8147-1e4189a1f3d3,fq_name:[default-domain,default-project,VN2],parent_type:project}}
2013-12-31 15:21:48,853 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Status: HTTP/1.1 200 OK
2013-12-31 15:21:48,853 DEBUG [contrail.api.ApiConnector]
(catalina-exec-1:null) Create virtual-network uuid:
ebb7e51a-9596-41b3-8147-1e4189a1f3d3
2013-12-31 15:21:48,891 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Creating a source nat ip for network Ntwk[206|Guest|15]
2013-12-31 15:21:48,893 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) lock account 2 is acquired
2013-12-31 15:21:48,932 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Releasing lock account 2
2013-12-31 15:21:48,934 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Asking
ContrailElementImpl_EnhancerByCloudStack_31e1587 to implemenet
Ntwk[206|Guest|15]
2013-12-31 15:21:48,935 DEBUG [contrail.management.ContrailElement]
(catalina-exec-1:null) NetworkElement implement: VN2, traffic type: Guest
2013-12-31 15:21:48,935 DEBUG [contrail.management.ContrailElement]
(catalina-exec-1:null) ignore network VN2
2013-12-31 15:21:48,935 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Reprogramming network Ntwk[206|Guest|15] as a part of
network implement
2013-12-31 15:21:48,939 DEBUG [network.rules.RulesManagerImpl]
(catalina-exec-1:null) There are no static nat to apply for network id=206
2013-12-31 15:21:48,939 DEBUG [network.firewall.FirewallManagerImpl]
(catalina-exec-1:null) There are no firewall rules to apply
2013-12-31 15:21:48,941 DEBUG [network.rules.RulesManagerImpl]
(catalina-exec-1:null) There are no port forwarding rules to apply for
network id=206
[jira] [Assigned] (CLOUDSTACK-5699) If a new network is created as part of create instance, networks table popluated With NULL CIDR/GATEWAY
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Balineni reassigned CLOUDSTACK-5699:
---
Assignee: kamlesh parmar (was: Suresh Balineni)
dup of 5681
If a new network is created as part of create instance, networks table
popluated With NULL CIDR/GATEWAY
-
Key: CLOUDSTACK-5699
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5699
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API, Management Server
Affects Versions: 4.2.0
Reporter: Vinod Nair
Assignee: kamlesh parmar
On creating a New Network as part of the Virtual Instance creation, error is
thrown and the virtual instance is not created, but the networks table gets
populated with the Virtual network defined.
The blow exception is seen in the management server logs
2013-12-31 15:21:48,815 DEBUG [cloud.network.NetworkServiceImpl]
(catalina-exec-1:null) Implementing network Ntwk[206|Guest|15] as a part of
network provision for persistent network
2013-12-31 15:21:48,817 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Lock is acquired for network id 206 as a part of
network implement
2013-12-31 15:21:48,817 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Asking ContrailGuru to implement Ntwk[206|Guest|15]
2013-12-31 15:21:48,840 DEBUG [contrail.management.ContrailGuru]
(catalina-exec-1:null) Implement network: VN2, traffic type: Guest
2013-12-31 15:21:48,840 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Request: GET,
/virtual-network/ebb7e51a-9596-41b3-8147-1e4189a1f3d3
2013-12-31 15:21:48,842 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Status: HTTP/1.1 404 Not Found
2013-12-31 15:21:48,842 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Request: GET,
/virtual-network/ebb7e51a-9596-41b3-8147-1e4189a1f3d3
2013-12-31 15:21:48,843 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Status: HTTP/1.1 404 Not Found
2013-12-31 15:21:48,844 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Request: POST, /fqname-to-id,
{type:network-ipam,fq_name:[default-domain,default-project,default-network-ipam]}
2013-12-31 15:21:48,845 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Status: HTTP/1.1 200 OK
2013-12-31 15:21:48,845 DEBUG [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Data: {uuid:
6e057215-1ed7-4889-99bf-626cddf125a5}
2013-12-31 15:21:48,845 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Request: GET,
/network-ipam/6e057215-1ed7-4889-99bf-626cddf125a5
2013-12-31 15:21:48,847 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Status: HTTP/1.1 200 OK
2013-12-31 15:21:48,849 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Request: POST, /virtual-networks,
{virtual-network:{name:VN2,uuid:ebb7e51a-9596-41b3-8147-1e4189a1f3d3,fq_name:[default-domain,default-project,VN2],parent_type:project}}
2013-12-31 15:21:48,853 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Status: HTTP/1.1 200 OK
2013-12-31 15:21:48,853 DEBUG [contrail.api.ApiConnector]
(catalina-exec-1:null) Create virtual-network uuid:
ebb7e51a-9596-41b3-8147-1e4189a1f3d3
2013-12-31 15:21:48,891 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Creating a source nat ip for network Ntwk[206|Guest|15]
2013-12-31 15:21:48,893 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) lock account 2 is acquired
2013-12-31 15:21:48,932 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Releasing lock account 2
2013-12-31 15:21:48,934 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Asking
ContrailElementImpl_EnhancerByCloudStack_31e1587 to implemenet
Ntwk[206|Guest|15]
2013-12-31 15:21:48,935 DEBUG [contrail.management.ContrailElement]
(catalina-exec-1:null) NetworkElement implement: VN2, traffic type: Guest
2013-12-31 15:21:48,935 DEBUG [contrail.management.ContrailElement]
(catalina-exec-1:null) ignore network VN2
2013-12-31 15:21:48,935 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Reprogramming network Ntwk[206|Guest|15] as a part of
network implement
2013-12-31 15:21:48,939 DEBUG [network.rules.RulesManagerImpl]
(catalina-exec-1:null) There are no static nat to apply for network id=206
2013-12-31 15:21:48,939 DEBUG [network.firewall.FirewallManagerImpl]
(catalina-exec-1:null) There are no firewall rules to apply
2013-12-31 15:21:48,941 DEBUG [network.rules.RulesManagerImpl]
(catalina-exec-1:null) There are no port forwarding rules
[jira] [Created] (CLOUDSTACK-6203) KVM live migration improvement
Marcus Sorensen created CLOUDSTACK-6203: --- Summary: KVM live migration improvement Key: CLOUDSTACK-6203 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6203 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: 4.4.0 Run the KVM live migration in a thread so we can monitor it. This will allow us to see how long migrations are taking and do things like pause the vm if migration is stalling (per user defined time limit) to quickly complete migration, or set the domain's max downtime during cut-over between machines (higher values make migration of busy vms easier, lower values may make migration stall). In the future we can add the autoconvergence flag that stalls VMs for a few ticks to allow memory copy to catch up, but it will be awhile before libvirt that's shipped in a distro supports it, so these tunables may be useful now. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6016) MS: MS out of memory java.lang.OutOfMemoryError: PermGen space
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suresh Balineni reassigned CLOUDSTACK-6016: --- Assignee: Suresh Balineni MS: MS out of memory java.lang.OutOfMemoryError: PermGen space -- Key: CLOUDSTACK-6016 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6016 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Contrail, Management Server, XenServer Affects Versions: 4.2.1 Environment: Master with Contrail and Xen. Reporter: Parth Jagirdar Assignee: Suresh Balineni Priority: Critical Fix For: 4.2.1 Attachments: management-server_attachment.log.bz2 Detailed logs are attached .. ++-+--+---+--++++---+++---++-+-+-++---+-++-+---+ | id | name| uuid | pool_type | port | data_center_id | pod_id | cluster_id | used_bytes| capacity_bytes | host_address | user_info | path | created | removed | update_time | status | storage_provider_name | scope | hypervisor | managed | capacity_iops | ++-+--+---+--++++---+++---++-+-+-++---+-++-+---+ | 16 | primary | 15027b8a-bb16-3f01-b5af-e980a0060f25 | NetworkFilesystem | 2049 | 1 | 1 | 1 | 4029850058752 | 11810778316800 | 10.223.110.232 | NULL | /export/home/parth/contrail/cloudstack_248_196/primary | 2014-01-31 20:53:34 | NULL| NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | ++-+--+---+--++++---+++---++-+-+-++---+-++-+---+ 1 row in set (0.01 sec) mysql select * from storage_pool_view; ++--+-+++---++-+-++---+-++---++--++--++--+--+--++--+---+--++++--+++ | id | uuid | name| status | path | pool_type | host_address | created | removed | capacity_bytes | capacity_iops | scope | hypervisor | storage_provider_name | cluster_id | cluster_uuid | cluster_name | cluster_type | data_center_id | data_center_uuid | data_center_name | data_center_type | pod_id | pod_uuid | pod_name | tag | disk_used_capacity | disk_reserved_capacity | job_id | job_uuid | job_status | job_account_id | ++--+-+++---++-+-++---+-++---++--++--++--+--+--++--+---+--++++--+++ | 16 | 15027b8a-bb16-3f01-b5af-e980a0060f25 | primary | Up | /export/home/parth/contrail/cloudstack_248_196/primary | NetworkFilesystem | 10.223.110.232 | 2014-01-31 20:53:34 | NULL|
[jira] [Assigned] (CLOUDSTACK-6016) MS: MS out of memory java.lang.OutOfMemoryError: PermGen space
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suresh Balineni reassigned CLOUDSTACK-6016: --- Assignee: Parth Jagirdar (was: Suresh Balineni) this is not applicable to contrail. Please verify in 4.3. MS: MS out of memory java.lang.OutOfMemoryError: PermGen space -- Key: CLOUDSTACK-6016 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6016 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Contrail, Management Server, XenServer Affects Versions: 4.2.1 Environment: Master with Contrail and Xen. Reporter: Parth Jagirdar Assignee: Parth Jagirdar Priority: Critical Fix For: 4.2.1 Attachments: management-server_attachment.log.bz2 Detailed logs are attached .. ++-+--+---+--++++---+++---++-+-+-++---+-++-+---+ | id | name| uuid | pool_type | port | data_center_id | pod_id | cluster_id | used_bytes| capacity_bytes | host_address | user_info | path | created | removed | update_time | status | storage_provider_name | scope | hypervisor | managed | capacity_iops | ++-+--+---+--++++---+++---++-+-+-++---+-++-+---+ | 16 | primary | 15027b8a-bb16-3f01-b5af-e980a0060f25 | NetworkFilesystem | 2049 | 1 | 1 | 1 | 4029850058752 | 11810778316800 | 10.223.110.232 | NULL | /export/home/parth/contrail/cloudstack_248_196/primary | 2014-01-31 20:53:34 | NULL| NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | ++-+--+---+--++++---+++---++-+-+-++---+-++-+---+ 1 row in set (0.01 sec) mysql select * from storage_pool_view; ++--+-+++---++-+-++---+-++---++--++--++--+--+--++--+---+--++++--+++ | id | uuid | name| status | path | pool_type | host_address | created | removed | capacity_bytes | capacity_iops | scope | hypervisor | storage_provider_name | cluster_id | cluster_uuid | cluster_name | cluster_type | data_center_id | data_center_uuid | data_center_name | data_center_type | pod_id | pod_uuid | pod_name | tag | disk_used_capacity | disk_reserved_capacity | job_id | job_uuid | job_status | job_account_id | ++--+-+++---++-+-++---+-++---++--++--++--+--+--++--+---+--++++--+++ | 16 | 15027b8a-bb16-3f01-b5af-e980a0060f25 | primary | Up | /export/home/parth/contrail/cloudstack_248_196/primary |
[jira] [Commented] (CLOUDSTACK-6203) KVM live migration improvement
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13921264#comment-13921264 ] ASF subversion and git services commented on CLOUDSTACK-6203: - Commit e5449e29c9bdc03c93fe8eb361f32878c9a1b980 in cloudstack's branch refs/heads/master from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e5449e2 ] CLOUDSTACK-6203: KVM Migration fixes. Moved migration to a thread so we can monitor it and potentially take action to make migration complete if admin has defined such. KVM live migration improvement -- Key: CLOUDSTACK-6203 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6203 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: 4.4.0 Run the KVM live migration in a thread so we can monitor it. This will allow us to see how long migrations are taking and do things like pause the vm if migration is stalling (per user defined time limit) to quickly complete migration, or set the domain's max downtime during cut-over between machines (higher values make migration of busy vms easier, lower values may make migration stall). In the future we can add the autoconvergence flag that stalls VMs for a few ticks to allow memory copy to catch up, but it will be awhile before libvirt that's shipped in a distro supports it, so these tunables may be useful now. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6203) KVM live migration improvement
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Sorensen resolved CLOUDSTACK-6203. - Resolution: Fixed added agent.properties tunables. The commit is based on 4.2 code we've been running in production for awhile. # set target downtime at end of livemigration, the 'hiccup' for final copy. Higher numbers # make livemigration easier, lower numbers may cause migration to never complete. Less than 1 # means hypervisor default (20ms). #vm.migrate.downtime=0 # Busy VMs may never finish migrating, depending on environment. When its available, we will # want to add support for autoconvergence migration flag which should fix this. Set an upper # limit in seconds for how long live migration should wait, at which point VM is paused and # migration will finish quickly. Less than 1 means disabled. #vm.migrate.pauseafter=0 KVM live migration improvement -- Key: CLOUDSTACK-6203 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6203 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: 4.4.0 Run the KVM live migration in a thread so we can monitor it. This will allow us to see how long migrations are taking and do things like pause the vm if migration is stalling (per user defined time limit) to quickly complete migration, or set the domain's max downtime during cut-over between machines (higher values make migration of busy vms easier, lower values may make migration stall). In the future we can add the autoconvergence flag that stalls VMs for a few ticks to allow memory copy to catch up, but it will be awhile before libvirt that's shipped in a distro supports it, so these tunables may be useful now. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CLOUDSTACK-6203) KVM live migration improvement
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13921269#comment-13921269 ] Marcus Sorensen edited comment on CLOUDSTACK-6203 at 3/5/14 7:28 PM: - added agent.properties tunables. The commit is based on 4.2 code we've been running in production for awhile. set target downtime at end of livemigration, the 'hiccup' for final copy. Higher numbers make livemigration easier, lower numbers may cause migration to never complete. Less than 1 means hypervisor default (20ms). vm.migrate.downtime=0 Busy VMs may never finish migrating, depending on environment. When its available, we will want to add support for autoconvergence migration flag which should fix this. Set an upper limit in seconds for how long live migration should wait, at which point VM is paused and migration will finish quickly. Less than 1 means disabled. vm.migrate.pauseafter=0 was (Author: mlsorensen): added agent.properties tunables. The commit is based on 4.2 code we've been running in production for awhile. # set target downtime at end of livemigration, the 'hiccup' for final copy. Higher numbers # make livemigration easier, lower numbers may cause migration to never complete. Less than 1 # means hypervisor default (20ms). #vm.migrate.downtime=0 # Busy VMs may never finish migrating, depending on environment. When its available, we will # want to add support for autoconvergence migration flag which should fix this. Set an upper # limit in seconds for how long live migration should wait, at which point VM is paused and # migration will finish quickly. Less than 1 means disabled. #vm.migrate.pauseafter=0 KVM live migration improvement -- Key: CLOUDSTACK-6203 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6203 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: 4.4.0 Run the KVM live migration in a thread so we can monitor it. This will allow us to see how long migrations are taking and do things like pause the vm if migration is stalling (per user defined time limit) to quickly complete migration, or set the domain's max downtime during cut-over between machines (higher values make migration of busy vms easier, lower values may make migration stall). In the future we can add the autoconvergence flag that stalls VMs for a few ticks to allow memory copy to catch up, but it will be awhile before libvirt that's shipped in a distro supports it, so these tunables may be useful now. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6204) HTTP support for CPVM, as part of realhostip changes
Amogh Vasekar created CLOUDSTACK-6204: - Summary: HTTP support for CPVM, as part of realhostip changes Key: CLOUDSTACK-6204 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6204 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Reporter: Amogh Vasekar Assignee: Amogh Vasekar Priority: Critical Fix For: Future Details can be found here https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6203) KVM live migration improvement
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13921293#comment-13921293 ] ASF subversion and git services commented on CLOUDSTACK-6203: - Commit bbaec7bae87fde2c93568a042b8cd085b57bf0d1 in cloudstack's branch refs/heads/master from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bbaec7b ] CLOUDSTACK-6203: Correct documentation for KVM migration tuneables KVM live migration improvement -- Key: CLOUDSTACK-6203 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6203 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: 4.4.0 Run the KVM live migration in a thread so we can monitor it. This will allow us to see how long migrations are taking and do things like pause the vm if migration is stalling (per user defined time limit) to quickly complete migration, or set the domain's max downtime during cut-over between machines (higher values make migration of busy vms easier, lower values may make migration stall). In the future we can add the autoconvergence flag that stalls VMs for a few ticks to allow memory copy to catch up, but it will be awhile before libvirt that's shipped in a distro supports it, so these tunables may be useful now. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-5876) Contrail: After vrouter restart agent doesnt have info about the Network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senthilnathan Murugappan closed CLOUDSTACK-5876. Resolution: Fixed Fix Version/s: 4.3.0 Resolved in latest contrail rpms Contrail: After vrouter restart agent doesnt have info about the Network Key: CLOUDSTACK-5876 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5876 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Contrail Affects Versions: 4.3.0 Reporter: Senthilnathan Murugappan Fix For: 4.3.0 Before vRouter restart [root@cloudcontrol ~]# curl -X POST http://10.84.24.58:8085/Snh_VnListReq?name= ?xml-stylesheet type=text/xsl href=universal_parse.xsl?VnListResp type=sandeshvn_list type=list identifier=1list type=struct size=1VnSandeshDataname type=string identifier=1default-domain:default-project:myvn/nameuuid type=string identifier=23baedfc0-1a02-49dc-b755-88e00c264e97/uuidacl_uuid type=string identifier=3 link=AclReq/acl_uuidmirror_acl_uuid type=string identifier=4 link=AclReq/mirror_acl_uuidmirror_cfg_acl_uuid type=string identifier=5 link=AclReq/mirror_cfg_acl_uuidvrf_name type=string identifier=6 link=VrfListReqdefault-domain:default-project:myvn:myvn/vrf_nameipam_data type=list identifier=7list type=struct size=1VnIpamDataip_prefix type=string identifier=110.2.2.0/ip_prefixprefix_len type=i32 identifier=224/prefix_lengateway type=string identifier=310.2.2.254/gatewayipam_name type=string identifier=4default-domain:default-project:default-network-ipam/ipam_name/VnIpamData/list/ipam_dataipam_host_routes type=list identifier=8list type=struct size=1VnIpamHostRoutesipam_name type=string identifier=1default-domain:default-project:default-network-ipam/ipam_namehost_routes type=list identifier=2list type=string size=0/list/host_routes/VnIpamHostRoutes/list/ipam_host_routeslayer2_forwarding type=bool identifier=9true/layer2_forwardingipv4_forwarding type=bool identifier=10true/ipv4_forwarding/VnSandeshData/list/vn_listmore type=bool identifier=0false/more/VnListResp[root@cloudcontrol ~]# [root@cloudcontrol ~]# cloudmonkey list networks count = 1 network: id = 3baedfc0-1a02-49dc-b755-88e00c264e97 name = myvn account = admin acltype = Account broadcastdomaintype = Lswitch canusefordeploy = True cidr = 10.2.2.0/24 displaynetwork = True displaytext = myvn domain = ROOT domainid = 99580468-5c6f-11e3-b3d5-0270da5861be gateway = 10.2.2.254 ispersistent = True issystem = False netmask = 255.255.255.0 networkofferingavailability = Optional networkofferingconservemode = False networkofferingdisplaytext = Juniper Contrail Network Offering networkofferingid = d1cc8adc-275a-44fe-9f3b-c52e8fdd288a networkofferingname = Juniper Contrail Network Offering physicalnetworkid = feb0abf2-37ff-4468-bb45-365baf42327b related = 3baedfc0-1a02-49dc-b755-88e00c264e97 restartrequired = False service: name = Dhcp capability: name = SourceNat name = NetworkACL name = StaticNat name = Connectivity specifyipranges = False state = Implemented tags: traffictype = Guest type = Isolated zoneid = 322ef348-fcad-457b-a869-162f93432a6f zonename = default After VRouter Restart: [root@cloudcontrol ~]# [root@cloudcontrol ~]# curl -X POST http://10.84.24.58:8085/Snh_VnListReq?name= ?xml-stylesheet type=text/xsl href=universal_parse.xsl?VnListResp type=sandeshvn_list type=list identifier=1list type=struct size=0/list/vn_listmore type=bool identifier=0false/more/VnListR esp [root@cloudcontrol ~]# cloudmonkey list networks count = 1 network: id = 3baedfc0-1a02-49dc-b755-88e00c264e97 name = myvn account = admin acltype = Account broadcastdomaintype = Lswitch canusefordeploy = True cidr = 10.2.2.0/24 displaynetwork = True displaytext = myvn domain = ROOT domainid = 99580468-5c6f-11e3-b3d5-0270da5861be gateway = 10.2.2.254 ispersistent = True issystem = False netmask = 255.255.255.0 networkofferingavailability = Optional networkofferingconservemode = False networkofferingdisplaytext = Juniper Contrail Network Offering networkofferingid = d1cc8adc-275a-44fe-9f3b-c52e8fdd288a networkofferingname = Juniper Contrail Network Offering physicalnetworkid =
[jira] [Commented] (CLOUDSTACK-6170) Support managed storage for root disks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13921387#comment-13921387 ] ASF subversion and git services commented on CLOUDSTACK-6170: - Commit b06e66c50a43337d28c4157c396e39adb488902f in cloudstack's branch refs/heads/master from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b06e66c ] CLOUDSTACK-6170 Support managed storage for root disks -- Key: CLOUDSTACK-6170 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6170 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Environment: I expect to support managed storage for root disks on XenServer and ESX (KVM is targeted for 4.5). Reporter: Mike Tutkowski Assignee: Mike Tutkowski Fix For: 4.4.0 Cloud environments have a need for guaranteed storage performance. By this I mean having the ability to specify a minimum and maximum number of IOPS on a volume-by-volume basis. I added support for this for XenServer and ESX in 4.2 for data disks. I added support for this for KVM in 4.3 for data disks. It is my intent to add support for this for XenServer and ESX in 4.4 for root disks (with subsequent support for root disks on KVM expected in 4.5). The main changes are expected to occur in CloudStack logic that controls hypervisors and additions to the way root-volume orchestration happens. This will also require minor changes in the SolidFire (storage) plug-in. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6205) VPC: when network is created in Setup state (with vlan specified), it never gets plugged to the VPC VR after restart
Alena Prokharchyk created CLOUDSTACK-6205:
-
Summary: VPC: when network is created in Setup state (with vlan
specified), it never gets plugged to the VPC VR after restart
Key: CLOUDSTACK-6205
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6205
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.3.0
Reporter: Alena Prokharchyk
Assignee: Alena Prokharchyk
Priority: Blocker
Fix For: 4.3.0
1. VPC Isolated Guest network in Setup state (vlan is specified at the moment
of creation by the Root admin), doesn’t get replugged to the VPC VR upon its
restart. Happens when the network is created in Setup State (with Vlan
specified)
2. When new VM starts up in this non-plugged network, network gets plugged, but
the LB rules are not getting programmed on the VR for this network/vm
Root cause for #1 - when the code forms the nics for the Guest networks, it
considers only networks in Implemented state:
List? extends Network guestNetworks = _vpcMgr.getVpcNetworks(vpcId);
for (Network guestNetwork : guestNetworks) {
if (guestNetwork.getState() == Network.State.Implemented) {
We should add one more condition - the network can be as well in setup state.
#2 is obviously caused by #1. When VR gets restarted, following happens:
All guest networks in Implemented/Setup state from this VPC supposed to
re-plugged to the VR
All networking rules should be set for all the networks that got plugged.
If there was some network in non-implemented/non-setup state, its rules will
not get applied. They will get applied later as a part of network implement. So
once #1 is fixed, the LB rules issue will get fixed as well.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5872) Async response from addAccountToProject doesn't contain useful information
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13921489#comment-13921489 ] ASF subversion and git services commented on CLOUDSTACK-5872: - Commit e0e13434b9191917342f751c07e8097f7f92a430 in cloudstack's branch refs/heads/4.3 from [~alena1108] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e0e1343 ] CLOUDSTACK-5872: use List DS for storing NicProfiles as public network can have more than one nic Conflicts: server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java Async response from addAccountToProject doesn't contain useful information -- Key: CLOUDSTACK-5872 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5872 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Reporter: Bill Jones Assignee: David Grizzanti Fix For: 4.4.0 Attachments: unnamed.patch The async response from addAccountToProject doesn't contain useful information. Generally async responses for commands that modify resources include the resource ID and/or description in the async response. This is not true of addAccountToProject or deleteAccountFromProject. Consequently the response is not so useful to clients that do not have access to the context of the request. Also, it seems inconsistent with the general design of the API. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6198) VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk resolved CLOUDSTACK-6198. --- Resolution: Fixed Resolved in 4.3 branch. VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart --- Key: CLOUDSTACK-6198 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6198 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Blocker Fix For: 4.3.0 Regression bug. Steps to reproduce: 1. Create vpc and launch a vm in one tear. 2. vpc source ip address is from one subnet (ex: 10.147.52.1) 3. Acquire another public ip address from new public subnet. 4. create static nat on it to plug the nic on VR. 5. Now the VR has link local nic, guest nic, source nat ip nic and second public range nic. 6. Restart the vpc. 7. After restart there is no source nat nic. 8. If we restart vpc again observed that more nics are missed. I do observe the HUGE problem in 4.3 in VpcVirtualNetworkApplianceManager.java createVpcRouterNetworks() method. In 4.2 we used to store vm's nics in the ArrayList datastructure: ListPairNetworkVO, NicProfile networks = new ArrayListPairNetworkVO, NicProfile(4); ArrayList does allow duplicates. Then in 4.3 the datastructure was changed to LinkedHashMap that doesn't allow duplicates: LinkedHashMapNetwork, NicProfile networks = new LinkedHashMapNetwork, NicProfile(4); To fix the problem, the datastructure has to be changed to LinkedHashMapNetwork, ListNicProfile. It has to be changed all the way up to VirtualMachienManagerImpl where the nics are being passed to. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-5699) If a new network is created as part of create instance, networks table popluated With NULL CIDR/GATEWAY
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kamlesh parmar closed CLOUDSTACK-5699.
--
Resolution: Invalid
The problem is when trying to create network with instance creation, all we can
supply today is network name. For contrail plugin to work we need to be able to
provide the network CIDR. This should be fixed or disallowed in GUI if using
contrail network offering. Marking the bug as invalid for now.
If a new network is created as part of create instance, networks table
popluated With NULL CIDR/GATEWAY
-
Key: CLOUDSTACK-5699
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5699
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API, Management Server
Affects Versions: 4.2.0
Reporter: Vinod Nair
Assignee: kamlesh parmar
On creating a New Network as part of the Virtual Instance creation, error is
thrown and the virtual instance is not created, but the networks table gets
populated with the Virtual network defined.
The blow exception is seen in the management server logs
2013-12-31 15:21:48,815 DEBUG [cloud.network.NetworkServiceImpl]
(catalina-exec-1:null) Implementing network Ntwk[206|Guest|15] as a part of
network provision for persistent network
2013-12-31 15:21:48,817 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Lock is acquired for network id 206 as a part of
network implement
2013-12-31 15:21:48,817 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Asking ContrailGuru to implement Ntwk[206|Guest|15]
2013-12-31 15:21:48,840 DEBUG [contrail.management.ContrailGuru]
(catalina-exec-1:null) Implement network: VN2, traffic type: Guest
2013-12-31 15:21:48,840 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Request: GET,
/virtual-network/ebb7e51a-9596-41b3-8147-1e4189a1f3d3
2013-12-31 15:21:48,842 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Status: HTTP/1.1 404 Not Found
2013-12-31 15:21:48,842 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Request: GET,
/virtual-network/ebb7e51a-9596-41b3-8147-1e4189a1f3d3
2013-12-31 15:21:48,843 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Status: HTTP/1.1 404 Not Found
2013-12-31 15:21:48,844 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Request: POST, /fqname-to-id,
{type:network-ipam,fq_name:[default-domain,default-project,default-network-ipam]}
2013-12-31 15:21:48,845 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Status: HTTP/1.1 200 OK
2013-12-31 15:21:48,845 DEBUG [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Data: {uuid:
6e057215-1ed7-4889-99bf-626cddf125a5}
2013-12-31 15:21:48,845 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Request: GET,
/network-ipam/6e057215-1ed7-4889-99bf-626cddf125a5
2013-12-31 15:21:48,847 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Status: HTTP/1.1 200 OK
2013-12-31 15:21:48,849 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Request: POST, /virtual-networks,
{virtual-network:{name:VN2,uuid:ebb7e51a-9596-41b3-8147-1e4189a1f3d3,fq_name:[default-domain,default-project,VN2],parent_type:project}}
2013-12-31 15:21:48,853 INFO [contrail.api.ApiConnector]
(catalina-exec-1:null) Response Status: HTTP/1.1 200 OK
2013-12-31 15:21:48,853 DEBUG [contrail.api.ApiConnector]
(catalina-exec-1:null) Create virtual-network uuid:
ebb7e51a-9596-41b3-8147-1e4189a1f3d3
2013-12-31 15:21:48,891 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Creating a source nat ip for network Ntwk[206|Guest|15]
2013-12-31 15:21:48,893 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) lock account 2 is acquired
2013-12-31 15:21:48,932 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Releasing lock account 2
2013-12-31 15:21:48,934 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Asking
ContrailElementImpl_EnhancerByCloudStack_31e1587 to implemenet
Ntwk[206|Guest|15]
2013-12-31 15:21:48,935 DEBUG [contrail.management.ContrailElement]
(catalina-exec-1:null) NetworkElement implement: VN2, traffic type: Guest
2013-12-31 15:21:48,935 DEBUG [contrail.management.ContrailElement]
(catalina-exec-1:null) ignore network VN2
2013-12-31 15:21:48,935 DEBUG [cloud.network.NetworkManagerImpl]
(catalina-exec-1:null) Reprogramming network Ntwk[206|Guest|15] as a part of
network implement
2013-12-31 15:21:48,939 DEBUG [network.rules.RulesManagerImpl]
(catalina-exec-1:null) There are no static nat to apply for network id=206
[jira] [Commented] (CLOUDSTACK-6205) VPC: when network is created in Setup state (with vlan specified), it never gets plugged to the VPC VR after restart
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13921635#comment-13921635
]
ASF subversion and git services commented on CLOUDSTACK-6205:
-
Commit d1c0b81dc1b11b1039627d0c400e9e6bfc70d2a8 in cloudstack's branch
refs/heads/master from [~alena1108]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d1c0b81 ]
CLOUDSTACK-6205: VPC VR start - when create guest nics for the VR, consider
networks not only in Implemented state, but in Setup state as well
VPC: when network is created in Setup state (with vlan specified), it never
gets plugged to the VPC VR after restart
Key: CLOUDSTACK-6205
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6205
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.3.0
Reporter: Alena Prokharchyk
Assignee: Alena Prokharchyk
Priority: Blocker
Fix For: 4.3.0
1. VPC Isolated Guest network in Setup state (vlan is specified at the moment
of creation by the Root admin), doesn’t get replugged to the VPC VR upon its
restart. Happens when the network is created in Setup State (with Vlan
specified)
2. When new VM starts up in this non-plugged network, network gets plugged,
but the LB rules are not getting programmed on the VR for this network/vm
Root cause for #1 - when the code forms the nics for the Guest networks, it
considers only networks in Implemented state:
List? extends Network guestNetworks = _vpcMgr.getVpcNetworks(vpcId);
for (Network guestNetwork : guestNetworks) {
if (guestNetwork.getState() == Network.State.Implemented) {
We should add one more condition - the network can be as well in setup state.
#2 is obviously caused by #1. When VR gets restarted, following happens:
All guest networks in Implemented/Setup state from this VPC supposed to
re-plugged to the VR
All networking rules should be set for all the networks that got plugged.
If there was some network in non-implemented/non-setup state, its rules will
not get applied. They will get applied later as a part of network implement.
So once #1 is fixed, the LB rules issue will get fixed as well.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6205) VPC: when network is created in Setup state (with vlan specified), it never gets plugged to the VPC VR after restart
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13921648#comment-13921648
]
ASF subversion and git services commented on CLOUDSTACK-6205:
-
Commit d009c8c7b229a1bb02834f52d9cac17f46e33349 in cloudstack's branch
refs/heads/4.3-forward from [~alena1108]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d009c8c ]
CLOUDSTACK-6205: VPC VR start - when create guest nics for the VR, consider
networks not only in Implemented state, but in Setup state as well
VPC: when network is created in Setup state (with vlan specified), it never
gets plugged to the VPC VR after restart
Key: CLOUDSTACK-6205
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6205
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.3.0
Reporter: Alena Prokharchyk
Assignee: Alena Prokharchyk
Priority: Blocker
Fix For: 4.3.0
1. VPC Isolated Guest network in Setup state (vlan is specified at the moment
of creation by the Root admin), doesn’t get replugged to the VPC VR upon its
restart. Happens when the network is created in Setup State (with Vlan
specified)
2. When new VM starts up in this non-plugged network, network gets plugged,
but the LB rules are not getting programmed on the VR for this network/vm
Root cause for #1 - when the code forms the nics for the Guest networks, it
considers only networks in Implemented state:
List? extends Network guestNetworks = _vpcMgr.getVpcNetworks(vpcId);
for (Network guestNetwork : guestNetworks) {
if (guestNetwork.getState() == Network.State.Implemented) {
We should add one more condition - the network can be as well in setup state.
#2 is obviously caused by #1. When VR gets restarted, following happens:
All guest networks in Implemented/Setup state from this VPC supposed to
re-plugged to the VR
All networking rules should be set for all the networks that got plugged.
If there was some network in non-implemented/non-setup state, its rules will
not get applied. They will get applied later as a part of network implement.
So once #1 is fixed, the LB rules issue will get fixed as well.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6199) Action Events - hide them when display flag is off in the context of Ability to have better control over first class objects in CS feature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13921734#comment-13921734 ] ASF subversion and git services commented on CLOUDSTACK-6199: - Commit 830328b63da3c720712263d792f0393ea547466d in cloudstack's branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=830328b ] CLOUDSTACK-6199: Hide action events for Vm/Volume commands when the resources have display flag=0. Introduce generic BaseAsync(Vm/Volume)Cmd to make get the flag value for logging action events. Rename the db field as display rather than display_event in keeping with the convention Action Events - hide them when display flag is off in the context of Ability to have better control over first class objects in CS feature Key: CLOUDSTACK-6199 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6199 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Fix For: 4.4.0 Action Events - hide them when display flag is off in the context of Ability to have better control over first class objects in CS feature. For root admin - s/he should be able to see all the events despite the value of the flag. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6207) Completely remove the Config.java and use the new ConfigKey framework
Alex Huang created CLOUDSTACK-6207: -- Summary: Completely remove the Config.java and use the new ConfigKey framework Key: CLOUDSTACK-6207 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6207 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Alex Huang The new way to do configuration is more comprehensive and doesn't require plugins to add their configurations to the same central file. However, old parameters have not been broken apart. Please help in migrating the enums defined in Config.java to the new ConfigKey parameter. See https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6208) Enhance ConfigKey to include per management server configurations
Alex Huang created CLOUDSTACK-6208: -- Summary: Enhance ConfigKey to include per management server configurations Key: CLOUDSTACK-6208 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6208 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Alex Huang There are a number of parameters in the global config parameters that should not be in a database table. Most of them have to do with management server configurations. For example, workers=500. By having this in the database, it forces all nodes of the management server cluster to use 500 worker threads. However, what if the management server nodes are not homogeneous. Someone should go through the global parameters and identify the ones that should be per management server and move those into a properties file. The new configuration mechanism already presents a ConfigDepot which can high this implementation. It already has a scope for management server but the implementation to read it from a properties file is missing. The work to identify the parameters that should be per management server also needs to be done. See https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6198) VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13921945#comment-13921945 ] angeline shen commented on CLOUDSTACK-6198: --- Reproduced problem with CloudPlatform-QA-4.3-0.292-rhel6.3.tar.gz (few days old): 1. vpc1 Tier 1 has 2 subnets : gw IP range VM -- 10.223.123.1 10.223.123.15 - 10.223.123.35i-2-4-VM i-2-5-VM 10.223.123.129 10.223.123.130 - 10.223.123.135 i-2-6i-2-7 2. vpc VR r-3 originally has 4 NIC entries eth0 eth1 eth2 eth3 : root@r-3-VM:~# ifconfig eth0 Link encap:Ethernet HWaddr 0e:00:a9:fe:02:44 inet addr:169.254.2.68 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::c00:a9ff:fefe:244/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3866 errors:0 dropped:0 overruns:0 frame:0 TX packets:3683 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:486452 (475.0 KiB) TX bytes:728142 (711.0 KiB) Interrupt:25 eth1 Link encap:Ethernet HWaddr 06:6c:1c:00:00:18 inet addr:10.223.123.17 Bcast:10.223.123.63 Mask:255.255.255.192 inet6 addr: fe80::46c:1cff:fe00:18/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:37961 errors:0 dropped:0 overruns:0 frame:0 TX packets:28208 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:45124780 (43.0 MiB) TX bytes:2938173 (2.8 MiB) Interrupt:24 eth2 Link encap:Ethernet HWaddr 02:00:69:5e:00:02 inet addr:10.1.1.1 Bcast:10.1.1.255 Mask:255.255.255.0 inet6 addr: fe80::69ff:fe5e:2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:47569 errors:0 dropped:0 overruns:0 frame:0 TX packets:63799 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4695934 (4.4 MiB) TX bytes:47489122 (45.2 MiB) Interrupt:26 eth3 Link encap:Ethernet HWaddr 06:d5:26:00:00:2b inet addr:10.223.123.130 Bcast:10.223.123.191 Mask:255.255.255.192 inet6 addr: fe80::4d5:26ff:fe00:2b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5805 errors:0 dropped:0 overruns:0 frame:0 TX packets:8530 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:340836 (332.8 KiB) TX bytes:1595764 (1.5 MiB) Interrupt:27 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:26 errors:0 dropped:0 overruns:0 frame:0 TX packets:26 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4827 (4.7 KiB) TX bytes:4827 (4.7 KiB) 3. attachment iptables1.doc = r-3 original iptables-save 4. after restart vpc, In UI VR r-3 has 3 entries, missing source NAT entry. But ifconfig shows 2 missing entries eth1 eth3: root@r-8-VM:~# ifconfig eth0 Link encap:Ethernet HWaddr 0e:00:a9:fe:01:c9 inet addr:169.254.1.201 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::c00:a9ff:fefe:1c9/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:697 errors:0 dropped:0 overruns:0 frame:0 TX packets:622 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:59140 (57.7 KiB) TX bytes:332580 (324.7 KiB) Interrupt:25 eth2 Link encap:Ethernet HWaddr 02:00:52:38:00:06 inet addr:10.1.1.1 Bcast:10.1.1.255 Mask:255.255.255.0 inet6 addr: fe80::52ff:fe38:6/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:534 (534.0 B) Interrupt:26 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:214 (214.0 B) TX bytes:214 (214.0 B) 5. attachment iptables2.doc shows iptables-save after restart vpc
[jira] [Updated] (CLOUDSTACK-6198) VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angeline shen updated CLOUDSTACK-6198: -- Attachment: v1.png VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart --- Key: CLOUDSTACK-6198 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6198 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Blocker Fix For: 4.3.0 Attachments: v1.png Regression bug. Steps to reproduce: 1. Create vpc and launch a vm in one tear. 2. vpc source ip address is from one subnet (ex: 10.147.52.1) 3. Acquire another public ip address from new public subnet. 4. create static nat on it to plug the nic on VR. 5. Now the VR has link local nic, guest nic, source nat ip nic and second public range nic. 6. Restart the vpc. 7. After restart there is no source nat nic. 8. If we restart vpc again observed that more nics are missed. I do observe the HUGE problem in 4.3 in VpcVirtualNetworkApplianceManager.java createVpcRouterNetworks() method. In 4.2 we used to store vm's nics in the ArrayList datastructure: ListPairNetworkVO, NicProfile networks = new ArrayListPairNetworkVO, NicProfile(4); ArrayList does allow duplicates. Then in 4.3 the datastructure was changed to LinkedHashMap that doesn't allow duplicates: LinkedHashMapNetwork, NicProfile networks = new LinkedHashMapNetwork, NicProfile(4); To fix the problem, the datastructure has to be changed to LinkedHashMapNetwork, ListNicProfile. It has to be changed all the way up to VirtualMachienManagerImpl where the nics are being passed to. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6198) VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angeline shen updated CLOUDSTACK-6198: -- Attachment: v3.png v2.png v1.png VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart --- Key: CLOUDSTACK-6198 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6198 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Blocker Fix For: 4.3.0 Attachments: v1.png, v2.png, v3.png Regression bug. Steps to reproduce: 1. Create vpc and launch a vm in one tear. 2. vpc source ip address is from one subnet (ex: 10.147.52.1) 3. Acquire another public ip address from new public subnet. 4. create static nat on it to plug the nic on VR. 5. Now the VR has link local nic, guest nic, source nat ip nic and second public range nic. 6. Restart the vpc. 7. After restart there is no source nat nic. 8. If we restart vpc again observed that more nics are missed. I do observe the HUGE problem in 4.3 in VpcVirtualNetworkApplianceManager.java createVpcRouterNetworks() method. In 4.2 we used to store vm's nics in the ArrayList datastructure: ListPairNetworkVO, NicProfile networks = new ArrayListPairNetworkVO, NicProfile(4); ArrayList does allow duplicates. Then in 4.3 the datastructure was changed to LinkedHashMap that doesn't allow duplicates: LinkedHashMapNetwork, NicProfile networks = new LinkedHashMapNetwork, NicProfile(4); To fix the problem, the datastructure has to be changed to LinkedHashMapNetwork, ListNicProfile. It has to be changed all the way up to VirtualMachienManagerImpl where the nics are being passed to. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6198) VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angeline shen updated CLOUDSTACK-6198: -- Attachment: (was: v1.png) VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart --- Key: CLOUDSTACK-6198 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6198 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Blocker Fix For: 4.3.0 Attachments: v1.png, v2.png, v3.png Regression bug. Steps to reproduce: 1. Create vpc and launch a vm in one tear. 2. vpc source ip address is from one subnet (ex: 10.147.52.1) 3. Acquire another public ip address from new public subnet. 4. create static nat on it to plug the nic on VR. 5. Now the VR has link local nic, guest nic, source nat ip nic and second public range nic. 6. Restart the vpc. 7. After restart there is no source nat nic. 8. If we restart vpc again observed that more nics are missed. I do observe the HUGE problem in 4.3 in VpcVirtualNetworkApplianceManager.java createVpcRouterNetworks() method. In 4.2 we used to store vm's nics in the ArrayList datastructure: ListPairNetworkVO, NicProfile networks = new ArrayListPairNetworkVO, NicProfile(4); ArrayList does allow duplicates. Then in 4.3 the datastructure was changed to LinkedHashMap that doesn't allow duplicates: LinkedHashMapNetwork, NicProfile networks = new LinkedHashMapNetwork, NicProfile(4); To fix the problem, the datastructure has to be changed to LinkedHashMapNetwork, ListNicProfile. It has to be changed all the way up to VirtualMachienManagerImpl where the nics are being passed to. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6198) VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13921957#comment-13921957 ] angeline shen commented on CLOUDSTACK-6198: --- After restart vpc second time, same result as restart vpc first time. VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart --- Key: CLOUDSTACK-6198 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6198 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Blocker Fix For: 4.3.0 Attachments: v1.png, v2.png, v3.png Regression bug. Steps to reproduce: 1. Create vpc and launch a vm in one tear. 2. vpc source ip address is from one subnet (ex: 10.147.52.1) 3. Acquire another public ip address from new public subnet. 4. create static nat on it to plug the nic on VR. 5. Now the VR has link local nic, guest nic, source nat ip nic and second public range nic. 6. Restart the vpc. 7. After restart there is no source nat nic. 8. If we restart vpc again observed that more nics are missed. I do observe the HUGE problem in 4.3 in VpcVirtualNetworkApplianceManager.java createVpcRouterNetworks() method. In 4.2 we used to store vm's nics in the ArrayList datastructure: ListPairNetworkVO, NicProfile networks = new ArrayListPairNetworkVO, NicProfile(4); ArrayList does allow duplicates. Then in 4.3 the datastructure was changed to LinkedHashMap that doesn't allow duplicates: LinkedHashMapNetwork, NicProfile networks = new LinkedHashMapNetwork, NicProfile(4); To fix the problem, the datastructure has to be changed to LinkedHashMapNetwork, ListNicProfile. It has to be changed all the way up to VirtualMachienManagerImpl where the nics are being passed to. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-5872) Async response from addAccountToProject doesn't contain useful information
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Grizzanti closed CLOUDSTACK-5872. --- Resolution: Won't Fix Async response from addAccountToProject doesn't contain useful information -- Key: CLOUDSTACK-5872 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5872 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Reporter: Bill Jones Assignee: David Grizzanti Fix For: 4.4.0 Attachments: unnamed.patch The async response from addAccountToProject doesn't contain useful information. Generally async responses for commands that modify resources include the resource ID and/or description in the async response. This is not true of addAccountToProject or deleteAccountFromProject. Consequently the response is not so useful to clients that do not have access to the context of the request. Also, it seems inconsistent with the general design of the API. -- This message was sent by Atlassian JIRA (v6.2#6252)
