Re: Review Request: updated the listnics response for non-root user

[Jayapal Reddy]

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

(Updated April 25, 2013, 7:06 a.m.)


Review request for cloudstack, Abhinandan Prateek and Murali Reddy.


Changes
---

updated ipv6 in response


Description
---

Updated listnics response for normal user


This addresses bug CLOUDSTACK-1573.


Diffs (updated)
-

  server/src/com/cloud/api/ApiResponseHelper.java 894ec8d 

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


Testing
---

Tested with admin and normal user


Thanks,

Jayapal Reddy

Re: Error starting management server

[Dharmesh Kakadia]

Hi,

Thanks. That was exactly what I was missing. Running now !!

Thanks,
Dharmesh


On Thu, Apr 25, 2013 at 10:34 AM, Prasanna Santhanam  wrote:

> On Wed, Apr 24, 2013 at 11:07:38PM +0530, Dharmesh Kakadia wrote:
> > Hi,
> >
> > I am setting up dev environment following :
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/DevCloud
>
> Dev environment specifics are here:
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Setting+up+CloudStack+Development+Environment
>
> If you are using master branch for building:
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+on+master+branch
>
> You might want to give more memory as shown in the wiki:
> export MAVEN_OPTS="-XX:MaxPermSize=512m -Xmx2g -Xdebug
> -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"
>
> The supported tomcat version is 6.0.33. So you might want to downgrade
> and setup your CATALINA_HOME to point to the correct tomcat install.
>
> --
> Prasanna.,
>
> >
> > I am stuck on step 7.3 while starting the management server.
> >
> > the output of
> >
> > mvn -pl :cloud-client-ui jetty:run
> >
> > gets stuck after
> >
> > INFO  [utils.component.ComponentContext] (main:) Setup Spring Application
> > context
> >
> > I tried starting client-ui manually by copying the cloud-client-ui war
> file
> > into tomcat.
> >
> > Interestingly the log says
> >
> > SEVERE: Error listenerStart
> > Apr 24, 2013 6:32:38 PM org.apache.catalina.core.StandardContext start
> > SEVERE: Context [/cloud-client-ui-4.2.0-SNAPSHOT] startup failed due to
> > previous errors
> > Apr 24, 2013 6:32:38 PM org.apache.catalina.loader.WebappClassLoader
> > clearReferencesThreads
> > SEVERE: The web application [/cloud-client-ui-4.2.0-SNAPSHOT] appears to
> > have started a thread named [Timer-0] but has failed to stop it. This is
> > very likely to create a memory leak.
> > Apr 24, 2013 6:32:38 PM org.apache.catalina.loader.WebappClassLoader
> > clearReferencesThreads
> > SEVERE: The web application [/cloud-client-ui-4.2.0-SNAPSHOT] appears to
> > have started a thread named [ClusteredAgentManager Timer] but has failed
> to
> > stop it. This is very likely to create a memory leak.
> > Apr 24, 2013 6:32:38 PM org.apache.catalina.loader.WebappClassLoader
> > checkThreadLocalMapForLeaks
> > SEVERE: The web application [/cloud-client-ui-4.2.0-SNAPSHOT] created a
> > ThreadLocal with key of type [java.lang.ThreadLocal] (value
> > [java.lang.ThreadLocal@3a7d1a7a]) and a value of type
> > [com.cloud.utils.db.Transaction] (value [ : ]) but failed to remove it
> when
> > the web application was stopped. This is very likely to create a memory
> > leak.
> >
> > I am running this on Mac OS with tomcat apache-tomcat-6.0.36 and java
> > 1.6.0_45 and maven 3.0.3.
> >
> > Any help ?
> >
> > Thanks,
> > Dharmesh
>
>
> 
> Powered by BigRock.com
>
>

RE: running jetty with eclipse generated code?

[Daan Hoogland]

So basically you are saying; move to unix (or Cygwin) as a dev platform. I 
guess I forgot to say that half my work is on a windows work station. I am 
would like eclipse to reload classes on the fly as they are changed.

Thanks for your pointer, though. It is very useful.
Daan Hoogland

-Original Message-
From: Edison Su [mailto:edison...@citrix.com] 
Sent: woensdag 24 april 2013 19:33
To: dev@cloudstack.apache.org
Subject: RE: running jetty with eclipse generated code?



> -Original Message-
> From: Daan Hoogland [mailto:dhoogl...@schubergphilis.com]
> Sent: Wednesday, April 24, 2013 2:56 AM
> To: dev@cloudstack.apache.org
> Subject: running jetty with eclipse generated code?
> 
> H,
> 
> Are any people using the run target in eclipse in debug mode to run 
> with the local code, as opposed to the packaged code?


Eclipse will call maven to build jars, even jetty is running inside Eclipse, 
AFAIK.

> 
> This would seriously reduce my dev-debug-cycle as I am now completely 
> building cloudstack on every code change.

If you just want to reduce the build time, only build your local changes, 
instead of build all the projects:
You can try the following link: 
http://www.mail-archive.com/dev@cloudstack.apache.org/msg01459.html

> I have not a lot of experience with the use of maven in eclipse. So I 
> can use a pointer.
> 
> Thanks,
> Daan

Review Request: CLOUDSTACK-2180: restoreVirtualMachine returns no password if the template is password enabled

[Harikrishna Patnala]

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

Review request for cloudstack, Abhinandan Prateek and Koushik Das.


Description
---

CLOUDSTACK-2180: restoreVirtualMachine returns no password
 if the template is password enabled

New password is generated as part of restore vm(passwd enabled template) and 
send new password on VR


This addresses bug CLOUDSTACK-2180.


Diffs
-

  api/src/com/cloud/vm/UserVmService.java 7e89cd3 
  server/src/com/cloud/vm/UserVmManagerImpl.java ebc5757 
  server/test/com/cloud/vm/MockUserVmManagerImpl.java d886fd8 
  server/test/com/cloud/vm/UserVmManagerTest.java e5e2ff2 

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


Testing
---


Thanks,

Harikrishna Patnala

Re: [DOCS][TRANSLATIONS] Upate

[Gavin Lee]

Done for zh_CN translation on transifex for master branch.

For 2.2.xmessages for zh_CN, and also for ja, the encoding is incorrect and
resource files are not maintained by community.


On Wed, Apr 24, 2013 at 10:06 PM, Milamber  wrote:

>
>
> Le 24/04/2013 10:44, Milamber a ecrit :
>
>
>>
>> Le 23/04/2013 13:50, Gavin Lee a ecrit :
>>
>>> Following Milamber's guide , below process I used for
>>> 4.1.xmessage.properties on zh_CN:
>>> 1. git pull for the latest messages_zh_CN.properties
>>> 2. native2ascii -reverse messages_zh_CN.properties
>>> /tmp/zh_CN.properties.native -encoding utf8
>>>
>> -encoding utf8 <=== not necessary (on my machine)
>
>
>
>  3. copy to the CloudStack_UI transifex project:
>>> cp/tmp/zh_CN.properties.native /
>>> txprj/acsui/translations/**CloudStack_UI.**41xmessageproperties
>>> 4. tx push -l zh_CN -r CloudStack_UI.**41xmessageproperties -t
>>> 5. Do translation on transifex, there are some untranslated items when
>>> syncing with en.properties
>>> 6. tx pull -a
>>>
>>>
>>> Then convert to ascii with unicode, the i18nedit tools throws exception,
>>> I
>>> tried native2ascii command as below and UI display correctly:
>>> native2ascii -encoding UTF-8 zh_CN.properties messages_zh_CN.properties
>>>
>>> Are the whole processes above correct or not?
>>>
>>
>> Yes the process is correct, but currently on master branch the
>> messages_zh_CN.properties is not converting into a ASCII with unicode
>> unlike the 4.1 branch.
>> I will fix this for all messages_xx.properties on master branch today
>> (tonight) (FRench is already convert)
>>
>
> I just have made the fix for chinese (zh_CN) resource file on master
> branch. Now it's a ascii with unicode file and the process can execute
> manually with transifex.
> I made too a upload on transifex (with converting into native charset) for
> fix all sentences which have been corrupts with a previous upload (perhaps
> your upload I think)
>
>
> Currently, missing 33 translations for master (4.2) resource file zn_CN on
> transifex.
>
> Milamber
>
>
>
>> === (on master branch) ===
>>
>> cloudstack-dev/client/WEB-INF/**classes/resources$ file *
>> messages_fr_FR.properties: ASCII text, with very long lines
>> messages_ja.properties:UTF-8 Unicode text, with very long lines
>> messages_ko_KR.properties: UTF-8 Unicode text, with very long lines
>> messages.properties:   ASCII text, with very long lines
>> messages_pt_BR.properties: ISO-8859 text, with very long lines
>> messages_ru_RU.properties: UTF-8 Unicode text, with very long lines, with
>> CRLF line terminators
>> messages_zh_CN.properties: UTF-8 Unicode text, with very long lines, with
>> CRLF, LF line terminators
>>
>> === (on 4.1 branch) ===
>> cloudstack-dev/client/WEB-INF/**classes/resources$ file *
>> messages_ca.properties:ASCII text, with very long lines
>> messages_de_DE.properties: ASCII text
>> messages_es.properties:ASCII text, with very long lines
>> messages_fr_FR.properties: ASCII text, with very long lines
>> messages_it_IT.properties: ASCII text, with very long lines
>> messages_ja.properties:ASCII text, with very long lines
>> messages_ko_KR.properties: ASCII text, with very long lines
>> messages_nb_NO.properties: ASCII text
>> messages.properties:   ASCII text, with very long lines
>> messages_pt_BR.properties: ASCII text, with very long lines
>> messages_ru_RU.properties: ASCII text, with very long lines
>> messages_zh_CN.properties: ASCII text, with very long lines
>>
>> Milamber
>>
>>
>>
>>>
>>>
>>>
>>> On Tue, Apr 23, 2013 at 12:01 AM, Sebastien Goasguen**
>>> wrote:
>>>
>>>  Milamber, I made you a manager of the transifex project so you can help
 fixing those issues.

 -sebastien

 On Apr 22, 2013, at 11:10 AM, Milamber  wrote:


> Le 17/04/2013 07:26, Sebastien Goasguen a ecrit :
>
>> On Apr 16, 2013, at 11:10 AM, Milamber   wrote:
>>
>>  Le 16/04/2013 13:41, Gavin Lee a ecrit :
>>>
 Yes, Traditional Chinese moving very quickly.
 Hopefully, the other languages can have more contributors.

 For the UI part, I saw the characters are not recognizable (browser
 encoding setting: auto detect&Unicode UTF-8):
 ja: http://snag.gy/AVsbU.jpg
 zh_CN: http://snag.gy/MxbBS.jpg

>>> This screenshots shows some characters with a incorrect encoding (try
>>>
>> to display a char as a ISO-8859-1 (or japanese charset) but the
 encoding is
 a UTF-8, I think)

> With Sebgoa, we have correct all UI ressource file to have only one
>>>
>> encoding charset in this files (ASCII with unicode). The transifex
 data
 isn't up-to-date.

> Sebgoa, I think we must upload the last version of this (all)
>>>
>> resources files (except FR already done) from branch 4.1 to transifex.

> The last version of resources files is ASCII with unicode for *all
>>>
>> chars* in each file, and now transif

Re: Exposing APIs that carry POST data

[Rohit Yadav]

On Thu, Apr 25, 2013 at 10:59 AM, Prasanna Santhanam  wrote:

> On Wed, Apr 24, 2013 at 06:08:49AM -0400, Sebastien Goasguen wrote:
> >
> > On Apr 24, 2013, at 4:38 AM, Prasanna Santhanam  wrote:
> >
> > > Vijay added the ability to send userdata as POST for the
> > > deployVirtualMachine API in review [1]. What I'd like to address here
> > > is how to expose this via ApiDiscovery so that clients like marvin,
> > > cloudmonkey can autogenerate themselves to support APIs of this
> > > kind. This also needs to be clearly specified in our API docs.
> > >
> > > I'm guessing we'll have to put in additional annotations on our APIs
> > > that support POST so that API discovery can print the methods
> > > supported (GET/POST). Right now it's only the deployVMCmd (AFAIK). But
> > > I expect this will need to be done for others soon.
> > >
> > > I've included POST support for _every_ command in marvin but that's
> > > just brute-force. To make it more intelligent I think we should apply
> > > it to only apis that make sense as POST (causing side-effects). But
> > > that needs to be exposed by the api endpoint.
> > >
> > > Thoughts?
> >
> > Prasanna, this seems to me like a bigger discussion as you say, we
> > could see more api start having a POST.
>
> > Will we later see DELETE and PATCH?
> >
> > Could be that we are talking about making the API from RESTfull
> > which would be a big undertaking.
>
> I think some work was already underway - Min/Rohit started working on
> a complete REST based service. It is a significant change and I'll let
> them speak about the scale of that change. In my case, I just want to
> auto-generate marvin classes without having to hand edit anything.
>

Nothing from my side on REST based service.


>
> >
> > I started a toy REST example for a talk:
> > https://github.com/runseb/cloudstack-flask/blob/master/flasktest.py
>

+1 cool

Cheers.


> This is cool! Will check it out!
>
> >
> > It would be a bit silly to create a REST wrapper on our API but might
> give ideas...
> >
> > -Sebastien
> >
> > >
> > > [1] https://reviews.apache.org/r/10294/
> > >
> > > --
> > > Prasanna.,
> > >
> > > 
> > > Powered by BigRock.com
> > >
>
> --
> Prasanna.,
>
> 
> Powered by BigRock.com
>
>

Re: Review Request: Updated the user permission to acquire ip

[Jayapal Reddy]

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

(Updated April 25, 2013, 8:43 a.m.)


Review request for cloudstack, Abhinandan Prateek and Murali Reddy.


Changes
---

Updated access checks to vm 


Description
---

Updated the user permissions check


This addresses bug CLOUDSTACK-2134.


Diffs (updated)
-

  server/src/com/cloud/network/NetworkServiceImpl.java 7653a08 

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


Testing
---

Unit tested on basic and advanced zone


Thanks,

Jayapal Reddy

Re: [DOCS][TRANSLATIONS] Upate

[Milamber]

Le 25/04/2013 08:05, Gavin Lee a ecrit :

Done for zh_CN translation on transifex for master branch.


Thanks. I just update the master branch.



For 2.2.xmessages for zh_CN, and also for ja, the encoding is incorrect and
resource files are not maintained by community.


Yes, the encoding's translation are incorrect.
I don't know where we can find the original 2.2 resource file to fix it. 
But I don't if we must maintain the version 2.2...


Milamber




On Wed, Apr 24, 2013 at 10:06 PM, Milamber  wrote:



Le 24/04/2013 10:44, Milamber a ecrit :



Le 23/04/2013 13:50, Gavin Lee a ecrit :


Following Milamber's guide , below process I used for
4.1.xmessage.properties on zh_CN:
1. git pull for the latest messages_zh_CN.properties
2. native2ascii -reverse messages_zh_CN.properties
/tmp/zh_CN.properties.native -encoding utf8


-encoding utf8<=== not necessary (on my machine)



  3. copy to the CloudStack_UI transifex project:

cp/tmp/zh_CN.properties.native /
txprj/acsui/translations/**CloudStack_UI.**41xmessageproperties
4. tx push -l zh_CN -r CloudStack_UI.**41xmessageproperties -t
5. Do translation on transifex, there are some untranslated items when
syncing with en.properties
6. tx pull -a


Then convert to ascii with unicode, the i18nedit tools throws exception,
I
tried native2ascii command as below and UI display correctly:
native2ascii -encoding UTF-8 zh_CN.properties messages_zh_CN.properties

Are the whole processes above correct or not?


Yes the process is correct, but currently on master branch the
messages_zh_CN.properties is not converting into a ASCII with unicode
unlike the 4.1 branch.
I will fix this for all messages_xx.properties on master branch today
(tonight) (FRench is already convert)


I just have made the fix for chinese (zh_CN) resource file on master
branch. Now it's a ascii with unicode file and the process can execute
manually with transifex.
I made too a upload on transifex (with converting into native charset) for
fix all sentences which have been corrupts with a previous upload (perhaps
your upload I think)


Currently, missing 33 translations for master (4.2) resource file zn_CN on
transifex.

Milamber




=== (on master branch) ===

cloudstack-dev/client/WEB-INF/**classes/resources$ file *
messages_fr_FR.properties: ASCII text, with very long lines
messages_ja.properties:UTF-8 Unicode text, with very long lines
messages_ko_KR.properties: UTF-8 Unicode text, with very long lines
messages.properties:   ASCII text, with very long lines
messages_pt_BR.properties: ISO-8859 text, with very long lines
messages_ru_RU.properties: UTF-8 Unicode text, with very long lines, with
CRLF line terminators
messages_zh_CN.properties: UTF-8 Unicode text, with very long lines, with
CRLF, LF line terminators

=== (on 4.1 branch) ===
cloudstack-dev/client/WEB-INF/**classes/resources$ file *
messages_ca.properties:ASCII text, with very long lines
messages_de_DE.properties: ASCII text
messages_es.properties:ASCII text, with very long lines
messages_fr_FR.properties: ASCII text, with very long lines
messages_it_IT.properties: ASCII text, with very long lines
messages_ja.properties:ASCII text, with very long lines
messages_ko_KR.properties: ASCII text, with very long lines
messages_nb_NO.properties: ASCII text
messages.properties:   ASCII text, with very long lines
messages_pt_BR.properties: ASCII text, with very long lines
messages_ru_RU.properties: ASCII text, with very long lines
messages_zh_CN.properties: ASCII text, with very long lines

Milamber






On Tue, Apr 23, 2013 at 12:01 AM, Sebastien Goasguen**
wrote:

  Milamber, I made you a manager of the transifex project so you can help

fixing those issues.

-sebastien

On Apr 22, 2013, at 11:10 AM, Milamber   wrote:



Le 17/04/2013 07:26, Sebastien Goasguen a ecrit :


On Apr 16, 2013, at 11:10 AM, Milamberwrote:

  Le 16/04/2013 13:41, Gavin Lee a ecrit :

Yes, Traditional Chinese moving very quickly.
Hopefully, the other languages can have more contributors.

For the UI part, I saw the characters are not recognizable (browser
encoding setting: auto detect& Unicode UTF-8):
ja: http://snag.gy/AVsbU.jpg
zh_CN: http://snag.gy/MxbBS.jpg


This screenshots shows some characters with a incorrect encoding (try


to display a char as a ISO-8859-1 (or japanese charset) but the

encoding is
a UTF-8, I think)


With Sebgoa, we have correct all UI ressource file to have only one

encoding charset in this files (ASCII with unicode). The transifex

data
isn't up-to-date.


Sebgoa, I think we must upload the last version of this (all)

resources files (except FR already done) from branch 4.1 to transifex.

The last version of resources files is ASCII with unicode for *all

chars* in each file, and now transifex keep the unicode char (check

with FR
download for use)


Mistake: transifex don't support uploaded unicode chars.

  The way the original workflow was:

-Upload new versions of the resources file in english
-Tran

Re: [DOCS][TRANSLATIONS] Upate

[Sebastien Goasguen]

On Apr 25, 2013, at 4:48 AM, Milamber  wrote:

> 
> 
> Le 25/04/2013 08:05, Gavin Lee a ecrit :
>> Done for zh_CN translation on transifex for master branch.
> 
> Thanks. I just update the master branch.
> 
>> 
>> For 2.2.xmessages for zh_CN, and also for ja, the encoding is incorrect and
>> resource files are not maintained by community.
> 
> Yes, the encoding's translation are incorrect.
> I don't know where we can find the original 2.2 resource file to fix it. But 
> I don't if we must maintain the version 2.2…

No, IMHO we should only maintain 4.x + since those are the only Apache releases.

as a side note, I noticed a Apache CloudStack UL project on transifex which has 
16% translation of the UI in arabic. I had met the folks in Oman, and they 
wanted their own project to manage. However i don't know how to "import" their 
translations into our project.


> 
> Milamber
> 
>> 
>> 
>> On Wed, Apr 24, 2013 at 10:06 PM, Milamber  wrote:
>> 
>>> 
>>> Le 24/04/2013 10:44, Milamber a ecrit :
>>> 
>>> 
 Le 23/04/2013 13:50, Gavin Lee a ecrit :
 
> Following Milamber's guide , below process I used for
> 4.1.xmessage.properties on zh_CN:
> 1. git pull for the latest messages_zh_CN.properties
> 2. native2ascii -reverse messages_zh_CN.properties
> /tmp/zh_CN.properties.native -encoding utf8
> 
 -encoding utf8<=== not necessary (on my machine)
>>> 
>>> 
>>>  3. copy to the CloudStack_UI transifex project:
> cp/tmp/zh_CN.properties.native /
> txprj/acsui/translations/**CloudStack_UI.**41xmessageproperties
> 4. tx push -l zh_CN -r CloudStack_UI.**41xmessageproperties -t
> 5. Do translation on transifex, there are some untranslated items when
> syncing with en.properties
> 6. tx pull -a
> 
> 
> Then convert to ascii with unicode, the i18nedit tools throws exception,
> I
> tried native2ascii command as below and UI display correctly:
> native2ascii -encoding UTF-8 zh_CN.properties messages_zh_CN.properties
> 
> Are the whole processes above correct or not?
> 
 Yes the process is correct, but currently on master branch the
 messages_zh_CN.properties is not converting into a ASCII with unicode
 unlike the 4.1 branch.
 I will fix this for all messages_xx.properties on master branch today
 (tonight) (FRench is already convert)
 
>>> I just have made the fix for chinese (zh_CN) resource file on master
>>> branch. Now it's a ascii with unicode file and the process can execute
>>> manually with transifex.
>>> I made too a upload on transifex (with converting into native charset) for
>>> fix all sentences which have been corrupts with a previous upload (perhaps
>>> your upload I think)
>>> 
>>> 
>>> Currently, missing 33 translations for master (4.2) resource file zn_CN on
>>> transifex.
>>> 
>>> Milamber
>>> 
>>> 
>>> 
 === (on master branch) ===
 
 cloudstack-dev/client/WEB-INF/**classes/resources$ file *
 messages_fr_FR.properties: ASCII text, with very long lines
 messages_ja.properties:UTF-8 Unicode text, with very long lines
 messages_ko_KR.properties: UTF-8 Unicode text, with very long lines
 messages.properties:   ASCII text, with very long lines
 messages_pt_BR.properties: ISO-8859 text, with very long lines
 messages_ru_RU.properties: UTF-8 Unicode text, with very long lines, with
 CRLF line terminators
 messages_zh_CN.properties: UTF-8 Unicode text, with very long lines, with
 CRLF, LF line terminators
 
 === (on 4.1 branch) ===
 cloudstack-dev/client/WEB-INF/**classes/resources$ file *
 messages_ca.properties:ASCII text, with very long lines
 messages_de_DE.properties: ASCII text
 messages_es.properties:ASCII text, with very long lines
 messages_fr_FR.properties: ASCII text, with very long lines
 messages_it_IT.properties: ASCII text, with very long lines
 messages_ja.properties:ASCII text, with very long lines
 messages_ko_KR.properties: ASCII text, with very long lines
 messages_nb_NO.properties: ASCII text
 messages.properties:   ASCII text, with very long lines
 messages_pt_BR.properties: ASCII text, with very long lines
 messages_ru_RU.properties: ASCII text, with very long lines
 messages_zh_CN.properties: ASCII text, with very long lines
 
 Milamber
 
 
 
> 
> 
> On Tue, Apr 23, 2013 at 12:01 AM, Sebastien Goasguen**
> wrote:
> 
>  Milamber, I made you a manager of the transifex project so you can help
>> fixing those issues.
>> 
>> -sebastien
>> 
>> On Apr 22, 2013, at 11:10 AM, Milamber   wrote:
>> 
>> 
>>> Le 17/04/2013 07:26, Sebastien Goasguen a ecrit :
>>> 
 On Apr 16, 2013, at 11:10 AM, Milamberwrote:
 
  Le 16/04/2013 13:41, Gavin Lee a ecrit :
>> Yes, Traditional Chinese moving very quickly.
>> Hopefully, the other languages can

Re: Review Request: CLOUDSTACK-2180: restoreVirtualMachine returns no password if the template is password enabled

[Harikrishna Patnala]

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

(Updated April 25, 2013, 8:54 a.m.)


Review request for cloudstack, Abhinandan Prateek and Koushik Das.


Description
---

CLOUDSTACK-2180: restoreVirtualMachine returns no password
 if the template is password enabled

New password is generated as part of restore vm(passwd enabled template) and 
send new password on VR


This addresses bug CLOUDSTACK-2180.


Diffs
-

  api/src/com/cloud/vm/UserVmService.java 7e89cd3 
  server/src/com/cloud/vm/UserVmManagerImpl.java ebc5757 
  server/test/com/cloud/vm/MockUserVmManagerImpl.java d886fd8 
  server/test/com/cloud/vm/UserVmManagerTest.java e5e2ff2 

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


Testing
---


Thanks,

Harikrishna Patnala

Re: Review Request: CLOUDSTACK-2180: restoreVirtualMachine returns no password if the template is password enabled

[Harikrishna Patnala]

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

(Updated April 25, 2013, 8:54 a.m.)


Review request for cloudstack, Abhinandan Prateek and Koushik Das.


Description
---

CLOUDSTACK-2180: restoreVirtualMachine returns no password
 if the template is password enabled

New password is generated as part of restore vm(passwd enabled template) and 
send new password on VR


This addresses bug CLOUDSTACK-2180.


Diffs
-

  api/src/com/cloud/vm/UserVmService.java 7e89cd3 
  server/src/com/cloud/vm/UserVmManagerImpl.java ebc5757 
  server/test/com/cloud/vm/MockUserVmManagerImpl.java d886fd8 
  server/test/com/cloud/vm/UserVmManagerTest.java e5e2ff2 

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


Testing
---


Thanks,

Harikrishna Patnala

Re: Review Request: (CLOUDSTACK-1325) add password in response of RestoreVM

[Harikrishna Patnala]

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

Ship it!


Ship It!

- Harikrishna Patnala


On April 2, 2013, 1:24 p.m., Wei Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/9539/
> ---
> 
> (Updated April 2, 2013, 1:24 p.m.)
> 
> 
> Review request for cloudstack, Sateesh Chodapuneedi and Harikrishna Patnala.
> 
> 
> Description
> ---
> 
> In 4.0.1, There is no password field in the respone of RestoreVM.
> Please see https://issues.apache.org/jira/browse/CLOUDSTACK-1325
> 
> This patch add a new password in the response.
> 
> 
> This addresses bug CLOUDSTACK-1325.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/vm/UserVmService.java 6635657 
>   server/src/com/cloud/vm/UserVmManagerImpl.java dbcbeb8 
> 
> Diff: https://reviews.apache.org/r/9539/diff/
> 
> 
> Testing
> ---
> 
> Testing manually ok.
> 
> command=restoreVirtualMachine&response=json&virtualmachineid=1a53a308-c870-452a-9eff-23975919286b
>  public $jobid =>
>  string(36) "7e855ed2-b5ab-4449-a163-5c1af62019ab"
> 
> command=queryAsyncJobResult&response=json&jobid=7e855ed2-b5ab-4449-a163-5c1af62019ab
>  public $password =>
>  string(9) "mD5qkzmdk"
> 
> 
> Thanks,
> 
> Wei Zhou
> 
>

Re: Review Request: CLOUDSTACK-2180: restoreVirtualMachine returns no password if the template is password enabled

[Prasanna Santhanam]

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

(Updated April 25, 2013, 9:05 a.m.)


Review request for cloudstack, Abhinandan Prateek, Koushik Das, and Wei Zhou.


Changes
---

This has some more detail than the similar: https://reviews.apache.org/r/9539/. 
Can you explain the additional detail? Thanks


Description
---

CLOUDSTACK-2180: restoreVirtualMachine returns no password
 if the template is password enabled

New password is generated as part of restore vm(passwd enabled template) and 
send new password on VR


This addresses bug CLOUDSTACK-2180.


Diffs
-

  api/src/com/cloud/vm/UserVmService.java 7e89cd3 
  server/src/com/cloud/vm/UserVmManagerImpl.java ebc5757 
  server/test/com/cloud/vm/MockUserVmManagerImpl.java d886fd8 
  server/test/com/cloud/vm/UserVmManagerTest.java e5e2ff2 

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


Testing
---


Thanks,

Harikrishna Patnala

Review Request: FIX https://issues.apache.org/jira/browse/CLOUDSTACK-2172, by adding database upgrade to 4.1.0 in PremiumDatabaseUpgradeChecker.

[Nicolas Lamirault]

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

Review request for cloudstack.


Description
---

Add migration to 4.1.0 in the PremiumDatabaseUpgradeChecker, like in the 
DatabaseUpgradeChecker.
I opened the ticket CS 2172, and this fix corrects the issue.
Regards.


This addresses bug 2172.


Diffs
-

  server/src/com/cloud/upgrade/PremiumDatabaseUpgradeChecker.java 14a8143 

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


Testing
---


Thanks,

Nicolas Lamirault

Re: Review Request: updated the listnics response for non-root user

[Murali Reddy]

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

Ship it!


Ship It!

- Murali Reddy


On April 25, 2013, 7:06 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10703/
> ---
> 
> (Updated April 25, 2013, 7:06 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Murali Reddy.
> 
> 
> Description
> ---
> 
> Updated listnics response for normal user
> 
> 
> This addresses bug CLOUDSTACK-1573.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/api/ApiResponseHelper.java 894ec8d 
> 
> Diff: https://reviews.apache.org/r/10703/diff/
> 
> 
> Testing
> ---
> 
> Tested with admin and normal user
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

There is no secondary storage VM for secondary storage host

[Amr M]

Hello !
iam new with cloudstack
i followed the installation documention
but when i trying to add iso its not be addedd
i checked the log
2013-04-25 00:41:16,783 WARN [storage.download.DownloadMonitorImpl]
(catalina-exec-12:null) There is no secondary storage VM for secondary
storage host nfs://67.215.229.165/export/secondary

Note: i use management server as Nfs server too

Regards,

Re: Review Request: CLOUDSTACK-2180: restoreVirtualMachine returns no password if the template is password enabled

[Prasanna Santhanam]

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


Added additional reviewer

- Prasanna Santhanam


On April 25, 2013, 9:05 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10772/
> ---
> 
> (Updated April 25, 2013, 9:05 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Koushik Das, and Wei Zhou.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2180: restoreVirtualMachine returns no password
>  if the template is password enabled
> 
> New password is generated as part of restore vm(passwd enabled template) and 
> send new password on VR
> 
> 
> This addresses bug CLOUDSTACK-2180.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/vm/UserVmService.java 7e89cd3 
>   server/src/com/cloud/vm/UserVmManagerImpl.java ebc5757 
>   server/test/com/cloud/vm/MockUserVmManagerImpl.java d886fd8 
>   server/test/com/cloud/vm/UserVmManagerTest.java e5e2ff2 
> 
> Diff: https://reviews.apache.org/r/10772/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request: (CLOUDSTACK-1325) add password in response of RestoreVM

[Harikrishna Patnala]

> On April 25, 2013, 8:55 a.m., Harikrishna Patnala wrote:
> > Ship It!

Not a right time to give comments but came across a difference when comparing 
with my patch on master. we need to load vm details "_vmDao.loadDetails(vm)" 
before getting the details "vm.getDetail("SSH.PublicKey")". since details are 
transient. 


- Harikrishna


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


On April 2, 2013, 1:24 p.m., Wei Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/9539/
> ---
> 
> (Updated April 2, 2013, 1:24 p.m.)
> 
> 
> Review request for cloudstack, Sateesh Chodapuneedi and Harikrishna Patnala.
> 
> 
> Description
> ---
> 
> In 4.0.1, There is no password field in the respone of RestoreVM.
> Please see https://issues.apache.org/jira/browse/CLOUDSTACK-1325
> 
> This patch add a new password in the response.
> 
> 
> This addresses bug CLOUDSTACK-1325.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/vm/UserVmService.java 6635657 
>   server/src/com/cloud/vm/UserVmManagerImpl.java dbcbeb8 
> 
> Diff: https://reviews.apache.org/r/9539/diff/
> 
> 
> Testing
> ---
> 
> Testing manually ok.
> 
> command=restoreVirtualMachine&response=json&virtualmachineid=1a53a308-c870-452a-9eff-23975919286b
>  public $jobid =>
>  string(36) "7e855ed2-b5ab-4449-a163-5c1af62019ab"
> 
> command=queryAsyncJobResult&response=json&jobid=7e855ed2-b5ab-4449-a163-5c1af62019ab
>  public $password =>
>  string(9) "mD5qkzmdk"
> 
> 
> Thanks,
> 
> Wei Zhou
> 
>

Re: Review Request: CLOUDSTACK-2180: restoreVirtualMachine returns no password if the template is password enabled

[Harikrishna Patnala]

> On April 25, 2013, 9:34 a.m., Prasanna Santhanam wrote:
> > Added additional reviewer

Both patches are same except the unit tests that we added on master. 


- Harikrishna


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


On April 25, 2013, 9:05 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10772/
> ---
> 
> (Updated April 25, 2013, 9:05 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Koushik Das, and Wei Zhou.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2180: restoreVirtualMachine returns no password
>  if the template is password enabled
> 
> New password is generated as part of restore vm(passwd enabled template) and 
> send new password on VR
> 
> 
> This addresses bug CLOUDSTACK-2180.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/vm/UserVmService.java 7e89cd3 
>   server/src/com/cloud/vm/UserVmManagerImpl.java ebc5757 
>   server/test/com/cloud/vm/MockUserVmManagerImpl.java d886fd8 
>   server/test/com/cloud/vm/UserVmManagerTest.java e5e2ff2 
> 
> Diff: https://reviews.apache.org/r/10772/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request: Add uuid to AddIpToVmNicCmd nicsecondary ip resonpose

[Abhinandan Prateek]

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

Ship it!


Ship It!

- Abhinandan Prateek


On April 22, 2013, 9:02 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10700/
> ---
> 
> (Updated April 22, 2013, 9:02 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Murali Reddy.
> 
> 
> Description
> ---
> 
> added the secondary ip id entry uuid to response.
> 
> 
> This addresses bug CLOUDSTACK-1741.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/NetworkService.java 5a6054d 
>   api/src/org/apache/cloudstack/api/ResponseGenerator.java c0dd57e 
>   api/src/org/apache/cloudstack/api/command/user/vm/AddIpToVmNicCmd.java 
> df6b399 
>   api/test/org/apache/cloudstack/api/command/test/AddIpToVmNicTest.java 
> 106589d 
>   server/src/com/cloud/api/ApiResponseHelper.java 7629e5e 
>   server/src/com/cloud/network/NetworkServiceImpl.java 12c6068 
>   server/test/com/cloud/network/MockNetworkManagerImpl.java 6a0263e 
>   server/test/com/cloud/vpc/MockNetworkManagerImpl.java bfcccf5 
> 
> Diff: https://reviews.apache.org/r/10700/diff/
> 
> 
> Testing
> ---
> 
> 1. Acquired secondary ip to the nic.
> 2. Deleted it from the UI. Deletion is successful. 
> Earlier deleting the acquired ip failed when doing it after acquire without 
> navigating the pages. 
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Re: Review Request: Adding more Granular Global Parameters

[Abhinandan Prateek]

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


Can you resubmit the patch after changing scope_id/scope_name to zone_id, 
account_id, cluster_id etc .

- Abhinandan Prateek


On April 23, 2013, 9:29 p.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10740/
> ---
> 
> (Updated April 23, 2013, 9:29 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Kishan Kavala, and Nitin 
> Mehta.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-741: Granular Global Parameters
> Adding the zone, cluster, account level parameters:
> zone: network.throttling.rate, Guest Domain Prefix
> cluster: cluster.cpu.allocated.capacity.disablethreshold, 
> cluster.cpu.allocated.capacity.notificationthreshold, 
> cluster.memory.allocated.capacity.disablethreshold, 
> cluster.memory.allocated.capacity.notificationthreshold
> account:  allow.public.user.templates, remote.access.vpn.client.iprange  
> 
> 
> This addresses bug CLOUDSTACK-741.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/configuration/ConfigurationService.java 6937d0b 
>   api/src/com/cloud/network/NetworkModel.java 4d7d714 
>   api/src/org/apache/cloudstack/api/ApiConstants.java e774ecc 
>   api/src/org/apache/cloudstack/api/command/admin/config/ListCfgsByCmd.java 
> 9f34405 
>   api/src/org/apache/cloudstack/api/command/admin/config/UpdateCfgCmd.java 
> 074c5a3 
>   server/src/com/cloud/alert/AlertManagerImpl.java 655ed98 
>   server/src/com/cloud/api/ApiDBUtils.java c60af27 
>   server/src/com/cloud/api/ApiDispatcher.java 925d90a 
>   server/src/com/cloud/capacity/dao/CapacityDao.java 0132f69 
>   server/src/com/cloud/capacity/dao/CapacityDaoImpl.java c3d9817 
>   server/src/com/cloud/configuration/Config.java dbcbc53 
>   server/src/com/cloud/configuration/ConfigurationManager.java 738c5ba 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java d5e405d 
>   server/src/com/cloud/deploy/FirstFitPlanner.java 1647cf7 
>   server/src/com/cloud/network/NetworkManagerImpl.java 72ccac0 
>   server/src/com/cloud/network/NetworkModelImpl.java c5930d9 
>   server/src/com/cloud/network/vpc/VpcManagerImpl.java 224a680 
>   server/src/com/cloud/network/vpn/RemoteAccessVpnManagerImpl.java 673535a 
>   server/src/com/cloud/server/ConfigurationServerImpl.java cd890ce 
>   server/src/com/cloud/storage/dao/StoragePoolDetailsDaoImpl.java a0d5d0e 
>   server/src/com/cloud/template/TemplateAdapterBase.java 1b11425 
>   server/src/com/cloud/template/TemplateManagerImpl.java c7eaa64 
>   server/test/com/cloud/network/MockNetworkModelImpl.java 511249f 
>   server/test/com/cloud/vpc/MockConfigurationManagerImpl.java 6cda294 
>   server/test/com/cloud/vpc/MockNetworkModelImpl.java 9857964 
>   
> server/test/org/apache/cloudstack/affinity/AffinityApiTestConfiguration.java 
> fb29469 
>   
> server/test/org/apache/cloudstack/networkoffering/ChildTestConfiguration.java 
> f1163ef 
>   setup/db/db/schema-410to420.sql 10cdbba 
>   test/integration/smoke/test_global_settings.py 12b35d7 
> 
> Diff: https://reviews.apache.org/r/10740/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request: (CLOUDSTACK-1325) add password in response of RestoreVM

[Wei Zhou]

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

(Updated April 25, 2013, 10:18 a.m.)


Review request for cloudstack, Sateesh Chodapuneedi and Harikrishna Patnala.


Changes
---

add "_vmDao.loadDetails(vm);". 

Harikrishna, Thanks a lot.


Description
---

In 4.0.1, There is no password field in the respone of RestoreVM.
Please see https://issues.apache.org/jira/browse/CLOUDSTACK-1325

This patch add a new password in the response.


This addresses bug CLOUDSTACK-1325.


Diffs (updated)
-

  api/src/com/cloud/vm/UserVmService.java 6635657 
  server/src/com/cloud/vm/UserVmManagerImpl.java dbcbeb8 

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


Testing
---

Testing manually ok.

command=restoreVirtualMachine&response=json&virtualmachineid=1a53a308-c870-452a-9eff-23975919286b
 public $jobid =>
 string(36) "7e855ed2-b5ab-4449-a163-5c1af62019ab"

command=queryAsyncJobResult&response=json&jobid=7e855ed2-b5ab-4449-a163-5c1af62019ab
 public $password =>
 string(9) "mD5qkzmdk"


Thanks,

Wei Zhou

Review Request: updated cloud-early-config to copy iptables-* config files to rules file to work old templates

[Jayapal Reddy]

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

Review request for cloudstack, Abhinandan Prateek, edison su, Chiradeep Vittal, 
Rohit Yadav, and anthony xu.


Description
---

Updated the cloud early config also to copy the /etc/iptables/iptables-router 
(iptables-*) to /etc/iptables/rules.


This addresses bug CLOUDSTACK-2161.


Diffs
-

  patches/systemvm/debian/config/etc/init.d/cloud-early-config 187ae25 

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


Testing
---

Tested by copying cloud-early-config to router with old template.


Thanks,

Jayapal Reddy

Re: Error starting management server

[Dharmesh Kakadia]

Hi,

I was able to only run management server. Now stuck at step-8. I tried
running it both way (mvn and python).

Traceback (most recent call last):
  File "../marvin/marvin/deployDataCenter.py", line 469, in 
deploy.deploy()
  File "../marvin/marvin/deployDataCenter.py", line 452, in deploy
self.loadCfg()
  File "../marvin/marvin/deployDataCenter.py", line 409, in loadCfg
apiKey, securityKey = self.registerApiKey()
  File "../marvin/marvin/deployDataCenter.py", line 349, in registerApiKey
listuserRes = self.testClient.getApiClient().listUsers(listuser)
  File
"/Users/GreatGod/cloudstack/cloudstack/tools/marvin/marvin/cloudstackAPI/cloudstackAPIClient.py",
line 436, in listUsers
response = self.connection.marvin_request(command,
response_type=response, method=method)
  File
"/Users/GreatGod/cloudstack/cloudstack/tools/marvin/marvin/cloudstackConnection.py",
line 208, in marvin_request
response = jsonHelper.getResultObj(response.json(), response_type)
  File "/Library/Python/2.7/site-packages/requests/models.py", line 638, in
json
return json.loads(self.text or self.content, **kwargs)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/__init__.py",
line 326, in loads
return _default_decoder.decode(s)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/decoder.py",
line 360, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/decoder.py",
line 378, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded


I am using python2.7 and have version 2.6 installed on system.

Also, I need help in using the management UI with devcloud. I am newbie and
guessed most of the values, but I am not able to add devcloud host
(192.168.56.10). Any pointers ?

Thanks,
Dharmesh


On Thu, Apr 25, 2013 at 12:36 PM, Dharmesh Kakadia wrote:

> Hi,
>
> Thanks. That was exactly what I was missing. Running now !!
>
> Thanks,
> Dharmesh
>
>
> On Thu, Apr 25, 2013 at 10:34 AM, Prasanna Santhanam wrote:
>
>> On Wed, Apr 24, 2013 at 11:07:38PM +0530, Dharmesh Kakadia wrote:
>> > Hi,
>> >
>> > I am setting up dev environment following :
>> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/DevCloud
>>
>> Dev environment specifics are here:
>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Setting+up+CloudStack+Development+Environment
>>
>> If you are using master branch for building:
>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+on+master+branch
>>
>> You might want to give more memory as shown in the wiki:
>> export MAVEN_OPTS="-XX:MaxPermSize=512m -Xmx2g -Xdebug
>> -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"
>>
>> The supported tomcat version is 6.0.33. So you might want to downgrade
>> and setup your CATALINA_HOME to point to the correct tomcat install.
>>
>> --
>> Prasanna.,
>>
>> >
>> > I am stuck on step 7.3 while starting the management server.
>> >
>> > the output of
>> >
>> > mvn -pl :cloud-client-ui jetty:run
>> >
>> > gets stuck after
>> >
>> > INFO  [utils.component.ComponentContext] (main:) Setup Spring
>> Application
>> > context
>> >
>> > I tried starting client-ui manually by copying the cloud-client-ui war
>> file
>> > into tomcat.
>> >
>> > Interestingly the log says
>> >
>> > SEVERE: Error listenerStart
>> > Apr 24, 2013 6:32:38 PM org.apache.catalina.core.StandardContext start
>> > SEVERE: Context [/cloud-client-ui-4.2.0-SNAPSHOT] startup failed due to
>> > previous errors
>> > Apr 24, 2013 6:32:38 PM org.apache.catalina.loader.WebappClassLoader
>> > clearReferencesThreads
>> > SEVERE: The web application [/cloud-client-ui-4.2.0-SNAPSHOT] appears to
>> > have started a thread named [Timer-0] but has failed to stop it. This is
>> > very likely to create a memory leak.
>> > Apr 24, 2013 6:32:38 PM org.apache.catalina.loader.WebappClassLoader
>> > clearReferencesThreads
>> > SEVERE: The web application [/cloud-client-ui-4.2.0-SNAPSHOT] appears to
>> > have started a thread named [ClusteredAgentManager Timer] but has
>> failed to
>> > stop it. This is very likely to create a memory leak.
>> > Apr 24, 2013 6:32:38 PM org.apache.catalina.loader.WebappClassLoader
>> > checkThreadLocalMapForLeaks
>> > SEVERE: The web application [/cloud-client-ui-4.2.0-SNAPSHOT] created a
>> > ThreadLocal with key of type [java.lang.ThreadLocal] (value
>> > [java.lang.ThreadLocal@3a7d1a7a]) and a value of type
>> > [com.cloud.utils.db.Transaction] (value [ : ]) but failed to remove it
>> when
>> > the web application was stopped. This is very likely to create a memory
>> > leak.
>> >
>> > I am running this on Mac OS with tomcat apache-tomcat-6.0.36 and java
>> > 1.6.0_45 and maven 3.0.3.
>> >
>> > Any help ?
>> >
>> > Thanks,
>> > Dharmesh
>>
>>
>> 
>> Powered by BigRock.com
>>
>>
>

Re: Error starting management server

[Dharmesh Kakadia]

Sorry. Understood now that the step-8 above will do add
datacenter/pod/cluster/host etc. Need help only in step-8.


On Thu, Apr 25, 2013 at 6:04 PM, Dharmesh Kakadia wrote:

> Hi,
>
> I was able to only run management server. Now stuck at step-8. I tried
> running it both way (mvn and python).
>
> Traceback (most recent call last):
>   File "../marvin/marvin/deployDataCenter.py", line 469, in 
> deploy.deploy()
>   File "../marvin/marvin/deployDataCenter.py", line 452, in deploy
> self.loadCfg()
>   File "../marvin/marvin/deployDataCenter.py", line 409, in loadCfg
> apiKey, securityKey = self.registerApiKey()
>   File "../marvin/marvin/deployDataCenter.py", line 349, in registerApiKey
> listuserRes = self.testClient.getApiClient().listUsers(listuser)
>   File
> "/Users/GreatGod/cloudstack/cloudstack/tools/marvin/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 436, in listUsers
> response = self.connection.marvin_request(command,
> response_type=response, method=method)
>   File
> "/Users/GreatGod/cloudstack/cloudstack/tools/marvin/marvin/cloudstackConnection.py",
> line 208, in marvin_request
> response = jsonHelper.getResultObj(response.json(), response_type)
>   File "/Library/Python/2.7/site-packages/requests/models.py", line 638,
> in json
> return json.loads(self.text or self.content, **kwargs)
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/__init__.py",
> line 326, in loads
> return _default_decoder.decode(s)
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/decoder.py",
> line 360, in decode
> obj, end = self.raw_decode(s, idx=_w(s, 0).end())
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/decoder.py",
> line 378, in raw_decode
> raise ValueError("No JSON object could be decoded")
> ValueError: No JSON object could be decoded
>
>
> I am using python2.7 and have version 2.6 installed on system.
>
> Also, I need help in using the management UI with devcloud. I am newbie
> and guessed most of the values, but I am not able to add devcloud host
> (192.168.56.10). Any pointers ?
>
> Thanks,
> Dharmesh
>
>
> On Thu, Apr 25, 2013 at 12:36 PM, Dharmesh Kakadia wrote:
>
>> Hi,
>>
>> Thanks. That was exactly what I was missing. Running now !!
>>
>>  Thanks,
>> Dharmesh
>>
>>
>> On Thu, Apr 25, 2013 at 10:34 AM, Prasanna Santhanam wrote:
>>
>>> On Wed, Apr 24, 2013 at 11:07:38PM +0530, Dharmesh Kakadia wrote:
>>> > Hi,
>>> >
>>> > I am setting up dev environment following :
>>> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/DevCloud
>>>
>>> Dev environment specifics are here:
>>>
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Setting+up+CloudStack+Development+Environment
>>>
>>> If you are using master branch for building:
>>>
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+on+master+branch
>>>
>>> You might want to give more memory as shown in the wiki:
>>> export MAVEN_OPTS="-XX:MaxPermSize=512m -Xmx2g -Xdebug
>>> -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"
>>>
>>> The supported tomcat version is 6.0.33. So you might want to downgrade
>>> and setup your CATALINA_HOME to point to the correct tomcat install.
>>>
>>> --
>>> Prasanna.,
>>>
>>> >
>>> > I am stuck on step 7.3 while starting the management server.
>>> >
>>> > the output of
>>> >
>>> > mvn -pl :cloud-client-ui jetty:run
>>> >
>>> > gets stuck after
>>> >
>>> > INFO  [utils.component.ComponentContext] (main:) Setup Spring
>>> Application
>>> > context
>>> >
>>> > I tried starting client-ui manually by copying the cloud-client-ui war
>>> file
>>> > into tomcat.
>>> >
>>> > Interestingly the log says
>>> >
>>> > SEVERE: Error listenerStart
>>> > Apr 24, 2013 6:32:38 PM org.apache.catalina.core.StandardContext start
>>> > SEVERE: Context [/cloud-client-ui-4.2.0-SNAPSHOT] startup failed due to
>>> > previous errors
>>> > Apr 24, 2013 6:32:38 PM org.apache.catalina.loader.WebappClassLoader
>>> > clearReferencesThreads
>>> > SEVERE: The web application [/cloud-client-ui-4.2.0-SNAPSHOT] appears
>>> to
>>> > have started a thread named [Timer-0] but has failed to stop it. This
>>> is
>>> > very likely to create a memory leak.
>>> > Apr 24, 2013 6:32:38 PM org.apache.catalina.loader.WebappClassLoader
>>> > clearReferencesThreads
>>> > SEVERE: The web application [/cloud-client-ui-4.2.0-SNAPSHOT] appears
>>> to
>>> > have started a thread named [ClusteredAgentManager Timer] but has
>>> failed to
>>> > stop it. This is very likely to create a memory leak.
>>> > Apr 24, 2013 6:32:38 PM org.apache.catalina.loader.WebappClassLoader
>>> > checkThreadLocalMapForLeaks
>>> > SEVERE: The web application [/cloud-client-ui-4.2.0-SNAPSHOT] created a
>>> > ThreadLocal with key of type [java.lang.ThreadLocal] (value
>>> > [java.lang.ThreadLocal@3a7d1a7a]) and a value of type
>>> > [com.cloud.utils.db.Transaction] (value [ : ]) but failed to remove i

RE: https://issues.apache.org/jira/browse/CLOUDSTACK-101 OVS support in KVM

[Hugo Trippaers]

Heya,

Comments inline.

I ran through the entire procedure I use to test the setup and documented it as 
detailed as possible. Hope this helps:

#
# CentOS KVM installation
#

Base installation: 
CentOS 6.2 Basic Server 

Upgraded to CentOS 6.4:
# yum update

Install Virtualization tools
# yum groupinstall Virtualization "Virtualization Client" 
"Virtualization Platform" "Virtualization Tools"

Verify Installed:
  hypervkvpd.x86_64 0:0-0.9.el6libguestfs.x86_64 
1:1.16.34-2.el6  libvirt.x86_64 0:0.10.2-18.el6_4.3
  libvirt-client.x86_64 0:0.10.2-18.el6_4.3python-virtinst.noarch 
0:0.600.0-15.el6qemu-kvm.x86_64 2:0.12.1.2-2.355.0.1.el6.centos.2
  virt-manager.x86_64 0:0.9.0-18.el6   virt-top.x86_64 
0:1.0.4-3.15.el6   virt-viewer.x86_64 0:0.5.2-18.el6_4.2
  
Modify libvirt configuration:
Edit /etc/libvirt/libvirtd.conf
listen_tls = 0
listen_tcp = 1
tcp_port = 16059
auth_tcp = "none"
mdns_adv = 0

Edit /etc/sysconfig/libvirtd
LIBVIRTD_ARGS="--listen"
  
Start libvirtd
   # /etc/init.d/libvirtd start
   # /etc/init.d/libvirtd status

Verify installation:
  # virsh capabilities 
  - Should list two guest tags with os_type hvm
  
Build and install openvswitch:
  Install build requirements:
 # yum install rpmdevtools openssl-devel kernel-devel gcc redhat-rpm-config
 
  Build packages:
 # mkdir -p ~/rpmbuild/SOURCES
 # curl -O http://openvswitch.org/releases/openvswitch-1.9.0.tar.gz
 # cp openvswitch-1.9.0.tar.gz ~/rpmbuild/SOURCES
 # cp centos64-openvswitch.patch ~/rpmbuild/SOURCES
 # tar -xzf openvswitch-1.9.0.tar.gz
 # cd openvswitch-1.9.0
 # patch -p1 < ~/rpmbuild/SOURCES/centos64-openvswitch.patch
 # rpmbuild -bb rhel/openvswitch.spec
 # rpmbuild -bb -D "kversion `uname -r`" 
rhel/openvswitch-kmod-rhel6.spec
 
  Install openvswitch:
# yum install 
~/rpmbuild/RPMS/x86_64/kmod-openvswitch-1.9.0-1.el6.x86_64.rpm 
~/rpmbuild/RPMS/x86_64/openvswitch-1.9.0-1.x86_64.rpm
# echo 'blacklist bridge' >> /etc/modprobe.d/blacklist.conf
# reboot

  Verify installation:
# lsmod |grep openvswitch
# ovs-vsctl -V

Network design:
  cloudbr0 (Management, Storage)
ip: 172.16.10.10/24
gateway: 172.16.10.1
eth0 (physical port, no vlans)
  cloudbr1 (Guest, Public)
eth1 (physical port, vlan trunk)
ip: none

Configure network interfaces:
   /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
IPV6INIT=no
NM_CONTROLLED=no
ONBOOT=yes
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=cloudbr0

   /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
IPV6INIT=no
NM_CONTROLLED=no
ONBOOT=yes
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=cloudbr1

   /etc/sysconfig/network-scripts/ifcfg-cloudbr0
DEVICE=cloudbr0
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
IPADDR=172.16.10.10
GATEWAY=172.16.10.1
NETMASK=255.255.255.0
HOTPLUG=no

   /etc/sysconfig/network-scripts/ifcfg-cloudbr1
DEVICE=cloudbr1
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=none
HOTPLUG=no

   /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=testkvm1
GATEWAY=172.10.10.1

Install cloudstack-agent:
# yum install cloudstack-agent

Edit /etc/cloudstack/agent/agent.properties
network.bridge.type=openvswitch
libvirt.vif.driver=com.cloud.hypervisor.kvm.resource.OvsVifDriver

Now add the host to cloudstack.


  
  centos64-openvswitch.patch =  
diff -ru 
openvswitch-1.9.0-clean/datapath/linux/compat/include/linux/etherdevice.h 
openvswitch-1.9.0/datapath/linux/compat/include/linux/etherdevice.h
--- openvswitch-1.9.0-clean/datapath/linux/compat/include/linux/etherdevice.h   
2013-02-26 21:25:37.0 +0100
+++ openvswitch-1.9.0/datapath/linux/compat/include/linux/etherdevice.h 
2013-04-25 10:45:09.942027933 +0200
@@ -4,16 +4,4 @@
 #include 
 #include_next 

-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,36)
-static inline void eth_hw_addr_random(struct net_device *dev)
-{
-   random_ether_addr(dev->dev_addr);
-}
-#elif LINUX_VERSION_CODE < KERNEL_VERSION(3,4,0)
-static inline void eth_hw_addr_random(struct net_device *dev)
-{
-   dev_hw_addr_random(dev, dev->dev_addr);
-}
-#endif
-
 #endif
diff -ru openvswitch-1.9.0-clean/datapath/linux/compat/include/linux/if_vlan.h 
openvswitch-1.9.0/datapath/linux/compat/include/linux/if_vlan.h
--- openvswitch-1.9.0-clean/datapath/linux/compat/include/linux/if_vlan.h   
2013-02-26 21:25:37.

Re: [ACS41][Patch Request]

[Chip Childers]

On Wed, Apr 24, 2013 at 03:24:20PM -0600, Marcus Sorensen wrote:
> https://reviews.apache.org/r/10766/

I'm unclear about the current state of this review request.  There is
the actual patch for the review [1] and an attached patch [2].

Which should be applied?

-chip

[1] https://reviews.apache.org/r/10766/diff/raw/
[2] 
https://reviews.apache.org/media/uploaded/files/2013/04/25/patch-fix-ha-primary-only

Re: [DOCS] Please Review - Releasing Publican Documentation from Apache CloudStack

[Chip Childers]

On Wed, Apr 24, 2013 at 06:20:38PM -0500, Joe Brockmeier wrote:
> While releasing the documentation today I went ahead and wrote up a
> draft on the wiki so that anyone can do this in the future. Please have
> a look and suggest changes (or make them yourself, it's a wiki!) 
> 
> https://cwiki.apache.org/CLOUDSTACK/releasing-docs.html

Thanks Joe...  

What was the part that got you stuck yesterday?  I noticed some buildbot
errors were sent to the commit list.

Re: Review Request: Don't do KVM heartbeat on secondary storage sources, primary only

[Marcus Sorensen]

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

(Updated April 25, 2013, 1:28 p.m.)


Review request for cloudstack and Chip Childers.


Changes
---

removing attachment


Description
---

the KVM HA runner uses any NFS secondary storage resource available to a host 
to store it's HA data. This causes template deletes to fail because it cannot 
delete KVMHA, which is a directory that is not empty. So if KVMHA directory is 
found, delete it's contents before trying to delete it.


This addresses bug CLOUDSTACK-2173.


Diffs
-

  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/KVMHAMonitor.java 
d1470d6 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStoragePoolManager.java
 c2bfad9 

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


Testing
---

diff revision 2 was tested with a new 4.1 zone deployment. Verified bug was 
reproducable with 4.1 HEAD, applied patch, ran through adding two NFS primary 
storages, verified KVM heartbeat was working on them, then ran various 
secondary storage operations (register template, download volume, take 
snapshot) and verified that they worked, and that KVM heartbeat operations were 
NOT acting on them.


Thanks,

Marcus Sorensen

Re: error while building Apache Whirr

[Chip Childers]

On Wed, Apr 24, 2013 at 04:37:08PM -0400, Han,Meng wrote:
> Hi,
> 
> Does anyone encounter the following error when building Whirr?

Wrong list?

Re: [ACS41][Patch Request]

[Marcus Sorensen]

Sorry, I attached the patch rather than updating the review diff because it
was just a quick idea and I wanted to get some feedback on it. After
working a bit more, I came up with a better solution based on that idea and
updated the diff with it.


On Thu, Apr 25, 2013 at 7:25 AM, Chip Childers wrote:

> On Wed, Apr 24, 2013 at 03:24:20PM -0600, Marcus Sorensen wrote:
> > https://reviews.apache.org/r/10766/
>
> I'm unclear about the current state of this review request.  There is
> the actual patch for the review [1] and an attached patch [2].
>
> Which should be applied?
>
> -chip
>
> [1] https://reviews.apache.org/r/10766/diff/raw/
> [2]
> https://reviews.apache.org/media/uploaded/files/2013/04/25/patch-fix-ha-primary-only
>

Re: [ACS41][Patch Request]

[Chip Childers]

On Thu, Apr 25, 2013 at 07:29:55AM -0600, Marcus Sorensen wrote:
> Sorry, I attached the patch rather than updating the review diff because it
> was just a quick idea and I wanted to get some feedback on it. After
> working a bit more, I came up with a better solution based on that idea and
> updated the diff with it.

OK, so I should apply what I see here:

https://reviews.apache.org/r/10766/diff/raw/

Just want to confirm...

> 
> 
> On Thu, Apr 25, 2013 at 7:25 AM, Chip Childers 
> wrote:
> 
> > On Wed, Apr 24, 2013 at 03:24:20PM -0600, Marcus Sorensen wrote:
> > > https://reviews.apache.org/r/10766/
> >
> > I'm unclear about the current state of this review request.  There is
> > the actual patch for the review [1] and an attached patch [2].
> >
> > Which should be applied?
> >
> > -chip
> >
> > [1] https://reviews.apache.org/r/10766/diff/raw/
> > [2]
> > https://reviews.apache.org/media/uploaded/files/2013/04/25/patch-fix-ha-primary-only
> >

Re: [ACS41][Patch Request]

[Marcus Sorensen]

yes


On Thu, Apr 25, 2013 at 7:31 AM, Chip Childers wrote:

> On Thu, Apr 25, 2013 at 07:29:55AM -0600, Marcus Sorensen wrote:
> > Sorry, I attached the patch rather than updating the review diff because
> it
> > was just a quick idea and I wanted to get some feedback on it. After
> > working a bit more, I came up with a better solution based on that idea
> and
> > updated the diff with it.
>
> OK, so I should apply what I see here:
>
> https://reviews.apache.org/r/10766/diff/raw/
>
> Just want to confirm...
>
> >
> >
> > On Thu, Apr 25, 2013 at 7:25 AM, Chip Childers <
> chip.child...@sungard.com>wrote:
> >
> > > On Wed, Apr 24, 2013 at 03:24:20PM -0600, Marcus Sorensen wrote:
> > > > https://reviews.apache.org/r/10766/
> > >
> > > I'm unclear about the current state of this review request.  There is
> > > the actual patch for the review [1] and an attached patch [2].
> > >
> > > Which should be applied?
> > >
> > > -chip
> > >
> > > [1] https://reviews.apache.org/r/10766/diff/raw/
> > > [2]
> > >
> https://reviews.apache.org/media/uploaded/files/2013/04/25/patch-fix-ha-primary-only
> > >
>

Re: [ACS41][Patch Request]

[Marcus Sorensen]

Sorry, I should have mentioned in my first response that I had just removed
the attachment from the review request. That would have clarified things.


On Thu, Apr 25, 2013 at 7:32 AM, Marcus Sorensen wrote:

> yes
>
>
> On Thu, Apr 25, 2013 at 7:31 AM, Chip Childers 
> wrote:
>
>> On Thu, Apr 25, 2013 at 07:29:55AM -0600, Marcus Sorensen wrote:
>> > Sorry, I attached the patch rather than updating the review diff
>> because it
>> > was just a quick idea and I wanted to get some feedback on it. After
>> > working a bit more, I came up with a better solution based on that idea
>> and
>> > updated the diff with it.
>>
>> OK, so I should apply what I see here:
>>
>> https://reviews.apache.org/r/10766/diff/raw/
>>
>> Just want to confirm...
>>
>> >
>> >
>> > On Thu, Apr 25, 2013 at 7:25 AM, Chip Childers <
>> chip.child...@sungard.com>wrote:
>> >
>> > > On Wed, Apr 24, 2013 at 03:24:20PM -0600, Marcus Sorensen wrote:
>> > > > https://reviews.apache.org/r/10766/
>> > >
>> > > I'm unclear about the current state of this review request.  There is
>> > > the actual patch for the review [1] and an attached patch [2].
>> > >
>> > > Which should be applied?
>> > >
>> > > -chip
>> > >
>> > > [1] https://reviews.apache.org/r/10766/diff/raw/
>> > > [2]
>> > >
>> https://reviews.apache.org/media/uploaded/files/2013/04/25/patch-fix-ha-primary-only
>> > >
>>
>
>

Re: Review Request: Don't do KVM heartbeat on secondary storage sources, primary only

[Chip Childers]

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

Ship it!


Ship It!

- Chip Childers


On April 25, 2013, 1:28 p.m., Marcus Sorensen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10766/
> ---
> 
> (Updated April 25, 2013, 1:28 p.m.)
> 
> 
> Review request for cloudstack and Chip Childers.
> 
> 
> Description
> ---
> 
> the KVM HA runner uses any NFS secondary storage resource available to a host 
> to store it's HA data. This causes template deletes to fail because it cannot 
> delete KVMHA, which is a directory that is not empty. So if KVMHA directory 
> is found, delete it's contents before trying to delete it.
> 
> 
> This addresses bug CLOUDSTACK-2173.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/KVMHAMonitor.java
>  d1470d6 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStoragePoolManager.java
>  c2bfad9 
> 
> Diff: https://reviews.apache.org/r/10766/diff/
> 
> 
> Testing
> ---
> 
> diff revision 2 was tested with a new 4.1 zone deployment. Verified bug was 
> reproducable with 4.1 HEAD, applied patch, ran through adding two NFS primary 
> storages, verified KVM heartbeat was working on them, then ran various 
> secondary storage operations (register template, download volume, take 
> snapshot) and verified that they worked, and that KVM heartbeat operations 
> were NOT acting on them.
> 
> 
> Thanks,
> 
> Marcus Sorensen
> 
>

Re: [DOCS] Please Review - Releasing Publican Documentation from Apache CloudStack

[Joe Brockmeier]

On Thu, Apr 25, 2013, at 08:27 AM, Chip Childers wrote:
> On Wed, Apr 24, 2013 at 06:20:38PM -0500, Joe Brockmeier wrote:
> > While releasing the documentation today I went ahead and wrote up a
> > draft on the wiki so that anyone can do this in the future. Please have
> > a look and suggest changes (or make them yourself, it's a wiki!) 
> > 
> > https://cwiki.apache.org/CLOUDSTACK/releasing-docs.html
> 
> Thanks Joe...  
> 
> What was the part that got you stuck yesterday?  I noticed some buildbot
> errors were sent to the commit list.

Damn, you want me to spell out *in public* how I futzed it up? :-)

The actual error was trying an 'svn remove' and then 'svn copy' when
moving the new docs over to the content/docs directory. Instead, it's
better to just copy over the new files using regular *nix cp and svn add
the new files. 

It seemed to get "stuck" on the order of removing/adding files, saying
it couldn't add a file to a location it was removing. I backed it out by
reverting the commits (which svn doesn't make nearly as easy, I'm
writing up a post on this today...) and then redoing everything, then
committing again. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [ACS41][Patch Request]

[Chip Childers]

On Thu, Apr 25, 2013 at 07:33:43AM -0600, Marcus Sorensen wrote:
> Sorry, I should have mentioned in my first response that I had just removed
> the attachment from the review request. That would have clarified things.
> 

Done!

> 
> On Thu, Apr 25, 2013 at 7:32 AM, Marcus Sorensen wrote:
> 
> > yes
> >
> >
> > On Thu, Apr 25, 2013 at 7:31 AM, Chip Childers 
> > wrote:
> >
> >> On Thu, Apr 25, 2013 at 07:29:55AM -0600, Marcus Sorensen wrote:
> >> > Sorry, I attached the patch rather than updating the review diff
> >> because it
> >> > was just a quick idea and I wanted to get some feedback on it. After
> >> > working a bit more, I came up with a better solution based on that idea
> >> and
> >> > updated the diff with it.
> >>
> >> OK, so I should apply what I see here:
> >>
> >> https://reviews.apache.org/r/10766/diff/raw/
> >>
> >> Just want to confirm...
> >>
> >> >
> >> >
> >> > On Thu, Apr 25, 2013 at 7:25 AM, Chip Childers <
> >> chip.child...@sungard.com>wrote:
> >> >
> >> > > On Wed, Apr 24, 2013 at 03:24:20PM -0600, Marcus Sorensen wrote:
> >> > > > https://reviews.apache.org/r/10766/
> >> > >
> >> > > I'm unclear about the current state of this review request.  There is
> >> > > the actual patch for the review [1] and an attached patch [2].
> >> > >
> >> > > Which should be applied?
> >> > >
> >> > > -chip
> >> > >
> >> > > [1] https://reviews.apache.org/r/10766/diff/raw/
> >> > > [2]
> >> > >
> >> https://reviews.apache.org/media/uploaded/files/2013/04/25/patch-fix-ha-primary-only
> >> > >
> >>
> >
> >

[ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Chip Childers]

Hi all,

The following bugs are currently blocking me from starting another 4.1.0
voting round.  Help please!

CLOUDSTACK-2158 'userconcentratedpod_firstfit failed to find alternate host to 
run VM   (Unassigned)
CLOUDSTACK-2172 Upgrade from 2.2.14 to 4.1.0 failed (Unassigned)
CLOUDSTACK-2190 DEB packaging does not package AWSAPI correctly (Chip Childers)
CLOUDSTACK-2126 Response objects of some entities contain job related 
information   (Unassigned)

I'll try to figure out CLOUDSTACK-2190.  The other three are currently 
unassigned.  If you can help resolve them, please step up!

-chip

Re: [DOCS] Please Review - Releasing Publican Documentation from Apache CloudStack

[Chip Childers]

On Thu, Apr 25, 2013 at 08:50:29AM -0500, Joe Brockmeier wrote:
> On Thu, Apr 25, 2013, at 08:27 AM, Chip Childers wrote:
> > On Wed, Apr 24, 2013 at 06:20:38PM -0500, Joe Brockmeier wrote:
> > > While releasing the documentation today I went ahead and wrote up a
> > > draft on the wiki so that anyone can do this in the future. Please have
> > > a look and suggest changes (or make them yourself, it's a wiki!) 
> > > 
> > > https://cwiki.apache.org/CLOUDSTACK/releasing-docs.html
> > 
> > Thanks Joe...  
> > 
> > What was the part that got you stuck yesterday?  I noticed some buildbot
> > errors were sent to the commit list.
> 
> Damn, you want me to spell out *in public* how I futzed it up? :-)

PEBKAC errors are useful for others to know about... ;-)

> 
> The actual error was trying an 'svn remove' and then 'svn copy' when
> moving the new docs over to the content/docs directory. Instead, it's
> better to just copy over the new files using regular *nix cp and svn add
> the new files. 
> 
> It seemed to get "stuck" on the order of removing/adding files, saying
> it couldn't add a file to a location it was removing. I backed it out by
> reverting the commits (which svn doesn't make nearly as easy, I'm
> writing up a post on this today...) and then redoing everything, then
> committing again. 

Interesting..  Thanks Joe!

Re: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Sebastien Goasguen]

On Apr 25, 2013, at 9:54 AM, Chip Childers  wrote:

> Hi all,
> 
> The following bugs are currently blocking me from starting another 4.1.0
> voting round.  Help please!
> 
> CLOUDSTACK-2158 'userconcentratedpod_firstfit failed to find alternate host 
> to run VM   (Unassigned)
> CLOUDSTACK-2172 Upgrade from 2.2.14 to 4.1.0 failed (Unassigned)

l_a_m on IRC raised that one. He is on Debian with vmware hypervisor.
They are not able to upgrade at all.
He is also stuck with CLOUDSTACK-528

-sebastien

> CLOUDSTACK-2190 DEB packaging does not package AWSAPI correctly (Chip 
> Childers)
> CLOUDSTACK-2126 Response objects of some entities contain job related 
> information   (Unassigned)
> 
> I'll try to figure out CLOUDSTACK-2190.  The other three are currently 
> unassigned.  If you can help resolve them, please step up!
> 
> -chip

Re: error while building Apache Whirr

[Sebastien Goasguen]

Hi Meng,

 I believe you are asking this in the context of the Google Summer of Code.
Please put [GSOC] at the start of your subject line, that way we can filter 
your question.

That said Chip is partially right (in that it's a Whirr question but for a 
Cloudstack project :) ) and you should send the question to the Whirr list.

-Sebastien

On Apr 25, 2013, at 9:28 AM, Chip Childers  wrote:

> On Wed, Apr 24, 2013 at 04:37:08PM -0400, Han,Meng wrote:
>> Hi,
>> 
>> Does anyone encounter the following error when building Whirr?
> 
> Wrong list?

Re: error while building Apache Whirr

[Chip Childers]

On Thu, Apr 25, 2013 at 10:03:03AM -0400, Sebastien Goasguen wrote:
> Hi Meng,
> 
>  I believe you are asking this in the context of the Google Summer of Code.
> Please put [GSOC] at the start of your subject line, that way we can filter 
> your question.

Ah!  I see the context now.  Yes, GSOC in the header or email subject
would be useful.

> 
> That said Chip is partially right (in that it's a Whirr question but for a 
> Cloudstack project :) ) and you should send the question to the Whirr list.
> 

Yup, we can't help with that here really.

> -Sebastien
> 
> On Apr 25, 2013, at 9:28 AM, Chip Childers  wrote:
> 
> > On Wed, Apr 24, 2013 at 04:37:08PM -0400, Han,Meng wrote:
> >> Hi,
> >> 
> >> Does anyone encounter the following error when building Whirr?
> > 
> > Wrong list?
> 
> 

Review Request: CLOUDSTACK-2191: Added the following to tests to qualify "Optional Public IP" changes happend in EIP enabled Zone

[venkata swamy babu budumuru]

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

Review request for cloudstack, Prasanna Santhanam, SrikanteswaraRao Talluri, 
and Girish Shilamkar.


Description
---

CLOUDSTACK-2191: Added the following to tests to qualify "Optional Public 
IP" changes happend in EIP enabled Zone
1. Verify that the EIP zone is created with "AssociatePublicIp" capability 
set to "false"
2. Verify that VM doesn't get public ip by default after 
deployVirtualMachine
3. Eanble static NAT and verify EIP semantics
4. disable static NAT and verify EIP semantics


This addresses bug CLOUDSTACK-2191.


Diffs
-

  test/integration/component/test_eip_optional_publicip.py PRE-CREATION 

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


Testing
---

Encountered few bugs while doing pilot run of the suite hence, couldn't test it 
completely.

Bugs encountered during the run are :


Thanks,

venkata swamy babu  budumuru

Re: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Prasanna Santhanam]

On Thu, Apr 25, 2013 at 10:01:11AM -0400, Sebastien Goasguen wrote:
> 
> On Apr 25, 2013, at 9:54 AM, Chip Childers  wrote:
> 
> > Hi all,
> > 
> > The following bugs are currently blocking me from starting another 4.1.0
> > voting round.  Help please!
> > 
> > CLOUDSTACK-2158 'userconcentratedpod_firstfit failed to find alternate host 
> > to run VM   (Unassigned)
> > CLOUDSTACK-2172 Upgrade from 2.2.14 to 4.1.0 failed (Unassigned)
> 
> l_a_m on IRC raised that one. He is on Debian with vmware hypervisor.
> They are not able to upgrade at all.
> He is also stuck with CLOUDSTACK-528
> 
I believe he also raised a patch request. It just needs someone to
review: https://reviews.apache.org/r/10773/

-- 
Prasanna.,


Powered by BigRock.com

Re: Review Request: FIX https://issues.apache.org/jira/browse/CLOUDSTACK-2172, by adding database upgrade to 4.1.0 in PremiumDatabaseUpgradeChecker.

[Chip Childers]

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

(Updated April 25, 2013, 2:14 p.m.)


Review request for cloudstack.


Description
---

Add migration to 4.1.0 in the PremiumDatabaseUpgradeChecker, like in the 
DatabaseUpgradeChecker.
I opened the ticket CS 2172, and this fix corrects the issue.
Regards.


This addresses bug CLOUDSTACK-2172.


Diffs
-

  server/src/com/cloud/upgrade/PremiumDatabaseUpgradeChecker.java 14a8143 

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


Testing
---


Thanks,

Nicolas Lamirault

Re: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Chip Childers]

On Thu, Apr 25, 2013 at 07:40:30PM +0530, Prasanna Santhanam wrote:
> On Thu, Apr 25, 2013 at 10:01:11AM -0400, Sebastien Goasguen wrote:
> > 
> > On Apr 25, 2013, at 9:54 AM, Chip Childers  
> > wrote:
> > 
> > > Hi all,
> > > 
> > > The following bugs are currently blocking me from starting another 4.1.0
> > > voting round.  Help please!
> > > 
> > > CLOUDSTACK-2158 'userconcentratedpod_firstfit failed to find alternate 
> > > host to run VM   (Unassigned)
> > > CLOUDSTACK-2172 Upgrade from 2.2.14 to 4.1.0 failed (Unassigned)
> > 
> > l_a_m on IRC raised that one. He is on Debian with vmware hypervisor.
> > They are not able to upgrade at all.
> > He is also stuck with CLOUDSTACK-528
> > 
> I believe he also raised a patch request. It just needs someone to
> review: https://reviews.apache.org/r/10773/

ACK - checking and applying now.  Thanks for catching that one Prasanna!

Re: Review Request: FIX https://issues.apache.org/jira/browse/CLOUDSTACK-2172, by adding database upgrade to 4.1.0 in PremiumDatabaseUpgradeChecker.

[ASF Subversion and Git Services]

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


Commit 41e6e9f30f035d9bd99d1aa3f4279ff748e8bcd4 in branch refs/heads/4.1 from 
Chip Childers 
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=41e6e9f ]

CLOUDSTACK-2172: adding database upgrade to 4.1.0 in 
PremiumDatabaseUpgradeChecker

Add migration to 4.1.0 in the PremiumDatabaseUpgradeChecker, like in the
DatabaseUpgradeChecker.

I opened the ticket CS 2172, and this fix corrects the issue.
Regards.

Signed-off-by: Chip Childers 


- ASF Subversion and Git Services


On April 25, 2013, 2:14 p.m., Nicolas Lamirault wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10773/
> ---
> 
> (Updated April 25, 2013, 2:14 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Description
> ---
> 
> Add migration to 4.1.0 in the PremiumDatabaseUpgradeChecker, like in the 
> DatabaseUpgradeChecker.
> I opened the ticket CS 2172, and this fix corrects the issue.
> Regards.
> 
> 
> This addresses bug CLOUDSTACK-2172.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/upgrade/PremiumDatabaseUpgradeChecker.java 14a8143 
> 
> Diff: https://reviews.apache.org/r/10773/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nicolas Lamirault
> 
>

Re: [DOCS] Please Review - Releasing Publican Documentation from Apache CloudStack

[Joe Brockmeier]

On Thu, Apr 25, 2013, at 08:55 AM, Chip Childers wrote:
> PEBKAC errors are useful for others to know about... ;-)

http://www.dissociatedpress.net/blog/2013/04/25/reverting-an-svn-commit/

There ya go. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Xen Hackathon Dublin May 16/17th

[Sebastien Goasguen]

Folks,

The Xen hackathon is being held in Dublin, Ireland on May 16/17th.

Is anyone interested to go there and actually work on improving Xen/XCP support 
in CloudStack ?

-Sebastien

RE: [Discuss] ACL deny rules

[Kishan Kavala]

There was a discussion regarding API name alias [1]. After adding API name 
alias, we still need to have different response tags for backward 
compatibility. 
New: ..
Old: ..

If we are to use the same API, networkId and aclId both have to be made 
optional. Would it better to have new API createNetworkACLItem instead and 
deprecate createNetworkACL gradually? 

[1] 
http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201304.mbox/%3ccd92e986.17651%25nitin.me...@citrix.com%3E

> -Original Message-
> From: Chiradeep Vittal
> Sent: Wednesday, 3 April 2013 1:08 AM
> To: Kishan Kavala; dev@cloudstack.apache.org; Chandan Purushothama
> Subject: Re: Question pertaining to the Support of ACL deny rules
> 
> 
> 
> On 4/2/13 6:46 AM, "Kishan Kavala"  wrote:
> > To implement API alias, APICommand annotation needs to be changed to
> >support multiple API names for the same Cmd object.
> 
> Can you call this out in a separate DISCUSS ?
> 
> >
> >> * createNetwork - I like this idea of being able to specify at
> >>creation time, but  it should fail if the ACL service is not present
> >[KK] ACL service will always be present in VPC case. We do not support
> >ACL container in non-vpc case.
> 
> But this can change.
> 
> >
> >> * listNetworkAclContainers - listAPIs usually have filters as
> >>parameters.
> >> You are proposing two filters -- by ACLList Id and network id. I
> >>could easily  see filtering by list of network ids, by vpc id, those
> >>that contain a particular  ACLItem, etc. At the very least can we
> >>rewrite the API that takes a filter as an  input ? How do I know which
> >>ACLList is the default one?
> >[KK] I'll add additional filters- byNetworkIds, byVpcId. Each ACLList
> >will have flag indicating default true/false.
> 
> Is there a standard filter syntax for this?
> 
> >
> >> * Scripts - do you propose deleting and re-creating the entire chain
> >>when you  update a rule? Or do you plan to surgically move around the
> >>rules as the  ordering changes?
> >[KK] Planning on deleting and re-creating all the rules.
> >
> >> * what are the contents of the default ACLList?
> >[KK] default ACLList will contain deny all rule.
> 
> Can you update the spec with the default ACL list?
> 
> Thanks
> --
> Chiradeep

Re: Review Request: CLOUDSTACK-2191: Added the following to tests to qualify "Optional Public IP" changes happend in EIP enabled Zone

[venkata swamy babu budumuru]

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

(Updated April 25, 2013, 2:40 p.m.)


Review request for cloudstack, Prasanna Santhanam, SrikanteswaraRao Talluri, 
and Girish Shilamkar.


Changes
---

Forgot to add the newly encountered bugs. added them under the testing done 
category


Description
---

CLOUDSTACK-2191: Added the following to tests to qualify "Optional Public 
IP" changes happend in EIP enabled Zone
1. Verify that the EIP zone is created with "AssociatePublicIp" capability 
set to "false"
2. Verify that VM doesn't get public ip by default after 
deployVirtualMachine
3. Eanble static NAT and verify EIP semantics
4. disable static NAT and verify EIP semantics


This addresses bug CLOUDSTACK-2191.


Diffs
-

  test/integration/component/test_eip_optional_publicip.py PRE-CREATION 

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


Testing (updated)
---

Encountered few bugs while doing pilot run of the suite hence, couldn't test it 
completely.

Bugs encountered during the run are :

CLOUDSTACK-2193 https://issues.apache.org/jira/browse/CLOUDSTACK-2193
CLOUDSTACK-2192 https://issues.apache.org/jira/browse/CLOUDSTACK-2192


Thanks,

venkata swamy babu  budumuru

Re: Review Request: FIX https://issues.apache.org/jira/browse/CLOUDSTACK-2172, by adding database upgrade to 4.1.0 in PremiumDatabaseUpgradeChecker.

[ASF Subversion and Git Services]

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


Commit 099677a1244cd55fb98d3c40ee7881223dd9ac7c in branch refs/heads/master 
from Chip Childers 
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=099677a ]

CLOUDSTACK-2172: adding database upgrade to 4.1.0 in 
PremiumDatabaseUpgradeChecker

Add migration to 4.1.0 in the PremiumDatabaseUpgradeChecker, like in the
DatabaseUpgradeChecker.

I opened the ticket CS 2172, and this fix corrects the issue.
Regards.

Signed-off-by: Chip Childers 


- ASF Subversion and Git Services


On April 25, 2013, 2:14 p.m., Nicolas Lamirault wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10773/
> ---
> 
> (Updated April 25, 2013, 2:14 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Description
> ---
> 
> Add migration to 4.1.0 in the PremiumDatabaseUpgradeChecker, like in the 
> DatabaseUpgradeChecker.
> I opened the ticket CS 2172, and this fix corrects the issue.
> Regards.
> 
> 
> This addresses bug CLOUDSTACK-2172.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/upgrade/PremiumDatabaseUpgradeChecker.java 14a8143 
> 
> Diff: https://reviews.apache.org/r/10773/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nicolas Lamirault
> 
>

DISCUSS

[MEHDI ALI SOLTANI]

Hi
I am new in Devcloud and I want to push my algorithm in Devcloud.

I have two questions : 
 1) From where I should start, my mean is developing requirements.
 2) I study on VMs scheduling and provisioning Algorithms please tell me which 
package is for scheduling and provisioning in Cloud Stack and also which 
scheduling policy is used in cloud stack by default.
 
Sincerely
Mehdi Ali Soltani

[ACS41] New blocker for 4.1 - CLOUDSTACK-2194 - Upgrade from 2.2.14 to 4.1.0 failed due to encryption error

[Chip Childers]

Hi,

Can someone please review / triage and help resolve CLOUDSTACK-2194?

-chip

Re: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Min Chen]

I can take a look at CLOUDSTACK-2126.

Thanks
-min

On 4/25/13 6:54 AM, "Chip Childers"  wrote:

>Hi all,
>
>The following bugs are currently blocking me from starting another 4.1.0
>voting round.  Help please!
>
>CLOUDSTACK-2158 'userconcentratedpod_firstfit failed to find alternate
>host to run VM   (Unassigned)
>CLOUDSTACK-2172 Upgrade from 2.2.14 to 4.1.0 failed (Unassigned)
>CLOUDSTACK-2190 DEB packaging does not package AWSAPI correctly (Chip
>Childers)
>CLOUDSTACK-2126 Response objects of some entities contain job related
>information   (Unassigned)
>
>I'll try to figure out CLOUDSTACK-2190.  The other three are currently
>unassigned.  If you can help resolve them, please step up!
>
>-chip

Re: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Chip Childers]

On Thu, Apr 25, 2013 at 09:18:52AM -0700, Min Chen wrote:
> I can take a look at CLOUDSTACK-2126.

Thank you Min!


I still need someone to look at the allocator bug (2158) and the DB
upgrade issue (2194).

> 
> Thanks
> -min
> 
> On 4/25/13 6:54 AM, "Chip Childers"  wrote:
> 
> >Hi all,
> >
> >The following bugs are currently blocking me from starting another 4.1.0
> >voting round.  Help please!
> >
> >CLOUDSTACK-2158 'userconcentratedpod_firstfit failed to find alternate
> >host to run VM   (Unassigned)
> >CLOUDSTACK-2172 Upgrade from 2.2.14 to 4.1.0 failed (Unassigned)
> >CLOUDSTACK-2190 DEB packaging does not package AWSAPI correctly (Chip
> >Childers)
> >CLOUDSTACK-2126 Response objects of some entities contain job related
> >information   (Unassigned)
> >
> >I'll try to figure out CLOUDSTACK-2190.  The other three are currently
> >unassigned.  If you can help resolve them, please step up!
> >
> >-chip
> 
> 

Re: [DISCUSS] ACS Release 4 month v/s 6 month

[Chip Childers]

On Wed, Apr 24, 2013 at 12:22:58PM +0100, Noah Slater wrote:
> I see where David is coming from.
> 
> The longer you leave a release branch, the harder it becomes to QA, the
> harder it comes to test, and the harder it becomes to release. As has been
> mentioned already, you can think of this as a "release cost". More regular
> releases keep complexity down, and reduce anxiety over "will my feature
> make the next release?" (Only applicable in a time-based system, like we
> have it.)

Indeed.  And frankly the longer the "QA" cycle, the less interest the
community will have (seems to have) in resolving bugs from the pending
feature release.  People move on, naturally, to the next feature they
want to work on.

Frankly this is the reason that I feel like we are still waiting to ship
4.1.0.

-chip

Re: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Min Chen]

Prasanna, I updated CLOUDSTACK-2126 with my comment. That is the intended
change done in list API performance improvement work, and I don't see any
issues by having the consistent UserVmResponse for both deployVMCmd and
listVMsCmd. Every BaseResponse class has jobId and jobStatus as serialized
fields, I don't see why marvin has issues in deserialization in this case.
Did I miss anything?

Thanks
-min

On 4/25/13 9:18 AM, "Min Chen"  wrote:

>I can take a look at CLOUDSTACK-2126.
>
>Thanks
>-min
>
>On 4/25/13 6:54 AM, "Chip Childers"  wrote:
>
>>Hi all,
>>
>>The following bugs are currently blocking me from starting another 4.1.0
>>voting round.  Help please!
>>
>>CLOUDSTACK-2158 'userconcentratedpod_firstfit failed to find alternate
>>host to run VM   (Unassigned)
>>CLOUDSTACK-2172 Upgrade from 2.2.14 to 4.1.0 failed (Unassigned)
>>CLOUDSTACK-2190 DEB packaging does not package AWSAPI correctly (Chip
>>Childers)
>>CLOUDSTACK-2126 Response objects of some entities contain job related
>>information   (Unassigned)
>>
>>I'll try to figure out CLOUDSTACK-2190.  The other three are currently
>>unassigned.  If you can help resolve them, please step up!
>>
>>-chip
>

Potential problem with IP ownership of a commit. WAS: Re: Review Request: Merging changes to marvin after ipclearance from cloudstack-qa

[Chip Childers]

Did we actually process IP Clearance for these?  The summary of the
review board record implies that we did.

I do *not* see it listed on the official IP Clearance page [1].  Is this
the code that was under discussion to be granted by Citrix to ASF (but
was developed by Clogeny)?  AFAIK, this was still pending CTXS signing a
new grant.  If that grant *was* signed, I still have to take it through
the IP clearance process before the code is submitted.

I'll give this 24 hours, and then revert the commit if I don't hear back
from anyone as to the legal status of this patch.

-chip

[1] http://incubator.apache.org/ip-clearance/index.html


On Wed, Apr 24, 2013 at 03:51:16PM +, Prasanna Santhanam wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10741/#review19624
> ---
> 
> Ship it!
> 
> 
> Applied but edited the log message to reflect the nature of fixes.
> 
> commit a1ef9d7312c2de037e09718abf367af774cc288a
> Author: Ashutosh Kelkar 
> Date:   Wed Apr 24 15:03:10 2013 +0530
> 
> Multiple fixes to marvin framework
> 
> 1. adding hypervisor information to configs
> TODO: support for multi-hypervisor zones?
> 2. CLOUDSTACK-601: Marvin unicode decode errors when running mysql
> queries via dbClient
> 3. adding keypair support for remotessh client
> 
> Signed-off-by: Prasanna Santhanam 
> 
> 
> - Prasanna Santhanam
> 
> 
> On April 23, 2013, 9:49 p.m., Ashutosh Kelkar wrote:
> > 
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/10741/
> > ---
> > 
> > (Updated April 23, 2013, 9:49 p.m.)
> > 
> > 
> > Review request for cloudstack and Prasanna Santhanam.
> > 
> > 
> > Description
> > ---
> > 
> > Merging changes to marvin after ipclearance from cloudstack-qa
> > 
> > - Base classes for Router, Tag, PrivateGateway and StaticRoute etc.
> > - VPC support for existing base classes
> > - Read hypervisor config from setting file
> > - Support for keypair authentication in remoteSSHClient
> > 
> > 
> > Diffs
> > -
> > 
> >   tools/marvin/marvin/asyncJobMgr.py 40304fa 
> >   tools/marvin/marvin/cloudstackConnection.py 214a878 
> >   tools/marvin/marvin/cloudstackTestClient.py 85552ed 
> >   tools/marvin/marvin/dbConnection.py 8fa8643 
> >   tools/marvin/marvin/deployDataCenter.py d358789 
> >   tools/marvin/marvin/integration/lib/base.py 92cdf81 
> >   tools/marvin/marvin/integration/lib/utils.py cff24a1 
> >   tools/marvin/marvin/remoteSSHClient.py 4fb2f0d 
> > 
> > Diff: https://reviews.apache.org/r/10741/diff/
> > 
> > 
> > Testing
> > ---
> > 
> > 
> > Thanks,
> > 
> > Ashutosh Kelkar
> > 
> >
> 

Re: Exposing APIs that carry POST data

[Min Chen]

REST based service is postponed, no active progress from mysids either.

Thanks
-min

On 4/25/13 1:10 AM, "Rohit Yadav"  wrote:

>On Thu, Apr 25, 2013 at 10:59 AM, Prasanna Santhanam 
>wrote:
>
>> On Wed, Apr 24, 2013 at 06:08:49AM -0400, Sebastien Goasguen wrote:
>> >
>> > On Apr 24, 2013, at 4:38 AM, Prasanna Santhanam 
>>wrote:
>> >
>> > > Vijay added the ability to send userdata as POST for the
>> > > deployVirtualMachine API in review [1]. What I'd like to address
>>here
>> > > is how to expose this via ApiDiscovery so that clients like marvin,
>> > > cloudmonkey can autogenerate themselves to support APIs of this
>> > > kind. This also needs to be clearly specified in our API docs.
>> > >
>> > > I'm guessing we'll have to put in additional annotations on our APIs
>> > > that support POST so that API discovery can print the methods
>> > > supported (GET/POST). Right now it's only the deployVMCmd (AFAIK).
>>But
>> > > I expect this will need to be done for others soon.
>> > >
>> > > I've included POST support for _every_ command in marvin but that's
>> > > just brute-force. To make it more intelligent I think we should
>>apply
>> > > it to only apis that make sense as POST (causing side-effects). But
>> > > that needs to be exposed by the api endpoint.
>> > >
>> > > Thoughts?
>> >
>> > Prasanna, this seems to me like a bigger discussion as you say, we
>> > could see more api start having a POST.
>>
>> > Will we later see DELETE and PATCH?
>> >
>> > Could be that we are talking about making the API from RESTfull
>> > which would be a big undertaking.
>>
>> I think some work was already underway - Min/Rohit started working on
>> a complete REST based service. It is a significant change and I'll let
>> them speak about the scale of that change. In my case, I just want to
>> auto-generate marvin classes without having to hand edit anything.
>>
>
>Nothing from my side on REST based service.
>
>
>>
>> >
>> > I started a toy REST example for a talk:
>> > https://github.com/runseb/cloudstack-flask/blob/master/flasktest.py
>>
>
>+1 cool
>
>Cheers.
>
>
>> This is cool! Will check it out!
>>
>> >
>> > It would be a bit silly to create a REST wrapper on our API but might
>> give ideas...
>> >
>> > -Sebastien
>> >
>> > >
>> > > [1] https://reviews.apache.org/r/10294/
>> > >
>> > > --
>> > > Prasanna.,
>> > >
>> > > 
>> > > Powered by BigRock.com
>> > >
>>
>> --
>> Prasanna.,
>>
>> 
>> Powered by BigRock.com
>>
>>

Re: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Prasanna Santhanam]

On Thu, Apr 25, 2013 at 09:30:08AM -0700, Min Chen wrote:
> Prasanna, I updated CLOUDSTACK-2126 with my comment. That is the intended
> change done in list API performance improvement work, and I don't see any
> issues by having the consistent UserVmResponse for both deployVMCmd and
> listVMsCmd. Every BaseResponse class has jobId and jobStatus as serialized
> fields, I don't see why marvin has issues in deserialization in this case.
> Did I miss anything?
> 

I'm not sure why internal representation should be a reason to surface
it upwards. But that's not the part I'm concerned with: If you look at
the response carefully - queryAsyncJobResultResponse contains two
jobstatus attributes. One for the query job and one as part of the
virtualmachine (within the virtualmachine block). The concern is with
the latter. 

That block pasted for brevity:

virtualmachine : {
"id": "649663f7-3c8d-4e0d-b693-4b1ea6085a84", 
"name": "649663f7-3c8d-4e0d-b693-4b1ea6085a84", 
"account": "QX7KKV", 
...
..
"zoneid": "6e301be1-8010-4b57-9638-c90761e40dc9",
"jobstatus": 0 
}

These attributes qualify a VM, but I'm not sure why jobstatus is in
there. That's an attribute of the job itself which is CloudStack's
concern, but not the VM's concern. When marvin looks to deserialize
back to a VM object, it looks at the inner block only. I can
workaround these within marvin, so feel free to reduce the priority if
you think the bug can be fixed later. Just that jobstatus represented
as a VM attribute doesn't seem right to me.

Thanks,

-- 
Prasanna.,


Powered by BigRock.com

Re: Review Request: updated cloud-early-config to copy iptables-* config files to rules file to work old templates

[Rohit Yadav]

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


Did not test your patch but saw the diff. Mostly looks good, we'll wait for 
other reviewers to review, test and ship!


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


Remove comment if not needed?



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


Is this file for ipv6? I see a rules.v4?


- Rohit Yadav


On April 25, 2013, 10:35 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10774/
> ---
> 
> (Updated April 25, 2013, 10:35 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, edison su, Chiradeep 
> Vittal, Rohit Yadav, and anthony xu.
> 
> 
> Description
> ---
> 
> Updated the cloud early config also to copy the /etc/iptables/iptables-router 
> (iptables-*) to /etc/iptables/rules.
> 
> 
> This addresses bug CLOUDSTACK-2161.
> 
> 
> Diffs
> -
> 
>   patches/systemvm/debian/config/etc/init.d/cloud-early-config 187ae25 
> 
> Diff: https://reviews.apache.org/r/10774/diff/
> 
> 
> Testing
> ---
> 
> Tested by copying cloud-early-config to router with old template.
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Re: Potential problem with IP ownership of a commit. WAS: Re: Review Request: Merging changes to marvin after ipclearance from cloudstack-qa

[Prasanna Santhanam]

Not quite : I emailed Ashutosh about the controversial subject earlier
today. We marked off 'ipclearance' as a point-in-time. This was when
(January?) the tests were contributed to ASF and went into some legal
issues. It is the point-in-time that is referred to in the request not
the code itself. This code is post-ipclearance changes made to the
framework and sent as a patch.

On Thu, Apr 25, 2013 at 12:33:07PM -0400, Chip Childers wrote:
> 
> Did we actually process IP Clearance for these?  The summary of the
> review board record implies that we did.
> 
> I do *not* see it listed on the official IP Clearance page [1].  Is this
> the code that was under discussion to be granted by Citrix to ASF (but
> was developed by Clogeny)?  AFAIK, this was still pending CTXS signing a
> new grant.  If that grant *was* signed, I still have to take it through
> the IP clearance process before the code is submitted.
> 
> I'll give this 24 hours, and then revert the commit if I don't hear back
> from anyone as to the legal status of this patch.
> 
> -chip
> 
> [1] http://incubator.apache.org/ip-clearance/index.html
> 
> 
> On Wed, Apr 24, 2013 at 03:51:16PM +, Prasanna Santhanam wrote:
> > 
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/10741/#review19624
> > ---
> > 
> > Ship it!
> > 
> > 
> > Applied but edited the log message to reflect the nature of fixes.
> > 
> > commit a1ef9d7312c2de037e09718abf367af774cc288a
> > Author: Ashutosh Kelkar 
> > Date:   Wed Apr 24 15:03:10 2013 +0530
> > 
> > Multiple fixes to marvin framework
> > 
> > 1. adding hypervisor information to configs
> > TODO: support for multi-hypervisor zones?
> > 2. CLOUDSTACK-601: Marvin unicode decode errors when running mysql
> > queries via dbClient
> > 3. adding keypair support for remotessh client
> > 
> > Signed-off-by: Prasanna Santhanam 
> > 
> > 
> > - Prasanna Santhanam
> > 
> > 
> > On April 23, 2013, 9:49 p.m., Ashutosh Kelkar wrote:
> > > 
> > > ---
> > > This is an automatically generated e-mail. To reply, visit:
> > > https://reviews.apache.org/r/10741/
> > > ---
> > > 
> > > (Updated April 23, 2013, 9:49 p.m.)
> > > 
> > > 
> > > Review request for cloudstack and Prasanna Santhanam.
> > > 
> > > 
> > > Description
> > > ---
> > > 
> > > Merging changes to marvin after ipclearance from cloudstack-qa
> > > 
> > > - Base classes for Router, Tag, PrivateGateway and StaticRoute etc.
> > > - VPC support for existing base classes
> > > - Read hypervisor config from setting file
> > > - Support for keypair authentication in remoteSSHClient
> > > 
> > > 
> > > Diffs
> > > -
> > > 
> > >   tools/marvin/marvin/asyncJobMgr.py 40304fa 
> > >   tools/marvin/marvin/cloudstackConnection.py 214a878 
> > >   tools/marvin/marvin/cloudstackTestClient.py 85552ed 
> > >   tools/marvin/marvin/dbConnection.py 8fa8643 
> > >   tools/marvin/marvin/deployDataCenter.py d358789 
> > >   tools/marvin/marvin/integration/lib/base.py 92cdf81 
> > >   tools/marvin/marvin/integration/lib/utils.py cff24a1 
> > >   tools/marvin/marvin/remoteSSHClient.py 4fb2f0d 
> > > 
> > > Diff: https://reviews.apache.org/r/10741/diff/
> > > 
> > > 
> > > Testing
> > > ---
> > > 
> > > 
> > > Thanks,
> > > 
> > > Ashutosh Kelkar
> > > 
> > >
> > 

-- 
Prasanna.,


Powered by BigRock.com

RE: [ACS41] New blocker for 4.1 - CLOUDSTACK-2194 - Upgrade from 2.2.14 to 4.1.0 failed due to encryption error

[Edison Su]

I can take a look at it.

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Thursday, April 25, 2013 8:49 AM
> To: dev@cloudstack.apache.org
> Subject: [ACS41] New blocker for 4.1 - CLOUDSTACK-2194 - Upgrade from
> 2.2.14 to 4.1.0 failed due to encryption error
> 
> Hi,
> 
> Can someone please review / triage and help resolve CLOUDSTACK-2194?
> 
> -chip

Re: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Min Chen]

In 4.0, CS has special code to return job status for a VM returned from
listVMsCmd. During API performance refactoring, I have a created a DB view
user_vm_view that joins async_job table just for that purpose and used
that view to uniformly generate UserVmResponse. So the same code will be
applied to generate UserVmResponse whenever it is used. In this case,
deployVMCmd itself will also return a UserVmResponse, thus the same code
applied, and so that is what you see. If we all agree that job status
should not appear in UserVmResponse, then I can change the view to remove
job from async_job. But I would argue that we should not return jobStatus
in ListVmsCmd as well, this will also be a change from 4.0 release.

Thanks
-min

On 4/25/13 9:48 AM, "Prasanna Santhanam"  wrote:

>On Thu, Apr 25, 2013 at 09:30:08AM -0700, Min Chen wrote:
>> Prasanna, I updated CLOUDSTACK-2126 with my comment. That is the
>>intended
>> change done in list API performance improvement work, and I don't see
>>any
>> issues by having the consistent UserVmResponse for both deployVMCmd and
>> listVMsCmd. Every BaseResponse class has jobId and jobStatus as
>>serialized
>> fields, I don't see why marvin has issues in deserialization in this
>>case.
>> Did I miss anything?
>> 
>
>I'm not sure why internal representation should be a reason to surface
>it upwards. But that's not the part I'm concerned with: If you look at
>the response carefully - queryAsyncJobResultResponse contains two
>jobstatus attributes. One for the query job and one as part of the
>virtualmachine (within the virtualmachine block). The concern is with
>the latter. 
>
>That block pasted for brevity:
>
>virtualmachine : {
>   "id": "649663f7-3c8d-4e0d-b693-4b1ea6085a84",
>   "name": "649663f7-3c8d-4e0d-b693-4b1ea6085a84",
>   "account": "QX7KKV",
>   ...
>   ..
>   "zoneid": "6e301be1-8010-4b57-9638-c90761e40dc9",
>"jobstatus": 0 
>}
>
>These attributes qualify a VM, but I'm not sure why jobstatus is in
>there. That's an attribute of the job itself which is CloudStack's
>concern, but not the VM's concern. When marvin looks to deserialize
>back to a VM object, it looks at the inner block only. I can
>workaround these within marvin, so feel free to reduce the priority if
>you think the bug can be fixed later. Just that jobstatus represented
>as a VM attribute doesn't seem right to me.
>
>Thanks,
>
>-- 
>Prasanna.,
>
>
>Powered by BigRock.com
>

Re: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Prasanna Santhanam]

That's odd - listXxx commands don't do async at all and shouldn't be
generating jobstatus,jobid etc. So I'm not sure why that was added in
(prior?) 4.0. I'd like to take that out too if there's no real reason
behind it.

-- 
Prasanna.,

On Thu, Apr 25, 2013 at 09:57:02AM -0700, Min Chen wrote:
> In 4.0, CS has special code to return job status for a VM returned from
> listVMsCmd. During API performance refactoring, I have a created a DB view
> user_vm_view that joins async_job table just for that purpose and used
> that view to uniformly generate UserVmResponse. So the same code will be
> applied to generate UserVmResponse whenever it is used. In this case,
> deployVMCmd itself will also return a UserVmResponse, thus the same code
> applied, and so that is what you see. If we all agree that job status
> should not appear in UserVmResponse, then I can change the view to remove
> job from async_job. But I would argue that we should not return jobStatus
> in ListVmsCmd as well, this will also be a change from 4.0 release.
> 
> Thanks
> -min
> 
> On 4/25/13 9:48 AM, "Prasanna Santhanam"  wrote:
> 
> >On Thu, Apr 25, 2013 at 09:30:08AM -0700, Min Chen wrote:
> >> Prasanna, I updated CLOUDSTACK-2126 with my comment. That is the
> >>intended
> >> change done in list API performance improvement work, and I don't see
> >>any
> >> issues by having the consistent UserVmResponse for both deployVMCmd and
> >> listVMsCmd. Every BaseResponse class has jobId and jobStatus as
> >>serialized
> >> fields, I don't see why marvin has issues in deserialization in this
> >>case.
> >> Did I miss anything?
> >> 
> >
> >I'm not sure why internal representation should be a reason to surface
> >it upwards. But that's not the part I'm concerned with: If you look at
> >the response carefully - queryAsyncJobResultResponse contains two
> >jobstatus attributes. One for the query job and one as part of the
> >virtualmachine (within the virtualmachine block). The concern is with
> >the latter. 
> >
> >That block pasted for brevity:
> >
> >virtualmachine : {
> > "id": "649663f7-3c8d-4e0d-b693-4b1ea6085a84",
> > "name": "649663f7-3c8d-4e0d-b693-4b1ea6085a84",
> > "account": "QX7KKV",
> > ...
> > ..
> > "zoneid": "6e301be1-8010-4b57-9638-c90761e40dc9",
> >"jobstatus": 0 
> >}
> >
> >These attributes qualify a VM, but I'm not sure why jobstatus is in
> >there. That's an attribute of the job itself which is CloudStack's
> >concern, but not the VM's concern. When marvin looks to deserialize
> >back to a VM object, it looks at the inner block only. I can
> >workaround these within marvin, so feel free to reduce the priority if
> >you think the bug can be fixed later. Just that jobstatus represented
> >as a VM attribute doesn't seem right to me.
> >
> >Thanks,
> >
> >-- 
> >Prasanna.,
> >
> >
> >Powered by BigRock.com
> >



Powered by BigRock.com

Re: Xen Hackathon Dublin May 16/17th

[Noah Slater]

Give me a shout if you'rein town and I'll come for drinks and meet some of
you folks.


On 25 April 2013 15:34, Sebastien Goasguen  wrote:

> Folks,
>
> The Xen hackathon is being held in Dublin, Ireland on May 16/17th.
>
> Is anyone interested to go there and actually work on improving Xen/XCP
> support in CloudStack ?
>
> -Sebastien




-- 
NS

Re: Google Summer of Code 2013 Mentor Registration

[Noah Slater]

This would make a good blog post and tweet!


On 9 April 2013 21:25, Sebastien Goasguen  wrote:

> Folks, [BCC: users@]
>
> Apache Software Foundation (ASF) has been accepted has a mentoring
> organization for the 2013 Google Summer of Code.
>
> If you wish to be a mentor for a student to work on a CloudStack project
> there are several "administrative" steps that you will need to do:
>
> 1-Add your project idea to JIRA, using the label gsoc2013. Then add an
> entry in the wiki page I started:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Student+Projects
>
> 2-register on the code-awa...@apache.org list
>
> 3-Follow the email from Ulrich Stark below which tells you to register on
> the "melange" site run by Google and then inform the PMC (
> priv...@cloudstack.apache.org) that you want to be a mentor.
>
> Note that all in all GSoC is a ~4months program, being a mentor will
> require a firm commitment to the students who may need mentorship/guidance
> on a daily basis.
>
> -Sebastien
>
> Begin forwarded message:
>
> > From: Ulrich Stärk 
> > Subject: Google Summer of Code 2013 Mentor Registration
> > Date: April 9, 2013 10:34:01 AM EDT
> > To: p...@apache.org
> > Cc: code-awa...@apache.org
> > Reply-To: priv...@cloudstack.apache.org
> > Reply-To: code-awa...@apache.org
> >
> > Dear PMCs,
> >
> > I'm happy to announce that the ASF has made it onto the list of 177
> accepted organizations for
> > Google Summer of Code 2013! [1,2]
> >
> > It is now time for the mentors to sign up, so please pass this email on
> to your community and podlings.
> >
> > Mentor signup requires two steps: mentor signup in Melange and PMC
> acknowledgement.
> >
> > If you want to mentor a project in this year's SoC you will have to
> >
> > 1. Be an Apache committer.
> > 2. Register with Melange and set up a profile [3].
> > 3. Add your username (formerly known as link_id) to [4]. This is NOT
> your email address but your
> > Melange username. You can find it at the top of any page once you are
> logged in.
> > 4. Request an acknowledgement from the PMC for which you want to mentor
> projects. Use the below
> > template and do not forget to copy code-awa...@apache.org.
> > 5. Once a PMC member acknowledges the request to mentor, and only then,
> go to [2] and click the
> > "Start a connection" button.
> >
> > PMCs, read carefully please.
> >
> > We request that each mentor is acknowledged by a PMC member. This is to
> ensure the mentor is in good
> > standing with the community. When you receive a request for
> acknowledgement, please ACK it and cc
> > code-awa...@apache.org
> >
> > Cheers,
> >
> > Uli
> >
> > mentor request email template:
> > 
> > to: private@.apache.org
> > cc: code-awa...@apache.org
> > subject: GSoC 2013 mentor request for 
> >
> >  PMC,
> >
> > please acknowledge my request to become a mentor for Google Summer of
> Code 2013 projects for Apache
> > .
> >
> > My Melange username is .
> >
> > 
> >
> > 
> >
> > [1]
> https://google-melange.appspot.com/gsoc/accepted_orgs/google/gsoc2013
> > [2] https://google-melange.appspot.com/gsoc/org/google/gsoc2013/apache
> > [3] https://google-melange.appspot.com/gsoc/homepage/google/gsoc2013
> > [4] https://svn.apache.org/repos/private/committers/GsocLinkId.txt
>
>


-- 
NS

Re: [DISCUSS] Making simple installs easier.

[Jörgen Maas]

As a new user (as of today) i can say the following from my personal
experience:

The biggest hurdle (in an enterprise setting) is getting the packages for
your platform.Building packages from source is nice and all, but in my case
i don't have Internet access in the datacenter. So the whole maven stuff is
pretty much a big time burner (there's also a bug somewhere wrt to calling
/usr/bin/mvn when there's only /usr/bin/mvn3 as per the docs). I also had
to downgrade tomcat to work around some bugs where the management service
would just shutdown (Ubuntu 12.04 LTS).

When the issues surrounding the packages were resolved and the management
service was up and running it was pretty much smooth sailing from there on
(except for the systemvm stuff).

So from my point of view it would make much more sense to first align the
releases more with the targeted distro's and provide repo's for those
distro's.

Hope this helps :)




On Wed, Apr 24, 2013 at 1:58 PM, Noah Slater  wrote:

> (Typo, but you can fill in any number you feel like...)
>
>
> On 24 April 2013 12:57, Noah Slater  wrote:
>
> > Also + for the initiative!
> >
> >
> > On 23 April 2013 20:15, Chiradeep Vittal  >wrote:
> >
> >>
> >>
> >> On 4/21/13 3:21 PM, "David Nalley"  wrote:
> >>
> >> >Hi folks.
> >> >
> >> >I've been thinking about our install process lately.
> >> >
> >> >We currently require folks to muck about with firewall settings, NFS
> >> >settings, network configuration, etc.
> >> >This makes configuration painful, our docs VERY platform specific, and
> >> >easily prone to mistakes which result in failure to get things to
> >> >work. Even the 'install.sh' from the 3.0.x and earlier days doesn't do
> >> >enough. What I want to do is get rid of sections 2-4 of the quick
> >> >install guide, and replace it with - 'run this one or two lines worth
> >> >of commands' (http://s.apache.org/runbook)
> >> >
> >> >My natural reaction was to reach for puppet - but I am not sure that's
> >> >the right answer. To do things right, I'd need several puppet modules
> >> >like stdlib, puppetlabs-firewall, etc, which is a fair bit of
> >> >overhread - and oh, yeah, need to install the puppet client. I think
> >> >Chef is probably in a similar problem space. I don't want to resort to
> >> >shell scripts of python - config management tools know the difference
> >> >between apt and yum, and can still get a package installed with one
> >> >declaration, same thing with firewall rules. Is something like Ansible
> >> >or SaltStack a better choice?? I don't see it right now if it is, but
> >> >I don't have much experience with either of those two.
> >> >
> >> >The all-in-one installation process I'd like to see:
> >> >
> >> >Install your host OS
> >> >Install an meta-RPM/Deb that either (installs everything, or
> >> >alternatively configures a repo - or just installs the repo and the
> >> >stuff I need to install with)
> >> >Run a command that activates one of these config tools - configures
> >> >the machine, installs the packages I need, and gets me to the point
> >> >where I'm ready to login and go through the beautiful new user gui
> >> >setup stuff.
> >> >
> >> >I still want to keep the documentation around, it's invaluable for
> >> >experienced users and more complex deployments - but right now it's
> >> >far too much overhead (probably an hour or two) to get things
> >> >installed and setup to the point where you are ready to run the
> >> >'Welcome to CloudStack GUI' if you just want to try CloudStack out.
> >> >
> >> >So why am I writing this email instead of diving in and solving this
> >> >problem? Well honestly, I'd like some external opinions. I want to
> >> >make sure that I am not seeing a 'nail' simply because I have a hammer
> >> >in my hand. How can we most easily do this? So - how do we make the
> >> >'brand-new' user experience much better? We develop a platform for
> >> >orchestration of complex systems, this should be a solved problem.
> >> >
> >> >--David
> >>
> >> +1 for the initiative.
> >> If I look at Apache Hadoop's single node operation documentation[1], it
> is
> >> considerably simpler.
> >> Apache Tomcat installation is also fairly trivial.
> >>
> >> [1] http://hadoop.apache.org/docs/stable/single_node_setup.html
> >>
> >>
> >
> >
> > --
> > NS
> >
>
>
>
> --
> NS
>



-- 
Grtz,
Jörgen Maas

Re: Potential problem with IP ownership of a commit. WAS: Re: Review Request: Merging changes to marvin after ipclearance from cloudstack-qa

[Chip Childers]

On Thu, Apr 25, 2013 at 10:25:12PM +0530, Prasanna Santhanam wrote:
> Not quite : I emailed Ashutosh about the controversial subject earlier
> today. We marked off 'ipclearance' as a point-in-time. This was when
> (January?) the tests were contributed to ASF and went into some legal
> issues. It is the point-in-time that is referred to in the request not
> the code itself. This code is post-ipclearance changes made to the
> framework and sent as a patch.

Thanks for clarifying!

No objection then.

Re: [ACS41] New blocker for 4.1 - CLOUDSTACK-2194 - Upgrade from 2.2.14 to 4.1.0 failed due to encryption error

[Chip Childers]

On Thu, Apr 25, 2013 at 09:55:43AM -0700, Edison Su wrote:
> I can take a look at it.

Thanks for stepping up Edison!

> 
> > -Original Message-
> > From: Chip Childers [mailto:chip.child...@sungard.com]
> > Sent: Thursday, April 25, 2013 8:49 AM
> > To: dev@cloudstack.apache.org
> > Subject: [ACS41] New blocker for 4.1 - CLOUDSTACK-2194 - Upgrade from
> > 2.2.14 to 4.1.0 failed due to encryption error
> > 
> > Hi,
> > 
> > Can someone please review / triage and help resolve CLOUDSTACK-2194?
> > 
> > -chip
> 

Re: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Min Chen]

Totally agree. 

Chip and others, Prasanna and I exchanged ideas about CLOUDSTACK--2126,
and we both agree that we should only return async job Id and job status
in queryAsyncJob and listAsyncJob commands, not in any other APIs so that
we can have consistent response return in various scenarios.  If we fix
this way, the behavior for listXXX api is changed. In 4.0, CloudStack has
used ApiServer.buildAsyncListResponse() routine to fill in async job Id
and status for all listXXX Apis.  With the proposed fix, we will not show
async job information in listXXX response as well. Not sure if anybody see
any side effect on this slight change from 4.0? Anybody know the reason
why we had that special code in 4.0 to return async job for listXXX api?
Since the proposed change will affect all newly created db view in 4.1, we
suggest that this can be fixed in 4.2 since current behavior is not
breaking functionalities, just return more information. Any thoughts?

Thanks
-min






On 4/25/13 10:05 AM, "Prasanna Santhanam"  wrote:

>That's odd - listXxx commands don't do async at all and shouldn't be
>generating jobstatus,jobid etc. So I'm not sure why that was added in
>(prior?) 4.0. I'd like to take that out too if there's no real reason
>behind it.
>
>-- 
>Prasanna.,
>
>On Thu, Apr 25, 2013 at 09:57:02AM -0700, Min Chen wrote:
>> In 4.0, CS has special code to return job status for a VM returned from
>> listVMsCmd. During API performance refactoring, I have a created a DB
>>view
>> user_vm_view that joins async_job table just for that purpose and used
>> that view to uniformly generate UserVmResponse. So the same code will be
>> applied to generate UserVmResponse whenever it is used. In this case,
>> deployVMCmd itself will also return a UserVmResponse, thus the same code
>> applied, and so that is what you see. If we all agree that job status
>> should not appear in UserVmResponse, then I can change the view to
>>remove
>> job from async_job. But I would argue that we should not return
>>jobStatus
>> in ListVmsCmd as well, this will also be a change from 4.0 release.
>> 
>> Thanks
>> -min
>> 
>> On 4/25/13 9:48 AM, "Prasanna Santhanam"  wrote:
>> 
>> >On Thu, Apr 25, 2013 at 09:30:08AM -0700, Min Chen wrote:
>> >> Prasanna, I updated CLOUDSTACK-2126 with my comment. That is the
>> >>intended
>> >> change done in list API performance improvement work, and I don't see
>> >>any
>> >> issues by having the consistent UserVmResponse for both deployVMCmd
>>and
>> >> listVMsCmd. Every BaseResponse class has jobId and jobStatus as
>> >>serialized
>> >> fields, I don't see why marvin has issues in deserialization in this
>> >>case.
>> >> Did I miss anything?
>> >> 
>> >
>> >I'm not sure why internal representation should be a reason to surface
>> >it upwards. But that's not the part I'm concerned with: If you look at
>> >the response carefully - queryAsyncJobResultResponse contains two
>> >jobstatus attributes. One for the query job and one as part of the
>> >virtualmachine (within the virtualmachine block). The concern is with
>> >the latter. 
>> >
>> >That block pasted for brevity:
>> >
>> >virtualmachine : {
>> >"id": "649663f7-3c8d-4e0d-b693-4b1ea6085a84",
>> >"name": "649663f7-3c8d-4e0d-b693-4b1ea6085a84",
>> >"account": "QX7KKV",
>> >...
>> >..
>> >"zoneid": "6e301be1-8010-4b57-9638-c90761e40dc9",
>> >"jobstatus": 0 
>> >}
>> >
>> >These attributes qualify a VM, but I'm not sure why jobstatus is in
>> >there. That's an attribute of the job itself which is CloudStack's
>> >concern, but not the VM's concern. When marvin looks to deserialize
>> >back to a VM object, it looks at the inner block only. I can
>> >workaround these within marvin, so feel free to reduce the priority if
>> >you think the bug can be fixed later. Just that jobstatus represented
>> >as a VM attribute doesn't seem right to me.
>> >
>> >Thanks,
>> >
>> >-- 
>> >Prasanna.,
>> >
>> >
>> >Powered by BigRock.com
>> >
>
>
>
>Powered by BigRock.com
>

Re: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Chip Childers]

On Thu, Apr 25, 2013 at 10:32:15AM -0700, Min Chen wrote:
> Totally agree. 
> 
> Chip and others, Prasanna and I exchanged ideas about CLOUDSTACK--2126,
> and we both agree that we should only return async job Id and job status
> in queryAsyncJob and listAsyncJob commands, not in any other APIs so that
> we can have consistent response return in various scenarios.  If we fix
> this way, the behavior for listXXX api is changed. In 4.0, CloudStack has
> used ApiServer.buildAsyncListResponse() routine to fill in async job Id
> and status for all listXXX Apis.  With the proposed fix, we will not show
> async job information in listXXX response as well. Not sure if anybody see
> any side effect on this slight change from 4.0? Anybody know the reason
> why we had that special code in 4.0 to return async job for listXXX api?
> Since the proposed change will affect all newly created db view in 4.1, we
> suggest that this can be fixed in 4.2 since current behavior is not
> breaking functionalities, just return more information. Any thoughts?

+1 to doing that change in 4.2.

Specific to that release, can you please start a new thread about this
topic?  I don't want a decision like this (for 4.2) to be buried in a
4.1.0 release thread.

-chip

Re: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Min Chen]

Thanks Chip, will do that.

-min

On 4/25/13 10:37 AM, "Chip Childers"  wrote:

>On Thu, Apr 25, 2013 at 10:32:15AM -0700, Min Chen wrote:
>> Totally agree. 
>> 
>> Chip and others, Prasanna and I exchanged ideas about CLOUDSTACK--2126,
>> and we both agree that we should only return async job Id and job status
>> in queryAsyncJob and listAsyncJob commands, not in any other APIs so
>>that
>> we can have consistent response return in various scenarios.  If we fix
>> this way, the behavior for listXXX api is changed. In 4.0, CloudStack
>>has
>> used ApiServer.buildAsyncListResponse() routine to fill in async job Id
>> and status for all listXXX Apis.  With the proposed fix, we will not
>>show
>> async job information in listXXX response as well. Not sure if anybody
>>see
>> any side effect on this slight change from 4.0? Anybody know the reason
>> why we had that special code in 4.0 to return async job for listXXX api?
>> Since the proposed change will affect all newly created db view in 4.1,
>>we
>> suggest that this can be fixed in 4.2 since current behavior is not
>> breaking functionalities, just return more information. Any thoughts?
>
>+1 to doing that change in 4.2.
>
>Specific to that release, can you please start a new thread about this
>topic?  I don't want a decision like this (for 4.2) to be buried in a
>4.1.0 release thread.
>
>-chip

Re: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Prasanna Santhanam]

On Thu, Apr 25, 2013 at 10:32:15AM -0700, Min Chen wrote:
> Totally agree. 
> 
> Chip and others, Prasanna and I exchanged ideas about CLOUDSTACK--2126,
> and we both agree that we should only return async job Id and job status
> in queryAsyncJob and listAsyncJob commands, not in any other APIs so that
> we can have consistent response return in various scenarios.  If we fix
> this way, the behavior for listXXX api is changed. In 4.0, CloudStack has
> used ApiServer.buildAsyncListResponse() routine to fill in async job Id
> and status for all listXXX Apis.  With the proposed fix, we will not show
> async job information in listXXX response as well. Not sure if anybody see
> any side effect on this slight change from 4.0? Anybody know the reason
> why we had that special code in 4.0 to return async job for listXXX api?
> Since the proposed change will affect all newly created db view in 4.1, we
> suggest that this can be fixed in 4.2 since current behavior is not
> breaking functionalities, just return more information. Any thoughts?

I went backwards in history and this seems to have existed from eons
ago when Will was still writing code. :)

If he remembers the reason - great! 

~/workspace/cloudstack/incubator-cloudstack(branch:4.0*) ?? find . -name 
ApiServer.java
./server/src/com/cloud/api/ApiServer.java

~/workspace/cloudstack/incubator-cloudstack(branch:4.0*) ?? git blame 303e2a74^ 
./server/src/com/cloud/api/ApiServer.java
~/workspace/cloudstack/incubator-cloudstack(branch:4.0*) ?? git blame 633d024b^ 
./server/src/com/cloud/api/ApiServer.java
~/workspace/cloudstack/incubator-cloudstack(branch:4.0*) ?? git blame c7e120a7^ 
./server/src/com/cloud/api/ApiServer.java
~/workspace/cloudstack/incubator-cloudstack(branch:4.0*) ?? git blame 52e6e4d0^ 
./server/src/com/cloud/api/ApiServer.java
~/workspace/cloudstack/incubator-cloudstack(branch:4.0*) ?? git blame c67d26ce^ 
./server/src/com/cloud/api/ApiServer.java  


commit c67d26cec4edb16d54b319e80f73034bda5f4c87
Author: will 
Date:   Tue Nov 30 19:11:55 2010 -0800

bug 6969: First step of now displaying pending async jobs for
listXXXCommands.  There is a lot more cleanup and fixing to do but all commands
acting against VirtualMachines now work.




-- 
Prasanna.,


Powered by BigRock.com

Re: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Alena Prokharchyk]

JobId/JobStatus were introduced to the list* responses on purpose. Some of
the CS customers wanted to see what async jobs that are currently being
executed on the object, just by looking at the result of list* command.

So removing async job params from the list response is not a good idea as
customers' software might rely on its presence.

On 4/25/13 10:32 AM, "Min Chen"  wrote:

>Totally agree. 
>
>Chip and others, Prasanna and I exchanged ideas about CLOUDSTACK--2126,
>and we both agree that we should only return async job Id and job status
>in queryAsyncJob and listAsyncJob commands, not in any other APIs so that
>we can have consistent response return in various scenarios.  If we fix
>this way, the behavior for listXXX api is changed. In 4.0, CloudStack has
>used ApiServer.buildAsyncListResponse() routine to fill in async job Id
>and status for all listXXX Apis.  With the proposed fix, we will not show
>async job information in listXXX response as well. Not sure if anybody see
>any side effect on this slight change from 4.0? Anybody know the reason
>why we had that special code in 4.0 to return async job for listXXX api?
>Since the proposed change will affect all newly created db view in 4.1, we
>suggest that this can be fixed in 4.2 since current behavior is not
>breaking functionalities, just return more information. Any thoughts?
>
>Thanks
>-min
>
>
>
>
>
>
>On 4/25/13 10:05 AM, "Prasanna Santhanam"  wrote:
>
>>That's odd - listXxx commands don't do async at all and shouldn't be
>>generating jobstatus,jobid etc. So I'm not sure why that was added in
>>(prior?) 4.0. I'd like to take that out too if there's no real reason
>>behind it.
>>
>>-- 
>>Prasanna.,
>>
>>On Thu, Apr 25, 2013 at 09:57:02AM -0700, Min Chen wrote:
>>> In 4.0, CS has special code to return job status for a VM returned from
>>> listVMsCmd. During API performance refactoring, I have a created a DB
>>>view
>>> user_vm_view that joins async_job table just for that purpose and used
>>> that view to uniformly generate UserVmResponse. So the same code will
>>>be
>>> applied to generate UserVmResponse whenever it is used. In this case,
>>> deployVMCmd itself will also return a UserVmResponse, thus the same
>>>code
>>> applied, and so that is what you see. If we all agree that job status
>>> should not appear in UserVmResponse, then I can change the view to
>>>remove
>>> job from async_job. But I would argue that we should not return
>>>jobStatus
>>> in ListVmsCmd as well, this will also be a change from 4.0 release.
>>> 
>>> Thanks
>>> -min
>>> 
>>> On 4/25/13 9:48 AM, "Prasanna Santhanam"  wrote:
>>> 
>>> >On Thu, Apr 25, 2013 at 09:30:08AM -0700, Min Chen wrote:
>>> >> Prasanna, I updated CLOUDSTACK-2126 with my comment. That is the
>>> >>intended
>>> >> change done in list API performance improvement work, and I don't
>>>see
>>> >>any
>>> >> issues by having the consistent UserVmResponse for both deployVMCmd
>>>and
>>> >> listVMsCmd. Every BaseResponse class has jobId and jobStatus as
>>> >>serialized
>>> >> fields, I don't see why marvin has issues in deserialization in this
>>> >>case.
>>> >> Did I miss anything?
>>> >> 
>>> >
>>> >I'm not sure why internal representation should be a reason to surface
>>> >it upwards. But that's not the part I'm concerned with: If you look at
>>> >the response carefully - queryAsyncJobResultResponse contains two
>>> >jobstatus attributes. One for the query job and one as part of the
>>> >virtualmachine (within the virtualmachine block). The concern is with
>>> >the latter. 
>>> >
>>> >That block pasted for brevity:
>>> >
>>> >virtualmachine : {
>>> >   "id": "649663f7-3c8d-4e0d-b693-4b1ea6085a84",
>>> >   "name": "649663f7-3c8d-4e0d-b693-4b1ea6085a84",
>>> >   "account": "QX7KKV",
>>> >   ...
>>> >   ..
>>> >   "zoneid": "6e301be1-8010-4b57-9638-c90761e40dc9",
>>> >"jobstatus": 0 
>>> >}
>>> >
>>> >These attributes qualify a VM, but I'm not sure why jobstatus is in
>>> >there. That's an attribute of the job itself which is CloudStack's
>>> >concern, but not the VM's concern. When marvin looks to deserialize
>>> >back to a VM object, it looks at the inner block only. I can
>>> >workaround these within marvin, so feel free to reduce the priority if
>>> >you think the bug can be fixed later. Just that jobstatus represented
>>> >as a VM attribute doesn't seem right to me.
>>> >
>>> >Thanks,
>>> >
>>> >-- 
>>> >Prasanna.,
>>> >
>>> >
>>> >Powered by BigRock.com
>>> >
>>
>>
>>
>>Powered by BigRock.com
>>
>
>

[ACS41] Allocator Expert Needed!

[Chip Childers]

CLOUDSTACK-2158 is a blocker bug for 4.1.0, and I need an allocator
expert to review and fix if required.

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

'userconcentratedpod_firstfit failed to find alternate host to run VM

Marcus laid out the situation in the bug itself.

Help please!

-chip

Re: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Chip Childers]

On Thu, Apr 25, 2013 at 10:48:02AM -0700, Alena Prokharchyk wrote:
> JobId/JobStatus were introduced to the list* responses on purpose. Some of
> the CS customers wanted to see what async jobs that are currently being
> executed on the object, just by looking at the result of list* command.
> 
> So removing async job params from the list response is not a good idea as
> customers' software might rely on its presence.

Please say that again when Min starts the new thread.

RE: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Will Chan]

Alena is right.  They were introduced eons ago for customers to figure out 
which objects still had pending jobs on them without having the need to know 
the async job ID in the first place.  I'm not sure who's using that now but if 
you remove it, it may cause existing customers that do rely on this.

Will

> -Original Message-
> From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
> Sent: Thursday, April 25, 2013 10:48 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [ACS41] Blocker and critical issues stopping me from spinning
> out a new RC for 4.1
> 
> JobId/JobStatus were introduced to the list* responses on purpose. Some
> of the CS customers wanted to see what async jobs that are currently being
> executed on the object, just by looking at the result of list* command.
> 
> So removing async job params from the list response is not a good idea as
> customers' software might rely on its presence.
> 
> On 4/25/13 10:32 AM, "Min Chen"  wrote:
> 
> >Totally agree.
> >
> >Chip and others, Prasanna and I exchanged ideas about CLOUDSTACK--
> 2126,
> >and we both agree that we should only return async job Id and job
> >status in queryAsyncJob and listAsyncJob commands, not in any other
> >APIs so that we can have consistent response return in various
> >scenarios.  If we fix this way, the behavior for listXXX api is
> >changed. In 4.0, CloudStack has used ApiServer.buildAsyncListResponse()
> >routine to fill in async job Id and status for all listXXX Apis.  With
> >the proposed fix, we will not show async job information in listXXX
> >response as well. Not sure if anybody see any side effect on this
> >slight change from 4.0? Anybody know the reason why we had that special
> code in 4.0 to return async job for listXXX api?
> >Since the proposed change will affect all newly created db view in 4.1,
> >we suggest that this can be fixed in 4.2 since current behavior is not
> >breaking functionalities, just return more information. Any thoughts?
> >
> >Thanks
> >-min
> >
> >
> >
> >
> >
> >
> >On 4/25/13 10:05 AM, "Prasanna Santhanam"  wrote:
> >
> >>That's odd - listXxx commands don't do async at all and shouldn't be
> >>generating jobstatus,jobid etc. So I'm not sure why that was added in
> >>(prior?) 4.0. I'd like to take that out too if there's no real reason
> >>behind it.
> >>
> >>--
> >>Prasanna.,
> >>
> >>On Thu, Apr 25, 2013 at 09:57:02AM -0700, Min Chen wrote:
> >>> In 4.0, CS has special code to return job status for a VM returned
> >>>from  listVMsCmd. During API performance refactoring, I have a
> >>>created a DB view  user_vm_view that joins async_job table just for
> >>>that purpose and used  that view to uniformly generate
> >>>UserVmResponse. So the same code will be  applied to generate
> >>>UserVmResponse whenever it is used. In this case,  deployVMCmd itself
> >>>will also return a UserVmResponse, thus the same code  applied, and
> >>>so that is what you see. If we all agree that job status  should not
> >>>appear in UserVmResponse, then I can change the view to remove  job
> >>>from async_job. But I would argue that we should not return jobStatus
> >>>in ListVmsCmd as well, this will also be a change from 4.0 release.
> >>>
> >>> Thanks
> >>> -min
> >>>
> >>> On 4/25/13 9:48 AM, "Prasanna Santhanam" 
> wrote:
> >>>
> >>> >On Thu, Apr 25, 2013 at 09:30:08AM -0700, Min Chen wrote:
> >>> >> Prasanna, I updated CLOUDSTACK-2126 with my comment. That is
> the
> >>> >>intended  change done in list API performance improvement work,
> >>> >>and I don't
> >>>see
> >>> >>any
> >>> >> issues by having the consistent UserVmResponse for both
> >>> >>deployVMCmd
> >>>and
> >>> >> listVMsCmd. Every BaseResponse class has jobId and jobStatus as
> >>> >>serialized  fields, I don't see why marvin has issues in
> >>> >>deserialization in this case.
> >>> >> Did I miss anything?
> >>> >>
> >>> >
> >>> >I'm not sure why internal representation should be a reason to
> >>> >surface it upwards. But that's not the part I'm concerned with: If
> >>> >you look at the response carefully - queryAsyncJobResultResponse
> >>> >contains two jobstatus attributes. One for the query job and one as
> >>> >part of the virtualmachine (within the virtualmachine block). The
> >>> >concern is with the latter.
> >>> >
> >>> >That block pasted for brevity:
> >>> >
> >>> >virtualmachine : {
> >>> > "id": "649663f7-3c8d-4e0d-b693-4b1ea6085a84",
> >>> > "name": "649663f7-3c8d-4e0d-b693-4b1ea6085a84",
> >>> > "account": "QX7KKV",
> >>> > ...
> >>> > ..
> >>> > "zoneid": "6e301be1-8010-4b57-9638-c90761e40dc9",
> >>> >"jobstatus": 0 
> >>> >}
> >>> >
> >>> >These attributes qualify a VM, but I'm not sure why jobstatus is in
> >>> >there. That's an attribute of the job itself which is CloudStack's
> >>> >concern, but not the VM's concern. When marvin looks to deserialize
> >>> >back to a VM object, it looks at the inner block only. I can
> >>> >workaround these within marvin, so feel free to reduce the priority
> >>> >if 

Re: [DOCS][TRANSLATIONS] Upate

[David Nalley]

On Thursday, April 25, 2013, Sebastien Goasguen wrote:

>
> On Apr 25, 2013, at 4:48 AM, Milamber >
> wrote:
>
> >
> >
> > Le 25/04/2013 08:05, Gavin Lee a ecrit :
> >> Done for zh_CN translation on transifex for master branch.
> >
> > Thanks. I just update the master branch.
> >
> >>
> >> For 2.2.xmessages for zh_CN, and also for ja, the encoding is incorrect
> and
> >> resource files are not maintained by community.
> >
> > Yes, the encoding's translation are incorrect.
> > I don't know where we can find the original 2.2 resource file to fix it.
> But I don't if we must maintain the version 2.2…
>
> No, IMHO we should only maintain 4.x + since those are the only Apache
> releases.
>
> as a side note, I noticed a Apache CloudStack UL project on transifex
> which has 16% translation of the UI in arabic. I had met the folks in Oman,
> and they wanted their own project to manage. However i don't know how to
> "import" their translations into our project.
>
>
>
Can you reach out to them via email and ask them to submit it via the
mailing list or RB? We really need it to be voluntarily submitted since
they did it externally to the project.

--David

RE: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Prachi Damle]

I will take a look at CLOUDSTACK-2158

-Prachi

-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com] 
Sent: Thursday, April 25, 2013 6:55 AM
To: dev@cloudstack.apache.org
Subject: [ACS41] Blocker and critical issues stopping me from spinning out a 
new RC for 4.1

Hi all,

The following bugs are currently blocking me from starting another 4.1.0 voting 
round.  Help please!

CLOUDSTACK-2158 'userconcentratedpod_firstfit failed to find alternate host to 
run VM   (Unassigned)
CLOUDSTACK-2172 Upgrade from 2.2.14 to 4.1.0 failed (Unassigned)
CLOUDSTACK-2190 DEB packaging does not package AWSAPI correctly (Chip Childers)
CLOUDSTACK-2126 Response objects of some entities contain job related 
information   (Unassigned)

I'll try to figure out CLOUDSTACK-2190.  The other three are currently 
unassigned.  If you can help resolve them, please step up!

-chip

RE: [ACS41] Allocator Expert Needed!

[Prachi Damle]

Looking at it.

-Prachi

-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com] 
Sent: Thursday, April 25, 2013 10:50 AM
To: dev@cloudstack.apache.org
Subject: [ACS41] Allocator Expert Needed!

CLOUDSTACK-2158 is a blocker bug for 4.1.0, and I need an allocator expert to 
review and fix if required.

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

'userconcentratedpod_firstfit failed to find alternate host to run VM

Marcus laid out the situation in the bug itself.

Help please!

-chip

RE: [ACS41] Allocator Expert Needed!

[Animesh Chaturvedi]

thanks

> -Original Message-
> From: Prachi Damle [mailto:prachi.da...@citrix.com]
> Sent: Thursday, April 25, 2013 10:56 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [ACS41] Allocator Expert Needed!
> 
> Looking at it.
> 
> -Prachi
> 
> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Thursday, April 25, 2013 10:50 AM
> To: dev@cloudstack.apache.org
> Subject: [ACS41] Allocator Expert Needed!
> 
> CLOUDSTACK-2158 is a blocker bug for 4.1.0, and I need an allocator expert to
> review and fix if required.
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-2158
> 
> 'userconcentratedpod_firstfit failed to find alternate host to run VM
> 
> Marcus laid out the situation in the bug itself.
> 
> Help please!
> 
> -chip

Re: [ACS41] Allocator Expert Needed!

[Marcus Sorensen]

I looked at it a bit, still beyond me, but the actual null pointer is:

for(HostAllocator allocator : _hostAllocators) {

_hostAllocators is locally defined in this file, but empty. I'm not sure
what should be calling 'setHostAllocators'.

   protected List _hostAllocators;
   public List getHostAllocators() {
return _hostAllocators;
}
public void setHostAllocators(List _hostAllocators) {
this._hostAllocators = _hostAllocators;
}



On Thu, Apr 25, 2013 at 11:49 AM, Chip Childers
wrote:

> CLOUDSTACK-2158 is a blocker bug for 4.1.0, and I need an allocator
> expert to review and fix if required.
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-2158
>
> 'userconcentratedpod_firstfit failed to find alternate host to run VM
>
> Marcus laid out the situation in the bug itself.
>
> Help please!
>
> -chip
>

RE: [ACS41] Allocator Expert Needed!

[Prachi Damle]

It should be set by Spring by looking at the applicationContext or 
componentContext

-Prachi
-Original Message-
From: Marcus Sorensen [mailto:shadow...@gmail.com] 
Sent: Thursday, April 25, 2013 10:58 AM
To: dev@cloudstack.apache.org
Subject: Re: [ACS41] Allocator Expert Needed!

I looked at it a bit, still beyond me, but the actual null pointer is:

for(HostAllocator allocator : _hostAllocators) {

_hostAllocators is locally defined in this file, but empty. I'm not sure what 
should be calling 'setHostAllocators'.

   protected List _hostAllocators;
   public List getHostAllocators() {
return _hostAllocators;
}
public void setHostAllocators(List _hostAllocators) {
this._hostAllocators = _hostAllocators;
}



On Thu, Apr 25, 2013 at 11:49 AM, Chip Childers
wrote:

> CLOUDSTACK-2158 is a blocker bug for 4.1.0, and I need an allocator 
> expert to review and fix if required.
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-2158
>
> 'userconcentratedpod_firstfit failed to find alternate host to run VM
>
> Marcus laid out the situation in the bug itself.
>
> Help please!
>
> -chip
>

RE: DISCUSS

[Prachi Damle]

Hi,

Comments Inline.

Thanks,
-Prachi
-Original Message-
From: MEHDI ALI SOLTANI [mailto:mehdi_alisolt...@yahoo.com] 
Sent: Thursday, April 25, 2013 8:34 AM
To: cloudstack-...@incubator.apache.org
Subject: DISCUSS

Hi
I am new in Devcloud and I want to push my algorithm in Devcloud.

I have two questions : 
 1) From where I should start, my mean is developing requirements.
>>>You should be able to find ample information on the Wiki, this is one link 
>>>to start at 
>>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Development+101

 2) I study on VMs scheduling and provisioning Algorithms please tell me which 
package is for scheduling and provisioning in Cloud Stack and also which 
scheduling policy is used in cloud stack by default.
 >>> Check out the com.cloud.deploy package under cloud-api and cloud-server 
projects, specifically the ' DeploymentPlanner' interface and its 
implementations.

Sincerely
Mehdi Ali Soltani

RE: [MERGE] UI support for VM affinity/anti-affinity groups

[Brian Federle]

Affinity/anti-affinity UI is now ready in master.

-Brian

-Original Message-
From: Brian Federle [mailto:brian.fede...@citrix.com] 
Sent: Monday, April 22, 2013 2:08 PM
To: dev@cloudstack.apache.org; Prachi Damle
Cc: Sonny Chhen; Animesh Chaturvedi; Jessica Wang
Subject: [MERGE] UI support for VM affinity/anti-affinity groups

Hi all,



I would like to merge the UI support for VM affinity/anti-affinity groups to 
master.



JIRA ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-2074

FS: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups

Branch: ui-vm-affinity

Unit tests: No new unit tests (UI only)



Discussion information: Please see backend discussion @ 
https://issues.apache.org/jira/browse/CLOUDSTACK-739

[Prachi, please add links to any other ML discussions if applicable]



RAT report:
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building Apache CloudStack 4.2.0-SNAPSHOT [INFO] 

[INFO]
[INFO] --- apache-rat-plugin:0.8:check (default-cli) @ cloudstack --- [INFO] 
Exclude: CHANGES [INFO] Exclude: INSTALL.md [INFO] Exclude: .idea/ [INFO] 
Exclude: *.log [INFO] Exclude: **/*.patch [INFO] Exclude: **/.classpath [INFO] 
Exclude: **/.project [INFO] Exclude: **/.idea/** [INFO] Exclude: **/*.iml 
[INFO] Exclude: **/.settings/** [INFO] Exclude: .metadata/** [INFO] Exclude: 
.git/** [INFO] Exclude: .gitignore [INFO] Exclude: **/*.crt [INFO] Exclude: 
**/*.csr [INFO] Exclude: **/*.key [INFO] Exclude: **/authorized_keys [INFO] 
Exclude: **/*.war [INFO] Exclude: **/*.mar [INFO] Exclude: **/*.jar [INFO] 
Exclude: **/*.iso [INFO] Exclude: **/*.tgz [INFO] Exclude: **/*.zip [INFO] 
Exclude: **/target/** [INFO] Exclude: **/.vagrant [INFO] Exclude: 
awsapi/overlays/** [INFO] Exclude: build/build.number [INFO] Exclude: 
services/console-proxy/server/js/jquery.js
[INFO] Exclude: debian/compat
[INFO] Exclude: debian/control
[INFO] Exclude: debian/dirs
[INFO] Exclude: debian/rules
[INFO] Exclude: deps/XenServerJava/src/com/xensource/xenapi/*.java
[INFO] Exclude: deps/XenServerJava/BSD
[INFO] Exclude: deps/XenServerJava/Makefile [INFO] Exclude: 
dist/console-proxy/js/jquery.js [INFO] Exclude: 
scripts/vm/systemvm/id_rsa.cloud [INFO] Exclude: 
services/console-proxy/server/conf/agent.properties
[INFO] Exclude: services/console-proxy/server/conf/environment.properties
[INFO] Exclude: services/secondary-storage/conf/agent.properties
[INFO] Exclude: services/secondary-storage/conf/environment.properties
[INFO] Exclude: 
tools/devcloud/basebuild/puppet-devcloudinitial/files/network.conf
[INFO] Exclude: tools/appliance/definitions/devcloud/*
[INFO] Exclude: tools/appliance/definitions/systemvmtemplate/*
[INFO] Exclude: tools/appliance/definitions/systemvmtemplate64/*
[INFO] Exclude: tools/cli/cloudmonkey.egg-info/* [INFO] Exclude: 
tools/devcloud/src/deps/boxes/basebox-build/definition.rb
[INFO] Exclude: tools/devcloud/src/deps/boxes/basebox-build/preseed.cfg
[INFO] Exclude: tools/marvin/Marvin.egg-info/* [INFO] Exclude: 
ui/lib/flot/jquery.colorhelpers.js
[INFO] Exclude: ui/lib/flot/jquery.flot.crosshair.js
[INFO] Exclude: ui/lib/flot/jquery.flot.fillbetween.js
[INFO] Exclude: ui/lib/flot/jquery.flot.image.js [INFO] Exclude: 
ui/lib/flot/jquery.flot.js [INFO] Exclude: ui/lib/flot/jquery.flot.navigate.js
[INFO] Exclude: ui/lib/flot/jquery.flot.pie.js [INFO] Exclude: 
ui/lib/flot/jquery.flot.resize.js [INFO] Exclude: 
ui/lib/flot/jquery.flot.selection.js
[INFO] Exclude: ui/lib/flot/jquery.flot.stack.js [INFO] Exclude: 
ui/lib/flot/jquery.flot.symbol.js [INFO] Exclude: 
ui/lib/flot/jquery.flot.threshold.js
[INFO] Exclude: ui/lib/jquery-ui/css/jquery-ui.css
[INFO] Exclude: ui/lib/jquery-ui/index.html [INFO] Exclude: 
ui/lib/jquery-ui/js/jquery-ui.js [INFO] Exclude: ui/lib/jquery.cookies.js 
[INFO] Exclude: ui/lib/jquery.easing.js [INFO] Exclude: ui/lib/jquery.js [INFO] 
Exclude: ui/lib/jquery.md5.js [INFO] Exclude: ui/lib/jquery.validate.js [INFO] 
Exclude: ui/lib/qunit/qunit.css [INFO] Exclude: ui/lib/qunit/qunit.js [INFO] 
Exclude: ui/lib/reset.css [INFO] Exclude: ui/lib/require.js [INFO] Exclude: waf 
[INFO] Exclude: patches/systemvm/debian/systemvm.vmx
[INFO] Exclude: patches/systemvm/debian/config/root/.ssh/authorized_keys
[INFO] Exclude: patches/systemvm/debian/config/etc/apache2/httpd.conf
[INFO] Exclude: patches/systemvm/debian/config/etc/apache2/ports.conf
[INFO] Exclude: 
patches/systemvm/debian/config/etc/apache2/sites-available/default
[INFO] Exclude: 
patches/systemvm/debian/config/etc/apache2/sites-available/default-ssl
[INFO] Exclude: patches/systemvm/debian/config/etc/apache2/vhostexample.conf
[INFO] Exclude: patches/systemvm/debian/config/etc/dnsmasq.conf
[INFO] Exclude: patches/systemvm/debian/config/etc/vpcdnsmasq.conf
[INFO] Exclude: patches/systemvm/debian/config/etc/ssh/sshd_config
[INFO] Exclude: pat

RE: [ACS41] Allocator Expert Needed!

[Prachi Damle]

Found the issue, in the applicationContext .xml , the context of the 
'UserConcentratedPodPlanner' needs to include the list of allocators.
This will ensure that when this component is loaded by Spring, the allocators 
gets initialized.

Will put in the fix now.

Thanks,
Prachi

-Original Message-
From: Prachi Damle [mailto:prachi.da...@citrix.com] 
Sent: Thursday, April 25, 2013 11:00 AM
To: dev@cloudstack.apache.org
Subject: RE: [ACS41] Allocator Expert Needed!

It should be set by Spring by looking at the applicationContext or 
componentContext

-Prachi
-Original Message-
From: Marcus Sorensen [mailto:shadow...@gmail.com]
Sent: Thursday, April 25, 2013 10:58 AM
To: dev@cloudstack.apache.org
Subject: Re: [ACS41] Allocator Expert Needed!

I looked at it a bit, still beyond me, but the actual null pointer is:

for(HostAllocator allocator : _hostAllocators) {

_hostAllocators is locally defined in this file, but empty. I'm not sure what 
should be calling 'setHostAllocators'.

   protected List _hostAllocators;
   public List getHostAllocators() {
return _hostAllocators;
}
public void setHostAllocators(List _hostAllocators) {
this._hostAllocators = _hostAllocators;
}



On Thu, Apr 25, 2013 at 11:49 AM, Chip Childers
wrote:

> CLOUDSTACK-2158 is a blocker bug for 4.1.0, and I need an allocator 
> expert to review and fix if required.
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-2158
>
> 'userconcentratedpod_firstfit failed to find alternate host to run VM
>
> Marcus laid out the situation in the bug itself.
>
> Help please!
>
> -chip
>

Re: [DISCUSS] Making simple installs easier.

[David Nalley]

On Thursday, April 25, 2013, Jörgen Maas wrote:

> As a new user (as of today) i can say the following from my personal
> experience:
>
>
Welcome - and thanks for pushing the feedback.


> The biggest hurdle (in an enterprise setting) is getting the packages for
> your platform.Building packages from source is nice and all, but in my case
> i don't have Internet access in the datacenter. So the whole maven stuff is
> pretty much a big time burner (there's also a bug somewhere wrt to calling
> /usr/bin/mvn when there's only /usr/bin/mvn3 as per the docs). I also had
> to downgrade tomcat to work around some bugs where the management service
> would just shutdown (Ubuntu 12.04 LTS).
>
>
Please file a bug for the tomcat issue.


> When the issues surrounding the packages were resolved and the management
> service was up and running it was pretty much smooth sailing from there on
> (except for the systemvm stuff).
>
> So from my point of view it would make much more sense to first align the
> releases more with the targeted distro's and provide repo's for those
> distro's.
>
>
The project officially doesn't release binaries at all - but we have some
enterprising contributors who have done just that.
Debs for Ubuntu are here:
http://cloudstack.apt-get.eu/ubuntu
RPMs for EL6 are here:
http://cloudstack.apt-get.eu/rhel/4.0/

The above site is maintained by Wido den Hollander who is a committer and
PMC member for CloudStack.

Trouble running CS MS from Eclipse

[Mike Tutkowski]

Hi,

I'm getting an out of memory error when trying to run the management server
from Eclipse.

In my Debug Configuration, for my Goal I use the following:

-pl client jetty:run

Under the Environment tab, I have MAVEN_OPTS set to the following:

-XX:MaxPermSize=1024m -Xmx1024m -Xdebug
-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n

Any thoughts on this?  Originally, I had 512 for MaxPermSize, but I bumped
it up to 1024 to see if that would fix the problem.

Thanks!!

java.lang.OutOfMemoryError: PermGen space

at java.lang.ClassLoader.findBootstrapClass(Native Method)

at java.lang.ClassLoader.findBootstrapClassOrNull(ClassLoader.java:926)

at java.lang.ClassLoader.loadClass(ClassLoader.java:297)

at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(
ClassRealm.java:239)

at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(
ClassRealm.java:230)

at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(
WebAppClassLoader.java:378)

at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(
WebAppClassLoader.java:363)

at org.apache.log4j.helpers.SyslogWriter.write(SyslogWriter.java:130)

at org.apache.log4j.helpers.QuietWriter.write(QuietWriter.java:48)

at org.apache.log4j.helpers.SyslogQuietWriter.write(
SyslogQuietWriter.java:54)

at org.apache.log4j.net.SyslogAppender.append(SyslogAppender.java:338)

at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)

at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(
AppenderAttachableImpl.java:66)

at org.apache.log4j.Category.callAppenders(Category.java:206)

at org.apache.log4j.Category.forcedLog(Category.java:391)

at org.apache.log4j.Category.log(Category.java:856)

at org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:257)

at org.springframework.web.context.ContextLoader.initWebApplicationContext(
ContextLoader.java:307)

at org.springframework.web.context.ContextLoaderListener.contextInitialized(
ContextLoaderListener.java:111)

at org.mortbay.jetty.handler.ContextHandler.startContext(
ContextHandler.java:549)

at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)

at org.mortbay.jetty.webapp.WebAppContext.startContext(
WebAppContext.java:1282)

at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518)

at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499)

at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(
Jetty6PluginWebAppContext.java:115)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)

at org.mortbay.jetty.handler.HandlerCollection.doStart(
HandlerCollection.java:152)

at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(
ContextHandlerCollection.java:156)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)

at org.mortbay.jetty.handler.HandlerCollection.doStart(
HandlerCollection.java:152)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)

at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)

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

[ACS41] new critical bug

[Marcus Sorensen]

I didn't mark this one as a blocker, but it's still pretty bad for someone
managing VMs in an automated fashion. Trying to stop a VM when the KVM
agent is disconnected reports success.

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

Re: [ACS41] new critical bug

[Chip Childers]

On Thu, Apr 25, 2013 at 02:01:56PM -0600, Marcus Sorensen wrote:
> I didn't mark this one as a blocker, but it's still pretty bad for someone
> managing VMs in an automated fashion. Trying to stop a VM when the KVM
> agent is disconnected reports success.
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-2195

I'll pull a fix in, if we have one ready before the final blockers.
Otherwise I'd pull it into a 4.1.1 release.

Re: [DOCS][TRANSLATIONS] Upate

[Sebastien Goasguen]

On Apr 25, 2013, at 1:54 PM, David Nalley  wrote:

> On Thursday, April 25, 2013, Sebastien Goasguen wrote:
> 
>> 
>> On Apr 25, 2013, at 4:48 AM, Milamber >
>> wrote:
>> 
>>> 
>>> 
>>> Le 25/04/2013 08:05, Gavin Lee a ecrit :
 Done for zh_CN translation on transifex for master branch.
>>> 
>>> Thanks. I just update the master branch.
>>> 
 
 For 2.2.xmessages for zh_CN, and also for ja, the encoding is incorrect
>> and
 resource files are not maintained by community.
>>> 
>>> Yes, the encoding's translation are incorrect.
>>> I don't know where we can find the original 2.2 resource file to fix it.
>> But I don't if we must maintain the version 2.2…
>> 
>> No, IMHO we should only maintain 4.x + since those are the only Apache
>> releases.
>> 
>> as a side note, I noticed a Apache CloudStack UL project on transifex
>> which has 16% translation of the UI in arabic. I had met the folks in Oman,
>> and they wanted their own project to manage. However i don't know how to
>> "import" their translations into our project.
>> 
>> 
>> 
> Can you reach out to them via email and ask them to submit it via the
> mailing list or RB? We really need it to be voluntarily submitted since
> they did it externally to the project.

I will if it's needed.

There is a more problematic issue with arabic that milamber raised: the ui is 
not setup to do right to left rendering….

-sebastien


> 
> --David

RE: https://issues.apache.org/jira/browse/CLOUDSTACK-101 Cent OS 6.3 OVS support in KVM

[Angeline Shen]

Hugo:

1. Your instructions here are for CentOS 6.4 environment.

However,  ASF 4.2   Cloudstack   is  currently only supported on CentOS 6.3,
 **   NOT CentOS 6.4   **
  Since ASF 4.2 Cloudstack has product features  requiring openvswitch 
support ,
 That is why we need to have openvswitch  (1.7.1 probably)  running on CentOS 
6.3   for ASF 4.2 Cloudstack.   **  NOT CENTOS 6.4  **

Also,  ASF  4.2  Cloudstack  has not been tested on CentOS 6.4 yet.
There are no ASF 4.2  cloudstack builds available  on CentOS 6.4

We need ASF 4.2 Cloudstack openvswitch running and tested  on   CENTOS 6.3.

Therefore I have been installing  libvirt-0.10.1   and openvswitch-1.7.1
on CentOS 6.3   in CentOS 6.3

Will your  configurations  work  on CentOS 6.3  ?



2.   Your instruction  in installing cloudstack-agent:

# yum install cloudstack-agent

What version of cloudstack-agent are you installing?

Please show content of   your  /etc/repos.d/  ?

There is no cloudstack-agent  on CentOS 6.4 yet.


2. What is the sectionon==  
centos64-openvswitch.patch ==about?


3. In CentOS 6.3,  only  libvirt-0.9.10  is available.   Cloudstack-agent 
installation installs   libvirt-0.9.10
  Therefore I had to installand overlaylibvirt-0.10.1over   
libvirt-0.9.10


4.   Your response   to my previous email about your openvswitch example To my 
question of commands  for openswitch  configuration  :
> ovs-vsctl add-br br0
> ovs-vsctl add-port br0 eth1

The redhat network configuration should take care of creating all the bridges 
and linking the ports. But yes the configuration above should have the same 
effect as these two commands.

Do you mean there is  NO NEED to execute  these two  commands at all as long as 
the files are configured,
Because  these commands are listed in ACS installation guide for openvswitch 
configuration, and upon executing the
Second command  ovs-vsctl add-port  br0  eth1the host  lost network 
connection ?


Thanks



-Original Message-
From: Hugo Trippaers [mailto:htrippa...@schubergphilis.com]
Sent: Thursday, April 25, 2013 6:19 AM
To: Angeline Shen; ''; Sheng Yang; Edison Su
Subject: RE: https://issues.apache.org/jira/browse/CLOUDSTACK-101 OVS support 
in KVM

Heya,

Comments inline.

I ran through the entire procedure I use to test the setup and documented it as 
detailed as possible. Hope this helps:

#
# CentOS KVM installation
#

Base installation:
CentOS 6.2 Basic Server

Upgraded to CentOS 6.4:
# yum update

Install Virtualization tools
# yum groupinstall Virtualization "Virtualization Client" 
"Virtualization Platform" "Virtualization Tools"

Verify Installed:
  hypervkvpd.x86_64 0:0-0.9.el6libguestfs.x86_64 
1:1.16.34-2.el6  libvirt.x86_64 0:0.10.2-18.el6_4.3
  libvirt-client.x86_64 0:0.10.2-18.el6_4.3python-virtinst.noarch 
0:0.600.0-15.el6qemu-kvm.x86_64 2:0.12.1.2-2.355.0.1.el6.centos.2
  virt-manager.x86_64 0:0.9.0-18.el6   virt-top.x86_64 
0:1.0.4-3.15.el6   virt-viewer.x86_64 0:0.5.2-18.el6_4.2

Modify libvirt configuration:
Edit /etc/libvirt/libvirtd.conf
listen_tls = 0
listen_tcp = 1
tcp_port = 16059
auth_tcp = "none"
mdns_adv = 0

Edit /etc/sysconfig/libvirtd
LIBVIRTD_ARGS="--listen"

Start libvirtd
   # /etc/init.d/libvirtd start
   # /etc/init.d/libvirtd status

Verify installation:
  # virsh capabilities
  - Should list two guest tags with os_type hvm

Build and install openvswitch:
  Install build requirements:
 # yum install rpmdevtools openssl-devel kernel-devel gcc redhat-rpm-config

  Build packages:
 # mkdir -p ~/rpmbuild/SOURCES
 # curl -O http://openvswitch.org/releases/openvswitch-1.9.0.tar.gz
 # cp openvswitch-1.9.0.tar.gz ~/rpmbuild/SOURCES
 # cp centos64-openvswitch.patch ~/rpmbuild/SOURCES
 # tar -xzf openvswitch-1.9.0.tar.gz
 # cd openvswitch-1.9.0
 # patch -p1 < ~/rpmbuild/SOURCES/centos64-openvswitch.patch
 # rpmbuild -bb rhel/openvswitch.spec
 # rpmbuild -bb -D "kversion `uname -r`" 
rhel/openvswitch-kmod-rhel6.spec

  Install openvswitch:
# yum install 
~/rpmbuild/RPMS/x86_64/kmod-openvswitch-1.9.0-1.el6.x86_64.rpm 
~/rpmbuild/RPMS/x86_64/openvswitch-1.9.0-1.x86_64.rpm
# echo 'blacklist bridge' >> /etc/modprobe.d/blacklist.conf
# reboot

  Verify installation:
# lsmod |grep openvswitch
# ovs-vsctl -V

Network design:
  cloudbr0 (Management, Storage)
ip: 172.16.10.10/24
gateway: 172.16.10.1
eth0 (physical port, no vlans)
  cloudbr1 (Guest, Public)
eth1 (physical port, vlan trunk)
ip: none

Configure network interfaces:
   /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
IPV6INIT=no
NM_CONTROLLED=

Re: [DOCS][TRANSLATIONS] Upate

[Milamber]

Le 25/04/2013 20:18, Sebastien Goasguen a ecrit :

On Apr 25, 2013, at 1:54 PM, David Nalley  wrote:


On Thursday, April 25, 2013, Sebastien Goasguen wrote:


On Apr 25, 2013, at 4:48 AM, Milamber >
wrote:



Le 25/04/2013 08:05, Gavin Lee a ecrit :

Done for zh_CN translation on transifex for master branch.

Thanks. I just update the master branch.


For 2.2.xmessages for zh_CN, and also for ja, the encoding is incorrect

and

resource files are not maintained by community.

Yes, the encoding's translation are incorrect.
I don't know where we can find the original 2.2 resource file to fix it.

But I don't if we must maintain the version 2.2…

No, IMHO we should only maintain 4.x + since those are the only Apache
releases.

as a side note, I noticed a Apache CloudStack UL project on transifex
which has 16% translation of the UI in arabic. I had met the folks in Oman,
and they wanted their own project to manage. However i don't know how to
"import" their translations into our project.




Can you reach out to them via email and ask them to submit it via the
mailing list or RB? We really need it to be voluntarily submitted since
they did it externally to the project.

I will if it's needed.

There is a more problematic issue with arabic that milamber raised: the ui is 
not setup to do right to left rendering….


Seb,

I have make a test with success (I think) to display arabic translation 
of  Web UI on dashboard. (To work, need to remove one sequence "\n" in 
AR resource from CS UL project)


http://awesomescreenshot.com/07817h5gc6

A control to  word "Dashboard" (Arabic is display correctly) (even if 
the alignment is not at right, the text is RTL)

http://awesomescreenshot.com/03317h5o82

IMO, I would better to manage the arabic translation directly into CS UI 
project in transifex.


Milamber



-sebastien



--David

Out of Memory while attempting a Run

[Parth Jagirdar]

mvn -pl :cloud-client-ui jetty:run

Hangs at following.. With out of memory.
Suggestions?

System…Info
Running OS X,
Tomcat 6.0.33,
java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06-451-11M4406)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01-451, mixed mode)

(One hiccup I recall is.. Brew install cdrtools didn't go through well 
(Could'nt link at the end) but then mkisofs is at desired location 
/usr/local/bin; this one was downloaded from Helios link.. Not sure if this 
would matter)


pNicMappingDaoImpl,niciraNvpRouterMappingDaoImpl,NiciraNvpGuestNetworkGuru,NiciraNvp,MidoNetGuestNetworkGuru,MidoNetElement,userAuthenticators,userPasswordEncoders,securityCheckers,resourceDiscoverers,haInvestigators,haFenceBuilders,deploymentPlanners,podAllocators,hostAllocators,storagePoolAllocators,ipDeployers,dhcpProviders,networkGurus,networkElements,HostAntiAffinityProcessor,affinityProcessors,org.springframework.context.annotation.ConfigurationClassPostProcessor$ImportAwareBeanPostProcessor#0];
 root of factory hierarchy
INFO  [utils.component.ComponentContext] (main:) Setup Spring Application 
context
^C^CJava HotSpot(TM) 64-Bit Server VM warning: Exception 
java.lang.OutOfMemoryError occurred dispatching signal Unknown Signal to 
handler- the VM may need to be forcibly terminated
^CJava HotSpot(TM) 64-Bit Server VM warning: Exception 
java.lang.OutOfMemoryError occurred dispatching signal Unknown Signal to 
handler- the VM may need to be forcibly terminated
Java HotSpot(TM) 64-Bit Server VM warning: Exception java.lang.OutOfMemoryError 
occurred dispatching signal Unknown Signal to handler- the VM may need to be 
forcibly terminated



Thanks,
.. Parth

RE: https://issues.apache.org/jira/browse/CLOUDSTACK-101 Cent OS 6.3 OVS support in KVM

[Hugo Trippaers]

Hey Angeline,

> -Original Message-
> From: Angeline Shen [mailto:angeline.s...@citrix.com]
> Sent: donderdag 25 april 2013 23:07
> To: Hugo Trippaers; ''; Sheng Yang; Edison Su
> Subject: RE: https://issues.apache.org/jira/browse/CLOUDSTACK-101 Cent
> OS 6.3 OVS support in KVM
> 
> Hugo:
> 
> 1. Your instructions here are for CentOS 6.4 environment.
> 
> However,  ASF 4.2   Cloudstack   is  currently only supported on CentOS 6.3,
> **   NOT CentOS 6.4   **
>   Since ASF 4.2 Cloudstack has product features  requiring openvswitch
> support ,
>  That is why we need to have openvswitch  (1.7.1 probably)  running on
> CentOS 6.3   for ASF 4.2 Cloudstack.   **  NOT CENTOS 6.4  **
> 
> Also,  ASF  4.2  Cloudstack  has not been tested on CentOS 6.4 yet.
> There are no ASF 4.2  cloudstack builds available  on CentOS 6.4

CloudStack 4.2 is perfectly supported on CentOS 6.4. The RPM packages are all 
developed on CentOS 6.4, so for that matter CentOS 6.3 is less supported ;-)

But this is actually irrelevant. CentOS has dropped the release strategy with 
minor version numbers to a certain degree. If you read my instructions I 
actually started with a CentOS 6.2 system, running a yum update like regular 
users would do will upgrade the entire system to the latest version available. 
CentOS 6 is the actual release and the minor numbers are only place holders for 
certain releases. You need to upgrade the system to get the latest security 
fixes and so you will end up with a CentOS 6.4 system. CloudStack supports 
CentOS 6 and has been tested on CentOS 6.

> 
> We need ASF 4.2 Cloudstack openvswitch running and tested  on   CENTOS
> 6.3.
> 
> Therefore I have been installing  libvirt-0.10.1   and openvswitch-1.7.1  
>   on
> CentOS 6.3   in CentOS 6.3
> 
> Will your  configurations  work  on CentOS 6.3  ?

As explained above there is no actual difference for CentOS 6.3 and 6.4 in 
setup. So the instructions will work regardless. The only thing you need to be 
aware of is the kernel version. My instructions regarding compiling openvswitch 
are specific to the current most recent version of the CentOS 6 kernel. So you 
need to upgrade at least that to work with these instructions.

> 
> 
> 
> 2.   Your instruction  in installing cloudstack-agent:
> 
> # yum install cloudstack-agent
> 
> What version of cloudstack-agent are you installing?
> 
> Please show content of   your  /etc/repos.d/  ?
> 
> There is no cloudstack-agent  on CentOS 6.4 yet.

I'm installing from my own repository with cloudstack packages which is updated 
on every build. I think I used the 4.1 branch here, because that is default in 
my repo. But there have been no noticeable changes for OVS support in 4.2 yet.
> 
> 
> 2. What is the sectionon==  centos64-
> openvswitch.patch ==about?

It's a patch I developed to support openvswitch with the latest kernel version 
of CentOS. The way redhat does kernel updates regularly conflicts with the 
compatibility settings in openvswitch. You need to apply this patch on 
openvswitch 1.9.0 to make it compile on the latest CentOS 6 kernel.
> 
> 
> 3. In CentOS 6.3,  only  libvirt-0.9.10  is available.   Cloudstack-agent
> installation installs   libvirt-0.9.10
>   Therefore I had to installand overlaylibvirt-0.10.1over   
> libvirt-0.9.10

I used a fully updated CentOS 6.2 release (effectively 6.4). You should 
consider these instructions for an updated system.
> 
> 
> 4.   Your response   to my previous email about your openvswitch example To
> my question of commands  for openswitch  configuration  :
> > ovs-vsctl add-br br0
> > ovs-vsctl add-port br0 eth1
> 
> The redhat network configuration should take care of creating all the bridges
> and linking the ports. But yes the configuration above should have the same
> effect as these two commands.
> 
> Do you mean there is  NO NEED to execute  these two  commands at all as
> long as the files are configured, Because  these commands are listed in ACS
> installation guide for openvswitch configuration, and upon executing the
> Second command  ovs-vsctl add-port  br0  eth1the host  lost network
> connection ?

You don't need to execute these commands. Thanks for pointing this out, I'll 
update the documentation to make this more clear.


> 
> 
> Thanks
> 
> 
> 
> -Original Message-
> From: Hugo Trippaers [mailto:htrippa...@schubergphilis.com]
> Sent: Thursday, April 25, 2013 6:19 AM
> To: Angeline Shen; ''; Sheng Yang; Edison Su
> Subject: RE: https://issues.apache.org/jira/browse/CLOUDSTACK-101 OVS
> support in KVM
> 
> Heya,
> 
> Comments inline.
> 
> I ran through the entire procedure I use to test the setup and documented it
> as detailed as possible. Hope this helps:
> 
> #
> # CentOS KVM installation
> #
> 
> Base installation:
> CentOS 6.2 Basic Server
> 
> Upgraded to CentOS 6.4:
> # yum update
> 
> Install Virtualization tools
> # yum groupinstal

RE: [DOC][Review] Document ability to delete events and alerts

[Parth Jagirdar]

Looks good to me.

Thanks,
.. Parth


-Original Message-
From: Radhika Puthiyetath [mailto:radhika.puthiyet...@citrix.com] 
Sent: Wednesday, April 24, 2013 11:02 PM
To: dev@cloudstack.apache.org; Sanjay Tripathi
Subject: [DOC][Review] Document ability to delete events and alerts

Hi,

Documentation for delete/archive events and alerts are ready.

The doc draft is posted to https://issues.apache.org/jira/browse/CLOUDSTACK-1567

Please share your comments.

Thanks
-Radhika

RE: [ACS41] Allocator Expert Needed!

[Prachi Damle]

Chip,

I just added the fix for CLOUDSTACK-2158  to master. Here is the commit info to 
cherry-pick:


Commit hash:232d44bf6e31898887b324bcdebbc659423917e4

In the applicationContext .xml , the context of the 
'UserConcentratedPodPlanner' needs to include the list of allocators.
This will ensure that when this component is loaded by Spring, the allocators 
gets initialized.

Contained in branches: master
Contained in no tag

Thanks,
Prachi

-Original Message-
From: Prachi Damle [mailto:prachi.da...@citrix.com] 
Sent: Thursday, April 25, 2013 11:22 AM
To: dev@cloudstack.apache.org
Subject: RE: [ACS41] Allocator Expert Needed!

Found the issue, in the applicationContext .xml , the context of the 
'UserConcentratedPodPlanner' needs to include the list of allocators.
This will ensure that when this component is loaded by Spring, the allocators 
gets initialized.

Will put in the fix now.

Thanks,
Prachi

-Original Message-
From: Prachi Damle [mailto:prachi.da...@citrix.com]
Sent: Thursday, April 25, 2013 11:00 AM
To: dev@cloudstack.apache.org
Subject: RE: [ACS41] Allocator Expert Needed!

It should be set by Spring by looking at the applicationContext or 
componentContext

-Prachi
-Original Message-
From: Marcus Sorensen [mailto:shadow...@gmail.com]
Sent: Thursday, April 25, 2013 10:58 AM
To: dev@cloudstack.apache.org
Subject: Re: [ACS41] Allocator Expert Needed!

I looked at it a bit, still beyond me, but the actual null pointer is:

for(HostAllocator allocator : _hostAllocators) {

_hostAllocators is locally defined in this file, but empty. I'm not sure what 
should be calling 'setHostAllocators'.

   protected List _hostAllocators;
   public List getHostAllocators() {
return _hostAllocators;
}
public void setHostAllocators(List _hostAllocators) {
this._hostAllocators = _hostAllocators;
}



On Thu, Apr 25, 2013 at 11:49 AM, Chip Childers
wrote:

> CLOUDSTACK-2158 is a blocker bug for 4.1.0, and I need an allocator 
> expert to review and fix if required.
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-2158
>
> 'userconcentratedpod_firstfit failed to find alternate host to run VM
>
> Marcus laid out the situation in the bug itself.
>
> Help please!
>
> -chip
>

Re: [ACS41] Blocker and critical issues stopping me from spinning out a new RC for 4.1

[Min Chen]

I did further analysis on the issue (CLOUDSTACK-2126)  and checked the
code back in 3.0.x and 4.0 branch, and found the following:
1. Showing pending job information for ListXXX api has been broken since
3.0.6. Based on ML discussion, this feature is requested by customers, so
we should fix this in 4.1. For this, I created this bug
(https://issues.apache.org/jira/browse/CLOUDSTACK-2196) for this issue.
2. The main issue reported by Prasanna in
https://issues.apache.org/jira/browse/CLOUDSTACK-2126 is more or less
caused by CLOUDSTACK-2196. Due to empty instance_type column in async_job
table, UserVmResponse will always have an incorrect job status for the
newly created DB view. If CLOUDSTACK-2196 is fixed, we will have the
following expected behavior: async job information will not show up in the
completed VM and will only show up in the pending VM.
Based on these new investigation, I think that we need to fix these two
bugs in 4.1.0, and assigned to myself to address them. Should be able to
submit a patch for them by the end of today.

Thanks
-min


On 4/25/13 10:52 AM, "Will Chan"  wrote:

>Alena is right.  They were introduced eons ago for customers to figure
>out which objects still had pending jobs on them without having the need
>to know the async job ID in the first place.  I'm not sure who's using
>that now but if you remove it, it may cause existing customers that do
>rely on this.
>
>Will
>
>> -Original Message-
>> From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
>> Sent: Thursday, April 25, 2013 10:48 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [ACS41] Blocker and critical issues stopping me from
>>spinning
>> out a new RC for 4.1
>> 
>> JobId/JobStatus were introduced to the list* responses on purpose. Some
>> of the CS customers wanted to see what async jobs that are currently
>>being
>> executed on the object, just by looking at the result of list* command.
>> 
>> So removing async job params from the list response is not a good idea
>>as
>> customers' software might rely on its presence.
>> 
>> On 4/25/13 10:32 AM, "Min Chen"  wrote:
>> 
>> >Totally agree.
>> >
>> >Chip and others, Prasanna and I exchanged ideas about CLOUDSTACK--
>> 2126,
>> >and we both agree that we should only return async job Id and job
>> >status in queryAsyncJob and listAsyncJob commands, not in any other
>> >APIs so that we can have consistent response return in various
>> >scenarios.  If we fix this way, the behavior for listXXX api is
>> >changed. In 4.0, CloudStack has used ApiServer.buildAsyncListResponse()
>> >routine to fill in async job Id and status for all listXXX Apis.  With
>> >the proposed fix, we will not show async job information in listXXX
>> >response as well. Not sure if anybody see any side effect on this
>> >slight change from 4.0? Anybody know the reason why we had that special
>> code in 4.0 to return async job for listXXX api?
>> >Since the proposed change will affect all newly created db view in 4.1,
>> >we suggest that this can be fixed in 4.2 since current behavior is not
>> >breaking functionalities, just return more information. Any thoughts?
>> >
>> >Thanks
>> >-min
>> >
>> >
>> >
>> >
>> >
>> >
>> >On 4/25/13 10:05 AM, "Prasanna Santhanam"  wrote:
>> >
>> >>That's odd - listXxx commands don't do async at all and shouldn't be
>> >>generating jobstatus,jobid etc. So I'm not sure why that was added in
>> >>(prior?) 4.0. I'd like to take that out too if there's no real reason
>> >>behind it.
>> >>
>> >>--
>> >>Prasanna.,
>> >>
>> >>On Thu, Apr 25, 2013 at 09:57:02AM -0700, Min Chen wrote:
>> >>> In 4.0, CS has special code to return job status for a VM returned
>> >>>from  listVMsCmd. During API performance refactoring, I have a
>> >>>created a DB view  user_vm_view that joins async_job table just for
>> >>>that purpose and used  that view to uniformly generate
>> >>>UserVmResponse. So the same code will be  applied to generate
>> >>>UserVmResponse whenever it is used. In this case,  deployVMCmd itself
>> >>>will also return a UserVmResponse, thus the same code  applied, and
>> >>>so that is what you see. If we all agree that job status  should not
>> >>>appear in UserVmResponse, then I can change the view to remove  job
>> >>>from async_job. But I would argue that we should not return jobStatus
>> >>>in ListVmsCmd as well, this will also be a change from 4.0 release.
>> >>>
>> >>> Thanks
>> >>> -min
>> >>>
>> >>> On 4/25/13 9:48 AM, "Prasanna Santhanam" 
>> wrote:
>> >>>
>> >>> >On Thu, Apr 25, 2013 at 09:30:08AM -0700, Min Chen wrote:
>> >>> >> Prasanna, I updated CLOUDSTACK-2126 with my comment. That is
>> the
>> >>> >>intended  change done in list API performance improvement work,
>> >>> >>and I don't
>> >>>see
>> >>> >>any
>> >>> >> issues by having the consistent UserVmResponse for both
>> >>> >>deployVMCmd
>> >>>and
>> >>> >> listVMsCmd. Every BaseResponse class has jobId and jobStatus as
>> >>> >>serialized  fields, I don't see why marvin has issues in
>>