Re: 4.2 branch with devcloud not working properly.

[Thomas O'Dowd]

Thanks Prasanna,

I reset the devcloud image back to its initial state (fresh copy of the
downloaded image) to get rid of anything that might be in a bad state.
Then rebuilt, deployed etc but I get the same problem. Do I need to
clean up something in addition on my development machine? 

Thanks,

Tom.

On Mon, 2013-07-01 at 11:12 +0530, Prasanna Santhanam wrote:
> On Mon, Jul 01, 2013 at 02:26:26PM +0900, Thomas O'Dowd wrote:
> > Hi all,
> > 
> > checked out 4.2 branch today. New build, deploydb and start management
> > server. then deploysvr... on the management server terminal logs, I can
> > see a new exception that wasn't on master last week.
> > 
>  
> > The system vms do eventually get launched but when I stop them and
> > restart the management server it never starts them again.
> > 
> > Any ideas? I've been testing with devcloud like this for a while now so
> > I don't think it's something I'm doing.
> > 
> I reset the devcloud image to the base snapshot on virtualbox and
> rebuilt on 4.2 and didn't find any exceptions. Then I stopped
> management server,  and destroyed my systemVMs and they came back up
> fine.
> 
> Edison mentioned the issue was with systemvm.iso last week
> http://markmail.org/message/c4ihlzu7lxohhc5k
> 
> Can you retry by reseting devcloud?
> 

-- 
Cloudian KK - http://www.cloudian.com/get-started.html
Fancy 100TB of full featured S3 Storage?
Checkout the Cloudian® Community Edition!

Re: [DISCUSS] unanswered questions

[Sebastien Goasguen]

On Jul 1, 2013, at 2:18 AM, Prasanna Santhanam  wrote:

> On Mon, Jul 01, 2013 at 07:57:11AM +0200, Daan Hoogland wrote:
>> On Mon, Jul 1, 2013 at 7:43 AM, Prasanna Santhanam  wrote:
>> 
>>> On Mon, Jul 01, 2013 at 07:34:00AM +0200, Daan Hoogland wrote:
 H,
 
 This might be more appropriate on the marketing list but it concerns
 contents here; Between Thursday and Saturday 6 questions where posed on
 this list that have not been replied to. Starting to work on cloudstack
 this happened to me as well a couple of times. Given that people take the
 trouble to ask, they are either trying to contribute or evaluating
 cloudstack for usage. In both cases it is missed chance if we let those
 people pass by.
 
 At a first glance it would seem there are two kind of questions that
>>> don't
 get answered:
 - boring ones
 - difficult ones
 - unclear ones
 
 Do more people see this as an issue?
 
>>> 
>>> Sometimes yes. Do you mean dev@ and users@? OR just dev@?
>>> 
>> I must confess I am guilty of not answerring any questions on users@.. So I
>> mean dev@.. but I can imagine the problem being present there as well.
>> 
> 
> users@ needs more people because I see difficult questions there
> often.

I have noticed it too, and from my side it seems that the questions have become 
much more specific.
Questions are certainly not 'boring' but need expert answers.

Not sure how to deal with this, except that all of us should regularly go 
through all the pending questions.

-sebastien


> dev@ just needs attention from folks working on the related
> piece of code and that's easier to get by Cc-ing the person if they've
> missed it. Given that the question has remained unanswered for a
> while.
> 
> For boring and unclear questions what is reqd is a page that describes
> "how to get your questions answered on the cloudstack mailing lists?".
> Other communities I've noticed have this sort of a page. 
> 
> 
> -- 
> Prasanna.,
> 
> 
> Powered by BigRock.com
> 

bean exception while running cloudstack on Latest Master.

[Rajesh Battala]

Hi All,

Am on latest master, while launching the jetty server am hitting with below 
bean execption server is not getting loaded.
How to resolve this bean issue?
In nonComponent.xml I had modified 'CloudStackImageStoreProviderImpl to 
cloudStackImageStoreProviderImpl but still am facing this issue.


Exception in thread "Timer-2" 
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'dataStoreProviderManager' defined in class path resource 
[nonossComponentContext.xml]: Cannot resolve reference to bean 
'CloudStackImageStoreProviderImpl' while setting bean property 'providers' with 
key [1]; nested exception is 
org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 
'CloudStackImageStoreProviderImpl' is defined
at 
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:328)
at 
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:106)
at 
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveManagedList(BeanDefinitionValueResolver.java:353)
at 
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:153)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1360)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1118)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.configureBean(AbstractAutowireCapableBeanFactory.java:314)
at 
com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:71)
at 
com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:50)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No 
bean named 'CloudStackImageStoreProviderImpl' is defined
at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:553)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.getMergedLocalBeanDefinition(AbstractBeanFactory.java:1095)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:277)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
at 
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:322)
... 10 more


Thanks
Rajesh Battala

[DISCUSS] vlan uri format change

[Daan Hoogland]

H,

I've been trying to get a patch accepted and had some discussions to do it
in parts as well. I would like to refresh the first part:

vlans are now referred as vlan://. I would like to change this to
vlan:. This will changee addressing the id as a scheme specific part
instead of as a host. As a result it will be easier to fix the code to use
Nicira NVP and other sdn networks whereever vlans are used now. Doing this
will result in a patch that is a subset of my earlier patch. It touches a
lot of core code and tests but has been tested  thoroughly for VPC gateways
with both vlans and Nicira NVP.

regards,
Daan

Re: bean exception while running cloudstack on Latest Master.

[Prasanna Santhanam]

Looking into it.

On Mon, Jul 01, 2013 at 07:25:22AM +, Rajesh Battala wrote:
> Hi All,
> 
> Am on latest master, while launching the jetty server am hitting with below 
> bean execption server is not getting loaded.
> How to resolve this bean issue?
> In nonComponent.xml I had modified 'CloudStackImageStoreProviderImpl to 
> cloudStackImageStoreProviderImpl but still am facing this issue.
> 
> 
> Exception in thread "Timer-2" 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'dataStoreProviderManager' defined in class path resource 
> [nonossComponentContext.xml]: Cannot resolve reference to bean 
> 'CloudStackImageStoreProviderImpl' while setting bean property 'providers' 
> with key [1]; nested exception is 
> org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean 
> named 'CloudStackImageStoreProviderImpl' is defined
> at 
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:328)
> at 
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:106)
> at 
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveManagedList(BeanDefinitionValueResolver.java:353)
> at 
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:153)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1360)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1118)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.configureBean(AbstractAutowireCapableBeanFactory.java:314)
> at 
> com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:71)
> at 
> com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:50)
> at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: 
> No bean named 'CloudStackImageStoreProviderImpl' is defined
> at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:553)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getMergedLocalBeanDefinition(AbstractBeanFactory.java:1095)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:277)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
> at 
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:322)
> ... 10 more
> 
> 
> Thanks
> Rajesh Battala

-- 
Prasanna.,



Powered by BigRock.com

RE: bean exception while running cloudstack on Latest Master.

[Rajesh Battala]

Thanks 

> -Original Message-
> From: Prasanna Santhanam [mailto:t...@apache.org]
> Sent: Monday, July 1, 2013 1:21 PM
> To: dev@cloudstack.apache.org
> Subject: Re: bean exception while running cloudstack on Latest Master.
> 
> Looking into it.
> 
> On Mon, Jul 01, 2013 at 07:25:22AM +, Rajesh Battala wrote:
> > Hi All,
> >
> > Am on latest master, while launching the jetty server am hitting with
> below bean execption server is not getting loaded.
> > How to resolve this bean issue?
> > In nonComponent.xml I had modified 'CloudStackImageStoreProviderImpl
> to cloudStackImageStoreProviderImpl but still am facing this issue.
> >
> >
> > Exception in thread "Timer-2"
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'dataStoreProviderManager' defined in class path resource
> [nonossComponentContext.xml]: Cannot resolve reference to bean
> 'CloudStackImageStoreProviderImpl' while setting bean property 'providers'
> with key [1]; nested exception is
> org.springframework.beans.factory.NoSuchBeanDefinitionException: No
> bean named 'CloudStackImageStoreProviderImpl' is defined
> > at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.res
> olveReference(BeanDefinitionValueResolver.java:328)
> > at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.res
> olveValueIfNecessary(BeanDefinitionValueResolver.java:106)
> > at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.res
> olveManagedList(BeanDefinitionValueResolver.java:353)
> > at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.res
> olveValueIfNecessary(BeanDefinitionValueResolver.java:153)
> > at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFa
> ctory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1360)
> > at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFa
> ctory.populateBean(AbstractAutowireCapableBeanFactory.java:1118)
> > at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFa
> ctory.configureBean(AbstractAutowireCapableBeanFactory.java:314)
> > at
> com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(Co
> mponentContext.java:71)
> > at
> com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:50)
> > at java.util.TimerThread.mainLoop(Timer.java:555)
> > at java.util.TimerThread.run(Timer.java:505)
> > Caused by:
> org.springframework.beans.factory.NoSuchBeanDefinitionException: No
> bean named 'CloudStackImageStoreProviderImpl' is defined
> > at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.getB
> eanDefinition(DefaultListableBeanFactory.java:553)
> > at
> org.springframework.beans.factory.support.AbstractBeanFactory.getMergedL
> ocalBeanDefinition(AbstractBeanFactory.java:1095)
> > at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(
> AbstractBeanFactory.java:277)
> > at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab
> stractBeanFactory.java:193)
> > at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.res
> olveReference(BeanDefinitionValueResolver.java:322)
> > ... 10 more
> >
> >
> > Thanks
> > Rajesh Battala
> 
> --
> Prasanna.,
> 
> 
> 
> Powered by BigRock.com

Re: [DISCUSS] vlan uri format change

[Hiroaki KAWAI]

Daan, I'm curious about what is the improvement of changing the
vlan String format in URI?

I'm -1 on pushing more complexity in URI, because that's
abuse of URI class and sounds it's time to get rid of URI.


(2013/07/01 16:47), Daan Hoogland wrote:

H,

I've been trying to get a patch accepted and had some discussions to do it
in parts as well. I would like to refresh the first part:

vlans are now referred as vlan://. I would like to change this to
vlan:. This will changee addressing the id as a scheme specific part
instead of as a host. As a result it will be easier to fix the code to use
Nicira NVP and other sdn networks whereever vlans are used now. Doing this
will result in a patch that is a subset of my earlier patch. It touches a
lot of core code and tests but has been tested  thoroughly for VPC gateways
with both vlans and Nicira NVP.

regards,
Daan

Re: bean exception while running cloudstack on Latest Master.

[Prasanna Santhanam]

On Mon, Jul 01, 2013 at 07:25:22AM +, Rajesh Battala wrote:
> Hi All,
> 
> Am on latest master, while launching the jetty server am hitting
> with below bean execption server is not getting loaded.
> How to resolve this bean issue?
> In nonComponent.xml I had modified 'CloudStackImageStoreProviderImpl
> to cloudStackImageStoreProviderImpl but still am facing this issue.
> 

For future reference:
beans from application context have visibility in the derived contexts
- component and nonosscomponent. But beans are not visible from
  component to the nonosscomponent contexts.

The data store providers (default, primary, s3, swift, solidfire) were
moved to componentContext. Since these are not plugged in on a nonoss
server it failed to start. The case change had been done since Spring
convention uses lower cases on bean names. While you changed the case
correctly, the other datastoreprovider beans were not injected causing
the server startup failure.

-- 
Prasanna.,


Powered by BigRock.com

Re: [DISCUSS] vlan uri format change

[Daan Hoogland]

The gain is that enums like BroadcastDomainType and IsolationType do not
have to check for different formats in the presented uri. It also makes it
more intiutive what the parts in the uri mean; vlan:// would inmply
that id is a hostname instead of a scheme specific identifier.

I think I am reducing complexity, not introducing any. The present use of
uri for vlans is abuse of the construct, i don't think my proposed new use
is.


On Mon, Jul 1, 2013 at 10:17 AM, Hiroaki KAWAI wrote:

> Daan, I'm curious about what is the improvement of changing the
> vlan String format in URI?
>
> I'm -1 on pushing more complexity in URI, because that's
> abuse of URI class and sounds it's time to get rid of URI.
>
>
>
> (2013/07/01 16:47), Daan Hoogland wrote:
>
>> H,
>>
>> I've been trying to get a patch accepted and had some discussions to do it
>> in parts as well. I would like to refresh the first part:
>>
>> vlans are now referred as vlan://. I would like to change this to
>> vlan:. This will changee addressing the id as a scheme specific part
>> instead of as a host. As a result it will be easier to fix the code to use
>> Nicira NVP and other sdn networks whereever vlans are used now. Doing this
>> will result in a patch that is a subset of my earlier patch. It touches a
>> lot of core code and tests but has been tested  thoroughly for VPC
>> gateways
>> with both vlans and Nicira NVP.
>>
>> regards,
>> Daan
>>
>>
>

RE: [DISCUSS] unanswered questions

[Donal Lafferty]

> > users@ needs more people because I see difficult questions there
> > often.
> 
> I have noticed it too, and from my side it seems that the questions have
> become much more specific.
> Questions are certainly not 'boring' but need expert answers.
> 
> Not sure how to deal with this, except that all of us should regularly go
> through all the pending questions.
> 
> -sebastien
> 

[Donal Lafferty] 
Is there an email portal that allows us to interact with the mailing list as if 
it were a member of stack exchange?

Stack Exchange have some excellent facilities for identifying important 
questions and unanswered questions.

RE: Master build problem

[Paul Angus]

This was a completely fresh build from the 4.2 branch (oss).

I don't use dev cloud as it's not representative of a real environment. I ran:

yum install -y cloud-client # run against local 4.2 repo
cloudstack-setup-databases cloud:cloud@$MYSQLIP --deploy-as=root:password
cloudstack-setup-management

that's it...

as a work around I assume I can open the unauthenticated api port and create a 
user (which I know the password for)...



-Original Message-
From: Prasanna Santhanam [mailto:t...@apache.org]
Sent: 01 July 2013 07:53
To: dev@cloudstack.apache.org
Subject: Re: Master build problem

On Sun, Jun 30, 2013 at 07:14:38PM +, Paul Angus wrote:
> Hi Prasanna,
>
> Here is the section from the componentContext.xml file.  The
> username/password in the user table is admin / 0.724297075275608
>
> The state was is "disabled" by default I changed it to enabled but it didn't 
> make a difference.

There is some kind of bug here. Can you tell us the steps to reproduce this 
from a fresh build? You will need to begin by wiping out the DB, doing the 
build, deploydb and a jetty:run.

What happens is that management server saves random values for user/password on 
startup. In another separate class it sets the password to default of 
admin/password based on the authenticator enabled. It looks like we randomized 
the password but failed to set it to defaults.
--
Prasanna.,


Powered by BigRock.com


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 operated under 
license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [DISCUSS] unanswered questions

[Daan Hoogland]

This sounds like something we want to set up.

Does markmail qualify?



On Mon, Jul 1, 2013 at 10:33 AM, Donal Lafferty
wrote:

> > > users@ needs more people because I see difficult questions there
> > > often.
> >
> > I have noticed it too, and from my side it seems that the questions have
> > become much more specific.
> > Questions are certainly not 'boring' but need expert answers.
> >
> > Not sure how to deal with this, except that all of us should regularly go
> > through all the pending questions.
> >
> > -sebastien
> >
>
> [Donal Lafferty]
> Is there an email portal that allows us to interact with the mailing list
> as if it were a member of stack exchange?
>
> Stack Exchange have some excellent facilities for identifying important
> questions and unanswered questions.
>
>

Re: Suggestion needed for CLOUDSTACK-212

[Sebastien Goasguen]

On 7/1/13 8:11 AM, Dharmesh Kakadia wrote:

Hi David,

I have submitted a patch yesterday. It migrates com.cloud.network o
org.apache.network. Please let me know if this is fine so that I can go on
for the rest of the packages.

Thanks,
Dharmesh
   


Can you send me another patch created with git format-patch

I will create a topic branch and put the patch there.

thanks

thanks



On Sat, Jun 29, 2013 at 10:09 PM, David Nalley  wrote:

   

On Fri, Jun 28, 2013 at 4:05 AM, Sebastien Goasguen
wrote:
 

On Jun 27, 2013, at 1:23 PM, Dharmesh Kakadia
   

wrote:
 
   

Hi,

I misunderstood the feature freeze. This has been assigned to fix in
Version 4.2 on jira. As per this discussion, should I change it to 4.3 ?
 

Dharmesh, can you give us the pointer to github where you put the latest
   

changes on this ?
 

Did you rebase against the latest master lately ?

-sebastien

   

Dharmesh:
4.2 has branched, and I'd like to get this up for review - can you get
us a patch and push it to ReviewBoard?

--David

 
   

Re: Review Request 11670: CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary storage is in maintenance state.

[Sanjay Tripathi]

> On June 30, 2013, 6:50 a.m., Prasanna Santhanam wrote:
> > Applying: CLOUDSTACK-2288: NPE while creating volume from snapshot when the 
> > primary storage is in maintenance state.
> > error: patch failed: server/src/com/cloud/storage/VolumeManagerImpl.java:523
> > error: server/src/com/cloud/storage/VolumeManagerImpl.java: patch does not 
> > apply
> > Patch failed at 0001 CLOUDSTACK-2288: NPE while creating volume from 
> > snapshot when the primary storage is in maintenance state.
> > When you have resolved this problem run "git am --resolved".
> > If you would prefer to skip this patch, instead run "git am --skip".
> > To restore the original branch and stop patching run "git am --abort".
> > 
> > Fails to apply because of storage related changes. Can you retest if this 
> > is still an issue and submit the patch?
> > 
> > Thanks

The issue is still there in master so recreating the patch based on latest 
master code.


- Sanjay


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


On June 6, 2013, 11:24 a.m., Sanjay Tripathi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11670/
> ---
> 
> (Updated June 6, 2013, 11:24 a.m.)
> 
> 
> Review request for cloudstack and Devdeep Singh.
> 
> 
> Bugs: CLOUDSTACK-2288
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary 
> storage is in maintenance state.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/storage/VolumeManagerImpl.java 43f3681 
> 
> Diff: https://reviews.apache.org/r/11670/diff/
> 
> 
> Testing
> ---
> 
> Tests:
> 1. In CS setup, put all primary storage in maintenance mode.
> 2. Create a volume from snapshot.
> 
> Verified the fix locally.
> 
> 
> Thanks,
> 
> Sanjay Tripathi
> 
>

Re: Review Request 11670: CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary storage is in maintenance state.

[Sanjay Tripathi]

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

(Updated July 1, 2013, 9:18 a.m.)


Review request for cloudstack and Devdeep Singh.


Changes
---

Updated patch.


Bugs: CLOUDSTACK-2288


Repository: cloudstack-git


Description
---

CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary 
storage is in maintenance state.


Diffs (updated)
-

  server/src/com/cloud/storage/VolumeManagerImpl.java a293da5 

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


Testing
---

Tests:
1. In CS setup, put all primary storage in maintenance mode.
2. Create a volume from snapshot.

Verified the fix locally.


Thanks,

Sanjay Tripathi

Re: Review Request 11670: CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary storage is in maintenance state.

[Sanjay Tripathi]

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

(Updated July 1, 2013, 9:18 a.m.)


Review request for cloudstack, Abhinandan Prateek, Devdeep Singh, and Prasanna 
Santhanam.


Bugs: CLOUDSTACK-2288


Repository: cloudstack-git


Description
---

CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary 
storage is in maintenance state.


Diffs
-

  server/src/com/cloud/storage/VolumeManagerImpl.java a293da5 

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


Testing
---

Tests:
1. In CS setup, put all primary storage in maintenance mode.
2. Create a volume from snapshot.

Verified the fix locally.


Thanks,

Sanjay Tripathi

Re: [GSoC] Encrypted passwords on LDAP.

[Sebastien Goasguen]

On 6/21/13 11:38 AM, Ian Duffy wrote:

Hi Guys,

I'm using JNDI to connect to LDAP for user authentication. At the
moment I'm just testing against an OpenLDAP server.

I have my Context.SECURITY_AUTHENTICATION set to simple, however when
some password encryption are used within LDAP it fails. Any idea how
to solve this?

clear - works
blowfish - fails
crypt - works
ext_des - works
md5 - works
k5key - fails
md5crypt - works
sha - works
smd5 - fails
ssha - works
sha512 - fails
   


Abhi, thoughts on Ian's question here ?

thanks,

-sebastien

Review Request 12205: message(s) made more identifying for the error location

[daan Hoogland]

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

Review request for cloudstack.


Bugs: CLOUDSTACK-2162


Repository: cloudstack-git


Description
---

make several messages made more distict and readible so identifying the error 
location is easier.


Diffs
-

  server/src/com/cloud/storage/StorageManagerImpl.java 138c6d7 

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


Testing
---


Thanks,

daan Hoogland

database deploy problem

[Thomas Schneider]

Hello,

I try to setup a Cloudstack developpement environement with devcloud
following the instruction on the wiki but I have two problems.
When I execute the following command I have an error:

mvn -P developer -pl developer,tools/devcloud -Ddeploydb

[INFO]

[INFO] Reactor Summary:
[INFO]
[INFO] Apache CloudStack Developer Mode .. FAILURE [10.313s]
[INFO] Apache CloudStack DevCloud  SKIPPED
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 13.993s
[INFO] Finished at: Mon Jul 01 13:24:03 CEST 2013
[INFO] Final Memory: 16M/38M
[INFO]

[ERROR] Failed to execute goal on project cloud-developer: Could not
resolve dependencies for project
org.apache.cloudstack:cloud-developer:pom:4.2.0-SNAPSHOT: The following
artifacts could not be resolved:
org.apache.cloudstack:cloud-server:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-plugin-hypervisor-simulator:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-secondary-storage:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-plugin-storage-image-simulator:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-engine-storage:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-engine-storage-image:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-engine-storage-volume:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-engine-storage-snapshot:jar:4.2.0-SNAPSHOT:
Could not find artifact
org.apache.cloudstack:cloud-server:jar:4.2.0-SNAPSHOT in
apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException

-- 
*Thomas Schneider*

Re: database deploy problem

[Wei ZHOU]

You need to run following command at first

mvn -P developer,systemvm clean install


2013/7/1 Thomas Schneider 

> Hello,
>
> I try to setup a Cloudstack developpement environement with devcloud
> following the instruction on the wiki but I have two problems.
> When I execute the following command I have an error:
>
> mvn -P developer -pl developer,tools/devcloud -Ddeploydb
>
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache CloudStack Developer Mode .. FAILURE
> [10.313s]
> [INFO] Apache CloudStack DevCloud  SKIPPED
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 13.993s
> [INFO] Finished at: Mon Jul 01 13:24:03 CEST 2013
> [INFO] Final Memory: 16M/38M
> [INFO]
> 
> [ERROR] Failed to execute goal on project cloud-developer: Could not
> resolve dependencies for project
> org.apache.cloudstack:cloud-developer:pom:4.2.0-SNAPSHOT: The following
> artifacts could not be resolved:
> org.apache.cloudstack:cloud-server:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-plugin-hypervisor-simulator:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-secondary-storage:jar:4.2.0-SNAPSHOT,
>
> org.apache.cloudstack:cloud-plugin-storage-image-simulator:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-engine-storage:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-engine-storage-image:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-engine-storage-volume:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-engine-storage-snapshot:jar:4.2.0-SNAPSHOT:
> Could not find artifact
> org.apache.cloudstack:cloud-server:jar:4.2.0-SNAPSHOT in
> apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
>
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
>
> --
> *Thomas Schneider*
>

backwards compatibility question

[Daan Hoogland]

H,

In the network thing I am trying to get you people to accept I want to add
a parameter to an api call. What is the policy (does it adhere to common
sense)? It is an extra parameter to the end of an otherwise unchanged call.
I am still checking to make sure it is really optional. If it is not can it
go in 4.3? Or must it wait till 5.0?

thanks,
Daan

Review Request 12207: Cloudstack-3299 incorrect arguments sent to the script createIpalias in case of vmware, Cloudstack-3240 corrected a mistake in the script name.

[bharat kumar]

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

Review request for cloudstack and Abhinandan Prateek.


Bugs: Cloudstack-3240 and Cloudstack-3299


Repository: cloudstack-git


Description
---

Cloudstack-3299 incorrect arguments sent to the script createIpalias in case of 
vmware,
Cloudstack-3240 corrected a mistake in the script name.


Diffs
-

  
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
 286eb48 

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


Testing
---


Thanks,

bharat kumar

Review Request 12209: Cloudstack-3302 VM deployement failed due to dnsmasq configuration issue in case of multiple subnets in a vlan

[bharat kumar]

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

Review request for cloudstack and Abhinandan Prateek.


Bugs: Cloudstack-3302


Repository: cloudstack-git


Description
---

Cloudstack-3302 VM deployement failed due to dnsmasq configuration issue in 
case of multiple subnets in a vlan


Diffs
-

  
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
 286eb48 

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


Testing
---


Thanks,

bharat kumar

Re: database deploy problem

[Thomas Schneider]

What I did:

# git clone https://git-wip-us.apache.org/repos/asf/cloudstack.git

# cd cloudstack

# mvn -P developer,systemvm clean install

# mvn -P developer -pl developer,tools/devcloud -Ddeploydb

then error:

[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]

[INFO] Reactor Build Order:
[INFO]
[INFO] Apache CloudStack Developer Mode
[INFO] Apache CloudStack DevCloud
[INFO]
[INFO]

[INFO] Building Apache CloudStack Developer Mode 4.2.0-SNAPSHOT
[INFO]

[INFO]

[INFO] Reactor Summary:
[INFO]
[INFO] Apache CloudStack Developer Mode .. FAILURE [3.594s]
[INFO] Apache CloudStack DevCloud  SKIPPED
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 7.951s
[INFO] Finished at: Mon Jul 01 15:16:56 CEST 2013
[INFO] Final Memory: 16M/38M
[INFO]

[ERROR] Failed to execute goal on project cloud-developer: Could not
resolve dependencies for project
org.apache.cloudstack:cloud-developer:pom:4.2.0-SNAPSHOT: The following
artifacts could not be resolved:
org.apache.cloudstack:cloud-server:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-plugin-hypervisor-simulator:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-secondary-storage:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-plugin-storage-image-simulator:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-engine-storage:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-engine-storage-image:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-engine-storage-volume:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-engine-storage-snapshot:jar:4.2.0-SNAPSHOT:
Failure to find org.apache.cloudstack:cloud-server:jar:4.2.0-SNAPSHOT in
http://repository.apache.org/snapshots was cached in the local
repository, resolution will not be reattempted until the update interval
of apache.snapshots has elapsed or updates are forced -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal on project cloud-developer: Could not resolve dependencies
for project org.apache.cloudstack:cloud-developer:pom:4.2.0-SNAPSHOT:
The following artifacts could not be resolved:
org.apache.cloudstack:cloud-server:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-plugin-hypervisor-simulator:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-secondary-storage:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-plugin-storage-image-simulator:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-engine-storage:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-engine-storage-image:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-engine-storage-volume:jar:4.2.0-SNAPSHOT,
org.apache.cloudstack:cloud-engine-storage-snapshot:jar:4.2.0-SNAPSHOT:
Failure to find org.apache.cloudstack:cloud-server:jar:4.2.0-SNAPSHOT in
http://repository.apache.org/snapshots was cached in the local
repository, resolution will not be reattempted until the update interval
of apache.snapshots has elapsed or updates are forced
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(Native

Re: [GSoC] Encrypted passwords on LDAP.

[Abhinandan Prateek]

On 01-Jul-2013, at 2:57 PM, Sebastien Goasguen  wrote:

> On 6/21/13 11:38 AM, Ian Duffy wrote:
>> Hi Guys,
>> 
>> I'm using JNDI to connect to LDAP for user authentication. At the
>> moment I'm just testing against an OpenLDAP server.
>> 
>> I have my Context.SECURITY_AUTHENTICATION set to simple, however when
>> some password encryption are used within LDAP it fails. Any idea how
>> to solve this?
>> 
>> clear - works
>> blowfish - fails
>> crypt - works
>> ext_des - works
>> md5 - works
>> k5key - fails
>> md5crypt - works
>> sha - works
>> smd5 - fails
>> ssha - works
>> sha512 - fails
>>   
> 
> Abhi, thoughts on Ian's question here ?
> 

Me and Ian have synced on this. Though I have not much idea on this, it seems 
that for a particular encryption to work the system's crypt library should 
support it.

-abhi

Re: backwards compatibility question

[Chip Childers]

On Mon, Jul 01, 2013 at 02:50:08PM +0200, Daan Hoogland wrote:
> H,
> 
> In the network thing I am trying to get you people to accept I want to add
> a parameter to an api call. What is the policy (does it adhere to common
> sense)? It is an extra parameter to the end of an otherwise unchanged call.
> I am still checking to make sure it is really optional. If it is not can it
> go in 4.3? Or must it wait till 5.0?
> 
> thanks,
> Daan

If you can add it as an optional param, with a reasonable default for
backward compatibility, then it wouldn't cause us to bump the major
version from 4 to 5.  If there really isn't a logical default (and the
param is *required*), then we would need to bump to 5 (based on current
consensus for version numbering).

We don't have any "plans" for a 5.x release line yet, and of course,
past consensus can be changed.  I expect that if we bump from 4 to 5,
there will be a decent number of API changes that we'd want to also make
(perhaps going so far as to switch from the query-based API approach to
a RESTful model, or perhaps not).

-chip

Re: backwards compatibility question

[Daan Hoogland]

sounds like the intuitive approach, thanks


On Mon, Jul 1, 2013 at 3:51 PM, Chip Childers wrote:

> On Mon, Jul 01, 2013 at 02:50:08PM +0200, Daan Hoogland wrote:
> > H,
> >
> > In the network thing I am trying to get you people to accept I want to
> add
> > a parameter to an api call. What is the policy (does it adhere to common
> > sense)? It is an extra parameter to the end of an otherwise unchanged
> call.
> > I am still checking to make sure it is really optional. If it is not can
> it
> > go in 4.3? Or must it wait till 5.0?
> >
> > thanks,
> > Daan
>
> If you can add it as an optional param, with a reasonable default for
> backward compatibility, then it wouldn't cause us to bump the major
> version from 4 to 5.  If there really isn't a logical default (and the
> param is *required*), then we would need to bump to 5 (based on current
> consensus for version numbering).
>
> We don't have any "plans" for a 5.x release line yet, and of course,
> past consensus can be changed.  I expect that if we bump from 4 to 5,
> there will be a decent number of API changes that we'd want to also make
> (perhaps going so far as to switch from the query-based API approach to
> a RESTful model, or perhaps not).
>
> -chip
>

please review

[Daan Hoogland]

Can someone look at review request 12205. It only changes strings in
exceptions and a log message.

thanks,
Daan

Re: Review Request 12205: message(s) made more identifying for the error location

[Hugo Trippaers]

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

Ship it!


Ship It!

- Hugo Trippaers


On July 1, 2013, 10:46 a.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12205/
> ---
> 
> (Updated July 1, 2013, 10:46 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-2162
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> make several messages made more distict and readible so identifying the error 
> location is easier.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/storage/StorageManagerImpl.java 138c6d7 
> 
> Diff: https://reviews.apache.org/r/12205/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> daan Hoogland
> 
>

Re: Review Request 11670: CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary storage is in maintenance state.

[ASF Subversion and Git Services]

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


Commit ffd5f1a777ac9af5b65b1fcd357684d7dafcce87 in branch refs/heads/master 
from Sanjay Tripathi
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ffd5f1a ]

CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary 
storage is in maintenance state.

Signed-off-by: Prasanna Santhanam 


- ASF Subversion and Git Services


On July 1, 2013, 9:18 a.m., Sanjay Tripathi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11670/
> ---
> 
> (Updated July 1, 2013, 9:18 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Devdeep Singh, and 
> Prasanna Santhanam.
> 
> 
> Bugs: CLOUDSTACK-2288
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary 
> storage is in maintenance state.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/storage/VolumeManagerImpl.java a293da5 
> 
> Diff: https://reviews.apache.org/r/11670/diff/
> 
> 
> Testing
> ---
> 
> Tests:
> 1. In CS setup, put all primary storage in maintenance mode.
> 2. Create a volume from snapshot.
> 
> Verified the fix locally.
> 
> 
> Thanks,
> 
> Sanjay Tripathi
> 
>

Re: Review Request 12205: message(s) made more identifying for the error location

[Prasanna Santhanam]

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

Ship it!


216e374 -> 4.2
639592f -> master

- Prasanna Santhanam


On July 1, 2013, 10:46 a.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12205/
> ---
> 
> (Updated July 1, 2013, 10:46 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-2162
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> make several messages made more distict and readible so identifying the error 
> location is easier.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/storage/StorageManagerImpl.java 138c6d7 
> 
> Diff: https://reviews.apache.org/r/12205/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> daan Hoogland
> 
>

Re: Review Request 11670: CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary storage is in maintenance state.

[ASF Subversion and Git Services]

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


Commit 58e69704ea9876b3c5195d085f9a7056b7f65298 in branch refs/heads/4.2 from 
Sanjay Tripathi
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=58e6970 ]

CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary 
storage is in maintenance state.

Signed-off-by: Prasanna Santhanam 
(cherry picked from commit ffd5f1a777ac9af5b65b1fcd357684d7dafcce87)


- ASF Subversion and Git Services


On July 1, 2013, 9:18 a.m., Sanjay Tripathi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11670/
> ---
> 
> (Updated July 1, 2013, 9:18 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Devdeep Singh, and 
> Prasanna Santhanam.
> 
> 
> Bugs: CLOUDSTACK-2288
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary 
> storage is in maintenance state.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/storage/VolumeManagerImpl.java a293da5 
> 
> Diff: https://reviews.apache.org/r/11670/diff/
> 
> 
> Testing
> ---
> 
> Tests:
> 1. In CS setup, put all primary storage in maintenance mode.
> 2. Create a volume from snapshot.
> 
> Verified the fix locally.
> 
> 
> Thanks,
> 
> Sanjay Tripathi
> 
>

Re: Review Request 11906: CLOUDSTACK-1047: tracking in logs using job id

[Prasanna Santhanam]

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

(Updated July 1, 2013, 2:50 p.m.)


Review request for cloudstack, Alex Huang, Devdeep Singh, and Nitin Mehta.


Bugs: CLOUDSTACK-1047


Repository: cloudstack-git


Description
---

CLOUDSTACK-1047: tracking in logs using job id

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


Diffs
-

  server/src/com/cloud/async/AsyncJobManagerImpl.java 0101a8a 
  server/src/com/cloud/storage/VolumeManagerImpl.java 4297efb 

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


Testing
---

Tests:
1. Deploy an Instance.
2. In the Management server logs, check the async job description, it should be 
somthing like: job-[ 22 ] = [ 1075d499-03a8-44c3-ac9e-348dc5b32ba1 ]


Thanks,

Sanjay Tripathi

Re: Review Request 12205: message(s) made more identifying for the error location

[Hugo Trippaers]

Hah,

you beat me to it by seconds prassana ;-)


Cheers,

Hugo

On Jul 1, 2013, at 4:48 PM, "Prasanna Santhanam"  wrote:

> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12205/#review22598
> ---
> 
> Ship it!
> 
> 
> 216e374 -> 4.2
> 639592f -> master
> 
> - Prasanna Santhanam
> 
> 
> On July 1, 2013, 10:46 a.m., daan Hoogland wrote:
>> 
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/12205/
>> ---
>> 
>> (Updated July 1, 2013, 10:46 a.m.)
>> 
>> 
>> Review request for cloudstack.
>> 
>> 
>> Bugs: CLOUDSTACK-2162
>> 
>> 
>> Repository: cloudstack-git
>> 
>> 
>> Description
>> ---
>> 
>> make several messages made more distict and readible so identifying the 
>> error location is easier.
>> 
>> 
>> Diffs
>> -
>> 
>>  server/src/com/cloud/storage/StorageManagerImpl.java 138c6d7 
>> 
>> Diff: https://reviews.apache.org/r/12205/diff/
>> 
>> 
>> Testing
>> ---
>> 
>> 
>> Thanks,
>> 
>> daan Hoogland
>> 
>> 
> 

Re: Review Request 12205: message(s) made more identifying for the error location

[Prasanna Santhanam]

On Mon, Jul 01, 2013 at 04:49:53PM +0200, Hugo Trippaers wrote:
> Hah,
> 
> you beat me to it by seconds prassana ;-)

Hehe. Need help with some others though. Ones by Laszlo and Dave
Brosius esp are simpler to review since they touch java issues. Anyone
willing to help?

https://reviews.apache.org/users/kocka/
https://reviews.apache.org/users/mebigfatguy/

-- 
Prasanna.,


Powered by BigRock.com

Re: please review

[Prasanna Santhanam]

On Mon, Jul 01, 2013 at 04:26:00PM +0200, Daan Hoogland wrote:
> Can someone look at review request 12205. It only changes strings in
> exceptions and a log message.
> 
Done.

-- 
Prasanna.,


Powered by BigRock.com

Re: Review Request 11942: ProcessUtil cleanup

[John Burwell]

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



utils/test/com/cloud/utils/ProcessUtilTest.java


Is there no system state on which to assert?  What would cause this test to 
fail?



utils/test/com/cloud/utils/ProcessUtilTest.java


Is there no system state on which to assert?  What would cause this test to 
fail?



utils/test/com/cloud/utils/ProcessUtilTest.java


Is there no system state on which to assert?  What would cause this test to 
fail?


- John Burwell


On June 29, 2013, 3:51 p.m., Laszlo Hornyak wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11942/
> ---
> 
> (Updated June 29, 2013, 3:51 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> - possible resource leak closed
> - file content read uses now commons-lang FileUtils
> - Added unit tests
> 
> 
> Diffs
> -
> 
>   utils/src/com/cloud/utils/ProcessUtil.java c9fdf35 
>   utils/test/com/cloud/utils/ProcessUtilTest.java PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/11942/diff/
> 
> 
> Testing
> ---
> 
> test included
> 
> 
> Thanks,
> 
> Laszlo Hornyak
> 
>

Re: Review Request 12191: removed EnumerationImpl

[Hugo Trippaers]

> On July 1, 2013, 3:07 p.m., Hugo Trippaers wrote:
> > Ship It!

master: 16b7509a234158b536155be9278cfee33b93a5c7
4.2: 00e99a08169b60b0449d67dfc891053cf4469bf7


- Hugo


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


On June 29, 2013, 5:05 p.m., Laszlo Hornyak wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12191/
> ---
> 
> (Updated June 29, 2013, 5:05 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> EnumerationImpl was not used and duplicates functionality
> with org.apache.commons.collections.iterators.EnumerationIterator
> 
> 
> Diffs
> -
> 
>   utils/src/com/cloud/utils/CleanupDelegate.java 6c368c3 
> 
> Diff: https://reviews.apache.org/r/12191/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Laszlo Hornyak
> 
>

Re: Review Request 12190: removed CleanupDelegate

[Hugo Trippaers]

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

Ship it!


Ship It!

- Hugo Trippaers


On June 29, 2013, 5:03 p.m., Laszlo Hornyak wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12190/
> ---
> 
> (Updated June 29, 2013, 5:03 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> It did not have an implementation
> 
> 
> Diffs
> -
> 
>   utils/src/com/cloud/utils/CleanupDelegate.java 6c368c3 
> 
> Diff: https://reviews.apache.org/r/12190/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Laszlo Hornyak
> 
>

Re: Review Request 12191: removed EnumerationImpl

[Hugo Trippaers]

> On July 1, 2013, 3:07 p.m., Hugo Trippaers wrote:
> > Ship It!
> 
> Hugo Trippaers wrote:
> master: 16b7509a234158b536155be9278cfee33b93a5c7
> 4.2: 00e99a08169b60b0449d67dfc891053cf4469bf7

This was the wrong patch, this is the removed CleanupDelegate patch.  Can you 
submit the right patch for this review?


- Hugo


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


On June 29, 2013, 5:05 p.m., Laszlo Hornyak wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12191/
> ---
> 
> (Updated June 29, 2013, 5:05 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> EnumerationImpl was not used and duplicates functionality
> with org.apache.commons.collections.iterators.EnumerationIterator
> 
> 
> Diffs
> -
> 
>   utils/src/com/cloud/utils/CleanupDelegate.java 6c368c3 
> 
> Diff: https://reviews.apache.org/r/12191/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Laszlo Hornyak
> 
>

Re: Review Request 12190: removed CleanupDelegate

[Hugo Trippaers]

> On July 1, 2013, 3:11 p.m., Hugo Trippaers wrote:
> > Ship It!


master: 16b7509a234158b536155be9278cfee33b93a5c7
4.2: 00e99a08169b60b0449d67dfc891053cf4469bf7


- Hugo


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


On June 29, 2013, 5:03 p.m., Laszlo Hornyak wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12190/
> ---
> 
> (Updated June 29, 2013, 5:03 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> It did not have an implementation
> 
> 
> Diffs
> -
> 
>   utils/src/com/cloud/utils/CleanupDelegate.java 6c368c3 
> 
> Diff: https://reviews.apache.org/r/12190/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Laszlo Hornyak
> 
>

Re: Review Request 12191: removed EnumerationImpl

[Hugo Trippaers]

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

Ship it!


Ship It!

- Hugo Trippaers


On June 29, 2013, 5:05 p.m., Laszlo Hornyak wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12191/
> ---
> 
> (Updated June 29, 2013, 5:05 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> EnumerationImpl was not used and duplicates functionality
> with org.apache.commons.collections.iterators.EnumerationIterator
> 
> 
> Diffs
> -
> 
>   utils/src/com/cloud/utils/CleanupDelegate.java 6c368c3 
> 
> Diff: https://reviews.apache.org/r/12191/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Laszlo Hornyak
> 
>

Re: On git 4.1 (4.1.1-SNAPSHOT), jetty:run fails because of database version errors

[David Nalley]

I don't understand why this is a problem.

>From a systems perspective there is only one (correct) timezone.
Actually using timezones, especially in a geographically distributed
cloud is problematic.

--David

On Sun, Jun 30, 2013 at 11:27 PM, Ryan Lei  wrote:
> Great. Both the OSS and non-OSS builds fine on the 4.1 branch now! Tested
> on OS X 10.6.8 and CentOS 6.3.
>
> But here's another flaw in DB upgrade:
> The upgrade writes the timestamp in UTC+0 time zone in MySQL (in 4.1, 4.2,
> master):
>
> [4.1] mysql> select * from version;
> ++-+-+--+
> | id | version | updated | step |
> ++-+-+--+
> |  1 | 4.0.0   | 2013-07-01 10:05:24 | Complete |
> |  2 | 4.1.0   | 2013-07-01 02:18:36 | Complete |
> |  3 | 4.1.1   | 2013-07-01 02:18:36 | Complete |
> ++-+-+--+
>
> [4.2] mysql> select * from version;
> ++-+-+--+
> | id | version | updated | step |
> ++-+-+--+
> |  1 | 4.0.0   | 2013-07-01 10:38:22 | Complete |
> |  2 | 4.1.0   | 2013-07-01 02:41:17 | Complete |
> |  3 | 4.2.0   | 2013-07-01 02:41:18 | Complete |
> ++-+-+--+
>
> My time zone is CST (UTC+8). The correct time should be 2013-07-01 10:xx:xx.
>
> mysql> SELECT NOW(); reports the correct time, so I guess the problem is on
> the Java (JDBC?) side.
>
>
> ---
> Yu-Heng (Ryan) Lei, Associate Reasearcher
> Chunghwa Telecom Laboratories / Cloud Computing Laboratory
> ryan...@cht.com.tw
> or
> ryanlei750...@gmail.com
>
>
>
> On Sat, Jun 29, 2013 at 1:59 AM, Hugo Trippaers  wrote:
>
>> Hello :-)
>>
>> Nice find!
>>
>> I've pushed this commit to the branch:
>>
>>  commit b330f2aa909d7ddc387863e0806f71964f6d5f80
>> Author: Hugo Trippaers 
>> Date:   Fri Jun 28 10:57:51 2013 -0700
>>
>> CLOUDSTACK-3278 Add the 410 to 411 upgrade to the
>> PremiumDatabaseUpgradeChecker
>>
>> Can you verify if this fixes your problem?
>>
>>
>> Cheers,
>>
>> Hugo
>>
>> On Jun 28, 2013, at 10:39 AM, Ryan Lei  wrote:
>>
>> > Actually, the errors happen only in non-OSS build with git 4.1
>> > (4.1.1-SNAPSHOT).
>> >
>> > OSS build with git 4.1 and non-OSS build with 4.1.0 source code work
>> fine.
>> > They are able to run the Upgrade40to41 or Upgrade410to411.
>> >
>> > I have created a JIRA ticket for this issue:
>> > https://issues.apache.org/jira/browse/CLOUDSTACK-3278
>> >
>> >
>> ---
>> > Yu-Heng (Ryan) Lei, Associate Reasearcher
>> > Chunghwa Telecom Laboratories / Cloud Computing Laboratory
>> > ryan...@cht.com.tw<
>> https://email.cht.com.tw/owa/redir.aspx?C=-wE1FEC3G0SWYpVkiWo8SsDdf3ZqO9AIuAPTzRnFYCUi-z4YljtI_hyVKkNHfn9F1Bn-vUWJnQ4.&URL=mailto%3aryanlei%40cht.com.tw
>> >
>> > or
>> > ryanlei750...@gmail.com
>> >
>> >
>> >
>> > On Fri, Jun 28, 2013 at 4:42 PM, Ryan Lei  wrote:
>> >
>> >> Hi all,
>> >> I was trying to use the git 4.1 branch to run non-OSS CloudStack from
>> >> source. My commands were:
>> >>
>> >> (1) Put the neccessary jars in deps
>> >> (2) Run deps/install-non-oss.sh with success
>> >> (3) $ mvn clean install -DskipTests=true -Dnonoss
>> >> (4) $ mvn -P developer -pl developer -Ddeploydb
>> >> (5) $ mvn -pl :cloud-client-ui jetty:run
>> >>
>> >> Then I got these DB version errors which made the jetty quit:
>> >> INFO  [utils.component.ComponentContext] (Timer-2:) Running
>> >> SystemIntegrityChecker encryptionSecretKeyChecker
>> >> INFO  [utils.component.ComponentContext] (Timer-2:) Running
>> >> SystemIntegrityChecker databaseIntegrityChecker
>> >> INFO  [cloud.upgrade.DatabaseIntegrityChecker] (Timer-2:) Grabbing lock
>> to
>> >> check for database integrity.
>> >> INFO  [cloud.upgrade.DatabaseIntegrityChecker] (Timer-2:) Performing
>> >> database integrity check
>> >> INFO  [utils.component.ComponentContext] (Timer-2:) Running
>> >> SystemIntegrityChecker managementServerNode
>> >> INFO  [utils.component.ComponentContext] (Timer-2:) Running
>> >> SystemIntegrityChecker premiumDatabaseUpgradeChecker
>> >> INFO  [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) Grabbing lock to
>> >> check for database upgrade.
>> >> INFO  [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) DB version =
>> 4.0.0
>> >> Code Version = 4.1.1-SNAPSHOT
>> >> INFO  [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) Database upgrade
>> >> must be performed from 4.0.0 to 4.1.1-SNAPSHOT
>> >> ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) The end upgrade
>> >> version is actually at 4.1.0 but our management server code version is
>> at
>> >> 4.1.1-SNAPSHOT
>> >> ERROR [utils.compon

Re: Master build problem

[Prasanna Santhanam]

On Mon, Jul 01, 2013 at 08:44:28AM +, Paul Angus wrote:
> This was a completely fresh build from the 4.2 branch (oss).
> 
> I don't use dev cloud as it's not representative of a real environment. I ran:
> 
Should fail on devcloud too ideally.

> yum install -y cloud-client # run against local 4.2 repo
> cloudstack-setup-databases cloud:cloud@$MYSQLIP --deploy-as=root:password
> cloudstack-setup-management
> 

Ok, thought you were running dev environment. If you see something
like "Admin user enabled" then everything went fine. Else we'll need
to see the management server logs to see if any of the classes has
misbehaved or hasn't done what it's supposed to do. 

You can also enable trace level log for two classes in particular that
we're chasing here: AccountManagerImpl and ConfigurationServerImpl.

See #5 in the wiki https://cwiki.apache.org/confluence/x/5QL8AQ on how
to achieve this.

com.cloud.user.AccountManagerImpl
com.cloud.server.ConfigurationServerImpl

> that's it...
> 
> as a work around I assume I can open the unauthenticated api port
> and create a user (which I know the password for)...

Umm, the system user should also have been randomized credentials so
you won't be able to login. The security loophole here was fixed
sometime ago.

-- 
Prasanna.,


Powered by BigRock.com

Re: Review Request 12106: Removed Dead Code from Management Server Hyper-V 2012 Support

[Prasanna Santhanam]

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


commit 4361418e415b81567423367c0bd3aff263cc15c8
Author: Donal Lafferty 
Date:   Thu Jun 27 11:46:02 2013 -0700



Closing the review

- Prasanna Santhanam


On June 27, 2013, 8:56 a.m., Donal Lafferty wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12106/
> ---
> 
> (Updated June 27, 2013, 8:56 a.m.)
> 
> 
> Review request for cloudstack, Alex Huang, Chip Childers, and edison su.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Update ImageFormat enum to include VHDX format introduced with Hyper-V Server 
> 2012.
> Remove existing Hyper-V plugin, because it does not work and is dead code.
> Remove references to existing Hyper-V plugin from config files.
> Remove Hypervisor.HypervisorType.Hyperv special cases from manager code that 
> are unused or unsupported.
> Specifically, there is no CIFS secondary storage class 
> "CifsSecondaryStorageResource".  Also, the Hyper-V plugin's ServerResource is 
> contacted by the management server and not the other way around.
> Add Hyperv-V support to ListHypervisorsCmd API call
> 
> 
> Diffs
> -
> 
>   agent/src/com/cloud/agent/VmmAgentShell.java 
> 190d1168284243f9e860677a03311da9db31c745 
>   api/src/com/cloud/storage/Storage.java 
> 9a50ffa786c9a1b516baa7b8bce04de7d3c7b2bc 
>   client/tomcatconf/applicationContext.xml.in 
> ac1f3e46fdb43b4a5e38f9f2b3c498a2c258a0aa 
>   core/src/com/cloud/hypervisor/hyperv/resource/HypervResource.java 
> 725f0cc1ae214447f20f5cd51c40e7e9128f0506 
>   engine/storage/integration-test/test/resource/component.xml 
> 5ba87e8ebe9a682b320c60caf0e0057d2eb92027 
>   plugins/network-elements/dns-notifier/resources/components-example.xml 
> 717c5e063fe0271eeb1143215a493c6342c5811e 
>   server/src/com/cloud/configuration/Config.java 
> ba508495c350714fff90da0923b046783d42b1c3 
>   server/src/com/cloud/hypervisor/guru/HypervGuru.java 
> 630080e21cbb6a501d67bda41179feb278b3d79c 
>   server/src/com/cloud/hypervisor/hyperv/HypervServerDiscoverer.java 
> 06658b7f3e2ea5e80edf012dcaf29d980758084d 
>   server/src/com/cloud/resource/ResourceManagerImpl.java 
> fe91cb337d0f5901012ca45e131d9cb2f7c54cf2 
>   server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java 
> 954c7e970f02e7ba0eae6e8e1616d9a08c9168b0 
> 
> Diff: https://reviews.apache.org/r/12106/diff/
> 
> 
> Testing
> ---
> 
> Compiled using mvn clean install, used in integration test on cshv3 branch 
> from github mirror.
> 
> 
> Thanks,
> 
> Donal Lafferty
> 
>

Error while Porting xenserver-6.2.0 in CS 4.1

[Keerthiraja SJ]

Hi

I tried to complied CS 4.1 to port xenserver-6.2.0 support.

Can someone help me what went wrong in this.



[INFO]
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @
cloud-engine-storage-snapshot ---
[INFO] Surefire report directory:
/root/cloudstack-4.1/dist/rpmbuild/BUILD/cloudstack-4.1.1-SNAPSHOT/engine/storage/snapshot/target/surefire-reports

---
 T E S T S
---

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @
cloud-engine-storage-snapshot ---
[INFO] Building jar:
/root/cloudstack-4.1/dist/rpmbuild/BUILD/cloudstack-4.1.1-SNAPSHOT/engine/storage/snapshot/target/cloud-engine-storage-snapshot-4.1.1-SNAPSHOT.jar
[INFO]
[INFO] --- maven-site-plugin:3.1:attach-descriptor (attach-descriptor) @
cloud-engine-storage-snapshot ---
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @
cloud-engine-storage-snapshot ---
[INFO] Deleting
/root/cloudstack-4.1/dist/rpmbuild/BUILD/cloudstack-4.1.1-SNAPSHOT/engine/storage/snapshot/target
[INFO]
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @
cloud-engine-storage-snapshot ---
[INFO]
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @
cloud-engine-storage-snapshot ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/root/cloudstack-4.1/dist/rpmbuild/BUILD/cloudstack-4.1.1-SNAPSHOT/engine/storage/snapshot/src/main/resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO]
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @
cloud-engine-storage-snapshot ---
[INFO] Compiling 8 source files to
/root/cloudstack-4.1/dist/rpmbuild/BUILD/cloudstack-4.1.1-SNAPSHOT/engine/storage/snapshot/target/classes
[INFO]
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources)
@ cloud-engine-storage-snapshot ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/root/cloudstack-4.1/dist/rpmbuild/BUILD/cloudstack-4.1.1-SNAPSHOT/engine/storage/snapshot/src/test/resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO]
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @
cloud-engine-storage-snapshot ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @
cloud-engine-storage-snapshot ---
[INFO] Skipping execution of surefire because it has already been run for
this configuration
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @
cloud-engine-storage-snapshot ---
[INFO] Building jar:
/root/cloudstack-4.1/dist/rpmbuild/BUILD/cloudstack-4.1.1-SNAPSHOT/engine/storage/snapshot/target/cloud-engine-storage-snapshot-4.1.1-SNAPSHOT.jar
[INFO]
[INFO] --- maven-site-plugin:3.1:attach-descriptor (attach-descriptor) @
cloud-engine-storage-snapshot ---
[INFO]
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @
cloud-engine-storage-snapshot ---
[INFO] Installing
/root/cloudstack-4.1/dist/rpmbuild/BUILD/cloudstack-4.1.1-SNAPSHOT/engine/storage/snapshot/target/cloud-engine-storage-snapshot-4.1.1-SNAPSHOT.jar
to
/root/.m2/repository/org/apache/cloudstack/cloud-engine-storage-snapshot/4.1.1-SNAPSHOT/cloud-engine-storage-snapshot-4.1.1-SNAPSHOT.jar
[INFO] Installing
/root/cloudstack-4.1/dist/rpmbuild/BUILD/cloudstack-4.1.1-SNAPSHOT/engine/storage/snapshot/pom.xml
to
/root/.m2/repository/org/apache/cloudstack/cloud-engine-storage-snapshot/4.1.1-SNAPSHOT/cloud-engine-storage-snapshot-4.1.1-SNAPSHOT.pom
[INFO]

[INFO]

[INFO] Building Apache CloudStack Client UI 4.1.1-SNAPSHOT
[INFO]

Downloading:
http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.3/maven-war-plugin-2.3.pom
Downloaded:
http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.3/maven-war-plugin-2.3.pom(8
KB at 4.5 KB/sec)
Downloading:
http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.3/maven-war-plugin-2.3.jar
Downloaded:
http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.3/maven-war-plugin-2.3.jar(82
KB at 32.7 KB/sec)
Downloading:
http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-xen/4.1.1-SNAPSHOT/maven-metadata.xml
Downloading:
http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-xen/4.1.1-SNAPSHOT/cloud-plugin-hypervisor-xen-4.1.1-SNAPSHOT.pom
[WARNING] The POM for
org.apache.cloudstack:cloud-plugin-hypervisor-xen:jar:4.1.1-SNAPSHOT is
missing, no dependency information available
Downloading:
http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-xen/4.1.1-SNAPSHOT/c

Re: Jenkins and IRC

[Hugo Trippaers]

Heya,

I "fixed" it manually for now. I've connected our cloud to the jenkins sytem. 
So there will be a few slaves popping up with names like 
'cloudstack-buildslave-centos6-xxx'. These are automagically created by jenkins.

I've setup the cloudstack-master build to use these slaves in addition to the 
rpmbuilder, by setting the label expression.  If this works we can add this 
label to more builds.

Cheers,

Hugo

On Jun 30, 2013, at 10:44 PM, David Nalley  wrote:

> On Sun, Jun 30, 2013 at 4:11 AM, Prasanna Santhanam  wrote:
>> On Fri, Jun 28, 2013 at 10:25:47AM -0700, Hugo Trippaers wrote:
> @David, remember that nginx proxy timeout setting we discussed ages
> ago? Would be nice to get that sorted so we can use some extra cloud
> power on jenkins.cloudstack.org. Any ideas on how we can get that
> done?
 
 I plan on moving the current jenkins node on to a CloudStack setup
 along with configuring jenkins purely via github/yaml config files.
 still exploring. I think there should be some nginx puppet recipes
 around for quick configuration.
>>> 
>>> Nice! I still have some cloud power i can add to the jenkins pool in
>>> our cloud, so with all those clouds we should be able to speed
>>> things up.
>> 
>> Yup - that's where we should be headed.
>> 
>>> 
>>> I tried making the change to the nginx configuration a while back,
>>> but some it did not get propagated, maybe you can have a look?  This
>>> is my commit on the puppet module:
>>> https://github.com/CloudStack-extras/cso-infrastructure/commit/9d65207989e7cbc5231f3f5184bd4bf6bf0f84d5
>> 
>> I don't know if the instance has been pulling config changes from
>> puppet anymore. It might need reviving. @David, is puppetmaster still
>> running for the cso-infra?
>> 
> 
> I don't believe it is - and I am hoping we move to a CloudStack-hosted
> Jenkins rather than the current one.
> 
> --David

Re: Review Request 12109: HAProxy maxconn is not configurable

[Prasanna Santhanam]

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

(Updated July 1, 2013, 3:55 p.m.)


Review request for cloudstack, Abhinandan Prateek and Jayapal Reddy.


Changes
---

Jayapal (ping)


Bugs: Cloudstack-2997


Repository: cloudstack-git


Description
---

Cloudstack-2997 HAProxy maxconn is not configurable
https://issues.apache.org/jira/browse/CLOUDSTACK-2997


Diffs
-

  api/src/com/cloud/offering/NetworkOffering.java 5f522eb 
  api/src/org/apache/cloudstack/api/ApiConstants.java b43f06c 
  
api/src/org/apache/cloudstack/api/command/admin/network/CreateNetworkOfferingCmd.java
 febb0c3 
  
api/src/org/apache/cloudstack/api/command/admin/network/UpdateNetworkOfferingCmd.java
 ba685a9 
  core/src/com/cloud/agent/api/routing/LoadBalancerConfigCommand.java 1c1fb91 
  core/src/com/cloud/network/HAProxyConfigurator.java 29fdf4a 
  engine/schema/src/com/cloud/offerings/NetworkOfferingVO.java fae315b 
  
plugins/network-elements/elastic-loadbalancer/src/com/cloud/network/lb/ElasticLoadBalancerManagerImpl.java
 b21e8f9 
  
plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManagerImpl.java
 2bdb28f 
  
plugins/network-elements/internal-loadbalancer/test/org/apache/cloudstack/internallbvmmgr/InternalLBVMManagerTest.java
 a19a82e 
  server/src/com/cloud/configuration/Config.java 2b0ffaf 
  server/src/com/cloud/configuration/ConfigurationManager.java 8db037b 
  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 97f0d33 
  server/src/com/cloud/network/NetworkManagerImpl.java 8c2806a 
  server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
7f3a88e 
  server/test/com/cloud/vpc/MockConfigurationManagerImpl.java 21b3590 
  
server/test/org/apache/cloudstack/networkoffering/CreateNetworkOfferingTest.java
 4a2c867 
  setup/db/db/schema-410to420.sql 181f1cb 

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


Testing
---

Tested on master.


Thanks,

bharat kumar

Re: Jenkins and IRC

[John Burwell]

Prasanna,

I don't think a small namespace will deliver much value.  We are responsible 
for maintaining the code base -- even the older code that will eventually be 
replaced.  I would prefer to start with a smaller set of rules focused on high 
priority issues (e.g. lack of proper equals, hashCode, and toString 
implementations), fix them across the entire codebase, and then expand the rule 
set.  Wash, rinse, repeat until we have a complete rule set and a compliant 
code base.  

Thanks,
-John

On Jun 29, 2013, at 2:12 AM, Prasanna Santhanam  wrote:

> On Fri, Jun 28, 2013 at 02:45:02PM -0400, John Burwell wrote:
>> Prasanna,
>> 
>> I am all for static analysis, but I think we should discuss it before
>> implementation to ensure that the community is in sync on the rules
>> and priority.  I am of the belief that static analysis shouldn't check
>> for violations that we don't are worthy of breaking a build.  However,
>> implementing such an approach would take a fair amount if coordination
>> and effort for (needed) cleanup.
> 
> Sure - we can start with a small namespace, say
> org.apache.cloudstack.storage, and extend the envelope based on
> discussions. Makes sense?
> 
>> 
>> That's my $0.02,
>> -John
>> 
> -- 
> Prasanna.,
> 
> 
> Powered by BigRock.com
> 

Re: Jenkins and IRC

[Chip Childers]

On Mon, Jul 01, 2013 at 12:05:44PM -0400, John Burwell wrote:
> Prasanna,
> 
> I don't think a small namespace will deliver much value.  We are responsible 
> for maintaining the code base -- even the older code that will eventually be 
> replaced.  I would prefer to start with a smaller set of rules focused on 
> high priority issues (e.g. lack of proper equals, hashCode, and toString 
> implementations), fix them across the entire codebase, and then expand the 
> rule set.  Wash, rinse, repeat until we have a complete rule set and a 
> compliant code base.  
> 
> Thanks,
> -John

Same goal / different paths...  FWIW, I'm with John.  However, someone
needs to propose the initial set of rules.

> 
> On Jun 29, 2013, at 2:12 AM, Prasanna Santhanam  wrote:
> 
> > On Fri, Jun 28, 2013 at 02:45:02PM -0400, John Burwell wrote:
> >> Prasanna,
> >> 
> >> I am all for static analysis, but I think we should discuss it before
> >> implementation to ensure that the community is in sync on the rules
> >> and priority.  I am of the belief that static analysis shouldn't check
> >> for violations that we don't are worthy of breaking a build.  However,
> >> implementing such an approach would take a fair amount if coordination
> >> and effort for (needed) cleanup.
> > 
> > Sure - we can start with a small namespace, say
> > org.apache.cloudstack.storage, and extend the envelope based on
> > discussions. Makes sense?
> > 
> >> 
> >> That's my $0.02,
> >> -John
> >> 
> > -- 
> > Prasanna.,
> > 
> > 
> > Powered by BigRock.com
> > 
> 
> 

Re: Jenkins and IRC

[Prasanna Santhanam]

On Mon, Jul 01, 2013 at 05:51:55PM +0200, Hugo Trippaers wrote:
> Heya,
> 
> I "fixed" it manually for now. I've connected our cloud to the
> jenkins sytem. So there will be a few slaves popping up with names
> like 'cloudstack-buildslave-centos6-xxx'. These are automagically
> created by jenkins.

*dogfood* - gotta love it!

-- 
Prasanna.,


Powered by BigRock.com

Re: Jenkins and IRC

[Prasanna Santhanam]

On Mon, Jul 01, 2013 at 12:07:47PM -0400, Chip Childers wrote:
> On Mon, Jul 01, 2013 at 12:05:44PM -0400, John Burwell wrote:
> > Prasanna,
> > 
> > I don't think a small namespace will deliver much value.  We are
> > responsible for maintaining the code base -- even the older code
> > that will eventually be replaced.  I would prefer to start with a
> > smaller set of rules focused on high priority issues (e.g. lack of
> > proper equals, hashCode, and toString implementations), fix them
> > across the entire codebase, and then expand the rule set.  Wash,
> > rinse, repeat until we have a complete rule set and a compliant
> > code base.  
> > 
> > Thanks,
> > -John
> 
> Same goal / different paths...  FWIW, I'm with John.  However, someone
> needs to propose the initial set of rules.
> 

Works for me!


-- 
Prasanna.,


Powered by BigRock.com

Re: Review Request 12205: message(s) made more identifying for the error location

[Daan Hoogland]

Is this request of yours still valid? happy to do a review or a half.


On Mon, Jul 1, 2013 at 4:53 PM, Prasanna Santhanam  wrote:

> On Mon, Jul 01, 2013 at 04:49:53PM +0200, Hugo Trippaers wrote:
> > Hah,
> >
> > you beat me to it by seconds prassana ;-)
>
> Hehe. Need help with some others though. Ones by Laszlo and Dave
> Brosius esp are simpler to review since they touch java issues. Anyone
> willing to help?
>
> https://reviews.apache.org/users/kocka/
> https://reviews.apache.org/users/mebigfatguy/
>
> --
> Prasanna.,
>
> 
> Powered by BigRock.com
>
>

RE: Review Request 12189: Apach CloudStack 4.1 Quick Install Guide (en-US)

[Soheil Eizadi]

Last week I had someone in Tech Marketing bring up a 4.1 using the distribution 
and following the installation guide. They were not able to connect the 
XenServer to CloudStack due to the  /usr/bin/vhd-util 
/opt/xenserver/bin/vhd-util not being present. I patched the system so it was 
operational.
-Soheil

From: Sebastien Goasguen [nore...@reviews.apache.org] on behalf of Sebastien 
Goasguen [run...@gmail.com]
Sent: Saturday, June 29, 2013 12:44 PM
To: cloudstack; Sebastien Goasguen; meng han
Subject: Re: Review Request 12189: Apach CloudStack 4.1 Quick Install Guide 
(en-US)

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

Ship it!


committed to master with 676d8744ef6801cf3fcf6425d37ba27a149e5615
also committed to 4.1 and 4.2 branch

make sure to add your name and email to your .gitconfig

also make sure to squash trailing whitespaces

thanks for this, it's great

please mark the review as submitted

- Sebastien Goasguen


On June 29, 2013, 3:54 p.m., meng han wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12189/
> ---
>
> (Updated June 29, 2013, 3:54 p.m.)
>
>
> Review request for cloudstack.
>
>
> Repository: cloudstack-git
>
>
> Description
> ---
>
> This is the ACS quick install guide for the branch 4.1
>
>
> Diffs
> -
>
>   docs/qig/en-US/Author_Group.xml PRE-CREATION
>   docs/qig/en-US/Book_Info.xml PRE-CREATION
>   docs/qig/en-US/Chapter.xml PRE-CREATION
>   docs/qig/en-US/Environment.xml PRE-CREATION
>   docs/qig/en-US/Management.xml PRE-CREATION
>   docs/qig/en-US/Overview.xml PRE-CREATION
>   docs/qig/en-US/Preface.xml PRE-CREATION
>   docs/qig/en-US/Revision_History.xml PRE-CREATION
>   docs/qig/en-US/config.xml PRE-CREATION
>   docs/qig/en-US/kvm.xml PRE-CREATION
>   docs/qig/en-US/qig.ent PRE-CREATION
>   docs/qig/en-US/qig.xml PRE-CREATION
>
> Diff: https://reviews.apache.org/r/12189/diff/
>
>
> Testing
> ---
>
> I tested the quick install guide of 4.0 and created this 4.1 guide 
> accordingly.
> Test it successfully on my desktop (centos6.4).
>
>
> Thanks,
>
> meng han
>
>

RE: [ACS42] Branch created

[Animesh Chaturvedi]

> -Original Message-
> From: Sudha Ponnaganti [mailto:sudha.ponnaga...@citrix.com]
> Sent: Saturday, June 29, 2013 12:00 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [ACS42] Branch created
> 
> Just want to confirm if upgrades are all enabled for 4.2??
[Animesh>] Upgrades should work but Alena will check and confirm
> 
> -Original Message-
> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> Sent: Saturday, June 29, 2013 10:31 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [ACS42] Branch created
> 
> Great!
> 
> I've setup the basic build jobs for 4.2 on jenkins.cloudstack.org.  I
> would like to send all build failures from those jobs directly to the
> dev list. Can a moderator add jenk...@cloudstack.org to the whitelist of
> the dev mailing list?
> 
> Cheers,
> 
> Hugo
> 
> On Jun 29, 2013, at 9:30 AM, Animesh Chaturvedi
>  wrote:
> 
> > I have created 4.2 branch
> >
> > Animesh

RE: [ACS42] Branch created

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Sunday, June 30, 2013 11:02 AM
> To: 
> Subject: Re: [ACS42] Branch created
> 
> On Jun 30, 2013, at 12:39 PM, Prasanna Santhanam  wrote:
> 
> > On Sun, Jun 30, 2013 at 04:29:31PM +, Animesh Chaturvedi wrote:
> >>
> >>
> >>> -Original Message-
> >>> From: Sateesh Chodapuneedi [mailto:sateesh.chodapune...@citrix.com]
> >>> Sent: Saturday, June 29, 2013 8:34 PM
> >>> To: dev@cloudstack.apache.org
> >>> Subject: RE: [ACS42] Branch created
> >>>
> >>> Hi Animesh,
> >>> Can you please let me know if commits into this branch are
> controlled?
> >>>
> >>> Regards,
> >>> Sateesh
> >> [Animesh>] No the commits are not controlled at this time but no new
> >> features can be added only bug fixes
> >
> > Should be (the same as it was for 4.1), RM will cherry-pick from
> > master/ apply from reviewboard. Except for docs and test script fixes
> > which can be pushed in post freeze. Any reason why it should not be
> > this way?
> 
> That isn't until later in the schedule. The RM shouldn't be a bottleneck
> to bug fixing right now.
[Animesh>] Chip thanks for responding, yes we need to make sure bug fixing is 
efficient. We will move to limited updates by end of this month
> 
> >
> > --
> > Prasanna.,
> >
> > 
> > Powered by BigRock.com
> >
> >

Test email #1

[jenkins]

This is test email #1 sent from Jenkins

Test email #3

[jenkins]

This is test email #3 sent from Jenkins

RE: [MERGE] Merge VMSync improvement branch into master

[Musayev, Ilya]

Alex,

I completely understand. Please keep us in the loop on the progress. If its 
functional to some extent - i.e. at least build succeeds without errors and 
major functionality is there, I can merge the code into CloudSand CS distro - 
to test it out and share it with whoever wants to try it. 

Thanks
ilya

> -Original Message-
> From: Alex Huang [mailto:alex.hu...@citrix.com]
> Sent: Friday, June 28, 2013 9:16 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [MERGE] Merge VMSync improvement branch into master
> 
> Given the current state of BVT, I don't think we can reliably merge this into
> master.  It will have to wait for 4.3.  I apologize to those who really want 
> to
> see this feature in.  I myself have slaved over this for some weeks, including
> missing the collab conference, but I just cannot conscientiously push it in
> under the current circumstances.
> 
> --Alex
> 
> > -Original Message-
> > From: Sudha Ponnaganti [mailto:sudha.ponnaga...@citrix.com]
> > Sent: Friday, June 28, 2013 7:11 AM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [MERGE] Merge VMSync improvement branch into master
> >
> > Ideally I would like to see all validation to be done on feature
> > branch - BVTs and also manual validation of the P1 test cases from VM
> > Sync test plan just like object store validation - sadhu has signed up
> > for it along with Ilya. This would help us to identify feature specific 
> > issues.
> >
> > We are running BVTs right now which have high failure rate. Focusing
> > on this part right now to reach parity with Master branch.
> >
> >
> > -Original Message-
> > From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> > Sent: Thursday, June 27, 2013 5:32 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [MERGE] Merge VMSync improvement branch into master
> >
> > I agree with John that a change like this is very hard to test in an
> > automated fashion. Still i have been looking at the numbers for the
> > code coverage with cobertura. I was a bit disappointed to find that we
> > have not made any progress with this merge with regards to unit tests and
> total code coverage.
> > We do not seem to be in a worse shape than before.
> >
> > @Sudha, it would be nice if you could add your view on this patch from
> > the QA perspective? How would this patch affect your planning for
> example?
> >
> > Cheers,
> >
> > Hugo
> >
> > On Jun 27, 2013, at 5:12 PM, John Burwell  wrote:
> >
> > > @David The types of concurrency changes introduced in this patch are
> > > extremely difficult to completely test in an automated fashion.
> > > Therefore, code review for correctness is critical to ensure quality.
> > > To be clear, I am not questioning the value of automated testing.  I
> > > am just noting that it's next to impossible to achieve full
> > > coverage, and code review is an critical supplement.
> > >
> > > @Ilya I plan to review this patch, but I will be able to start until
> > > next week.  I am also still reviewing object_store (a separate
> > > procedural issue for another thread), and need to complete solidfire.
> > > This backlog is precisely why need to be reviewing iteratively
> > > throughout the dev cycle.
> > >
> > > Thanks,
> > > -John
> > >
> > > On Jun 27, 2013, at 7:35 PM, David Nalley  wrote:
> > >
> > >> On Thu, Jun 27, 2013 at 5:51 PM, Hugo Trippaers 
> > wrote:
> > >>>
> > >>> I think Ilya offers is great, my current stance is also to see how
> > >>> we can
> > bring this forward.
> > >>>
> > >>> I've had the opportunity to meet with several people at the Citrix
> > >>> office
> > in Santa Clara, i'm actually working from their office at this moment.
> > I think it's also the responsibility of someone who put in a -1 to
> > work with the original committer to get the situation resolved. So
> > i'll invest the time to help with the review as well.
> > >>>
> > >>> It would be great if Alex or Kelven could take the time to explain
> > >>> how
> > this feature has been tested. That would give the community some
> > insight as well.
> > >>>
> > >>> My main technical problem with this merge is that stuff is moving
> > >>> all over
> > the place without having even the slightest idea why. Now having
> > discussed this with Alex in person i get the general idea of this
> > merge, so can actually try to review it.
> > >>>
> > >>> I think that John have nicely explained what we could do to
> > >>> prevent
> > situations like this in advance. I fully understand that big features
> > or rewrites don't happen overnight and might show up near the end of the
> release cycle.
> > With the time based release cycle it's always a risk that some feature
> > might not make it in on time. Getting more people involved and
> > chunking the commits into master will greatly speed up the reviewing
> process.
> > >>>
> > >>> I'll get back to this after spending some time on reviewing the
> > >>> actual
> > patch. In fact i would like to ask more people to hav

Re: Review Request 11992: CLOUDSTACK-2571 ZWPS issues with Enabling/Clearing the Maintenance State of the Storage

[edison su]

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

Ship it!


Ship It!

- edison su


On June 28, 2013, 9:18 a.m., Rajesh Battala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11992/
> ---
> 
> (Updated June 28, 2013, 9:18 a.m.)
> 
> 
> Review request for cloudstack, Alex Huang, edison su, Ram Ganesh, and Sateesh 
> Chodapuneedi.
> 
> 
> Bugs: CLOUDSTACK-2571
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Issue : NPE's are happening when ZWPS is put in maintenance, removed from 
> maintenance.
> 
> Fixed:
> 1. Added ZONE scope storage handling in StorageManagerImpl and 
> StoragePoolAutomationImpl 
> 2. Modified PrimaryDataStoreDao, listBy method to take poolid to Wrapper 
> class of long instead of primitive. Modified associated DaoImpl.
> 3. StoragePoolAutomationImpl, when storage is setting to Maintenance mode, 
> handled the case for ZONE wide scope of storage. 
>if the storage is zone wide, get all the hosts(kvm, vmware) in zone and 
> send the ModifyStoragePool command (with false)
> 4. When users, cancels maintenance mode, the handled the ZONE wide scope of 
> storage pool.
> 5. Once the Storage is in maintenance, Deletion of the Storage will remove 
> the mount points from all the hosts.
> 
> This patch will solve all the issues pertaining to keeping/cancelling the 
> ZONE wide primary storage.
> 
> 
> Diffs
> -
> 
>   
> engine/api/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
>  99b7b9c 
>   
> engine/api/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
>  8f7826f 
>   server/src/com/cloud/storage/StorageManagerImpl.java b3e8b96 
>   server/src/com/cloud/storage/StoragePoolAutomationImpl.java 4001775 
> 
> Diff: https://reviews.apache.org/r/11992/diff/
> 
> 
> Testing
> ---
> 
> Manual Testing
> = 
> 1. Enable maintenance mode of Zone wide storage , There were no NPE's 
> happening and successfully kept the storage in maintenance mode. Verified DB 
> status.
> 2. Cancel maintenance mode of Zone wide storage, There were no NPE's 
> happening and successfully kept the storage in UP state.
> 3. Enable maintenance mode of zone wide, once successful then Delete the 
> storage, Storage got deleted successfuly. Verify the hosts,  Storage got 
> unmounted and verified the DB status.
> Addition Tests (As the common code path is modified):
> 1. Add the Cluster scope of primary storage (kvm , xenserver). Adding the 
> storage in both clusters is successful.
> kvm specific:
> 
> 2. Enable Maintenance Mode of cluster scope kvm storage. Successfully enabled 
> the storage in maintenance state. 
> 3. Cancel the Maintenance Mode of cluster scope kvm storage. Successfully 
> enabled the storage in UP state.
> 4. Enable Maintenance Mode of cluster scope kvm storage. Delete the storage. 
> Storage got successfully deleted, unmounted from hosts and from db.
> 
> Xenserver specific:
> ===
> 5. Enable Maintenance Mode of cluster scope Xenserver storage. Successfully 
> enabled the storage in maintenance state. 
> 6. Cancel the Maintenance Mode of cluster scope Xenserver storage. 
> Successfully enabled the storage in UP state.
> 7. Enable Maintenance Mode of cluster scope Xenserver storage. Delete the 
> storage. Storage got successfully deleted, unmounted from hosts and from db.
> 
> ZWPS is supported in KVM and VMware, the common code is modified. It should 
> work of VMWare as well without any issues
> 
> 
> Thanks,
> 
> Rajesh Battala
> 
>

Re: Review Request 11992: CLOUDSTACK-2571 ZWPS issues with Enabling/Clearing the Maintenance State of the Storage

[ASF Subversion and Git Services]

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


Commit 160b493285f6c72e1e93509dfd470c4bd7da7945 in branch refs/heads/4.2 from 
Rajesh Battala
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=160b493 ]

CLOUDSTACK-2571 Zone Wide Primary Storage blocker issues while Enabling in 
Maintenance State

Signed-off-by: Edison Su 


- ASF Subversion and Git Services


On June 28, 2013, 9:18 a.m., Rajesh Battala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11992/
> ---
> 
> (Updated June 28, 2013, 9:18 a.m.)
> 
> 
> Review request for cloudstack, Alex Huang, edison su, Ram Ganesh, and Sateesh 
> Chodapuneedi.
> 
> 
> Bugs: CLOUDSTACK-2571
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Issue : NPE's are happening when ZWPS is put in maintenance, removed from 
> maintenance.
> 
> Fixed:
> 1. Added ZONE scope storage handling in StorageManagerImpl and 
> StoragePoolAutomationImpl 
> 2. Modified PrimaryDataStoreDao, listBy method to take poolid to Wrapper 
> class of long instead of primitive. Modified associated DaoImpl.
> 3. StoragePoolAutomationImpl, when storage is setting to Maintenance mode, 
> handled the case for ZONE wide scope of storage. 
>if the storage is zone wide, get all the hosts(kvm, vmware) in zone and 
> send the ModifyStoragePool command (with false)
> 4. When users, cancels maintenance mode, the handled the ZONE wide scope of 
> storage pool.
> 5. Once the Storage is in maintenance, Deletion of the Storage will remove 
> the mount points from all the hosts.
> 
> This patch will solve all the issues pertaining to keeping/cancelling the 
> ZONE wide primary storage.
> 
> 
> Diffs
> -
> 
>   
> engine/api/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
>  99b7b9c 
>   
> engine/api/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
>  8f7826f 
>   server/src/com/cloud/storage/StorageManagerImpl.java b3e8b96 
>   server/src/com/cloud/storage/StoragePoolAutomationImpl.java 4001775 
> 
> Diff: https://reviews.apache.org/r/11992/diff/
> 
> 
> Testing
> ---
> 
> Manual Testing
> = 
> 1. Enable maintenance mode of Zone wide storage , There were no NPE's 
> happening and successfully kept the storage in maintenance mode. Verified DB 
> status.
> 2. Cancel maintenance mode of Zone wide storage, There were no NPE's 
> happening and successfully kept the storage in UP state.
> 3. Enable maintenance mode of zone wide, once successful then Delete the 
> storage, Storage got deleted successfuly. Verify the hosts,  Storage got 
> unmounted and verified the DB status.
> Addition Tests (As the common code path is modified):
> 1. Add the Cluster scope of primary storage (kvm , xenserver). Adding the 
> storage in both clusters is successful.
> kvm specific:
> 
> 2. Enable Maintenance Mode of cluster scope kvm storage. Successfully enabled 
> the storage in maintenance state. 
> 3. Cancel the Maintenance Mode of cluster scope kvm storage. Successfully 
> enabled the storage in UP state.
> 4. Enable Maintenance Mode of cluster scope kvm storage. Delete the storage. 
> Storage got successfully deleted, unmounted from hosts and from db.
> 
> Xenserver specific:
> ===
> 5. Enable Maintenance Mode of cluster scope Xenserver storage. Successfully 
> enabled the storage in maintenance state. 
> 6. Cancel the Maintenance Mode of cluster scope Xenserver storage. 
> Successfully enabled the storage in UP state.
> 7. Enable Maintenance Mode of cluster scope Xenserver storage. Delete the 
> storage. Storage got successfully deleted, unmounted from hosts and from db.
> 
> ZWPS is supported in KVM and VMware, the common code is modified. It should 
> work of VMWare as well without any issues
> 
> 
> Thanks,
> 
> Rajesh Battala
> 
>

RE: [MERGE] Merge VMSync improvement branch into master

[Alex Huang]

Ilya,

Thanks!  The current problem on this branch is we're trying to distinguish 
what's actually broken on master and what's broken by introducing this change.  
At this point, the branch is basically frozen and only applying bug fixes once 
BVT found problems.

--Alex

> -Original Message-
> From: Musayev, Ilya [mailto:imusa...@webmd.net]
> Sent: Monday, July 1, 2013 10:16 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [MERGE] Merge VMSync improvement branch into master
> 
> Alex,
> 
> I completely understand. Please keep us in the loop on the progress. If its
> functional to some extent - i.e. at least build succeeds without errors and
> major functionality is there, I can merge the code into CloudSand CS distro -
> to test it out and share it with whoever wants to try it.
> 
> Thanks
> ilya
> 
> > -Original Message-
> > From: Alex Huang [mailto:alex.hu...@citrix.com]
> > Sent: Friday, June 28, 2013 9:16 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [MERGE] Merge VMSync improvement branch into master
> >
> > Given the current state of BVT, I don't think we can reliably merge
> > this into master.  It will have to wait for 4.3.  I apologize to those
> > who really want to see this feature in.  I myself have slaved over
> > this for some weeks, including missing the collab conference, but I
> > just cannot conscientiously push it in under the current circumstances.
> >
> > --Alex
> >
> > > -Original Message-
> > > From: Sudha Ponnaganti [mailto:sudha.ponnaga...@citrix.com]
> > > Sent: Friday, June 28, 2013 7:11 AM
> > > To: dev@cloudstack.apache.org
> > > Subject: RE: [MERGE] Merge VMSync improvement branch into master
> > >
> > > Ideally I would like to see all validation to be done on feature
> > > branch - BVTs and also manual validation of the P1 test cases from
> > > VM Sync test plan just like object store validation - sadhu has
> > > signed up for it along with Ilya. This would help us to identify feature
> specific issues.
> > >
> > > We are running BVTs right now which have high failure rate. Focusing
> > > on this part right now to reach parity with Master branch.
> > >
> > >
> > > -Original Message-
> > > From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> > > Sent: Thursday, June 27, 2013 5:32 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: [MERGE] Merge VMSync improvement branch into master
> > >
> > > I agree with John that a change like this is very hard to test in an
> > > automated fashion. Still i have been looking at the numbers for the
> > > code coverage with cobertura. I was a bit disappointed to find that
> > > we have not made any progress with this merge with regards to unit
> > > tests and
> > total code coverage.
> > > We do not seem to be in a worse shape than before.
> > >
> > > @Sudha, it would be nice if you could add your view on this patch
> > > from the QA perspective? How would this patch affect your planning
> > > for
> > example?
> > >
> > > Cheers,
> > >
> > > Hugo
> > >
> > > On Jun 27, 2013, at 5:12 PM, John Burwell  wrote:
> > >
> > > > @David The types of concurrency changes introduced in this patch
> > > > are extremely difficult to completely test in an automated fashion.
> > > > Therefore, code review for correctness is critical to ensure quality.
> > > > To be clear, I am not questioning the value of automated testing.
> > > > I am just noting that it's next to impossible to achieve full
> > > > coverage, and code review is an critical supplement.
> > > >
> > > > @Ilya I plan to review this patch, but I will be able to start
> > > > until next week.  I am also still reviewing object_store (a
> > > > separate procedural issue for another thread), and need to complete
> solidfire.
> > > > This backlog is precisely why need to be reviewing iteratively
> > > > throughout the dev cycle.
> > > >
> > > > Thanks,
> > > > -John
> > > >
> > > > On Jun 27, 2013, at 7:35 PM, David Nalley  wrote:
> > > >
> > > >> On Thu, Jun 27, 2013 at 5:51 PM, Hugo Trippaers
> > > >> 
> > > wrote:
> > > >>>
> > > >>> I think Ilya offers is great, my current stance is also to see
> > > >>> how we can
> > > bring this forward.
> > > >>>
> > > >>> I've had the opportunity to meet with several people at the
> > > >>> Citrix office
> > > in Santa Clara, i'm actually working from their office at this moment.
> > > I think it's also the responsibility of someone who put in a -1 to
> > > work with the original committer to get the situation resolved. So
> > > i'll invest the time to help with the review as well.
> > > >>>
> > > >>> It would be great if Alex or Kelven could take the time to
> > > >>> explain how
> > > this feature has been tested. That would give the community some
> > > insight as well.
> > > >>>
> > > >>> My main technical problem with this merge is that stuff is
> > > >>> moving all over
> > > the place without having even the slightest idea why. Now having
> > > discussed this with Alex in person i get t

Re: Review Request 11953: Remove code that does nothing but allocate a bunch of objects

[Prachi Damle]

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

Ship it!


This change looks good, we can remove this part for now.

Some background about this code:
Originaly the design was to pass down the poolId from the reservation via the 
DeploymentPlan to the DeploymentPlanners to use. However we need some 
refactoring around this code to be able to pass multiple pool information in 
case a VM has multiple Volumes. Until then we will let the planners figure out 
the pools to use for deployment always, so passing the poolId null for now.

- Prachi Damle


On June 30, 2013, 5:52 a.m., Dave Brosius wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11953/
> ---
> 
> (Updated June 30, 2013, 5:52 a.m.)
> 
> 
> Review request for cloudstack, Alena Prokharchyk and Prachi Damle.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> remove code that may have been used for something in the past, but now does 
> nothing but allocate memory temporarily.
> 
> 
> Diffs
> -
> 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/cloud/entity/api/VMEntityManagerImpl.java
>  38ed7e6 
> 
> Diff: https://reviews.apache.org/r/11953/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dave Brosius
> 
>

Re: Test Result for test-smoke-matrix #559

[Min Chen]

Hi Prasanna,

Can you add the following logging configuration in your log4j
configuration in your automation run:



   
I am trying to look into create_template test case failure, but the ms log
does not show much information for me to get some clue where it happens
wrong.


Thanks
-min

On 6/30/13 9:50 PM, "Prasanna Santhanam"  wrote:

>Here's the latest run, there are only 7 failures left to have a fully
>successful run.
>
>Test Run: #561
>
>Total:94
>Fail :7
>Skip :2
>
>
>name   passfailskip
>test_vm_life_cycle/  10   0   0
>test_global_settings/ 1   0   0
>test_affinity_groups/ 0   1   0
>test_deploy_vm/   1   0   0
>test_network_acl/ 1   0   0
>test_regions/ 1   0   0
>test_resource_detail/ 1   0   0
>test_pvlan/   1   0   0
>test_iso/ 5   0   1
>test_deploy_vm_with_userdata/ 2   0   0
>test_routers/10   0   0
>test_disk_offerings/  3   0   0
>test_scale_vm/0   1   0
>test_deploy_vms_with_varied_deploymentplanners/   2   1   0
>test_templates/   6   1   1
>test_internal_lb/ 1   0   0
>test_nic/ 1   0   0
>test_portable_publicip/   2   0   0
>test_non_contigiousvlan/  1   0   0
>test_ssvm/   10   0   0
>test_network/ 7   3   0
>test_public_ip_range/ 1   0   0
>test_vm_snapshots/3   0   0
>test_volumes/ 9   0   0
>test_guest_vlan_range/1   0   0
>test_privategw_acl/   1   0   0
>test_service_offerings/   4   0   0
>
>
>
>Regressions
>
>name  
> durationage
>integration.smoke.test_templates.TestCreateTemplate.test_01_create_templat
>e  51.686  1
>integration.smoke.test_network.TestLoadBalancingRule.test_01_create_lb_rul
>e_src_nat  66.749  1
>integration.smoke.test_network.TestReleaseIP.test_releaseIP
>  171.407  1
>
>Failures
>
>name  
>  durationage
>integration.smoke.test_affinity_groups.TestDeployVmWithAffinityGroup.test_
>DeployVmAntiAffinityGroup0.584 28
>integration.smoke.test_scale_vm.TestScaleVm.test_01_scale_vm
>40.644 36
>integration.smoke.test_deploy_vms_with_varied_deploymentplanners.TestDeplo
>yVmWithVariedPlanners.test_deployvm_userdispersing  87.437147
>integration.smoke.test_network.TestLoadBalancingRule.test_02_create_lb_rul
>e_non_nat   15.347 36
>
>Fixed
>
>name  
> durationage
>integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDeta
>ch_iso 71.225  0
>integration.smoke.test_templates.TestTemplates.test_03_delete_template
>5.19   0
>integration.smoke.test_templates.TestTemplates.test_04_extract_template
>5.205  0
>integration.smoke.test_network.TestAssignRemoveLB.test_assign_and_removal_
>lb458.79   0
>integration.smoke.test_network.TestPortForwarding.test_01_port_fwd_on_src_
>nat   111.604  0
>integration.smoke.test_network.TestPortForwarding.test_02_port_fwd_on_non_
>src_nat30.584  0
>integration.smoke.test_vm_snapshots.TestVmSnapshot.test_01_create_vm_snaps
>hots   98.616  0
>integration.smoke.test_vm_snapshots.TestVmSnapshot.test_02_revert_vm_snaps
>hots  171.544  0
>integration.smoke.test_vm_snapshots.TestVmSnapshot.test_03_delete_vm_snaps
>hots  185.229  0
>integration.smoke.test_service_offerings.TestServiceOfferings.test_04_chan
>ge_offering_small 107.035  0
>
>
>-- 
>Prasanna.,
>
>
>Powered by BigRock.com
>

RE: Test Result for test-smoke-matrix #559

[Prachi Damle]

Hi Prasanna,

For the following two test failures:

- 
integration.smoke.test_affinity_groups.TestDeployVmWithAffinityGroup.test_DeployVmAntiAffinityGroup

   It looks to be some issue with the test itself. The test is failing to find 
the affinity group created during the test setup.

- 
integration.smoke.test_deploy_vms_with_varied_deploymentplanners.TestDeployVmWithVariedPlanners.test_deployvm_userdispersing
  
   For the test failure about user dispersing, deployment will always succeed 
due to the best-effort strategy even if it is not possible to  disperse the VMs 
. So we may want to remove the userdispering and userconscentrated planner 
tests as they may not indicate true failures.

Prachi


-Original Message-
From: Prasanna Santhanam [mailto:t...@apache.org] 
Sent: Sunday, June 30, 2013 9:50 PM
To: CloudStack Dev
Subject: Re: Test Result for test-smoke-matrix #559

Here's the latest run, there are only 7 failures left to have a fully 
successful run.

Test Run: #561

Total:94
Fail :7
Skip :2


name   passfailskip
test_vm_life_cycle/  10   0   0
test_global_settings/ 1   0   0
test_affinity_groups/ 0   1   0
test_deploy_vm/   1   0   0
test_network_acl/ 1   0   0
test_regions/ 1   0   0
test_resource_detail/ 1   0   0
test_pvlan/   1   0   0
test_iso/ 5   0   1
test_deploy_vm_with_userdata/ 2   0   0
test_routers/10   0   0
test_disk_offerings/  3   0   0
test_scale_vm/0   1   0
test_deploy_vms_with_varied_deploymentplanners/   2   1   0
test_templates/   6   1   1
test_internal_lb/ 1   0   0
test_nic/ 1   0   0
test_portable_publicip/   2   0   0
test_non_contigiousvlan/  1   0   0
test_ssvm/   10   0   0
test_network/ 7   3   0
test_public_ip_range/ 1   0   0
test_vm_snapshots/3   0   0
test_volumes/ 9   0   0
test_guest_vlan_range/1   0   0
test_privategw_acl/   1   0   0
test_service_offerings/   4   0   0



Regressions

name
   durationage
integration.smoke.test_templates.TestCreateTemplate.test_01_create_template 
 51.686  1
integration.smoke.test_network.TestLoadBalancingRule.test_01_create_lb_rule_src_nat
  66.749  1
integration.smoke.test_network.TestReleaseIP.test_releaseIP 
171.407  1

Failures

name
durationage
integration.smoke.test_affinity_groups.TestDeployVmWithAffinityGroup.test_DeployVmAntiAffinityGroup
0.584 28
integration.smoke.test_scale_vm.TestScaleVm.test_01_scale_vm
  40.644 36
integration.smoke.test_deploy_vms_with_varied_deploymentplanners.TestDeployVmWithVariedPlanners.test_deployvm_userdispersing
  87.437147
integration.smoke.test_network.TestLoadBalancingRule.test_02_create_lb_rule_non_nat
   15.347 36

Fixed

name
   durationage
integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso
 71.225  0
integration.smoke.test_templates.TestTemplates.test_03_delete_template  
  5.19   0
integration.smoke.test_templates.TestTemplates.test_04_extract_template 
  5.205  0
integration.smoke.test_network.TestAssignRemoveLB.test_assign_and_removal_lb
458.79   0
integration.smoke.test_network.TestPortForwarding.test_01_port_fwd_on_src_nat   
111.604  0
integration.smoke.test_n

Re: Review Request 12156: CLOUDSTACK-3189: Primary storage usage is not getting decremented after deleting the DATA volumes

[ASF Subversion and Git Services]

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


Commit 301c91c099957b77dd1127484446f9fe69b53e39 in branch refs/heads/master 
from Sanjay Tripathi
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=301c91c ]

CLOUDSTACK-3189: Primary storage usage is not getting decremented after 
deleting the DATA volumes.
When a volume is created the resource usage for it gets incremented. If it is 
deleted without being
attached to a volume, the decrement doesn't take place. Fixed the delete volume 
code to decrement
resource usage for a volume in allocated state too.


- ASF Subversion and Git Services


On June 28, 2013, 9:12 a.m., Sanjay Tripathi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12156/
> ---
> 
> (Updated June 28, 2013, 9:12 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Sateesh Chodapuneedi.
> 
> 
> Bugs: CLOUDSTACK-3189
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-3189: Primary storage usage is not getting decremented after 
> deleting the DATA volumes.
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-3189
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/storage/VolumeManagerImpl.java 4297efb 
> 
> Diff: https://reviews.apache.org/r/12156/diff/
> 
> 
> Testing
> ---
> 
> Tests:
> 
> 1. Create a volume from a user account.
> 2. Verify the increment in primaryStorageTotal count using listAccount API.
> 3. Delete volume.
> 4. Verify the decrement in primaryStorageTotal count.
> 
> 
> Thanks,
> 
> Sanjay Tripathi
> 
>

RE: Master build problem

[Paul Angus]

I see the admin user getting added:

2013-07-01 19:14:04,739 TRACE [db.Transaction.Statement] (Timer-1:null) 
Preparing: INSERT INTO `cloud`.`user` (id, uuid, username, password, 
account_id, firstname, lastname, created, state, user.default) VALUES (2, 
UUID(), 'admin', RAND(), 2, 'admin','cloud',now(), 'disabled', 1)

No other mention of admin.

The other two classes you were looking for appear in errors:

2013-07-01 19:13:35,774 ERROR [cloud.api.ApiServlet] (catalina-exec-1:null) 
unknown exception writing api response
java.lang.NullPointerException
at com.cloud.api.ApiServer.loginUser(ApiServer.java:784)
at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:210)
at com.cloud.api.ApiServlet.doPost(ApiServlet.java:71)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at 
org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
at 
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2274)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:679)
2013-07-01 19:13:35,781 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null) 
===END===  10.0.0.17 -- POST  null
2013-07-01 19:13:38,271 TRACE [db.Transaction.Transaction] (Timer-1:null) Took 
over the transaction: init

---

2013-07-01 19:14:14,037 INFO  [cloud.server.ConfigurationServerImpl] 
(Timer-1:null) Processing updateKeyPairs
2013-07-01 19:14:14,037 INFO  [cloud.server.ConfigurationServerImpl] 
(Timer-1:null) Systemvm keypairs not found in database. Need to store them in 
the database
2013-07-01 19:14:14,037 DEBUG [utils.script.Script] (Timer-1:null) Executing: 
/bin/bash -c if [ -f /var/cloudstack/management/.ssh/id_rsa ]; then rm -f 
/var/cloudstack/management/.ssh/id_rsa; fi; ssh-keygen -t rsa -N '' -f 
/var/cloudstack/management/.ssh/id_rsa -q
2013-07-01 19:14:14,055 WARN  [utils.script.Script] (Timer-1:null) Exception: 
/bin/bash -c if [ -f /var/cloudstack/management/.ssh/id_rsa ]; then rm -f 
/var/cloudstack/management/.ssh/id_rsa; fi; ssh-keygen -t rsa -N '' -f 
/var/cloudstack/management/.ssh/id_rsa -q
java.io.IOException: Cannot run program "/bin/bash": java.io.IOException: 
error=12, Cannot allocate memory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:488)
at com.cloud.utils.script.Script.execute(Script.java:183)
at com.cloud.utils.script.Script.runSimpleBashScript(Script.java:481)
at com.cloud.utils.script.Script.runSimpleBashScript(Script.java:471)
at 
com.cloud.server.ConfigurationServerImpl.updateKeyPairs(ConfigurationServerImpl.java:627)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
com.cloud.server.ConfigurationServerImpl.persistDefaultValues(ConfigurationServerImpl.java:292)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
com.cloud.server.ConfigurationServerImpl.configure(ConfigurationServerImpl.java:157)
at 
com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:111)
at 
com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:50)
at java.util.TimerThread.mainLoop(Timer.java:534)
at java.util.TimerThread.run(Timer.java:484)
Caused by: java.io.IOException: java.io.IOException: error=12, Cannot allocate 
memory
at java.lang.UNIXProcess.(UNIXProcess.java:164)
at java.lang.ProcessImpl.start(ProcessImpl.java:81)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:470)
   

In-Development Release Naming

[John Burwell]

All,

Since we have adopted Semantic Versioning [1], it seems odd that we designate a 
release version before the final set of enhancements/fixes has been identified. 
 For example, the release proceeding 4.2 may contain no backwards compatible 
API changes to be 4.3.  Conversely, we may decide during the development cycle, 
as a community, to accept a non-backwards compatible change which would bump 
the version to 5.0.0.  As such, it is difficult to know in advance what the 
proper semantic version number will be at when the work is released.  We run 
the risk of confusing our users if we start calling a pending release say 
4.3.0, and accept a change mid-cycle that will bump it to 5.0.0.  To address 
this potential issue, I proposed that we refer to releases by a codename until 
feature freeze when we understand the complete scope of change and can apply 
the correct semantic version number.  I further propose we codename the release 
directly proceeding 4.2 "Gamma Rays" or "Gamma Rays Gonna Get Ya".  

Thoughts?
-John

[1]: http://semver.org

Re: Master build problem

[Hugo Trippaers]

Hey Paul,

That out-of-memory error in the ConfigurationServerImpl might be the 
root-cause. This would prevent cloudstack from completely initialising and one 
of the last initialisation steps is to enable the admin user.

If you fix that you are a step closer.

Cheers,

Hugo


On Jul 1, 2013, at 8:24 PM, Paul Angus  wrote:

> I see the admin user getting added:
> 
> 2013-07-01 19:14:04,739 TRACE [db.Transaction.Statement] (Timer-1:null) 
> Preparing: INSERT INTO `cloud`.`user` (id, uuid, username, password, 
> account_id, firstname, lastname, created, state, user.default) VALUES (2, 
> UUID(), 'admin', RAND(), 2, 'admin','cloud',now(), 'disabled', 1)
> 
> No other mention of admin.
> 
> The other two classes you were looking for appear in errors:
> 
> 2013-07-01 19:13:35,774 ERROR [cloud.api.ApiServlet] (catalina-exec-1:null) 
> unknown exception writing api response
> java.lang.NullPointerException
>at com.cloud.api.ApiServer.loginUser(ApiServer.java:784)
>at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:210)
>at com.cloud.api.ApiServlet.doPost(ApiServlet.java:71)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
>at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
>at 
> org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
>at 
> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721)
>at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2274)
>at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
>at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>at java.lang.Thread.run(Thread.java:679)
> 2013-07-01 19:13:35,781 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null) 
> ===END===  10.0.0.17 -- POST  null
> 2013-07-01 19:13:38,271 TRACE [db.Transaction.Transaction] (Timer-1:null) 
> Took over the transaction: init
> 
> ---
> 
> 2013-07-01 19:14:14,037 INFO  [cloud.server.ConfigurationServerImpl] 
> (Timer-1:null) Processing updateKeyPairs
> 2013-07-01 19:14:14,037 INFO  [cloud.server.ConfigurationServerImpl] 
> (Timer-1:null) Systemvm keypairs not found in database. Need to store them in 
> the database
> 2013-07-01 19:14:14,037 DEBUG [utils.script.Script] (Timer-1:null) Executing: 
> /bin/bash -c if [ -f /var/cloudstack/management/.ssh/id_rsa ]; then rm -f 
> /var/cloudstack/management/.ssh/id_rsa; fi; ssh-keygen -t rsa -N '' -f 
> /var/cloudstack/management/.ssh/id_rsa -q
> 2013-07-01 19:14:14,055 WARN  [utils.script.Script] (Timer-1:null) Exception: 
> /bin/bash -c if [ -f /var/cloudstack/management/.ssh/id_rsa ]; then rm -f 
> /var/cloudstack/management/.ssh/id_rsa; fi; ssh-keygen -t rsa -N '' -f 
> /var/cloudstack/management/.ssh/id_rsa -q
> java.io.IOException: Cannot run program "/bin/bash": java.io.IOException: 
> error=12, Cannot allocate memory
>at java.lang.ProcessBuilder.start(ProcessBuilder.java:488)
>at com.cloud.utils.script.Script.execute(Script.java:183)
>at com.cloud.utils.script.Script.runSimpleBashScript(Script.java:481)
>at com.cloud.utils.script.Script.runSimpleBashScript(Script.java:471)
>at 
> com.cloud.server.ConfigurationServerImpl.updateKeyPairs(ConfigurationServerImpl.java:627)
>at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>at 
> com.cloud.server.ConfigurationServerImpl.persistDefaultValues(ConfigurationServerImpl.java:292)
>at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>at 
> com.cloud.server.ConfigurationServerImpl.configure(ConfigurationServerImpl.java:157)
>at 
> com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:111)

RE: Query String Request Authentication(QSRA) support by S3 providers

[Jessica Wang]

Thomas,

I checked the data you provided.

The reason that the 2 templates("MyTiny", "AnotherTiny") have no download 
button is because they are not ready 
(i.e. their "isready" property is false).

Download button is only available when "isready" property is true.

Jessica

-Original Message-
From: Thomas O'Dowd [mailto:tpod...@cloudian.com] 
Sent: Thursday, June 27, 2013 8:04 PM
To: Min Chen
Cc: dev@cloudstack.apache.org; Jessica Wang
Subject: Re: Query String Request Authentication(QSRA) support by S3 providers

Hi Min/Jessica,

I attached an image to that issue to show what what my browser is
showing.

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

Tom.

On Fri, 2013-06-28 at 09:45 +0900, Thomas O'Dowd wrote:
> Hi Min,
> 
> Yes. I'll try it again today to check again but when I added Amazon S3
> as the S3 secondary storage and uploaded a template, I was not shown the
> "download template" link. However - for Cloudian S3, I am shown it so
> I'm wondering why.
> 
> Tom.
> 
> On Fri, 2013-06-28 at 00:26 +, Min Chen wrote:
> > Hi Tom,
> > 
> > Are you saying that you cannot see a Download Template button from UI
> > when Amazon S3 is added as secondary storage? I only tested with RiakCS
> > and Cloudian, so didn't see this issue. But I am CC Jessica her to confirm
> > what special handling is done in UI to enable/disable a button from UI.
> > 
> > Thanks
> > -min
> > 
> > On 6/27/13 5:23 PM, "Thomas O'Dowd"  wrote:
> > 
> > >Hi Min,
> > >
> > >Can you check this bug? I'm trying to test this feature for Amazon but
> > >having no luck getting the Download template link/button to appear.
> > >
> > >https://issues.apache.org/jira/browse/CLOUDSTACK-3220
> > >
> > >Thanks,
> > >
> > >Tom.
> > >
> > >On Fri, 2013-06-21 at 17:21 +, Min Chen wrote:
> > >> John,
> > >> 
> > >>  For S3, the api call createEntityExtractUrl is done on management
> > >>server
> > >> side; while for NFS secondary storage, if the implementation of
> > >> createEntityExtractUrl will involve some code be executed in ssvm to
> > >>copy
> > >> template from the install location to a public accessible web server
> > >> location.
> > >>  I don't quite understand some of your comments below. This API is not
> > >> used to write any information to S3 bucket/directory. This is used for
> > >> object already existed on S3, and we just provide a URL for user to
> > >> download a template from S3, just like how Amazon provided user a way to
> > >> user to extract a S3 object through generatePresignedUrl. We can discuss
> > >> more on this on collaboration conference.
> > >> 
> > >>  Thanks  
> > >>  -min
> > >> 
> > >> 
> > >> 
> > >> On 6/21/13 7:25 AM, "John Burwell"  wrote:
> > >> 
> > >> >Min,
> > >> >
> > >> >(I apologize for my belated reply -- I lost track of this draft in the
> > >> >chaos of the last couple of days.)
> > >> >
> > >> >Upon further review, I think I feel into the confusion between
> > >>management
> > >> >server and ssvm.  This code is executing on the management server side,
> > >> >correct?  Based on my "corrected" understanding is correct, I would
> > >>like
> > >> >to amend my thoughts.  Namely, I would like to see the driver
> > >>operations
> > >> >pushed out to the SSVM where we can use the stream.  As I think about
> > >>it,
> > >> >the management server should not need to interact with the driver.
> > >> >Simply yard up the DataStore attributes + details map and other extract
> > >> >parameters, and send them to the SSVM.  Using this information, the S3
> > >> >driver could open a stream to write the template out to the
> > >> >bucket/directory.  I recognize it changes the protocol between the
> > >> >management server and SSVM, but it simply both sides of the operation
> > >>by
> > >> >allowing the DataStore information to be treated opaquely until it is
> > >> >consumed by the driver to execute the write operation.  I also
> > >>recognize
> > >> >that we may a little late in the cycle to address it for 4.2, and it
> > >>may
> > >> >need to be part of the 4.3 enhancements.
> > >> >
> > >> >Thanks,
> > >> >-John
> > >> >
> > >> >On Jun 18, 2013, at 3:55 PM, Min Chen  wrote:
> > >> >
> > >> >> John,
> > >> >>   In that case, how do we keep backward compatibility of
> > >>extractTemplate
> > >> >> api, which requires a URL in the response?
> > >> >> 
> > >> >>   Thanks
> > >> >>   -min
> > >> >> 
> > >> >> On 6/18/13 11:53 AM, "John Burwell"  wrote:
> > >> >> 
> > >> >>> Min,
> > >> >>> 
> > >> >>> Looking through the code, I think we can simplify driver operation
> > >>and
> > >> >>> increase robustness by changing
> > >> >>>ImageStoreDriver#createEntityExtractUrl()
> > >> >>> : String to ImageStoreDriver#readEntity(Š) : InputStream.  My first
> > >> >>> concern with the current implementation is that it circumvents any
> > >> >>> connection pooling/resource management underlying client libraries
> > >> >>> provide.  I/O streams provide a higher-level abstraction tha

Re: In-Development Release Naming

[Daan Hoogland]

Exactly (+1) and 'gammarays' or '#gammarays' have my preference.



On Mon, Jul 1, 2013 at 8:28 PM, John Burwell  wrote:

> All,
>
> Since we have adopted Semantic Versioning [1], it seems odd that we
> designate a release version before the final set of enhancements/fixes has
> been identified.  For example, the release proceeding 4.2 may contain no
> backwards compatible API changes to be 4.3.  Conversely, we may decide
> during the development cycle, as a community, to accept a non-backwards
> compatible change which would bump the version to 5.0.0.  As such, it is
> difficult to know in advance what the proper semantic version number will
> be at when the work is released.  We run the risk of confusing our users if
> we start calling a pending release say 4.3.0, and accept a change mid-cycle
> that will bump it to 5.0.0.  To address this potential issue, I proposed
> that we refer to releases by a codename until feature freeze when we
> understand the complete scope of change and can apply the correct semantic
> version number.  I further propose we codename the release directly
> proceeding 4.2 "Gamma Rays" or "Gamma Rays Gonna Get Ya".
>
> Thoughts?
> -John
>
> [1]: http://semver.org

Re: Review Request 12156: CLOUDSTACK-3189: Primary storage usage is not getting decremented after deleting the DATA volumes

[ASF Subversion and Git Services]

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


Commit 737a9c397755f979bd42a1504bd0b298b4f74825 in branch 
refs/heads/master-6-17-stable from Sanjay Tripathi
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=737a9c3 ]

CLOUDSTACK-3189: Primary storage usage is not getting decremented after 
deleting the DATA volumes.
When a volume is created the resource usage for it gets incremented. If it is 
deleted without being
attached to a volume, the decrement doesn't take place. Fixed the delete volume 
code to decrement
resource usage for a volume in allocated state too.


- ASF Subversion and Git Services


On June 28, 2013, 9:12 a.m., Sanjay Tripathi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12156/
> ---
> 
> (Updated June 28, 2013, 9:12 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Sateesh Chodapuneedi.
> 
> 
> Bugs: CLOUDSTACK-3189
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-3189: Primary storage usage is not getting decremented after 
> deleting the DATA volumes.
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-3189
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/storage/VolumeManagerImpl.java 4297efb 
> 
> Diff: https://reviews.apache.org/r/12156/diff/
> 
> 
> Testing
> ---
> 
> Tests:
> 
> 1. Create a volume from a user account.
> 2. Verify the increment in primaryStorageTotal count using listAccount API.
> 3. Delete volume.
> 4. Verify the decrement in primaryStorageTotal count.
> 
> 
> Thanks,
> 
> Sanjay Tripathi
> 
>

Bug in 4.1-4.2 template upgrade process

[Alena Prokharchyk]

Ran sanity check for the 4.1-4.2 upgrade. Went fine with one exception - I
haven't pre-installed the 4.2 system templates, and the update didn't fail.

Hari, can you please fix it as you were the one who implemented system
template upgrade. Steps to reproduce:

1) Istall 4.1.0
2) Add 1 xen cluster with 1 host and 1 primary storage.

mysql> select distinct(hypervisor_type) from `cloud`.`cluster` where
removed is null;
+-+
| hypervisor_type |
+-+
| xenserver   |
+-+



3) Upgrade to 4.2

I bet all you have to do is to fix string comparison in Upgrade410to42.java

-alena.

Re: In-Development Release Naming

[Mathias Mullins]

Definitely a +1

Matt 


On 7/1/13 2:28 PM, "John Burwell"  wrote:

>All,
>
>Since we have adopted Semantic Versioning [1], it seems odd that we
>designate a release version before the final set of enhancements/fixes
>has been identified.  For example, the release proceeding 4.2 may contain
>no backwards compatible API changes to be 4.3.  Conversely, we may decide
>during the development cycle, as a community, to accept a non-backwards
>compatible change which would bump the version to 5.0.0.  As such, it is
>difficult to know in advance what the proper semantic version number will
>be at when the work is released.  We run the risk of confusing our users
>if we start calling a pending release say 4.3.0, and accept a change
>mid-cycle that will bump it to 5.0.0.  To address this potential issue, I
>proposed that we refer to releases by a codename until feature freeze
>when we understand the complete scope of change and can apply the correct
>semantic version number.  I further propose we codename the release
>directly proceeding 4.2 "Gamma Rays" or "Gamma Rays Gonna Get Ya".
>
>Thoughts?
>-John
>
>[1]: http://semver.org

Re: London CloudStack Meetup on July 4th

[Mike Tutkowski]

Just figured I'd follow up on this.

If anyone's planning on attending this CloudStack Meetup in London, I'll
see you there!


On Wed, Jun 12, 2013 at 1:05 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hi everyone,
>
> I am planning on heading to London to speak at a CloudStack Meetup on July
> 4th and was curious if anyone on the list was planning on attending, as
> well.
>
> I figured this would be a good opportunity to meet more CloudStack people
> in person. :)
>
> 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
> *™*
>



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

Re: Review Request 12156: CLOUDSTACK-3189: Primary storage usage is not getting decremented after deleting the DATA volumes

[ASF Subversion and Git Services]

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


Commit af4eb22a6539b9c25f6b9df2aa110bf099283cbb in branch refs/heads/4.2 from 
Sanjay Tripathi
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=af4eb22 ]

CLOUDSTACK-3189: Primary storage usage is not getting decremented after 
deleting the DATA volumes.
When a volume is created the resource usage for it gets incremented. If it is 
deleted without being
attached to a volume, the decrement doesn't take place. Fixed the delete volume 
code to decrement
resource usage for a volume in allocated state too.


- ASF Subversion and Git Services


On June 28, 2013, 9:12 a.m., Sanjay Tripathi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12156/
> ---
> 
> (Updated June 28, 2013, 9:12 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Sateesh Chodapuneedi.
> 
> 
> Bugs: CLOUDSTACK-3189
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-3189: Primary storage usage is not getting decremented after 
> deleting the DATA volumes.
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-3189
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/storage/VolumeManagerImpl.java 4297efb 
> 
> Diff: https://reviews.apache.org/r/12156/diff/
> 
> 
> Testing
> ---
> 
> Tests:
> 
> 1. Create a volume from a user account.
> 2. Verify the increment in primaryStorageTotal count using listAccount API.
> 3. Delete volume.
> 4. Verify the decrement in primaryStorageTotal count.
> 
> 
> Thanks,
> 
> Sanjay Tripathi
> 
>

Re: In-Development Release Naming

[Chip Childers]

On Mon, Jul 01, 2013 at 02:28:37PM -0400, John Burwell wrote:
> All,
> 
> Since we have adopted Semantic Versioning [1], it seems odd that we designate 
> a release version before the final set of enhancements/fixes has been 
> identified.  For example, the release proceeding 4.2 may contain no backwards 
> compatible API changes to be 4.3.  Conversely, we may decide during the 
> development cycle, as a community, to accept a non-backwards compatible 
> change which would bump the version to 5.0.0.  As such, it is difficult to 
> know in advance what the proper semantic version number will be at when the 
> work is released.  We run the risk of confusing our users if we start calling 
> a pending release say 4.3.0, and accept a change mid-cycle that will bump it 
> to 5.0.0.  To address this potential issue, I proposed that we refer to 
> releases by a codename until feature freeze when we understand the complete 
> scope of change and can apply the correct semantic version number.  I further 
> propose we codename the release directly proceeding 4.2 "Gamma Rays" or 
> "Gamma Rays Gonna Get Ya".  
> 
> Thoughts?
> -John
> 
> [1]: http://semver.org

Some technical issues to address WRT versions prior to a number being
assigned:

1) package version strings (DEB and RPM)
2) DB version string, especially for testing upgrades

Thoughts on how to avoid issues here?  

To me, it seems like we should make an upgrade to 5.x a *major discussion*, 
and instead *assume* that we will retain backward compatibility and not bump 
the major number.  I'd rather limit the number of times that we
actually jump major versions and take the hit on the version numbering
changes when those times to occur.  Just my 2 cents though.

-chip

Unresolved compilation problem?

[Vijayendra Bhamidipati]

I'm running into this exception when trying to add a vmware cluster on top of 
latest master:


INFO  [cloud.configuration.ConfigurationManagerImpl] 
(829088401@qtp-729217986-4:) adding a new subnet to the network 200
INFO  [hypervisor.vmware.VmwareServerDiscoverer] (1175658854@qtp-729217986-5:) 
Discover host. dc: 1, pod: 1, cluster: 1, uri host: 10.223.52.61
2013-07-01 06:52:24.507:WARN::Error for /client/api
java.lang.Error: Unresolved compilation problem: |?The method 
prepareNetwork(String, String, HostMO, String, Integer, Integer, long, boolean, 
BroadcastDomainType) from the type HypervisorHostHelper refers to the missing 
type BroadcastDomainType|
at 
com.cloud.hypervisor.vmware.manager.VmwareManagerImpl.prepareHost(VmwareManagerImpl.java:351)
at 
com.cloud.hypervisor.vmware.manager.VmwareManagerImpl.addHostToPodCluster(VmwareManagerImpl.java:397)
at 
com.cloud.hypervisor.vmware.VmwareServerDiscoverer.find(VmwareServerDiscoverer.java:312)
at 
com.cloud.resource.ResourceManagerImpl.discoverCluster(ResourceManagerImpl.java:538)
at 
com.cloud.resource.ResourceManagerImpl_EnhancerByCloudStack_84a53fa0.CGLIB$discoverCluster$29()
at 
com.cloud.resource.ResourceManagerImpl_EnhancerByCloudStack_84a53fa0_FastClassByCloudStack_84071e69.invoke()
at net.sf.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
com.cloud.resource.ResourceManagerImpl_EnhancerByCloudStack_84a53fa0.discoverCluster()
at 
org.apache.cloudstack.api.command.admin.cluster.AddClusterCmd.execute(AddClusterCmd.java:204)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:528)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:371)
at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:304)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at 
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
at 
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at 
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at 
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at 
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at 
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)



I believe this could be caused by stale eclipse generated compile time files, 
so I did a mvn clean and retried the compilation, which went through fine, and 
the mgmt. server restarted up fine, so what am I missing? Any ideas?


Regards,
Vijay

Re: Console Access: /ajax 404 not found

[Kelven Yang]

Not too sure about devCloud, it seems that there will be port-forwarding
rules set on your local host to make sure console access can go pass the
NAT to reach console proxy VM.

>From the error log, I think it has reached to a wrong HTTP server

Kelven

On 6/28/13 4:05 PM, "Tobias Brunner"  wrote:

>Hi,
>
>As suggested on the users mailing list, I ask this question again
>here...
>
>I've managed it to install CloudStack on Virtualbox: One VM with Ubuntu
>where the management server is installed as described in the official
>documentation (.deb packages) and a DevCloud2 VM which acts as
>Virtualization Host with XEN.
>Everything runs fine so far, I'm able to create instances and start
>them. But I don't manage it to access the console, I always get "Not
>Found. The requested URL /ajax was not found on this server."
>
>The URL accessed for using the console is
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>:8080/client/console?cmd=access&vm=bd1db514-abb8-4392-a36b-90d55349945a"
>which tries to open
>"https://192-168-26-103.realhostip.com/ajax?token=hrDL3BN..."; (token
>shortened for better reading). "https://192-168-26-103.realhostip.com/";
>is accessible (added a hosts entry to 192.168.26.103 which is the
>console proxy vm).
>
>Any idea how I can debug or even fix this problem?
>
>Cheers,
>Tobias
>

Re: Unresolved compilation problem?

[Hugo Trippaers]

Heya,

I've made some changes to this function to support multiple types of broadcast 
domain types. So I had to add a dependency to the Pom to get the 
BroadcastDomainType enum.

This probably was not properly updated until you did a full recompile.

Cheers,

Hugo 

Sent from my iPhone

On 1 jul. 2013, at 22:21, Vijayendra Bhamidipati 
 wrote:

> I'm running into this exception when trying to add a vmware cluster on top of 
> latest master:
> 
> 
> INFO  [cloud.configuration.ConfigurationManagerImpl] 
> (829088401@qtp-729217986-4:) adding a new subnet to the network 200
> INFO  [hypervisor.vmware.VmwareServerDiscoverer] 
> (1175658854@qtp-729217986-5:) Discover host. dc: 1, pod: 1, cluster: 1, uri 
> host: 10.223.52.61
> 2013-07-01 06:52:24.507:WARN::Error for /client/api
> java.lang.Error: Unresolved compilation problem: |?The method 
> prepareNetwork(String, String, HostMO, String, Integer, Integer, long, 
> boolean, BroadcastDomainType) from the type HypervisorHostHelper refers to 
> the missing type BroadcastDomainType|
>at 
> com.cloud.hypervisor.vmware.manager.VmwareManagerImpl.prepareHost(VmwareManagerImpl.java:351)
>at 
> com.cloud.hypervisor.vmware.manager.VmwareManagerImpl.addHostToPodCluster(VmwareManagerImpl.java:397)
>at 
> com.cloud.hypervisor.vmware.VmwareServerDiscoverer.find(VmwareServerDiscoverer.java:312)
>at 
> com.cloud.resource.ResourceManagerImpl.discoverCluster(ResourceManagerImpl.java:538)
>at 
> com.cloud.resource.ResourceManagerImpl_EnhancerByCloudStack_84a53fa0.CGLIB$discoverCluster$29()
>at 
> com.cloud.resource.ResourceManagerImpl_EnhancerByCloudStack_84a53fa0_FastClassByCloudStack_84071e69.invoke()
>at net.sf.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)
>at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>at 
> com.cloud.resource.ResourceManagerImpl_EnhancerByCloudStack_84a53fa0.discoverCluster()
>at 
> org.apache.cloudstack.api.command.admin.cluster.AddClusterCmd.execute(AddClusterCmd.java:204)
>at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
>at com.cloud.api.ApiServer.queueCommand(ApiServer.java:528)
>at com.cloud.api.ApiServer.handleRequest(ApiServer.java:371)
>at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:304)
>at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>at 
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
>at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
>at 
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>at 
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>at 
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
>at 
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
>at 
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
>at 
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
>at 
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>at org.mortbay.jetty.Server.handle(Server.java:326)
>at 
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
>at 
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
>at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
>at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
>at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
>at 
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
>at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> 
> 
> 
> I believe this could be caused by stale eclipse generated compile time files, 
> so I did a mvn clean and retried the compilation, which went through fine, 
> and the mgmt. server restarted up fine, so what am I missing? Any ideas?
> 
> 
> Regards,
> Vijay

Re: In-Development Release Naming

[Daan Hoogland]

That doesn't invalidate John's point about the message to the users. We can
publish it by a code name and still code it with numbers according to our
expectations of the level of bump it will take.


On Mon, Jul 1, 2013 at 10:15 PM, Chip Childers wrote:

> On Mon, Jul 01, 2013 at 02:28:37PM -0400, John Burwell wrote:
> > All,
> >
> > Since we have adopted Semantic Versioning [1], it seems odd that we
> designate a release version before the final set of enhancements/fixes has
> been identified.  For example, the release proceeding 4.2 may contain no
> backwards compatible API changes to be 4.3.  Conversely, we may decide
> during the development cycle, as a community, to accept a non-backwards
> compatible change which would bump the version to 5.0.0.  As such, it is
> difficult to know in advance what the proper semantic version number will
> be at when the work is released.  We run the risk of confusing our users if
> we start calling a pending release say 4.3.0, and accept a change mid-cycle
> that will bump it to 5.0.0.  To address this potential issue, I proposed
> that we refer to releases by a codename until feature freeze when we
> understand the complete scope of change and can apply the correct semantic
> version number.  I further propose we codename the release directly
> proceeding 4.2 "Gamma Rays" or "Gamma Rays Gonna Get Ya".
> >
> > Thoughts?
> > -John
> >
> > [1]: http://semver.org
>
> Some technical issues to address WRT versions prior to a number being
> assigned:
>
> 1) package version strings (DEB and RPM)
> 2) DB version string, especially for testing upgrades
>
> Thoughts on how to avoid issues here?
>
> To me, it seems like we should make an upgrade to 5.x a *major discussion*,
> and instead *assume* that we will retain backward compatibility and not
> bump
> the major number.  I'd rather limit the number of times that we
> actually jump major versions and take the hit on the version numbering
> changes when those times to occur.  Just my 2 cents though.
>
> -chip
>

Re: In-Development Release Naming

[Chip Childers]

On Mon, Jul 01, 2013 at 10:40:38PM +0200, Daan Hoogland wrote:
> That doesn't invalidate John's point about the message to the users. We can
> publish it by a code name and still code it with numbers according to our
> expectations of the level of bump it will take.

Ah...  I guess I was thinking that this was an all-inclusive proposal.

Sounds fine to me.  I'd suggest that 4.2 is out of the bag now, but how
about for our next feature release?

> 
> 
> On Mon, Jul 1, 2013 at 10:15 PM, Chip Childers wrote:
> 
> > On Mon, Jul 01, 2013 at 02:28:37PM -0400, John Burwell wrote:
> > > All,
> > >
> > > Since we have adopted Semantic Versioning [1], it seems odd that we
> > designate a release version before the final set of enhancements/fixes has
> > been identified.  For example, the release proceeding 4.2 may contain no
> > backwards compatible API changes to be 4.3.  Conversely, we may decide
> > during the development cycle, as a community, to accept a non-backwards
> > compatible change which would bump the version to 5.0.0.  As such, it is
> > difficult to know in advance what the proper semantic version number will
> > be at when the work is released.  We run the risk of confusing our users if
> > we start calling a pending release say 4.3.0, and accept a change mid-cycle
> > that will bump it to 5.0.0.  To address this potential issue, I proposed
> > that we refer to releases by a codename until feature freeze when we
> > understand the complete scope of change and can apply the correct semantic
> > version number.  I further propose we codename the release directly
> > proceeding 4.2 "Gamma Rays" or "Gamma Rays Gonna Get Ya".
> > >
> > > Thoughts?
> > > -John
> > >
> > > [1]: http://semver.org
> >
> > Some technical issues to address WRT versions prior to a number being
> > assigned:
> >
> > 1) package version strings (DEB and RPM)
> > 2) DB version string, especially for testing upgrades
> >
> > Thoughts on how to avoid issues here?
> >
> > To me, it seems like we should make an upgrade to 5.x a *major discussion*,
> > and instead *assume* that we will retain backward compatibility and not
> > bump
> > the major number.  I'd rather limit the number of times that we
> > actually jump major versions and take the hit on the version numbering
> > changes when those times to occur.  Just my 2 cents though.
> >
> > -chip
> >

Re: In-Development Release Naming

[John Burwell]

Chip,


On Mon, Jul 1, 2013 at 4:15 PM, Chip Childers wrote:

> On Mon, Jul 01, 2013 at 02:28:37PM -0400, John Burwell wrote:
> > All,
> >
> > Since we have adopted Semantic Versioning [1], it seems odd that we
> designate a release version before the final set of enhancements/fixes has
> been identified.  For example, the release proceeding 4.2 may contain no
> backwards compatible API changes to be 4.3.  Conversely, we may decide
> during the development cycle, as a community, to accept a non-backwards
> compatible change which would bump the version to 5.0.0.  As such, it is
> difficult to know in advance what the proper semantic version number will
> be at when the work is released.  We run the risk of confusing our users if
> we start calling a pending release say 4.3.0, and accept a change mid-cycle
> that will bump it to 5.0.0.  To address this potential issue, I proposed
> that we refer to releases by a codename until feature freeze when we
> understand the complete scope of change and can apply the correct semantic
> version number.  I further propose we codename the release directly
> proceeding 4.2 "Gamma Rays" or "Gamma Rays Gonna Get Ya".
> >
> > Thoughts?
> > -John
> >
> > [1]: http://semver.org
>
> Some technical issues to address WRT versions prior to a number being
> assigned:
>
> 1) package version strings (DEB and RPM)
>

Do we produce packages before feature freeze?  Provided that we don't
produce packages until the freeze, my thinking is that we would identify
the version number at the time the release branch gets cut.  I think it is
an extremely low (near nothing) probability that we would elect to take on
a backwards compatibility breaking patch after freeze.


> 2) DB version string, especially for testing upgrades
>

I think we should be considering a different versioning scheme for database
schemas that better accounts for the concurrent nature of development.  By
way of example, Flyway [1] has such an approach which helps sequencing
database changes made concurrently in different branches.  In the release
documentation, we would simply capture the associated schema version number
(e.g. 4.2.0 uses schema version 342312).


>
> Thoughts on how to avoid issues here?
>
> To me, it seems like we should make an upgrade to 5.x a *major discussion*,
> and instead *assume* that we will retain backward compatibility and not
> bump
> the major number.  I'd rather limit the number of times that we
> actually jump major versions and take the hit on the version numbering
> changes when those times to occur.  Just my 2 cents though.
>

I completely agree that we would have to accept such a change carefully as
a community, and seek to minimize the occurrence.  My thinking is that we
recognize that we likely won't know going into a release cycle that we have
such a change (or set of changes) coming.  My thought is that the messaging
for such a change would be significant, and that it would be nice to remove
the additional complexity of explaining, "You knew this release as 4.x, but
now we are calling it 5.0.0".


>
> -chip
>

[1]: http://flywaydb.org/

Re: Review Request 11670: CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary storage is in maintenance state.

[ASF Subversion and Git Services]

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


Commit ffd5f1a777ac9af5b65b1fcd357684d7dafcce87 in branch refs/heads/vmsync 
from Sanjay Tripathi
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ffd5f1a ]

CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary 
storage is in maintenance state.

Signed-off-by: Prasanna Santhanam 


- ASF Subversion and Git Services


On July 1, 2013, 9:18 a.m., Sanjay Tripathi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11670/
> ---
> 
> (Updated July 1, 2013, 9:18 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Devdeep Singh, and 
> Prasanna Santhanam.
> 
> 
> Bugs: CLOUDSTACK-2288
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary 
> storage is in maintenance state.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/storage/VolumeManagerImpl.java a293da5 
> 
> Diff: https://reviews.apache.org/r/11670/diff/
> 
> 
> Testing
> ---
> 
> Tests:
> 1. In CS setup, put all primary storage in maintenance mode.
> 2. Create a volume from snapshot.
> 
> Verified the fix locally.
> 
> 
> Thanks,
> 
> Sanjay Tripathi
> 
>

RE: Unresolved compilation problem?

[Vijayendra Bhamidipati]

Hi Hugo,

Looks like it was just due to some stale files - probably mvn clean has some 
issue where it isn't cleaning them up - I nuked and recreated my workspace and 
the cluster addition went through. Thanks for the prompt response!

Cheers!
Regards,
Vijay

-Original Message-
From: Hugo Trippaers [mailto:trip...@gmail.com] 
Sent: Monday, July 01, 2013 1:39 PM
To: dev@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: Unresolved compilation problem?

Heya,

I've made some changes to this function to support multiple types of broadcast 
domain types. So I had to add a dependency to the Pom to get the 
BroadcastDomainType enum.

This probably was not properly updated until you did a full recompile.

Cheers,

Hugo 

Sent from my iPhone

On 1 jul. 2013, at 22:21, Vijayendra Bhamidipati 
 wrote:

> I'm running into this exception when trying to add a vmware cluster on top of 
> latest master:
> 
> 
> INFO  [cloud.configuration.ConfigurationManagerImpl] 
> (829088401@qtp-729217986-4:) adding a new subnet to the network 200 
> INFO  [hypervisor.vmware.VmwareServerDiscoverer] 
> (1175658854@qtp-729217986-5:) Discover host. dc: 1, pod: 1, cluster: 
> 1, uri host: 10.223.52.61
> 2013-07-01 06:52:24.507:WARN::Error for /client/api
> java.lang.Error: Unresolved compilation problem: |?The method 
> prepareNetwork(String, String, HostMO, String, Integer, Integer, long, 
> boolean, BroadcastDomainType) from the type HypervisorHostHelper refers to 
> the missing type BroadcastDomainType|
>at 
> com.cloud.hypervisor.vmware.manager.VmwareManagerImpl.prepareHost(VmwareManagerImpl.java:351)
>at 
> com.cloud.hypervisor.vmware.manager.VmwareManagerImpl.addHostToPodCluster(VmwareManagerImpl.java:397)
>at 
> com.cloud.hypervisor.vmware.VmwareServerDiscoverer.find(VmwareServerDiscoverer.java:312)
>at 
> com.cloud.resource.ResourceManagerImpl.discoverCluster(ResourceManagerImpl.java:538)
>at 
> com.cloud.resource.ResourceManagerImpl_EnhancerByCloudStack_84a53fa0.CGLIB$discoverCluster$29()
>at 
> com.cloud.resource.ResourceManagerImpl_EnhancerByCloudStack_84a53fa0_FastClassByCloudStack_84071e69.invoke()
>at net.sf.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)
>at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>at 
> com.cloud.resource.ResourceManagerImpl_EnhancerByCloudStack_84a53fa0.discoverCluster()
>at 
> org.apache.cloudstack.api.command.admin.cluster.AddClusterCmd.execute(AddClusterCmd.java:204)
>at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
>at com.cloud.api.ApiServer.queueCommand(ApiServer.java:528)
>at com.cloud.api.ApiServer.handleRequest(ApiServer.java:371)
>at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:304)
>at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>at 
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
>at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
>at 
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>at 
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>at 
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
>at 
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
>at 
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
>at 
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
>at 
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>at org.mortbay.jetty.Server.handle(Server.java:326)
>at 
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
>at 
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
>at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
>at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
>at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
>at 
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
>at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.ja
> va:582)
> 
> 
> 
> I believe this could be caused by stale eclipse generated compile time files, 
> so I did a mvn clean and retried the compilation, which went through fine, 
> and the mgmt. server restarted up fine, so what am I missing? Any ideas?
> 
> 
> Regards,
> Vijay

Re: [MERGE] Merge VMSync improvement branch into master

[Kelven Yang]

I recently had an urgent family matter to take care and thanks for Alex to
help me out on this matter. I think at this moment, without a previous
100% rate of BVT past rate, it will be hard to tell a direct link between
a particular change with a BVT failure. It is a good idea to resolve this
measurement tool issue first.

Kelven

On 6/27/13 4:50 PM, "Alex Huang"  wrote:

>Dave,
>
>Chip has asked this before and we also stated specifically that we won't
>merge it in unless we see equivalent pass rate on the BVT as master.
>We're doing that right now.
>
>--Alex
>
>> -Original Message-
>> From: David Nalley [mailto:da...@gnsa.us]
>> Sent: Thursday, June 27, 2013 4:34 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [MERGE] Merge VMSync improvement branch into master
>> 
>> On Thu, Jun 27, 2013 at 5:51 PM, Hugo Trippaers 
>>wrote:
>> >
>> > I think Ilya offers is great, my current stance is also to see how we
>>can bring
>> this forward.
>> >
>> > I've had the opportunity to meet with several people at the Citrix
>>office in
>> Santa Clara, i'm actually working from their office at this moment. I
>>think it's
>> also the responsibility of someone who put in a -1 to work with the
>>original
>> committer to get the situation resolved. So i'll invest the time to
>>help with
>> the review as well.
>> >
>> > It would be great if Alex or Kelven could take the time to explain
>>how this
>> feature has been tested. That would give the community some insight as
>> well.
>> >
>> > My main technical problem with this merge is that stuff is moving all
>>over
>> the place without having even the slightest idea why. Now having
>>discussed
>> this with Alex in person i get the general idea of this merge, so can
>>actually
>> try to review it.
>> >
>> > I think that John have nicely explained what we could do to prevent
>> situations like this in advance. I fully understand that big features
>>or rewrites
>> don't happen overnight and might show up near the end of the release
>>cycle.
>> With the time based release cycle it's always a risk that some feature
>>might
>> not make it in on time. Getting more people involved and chunking the
>> commits into master will greatly speed up the reviewing process.
>> >
>> > I'll get back to this after spending some time on reviewing the
>>actual patch.
>> In fact i would like to ask more people to have a look at this patch
>>and reply
>> to this thread with comments or remarks.
>> >
>> > Cheers,
>> >
>> > Hugo
>> >
>> 
>> So the problem in my mind, is that we don't have a way of verifying that
>> master isn't broken, and won't be broken by any given merge. I look at
>>even
>> the minimal level of automated testing that I see today, and ~20% of
>> integration tests are failing[1]. The regression set of tests (which
>>isn't running
>> as often) is seeing 75% of tests failing[2]. Heaping on more change
>>when we
>> are demonstrably already failing in many places is not behaving
>>responsibly
>> IMO.
>> The question I'd pose is this - running the various automated tests is
>>pretty
>> cheap - whats the output of that compared to the current test output on
>> master? Better or worse? If it hasn't been done, why not?
>> I desperately want these features, but not necessarily at the cost of
>>further
>> destabilizing what we have now in master - we can't continue accruing
>> technical debt.
>> 
>> --David
>> 
>> [1] http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-
>> matrix/lastCompletedBuild/testReport/
>> [2] 
>>http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-regression-
>> matrix/28/testReport/

Secondary Storage/TinyLinux

[Soheil Eizadi]

A few days ago I built the latest 4.2 and it came up and secondary storage 
loaded TinyLinux Image that I was able to deploy it adding instances.

Today I rebuilt my system, initialized the database and this time using the 
same NFS secondary storage. I don't have Tiny Linux Image, when I go to add an 
instance from templates. However I see it in the Templates for the zone. Has 
any one seen this behavior?
-Soheil

RE: Secondary Storage/TinyLinux

[Devdeep Singh]

When you see it under Templates, what is the property of 'Ready' attribute of 
the template?

Regards,
Devdeep

> -Original Message-
> From: Soheil Eizadi [mailto:seiz...@infoblox.com]
> Sent: Monday, July 01, 2013 4:06 PM
> To: dev@cloudstack.apache.org
> Subject: Secondary Storage/TinyLinux
> 
> A few days ago I built the latest 4.2 and it came up and secondary storage
> loaded TinyLinux Image that I was able to deploy it adding instances.
> 
> Today I rebuilt my system, initialized the database and this time using the 
> same
> NFS secondary storage. I don't have Tiny Linux Image, when I go to add an
> instance from templates. However I see it in the Templates for the zone. Has
> any one seen this behavior?
> -Soheil

DevCloud2 problem

[CK]

I’m having some problems deploying DevCloud2 and wonder if you could help
please. I would like to build the Cloudstack source in DevCloud2 and run
everything from within the DevCloud2 VM. So far I have done the following,
any idea what can be causing the PermGen error at the end:**

 1.   Downloaded and imported the DevCloud2 image into VirtualBox –
ensured network settings were correct etc.

**

2.   Used PuTTY to SSH to the machine at 192.168.56.10 and logged in
with root and password for username and password

3.   cd to /opt/cloudstack

4.   git cloned into the source code for apache-cloudstack-4.1.0-src**

5.   once that had completed I cd’d to the
apache-cloudstack-4.1.0-src directory

6.   Ran mvn clean install –P developer,systemvm

7.   Changed the host value in devcloud.sql to 192.168.56.10 as I want
everything to run inside this one VM

8.   Ran mvn –pl developer,tools/devloud –Deploydb –P developer

9. Ran mvn -pl :cloud-client-ui jetty:run
I get the following messages:
...
INFO  [cloud.server.ManagementServerImpl] (Timer-2:) Startup CloudStack
management server...
INFO  [cloud.cluster.ClusterServiceServletContainer] (Thread-16:) Cluster
service servlet container listening on port 9090
INFO  [cloud.cluster.ClusterManagerImpl] (Cluster-Heartbeat-1:) We are
good, no orphan management server msid in host table is found
INFO  [cloud.cluster.ClusterManagerImpl] (Cluster-Heartbeat-1:) No inactive
management server node found
WARN  [cloud.cluster.ClusterManagerImpl] (Cluster-Notification-1:)
Notifying management server join event took 20 ms

Then when I browse from my laptop: http://192.168.56.10:8080/client/ I get
the following PermGen error in the browser:

HTTP ERROR 500

Problem accessing /client/. Reason:

PermGen space

Caused by:

java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386)
at 
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
at 
org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.buildTypeBindings(LookupEnvironment.java:143)
at 
org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:292)
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:315)
at 
org.apache.jasper.compiler.JDTJavaCompiler.compile(JDTJavaCompiler.java:503)
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:368)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:437)
at 
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:608)
at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:360)
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:486)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:380)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at 
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:327)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126)
at 
org.mortbay.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:503)


On the console:

2013-07-02 00:28:49.869:WARN::/client/
java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
at java.net.UR

Re: Review Request 12220: Cloudstack-3313 Ipv6 - Not able to deploy a new VM in IPV6 network.

[bharat kumar]

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

(Updated July 2, 2013, 2:07 a.m.)


Review request for cloudstack and Abhinandan Prateek.


Bugs: Cloudstack-3313


Repository: cloudstack-git


Description
---

Cloudstack-3313 Ipv6 - Not able to deploy a new VM in IPV6 network.


Diffs
-

  server/src/com/cloud/network/NetworkManagerImpl.java eef5d76 

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


Testing
---


Thanks,

bharat kumar

Review Request 12220: Cloudstack-3313 Ipv6 - Not able to deploy a new VM in IPV6 network.

[bharat kumar]

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

Review request for cloudstack and Abhinandan Prateek.


Bugs: Cloudstack-3313


Repository: cloudstack-git


Description
---

Cloudstack-3313 Ipv6 - Not able to deploy a new VM in IPV6 network.


Diffs
-

  server/src/com/cloud/network/NetworkManagerImpl.java eef5d76 

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


Testing
---


Thanks,

bharat kumar

Re: Query String Request Authentication(QSRA) support by S3 providers

[Thomas O'Dowd]

Yes thanks Jessica. I re-opened the bug again. I know its not a gui
problem per-say in that the template is not ready to show the download
link. However, it never becomes ready is the actual problem. What sets
the "isready" property to true? As far as I can see, the objects in the
S3 stores (AWS or Cloudian) are complete and from my perspective "ready"
to download/use. It sounds like a bug when registering the template.

Tom.

On Mon, 2013-07-01 at 18:54 +, Jessica Wang wrote:
> Thomas,
> 
> I checked the data you provided.
> 
> The reason that the 2 templates("MyTiny", "AnotherTiny") have no download 
> button is because they are not ready 
> (i.e. their "isready" property is false).
> 
> Download button is only available when "isready" property is true.
> 
> Jessica
> 
> -Original Message-
> From: Thomas O'Dowd [mailto:tpod...@cloudian.com] 
> Sent: Thursday, June 27, 2013 8:04 PM
> To: Min Chen
> Cc: dev@cloudstack.apache.org; Jessica Wang
> Subject: Re: Query String Request Authentication(QSRA) support by S3 providers
> 
> Hi Min/Jessica,
> 
> I attached an image to that issue to show what what my browser is
> showing.
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-3220 
> 
> Tom.
> 
> On Fri, 2013-06-28 at 09:45 +0900, Thomas O'Dowd wrote:
> > Hi Min,
> > 
> > Yes. I'll try it again today to check again but when I added Amazon S3
> > as the S3 secondary storage and uploaded a template, I was not shown the
> > "download template" link. However - for Cloudian S3, I am shown it so
> > I'm wondering why.
> > 
> > Tom.
> > 
> > On Fri, 2013-06-28 at 00:26 +, Min Chen wrote:
> > > Hi Tom,
> > > 
> > >   Are you saying that you cannot see a Download Template button from UI
> > > when Amazon S3 is added as secondary storage? I only tested with RiakCS
> > > and Cloudian, so didn't see this issue. But I am CC Jessica her to confirm
> > > what special handling is done in UI to enable/disable a button from UI.
> > > 
> > >   Thanks
> > >   -min
> > > 
> > > On 6/27/13 5:23 PM, "Thomas O'Dowd"  wrote:
> > > 
> > > >Hi Min,
> > > >
> > > >Can you check this bug? I'm trying to test this feature for Amazon but
> > > >having no luck getting the Download template link/button to appear.
> > > >
> > > >https://issues.apache.org/jira/browse/CLOUDSTACK-3220
> > > >
> > > >Thanks,
> > > >
> > > >Tom.
> > > >
> > > >On Fri, 2013-06-21 at 17:21 +, Min Chen wrote:
> > > >> John,
> > > >> 
> > > >>For S3, the api call createEntityExtractUrl is done on 
> > > >> management
> > > >>server
> > > >> side; while for NFS secondary storage, if the implementation of
> > > >> createEntityExtractUrl will involve some code be executed in ssvm to
> > > >>copy
> > > >> template from the install location to a public accessible web server
> > > >> location.
> > > >>I don't quite understand some of your comments below. This API 
> > > >> is not
> > > >> used to write any information to S3 bucket/directory. This is used for
> > > >> object already existed on S3, and we just provide a URL for user to
> > > >> download a template from S3, just like how Amazon provided user a way 
> > > >> to
> > > >> user to extract a S3 object through generatePresignedUrl. We can 
> > > >> discuss
> > > >> more on this on collaboration conference.
> > > >> 
> > > >>Thanks  
> > > >>-min
> > > >> 
> > > >> 
> > > >> 
> > > >> On 6/21/13 7:25 AM, "John Burwell"  wrote:
> > > >> 
> > > >> >Min,
> > > >> >
> > > >> >(I apologize for my belated reply -- I lost track of this draft in the
> > > >> >chaos of the last couple of days.)
> > > >> >
> > > >> >Upon further review, I think I feel into the confusion between
> > > >>management
> > > >> >server and ssvm.  This code is executing on the management server 
> > > >> >side,
> > > >> >correct?  Based on my "corrected" understanding is correct, I would
> > > >>like
> > > >> >to amend my thoughts.  Namely, I would like to see the driver
> > > >>operations
> > > >> >pushed out to the SSVM where we can use the stream.  As I think about
> > > >>it,
> > > >> >the management server should not need to interact with the driver.
> > > >> >Simply yard up the DataStore attributes + details map and other 
> > > >> >extract
> > > >> >parameters, and send them to the SSVM.  Using this information, the S3
> > > >> >driver could open a stream to write the template out to the
> > > >> >bucket/directory.  I recognize it changes the protocol between the
> > > >> >management server and SSVM, but it simply both sides of the operation
> > > >>by
> > > >> >allowing the DataStore information to be treated opaquely until it is
> > > >> >consumed by the driver to execute the write operation.  I also
> > > >>recognize
> > > >> >that we may a little late in the cycle to address it for 4.2, and it
> > > >>may
> > > >> >need to be part of the 4.3 enhancements.
> > > >> >
> > > >> >Thanks,
> > > >> >-John
> > > >> >
> > > >> >On Jun 18, 2013, at 3:55 PM, Min Chen  wrote:
> > > >> >
> > > 

Re: Review Request 11992: CLOUDSTACK-2571 ZWPS issues with Enabling/Clearing the Maintenance State of the Storage

[Rajesh Battala]

> On July 1, 2013, 5:18 p.m., edison su wrote:
> > Ship It!

Thanks Edison for the review and pushing to repo.


- Rajesh


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


On June 28, 2013, 9:18 a.m., Rajesh Battala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11992/
> ---
> 
> (Updated June 28, 2013, 9:18 a.m.)
> 
> 
> Review request for cloudstack, Alex Huang, edison su, Ram Ganesh, and Sateesh 
> Chodapuneedi.
> 
> 
> Bugs: CLOUDSTACK-2571
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Issue : NPE's are happening when ZWPS is put in maintenance, removed from 
> maintenance.
> 
> Fixed:
> 1. Added ZONE scope storage handling in StorageManagerImpl and 
> StoragePoolAutomationImpl 
> 2. Modified PrimaryDataStoreDao, listBy method to take poolid to Wrapper 
> class of long instead of primitive. Modified associated DaoImpl.
> 3. StoragePoolAutomationImpl, when storage is setting to Maintenance mode, 
> handled the case for ZONE wide scope of storage. 
>if the storage is zone wide, get all the hosts(kvm, vmware) in zone and 
> send the ModifyStoragePool command (with false)
> 4. When users, cancels maintenance mode, the handled the ZONE wide scope of 
> storage pool.
> 5. Once the Storage is in maintenance, Deletion of the Storage will remove 
> the mount points from all the hosts.
> 
> This patch will solve all the issues pertaining to keeping/cancelling the 
> ZONE wide primary storage.
> 
> 
> Diffs
> -
> 
>   
> engine/api/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
>  99b7b9c 
>   
> engine/api/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
>  8f7826f 
>   server/src/com/cloud/storage/StorageManagerImpl.java b3e8b96 
>   server/src/com/cloud/storage/StoragePoolAutomationImpl.java 4001775 
> 
> Diff: https://reviews.apache.org/r/11992/diff/
> 
> 
> Testing
> ---
> 
> Manual Testing
> = 
> 1. Enable maintenance mode of Zone wide storage , There were no NPE's 
> happening and successfully kept the storage in maintenance mode. Verified DB 
> status.
> 2. Cancel maintenance mode of Zone wide storage, There were no NPE's 
> happening and successfully kept the storage in UP state.
> 3. Enable maintenance mode of zone wide, once successful then Delete the 
> storage, Storage got deleted successfuly. Verify the hosts,  Storage got 
> unmounted and verified the DB status.
> Addition Tests (As the common code path is modified):
> 1. Add the Cluster scope of primary storage (kvm , xenserver). Adding the 
> storage in both clusters is successful.
> kvm specific:
> 
> 2. Enable Maintenance Mode of cluster scope kvm storage. Successfully enabled 
> the storage in maintenance state. 
> 3. Cancel the Maintenance Mode of cluster scope kvm storage. Successfully 
> enabled the storage in UP state.
> 4. Enable Maintenance Mode of cluster scope kvm storage. Delete the storage. 
> Storage got successfully deleted, unmounted from hosts and from db.
> 
> Xenserver specific:
> ===
> 5. Enable Maintenance Mode of cluster scope Xenserver storage. Successfully 
> enabled the storage in maintenance state. 
> 6. Cancel the Maintenance Mode of cluster scope Xenserver storage. 
> Successfully enabled the storage in UP state.
> 7. Enable Maintenance Mode of cluster scope Xenserver storage. Delete the 
> storage. Storage got successfully deleted, unmounted from hosts and from db.
> 
> ZWPS is supported in KVM and VMware, the common code is modified. It should 
> work of VMWare as well without any issues
> 
> 
> Thanks,
> 
> Rajesh Battala
> 
>

Review Request 12222: CLOUDSTACK-2510: Getting NPE while executing listStoragePools API command.

[Sanjay Tripathi]

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

Review request for cloudstack, Devdeep Singh, edison su, and Nitin Mehta.


Bugs: CLOUDSTACK-2510


Repository: cloudstack-git


Description
---

CLOUDSTACK-2510: Getting NPE while executinng listStoragePools API command.

Tried to add a primary storage to empty xen cluster; after this event not able 
to list primary storage, getting NPE . 


Diffs
-

  
plugins/storage/volume/default/src/org/apache/cloudstack/storage/datastore/lifecycle/CloudStackPrimaryDataStoreLifeCycleImpl.java
 2e0ff66 

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


Testing
---

Tests:
1. Add an empty cluster (without any host).
2. Add a cluster wide primary storage to this cluster (It will fail with an 
exception that "Fail to add data store").
3. Verified that listStoragePools API is working properly and its not listing 
the storage pool that admin tried to add in step 2.


Thanks,

Sanjay Tripathi

Re: Bug in 4.1-4.2 template upgrade process

[Abhinandan Prateek]

Hari,
  The hypervisor comparison should be case insensitive. I think the types
comes from a enum, can you also check the case there and try not to
hardcode the hypervisor string.
Another thing is that we are repeating the code for each HypervisorŠ  this
can be made more compact.

-abhi

On 02/07/13 12:35 AM, "Alena Prokharchyk" 
wrote:

>Ran sanity check for the 4.1-4.2 upgrade. Went fine with one exception - I
>haven't pre-installed the 4.2 system templates, and the update didn't
>fail.
>
>Hari, can you please fix it as you were the one who implemented system
>template upgrade. Steps to reproduce:
>
>1) Istall 4.1.0
>2) Add 1 xen cluster with 1 host and 1 primary storage.
>
>mysql> select distinct(hypervisor_type) from `cloud`.`cluster` where
>removed is null;
>+-+
>| hypervisor_type |
>+-+
>| xenserver   |
>+-+
>
>
>
>3) Upgrade to 4.2
>
>I bet all you have to do is to fix string comparison in
>Upgrade410to42.java
>
>-alena.
>
>

Re: In-Development Release Naming

[Daan Hoogland]

John,

If I understand you, we will call master x.(y+1) with x.y being the latest
unpatched release unless we decide that it is not going to be x-compatible
anymore. We will publish x.(y+1) as some symbolic name, possibly reflecting
a running gag from the latest collab, until it is decided whether it will
be x.(y+1) or (x+1).0.

I think it will have to have a semantic number on master or patch branches,
for people to be able to cook their own packages.

As for your schema versions, is the scheme you are proposing not just
adding administration. Flyway seems like a good tool but does it solve
concurrent upgrades i.e. 4.1.3 has an upgrade to 4.1.2 and 4.2.0 has a
similar but not equal upgrade. Will we have the obvious manual work on
4.1.3 -> 4.2.0 or will flyway help us smoothen this path.

regards,



On Mon, Jul 1, 2013 at 10:45 PM, John Burwell  wrote:

> Chip,
>
>
> On Mon, Jul 1, 2013 at 4:15 PM, Chip Childers  >wrote:
>
> > On Mon, Jul 01, 2013 at 02:28:37PM -0400, John Burwell wrote:
> > > All,
> > >
> > > Since we have adopted Semantic Versioning [1], it seems odd that we
> > designate a release version before the final set of enhancements/fixes
> has
> > been identified.  For example, the release proceeding 4.2 may contain no
> > backwards compatible API changes to be 4.3.  Conversely, we may decide
> > during the development cycle, as a community, to accept a non-backwards
> > compatible change which would bump the version to 5.0.0.  As such, it is
> > difficult to know in advance what the proper semantic version number will
> > be at when the work is released.  We run the risk of confusing our users
> if
> > we start calling a pending release say 4.3.0, and accept a change
> mid-cycle
> > that will bump it to 5.0.0.  To address this potential issue, I proposed
> > that we refer to releases by a codename until feature freeze when we
> > understand the complete scope of change and can apply the correct
> semantic
> > version number.  I further propose we codename the release directly
> > proceeding 4.2 "Gamma Rays" or "Gamma Rays Gonna Get Ya".
> > >
> > > Thoughts?
> > > -John
> > >
> > > [1]: http://semver.org
> >
> > Some technical issues to address WRT versions prior to a number being
> > assigned:
> >
> > 1) package version strings (DEB and RPM)
> >
>
> Do we produce packages before feature freeze?  Provided that we don't
> produce packages until the freeze, my thinking is that we would identify
> the version number at the time the release branch gets cut.  I think it is
> an extremely low (near nothing) probability that we would elect to take on
> a backwards compatibility breaking patch after freeze.
>
>
> > 2) DB version string, especially for testing upgrades
> >
>
> I think we should be considering a different versioning scheme for database
> schemas that better accounts for the concurrent nature of development.  By
> way of example, Flyway [1] has such an approach which helps sequencing
> database changes made concurrently in different branches.  In the release
> documentation, we would simply capture the associated schema version number
> (e.g. 4.2.0 uses schema version 342312).
>
>
> >
> > Thoughts on how to avoid issues here?
> >
> > To me, it seems like we should make an upgrade to 5.x a *major
> discussion*,
> > and instead *assume* that we will retain backward compatibility and not
> > bump
> > the major number.  I'd rather limit the number of times that we
> > actually jump major versions and take the hit on the version numbering
> > changes when those times to occur.  Just my 2 cents though.
> >
>
> I completely agree that we would have to accept such a change carefully as
> a community, and seek to minimize the occurrence.  My thinking is that we
> recognize that we likely won't know going into a release cycle that we have
> such a change (or set of changes) coming.  My thought is that the messaging
> for such a change would be significant, and that it would be nice to remove
> the additional complexity of explaining, "You knew this release as 4.x, but
> now we are calling it 5.0.0".
>
>
> >
> > -chip
> >
>
> [1]: http://flywaydb.org/
>

Re: Review Request 12209: Cloudstack-3302 VM deployement failed due to dnsmasq configuration issue in case of multiple subnets in a vlan

[Abhinandan Prateek]

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

Ship it!


Ship It!

- Abhinandan Prateek


On July 1, 2013, 1 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12209/
> ---
> 
> (Updated July 1, 2013, 1 p.m.)
> 
> 
> Review request for cloudstack and Abhinandan Prateek.
> 
> 
> Bugs: Cloudstack-3302
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Cloudstack-3302 VM deployement failed due to dnsmasq configuration issue in 
> case of multiple subnets in a vlan
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  286eb48 
> 
> Diff: https://reviews.apache.org/r/12209/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request 12209: Cloudstack-3302 VM deployement failed due to dnsmasq configuration issue in case of multiple subnets in a vlan

[Abhinandan Prateek]

> On July 2, 2013, 6:08 a.m., Abhinandan Prateek wrote:
> > Ship It!

Please, test your code in future, these errors could easily be caught if you 
tested your code.


- Abhinandan


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


On July 1, 2013, 1 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12209/
> ---
> 
> (Updated July 1, 2013, 1 p.m.)
> 
> 
> Review request for cloudstack and Abhinandan Prateek.
> 
> 
> Bugs: Cloudstack-3302
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Cloudstack-3302 VM deployement failed due to dnsmasq configuration issue in 
> case of multiple subnets in a vlan
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  286eb48 
> 
> Diff: https://reviews.apache.org/r/12209/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request 12207: Cloudstack-3299 incorrect arguments sent to the script createIpalias in case of vmware, Cloudstack-3240 corrected a mistake in the script name.

[Abhinandan Prateek]

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


Has this been tested ?

- Abhinandan Prateek


On July 1, 2013, 12:53 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12207/
> ---
> 
> (Updated July 1, 2013, 12:53 p.m.)
> 
> 
> Review request for cloudstack and Abhinandan Prateek.
> 
> 
> Bugs: Cloudstack-3240 and Cloudstack-3299
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Cloudstack-3299 incorrect arguments sent to the script createIpalias in case 
> of vmware,
> Cloudstack-3240 corrected a mistake in the script name.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  286eb48 
> 
> Diff: https://reviews.apache.org/r/12207/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request 12207: Cloudstack-3299 incorrect arguments sent to the script createIpalias in case of vmware, Cloudstack-3240 corrected a mistake in the script name.

[Abhinandan Prateek]

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


Also for two bug fixes submit different reviews or if they are duplicate mark 
these as such.

- Abhinandan Prateek


On July 1, 2013, 12:53 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12207/
> ---
> 
> (Updated July 1, 2013, 12:53 p.m.)
> 
> 
> Review request for cloudstack and Abhinandan Prateek.
> 
> 
> Bugs: Cloudstack-3240 and Cloudstack-3299
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Cloudstack-3299 incorrect arguments sent to the script createIpalias in case 
> of vmware,
> Cloudstack-3240 corrected a mistake in the script name.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  286eb48 
> 
> Diff: https://reviews.apache.org/r/12207/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> bharat kumar
> 
>