date:20140331

[GitHub] cloudstack-docs-install pull request: fix bullet lists

2014-03-31 Thread runseb

Github user runseb closed the pull request at:

https://github.com/apache/cloudstack-docs-install/pull/1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

RE: Guidelines for new or changed APIs?

2014-03-31 Thread Stephen Turner

Actually, Alena has recently started a document:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+API+Coding+Guidelines

I don't know how complete it is yet though.

-- 
Stephen Turner


-Original Message-
From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com] 
Sent: 29 March 2014 15:15
To: dev@cloudstack.apache.org
Subject: RE: Guidelines for new or changed APIs?

I don't know of any documentation, however we must ensure backwards 
compatibility, so that rather rules out changing existing api method signatures 
(adding/removing parameters).



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: Demetrius Tsitrelis [mailto:demetrius.tsitre...@citrix.com]
Sent: 29 March 2014 15:06
To: dev@cloudstack.apache.org
Subject: Guidelines for new or changed APIs?

I'd like to propose a few changes.  Some adding a parameter to an existing API 
and some adding a new API altogether.  Is there a document describing ASF or 
ACS policies for doing so?

Sent from my Windows Phone
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

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

4.4 BVT blocker : CLOUDSTACK-6309

2014-03-31 Thread Rayees Namathponnan

Hi All,

4.4 automation blocked with latest build, router deployment failing with below 
error

2014-03-31 00:16:52,144 WARN [o.a.c.e.o.NetworkOrchestrator] 
(Work-Job-Executor-22:Job-105/Job-106 ctx-1996e983) Failed to re-
program the network as a part of network 
Ntwk[38591d1e-5193-451c-beb0-854f44692880|Guest|8] implement due to aggregated 
command
s execution failure!

Defect https://issues.apache.org/jira/browse/CLOUDSTACK-6309 created for this.

Regards,
Rayees

Interesting 4.2.1. Issue...

2014-03-31 Thread Michael Phillips

So I have a redundant pair of management servers running on 4.2.1. At least 
once a day one of the management servers crashes and the log gets filled with 
the following messages:
java.lang.OutOfMemoryError: Java heap 
spac0java.lang.ArrayIndexOutOfBoundsExceptioneCaused by: java.io.EOFException: 
SSL peer shut down incorrectlyCaused by: javax.net.ssl.SSLHandshakeException: 
Remote host closed connection during handshake
and there are a few others. When the one management server tanks, although the 
other management server is up and active, it won't actually process any UI 
commands until the crashed server is restarted.  Example of won't process any 
UI command is create a new instance, create a new account, etc. After doing 
some searching I have found that others have noticed java heap errors in 4.2.1, 
and the suggested fix is to increase the heap size. I am planning on increasing 
it from 2g to 4g, however if the problem is something like a memory leak, then 
increasing the heap size will just delay the inevitable. Has anyone else fixed 
this issue by increasing the heap size? Or what is the recommended value? 
**updated...as expected I increased the heap size from 2g to 4g, and it just 
took longer for the problem to reoccur...
In my honest opinion of bigger concern is the fact that when one management 
server crashes the other stops functioning as well. So this begs the question 
of why even bother with a redundant pair of servers..Anybody else experience 
this issue? I would love to hear any dev guys opinion on this

docker.io integration

2014-03-31 Thread Francois Gaudreault


Hi all,

I am curious, anyone working on docker.io integration with CloudStack?

Thanks!

--
Francois Gaudreault
Architecte de Solution Cloud | Cloud Solutions Architect
fgaudrea...@cloudops.com
514-629-6775
- - -
CloudOps
420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_

Re: Guidelines for new or changed APIs?

2014-03-31 Thread Alena Prokharchyk

Thank you, Stephen, for sharing the document. I did include the backwards
compatibility requirements there.

Demetrius, please feel free to cover the gaps in the doc, if any.

-Alena.

On 3/31/14, 2:41 AM, "Stephen Turner"  wrote:

>Actually, Alena has recently started a document:
>
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+API+Codi
>ng+Guidelines
>
>I don't know how complete it is yet though.
>
>-- 
>Stephen Turner
>
>
>-Original Message-
>From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com]
>Sent: 29 March 2014 15:15
>To: dev@cloudstack.apache.org
>Subject: RE: Guidelines for new or changed APIs?
>
>I don't know of any documentation, however we must ensure backwards
>compatibility, so that rather rules out changing existing api method
>signatures (adding/removing parameters).
>
>
>
>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: Demetrius Tsitrelis [mailto:demetrius.tsitre...@citrix.com]
>Sent: 29 March 2014 15:06
>To: dev@cloudstack.apache.org
>Subject: Guidelines for new or changed APIs?
>
>I'd like to propose a few changes.  Some adding a parameter to an
>existing API and some adding a new API altogether.  Is there a document
>describing ASF or ACS policies for doing so?
>
>Sent from my Windows Phone
>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
>
>This email and any attachments to it may be confidential and are intended
>solely for the use of the individual to whom it is addressed. Any views
>or opinions expressed are solely those of the author and do not
>necessarily represent those of Shape Blue Ltd or related companies. If
>you are not the intended recipient of this email, you must neither take
>any action based upon its contents, nor copy or show it to anyone. Please
>contact the sender if you believe you have received this email in error.
>Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
>Services India LLP is a company incorporated in India and is operated
>under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
>a company incorporated in Brasil and is operated under license from Shape
>Blue Ltd. ShapeBlue is a registered trademark.

Re: docker.io integration

2014-03-31 Thread Sebastien Goasguen

Tuna has started a 'docker' branch


On Mar 31, 2014, at 11:50 AM, Francois Gaudreault  
wrote:

> Hi all,
> 
> I am curious, anyone working on docker.io integration with CloudStack?
> 
> Thanks!
> 
> -- 
> Francois Gaudreault
> Architecte de Solution Cloud | Cloud Solutions Architect
> fgaudrea...@cloudops.com
> 514-629-6775
> - - -
> CloudOps
> 420 rue Guy
> Montréal QC  H3J 1S6
> www.cloudops.com
> @CloudOps_
>

Re: docker.io integration

2014-03-31 Thread Francois Gaudreault


Cool!

Anh: Can you share the current state of the Branch?

Thanks!

On 2014-03-31, 1:21 PM, Sebastien Goasguen wrote:

Tuna has started a 'docker' branch


On Mar 31, 2014, at 11:50 AM, Francois Gaudreault  
wrote:


Hi all,

I am curious, anyone working on docker.io integration with CloudStack?

Thanks!

--
Francois Gaudreault
Architecte de Solution Cloud | Cloud Solutions Architect
fgaudrea...@cloudops.com
514-629-6775
- - -
CloudOps
420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_







--
Francois Gaudreault
Architecte de Solution Cloud | Cloud Solutions Architect
fgaudrea...@cloudops.com
514-629-6775
- - -
CloudOps
420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_

[4.2] Failed to create Host

2014-03-31 Thread dimas yoga pratama

Hi,

I'm trying to build Cloudstack 4.2 on my laptop using Devcloud with
VirtualBox and managed to login in CS Dashboard, but I've got the following
error when I try to create host in Infrastructure Tab.

Why is this happen?

WARN  [c.c.a.d.
ParamGenericValidationWorker] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Received unknown parameters for command addHost. Unknown
parameters : clustertype
INFO  [c.c.r.ResourceManagerImpl] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Trying to add a new host at http://192.168.56.10 in data
center 2
INFO  [c.c.h.x.d.XcpServerDiscoverer] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Found host devcloud ip=192.168.56.10 product version=1.6.0
INFO  [c.c.h.x.r.CitrixResourceBase] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Private Network is Pool-wide network associated with eth0 for
host 192.168.56.10
INFO  [c.c.h.x.r.CitrixResourceBase] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Guest Network is Pool-wide network associated with eth0 for
host 192.168.56.10
INFO  [c.c.h.x.r.CitrixResourceBase] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Public Network is Pool-wide network associated with eth0 for
host 192.168.56.10
INFO  [c.c.h.x.d.XcpServerDiscoverer] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Host: devcloud connected with hypervisor type: XenServer.
Checking CIDR...
INFO  [c.c.a.m.DirectAgentAttache] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) StartupAnswer received 4 Interval = 60
WARN  [c.c.a.m.DirectAgentAttache] (DirectAgent-2:ctx-1dd57f8e) Seq
4-7148901458497241089: Exception Caught while executing command
com.cloud.utils.exception.CloudRuntimeException: Cannot create directory
/opt/cloud/bin on XenServer hosts
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.setupServer(CitrixResourceBase.java:4892)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4718)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:497)
at
com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOssResource.java:176)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
WARN  [c.c.h.x.d.XcpServerDiscoverer] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Unable to setup agent 4 due to
com.cloud.utils.exception.CloudRuntimeException: Cannot create directory
/opt/cloud/bin on XenServer hosts
INFO  [c.c.u.e.CSExceptionErrorCode] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Could not find exception:
com.cloud.exception.ConnectionException in error code list for exceptions
WARN  [c.c.a.m.AgentManagerImpl] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Monitor XcpServerDiscoverer says there is an error in the
connect process for 4 due to Reinitialize agent after setup.
INFO  [c.c.a.m.AgentManagerImpl] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Host 4 is disconnecting with event AgentDisconnected
WARN  [c.c.r.ResourceManagerImpl] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Unable to connect due to
com.cloud.exception.ConnectionException: Reinitialize agent after setup.
at
com.cloud.hypervisor.xen.discoverer.XcpServerDiscoverer.processConnect(XcpServerDiscoverer.java:647)
at
com.cloud.agent.manager.AgentManagerImpl.notifyMonitorsOfConnection(AgentManagerImpl.java:514)
at
com.cloud.agent.manager.AgentManagerImpl.handleDirectConnectAgent(AgentManagerImpl.java:1427)
at
com.cloud.resource.ResourceManagerImpl.createHostAndAgent(ResourceManagerImpl.java:1764)
at
com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:773)
at
com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586)
at sun.reflect.Nat

Re: 4.4 BVT blocker : CLOUDSTACK-6309

2014-03-31 Thread Sheng Yang

I would take a look at this.

--Sheng


On Mon, Mar 31, 2014 at 8:30 AM, Rayees Namathponnan <
rayees.namathpon...@citrix.com> wrote:

> Hi All,
>
> 4.4 automation blocked with latest build, router deployment failing with
> below error
>
> 2014-03-31 00:16:52,144 WARN [o.a.c.e.o.NetworkOrchestrator]
> (Work-Job-Executor-22:Job-105/Job-106 ctx-1996e983) Failed to re-
> program the network as a part of network
> Ntwk[38591d1e-5193-451c-beb0-854f44692880|Guest|8] implement due to
> aggregated command
> s execution failure!
>
> Defect https://issues.apache.org/jira/browse/CLOUDSTACK-6309 created for
> this.
>
> Regards,
> Rayees
>

Where is our favorite CloudStack developer?

2014-03-31 Thread Mike Tutkowski

Hi,

Just an FYI that I'm WFH today and will be on PTO the rest of the week.

Next week I'm in Denver for ApacheCon on Monday and Tuesday and back to
Denver Wednesday - Friday for the CloudStack Collaboration Conference.

Talk to you later!

-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*

Re: 4.4 BVT blocker : CLOUDSTACK-6309

2014-03-31 Thread Sheng Yang

Fixed in 4.4 and master. Please verify.

--Sheng


On Mon, Mar 31, 2014 at 11:06 AM, Sheng Yang  wrote:

> I would take a look at this.
>
> --Sheng
>
>
> On Mon, Mar 31, 2014 at 8:30 AM, Rayees Namathponnan <
> rayees.namathpon...@citrix.com> wrote:
>
>> Hi All,
>>
>> 4.4 automation blocked with latest build, router deployment failing with
>> below error
>>
>> 2014-03-31 00:16:52,144 WARN [o.a.c.e.o.NetworkOrchestrator]
>> (Work-Job-Executor-22:Job-105/Job-106 ctx-1996e983) Failed to re-
>> program the network as a part of network
>> Ntwk[38591d1e-5193-451c-beb0-854f44692880|Guest|8] implement due to
>> aggregated command
>> s execution failure!
>>
>> Defect https://issues.apache.org/jira/browse/CLOUDSTACK-6309 created for
>> this.
>>
>> Regards,
>> Rayees
>>
>
>

RE: 4.4 BVT blocker : CLOUDSTACK-6309

2014-03-31 Thread Rayees Namathponnan

Thanks Sheng, I will check with new build 

-Original Message-
From: Sheng Yang [mailto:sh...@yasker.org] 
Sent: Monday, March 31, 2014 11:31 AM
To: 
Subject: Re: 4.4 BVT blocker : CLOUDSTACK-6309

Fixed in 4.4 and master. Please verify.

--Sheng


On Mon, Mar 31, 2014 at 11:06 AM, Sheng Yang  wrote:

> I would take a look at this.
>
> --Sheng
>
>
> On Mon, Mar 31, 2014 at 8:30 AM, Rayees Namathponnan < 
> rayees.namathpon...@citrix.com> wrote:
>
>> Hi All,
>>
>> 4.4 automation blocked with latest build, router deployment failing 
>> with below error
>>
>> 2014-03-31 00:16:52,144 WARN [o.a.c.e.o.NetworkOrchestrator]
>> (Work-Job-Executor-22:Job-105/Job-106 ctx-1996e983) Failed to re- 
>> program the network as a part of network 
>> Ntwk[38591d1e-5193-451c-beb0-854f44692880|Guest|8] implement due to 
>> aggregated command s execution failure!
>>
>> Defect https://issues.apache.org/jira/browse/CLOUDSTACK-6309 created 
>> for this.
>>
>> Regards,
>> Rayees
>>
>
>

Re: build cloudstack 4.3 from source

2014-03-31 Thread Pierre-Luc Dion

Hi all,

Any chance someone would know where we should place the MySQL connector.jar
file in order to build with nodist?
I haven't found any instruction so far.

Regards,



Pierre-Luc Dion
Architecte de Solution Cloud | Cloud Solutions Architect
514-447-3456, 1101
- - -

*CloudOps*420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_


On Mon, Mar 24, 2014 at 4:53 PM, Pierre-Luc Dion  wrote:

> Hi,
>
> I'm trying to build Cloudstack 4.3 from the 4.3 branch with nodist
> package.
>
> Do I need to place the mysql-connector-java-5.1.29-bin.jar somewhere?
>
> here is the build output log:
>
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR] 
> /var/lib/jenkins/workspace/CloudStack4.3_nodist_rpms/dist/rpmbuild/BUILD/cloudstack-4.3.0/framework/db/src/com/cloud/utils/db/StaticStrategy.java:[26,21]
>  error: package com.mysql.jdbc does not exist
>
>
>
> is there any reference about this in the doc or the wiki ? I've found
> nothing so far.
>
> Thanks
>
>
> Pierre-Luc Dion
> Architecte de Solution Cloud | Cloud Solutions Architect
> 514-447-3456, 1101
> - - -
>
> *CloudOps*420 rue Guy
> Montréal QC  H3J 1S6
> www.cloudops.com
> @CloudOps_
>

Re: spring unittests

2014-03-31 Thread Laszlo Hornyak

Hi Rajani,

I had a short investigation into the problem and that test context is quite
exciting. (which means I would need a lot more time to find all the
details) For a short solution I would recommend you to write another rather
than trying to reuse.



On Sat, Mar 29, 2014 at 11:30 AM, Rajani Karuturi <
rajani.karut...@citrix.com> wrote:

> any help?
>
>
> ~Rajani
>
>
>
> On 28-Mar-2014, at 9:48 am, Rajani Karuturi 
> wrote:
>
> > Its the testContext.xml we have at server/test/resouces
> >
> > As the async job dispatcher also comes under server/, i used the same
> test context file.
> >
> > ~Rajani
> >
> >
> >
> > On 28-Mar-2014, at 1:23 am, Laszlo Hornyak 
> wrote:
> >
> >> Hi Rajani,
> >>
> >> Can you share your spring context file?
> >>
> >>
> >> On Thu, Mar 27, 2014 at 10:50 AM, Rajani Karuturi <
> >> rajani.karut...@citrix.com> wrote:
> >>
> >>> Hi All,
> >>>
> >>> I am trying to write unit tests for ApiAsyncJobDispatcher. This is how
> I
> >>> defined by Test class @ server/test/com/cloud/api
> >>>
> >>> @RunWith(SpringJUnit4ClassRunner.class)
> >>> @ContextConfiguration(locations = "classpath:/testContext.xml")
> >>> public class ApiAsyncJobDispatcherTest {
> >>>   @Mock
> >>>   private ApiDispatcher _dispatcher;
> >>>
> >>>   @Mock
> >>>   private AsyncJobManager _asyncJobMgr;
> >>>
> >>>   @Mock
> >>>   private EntityManager _entityMgr;
> >>>
> >>>   @InjectMocks
> >>>   private ApiAsyncJobDispatcher apiAsyncJobDispatcher = new
> >>> ApiAsyncJobDispatcher();
> >>>
> >>>   @Before
> >>>   public void setUp() throws Exception {
> >>>   MockitoAnnotations.initMocks(this);
> >>>   ComponentContext.initComponentsLifeCycle();
> >>>   }
> >>>
> >>>   @Test
> >>>   public void testRunJob() throws Exception {
> >>>   AsyncJob asyncJob = new AsyncJobVO("", User.UID_SYSTEM, 1,
> >>> DetachVolumeCmdByAdmin.class.getCanonicalName(), null, null, null);
> >>>   apiAsyncJobDispatcher.runJob(asyncJob);
> >>>   }
> >>> }
> >>>
> >>>
> >>> I am getting failed to load ApplicationContext error. The exact error
> >>> message is
> >>> java.lang.ClassNotFoundException:
> >>> org.apache.cloudstack.framework.eventbus.EventBusBase
> >>>
> >>> I think, that class is moved to
> >>> org.apache.cloudstack.framework.events.EventBus. Once I make that
> change in
> >>> the application context file, I am getting
> >>> Caused by:
> >>> org.springframework.beans.factory.NoUniqueBeanDefinitionException: No
> >>> qualifying bean of type [com.cloud.user.AccountService] is defined:
> >>> expected single matching bean but found 4:
> >>> mockAccountManagerImpl,accountService,accountManager,acctMgr
> >>>
> >>>
> >>> Am I miss something?
> >>>
> >>> I did go through
> >>>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Unit+Testing+with+JUnit+and+SpringBut,
> didn't understand Note: #4 of it.
> >>>
> >>>
> >>> ~Rajani
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> EOF
> >
>
>


-- 

EOF

Re: [QUESTION] VMware ServerResource

2014-03-31 Thread Kelven Yang



On 3/29/14, 7:31 PM, "Sateesh Chodapuneedi"
 wrote:

>> -Original Message-
>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> Sent: 30 March 2014 00:06
>> To: dev@cloudstack.apache.org
>> Subject: [QUESTION] VMware ServerResource
>> 
>> Hi,
>> 
>> Quick question:
>> 
>> For VMware, since we have vCenter Server in the mix as opposed to just
>> ESX(i) hosts, I was wondering how that works out with our related
>>ServerResources.
>> 
>> For example, if you have a cluster with three ESX hosts, does that
>>equate to three ServerResources running on the management server?
>Yes, each host is tracked by a server resource. CloudStack retrieves
>owning cluster/datacenter as required from vCenter and performs required
>operations.
>
>> 
>> Assuming that leads to three ServerResources in that situation, if you
>>have multiple management servers for your cloud, do all three of
>> these ServerResources have to be managed by a single management server
>>(because their resources are in the same cluster)?
>I think it is not required to be managed by a single management server.


Yes, it is not required to be managed by a single management server. One
thing to note that, all resource instances are now sharing a pool of
vCenter sessions, an instance of such vCenter session is acquired and
released by server resource when it needs to perform operations to vCenter.


>
>> 
>> Thanks!
>> 
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the
>> cloud
>> *(tm)*

Re: [QUESTION] VMware ServerResource

2014-03-31 Thread Mike Tutkowski

Hi Kelven,

Thanks for the info!

I have another question that perhaps you can answer.

In my situation, with managed storage, I need to create and delete
datastores dynamically. The idea is to have a single VM (and all of its
corresponding files) or a single VMDK data disk file per datastore in some
cases so we can guarantee IOPS to the VM or data disk.

Each datastore is based on an iSCSI target that has guaranteed IOPS.

For data disks, this process has worked perfectly (first implemented in
4.2). When I need the datastore, I create an iSCSI target on my SAN, then
establish a connection to it from each host in the VMware cluster, then
create a datastore on the target.

When I no longer need the data disk, I remove the iSCSI targets from the
hosts and the datastore goes away.

This same process works pretty well for root disks (and the other files of
a VM) except for when I want to delete the VM and get rid of its datastore.
In this case, I follow the same process of removing the iSCSI connections
from each host in the cluster, but the datastore still shows up in vCenter
(albeit greyed out and in the inactive state when viewed through vSphere
Client).

Any thoughts on this? I've looked into this on the web and the general
consensus is that the datastore is still somehow in use by vCenter. Not
sure why that would be, though.

Thanks!
Mike

On Mon, Mar 31, 2014 at 2:45 PM, Kelven Yang  wrote:

>
>
> On 3/29/14, 7:31 PM, "Sateesh Chodapuneedi"
>  wrote:
>
> >> -Original Message-
> >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> >> Sent: 30 March 2014 00:06
> >> To: dev@cloudstack.apache.org
> >> Subject: [QUESTION] VMware ServerResource
> >>
> >> Hi,
> >>
> >> Quick question:
> >>
> >> For VMware, since we have vCenter Server in the mix as opposed to just
> >> ESX(i) hosts, I was wondering how that works out with our related
> >>ServerResources.
> >>
> >> For example, if you have a cluster with three ESX hosts, does that
> >>equate to three ServerResources running on the management server?
> >Yes, each host is tracked by a server resource. CloudStack retrieves
> >owning cluster/datacenter as required from vCenter and performs required
> >operations.
> >
> >>
> >> Assuming that leads to three ServerResources in that situation, if you
> >>have multiple management servers for your cloud, do all three of
> >> these ServerResources have to be managed by a single management server
> >>(because their resources are in the same cluster)?
> >I think it is not required to be managed by a single management server.
>
>
> Yes, it is not required to be managed by a single management server. One
> thing to note that, all resource instances are now sharing a pool of
> vCenter sessions, an instance of such vCenter session is acquired and
> released by server resource when it needs to perform operations to vCenter.
>
>
> >
> >>
> >> Thanks!
> >>
> >> --
> >> *Mike Tutkowski*
> >> *Senior CloudStack Developer, SolidFire Inc.*
> >> e: mike.tutkow...@solidfire.com
> >> o: 303.746.7302
> >> Advancing the way the world uses the
> >> cloud
> >> *(tm)*
>
>

-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*

Re: [QUESTION] VMware ServerResource

2014-03-31 Thread Kelven Yang


On 3/31/14, 1:54 PM, "Mike Tutkowski"  wrote:

>Hi Kelven,
>
>Thanks for the info!
>
>I have another question that perhaps you can answer.
>
>In my situation, with managed storage, I need to create and delete
>datastores dynamically. The idea is to have a single VM (and all of its
>corresponding files) or a single VMDK data disk file per datastore in some
>cases so we can guarantee IOPS to the VM or data disk.
>
>Each datastore is based on an iSCSI target that has guaranteed IOPS.
>
>For data disks, this process has worked perfectly (first implemented in
>4.2). When I need the datastore, I create an iSCSI target on my SAN, then
>establish a connection to it from each host in the VMware cluster, then
>create a datastore on the target.
>
>When I no longer need the data disk, I remove the iSCSI targets from the
>hosts and the datastore goes away.
>
>This same process works pretty well for root disks (and the other files of
>a VM) except for when I want to delete the VM and get rid of its
>datastore.
>In this case, I follow the same process of removing the iSCSI connections
>from each host in the cluster, but the datastore still shows up in vCenter
>(albeit greyed out and in the inactive state when viewed through vSphere
>Client).
>
>Any thoughts on this? I've looked into this on the web and the general
>consensus is that the datastore is still somehow in use by vCenter. Not
>sure why that would be, though.


Have you checked if the datastore is unmounted from all hosts within the
cluster? When iSCSI target is added as a VMFS datastore, I believe all
hosts within the cluster will mount it automatically. To remove the
datastore from vCenter, you probably need to make sure the datastore is
unmounted from all hosts.





>
>Thanks!
>Mike
>
>
>On Mon, Mar 31, 2014 at 2:45 PM, Kelven Yang 
>wrote:
>
>>
>>
>> On 3/29/14, 7:31 PM, "Sateesh Chodapuneedi"
>>  wrote:
>>
>> >> -Original Message-
>> >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> >> Sent: 30 March 2014 00:06
>> >> To: dev@cloudstack.apache.org
>> >> Subject: [QUESTION] VMware ServerResource
>> >>
>> >> Hi,
>> >>
>> >> Quick question:
>> >>
>> >> For VMware, since we have vCenter Server in the mix as opposed to
>>just
>> >> ESX(i) hosts, I was wondering how that works out with our related
>> >>ServerResources.
>> >>
>> >> For example, if you have a cluster with three ESX hosts, does that
>> >>equate to three ServerResources running on the management server?
>> >Yes, each host is tracked by a server resource. CloudStack retrieves
>> >owning cluster/datacenter as required from vCenter and performs
>>required
>> >operations.
>> >
>> >>
>> >> Assuming that leads to three ServerResources in that situation, if
>>you
>> >>have multiple management servers for your cloud, do all three of
>> >> these ServerResources have to be managed by a single management
>>server
>> >>(because their resources are in the same cluster)?
>> >I think it is not required to be managed by a single management server.
>>
>>
>> Yes, it is not required to be managed by a single management server. One
>> thing to note that, all resource instances are now sharing a pool of
>> vCenter sessions, an instance of such vCenter session is acquired and
>> released by server resource when it needs to perform operations to
>>vCenter.
>>
>>
>> >
>> >>
>> >> Thanks!
>> >>
>> >> --
>> >> *Mike Tutkowski*
>> >> *Senior CloudStack Developer, SolidFire Inc.*
>> >> e: mike.tutkow...@solidfire.com
>> >> o: 303.746.7302
>> >> Advancing the way the world uses the
>> >> cloud
>> >> *(tm)*
>>
>>
>
>
>-- 
>*Mike Tutkowski*
>*Senior CloudStack Developer, SolidFire Inc.*
>e: mike.tutkow...@solidfire.com
>o: 303.746.7302
>Advancing the way the world uses the
>cloud
>*(tm)*

Re: [QUESTION] Unsupported operation on VMware?

2014-03-31 Thread Kelven Yang



On 3/25/14, 1:58 PM, "Mike Tutkowski"  wrote:

>Hi,
>
>I've noticed the following exception on VMware on 4.4 (when trying to
>create a VM from a template and when trying to create a template from a
>volume):
>
>Unsupported command
>issued:org.apache.cloudstack.storage.command.CopyCommand. Are you sure you
>got the right type of server?
>
>Any thoughts on why I might be getting this error?

It looks like the command is sent to the wrong end-point or an endpoint is
running a wrong version of the agent (i.e, SSVM agent)



>
>Thanks,
>
>-- 
>*Mike Tutkowski*
>*Senior CloudStack Developer, SolidFire Inc.*
>e: mike.tutkow...@solidfire.com
>o: 303.746.7302
>Advancing the way the world uses the
>cloud
>*(tm)*

Re: role of HA-Worker

2014-03-31 Thread Kelven Yang

HA-Workers are pool of threads to execute "HA" related tasks, I quoted
"HA" is that not all these tasks are purely issued from HA, since some
operations like putting a host into maintenance mode also use the facility.

ha.workers configures the size of the thread pool. If you set it to 0, you
will have consequences that no worker will help you finish operations like
"Put a host into maintenance" and of course no HA attempt at all.

CLOUDSTACK-6036 is caused by the VM state-sync actions, the decision from
the sync process uses HA worker to perform these harmful actions.
CloudStack 4.4 will address these issues.

Kelven

On 3/25/14, 7:20 AM, "Tomasz Zięba"  wrote:

>Hello,
>
>Could someone explain to me what is the role of HA-Worker thread
>in CloudStack ?
>
>The number of threads is set in the global settings:
>ha.workers Number of hectares of worker threads. 5
>
>According to me, HA-Worker thread has a bug in the implementation that
>causes uncontrolled stopping virtual machines. (CLOUDSTACK-6036).
>
>Which ACS functionality will be lost when the option ha.workers we set to
>0?
>
>Regards,
>
>
>-- 
>Regards,
>Tomasz Zięba
>Twitter: @TZieba
>LinkedIn: 
>pl.linkedin.com/pub/tomasz-zięba-ph-d/3b/7a8/ab6/ub/tomasz-zi%C4%99ba-ph-d/3b/7a8/ab6/>

How to use @Inject

2014-03-31 Thread Alex Ough

All,

I'm trying to change "ComponentContext.getComponent(RmapDao.class)" to
using @Inject, but I can't get the Dao object even after adding a
configuration file with below information.

http://www.springframework.org/schema/beans";
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xmlns:context="http://www.springframework.org/schema/context";
   xmlns:aop="http://www.springframework.org/schema/aop";
   xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
  http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
  http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context-3.0.xsd";
  >







Can anyone show me what needs to be fixed?
Thanks
Alex Ough

[DESIGN] No agent calls within database transactions....

2014-03-31 Thread Alex Huang

Hi All,

I was alerted to this problem recently and it's something that affects 
developers so I want to bring it up.  It is a design principle in CloudStack 
that we do not make agent calls within database transactions.  The reason is 
because when you make a call to an external system, there's no guarantee on how 
long the call takes or even whether the call returns.  When a call takes a long 
time, several bad things can happen:
- The MySQL DB Connection held opened due to the DB transaction goes 
into idle. Eventually, a timeout in MySQL hits and the connection gets severed 
and the transaction is rolled back.  By default, this timeout is 45 seconds but 
can be changed via a parameter in my.cnf.  So it's problem that the agent call 
completes just fine but the DB transaction rolls back and changes are undone.
- The rows locked in that transaction before the remote agent call 
could be holding up other foreign key checks into the table.  MySQL runs 
foreign key checks in transactions to make sure the data modification and the 
checks are done atomically.  Therefore, these checks must wait for other 
transactions to complete.  Hence, an agent call that takes sometime can 
severely slow down the system, particularly under scale.

We have two solutions to this:
- Drive agent interactions with states.  There are many examples of 
this in VM, Volume, etc.
- When the above cannot be done, acquire a lock in the lock table via a 
DAO method call.  Locks do not maintain DB transactions and therefore will not 
run into this problem.  However, you are responsible for releasing locks.  It 
used to be that if you forget to release the locks, the @DB annotation 
automatically releases locks once it went out of the scope and asserts to alert 
the developer.  However, the @DB annotation has been removed in the Spring work 
so I'm not sure if it's still done.  

This is a tough problem to solve because 
1. It usually works just fine during functional testing.  During scale 
testing, this problem surfaces and often in unexpected places due to the 
foreign key check problem.
2. For developers, it is difficult for them to know if a method that 
they're calling within a transaction ends up in an agent call.  

There is an assert in AgentManager to ensure that there are no db transactions 
before making a agent call.  Apparently, since the conversion to Maven, no one 
actually runs with assert on any more.  Due to that, this design principle has 
been lost in CloudStack and we're finding more and more calls being made in DB 
transactions.   To counter that, I decided to add a global parameter that turns 
the assert to an actual exception.  It is advised that all developers set this 
global parameter, check.txn.before.sending.agent.commands, during their own 
testing to make sure it doesn't call agent calls in transactions.

--Alex

Re: [QUESTION] VMware ServerResource

2014-03-31 Thread Mike Tutkowski

Interesting...I can look into that. Do you know off hand if we already have
such a call to perform an unmount?

Thanks, Kelven!


On Mon, Mar 31, 2014 at 3:28 PM, Kelven Yang  wrote:

>
> On 3/31/14, 1:54 PM, "Mike Tutkowski" 
> wrote:
>
> >Hi Kelven,
> >
> >Thanks for the info!
> >
> >I have another question that perhaps you can answer.
> >
> >In my situation, with managed storage, I need to create and delete
> >datastores dynamically. The idea is to have a single VM (and all of its
> >corresponding files) or a single VMDK data disk file per datastore in some
> >cases so we can guarantee IOPS to the VM or data disk.
> >
> >Each datastore is based on an iSCSI target that has guaranteed IOPS.
> >
> >For data disks, this process has worked perfectly (first implemented in
> >4.2). When I need the datastore, I create an iSCSI target on my SAN, then
> >establish a connection to it from each host in the VMware cluster, then
> >create a datastore on the target.
> >
> >When I no longer need the data disk, I remove the iSCSI targets from the
> >hosts and the datastore goes away.
> >
> >This same process works pretty well for root disks (and the other files of
> >a VM) except for when I want to delete the VM and get rid of its
> >datastore.
> >In this case, I follow the same process of removing the iSCSI connections
> >from each host in the cluster, but the datastore still shows up in vCenter
> >(albeit greyed out and in the inactive state when viewed through vSphere
> >Client).
> >
> >Any thoughts on this? I've looked into this on the web and the general
> >consensus is that the datastore is still somehow in use by vCenter. Not
> >sure why that would be, though.
>
>
> Have you checked if the datastore is unmounted from all hosts within the
> cluster? When iSCSI target is added as a VMFS datastore, I believe all
> hosts within the cluster will mount it automatically. To remove the
> datastore from vCenter, you probably need to make sure the datastore is
> unmounted from all hosts.
>
>
>
>
>
> >
> >Thanks!
> >Mike
> >
> >
> >On Mon, Mar 31, 2014 at 2:45 PM, Kelven Yang 
> >wrote:
> >
> >>
> >>
> >> On 3/29/14, 7:31 PM, "Sateesh Chodapuneedi"
> >>  wrote:
> >>
> >> >> -Original Message-
> >> >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> >> >> Sent: 30 March 2014 00:06
> >> >> To: dev@cloudstack.apache.org
> >> >> Subject: [QUESTION] VMware ServerResource
> >> >>
> >> >> Hi,
> >> >>
> >> >> Quick question:
> >> >>
> >> >> For VMware, since we have vCenter Server in the mix as opposed to
> >>just
> >> >> ESX(i) hosts, I was wondering how that works out with our related
> >> >>ServerResources.
> >> >>
> >> >> For example, if you have a cluster with three ESX hosts, does that
> >> >>equate to three ServerResources running on the management server?
> >> >Yes, each host is tracked by a server resource. CloudStack retrieves
> >> >owning cluster/datacenter as required from vCenter and performs
> >>required
> >> >operations.
> >> >
> >> >>
> >> >> Assuming that leads to three ServerResources in that situation, if
> >>you
> >> >>have multiple management servers for your cloud, do all three of
> >> >> these ServerResources have to be managed by a single management
> >>server
> >> >>(because their resources are in the same cluster)?
> >> >I think it is not required to be managed by a single management server.
> >>
> >>
> >> Yes, it is not required to be managed by a single management server. One
> >> thing to note that, all resource instances are now sharing a pool of
> >> vCenter sessions, an instance of such vCenter session is acquired and
> >> released by server resource when it needs to perform operations to
> >>vCenter.
> >>
> >>
> >> >
> >> >>
> >> >> Thanks!
> >> >>
> >> >> --
> >> >> *Mike Tutkowski*
> >> >> *Senior CloudStack Developer, SolidFire Inc.*
> >> >> e: mike.tutkow...@solidfire.com
> >> >> o: 303.746.7302
> >> >> Advancing the way the world uses the
> >> >> cloud
> >> >> *(tm)*
> >>
> >>
> >
> >
> >--
> >*Mike Tutkowski*
> >*Senior CloudStack Developer, SolidFire Inc.*
> >e: mike.tutkow...@solidfire.com
> >o: 303.746.7302
> >Advancing the way the world uses the
> >cloud
> >*(tm)*
>
>


-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*

Re: [QUESTION] Unsupported operation on VMware?

2014-03-31 Thread Mike Tutkowski

Thanks, Kelven...once I updated, this end-point problem went away. Weird


On Mon, Mar 31, 2014 at 3:34 PM, Kelven Yang  wrote:

>
>
> On 3/25/14, 1:58 PM, "Mike Tutkowski" 
> wrote:
>
> >Hi,
> >
> >I've noticed the following exception on VMware on 4.4 (when trying to
> >create a VM from a template and when trying to create a template from a
> >volume):
> >
> >Unsupported command
> >issued:org.apache.cloudstack.storage.command.CopyCommand. Are you sure you
> >got the right type of server?
> >
> >Any thoughts on why I might be getting this error?
>
> It looks like the command is sent to the wrong end-point or an endpoint is
> running a wrong version of the agent (i.e, SSVM agent)
>
>
>
> >
> >Thanks,
> >
> >--
> >*Mike Tutkowski*
> >*Senior CloudStack Developer, SolidFire Inc.*
> >e: mike.tutkow...@solidfire.com
> >o: 303.746.7302
> >Advancing the way the world uses the
> >cloud
> >*(tm)*
>
>


-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*

Re: [DESIGN] No agent calls within database transactions....

2014-03-31 Thread Marcus

Yeah, that assert issue has bitten us once or twice, and I know Ryan
squawked about it at some point.  Do we have any point where
enforcement will occur (BVT or some other tests)?

On Mon, Mar 31, 2014 at 4:04 PM, Alex Huang  wrote:
> Hi All,
>
> I was alerted to this problem recently and it's something that affects 
> developers so I want to bring it up.  It is a design principle in CloudStack 
> that we do not make agent calls within database transactions.  The reason is 
> because when you make a call to an external system, there's no guarantee on 
> how long the call takes or even whether the call returns.  When a call takes 
> a long time, several bad things can happen:
> - The MySQL DB Connection held opened due to the DB transaction goes 
> into idle. Eventually, a timeout in MySQL hits and the connection gets 
> severed and the transaction is rolled back.  By default, this timeout is 45 
> seconds but can be changed via a parameter in my.cnf.  So it's problem that 
> the agent call completes just fine but the DB transaction rolls back and 
> changes are undone.
> - The rows locked in that transaction before the remote agent call 
> could be holding up other foreign key checks into the table.  MySQL runs 
> foreign key checks in transactions to make sure the data modification and the 
> checks are done atomically.  Therefore, these checks must wait for other 
> transactions to complete.  Hence, an agent call that takes sometime can 
> severely slow down the system, particularly under scale.
>
> We have two solutions to this:
> - Drive agent interactions with states.  There are many examples of 
> this in VM, Volume, etc.
> - When the above cannot be done, acquire a lock in the lock table via 
> a DAO method call.  Locks do not maintain DB transactions and therefore will 
> not run into this problem.  However, you are responsible for releasing locks. 
>  It used to be that if you forget to release the locks, the @DB annotation 
> automatically releases locks once it went out of the scope and asserts to 
> alert the developer.  However, the @DB annotation has been removed in the 
> Spring work so I'm not sure if it's still done.
>
> This is a tough problem to solve because
> 1. It usually works just fine during functional testing.  During 
> scale testing, this problem surfaces and often in unexpected places due to 
> the foreign key check problem.
> 2. For developers, it is difficult for them to know if a method that 
> they're calling within a transaction ends up in an agent call.
>
> There is an assert in AgentManager to ensure that there are no db 
> transactions before making a agent call.  Apparently, since the conversion to 
> Maven, no one actually runs with assert on any more.  Due to that, this 
> design principle has been lost in CloudStack and we're finding more and more 
> calls being made in DB transactions.   To counter that, I decided to add a 
> global parameter that turns the assert to an actual exception.  It is advised 
> that all developers set this global parameter, 
> check.txn.before.sending.agent.commands, during their own testing to make 
> sure it doesn't call agent calls in transactions.
>
> --Alex
>
>

OVS plugin communication failure (CS 4.3.0)

2014-03-31 Thread Florin Dumitrascu

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 ?

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(CitrixResourceBase.java:4239)
at 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5685)
at 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:567)
at 
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
at 
com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
at 
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.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.

[BUG ACS 4.3] Cannot delete and re-add IP range on guest network

2014-03-31 Thread ilya musayev


Hi All,

Just trying to raise awareness for the issue we are seeing on 4.3 with 
IP management of guest vlans: details of JIRA issue 
https://issues.apache.org/jira/browse/CLOUDSTACK-6312


--
I've realized that i over allocated IP addresses for some of guest 
VLANs, so i went ahead and deleted all guests using the VLAN in question 
to free ip space in use.


2 issues noticed:

1) The router that were using Guest VLAN in question after deletion did 
not release the IP space, the record had to be de-allocated via mysql


2)After the guest ip range has been deleted, i attempted to add the same 
network with smaller IP range, cloudstack now claims that IP range does 
not match - while it does!


Regards
ilya

Re: Interesting 4.2.1. Issue...

2014-03-31 Thread Marcus

I'm running 3 mgmt servers on 4.2.1, haven't seen any issues like
that. You can send along your memory settings... here's what I'm
running:

JAVA_OPTS="-Djava.awt.headless=true
-Dcom.sun.management.jmxremote.port=45219
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false -Xmx2g
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M
-XX:MaxPermSize=800m

On Mon, Mar 31, 2014 at 9:33 AM, Michael Phillips
 wrote:
> So I have a redundant pair of management servers running on 4.2.1. At least 
> once a day one of the management servers crashes and the log gets filled with 
> the following messages:
> java.lang.OutOfMemoryError: Java heap 
> spac0java.lang.ArrayIndexOutOfBoundsExceptioneCaused by: 
> java.io.EOFException: SSL peer shut down incorrectlyCaused by: 
> javax.net.ssl.SSLHandshakeException: Remote host closed connection during 
> handshake
> and there are a few others. When the one management server tanks, although 
> the other management server is up and active, it won't actually process any 
> UI commands until the crashed server is restarted.  Example of won't process 
> any UI command is create a new instance, create a new account, etc. After 
> doing some searching I have found that others have noticed java heap errors 
> in 4.2.1, and the suggested fix is to increase the heap size. I am planning 
> on increasing it from 2g to 4g, however if the problem is something like a 
> memory leak, then increasing the heap size will just delay the inevitable. 
> Has anyone else fixed this issue by increasing the heap size? Or what is the 
> recommended value? **updated...as expected I increased the heap size from 2g 
> to 4g, and it just took longer for the problem to reoccur...
> In my honest opinion of bigger concern is the fact that when one management 
> server crashes the other stops functioning as well. So this begs the question 
> of why even bother with a redundant pair of servers..Anybody else experience 
> this issue? I would love to hear any dev guys opinion on this

Re: [BUG ACS 4.3] Cannot delete and re-add IP range on guest network

2014-03-31 Thread ilya musayev


+1 more issue, cannot delete blank guest vlan

https://issues.apache.org/jira/browse/CLOUDSTACK-6313

On 3/31/14, 3:19 PM, ilya musayev wrote:

Hi All,

Just trying to raise awareness for the issue we are seeing on 4.3 with 
IP management of guest vlans: details of JIRA issue 
https://issues.apache.org/jira/browse/CLOUDSTACK-6312


--
I've realized that i over allocated IP addresses for some of guest 
VLANs, so i went ahead and deleted all guests using the VLAN in 
question to free ip space in use.


2 issues noticed:

1) The router that were using Guest VLAN in question after deletion 
did not release the IP space, the record had to be de-allocated via mysql


2)After the guest ip range has been deleted, i attempted to add the 
same network with smaller IP range, cloudstack now claims that IP 
range does not match - while it does!


Regards
ilya

Re: [QUESTION] VMware ServerResource

2014-03-31 Thread Kelven Yang

Would this KB article helpful? Particularly, it seems that Stroage IO
control needs to disabled before detaching the datastore.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=di
splayKC&externalId=2004605

Kelven

On 3/31/14, 3:14 PM, "Mike Tutkowski"  wrote:

>Interesting...I can look into that. Do you know off hand if we already
>have
>such a call to perform an unmount?
>
>Thanks, Kelven!
>
>
>On Mon, Mar 31, 2014 at 3:28 PM, Kelven Yang 
>wrote:
>
>>
>> On 3/31/14, 1:54 PM, "Mike Tutkowski" 
>> wrote:
>>
>> >Hi Kelven,
>> >
>> >Thanks for the info!
>> >
>> >I have another question that perhaps you can answer.
>> >
>> >In my situation, with managed storage, I need to create and delete
>> >datastores dynamically. The idea is to have a single VM (and all of its
>> >corresponding files) or a single VMDK data disk file per datastore in
>>some
>> >cases so we can guarantee IOPS to the VM or data disk.
>> >
>> >Each datastore is based on an iSCSI target that has guaranteed IOPS.
>> >
>> >For data disks, this process has worked perfectly (first implemented in
>> >4.2). When I need the datastore, I create an iSCSI target on my SAN,
>>then
>> >establish a connection to it from each host in the VMware cluster, then
>> >create a datastore on the target.
>> >
>> >When I no longer need the data disk, I remove the iSCSI targets from
>>the
>> >hosts and the datastore goes away.
>> >
>> >This same process works pretty well for root disks (and the other
>>files of
>> >a VM) except for when I want to delete the VM and get rid of its
>> >datastore.
>> >In this case, I follow the same process of removing the iSCSI
>>connections
>> >from each host in the cluster, but the datastore still shows up in
>>vCenter
>> >(albeit greyed out and in the inactive state when viewed through
>>vSphere
>> >Client).
>> >
>> >Any thoughts on this? I've looked into this on the web and the general
>> >consensus is that the datastore is still somehow in use by vCenter. Not
>> >sure why that would be, though.
>>
>>
>> Have you checked if the datastore is unmounted from all hosts within the
>> cluster? When iSCSI target is added as a VMFS datastore, I believe all
>> hosts within the cluster will mount it automatically. To remove the
>> datastore from vCenter, you probably need to make sure the datastore is
>> unmounted from all hosts.
>>
>>
>>
>>
>>
>> >
>> >Thanks!
>> >Mike
>> >
>> >
>> >On Mon, Mar 31, 2014 at 2:45 PM, Kelven Yang 
>> >wrote:
>> >
>> >>
>> >>
>> >> On 3/29/14, 7:31 PM, "Sateesh Chodapuneedi"
>> >>  wrote:
>> >>
>> >> >> -Original Message-
>> >> >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> >> >> Sent: 30 March 2014 00:06
>> >> >> To: dev@cloudstack.apache.org
>> >> >> Subject: [QUESTION] VMware ServerResource
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> Quick question:
>> >> >>
>> >> >> For VMware, since we have vCenter Server in the mix as opposed to
>> >>just
>> >> >> ESX(i) hosts, I was wondering how that works out with our related
>> >> >>ServerResources.
>> >> >>
>> >> >> For example, if you have a cluster with three ESX hosts, does that
>> >> >>equate to three ServerResources running on the management server?
>> >> >Yes, each host is tracked by a server resource. CloudStack retrieves
>> >> >owning cluster/datacenter as required from vCenter and performs
>> >>required
>> >> >operations.
>> >> >
>> >> >>
>> >> >> Assuming that leads to three ServerResources in that situation, if
>> >>you
>> >> >>have multiple management servers for your cloud, do all three of
>> >> >> these ServerResources have to be managed by a single management
>> >>server
>> >> >>(because their resources are in the same cluster)?
>> >> >I think it is not required to be managed by a single management
>>server.
>> >>
>> >>
>> >> Yes, it is not required to be managed by a single management server.
>>One
>> >> thing to note that, all resource instances are now sharing a pool of
>> >> vCenter sessions, an instance of such vCenter session is acquired and
>> >> released by server resource when it needs to perform operations to
>> >>vCenter.
>> >>
>> >>
>> >> >
>> >> >>
>> >> >> Thanks!
>> >> >>
>> >> >> --
>> >> >> *Mike Tutkowski*
>> >> >> *Senior CloudStack Developer, SolidFire Inc.*
>> >> >> e: mike.tutkow...@solidfire.com
>> >> >> o: 303.746.7302
>> >> >> Advancing the way the world uses the
>> >> >> cloud
>> >> >> *(tm)*
>> >>
>> >>
>> >
>> >
>> >--
>> >*Mike Tutkowski*
>> >*Senior CloudStack Developer, SolidFire Inc.*
>> >e: mike.tutkow...@solidfire.com
>> >o: 303.746.7302
>> >Advancing the way the world uses the
>> >cloud
>> >*(tm)*
>>
>>
>
>
>-- 
>*Mike Tutkowski*
>*Senior CloudStack Developer, SolidFire Inc.*
>e: mike.tutkow...@solidfire.com
>o: 303.746.7302
>Advancing the way the world uses the
>cloud
>*(tm)*

Re: [QUESTION] VMware ServerResource

2014-03-31 Thread Mike Tutkowski

Thanks, Kelven...I had seen a similar article about Storage IO
Control...perhaps the article you pointed to has more info.


On Mon, Mar 31, 2014 at 4:38 PM, Kelven Yang  wrote:

> Would this KB article helpful? Particularly, it seems that Stroage IO
> control needs to disabled before detaching the datastore.
>
> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=di
> splayKC&externalId=2004605
>
> Kelven
>
> On 3/31/14, 3:14 PM, "Mike Tutkowski" 
> wrote:
>
> >Interesting...I can look into that. Do you know off hand if we already
> >have
> >such a call to perform an unmount?
> >
> >Thanks, Kelven!
> >
> >
> >On Mon, Mar 31, 2014 at 3:28 PM, Kelven Yang 
> >wrote:
> >
> >>
> >> On 3/31/14, 1:54 PM, "Mike Tutkowski" 
> >> wrote:
> >>
> >> >Hi Kelven,
> >> >
> >> >Thanks for the info!
> >> >
> >> >I have another question that perhaps you can answer.
> >> >
> >> >In my situation, with managed storage, I need to create and delete
> >> >datastores dynamically. The idea is to have a single VM (and all of its
> >> >corresponding files) or a single VMDK data disk file per datastore in
> >>some
> >> >cases so we can guarantee IOPS to the VM or data disk.
> >> >
> >> >Each datastore is based on an iSCSI target that has guaranteed IOPS.
> >> >
> >> >For data disks, this process has worked perfectly (first implemented in
> >> >4.2). When I need the datastore, I create an iSCSI target on my SAN,
> >>then
> >> >establish a connection to it from each host in the VMware cluster, then
> >> >create a datastore on the target.
> >> >
> >> >When I no longer need the data disk, I remove the iSCSI targets from
> >>the
> >> >hosts and the datastore goes away.
> >> >
> >> >This same process works pretty well for root disks (and the other
> >>files of
> >> >a VM) except for when I want to delete the VM and get rid of its
> >> >datastore.
> >> >In this case, I follow the same process of removing the iSCSI
> >>connections
> >> >from each host in the cluster, but the datastore still shows up in
> >>vCenter
> >> >(albeit greyed out and in the inactive state when viewed through
> >>vSphere
> >> >Client).
> >> >
> >> >Any thoughts on this? I've looked into this on the web and the general
> >> >consensus is that the datastore is still somehow in use by vCenter. Not
> >> >sure why that would be, though.
> >>
> >>
> >> Have you checked if the datastore is unmounted from all hosts within the
> >> cluster? When iSCSI target is added as a VMFS datastore, I believe all
> >> hosts within the cluster will mount it automatically. To remove the
> >> datastore from vCenter, you probably need to make sure the datastore is
> >> unmounted from all hosts.
> >>
> >>
> >>
> >>
> >>
> >> >
> >> >Thanks!
> >> >Mike
> >> >
> >> >
> >> >On Mon, Mar 31, 2014 at 2:45 PM, Kelven Yang 
> >> >wrote:
> >> >
> >> >>
> >> >>
> >> >> On 3/29/14, 7:31 PM, "Sateesh Chodapuneedi"
> >> >>  wrote:
> >> >>
> >> >> >> -Original Message-
> >> >> >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> >> >> >> Sent: 30 March 2014 00:06
> >> >> >> To: dev@cloudstack.apache.org
> >> >> >> Subject: [QUESTION] VMware ServerResource
> >> >> >>
> >> >> >> Hi,
> >> >> >>
> >> >> >> Quick question:
> >> >> >>
> >> >> >> For VMware, since we have vCenter Server in the mix as opposed to
> >> >>just
> >> >> >> ESX(i) hosts, I was wondering how that works out with our related
> >> >> >>ServerResources.
> >> >> >>
> >> >> >> For example, if you have a cluster with three ESX hosts, does that
> >> >> >>equate to three ServerResources running on the management server?
> >> >> >Yes, each host is tracked by a server resource. CloudStack retrieves
> >> >> >owning cluster/datacenter as required from vCenter and performs
> >> >>required
> >> >> >operations.
> >> >> >
> >> >> >>
> >> >> >> Assuming that leads to three ServerResources in that situation, if
> >> >>you
> >> >> >>have multiple management servers for your cloud, do all three of
> >> >> >> these ServerResources have to be managed by a single management
> >> >>server
> >> >> >>(because their resources are in the same cluster)?
> >> >> >I think it is not required to be managed by a single management
> >>server.
> >> >>
> >> >>
> >> >> Yes, it is not required to be managed by a single management server.
> >>One
> >> >> thing to note that, all resource instances are now sharing a pool of
> >> >> vCenter sessions, an instance of such vCenter session is acquired and
> >> >> released by server resource when it needs to perform operations to
> >> >>vCenter.
> >> >>
> >> >>
> >> >> >
> >> >> >>
> >> >> >> Thanks!
> >> >> >>
> >> >> >> --
> >> >> >> *Mike Tutkowski*
> >> >> >> *Senior CloudStack Developer, SolidFire Inc.*
> >> >> >> e: mike.tutkow...@solidfire.com
> >> >> >> o: 303.746.7302
> >> >> >> Advancing the way the world uses the
> >> >> >> cloud
> >> >> >> *(tm)*
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >*Mike Tutkowski*
> >> >*Senior CloudStack D

Re: How to use @Inject

2014-03-31 Thread Alex Ough

It seems like I wrote a wrong type in ComponentContext.
getComponent(RmapDao.class).
It should be ComponentContext.getComponent(DomainDao.class)

Thanks
Alex Ough


On Mon, Mar 31, 2014 at 5:53 PM, Alex Ough  wrote:

> All,
>
> I'm trying to change "ComponentContext.getComponent(RmapDao.class)" to
> using @Inject, but I can't get the Dao object even after adding a
> configuration file with below information.
>
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:context="http://www.springframework.org/schema/context";
>xmlns:aop="http://www.springframework.org/schema/aop";
>xsi:schemaLocation="http://www.springframework.org/schema/beans
>
> http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
>   http://www.springframework.org/schema/aop
> http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
>   http://www.springframework.org/schema/context
>
> http://www.springframework.org/schema/context/spring-context-3.0.xsd";
>   >
>
> 
> 
> 
>
> 
>
> Can anyone show me what needs to be fixed?
> Thanks
> Alex Ough
>
>

RE: [DESIGN] No agent calls within database transactions....

2014-03-31 Thread Alex Huang

Assert should always be on when we're QAing the system, including BVT.  I've 
alerted many people who work on QA about that.  Unfortunately, that's a 
deployment time setting so it's up the deployer who's running the BVT to set 
that.  Perhaps, we can write a script to perform QA deployment and it has all 
of these things set already.  That way QA deployment is always the same.

--Alex

> -Original Message-
> From: Marcus [mailto:shadow...@gmail.com]
> Sent: Monday, March 31, 2014 3:15 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DESIGN] No agent calls within database transactions
> 
> Yeah, that assert issue has bitten us once or twice, and I know Ryan
> squawked about it at some point.  Do we have any point where enforcement
> will occur (BVT or some other tests)?
> 
> On Mon, Mar 31, 2014 at 4:04 PM, Alex Huang 
> wrote:
> > Hi All,
> >
> > I was alerted to this problem recently and it's something that affects
> developers so I want to bring it up.  It is a design principle in CloudStack 
> that
> we do not make agent calls within database transactions.  The reason is
> because when you make a call to an external system, there's no guarantee
> on how long the call takes or even whether the call returns.  When a call
> takes a long time, several bad things can happen:
> > - The MySQL DB Connection held opened due to the DB transaction
> goes into idle. Eventually, a timeout in MySQL hits and the connection gets
> severed and the transaction is rolled back.  By default, this timeout is 45
> seconds but can be changed via a parameter in my.cnf.  So it's problem that
> the agent call completes just fine but the DB transaction rolls back and
> changes are undone.
> > - The rows locked in that transaction before the remote agent call 
> > could
> be holding up other foreign key checks into the table.  MySQL runs foreign
> key checks in transactions to make sure the data modification and the checks
> are done atomically.  Therefore, these checks must wait for other
> transactions to complete.  Hence, an agent call that takes sometime can
> severely slow down the system, particularly under scale.
> >
> > We have two solutions to this:
> > - Drive agent interactions with states.  There are many examples of 
> > this
> in VM, Volume, etc.
> > - When the above cannot be done, acquire a lock in the lock table 
> > via a
> DAO method call.  Locks do not maintain DB transactions and therefore will
> not run into this problem.  However, you are responsible for releasing locks.
> It used to be that if you forget to release the locks, the @DB annotation
> automatically releases locks once it went out of the scope and asserts to 
> alert
> the developer.  However, the @DB annotation has been removed in the
> Spring work so I'm not sure if it's still done.
> >
> > This is a tough problem to solve because
> > 1. It usually works just fine during functional testing.  During 
> > scale
> testing, this problem surfaces and often in unexpected places due to the
> foreign key check problem.
> > 2. For developers, it is difficult for them to know if a method that
> they're calling within a transaction ends up in an agent call.
> >
> > There is an assert in AgentManager to ensure that there are no db
> transactions before making a agent call.  Apparently, since the conversion to
> Maven, no one actually runs with assert on any more.  Due to that, this
> design principle has been lost in CloudStack and we're finding more and more
> calls being made in DB transactions.   To counter that, I decided to add a
> global parameter that turns the assert to an actual exception.  It is advised
> that all developers set this global parameter,
> check.txn.before.sending.agent.commands, during their own testing to
> make sure it doesn't call agent calls in transactions.
> >
> > --Alex
> >
> >

devCloud2 and master

2014-03-31 Thread Sachchidanand Vaidya

Hi All,
   I'm trying to run devCloud2 with CS Management server running master code.
Setup is: CS Mgmt Server: 192.168.56.1, XenHost ova:192.168.56.10

-> While trying to setup Basic networking using (devcloud.cfg), got "Cannot 
create directory /opt/cloud/bin on XenServer hosts"
error during addHost. Anyone facing similar issue ?

-> I can manually ssh to xenhost(192.168.56.10) and also execute the command  
"mkdir -p /opt/cloud/bin /var/log/cloud"
without any error.

INFO  [c.c.h.x.d.XcpServerDiscoverer] (562467077@qtp-957221885-0:ctx-3b4e545f 
ctx-af9f99c3 ctx-87169cf4) Host: devcloud connected with hypervisor type: 
XenServer. Checking CIDR...
INFO  [c.c.a.m.DirectAgentAttache] (562467077@qtp-957221885-0:ctx-3b4e545f 
ctx-af9f99c3 ctx-87169cf4) StartupAnswer received 1 Interval = 60
WARN  [c.c.a.m.DirectAgentAttache] (DirectAgent-1:ctx-0439d91d) Seq 
1-5104267227671035905: Exception Caught while executing command
com.cloud.utils.exception.CloudRuntimeException: Cannot create directory 
/opt/cloud/bin on XenServer hosts
at 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.setupServer(CitrixResourceBase.java:4892)
at 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4718)
at 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:497)
at 
com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOssResource.java:176)
at 
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
WARN  [c.c.h.x.d.XcpServerDiscoverer] (562467077@qtp-957221885-0:ctx-3b4e545f 
ctx-af9f99c3 ctx-87169cf4) Unable to setup agent 1 due to 
com.cloud.utils.exception.CloudRuntimeException: Cannot create directory 
/opt/cloud/bin on XenServer hosts


-> In addition to above error, also seeing following errors during datacenter 
deployment..
WARN  [c.c.a.d.ParamGenericValidationWorker] (API-Job-Executor-1:Job-5 
ctx-45552650) Received unknown parameters for command createPhysicalNetwork. 
Unknown parameters : ctxstarteventid
INFO  [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-1:Job-5) Remove job-5 
from job monitoring
INFO  [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-2:Job-6) Add job-6 into 
job monitoring
WARN  [c.c.a.d.ParamGenericValidationWorker] (API-Job-Executor-2:Job-6 
ctx-8ec87166) Received unknown parameters for command addTrafficType. Unknown 
parameters : ctxstarteventid
INFO  [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-2:Job-6) Remove job-6 
from job monitoring
INFO  [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-3:Job-7) Add job-7 into 
job monitoring
WARN  [c.c.a.d.ParamGenericValidationWorker] (API-Job-Executor-3:Job-7 
ctx-3804814f) Received unknown parameters for command addTrafficType. Unknown 
parameters : ctxstarteventid
INFO  [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-3:Job-7) Remove job-7 
from job monitoring
INFO  [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-4:Job-8) Add job-8 into 
job monitoring
WARN  [c.c.a.d.ParamGenericValidationWorker] (API-Job-Executor-4:Job-8 
ctx-62121f8f) Received unknown parameters for command 
configureVirtualRouterElement. Unknown parameters : ctxstarteventid
INFO  [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-4:Job-8) Remove job-8 
from job monitoring
INFO  [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-5:Job-9) Add job-9 into 
job monitoring
WARN  [c.c.a.d.ParamGenericValidationWorker] (API-Job-Executor-5:Job-9 
ctx-31297f1c) Received unknown parameters for command 
updateNetworkServiceProvider. Unknown parameters : ctxstarteventid
INFO  [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-5:Job-9) Remove job-9 
from job monitoring
INFO  [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-6:Job-10) Add job-10 into 
job monitoring
WARN  [c.c.a.d.ParamGenericValidationWorker] (API-Job-Executor-6:Job-10 
ctx-95dd4c17) Received unknown paramete

Re: devCloud2 and master

2014-03-31 Thread dimas yoga pratama

Hi,

I'm facing similar issue and can't go any further

WARN  [c.c.a.d.
ParamGenericValidationWorker] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Received unknown parameters for command addHost. Unknown
parameters : clustertype
INFO  [c.c.r.ResourceManagerImpl] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Trying to add a new host at http://192.168.56.10 in data
center 2
INFO  [c.c.h.x.d.XcpServerDiscoverer] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Found host devcloud ip=192.168.56.10 product version=1.6.0
INFO  [c.c.h.x.r.CitrixResourceBase] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Private Network is Pool-wide network associated with eth0 for
host 192.168.56.10
INFO  [c.c.h.x.r.CitrixResourceBase] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Guest Network is Pool-wide network associated with eth0 for
host 192.168.56.10
INFO  [c.c.h.x.r.CitrixResourceBase] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Public Network is Pool-wide network associated with eth0 for
host 192.168.56.10
INFO  [c.c.h.x.d.XcpServerDiscoverer] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Host: devcloud connected with hypervisor type: XenServer.
Checking CIDR...
INFO  [c.c.a.m.DirectAgentAttache] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) StartupAnswer received 4 Interval = 60
WARN  [c.c.a.m.DirectAgentAttache] (DirectAgent-2:ctx-1dd57f8e) Seq
4-7148901458497241089: Exception Caught while executing command
com.cloud.utils.exception.CloudRuntimeException: Cannot create directory
/opt/cloud/bin on XenServer hosts
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.setupServer(CitrixResourceBase.java:4892)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4718)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:497)
at
com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOssResource.java:176)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
WARN  [c.c.h.x.d.XcpServerDiscoverer] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Unable to setup agent 4 due to
com.cloud.utils.exception.CloudRuntimeException: Cannot create directory
/opt/cloud/bin on XenServer hosts
INFO  [c.c.u.e.CSExceptionErrorCode] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Could not find exception:
com.cloud.exception.ConnectionException in error code list for exceptions
WARN  [c.c.a.m.AgentManagerImpl] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Monitor XcpServerDiscoverer says there is an error in the
connect process for 4 due to Reinitialize agent after setup.
INFO  [c.c.a.m.AgentManagerImpl] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Host 4 is disconnecting with event AgentDisconnected
WARN  [c.c.r.ResourceManagerImpl] (1583536287@qtp-102099346-7:ctx-d4dd6064
ctx-08f90d59) Unable to connect due to
com.cloud.exception.ConnectionException: Reinitialize agent after setup.
at
com.cloud.hypervisor.xen.discoverer.XcpServerDiscoverer.processConnect(XcpServerDiscoverer.java:647)
at
com.cloud.agent.manager.AgentManagerImpl.notifyMonitorsOfConnection(AgentManagerImpl.java:514)
at
com.cloud.agent.manager.AgentManagerImpl.handleDirectConnectAgent(AgentManagerImpl.java:1427)
at
com.cloud.resource.ResourceManagerImpl.createHostAndAgent(ResourceManagerImpl.java:1764)
at
com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:773)
at
com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAcces

Re: [QUESTION] VMware ServerResource

2014-03-31 Thread Mike Tutkowski

Interesting...when I try to unmount the datastore prior to removing the
iSCSI connections, I get a similar error to when I straight-out try to
delete the datastore prior to removing the iSCSI connections: it says the
datastore is still in use.

When I look at the contents of the datastore, there doesn't appear to be
anything on it.

There is a clue in the fact that this is only a problem if a VM was running
off of this datastore. If the datastore was only used to house a VMDK file
for a data disk, there is no problem removing it by getting rid of the
iSCSI connections to the SAN volume from the hosts.


On Mon, Mar 31, 2014 at 4:44 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Thanks, Kelven...I had seen a similar article about Storage IO
> Control...perhaps the article you pointed to has more info.
>
>
> On Mon, Mar 31, 2014 at 4:38 PM, Kelven Yang wrote:
>
>> Would this KB article helpful? Particularly, it seems that Stroage IO
>> control needs to disabled before detaching the datastore.
>>
>>
>> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=di
>> splayKC&externalId=2004605
>>
>> Kelven
>>
>> On 3/31/14, 3:14 PM, "Mike Tutkowski" 
>> wrote:
>>
>> >Interesting...I can look into that. Do you know off hand if we already
>> >have
>> >such a call to perform an unmount?
>> >
>> >Thanks, Kelven!
>> >
>> >
>> >On Mon, Mar 31, 2014 at 3:28 PM, Kelven Yang 
>> >wrote:
>> >
>> >>
>> >> On 3/31/14, 1:54 PM, "Mike Tutkowski" 
>> >> wrote:
>> >>
>> >> >Hi Kelven,
>> >> >
>> >> >Thanks for the info!
>> >> >
>> >> >I have another question that perhaps you can answer.
>> >> >
>> >> >In my situation, with managed storage, I need to create and delete
>> >> >datastores dynamically. The idea is to have a single VM (and all of
>> its
>> >> >corresponding files) or a single VMDK data disk file per datastore in
>> >>some
>> >> >cases so we can guarantee IOPS to the VM or data disk.
>> >> >
>> >> >Each datastore is based on an iSCSI target that has guaranteed IOPS.
>> >> >
>> >> >For data disks, this process has worked perfectly (first implemented
>> in
>> >> >4.2). When I need the datastore, I create an iSCSI target on my SAN,
>> >>then
>> >> >establish a connection to it from each host in the VMware cluster,
>> then
>> >> >create a datastore on the target.
>> >> >
>> >> >When I no longer need the data disk, I remove the iSCSI targets from
>> >>the
>> >> >hosts and the datastore goes away.
>> >> >
>> >> >This same process works pretty well for root disks (and the other
>> >>files of
>> >> >a VM) except for when I want to delete the VM and get rid of its
>> >> >datastore.
>> >> >In this case, I follow the same process of removing the iSCSI
>> >>connections
>> >> >from each host in the cluster, but the datastore still shows up in
>> >>vCenter
>> >> >(albeit greyed out and in the inactive state when viewed through
>> >>vSphere
>> >> >Client).
>> >> >
>> >> >Any thoughts on this? I've looked into this on the web and the general
>> >> >consensus is that the datastore is still somehow in use by vCenter.
>> Not
>> >> >sure why that would be, though.
>> >>
>> >>
>> >> Have you checked if the datastore is unmounted from all hosts within
>> the
>> >> cluster? When iSCSI target is added as a VMFS datastore, I believe all
>> >> hosts within the cluster will mount it automatically. To remove the
>> >> datastore from vCenter, you probably need to make sure the datastore is
>> >> unmounted from all hosts.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> >
>> >> >Thanks!
>> >> >Mike
>> >> >
>> >> >
>> >> >On Mon, Mar 31, 2014 at 2:45 PM, Kelven Yang 
>> >> >wrote:
>> >> >
>> >> >>
>> >> >>
>> >> >> On 3/29/14, 7:31 PM, "Sateesh Chodapuneedi"
>> >> >>  wrote:
>> >> >>
>> >> >> >> -Original Message-
>> >> >> >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> >> >> >> Sent: 30 March 2014 00:06
>> >> >> >> To: dev@cloudstack.apache.org
>> >> >> >> Subject: [QUESTION] VMware ServerResource
>> >> >> >>
>> >> >> >> Hi,
>> >> >> >>
>> >> >> >> Quick question:
>> >> >> >>
>> >> >> >> For VMware, since we have vCenter Server in the mix as opposed to
>> >> >>just
>> >> >> >> ESX(i) hosts, I was wondering how that works out with our related
>> >> >> >>ServerResources.
>> >> >> >>
>> >> >> >> For example, if you have a cluster with three ESX hosts, does
>> that
>> >> >> >>equate to three ServerResources running on the management server?
>> >> >> >Yes, each host is tracked by a server resource. CloudStack
>> retrieves
>> >> >> >owning cluster/datacenter as required from vCenter and performs
>> >> >>required
>> >> >> >operations.
>> >> >> >
>> >> >> >>
>> >> >> >> Assuming that leads to three ServerResources in that situation,
>> if
>> >> >>you
>> >> >> >>have multiple management servers for your cloud, do all three of
>> >> >> >> these ServerResources have to be managed by a single management
>> >> >>serve

RE: Interesting 4.2.1. Issue...

2014-03-31 Thread Amin Samir

We have the same issue, after an upgrade from 2.2.14 to 4.2.1, and during this 
upgrade we had upgrade from Ubuntu 10 LTS to Ubuntu 12 LTS, it seems it related 
to tomcat 6.0.35, because it is recommended to have tomcat 6.0.33 which doesn't 
come by default with Ubuntu 12.04.4

Kind Regards
Amin



-Original Message-
From: Marcus [mailto:shadow...@gmail.com] 
Sent: Tuesday, 1 April 2014 6:22 AM
To: dev@cloudstack.apache.org
Subject: Re: Interesting 4.2.1. Issue...

I'm running 3 mgmt servers on 4.2.1, haven't seen any issues like that. You can 
send along your memory settings... here's what I'm
running:

JAVA_OPTS="-Djava.awt.headless=true
-Dcom.sun.management.jmxremote.port=45219
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false -Xmx2g -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M 
-XX:MaxPermSize=800m

On Mon, Mar 31, 2014 at 9:33 AM, Michael Phillips  
wrote:
> So I have a redundant pair of management servers running on 4.2.1. At least 
> once a day one of the management servers crashes and the log gets filled with 
> the following messages:
> java.lang.OutOfMemoryError: Java heap 
> spac0java.lang.ArrayIndexOutOfBoundsExceptioneCaused by: 
> java.io.EOFException: SSL peer shut down incorrectlyCaused by: 
> javax.net.ssl.SSLHandshakeException: Remote host closed connection during 
> handshake and there are a few others. When the one management server tanks, 
> although the other management server is up and active, it won't actually 
> process any UI commands until the crashed server is restarted.  Example of 
> won't process any UI command is create a new instance, create a new account, 
> etc. After doing some searching I have found that others have noticed java 
> heap errors in 4.2.1, and the suggested fix is to increase the heap size. I 
> am planning on increasing it from 2g to 4g, however if the problem is 
> something like a memory leak, then increasing the heap size will just delay 
> the inevitable. Has anyone else fixed this issue by increasing the heap size? 
> Or what is the recommended value? **updated...as expected I increased the 
> heap size from 2g to 4g, and it just too
 k longer for the problem to reoccur...
> In my honest opinion of bigger concern is the fact that when one management 
> server crashes the other stops functioning as well. So this begs the question 
> of why even bother with a redundant pair of servers..Anybody else experience 
> this issue? I would love to hear any dev guys opinion on this

Re: docker.io integration

2014-03-31 Thread Nguyen Anh Tu

On Tue, Apr 1, 2014 at 12:33 AM, Francois Gaudreault <
fgaudrea...@cloudops.com> wrote:

> Cool!
>
> Anh: Can you share the current state of the Branch?
>
> Thanks!
>

Francois, I'm finishing first version running Docker as a new hypervisor in
CLoudStack. Take a look into:
http://ngtuna.blogspot.com/2013/12/docker-in-cloudstack.html

As the first version, I only run Docker containers as instances, data is
stored local on Docker hosts, using public repository (
http://index.docker.io) for pulling Docker templates.

Do you attend CloudStack Collaboration in next days? if yes, welcome you to
my section "Docker - an implementation in CloudStack"
http://events.linuxfoundation.org/events/cloudstack-collaboration-conference-north-america/program/schedule

Thanks,
--Tuna

Re: spring unittests

2014-03-31 Thread Rajani Karuturi

I think its not with the context file. The problem is with class level bean 
definitions using annotations once the component scan is turned on. 

I will try injecting a custom context. Thanks Laszlo.


~Rajani



On 01-Apr-2014, at 12:35 am, Laszlo Hornyak  wrote:

> Hi Rajani,
> 
> I had a short investigation into the problem and that test context is quite
> exciting. (which means I would need a lot more time to find all the
> details) For a short solution I would recommend you to write another rather
> than trying to reuse.
> 
> 
> 
> On Sat, Mar 29, 2014 at 11:30 AM, Rajani Karuturi <
> rajani.karut...@citrix.com> wrote:
> 
>> any help?
>> 
>> 
>> ~Rajani
>> 
>> 
>> 
>> On 28-Mar-2014, at 9:48 am, Rajani Karuturi 
>> wrote:
>> 
>>> Its the testContext.xml we have at server/test/resouces
>>> 
>>> As the async job dispatcher also comes under server/, i used the same
>> test context file.
>>> 
>>> ~Rajani
>>> 
>>> 
>>> 
>>> On 28-Mar-2014, at 1:23 am, Laszlo Hornyak 
>> wrote:
>>> 
 Hi Rajani,
 
 Can you share your spring context file?
 
 
 On Thu, Mar 27, 2014 at 10:50 AM, Rajani Karuturi <
 rajani.karut...@citrix.com> wrote:
 
> Hi All,
> 
> I am trying to write unit tests for ApiAsyncJobDispatcher. This is how
>> I
> defined by Test class @ server/test/com/cloud/api
> 
> @RunWith(SpringJUnit4ClassRunner.class)
> @ContextConfiguration(locations = "classpath:/testContext.xml")
> public class ApiAsyncJobDispatcherTest {
>  @Mock
>  private ApiDispatcher _dispatcher;
> 
>  @Mock
>  private AsyncJobManager _asyncJobMgr;
> 
>  @Mock
>  private EntityManager _entityMgr;
> 
>  @InjectMocks
>  private ApiAsyncJobDispatcher apiAsyncJobDispatcher = new
> ApiAsyncJobDispatcher();
> 
>  @Before
>  public void setUp() throws Exception {
>  MockitoAnnotations.initMocks(this);
>  ComponentContext.initComponentsLifeCycle();
>  }
> 
>  @Test
>  public void testRunJob() throws Exception {
>  AsyncJob asyncJob = new AsyncJobVO("", User.UID_SYSTEM, 1,
> DetachVolumeCmdByAdmin.class.getCanonicalName(), null, null, null);
>  apiAsyncJobDispatcher.runJob(asyncJob);
>  }
> }
> 
> 
> I am getting failed to load ApplicationContext error. The exact error
> message is
> java.lang.ClassNotFoundException:
> org.apache.cloudstack.framework.eventbus.EventBusBase
> 
> I think, that class is moved to
> org.apache.cloudstack.framework.events.EventBus. Once I make that
>> change in
> the application context file, I am getting
> Caused by:
> org.springframework.beans.factory.NoUniqueBeanDefinitionException: No
> qualifying bean of type [com.cloud.user.AccountService] is defined:
> expected single matching bean but found 4:
> mockAccountManagerImpl,accountService,accountManager,acctMgr
> 
> 
> Am I miss something?
> 
> I did go through
> 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Unit+Testing+with+JUnit+and+SpringBut,
>> didn't understand Note: #4 of it.
> 
> 
> ~Rajani
> 
> 
> 
> 
 
 
 --
 
 EOF
>>> 
>> 
>> 
> 
> 
> -- 
> 
> EOF

Re: [QUESTION] VMware ServerResource

2014-03-31 Thread Mike Tutkowski

I found a way to make this work.

For whatever reason, destroying a VM - although it seems to mainly remove
it from vCenter's inventory - leaves some info around that makes vCenter
think the datastore is still in use.

Instead of destroying the VM, what I do for managed storage (when we are
expunging the VM) is unregister it from vCenter. Once it is unregistered, I
can remove the iSCSI connections from the ESX hosts and the datastore goes
away.

Destroying a VM is supposed to be similar: It removes the VM from vCenter's
inventory and deletes all of the relevant files from the VM that are in the
datastore in question. However, there must be a VMware bug where destroying
the VM still leaves some trace in vCenter that tricks it into thinking the
datastore is still in use due to this VM.

In the case of managed storage, when you expunge the VM, I plan to delete
the corresponding SAN volume via a storage plug-in, so it doesn't matter if
there were files remaining on it from the VM or not.


On Mon, Mar 31, 2014 at 8:34 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Interesting...when I try to unmount the datastore prior to removing the
> iSCSI connections, I get a similar error to when I straight-out try to
> delete the datastore prior to removing the iSCSI connections: it says the
> datastore is still in use.
>
> When I look at the contents of the datastore, there doesn't appear to be
> anything on it.
>
> There is a clue in the fact that this is only a problem if a VM was
> running off of this datastore. If the datastore was only used to house a
> VMDK file for a data disk, there is no problem removing it by getting rid
> of the iSCSI connections to the SAN volume from the hosts.
>
>
> On Mon, Mar 31, 2014 at 4:44 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> Thanks, Kelven...I had seen a similar article about Storage IO
>> Control...perhaps the article you pointed to has more info.
>>
>>
>> On Mon, Mar 31, 2014 at 4:38 PM, Kelven Yang wrote:
>>
>>> Would this KB article helpful? Particularly, it seems that Stroage IO
>>> control needs to disabled before detaching the datastore.
>>>
>>>
>>> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=di
>>> splayKC&externalId=2004605
>>>
>>> Kelven
>>>
>>> On 3/31/14, 3:14 PM, "Mike Tutkowski" 
>>> wrote:
>>>
>>> >Interesting...I can look into that. Do you know off hand if we already
>>> >have
>>> >such a call to perform an unmount?
>>> >
>>> >Thanks, Kelven!
>>> >
>>> >
>>> >On Mon, Mar 31, 2014 at 3:28 PM, Kelven Yang 
>>> >wrote:
>>> >
>>> >>
>>> >> On 3/31/14, 1:54 PM, "Mike Tutkowski" 
>>> >> wrote:
>>> >>
>>> >> >Hi Kelven,
>>> >> >
>>> >> >Thanks for the info!
>>> >> >
>>> >> >I have another question that perhaps you can answer.
>>> >> >
>>> >> >In my situation, with managed storage, I need to create and delete
>>> >> >datastores dynamically. The idea is to have a single VM (and all of
>>> its
>>> >> >corresponding files) or a single VMDK data disk file per datastore in
>>> >>some
>>> >> >cases so we can guarantee IOPS to the VM or data disk.
>>> >> >
>>> >> >Each datastore is based on an iSCSI target that has guaranteed IOPS.
>>> >> >
>>> >> >For data disks, this process has worked perfectly (first implemented
>>> in
>>> >> >4.2). When I need the datastore, I create an iSCSI target on my SAN,
>>> >>then
>>> >> >establish a connection to it from each host in the VMware cluster,
>>> then
>>> >> >create a datastore on the target.
>>> >> >
>>> >> >When I no longer need the data disk, I remove the iSCSI targets from
>>> >>the
>>> >> >hosts and the datastore goes away.
>>> >> >
>>> >> >This same process works pretty well for root disks (and the other
>>> >>files of
>>> >> >a VM) except for when I want to delete the VM and get rid of its
>>> >> >datastore.
>>> >> >In this case, I follow the same process of removing the iSCSI
>>> >>connections
>>> >> >from each host in the cluster, but the datastore still shows up in
>>> >>vCenter
>>> >> >(albeit greyed out and in the inactive state when viewed through
>>> >>vSphere
>>> >> >Client).
>>> >> >
>>> >> >Any thoughts on this? I've looked into this on the web and the
>>> general
>>> >> >consensus is that the datastore is still somehow in use by vCenter.
>>> Not
>>> >> >sure why that would be, though.
>>> >>
>>> >>
>>> >> Have you checked if the datastore is unmounted from all hosts within
>>> the
>>> >> cluster? When iSCSI target is added as a VMFS datastore, I believe all
>>> >> hosts within the cluster will mount it automatically. To remove the
>>> >> datastore from vCenter, you probably need to make sure the datastore
>>> is
>>> >> unmounted from all hosts.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> >
>>> >> >Thanks!
>>> >> >Mike
>>> >> >
>>> >> >
>>> >> >On Mon, Mar 31, 2014 at 2:45 PM, Kelven Yang >> >
>>> >> >wrote:
>>> >> >
>>> >> >>
>>> >> >>
>>> >> >> On 3/29/14

Re: Where is our favorite CloudStack developer?

2014-03-31 Thread Mike Tutkowski

ha ha ha ha

This was meant to go to SolidFire's dev e-mail list! :)

Since I'm the only CloudStack developer at SolidFire, I am therefore
SolidFire's "favorite CloudStack developer."

Somehow I ended up sending it to the wrong list!

I guess I don't need to tell anyone on the CloudStack mailing list where
I'll be for the next two weeks, though. :)


On Mon, Mar 31, 2014 at 12:10 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hi,
>
> Just an FYI that I'm WFH today and will be on PTO the rest of the week.
>
> Next week I'm in Denver for ApacheCon on Monday and Tuesday and back to
> Denver Wednesday - Friday for the CloudStack Collaboration Conference.
>
> Talk to you later!
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the 
> cloud
> *(tm)*
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*

RE: Password visible in plan text CS 4.3

2014-03-31 Thread Devdeep Singh

Hi Tejas,

Can you file a bug for these? We clean up a string before logging it; but it 
looks like we missed it here.

Regards,
Devdeep

> -Original Message-
> From: Tejas Gadaria [mailto:refond.g...@gmail.com]
> Sent: Friday, March 28, 2014 6:01 PM
> To: dev@cloudstack.apache.org
> Subject: Password visible in plan text CS 4.3
> 
> Hi,
> 
> While doing volume migration from one storage to another, password was
> visible in plan text.
> environment CS 4.3,
> Management server: CentOS 6.3 x64
> Hypervisor: Hyperv
> 
> 2014-03-28 17:53:39,059 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-216:ctx-89b9eb84) POST response is
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":true
> ,"details":null,"newData":{"org.apache.cloudstack.storage.to.VolumeObject
> TO":{"dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{
> "uuid":"7890d244-e307-320e-ac42-
> f90e925b32b8","id":5,"poolType":"SMB","host":"10.129.150.24","path":"/vol
> _cifs?user=administrator&domain=
> nw.com","port":445,"url":"SMB://
> 10.129.150.24//vol_cifs?user=administrator&domain=nw.com/?ROLE=Primar
> y&STOREUUID=7890d244-e307-320e-ac42-f90e925b32b8
> "}},"format":"VHD","name":"ROOT-
> 7","path":"\\10.129.150.24\vol_cifs\ROOT-7.vhd","uuid":"ca572e34-ffa6-
> 4cce-bb24-
> 44c989b4156e","size":10737418240,"primaryDataStore":{"host":"10.129.150.2
> 4","uri":"cifs://
> 10.129.150.24/vol_cifs?user=administrator&domain=nw.com
> ","_role":null,"Path":"\\10.129.150.24/vol_cifs","UncPath":"\\
> 10.129.150.24/vol_cifs","User":"administrator","*Password":"C1sco123*
> ","Domain":"nw.com
> ","isLocal":false},"nfsDataStore":null,"FullFileName":"\\10.129.150.24\vol_cif
> s\ROOT-7.vhd"}},"contextMap":{}}}]
> 2014-03-28 17:53:39,060 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-216:ctx-89b9eb84) executeRequest received response
> [Lcom.cloud.agent.api.Answer;@31c91ca
> 
> Regards,
> Tejas

42 matches

Mail list logo