Re: Review Request 19351: Fixed updating ipset on acquiring vm nic secondary ip for advanced SG zone

[Jayapal Reddy]

> On March 18, 2014, 6:25 p.m., Alena Prokharchyk wrote:
> > Jayapal, you shoudldn't rely on SG attribute of the zone. You should check 
> > if the SG service is supported by the network you are adding your rule to.

Updated patch to check network for SG enabled.


- Jayapal


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19351/#review37589
---


On March 19, 2014, 11:59 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19351/
> ---
> 
> (Updated March 19, 2014, 11:59 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and edison su.
> 
> 
> Bugs: CLOUDSTACK-6240
> https://issues.apache.org/jira/browse/CLOUDSTACK-6240
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Updated adding SG rules for nic secondary ips in Advacned SG.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/command/user/vm/AddIpToVmNicCmd.java 
> b5e2239 
>   api/src/org/apache/cloudstack/api/command/user/vm/RemoveIpFromVmNicCmd.java 
> 199cf2e 
>   server/src/com/cloud/network/security/SecurityGroupManagerImpl.java 51c93b7 
> 
> Diff: https://reviews.apache.org/r/19351/diff/
> 
> 
> Testing
> ---
> 
> Tested 'ipset -L' output on xenserver after acquiring secondary ip for vm nic
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Re: Review Request 19351: Fixed updating ipset on acquiring vm nic secondary ip for advanced SG zone

[Jayapal Reddy]

> On March 18, 2014, 6:35 p.m., Alena Prokharchyk wrote:
> > Even for the Basic zone, we should send the ipSet command on nicplug only 
> > when the SG is supported by the Basic zone network. Because we also support 
> > a model when Basic zone is deployed with SG disabled.

When vm is created vm primary ip is set in ipset. For nic secondary ip there is 
no nicplug command send to hypervisor. 


- Jayapal


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19351/#review37596
---


On March 19, 2014, 11:59 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19351/
> ---
> 
> (Updated March 19, 2014, 11:59 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and edison su.
> 
> 
> Bugs: CLOUDSTACK-6240
> https://issues.apache.org/jira/browse/CLOUDSTACK-6240
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Updated adding SG rules for nic secondary ips in Advacned SG.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/command/user/vm/AddIpToVmNicCmd.java 
> b5e2239 
>   api/src/org/apache/cloudstack/api/command/user/vm/RemoveIpFromVmNicCmd.java 
> 199cf2e 
>   server/src/com/cloud/network/security/SecurityGroupManagerImpl.java 51c93b7 
> 
> Diff: https://reviews.apache.org/r/19351/diff/
> 
> 
> Testing
> ---
> 
> Tested 'ipset -L' output on xenserver after acquiring secondary ip for vm nic
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Re: Review Request 19922: CLOUDSTACK-6251: Removed XenServer stub code and used xapi.jar from the central repository instead.

[Konstantina Chremmou]

> On April 2, 2014, 8:54 p.m., Alex Huang wrote:
> > Please resubmit the patch for master.  It doesn't apply on master.  It 
> > looks to be fine for 4.4 but currently 4.4 is not building so I will get it 
> > applied once 4.4. is compiling.

I've just seen the patch went into master too, so I take it no resubmission is 
needed. Thanks for applying it.


- Konstantina


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19922/#review39351
---


On April 2, 2014, 2:59 p.m., Konstantina Chremmou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19922/
> ---
> 
> (Updated April 2, 2014, 2:59 p.m.)
> 
> 
> Review request for cloudstack and Alex Huang.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6251: Removed XenServer stub code and used xapi.jar from the 
> central repository instead. Also: fixed typo; ignored file.
> 
> 
> Diffs
> -
> 
>   .gitignore d6f5d1c 
>   deps/XenServerJava/pom.xml c9a4e86 
>   deps/XenServerJava/src/LICENSE.Apache-2.0.txt 261eeb9 
>   deps/XenServerJava/src/LICENSE.txt 76c4a22 
>   deps/XenServerJava/src/README.txt 2e6fa45 
>   deps/XenServerJava/src/com/xensource/xenapi/APIVersion.java 9dcdd9f 
>   deps/XenServerJava/src/com/xensource/xenapi/Auth.java 4778e6a 
>   deps/XenServerJava/src/com/xensource/xenapi/Blob.java ec91d87 
>   deps/XenServerJava/src/com/xensource/xenapi/Bond.java 5a54ad2 
>   deps/XenServerJava/src/com/xensource/xenapi/Connection.java 661724f 
>   deps/XenServerJava/src/com/xensource/xenapi/Console.java bb4440ae 
>   deps/XenServerJava/src/com/xensource/xenapi/Crashdump.java 1d40d4d 
>   deps/XenServerJava/src/com/xensource/xenapi/DRTask.java bbca81c 
>   deps/XenServerJava/src/com/xensource/xenapi/DataSource.java 9a4bfcd 
>   deps/XenServerJava/src/com/xensource/xenapi/Event.java 27db4a5 
>   deps/XenServerJava/src/com/xensource/xenapi/GPUGroup.java 916d8b6 
>   deps/XenServerJava/src/com/xensource/xenapi/Host.java 0bbae11 
>   deps/XenServerJava/src/com/xensource/xenapi/HostCpu.java 0f802f8 
>   deps/XenServerJava/src/com/xensource/xenapi/HostCrashdump.java e93240e 
>   deps/XenServerJava/src/com/xensource/xenapi/HostMetrics.java 261933f 
>   deps/XenServerJava/src/com/xensource/xenapi/HostPatch.java 0f229dc 
>   deps/XenServerJava/src/com/xensource/xenapi/Marshalling.java b7483c1 
>   deps/XenServerJava/src/com/xensource/xenapi/Message.java 8cb4127 
>   deps/XenServerJava/src/com/xensource/xenapi/Network.java 9f8c929 
>   deps/XenServerJava/src/com/xensource/xenapi/PBD.java bae095f 
>   deps/XenServerJava/src/com/xensource/xenapi/PCI.java fbee50a 
>   deps/XenServerJava/src/com/xensource/xenapi/PGPU.java 43eadf5 
>   deps/XenServerJava/src/com/xensource/xenapi/PIF.java e75b565 
>   deps/XenServerJava/src/com/xensource/xenapi/PIFMetrics.java 7d15393 
>   deps/XenServerJava/src/com/xensource/xenapi/Pool.java 8b5c94d 
>   deps/XenServerJava/src/com/xensource/xenapi/PoolPatch.java 99ac7e8 
>   deps/XenServerJava/src/com/xensource/xenapi/Role.java c9eaeaa 
>   deps/XenServerJava/src/com/xensource/xenapi/SM.java 6950fcd 
>   deps/XenServerJava/src/com/xensource/xenapi/SR.java 8999158 
>   deps/XenServerJava/src/com/xensource/xenapi/Secret.java 418bb88 
>   deps/XenServerJava/src/com/xensource/xenapi/Session.java a00ab7d 
>   deps/XenServerJava/src/com/xensource/xenapi/Subject.java 9a8fbfb 
>   deps/XenServerJava/src/com/xensource/xenapi/Task.java 4a85dfe 
>   deps/XenServerJava/src/com/xensource/xenapi/Tunnel.java e30bd0a 
>   deps/XenServerJava/src/com/xensource/xenapi/Types.java 50f49a0 
>   deps/XenServerJava/src/com/xensource/xenapi/User.java 4a01d60 
>   deps/XenServerJava/src/com/xensource/xenapi/VBD.java 72edf38 
>   deps/XenServerJava/src/com/xensource/xenapi/VBDMetrics.java a58e5e0 
>   deps/XenServerJava/src/com/xensource/xenapi/VDI.java 1431ce0 
>   deps/XenServerJava/src/com/xensource/xenapi/VGPU.java ebd0a64 
>   deps/XenServerJava/src/com/xensource/xenapi/VGPUType.java 075ec18 
>   deps/XenServerJava/src/com/xensource/xenapi/VIF.java c755dc4 
>   deps/XenServerJava/src/com/xensource/xenapi/VIFMetrics.java c051e53 
>   deps/XenServerJava/src/com/xensource/xenapi/VLAN.java f0abe29 
>   deps/XenServerJava/src/com/xensource/xenapi/VM.java 6ed76af 
>   deps/XenServerJava/src/com/xensource/xenapi/VMAppliance.java a0eb0d6 
>   deps/XenServerJava/src/com/xensource/xenapi/VMGuestMetrics.java 024f6c4 
>   deps/XenServerJava/src/com/xensource/xenapi/VMMetrics.java 30f4984 
>   deps/XenServerJava/src/com/xensource/xenapi/VMPP.java f49019b 
>   deps/XenServerJava/src/com/xensource/xenapi/VTPM.java 4ee7b2f 
>   deps/XenServerJava/src/com/xensource/xenapi/XenAPIObject.java 815a874 
>   plugins/hypervisors/

RE: [ANNOUNCE] Better XenServer support in 4.4....

[Konstantina Chremmou]

> -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.


> The most obvious change for developers and users is that they no longer
> have to download the vhd-util in order for CloudStack to work with
> XenServer 6.2 + SP1 + XS62ESP1004.  Note that CloudStack's version of vhd-
> util is still needed for all previous versions of XenServer.
> 
> For users who have deployed previous versions of CloudStack, it may be wise
> to remove all copies of the CloudStack's copy of the xen-api.jar from their
> maven cache and deployments.
> 
> To download patch XS62ESP1004, see [1].  To download SP1 for XenServer
> 6.2, see [2].
> 
> My sincere thanks to the XenServer team in making this change happen.
> 
> --Alex
> 
> [1] http://support.citrix.com/article/CTX140417
> [2] http://support.citrix.com/article/CTX139788

Re: ALARM - ACS reboots host servers!!!

[France]

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" 
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  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  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  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!  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

[chris snow]

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: 
  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: RTD documentations

[benoit lair]

+1 too for doc release with version number according to code releases


2014-04-03 6:41 GMT+02:00 Radhika Puthiyetath <
radhika.puthiyet...@citrix.com>:

> +1  doc release with version number that match code releases
>
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: Wednesday, April 02, 2014 8:52 PM
> To: dev@cloudstack.apache.org
> Subject: Re: RTD documentations
>
>
> On Apr 2, 2014, at 10:09 AM, Pierre-Luc Dion  wrote:
>
> > Hi,
> >
> > I was reviewing how to use RTD for CloudStack documentation and look
> > like we could use git branches to match product and doc version. This
> > way we could provide documentation update while and keep the
> > documentation match the product version. it should also be possible to
> > define the default
> > ("latest") to a specific branch so we could have  branches for  4.3,
> > 4.4 and still have the default documentation pointing to 4.3 as the
> latest.
> >
> > Did any one tested that?
>
> you are correct but we have not tested it yet.
>
> We need to discuss how we want to release documentation, i.e. do we make
> formal doc release with version number that match code releases, do we vote
> on the doc releases etc.
>
> But you are right that we can tag a special branch and keep track of the
> releases in RTD.
>
> >
> > RTD support also Tags for documentation versioning but if we want to
> > keep matching doc version and CS version we couldn't perform fixes in
> > the doc without updating the doc version.
>
> Right, and that's an issue we had before. If we make a doc release that
> match the code release then we "abandon" that release and never go back to
> fix it, except in bug fix releases or next major releases.
>
> I have not had time to seat down and think through this, ideas welcome...
>
>
> >
> >
> > Pierre-Luc Dion
> > Architecte de Solution Cloud | Cloud Solutions Architect
> > - - -
> >
> > *CloudOps*420 rue Guy
> > Montréal QC  H3J 1S6
> > www.cloudops.com
> > @CloudOps_
>
>

Re: ALARM - ACS reboots host servers!!!

[Wido den Hollander]

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" 
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  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  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  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!  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

[Anshul Gangwar]

---
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

[Koushik Das]

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  
wrote:

> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator
> 
> Thanks!
> Santhosh

RE: Validating check-ins for your local changes, using Simulator

[Santhosh Edukulla]

Also a note for writing integration tests.  We need to add a tag as 
"selfservice" or "provisioning" for every test,  apart from other tags 
relevant.  See, tests in master or 4.4 for example. 

Regards,
Santhosh

From: Koushik Das [koushik@citrix.com]
Sent: Thursday, April 03, 2014 4:40 AM
To: 
Subject: 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  
wrote:

> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator
>
> Thanks!
> Santhosh

Re: Review Request 19584: CLOUDSTACK-6258: Disable systemvm cloud startup script from logging messages to /var/log/cloud/cloud.out

[Rajani Karuturi]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19584/#review39408
---



systemvm/patches/debian/config/etc/init.d/cloud


since the check is about the log file location, i think it should set just 
that

if()
  LOG_FILE = /var/log/cloud/cloud.out
else
  LOG_FILE = /dev/null


and the actual cmd can be

(cd $CLOUDSTACK_HOME/systemvm; nohup ./run.sh > $LOG_FILE 2>&1 &)


- Rajani Karuturi


On March 24, 2014, 3 p.m., Saurav Lahiri wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19584/
> ---
> 
> (Updated March 24, 2014, 3 p.m.)
> 
> 
> 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
> 
>

Re: git commit: updated refs/heads/wip-multi-disk-select to 4c99757

[Daan Hoogland]

Brian,

could you not check in commented out code? We have git, it is a bit of
pollution of our code base.

thanks,
Daan

On Wed, Apr 2, 2014 at 10:58 PM,   wrote:
> Repository: cloudstack
> Updated Branches:
>   refs/heads/wip-multi-disk-select f23dd1df9 -> 4c997570b
>
>
> Comment out multiDisk dummy code
>
>
> Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
> Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/4c997570
> Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/4c997570
> Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/4c997570
>
> Branch: refs/heads/wip-multi-disk-select
> Commit: 4c997570bb7572c9aacdbbae5295b59428affc4b
> Parents: f23dd1d
> Author: Brian Federle 
> Authored: Wed Apr 2 13:58:26 2014 -0700
> Committer: Brian Federle 
> Committed: Wed Apr 2 13:58:26 2014 -0700
>
> --
>  ui/scripts/instanceWizard.js | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/4c997570/ui/scripts/instanceWizard.js
> --
> diff --git a/ui/scripts/instanceWizard.js b/ui/scripts/instanceWizard.js
> index 1b93364..d602074 100644
> --- a/ui/scripts/instanceWizard.js
> +++ b/ui/scripts/instanceWizard.js
> @@ -336,12 +336,13 @@
>  data: {
>  diskOfferings: diskOfferingObjs
>  },
> -multiDisk: args.currentData.serviceofferingid 
> === "919ac1bb-be43-4811-8c73-b1c038aac5be" ?
> -[
> -{ id: 1, label: 'vm-disk-1' },
> -{ id: 2, label: 'vm-disk-2' },
> -{ id: 3, label: 'vm-disk-3' }
> -] : null
> +multiDisk: false
> +// multiDisk:
> +// [
> +//{ id: 1, label: 'vm-disk-1' },
> +//{ id: 2, label: 'vm-disk-2' },
> +//{ id: 3, label: 'vm-disk-3' }
> +// ]
>  });
>  }
>  });
>



-- 
Daan

Re: Review Request 19916: Updated listLoadBalancerRuleInstances, removeFromLoadBalancerRule APIs for VM secondary ip addresses

[Murali Reddy]

---
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

[Alex Hitchins]

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  
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"  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 
Support offers the 
best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2.1 training
18th-19th February 2014, Brazil. 
Classroom
17th-23rd March 2014, Region A. Instructor led, 
On-line
24th-28th March 2014, Region B. Instructor led, 
On-line
16th-20th June 2014, Region A. Instructor led, 
On-line
23rd-27th June 2014, Region B. Instructor led, 
On-line

Review Request 19992: CLOUDSTACK-6268: Unable to get GPU stats, You tried to call a method that does not exist.

[Sanjay Tripathi]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19992/
---

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

Re: Review Request 19616: Added check for null return.

[Alex Hitchins]

---
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

Review Request 19993: CLOUDSTACK-5674: Minor fixes to BVT test cases in marvin branch

[Gaurav Aradhye]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19993/
---

Review request for cloudstack and Girish Shilamkar.


Bugs: CLOUDSTACK-5674
https://issues.apache.org/jira/browse/CLOUDSTACK-5674


Repository: cloudstack-git


Description
---

Minor fixes to few BVT test cases such as
1. Correcting the method call to getZoneForTests
2. Adding list validation
3. Removing services["mode"]. Reading it from zone.networktype


Diffs
-

  test/integration/smoke/test_network.py dc2e53e 
  test/integration/smoke/test_public_ip_range.py ca3c83b 
  test/integration/smoke/test_secondary_storage.py d430beb 
  test/integration/smoke/test_vm_snapshots.py ca6af31 

Diff: https://reviews.apache.org/r/19993/diff/


Testing
---

Yes


Thanks,

Gaurav Aradhye

Re: Unable to deploy systemvms

[Pierre-Luc Dion]

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  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 
> wrote:
>
> > Tejas,
> >
> > D

Re: ALARM - ACS reboots host servers!!!

[France]

Andrei,

is your hypervisor KVM?
I'm using XenServer.

Review Request 19995: VM Userdata field at GUI VM creation

[Jean-Francois Vincent]

---
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)

[Daan Hoogland]

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  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  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(getComm

Re: Review Request 19584: CLOUDSTACK-6258: Disable systemvm cloud startup script from logging messages to /var/log/cloud/cloud.out

[Saurav Lahiri]

---
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

[Sudha Ponnaganti]

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  
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"  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 
Support offers the 
best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2.1 training
18th-19th February 2014, Brazil. 
Classroom
17th-23rd March 2014, Region A. Instructor led, 
On-line

Re: Review Request 19917: Improvements on exception handlers (JIRA-6242)

[Ding Yuan]

---
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)

[Ding Yuan]

---
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
-

  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)

[Ding Yuan]

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  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  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  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: s

Re: Review Request 17790: Domain-Account-User Sync Up Among Multiple Regions

[Alex Ough]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17790/
---

(Updated April 3, 2014, 3:52 p.m.)


Review request for cloudstack.


Changes
---

This is the patch for the core changes.

As per Alena's request,
1) Done
2) Done
3) Done
4) Done
5) Done
6) Done
7) Yes
8) One of the key features is to assign the created/modified datetimes of newly 
being created/modifyed resources with them of corresponding remote resources in 
order to maintain the original datetimes of the resources. Otherwise, the 
datetime comparison will not be correct.
9) Done
10) Done
11) Done
12) Done
13) Done

Please let me know if there is anything incorrect/missing. 


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)
-

  api/src/com/cloud/domain/Domain.java 365a705 
  api/src/com/cloud/event/EventTypes.java 39ef710 
  api/src/com/cloud/user/Account.java b912e51 
  api/src/com/cloud/user/AccountService.java 7e37b38 
  api/src/com/cloud/user/User.java 36e9028 
  api/src/com/cloud/user/UserAccount.java c5a0637 
  api/src/org/apache/cloudstack/api/ApiConstants.java fdb4558 
  api/src/org/apache/cloudstack/api/BaseCmd.java f6f21ae 
  api/src/org/apache/cloudstack/api/command/admin/region/AddRegionCmd.java 
f6743ba 
  api/src/org/apache/cloudstack/api/command/admin/region/UpdateRegionCmd.java 
b08cbbb 
  api/src/org/apache/cloudstack/api/response/AccountResponse.java 2e50c51 
  api/src/org/apache/cloudstack/api/response/DomainResponse.java 0c0281e 
  api/src/org/apache/cloudstack/api/response/RegionResponse.java 6c74fa6 
  api/src/org/apache/cloudstack/api/response/UserResponse.java 40e1561 
  api/src/org/apache/cloudstack/region/Region.java df64e44 
  api/src/org/apache/cloudstack/region/RegionService.java afefcc7 
  api/test/org/apache/cloudstack/api/command/test/RegionCmdTest.java 10c3d85 
  client/pom.xml d8dbde7 
  
engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml
 489b37d 
  engine/schema/src/com/cloud/domain/DomainVO.java f6494b3 
  engine/schema/src/com/cloud/rmap/RmapVO.java PRE-CREATION 
  engine/schema/src/com/cloud/rmap/dao/RmapDao.java PRE-CREATION 
  engine/schema/src/com/cloud/rmap/dao/RmapDaoImpl.java PRE-CREATION 
  engine/schema/src/com/cloud/user/AccountVO.java 0f5a044 
  engine/schema/src/com/cloud/user/UserAccountVO.java cef9239 
  engine/schema/src/com/cloud/user/UserVO.java 68879f6 
  engine/schema/src/org/apache/cloudstack/region/RegionVO.java 608bd2b 
  framework/db/src/com/cloud/utils/db/Attribute.java 82c2bdb 
  framework/db/src/com/cloud/utils/db/GenericDao.java cb401cd 
  framework/db/src/com/cloud/utils/db/GenericDaoBase.java 2052aad 
  framework/db/src/com/cloud/utils/db/SqlGenerator.java befe34b 
  framework/db/test/com/cloud/utils/db/GenericDaoBaseTest.java aef0c69 
  framework/db/test/com/cloud/utils/db/SqlGeneratorTest.java PRE-CREATION 
  
plugins/network-elements/juniper-contrail/test/org/apache/cloudstack/network/contrail/management/MockAccountManager.java
 957f708 
  plugins/pom.xml 9b391b8 
  
server/resources/META-INF/cloudstack/core/spring-server-core-managers-context.xml
 fc1c7e2 
  server/src/com/cloud/api/ApiDispatcher.java 95074e2 
  server/src/com/cloud/api/ApiResponseHelper.java 38f2f0b 
  server/src/com/cloud/api/dispatch/ParamProcessWorker.java e9bdd8b 
  server/src/com/cloud/api/query/dao/AccountJoinDaoImpl.java ecd97c7 
  server/src/com/cloud/api/query/dao/UserAccountJoinDaoImpl.java 923a238 
  server/src/com/cloud/api/query/vo/AccountJoinVO.java 8d642ed 
  server/src/com/cloud/api/query/vo/UserAccountJoinVO.java ed29284 
  server/src/com/cloud/event/ActionEventUtils.java 28e5680 
  server/src/com/cloud/projects/ProjectManagerImpl.java d10c059 
  server/src/com/cloud/user/AccountManager.java 03bf842 
  server/src/com/cloud/user/AccountManagerImpl.java 2070ee6 
  server/src/com/cloud/user/DomainManager.java f72b18a 
  server/src/com/cloud/user/DomainManagerImpl.java fbbe0c2 
  server/src/org/apache/cloudstack/region/RegionManager.java 6f25481 
  server/src/org/apache/cloudstack/region/RegionManagerImpl.java 8910714 
  server/src/org/apache/cloudstack/region/RegionServiceImpl.java 98cf500 
  serve

Re: Review Request 19616: Added check for null return.

[Daan Hoogland]

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
 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 17790: Domain-Account-User Sync Up Among Multiple Regions

[Alex Ough]

---
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 
  
plugins/event-bus/multiregion/

Re: [DISCUSS]{BEHAVIORAL-CHANGE]Domain-Account-User Sync Up Among Multiple Regions

[Alex Ough]

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  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 
>> Date: Wednesday, March 26, 2014 at 7:39 AM
>> To: Alex Ough , "dev@cloudstack.apache.org" <
>> dev@cloudstack.apache.org>
>> Cc: Chiradeep Vittal 
>>
>> 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 
>> Date: Wednesday, March 26, 2014 at 6:35 AM
>> To: Alena Prokharchyk 
>> Cc: "dev@cloudstack.apache.org" , Chiradeep
>> Vittal 
>> 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.
>>   > 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  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=lockUser&id=" + userId +
 "&response=json&sessionkey=" + URLEncoder.encode(getSessionKey(),
 "UTF-8");
 return sendApacheGet(paramStr);
 }


 public JSONObject disableUser(String userId) throws Exception {

 String paramStr = "command=disableUser&id=" + userId +
 "&response=json&sessionkey=" + 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: Review Request 19616: Added check for null return.

[Alex Hitchins]

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 
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.

[Daan Hoogland]

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  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 
> 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 19917: Improvements on exception handlers (JIRA-6242)

[Daan Hoogland]

thanks Ding,

I saw your update. Did your run a cloud with this code; i.e. did you
monkey-test it?

On Thu, Apr 3, 2014 at 5:26 PM, Ding Yuan  wrote:
> 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  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  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  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: "

Re: Review Request 19686: Implementation of the issue CLOUDSTACK 6139 - System.vm.use.local.storage global setting to zone setting

[daan Hoogland]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19686/#review39416
---



server/src/com/cloud/deploy/DeploymentPlanningManagerImpl.java


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

[Alex Ough]

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  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  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 
>>> Date: Wednesday, March 26, 2014 at 7:39 AM
>>> To: Alex Ough , "dev@cloudstack.apache.org" <
>>> dev@cloudstack.apache.org>
>>> Cc: Chiradeep Vittal 
>>>
>>> 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 
>>> Date: Wednesday, March 26, 2014 at 6:35 AM
>>> To: Alena Prokharchyk 
>>> Cc: "dev@cloudstack.apache.org" , Chiradeep
>>> Vittal 
>>> 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.
>>>   >> 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 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=lockUser&id=" + userId +
> "&response=json&sessionkey=" + URLEncoder.encode(getSessionKey(),
> "UTF-8");
> return sendApacheGet(paramStr);
> }
>
>
> public JSONObject disableUser(String userId) throws Exception {
>
> String paramStr = "command=disableUser&id=" + userId +
> "&

Re: VM_HVM_REQUIRED - installing from ISO's

[chris snow]

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: Review Request 19917: Improvements on exception handlers (JIRA-6242)

[Daan Hoogland]

btw Ding,

You didn't add people to the review request you made. I was triggered
by something (must have been the title) I don't remember to look at it
but sometimes they lay around when no reviewer is assigned.

As I just stated in another thread: look at the annotations and/or git
log and see who did the most changes in the code, then add those
people as reviewers.

regards,
Daan

On Thu, Apr 3, 2014 at 6:04 PM, Daan Hoogland  wrote:
> thanks Ding,
>
> I saw your update. Did your run a cloud with this code; i.e. did you
> monkey-test it?
>
> On Thu, Apr 3, 2014 at 5:26 PM, Ding Yuan  wrote:
>> 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  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  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  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"

Re: Converting QCOW2 to VHD

[Rohit Yadav]

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!  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.

[Alex Hitchins]

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  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 
> 
> 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

[Nux!]

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!!!

[Alex Huang]

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" 
> > 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  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  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 
> 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!  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

[Rohit Yadav]

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=1&hl=en&ct=clnk&gl=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  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!  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

[Girish Chaudhari]

---
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

[Alena Prokharchyk]

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 mailto:alex.o...@sungardas.com>>
Date: Thursday, April 3, 2014 at 9:22 AM
To: Chiradeep Vittal 
mailto:chiradeep.vit...@citrix.com>>, Alena 
Prokharchyk 
mailto:alena.prokharc...@citrix.com>>, Darren 
Shepherd mailto:darren.sheph...@citrix.com>>
Cc: "dev@cloudstack.apache.org" 
mailto: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 
mailto: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 
mailto: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 
mailto: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 
mailto:alena.prokharc...@citrix.com>>
Date: Wednesday, March 26, 2014 at 7:39 AM
To: Alex Ough mailto:alex.o...@sungard.com>>, 
"dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Cc: Chiradeep Vittal 
mailto: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 mailto:alex.o...@sungard.com>>
Date: Wednesday, March 26, 2014 at 6:35 AM
To: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Cc: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, Chiradeep Vittal 
mailto: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.
 

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 
mailto: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 
mailto: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 JSONObjec

Re: Review Request 16688: console-proxy add support of AltGr key and FR azerty keyboard

[Axel Delahaye]

---
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 : , -- match on altgr state

It works like the shift match condition.
shift : , -- 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)

[Florin Dumitrascu]

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"
 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 

Re: Converting QCOW2 to VHD

[Nux!]

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=1&hl=en&ct=clnk&gl=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

how to keep the world from ending

[Marcus Sorensen]

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: [DISCUSS]{BEHAVIORAL-CHANGE]Domain-Account-User Sync Up Among Multiple Regions

[Alex Ough]

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 
> Date: Thursday, April 3, 2014 at 9:22 AM
> To: Chiradeep Vittal , Alena Prokharchyk <
> alena.prokharc...@citrix.com>, Darren Shepherd  >
> Cc: "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 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  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 
 Date: Wednesday, March 26, 2014 at 7:39 AM
 To: Alex Ough , "dev@cloudstack.apache.org" <
 dev@cloudstack.apache.org>
 Cc: Chiradeep Vittal 

 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 
 Date: Wednesday, March 26, 2014 at 6:35 AM
 To: Alena Prokharchyk 
 Cc: "dev@cloudstack.apache.org" , Chiradeep
 Vittal 
 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.
   >>> 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 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 mer

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 Dumitrascu]

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=
(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"
 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"
> 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"  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"
>>> 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. 

Re: [ANNOUNCE] Better XenServer support in 4.4....

[David Nalley]

On Thu, Apr 3, 2014 at 3:59 AM, Konstantina Chremmou
 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

[Marcus Sorensen]

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....

[David Nalley]

On Thu, Apr 3, 2014 at 1:28 PM, David Nalley  wrote:
> On Thu, Apr 3, 2014 at 3:59 AM, Konstantina Chremmou
>  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

[David Nalley]

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
 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

[Marcus]

Yeah, we're going through this... thing. Sorry for the noise.

On Thu, Apr 3, 2014 at 11:37 AM, David Nalley  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
>  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!!!

[Andrei Mikhailovsky]

I am on KVM.  thanks

- Original Message -
From: "France" 
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!!!

[Andrei Mikhailovsky]

+1


- Original Message -
From: "Alex Huang" 
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" 
> > 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  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  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 
> 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!  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

[Soheil Eizadi]

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

[Michael Phillips]

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

[Alena Prokharchyk]

---
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=createDomain&name=" + name + 
"&response=json&sessionkey=" + encodeSessionKey());
if (parentDomainId != null) param.append("&parentdomainid=" + parentDomainId);

with

StringBuilder param = new 
StringBuilder("command=createDomain&name=").append(name).append("&response=json&sessionkey=").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, Map parameters) {
StringBuilder param = new 
StringBuilder("command=).append(commandName).append("&response=json&sessionkey=").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 
>   
> plugi

Re: Review Request 16688: console-proxy add support of AltGr key and FR azerty keyboard

[Daan Hoogland]

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
wrote:

>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 : , -- match on altgr state
>
> It works like the shift match condition.
> shift : , -- 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 
>



-- 
Daan

Re: Unable to deploy systemvms

[Yitao Jiang]

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"  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  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"  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 
> 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  >
> > > > 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:

RE: Interesting 4.2.1. Issue...

[Michael Phillips]

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 
> > -Xmx"size""MB" 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...

[Amin Samir]

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 
> > -Xmx"size""MB" 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?
> > > 
> > > > Subje

RE: Interesting 4.2.1. Issue...

[Michael Phillips]

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 
> > > -Xmx"size""MB" 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 
> > >

Re: cloudstack debug level when running "mvn -pl :cloud-client-ui jetty:run"

[Yitao Jiang]

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 :

> 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...

[Amin Samir]

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 
> > > -Xmx"size""MB" 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

RE: Interesting 4.2.1. Issue...

[Michael Phillips]

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 

RE: Interesting 4.2.1. Issue...

[Amin Samir]

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]
> > >

RE: Interesting 4.2.1. Issue...

[Michael Phillips]

No problem. CS is at least running on tomcat 6.0.33 so that's good news. :)

> Subject: RE: Interesting 4.2.1. Issue...
> From: a...@opencloud.net.au
> To: dev@cloudstack.apache.org
> Date: Fri, 4 Apr 2014 11:10:28 +0800
> 
> 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?
> > > > 
> > > > > Subj

Re: Unable to deploy systemvms

[Tejas Gadaria]

Hi Dion & Jiang,

Thanks for your great help. I had improper VLAN ID for Storage Network.
Template is downloading now.


Regards,
Tejas


On Fri, Apr 4, 2014 at 5:33 AM, Yitao Jiang  wrote:

> 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"  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 
> 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"  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 
> > 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
> > VMTemplateSto

Re: Review Request 19992: CLOUDSTACK-6268: Unable to get GPU stats, You tried to call a method that does not exist.

[ASF Subversion and Git Services]

---
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
> 
>

Re: Review Request 19584: CLOUDSTACK-6258: Disable systemvm cloud startup script from logging messages to /var/log/cloud/cloud.out

[Rajani Karuturi]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19584/#review39517
---



systemvm/patches/debian/config/etc/init.d/cloud


Can we consider $CLOUD_DEBUG not set as true ie) log to cloud.out when 
$CLOUD_DEBUG is not set or $CLOUD_DEBUG is 1 ?

redirect to /dev/null when $CLOUD_DEBUG is 0

this way, it wont change the default behaviour of it. whoever doesnt want 
logging can set the variable to 0


- Rajani Karuturi


On April 3, 2014, 2:12 p.m., Saurav Lahiri wrote:
> 
> ---
> 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.
> 
> 
> 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
> 
>

Re: Review Request 19992: CLOUDSTACK-6268: Unable to get GPU stats, You tried to call a method that does not exist.

[ASF Subversion and Git Services]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19992/#review39518
---


Commit 0d770941413f2a0999ff43f1f49c8491f896a3d1 in cloudstack's branch 
refs/heads/4.4 from Sanjay Tripathi
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0d77094 ]

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
> 
>

Re: Review Request 19584: CLOUDSTACK-6258: Disable systemvm cloud startup script from logging messages to /var/log/cloud/cloud.out

[Saurav Lahiri]

> On April 4, 2014, 6:01 a.m., Rajani Karuturi wrote:
> > systemvm/patches/debian/config/etc/init.d/cloud, line 36
> > 
> >
> > Can we consider $CLOUD_DEBUG not set as true ie) log to cloud.out when 
> > $CLOUD_DEBUG is not set or $CLOUD_DEBUG is 1 ?
> > 
> > redirect to /dev/null when $CLOUD_DEBUG is 0
> > 
> > this way, it wont change the default behaviour of it. whoever doesnt 
> > want logging can set the variable to 0

Since the earlier behaviour was causing the file system to fill up( which is a 
serious issue) , I would think that changing that and preventing the init 
script to write to cloud.out, should be useful. And if required logging can be 
turned on, any problems identified and turned off. 


- Saurav


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19584/#review39517
---


On April 3, 2014, 2:12 p.m., Saurav Lahiri wrote:
> 
> ---
> 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.
> 
> 
> 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
> 
>

Re: Review Request 19584: CLOUDSTACK-6258: Disable systemvm cloud startup script from logging messages to /var/log/cloud/cloud.out

[Saurav Lahiri]

> On April 4, 2014, 6:01 a.m., Rajani Karuturi wrote:
> > systemvm/patches/debian/config/etc/init.d/cloud, line 36
> > 
> >
> > Can we consider $CLOUD_DEBUG not set as true ie) log to cloud.out when 
> > $CLOUD_DEBUG is not set or $CLOUD_DEBUG is 1 ?
> > 
> > redirect to /dev/null when $CLOUD_DEBUG is 0
> > 
> > this way, it wont change the default behaviour of it. whoever doesnt 
> > want logging can set the variable to 0
> 
> Saurav Lahiri wrote:
> Since the earlier behaviour was causing the file system to fill up( which 
> is a serious issue) , I would think that changing that and preventing the 
> init script to write to cloud.out, should be useful. And if required logging 
> can be turned on, any problems identified and turned off.

So if there is a confusion here, the fix only prevents messages logged by the 
init shell script, the java process will still continue to log messages via 
log4j and roll over once it reaches maxSize. This has not changed.


- Saurav


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19584/#review39517
---


On April 3, 2014, 2:12 p.m., Saurav Lahiri wrote:
> 
> ---
> 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.
> 
> 
> 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
> 
>