Re: Unable to deploy systemvms
Hi Dion,
Thanks for the clue,I was missing 'cloud traffic label' there.
One step ahead Now SSVM and CPVM is UP running. I am able to ping both
private ip but not Public ip from Management server and link local is also
pinging from hypervisor . I tried SSVM health check. every thing fine.
secstorage.allowed.internal.sites = Management server ip.
2014-04-03 11:15:55,280 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-7:null) SeqA 2-5: Processing Seq 2-5: { Cmd ,
MgmtId: -1, via: 2, Ver: v1, Flags: 11,
[{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n
\connections\: []\n},wait:0}}] }
2014-04-03 11:15:55,288 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-7:null) SeqA 2-5: Sending Seq 2-5: { Ans: , MgmtId:
345049296663, via: 2, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2014-04-03 11:15:55,996 DEBUG [o.a.c.s.RemoteHostEndPoint]
(Timer-11:ctx-67fcb05a) Sending command
org.apache.cloudstack.storage.command.DownloadProgressCommand to host: 3
2014-04-03 11:15:55,998 DEBUG [c.c.a.t.Request] (Timer-11:ctx-67fcb05a) Seq
3-140181514: Sending { Cmd , MgmtId: 345049296663, via: 3(s-1-VM), Ver:
v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.DownloadProgressCommand:{jobId:c9ad6108-ddcd-44a1-8e62-9d7ab76e4834,request:GET_STATUS,hvm:false,description:CentOS
5.6(64-bit) no GUI
(XenServer),checksum:905cec879afd9c9d22ecc8036131a180,maxDownloadSizeInBytes:53687091200,id:5,resourceType:TEMPLATE,installPath:template/tmpl/1/5,_store:{com.cloud.agent.api.to.NfsTO:{_url:nfs://
10.129.151.60/vol/secondary,_role:Image}},url:
http://download.cloud.com/templates/builtin/centos56-x86_64.vhd.bz2
,format:VHD,accountId:1,name:centos56-x86_64-xen,secUrl:nfs://
10.129.151.60/vol/secondary,wait:0}}] }
2014-04-03 11:15:55,999 DEBUG [o.a.c.s.RemoteHostEndPoint]
(Timer-10:ctx-7539f2bf) Sending command
org.apache.cloudstack.storage.command.DownloadProgressCommand to host: 3
2014-04-03 11:15:56,001 DEBUG [c.c.a.t.Request] (Timer-10:ctx-7539f2bf) Seq
3-140181515: Sending { Cmd , MgmtId: 345049296663, via: 3(s-1-VM), Ver:
v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.DownloadProgressCommand:{jobId:8c3263f0-b796-4f28-a965-6f2ef421f815,request:GET_STATUS,hvm:false,description:CentOS
5.3(64-bit) no GUI
(XenServer),checksum:b63d854a9560c013142567bbae8d98cf,maxDownloadSizeInBytes:53687091200,id:2,resourceType:TEMPLATE,installPath:template/tmpl/1/2,_store:{com.cloud.agent.api.to.NfsTO:{_url:nfs://
10.129.151.60/vol/secondary,_role:Image}},url:
http://download.cloud.com/templates/builtin/f59f18fb-ae94-4f97-afd2-f84755767aca.vhd.bz2
,format:VHD,accountId:1,name:centos53-x86_64,secUrl:nfs://
10.129.151.60/vol/secondary,wait:0}}] }
2014-04-03 11:15:56,021 DEBUG [c.c.a.t.Request]
(AgentManager-Handler-9:null) Seq 3-140181515: Processing: { Ans: ,
MgmtId: 345049296663, via: 3, Ver: v1, Flags: 10,
[{com.cloud.agent.api.storage.DownloadAnswer:{jobId:8c3263f0-b796-4f28-a965-6f2ef421f815,*downloadPct:0,errorString:No
route to
host,downloadStatus:DOWNLOAD_ERROR,downloadPath:/mnt/SecStorage/083f43be-897d-3f0d-b65e-54e1462fa59a/template/tmpl/1/2/dnld4937216608487758375tmp_,installPath:template/tmpl/1/2,templateSize:0,templatePhySicalSize:0,checkSum:b63d854a9560c013142567bbae8d98cf,result:true,details:No
route to host,wait:0}}] }*
2014-04-03 11:15:56,021 DEBUG [c.c.a.t.Request]
(AgentManager-Handler-8:null) Seq 3-140181514: Processing: { Ans: ,
MgmtId: 345049296663, via: 3, Ver: v1, Flags: 10,
[{com.cloud.agent.api.storage.DownloadAnswer:{jobId:c9ad6108-ddcd-44a1-8e62-9d7ab76e4834,downloadPct:0,errorString:No
route to
host,*downloadStatus:DOWNLOAD_ERROR,*downloadPath:/mnt/SecStorage/083f43be-897d-3f0d-b65e-54e1462fa59a/template/tmpl/1/5/dnld2277393467913145419tmp_,installPath:template/tmpl/1/5,templateSize:0,templatePhySicalSize:0,checkSum:905cec879afd9c9d22ecc8036131a180,result:true,details:No
route to host,wait:0}}] }
Regards,
Tejas
On Wed, Apr 2, 2014 at 7:24 PM, Pierre-Luc Dion pd...@cloudops.com wrote:
Tejas,
Did you add the network label names in Cloudstack ? You need to specify
the network label name in Cloudstack that are configured in XenServer. I'm
suspecting that the current issue is that CloudStack cannot map the Storage
Network from is config in XenServer so xenserver cannot reach the secondary
storage.
I've add an attachment on where to look at in Cloudstack. If you have
access to XenCenter you have to use name of networks under networking tab
on the XenServer host.
you can refer to:
http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/latest/hypervisor_installation.html#citrix-xenserver-installation-for-cloudstack
Regards,
Pierre-Luc Dion
Architecte de Solution Cloud | Cloud Solutions Architect
514-447-3456, 1101
- - -
*CloudOps*420 rue Guy
Montréal QC H3J 1S6
www.cloudops.com
@CloudOps_
On Wed, Apr 2, 2014 at 8:54 AM, Tejas Gadaria refond.g...@gmail.comwrote:
Hi Yitao,
[REMINDER]Review Request 19584: CLOUDSTACK-6258: Disable systemvm cloud startup script from logging messages to /var/log/cloud/cloud.out
Hi Rajesh, Any thoughts/suggestions on the changes? Thanks Saurav On Mon, Mar 24, 2014 at 8:30 PM, Saurav Lahiri saurav.lah...@sungard.comwrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19584/ --- Review request for cloudstack. Repository: cloudstack-git Description --- This will prevent the /etc/init.d/cloud script from logging messages to /var/log/cloud/cloud.out if the CLOUD_DEBUG flag is not defined. If the flag is defined only then will messages be logged. This is because the cloud.out file gets rolled over once max size is reached via the log4j settings, since the script is not aware of the log4j settings it causes the log file to exceed its max size and fill up the file system. Diffs - systemvm/patches/debian/config/etc/init.d/cloud 83853bc Diff: https://reviews.apache.org/r/19584/diff/ Testing --- The console proxy vm was started and console sessions tested. The secondary storage vm was succesfully started. Thanks, Saurav Lahiri
[PROPOSAL] LDAP Authorisation and multiple LDAP server support
Currently, ACS only does authentication on LDAP server. The user roles have to be configured manually in cloudstack. Also, we don’t support multiple LDAP servers. I am planning to work on adding LDAP authorisation and multiple LDAP server support to CloudStack The proposal is @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/LDAP+user+Authorization Let me know your comments/suggestions ~Rajani
Re: ALARM - ACS reboots host servers!!!
I'm also interested in this issue. Can any1 from developers confirm this is expected behavior? On 2/4/14 2:32 PM, Andrei Mikhailovsky wrote: Coming back to this issue. This time to perform the maintenance of the nfs primary storage I've plated the storage in question in the Maintenance mode. After about 20 minutes ACS showed the nfs storage is in Maintenance. However, none of the virtual machines with volumes on that storage were stopped. I've manually stopped the virtual machines and went to upgrade and restart the nfs server. A few minutes after the nfs server shutdown all of my host servers went into reboot killing all vms! Thus, it seems that putting nfs server in Maintenance mode does not stop ACS agent from restarting the host servers. Does anyone know a way to stop this behaviour? Thanks Andrei - Original Message - From: France mailingli...@isg.si To: us...@cloudstack.apache.org Cc: dev@cloudstack.apache.org Sent: Monday, 3 March, 2014 9:49:28 AM Subject: Re: ALARM - ACS reboots host servers!!! I believe this is a bug too, because VMs not running on the storage, get destroyed too: Issue has been around for a long time, like with all others I reported. They do not get fixed: https://issues.apache.org/jira/browse/CLOUDSTACK-3367 We even lost assignee today. Regards, F. On 3/3/14 6:55 AM, Koushik Das wrote: The primary storage needs to be put in maintenance before doing any upgrade/reboot as mentioned in the previous mails. -Koushik On 03-Mar-2014, at 6:07 AM, Marcus shadow...@gmail.com wrote: Also, please note that in the bug you referenced it doesn't have a problem with the reboot being triggered, but with the fact that reboot never completes due to hanging NFS mount (which is why the reboot occurs, inaccessible primary storage). On Sun, Mar 2, 2014 at 5:26 PM, Marcus shadow...@gmail.com wrote: Or do you mean you have multiple primary storages and this one was not in use and put into maintenance? On Sun, Mar 2, 2014 at 5:25 PM, Marcus shadow...@gmail.com wrote: I'm not sure I understand. How do you expect to reboot your primary storage while vms are running? It sounds like the host is being fenced since it cannot contact the resources it depends on. On Sun, Mar 2, 2014 at 3:24 PM, Nux! n...@li.nux.ro wrote: On 02.03.2014 21:17, Andrei Mikhailovsky wrote: Hello guys, I've recently came across the bug CLOUDSTACK-5429 which has rebooted all of my host servers without properly shutting down the guest vms. I've simply upgraded and rebooted one of the nfs primary storage servers and a few minutes later, to my horror, i've found out that all of my host servers have been rebooted. Is it just me thinking so, or is this bug should be fixed ASAP and should be a blocker for any new ACS release. I mean not only does it cause downtime, but also possible data loss and server corruption. Hi Andrei, Do you have HA enabled and did you put that primary storage in maintenance mode before rebooting it? It's my understanding that ACS relies on the shared storage to perform HA so if the storage goes it's expected to go berserk. I've noticed similar behaviour in Xenserver pools without ACS. I'd imagine a cure for this would be to use network distributed filesystems like GlusterFS or CEPH. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
VM_HVM_REQUIRED - installing from ISO's
I'm trying to install from a Ubuntu 12.05 ISO [1] to Cloudstack 4.3
[2] running with a non HVM host running on a variant of devcloud.
I've applied this fix [3]:
INSERT INTO `cloud`.`configuration` (`category`, `instance`,
`component`, `name`,
`value`, `description`) VALUES ('Advanced', 'DEFAULT', 'management-server',
'xen.check.hvm', 'false', 'Shoud we allow only the XenServers support HVM');
But I see the following error in the log:
WARN [c.c.h.x.r.CitrixResourceBase] (DirectAgent-235:ctx-1aaf2309)
Unable to start i-2-15-VM due to
com.cloud.utils.exception.CloudRuntimeException: Unable to start
VM(i-2-15-VM) on host(c47d712e-8aa8-fcd6-113e-8546532e5fcc) due to
Task failed! Task record: uuid:
1b5a9bda-facb-e6e9-3e81-aa8168fe63cb
nameLabel: Async.VM.start_on
nameDescription:
allowedOperations: []
currentOperations: {}
created: Thu Apr 03 06:54:00 UTC 2014
finished: Thu Apr 03 06:54:01 UTC 2014
status: failure
residentOn: com.xensource.xenapi.Host@676529fc
progress: 1.0
type: none/
result:
errorInfo: [VM_HVM_REQUIRED,
OpaqueRef:e917ac0d-f620-231e-7d0b-4d0e68776eef]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
I'm currently looking through the ocaml code, and trying to trace the
calls with wireshark, but nothing is jumping out at me.
Any pointers will be appreciated.
Many thanks,
Chris
---
[1] http://releases.ubuntu.com/12.04/ubuntu-12.04.4-server-i386.iso
[2]
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=24dcf2948c2d4cdd98fcda0f766d82f40eee8be1
[3] http://support.citrix.com/article/CTX132015
Re: ALARM - ACS reboots host servers!!!
On 04/03/2014 10:06 AM, France wrote: I'm also interested in this issue. Can any1 from developers confirm this is expected behavior? Yes, this still happens due to the kvmheartbeat.sh script which runs. On some clusters I disabled this by simply overwriting that script with a version where reboot is removed. I have some ideas on how to fix this, but I don't have the time at the moment. Short version: The hosts shouldn't reboot themselves as long as they can reach other nodes or it should at least be configurable. The management server should also do further inspection during HA by using a helper on the KVM Agent. Wido On 2/4/14 2:32 PM, Andrei Mikhailovsky wrote: Coming back to this issue. This time to perform the maintenance of the nfs primary storage I've plated the storage in question in the Maintenance mode. After about 20 minutes ACS showed the nfs storage is in Maintenance. However, none of the virtual machines with volumes on that storage were stopped. I've manually stopped the virtual machines and went to upgrade and restart the nfs server. A few minutes after the nfs server shutdown all of my host servers went into reboot killing all vms! Thus, it seems that putting nfs server in Maintenance mode does not stop ACS agent from restarting the host servers. Does anyone know a way to stop this behaviour? Thanks Andrei - Original Message - From: France mailingli...@isg.si To: us...@cloudstack.apache.org Cc: dev@cloudstack.apache.org Sent: Monday, 3 March, 2014 9:49:28 AM Subject: Re: ALARM - ACS reboots host servers!!! I believe this is a bug too, because VMs not running on the storage, get destroyed too: Issue has been around for a long time, like with all others I reported. They do not get fixed: https://issues.apache.org/jira/browse/CLOUDSTACK-3367 We even lost assignee today. Regards, F. On 3/3/14 6:55 AM, Koushik Das wrote: The primary storage needs to be put in maintenance before doing any upgrade/reboot as mentioned in the previous mails. -Koushik On 03-Mar-2014, at 6:07 AM, Marcus shadow...@gmail.com wrote: Also, please note that in the bug you referenced it doesn't have a problem with the reboot being triggered, but with the fact that reboot never completes due to hanging NFS mount (which is why the reboot occurs, inaccessible primary storage). On Sun, Mar 2, 2014 at 5:26 PM, Marcus shadow...@gmail.com wrote: Or do you mean you have multiple primary storages and this one was not in use and put into maintenance? On Sun, Mar 2, 2014 at 5:25 PM, Marcus shadow...@gmail.com wrote: I'm not sure I understand. How do you expect to reboot your primary storage while vms are running? It sounds like the host is being fenced since it cannot contact the resources it depends on. On Sun, Mar 2, 2014 at 3:24 PM, Nux! n...@li.nux.ro wrote: On 02.03.2014 21:17, Andrei Mikhailovsky wrote: Hello guys, I've recently came across the bug CLOUDSTACK-5429 which has rebooted all of my host servers without properly shutting down the guest vms. I've simply upgraded and rebooted one of the nfs primary storage servers and a few minutes later, to my horror, i've found out that all of my host servers have been rebooted. Is it just me thinking so, or is this bug should be fixed ASAP and should be a blocker for any new ACS release. I mean not only does it cause downtime, but also possible data loss and server corruption. Hi Andrei, Do you have HA enabled and did you put that primary storage in maintenance mode before rebooting it? It's my understanding that ACS relies on the shared storage to perform HA so if the storage goes it's expected to go berserk. I've noticed similar behaviour in Xenserver pools without ACS. I'd imagine a cure for this would be to use network distributed filesystems like GlusterFS or CEPH. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Review Request 19913: CLOUDSTACK-6326 : Fixed password visible in plain text in some of commands in Hyper-v Agent logs
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19913/ --- Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6326 https://issues.apache.org/jira/browse/CLOUDSTACK-6326 Repository: cloudstack-git Description --- Fixed password visible in plain text in some of commands in Hyper-v Agent logs Diffs - plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/HypervResourceController.cs 66b9828 plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/Utils.cs 6ebc5bf Diff: https://reviews.apache.org/r/19913/diff/ Testing --- verified by seeing the logs for some commands Thanks, Anshul Gangwar
Re: Validating check-ins for your local changes, using Simulator
Thanks for updating the wiki Santhosh. Also for any new feature adding agent commands, the simulator needs to be fixed as well. The integration tests added for new features should be run against simulator as well to ensure it is not broken. -Koushik On 03-Apr-2014, at 2:16 AM, Santhosh Edukulla santhosh.eduku...@citrix.com wrote: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator Thanks! Santhosh
Re: Review Request 19916: Updated listLoadBalancerRuleInstances, removeFromLoadBalancerRule APIs for VM secondary ip addresses
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19916/#review39409 --- Ship it! Ship It! - Murali Reddy On April 2, 2014, 1:06 p.m., Jayapal Reddy wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19916/ --- (Updated April 2, 2014, 1:06 p.m.) Review request for cloudstack, Abhinandan Prateek, Chiradeep Vittal, and Murali Reddy. Bugs: CLOUDSTACK-6327 https://issues.apache.org/jira/browse/CLOUDSTACK-6327 Repository: cloudstack-git Description --- Configuring load balancing rules for VM secondary ip address feature is in 4.4. In this patch updated 'listLoadBalancerRuleInstances' API response to display the VM ip address. Also updated the removeFromLoadBalancerRule to remove the specific vm and ip entry which assigned to LB rule. Diffs - api/src/com/cloud/network/lb/LoadBalancingRulesService.java 6643de6 api/src/org/apache/cloudstack/api/ApiConstants.java 1146cea api/src/org/apache/cloudstack/api/command/admin/loadbalancer/ListLoadBalancerRuleInstancesCmdByAdmin.java 26202b9 api/src/org/apache/cloudstack/api/command/user/loadbalancer/ListLoadBalancerRuleInstancesCmd.java 2d458a7 api/src/org/apache/cloudstack/api/command/user/loadbalancer/RemoveFromLoadBalancerRuleCmd.java 8714d34 api/src/org/apache/cloudstack/api/response/LoadBalancerRuleVmMapResponse.java PRE-CREATION engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapDao.java 51f45c2 engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapDaoImpl.java bb24e04 server/src/com/cloud/network/as/AutoScaleManagerImpl.java 8fafcc9 server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java 4e6d6fd Diff: https://reviews.apache.org/r/19916/diff/ Testing --- Tested listLoadBalancerRuleInstances API to display vm and vm ip address details. Tested removing only specific ip of the VM from the LB rule. Thanks, Jayapal Reddy
RE: [PROPOSAL][Merge] Windowsfication of management server
Sudha, Have you distributed a list of items yet? I'm sorry if you have and I've missed it. Regards Alex Hitchins D: +44 1892 523 587 | S: +44 2036 030 540 | M: +44 7788 423 969 alex.hitch...@shapeblue.com -Original Message- From: Sudha Ponnaganti [mailto:sudha.ponnaga...@citrix.com] Sent: 28 March 2014 15:00 To: dev@cloudstack.apache.org Cc: Daan Hoogland; Donal Lafferty Subject: RE: [PROPOSAL][Merge] Windowsfication of management server Let me send broader categories that can be shared, meanwhile if you have some preference, pl do post it. -Original Message- From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com] Sent: Friday, March 28, 2014 7:49 AM To: dev@cloudstack.apache.org Cc: Daan Hoogland; Donal Lafferty Subject: RE: [PROPOSAL][Merge] Windowsfication of management server Sudha, Yes - that sounds like a good idea. How do you think it best to draw up a to-do list or tasks? Regards Alex Hitchins D: +44 1892 523 587 | S: +44 2036 030 540 | M: +44 7788 423 969 alex.hitch...@shapeblue.com -Original Message- From: Sudha Ponnaganti [mailto:sudha.ponnaga...@citrix.com] Sent: 28 March 2014 14:47 To: dev@cloudstack.apache.org Cc: Daan Hoogland; Donal Lafferty Subject: RE: [PROPOSAL][Merge] Windowsfication of management server Alex, Glad to hear that you are interested in validation aspects for this feature. We are also interested. Not to cover the same areas, can we share general broader categories for validation. Thanks /sudha -Original Message- From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com] Sent: Friday, March 28, 2014 4:07 AM To: dev@cloudstack.apache.org Cc: Daan Hoogland; Donal Lafferty Subject: RE: [PROPOSAL][Merge] Windowsfication of management server I'm happy to help with documentation for this and doing testing, maybe some packaging. I can certainly host installers if they need to be separate. I would guess it best to start with testing first and building up documentation from there? Perhaps this needs its own thread running now? Regards Alex Hitchins D: +44 1892 523 587 | S: +44 2036 030 540 | M: +44 7788 423 969 alex.hitch...@shapeblue.com -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: 28 March 2014 09:41 To: dev@cloudstack.apache.org Cc: Daan Hoogland; Donal Lafferty Subject: Re: [PROPOSAL][Merge] Windowsfication of management server Hey, 4.4 is in feature freeze, so no new features will be added. I think its fair to debate if this is a feature in that sense. It seems like minor changes and the addition of a few scripts, making it a simple change in my view. It would be great to be able to announce this, but for it to be part of a release i think we need a couple of other things to be done. The most prominent are, packaging, testing and documentation. Documentation: If we want to ship this with 4.4 and announce that CS now runs on windows we need to have the installation manual covered at least. Packaging: We can't expect our users to build it themselves on windows. So we need some kind of packaging that people can install on their windows server. Testing: We need to automagically verify that these changes aren't affected by future changes. I would expect to see the packaging and functional tests on starting and stopping CS on a windows host as part of the automated test procedure. I'd be happy to work with you to set it up on Jenkins. If we can fix these items before the bug fix phase i'd be +1 to include this in the 4.4 release, but of course this is depending on the consensus in the community. I'm just the RM, not the guy who decides what goes into a release. Cheers, Hugo On 28 mrt. 2014, at 06:14, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: It will be really nice to get the preview code for windowsfication in 4.4. https://reviews.apache.org/r/18964/ The changes are well segregated. -abhi On 28/03/14 10:26 am, Damoder Reddy damoder.re...@citrix.com wrote: Hugo, Can Windowsfication be cherry-picked to 4.4 from master ? It is now well reviewed and tested. Due to review process it got delayed to commit to 4.4 earlier. Thanks Regards Damodar/ Need Enterprise Grade Support for Apache CloudStack? Our CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ offers the best 24/7 SLA for CloudStack Environments. Apache CloudStack Bootcamp training courses **NEW!** CloudStack 4.2.1 traininghttp://shapeblue.com/cloudstack-training/ 18th-19th February 2014, Brazil. Classroomhttp://shapeblue.com/cloudstack-training/ 17th-23rd March 2014, Region A. Instructor led, On-linehttp://shapeblue.com/cloudstack-training/ 24th-28th March 2014, Region B. Instructor led, On-linehttp://shapeblue.com/cloudstack-training/ 16th-20th June 2014, Region A. Instructor led, On-linehttp://shapeblue.com/cloudstack-training/ 23rd-27th June 2014, Region B. Instructor led,
Re: Unable to deploy systemvms
Tejas,
The SSVM will mount the NFS share using is Storage network interface if
define otherwise it will mount it using is management NIC. To download the
template, the traffic from the SSVM will go from is Public interface. You
should be able to ping the SSVM public IP, the current setup might have a
networking issue such as an improper VLAN ID defined or label.
Pierre-Luc Dion
Architecte de Solution Cloud | Cloud Solutions Architect
- - -
*CloudOps*420 rue Guy
Montréal QC H3J 1S6
www.cloudops.com
@CloudOps_
On Thu, Apr 3, 2014 at 2:31 AM, Tejas Gadaria refond.g...@gmail.com wrote:
Hi Dion,
Thanks for the clue,I was missing 'cloud traffic label' there.
One step ahead Now SSVM and CPVM is UP running. I am able to ping both
private ip but not Public ip from Management server and link local is also
pinging from hypervisor . I tried SSVM health check. every thing fine.
secstorage.allowed.internal.sites = Management server ip.
2014-04-03 11:15:55,280 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-7:null) SeqA 2-5: Processing Seq 2-5: { Cmd ,
MgmtId: -1, via: 2, Ver: v1, Flags: 11,
[{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n
\connections\: []\n},wait:0}}] }
2014-04-03 11:15:55,288 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-7:null) SeqA 2-5: Sending Seq 2-5: { Ans: , MgmtId:
345049296663, via: 2, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2014-04-03 11:15:55,996 DEBUG [o.a.c.s.RemoteHostEndPoint]
(Timer-11:ctx-67fcb05a) Sending command
org.apache.cloudstack.storage.command.DownloadProgressCommand to host: 3
2014-04-03 11:15:55,998 DEBUG [c.c.a.t.Request] (Timer-11:ctx-67fcb05a) Seq
3-140181514: Sending { Cmd , MgmtId: 345049296663, via: 3(s-1-VM), Ver:
v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.DownloadProgressCommand:{jobId:c9ad6108-ddcd-44a1-8e62-9d7ab76e4834,request:GET_STATUS,hvm:false,description:CentOS
5.6(64-bit) no GUI
(XenServer),checksum:905cec879afd9c9d22ecc8036131a180,maxDownloadSizeInBytes:53687091200,id:5,resourceType:TEMPLATE,installPath:template/tmpl/1/5,_store:{com.cloud.agent.api.to.NfsTO:{_url:nfs://
10.129.151.60/vol/secondary,_role:Image}},url:
http://download.cloud.com/templates/builtin/centos56-x86_64.vhd.bz2
,format:VHD,accountId:1,name:centos56-x86_64-xen,secUrl:nfs://
10.129.151.60/vol/secondary,wait:0}}] }
2014-04-03 11:15:55,999 DEBUG [o.a.c.s.RemoteHostEndPoint]
(Timer-10:ctx-7539f2bf) Sending command
org.apache.cloudstack.storage.command.DownloadProgressCommand to host: 3
2014-04-03 11:15:56,001 DEBUG [c.c.a.t.Request] (Timer-10:ctx-7539f2bf) Seq
3-140181515: Sending { Cmd , MgmtId: 345049296663, via: 3(s-1-VM), Ver:
v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.DownloadProgressCommand:{jobId:8c3263f0-b796-4f28-a965-6f2ef421f815,request:GET_STATUS,hvm:false,description:CentOS
5.3(64-bit) no GUI
(XenServer),checksum:b63d854a9560c013142567bbae8d98cf,maxDownloadSizeInBytes:53687091200,id:2,resourceType:TEMPLATE,installPath:template/tmpl/1/2,_store:{com.cloud.agent.api.to.NfsTO:{_url:nfs://
10.129.151.60/vol/secondary,_role:Image}},url:
http://download.cloud.com/templates/builtin/f59f18fb-ae94-4f97-afd2-f84755767aca.vhd.bz2
,format:VHD,accountId:1,name:centos53-x86_64,secUrl:nfs://
10.129.151.60/vol/secondary,wait:0}}] }
2014-04-03 11:15:56,021 DEBUG [c.c.a.t.Request]
(AgentManager-Handler-9:null) Seq 3-140181515: Processing: { Ans: ,
MgmtId: 345049296663, via: 3, Ver: v1, Flags: 10,
[{com.cloud.agent.api.storage.DownloadAnswer:{jobId:8c3263f0-b796-4f28-a965-6f2ef421f815,*downloadPct:0,errorString:No
route to
host,downloadStatus:DOWNLOAD_ERROR,downloadPath:/mnt/SecStorage/083f43be-897d-3f0d-b65e-54e1462fa59a/template/tmpl/1/2/dnld4937216608487758375tmp_,installPath:template/tmpl/1/2,templateSize:0,templatePhySicalSize:0,checkSum:b63d854a9560c013142567bbae8d98cf,result:true,details:No
route to host,wait:0}}] }*
2014-04-03 11:15:56,021 DEBUG [c.c.a.t.Request]
(AgentManager-Handler-8:null) Seq 3-140181514: Processing: { Ans: ,
MgmtId: 345049296663, via: 3, Ver: v1, Flags: 10,
[{com.cloud.agent.api.storage.DownloadAnswer:{jobId:c9ad6108-ddcd-44a1-8e62-9d7ab76e4834,downloadPct:0,errorString:No
route to
host,*downloadStatus:DOWNLOAD_ERROR,*downloadPath:/mnt/SecStorage/083f43be-897d-3f0d-b65e-54e1462fa59a/template/tmpl/1/5/dnld2277393467913145419tmp_,installPath:template/tmpl/1/5,templateSize:0,templatePhySicalSize:0,checkSum:905cec879afd9c9d22ecc8036131a180,result:true,details:No
route to host,wait:0}}] }
Regards,
Tejas
On Wed, Apr 2, 2014 at 7:24 PM, Pierre-Luc Dion pd...@cloudops.com
wrote:
Tejas,
Did you add the network label names in Cloudstack ? You need to specify
the network label name in Cloudstack that are configured in XenServer.
I'm
suspecting that the current issue is that CloudStack cannot map the
Storage
Network from is config in XenServer so
Re: ALARM - ACS reboots host servers!!!
Andrei, is your hypervisor KVM? I'm using XenServer.
Review Request 19995: VM Userdata field at GUI VM creation
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19995/ --- Review request for cloudstack. Repository: cloudstack-git Description --- VM creation user interface : added the Userdata field Diffs - client/WEB-INF/classes/resources/messages.properties 8abe874 ui/index.jsp 4910b9f ui/scripts/instanceWizard.js c2d3030 Diff: https://reviews.apache.org/r/19995/diff/ Testing --- tested done on 4.2.1. This patch was adapted for last master branch. Thanks, Jean-Francois Vincent
Re: Review Request 19917: Improvements on exception handlers (JIRA-6242)
Ding,
I think we can dare to do so in master as it will not see release for
a while. We'll just have to be aware of the locations and be on alert
for any stacktraces that will pass this list. I would not like to do
this on the 4.4 branch even when it is an improvement of code quality
as such. It might do things or prevent things from happening that we
need done.
I don't see a new version of the diff in the review request. Did you
'Update' - 'Upload Diff'?
regards,
Daan
On Thu, Apr 3, 2014 at 12:34 AM, Ding Yuan y...@ece.utoronto.ca wrote:
Uploaded a new patch to 19917. Changed the verbosity to debug, and addressed
Daan's comment on providing more distinctive text messages.
Sorry that I haven't split them into smaller patches.
Note in a few cases the original code was like:
try {
pstmt = txn.prepareAutoCloseStatement(sql);
String gmtCutTime =
DateUtil.getDateDisplayString(TimeZone.getTimeZone(GMT), cutTime);
pstmt.setString(1, gmtCutTime);
pstmt.setString(2, gmtCutTime);
ResultSet rs = pstmt.executeQuery();
while (rs.next()) {
RunningHostCountInfo info = new RunningHostCountInfo();
info.setDcId(rs.getLong(1));
info.setHostType(rs.getString(2));
info.setCount(rs.getInt(3));
l.add(info);
}
} catch (SQLException e) {
} catch (Throwable e) {
}
The try block only throws SQLException as checked exception, and this code
would also swallow any unchecked exceptions. I removed the catch (Throwable)
in these cases to avoid potentially swallowing any unexpected runtime
exceptions. Please let me know if this is not desirable so I can further
update.
Thanks,
Ding
On Apr 2, 2014, at 5:17 PM, Ding Yuan y...@eecg.toronto.edu wrote:
Thanks all for the quick comments!
If i understand the discussion correctly, I will just change all the added
log printing statements to debug verbosity. I will upload a new patch for
that shortly.
Now a bit back story: the reason we are doing this is that we recently did
an analysis on many bugs collected from JIRA to understand why today's cloud
system fails. And we found that almost all of the cluster-wide failures are
caused by buggy exception handling, which would often turn a component
failure into a cluster-wide one. One of the common bug pattern is ignoring
some exceptions -- allowing them to propagate and finally turn into disaster.
Therefore we built a simple static checking tool just to check some simple
rules for exception handling, such as if an exception is ignored.
Admittedly, it would be much harder to reason about the potential
consequences caused for ignoring a certain exception, that's why without
much more domain knowledge I can only recommend to 1) avoid over-catching an
exception, especially when the handling logic will swallow it, and 2) log
them, as what this patch does.
Nevertheless, it seems the four cases I mentioned in JIRA-6242 are
particularly suspicious. It might be worthwhile to double check their
correctness if you have time. I am reposting them below.
Thanks!
Ding
=
Case 1:
Line: 375, File: com/cloud/network/ovs/OvsTunnelManagerImpl.java
326: try {
327: String myIp = getGreEndpointIP(dest.getHost(), nw);
.. .. ..
373: } catch (Exception e) {
374: // I really thing we should do a better handling of these exceptions
375: s_logger.warn(Ovs Tunnel network created tunnel failed, e);
376: }
Comment seems to suggest for a better handling.
=
=
Case 2:
Line: 2295, File: com/cloud/resource/ResourceManagerImpl.java
2284: try {
2285: /*
2286: * FIXME: this is a buggy logic, check with alex. Shouldn't
2287: * return if propagation return non null
2288: */
2289: Boolean result = _clusterMgr.propagateResourceEvent(h.getId(),
ResourceState.Event.UpdatePassword);
2290: if (result != null) {
2291: return result;
2292: }
2293:
2294: doUpdateHostPassword(h.getId());
2295: } catch (AgentUnavailableException e) {
2296: }
Seem from the comment the logic should be fixed.
A similar code snipeet is at:
Line: 2276, File: com/cloud/resource/ResourceManagerImpl.java
=
=
Case 3:
Line: 184, File:
org/apache/cloudstack/api/command/user/autoscale/CreateAutoScaleVmGroupCmd.java
174: try
175: {
176: success = _autoScaleService.configureAutoScaleVmGroup(this);
177: if (success) {
178: vmGroup = _entityMgr.findById(AutoScaleVmGroup.class, getEntityId());
179: AutoScaleVmGroupResponse responseObject =
_responseGenerator.createAutoScaleVmGroupResponse(vmGroup);
180: setResponseObject(responseObject);
181: responseObject.setResponseName(getCommandName());
182: }
183: } catch (Exception ex) {
184: // TODO what will happen if
Re: Review Request 19584: CLOUDSTACK-6258: Disable systemvm cloud startup script from logging messages to /var/log/cloud/cloud.out
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19584/ --- (Updated April 3, 2014, 2:12 p.m.) Review request for cloudstack. Changes --- Incorporate Review comments and retested. Repository: cloudstack-git Description --- This will prevent the /etc/init.d/cloud script from logging messages to /var/log/cloud/cloud.out if the CLOUD_DEBUG flag is not defined. If the flag is defined only then will messages be logged. This is because the cloud.out file gets rolled over once max size is reached via the log4j settings, since the script is not aware of the log4j settings it causes the log file to exceed its max size and fill up the file system. Diffs (updated) - systemvm/patches/debian/config/etc/init.d/cloud 83853bc Diff: https://reviews.apache.org/r/19584/diff/ Testing --- The console proxy vm was started and console sessions tested. The secondary storage vm was succesfully started. Thanks, Saurav Lahiri
RE: [PROPOSAL][Merge] Windowsfication of management server
Hi Alex, Sorry not yet. Will get back to you tonight PST Thanks /sudha -Original Message- From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com] Sent: Thursday, April 03, 2014 3:41 AM To: dev@cloudstack.apache.org Cc: Daan Hoogland; Donal Lafferty Subject: RE: [PROPOSAL][Merge] Windowsfication of management server Sudha, Have you distributed a list of items yet? I'm sorry if you have and I've missed it. Regards Alex Hitchins D: +44 1892 523 587 | S: +44 2036 030 540 | M: +44 7788 423 969 alex.hitch...@shapeblue.com -Original Message- From: Sudha Ponnaganti [mailto:sudha.ponnaga...@citrix.com] Sent: 28 March 2014 15:00 To: dev@cloudstack.apache.org Cc: Daan Hoogland; Donal Lafferty Subject: RE: [PROPOSAL][Merge] Windowsfication of management server Let me send broader categories that can be shared, meanwhile if you have some preference, pl do post it. -Original Message- From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com] Sent: Friday, March 28, 2014 7:49 AM To: dev@cloudstack.apache.org Cc: Daan Hoogland; Donal Lafferty Subject: RE: [PROPOSAL][Merge] Windowsfication of management server Sudha, Yes - that sounds like a good idea. How do you think it best to draw up a to-do list or tasks? Regards Alex Hitchins D: +44 1892 523 587 | S: +44 2036 030 540 | M: +44 7788 423 969 alex.hitch...@shapeblue.com -Original Message- From: Sudha Ponnaganti [mailto:sudha.ponnaga...@citrix.com] Sent: 28 March 2014 14:47 To: dev@cloudstack.apache.org Cc: Daan Hoogland; Donal Lafferty Subject: RE: [PROPOSAL][Merge] Windowsfication of management server Alex, Glad to hear that you are interested in validation aspects for this feature. We are also interested. Not to cover the same areas, can we share general broader categories for validation. Thanks /sudha -Original Message- From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com] Sent: Friday, March 28, 2014 4:07 AM To: dev@cloudstack.apache.org Cc: Daan Hoogland; Donal Lafferty Subject: RE: [PROPOSAL][Merge] Windowsfication of management server I'm happy to help with documentation for this and doing testing, maybe some packaging. I can certainly host installers if they need to be separate. I would guess it best to start with testing first and building up documentation from there? Perhaps this needs its own thread running now? Regards Alex Hitchins D: +44 1892 523 587 | S: +44 2036 030 540 | M: +44 7788 423 969 alex.hitch...@shapeblue.com -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: 28 March 2014 09:41 To: dev@cloudstack.apache.org Cc: Daan Hoogland; Donal Lafferty Subject: Re: [PROPOSAL][Merge] Windowsfication of management server Hey, 4.4 is in feature freeze, so no new features will be added. I think its fair to debate if this is a feature in that sense. It seems like minor changes and the addition of a few scripts, making it a simple change in my view. It would be great to be able to announce this, but for it to be part of a release i think we need a couple of other things to be done. The most prominent are, packaging, testing and documentation. Documentation: If we want to ship this with 4.4 and announce that CS now runs on windows we need to have the installation manual covered at least. Packaging: We can't expect our users to build it themselves on windows. So we need some kind of packaging that people can install on their windows server. Testing: We need to automagically verify that these changes aren't affected by future changes. I would expect to see the packaging and functional tests on starting and stopping CS on a windows host as part of the automated test procedure. I'd be happy to work with you to set it up on Jenkins. If we can fix these items before the bug fix phase i'd be +1 to include this in the 4.4 release, but of course this is depending on the consensus in the community. I'm just the RM, not the guy who decides what goes into a release. Cheers, Hugo On 28 mrt. 2014, at 06:14, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: It will be really nice to get the preview code for windowsfication in 4.4. https://reviews.apache.org/r/18964/ The changes are well segregated. -abhi On 28/03/14 10:26 am, Damoder Reddy damoder.re...@citrix.com wrote: Hugo, Can Windowsfication be cherry-picked to 4.4 from master ? It is now well reviewed and tested. Due to review process it got delayed to commit to 4.4 earlier. Thanks Regards Damodar/ Need Enterprise Grade Support for Apache CloudStack? Our CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ offers the best 24/7 SLA for CloudStack Environments. Apache CloudStack Bootcamp training courses **NEW!** CloudStack 4.2.1 traininghttp://shapeblue.com/cloudstack-training/ 18th-19th February 2014, Brazil. Classroomhttp://shapeblue.com/cloudstack-training/ 17th-23rd March 2014, Region A.
Re: Review Request 19917: Improvements on exception handlers (JIRA-6242)
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19917/
---
(Updated April 3, 2014, 3:22 p.m.)
Review request for cloudstack.
Changes
---
Updated according to our email discussions.
Changed the verbosity to debug, and addressed Daan’s comment on providing more
distinctive text messages.
Sorry that I haven’t split them into smaller patches.
Note in a few cases the original code was like:
try {
pstmt = txn.prepareAutoCloseStatement(sql);
String gmtCutTime =
DateUtil.getDateDisplayString(TimeZone.getTimeZone(GMT), cutTime);
pstmt.setString(1, gmtCutTime);
pstmt.setString(2, gmtCutTime);
ResultSet rs = pstmt.executeQuery();
while (rs.next()) {
RunningHostCountInfo info = new RunningHostCountInfo();
info.setDcId(rs.getLong(1));
info.setHostType(rs.getString(2));
info.setCount(rs.getInt(3));
l.add(info);
}
} catch (SQLException e) {
} catch (Throwable e) {
}
The try block only throws SQLException as checked exception, and this code
would also swallow any unchecked exceptions. I removed the catch (Throwable) in
these cases to avoid potentially swallowing any unexpected runtime exceptions.
Please let me know if this is not desirable so I can further update.
Thanks,
Repository: cloudstack-git
Description
---
This is the patch for JIRA-6242. See
https://issues.apache.org/jira/browse/CLOUDSTACK-6242 for more details. Thanks!
Diffs (updated)
-
engine/orchestration/src/com/cloud/agent/manager/AgentManagerImpl.java
0d41bc1
engine/orchestration/src/com/cloud/agent/manager/ClusteredAgentManagerImpl.java
01508a4
engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 3e088db
engine/orchestration/src/org/apache/cloudstack/engine/datacenter/entity/api/db/dao/EngineDataCenterDaoImpl.java
4b6818e
engine/schema/src/com/cloud/dc/dao/DataCenterDaoImpl.java ea5039f
engine/schema/src/com/cloud/host/dao/HostDaoImpl.java 426c90d
engine/schema/src/com/cloud/storage/dao/StoragePoolHostDaoImpl.java e42eaf4
engine/schema/src/com/cloud/storage/dao/VMTemplateDaoImpl.java 34fdca5
engine/schema/src/com/cloud/upgrade/dao/Upgrade2214to30.java 58dd916
engine/schema/src/com/cloud/vm/dao/ConsoleProxyDaoImpl.java 5e9c2f0
engine/schema/src/com/cloud/vm/dao/SecondaryStorageVmDaoImpl.java 1f382d6
engine/storage/src/org/apache/cloudstack/storage/datastore/DataObjectManagerImpl.java
6ed1274
framework/ipc/src/org/apache/cloudstack/framework/serializer/OnwireClassRegistry.java
83c8a42
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/discoverer/XcpServerDiscoverer.java
0ad6dc4
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServerConnectionPool.java
b779085
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServerStorageProcessor.java
e512046
plugins/storage/volume/solidfire/src/org/apache/cloudstack/storage/datastore/lifecycle/SolidFirePrimaryDataStoreLifeCycle.java
af6a77a
server/src/com/cloud/resource/ResourceManagerImpl.java f9a59ba
server/src/com/cloud/server/ConfigurationServerImpl.java b8da4c8
services/console-proxy/server/src/com/cloud/consoleproxy/ConsoleProxyThumbnailHandler.java
06f21d3
utils/src/com/cloud/utils/net/NetUtils.java 6350986
Diff: https://reviews.apache.org/r/19917/diff/
Testing
---
Thanks,
Ding Yuan
Re: Review Request 19917: Improvements on exception handlers (JIRA-6242)
Oops, sorry I didn’t publish my diff. I just published it on review board.
Thanks for the comment Daan! Please let me know if I further need to improve it.
Ding
On Apr 3, 2014, at 9:52 AM, Daan Hoogland daan.hoogl...@gmail.com wrote:
Ding,
I think we can dare to do so in master as it will not see release for
a while. We'll just have to be aware of the locations and be on alert
for any stacktraces that will pass this list. I would not like to do
this on the 4.4 branch even when it is an improvement of code quality
as such. It might do things or prevent things from happening that we
need done.
I don't see a new version of the diff in the review request. Did you
'Update' - 'Upload Diff'?
regards,
Daan
On Thu, Apr 3, 2014 at 12:34 AM, Ding Yuan y...@ece.utoronto.ca wrote:
Uploaded a new patch to 19917. Changed the verbosity to debug, and addressed
Daan's comment on providing more distinctive text messages.
Sorry that I haven't split them into smaller patches.
Note in a few cases the original code was like:
try {
pstmt = txn.prepareAutoCloseStatement(sql);
String gmtCutTime =
DateUtil.getDateDisplayString(TimeZone.getTimeZone(GMT), cutTime);
pstmt.setString(1, gmtCutTime);
pstmt.setString(2, gmtCutTime);
ResultSet rs = pstmt.executeQuery();
while (rs.next()) {
RunningHostCountInfo info = new RunningHostCountInfo();
info.setDcId(rs.getLong(1));
info.setHostType(rs.getString(2));
info.setCount(rs.getInt(3));
l.add(info);
}
} catch (SQLException e) {
} catch (Throwable e) {
}
The try block only throws SQLException as checked exception, and this code
would also swallow any unchecked exceptions. I removed the catch (Throwable)
in these cases to avoid potentially swallowing any unexpected runtime
exceptions. Please let me know if this is not desirable so I can further
update.
Thanks,
Ding
On Apr 2, 2014, at 5:17 PM, Ding Yuan y...@eecg.toronto.edu wrote:
Thanks all for the quick comments!
If i understand the discussion correctly, I will just change all the added
log printing statements to debug verbosity. I will upload a new patch for
that shortly.
Now a bit back story: the reason we are doing this is that we recently did
an analysis on many bugs collected from JIRA to understand why today's cloud
system fails. And we found that almost all of the cluster-wide failures are
caused by buggy exception handling, which would often turn a component
failure into a cluster-wide one. One of the common bug pattern is ignoring
some exceptions -- allowing them to propagate and finally turn into disaster.
Therefore we built a simple static checking tool just to check some simple
rules for exception handling, such as if an exception is ignored.
Admittedly, it would be much harder to reason about the potential
consequences caused for ignoring a certain exception, that's why without
much more domain knowledge I can only recommend to 1) avoid over-catching an
exception, especially when the handling logic will swallow it, and 2) log
them, as what this patch does.
Nevertheless, it seems the four cases I mentioned in JIRA-6242 are
particularly suspicious. It might be worthwhile to double check their
correctness if you have time. I am reposting them below.
Thanks!
Ding
=
Case 1:
Line: 375, File: com/cloud/network/ovs/OvsTunnelManagerImpl.java
326: try {
327: String myIp = getGreEndpointIP(dest.getHost(), nw);
.. .. ..
373: } catch (Exception e) {
374: // I really thing we should do a better handling of these exceptions
375: s_logger.warn(Ovs Tunnel network created tunnel failed, e);
376: }
Comment seems to suggest for a better handling.
=
=
Case 2:
Line: 2295, File: com/cloud/resource/ResourceManagerImpl.java
2284: try {
2285: /*
2286: * FIXME: this is a buggy logic, check with alex. Shouldn't
2287: * return if propagation return non null
2288: */
2289: Boolean result = _clusterMgr.propagateResourceEvent(h.getId(),
ResourceState.Event.UpdatePassword);
2290: if (result != null) {
2291: return result;
2292: }
2293:
2294: doUpdateHostPassword(h.getId());
2295: } catch (AgentUnavailableException e) {
2296: }
Seem from the comment the logic should be fixed.
A similar code snipeet is at:
Line: 2276, File: com/cloud/resource/ResourceManagerImpl.java
=
=
Case 3:
Line: 184, File:
org/apache/cloudstack/api/command/user/autoscale/CreateAutoScaleVmGroupCmd.java
174: try
175: {
176: success = _autoScaleService.configureAutoScaleVmGroup(this);
177: if (success) {
178: vmGroup = _entityMgr.findById(AutoScaleVmGroup.class, getEntityId());
179:
Re: Review Request 17790: Domain-Account-User Sync Up Among Multiple Regions
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17790/ --- (Updated April 3, 2014, 3:54 p.m.) Review request for cloudstack. Changes --- This is the patch for the new plugin. Repository: cloudstack-git Description --- Currently, under the environment of cloudstack with multiple regions, each region has its own management server running with a separate database, which will cause data discrepancies when users create/update/delete domain/account/user data independently in each management server. So to support multiple regions and provide one point of entry for each customer, this implementation duplicates domain/account/user information of customers in one region to all of the regions independently whenever there is any change. https://issues.apache.org/jira/browse/CLOUDSTACK-4992 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain-Account-User+Sync+Up+Among+Multiple+Regions Diffs (updated) - plugins/event-bus/multiregion/pom.xml PRE-CREATION plugins/event-bus/multiregion/resources/META-INF/cloudstack/spring-mom-multiregion-daos-context.xml PRE-CREATION plugins/event-bus/multiregion/resources/META-INF/cloudstack/system/spring-plugin-multiregion-system-context.xml PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/FullSyncer.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/InjectedCollection.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/MultiRegionEventBus.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/api/AccountInterface.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/api/BaseInterface.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/api/DomainInterface.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/api/UserInterface.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/service/AccountFullSyncProcessor.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/service/AccountService.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/service/BaseService.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/service/DomainFullSyncProcessor.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/service/DomainService.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/service/FullScanner.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/service/FullSyncProcessor.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/service/LocalAccountManager.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/service/LocalDomainManager.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/service/LocalUserManager.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/service/RemoteAccountEventProcessor.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/service/RemoteDomainEventProcessor.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/service/RemoteEventProcessor.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/service/RemoteUserEventProcessor.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/service/UserFullSyncProcessor.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/service/UserService.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/simulator/SimulatorAccountLocalGenerator.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/simulator/SimulatorAccountLocalGeneratorEvent.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/simulator/SimulatorAutoGenerator.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/simulator/SimulatorDomainLocalGenerator.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/simulator/SimulatorDomainLocalGeneratorEvent.java PRE-CREATION plugins/event-bus/multiregion/src/org/apache/cloudstack/mom/multiregion/simulator/SimulatorLocalGenerator.java PRE-CREATION
Re: [DISCUSS]{BEHAVIORAL-CHANGE]Domain-Account-User Sync Up Among Multiple Regions
All,
I updated the patches as per Alena's request.
Let me know if there is anything missing/incorrect.
Thanks
Alex Ough
On Wed, Mar 26, 2014 at 1:40 PM, Alex Ough alex.o...@sungard.com wrote:
Sorry, my bad. I mis-read your comment.
Thanks for pointing it out.
Alex Ough
On Wed, Mar 26, 2014 at 12:25 PM, Chiradeep Vittal
chiradeep.vit...@citrix.com wrote:
I didn't say do not use auto wiring. I said the convention is to use
@Inject which you didn't have.
From: Alena Prokharchyk alena.prokharc...@citrix.com
Date: Wednesday, March 26, 2014 at 7:39 AM
To: Alex Ough alex.o...@sungard.com, dev@cloudstack.apache.org
dev@cloudstack.apache.org
Cc: Chiradeep Vittal chiradeep.vit...@citrix.com
Subject: Re: [DISCUSS]{BEHAVIORAL-CHANGE]Domain-Account-User Sync Up
Among Multiple Regions
Alex, I'm attending a conference today, will review the patch tomorrow.
-Alena
From: Alex Ough alex.o...@sungard.com
Date: Wednesday, March 26, 2014 at 6:35 AM
To: Alena Prokharchyk alena.prokharc...@citrix.com
Cc: dev@cloudstack.apache.org dev@cloudstack.apache.org, Chiradeep
Vittal chiradeep.vit...@citrix.com
Subject: Re: [DISCUSS]{BEHAVIORAL-CHANGE]Domain-Account-User Sync Up
Among Multiple Regions
Alena,
It took a little time to update the patch because I had a vacation last
week.
Now I uploaded the updated patch for review with below status, so please
check them and let me know what you think.
I hope it to be merged soon to wrap this up asap.
1. no change with waiting for comments on my recommendation.
2. The two things to turn on the sync-up among multiple regions is to
change the class name of eventNotificationBus into MultiRegionEventBus
from RabbitMQEventBus as below and change the value of
'region.full.scan.interval' in Global Settings. And the new classes are
never used unless the feature is turned on, so I'm not sure if auto wiring
is necessary here and Chiradeep asked not to use @inject in his initial
review, so I removed them.
bean id=eventNotificationBus
class=org.apache.cloudstack.mom.rabbitmq.MultiRegionEventBus
3. They are not adaptors, but inherited classes to process
domain/account/user objects separately.
4. Done
5. Same
6. I removed 'domain path' from AccountResponse UserResponse.
Thanks
Alex Ough
On Thu, Mar 13, 2014 at 9:48 PM, Alex Ough alex.o...@sungard.com wrote:
What I think based on your comments are
1. Well, I have a different thought. I'd rather have separated classes
instead of having a class with lots of methods, which makes the maintenance
easier. And as you show as an example, it is possible to create a method
and merge them, but I think it is better to provide separate methods that
are exposed outside so that the callers can know what to call with ease.
2. Let me look at that.
3. I'm not sure why you think they are adapters, but let me look at
that class.
4. OK, let me work on this.
5. The urls are stored in the region table along with username and
password. Please see 'RegionVO' under
'engine/schema/src/org/apache/cloudstack/region'.
Thanks
Alex Ough
On Thu, Mar 13, 2014 at 5:49 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Alex,
There are so many classes, and it makes it hard to see/review the
feature.
Can you come up with some sort of visual diagram, so its easier to see
which component is responsible for what task, and how they interact with
each other.
My suggestions:
1) I think it would make sense to merge all the classes doing utils
tasks
(forming and sending Apis to CS) - UserInterface, AccountInterface,
DomainInterface - to a single util class. They do return generic types
anyway - JsonArray/JsonObject, and they do perform a generic util task -
forming and sending the request to the CS. I would merge them all with
the
BaseInterface and name it with the name indicating that this class is
responsible for sending API calls against CS. And this would be your
util
class.
You should also come up with some generic method that forms the requests
to CS APIs to make the code cleaner.
For example, look at these 2:
public JSONObject lockUser(String userId) throws Exception {
String paramStr = command=lockUserid= + userId +
response=jsonsessionkey= + URLEncoder.encode(getSessionKey(),
UTF-8);
return sendApacheGet(paramStr);
}
public JSONObject disableUser(String userId) throws Exception {
String paramStr = command=disableUserid= + userId +
response=jsonsessionkey= + URLEncoder.encode(getSessionKey(),
UTF-8);
return sendApacheGet(paramStr);
}
You repeat appending json and session key in all of them. Why not create
some generic method where you pass a) commandName 2) map of parameters,
and make that method return JsonObject/JsonArray?
2) I would suggest you utilize Spring framework in your code and auto
wire
all the dependencies by using @Inject rather than locating them with the
components
RE: Review Request 19616: Added check for null return.
Thanks for looking Daan, I'm unsure sometimes who is best to add to review
certain projects/sections.
I will review your comments and look out for those of Edison/Laszlo.
My immediate concern was to stop the log saying it had succeeded when it
hadn't in fact succeeded.
Again, I'll review this and make amendments.
Alex Hitchins
-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: 03 April 2014 16:53
To: dev; Alex Hitchins; Edison Su; Laszlo Hornyak
Subject: Re: Review Request 19616: Added check for null return.
H Alex,
I had a quick look, keeping Laszlo's remark in mind.
volService.takeSnapshot(volume) catches all exceptions and then returns null
if any is caught. All calls are from tests or from VolumeApiServieImpl so I
think we can safely push the exeption handler down and not return null from
takeSnapshot. The only issue is that the VolumeService interface should then
throw it. (adding Edison in recip
list)
you want to do this:
throw new ResourceAllocationException(Take snapshot for VolumeId:
+ volumeId + failed., ResourceType.snapshot);
after calling
@Override
public SnapshotInfo takeSnapshot(VolumeInfo volume) {
SnapshotInfo snapshot = null;
try {
snapshot = snapshotMgr.takeSnapshot(volume);
} catch (Exception e) {
s_logger.debug(Take snapshot: + volume.getId() + failed,
e);
}
return snapshot;
}
the only Exception thrown in that method is a ResourceAllocationException. I
think it is better to let that one go through or handle the error.
thoughts Laszlo, Edison?
If you want people to look at your review reqest you can add them to the
list of reviewers in revoew board.
Regards,
Daan
On Thu, Apr 3, 2014 at 2:24 PM, Alex Hitchins alex.hitch...@shapeblue.com
wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19616/
---
(Updated April 3, 2014, 12:24 p.m.)
Review request for cloudstack.
Changes
---
Daan, are you able to take a look at this for me?
Repository: cloudstack-git
Description
---
Added check for returned null, if received then throw exception.
Diffs
-
server/src/com/cloud/storage/VolumeApiServiceImpl.java 5ffa99b
Diff: https://reviews.apache.org/r/19616/diff/
Testing
---
Compiled ran.
Thanks,
Alex Hitchins
--
Daan
Re: Review Request 19616: Added check for null return.
Prasanna made a nice remark about that; look at the annotations and/or
git log and see who did the most changes in the code you want to
protect the world against. Those are the people to address.
On Thu, Apr 3, 2014 at 6:06 PM, Alex Hitchins a...@alexhitchins.com wrote:
Thanks for looking Daan, I'm unsure sometimes who is best to add to review
certain projects/sections.
I will review your comments and look out for those of Edison/Laszlo.
My immediate concern was to stop the log saying it had succeeded when it
hadn't in fact succeeded.
Again, I'll review this and make amendments.
Alex Hitchins
-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: 03 April 2014 16:53
To: dev; Alex Hitchins; Edison Su; Laszlo Hornyak
Subject: Re: Review Request 19616: Added check for null return.
H Alex,
I had a quick look, keeping Laszlo's remark in mind.
volService.takeSnapshot(volume) catches all exceptions and then returns null
if any is caught. All calls are from tests or from VolumeApiServieImpl so I
think we can safely push the exeption handler down and not return null from
takeSnapshot. The only issue is that the VolumeService interface should then
throw it. (adding Edison in recip
list)
you want to do this:
throw new ResourceAllocationException(Take snapshot for VolumeId:
+ volumeId + failed., ResourceType.snapshot);
after calling
@Override
public SnapshotInfo takeSnapshot(VolumeInfo volume) {
SnapshotInfo snapshot = null;
try {
snapshot = snapshotMgr.takeSnapshot(volume);
} catch (Exception e) {
s_logger.debug(Take snapshot: + volume.getId() + failed,
e);
}
return snapshot;
}
the only Exception thrown in that method is a ResourceAllocationException. I
think it is better to let that one go through or handle the error.
thoughts Laszlo, Edison?
If you want people to look at your review reqest you can add them to the
list of reviewers in revoew board.
Regards,
Daan
On Thu, Apr 3, 2014 at 2:24 PM, Alex Hitchins alex.hitch...@shapeblue.com
wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19616/
---
(Updated April 3, 2014, 12:24 p.m.)
Review request for cloudstack.
Changes
---
Daan, are you able to take a look at this for me?
Repository: cloudstack-git
Description
---
Added check for returned null, if received then throw exception.
Diffs
-
server/src/com/cloud/storage/VolumeApiServiceImpl.java 5ffa99b
Diff: https://reviews.apache.org/r/19616/diff/
Testing
---
Compiled ran.
Thanks,
Alex Hitchins
--
Daan
--
Daan
Re: Review Request 19686: Implementation of the issue CLOUDSTACK 6139 - System.vm.use.local.storage global setting to zone setting
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19686/#review39416
---
server/src/com/cloud/deploy/DeploymentPlanningManagerImpl.java
https://reviews.apache.org/r/19686/#comment71809
The code seems to contradict the comment here. the check says either the
global or the zone setting must be true. The comment says the zone setting
rules in any case.
- daan Hoogland
On March 26, 2014, 2:56 p.m., Wilder Rodrigues wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19686/
---
(Updated March 26, 2014, 2:56 p.m.)
Review request for cloudstack, daan Hoogland and Hugo Trippaers.
Bugs: CLOUDSTACK-6139
https://issues.apache.org/jira/browse/CLOUDSTACK-6139
Repository: cloudstack-git
Description
---
I changed the following code in order to accomplish what is expected by the
issue:
Config enum:
SystemVMUseLocalStorage(
Advanced,
ManagementServer.class,
Boolean.class,
system.vm.use.local.storage,
false,
Indicates whether to use local storage pools or shared storage
pools for system VMs.,
null, ConfigKey.Scope.Zone.toString()),
DeploymentPlanningManagerImpl:
* I injected the DataCenterDao in order to check if the Zone uses
local storage
String ssvmUseLocalStorage =
_configDao.getValue(Config.SystemVMUseLocalStorage.key());
DataCenterVO zone = _zoneDao.findById(plan.getDataCenterId());
boolean zoneUsesLocalStorage = zone.isLocalStorageEnabled();
if (ssvmUseLocalStorage.equalsIgnoreCase(true)
zoneUsesLocalStorage) {
useLocalStorage = true;
}
Diffs
-
server/src/com/cloud/configuration/Config.java af1f062
server/src/com/cloud/deploy/DeploymentPlanningManagerImpl.java 9cbbb10
Diff: https://reviews.apache.org/r/19686/diff/
Testing
---
I have tested those changes running multiple zones (2 with local storage and
1 without). Instances, networks, and all the rest are working fine. I ran the
tests against 3 hosts running XenServer, where one of them has an extra disk
which is used as NFS primary storage. From the 2 instances using local
storage, one was created with Cloudtack 4.3 RC (9th round). In order to make
it clear, below the steps I followed to test it:
Global settings: system.vm.use.local.storage == true
1. Deploy Cloudstack 4.3.0 RC (9th round)
2. Create a zone (local storage enabled)
a. Create an instance and network
3. Test firewalling and port forwarding
4. Upgrade Cloudstack 4.3.0 RC (9th round) to Cloudstack 4.5.0-SNAPSHOT
5. Test firewalling and port forwarding
6. Create a zone (local storage enabled)
a. Create an instance and network
7. Create a zone (local storage disabled) + NFS primary storage
a. Create an instance and network
8. Test firewalling and port forwarding
With the steps above, I was able to set up the whole environment and make
sure the VMs were running properly and ACL/Port-Forwarding were also working
as expected.
Global settings: system.vm.use.local.storage == false
1. Deploy Cloudstack 4.3.0 RC (9th round)
2. Create a zone (local storage disabled) + NFS primary storage
a. Create an instance and network
3. Test firewalling and port forwarding
4. Upgrade Cloudstack 4.3.0 RC (9th round) to Cloudstack 4.5.0-SNAPSHOT
5. Test firewalling and port forwarding
6. Set system.vm.use.local.storage to true
7. Create a zone (local storage enabled)
a. Create an instance and network
8. Create a zone (local storage enabled)
a. Create an instance and network
9. Create new instance under the Zone which does not use local storage
10. Test firewalling and port forwarding
Again, everything worked as expected.
With the steps provided above, I can make sure that resources created with
version prior to master (4.5.0-SNAPSHOT) won't have problems when performing
an update.
Thanks,
Wilder Rodrigues
Re: [DISCUSS]{BEHAVIORAL-CHANGE]Domain-Account-User Sync Up Among Multiple Regions
Forgot to mention this, but it was a great help from Darren.
Thanks again, Darren!
Alex Ough
On Thu, Apr 3, 2014 at 11:56 AM, Alex Ough alex.o...@sungardas.com wrote:
All,
I updated the patches as per Alena's request.
Let me know if there is anything missing/incorrect.
Thanks
Alex Ough
On Wed, Mar 26, 2014 at 1:40 PM, Alex Ough alex.o...@sungard.com wrote:
Sorry, my bad. I mis-read your comment.
Thanks for pointing it out.
Alex Ough
On Wed, Mar 26, 2014 at 12:25 PM, Chiradeep Vittal
chiradeep.vit...@citrix.com wrote:
I didn't say do not use auto wiring. I said the convention is to use
@Inject which you didn't have.
From: Alena Prokharchyk alena.prokharc...@citrix.com
Date: Wednesday, March 26, 2014 at 7:39 AM
To: Alex Ough alex.o...@sungard.com, dev@cloudstack.apache.org
dev@cloudstack.apache.org
Cc: Chiradeep Vittal chiradeep.vit...@citrix.com
Subject: Re: [DISCUSS]{BEHAVIORAL-CHANGE]Domain-Account-User Sync Up
Among Multiple Regions
Alex, I'm attending a conference today, will review the patch
tomorrow.
-Alena
From: Alex Ough alex.o...@sungard.com
Date: Wednesday, March 26, 2014 at 6:35 AM
To: Alena Prokharchyk alena.prokharc...@citrix.com
Cc: dev@cloudstack.apache.org dev@cloudstack.apache.org, Chiradeep
Vittal chiradeep.vit...@citrix.com
Subject: Re: [DISCUSS]{BEHAVIORAL-CHANGE]Domain-Account-User Sync Up
Among Multiple Regions
Alena,
It took a little time to update the patch because I had a vacation
last week.
Now I uploaded the updated patch for review with below status, so please
check them and let me know what you think.
I hope it to be merged soon to wrap this up asap.
1. no change with waiting for comments on my recommendation.
2. The two things to turn on the sync-up among multiple regions is to
change the class name of eventNotificationBus into MultiRegionEventBus
from RabbitMQEventBus as below and change the value of
'region.full.scan.interval' in Global Settings. And the new classes are
never used unless the feature is turned on, so I'm not sure if auto wiring
is necessary here and Chiradeep asked not to use @inject in his initial
review, so I removed them.
bean id=eventNotificationBus
class=org.apache.cloudstack.mom.rabbitmq.MultiRegionEventBus
3. They are not adaptors, but inherited classes to process
domain/account/user objects separately.
4. Done
5. Same
6. I removed 'domain path' from AccountResponse UserResponse.
Thanks
Alex Ough
On Thu, Mar 13, 2014 at 9:48 PM, Alex Ough alex.o...@sungard.comwrote:
What I think based on your comments are
1. Well, I have a different thought. I'd rather have separated
classes instead of having a class with lots of methods, which makes the
maintenance easier. And as you show as an example, it is possible to create
a method and merge them, but I think it is better to provide separate
methods that are exposed outside so that the callers can know what to call
with ease.
2. Let me look at that.
3. I'm not sure why you think they are adapters, but let me look at
that class.
4. OK, let me work on this.
5. The urls are stored in the region table along with username and
password. Please see 'RegionVO' under
'engine/schema/src/org/apache/cloudstack/region'.
Thanks
Alex Ough
On Thu, Mar 13, 2014 at 5:49 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Alex,
There are so many classes, and it makes it hard to see/review the
feature.
Can you come up with some sort of visual diagram, so its easier to see
which component is responsible for what task, and how they interact
with
each other.
My suggestions:
1) I think it would make sense to merge all the classes doing utils
tasks
(forming and sending Apis to CS) - UserInterface, AccountInterface,
DomainInterface - to a single util class. They do return generic types
anyway - JsonArray/JsonObject, and they do perform a generic util task
-
forming and sending the request to the CS. I would merge them all with
the
BaseInterface and name it with the name indicating that this class is
responsible for sending API calls against CS. And this would be your
util
class.
You should also come up with some generic method that forms the
requests
to CS APIs to make the code cleaner.
For example, look at these 2:
public JSONObject lockUser(String userId) throws Exception {
String paramStr = command=lockUserid= + userId +
response=jsonsessionkey= + URLEncoder.encode(getSessionKey(),
UTF-8);
return sendApacheGet(paramStr);
}
public JSONObject disableUser(String userId) throws Exception {
String paramStr = command=disableUserid= + userId +
response=jsonsessionkey= + URLEncoder.encode(getSessionKey(),
UTF-8);
return sendApacheGet(paramStr);
}
You repeat appending json and session key in all of them. Why not
create
some generic method where you pass a) commandName 2) map of parameters,
and make that method return
Re: VM_HVM_REQUIRED - installing from ISO's
I've dumped the XAPI RPC commands on gist.github. The output is here: - VM.create, request : https://gist.github.com/snowch/9957504 - Async.VM.start_on, response : https://gist.github.com/snowch/9957480 The VM.create has some hvm_XXX options, should this be happening with xen.check.hvm set to false? Many thanks, Chris
Re: Converting QCOW2 to VHD
Hi Lucian, Yes you can and we've been hacking like that with systemvms [1]. Here's how you may do it using: - Packer: http://www.packer.io - Hack you own using vboxmanage, qemu, vhd-utils etc. and work on raw hdd image, checkout the code marked here: https://github.com/apache/cloudstack/blob/master/tools/appliance/build.sh#L80-L99 [1] https://github.com/apache/cloudstack/blob/master/tools/appliance/build.sh Hope this helps. On Thu, Apr 3, 2014 at 3:24 AM, Nux! n...@li.nux.ro wrote: Hello, I have used qemu-img to successfully convert a qcow2 image to vpc (vhd, these names give me head aches). I do have a problem with these converted images, XenServer complains that they were not created by itself and refuses to resize them for example. Can anyone advise if there is another way of converting qcow2 to vhd without having Xenserver complaining? Vhd-util binary is missing the convert functionality. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
RE: Review Request 19616: Added check for null return.
That's too much common sense for me to cope with.
Thanks for the tip!
-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: 03 April 2014 17:10
To: dev
Cc: Alex Hitchins; Edison Su; Laszlo Hornyak
Subject: Re: Review Request 19616: Added check for null return.
Prasanna made a nice remark about that; look at the annotations and/or git
log and see who did the most changes in the code you want to protect the
world against. Those are the people to address.
On Thu, Apr 3, 2014 at 6:06 PM, Alex Hitchins a...@alexhitchins.com wrote:
Thanks for looking Daan, I'm unsure sometimes who is best to add to
review certain projects/sections.
I will review your comments and look out for those of Edison/Laszlo.
My immediate concern was to stop the log saying it had succeeded when
it hadn't in fact succeeded.
Again, I'll review this and make amendments.
Alex Hitchins
-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: 03 April 2014 16:53
To: dev; Alex Hitchins; Edison Su; Laszlo Hornyak
Subject: Re: Review Request 19616: Added check for null return.
H Alex,
I had a quick look, keeping Laszlo's remark in mind.
volService.takeSnapshot(volume) catches all exceptions and then
returns null if any is caught. All calls are from tests or from
VolumeApiServieImpl so I think we can safely push the exeption handler
down and not return null from takeSnapshot. The only issue is that the
VolumeService interface should then throw it. (adding Edison in recip
list)
you want to do this:
throw new ResourceAllocationException(Take snapshot for VolumeId:
+ volumeId + failed., ResourceType.snapshot);
after calling
@Override
public SnapshotInfo takeSnapshot(VolumeInfo volume) {
SnapshotInfo snapshot = null;
try {
snapshot = snapshotMgr.takeSnapshot(volume);
} catch (Exception e) {
s_logger.debug(Take snapshot: + volume.getId() +
failed, e);
}
return snapshot;
}
the only Exception thrown in that method is a
ResourceAllocationException. I think it is better to let that one go
through or handle the error.
thoughts Laszlo, Edison?
If you want people to look at your review reqest you can add them to
the list of reviewers in revoew board.
Regards,
Daan
On Thu, Apr 3, 2014 at 2:24 PM, Alex Hitchins
alex.hitch...@shapeblue.com
wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19616/
---
(Updated April 3, 2014, 12:24 p.m.)
Review request for cloudstack.
Changes
---
Daan, are you able to take a look at this for me?
Repository: cloudstack-git
Description
---
Added check for returned null, if received then throw exception.
Diffs
-
server/src/com/cloud/storage/VolumeApiServiceImpl.java 5ffa99b
Diff: https://reviews.apache.org/r/19616/diff/
Testing
---
Compiled ran.
Thanks,
Alex Hitchins
--
Daan
--
Daan
Re: Converting QCOW2 to VHD
On 03.04.2014 17:43, Rohit Yadav wrote: Hi Lucian, Yes you can and we've been hacking like that with systemvms [1]. Here's how you may do it using: - Packer: http://www.packer.io - Hack you own using vboxmanage, qemu, vhd-utils etc. and work on raw hdd image, checkout the code marked here: https://github.com/apache/cloudstack/blob/master/tools/appliance/build.sh#L80-L99 [1] https://github.com/apache/cloudstack/blob/master/tools/appliance/build.sh Hope this helps. I think it does, thanks. I was hoping more for a miracle from vhd-util though, something nice and clean. I guess that would have to do. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
RE: ALARM - ACS reboots host servers!!!
This is a severe bug if that's the case. It's supposed to stop the heartbeat script when a primary storage is placed in maintenance. --Alex -Original Message- From: France [mailto:mailingli...@isg.si] Sent: Thursday, April 3, 2014 1:06 AM To: dev@cloudstack.apache.org Subject: Re: ALARM - ACS reboots host servers!!! I'm also interested in this issue. Can any1 from developers confirm this is expected behavior? On 2/4/14 2:32 PM, Andrei Mikhailovsky wrote: Coming back to this issue. This time to perform the maintenance of the nfs primary storage I've plated the storage in question in the Maintenance mode. After about 20 minutes ACS showed the nfs storage is in Maintenance. However, none of the virtual machines with volumes on that storage were stopped. I've manually stopped the virtual machines and went to upgrade and restart the nfs server. A few minutes after the nfs server shutdown all of my host servers went into reboot killing all vms! Thus, it seems that putting nfs server in Maintenance mode does not stop ACS agent from restarting the host servers. Does anyone know a way to stop this behaviour? Thanks Andrei - Original Message - From: France mailingli...@isg.si To: us...@cloudstack.apache.org Cc: dev@cloudstack.apache.org Sent: Monday, 3 March, 2014 9:49:28 AM Subject: Re: ALARM - ACS reboots host servers!!! I believe this is a bug too, because VMs not running on the storage, get destroyed too: Issue has been around for a long time, like with all others I reported. They do not get fixed: https://issues.apache.org/jira/browse/CLOUDSTACK-3367 We even lost assignee today. Regards, F. On 3/3/14 6:55 AM, Koushik Das wrote: The primary storage needs to be put in maintenance before doing any upgrade/reboot as mentioned in the previous mails. -Koushik On 03-Mar-2014, at 6:07 AM, Marcus shadow...@gmail.com wrote: Also, please note that in the bug you referenced it doesn't have a problem with the reboot being triggered, but with the fact that reboot never completes due to hanging NFS mount (which is why the reboot occurs, inaccessible primary storage). On Sun, Mar 2, 2014 at 5:26 PM, Marcus shadow...@gmail.com wrote: Or do you mean you have multiple primary storages and this one was not in use and put into maintenance? On Sun, Mar 2, 2014 at 5:25 PM, Marcus shadow...@gmail.com wrote: I'm not sure I understand. How do you expect to reboot your primary storage while vms are running? It sounds like the host is being fenced since it cannot contact the resources it depends on. On Sun, Mar 2, 2014 at 3:24 PM, Nux! n...@li.nux.ro wrote: On 02.03.2014 21:17, Andrei Mikhailovsky wrote: Hello guys, I've recently came across the bug CLOUDSTACK-5429 which has rebooted all of my host servers without properly shutting down the guest vms. I've simply upgraded and rebooted one of the nfs primary storage servers and a few minutes later, to my horror, i've found out that all of my host servers have been rebooted. Is it just me thinking so, or is this bug should be fixed ASAP and should be a blocker for any new ACS release. I mean not only does it cause downtime, but also possible data loss and server corruption. Hi Andrei, Do you have HA enabled and did you put that primary storage in maintenance mode before rebooting it? It's my understanding that ACS relies on the shared storage to perform HA so if the storage goes it's expected to go berserk. I've noticed similar behaviour in Xenserver pools without ACS. I'd imagine a cure for this would be to use network distributed filesystems like GlusterFS or CEPH. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: Converting QCOW2 to VHD
To add, I've this patched vhd-util that has convert. For some reason my apache login and the web dir including the vhd-util file is not accessible: people.apache.org/~bhaisaab/vhd-util-patched This is the google cache: http://webcache.googleusercontent.com/search?q=cache:vZPgSRlk9LwJ:people.apache.org/~bhaisaab/vhd-util-patched/+cd=1hl=enct=clnkgl=in Here is a link from my blog which can help you while working with vhds for xen: http://blogs.citrix.com/2012/10/04/convert-a-raw-image-to-xenserver-vhd/ Cheers. On Thu, Apr 3, 2014 at 10:13 PM, Rohit Yadav bhais...@apache.org wrote: Hi Lucian, Yes you can and we've been hacking like that with systemvms [1]. Here's how you may do it using: - Packer: http://www.packer.io - Hack you own using vboxmanage, qemu, vhd-utils etc. and work on raw hdd image, checkout the code marked here: https://github.com/apache/cloudstack/blob/master/tools/appliance/build.sh#L80-L99 [1] https://github.com/apache/cloudstack/blob/master/tools/appliance/build.sh Hope this helps. On Thu, Apr 3, 2014 at 3:24 AM, Nux! n...@li.nux.ro wrote: Hello, I have used qemu-img to successfully convert a qcow2 image to vpc (vhd, these names give me head aches). I do have a problem with these converted images, XenServer complains that they were not created by itself and refuses to resize them for example. Can anyone advise if there is another way of converting qcow2 to vhd without having Xenserver complaining? Vhd-util binary is missing the convert functionality. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Review Request 20007: CLOUDSTACK-2697 - Populated the clusterId with actual value instead of Null in the alert message logs
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20007/
---
Review request for cloudstack and prashant mishra.
Bugs: CLOUDSTACK-2697
https://issues.apache.org/jira/browse/CLOUDSTACK-2697
Repository: cloudstack-git
Description
---
CLOUDSTACK-2697 - cluster id in alert message is null {alertType:: 1 //
dataCenterId:: 1 // podId:: 1 // clusterId:: null }
The Cluster ID is getting populated as null in the logs for the alert messages.
In the code base the ClusterId has been hardcoded as null for the log messages.
I have modified to code to provide the actual cluster ID.
Diffs
-
server/src/com/cloud/alert/AlertManagerImpl.java 2a343d5
Diff: https://reviews.apache.org/r/20007/diff/
Testing
---
Tested on the 4.3 platform.
Thanks,
Girish Chaudhari
Re: [DISCUSS]{BEHAVIORAL-CHANGE]Domain-Account-User Sync Up Among Multiple Regions
Alex, please feel free to update Wiki docs related to the questions you got
Darren’s help from. I think this info would be useful for all CS committers.
Thank you,
Alena.
From: Alex Ough alex.o...@sungardas.commailto:alex.o...@sungardas.com
Date: Thursday, April 3, 2014 at 9:22 AM
To: Chiradeep Vittal
chiradeep.vit...@citrix.commailto:chiradeep.vit...@citrix.com, Alena
Prokharchyk
alena.prokharc...@citrix.commailto:alena.prokharc...@citrix.com, Darren
Shepherd darren.sheph...@citrix.commailto:darren.sheph...@citrix.com
Cc: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org
dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org
Subject: Re: [DISCUSS]{BEHAVIORAL-CHANGE]Domain-Account-User Sync Up Among
Multiple Regions
Forgot to mention this, but it was a great help from Darren.
Thanks again, Darren!
Alex Ough
On Thu, Apr 3, 2014 at 11:56 AM, Alex Ough
alex.o...@sungardas.commailto:alex.o...@sungardas.com wrote:
All,
I updated the patches as per Alena's request.
Let me know if there is anything missing/incorrect.
Thanks
Alex Ough
On Wed, Mar 26, 2014 at 1:40 PM, Alex Ough
alex.o...@sungard.commailto:alex.o...@sungard.com wrote:
Sorry, my bad. I mis-read your comment.
Thanks for pointing it out.
Alex Ough
On Wed, Mar 26, 2014 at 12:25 PM, Chiradeep Vittal
chiradeep.vit...@citrix.commailto:chiradeep.vit...@citrix.com wrote:
I didn’t say “do not use auto wiring”. I said the convention is to use @Inject
which you didn’t have.
From: Alena Prokharchyk
alena.prokharc...@citrix.commailto:alena.prokharc...@citrix.com
Date: Wednesday, March 26, 2014 at 7:39 AM
To: Alex Ough alex.o...@sungard.commailto:alex.o...@sungard.com,
dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org
dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org
Cc: Chiradeep Vittal
chiradeep.vit...@citrix.commailto:chiradeep.vit...@citrix.com
Subject: Re: [DISCUSS]{BEHAVIORAL-CHANGE]Domain-Account-User Sync Up Among
Multiple Regions
Alex, I’m attending a conference today, will review the patch tomorrow.
-Alena
From: Alex Ough alex.o...@sungard.commailto:alex.o...@sungard.com
Date: Wednesday, March 26, 2014 at 6:35 AM
To: Alena Prokharchyk
alena.prokharc...@citrix.commailto:alena.prokharc...@citrix.com
Cc: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org
dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org, Chiradeep Vittal
chiradeep.vit...@citrix.commailto:chiradeep.vit...@citrix.com
Subject: Re: [DISCUSS]{BEHAVIORAL-CHANGE]Domain-Account-User Sync Up Among
Multiple Regions
Alena,
It took a little time to update the patch because I had a vacation last week.
Now I uploaded the updated patch for review with below status, so please check
them and let me know what you think.
I hope it to be merged soon to wrap this up asap.
1. no change with waiting for comments on my recommendation.
2. The two things to turn on the sync-up among multiple regions is to change
the class name of eventNotificationBus into MultiRegionEventBus from
RabbitMQEventBus as below and change the value of 'region.full.scan.interval'
in Global Settings. And the new classes are never used unless the feature is
turned on, so I'm not sure if auto wiring is necessary here and Chiradeep asked
not to use @inject in his initial review, so I removed them.
bean id=eventNotificationBus
class=org.apache.cloudstack.mom.rabbitmq.MultiRegionEventBus
3. They are not adaptors, but inherited classes to process domain/account/user
objects separately.
4. Done
5. Same
6. I removed 'domain path' from AccountResponse UserResponse.
Thanks
Alex Ough
On Thu, Mar 13, 2014 at 9:48 PM, Alex Ough
alex.o...@sungard.commailto:alex.o...@sungard.com wrote:
What I think based on your comments are
1. Well, I have a different thought. I'd rather have separated classes instead
of having a class with lots of methods, which makes the maintenance easier. And
as you show as an example, it is possible to create a method and merge them,
but I think it is better to provide separate methods that are exposed outside
so that the callers can know what to call with ease.
2. Let me look at that.
3. I'm not sure why you think they are adapters, but let me look at that class.
4. OK, let me work on this.
5. The urls are stored in the region table along with username and password.
Please see 'RegionVO' under 'engine/schema/src/org/apache/cloudstack/region'.
Thanks
Alex Ough
On Thu, Mar 13, 2014 at 5:49 PM, Alena Prokharchyk
alena.prokharc...@citrix.commailto:alena.prokharc...@citrix.com wrote:
Alex,
There are so many classes, and it makes it hard to see/review the feature.
Can you come up with some sort of visual diagram, so its easier to see
which component is responsible for what task, and how they interact with
each other.
My suggestions:
1) I think it would make sense to merge all the classes doing utils tasks
(forming and sending Apis to CS) - UserInterface, AccountInterface,
DomainInterface - to a single util class.
Re: Review Request 16688: console-proxy add support of AltGr key and FR azerty keyboard
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16688/
---
(Updated April 3, 2014, 4:51 p.m.)
Review request for cloudstack.
Changes
---
I added the '' and '' char to the french keyboard for console proxy
Repository: cloudstack-git
Description
---
Firstly, I add a match condition 'altgr' for Conditional mapping entry in
ajaxviwer.js.
altgr : altgr state match condition, -- match on altgr state
It works like the shift match condition.
shift : shift state match condition, -- match on shift state
Browser can't detect difference between AltGr and Ctrl+Alt pressed at the same
time.
So when the modifier is 896, (Alt(512) + Ctrl(384)) I assume it is the AltGr
key and 'altgr' condition will be true.
In the ajaxkey.js file you got for example:
{type: KEY_DOWN, code: 0x32, modifiers: 0, altgr: true}
to send the spécified key to vnc if user pressed the AltGr (or Ctrl+Alt) key
Secondly,
I wrote the French AZERTY translation table in ajaxkeys.js with the support of
AltGr character (like #{}[]|,etc.)
For example the '#':
{keycode: 51, entry: [ //User type the 3# key and each condition match
'altgr'
{type: KEY_DOWN, code: 0xffea, modifiers: 0, altgr: true}, //press the VNC
AltGR key
{type: KEY_DOWN, code: 0x33, modifiers: 0, altgr: true}, //press the 3 key
{type: KEY_UP, code: 0x33, modifiers: 0, altgr: true}, //release it
{type: KEY_UP, code: 0xffea, modifiers: 0, altgr: true}//release the AltGr
key
]},
I replace the Standard (US) keyboard translation table because I can't add an
entry in the console proxy keyboard menu.
Thanks for watching my work
Axel Delahaye
Diffs (updated)
-
services/console-proxy/server/js/ajaxkeys.js abe6f13
Diff: https://reviews.apache.org/r/16688/diff/
Testing
---
Tested with
Hardware : French AZERTY keyboard
Software : Configured in windows as FR keyboard
Console-proxy : Customized Standard (US) keyboard
Guest : CentOS 6.5 , Debian 7 and FreeBSD 8
Guest keymap : fr, fr-pc
Only the key doesn't work
Thanks,
Axel Delahaye
RE: OVS plugin communication failure (CS 4.3.0)
Hi, Still struggling with this error. I have been trying to create a VM 3 times without success. Here is what I am seeing in the 2 logs mentioned. Any idea where to look next ? Supposing it is an OpenVSwitch issue, is there a specific log to look into ? xensource.log -- 2014-04-03 17:27:52DEBUG [root] VMOPS enter create_tunnel 2014-04-03 17:27:52DEBUG [root] Entering create_tunnel 2014-04-03 17:27:52DEBUG [root] Executing:['/usr/bin/ovs-vsctl', '--timeout=30', 'wait-until', 'bridge', 'xapi2', '--', 'get', 'bridge', 'xapi2', 'name'] 2014-04-03 17:28:22DEBUG [root] The command exited with the error code: -14 (stderr output:) ovstunnel.log - Apr 3 17:27:52 xenserver2 xapi: [debug|xenserver2|41227 INET 0.0.0.0:80|host.call_plugin R:526e3c11306f|audit] Host.call_plugin host = 'f90dbc43-030d-40f0-a61a-f69fc5b29b89 (xenserver2)'; plugin = 'ovstunnel'; fn = 'create_tunnel'; args = [ to: 5; remote_ip: 10.20.1.20; bridge: xapi2; from: 17; key: 263 ] ... Apr 3 17:28:22 xenserver2 xapi: [debug|xenserver2|41227 INET 0.0.0.0:80|host.call_plugin R:526e3c11306f|backtrace] Raised at xapi_plugins.ml:50.44-83 - message_forwarding.ml:233.25-44 - rbac.ml:229.16-23 Apr 3 17:28:22 xenserver2 xapi: [debug|xenserver2|41227 INET 0.0.0.0:80|host.call_plugin R:526e3c11306f|backtrace] Raised at rbac.ml:238.10-15 - server_helpers.ml:79.11-41 Apr 3 17:28:22 xenserver2 xapi: [debug|xenserver2|41227 INET 0.0.0.0:80|host.call_plugin R:526e3c11306f|dispatcher] Server_helpers.exec exception_handler: Got exception XENAPI_PLUGIN_FAILURE: [ create_tunnel; PluginError; ] Apr 3 17:28:22 xenserver2 xapi: [debug|xenserver2|41227 INET 0.0.0.0:80|host.call_plugin R:526e3c11306f|dispatcher] Raised at string.ml:150.25-34 - stringext.ml:108.13-29 Apr 3 17:28:22 xenserver2 xapi: [debug|xenserver2|41227 INET 0.0.0.0:80|host.call_plugin R:526e3c11306f|backtrace] Raised at string.ml:150.25-34 - stringext.ml:108.13-29 Apr 3 17:28:22 xenserver2 xapi: [debug|xenserver2|41227 INET 0.0.0.0:80|host.call_plugin R:526e3c11306f|xapi] Raised at server_helpers.ml:94.14-15 - pervasiveext.ml:22.2-9 Apr 3 17:28:22 xenserver2 xapi: [debug|xenserver2|41227 INET 0.0.0.0:80|host.call_plugin R:526e3c11306f|xapi] Raised at pervasiveext.ml:26.22-25 - pervasiveext.ml:22.2-9 Apr 3 17:28:22 xenserver2 xapi: [debug|xenserver2|41227 INET 0.0.0.0:80|dispatch:host.call_plugin D:b01ee1cbc1dc|xapi] Raised at pervasiveext.ml:26.22-25 - pervasiveext.ml:22.2-9 Thanks, Florin -Original Message- From: Murali Reddy [mailto:murali.re...@citrix.com] Sent: Tuesday, April 01, 2014 8:59 AM To: dev@cloudstack.apache.org Subject: Re: OVS plugin communication failure (CS 4.3.0) On 01/04/14 3:46 AM, Florin Dumitrascu florin.dumitra...@intunenetworks.com wrote: Hi, I am using CS 4.3.0 and XenServer 6.2.0 with SP1, on a GRE isolated network. The tunnel creation keeps failing intermittently with the error below (failure communicating with the plugin). Cloudstack management server can ping the xenserver reliably, there doesn't seem to be any issue at the IP level. Any idea what is causing this ? Do you see any relevant errors in /var/log/cloud/ovstunnel.log or /var/log/xensource.log Thanks 2014-03-31 23:08:56,528 WARN [c.c.h.x.r.CitrixResourceBase] (DirectAgent-265:ctx-3ca23292) Caught execption when creating ovs tunnel com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for cmd: create_tunnel with args to: 5, remote_ip: 10.20.1.20, from: 16, bridge: xapi4, key: 213, due to There was a failure communicating with the plugin. at com.cloud.hypervisor.xen.resource.CitrixResourceBase.callHostPlugin(Cit rix ResourceBase.java:4239) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixReso urc eBase.java:5685) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(Cit rix ResourceBase.java:567) at com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(Xe nSe rver56Resource.java:59) at com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(X enS erver610Resource.java:106) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgen tAt tache.java:216) Florin IMPORTANT NOTE: The information in this e-mail (and any attachments) is confidential. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient, please notify the sender immediately or telephone: +353 (0)1 6204700. We cannot accept any responsibility for the accuracy or completeness of this message as it has been transmitted over a public network. If you suspect that the message may have been intercepted or amended, please call the sender. IMPORTANT NOTE: The information in this e-mail (and any attachments) is confidential. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient,
Re: Converting QCOW2 to VHD
On 03.04.2014 17:48, Rohit Yadav wrote: To add, I've this patched vhd-util that has convert. For some reason my apache login and the web dir including the vhd-util file is not accessible: people.apache.org/~bhaisaab/vhd-util-patched This is the google cache: http://webcache.googleusercontent.com/search?q=cache:vZPgSRlk9LwJ:people.apache.org/~bhaisaab/vhd-util-patched/+cd=1hl=enct=clnkgl=in Here is a link from my blog which can help you while working with vhds for xen: http://blogs.citrix.com/2012/10/04/convert-a-raw-image-to-xenserver-vhd/ Thanks, I've seen that in the past. Was hoping something simpler happened in the meantime. :) -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: [DISCUSS]{BEHAVIORAL-CHANGE]Domain-Account-User Sync Up Among Multiple Regions
Well, I'm not sure about that because the help is about how to use @Inject
in the Spring framework.
On Thu, Apr 3, 2014 at 12:49 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Alex, please feel free to update Wiki docs related to the questions you
got Darren's help from. I think this info would be useful for all CS
committers.
Thank you,
Alena.
From: Alex Ough alex.o...@sungardas.com
Date: Thursday, April 3, 2014 at 9:22 AM
To: Chiradeep Vittal chiradeep.vit...@citrix.com, Alena Prokharchyk
alena.prokharc...@citrix.com, Darren Shepherd darren.sheph...@citrix.com
Cc: dev@cloudstack.apache.org dev@cloudstack.apache.org
Subject: Re: [DISCUSS]{BEHAVIORAL-CHANGE]Domain-Account-User Sync Up
Among Multiple Regions
Forgot to mention this, but it was a great help from Darren.
Thanks again, Darren!
Alex Ough
On Thu, Apr 3, 2014 at 11:56 AM, Alex Ough alex.o...@sungardas.comwrote:
All,
I updated the patches as per Alena's request.
Let me know if there is anything missing/incorrect.
Thanks
Alex Ough
On Wed, Mar 26, 2014 at 1:40 PM, Alex Ough alex.o...@sungard.com wrote:
Sorry, my bad. I mis-read your comment.
Thanks for pointing it out.
Alex Ough
On Wed, Mar 26, 2014 at 12:25 PM, Chiradeep Vittal
chiradeep.vit...@citrix.com wrote:
I didn't say do not use auto wiring. I said the convention is to
use @Inject which you didn't have.
From: Alena Prokharchyk alena.prokharc...@citrix.com
Date: Wednesday, March 26, 2014 at 7:39 AM
To: Alex Ough alex.o...@sungard.com, dev@cloudstack.apache.org
dev@cloudstack.apache.org
Cc: Chiradeep Vittal chiradeep.vit...@citrix.com
Subject: Re: [DISCUSS]{BEHAVIORAL-CHANGE]Domain-Account-User Sync Up
Among Multiple Regions
Alex, I'm attending a conference today, will review the patch
tomorrow.
-Alena
From: Alex Ough alex.o...@sungard.com
Date: Wednesday, March 26, 2014 at 6:35 AM
To: Alena Prokharchyk alena.prokharc...@citrix.com
Cc: dev@cloudstack.apache.org dev@cloudstack.apache.org, Chiradeep
Vittal chiradeep.vit...@citrix.com
Subject: Re: [DISCUSS]{BEHAVIORAL-CHANGE]Domain-Account-User Sync Up
Among Multiple Regions
Alena,
It took a little time to update the patch because I had a vacation
last week.
Now I uploaded the updated patch for review with below status, so
please check them and let me know what you think.
I hope it to be merged soon to wrap this up asap.
1. no change with waiting for comments on my recommendation.
2. The two things to turn on the sync-up among multiple regions is to
change the class name of eventNotificationBus into MultiRegionEventBus
from RabbitMQEventBus as below and change the value of
'region.full.scan.interval' in Global Settings. And the new classes are
never used unless the feature is turned on, so I'm not sure if auto wiring
is necessary here and Chiradeep asked not to use @inject in his initial
review, so I removed them.
bean id=eventNotificationBus
class=org.apache.cloudstack.mom.rabbitmq.MultiRegionEventBus
3. They are not adaptors, but inherited classes to process
domain/account/user objects separately.
4. Done
5. Same
6. I removed 'domain path' from AccountResponse UserResponse.
Thanks
Alex Ough
On Thu, Mar 13, 2014 at 9:48 PM, Alex Ough alex.o...@sungard.comwrote:
What I think based on your comments are
1. Well, I have a different thought. I'd rather have separated
classes instead of having a class with lots of methods, which makes the
maintenance easier. And as you show as an example, it is possible to
create
a method and merge them, but I think it is better to provide separate
methods that are exposed outside so that the callers can know what to call
with ease.
2. Let me look at that.
3. I'm not sure why you think they are adapters, but let me look at
that class.
4. OK, let me work on this.
5. The urls are stored in the region table along with username and
password. Please see 'RegionVO' under
'engine/schema/src/org/apache/cloudstack/region'.
Thanks
Alex Ough
On Thu, Mar 13, 2014 at 5:49 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Alex,
There are so many classes, and it makes it hard to see/review the
feature.
Can you come up with some sort of visual diagram, so its easier to see
which component is responsible for what task, and how they interact
with
each other.
My suggestions:
1) I think it would make sense to merge all the classes doing utils
tasks
(forming and sending Apis to CS) - UserInterface, AccountInterface,
DomainInterface - to a single util class. They do return generic types
anyway - JsonArray/JsonObject, and they do perform a generic util
task -
forming and sending the request to the CS. I would merge them all
with the
BaseInterface and name it with the name indicating that this class is
responsible for sending API calls against CS. And this would be your
util
class.
You should also come up with some
RE: GRE isolation - no in service upgrade (4.1.1 to 4.3.0) - Is your zone an Advanced zone or Basic zone? (2)
Hi, I have taken the following steps from Cloudmonkey, as a workaround: # List physical networks to get the id of the GRE isolated network: cloudmonkey list physicalnetworks # Add Ovs network service provider to the GRE isolated network: cloudmonkey add networkserviceprovider name=Ovs destinationphysicalnetworkid=the_network_id_discovered_in_previos_step (there will be an id associated with the provider, suppose this is b2f02334-e4c6-45b8-87c3-e96a7301b5ca) # Enable the provider: cloudmonkey update networkserviceprovider id=b2f02334-e4c6-45b8-87c3-e96a7301b5ca state=Enabled I will add this in the bug comments as well. Regards, Florin -Original Message- From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] Sent: Wednesday, April 02, 2014 5:46 PM To: dev@cloudstack.apache.org; Jessica Wang; Murali Reddy; Florin Dumitrascu Cc: Nguyen Anh Tu (t...@apache.org) Subject: Re: GRE isolation - no in service upgrade (4.1.1 to 4.3.0) - Is your zone an Advanced zone or Basic zone? (2) Oh, yea, I've mistaken it for some other bug - when new hypervisor wasn't inserted to the global config variable. Florin, can you please provide the db upgrade statements you've executed to fix the problem, for the reference? In case other people are blocked by the same bug. Thanks! Alena. On 4/2/14, 2:48 AM, Florin Dumitrascu florin.dumitra...@intunenetworks.com wrote: Hi Alena, I think you have mistaken this with something else :) The bug I have raised below (CLOUDSTACK-6320) is for OVS. OVS network provider was introduced in 4.3.0 and when upgrading from older versions it should be inserted in the existing physical networks. To make it work I had to manually create the provider and enable it from Cloudmonkey interface. But this should be part of the DB upgrade somehow. Florin -Original Message- From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] Sent: Tuesday, April 01, 2014 5:46 PM To: dev@cloudstack.apache.org; Jessica Wang; Murali Reddy Cc: Nguyen Anh Tu (t...@apache.org) Subject: Re: GRE isolation - no in service upgrade (4.1.1 to 4.3.0) - Is your zone an Advanced zone or Basic zone? (2) Florin, you must have fixed it already on your side, but for other people information: to fix the problem, update cloud.configuration table by modifying the value for hypervisor.list parameter On 4/1/14, 9:42 AM, Florin Dumitrascu florin.dumitra...@intunenetworks.com wrote: Raised a bug for the DB upgrade: https://issues.apache.org/jira/browse/CLOUDSTACK-6320 Regards, Florin -Original Message- From: Jessica Wang [mailto:jessica.w...@citrix.com] Sent: Friday, March 21, 2014 11:19 PM To: Alena Prokharchyk; Florin Dumitrascu; Murali Reddy Cc: Nguyen Anh Tu (t...@apache.org); dev@cloudstack.apache.org Subject: RE: GRE isolation - no in service upgrade (4.1.1 to 4.3.0) - Is your zone an Advanced zone or Basic zone? (2) +1 -Original Message- From: Alena Prokharchyk Sent: Friday, March 21, 2014 4:18 PM To: Jessica Wang; Florin Dumitrascu; Murali Reddy Cc: Nguyen Anh Tu (t...@apache.org); dev@cloudstack.apache.org Subject: Re: GRE isolation - no in service upgrade (4.1.1 to 4.3.0) - Is your zone an Advanced zone or Basic zone? (2) Then its a DB upgrade bug. If the GRE isolation is supported on the network in 4.1.1, DB upgrade should have inserted the provider to physical network. On 3/21/14, 3:51 PM, Jessica Wang jessica.w...@citrix.com wrote: [Alena] Not exactly like that. [Alena] None of the providers are added to the physical network by default if execute createPhysicalNetwork call via API. [Alena] Our CS UI does this job - adding the providers to the network - for you by calling addNetworkServiceProvider call. Actually, OVS provider is an exception. UI doesn't do the job because server-side already does the job. When you create an Advanced zone in 4.3 code, server-side will automatically add OVS provider to its physical network. However, since your zone was created in 4.1 code and upgraded to 4.3, server-side won't automatically add OVS provider to its physical network. Murali, please confirm. -Original Message- From: Alena Prokharchyk Sent: Friday, March 21, 2014 2:44 PM To: Florin Dumitrascu; Jessica Wang; Murali Reddy; Florin Dumitrascu Cc: Nguyen Anh Tu (t...@apache.org); dev@cloudstack.apache.org Subject: Re: GRE isolation - no in service upgrade (4.1.1 to 4.3.0) - Is your zone an Advanced zone or Basic zone? (2) On 3/21/14, 2:34 PM, Florin Dumitrascu florin.dumitra...@intunenetworks.com wrote: Hi, Alena, my assumption is that the Ovs provider is created when you create the physical network with GRE isolation (if someone can confirm ...). When I configured CS RC8 from scratch, I could see the provider and enable it in the GUI. Not exactly like that. None of the providers are added to the physical network by default if execute createPhysicalNetwork call via API. Our CS UI does this job - adding the providers to the network - for you by
Re: [ANNOUNCE] Better XenServer support in 4.4....
On Thu, Apr 3, 2014 at 3:59 AM, Konstantina Chremmou konstantina.chrem...@citrix.com wrote: -Original Message- From: Alex Huang [mailto:alex.hu...@citrix.com] Sent: 02 April 2014 10:46 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Better XenServer support in 4.4 I've talked about this all the way back when we were in Amsterdam and now it's finally done. Tina (Konstantina Chremmou) checked in a patch that removes CloudStack's own copy of XenServerJava source code and submitted a copy of the xen-api.jar into the maven repository. Since xen- api.jar is backwards compatible with previous versions of XenServer, only one copy of such jar is needed. For those of you not familiar with this, CloudStack keeps its own copy of three files that really belongs to XenServer: - xen-api.jar: CloudStack modified the source code to add a client side timeout to fault isolate CloudStack from XenServer if the XenServer control layer runs into trouble. - vhd-util: The copy of vhd-util shipped with XenServer is old and does not provide the functionality to change the parent id of the vhd file. - NFSSR.py: XenServer's copy always creates a subdirectory and utilize that subdirectory for its vm images. CloudStack needed one that doesn't create a subdirectory. With the release of hot fix XS62ESP1004, XenSever has incorporated all of CloudStack's changes for the three files. Unfortunately, these changes are not back-ported to previous versions so CloudStack will only utilize the new changes against XenSever 6.2 + SP1 + XS62ESP1004. There is a new resource, XenServer625Resource.java, that was added in 4.3 to work with this exact XenServer patch level. Unfortunately, the xen-api.jar couldn't make it in time for the 4.3 release so we still had to keep our own copy of the source code in 4.3. We could still change it for 4.3-forward though. I've submitted for consideration a patch for that branch too. Doesn't sound like a bug fix, so probably not appropriate for 4.3-forward. As an aside, we need to make sure LICENSE gets updated.
Re: how to keep the world from ending
Uh... sorry. Autocomplete FTL. This was supposed to be to our internal team. On 04/03/2014 10:59 AM, Marcus Sorensen wrote: For those who missed the info yesterday. This is mostly for developers. * Commit your changes every day * Push to production daily * Test what you pushed to production, IN production (not staging) * Don't ever say something is done (or works), then come back and say oh, I just needed to push this thing. It's done when you tested in production. signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] Better XenServer support in 4.4....
On Thu, Apr 3, 2014 at 1:28 PM, David Nalley da...@gnsa.us wrote: On Thu, Apr 3, 2014 at 3:59 AM, Konstantina Chremmou konstantina.chrem...@citrix.com wrote: -Original Message- From: Alex Huang [mailto:alex.hu...@citrix.com] Sent: 02 April 2014 10:46 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Better XenServer support in 4.4 I've talked about this all the way back when we were in Amsterdam and now it's finally done. Tina (Konstantina Chremmou) checked in a patch that removes CloudStack's own copy of XenServerJava source code and submitted a copy of the xen-api.jar into the maven repository. Since xen- api.jar is backwards compatible with previous versions of XenServer, only one copy of such jar is needed. For those of you not familiar with this, CloudStack keeps its own copy of three files that really belongs to XenServer: - xen-api.jar: CloudStack modified the source code to add a client side timeout to fault isolate CloudStack from XenServer if the XenServer control layer runs into trouble. - vhd-util: The copy of vhd-util shipped with XenServer is old and does not provide the functionality to change the parent id of the vhd file. - NFSSR.py: XenServer's copy always creates a subdirectory and utilize that subdirectory for its vm images. CloudStack needed one that doesn't create a subdirectory. With the release of hot fix XS62ESP1004, XenSever has incorporated all of CloudStack's changes for the three files. Unfortunately, these changes are not back-ported to previous versions so CloudStack will only utilize the new changes against XenSever 6.2 + SP1 + XS62ESP1004. There is a new resource, XenServer625Resource.java, that was added in 4.3 to work with this exact XenServer patch level. Unfortunately, the xen-api.jar couldn't make it in time for the 4.3 release so we still had to keep our own copy of the source code in 4.3. We could still change it for 4.3-forward though. I've submitted for consideration a patch for that branch too. Doesn't sound like a bug fix, so probably not appropriate for 4.3-forward. As an aside, we need to make sure LICENSE gets updated. I have a patch for this, and will push as soon as the LDAP issues are resolved. --David
Re: how to keep the world from ending
I thought you were advocating CD (Yay!) and then the 'push to production' seemed out of place. --David On Thu, Apr 3, 2014 at 1:23 PM, Marcus Sorensen mar...@betterservers.com wrote: Uh... sorry. Autocomplete FTL. This was supposed to be to our internal team. On 04/03/2014 10:59 AM, Marcus Sorensen wrote: For those who missed the info yesterday. This is mostly for developers. * Commit your changes every day * Push to production daily * Test what you pushed to production, IN production (not staging) * Don't ever say something is done (or works), then come back and say oh, I just needed to push this thing. It's done when you tested in production.
Re: how to keep the world from ending
Yeah, we're going through this... thing. Sorry for the noise. On Thu, Apr 3, 2014 at 11:37 AM, David Nalley da...@gnsa.us wrote: I thought you were advocating CD (Yay!) and then the 'push to production' seemed out of place. --David On Thu, Apr 3, 2014 at 1:23 PM, Marcus Sorensen mar...@betterservers.com wrote: Uh... sorry. Autocomplete FTL. This was supposed to be to our internal team. On 04/03/2014 10:59 AM, Marcus Sorensen wrote: For those who missed the info yesterday. This is mostly for developers. * Commit your changes every day * Push to production daily * Test what you pushed to production, IN production (not staging) * Don't ever say something is done (or works), then come back and say oh, I just needed to push this thing. It's done when you tested in production.
Re: ALARM - ACS reboots host servers!!!
I am on KVM. thanks - Original Message - From: France mailingli...@isg.si To: dev@cloudstack.apache.org Sent: Thursday, 3 April, 2014 2:34:53 PM Subject: Re: ALARM - ACS reboots host servers!!! Andrei, is your hypervisor KVM? I'm using XenServer.
Re: ALARM - ACS reboots host servers!!!
+1 - Original Message - From: Alex Huang alex.hu...@citrix.com To: dev@cloudstack.apache.org Sent: Thursday, 3 April, 2014 6:47:22 PM Subject: RE: ALARM - ACS reboots host servers!!! This is a severe bug if that's the case. It's supposed to stop the heartbeat script when a primary storage is placed in maintenance. --Alex -Original Message- From: France [mailto:mailingli...@isg.si] Sent: Thursday, April 3, 2014 1:06 AM To: dev@cloudstack.apache.org Subject: Re: ALARM - ACS reboots host servers!!! I'm also interested in this issue. Can any1 from developers confirm this is expected behavior? On 2/4/14 2:32 PM, Andrei Mikhailovsky wrote: Coming back to this issue. This time to perform the maintenance of the nfs primary storage I've plated the storage in question in the Maintenance mode. After about 20 minutes ACS showed the nfs storage is in Maintenance. However, none of the virtual machines with volumes on that storage were stopped. I've manually stopped the virtual machines and went to upgrade and restart the nfs server. A few minutes after the nfs server shutdown all of my host servers went into reboot killing all vms! Thus, it seems that putting nfs server in Maintenance mode does not stop ACS agent from restarting the host servers. Does anyone know a way to stop this behaviour? Thanks Andrei - Original Message - From: France mailingli...@isg.si To: us...@cloudstack.apache.org Cc: dev@cloudstack.apache.org Sent: Monday, 3 March, 2014 9:49:28 AM Subject: Re: ALARM - ACS reboots host servers!!! I believe this is a bug too, because VMs not running on the storage, get destroyed too: Issue has been around for a long time, like with all others I reported. They do not get fixed: https://issues.apache.org/jira/browse/CLOUDSTACK-3367 We even lost assignee today. Regards, F. On 3/3/14 6:55 AM, Koushik Das wrote: The primary storage needs to be put in maintenance before doing any upgrade/reboot as mentioned in the previous mails. -Koushik On 03-Mar-2014, at 6:07 AM, Marcus shadow...@gmail.com wrote: Also, please note that in the bug you referenced it doesn't have a problem with the reboot being triggered, but with the fact that reboot never completes due to hanging NFS mount (which is why the reboot occurs, inaccessible primary storage). On Sun, Mar 2, 2014 at 5:26 PM, Marcus shadow...@gmail.com wrote: Or do you mean you have multiple primary storages and this one was not in use and put into maintenance? On Sun, Mar 2, 2014 at 5:25 PM, Marcus shadow...@gmail.com wrote: I'm not sure I understand. How do you expect to reboot your primary storage while vms are running? It sounds like the host is being fenced since it cannot contact the resources it depends on. On Sun, Mar 2, 2014 at 3:24 PM, Nux! n...@li.nux.ro wrote: On 02.03.2014 21:17, Andrei Mikhailovsky wrote: Hello guys, I've recently came across the bug CLOUDSTACK-5429 which has rebooted all of my host servers without properly shutting down the guest vms. I've simply upgraded and rebooted one of the nfs primary storage servers and a few minutes later, to my horror, i've found out that all of my host servers have been rebooted. Is it just me thinking so, or is this bug should be fixed ASAP and should be a blocker for any new ACS release. I mean not only does it cause downtime, but also possible data loss and server corruption. Hi Andrei, Do you have HA enabled and did you put that primary storage in maintenance mode before rebooting it? It's my understanding that ACS relies on the shared storage to perform HA so if the storage goes it's expected to go berserk. I've noticed similar behaviour in Xenserver pools without ACS. I'd imagine a cure for this would be to use network distributed filesystems like GlusterFS or CEPH. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Enabling VMware Support
I was trying to bring up VMware Hypervisor, for the first time, mostly worked with XenServer in the past. I have mostly 5.1 and 5.5 systems. I looked at the Wiki: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Hypervisor+VMWare Is this wiki still current? It is referencing the 4.1 SDK files to download from VMware site and supported versions is 4.1 and 5.0. -Soheil
RE: Enabling VMware Support
You need to use the vsphere 5.1 SDK to build the nonoss From: seiz...@infoblox.com To: dev@cloudstack.apache.org Subject: Enabling VMware Support Date: Thu, 3 Apr 2014 21:15:15 + I was trying to bring up VMware Hypervisor, for the first time, mostly worked with XenServer in the past. I have mostly 5.1 and 5.5 systems. I looked at the Wiki: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Hypervisor+VMWare Is this wiki still current? It is referencing the 4.1 SDK files to download from VMware site and supported versions is 4.1 and 5.0. -Soheil
Re: Review Request 17790: Domain-Account-User Sync Up Among Multiple Regions
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17790/#review39482
---
Alex, all the fixes from the previous review, were done, thank you. But there
are some more to address:
1) Minor: Its a good practice shutdownNow() for your executors as a part of the
server shutdownHook
Take for example:
FullSyncer.java
You have an _executor there; you have to call shutdownNow for it as a part of
stop() method. You can refer to ClusteredAgentManagerImpl for the example
2) Replace all of the hardcoded values like account/domainId you are
getting when parse API requests from CS, with the references to ApiConstants.
3) Replace generic Exception for not implemented cases in places like below,
with CS UnsupportedException:
public JSONObject deleteAccountFromProject() throws Exception {
158
throw new Exception(Not implemented);
159
}
4) :) Use StringBuilder for String concatination (BaseInterface.java, and may
be some other classes)
if (paramStr != null !paramStr.equals())
98
connUrl += ? + paramStr;
5) Rename BaseInterface.java, its not an interface. Rename is with some name
meaningful to your component.
Same for DomainInterface/AccountInterface. all the classes that are not
interfaces.
6) Back to StringBuilder. Replace
StringBuilder param = new StringBuilder(command=createDomainname= + name +
response=jsonsessionkey= + encodeSessionKey());
if (parentDomainId != null) param.append(parentdomainid= + parentDomainId);
with
StringBuilder param = new
StringBuilder(command=createDomainname=).append(name).append(response=jsonsessionkey=).append(encodeSessionKey());
if (parentDomainId != null)
param.append(parentdomainid=).append(parentDomainId);
Just search for all + occurance for your string, and put a replacement
7) My suggestion for you would be: build your commands in generic manner. For
example, create some helper method with the signature:
buildCommand(String commandName, MapString, String parameters) {
StringBuilder param = new
StringBuilder(command=).append(commandName).append(response=jsonsessionkey=).append(encodeSessionKey());
...
go through parameters list to form the request
}
8) Whenever possible, try to use interface instead of VO class. For example,
Account vs AccountVO. Only if Account misses some fiels that you need, use
AccountVO.
9) AccountFullSyncProcesser. What is the reason for the code swallowing a
generic exception like this? Its not a good practice
for (int idx = 0; idx remoteArray.length(); idx++) {
93
try {
94
remoteList.add(remoteArray.getJSONObject(idx));
95
} catch (Exception ex) {
96
97
}
98
}
10) AccountFullSync
catch (Exception ex) {
118
s_logger.error(Failed to synchronize accounts : +
ex.getMessage());
119
}
exception is logged incorrectly, should be logged like:
s_logger.error(Failed to synchronize accounts : , ex;
I've seen the similar in other places; please replace everywhere
11) On Exceptions. I can see that you throw generic Exception everywhere. Try
to replace them with more specific exceptions reflecting reason for the
failure. Look at CS existing exceptions -
PermissionDeniedException,InvalidParameterValueException/CloudRuntimeException,
and try to utilize them.
12) Please compare accountNames (and other string values) in case insensitive
manner. Use equalsignorecase instead of equals
- Alena Prokharchyk
On April 3, 2014, 3:54 p.m., Alex Ough wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17790/
---
(Updated April 3, 2014, 3:54 p.m.)
Review request for cloudstack.
Repository: cloudstack-git
Description
---
Currently, under the environment of cloudstack with multiple regions, each
region has its own management server running with a separate database, which
will cause data discrepancies when users create/update/delete
domain/account/user data independently in each management server. So to
support multiple regions and provide one point of entry for each customer,
this implementation duplicates domain/account/user information of customers
in one region to all of the regions independently whenever there is any
change.
https://issues.apache.org/jira/browse/CLOUDSTACK-4992
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain-Account-User+Sync+Up+Among+Multiple+Regions
Diffs
-
plugins/event-bus/multiregion/pom.xml PRE-CREATION
plugins/event-bus/multiregion/resources/META-INF/cloudstack/spring-mom-multiregion-daos-context.xml
PRE-CREATION
Re: Review Request 16688: console-proxy add support of AltGr key and FR azerty keyboard
Axel, did you change this already submitted change request? Or did you
reuse the entry in the review boar to create a new review request? In both
cases I'd rather have you close this one and create a new one.
On Thu, Apr 3, 2014 at 6:51 PM, Axel Delahaye
axel.delah...@worldline.comwrote:
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16688/
Review request for cloudstack.
By Axel Delahaye.
*Updated April 3, 2014, 4:51 p.m.*
Changes
I added the '' and '' char to the french keyboard for console proxy
*Repository: * cloudstack-git
Description
Firstly, I add a match condition 'altgr' for Conditional mapping entry in
ajaxviwer.js.
altgr : altgr state match condition, -- match on altgr state
It works like the shift match condition.
shift : shift state match condition, -- match on shift state
Browser can't detect difference between AltGr and Ctrl+Alt pressed at the
same time.
So when the modifier is 896, (Alt(512) + Ctrl(384)) I assume it is the AltGr
key and 'altgr' condition will be true.
In the ajaxkey.js file you got for example:
{type: KEY_DOWN, code: 0x32, modifiers: 0, altgr: true}
to send the spécified key to vnc if user pressed the AltGr (or Ctrl+Alt) key
Secondly,
I wrote the French AZERTY translation table in ajaxkeys.js with the support
of AltGr character (like #{}[]|,etc.)
For example the '#':
{keycode: 51, entry: [ //User type the 3# key and each condition
match 'altgr'
{type: KEY_DOWN, code: 0xffea, modifiers: 0, altgr: true}, //press the VNC
AltGR key
{type: KEY_DOWN, code: 0x33, modifiers: 0, altgr: true}, //press the 3 key
{type: KEY_UP, code: 0x33, modifiers: 0, altgr: true}, //release it
{type: KEY_UP, code: 0xffea, modifiers: 0, altgr: true}//release the
AltGr key
]},
I replace the Standard (US) keyboard translation table because I can't add an
entry in the console proxy keyboard menu.
Thanks for watching my work
Axel Delahaye
Testing
Tested with
Hardware : French AZERTY keyboard
Software : Configured in windows as FR keyboard
Console-proxy : Customized Standard (US) keyboard
Guest : CentOS 6.5 , Debian 7 and FreeBSD 8
Guest keymap : fr, fr-pc
Only the key doesn't work
Diffs (updated)
- services/console-proxy/server/js/ajaxkeys.js (abe6f13)
View Diff https://reviews.apache.org/r/16688/diff/
--
Daan
Re: Unable to deploy systemvms
Hi，as you defined the STORAGE network, the SSVM need access NFSserver through storage network ,just as Pierre-Luc Dion said there maybe vlan rag or namelable play the trick ,so you can check whether the compute node with xen can manualy mount the nfs mount point through xenbr1 On Apr 2, 2014 8:55 PM, Tejas Gadaria refond.g...@gmail.com wrote: Hi Yitao, xenbr0 : acting as Management network and no VLAN is assigned to it xenbr1 : acting as public, guest storage network. All of this are in same VLAN. Also I have given same name-label as here in Cloudstack network configuraion. I don't know much about xen VLAN networking..if anything wrong please point it out. [root@xen-dev ~]# xe network-list uuid ( RO): bfb89346-9eae-4554-a46a-59f9b4587983 name-label ( RW): cloud_link_local_network name-description ( RW): link local network used by system vms bridge ( RO): xapi0 uuid ( RO): eeb9fb94-7468-6b78-aaae-8d4e84b48afd name-label ( RW): Host internal management network name-description ( RW): Network on which guests will be assigned a private link-local IP address which can be used to talk XenAPI bridge ( RO): xenapi uuid ( RO): 90f6f78a-d4d8-463a-ccca-e28f7ea4e7d2 name-label ( RW): cloud-manage name-description ( RW): bridge ( RO): xenbr0 uuid ( RO): 88f0843e-feb9-44d0-5a04-06f32a258b81 name-label ( RW): cloud-public name-description ( RW): bridge ( RO): xenbr1 Regards, Tejas On Wed, Apr 2, 2014 at 5:42 PM, Yitao Jiang willier...@gmail.com wrote: Can you post your network configuration here, and do u able make operation on xenseever through xencenter? May be something wrong with ur storage On Apr 2, 2014 6:47 PM, Tejas Gadaria refond.g...@gmail.com wrote: Hi Punith, Thanks for reply, I have already uploaded systemvm64template-2014-01-14-master-xen.vhd.bz2 in secondary . [root@con-xen ~]# ls -lR /vol/ /vol/: total 8 drwxr-xr-x 2 root root 4096 Apr 2 12:46 primary drwxr-xr-x 3 root root 4096 Apr 2 12:14 secondary /vol/primary: total 4 -rw-r--r-- 1 root root 11 Apr 2 16:03 hb-ecff5b59-a2bc-4c0c-9ec8-05f7b4cda546 /vol/secondary: total 4 drwxr-xr-x 3 root root 4096 Apr 2 12:14 template /vol/secondary/template: total 4 drwxr-xr-x 3 root root 4096 Apr 2 12:14 tmpl /vol/secondary/template/tmpl: total 4 drwxr-xr-x 3 root root 4096 Apr 2 12:14 1 /vol/secondary/template/tmpl/1: total 4 drwxr-xr-x 2 root root 4096 Apr 2 12:26 1 /vol/secondary/template/tmpl/1/1: total 2565016 -rw-r--r-- 1 root root 2626564608 Apr 2 12:19 041bb2b7-2c84-4a72-a2bb-573d6c1ba56e.vhd -rw-r--r-- 1 root root287 Apr 2 12:26 template.properties Regards, Tejas On Wed, Apr 2, 2014 at 3:59 PM, Punith S punit...@cloudbyte.com wrote: hi, check whether you have seeded the vdh util for sysytem vms in secondary storage. http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/latest/installation.html#prepare-the-system-vm-template thanks. On Wed, Apr 2, 2014 at 3:54 PM, Tejas Gadaria refond.g...@gmail.com wrote: Hi, I am trying to create system vms, in CS 4.3 with Xenserver 6.2 I am trying to create advance zone. I have 2nics. 1 for management network second is trunk. I am getting below error 2014-04-02 15:18:28,827 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl] (consoleproxy-1:ctx-774da64a) template 1 is already in store:1, type:Image 2014-04-02 15:18:28,831 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl] (consoleproxy-1:ctx-774da64a) template 1 is already in store:1, type:Primary 2014-04-02 15:18:28,832 DEBUG [o.a.c.s.v.VolumeServiceImpl] (consoleproxy-1:ctx-774da64a) Found template routing-1 in storage pool 1 with VMTemplateStoragePool id: 4 2014-04-02 15:18:28,840 DEBUG [o.a.c.s.v.VolumeServiceImpl] (consoleproxy-1:ctx-774da64a) Acquire lock on VMTemplateStoragePool 4 with timeout 3600 seconds 2014-04-02 15:18:30,903 WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-111:ctx-f68bde71) destoryVDIbyNameLabel failed due to there are 0 VDIs with name cloud-cff5e443-72df-4aae-a4fd-1278fc0cbeb4 2014-04-02 15:18:30,903 WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-111:ctx-f68bde71) can not create vdi in sr d2bf95cc-8761-c31d-37a5-173304cc621e 2014-04-02 15:18:30,904 WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-111:ctx-f68bde71) Catch Exception com.cloud.utils.exception.CloudRuntimeException for template + due to com.cloud.utils.exception.CloudRuntimeException: can not create vdi in sr
RE: Interesting 4.2.1. Issue...
I've put tomcat 6.0.33 on our mgmt servers. I'm going to monitor it for the next few days to see if we get the error again. Do you know any way way to verify the version of tomcat that's running? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Thu, 3 Apr 2014 10:35:29 +0800 No we didn't, it wouldn't matter because the memory would still fill up, the problem is it opens a thread and it fails to close it so whatever you will increase soon or later the memory will fill up (if I understand right) The error in catalina is as follows: SEVERE: The web application [/client] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@1bd66d2d]) and a value of type [com.cloud.api.SerializationContext] (value [com.cloud.api.SerializationContext@2f6baed9]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. If someone could help with this error generated in the catalina log, that would be much appreicated. Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, 3 April 2014 9:34 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... A few other articles also mention setting the initial heap size -Xms to the same value as the heap size, to go ahead and fully commit the heap. Have you tried that? One other thing I am curious of is have you fiddled with the Perm Size XX:Permsize setting? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Thu, 3 Apr 2014 09:26:31 +0800 Believe or not!! We have tried setting them in both formats and still the catalina log produces java heap space error Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, 3 April 2014 9:24 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... This may be a silly question, but in all of the docs I am reading online in regards to increasing the java heap size, they are specifying it as -XmxsizeMB example -Xmx2048m vs -Xmx2g Is it possible that it's not reading the 2g variable as 2GB? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Thu, 3 Apr 2014 09:06:17 +0800 It is 6.0.35 and it still produces this error, even after increasing the Xmx to 4g, we have installed tomcat 6.0.33 and each time we install the cloudstack it does not sense the installed 6.0.33 and attempts to install 6.0.35 as it is dependent on it. Silly solution is that we scheduled a daily restart @ 2PM through a cron job But first you have to killall jvsc then restart the management server. What we are considering is to migrate the management server to CentOS 6.5 it comes with tomcat 6.0.24 and mysql 5.1, we attempted to restore the dump on a pilot environment and it worked. If someone else has a better solution than this would you please share it? Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, 3 April 2014 5:31 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... So I just checked my tomcat version and we are running 6.0.35 which must be the default that comes with Ubuntu 12.04 out of the box. Our memory settings are as follows: JAVA_OPTS=-Djava.awt.headless=true -Dcom.sun.management.jmxremote.port=45219 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Xmx4g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M -XX:MaxPermSize=800m So what version of tomcat are you running 6.0.35 or 6.0.33? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Tue, 1 Apr 2014 11:23:57 +0800 We have the same issue, after an upgrade from 2.2.14 to 4.2.1, and during this upgrade we had upgrade from Ubuntu 10 LTS to Ubuntu 12 LTS, it seems it related to tomcat 6.0.35, because it is recommended to have tomcat 6.0.33 which doesn't come by default with Ubuntu 12.04.4 Kind Regards Amin -Original Message- From: Marcus [mailto:shadow...@gmail.com] Sent: Tuesday, 1 April 2014 6:22 AM To: dev@cloudstack.apache.org Subject: Re: Interesting 4.2.1. Issue... I'm running 3 mgmt servers on 4.2.1, haven't seen any issues like that. You can send along your memory settings... here's what I'm running: JAVA_OPTS=-Djava.awt.headless=true -Dcom.sun.management.jmxremote.port=45219
RE: Interesting 4.2.1. Issue...
cd /usr/share/tomcat6/bin/ ./version.sh The output should be 6.0.33 instead of 6.0.35 Using CATALINA_BASE: /usr/share/tomcat6 Using CATALINA_HOME: /usr/share/tomcat6 Using CATALINA_TMPDIR: /usr/share/tomcat6/temp Using JRE_HOME:/usr Using CLASSPATH: /usr/share/tomcat6/bin/bootstrap.jar Server version: Apache Tomcat/6.0.35 Server built: Server number: 6.0.35.0 OS Name:Linux OS Version: 3.11.0-18-generic Architecture: amd64 JVM Version:1.6.0_30-b30 JVM Vendor: Sun Microsystems Inc. Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Friday, 4 April 2014 10:31 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... I've put tomcat 6.0.33 on our mgmt servers. I'm going to monitor it for the next few days to see if we get the error again. Do you know any way way to verify the version of tomcat that's running? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Thu, 3 Apr 2014 10:35:29 +0800 No we didn't, it wouldn't matter because the memory would still fill up, the problem is it opens a thread and it fails to close it so whatever you will increase soon or later the memory will fill up (if I understand right) The error in catalina is as follows: SEVERE: The web application [/client] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@1bd66d2d]) and a value of type [com.cloud.api.SerializationContext] (value [com.cloud.api.SerializationContext@2f6baed9]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. If someone could help with this error generated in the catalina log, that would be much appreicated. Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, 3 April 2014 9:34 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... A few other articles also mention setting the initial heap size -Xms to the same value as the heap size, to go ahead and fully commit the heap. Have you tried that? One other thing I am curious of is have you fiddled with the Perm Size XX:Permsize setting? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Thu, 3 Apr 2014 09:26:31 +0800 Believe or not!! We have tried setting them in both formats and still the catalina log produces java heap space error Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, 3 April 2014 9:24 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... This may be a silly question, but in all of the docs I am reading online in regards to increasing the java heap size, they are specifying it as -XmxsizeMB example -Xmx2048m vs -Xmx2g Is it possible that it's not reading the 2g variable as 2GB? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Thu, 3 Apr 2014 09:06:17 +0800 It is 6.0.35 and it still produces this error, even after increasing the Xmx to 4g, we have installed tomcat 6.0.33 and each time we install the cloudstack it does not sense the installed 6.0.33 and attempts to install 6.0.35 as it is dependent on it. Silly solution is that we scheduled a daily restart @ 2PM through a cron job But first you have to killall jvsc then restart the management server. What we are considering is to migrate the management server to CentOS 6.5 it comes with tomcat 6.0.24 and mysql 5.1, we attempted to restore the dump on a pilot environment and it worked. If someone else has a better solution than this would you please share it? Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, 3 April 2014 5:31 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... So I just checked my tomcat version and we are running 6.0.35 which must be the default that comes with Ubuntu 12.04 out of the box. Our memory settings are as follows: JAVA_OPTS=-Djava.awt.headless=true -Dcom.sun.management.jmxremote.port=45219 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Xmx4g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M -XX:MaxPermSize=800m So what version of tomcat are you running 6.0.35 or 6.0.33? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Tue, 1 Apr 2014 11:23:57 +0800 We have the same issue, after an upgrade from 2.2.14 to 4.2.1,
RE: Interesting 4.2.1. Issue...
So did you try changing your version of tomcat? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Fri, 4 Apr 2014 10:35:42 +0800 cd /usr/share/tomcat6/bin/ ./version.sh The output should be 6.0.33 instead of 6.0.35 Using CATALINA_BASE: /usr/share/tomcat6 Using CATALINA_HOME: /usr/share/tomcat6 Using CATALINA_TMPDIR: /usr/share/tomcat6/temp Using JRE_HOME:/usr Using CLASSPATH: /usr/share/tomcat6/bin/bootstrap.jar Server version: Apache Tomcat/6.0.35 Server built: Server number: 6.0.35.0 OS Name:Linux OS Version: 3.11.0-18-generic Architecture: amd64 JVM Version:1.6.0_30-b30 JVM Vendor: Sun Microsystems Inc. Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Friday, 4 April 2014 10:31 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... I've put tomcat 6.0.33 on our mgmt servers. I'm going to monitor it for the next few days to see if we get the error again. Do you know any way way to verify the version of tomcat that's running? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Thu, 3 Apr 2014 10:35:29 +0800 No we didn't, it wouldn't matter because the memory would still fill up, the problem is it opens a thread and it fails to close it so whatever you will increase soon or later the memory will fill up (if I understand right) The error in catalina is as follows: SEVERE: The web application [/client] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@1bd66d2d]) and a value of type [com.cloud.api.SerializationContext] (value [com.cloud.api.SerializationContext@2f6baed9]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. If someone could help with this error generated in the catalina log, that would be much appreicated. Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, 3 April 2014 9:34 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... A few other articles also mention setting the initial heap size -Xms to the same value as the heap size, to go ahead and fully commit the heap. Have you tried that? One other thing I am curious of is have you fiddled with the Perm Size XX:Permsize setting? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Thu, 3 Apr 2014 09:26:31 +0800 Believe or not!! We have tried setting them in both formats and still the catalina log produces java heap space error Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, 3 April 2014 9:24 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... This may be a silly question, but in all of the docs I am reading online in regards to increasing the java heap size, they are specifying it as -XmxsizeMB example -Xmx2048m vs -Xmx2g Is it possible that it's not reading the 2g variable as 2GB? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Thu, 3 Apr 2014 09:06:17 +0800 It is 6.0.35 and it still produces this error, even after increasing the Xmx to 4g, we have installed tomcat 6.0.33 and each time we install the cloudstack it does not sense the installed 6.0.33 and attempts to install 6.0.35 as it is dependent on it. Silly solution is that we scheduled a daily restart @ 2PM through a cron job But first you have to killall jvsc then restart the management server. What we are considering is to migrate the management server to CentOS 6.5 it comes with tomcat 6.0.24 and mysql 5.1, we attempted to restore the dump on a pilot environment and it worked. If someone else has a better solution than this would you please share it? Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, 3 April 2014 5:31 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... So I just checked my tomcat version and we are running 6.0.35 which must be the default that comes with Ubuntu 12.04 out of the box. Our memory settings are as follows: JAVA_OPTS=-Djava.awt.headless=true -Dcom.sun.management.jmxremote.port=45219 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Xmx4g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/cloudstack/management/
Re: cloudstack debug level when running mvn -pl :cloud-client-ui jetty:run
Hi You can hava a try modify file client/tomcatconf/log4j-cloud.xml.in, changing log level INFO to DEBUG. Hopes working. Thanks, Yitao 2014-04-02 2:24 GMT+08:00 chris snow chsnow...@gmail.com: How can I increase the debug level when I am running: mvn -pl :cloud-client-ui jetty:run Currently log level seems to be set to INFO, and doesn't tell me much when things go wrong. Many thanks, Chris
RE: Interesting 4.2.1. Issue...
I tried but I failed to do so, each time cloudstack attempts to install to go fetches the 6.0.35 from the repo, maybe you have installed it after installing the cloudstack, if you managed to have a running cloudstack version above the 6.0.33 feedback with the results. Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Friday, 4 April 2014 10:41 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... So did you try changing your version of tomcat? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Fri, 4 Apr 2014 10:35:42 +0800 cd /usr/share/tomcat6/bin/ ./version.sh The output should be 6.0.33 instead of 6.0.35 Using CATALINA_BASE: /usr/share/tomcat6 Using CATALINA_HOME: /usr/share/tomcat6 Using CATALINA_TMPDIR: /usr/share/tomcat6/temp Using JRE_HOME:/usr Using CLASSPATH: /usr/share/tomcat6/bin/bootstrap.jar Server version: Apache Tomcat/6.0.35 Server built: Server number: 6.0.35.0 OS Name:Linux OS Version: 3.11.0-18-generic Architecture: amd64 JVM Version:1.6.0_30-b30 JVM Vendor: Sun Microsystems Inc. Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Friday, 4 April 2014 10:31 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... I've put tomcat 6.0.33 on our mgmt servers. I'm going to monitor it for the next few days to see if we get the error again. Do you know any way way to verify the version of tomcat that's running? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Thu, 3 Apr 2014 10:35:29 +0800 No we didn't, it wouldn't matter because the memory would still fill up, the problem is it opens a thread and it fails to close it so whatever you will increase soon or later the memory will fill up (if I understand right) The error in catalina is as follows: SEVERE: The web application [/client] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@1bd66d2d]) and a value of type [com.cloud.api.SerializationContext] (value [com.cloud.api.SerializationContext@2f6baed9]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. If someone could help with this error generated in the catalina log, that would be much appreicated. Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, 3 April 2014 9:34 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... A few other articles also mention setting the initial heap size -Xms to the same value as the heap size, to go ahead and fully commit the heap. Have you tried that? One other thing I am curious of is have you fiddled with the Perm Size XX:Permsize setting? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Thu, 3 Apr 2014 09:26:31 +0800 Believe or not!! We have tried setting them in both formats and still the catalina log produces java heap space error Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, 3 April 2014 9:24 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... This may be a silly question, but in all of the docs I am reading online in regards to increasing the java heap size, they are specifying it as -XmxsizeMB example -Xmx2048m vs -Xmx2g Is it possible that it's not reading the 2g variable as 2GB? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Thu, 3 Apr 2014 09:06:17 +0800 It is 6.0.35 and it still produces this error, even after increasing the Xmx to 4g, we have installed tomcat 6.0.33 and each time we install the cloudstack it does not sense the installed 6.0.33 and attempts to install 6.0.35 as it is dependent on it. Silly solution is that we scheduled a daily restart @ 2PM through a cron job But first you have to killall jvsc then restart the management server. What we are considering is to migrate the management server to CentOS 6.5 it comes with tomcat 6.0.24 and mysql 5.1, we attempted to restore the dump on a pilot environment and it worked. If someone else has a better solution than this would you please share it? Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, 3 April 2014 5:31 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1.
RE: Interesting 4.2.1. Issue...
So I manually downloaded tomcat 6.0.33 herehttps://cwiki.apache.org/confluence/display/CLOUDSTACK/Setting+up+CloudStack+Development+Environment+on+Linux Then did the following1. extracted 6.0.33 to /usr/share/tomcat6.0.33. 2. Changed symlink of /usr/share/cloudstack-managemet/bin to /usr/share/tomcat6.0.33/bin3. Changed symlink of /usr/share/cloudstack-management/lib to /usr/share/tomcat6.0.33/lib4. Verified cloudstack was running tomcat 6.0.33 by creating a tomcat_version.jsp file in /usr/share/cloudstack-management/webapps/client code for tomcat_version.jsp can be found herehttp://stackoverflow.com/questions/14925073/how-to-find-out-running-tomcat-version I'll definitely let you know how it goes... Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Fri, 4 Apr 2014 10:43:35 +0800 I tried but I failed to do so, each time cloudstack attempts to install to go fetches the 6.0.35 from the repo, maybe you have installed it after installing the cloudstack, if you managed to have a running cloudstack version above the 6.0.33 feedback with the results. Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Friday, 4 April 2014 10:41 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... So did you try changing your version of tomcat? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Fri, 4 Apr 2014 10:35:42 +0800 cd /usr/share/tomcat6/bin/ ./version.sh The output should be 6.0.33 instead of 6.0.35 Using CATALINA_BASE: /usr/share/tomcat6 Using CATALINA_HOME: /usr/share/tomcat6 Using CATALINA_TMPDIR: /usr/share/tomcat6/temp Using JRE_HOME:/usr Using CLASSPATH: /usr/share/tomcat6/bin/bootstrap.jar Server version: Apache Tomcat/6.0.35 Server built: Server number: 6.0.35.0 OS Name:Linux OS Version: 3.11.0-18-generic Architecture: amd64 JVM Version:1.6.0_30-b30 JVM Vendor: Sun Microsystems Inc. Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Friday, 4 April 2014 10:31 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... I've put tomcat 6.0.33 on our mgmt servers. I'm going to monitor it for the next few days to see if we get the error again. Do you know any way way to verify the version of tomcat that's running? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Thu, 3 Apr 2014 10:35:29 +0800 No we didn't, it wouldn't matter because the memory would still fill up, the problem is it opens a thread and it fails to close it so whatever you will increase soon or later the memory will fill up (if I understand right) The error in catalina is as follows: SEVERE: The web application [/client] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@1bd66d2d]) and a value of type [com.cloud.api.SerializationContext] (value [com.cloud.api.SerializationContext@2f6baed9]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. If someone could help with this error generated in the catalina log, that would be much appreicated. Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, 3 April 2014 9:34 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... A few other articles also mention setting the initial heap size -Xms to the same value as the heap size, to go ahead and fully commit the heap. Have you tried that? One other thing I am curious of is have you fiddled with the Perm Size XX:Permsize setting? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Thu, 3 Apr 2014 09:26:31 +0800 Believe or not!! We have tried setting them in both formats and still the catalina log produces java heap space error Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, 3 April 2014 9:24 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... This may be a silly question, but in all of the docs I am reading online in regards to increasing the java heap size, they are specifying it as -XmxsizeMB example -Xmx2048m vs -Xmx2g Is it possible that it's not reading the 2g variable as 2GB? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Thu, 3 Apr 2014
RE: Interesting 4.2.1. Issue...
Thanks and thanks for sharing the steps Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Friday, 4 April 2014 11:02 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... So I manually downloaded tomcat 6.0.33 herehttps://cwiki.apache.org/confluence/display/CLOUDSTACK/Setting+up+CloudStack+Development+Environment+on+Linux Then did the following1. extracted 6.0.33 to /usr/share/tomcat6.0.33. 2. Changed symlink of /usr/share/cloudstack-managemet/bin to /usr/share/tomcat6.0.33/bin3. Changed symlink of /usr/share/cloudstack-management/lib to /usr/share/tomcat6.0.33/lib4. Verified cloudstack was running tomcat 6.0.33 by creating a tomcat_version.jsp file in /usr/share/cloudstack-management/webapps/client code for tomcat_version.jsp can be found herehttp://stackoverflow.com/questions/14925073/how-to-find-out-running-tomcat-version I'll definitely let you know how it goes... Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Fri, 4 Apr 2014 10:43:35 +0800 I tried but I failed to do so, each time cloudstack attempts to install to go fetches the 6.0.35 from the repo, maybe you have installed it after installing the cloudstack, if you managed to have a running cloudstack version above the 6.0.33 feedback with the results. Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Friday, 4 April 2014 10:41 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... So did you try changing your version of tomcat? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Fri, 4 Apr 2014 10:35:42 +0800 cd /usr/share/tomcat6/bin/ ./version.sh The output should be 6.0.33 instead of 6.0.35 Using CATALINA_BASE: /usr/share/tomcat6 Using CATALINA_HOME: /usr/share/tomcat6 Using CATALINA_TMPDIR: /usr/share/tomcat6/temp Using JRE_HOME:/usr Using CLASSPATH: /usr/share/tomcat6/bin/bootstrap.jar Server version: Apache Tomcat/6.0.35 Server built: Server number: 6.0.35.0 OS Name:Linux OS Version: 3.11.0-18-generic Architecture: amd64 JVM Version:1.6.0_30-b30 JVM Vendor: Sun Microsystems Inc. Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Friday, 4 April 2014 10:31 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... I've put tomcat 6.0.33 on our mgmt servers. I'm going to monitor it for the next few days to see if we get the error again. Do you know any way way to verify the version of tomcat that's running? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Thu, 3 Apr 2014 10:35:29 +0800 No we didn't, it wouldn't matter because the memory would still fill up, the problem is it opens a thread and it fails to close it so whatever you will increase soon or later the memory will fill up (if I understand right) The error in catalina is as follows: SEVERE: The web application [/client] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@1bd66d2d]) and a value of type [com.cloud.api.SerializationContext] (value [com.cloud.api.SerializationContext@2f6baed9]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. If someone could help with this error generated in the catalina log, that would be much appreicated. Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, 3 April 2014 9:34 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... A few other articles also mention setting the initial heap size -Xms to the same value as the heap size, to go ahead and fully commit the heap. Have you tried that? One other thing I am curious of is have you fiddled with the Perm Size XX:Permsize setting? Subject: RE: Interesting 4.2.1. Issue... From: a...@opencloud.net.au To: dev@cloudstack.apache.org Date: Thu, 3 Apr 2014 09:26:31 +0800 Believe or not!! We have tried setting them in both formats and still the catalina log produces java heap space error Kind Regards Amin -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, 3 April 2014 9:24 AM To: dev@cloudstack.apache.org Subject: RE: Interesting 4.2.1. Issue... This may be a silly question, but in all of the docs I am reading online in regards to increasing the java heap size, they are specifying it as
Re: Review Request 19992: CLOUDSTACK-6268: Unable to get GPU stats, You tried to call a method that does not exist.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19992/#review39512 --- Commit 3666df4d34c880097e717cb949d05f3178e5a65f in cloudstack's branch refs/heads/master from Sanjay Tripathi [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3666df4 ] CLOUDSTACK-6268: Unable to get GPU stats, You tried to call a method that does not exist. - ASF Subversion and Git Services On April 3, 2014, 12:22 p.m., Sanjay Tripathi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19992/ --- (Updated April 3, 2014, 12:22 p.m.) Review request for cloudstack, anthony xu and Devdeep Singh. Repository: cloudstack-git Description --- This issue is because of the absence of XenServer620SP1 resource file. which I have added as a fix. Diffs - plugins/hypervisors/xen/src/com/cloud/hypervisor/XenServerGuru.java 4d88740 plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/discoverer/XcpServerDiscoverer.java 6ead6b7 plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixHelper.java 6c1e9a8 plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java 8556e4e plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer620SP1Resource.java PRE-CREATION plugins/hypervisors/xen/src/org/apache/cloudstack/hypervisor/xenserver/XenServerResourceNewBase.java e3626c3 plugins/hypervisors/xen/src/org/apache/cloudstack/hypervisor/xenserver/XenserverConfigs.java 8df803b Diff: https://reviews.apache.org/r/19992/diff/ Testing --- Verified the fix on XS6.2SP1 and older versions. Thanks, Sanjay Tripathi
