Build failed in Jenkins: build-master-slowbuild #1493
See http://jenkins.buildacloud.org/job/build-master-slowbuild/1493/ -- [...truncated 27281 lines...] [INFO] No sources to compile [INFO] [INFO] findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud [INFO] [INFO] --- findbugs-maven-plugin:3.0.0:findbugs (findbugs) @ cloud-quickcloud --- [INFO] [INFO] findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud [INFO] [INFO] --- findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud --- [INFO] [INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ cloud-quickcloud --- [WARNING] No files to instrument. [INFO] NOT adding cobertura ser file to attached artifacts list. [INFO] [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ cloud-quickcloud --- [debug] execute contextualize [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory http://jenkins.buildacloud.org/job/build-master-slowbuild/ws/quickcloud/src/test/resources [INFO] Copying 3 resources [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ cloud-quickcloud --- [INFO] No sources to compile [INFO] [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud --- [INFO] [INFO] cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-quickcloud [INFO] [INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-quickcloud --- [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache CloudStack Developer Tools - Checkstyle Configuration SUCCESS [1.997s] [INFO] Apache CloudStack . SUCCESS [2.381s] [INFO] Apache CloudStack Maven Conventions Parent SUCCESS [0.806s] [INFO] Apache CloudStack Framework - Managed Context . SUCCESS [22.085s] [INFO] Apache CloudStack Utils ... SUCCESS [1:28.312s] [INFO] Apache CloudStack Framework ... SUCCESS [0.150s] [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [52.347s] [INFO] Apache CloudStack Framework - Configuration ... SUCCESS [28.549s] [INFO] Apache CloudStack API . SUCCESS [1:47.993s] [INFO] Apache CloudStack Framework - REST SUCCESS [17.353s] [INFO] Apache CloudStack Framework - IPC . SUCCESS [32.165s] [INFO] Apache CloudStack Cloud Engine SUCCESS [0.111s] [INFO] Apache CloudStack Cloud Engine API SUCCESS [29.779s] [INFO] Apache CloudStack Framework - Security SUCCESS [26.477s] [INFO] Apache CloudStack Core SUCCESS [1:17.435s] [INFO] Apache CloudStack Agents .. SUCCESS [37.354s] [INFO] Apache CloudStack Framework - Clustering .. SUCCESS [32.013s] [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [15.862s] [INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:05.686s] [INFO] Apache CloudStack Framework - Jobs SUCCESS [47.643s] [INFO] Apache CloudStack Cloud Engine Internal Components API SUCCESS [30.886s] [INFO] Apache CloudStack Server .. SUCCESS [4:15.999s] [INFO] Apache CloudStack Usage Server SUCCESS [49.410s] [INFO] Apache CloudStack Cloud Engine Orchestration Component SUCCESS [1:23.642s] [INFO] Apache CloudStack Cloud Services .. SUCCESS [0.070s] [INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.535s] [INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [1:06.511s] [INFO] Apache CloudStack Engine Storage Component SUCCESS [54.019s] [INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [34.878s] [INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [30.341s] [INFO] Apache CloudStack Engine Storage Data Motion Component SUCCESS [33.857s] [INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [21.650s] [INFO] Apache CloudStack Engine Storage Snapshot Component SUCCESS [42.578s] [INFO] Apache CloudStack Cloud Engine API SUCCESS [1:44.856s] [INFO] Apache CloudStack Cloud Engine Service SUCCESS [52.245s] [INFO] Apache CloudStack Plugin POM .. SUCCESS [6.927s] [INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [2:15.597s] [INFO] Apache CloudStack Plugin - Storage Volume default provider SUCCESS [31.765s] [INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider SUCCESS [1:01.610s] [INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [29.743s] [INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [53.858s] [INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [19.979s] [INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor
Build failed in Jenkins: build-master-slowbuild #1494
See http://jenkins.buildacloud.org/job/build-master-slowbuild/1494/ -- [...truncated 27274 lines...] [INFO] No sources to compile [INFO] [INFO] findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud [INFO] [INFO] --- findbugs-maven-plugin:3.0.0:findbugs (findbugs) @ cloud-quickcloud --- [INFO] [INFO] findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud [INFO] [INFO] --- findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud --- [INFO] [INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ cloud-quickcloud --- [WARNING] No files to instrument. [INFO] NOT adding cobertura ser file to attached artifacts list. [INFO] [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ cloud-quickcloud --- [debug] execute contextualize [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory http://jenkins.buildacloud.org/job/build-master-slowbuild/ws/quickcloud/src/test/resources [INFO] Copying 3 resources [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ cloud-quickcloud --- [INFO] No sources to compile [INFO] [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud --- [INFO] [INFO] cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-quickcloud [INFO] [INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-quickcloud --- [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache CloudStack Developer Tools - Checkstyle Configuration SUCCESS [1.730s] [INFO] Apache CloudStack . SUCCESS [2.081s] [INFO] Apache CloudStack Maven Conventions Parent SUCCESS [0.794s] [INFO] Apache CloudStack Framework - Managed Context . SUCCESS [21.417s] [INFO] Apache CloudStack Utils ... SUCCESS [1:33.230s] [INFO] Apache CloudStack Framework ... SUCCESS [0.152s] [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [50.816s] [INFO] Apache CloudStack Framework - Configuration ... SUCCESS [27.752s] [INFO] Apache CloudStack API . SUCCESS [1:46.919s] [INFO] Apache CloudStack Framework - REST SUCCESS [17.930s] [INFO] Apache CloudStack Framework - IPC . SUCCESS [30.448s] [INFO] Apache CloudStack Cloud Engine SUCCESS [0.091s] [INFO] Apache CloudStack Cloud Engine API SUCCESS [29.214s] [INFO] Apache CloudStack Framework - Security SUCCESS [25.250s] [INFO] Apache CloudStack Core SUCCESS [1:16.508s] [INFO] Apache CloudStack Agents .. SUCCESS [36.781s] [INFO] Apache CloudStack Framework - Clustering .. SUCCESS [32.386s] [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [15.796s] [INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:03.226s] [INFO] Apache CloudStack Framework - Jobs SUCCESS [42.479s] [INFO] Apache CloudStack Cloud Engine Internal Components API SUCCESS [31.444s] [INFO] Apache CloudStack Server .. SUCCESS [4:06.356s] [INFO] Apache CloudStack Usage Server SUCCESS [50.856s] [INFO] Apache CloudStack Cloud Engine Orchestration Component SUCCESS [1:27.064s] [INFO] Apache CloudStack Cloud Services .. SUCCESS [0.077s] [INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.432s] [INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [53.634s] [INFO] Apache CloudStack Engine Storage Component SUCCESS [54.271s] [INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [40.768s] [INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [28.936s] [INFO] Apache CloudStack Engine Storage Data Motion Component SUCCESS [33.515s] [INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [19.604s] [INFO] Apache CloudStack Engine Storage Snapshot Component SUCCESS [38.729s] [INFO] Apache CloudStack Cloud Engine API SUCCESS [13.186s] [INFO] Apache CloudStack Cloud Engine Service SUCCESS [6.859s] [INFO] Apache CloudStack Plugin POM .. SUCCESS [0.820s] [INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [27.850s] [INFO] Apache CloudStack Plugin - Storage Volume default provider SUCCESS [1:30.704s] [INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider SUCCESS [4:02.693s] [INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [23.097s] [INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [30.196s] [INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [32.682s] [INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor
Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
In case of #1 timing of reboot will also have impact and may result to undesired behaviour as both CloudStack and native HA trying to act on same VM. Regards, Anshul On 04-Jun-2015, at 2:35 pm, Remi Bergsma rberg...@schubergphilis.commailto:rberg...@schubergphilis.com wrote: To summarise: #1. rebooting VR is needed for hypervisors that have their own DR (like VMware and Hyperv) as a restart outside of CloudStack makes it lose its config hence the VR is unavailable #2. rebooting is NOT needed for successful live migrations on _any_ hypervisor (since there was no restart everything still works) #3. CloudStack 4.6 has persistent config in VR, so rebooting is never needed The current behaviour in 4.4.3, 4.5.1 and master: - always rebooting VR when out-of-band detected == Works great for #1, but makes case #2 not work The previous behaviour: - never rebooting VR when out-of-band detected == Works great for #2, but makes case #1 not work We need something that works for both cases :-) About #1 and #2: Can we detect in another way that a VR became unreachable/non-functional and do an action based on that? So, if a VR lives on a VMware hypervisor that happens to crash, VMware HA will start it on another available hypervisor but without config it will not be reachable on the control network. If we want to do it generic, I’d say that when a VR is not controllable any more we could reboot it. We could also make this a setting ‘systemvm auto reboot on control failure’ or whatever we call it. This would then also be a useful feature in 4.6 About #3: I’d suggest at least reverting the commit to master, as it makes no sense since the VR is persistent already. https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java#L2638 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=c3515c9 Regards, Remi On 04 Jun 2015, at 10:03, Wilder Rodrigues wrodrig...@schubergphilis.commailto:wrodrig...@schubergphilis.com wrote: There was a bug in the persistent stuff that was fixed here: https://issues.apache.org/jira/browse/CLOUDSTACK-4605 User data, IP tables, guest networks and pretty much everything else will be persisted. Cheers, Wilder On 04 Jun 2015, at 09:54, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: On Thu, Jun 4, 2015 at 8:15 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.commailto:jayapalreddy.ur...@citrix.commailto:jayapalreddy.ur...@citrix.com wrote: In VR configuration persistence (4.6) only iptables rules are persisted ? There are other configuration (interface ips, routes etc in VR will be lost on reboot) are these taken care ? By design all config is persisted but let's double check on that. @Ian: sir, can you confirm? -- Daan (being to lazy/busy to check the code)
Build failed in Jenkins: build-master-slowbuild #1492
See http://jenkins.buildacloud.org/job/build-master-slowbuild/1492/ -- [...truncated 27274 lines...] [INFO] No sources to compile [INFO] [INFO] findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud [INFO] [INFO] --- findbugs-maven-plugin:3.0.0:findbugs (findbugs) @ cloud-quickcloud --- [INFO] [INFO] findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud [INFO] [INFO] --- findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud --- [INFO] [INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ cloud-quickcloud --- [WARNING] No files to instrument. [INFO] NOT adding cobertura ser file to attached artifacts list. [INFO] [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ cloud-quickcloud --- [debug] execute contextualize [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory http://jenkins.buildacloud.org/job/build-master-slowbuild/ws/quickcloud/src/test/resources [INFO] Copying 3 resources [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ cloud-quickcloud --- [INFO] No sources to compile [INFO] [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud --- [INFO] [INFO] cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-quickcloud [INFO] [INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-quickcloud --- [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache CloudStack Developer Tools - Checkstyle Configuration SUCCESS [2.574s] [INFO] Apache CloudStack . SUCCESS [2.581s] [INFO] Apache CloudStack Maven Conventions Parent SUCCESS [1.041s] [INFO] Apache CloudStack Framework - Managed Context . SUCCESS [28.317s] [INFO] Apache CloudStack Utils ... SUCCESS [1:31.968s] [INFO] Apache CloudStack Framework ... SUCCESS [0.104s] [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [52.606s] [INFO] Apache CloudStack Framework - Configuration ... SUCCESS [28.050s] [INFO] Apache CloudStack API . SUCCESS [1:54.900s] [INFO] Apache CloudStack Framework - REST SUCCESS [30.626s] [INFO] Apache CloudStack Framework - IPC . SUCCESS [30.715s] [INFO] Apache CloudStack Cloud Engine SUCCESS [0.085s] [INFO] Apache CloudStack Cloud Engine API SUCCESS [30.273s] [INFO] Apache CloudStack Framework - Security SUCCESS [24.640s] [INFO] Apache CloudStack Core SUCCESS [1:24.959s] [INFO] Apache CloudStack Agents .. SUCCESS [36.775s] [INFO] Apache CloudStack Framework - Clustering .. SUCCESS [33.103s] [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [17.589s] [INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:03.047s] [INFO] Apache CloudStack Framework - Jobs SUCCESS [39.933s] [INFO] Apache CloudStack Cloud Engine Internal Components API SUCCESS [26.059s] [INFO] Apache CloudStack Server .. SUCCESS [3:59.908s] [INFO] Apache CloudStack Usage Server SUCCESS [45.354s] [INFO] Apache CloudStack Cloud Engine Orchestration Component SUCCESS [1:21.387s] [INFO] Apache CloudStack Cloud Services .. SUCCESS [0.080s] [INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.473s] [INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [55.716s] [INFO] Apache CloudStack Engine Storage Component SUCCESS [46.879s] [INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [34.522s] [INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [29.258s] [INFO] Apache CloudStack Engine Storage Data Motion Component SUCCESS [24.328s] [INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [21.445s] [INFO] Apache CloudStack Engine Storage Snapshot Component SUCCESS [39.502s] [INFO] Apache CloudStack Cloud Engine API SUCCESS [13.957s] [INFO] Apache CloudStack Cloud Engine Service SUCCESS [6.164s] [INFO] Apache CloudStack Plugin POM .. SUCCESS [0.836s] [INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [27.280s] [INFO] Apache CloudStack Plugin - Storage Volume default provider SUCCESS [24.264s] [INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider SUCCESS [38.344s] [INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [18.788s] [INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [24.922s] [INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [17.752s] [INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor SUCCESS
Re: Strange bug? spam in management log files...
And if of any help another hint: while Im having this lines sent to logs in high volume...if I stop second mgmt server, first one (that is making all these lines, doesnt stop to make them), so log is still heavily writen to - only when I also restart mgmt on 1st node (2nd node is down), then these log lines dissapear. Thx On 4 June 2015 at 19:19, Andrija Panic andrija.pa...@gmail.com wrote: And I could add - these lines (in this volume) only appears on first mgmt server (Actually I have 2 separate, but identical ACS installations, and same behaviour). On 4 June 2015 at 19:18, Andrija Panic andrija.pa...@gmail.com wrote: Just checked, in the HOSTS table, all agents are connected (via haproxy) to the first mgmt server...I just restarted haproxy, and still inside the DB, it says same mgmt_server_id for all agents - which is not really true. Actually, on the haproxy itslef (statistics page) I can see almoust 50%-50% distribution across 2 backends - which means by haproxy it should be fine. total 18 agents, 10 goes to 1 backend, 8 goes to other backend (ACS mgmt server) This is our haproxy config, I think it's fine, but... DB says differently, althouh haproxy statistick say all fine ### ACS 8250 ### frontend front_ACS_8250 10.20.10.100:8250 option tcplog mode tcp default_backend back_8250 backend back_8250 mode tcp balance source server acs1_8250 10.20.10.7:8250 check port 8250 inter 2000 rise 3 fall 3 server acs2_8250 10.20.10.8:8250 check port 8250 inter 2000 rise 3 fall 3 ## Any info on how to proceed with this, since because of these lines, it makes mgmt logs almoust unreadable... :( Thanks, Andrija On 4 June 2015 at 19:00, Andrija Panic andrija.pa...@gmail.com wrote: Thanks Koushik, I will check and let you know - but 11GB log file for 10h ? I dont expect this is expected :) I understand that the message is there because of setup, just an awful lot of lines Will check thx for the help ! Andrija On 4 June 2015 at 18:53, Koushik Das koushik@citrix.com wrote: This is expected in a clustered MS setup. What is the distribution of HV hosts across these MS (check host table in db for MS id)? MS owning the HV host processes all commands for that host. Grep for the sequence numbers (for e.g. 73-7374644389819187201) in both MS logs to correlate. On 04-Jun-2015, at 8:30 PM, Andrija Panic andrija.pa...@gmail.com wrote: Hi, I have 2 ACS MGMT servers, loadbalanced properly (AFAIK), and sometimes it happens that on the first node, we have extremem number of folowing line entries in the log fie, which causes many GB log in just few hours or less: (as you can see here they are not even that frequent, but sometimes, it gets really crazy with the speed/numer logged per seconds: 2015-06-04 16:55:04,089 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-29:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,129 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-28:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,129 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-8:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,169 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-26:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,169 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-30:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,209 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-27:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,209 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-2:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,249 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-4:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,249 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-7:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,289 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-3:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,289 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-5:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,329
Build failed in Jenkins: build-master-slowbuild #1490
See http://jenkins.buildacloud.org/job/build-master-slowbuild/1490/ -- [...truncated 27274 lines...] [INFO] No sources to compile [INFO] [INFO] findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud [INFO] [INFO] --- findbugs-maven-plugin:3.0.0:findbugs (findbugs) @ cloud-quickcloud --- [INFO] [INFO] findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud [INFO] [INFO] --- findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud --- [INFO] [INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ cloud-quickcloud --- [WARNING] No files to instrument. [INFO] NOT adding cobertura ser file to attached artifacts list. [INFO] [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ cloud-quickcloud --- [debug] execute contextualize [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory http://jenkins.buildacloud.org/job/build-master-slowbuild/ws/quickcloud/src/test/resources [INFO] Copying 3 resources [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ cloud-quickcloud --- [INFO] No sources to compile [INFO] [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud --- [INFO] [INFO] cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-quickcloud [INFO] [INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-quickcloud --- [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache CloudStack Developer Tools - Checkstyle Configuration SUCCESS [1.845s] [INFO] Apache CloudStack . SUCCESS [2.295s] [INFO] Apache CloudStack Maven Conventions Parent SUCCESS [0.937s] [INFO] Apache CloudStack Framework - Managed Context . SUCCESS [22.160s] [INFO] Apache CloudStack Utils ... SUCCESS [1:27.874s] [INFO] Apache CloudStack Framework ... SUCCESS [0.108s] [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [52.356s] [INFO] Apache CloudStack Framework - Configuration ... SUCCESS [29.597s] [INFO] Apache CloudStack API . SUCCESS [1:53.434s] [INFO] Apache CloudStack Framework - REST SUCCESS [21.992s] [INFO] Apache CloudStack Framework - IPC . SUCCESS [32.458s] [INFO] Apache CloudStack Cloud Engine SUCCESS [0.087s] [INFO] Apache CloudStack Cloud Engine API SUCCESS [29.280s] [INFO] Apache CloudStack Framework - Security SUCCESS [25.112s] [INFO] Apache CloudStack Core SUCCESS [1:15.590s] [INFO] Apache CloudStack Agents .. SUCCESS [35.586s] [INFO] Apache CloudStack Framework - Clustering .. SUCCESS [40.871s] [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [18.159s] [INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [1:59.036s] [INFO] Apache CloudStack Framework - Jobs SUCCESS [38.775s] [INFO] Apache CloudStack Cloud Engine Internal Components API SUCCESS [25.465s] [INFO] Apache CloudStack Server .. SUCCESS [3:56.667s] [INFO] Apache CloudStack Usage Server SUCCESS [44.606s] [INFO] Apache CloudStack Cloud Engine Orchestration Component SUCCESS [1:22.279s] [INFO] Apache CloudStack Cloud Services .. SUCCESS [0.069s] [INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.457s] [INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [56.779s] [INFO] Apache CloudStack Engine Storage Component SUCCESS [47.765s] [INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [33.597s] [INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [36.542s] [INFO] Apache CloudStack Engine Storage Data Motion Component SUCCESS [35.701s] [INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [20.901s] [INFO] Apache CloudStack Engine Storage Snapshot Component SUCCESS [43.602s] [INFO] Apache CloudStack Cloud Engine API SUCCESS [13.569s] [INFO] Apache CloudStack Cloud Engine Service SUCCESS [6.994s] [INFO] Apache CloudStack Plugin POM .. SUCCESS [0.835s] [INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [27.462s] [INFO] Apache CloudStack Plugin - Storage Volume default provider SUCCESS [25.601s] [INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider SUCCESS [38.147s] [INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [19.991s] [INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [25.531s] [INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [19.857s] [INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor SUCCESS
Re: Strange bug? spam in management log files...
Just checked, in the HOSTS table, all agents are connected (via haproxy) to the first mgmt server...I just restarted haproxy, and still inside the DB, it says same mgmt_server_id for all agents - which is not really true. Actually, on the haproxy itslef (statistics page) I can see almoust 50%-50% distribution across 2 backends - which means by haproxy it should be fine. total 18 agents, 10 goes to 1 backend, 8 goes to other backend (ACS mgmt server) This is our haproxy config, I think it's fine, but... DB says differently, althouh haproxy statistick say all fine ### ACS 8250 ### frontend front_ACS_8250 10.20.10.100:8250 option tcplog mode tcp default_backend back_8250 backend back_8250 mode tcp balance source server acs1_8250 10.20.10.7:8250 check port 8250 inter 2000 rise 3 fall 3 server acs2_8250 10.20.10.8:8250 check port 8250 inter 2000 rise 3 fall 3 ## Any info on how to proceed with this, since because of these lines, it makes mgmt logs almoust unreadable... :( Thanks, Andrija On 4 June 2015 at 19:00, Andrija Panic andrija.pa...@gmail.com wrote: Thanks Koushik, I will check and let you know - but 11GB log file for 10h ? I dont expect this is expected :) I understand that the message is there because of setup, just an awful lot of lines Will check thx for the help ! Andrija On 4 June 2015 at 18:53, Koushik Das koushik@citrix.com wrote: This is expected in a clustered MS setup. What is the distribution of HV hosts across these MS (check host table in db for MS id)? MS owning the HV host processes all commands for that host. Grep for the sequence numbers (for e.g. 73-7374644389819187201) in both MS logs to correlate. On 04-Jun-2015, at 8:30 PM, Andrija Panic andrija.pa...@gmail.com wrote: Hi, I have 2 ACS MGMT servers, loadbalanced properly (AFAIK), and sometimes it happens that on the first node, we have extremem number of folowing line entries in the log fie, which causes many GB log in just few hours or less: (as you can see here they are not even that frequent, but sometimes, it gets really crazy with the speed/numer logged per seconds: 2015-06-04 16:55:04,089 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-29:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,129 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-28:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,129 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-8:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,169 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-26:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,169 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-30:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,209 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-27:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,209 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-2:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,249 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-4:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,249 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-7:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,289 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-3:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,289 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-5:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,329 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-1:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,330 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-15:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,369 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-11:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,369 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-17:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to
Re: Strange bug? spam in management log files...
And I could add - these lines (in this volume) only appears on first mgmt server (Actually I have 2 separate, but identical ACS installations, and same behaviour). On 4 June 2015 at 19:18, Andrija Panic andrija.pa...@gmail.com wrote: Just checked, in the HOSTS table, all agents are connected (via haproxy) to the first mgmt server...I just restarted haproxy, and still inside the DB, it says same mgmt_server_id for all agents - which is not really true. Actually, on the haproxy itslef (statistics page) I can see almoust 50%-50% distribution across 2 backends - which means by haproxy it should be fine. total 18 agents, 10 goes to 1 backend, 8 goes to other backend (ACS mgmt server) This is our haproxy config, I think it's fine, but... DB says differently, althouh haproxy statistick say all fine ### ACS 8250 ### frontend front_ACS_8250 10.20.10.100:8250 option tcplog mode tcp default_backend back_8250 backend back_8250 mode tcp balance source server acs1_8250 10.20.10.7:8250 check port 8250 inter 2000 rise 3 fall 3 server acs2_8250 10.20.10.8:8250 check port 8250 inter 2000 rise 3 fall 3 ## Any info on how to proceed with this, since because of these lines, it makes mgmt logs almoust unreadable... :( Thanks, Andrija On 4 June 2015 at 19:00, Andrija Panic andrija.pa...@gmail.com wrote: Thanks Koushik, I will check and let you know - but 11GB log file for 10h ? I dont expect this is expected :) I understand that the message is there because of setup, just an awful lot of lines Will check thx for the help ! Andrija On 4 June 2015 at 18:53, Koushik Das koushik@citrix.com wrote: This is expected in a clustered MS setup. What is the distribution of HV hosts across these MS (check host table in db for MS id)? MS owning the HV host processes all commands for that host. Grep for the sequence numbers (for e.g. 73-7374644389819187201) in both MS logs to correlate. On 04-Jun-2015, at 8:30 PM, Andrija Panic andrija.pa...@gmail.com wrote: Hi, I have 2 ACS MGMT servers, loadbalanced properly (AFAIK), and sometimes it happens that on the first node, we have extremem number of folowing line entries in the log fie, which causes many GB log in just few hours or less: (as you can see here they are not even that frequent, but sometimes, it gets really crazy with the speed/numer logged per seconds: 2015-06-04 16:55:04,089 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-29:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,129 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-28:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,129 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-8:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,169 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-26:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,169 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-30:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,209 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-27:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,209 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-2:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,249 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-4:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,249 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-7:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,289 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-3:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,289 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-5:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,329 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-1:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,330 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-15:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,369 DEBUG [c.c.a.m.ClusteredAgentManagerImpl]
Re: IPv6 ideas for Basic Networking
Hi Wido, Parts like DHCPv6, IP6Table, IPv6 network carving, IPv6 IP allocation etc could be reused. I proposed to implement RA in VPC Router. This could also be reused. And, there could be few others too.. I will ping you once you are back from vacation. Right now, I am in investigation mode. So, I might have few more details to discuss with you by then. Thanks, Suresh On Wed, Jun 3, 2015 at 11:36 AM, Wido den Hollander w...@widodh.nl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/29/2015 09:59 PM, Suresh Ramamurthy wrote: Hi Wido, After reading your IPv6 ideas for Basic Networking, I realized that couple of them can be reused for Advanced Networking too. Great! Like which parts? I guess there is a big overlap between Advanced and Basic networking. We have come up with a proposal for IPv6 support in VPC and it is posted in wiki https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+VPC+Rou ter Did you get a chance to look at it? Let me know your feedback on the DD. No, I didn't, but I really should! I work from bay area, so I will not be able to attend the meetup at Amsterdam. But, I would like to have a call/chat with you to discuss on further details about IPv6 support. I would like to schedule a conference call with you. Would you be available for the call? Yes, that seems like a good idea. I'm heading off on vacation and it won't be until around June 20th before I'll be available. Wido Thanks, Suresh On Sat, May 23, 2015 at 11:18 PM, Remi Bergsma rberg...@schubergphilis.com wrote: At Schuberg Philis we’ve been working on a design voor IPv6 in VPC networks (so this is Advanced Networking) and I indeed had a look at your functional spec. I’ll finalise what we’ve come up with and publish it early next week so we can align and discuss and work from there. Nice to see there is a design for Basic Networking as well! Regards, Remi On 24 May 2015, at 02:47, Marcus shadow...@gmail.com wrote: Did you guys review the functional spec that has been floating around on cwiki? On May 23, 2015 8:27 AM, Wido den Hollander w...@widodh.nl wrote: On 05/22/2015 11:05 PM, server24 Cloudstack wrote: Hi Wido, was nice talking to you about this. On 5/21/2015 8:59 PM, Wido den Hollander wrote: (IPv6) routers should send out RAs (Router Advertisements) with the managed-other-flag [0][1], telling Instances to ONLY use that routers as their default gateways and NOT to use SLAAC to autoconfigure their IP-Address. OK, so no autonomous flag No, the managed other flag as described in RFC 4862. Meaning that the Routers should only be used as a default gateway and DHCPv6 should be used for obtaining a address. The (ip6tables) Security Groups should allow ICMPv6 by default. IPv6 traffic breaks really hard without ICMPv6 traffic, for example PMTU doesn't work properly and breaks IPv6 connections. yes, and default ip(6)tables should be in place to block VNC-related traffic except to the Virtual Console (as currently VNC ports on IPv6 are world-wide-open in BASIC network)! Yes, but in that case you are talking about the Console Proxy which should be firewalled properly. In CloudStack we might configure a /48, but tell it to hand out addresses for each instance from a /64 out of that /48. That means we can have 65k Instances in that pod. Some firewall policies block a complete /64 when they see malicious traffic coming from that subnet, so if the subnet is big enough we should try to keep all the IPv6 addresses from one Instance in the same /64 subnet. This could also simplify the iptable rules. so one /48 per pod? RIRs provide either /48 or /32 (the latter to the providers) IPv6 blocks. So this should then be configurable, both per instance and per pod. One /48 per pod still looks large to me.. A /48 should be a possibility. If you only have a /64 available that should be no problem either. On the other hand any prefix more specific than /64 could break IPv6 features, so that there are at least some practical values to rely on. Security grouping has to be extended to also support IPv6, but should allow ICMPv6 by default. yes, ICMPv6 should be on by default (maybe it should be forced to be always on for IPv6?). At the end of June 2015 we want to keep a one-day meetup in Amsterdam with various developers to discuss some more details. great work and very good meeting, was a pleasure to be there. Thomas Moroder -- Incubatec GmbH - Srl Via Scurcia'str. 36, 39046 Ortisei(BZ), ITALY Registered with the chamber of commerce of Bolzano the 8th of November 2001 with REA-No. 168204 (s.c. of EUR 10.000 f.p.u.) President: Thomas Moroder, VAT-No. IT 02283140214 Tel: +39.0471796829 - Fax: +39.0471797949 IMPRINT: http://www.incubatec.com/imprint.html PRIVACY:
Re: Strange bug? spam in management log files...
Thanks Koushik, I will check and let you know - but 11GB log file for 10h ? I dont expect this is expected :) I understand that the message is there because of setup, just an awful lot of lines Will check thx for the help ! Andrija On 4 June 2015 at 18:53, Koushik Das koushik@citrix.com wrote: This is expected in a clustered MS setup. What is the distribution of HV hosts across these MS (check host table in db for MS id)? MS owning the HV host processes all commands for that host. Grep for the sequence numbers (for e.g. 73-7374644389819187201) in both MS logs to correlate. On 04-Jun-2015, at 8:30 PM, Andrija Panic andrija.pa...@gmail.com wrote: Hi, I have 2 ACS MGMT servers, loadbalanced properly (AFAIK), and sometimes it happens that on the first node, we have extremem number of folowing line entries in the log fie, which causes many GB log in just few hours or less: (as you can see here they are not even that frequent, but sometimes, it gets really crazy with the speed/numer logged per seconds: 2015-06-04 16:55:04,089 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-29:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,129 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-28:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,129 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-8:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,169 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-26:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,169 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-30:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,209 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-27:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,209 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-2:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,249 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-4:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,249 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-7:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,289 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-3:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,289 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-5:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,329 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-1:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,330 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-15:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,369 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-11:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,369 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-17:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,409 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-14:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,409 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-12:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer We have haproxy VIP, to which SSVM connects, and all cloudstack agents (agent.properties file). Any suggestions, how to avoid this - I noticed when I turn off second ACS MGMT server, and then reboot first one (restart cloudstack-management) it stops and behaves nice :) This is ACS 4.5.1, Ubuntu 14.04 for mgmt nodes. Thanks, -- Andrija Panić -- Andrija Panić
[GitHub] cloudstack pull request: Allow PropertiesUtil to read from jar fil...
GitHub user ProjectMoon opened a pull request: https://github.com/apache/cloudstack/pull/358 Allow PropertiesUtil to read from jar files. ## Commit Message PropertiesUtil has code for reading from jar files, but the findConfigFile method will prevent it from ever returning a file in a jar on the classpath since it always wants to have a file: URL and use the File class. This commit moves the jar file loading attempt from a catch block to an else clause, executed if a config file:// URL could not be found. ## Tests Performed Moved API commands from commands.properties to a file in a jar and started up the simulator. Verified that all 479 synced when running the sync command. You can merge this pull request into a Git repository by running: $ git pull https://github.com/greenqloud/cloudstack pr-read-properties-from-jars Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/358.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #358 commit ad37446a7b3c241686f6cd3e7af5fc3414fda7dd Author: jeff j...@greenqloud.com Date: 2015-06-04T16:35:34Z Allow PropertiesUtil to read from jar files. PropertiesUtil has code for reading from jar files, but the findConfigFile method will prevent it from ever returning a file in a jar on the classpath since it always wants to have a file: URL and use the File class. This commit moves the jar file loading attempt from a catch block to an else clause, executed if a config file:// URL could not be found. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Strange bug? spam in management log files...
This is expected in a clustered MS setup. What is the distribution of HV hosts across these MS (check host table in db for MS id)? MS owning the HV host processes all commands for that host. Grep for the sequence numbers (for e.g. 73-7374644389819187201) in both MS logs to correlate. On 04-Jun-2015, at 8:30 PM, Andrija Panic andrija.pa...@gmail.com wrote: Hi, I have 2 ACS MGMT servers, loadbalanced properly (AFAIK), and sometimes it happens that on the first node, we have extremem number of folowing line entries in the log fie, which causes many GB log in just few hours or less: (as you can see here they are not even that frequent, but sometimes, it gets really crazy with the speed/numer logged per seconds: 2015-06-04 16:55:04,089 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-29:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,129 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-28:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,129 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-8:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,169 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-26:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,169 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-30:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,209 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-27:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,209 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-2:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,249 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-4:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,249 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-7:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,289 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-3:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,289 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-5:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,329 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-1:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,330 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-15:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,369 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-11:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,369 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-17:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,409 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-14:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,409 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-12:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer We have haproxy VIP, to which SSVM connects, and all cloudstack agents (agent.properties file). Any suggestions, how to avoid this - I noticed when I turn off second ACS MGMT server, and then reboot first one (restart cloudstack-management) it stops and behaves nice :) This is ACS 4.5.1, Ubuntu 14.04 for mgmt nodes. Thanks, -- Andrija Panić
Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
+1 On 04 Jun 2015, at 14:29, Rohit Yadav rohit.ya...@shapeblue.commailto:rohit.ya...@shapeblue.com wrote: Hi, On 04-Jun-2015, at 11:05 am, Remi Bergsma rberg...@schubergphilis.commailto:rberg...@schubergphilis.com wrote: To summarise: #1. rebooting VR is needed for hypervisors that have their own DR (like VMware and Hyperv) as a restart outside of CloudStack makes it lose its config hence the VR is unavailable #2. rebooting is NOT needed for successful live migrations on _any_ hypervisor (since there was no restart everything still works) #3. CloudStack 4.6 has persistent config in VR, so rebooting is never needed The current behaviour in 4.4.3, 4.5.1 and master: - always rebooting VR when out-of-band detected == Works great for #1, but makes case #2 not work The previous behaviour: - never rebooting VR when out-of-band detected == Works great for #2, but makes case #1 not work We need something that works for both cases :-) About #1 and #2: Can we detect in another way that a VR became unreachable/non-functional and do an action based on that? So, if a VR lives on a VMware hypervisor that happens to crash, VMware HA will start it on another available hypervisor but without config it will not be reachable on the control network. If we want to do it generic, I’d say that when a VR is not controllable any more we could reboot it. We could also make this a setting ‘systemvm auto reboot on control failure’ or whatever we call it. This would then also be a useful feature in 4.6 About #3: I’d suggest at least reverting the commit to master, as it makes no sense since the VR is persistent already. https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java#L2638 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=c3515c9 I agree on master, we can revert due to #3. On 4.4 and 4.5 branches, if we revert it than it will break #1 and if we keep it - it breaks #2. We need to fix this in a hypervisor agnostic way. So, if we can use aggregated cmd execution that Sudhashu and others have shared, in case of an out of band migration we can do this: 1. If we’re unable to reach VR, we can keep the RebootTask to do its job. In many cases I’ve seen VR disk corruption, so if after rebooting VR (which might kick in fsck) it fails CloudStack may eventually recreate a new VR makes sense. This will solve #1. This case IMO is highly unlikely. 2. If we’re able to reach the VR after VR is migrated out of band, we run an AgrregationExecutionTask sending all the rules for that VR. This will solve #2 without needing to reboot a VM. This case is more likely to happen, so if I’ve pick between this and the above case, I would try to solve for this case. I’m not sure about the actual implementation, and will re-applying rules using a AgrregationExecutionTask cause any issue in the VR? Comments? Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.commailto:rohit.ya...@shapeblue.com Blog: bhaisaab.orghttp://bhaisaab.org/ | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
On 04 Jun 2015, at 16:50, Koushik Das koushik@citrix.commailto:koushik@citrix.com wrote: Thanks for the clarification Daan. So as I understand - after VR reboot outside of CS if there is any config differences (between persisted ones and DB) then MS will immediately push the config from DB to VR. Is that correct? Is there any document/write-up available for the persistence changes? Hi, I cannot find the docs we wrote up but will send the link when I do! Essentially the shell commands are replaced with json which is passed to VPCr or VR. The son object is then merged into a son configuration on the router. There is one config per type (firewallacls, lips, forwarding_rules etc.). These are stored in /etc/cloudstack. (See ./core/src/com/cloud/agent/resource/virtualnetwork/facade/ and ./core/src/com/cloud/agent/resource/virtualnetwork/model/) Each time the config is merged, some python runs which compares the configured state to the expected state from the json files. It will then provision (or deprovision) anything that has changed. (See systemvm/patches/debian/config/opt/cloud/bin/configure.py) In addition on reboot (planned or otherwise), the configurator is also called setting the provisioned state back to the last known good state. For VPCs we also implemented a redundant VPCr (based upon the same technology as the normal VR) and, calls to allow an upgrade from single VPCr to redundant VPCr. Beyond this, cloudstack will work the same as it always did. If it loses touch with a router, it will takes steps to recreate it etc. So yes, the router is no longer truly stateless but, cloudstack remains in charge. The intention is not to break the orchestration paradagm. — Grts! Ian
Build failed in Jenkins: build-master-slowbuild #1489
See http://jenkins.buildacloud.org/job/build-master-slowbuild/1489/changes
Changes:
[Daan Hoogland] Formatting the code - Adding final modifier to attributes and
indenting the code.
[Daan Hoogland] Coverity issue: 1012179 - Commenting out unused variable.
[Daan Hoogland] Formatting the code - Adding final modifier and indenting the
code
[Daan Hoogland] Coverity issue 1116509 - Assigning the the new returned
ResultSet to the rs variable in order to get it closed in the finally block
[Daan Hoogland] Formatting the code - Adding final modifier and indenting the
code
[Daan Hoogland] Coverity issue 1116677 - Avoiding catching only Exception.
Makes the code too britle. - Catching the QemuImgException and throwing it to
be caught further in the code - Surrounding the output stream with try/catch
and throwing it to be further handled in the code. Closing the output stream
quietly.
[Daan Hoogland] Coverity issue 1116812 - Replacing concatenation with
optionsBuffer.append(option.getKey()).append('=').append(option.getValue()).append(',');
[Daan Hoogland] Renaming the variable from s to script
[Daan Hoogland] Using a try-wioth resrouce block as suggested in @DaanHoogland
review.
--
[...truncated 27271 lines...]
[INFO] No sources to compile
[INFO]
[INFO] findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @
cloud-quickcloud
[INFO]
[INFO] --- findbugs-maven-plugin:3.0.0:findbugs (findbugs) @ cloud-quickcloud
---
[INFO]
[INFO] findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @
cloud-quickcloud
[INFO]
[INFO] --- findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @
cloud-quickcloud ---
[INFO]
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO]
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
http://jenkins.buildacloud.org/job/build-master-slowbuild/ws/quickcloud/src/test/resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @
cloud-quickcloud ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud
---
[INFO]
[INFO] cobertura-maven-plugin:2.6:cobertura (default-cli) @
cloud-quickcloud
[INFO]
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @
cloud-quickcloud ---
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration SUCCESS
[2.133s]
[INFO] Apache CloudStack . SUCCESS [2.651s]
[INFO] Apache CloudStack Maven Conventions Parent SUCCESS [0.996s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [22.590s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:29.761s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.107s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [51.271s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [28.283s]
[INFO] Apache CloudStack API . SUCCESS [1:46.580s]
[INFO] Apache CloudStack Framework - REST SUCCESS [17.310s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [30.644s]
[INFO] Apache CloudStack Cloud Engine SUCCESS [0.099s]
[INFO] Apache CloudStack Cloud Engine API SUCCESS [28.093s]
[INFO] Apache CloudStack Framework - Security SUCCESS [25.145s]
[INFO] Apache CloudStack Core SUCCESS [1:17.220s]
[INFO] Apache CloudStack Agents .. SUCCESS [37.110s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [31.635s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [16.216s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:03.178s]
[INFO] Apache CloudStack Framework - Jobs SUCCESS [40.208s]
[INFO] Apache CloudStack Cloud Engine Internal Components API SUCCESS [35.490s]
[INFO] Apache CloudStack Server .. SUCCESS [4:09.604s]
[INFO] Apache CloudStack Usage Server SUCCESS [48.690s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component SUCCESS
[1:28.443s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.069s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.453s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [56.330s]
[INFO] Apache CloudStack Engine Storage Component SUCCESS [1:00.126s]
[INFO] Apache CloudStack Engine
Re: database high availability question vs haproxy
Andrija, Here is the original design document, and it should give you a better idea of what is implemented today: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=34838207 We have plans to test this in our lab soon, but just haven't got around to it yet. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Thursday, June 4, 2015 9:08 AM To: dev@cloudstack.apache.org; us...@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Anyone :) ? On 31 May 2015 at 00:26, Andrija Panic andrija.pa...@gmail.com wrote: Hi, I would have a question on database HA feature in db.properties ( http://cloudstack-administration.readthedocs.org/en/latest/reliability.html#configuring-database-high-availability ) If I understand correctly, it is up to the admin to provide appropriate mysql HA (active-active, galera, etc) and ACS management server will JUST try to connect to slaves if the master is down ? We are running Galera, with haproxy/keepalived, and by using stoping haproxy, it takes i.e. 6sec for keepalived to detect haproxy is down, and failover IP to another host. During these 6 seconds, ACS managemnt server goes dead, because of this DB unavailability. So my wondering, is better to use ACS db HA feature, instead of loadbalancer for this specific purpose ? (we are also using haproxy/keepalived for management server loadbalancing - 2 servers in backend...) Any experience shared is really appreciated ! -- Andrija Panić -- Andrija Panić
[GitHub] cloudstack pull request: CLOUDSTACK-8537 add check for unique publ...
GitHub user DaanHoogland opened a pull request: https://github.com/apache/cloudstack/pull/357 CLOUDSTACK-8537 add check for unique public key on registration tests are following but need a manager refactor:( You can merge this pull request into a Git repository by running: $ git pull https://github.com/DaanHoogland/cloudstack CLOUDSTACK-8537 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/357.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #357 commit 94e0499b66c225350cd554116dad57bd68f2a4bc Author: Daan Hoogland daan.hoogl...@gmail.com Date: 2015-06-04T14:48:14Z CLODSTACK-8537 add check for unique public key on registration --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
Thanks for the clarification Daan. So as I understand - after VR reboot outside of CS if there is any config differences (between persisted ones and DB) then MS will immediately push the config from DB to VR. Is that correct? Is there any document/write-up available for the persistence changes? On 04-Jun-2015, at 5:28 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: On Thu, Jun 4, 2015 at 1:27 PM, Koushik Das koushik@citrix.com wrote: Is there a possibility for VR config and DB config to go out of sync? If so how is the config in the VR and DB kept in sync? Koushik, the db is leading and conversion is applied to the state of the router. On differences, newly sent config takes precedence. -- Daan
Strange bug? spam in management log files...
Hi, I have 2 ACS MGMT servers, loadbalanced properly (AFAIK), and sometimes it happens that on the first node, we have extremem number of folowing line entries in the log fie, which causes many GB log in just few hours or less: (as you can see here they are not even that frequent, but sometimes, it gets really crazy with the speed/numer logged per seconds: 2015-06-04 16:55:04,089 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-29:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,129 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-28:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,129 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-8:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,169 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-26:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,169 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-30:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,209 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-27:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,209 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-2:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,249 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-4:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,249 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-7:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,289 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-3:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,289 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-5:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,329 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-1:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,330 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-15:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,369 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-11:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,369 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-17:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,409 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-14:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,409 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-12:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer We have haproxy VIP, to which SSVM connects, and all cloudstack agents (agent.properties file). Any suggestions, how to avoid this - I noticed when I turn off second ACS MGMT server, and then reboot first one (restart cloudstack-management) it stops and behaves nice :) This is ACS 4.5.1, Ubuntu 14.04 for mgmt nodes. Thanks, -- Andrija Panić
Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
In VR configuration persistence (4.6) only iptables rules are persisted ? There are other configuration (interface ips, routes etc in VR will be lost on reboot) are these taken care ? Thanks, Jayapal On 04-Jun-2015, at 11:15 AM, Koushik Das koushik@citrix.com wrote: On 04-Jun-2015, at 12:04 AM, Remi Bergsma rberg...@schubergphilis.com wrote: Hi all, I just had a look at this more closely and had a chat with Ian about it. The only way for the original problem to happen (losing iptables rules) is if the live migrate would fail and the hypervisor rebooted the vm. The cause is the non-persistance of the router configuration, which is fixed in 4.6 by the way. I would say failing live migrations does not happen often (I have never seen it happening). What about native HA in Vmware and HyperV? Say the original host has failed, Vmware will bring up the VR on another host as part of native HA. In this case also the configuration is lost. Anyway, once this happens to the router, it is stuck in a state where it does not have the linklocal configuration any more. Would CloudStack be able to issue a aggregate command while it cannot reach it? Rebooting might be the only way out after all. It’s just that rebooting by default in case of out-of-band migrations I’d say is a little bit too much. CloudStack would detect the problem anyway, as it cannot reach the linklocal anymore. The interesting situation is that we have releases out there that now reboot by default. My proposal to solve it in 4.4 and 4.5: - Implement a setting ‘reboot systemvm when out-of-band migration detected’. The default should be false and release notes should mention a changed behaviour from 4.4.3 and 4.5.1. To get the old behaviour, switch to true. A small group of people should be interested in this. I guess this is the best of both worlds. Do you guys agree? The other option I see is to revert the commit, as I think that serves most people. Who is willing to help implement it? Regards, Remi On 03 Jun 2015, at 17:42, Rene Moser m...@renemoser.netmailto:m...@renemoser.net wrote: Hi On 03.06.2015 17:06, Ian Southam wrote: If the machine crashes and/or rebooted during the oob migration by a party that is not the orchestrator, (read vCenter) then the rules will be lost. I fully agree, a reboot due a failing live migration, would cause a reboot. So what? Then we blame VMware, the orchestration will reboot the VR and everything is fine. This would cause seconds of outage. But then the missing persistence of the iptables would be the problem, not the live migration task, right? We should fix the persistence of the rules during reboot and not try to be more clever then the hypervisor cluster orchestration. Just my 2 cents.
[GitHub] cloudstack pull request: Fix/coverity issues
GitHub user wilderrodrigues opened a pull request:
https://github.com/apache/cloudstack/pull/355
Fix/coverity issues
Fixing issues: 1012719, 1116509, 1116677 and 1116812
I split commit between fixes and code formatting in order to keep the
review as smooth as possible.
The fixes include:
* Commenting out an unused variable in the Test.java
* Assigning the ResultSet returned by the prepared statement and closing it
in the finally block
* Avoiding catching only Exception. Makes the code too britle.
* Catching the QemuImgException and throwing it to be caught further in the
code
* Surrounding the output stream with try/catch and throwing it to be
further handled in the code. Closing the output stream quietly.
* Replacing concatenation with
optionsBuffer.append(option.getKey()).append('=').append(option.getValue()).append(',');
Full build, including tests, was executed. I will deploy a DC and run VM
Life Cycle on KVM and XenServer62. Report will follow.
Cheers,
Wilder
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/schubergphilis/cloudstack fix/coverity_issues
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cloudstack/pull/355.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #355
commit 9ac4e6b1c4d6812af9c9edcccd7113035cf1
Author: wilderrodrigues wrodrig...@schubergphilis.com
Date: 2015-06-04T06:12:04Z
Formatting the code
- Adding final modifier to attributes and indenting the code.
commit 83429b8e61fbcb8c502b5c9ae08f7abfa7132370
Author: wilderrodrigues wrodrig...@schubergphilis.com
Date: 2015-06-04T06:12:50Z
Coverity issue: 1012179
- Commenting out unused variable.
commit 8d8952e72a886f78bfd12e6d443dc770c8d489d1
Author: wilderrodrigues wrodrig...@schubergphilis.com
Date: 2015-06-04T06:14:07Z
Formatting the code
- Adding final modifier and indenting the code
commit e478e35323014fae6bbfab3a97b4a3e8f0af6e6c
Author: wilderrodrigues wrodrig...@schubergphilis.com
Date: 2015-06-04T06:18:17Z
Coverity issue 1116509
- Assigning the the new returned ResultSet to the rs variable in order
to get it closed in the finally block
commit a33dc17532869045942f5f07faecec9c6365d411
Author: wilderrodrigues wrodrig...@schubergphilis.com
Date: 2015-06-04T06:30:00Z
Formatting the code
- Adding final modifier and indenting the code
commit 85181167b0211d716eeb84704f9e9085f9f40e01
Author: wilderrodrigues wrodrig...@schubergphilis.com
Date: 2015-06-04T06:38:06Z
Coverity issue 1116677
- Avoiding catching only Exception. Makes the code too britle.
- Catching the QemuImgException and throwing it to be caught further in
the code
- Surrounding the output stream with try/catch and throwing it to be
further handled in the code. Closing the output stream quietly.
commit 082d66719831c68146bcfc87558e2f31ba05ceba
Author: wilderrodrigues wrodrig...@schubergphilis.com
Date: 2015-06-04T06:45:57Z
Coverity issue 1116812
- Replacing concatenation with
optionsBuffer.append(option.getKey()).append('=').append(option.getValue()).append(',');
commit f68d02ce5e609b276c41f7940a52cdef5478a74f
Author: wilderrodrigues wrodrig...@schubergphilis.com
Date: 2015-06-04T06:47:00Z
Renaming the variable from s to script
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
On Thu, Jun 4, 2015 at 8:15 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: In VR configuration persistence (4.6) only iptables rules are persisted ? There are other configuration (interface ips, routes etc in VR will be lost on reboot) are these taken care ? By design all config is persisted but let's double check on that. @Ian: sir, can you confirm? -- Daan (being to lazy/busy to check the code)
Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
On Thu, Jun 4, 2015 at 7:45 AM, Koushik Das koushik@citrix.com wrote: What about native HA in Vmware and HyperV? Say the original host has failed, Vmware will bring up the VR on another host as part of native HA. In this case also the configuration is lost. Yes, in this case it is needed, no discussion there. (untill 4.6) -- Daan
Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
On Thu, Jun 4, 2015 at 6:39 AM, Koushik Das koushik@citrix.com wrote: The VR configurations are not persisted and so these are not present when out of band movement happens outside of CS. When a VR is recreated/rebooted from CS all the configurations are read from DB and pushed to the VR. This is not needed if it was a live migration. Only when the vm was actually recreated. -- Daan
[GitHub] cloudstack pull request: Update debian packaging
Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/339#issuecomment-108768332 there is a ticket open for that at infra On Thu, Jun 4, 2015 at 12:23 AM, Rafael da Fonseca notificati...@github.com wrote: yeah.. asfbot seems to only monitor master :) closing... â Reply to this email directly or view it on GitHub https://github.com/apache/cloudstack/pull/339#issuecomment-108631632. -- Daan --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Changing the source NAT IP
You can change the source NAT ip of the network with the API/UI. If you want to change you need to do the following. 1. Acuire another public ip P2 to the network. 2. Stop the router. 3. Edit the user_ip_address table, source_nat column of P2 to 1 and old source NAT ip to 0. 4. Restart the Router. Hope this will work. Thanks, Jayapal On 04-Jun-2015, at 2:39 PM, Schubert, Sven sven.schub...@bautzen-it.de wrote: Hi, is there a possibility to change the source NAT IP in an existing environment? Regards, Sven -- This email was Virus checked by UTM 9. http://www.sophos.com
[GitHub] cloudstack pull request: Disable enable Zone Pod Cluster Host
GitHub user pritisarap12 opened a pull request: https://github.com/apache/cloudstack/pull/356 Disable enable Zone Pod Cluster Host Updating the testcase as Admin user is also not able to deploy new VM on Host in disabled state You can merge this pull request into a Git repository by running: $ git pull https://github.com/pritisarap12/cloudstack Disable-Enable-Zone-Pod-Cluster-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/356.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #356 commit 69193d588fb5713b2d419ffe906f5f2239942f3e Author: pritisarap12 priti.sa...@clogeny.com Date: 2015-05-22T11:58:40Z CLOUDSTACK-8476-Disable enable zone pod cluster and host: --Test cases for testing the behavior of resources running on zone, cluster, pod, host and admin/non-admin user after disabling the zone, cluster, pod, host respectively commit 983945be0b65fd0bd54c42795576e859765822f3 Author: pritisarap12 priti.sa...@clogeny.com Date: 2015-05-25T05:40:30Z Disable enable zone pod cluster and host: --Adding missing strings in codes.py commit 2524d0b0edc3ae5359feacf75868a228ca02a1fa Author: pritisarap12 priti.sa...@clogeny.com Date: 2015-05-26T07:35:27Z Disable-Enable-Zone-Pod-Cluster-1: --Modified the string comparison by using lowercase string commit c5c30f6c0c24224c67c7b249f81e46ded0935d4f Author: pritisarap12 priti.sa...@clogeny.com Date: 2015-06-04T09:31:08Z Disable-Enable-Zone-Pod-Cluster: --Updating Disable/enable host testpath as admin user should not be able to deploy vm on disabled host --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Not found CS 4.5.1 RHEL packages on apt-get.eu
Hello, There are a special reason to not have the 4.5.1 RHEL packages on http://cloudstack.apt-get.eu/rhel/ ? Milamber On 11/05/2015 13:01, Rohit Yadav wrote: Hi everyone, The Apache CloudStack project is pleased to announce the 4.5.1 release of the CloudStack, the cloud orchestration platform. The 4.5.1 release contains more than 500 bug fixes since the 4.4 release and represents over six months of work from the Apache CloudStack community with new and improved features. # Documentation What's new in CloudStack 4.5: http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.5.1/about.html The 4.5.1 release notes includes full list of corrected issues as well as upgrade instructions from previous versions of Apache CloudStack. Please see the Release Notes for a full list of corrected issues and upgrade instructions: http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.5.1/ The official installation, administration and API documentation for each release are available on our Documentation Page: http://docs.cloudstack.apache.org/ # Downloads The official source code for the 4.5.1 release can be downloaded from our Downloads Page: http://cloudstack.apache.org/downloads.html # Availability and Oversight As with all Apache products, Apache CloudStack v4.5.1 is released under the Apache License v2.0, and is overseen by a self-selected team of active contributors to the project. A Project Management Committee (PMC) guides the Project's day-to-day operations, including community development and product releases. For documentation and to learn how to join and contribute to the Apache CloudStack community please visit our website: http://cloudstack.apache.org For additional marketing or communications information, please contact the marketing mailing list: market...@cloudstack.apache.org Join members of the Apache CloudStack community at the CloudStack Collaboration Conference, taking place 8-9 October 2015 in Dublin, Ireland. For more information, visit http://events.linuxfoundation.org/events/cloudstack-collaboration-conference-europe # About Apache CloudStack is open source software designed to deploy and manage large networks of virtual machines, as a highly available, highly scalable Infrastructure as a Service (IaaS) cloud computing platform. CloudStack is used by a number of service providers to offer public cloud services, and by many companies to provide an on-premises (private) cloud offering, or as part of a hybrid cloud solution. CloudStack became an Apache Top-level Project (TLP) in March 2013. Established in 1999, the all-volunteer Foundation oversees more than one hundred and seventy leading Open Source projects, including Apache HTTP Server --the world's most popular Web server software. Through the ASF's meritocratic process known as The Apache Way, more than 400 individual Members and 3,500 Committers successfully collaborate to develop freely available enterprise-grade software, benefiting millions of users worldwide: thousands of software solutions are distributed under the Apache License; and the community actively participates in ASF mailing lists, mentoring initiatives, and ApacheCon, the Foundation's official user conference, trainings, and expo. The ASF is a US 501(c)(3) charitable organization, funded by individual donations and corporate sponsors including Budget Direct, Citrix, Cloudera, Comcast, Facebook, Google, Hortonworks, HP, Huawei, IBM, InMotion Hosting, Matt Mullenweg, Microsoft, Pivotal, Produban, WANdisco, and Yahoo. For more information, visit http://www.apache.org/ or follow @TheASF on Twitter. Apache, CloudStack, Apache CloudStack, and ApacheCon are trademarks of The Apache Software Foundation. All other brands and trademarks are the property of their respective owners. -- Regards.
[GitHub] cloudstack pull request: Fix/coverity issues
Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/355 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
There was a bug in the persistent stuff that was fixed here: https://issues.apache.org/jira/browse/CLOUDSTACK-4605 User data, IP tables, guest networks and pretty much everything else will be persisted. Cheers, Wilder On 04 Jun 2015, at 09:54, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: On Thu, Jun 4, 2015 at 8:15 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.commailto:jayapalreddy.ur...@citrix.com wrote: In VR configuration persistence (4.6) only iptables rules are persisted ? There are other configuration (interface ips, routes etc in VR will be lost on reboot) are these taken care ? By design all config is persisted but let's double check on that. @Ian: sir, can you confirm? -- Daan (being to lazy/busy to check the code)
[KVM] SSVM/CPVM stay in Starting for ever
Hi all, Since day before yesterday I noticed that the SSVM/CPVM on KVM are not moving to status Running. Executing: virsh list —al Shows: IdName State 2 s-2-VM running 3 v-1-VM running With this one: vish console 2 [root@kvm1 ~]# virsh console 2 setlocale: No such file or directory Connected to domain s-2-VM Escape character is ^] Debian GNU/Linux 7 s-2-VM ttyS0 s-2-VM login: root Password: Last login: Wed Jun 3 23:35:56 UTC 2015 from 10.0.2.2 on pts/0 Linux s-2-VM 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u1 x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@s-2-VM:~# The Agent State is showing UP, as it should be. @Funs mentioned that cloud early config could have been broken by a commit, since after a rebase he is experiencing the same behaviour. Who would know something about that? I’m really stuck on this one. Thanks in advance. Cheers, Wilder
[GitHub] cloudstack pull request: Fix/coverity issues
Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/355#issuecomment-108783944 LGTM --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
To summarise: #1. rebooting VR is needed for hypervisors that have their own DR (like VMware and Hyperv) as a restart outside of CloudStack makes it lose its config hence the VR is unavailable #2. rebooting is NOT needed for successful live migrations on _any_ hypervisor (since there was no restart everything still works) #3. CloudStack 4.6 has persistent config in VR, so rebooting is never needed The current behaviour in 4.4.3, 4.5.1 and master: - always rebooting VR when out-of-band detected == Works great for #1, but makes case #2 not work The previous behaviour: - never rebooting VR when out-of-band detected == Works great for #2, but makes case #1 not work We need something that works for both cases :-) About #1 and #2: Can we detect in another way that a VR became unreachable/non-functional and do an action based on that? So, if a VR lives on a VMware hypervisor that happens to crash, VMware HA will start it on another available hypervisor but without config it will not be reachable on the control network. If we want to do it generic, I’d say that when a VR is not controllable any more we could reboot it. We could also make this a setting ‘systemvm auto reboot on control failure’ or whatever we call it. This would then also be a useful feature in 4.6 About #3: I’d suggest at least reverting the commit to master, as it makes no sense since the VR is persistent already. https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java#L2638 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=c3515c9 Regards, Remi On 04 Jun 2015, at 10:03, Wilder Rodrigues wrodrig...@schubergphilis.commailto:wrodrig...@schubergphilis.com wrote: There was a bug in the persistent stuff that was fixed here: https://issues.apache.org/jira/browse/CLOUDSTACK-4605 User data, IP tables, guest networks and pretty much everything else will be persisted. Cheers, Wilder On 04 Jun 2015, at 09:54, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: On Thu, Jun 4, 2015 at 8:15 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.commailto:jayapalreddy.ur...@citrix.commailto:jayapalreddy.ur...@citrix.com wrote: In VR configuration persistence (4.6) only iptables rules are persisted ? There are other configuration (interface ips, routes etc in VR will be lost on reboot) are these taken care ? By design all config is persisted but let's double check on that. @Ian: sir, can you confirm? -- Daan (being to lazy/busy to check the code)
Changing the source NAT IP
Hi, is there a possibility to change the source NAT IP in an existing environment? Regards, Sven -- This email was Virus checked by UTM 9. http://www.sophos.com
Build failed in Jenkins: build-master-slowbuild #1487
See http://jenkins.buildacloud.org/job/build-master-slowbuild/1487/changes Changes: [Gaurav Aradhye] CLOUDSTACK-8515: Skipping snapshots tests on HyperV and LXC hypervisors -- [...truncated 27274 lines...] [INFO] No sources to compile [INFO] [INFO] findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud [INFO] [INFO] --- findbugs-maven-plugin:3.0.0:findbugs (findbugs) @ cloud-quickcloud --- [INFO] [INFO] findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud [INFO] [INFO] --- findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud --- [INFO] [INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ cloud-quickcloud --- [WARNING] No files to instrument. [INFO] NOT adding cobertura ser file to attached artifacts list. [INFO] [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ cloud-quickcloud --- [debug] execute contextualize [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory http://jenkins.buildacloud.org/job/build-master-slowbuild/ws/quickcloud/src/test/resources [INFO] Copying 3 resources [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ cloud-quickcloud --- [INFO] No sources to compile [INFO] [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud --- [INFO] [INFO] cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-quickcloud [INFO] [INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-quickcloud --- [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache CloudStack Developer Tools - Checkstyle Configuration SUCCESS [1.708s] [INFO] Apache CloudStack . SUCCESS [1.987s] [INFO] Apache CloudStack Maven Conventions Parent SUCCESS [0.797s] [INFO] Apache CloudStack Framework - Managed Context . SUCCESS [21.404s] [INFO] Apache CloudStack Utils ... SUCCESS [1:22.482s] [INFO] Apache CloudStack Framework ... SUCCESS [0.103s] [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [50.769s] [INFO] Apache CloudStack Framework - Configuration ... SUCCESS [28.665s] [INFO] Apache CloudStack API . SUCCESS [1:47.008s] [INFO] Apache CloudStack Framework - REST SUCCESS [18.649s] [INFO] Apache CloudStack Framework - IPC . SUCCESS [31.183s] [INFO] Apache CloudStack Cloud Engine SUCCESS [0.096s] [INFO] Apache CloudStack Cloud Engine API SUCCESS [28.821s] [INFO] Apache CloudStack Framework - Security SUCCESS [25.211s] [INFO] Apache CloudStack Core SUCCESS [1:15.462s] [INFO] Apache CloudStack Agents .. SUCCESS [36.021s] [INFO] Apache CloudStack Framework - Clustering .. SUCCESS [31.875s] [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [15.995s] [INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:00.922s] [INFO] Apache CloudStack Framework - Jobs SUCCESS [39.714s] [INFO] Apache CloudStack Cloud Engine Internal Components API SUCCESS [35.227s] [INFO] Apache CloudStack Server .. SUCCESS [4:09.465s] [INFO] Apache CloudStack Usage Server SUCCESS [51.896s] [INFO] Apache CloudStack Cloud Engine Orchestration Component SUCCESS [1:20.823s] [INFO] Apache CloudStack Cloud Services .. SUCCESS [0.065s] [INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.418s] [INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [55.927s] [INFO] Apache CloudStack Engine Storage Component SUCCESS [1:00.567s] [INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [35.859s] [INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [28.961s] [INFO] Apache CloudStack Engine Storage Data Motion Component SUCCESS [24.130s] [INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [20.862s] [INFO] Apache CloudStack Engine Storage Snapshot Component SUCCESS [38.362s] [INFO] Apache CloudStack Cloud Engine API SUCCESS [13.443s] [INFO] Apache CloudStack Cloud Engine Service SUCCESS [6.265s] [INFO] Apache CloudStack Plugin POM .. SUCCESS [0.880s] [INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [29.529s] [INFO] Apache CloudStack Plugin - Storage Volume default provider SUCCESS [3:10.212s] [INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider SUCCESS [2:15.298s] [INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [22.832s] [INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [39.629s] [INFO] Apache CloudStack Plugin -
[GitHub] cloudstack pull request: Fix/coverity issues
Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/355#issuecomment-108786172 Did not delete because I saw other attributes which were only commented out. Left it there in case someone will need to find it in the future. Anyway, that's just a Test.java class. I will apply the try-with resource thing and get it into the PR. Thanks for the review. :) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
The idea is to resist everything. If stuff does not persist then it can be viewed as a bug ;). — Ian On 04 Jun 2015, at 09:54, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: By design all config is persisted but let's double check on that. @Ian: sir, can you confirm?
RE: Changing the source NAT IP
Thx, I will try. From: Jayapal Reddy Uradi [jayapalreddy.ur...@citrix.com] Sent: Thursday, June 04, 2015 11:22 To: dev@cloudstack.apache.org Subject: Re: Changing the source NAT IP You can change the source NAT ip of the network with the API/UI. If you want to change you need to do the following. 1. Acuire another public ip P2 to the network. 2. Stop the router. 3. Edit the user_ip_address table, source_nat column of P2 to 1 and old source NAT ip to 0. 4. Restart the Router. Hope this will work. Thanks, Jayapal On 04-Jun-2015, at 2:39 PM, Schubert, Sven sven.schub...@bautzen-it.de wrote: Hi, is there a possibility to change the source NAT IP in an existing environment? Regards, Sven -- This email was Virus checked by UTM 9. http://www.sophos.com -- This email was Virus checked by UTM 9. http://www.sophos.com
Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
resist should be persist. Do not answer mails on iphones ;) On 04 Jun 2015, at 11:31, Ian Southam isout...@schubergphilis.com wrote: The idea is to resist everything. If stuff does not persist then it can be viewed as a bug ;). — Ian On 04 Jun 2015, at 09:54, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: By design all config is persisted but let's double check on that. @Ian: sir, can you confirm?
RE: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
Ian, With the persistent config change, the VR has become 'stateful'. Is there a possibility for VR config and DB config to go out of sync? If so how is the config in the VR and DB kept in sync? -Original Message- From: Ian Southam [mailto:isout...@schubergphilis.com] Sent: Thursday, 4 June 2015 15:41 To: dev@cloudstack.apache.org Cc: Daan Hoogland Subject: Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not? resist should be persist. Do not answer mails on iphones ;) On 04 Jun 2015, at 11:31, Ian Southam isout...@schubergphilis.com wrote: The idea is to resist everything. If stuff does not persist then it can be viewed as a bug ;). — Ian On 04 Jun 2015, at 09:54, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: By design all config is persisted but let's double check on that. @Ian: sir, can you confirm?
[DISCUSS] new findbugs bug findings
LS, We have been improving a lot in terms checking submissions and having better (as in less) overall mastaer breakage lately. We are not there yet. At the moment findbugs has 51 new findings and fails the slowbuild for that reason. I think a lot of those can be prevented. For the rest we can attribute them to people/commits. Call it blaming but I know I am guilty at times and some far better developers then me, as well. We are not running the slow build on every commit (it is called slow for a reason) and a lot of people are ignoring the output from it because it almost always fails. I fixed it in Austin and it now has 51 new findings (when I last looked). 1. One way to handle this is to publish the attribution on this list. 2. Another way is to have a pull request builder do the slow build on every commit 3. The old proposal was to do the slow build at regular intervals and revert everything in a failed build. I was one of the people rejecting it but I put it here to be as complete as possible. 1 is very intensive work but very easily implemented 2 is not much implementation work but requires even more discipline of committers in their review work. I feel for both equally strong either way but I think we should make the next step soon. thoughts? -- Daan
[GitHub] cloudstack pull request: Reinstate working sessions in browser
Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/308#issuecomment-108844572 This merges cleanly, should we wait on extra fixes? or have them done in separate PRs? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Build failed in Jenkins: simulator-singlerun #1213
See http://jenkins.buildacloud.org/job/simulator-singlerun/1213/ -- Started by upstream project build-master-simulator build number 2031 originally caused by: Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by upstream project build-master build number 2361 originally caused by: Started by an SCM change Started by an SCM change Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on simulator in workspace http://jenkins.buildacloud.org/job/simulator-singlerun/ws/ /usr/bin/git rev-parse --is-inside-work-tree # timeout=400 Fetching changes from the remote Git repository /usr/bin/git config remote.origin.url https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=400 Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/cloudstack.git /usr/bin/git --version # timeout=400 /usr/bin/git fetch --tags --progress https://git-wip-us.apache.org/repos/asf/cloudstack.git +refs/heads/*:refs/remotes/origin/* ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from https://git-wip-us.apache.org/repos/asf/cloudstack.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:735) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:983) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1016) at hudson.scm.SCM.checkout(SCM.java:484) at hudson.model.AbstractProject.checkout(AbstractProject.java:1258) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528) at hudson.model.Run.execute(Run.java:1759) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Caused by: hudson.plugins.git.GitException: Command /usr/bin/git fetch --tags --progress https://git-wip-us.apache.org/repos/asf/cloudstack.git +refs/heads/*:refs/remotes/origin/* returned status code 128: stdout: stderr: error: while accessing https://git-wip-us.apache.org/repos/asf/cloudstack.git/info/refs fatal: HTTP request failed at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1591) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1379) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:86) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:324) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) at ..remote call to simulator(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:752) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145) at sun.reflect.GeneratedMethodAccessor375.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131) at sun.proxy.$Proxy46.execute(Unknown Source) at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:733) ... 11 more ERROR: Error fetching remote repo 'origin' [xUnit] [INFO] - Starting to record. [xUnit] [INFO] - Processing JUnit [xUnit] [INFO] - [JUnit] - 1 test report file(s) were found with the pattern 'xunit.xml' relative to 'http://jenkins.buildacloud.org/job/simulator-singlerun/ws/' for the testing framework 'JUnit'. [xUnit] [ERROR] - Test reports were found but not all of them are new. Did all the tests run? *
Build failed in Jenkins: build-master-slowbuild #1488
See http://jenkins.buildacloud.org/job/build-master-slowbuild/1488/ -- [...truncated 27274 lines...] [INFO] No sources to compile [INFO] [INFO] findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud [INFO] [INFO] --- findbugs-maven-plugin:3.0.0:findbugs (findbugs) @ cloud-quickcloud --- [INFO] [INFO] findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud [INFO] [INFO] --- findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud --- [INFO] [INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ cloud-quickcloud --- [WARNING] No files to instrument. [INFO] NOT adding cobertura ser file to attached artifacts list. [INFO] [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ cloud-quickcloud --- [debug] execute contextualize [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory http://jenkins.buildacloud.org/job/build-master-slowbuild/ws/quickcloud/src/test/resources [INFO] Copying 3 resources [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ cloud-quickcloud --- [INFO] No sources to compile [INFO] [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud --- [INFO] [INFO] cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-quickcloud [INFO] [INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-quickcloud --- [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache CloudStack Developer Tools - Checkstyle Configuration SUCCESS [1.812s] [INFO] Apache CloudStack . SUCCESS [2.822s] [INFO] Apache CloudStack Maven Conventions Parent SUCCESS [1.122s] [INFO] Apache CloudStack Framework - Managed Context . SUCCESS [21.934s] [INFO] Apache CloudStack Utils ... SUCCESS [1:42.955s] [INFO] Apache CloudStack Framework ... SUCCESS [0.102s] [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [51.265s] [INFO] Apache CloudStack Framework - Configuration ... SUCCESS [28.364s] [INFO] Apache CloudStack API . SUCCESS [1:46.461s] [INFO] Apache CloudStack Framework - REST SUCCESS [17.400s] [INFO] Apache CloudStack Framework - IPC . SUCCESS [31.069s] [INFO] Apache CloudStack Cloud Engine SUCCESS [0.097s] [INFO] Apache CloudStack Cloud Engine API SUCCESS [30.295s] [INFO] Apache CloudStack Framework - Security SUCCESS [25.871s] [INFO] Apache CloudStack Core SUCCESS [1:17.098s] [INFO] Apache CloudStack Agents .. SUCCESS [36.685s] [INFO] Apache CloudStack Framework - Clustering .. SUCCESS [31.632s] [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [15.852s] [INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:05.894s] [INFO] Apache CloudStack Framework - Jobs SUCCESS [48.397s] [INFO] Apache CloudStack Cloud Engine Internal Components API SUCCESS [30.615s] [INFO] Apache CloudStack Server .. SUCCESS [4:16.299s] [INFO] Apache CloudStack Usage Server SUCCESS [48.590s] [INFO] Apache CloudStack Cloud Engine Orchestration Component SUCCESS [1:25.279s] [INFO] Apache CloudStack Cloud Services .. SUCCESS [0.069s] [INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.446s] [INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [1:05.475s] [INFO] Apache CloudStack Engine Storage Component SUCCESS [52.402s] [INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [33.411s] [INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [28.394s] [INFO] Apache CloudStack Engine Storage Data Motion Component SUCCESS [32.229s] [INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [19.673s] [INFO] Apache CloudStack Engine Storage Snapshot Component SUCCESS [38.333s] [INFO] Apache CloudStack Cloud Engine API SUCCESS [53.415s] [INFO] Apache CloudStack Cloud Engine Service SUCCESS [53.862s] [INFO] Apache CloudStack Plugin POM .. SUCCESS [7.056s] [INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [2:54.351s] [INFO] Apache CloudStack Plugin - Storage Volume default provider SUCCESS [41.444s] [INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider SUCCESS [59.052s] [INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [31.271s] [INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [53.553s] [INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [21.820s] [INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor
Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
On Thu, Jun 4, 2015 at 1:27 PM, Koushik Das koushik@citrix.com wrote: Is there a possibility for VR config and DB config to go out of sync? If so how is the config in the VR and DB kept in sync? Koushik, the db is leading and conversion is applied to the state of the router. On differences, newly sent config takes precedence. -- Daan
Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
Hi, On 04-Jun-2015, at 11:05 am, Remi Bergsma rberg...@schubergphilis.com wrote: To summarise: #1. rebooting VR is needed for hypervisors that have their own DR (like VMware and Hyperv) as a restart outside of CloudStack makes it lose its config hence the VR is unavailable #2. rebooting is NOT needed for successful live migrations on _any_ hypervisor (since there was no restart everything still works) #3. CloudStack 4.6 has persistent config in VR, so rebooting is never needed The current behaviour in 4.4.3, 4.5.1 and master: - always rebooting VR when out-of-band detected == Works great for #1, but makes case #2 not work The previous behaviour: - never rebooting VR when out-of-band detected == Works great for #2, but makes case #1 not work We need something that works for both cases :-) About #1 and #2: Can we detect in another way that a VR became unreachable/non-functional and do an action based on that? So, if a VR lives on a VMware hypervisor that happens to crash, VMware HA will start it on another available hypervisor but without config it will not be reachable on the control network. If we want to do it generic, I’d say that when a VR is not controllable any more we could reboot it. We could also make this a setting ‘systemvm auto reboot on control failure’ or whatever we call it. This would then also be a useful feature in 4.6 About #3: I’d suggest at least reverting the commit to master, as it makes no sense since the VR is persistent already. https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java#L2638 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=c3515c9 I agree on master, we can revert due to #3. On 4.4 and 4.5 branches, if we revert it than it will break #1 and if we keep it - it breaks #2. We need to fix this in a hypervisor agnostic way. So, if we can use aggregated cmd execution that Sudhashu and others have shared, in case of an out of band migration we can do this: 1. If we’re unable to reach VR, we can keep the RebootTask to do its job. In many cases I’ve seen VR disk corruption, so if after rebooting VR (which might kick in fsck) it fails CloudStack may eventually recreate a new VR makes sense. This will solve #1. This case IMO is highly unlikely. 2. If we’re able to reach the VR after VR is migrated out of band, we run an AgrregationExecutionTask sending all the rules for that VR. This will solve #2 without needing to reboot a VM. This case is more likely to happen, so if I’ve pick between this and the above case, I would try to solve for this case. I’m not sure about the actual implementation, and will re-applying rules using a AgrregationExecutionTask cause any issue in the VR? Comments? Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Build failed in Jenkins: build-master-slowbuild #1491
See http://jenkins.buildacloud.org/job/build-master-slowbuild/1491/ -- [...truncated 27274 lines...] [INFO] No sources to compile [INFO] [INFO] findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud [INFO] [INFO] --- findbugs-maven-plugin:3.0.0:findbugs (findbugs) @ cloud-quickcloud --- [INFO] [INFO] findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud [INFO] [INFO] --- findbugs-maven-plugin:3.0.0:check (cloudstack-findbugs) @ cloud-quickcloud --- [INFO] [INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ cloud-quickcloud --- [WARNING] No files to instrument. [INFO] NOT adding cobertura ser file to attached artifacts list. [INFO] [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ cloud-quickcloud --- [debug] execute contextualize [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory http://jenkins.buildacloud.org/job/build-master-slowbuild/ws/quickcloud/src/test/resources [INFO] Copying 3 resources [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ cloud-quickcloud --- [INFO] No sources to compile [INFO] [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud --- [INFO] [INFO] cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-quickcloud [INFO] [INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-quickcloud --- [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache CloudStack Developer Tools - Checkstyle Configuration SUCCESS [1.890s] [INFO] Apache CloudStack . SUCCESS [2.045s] [INFO] Apache CloudStack Maven Conventions Parent SUCCESS [0.789s] [INFO] Apache CloudStack Framework - Managed Context . SUCCESS [22.217s] [INFO] Apache CloudStack Utils ... SUCCESS [1:27.967s] [INFO] Apache CloudStack Framework ... SUCCESS [0.132s] [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [50.916s] [INFO] Apache CloudStack Framework - Configuration ... SUCCESS [28.602s] [INFO] Apache CloudStack API . SUCCESS [1:57.445s] [INFO] Apache CloudStack Framework - REST SUCCESS [18.075s] [INFO] Apache CloudStack Framework - IPC . SUCCESS [31.022s] [INFO] Apache CloudStack Cloud Engine SUCCESS [0.085s] [INFO] Apache CloudStack Cloud Engine API SUCCESS [30.230s] [INFO] Apache CloudStack Framework - Security SUCCESS [25.797s] [INFO] Apache CloudStack Core SUCCESS [1:17.416s] [INFO] Apache CloudStack Agents .. SUCCESS [36.603s] [INFO] Apache CloudStack Framework - Clustering .. SUCCESS [31.303s] [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.692s] [INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:05.532s] [INFO] Apache CloudStack Framework - Jobs SUCCESS [50.682s] [INFO] Apache CloudStack Cloud Engine Internal Components API SUCCESS [30.004s] [INFO] Apache CloudStack Server .. SUCCESS [4:19.790s] [INFO] Apache CloudStack Usage Server SUCCESS [49.588s] [INFO] Apache CloudStack Cloud Engine Orchestration Component SUCCESS [1:25.323s] [INFO] Apache CloudStack Cloud Services .. SUCCESS [0.077s] [INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.460s] [INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [1:05.545s] [INFO] Apache CloudStack Engine Storage Component SUCCESS [49.946s] [INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [34.902s] [INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [29.052s] [INFO] Apache CloudStack Engine Storage Data Motion Component SUCCESS [33.307s] [INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [20.188s] [INFO] Apache CloudStack Engine Storage Snapshot Component SUCCESS [38.638s] [INFO] Apache CloudStack Cloud Engine API SUCCESS [1:12.478s] [INFO] Apache CloudStack Cloud Engine Service SUCCESS [52.736s] [INFO] Apache CloudStack Plugin POM .. SUCCESS [6.604s] [INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [2:43.671s] [INFO] Apache CloudStack Plugin - Storage Volume default provider SUCCESS [34.160s] [INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider SUCCESS [47.206s] [INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [34.372s] [INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [49.670s] [INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [25.202s] [INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor
[GitHub] cloudstack pull request: This branch implements the CSV and native...
Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/351#issuecomment-109032779 Hi @anshul1886, Thanks for the PR :-) Looks like quite some work! I don't have a Hyper-V setup to test it.. Will ask around and see who can help test it. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
Hi On 04.06.2015 14:29, Rohit Yadav wrote: Hi, On 04-Jun-2015, at 11:05 am, Remi Bergsma rberg...@schubergphilis.com wrote: To summarise: #1. rebooting VR is needed for hypervisors that have their own DR (like VMware and Hyperv) as a restart outside of CloudStack makes it lose its config hence the VR is unavailable #2. rebooting is NOT needed for successful live migrations on _any_ hypervisor (since there was no restart everything still works) #3. CloudStack 4.6 has persistent config in VR, so rebooting is never needed On 4.4 and 4.5 branches, if we revert it than it will break #1 and if we keep it - it breaks #2. We need to fix this in a hypervisor agnostic way. #1 is something we are already aware of. So I vote for a revert. We can currently live with it, because 1. Live Migration in VMware hardly fails for such a small VM without much I/O and such low amount of RAM. 2. We are monitoring the router reboots (uptime) and cloudstack restart router manually if this happens. Just a silly question: why not implementing a detected OS out of bound reboot looking for the if uptime last_uptime ? restartRouter on the router in 4.4 and 4.5?
[GitHub] cloudstack pull request: Disable enable Zone Pod Cluster Host
Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/356#issuecomment-108898254 @pritisarap12 is this intended to go on master? it doesn't apply and as it is pretty new it probably isn't. If it is intended for master please rebase and resubmit. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
