[ACS42][QA]Limit Resources - Internal Error when there are no resources available

[Sailaja Mada]

Hi,

I have set the limit to use x amount of resources for the Domain Admin account. 
When there are not enough resources available and tried to deploy VM,  this 
user gets the message as "Internal error executing command, please contact your 
system administrator"  .

Only in the Management Server log  , root user can get the reason why it failed 
as INFO Message : 2013-04-03 11:50:59,813 INFO  [cloud.api.ApiServer] 
(catalina-exec-18:null) Maximum number of resources of type 'cpu' for domain 
id=3 has been exceeded."

Is there any reason why we can not provide the root cause for failure to Child 
Domain Account ?

Thanks,
Sailaja.M

Re: deleteStoragePool API Command

[Mike Tutkowski]

Yeah...I wasn't sure if the GUI was somehow making you walk through the
Maintenance mode before deleting the Primary Storage and you could maybe
circumvent that with a parameter to the deleteStoragePool API call.

Sounds like you cannot do so.  :)

On a related note, can you enlighten me a bit about what "Force" means when
deleting Primary Storage?

On Tue, Apr 2, 2013 at 10:57 PM, Pranav Saxena wrote:

> Had that not been the case , then it would have been a Contradiction in
> itself :D   After all the UI triggers the API's , so if you trigger them
> manually or from the UI , the behavior has to be the same .  Just that you
> might get some more flexibility with the API's in certain cases but there
> can't be a behavioral change in the API .
>
> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Wednesday, April 03, 2013 1:14 AM
> To: cloudstack-...@incubator.apache.org
> Subject: Re: deleteStoragePool API Command
>
> Spoke too soon. :)
>
> I just ran a quick test and you do have to put the Primary Storage in
> maintenance mode prior to deleting it with the API, too.
>
>
> On Tue, Apr 2, 2013 at 1:37 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com
> > wrote:
>
> > Hi,
> >
> > Is it required that a primary storage be in maintenance mode before
> > calling the deleteStoragePool API command?
> >
> > In the GUI, you have to do this, but I wasn't sure if it was the same
> > for the API.
> >
> > Thanks!
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud
> > *(tm)*
> >
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *(tm)*
>



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

[ACS41][Patch Request]

[Marcus Sorensen]

Commit 04a511a1a828a829962681525780f80935a161f9 in branch refs/heads/master
from Marcus Sorensen 
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=04a511a ]

CLOUDSTACK-1900  :
Save a default db.properties during upgrade, and make sure
we only pull the old configs once.

Re: [DISCUSS] Upgrade from 4.0 -> 4.1 ( components.xml and db.propetries)

[Marcus Sorensen]

People aren't required to set up the awsapi, right? Many won't need it.
Just wondering if it should be reflected as optional.

For #2, we should tell them to add the lines to their db.properties, but
also save the example db.properties. I've pushed a commit to save the
example one for RPM installations, although it doesn't do much to solve the
issue since the user still needs to either copy their existing config into
it or modify their existing config adding the lines you mention.




On Tue, Apr 2, 2013 at 8:23 PM, Sangeetha Hariharan <
sangeetha.hariha...@citrix.com> wrote:

> Wanted to discuss about how to deal with components.xml and db.properties
> when upgrading from 4.0 ->4.1.
>
>
> 1. If someone has made changes to your existing copy of the file
> components.xml in your previous-version CloudStack installation , after
> upgrade they will have to translate these changes into the current
> componentContext.xml file  which is located in
> /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/componentContext.xml.
> This step needs to be documented in the upgrade procedure.
>
> Had a question here. Should we ideally maintain the location of the
> componentContext.xml to be the same as it was in 4.0? It is now present in
> a completely different location.
>
>
>
> 2. When we upgrade from 4.0 to 4.1 , we do not have a copy of
> db.properties that comes from a 4.1 installation saved anywhere.
>
>
>
> I have logged the following bug to track this issue:
>
> CLOUDSTACK-1900 -
> Upgrade 4.0 -> 4.1 , We do not have a copy of db.properties that comes from
> a 4.1 installation saved anywhere.
>
>
>
>
>
> This needs to be saved , So that as part of upgrade instructions we can
> ask that the user makes his current  db.properties compatible with this
> version. This step is documented as part of upgrade procedures from
> 2.2.14-> 4.0 and 3.0.2->4.0.
>
>
>
> I see the following awsapi missing in db.properties when upgrading from
> 4.0 -> 4.1:
>
>
>db.awsapi.username=cloud
> db.awsapi.password=cloud
> db.awsapi.host=localhost
> db.awsapi.port=3306
>
> What should the solution for this issue be ?
>
> -Thanks
> Sangeetha
>

RE: deleteStoragePool API Command

[Pranav Saxena]

Had that not been the case , then it would have been a Contradiction in itself 
:D   After all the UI triggers the API's , so if you trigger them manually or 
from the UI , the behavior has to be the same .  Just that you might get some 
more flexibility with the API's in certain cases but there can't be a 
behavioral change in the API .

-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] 
Sent: Wednesday, April 03, 2013 1:14 AM
To: cloudstack-...@incubator.apache.org
Subject: Re: deleteStoragePool API Command

Spoke too soon. :)

I just ran a quick test and you do have to put the Primary Storage in 
maintenance mode prior to deleting it with the API, too.


On Tue, Apr 2, 2013 at 1:37 PM, Mike Tutkowski  wrote:

> Hi,
>
> Is it required that a primary storage be in maintenance mode before 
> calling the deleteStoragePool API command?
>
> In the GUI, you have to do this, but I wasn't sure if it was the same 
> for the API.
>
> Thanks!
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the 
> cloud
> *(tm)*
>



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

Re: Prerequisite

[L Radhakrishna Rao]

Hi Sudha,

I am interested in any kind of works, the only constraint is time.

I will be able to contribute in this community from friday, and oh yes,
saturday is always there, because I have a day job.




On Wed, Apr 3, 2013 at 10:14 AM, Sudha Ponnaganti <
sudha.ponnaga...@citrix.com> wrote:

> Radhakrishna,
>
> Welcome! Would you be interested to write some test cases in python. We
> have rich automation suite which is mainly written in python.
> If you feel comfortable in certain area, you can start looking at current
> feature set i.e Apache Cloudstack 4.1 release / 4.2 feature sets.
>
> You will find all the new stories by going over the cwiki page that
> Radhika has provided.
>
> Thanks
> /sudha
>
> -Original Message-
> From: L Radhakrishna Rao [mailto:satishsaga...@gmail.com]
> Sent: Tuesday, April 02, 2013 9:41 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Prerequisite
>
> Thanks Kelcey for the information and encouraging me.
>
> Of course, I will maintain the ideology of the group, open discussion and
> transparency
>
> Yes, I am comfortable with the theory of Java, and I do write programs in
> Python, but nothing like big the way the people in the community do, so a
> touch nervous.
>
>
> On Wed, Apr 3, 2013 at 10:08 AM, Kelceydamage@bbits 
> wrote:
>
> > Hi, I would not go so far as to say you need to be an expert, but
> > knowledge of theory would be helpfull.
> >
> > The core is written in Java, and there are many tools/scripts in Bash
> > and Python.
> >
> > Most importantly is to learn the methods of the community namely open
> > discussion and transparency on your contributions.
> >
> > There are many great resource on our wiki for new developers.
> >
> > cloudstack.apache.org
> >
> > Welcome aboard.
> >
> > Sent from my iPhone
> >
> > On Apr 2, 2013, at 9:32 PM, L Radhakrishna Rao
> > 
> > wrote:
> >
> > > Hi All,
> > >
> > > I would like to know that how can I start contributing to the apache
> > cloud
> > > stack.
> > >
> > > What are the basic things needed, which programming language to be
> used.
> > > And do I need to be expert in Cloud computing?
> > >
> > > With Best Regards,
> > > RK
> >
>

RE: Prerequisite

[Sudha Ponnaganti]

Radhakrishna,

Welcome! Would you be interested to write some test cases in python. We have 
rich automation suite which is mainly written in python.
If you feel comfortable in certain area, you can start looking at current 
feature set i.e Apache Cloudstack 4.1 release / 4.2 feature sets. 

You will find all the new stories by going over the cwiki page that Radhika has 
provided.

Thanks
/sudha

-Original Message-
From: L Radhakrishna Rao [mailto:satishsaga...@gmail.com] 
Sent: Tuesday, April 02, 2013 9:41 PM
To: dev@cloudstack.apache.org
Subject: Re: Prerequisite

Thanks Kelcey for the information and encouraging me.

Of course, I will maintain the ideology of the group, open discussion and 
transparency

Yes, I am comfortable with the theory of Java, and I do write programs in 
Python, but nothing like big the way the people in the community do, so a touch 
nervous.


On Wed, Apr 3, 2013 at 10:08 AM, Kelceydamage@bbits  wrote:

> Hi, I would not go so far as to say you need to be an expert, but 
> knowledge of theory would be helpfull.
>
> The core is written in Java, and there are many tools/scripts in Bash 
> and Python.
>
> Most importantly is to learn the methods of the community namely open 
> discussion and transparency on your contributions.
>
> There are many great resource on our wiki for new developers.
>
> cloudstack.apache.org
>
> Welcome aboard.
>
> Sent from my iPhone
>
> On Apr 2, 2013, at 9:32 PM, L Radhakrishna Rao 
> 
> wrote:
>
> > Hi All,
> >
> > I would like to know that how can I start contributing to the apache
> cloud
> > stack.
> >
> > What are the basic things needed, which programming language to be used.
> > And do I need to be expert in Cloud computing?
> >
> > With Best Regards,
> > RK
>

Re: Review Request: CLOUDSTACK-1890: listProjects is not listing state in the response

[ASF Subversion and Git Services]

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


Commit a24b4d5a7ab05e09ecfd75e743c61e74ff71d322 in branch refs/heads/internallb 
from Alena Prokharchyk 
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a24b4d5 ]

CLOUDSTACK-1890: listProjects is not listing state in the response.


- ASF Subversion and Git Services


On April 2, 2013, 6:46 p.m., Min Chen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10240/
> ---
> 
> (Updated April 2, 2013, 6:46 p.m.)
> 
> 
> Review request for cloudstack and Chip Childers.
> 
> 
> Description
> ---
> 
> This patch fixed the bug CLOUDSTACK-1890, wrong State class is imported in 
> ProjectJoinVO class.
> 
> 
> This addresses bug https://issues.apache.org/jira/browse/CLOUDSTACK-1890.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/api/query/vo/ProjectJoinVO.java 73ec931 
> 
> Diff: https://reviews.apache.org/r/10240/diff/
> 
> 
> Testing
> ---
> 
> Tested locally.
> 
> 
> Thanks,
> 
> Min Chen
> 
>

Re: Prerequisite

[L Radhakrishna Rao]

Hi Radhika,

thanks for the information and also advnice.

I will definitely contribute to documentation.


On Wed, Apr 3, 2013 at 10:10 AM, L Radhakrishna Rao  wrote:

> Thanks Kelcey for the information and encouraging me.
>
> Of course, I will maintain the ideology of the group, open discussion and
> transparency
>
> Yes, I am comfortable with the theory of Java, and I do write programs in
> Python, but nothing like big the way the people in the community do, so a
> touch nervous.
>
>
> On Wed, Apr 3, 2013 at 10:08 AM, Kelceydamage@bbits wrote:
>
>> Hi, I would not go so far as to say you need to be an expert, but
>> knowledge of theory would be helpfull.
>>
>> The core is written in Java, and there are many tools/scripts in Bash and
>> Python.
>>
>> Most importantly is to learn the methods of the community namely open
>> discussion and transparency on your contributions.
>>
>> There are many great resource on our wiki for new developers.
>>
>> cloudstack.apache.org
>>
>> Welcome aboard.
>>
>> Sent from my iPhone
>>
>> On Apr 2, 2013, at 9:32 PM, L Radhakrishna Rao 
>> wrote:
>>
>> > Hi All,
>> >
>> > I would like to know that how can I start contributing to the apache
>> cloud
>> > stack.
>> >
>> > What are the basic things needed, which programming language to be used.
>> > And do I need to be expert in Cloud computing?
>> >
>> > With Best Regards,
>> > RK
>>
>
>

Re: Prerequisite

[L Radhakrishna Rao]

Thanks Kelcey for the information and encouraging me.

Of course, I will maintain the ideology of the group, open discussion and
transparency

Yes, I am comfortable with the theory of Java, and I do write programs in
Python, but nothing like big the way the people in the community do, so a
touch nervous.


On Wed, Apr 3, 2013 at 10:08 AM, Kelceydamage@bbits  wrote:

> Hi, I would not go so far as to say you need to be an expert, but
> knowledge of theory would be helpfull.
>
> The core is written in Java, and there are many tools/scripts in Bash and
> Python.
>
> Most importantly is to learn the methods of the community namely open
> discussion and transparency on your contributions.
>
> There are many great resource on our wiki for new developers.
>
> cloudstack.apache.org
>
> Welcome aboard.
>
> Sent from my iPhone
>
> On Apr 2, 2013, at 9:32 PM, L Radhakrishna Rao 
> wrote:
>
> > Hi All,
> >
> > I would like to know that how can I start contributing to the apache
> cloud
> > stack.
> >
> > What are the basic things needed, which programming language to be used.
> > And do I need to be expert in Cloud computing?
> >
> > With Best Regards,
> > RK
>

RE: Prerequisite

[Radhika Puthiyetath]

Hi,

To learn more about CloudStack, see 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+University
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Getting+Help

Why don't you start with contributing to documentation ?

Here is the link to start 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Documentation+Contributors+Overview

Regards
-Radhika
-Original Message-
From: L Radhakrishna Rao [mailto:satishsaga...@gmail.com] 
Sent: Wednesday, April 03, 2013 10:02 AM
To: dev@cloudstack.apache.org
Subject: Prerequisite

Hi All,

I would like to know that how can I start contributing to the apache cloud 
stack.

What are the basic things needed, which programming language to be used.
And do I need to be expert in Cloud computing?

With Best Regards,
RK

Re: Prerequisite

[Kelceydamage@bbits]

Hi, I would not go so far as to say you need to be an expert, but knowledge of 
theory would be helpfull.

The core is written in Java, and there are many tools/scripts in Bash and 
Python.

Most importantly is to learn the methods of the community namely open 
discussion and transparency on your contributions.

There are many great resource on our wiki for new developers.

cloudstack.apache.org

Welcome aboard.

Sent from my iPhone

On Apr 2, 2013, at 9:32 PM, L Radhakrishna Rao  wrote:

> Hi All,
> 
> I would like to know that how can I start contributing to the apache cloud
> stack.
> 
> What are the basic things needed, which programming language to be used.
> And do I need to be expert in Cloud computing?
> 
> With Best Regards,
> RK

Prerequisite

[L Radhakrishna Rao]

Hi All,

I would like to know that how can I start contributing to the apache cloud
stack.

What are the basic things needed, which programming language to be used.
And do I need to be expert in Cloud computing?

With Best Regards,
RK

Re: Additional IP Assignment

[Ahmad Emneina]

roping in chiradeep, would security groups prevent this kind of behavior?
should this be do'able with virtual interfaces, from within the guest vm?


On Tue, Apr 2, 2013 at 5:49 PM, Maurice Lawler wrote:

>
> Greetings,
>
> I am attempting to manually assign my instance two additional IP
> addresses, however, utilizing range0 file and or ifcfg-eth0:1 and :2 are
> proving to fail.
>
> When adding an IP from a different subnet that is not being utilized by
> CS, how must one do this?
>
> Maurice
>

[DISCUSS] Upgrade from 4.0 -> 4.1 ( components.xml and db.propetries)

[Sangeetha Hariharan]

Wanted to discuss about how to deal with components.xml and db.properties when 
upgrading from 4.0 ->4.1.


1. If someone has made changes to your existing copy of the file 
components.xml in your previous-version CloudStack installation , after upgrade 
they will have to translate these changes into the current componentContext.xml 
file  which is located in 
/usr/share/cloudstack-management/webapps/client/WEB-INF/classes/componentContext.xml.
 This step needs to be documented in the upgrade procedure.

Had a question here. Should we ideally maintain the location of the 
componentContext.xml to be the same as it was in 4.0? It is now present in a 
completely different location.



2. When we upgrade from 4.0 to 4.1 , we do not have a copy of db.properties 
that comes from a 4.1 installation saved anywhere.



I have logged the following bug to track this issue:

CLOUDSTACK-1900 - 
Upgrade 4.0 -> 4.1 , We do not have a copy of db.properties that comes from a 
4.1 installation saved anywhere.





This needs to be saved , So that as part of upgrade instructions we can ask 
that the user makes his current  db.properties compatible with this version. 
This step is documented as part of upgrade procedures from 2.2.14-> 4.0 and 
3.0.2->4.0.



I see the following awsapi missing in db.properties when upgrading from 4.0 -> 
4.1:


   db.awsapi.username=cloud
db.awsapi.password=cloud
db.awsapi.host=localhost
db.awsapi.port=3306

What should the solution for this issue be ?

-Thanks
Sangeetha

RE: [DISCUSS] Don't assign tickets to people when triaging

[Alex Huang]

> I understand the reasoning - but for a newcomer looking to get involved, I
> think 'assigning' a bug - whether by default, or otherwise can be construed as
> excluding newcomers and no room for them to get involved, so I think it
> warrants caution at a minimum.
> 
> Our 'if not 'in progress' anyone can grab it' does not seem to be the norm for
> open source projects.
> 
> I also wonder if it makes a difference. Perhaps it does. In other projects 
> I've
> been involved in, when I care about releases or just the project, I tend to
> watch the categories of bugs that I can fix, particularly the unassigned 
> items.
> Does having a backlog of work assigned to me (as opposed to checking a
> component in Jira for outstanding work) improve things somehow? I don't
> know, perhaps it does and there is something I am missing.
> 

I want to first establish that we should do what's right for this community.  
We should use other open source projects as a reference but we shouldn't just 
do whatever others are doing.

With that said, I think Jira is just a much better project management tool than 
what's available before.  We should use these workflows as much as possible to 
communicate what a release needs.  It's almost like git vs svn.  For many 
years, almost all open source projects use svn and linux is the only one that 
uses git but now you hardly hear of new projects say they're using svn anymore. 
 Apache was almost exclusively on bugzilla and jira before.  From what I can 
see, Cloudstack was one of the first to bring these into Apache and CloudStack 
can be one of the first to bring better patterns to apache as well.

Cloud is the future and cloudstack should use tools and patterns fit for the 
future.  Jira has a superior workflow for us to utilize.  We should utilize it 
when it comes to bug triage and release management.  

--Alex

Re: Review Request: Make SHA256Salt the default password encoding and authentication mechanism for cloudstack

[Min Chen]

> On April 3, 2013, 1:03 a.m., Min Chen wrote:
> > Ship It!

committed to master 2dbdc46337be375940441ac4b41f95f25bbbf21d


- Min


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


On April 3, 2013, 12:31 a.m., Venkata Siva Vijayendra Bhamidipati wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10039/
> ---
> 
> (Updated April 3, 2013, 12:31 a.m.)
> 
> 
> Review request for cloudstack, Hugo Trippaers, Kelven Yang, and Min Chen.
> 
> 
> Description
> ---
> 
> Changing default password encoding mechanism from MD5 to SHA256Salted.
> 
> 
> This addresses bug CS-1734.
> 
> 
> Diffs
> -
> 
>   
> api/src/org/apache/cloudstack/api/command/admin/account/CreateAccountCmd.java 
> 89673ea 
>   api/src/org/apache/cloudstack/api/command/admin/user/CreateUserCmd.java 
> fb29e1a 
>   api/src/org/apache/cloudstack/api/command/admin/user/UpdateUserCmd.java 
> 1f31662 
>   client/tomcatconf/applicationContext.xml.in 636eac2 
>   client/tomcatconf/componentContext.xml.in 0ddb428 
>   client/tomcatconf/nonossComponentContext.xml.in 0b02eb6 
>   developer/developer-prefill.sql 6300d35 
>   
> plugins/user-authenticators/ldap/src/com/cloud/server/auth/LDAPUserAuthenticator.java
>  61eebe5 
>   
> plugins/user-authenticators/md5/src/com/cloud/server/auth/MD5UserAuthenticator.java
>  026125e 
>   
> plugins/user-authenticators/plain-text/src/com/cloud/server/auth/PlainTextUserAuthenticator.java
>  52e7cb3 
>   
> plugins/user-authenticators/sha256salted/src/com/cloud/server/auth/SHA256SaltedUserAuthenticator.java
>  1b29f69 
>   server/src/com/cloud/server/ManagementServerImpl.java d0904e1 
>   server/src/com/cloud/user/AccountManagerImpl.java 40db4ed 
> 
> Diff: https://reviews.apache.org/r/10039/diff/
> 
> 
> Testing
> ---
> 
> Manual testing done for both oss and nonoss components. Both admin and users 
> added later are encoded according to the scheme configured, and authenticated 
> by the same scheme.
> 
> To change the order of the schemes, modify the following list properties in 
> client/tomcatconf/nonossComponentContext.xml.in or 
> client/tomcatconf/componentContext.xml.in as applicable, to the desired order:
> 
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
>  
> 
>  
> 
> 
> Thanks,
> 
> Venkata Siva Vijayendra Bhamidipati
> 
>

Re: Review Request: Make SHA256Salt the default password encoding and authentication mechanism for cloudstack

[Min Chen]

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

Ship it!


Ship It!

- Min Chen


On April 3, 2013, 12:31 a.m., Venkata Siva Vijayendra Bhamidipati wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10039/
> ---
> 
> (Updated April 3, 2013, 12:31 a.m.)
> 
> 
> Review request for cloudstack, Hugo Trippaers, Kelven Yang, and Min Chen.
> 
> 
> Description
> ---
> 
> Changing default password encoding mechanism from MD5 to SHA256Salted.
> 
> 
> This addresses bug CS-1734.
> 
> 
> Diffs
> -
> 
>   
> api/src/org/apache/cloudstack/api/command/admin/account/CreateAccountCmd.java 
> 89673ea 
>   api/src/org/apache/cloudstack/api/command/admin/user/CreateUserCmd.java 
> fb29e1a 
>   api/src/org/apache/cloudstack/api/command/admin/user/UpdateUserCmd.java 
> 1f31662 
>   client/tomcatconf/applicationContext.xml.in 636eac2 
>   client/tomcatconf/componentContext.xml.in 0ddb428 
>   client/tomcatconf/nonossComponentContext.xml.in 0b02eb6 
>   developer/developer-prefill.sql 6300d35 
>   
> plugins/user-authenticators/ldap/src/com/cloud/server/auth/LDAPUserAuthenticator.java
>  61eebe5 
>   
> plugins/user-authenticators/md5/src/com/cloud/server/auth/MD5UserAuthenticator.java
>  026125e 
>   
> plugins/user-authenticators/plain-text/src/com/cloud/server/auth/PlainTextUserAuthenticator.java
>  52e7cb3 
>   
> plugins/user-authenticators/sha256salted/src/com/cloud/server/auth/SHA256SaltedUserAuthenticator.java
>  1b29f69 
>   server/src/com/cloud/server/ManagementServerImpl.java d0904e1 
>   server/src/com/cloud/user/AccountManagerImpl.java 40db4ed 
> 
> Diff: https://reviews.apache.org/r/10039/diff/
> 
> 
> Testing
> ---
> 
> Manual testing done for both oss and nonoss components. Both admin and users 
> added later are encoded according to the scheme configured, and authenticated 
> by the same scheme.
> 
> To change the order of the schemes, modify the following list properties in 
> client/tomcatconf/nonossComponentContext.xml.in or 
> client/tomcatconf/componentContext.xml.in as applicable, to the desired order:
> 
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
>  
> 
>  
> 
> 
> Thanks,
> 
> Venkata Siva Vijayendra Bhamidipati
> 
>

Re: Review Request: MidoNet Networking Plugin [2/2]

[Dave Cahill]

Checking back in - any progress on this review? We're now at the 3 week
point from initial submission.

Hugo, is your Ship It (once test run completes) equivalent to a "commit
now", or is there an additional review required? I don't see any other
review activity, so I'm guessing you're the only one actively looking at
this at the moment.


On Fri, Mar 29, 2013 at 11:37 PM, Dave Cahill  wrote:

> Sounds great, thanks Hugo!
>
>
> On Fri, Mar 29, 2013 at 8:47 PM, Hugo Trippaers <
> htrippa...@schubergphilis.com> wrote:
>
>>  Hey Dave,
>>
>>  My "ship it" is waiting for a last compile and test run on my dev
>> platform. I'll try to do that over the weekend.
>>
>>   Cheers,
>>
>>  Hugo
>>
>> Sent from my iPhone
>>
>> On 29 mrt. 2013, at 02:17, "Dave Cahill"  wrote:
>>
>>   Hi all,
>>
>>  I think all review comments have been addressed on this, but review
>> progress seems to have stalled - anything I should be doing to keep things
>> moving?
>>
>>  Thanks,
>> Dave.
>>
>>
>> On Wed, Mar 27, 2013 at 3:33 PM, Dave Cahill wrote:
>>
>>>This is an automatically generated e-mail. To reply, visit:
>>> https://reviews.apache.org/r/9898/
>>>Review request for cloudstack, Hugo Trippaers and Chiradeep Vittal.
>>> By Dave Cahill.
>>>
>>> *Updated March 27, 2013, 6:33 a.m.*
>>> Changes
>>>
>>> Fixed Hiroaki's exception-related review comment.
>>>
>>>   Description
>>>
>>> Feature 
>>> spec:https://cwiki.apache.org/confluence/display/CLOUDSTACK/Midokura+Networking+Plugin
>>>
>>> Jira ticket:https://issues.apache.org/jira/browse/CLOUDSTACK-996
>>>
>>> Notes:
>>>
>>> * Documentation will follow as a separate commit
>>>
>>> * One main difference from existing networking plugins is the lack of a 
>>> Resource class; we didn't feel it was necessary in this case. As mentioned 
>>> in Extending CloudStack Networking [1]:
>>> "Just like managers, resources are not strictly necessary. In theory a 
>>> Network Element could implement a client for the API of the new controller 
>>> and therefore be completely self-contained."
>>>
>>> * We allow overriding Public traffic via the MidoNetPublicNetworkGuru. We 
>>> checked this approach with the list [2] and received no comments, so we're 
>>> going with it for now.
>>>
>>> [1] https://cwiki.apache.org/CLOUDSTACK/extending-cloudstack-networking.html
>>> [2] http://markmail.org/message/k5qse63eyylszm3i
>>>
>>>   Testing
>>>
>>> Built and deployed, spun up Advanced Isolated network with two VMs, 
>>> verified internal and external connectivity via MidoNet.
>>>
>>>   *Bugs: *CLOUDSTACK-996
>>> Diffs (updated)
>>>
>>>- api/src/com/cloud/network/Network.java (c2ab655)
>>>- api/src/com/cloud/network/Networks.java (e3d2158)
>>>- api/src/com/cloud/network/PhysicalNetwork.java (343a2b1)
>>>- api/src/org/apache/cloudstack/network/ExternalNetworkDeviceManager.java
>>>(bc22804)
>>>- client/pom.xml (7ad2eff)
>>>- 
>>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtDomainXMLParser.java
>>>(b622b6d)
>>>- 
>>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java
>>>(c93aeeb)
>>>- plugins/network-elements/midokura-midonet/pom.xml (7f2e2d3)
>>>- plugins/network-elements/midonet/pom.xml (PRE-CREATION)
>>>- 
>>> plugins/network-elements/midonet/src/com/cloud/network/element/MidoNetElement.java
>>>(48833b3)
>>>- 
>>> plugins/network-elements/midonet/src/com/cloud/network/element/SimpleFirewallRule.java
>>>(PRE-CREATION)
>>>- 
>>> plugins/network-elements/midonet/src/com/cloud/network/guru/MidoNetGuestNetworkGuru.java
>>>(ed0eb3c)
>>>- 
>>> plugins/network-elements/midonet/src/com/cloud/network/guru/MidoNetPublicNetworkGuru.java
>>>(PRE-CREATION)
>>>- 
>>> plugins/network-elements/midonet/src/com/cloud/network/resource/MidoNetVifDriver.java
>>>(PRE-CREATION)
>>>- 
>>> plugins/network-elements/midonet/test/com/cloud/network/element/MidoNetElementTest.java
>>>(PRE-CREATION)
>>>- plugins/pom.xml (39d9907)
>>>- server/src/com/cloud/configuration/Config.java (9db7dbd)
>>>- server/src/com/cloud/network/NetworkManagerImpl.java (b1236cc)
>>>- ui/scripts/system.js (c0a5d14)
>>>
>>> View Diff 
>>>
>>
>>
>

Additional IP Assignment

[Maurice Lawler]

Greetings,I am attempting to 
manually assign my instance two additional IP addresses, however, 
utilizing range0 file and or ifcfg-eth0:1 and :2 are proving to fail.When adding an IP from a different subnet that is not being utilized by CS, how must one do this?Maurice

Re: Review Request: Make SHA256Salt the default password encoding and authentication mechanism for cloudstack

[Venkata Siva Vijayendra Bhamidipati]

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

(Updated April 3, 2013, 12:31 a.m.)


Review request for cloudstack, Hugo Trippaers, Kelven Yang, and Min Chen.


Changes
---

Uploading new diff since older patch won't apply due to changes checked into 
master as part of b798c451141c32d46322aae83063eeaa9634b337.


Description
---

Changing default password encoding mechanism from MD5 to SHA256Salted.


This addresses bug CS-1734.


Diffs (updated)
-

  api/src/org/apache/cloudstack/api/command/admin/account/CreateAccountCmd.java 
89673ea 
  api/src/org/apache/cloudstack/api/command/admin/user/CreateUserCmd.java 
fb29e1a 
  api/src/org/apache/cloudstack/api/command/admin/user/UpdateUserCmd.java 
1f31662 
  client/tomcatconf/applicationContext.xml.in 636eac2 
  client/tomcatconf/componentContext.xml.in 0ddb428 
  client/tomcatconf/nonossComponentContext.xml.in 0b02eb6 
  developer/developer-prefill.sql 6300d35 
  
plugins/user-authenticators/ldap/src/com/cloud/server/auth/LDAPUserAuthenticator.java
 61eebe5 
  
plugins/user-authenticators/md5/src/com/cloud/server/auth/MD5UserAuthenticator.java
 026125e 
  
plugins/user-authenticators/plain-text/src/com/cloud/server/auth/PlainTextUserAuthenticator.java
 52e7cb3 
  
plugins/user-authenticators/sha256salted/src/com/cloud/server/auth/SHA256SaltedUserAuthenticator.java
 1b29f69 
  server/src/com/cloud/server/ManagementServerImpl.java d0904e1 
  server/src/com/cloud/user/AccountManagerImpl.java 40db4ed 

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


Testing
---

Manual testing done for both oss and nonoss components. Both admin and users 
added later are encoded according to the scheme configured, and authenticated 
by the same scheme.

To change the order of the schemes, modify the following list properties in 
client/tomcatconf/nonossComponentContext.xml.in or 
client/tomcatconf/componentContext.xml.in as applicable, to the desired order:


 










 
 

 


Thanks,

Venkata Siva Vijayendra Bhamidipati

Re: [DISCUSS] Don't assign tickets to people when triaging

[David Nalley]

On Tue, Apr 2, 2013 at 6:53 PM, Alex Huang  wrote:
> So let me start off with I agree in principle with what Noah is talking about 
> here.  Cookie licking is an anti-pattern that we should reject as a 
> community.  However, I disagree the solution or even what is perceived as 
> cookie licking.
>
> We established a while ago as a community that we follow a Jira workflow in 
> handling bugs.  In that process, a bug is Open until it goes to "In 
> Progress".  We can simply tweak our expectations on this workflow to achieve 
> exactly the desired effects.
>
> - Assign bugs does not mean you own it, even if you assign it to yourself 
> doesn't mean you own it.
> - No one owns a bug until the person assigned changed it to In Progress (not 
> licked til this stage)
> - Before a bug goes into In Progress, anyone can grab it.
>
> By doing this we allow people who can help in prioritizing the bugs to assign 
> bugs without going through another layer of negotiation.  Assigning bugs 
> merely means asking the question "can you work on it".  This would be much 
> more efficient way of doing things.
>
> I also think that we can setup public filters that people can use to find 
> bugs they can work on.  In the filter, it doesn't look at who the bug is 
> assigned to.  Just whether the bug is open or not.
>
> --Alex

I understand the reasoning - but for a newcomer looking to get
involved, I think 'assigning' a bug - whether by default, or otherwise
can be construed as excluding newcomers and no room for them to get
involved, so I think it warrants caution at a minimum.

Our 'if not 'in progress' anyone can grab it' does not seem to be the
norm for open source projects.

I also wonder if it makes a difference. Perhaps it does. In other
projects I've been involved in, when I care about releases or just the
project, I tend to watch the categories of bugs that I can fix,
particularly the unassigned items. Does having a backlog of work
assigned to me (as opposed to checking a component in Jira for
outstanding work) improve things somehow? I don't know, perhaps it
does and there is something I am missing.

I do think triaging is important - there are simply too many bugs to
not have some ongoing triage, make sure the proper component,
severity, etc is set, perhaps even doing some initial prompting for
enough information.

--David

RE: [MERGE] scaleupvm functionality branch to master

[Edison Su]

Happened to take a look at virtualmachinemanagerimpl on master, during 
reviewing storage migration code. Just want to know, what's the difference 
between migrate and migrateforscale in VirtualmachineManagerImpl? Is it 
necessary to duplicate code?


> -Original Message-
> From: Nitin Mehta [mailto:nitin.me...@citrix.com]
> Sent: Monday, March 18, 2013 9:10 AM
> To: cloudstack-...@incubator.apache.org
> Subject: [MERGE] scaleupvm functionality branch to master
> 
> I would like to merge scale up vm functionality branch to master
> 
> Spec :
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+scaling
> +of+CPU+and+RAM
> 
> JIRA ticket :
> https://issues.apache.org/jira/browse/CLOUDSTACK-658
> 
> Branch:
> Scaleupvm
> 
> Notes:-
> 
>   1.  I have removed the vm state change in the code and so there is no vm
> state machine change. I am planning to achieve the synchronization using
> async job framework. I will make this change once I get a reply from Kelvn
> (minor change)
>   2.  With the changes in #1 this feature is independent and should not be
> intrusive to any functionality.
> 
> Thanks,
> -Nitin

RE: [DISCUSS] Don't assign tickets to people when triaging

[Alex Huang]

So let me start off with I agree in principle with what Noah is talking about 
here.  Cookie licking is an anti-pattern that we should reject as a community.  
However, I disagree the solution or even what is perceived as cookie licking.

We established a while ago as a community that we follow a Jira workflow in 
handling bugs.  In that process, a bug is Open until it goes to "In Progress".  
We can simply tweak our expectations on this workflow to achieve exactly the 
desired effects.

- Assign bugs does not mean you own it, even if you assign it to yourself 
doesn't mean you own it.
- No one owns a bug until the person assigned changed it to In Progress (not 
licked til this stage)
- Before a bug goes into In Progress, anyone can grab it.

By doing this we allow people who can help in prioritizing the bugs to assign 
bugs without going through another layer of negotiation.  Assigning bugs merely 
means asking the question "can you work on it".  This would be much more 
efficient way of doing things.

I also think that we can setup public filters that people can use to find bugs 
they can work on.  In the filter, it doesn't look at who the bug is assigned 
to.  Just whether the bug is open or not.  

--Alex

> -Original Message-
> From: Noah Slater [mailto:nsla...@apache.org]
> Sent: Tuesday, April 2, 2013 12:21 PM
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS] Don't assign tickets to people when triaging
> 
> Dear community,
> 
> Right now, we have people who are regularly going through JIRA and triaging
> tickets. This is totally fantastic, and a very valuable activity for the 
> project. (So
> thank you!) But I also notice that specific individuals are being assigned to 
> the
> tickets in the process.
> 
> This is a form of "cookie licking". The analogy is that if you fancy a 
> cookie, but
> you're too hungry right now, you take a lick of it so nobody else can touch 
> it.
> This is an anti-pattern and we should try to avoid it.
> 
> In general, I would say we should only be assigning a ticket to ourselves, and
> we should only be doing that when we actually intend to sit down and work
> on it.
> 
> If we have people going through and saying "well, this is clearly Joe's area" 
> or
> "this is clearly Fred's area" then that is a great way to make sure that those
> areas remain "Joe's area" or "Fred's area" or whatever.
> Which is unhealthy for the project.
> 
> So what I would suggest is that we consider changing the way we work here.
> 
> Ticket triage might change so that tickets are put on to component backlogs.
> And engineers can switch from grabbing tickets of their "assigned to me"
> report, and start looking at the "Foo feature backlog" report instead.
> Selecting a ticket and assigning it *to themselves* when they are *starting
> work on it*.
> 
> (This would then take the ticket off the component backlog. So the backlog
> report would only display tickets that were unassigned and available to
> grab.)
> 
> This would mean that all this valuable ticket triage work we're doing is
> something that can benefit everyone in the project (not just people who are
> already known for their contributions) and will hopefully open the
> development workflow to people who are just starting out with the project,
> or want to get their toes wet.
> 
> In fact, when someone comes to us and asks "how can I contribute" we can
> point them at these backlogs and say "well, just grab a ticket off one of 
> these
> queues, assign it to yourself, and start working on it!" We could make use of
> a "difficulty" field too, so you could sort by difficulty, and grab one of the
> "easy", "medium", or "hard" tickets.
> 
> Thoughts?
> 
> --
> NS

RE: [DISCUSS] Don't assign tickets to people when triaging

[Animesh Chaturvedi]

> -Original Message-
> From: Will Chan [mailto:will.c...@citrix.com]
> Sent: Tuesday, April 02, 2013 2:22 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Don't assign tickets to people when triaging
> 
> I think the purpose of this discussion is that there are people currently 
> today
> that are auto-assigning bugs to individual developers of the community.  Most
> of these bugs were assigned for two main reasons.
> 
> 1. It was blatantly obvious the bugs stemmed from the feature developer.
> 
> - OR -
> 
> 2. The bugs were deemed a blocker either by the community, release manager,
> or someone that knows about the issue.
> 
> Both of these cases were done partly because of their $dayjobs leaking into
> community.  It simply looks like there are hidden agendas when these triaging
> were happening.  I think there are obviously ways we can get around but to me,
> it's a burdensome process especially when JIRA is a tool that helps our
> community in organizing our work and priorities rather than using the dev@
> list.
> 
> The second point is that by assigning these bugs, we are effectively pushing 
> out
> anyone that wants to contribute.  But as Sebastian has already done some
> legwork, the majority of the bugs are in Unassigned state.  If someone wants 
> to
> contribute, there are hundreds of bugs to participate in.  Just go grab one.
> 
> Everyone has probably something they are doing besides reading the ML every
> day or doing a search on JIRA.  By assigning a bug on JIRA, that person gets
> notified.  He can always decline to fix it but at least a notification has 
> been
> sent.  I think for the most serious of bugs or blocker bugs, anyone in the
> community should be able to help with the triage process.  If not for the very
> least, it helps in notifying the developer and effectively pinging the person 
> if
> they can help assist with the bug or not.
> 
> All I am proposing is a more efficient way of dealing with serious blocker
> issues.  We can end up losing days of work if we have to wait sometimes.  I
> think there are plenty of developers that want to help in some way, otherwise,
> why bother to be on the dev list.  However, I do know that I cannot search 
> JIRA
> everyday nor can I read every thread that happens here.  Someone pinging me
> via JIRA notifications seems like a decent way to be notified.  I can always
> decline to fix the bug.
> 
> What do you guys think?  Am I the only that wants to make things more
> efficient here?
> 
> Will
> 
I take some blame for assigning the defects but intent was to get issues 
(mostly blockers and critical) resolved  faster and not to exclude anyone.  The 
issues were assigned based on our list of component maintainers at [1]. Noah 
thanks for clarifying that the triaging may exclude new contributors.

Can I propose that whoever wants to contribute in fixing defects for a specific 
module add their name as maintainer of  that module in component maintainer 
list [1]? And we update how to contribute wiki on this process .

During 4.1  there are a large number of major issues that as community we ended 
up not addressing and given that number of unassigned issues is high % should 
we consider auto-assign based on the maintainers list? This is still not 
optimal since auto-assign will go to primary maintainer and secondary 
maintainers still need to pull in defects  but is better than one person 
triaging defects.

I also wanted to find out how do other projects get through resolving blocker 
bugs sooner? 

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Current+Maintainers+Per+Component



> > -Original Message-
> > From: Sebastien Goasguen [mailto:run...@gmail.com]
> > Sent: Tuesday, April 02, 2013 1:56 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] Don't assign tickets to people when triaging
> >
> >
> > On Apr 2, 2013, at 3:21 PM, Noah Slater  wrote:
> >
> > > Dear community,
> > >
> > > Right now, we have people who are regularly going through JIRA and
> > > triaging tickets. This is totally fantastic, and a very valuable
> > > activity for the project. (So thank you!) But I also notice that
> > > specific individuals are being assigned to the tickets in the process.
> > >
> > > This is a form of "cookie licking". The analogy is that if you fancy
> > > a cookie, but you're too hungry right now, you take a lick of it so
> > > nobody else can touch it. This is an anti-pattern and we should try
> > > to
> > avoid it.
> > >
> > > In general, I would say we should only be assigning a ticket to
> > > ourselves, and we should only be doing that when we actually intend
> > > to sit down and work on it.
> > >
> > > If we have people going through and saying "well, this is clearly
> > > Joe's area" or "this is clearly Fred's area" then that is a great
> > > way to make sure that those areas remain "Joe's area" or "Fred's
> > > area" or
> > whatever.
> > > Which is unhealthy for the project.
> > >
> 

[DISCUSS] UI time conversion for Events and Alerts.

[Parth Jagirdar]

All,

CS – 1898 ::  UI : incorrect time conversion on UI under Events

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


I am proposing to change/redesign the way CS handles times and dates currently.


We have time conversion issue on UI due to Time Zones.

Time Zones is not a mandatory field and if left blank CS will use its default 
time zone and Users will see time on their UI's off. (Refer to bug and attached 
screen for clarification) (Unless of course they are in default time zone that 
CS would use, when no time zone is supplied)


Once upon a time…there was a table in a database , named Event…..


mysql> select * from event;
+-+--+---+---+---+-++---+-+---+--++--+
| id  | uuid | type  | 
state | description 
  | user_id | account_id | domain_id | created 
| level | start_id | parameters | archived |
+-+--+---+---+---+-++---+-+---+--++--+
|   1 | 746273bb-a6ed-453a-8e45-a9873d06c58e | USER.LOGIN| 
Completed | user has logged in from IP Address 10.216.132.50
  |   2 |  2 | 1 | 2013-04-01 22:26:12 
| INFO  |0 | NULL   |0 |
|   2 | f8323212-fe8f-4d3c-a1c8-40d26b217895 | USER.CREATE   | 
Completed | Successfully completed creating User. Account Name: test, Domain 
Id:1 |   2 |  1 | 1 | 2013-04-01 
22:49:50 | INFO  |0 | NULL   |0 |


Now assume 2 users;

1.Admin  and
2.User

with User created by Admin using "Pacific time Zone".

When these 2 Users log in on UI, they both will see Event 1 (From Table above) 
with different times. (Of course Admin)

Admin will see it as 2013-04-01 22:26:12  +/- Time Zone specified when this 
user was created.
Similarly user will see this same event with time +/- "Time Zone specified when 
this user was created". (Pacific Time , in our example)

As per existing implementation, a Traveling "User", Either logs in from London 
Or Tokyo; "if this User was created using PST", then he will have time off all 
the time during his travel.



DISCUSS:: To Prevent CS – 1898

- Should we actually store time/date in DB in some standard format. And then 
display it by converting based on User's (Client Browser's) time/zone.
- Or should we instead make Time Zone field mandatory? (In this case we still 
have traveling user problem).

RE: [DISCUSS] Don't assign tickets to people when triaging

[Will Chan]

I think the purpose of this discussion is that there are people currently today 
that are auto-assigning bugs to individual developers of the community.  Most 
of these bugs were assigned for two main reasons.

1. It was blatantly obvious the bugs stemmed from the feature developer.

- OR - 

2. The bugs were deemed a blocker either by the community, release manager, or 
someone that knows about the issue.  

Both of these cases were done partly because of their $dayjobs leaking into 
community.  It simply looks like there are hidden agendas when these triaging 
were happening.  I think there are obviously ways we can get around but to me, 
it's a burdensome process especially when JIRA is a tool that helps our 
community in organizing our work and priorities rather than using the dev@ list.

The second point is that by assigning these bugs, we are effectively pushing 
out anyone that wants to contribute.  But as Sebastian has already done some 
legwork, the majority of the bugs are in Unassigned state.  If someone wants to 
contribute, there are hundreds of bugs to participate in.  Just go grab one.  

Everyone has probably something they are doing besides reading the ML every day 
or doing a search on JIRA.  By assigning a bug on JIRA, that person gets 
notified.  He can always decline to fix it but at least a notification has been 
sent.  I think for the most serious of bugs or blocker bugs, anyone in the 
community should be able to help with the triage process.  If not for the very 
least, it helps in notifying the developer and effectively pinging the person 
if they can help assist with the bug or not.

All I am proposing is a more efficient way of dealing with serious blocker 
issues.  We can end up losing days of work if we have to wait sometimes.  I 
think there are plenty of developers that want to help in some way, otherwise, 
why bother to be on the dev list.  However, I do know that I cannot search JIRA 
everyday nor can I read every thread that happens here.  Someone pinging me via 
JIRA notifications seems like a decent way to be notified.  I can always 
decline to fix the bug. 

What do you guys think?  Am I the only that wants to make things more efficient 
here?

Will

> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: Tuesday, April 02, 2013 1:56 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Don't assign tickets to people when triaging
> 
> 
> On Apr 2, 2013, at 3:21 PM, Noah Slater  wrote:
> 
> > Dear community,
> >
> > Right now, we have people who are regularly going through JIRA and
> > triaging tickets. This is totally fantastic, and a very valuable
> > activity for the project. (So thank you!) But I also notice that
> > specific individuals are being assigned to the tickets in the process.
> >
> > This is a form of "cookie licking". The analogy is that if you fancy a
> > cookie, but you're too hungry right now, you take a lick of it so
> > nobody else can touch it. This is an anti-pattern and we should try to
> avoid it.
> >
> > In general, I would say we should only be assigning a ticket to
> > ourselves, and we should only be doing that when we actually intend to
> > sit down and work on it.
> >
> > If we have people going through and saying "well, this is clearly
> > Joe's area" or "this is clearly Fred's area" then that is a great way
> > to make sure that those areas remain "Joe's area" or "Fred's area" or
> whatever.
> > Which is unhealthy for the project.
> >
> > So what I would suggest is that we consider changing the way we work
> here.
> >
> > Ticket triage might change so that tickets are put on to component
> > backlogs. And engineers can switch from grabbing tickets of their
> > "assigned to me" report, and start looking at the "Foo feature
> > backlog" report instead. Selecting a ticket and assigning it *to
> > themselves* when they are *starting work on it*.
> >
> > (This would then take the ticket off the component backlog. So the
> > backlog report would only display tickets that were unassigned and
> > available to
> > grab.)
> >
> > This would mean that all this valuable ticket triage work we're doing
> > is something that can benefit everyone in the project (not just people
> > who are already known for their contributions) and will hopefully open
> > the development workflow to people who are just starting out with the
> > project, or want to get their toes wet.
> >
> > In fact, when someone comes to us and asks "how can I contribute" we
> > can point them at these backlogs and say "well, just grab a ticket off
> > one of these queues, assign it to yourself, and start working on it!"
> > We could make use of a "difficulty" field too, so you could sort by
> > difficulty, and grab one of the "easy", "medium", or "hard" tickets.
> >
> > Thoughts?
> >
> > --
> > NS
> 
> Hi Noah, I know where you are coming from here, I would just like to point
> out that a quick JIRA search for Unassgined ticket returns 392 tick

RE: CLOUDSTACK-1842: ASF 4.0 to 4.1 Upgrade: Missing Ubuntu 12.04 Guest OS Types on the Upgraded Setup

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Tuesday, April 02, 2013 12:44 PM
> To: ; Animesh Chaturvedi
> Subject: Re: CLOUDSTACK-1842: ASF 4.0 to 4.1 Upgrade: Missing Ubuntu 12.04
> Guest OS Types on the Upgraded Setup
> 
> On Mon, Apr 1, 2013 at 3:46 PM, Chip Childers 
> wrote:
> > I went digging into CLOUDSTACK-1842, and I see the following:
> >
> > In looking at the SQL scripts, I see that the guest_os and
> > guest_os_hypervisor tables are typically populated via the upgrade
> > scripts during an upgrade.
> >
> > I also see that templates.sql has the data to populate these tables:
> >
> > INSERT INTO `cloud`.`guest_os` (id, uuid, category_id, display_name)
> > VALUES (163, UUID(), 10, 'Ubuntu 12.04 (32-bit)'); INSERT INTO
> > `cloud`.`guest_os` (id, uuid, category_id, display_name) VALUES (164,
> > UUID(), 10, 'Ubuntu 12.04 (64-bit)');
> >
> > and for VMware:
> >
> > INSERT INTO `cloud`.`guest_os_hypervisor` (hypervisor_type,
> > guest_os_name, guest_os_id) VALUES ("VmWare", 'Ubuntu 12.04 (32-bit)',
> > 162); INSERT INTO `cloud`.`guest_os_hypervisor` (hypervisor_type,
> > guest_os_name, guest_os_id) VALUES ("VmWare", 'Ubuntu 12.04 (64-bit)',
> > 163);
> >
> > Nothing is in templates.sql for Ubuntu 12.04 on KVM, and no Ubuntu
> > (any version) for XenServer.  Is this right?  Also, should we populate
> > Ubuntu 12.04 into guest_os and guest_os_hypervisor via the
> > 40to41 upgrade script?
> >
> > -chip
> 
> Animesh - I see you assigned this one to yourself.  Just ACK back if you are
> going to work on fixing it up please!
[Animesh>] Oh I didn't realize it was assigned to me, I reverted it back to 
Abhi.

Re: [ACS41] Another day, another bug list

[Chip Childers]

On Tue, Apr 02, 2013 at 01:52:49PM -0700, Sangeetha Hariharan wrote:
> * CLOUDSTACK-1874
> * AWS Regions - Account table in cloud_usage DB has region_id.
> 
> Kishan / Sangeetha - I'm not quite sure if this is actually critical.  
> Frankly it doesn't sound like it is.  Can we either resolve it or downgrade 
> it?
> 
> >>This was logged as Critical only because it is a DB schema change and 
> >>better to get it addressed as part of the release. Otherwise this would 
> >>need to be taken care of as an upgrade procedure.
> 
> -Thanks
> Sangeetha

That seems fair.  Kishan, do you mind confirming that this is the right
thing to do, and perhaps getting it done?

Re: [DISCUSS] Don't assign tickets to people when triaging

[Sebastien Goasguen]

On Apr 2, 2013, at 3:21 PM, Noah Slater  wrote:

> Dear community,
> 
> Right now, we have people who are regularly going through JIRA and triaging
> tickets. This is totally fantastic, and a very valuable activity for the
> project. (So thank you!) But I also notice that specific individuals are
> being assigned to the tickets in the process.
> 
> This is a form of "cookie licking". The analogy is that if you fancy a
> cookie, but you're too hungry right now, you take a lick of it so nobody
> else can touch it. This is an anti-pattern and we should try to avoid it.
> 
> In general, I would say we should only be assigning a ticket to ourselves,
> and we should only be doing that when we actually intend to sit down and
> work on it.
> 
> If we have people going through and saying "well, this is clearly Joe's
> area" or "this is clearly Fred's area" then that is a great way to make
> sure that those areas remain "Joe's area" or "Fred's area" or whatever.
> Which is unhealthy for the project.
> 
> So what I would suggest is that we consider changing the way we work here.
> 
> Ticket triage might change so that tickets are put on to component
> backlogs. And engineers can switch from grabbing tickets of their "assigned
> to me" report, and start looking at the "Foo feature backlog" report
> instead. Selecting a ticket and assigning it *to themselves* when they are
> *starting work on it*.
> 
> (This would then take the ticket off the component backlog. So the backlog
> report would only display tickets that were unassigned and available to
> grab.)
> 
> This would mean that all this valuable ticket triage work we're doing is
> something that can benefit everyone in the project (not just people who are
> already known for their contributions) and will hopefully open the
> development workflow to people who are just starting out with the project,
> or want to get their toes wet.
> 
> In fact, when someone comes to us and asks "how can I contribute" we can
> point them at these backlogs and say "well, just grab a ticket off one of
> these queues, assign it to yourself, and start working on it!" We could
> make use of a "difficulty" field too, so you could sort by difficulty, and
> grab one of the "easy", "medium", or "hard" tickets.
> 
> Thoughts?
> 
> -- 
> NS

Hi Noah, I know where you are coming from here, I would just like to point out 
that a quick JIRA search for Unassgined ticket returns 392 tickets up for grabs 
(out of 641 open tickets). That's 61% of our total tickets that are Unassigned.

In some ways and to keep things simple, anyone should feel free to grab any 
ticket they think they can work on and hopefully close. No need for buckets, 
priorities or difficulty rating. Just grab it.


-Sebastien

RE: [ACS41] Another day, another bug list

[Sangeetha Hariharan]

* CLOUDSTACK-1874
* AWS Regions - Account table in cloud_usage DB has region_id.

Kishan / Sangeetha - I'm not quite sure if this is actually critical.  Frankly 
it doesn't sound like it is.  Can we either resolve it or downgrade it?

>>This was logged as Critical only because it is a DB schema change and better 
>>to get it addressed as part of the release. Otherwise this would need to be 
>>taken care of as an upgrade procedure.

-Thanks
Sangeetha

-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com] 
Sent: Tuesday, April 02, 2013 1:43 PM
To: dev@cloudstack.apache.org
Subject: [ACS41] Another day, another bug list

Hi all,

Here's what we're tracking as of today for 4.1.  Please jump in and get these 
bugs knocked out!

Blocker:

* CLOUDSTACK-1877
* Failed to connect to DB while starting Ubuntu management server after 
upgrading the packages from 4.0 to 4.1

Currently unassigned.  Anyone want to take ownership over this one?

* NO BUG ID YET
* The reported issue with the mgmt server dropping connections from agents 
mentioned by Wido

We need to figure this one out (and have a bug ID).  It sounds like a blocker 
to me right now.

Critical:

* CLOUDSTACK-1837
* Document additonal Steps ( Restart of all system Vms , copy vhd-utils) to be 
included in the upgrade procedure from 4.0 -> 4.1

Currently unassigned.  Joe - I actually think this would be part of the upgrade 
docs portion of the release notes, so you may already be working on it.


* CLOUDSTACK-1839
* Upgrade 4.0 -> 4.1 - Upgraded DB has lot more keys and indexes for many 
tables compare to the fresh installed 4.1 DB.

Alex is working on this one.


* CLOUDSTACK-1842
* ASF 4.0 to 4.1 Upgrade: Missing Ubuntu 12.04 Guest OS Types on the Upgraded 
Setup

Animesh - looking for an ACK that you are working on this one please.


* CLOUDSTACK-1868
* GetVmStatsCommand throws NullPointerException with VMWare

Sateesh - you have this one assigned by Ram.  Are you able to look into it?
We have not been clear on the ML if this is actually reproducible.


* CLOUDSTACK-1874
* AWS Regions - Account table in cloud_usage DB has region_id.

Kishan / Sangeetha - I'm not quite sure if this is actually critical.  Frankly 
it doesn't sound like it is.  Can we either resolve it or downgrade it?




-chip

Re: [ACS41][DOCS] CLOUDSTACK-1837: Document additonal Steps ( Restart of all system Vms , copy vhd-utils) to be included in the upgrade procedure from 4.0 -> 4.1

[Chip Childers]

On Tue, Apr 02, 2013 at 03:44:48PM -0500, Joe Brockmeier wrote:
> On Tue, Apr 2, 2013, at 02:41 PM, Chip Childers wrote:
> > Can someone take this docs bug for 4.1 please?
> > 
> > https://issues.apache.org/jira/browse/CLOUDSTACK-1837
> > Document additonal Steps ( Restart of all system Vms , copy vhd-utils)
> > to be included in the upgrade procedure from 4.0 -> 4.1
> 
> This is really just part of Release Notes, yes? Claimed the bug. 

I believe so.  Thanks Joe!

Re: [ACS41][DOCS] CLOUDSTACK-1837: Document additonal Steps ( Restart of all system Vms , copy vhd-utils) to be included in the upgrade procedure from 4.0 -> 4.1

[Joe Brockmeier]

On Tue, Apr 2, 2013, at 02:41 PM, Chip Childers wrote:
> Can someone take this docs bug for 4.1 please?
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-1837
> Document additonal Steps ( Restart of all system Vms , copy vhd-utils)
> to be included in the upgrade procedure from 4.0 -> 4.1

This is really just part of Release Notes, yes? Claimed the bug. 

Best,

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

[ACS41] Another day, another bug list

[Chip Childers]

Hi all,

Here's what we're tracking as of today for 4.1.  Please jump in and get
these bugs knocked out!

Blocker:

* CLOUDSTACK-1877 
* Failed to connect to DB while starting Ubuntu management server after 
upgrading the packages from 4.0 to 4.1

Currently unassigned.  Anyone want to take ownership over this one?

* NO BUG ID YET
* The reported issue with the mgmt server dropping connections from agents 
mentioned by Wido

We need to figure this one out (and have a bug ID).  It sounds like a blocker 
to me right now.

Critical:

* CLOUDSTACK-1837 
* Document additonal Steps ( Restart of all system Vms , copy vhd-utils) to be 
included in the upgrade procedure from 4.0 -> 4.1

Currently unassigned.  Joe - I actually think this would be part of the 
upgrade docs portion of the release notes, so you may already be working 
on it.


* CLOUDSTACK-1839 
* Upgrade 4.0 -> 4.1 - Upgraded DB has lot more keys and indexes for many 
tables compare to the fresh installed 4.1 DB.

Alex is working on this one.


* CLOUDSTACK-1842 
* ASF 4.0 to 4.1 Upgrade: Missing Ubuntu 12.04 Guest OS Types on the Upgraded 
Setup

Animesh - looking for an ACK that you are working on this one please.


* CLOUDSTACK-1868 
* GetVmStatsCommand throws NullPointerException with VMWare

Sateesh - you have this one assigned by Ram.  Are you able to look into it?
We have not been clear on the ML if this is actually reproducible.


* CLOUDSTACK-1874 
* AWS Regions - Account table in cloud_usage DB has region_id.

Kishan / Sangeetha - I'm not quite sure if this is actually critical.  Frankly 
it doesn't
sound like it is.  Can we either resolve it or downgrade it?




-chip

RE: [DISCUSS] RESTful API for CloudStack agents

[Alex Huang]

Donal,

This looks very good.  I especially like the fact that we didn't go do a bunch 
of mapping of json to url paths.  After all, we're don't need full REST for 
agents.

+1

--Alex

> -Original Message-
> From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
> Sent: Tuesday, April 2, 2013 12:00 PM
> To: cloudstack-...@incubator.apache.org
> Subject: [DISCUSS] RESTful API for CloudStack agents
> 
> Could I get some feedback on the following strategy for mapping CloudStack
> RPC commands to HTTP requests?
> 
> The general approach is to:
> 1. map each category of command to a URL.  Each category corresponds
> roughly to a resource type being manipulated.
> E.g. /cloudstack/latest/storagepool/
> 2. make the command itself a path under the category E.g.
> /cloudstack/latest/storagepool/create
> 3. make resource changes using a POST request with parameters JSON
> encoded in the body E.g.
> 
> POST /cloudstack/latest/storagepool/{create | modify | destroy} POST
> /cloudstack/latest/volumes/{create | destroy} POST
> /cloudstack/latest/vm/{start | stop} 4. query resource state using a GET
> request that identifies specific resources with a query parameter E.g. GET
> /cloudstack/latest/vm?id=1&id=2&id=3
> 
> 
> 
> Commands are mapped to paths for simplicity.  Identifying CRUD operations
> such as create, modify and destroy from the path limits the HTTP methods to
> POST and GET.
> Serialising parameters as JSON in the body of a POST request is for 
> simplicity.
> Passing all command data in the URI is difficult, because URIs are ill suited 
> to
> expressing object trees that exist in complex commands such as the VM
> StartCommand.  Since parameters such as VM identifier are already in the
> body, static URIs can be used for many commands.
> 
> Commands that push data from the agent to the server have to be
> implemented as polling operations.  This applies to initial configuration
> commands and the hypervisor ping.  Agent configuration will come from
> HTTP POST versions of StartupRoutingCommand and
> StartupStorageCommand, rather than a config file copied to the hypervisor
> as was done with KVM.  To simulate a PingCommand the ServerComponent
> will use a HTTP GET.
> 
> Versioning is by way of dated path rather than version number.  Assuming
> the latest API is completed 2013/02/04,
> 
> /cloudstack/latest
> and
> 
> /cloudstack/2013-04-02
> refer to the same API.

[ACS41][DOCS] Generate diff of APIs changed/added/deleted?

[Joe Brockmeier]

Hi all,

So - the build process for generating API docs has changed since 4.0 ->
4.1, and it looks like in the process we've stopped generating a
"diff.txt" of APIs changed/added/deleted since the last version.

Any idea how we can generate this automagically rather than combing
through the new docs to see what's different since 4.0.x? Thanks!

Best,

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

Re: [ACS41] Management server closes connection on port 8250

[Chip Childers]

On Tue, Apr 02, 2013 at 10:10:28PM +0200, Wido den Hollander wrote:
> Hi,
> 
> On 04/02/2013 08:50 PM, Sheng Yang wrote:
> >On Tue, Apr 2, 2013 at 11:49 AM, Sheng Yang  wrote:
> >>On Tue, Apr 2, 2013 at 11:32 AM, Wido den Hollander  wrote:
> >>>Hi,
> >>>
> >>>Since I've upgraded my management server to 4.1 my agents refuse to 
> >>>connect,
> >>>their log says:
> >>>
> >>>2013-04-02 20:26:11,207 INFO  [utils.nio.NioClient] (Agent-Selector:null)
> >>>Connecting to 31.25.X.X:8250
> >>>2013-04-02 20:26:11,209 ERROR [utils.nio.NioConnection]
> >>>(Agent-Selector:null) Unable to initialize the threads.
> >>>java.io.IOException: SSL: Fail to init SSL! java.io.IOException: Connection
> >>>closed with -1 on reading size.
> >>> at com.cloud.utils.nio.NioClient.init(NioClient.java:83)
> >>> at com.cloud.utils.nio.NioConnection.run(NioConnection.java:108)
> >>> at java.lang.Thread.run(Thread.java:679)
> >>>
> >>>So I tried a telnet connection:
> >>>
> >>>Connection closed by foreign host.
> >>>root@stack01:~# telnet 31.25.X.X 8250
> >>>Trying 31.25.X.X...
> >>>Connected to 31.X.X.X.
> >>>Escape character is '^]'.
> >>>Connection closed by foreign host.
> >>>root@stack01:~#
> >>>
> >>>So I didn't close the connection, but it was the management server.
> >>>
> >>>I cranked up the logging to DEBUG, but nothing shows in any of the logs, so
> >>>I have no clue why this isn't working.
> >>>
> >>>On the mgmt server I see Java in LISTEN state on port 8250
> >>>
> >>>There is no firewall on the management server (it's my lab!).
> >>>
> >>>Any clues to what this could be before I start filing a in Jira? Since I'm
> >>>not sure if this is a bug.
> >>
> >>Have you upgrade your agent?
> >
> 
> Yes, the Agent is also 4.1
> 
> >Also you could try to enable TRACE for com.cloud.utils.nio to see more
> >log of NIO.
> >
> 
> I think you mean at the agent?
> 
> But what I think is weird is that the mgmt server directly closes
> the telnet connection as well and nothing shows up in the logs.
> 
> In the mgmt server log I found this:
> 
> 2013-04-02 22:08:41,156 INFO  [utils.nio.NioServer]
> (AgentManager-Selector:null) NioConnection started and listening on
> 0.0.0.0/0.0.0.0:8250
> 
> What I did notice is that when I shutdown the mgmt server the Agent
> connects for a second:
> 
> 2013-04-02 22:07:53,689 INFO  [utils.nio.NioClient]
> (Agent-Selector:null) Connecting to 31.25.X.X:8250
> 2013-04-02 22:07:53,934 INFO  [utils.nio.NioClient]
> (Agent-Selector:null) SSL: Handshake done
> 
> And then the mgmt server exists and the connection gets lost.
> 
> ANY clues about this weird behavior?
> 
> Wido
> 
> >--Sheng
> >>
> >>--Sheng
> >>>
> >>>Wido
>

Wido - Can you please open a blocker bug to track this?  It may end up
being a non-issue or something...  but I want to know that we have it
outstanding when considering when to cut the RC.

Re: [ACS41] Management server closes connection on port 8250

[Wido den Hollander]

Hi,

On 04/02/2013 08:50 PM, Sheng Yang wrote:

On Tue, Apr 2, 2013 at 11:49 AM, Sheng Yang  wrote:

On Tue, Apr 2, 2013 at 11:32 AM, Wido den Hollander  wrote:

Hi,

Since I've upgraded my management server to 4.1 my agents refuse to connect,
their log says:

2013-04-02 20:26:11,207 INFO  [utils.nio.NioClient] (Agent-Selector:null)
Connecting to 31.25.X.X:8250
2013-04-02 20:26:11,209 ERROR [utils.nio.NioConnection]
(Agent-Selector:null) Unable to initialize the threads.
java.io.IOException: SSL: Fail to init SSL! java.io.IOException: Connection
closed with -1 on reading size.
 at com.cloud.utils.nio.NioClient.init(NioClient.java:83)
 at com.cloud.utils.nio.NioConnection.run(NioConnection.java:108)
 at java.lang.Thread.run(Thread.java:679)

So I tried a telnet connection:

Connection closed by foreign host.
root@stack01:~# telnet 31.25.X.X 8250
Trying 31.25.X.X...
Connected to 31.X.X.X.
Escape character is '^]'.
Connection closed by foreign host.
root@stack01:~#

So I didn't close the connection, but it was the management server.

I cranked up the logging to DEBUG, but nothing shows in any of the logs, so
I have no clue why this isn't working.

On the mgmt server I see Java in LISTEN state on port 8250

There is no firewall on the management server (it's my lab!).

Any clues to what this could be before I start filing a in Jira? Since I'm
not sure if this is a bug.


Have you upgrade your agent?




Yes, the Agent is also 4.1


Also you could try to enable TRACE for com.cloud.utils.nio to see more
log of NIO.



I think you mean at the agent?

But what I think is weird is that the mgmt server directly closes the 
telnet connection as well and nothing shows up in the logs.


In the mgmt server log I found this:

2013-04-02 22:08:41,156 INFO  [utils.nio.NioServer] 
(AgentManager-Selector:null) NioConnection started and listening on 
0.0.0.0/0.0.0.0:8250


What I did notice is that when I shutdown the mgmt server the Agent 
connects for a second:


2013-04-02 22:07:53,689 INFO  [utils.nio.NioClient] 
(Agent-Selector:null) Connecting to 31.25.X.X:8250
2013-04-02 22:07:53,934 INFO  [utils.nio.NioClient] 
(Agent-Selector:null) SSL: Handshake done


And then the mgmt server exists and the connection gets lost.

ANY clues about this weird behavior?

Wido


--Sheng


--Sheng


Wido

Re: wiki.cloudstack.org redirect to cwiki.apache.org/confluence/display/CLOUDSTACK ?

[Chip Childers]

On Tue, Apr 02, 2013 at 12:54:15PM -0700, Kelcey Damage (BT) wrote:
> Would be nice, I have dealt with 2 issues of confusion by users today alone
> :)

Yeah, watching that is what caused the email.

Can someone with the correct rights on the old cloudstack.org
infrastructure make this happen?

> 
> -kd
>  
> 
> >-Original Message-
> >From: Chip Childers [mailto:chip.child...@sungard.com]
> >Sent: Tuesday, April 02, 2013 12:53 PM
> >To: dev@cloudstack.apache.org
> >Subject: wiki.cloudstack.org redirect to
> >cwiki.apache.org/confluence/display/CLOUDSTACK ?
> >
> >Hi all,
> >
> >What do you folks think about redirecting wiki.cloudstack.org over to
> >cwiki.apache.org/confluence/display/CLOUDSTACK ?
> >
> >I'd like to remove confusion about the active cloudstack wiki wherever
> >possible.
> >
> >-chip
> 
> 

RE: wiki.cloudstack.org redirect to cwiki.apache.org/confluence/display/CLOUDSTACK ?

[Kelcey Damage (BT)]

Would be nice, I have dealt with 2 issues of confusion by users today alone
:)

-kd
 

>-Original Message-
>From: Chip Childers [mailto:chip.child...@sungard.com]
>Sent: Tuesday, April 02, 2013 12:53 PM
>To: dev@cloudstack.apache.org
>Subject: wiki.cloudstack.org redirect to
>cwiki.apache.org/confluence/display/CLOUDSTACK ?
>
>Hi all,
>
>What do you folks think about redirecting wiki.cloudstack.org over to
>cwiki.apache.org/confluence/display/CLOUDSTACK ?
>
>I'd like to remove confusion about the active cloudstack wiki wherever
>possible.
>
>-chip

wiki.cloudstack.org redirect to cwiki.apache.org/confluence/display/CLOUDSTACK ?

[Chip Childers]

Hi all,

What do you folks think about redirecting wiki.cloudstack.org over to
cwiki.apache.org/confluence/display/CLOUDSTACK ?

I'd like to remove confusion about the active cloudstack wiki wherever
possible.

-chip

Re: Review Request: CLOUDSTACK-1846, CLOUDSTACK-1845 - KVM Storage, sometimes KVMHA will remount deleted NFS pools, causing failures when defining new storage pools.

[Chip Childers]

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

Ship it!


Ship It!

- Chip Childers


On April 1, 2013, 8:29 p.m., Marcus Sorensen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10227/
> ---
> 
> (Updated April 1, 2013, 8:29 p.m.)
> 
> 
> Review request for cloudstack and Joe Brockmeier.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-1846, CLOUDSTACK-1845 - KVM Storage, sometimes KVMHA will remount
> deleted NFS pools, causing failures when defining new storage pools. 
> Sometimes
> a storage pool has never been used on a host, and getStoragePool fails 
> when
> copying templates or in storage migration. deleteStoragePool(pool) often 
> fails
> silently, leaving no pool defined in libvirt, but a mountpoint left 
> behind.
> This patch handles some of these exceptions and brings forward any issues 
> via
> logging.
> 
> 
> This addresses bugs CLOUDSTACK-1845 and CLOUDSTACK-1846.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java
>  131c37e 
> 
> Diff: https://reviews.apache.org/r/10227/diff/
> 
> 
> Testing
> ---
> 
> Deployed new 4.0 zone in devcloud-kvm, tested volume downloads, template 
> creation, storage migration
> 
> 
> Thanks,
> 
> Marcus Sorensen
> 
>

Re: Review Request: CLOUDSTACK-1846, CLOUDSTACK-1845 - KVM Storage, sometimes KVMHA will remount deleted NFS pools, causing failures when defining new storage pools.

[ASF Subversion and Git Services]

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


Commit 3541aa86e34605e5ac4a99df84c47e6f6e7c71ee in branch refs/heads/4.0 from 
Chip Childers 
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3541aa8 ]

CLOUDSTACK-1846, CLOUDSTACK-1845 - KVM Storage, sometimes KVMHA will remount
deleted NFS pools, causing failures when defining new storage pools. Sometimes
a storage pool has never been used on a host, and getStoragePool fails when
copying templates or in storage migration. deleteStoragePool(pool) often fails
silently, leaving no pool defined in libvirt, but a mountpoint left behind.
This patch handles some of these exceptions and brings forward any issues via
logging.

Signed-off-by: Chip Childers 


- ASF Subversion and Git Services


On April 1, 2013, 8:29 p.m., Marcus Sorensen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10227/
> ---
> 
> (Updated April 1, 2013, 8:29 p.m.)
> 
> 
> Review request for cloudstack and Joe Brockmeier.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-1846, CLOUDSTACK-1845 - KVM Storage, sometimes KVMHA will remount
> deleted NFS pools, causing failures when defining new storage pools. 
> Sometimes
> a storage pool has never been used on a host, and getStoragePool fails 
> when
> copying templates or in storage migration. deleteStoragePool(pool) often 
> fails
> silently, leaving no pool defined in libvirt, but a mountpoint left 
> behind.
> This patch handles some of these exceptions and brings forward any issues 
> via
> logging.
> 
> 
> This addresses bugs CLOUDSTACK-1845 and CLOUDSTACK-1846.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java
>  131c37e 
> 
> Diff: https://reviews.apache.org/r/10227/diff/
> 
> 
> Testing
> ---
> 
> Deployed new 4.0 zone in devcloud-kvm, tested volume downloads, template 
> creation, storage migration
> 
> 
> Thanks,
> 
> Marcus Sorensen
> 
>

Re: [MERGE] bvt branch to master

[Rohit Yadav]

Awesome, thanks for your work Prasanna, do we have a jenkins job yet?

Cheers.

On Tue, Apr 2, 2013 at 7:59 PM, Prasanna Santhanam  wrote:

> On Thu, Mar 28, 2013 at 07:36:58PM +0530, Prasanna Santhanam wrote:
> > I'd like to merge the bvt branch into master. The proposal [1] was to
> > stabilize master by allowing devs to quickly setup CloudStack using
> > simulated hypervisors and run some basic tests against it.
> >
> > The bvt branch integrates the testing of cloudstack using marvin and
> > the simulator hypervisor. Alternately you may use devcloud as well
> > with the appropriate maven profiles enabled. One can try the
> > integrated tests today as described in [2]
> >
> > While this is not to be touted as the magic pill for master stability
> > I think it is a good first step towards bringing together tests as
> > part of the build system. I've tested the steps on Linux and OSX.
> >
> > [1] http://s.apache.org/5Lc
> > [2] https://cwiki.apache.org/confluence/x/PgvMAQ
> >
> > Thanks,
>
> This branch is now merged to master. All commits were rebased
> logically and grouped before push.
>
> b798c451141c32d46322aae83063eeaa9634b337 maven+marvin+simulator: Changes
> to the lifecycle steps
> 82fd9382b7497f1ee753e1298a9db1aed325fbc6 marvin+sync: apidiscovery sync
> and regenerate for marvin
> 5d67c98e5b7b763fde5ea87850e9cd7bafd2a4e1 marvin+apidiscovery: Extend API
> discovery plugin
> 9c755e11e5067bfbc14581a3a3fac9b5b7fd21a1 marvin-nose: include the plugin
> as part of marvin install
> 2e2046fe389b79b2b105ef40b792263cee831929 marvin changes to do an
> pre-integration and integration test
>
> Thanks,
>
> --
> Prasanna.,
>

Re: CLOUDSTACK-1842: ASF 4.0 to 4.1 Upgrade: Missing Ubuntu 12.04 Guest OS Types on the Upgraded Setup

[Chip Childers]

On Mon, Apr 1, 2013 at 3:46 PM, Chip Childers  wrote:
> I went digging into CLOUDSTACK-1842, and I see the following:
>
> In looking at the SQL scripts, I see that the guest_os and
> guest_os_hypervisor tables are typically populated via the upgrade
> scripts during an upgrade.
>
> I also see that templates.sql has the data to populate these tables:
>
> INSERT INTO `cloud`.`guest_os` (id, uuid, category_id, display_name) VALUES 
> (163, UUID(), 10, 'Ubuntu 12.04 (32-bit)');
> INSERT INTO `cloud`.`guest_os` (id, uuid, category_id, display_name) VALUES 
> (164, UUID(), 10, 'Ubuntu 12.04 (64-bit)');
>
> and for VMware:
>
> INSERT INTO `cloud`.`guest_os_hypervisor` (hypervisor_type, guest_os_name, 
> guest_os_id) VALUES ("VmWare", 'Ubuntu 12.04 (32-bit)', 162);
> INSERT INTO `cloud`.`guest_os_hypervisor` (hypervisor_type, guest_os_name, 
> guest_os_id) VALUES ("VmWare", 'Ubuntu 12.04 (64-bit)', 163);
>
> Nothing is in templates.sql for Ubuntu 12.04 on KVM, and no Ubuntu
> (any version) for XenServer.  Is this right?  Also, should we
> populate Ubuntu 12.04 into guest_os and guest_os_hypervisor via the
> 40to41 upgrade script?
>
> -chip

Animesh - I see you assigned this one to yourself.  Just ACK back if
you are going to work on fixing it up please!

Re: deleteStoragePool API Command

[Mike Tutkowski]

Spoke too soon. :)

I just ran a quick test and you do have to put the Primary Storage in
maintenance mode prior to deleting it with the API, too.


On Tue, Apr 2, 2013 at 1:37 PM, Mike Tutkowski  wrote:

> Hi,
>
> Is it required that a primary storage be in maintenance mode before
> calling the deleteStoragePool API command?
>
> In the GUI, you have to do this, but I wasn't sure if it was the same for
> the API.
>
> Thanks!
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the 
> cloud
> *™*
>



-- 
*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][DOCS] CLOUDSTACK-1837: Document additonal Steps ( Restart of all system Vms , copy vhd-utils) to be included in the upgrade procedure from 4.0 -> 4.1

[Chip Childers]

Can someone take this docs bug for 4.1 please?

https://issues.apache.org/jira/browse/CLOUDSTACK-1837
Document additonal Steps ( Restart of all system Vms , copy vhd-utils)
to be included in the upgrade procedure from 4.0 -> 4.1

Re: Question pertaining to the Support of ACL deny rules

[Chiradeep Vittal]

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

deleteStoragePool API Command

[Mike Tutkowski]

Hi,

Is it required that a primary storage be in maintenance mode before calling
the deleteStoragePool API command?

In the GUI, you have to do this, but I wasn't sure if it was the same for
the API.

Thanks!

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

Re: [DISCUSS] RESTful API for CloudStack agents

[Chip Childers]

On Tue, Apr 02, 2013 at 03:14:46PM -0400, Sebastien Goasguen wrote:
> 
> On Apr 2, 2013, at 3:00 PM, Donal Lafferty  wrote:
> 
> > Could I get some feedback on the following strategy for mapping CloudStack 
> > RPC commands to HTTP requests?
> > 
> > The general approach is to:
> > 1. map each category of command to a URL.  Each category corresponds 
> > roughly to a resource type being manipulated.
> > E.g. /cloudstack/latest/storagepool/
> > 2. make the command itself a path under the category
> > E.g. /cloudstack/latest/storagepool/create
> > 3. make resource changes using a POST request with parameters JSON encoded 
> > in the body
> > E.g.
> > 
> > POST /cloudstack/latest/storagepool/{create | modify | destroy}
> > POST /cloudstack/latest/volumes/{create | destroy}
> > POST /cloudstack/latest/vm/{start | stop}
> > 4. query resource state using a GET request that identifies specific 
> > resources with a query parameter
> > E.g. GET /cloudstack/latest/vm?id=1&id=2&id=3
> > 
> > 
> 
> I just read something about it the other day, and it seems people are 
> starting to use PATCH to update .
> 
> So POST would be to create, PATCH to update, GET to list….
> 
> so everything fits under /cloudstack/storagepool/ no need for a /create...

Not to be considered too much of a REST-afarian, consider the difference
in meaning between a PUT and PATCH.

PUT should be used to replace the resource in question with the contents
provided in the request. [1]

PATCH should be used when "patching" (or partially modifying) the resource in
question. [2]

-chip

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6
[2] http://tools.ietf.org/html/rfc5789

Re: Review Request: CLOUDSTACK-1890: listProjects is not listing state in the response

[ASF Subversion and Git Services]

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


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

CLOUDSTACK-1890: listProjects is not listing state in the response.


- ASF Subversion and Git Services


On April 2, 2013, 6:46 p.m., Min Chen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10240/
> ---
> 
> (Updated April 2, 2013, 6:46 p.m.)
> 
> 
> Review request for cloudstack and Chip Childers.
> 
> 
> Description
> ---
> 
> This patch fixed the bug CLOUDSTACK-1890, wrong State class is imported in 
> ProjectJoinVO class.
> 
> 
> This addresses bug https://issues.apache.org/jira/browse/CLOUDSTACK-1890.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/api/query/vo/ProjectJoinVO.java 73ec931 
> 
> Diff: https://reviews.apache.org/r/10240/diff/
> 
> 
> Testing
> ---
> 
> Tested locally.
> 
> 
> Thanks,
> 
> Min Chen
> 
>

Re: Review Request: CLOUDSTACK-1890: listProjects is not listing state in the response

[Chip Childers]

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

Ship it!


Ship It!

- Chip Childers


On April 2, 2013, 6:46 p.m., Min Chen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10240/
> ---
> 
> (Updated April 2, 2013, 6:46 p.m.)
> 
> 
> Review request for cloudstack and Chip Childers.
> 
> 
> Description
> ---
> 
> This patch fixed the bug CLOUDSTACK-1890, wrong State class is imported in 
> ProjectJoinVO class.
> 
> 
> This addresses bug https://issues.apache.org/jira/browse/CLOUDSTACK-1890.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/api/query/vo/ProjectJoinVO.java 73ec931 
> 
> Diff: https://reviews.apache.org/r/10240/diff/
> 
> 
> Testing
> ---
> 
> Tested locally.
> 
> 
> Thanks,
> 
> Min Chen
> 
>

Re: Review Request: CLOUDSTACK-1890: listProjects is not listing state in the response

[ASF Subversion and Git Services]

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


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

CLOUDSTACK-1890: listProjects is not listing state in the response.


- ASF Subversion and Git Services


On April 2, 2013, 6:46 p.m., Min Chen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10240/
> ---
> 
> (Updated April 2, 2013, 6:46 p.m.)
> 
> 
> Review request for cloudstack and Chip Childers.
> 
> 
> Description
> ---
> 
> This patch fixed the bug CLOUDSTACK-1890, wrong State class is imported in 
> ProjectJoinVO class.
> 
> 
> This addresses bug https://issues.apache.org/jira/browse/CLOUDSTACK-1890.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/api/query/vo/ProjectJoinVO.java 73ec931 
> 
> Diff: https://reviews.apache.org/r/10240/diff/
> 
> 
> Testing
> ---
> 
> Tested locally.
> 
> 
> Thanks,
> 
> Min Chen
> 
>

[DISCUSS] Don't assign tickets to people when triaging

[Noah Slater]

Dear community,

Right now, we have people who are regularly going through JIRA and triaging
tickets. This is totally fantastic, and a very valuable activity for the
project. (So thank you!) But I also notice that specific individuals are
being assigned to the tickets in the process.

This is a form of "cookie licking". The analogy is that if you fancy a
cookie, but you're too hungry right now, you take a lick of it so nobody
else can touch it. This is an anti-pattern and we should try to avoid it.

In general, I would say we should only be assigning a ticket to ourselves,
and we should only be doing that when we actually intend to sit down and
work on it.

If we have people going through and saying "well, this is clearly Joe's
area" or "this is clearly Fred's area" then that is a great way to make
sure that those areas remain "Joe's area" or "Fred's area" or whatever.
Which is unhealthy for the project.

So what I would suggest is that we consider changing the way we work here.

Ticket triage might change so that tickets are put on to component
backlogs. And engineers can switch from grabbing tickets of their "assigned
to me" report, and start looking at the "Foo feature backlog" report
instead. Selecting a ticket and assigning it *to themselves* when they are
*starting work on it*.

(This would then take the ticket off the component backlog. So the backlog
report would only display tickets that were unassigned and available to
grab.)

This would mean that all this valuable ticket triage work we're doing is
something that can benefit everyone in the project (not just people who are
already known for their contributions) and will hopefully open the
development workflow to people who are just starting out with the project,
or want to get their toes wet.

In fact, when someone comes to us and asks "how can I contribute" we can
point them at these backlogs and say "well, just grab a ticket off one of
these queues, assign it to yourself, and start working on it!" We could
make use of a "difficulty" field too, so you could sort by difficulty, and
grab one of the "easy", "medium", or "hard" tickets.

Thoughts?

-- 
NS

Re: [ACS42][QA] Host level scope while adding Primary storage

[Ahmad Emneina]

just make sure to enable local storage when defining the zone, then each
host that gets added will add its local storage as a potential volume
destination.


On Tue, Apr 2, 2013 at 2:16 AM, Srikanteswararao Talluri <
srikanteswararao.tall...@citrix.com> wrote:

>
>
> > -Original Message-
> > From: Sailaja Mada [mailto:sailaja.m...@citrix.com]
> > Sent: Tuesday, April 02, 2013 2:28 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [ACS42][QA] Host level scope while adding Primary storage
> >
> > I see. Actually mine is Xenserver.  I see that there is a defect created
> to enable
> > host level scope only for KVM.
>
> It's the other way, currently , scope of the primary storage can be
> selected as Zone/Cluster for zones with KVM hypervisor.
> Zone wide primary storage is not yet supported for other hypervisors.
>
> Local storage is added by default as the local storage attached to a host.
> User don't add it explicitly.
>
> >
> > Thanks Talluri & Sateesh.
> >
> > Regards,
> > Sailaja.M
> >
> > -Original Message-
> > From: Srikanteswararao Talluri [mailto:
> srikanteswararao.tall...@citrix.com]
> > Sent: Tuesday, April 02, 2013 2:22 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [ACS42][QA] Host level scope while adding Primary storage
> >
> > Host means the storage is attached to a particular hypervisor host,
> a.k.a, it's the
> > local storage.
> >
> > Thanks,
> > ~Talluri
> >
> > > -Original Message-
> > > From: Sailaja Mada [mailto:sailaja.m...@citrix.com]
> > > Sent: Tuesday, April 02, 2013 1:51 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: [ACS42][QA] Host level scope while adding Primary storage
> > >
> > > Hi,
> > >
> > > With 4.2,  I see that primary storage scope is defined @ host level
> > > along with Cluster and Zone-wide .
> > >
> > > I am aware of Zone-wide primary storage. Can some one point me about
> > > host level primary storage ?
> > >
> > > Thanks,
> > > Sailaja.M
>

Re: [DISCUSS] RESTful API for CloudStack agents

[Sebastien Goasguen]

On Apr 2, 2013, at 3:00 PM, Donal Lafferty  wrote:

> Could I get some feedback on the following strategy for mapping CloudStack 
> RPC commands to HTTP requests?
> 
> The general approach is to:
> 1. map each category of command to a URL.  Each category corresponds roughly 
> to a resource type being manipulated.
> E.g. /cloudstack/latest/storagepool/
> 2. make the command itself a path under the category
> E.g. /cloudstack/latest/storagepool/create
> 3. make resource changes using a POST request with parameters JSON encoded in 
> the body
> E.g.
> 
> POST /cloudstack/latest/storagepool/{create | modify | destroy}
> POST /cloudstack/latest/volumes/{create | destroy}
> POST /cloudstack/latest/vm/{start | stop}
> 4. query resource state using a GET request that identifies specific 
> resources with a query parameter
> E.g. GET /cloudstack/latest/vm?id=1&id=2&id=3
> 
> 

I just read something about it the other day, and it seems people are starting 
to use PATCH to update .

So POST would be to create, PATCH to update, GET to list….

so everything fits under /cloudstack/storagepool/ no need for a /create...

> 
> Commands are mapped to paths for simplicity.  Identifying CRUD operations 
> such as create, modify and destroy from the path limits the HTTP methods to 
> POST and GET.
> Serialising parameters as JSON in the body of a POST request is for 
> simplicity.  Passing all command data in the URI is difficult, because URIs 
> are ill suited to expressing object trees that exist in complex commands such 
> as the VM StartCommand.  Since parameters such as VM identifier are already 
> in the body, static URIs can be used for many commands.
> 
> Commands that push data from the agent to the server have to be implemented 
> as polling operations.  This applies to initial configuration commands and 
> the hypervisor ping.  Agent configuration will come from HTTP POST versions 
> of StartupRoutingCommand and StartupStorageCommand, rather than a config file 
> copied to the hypervisor as was done with KVM.  To simulate a PingCommand the 
> ServerComponent will use a HTTP GET.
> 
> Versioning is by way of dated path rather than version number.  Assuming the 
> latest API is completed 2013/02/04,
> 
> /cloudstack/latest
> and
> 
> /cloudstack/2013-04-02
> refer to the same API.
> 

[DISCUSS] RESTful API for CloudStack agents

[Donal Lafferty]

Could I get some feedback on the following strategy for mapping CloudStack RPC 
commands to HTTP requests?

The general approach is to:
1. map each category of command to a URL.  Each category corresponds roughly to 
a resource type being manipulated.
E.g. /cloudstack/latest/storagepool/
2. make the command itself a path under the category
E.g. /cloudstack/latest/storagepool/create
3. make resource changes using a POST request with parameters JSON encoded in 
the body
E.g.

POST /cloudstack/latest/storagepool/{create | modify | destroy}
POST /cloudstack/latest/volumes/{create | destroy}
POST /cloudstack/latest/vm/{start | stop}
4. query resource state using a GET request that identifies specific resources 
with a query parameter
E.g. GET /cloudstack/latest/vm?id=1&id=2&id=3



Commands are mapped to paths for simplicity.  Identifying CRUD operations such 
as create, modify and destroy from the path limits the HTTP methods to POST and 
GET.
Serialising parameters as JSON in the body of a POST request is for simplicity. 
 Passing all command data in the URI is difficult, because URIs are ill suited 
to expressing object trees that exist in complex commands such as the VM 
StartCommand.  Since parameters such as VM identifier are already in the body, 
static URIs can be used for many commands.

Commands that push data from the agent to the server have to be implemented as 
polling operations.  This applies to initial configuration commands and the 
hypervisor ping.  Agent configuration will come from HTTP POST versions of 
StartupRoutingCommand and StartupStorageCommand, rather than a config file 
copied to the hypervisor as was done with KVM.  To simulate a PingCommand the 
ServerComponent will use a HTTP GET.

Versioning is by way of dated path rather than version number.  Assuming the 
latest API is completed 2013/02/04,

/cloudstack/latest
and

/cloudstack/2013-04-02
refer to the same API.

Re: [ACS41] Management server closes connection on port 8250

[Sheng Yang]

On Tue, Apr 2, 2013 at 11:49 AM, Sheng Yang  wrote:
> On Tue, Apr 2, 2013 at 11:32 AM, Wido den Hollander  wrote:
>> Hi,
>>
>> Since I've upgraded my management server to 4.1 my agents refuse to connect,
>> their log says:
>>
>> 2013-04-02 20:26:11,207 INFO  [utils.nio.NioClient] (Agent-Selector:null)
>> Connecting to 31.25.X.X:8250
>> 2013-04-02 20:26:11,209 ERROR [utils.nio.NioConnection]
>> (Agent-Selector:null) Unable to initialize the threads.
>> java.io.IOException: SSL: Fail to init SSL! java.io.IOException: Connection
>> closed with -1 on reading size.
>> at com.cloud.utils.nio.NioClient.init(NioClient.java:83)
>> at com.cloud.utils.nio.NioConnection.run(NioConnection.java:108)
>> at java.lang.Thread.run(Thread.java:679)
>>
>> So I tried a telnet connection:
>>
>> Connection closed by foreign host.
>> root@stack01:~# telnet 31.25.X.X 8250
>> Trying 31.25.X.X...
>> Connected to 31.X.X.X.
>> Escape character is '^]'.
>> Connection closed by foreign host.
>> root@stack01:~#
>>
>> So I didn't close the connection, but it was the management server.
>>
>> I cranked up the logging to DEBUG, but nothing shows in any of the logs, so
>> I have no clue why this isn't working.
>>
>> On the mgmt server I see Java in LISTEN state on port 8250
>>
>> There is no firewall on the management server (it's my lab!).
>>
>> Any clues to what this could be before I start filing a in Jira? Since I'm
>> not sure if this is a bug.
>
> Have you upgrade your agent?

Also you could try to enable TRACE for com.cloud.utils.nio to see more
log of NIO.

--Sheng
>
> --Sheng
>>
>> Wido

Re: [ACS41] Management server closes connection on port 8250

[Sheng Yang]

On Tue, Apr 2, 2013 at 11:32 AM, Wido den Hollander  wrote:
> Hi,
>
> Since I've upgraded my management server to 4.1 my agents refuse to connect,
> their log says:
>
> 2013-04-02 20:26:11,207 INFO  [utils.nio.NioClient] (Agent-Selector:null)
> Connecting to 31.25.X.X:8250
> 2013-04-02 20:26:11,209 ERROR [utils.nio.NioConnection]
> (Agent-Selector:null) Unable to initialize the threads.
> java.io.IOException: SSL: Fail to init SSL! java.io.IOException: Connection
> closed with -1 on reading size.
> at com.cloud.utils.nio.NioClient.init(NioClient.java:83)
> at com.cloud.utils.nio.NioConnection.run(NioConnection.java:108)
> at java.lang.Thread.run(Thread.java:679)
>
> So I tried a telnet connection:
>
> Connection closed by foreign host.
> root@stack01:~# telnet 31.25.X.X 8250
> Trying 31.25.X.X...
> Connected to 31.X.X.X.
> Escape character is '^]'.
> Connection closed by foreign host.
> root@stack01:~#
>
> So I didn't close the connection, but it was the management server.
>
> I cranked up the logging to DEBUG, but nothing shows in any of the logs, so
> I have no clue why this isn't working.
>
> On the mgmt server I see Java in LISTEN state on port 8250
>
> There is no firewall on the management server (it's my lab!).
>
> Any clues to what this could be before I start filing a in Jira? Since I'm
> not sure if this is a bug.

Have you upgrade your agent?

--Sheng
>
> Wido

Review Request: CLOUDSTACK-1890: listProjects is not listing state in the response

[Min Chen]

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

Review request for cloudstack and Chip Childers.


Description
---

This patch fixed the bug CLOUDSTACK-1890, wrong State class is imported in 
ProjectJoinVO class.


This addresses bug https://issues.apache.org/jira/browse/CLOUDSTACK-1890.


Diffs
-

  server/src/com/cloud/api/query/vo/ProjectJoinVO.java 73ec931 

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


Testing
---

Tested locally.


Thanks,

Min Chen

[ACS41] Management server closes connection on port 8250

[Wido den Hollander]

Hi,

Since I've upgraded my management server to 4.1 my agents refuse to 
connect, their log says:


2013-04-02 20:26:11,207 INFO  [utils.nio.NioClient] 
(Agent-Selector:null) Connecting to 31.25.X.X:8250
2013-04-02 20:26:11,209 ERROR [utils.nio.NioConnection] 
(Agent-Selector:null) Unable to initialize the threads.
java.io.IOException: SSL: Fail to init SSL! java.io.IOException: 
Connection closed with -1 on reading size.

at com.cloud.utils.nio.NioClient.init(NioClient.java:83)
at com.cloud.utils.nio.NioConnection.run(NioConnection.java:108)
at java.lang.Thread.run(Thread.java:679)

So I tried a telnet connection:

Connection closed by foreign host.
root@stack01:~# telnet 31.25.X.X 8250
Trying 31.25.X.X...
Connected to 31.X.X.X.
Escape character is '^]'.
Connection closed by foreign host.
root@stack01:~#

So I didn't close the connection, but it was the management server.

I cranked up the logging to DEBUG, but nothing shows in any of the logs, 
so I have no clue why this isn't working.


On the mgmt server I see Java in LISTEN state on port 8250

There is no firewall on the management server (it's my lab!).

Any clues to what this could be before I start filing a in Jira? Since 
I'm not sure if this is a bug.


Wido

RE: [DISCUSS] Affinity / Anti-affinity Rules

[Prachi Damle]

Hi Sangeetha,

Answered inline,

Prachi

-Original Message-
From: Sangeetha Hariharan [mailto:sangeetha.hariha...@citrix.com] 
Sent: Tuesday, April 02, 2013 11:08 AM
To: dev@cloudstack.apache.org; cloudstack-...@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules

Prachi , Thanks for your response.
Had 1 follow up question :

5.DeleteAffinityGroup API:
Can this API  be used to delete an Affinity Group / Can it be used to only to 
remove an existing VM from an affinity group? 
Why is there a need to pass AccountName and DomainId for this API call ? Is 
Affinity Group Id not enough to uniquely identify this entity ?

[Prachi] It is for deleting groups of an account. The API also takes in the 
user-friendly group name too, in which case the account info is needed.
To delete VM's association to the group, updateVMAffinityGroup API will serve 
the purpose.

[Sangeetha] - How can I use updateVMAffinityGroup API() to remove the vm from 
an affinityGroup? 
By calling this API with a affinityGroup and VM , I thought we will associate 
this VM to the affinity group ? Is that correct?

[Prachi] It is update the set of affinity groups of a VM. So this call will 
wipe out the existing group associations of the VM and create the new 
associations.
If you do not include some existing affinity group in this API call, it will 
get removed.

-Thanks
Sangeetha

-Original Message-
From: Prachi Damle [mailto:prachi.da...@citrix.com] 
Sent: Monday, April 01, 2013 7:51 PM
To: dev@cloudstack.apache.org; cloudstack-...@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules

Comments inline. 

Thanks,
Prachi

-Original Message-
From: Sangeetha Hariharan [mailto:sangeetha.hariha...@citrix.com] 
Sent: Monday, April 01, 2013 5:45 PM
To: cloudstack-...@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules

Had the following questions after going over the spec - 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups
 :

1.In the API changes section - For all the API calls listed can we include if 
the parameters are optional/Required?

2.Can new DB changes introduced by this feature be included  ?

[Prachi] Will update FS with this info.

3.CreateAffinityGroup API: 
Using this API can admin/domain admin user be able to create an affinity group 
for other accounts to use ? Or can it be created only for its own consumption?

[Prachi] No, affinity groups can be created and used by individual account 
only. Affinity groups are a way for the user to specify her/his deployment 
preference, so the visibility/usage is limited to the account only.

4.ListAffinityGroups API:
Will admin/domain admin user be able to list the affinity groups of the other 
regular users ?

[Prachi] No, same as above.

5.DeleteAffinityGroup API:
Can this API  be used to delete an Affinity Group / Can it be used to only to 
remove an existing VM from an affinity group? 
Why is there a need to pass AccountName and DomainId for this API call ? Is 
Affinity Group Id not enough to uniquely identify this entity ?

[Prachi] It is for deleting groups of an account. The API also takes in the 
user-friendly group name too, in which case the account info is needed.
To delete VM's association to the group, updateVMAffinityGroup API will serve 
the purpose.

6. Will Affinity rules apply when we stop and start the Vms? Will it be applied 
when CloudStack performs HA ? 

[Prachi] Yes. 

7.When User tries to migrate/live migrate the VM , will the action to migrate a 
VM to a host that does not satisfy the affinity rule fail ?

[Prachi] When root Admin lists hosts available for live migration, CS will 
indicate the hosts that do not fit the affinity rules as 'Not Suitable'. If 
admin still goes ahead and migrates to such a host, migration will proceed.

8.DeployVirtualMachine API:  It is mentioned in the FS that  affinitygroupids 
OR affinitygroupnames need to be passed. If both are passed will the API fail ?

[Prachi] yes

9.Is there any difference in implementation for this feature between a Basic 
Zone and Advanced zone ?  

[Prachi] Nope

10. In cases where there is a mismatch between service offering (host tag and 
storage tag) and anti-affinity group that the Vm is being deployed with , will 
the error message provided to the user be informative enough to know why the 
deployment failure happened (due to service offerings vs anti-affinity group) 
to take corrective actions?

[Prachi] No, it will still throw out the generic InsufficentCapacity error - 
and this is correct, since the underlying error is still not enough compute or 
storage capacity in the datacenter to _match_ your needs.
The logs will however show that the affinity rules + tags are being applied - 
causing no match found.

11. When a VM is in "Stopped" state , will it continue to be  part of the 
affinity group ?  Or will its association with the affinity group be released 
immediately, so t

RE: [DISCUSS] Affinity / Anti-affinity Rules

[Sangeetha Hariharan]

Prachi , Thanks for your response.
Had 1 follow up question :

5.DeleteAffinityGroup API:
Can this API  be used to delete an Affinity Group / Can it be used to only to 
remove an existing VM from an affinity group? 
Why is there a need to pass AccountName and DomainId for this API call ? Is 
Affinity Group Id not enough to uniquely identify this entity ?

[Prachi] It is for deleting groups of an account. The API also takes in the 
user-friendly group name too, in which case the account info is needed.
To delete VM's association to the group, updateVMAffinityGroup API will serve 
the purpose.

[Sangeetha] - How can I use updateVMAffinityGroup API() to remove the vm from 
an affinityGroup? 
By calling this API with a affinityGroup and VM , I thought we will associate 
this VM to the affinity group ? Is that correct?

-Thanks
Sangeetha

-Original Message-
From: Prachi Damle [mailto:prachi.da...@citrix.com] 
Sent: Monday, April 01, 2013 7:51 PM
To: dev@cloudstack.apache.org; cloudstack-...@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules

Comments inline. 

Thanks,
Prachi

-Original Message-
From: Sangeetha Hariharan [mailto:sangeetha.hariha...@citrix.com] 
Sent: Monday, April 01, 2013 5:45 PM
To: cloudstack-...@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules

Had the following questions after going over the spec - 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups
 :

1.In the API changes section - For all the API calls listed can we include if 
the parameters are optional/Required?

2.Can new DB changes introduced by this feature be included  ?

[Prachi] Will update FS with this info.

3.CreateAffinityGroup API: 
Using this API can admin/domain admin user be able to create an affinity group 
for other accounts to use ? Or can it be created only for its own consumption?

[Prachi] No, affinity groups can be created and used by individual account 
only. Affinity groups are a way for the user to specify her/his deployment 
preference, so the visibility/usage is limited to the account only.

4.ListAffinityGroups API:
Will admin/domain admin user be able to list the affinity groups of the other 
regular users ?

[Prachi] No, same as above.

5.DeleteAffinityGroup API:
Can this API  be used to delete an Affinity Group / Can it be used to only to 
remove an existing VM from an affinity group? 
Why is there a need to pass AccountName and DomainId for this API call ? Is 
Affinity Group Id not enough to uniquely identify this entity ?

[Prachi] It is for deleting groups of an account. The API also takes in the 
user-friendly group name too, in which case the account info is needed.
To delete VM's association to the group, updateVMAffinityGroup API will serve 
the purpose.

6. Will Affinity rules apply when we stop and start the Vms? Will it be applied 
when CloudStack performs HA ? 

[Prachi] Yes. 

7.When User tries to migrate/live migrate the VM , will the action to migrate a 
VM to a host that does not satisfy the affinity rule fail ?

[Prachi] When root Admin lists hosts available for live migration, CS will 
indicate the hosts that do not fit the affinity rules as 'Not Suitable'. If 
admin still goes ahead and migrates to such a host, migration will proceed.

8.DeployVirtualMachine API:  It is mentioned in the FS that  affinitygroupids 
OR affinitygroupnames need to be passed. If both are passed will the API fail ?

[Prachi] yes

9.Is there any difference in implementation for this feature between a Basic 
Zone and Advanced zone ?  

[Prachi] Nope

10. In cases where there is a mismatch between service offering (host tag and 
storage tag) and anti-affinity group that the Vm is being deployed with , will 
the error message provided to the user be informative enough to know why the 
deployment failure happened (due to service offerings vs anti-affinity group) 
to take corrective actions?

[Prachi] No, it will still throw out the generic InsufficentCapacity error - 
and this is correct, since the underlying error is still not enough compute or 
storage capacity in the datacenter to _match_ your needs.
The logs will however show that the affinity rules + tags are being applied - 
causing no match found.

11. When a VM is in "Stopped" state , will it continue to be  part of the 
affinity group ?  Or will its association with the affinity group be released 
immediately, so that new Vms deployed as part of this anti-affinity group can 
use the host on which the Vm was running before it was stopped.  

[Prachi] Good point. The association with affinity group is maintained. We 
never remove it unless user removes. But yes, it makes sense to avoid deploying 
new VMs in the same group, on that host. So host-anti-affinity should also 
consider last_host_id of the VM's that are in stopped state.

Thanks
Sangeetha

-Original Message-
From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] 
Sent: Friday, March 

RE: [VMWARE]Any way to allow concurrent operations?

[Musayev, Ilya]

Kelven

Thanks for the response,

As it stands, the serial operations - even for storage maintenance - are 
unbearably slow - especially if your storage can handle many more concurrent 
tasks

Same applies for host maintenance mode, or any other operation like VM 
creation/deployment process. Everything is done in sequence. 

This approach is probably OK for small environments, but for really large 
implementations - when you need to spin instance up and down without waiting 
for a really long queue, or some other operation to complete .

For example, just now a colleague of mine added a windows template, at the same 
time I decide to provision more linux host. His windows template is about 5 GB 
in size, he kicked of his tasks for the first time, while I kicked off mine 
right after him.

As the result, I had to wait for his template to be initially deployed first, 
before my job can start. His job took about 20-30 minutes, my job takes less 
than 30 seconds. I understand this maybe a corner case, but our SLA can get 
really skewed if someone decides to add a new large sized template. If template 
additions are automated, we can go into a swing state on timing.

Like you mentioned, we need more concurrency.

Thanks
ilya

-Original Message-
From: Kelven Yang [mailto:kelven.y...@citrix.com] 
Sent: Tuesday, April 02, 2013 1:27 PM
To: dev@cloudstack.apache.org
Subject: Re: [VMWARE]Any way to allow concurrent operations?

We don't use queue facility/concurrency management within CloudStack 
extensively for now, the orchestration flow (i.e., putting storage into 
maintenance process) should launch concurrent tasks and manage it properly to 
achieve maximum of concurrency without breaking integrity of the operation. 

We do need to add more convenient facilities at framework level to enable these 
apparently needed features in various individual orchestration flows. Currently 
we write most of orchestration flows in a sequential execution manner.

Kelven

On 4/2/13 8:12 AM, "Marcus Sorensen"  wrote:

>Edison was saying something about executeInSequence, causing the serial 
>operations, and how it was a compatibility thing. He said he removed it 
>once as a test and it seemed to work for concurrent operations on KVM, 
>but I don't know much about it. Just thought it was worth mentioning.
>
>
>On Tue, Apr 2, 2013 at 9:06 AM, Chip Childers
>wrote:
>
>> On Tue, Apr 02, 2013 at 02:56:24PM +, Musayev, Ilya wrote:
>> > Long story short - due to the fact, we do things serially, any mass
>> operation will be queued, and may take very long time to complete.
>> >
>> > We need to improve this area, as its going to be one of the major
>> complaints in the near future for corporate users that run vmware.
>>
>> Sounds like something that we should create as an "Improvement" ticket.
>>

Re: Master broken

[Kelven Yang]

I've applied a commit 5782abf8f80fce929e3d6e20068bc165f2360426 to address
these test configuration fix already. This was done at last Friday.

Kelven 



On 4/2/13 9:39 AM, "Alena Prokharchyk" 
wrote:

>The test itself is written by me. It doesn't touch the DB - I mock
>"persist" method of the corresponding Dao. The test was added about 2
>weeks ago to master branch, and it was running fine the last time I've
>checked - last Friday.
>
>As Pranav stated, the test got broken with commit
>5782abf8f80fce929e3d6e20068bc165f2360426, and related to UserContext
>initializing.
>
>-Alena. 
>
>On 4/2/13 1:32 AM, "Pranav Saxena"  wrote:
>
>>Yeah I saw that . Thanks Hugo . I hope master is stable now though I
>>haven't got a change to build it again.
>>
>>Regards,
>>Pranav
>>
>>-Original Message-
>>From: Hugo Trippaers [mailto:htrippa...@schubergphilis.com]
>>Sent: Tuesday, April 02, 2013 1:37 PM
>>To: dev@cloudstack.apache.org; cloudstack-...@incubator.apache.org
>>Subject: RE: Master broken
>>
>>Thanks Pranav,
>>
>>I couldn't find an easy way to fix the test so I indeed disabled it. See
>>commit df6b97c194caa8b34fa14bf5164eb2fe1f26b2b1.
>>
>>Raised a ticket for Kelven (CLOUDSTACK-1884) to have a look at it.
>>
>>Cheers,
>>
>>Hugo
>>
>>> -Original Message-
>>> From: Pranav Saxena [mailto:pranav.sax...@citrix.com]
>>> Sent: dinsdag 2 april 2013 10:04
>>> To: dev@cloudstack.apache.org; cloudstack-...@incubator.apache.org
>>> Subject: RE: Master broken
>>> 
>>> This commit deals with the tests for create network offering - Commit:
>>> 5782abf8f80fce929e3d6e20068bc165f2360426 and I am presuming because of
>>> this only the test is failing.
>>> 
>>> You might need to revert the commit if required.
>>> 
>>> Thanks,
>>> Pranav
>>> 
>>> -Original Message-
>>> From: Hugo Trippaers [mailto:htrippa...@schubergphilis.com]
>>> Sent: Tuesday, April 02, 2013 12:32 PM
>>> To: cloudstack-...@incubator.apache.org
>>> Subject: Master broken
>>> 
>>> Heya all,
>>> 
>>> Master branch appears to be broken. Is anybody working on this?
>>> 
>>> The failed tests are:
>>> >>> 
>>> >>>org.apache.cloudstack.networkoffering.CreateNetworkOfferingTest.cre
>>> ateSharedNtwkOffWithNoVlan
>>> >>> 
>>> >>>org.apache.cloudstack.networkoffering.CreateNetworkOfferingTest.cre
>>> ateSharedNtwkOffWithoutSpecifyIpRanges
>>> >>> 
>>> >>>org.apache.cloudstack.networkoffering.CreateNetworkOfferingTest.cre
>>> ateIsolatedNtwkOffWithSpecifyIpRangesAndSourceNat
>>> >>> 
>>> >>>org.apache.cloudstack.networkoffering.CreateNetworkOfferingTest.cre
>>> ateSharedNtwkOffWithVlan
>>> >>> 
>>> >>>org.apache.cloudstack.networkoffering.CreateNetworkOfferingTest.cre
>>> ateSharedNtwkOffWithSpecifyIpRanges
>>> >>> 
>>> >>>org.apache.cloudstack.networkoffering.CreateNetworkOfferingTest.cre
>>> ateIsolatedNtwkOffWithNoVlan
>>> >>> 
>>> >>>org.apache.cloudstack.networkoffering.CreateNetworkOfferingTest.cre
>>> ateIsolatedNtwkOffWithVlan
>>> >>> 
>>> >>>org.apache.cloudstack.networkoffering.CreateNetworkOfferingTest.cre
>>> ateIsolatedNtwkOffWithSpecifyIpRangesAndNoSourceNat
>>> 
>>> 
>>> It appears to have something to do with the CreateNetworkOfferingTest
>>> trying to use the database (which is never there during test runs)
>>> 
>>> I'm looking at it, but if somebody else is doing that as well we might
>>> pool resources.
>>> 
>>> Cheers,
>>> 
>>> Hugo
>>
>>
>
>

Re: Review Request: CLOUDSTACK-1830: ZWPS: NPE while create volume from snapshot

[edison su]

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

Ship it!


Ship It!

- edison su


On April 2, 2013, 1:53 p.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10239/
> ---
> 
> (Updated April 2, 2013, 1:53 p.m.)
> 
> 
> Review request for cloudstack and Abhinandan Prateek.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-1830:  ZWPS: NPE while create volume from snapshot 
> 
> previously there is a check for hypervisor type using the virtual machine 
> profile where null is being passes. 
> Changed the check by getting the hypervisor type from the disk profile. 
> 
> 
> This addresses bug CLOUDSTACK-1830.
> 
> 
> Diffs
> -
> 
>   
> engine/storage/src/org/apache/cloudstack/storage/allocator/ZoneWideStoragePoolAllocator.java
>  c45f8a8 
> 
> Diff: https://reviews.apache.org/r/10239/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request: CLOUDSTACK-1830: ZWPS: NPE while create volume from snapshot

[ASF Subversion and Git Services]

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


Commit 6110e00c549630e8b08fc6ca4818a60ef6a0c919 in branch refs/heads/master 
from Edison Su 
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6110e00 ]

CLOUDSTACK-1830: ZWPS: NPE while create volume from snapshot


- ASF Subversion and Git Services


On April 2, 2013, 1:53 p.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10239/
> ---
> 
> (Updated April 2, 2013, 1:53 p.m.)
> 
> 
> Review request for cloudstack and Abhinandan Prateek.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-1830:  ZWPS: NPE while create volume from snapshot 
> 
> previously there is a check for hypervisor type using the virtual machine 
> profile where null is being passes. 
> Changed the check by getting the hypervisor type from the disk profile. 
> 
> 
> This addresses bug CLOUDSTACK-1830.
> 
> 
> Diffs
> -
> 
>   
> engine/storage/src/org/apache/cloudstack/storage/allocator/ZoneWideStoragePoolAllocator.java
>  c45f8a8 
> 
> Diff: https://reviews.apache.org/r/10239/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

RE: Notification Center: Should I be concerned?

[Pranav Saxena]

One way is to delete them from the db itself if you aren't interested in what's 
being showcased on the UI . Other way is to tweak the UI code to not to display 
these alerts if they don't happen to bother you at all :) .  There's no direct 
way on the UI to clear them off though as of now .

Regards,
Pranav

From: Maurice Lawler [mailto:maurice.law...@me.com]
Sent: Tuesday, April 02, 2013 10:35 PM
To: us...@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Notification Center: Should I be concerned?

[cid:image001.png@01CE2FF5.DC6DCF00]

When logging into CS UI, I keep seeing notifications; for one, my 
primary/secondary are both online. There are not any issues at hand that I can 
see. However, is there a way to clear the alerts; instead of causing me to be 
concerned when they are false positives?

- Maurice

Re: [VMWARE]Any way to allow concurrent operations?

[Kelven Yang]

We don't use queue facility/concurrency management within CloudStack
extensively for now, the orchestration flow (i.e., putting storage into
maintenance process) should launch concurrent tasks and manage it properly
to achieve maximum of concurrency without breaking integrity of the
operation. 

We do need to add more convenient facilities at framework level to enable
these apparently needed features in various individual orchestration
flows. Currently we write most of orchestration flows in a sequential
execution manner.

Kelven

On 4/2/13 8:12 AM, "Marcus Sorensen"  wrote:

>Edison was saying something about executeInSequence, causing the serial
>operations, and how it was a compatibility thing. He said he removed it
>once as a test and it seemed to work for concurrent operations on KVM, but
>I don't know much about it. Just thought it was worth mentioning.
>
>
>On Tue, Apr 2, 2013 at 9:06 AM, Chip Childers
>wrote:
>
>> On Tue, Apr 02, 2013 at 02:56:24PM +, Musayev, Ilya wrote:
>> > Long story short - due to the fact, we do things serially, any mass
>> operation will be queued, and may take very long time to complete.
>> >
>> > We need to improve this area, as its going to be one of the major
>> complaints in the near future for corporate users that run vmware.
>>
>> Sounds like something that we should create as an "Improvement" ticket.
>>

RE: Notification Center: Should I be concerned?

[Oliver Leach]

There was obviously an event of some sort that triggered the alert which is why 
you see these alerts. If you are sure they are old you can remove them in the 
database - there is a cloud.alerts table that holds this information in the 
database - also there is a cloud.event table that holds other information you 
see in the dashboard. You can clear it if you are sure they are no longer 
needed. I would like to see recent events and alerts removed say after 2 weeks, 
or a clear recent events/alerts threshold setting in Cloudstack which clears 
these up. Not sure that exists just yet. A routine in mysql could help here 
which could archive these alerts if something doesn't exist in Cloudstack but 
that would have to be something you implement and maintain.

Oliver Leach
Platform Architect
InstaCompute


From: Maurice Lawler [mailto:maurice.law...@me.com]
Sent: Tuesday, April 02, 2013 6:05 PM
To: us...@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Notification Center: Should I be concerned?

[cid:image002.png@01CE2FCD.753100F0]

When logging into CS UI, I keep seeing notifications; for one, my 
primary/secondary are both online. There are not any issues at hand that I can 
see. However, is there a way to clear the alerts; instead of causing me to be 
concerned when they are false positives?

- Maurice

Re: CLOUDSTACK-1839: Upgrade 4.0 -> 4.1 - Upgraded DB has lot more keys and indexes for many tables compare to the fresh installed 4.1 DB.

[Chip Childers]

On Tue, Apr 02, 2013 at 10:07:54AM -0700, Alex Huang wrote:
> I'll take it over.

Many thanks Alex!

> 
> --Alex
> 
> > -Original Message-
> > From: Chip Childers [mailto:chip.child...@sungard.com]
> > Sent: Tuesday, April 2, 2013 8:03 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: CLOUDSTACK-1839: Upgrade 4.0 -> 4.1 - Upgraded DB has lot
> > more keys and indexes for many tables compare to the fresh installed 4.1 DB.
> > 
> > On Tue, Apr 02, 2013 at 03:16:13PM +0530, Rohit Yadav wrote:
> > > Replied on the ticket, pl. reassign for now so as to meet our release
> > > schedule.
> > 
> > Thanks!
> > 
> > OK folks - I need someone to volunteer for this bug.  It's DB upgrade 
> > related,
> > so experience working with that part of the code would be good.
> > 
> > Anyone?
> > 
> > >
> > > On Tue, Apr 2, 2013 at 12:52 AM, Chip Childers
> > wrote:
> > >
> > > > Rohit,
> > > >
> > > > I know you are quasi-offline right now, but do you think you'd be
> > > > able to take a look at CLOUDSTACK-1839 for me in the next day or so?
> > > >
> > > > If not, just say so and we'll try to find someone else to review /
> > > > fix it.
> > > >
> > > > Thanks!
> > > >
> > > > -chip
> > > >
> 

RE: [ACS41] Final push to an RC?

[Sailaja Mada]

Hi,

Jira ticket is updated with the details.

Yes i can connect DB manually .

root@ub12sailaja:~# mysql -u cloud -ppassword 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 759
Server version: 5.5.29-0ubuntu0.12.04.2 (Ubuntu)

Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. 
Other names may be trademarks of their respective owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

Thanks,
Sailaja.M

-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com] 
Sent: Tuesday, April 02, 2013 8:23 PM
To: dev@cloudstack.apache.org
Cc: Edison Su; bhais...@apache.org; Abhinandan Prateek; shadow...@gmail.com
Subject: Re: [ACS41] Final push to an RC?

On Tue, Apr 02, 2013 at 05:57:07AM +, Sailaja Mada wrote:
> Hi,
> 
> I have one more issue with upgrade parh from 4.0 to 4.1 [Ubuntu]:
> 
> CLOUDSTACK-1877
> 
> Thanks,
> Sailaja.M

I asked a follow up question in the bug.

RE: CLOUDSTACK-1839: Upgrade 4.0 -> 4.1 - Upgraded DB has lot more keys and indexes for many tables compare to the fresh installed 4.1 DB.

[Alex Huang]

I'll take it over.

--Alex

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Tuesday, April 2, 2013 8:03 AM
> To: dev@cloudstack.apache.org
> Subject: Re: CLOUDSTACK-1839: Upgrade 4.0 -> 4.1 - Upgraded DB has lot
> more keys and indexes for many tables compare to the fresh installed 4.1 DB.
> 
> On Tue, Apr 02, 2013 at 03:16:13PM +0530, Rohit Yadav wrote:
> > Replied on the ticket, pl. reassign for now so as to meet our release
> > schedule.
> 
> Thanks!
> 
> OK folks - I need someone to volunteer for this bug.  It's DB upgrade related,
> so experience working with that part of the code would be good.
> 
> Anyone?
> 
> >
> > On Tue, Apr 2, 2013 at 12:52 AM, Chip Childers
> wrote:
> >
> > > Rohit,
> > >
> > > I know you are quasi-offline right now, but do you think you'd be
> > > able to take a look at CLOUDSTACK-1839 for me in the next day or so?
> > >
> > > If not, just say so and we'll try to find someone else to review /
> > > fix it.
> > >
> > > Thanks!
> > >
> > > -chip
> > >

Re: Master broken

[Alena Prokharchyk]

The test itself is written by me. It doesn't touch the DB - I mock
"persist" method of the corresponding Dao. The test was added about 2
weeks ago to master branch, and it was running fine the last time I've
checked - last Friday.

As Pranav stated, the test got broken with commit
5782abf8f80fce929e3d6e20068bc165f2360426, and related to UserContext
initializing.

-Alena. 

On 4/2/13 1:32 AM, "Pranav Saxena"  wrote:

>Yeah I saw that . Thanks Hugo . I hope master is stable now though I
>haven't got a change to build it again.
>
>Regards,
>Pranav
>
>-Original Message-
>From: Hugo Trippaers [mailto:htrippa...@schubergphilis.com]
>Sent: Tuesday, April 02, 2013 1:37 PM
>To: dev@cloudstack.apache.org; cloudstack-...@incubator.apache.org
>Subject: RE: Master broken
>
>Thanks Pranav,
>
>I couldn't find an easy way to fix the test so I indeed disabled it. See
>commit df6b97c194caa8b34fa14bf5164eb2fe1f26b2b1.
>
>Raised a ticket for Kelven (CLOUDSTACK-1884) to have a look at it.
>
>Cheers,
>
>Hugo
>
>> -Original Message-
>> From: Pranav Saxena [mailto:pranav.sax...@citrix.com]
>> Sent: dinsdag 2 april 2013 10:04
>> To: dev@cloudstack.apache.org; cloudstack-...@incubator.apache.org
>> Subject: RE: Master broken
>> 
>> This commit deals with the tests for create network offering - Commit:
>> 5782abf8f80fce929e3d6e20068bc165f2360426 and I am presuming because of
>> this only the test is failing.
>> 
>> You might need to revert the commit if required.
>> 
>> Thanks,
>> Pranav
>> 
>> -Original Message-
>> From: Hugo Trippaers [mailto:htrippa...@schubergphilis.com]
>> Sent: Tuesday, April 02, 2013 12:32 PM
>> To: cloudstack-...@incubator.apache.org
>> Subject: Master broken
>> 
>> Heya all,
>> 
>> Master branch appears to be broken. Is anybody working on this?
>> 
>> The failed tests are:
>> >>> 
>> >>>org.apache.cloudstack.networkoffering.CreateNetworkOfferingTest.cre
>> ateSharedNtwkOffWithNoVlan
>> >>> 
>> >>>org.apache.cloudstack.networkoffering.CreateNetworkOfferingTest.cre
>> ateSharedNtwkOffWithoutSpecifyIpRanges
>> >>> 
>> >>>org.apache.cloudstack.networkoffering.CreateNetworkOfferingTest.cre
>> ateIsolatedNtwkOffWithSpecifyIpRangesAndSourceNat
>> >>> 
>> >>>org.apache.cloudstack.networkoffering.CreateNetworkOfferingTest.cre
>> ateSharedNtwkOffWithVlan
>> >>> 
>> >>>org.apache.cloudstack.networkoffering.CreateNetworkOfferingTest.cre
>> ateSharedNtwkOffWithSpecifyIpRanges
>> >>> 
>> >>>org.apache.cloudstack.networkoffering.CreateNetworkOfferingTest.cre
>> ateIsolatedNtwkOffWithNoVlan
>> >>> 
>> >>>org.apache.cloudstack.networkoffering.CreateNetworkOfferingTest.cre
>> ateIsolatedNtwkOffWithVlan
>> >>> 
>> >>>org.apache.cloudstack.networkoffering.CreateNetworkOfferingTest.cre
>> ateIsolatedNtwkOffWithSpecifyIpRangesAndNoSourceNat
>> 
>> 
>> It appears to have something to do with the CreateNetworkOfferingTest
>> trying to use the database (which is never there during test runs)
>> 
>> I'm looking at it, but if somebody else is doing that as well we might
>> pool resources.
>> 
>> Cheers,
>> 
>> Hugo
>
>

Re: [REMINDER] IRC Meeting tomorrow + moderator needed

[Joe Brockmeier]

On Tue, Apr 2, 2013, at 11:07 AM, Noah Slater wrote:
> Can we have the meeting in the Bat-cave as well? :P

That's really up to Adam West... 

Best,

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

Re: [REMINDER] IRC Meeting tomorrow + moderator needed

[Chip Childers]

On Tue, Apr 02, 2013 at 11:05:50AM -0500, Joe Brockmeier wrote:
> Hey all,
> 
> IRC meeting tomorrow, same Bat-time, same Bat-channel.
> (#cloudstack-meeting on Freenode, 17:00 UTC).
> 
> That's 1 p.m. Eastern, 10 a.m. Pacific, and 6 p.m. in London.
> 
> Also - I have a meeting that may carry over into the IRC meeting, so I'd
> like to ask if we can get someone else to moderate the meeting tomorrow,
> as I may be unable to do so. 

I'll moderate.  Thanks for the heads up Joe!

Re: [REMINDER] IRC Meeting tomorrow + moderator needed

[Noah Slater]

Can we have the meeting in the Bat-cave as well? :P


On 2 April 2013 17:05, Joe Brockmeier  wrote:

> Hey all,
>
> IRC meeting tomorrow, same Bat-time, same Bat-channel.
> (#cloudstack-meeting on Freenode, 17:00 UTC).
>
> That's 1 p.m. Eastern, 10 a.m. Pacific, and 6 p.m. in London.
>
> Also - I have a meeting that may carry over into the IRC meeting, so I'd
> like to ask if we can get someone else to moderate the meeting tomorrow,
> as I may be unable to do so.
>
> Best,
>
> jzb
> --
> Joe Brockmeier
> j...@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
>



-- 
NS

Re: [ACS41] Final push to an RC?

[Wido den Hollander]

On 04/01/2013 11:14 PM, Joe Brockmeier wrote:

On Mon, Apr 1, 2013, at 03:08 PM, Chip Childers wrote:

* Joe - Release Notes
I think that the upgrade portion of the docs probably needs to be
updated to reflect Wido's notes on the wiki for how to perform the
upgrade process itself.  Do you have this one under control, or do you
want help?  I'd love to have the upgrade instructions in the release
itself (and will probably hold off on an RC until we have them).


Yep, I saw Wido's emails on that and have everything in front of me to
update the release notes. I've already pushed some minor updates to the
release notes and will get them finished shortly.



Great! I still need to verify some stuff, but I have some talks coming 
up this week, like a Webinar about CloudStack and Ceph so I have to pay 
some attention to that as well.


Packages still need some work I think, mainly the management server, the 
agent package seeems pretty done.


Wido


Any finally...  does anyone else have any outstanding work / items /
bugs that you believe need to be addressed before we start the voting
process for 4.1.0's first RC?


Are we going directly to a vote or are we going to have an RC for
comments and *then* a vote?

Best,

jzb

[REMINDER] IRC Meeting tomorrow + moderator needed

[Joe Brockmeier]

Hey all,

IRC meeting tomorrow, same Bat-time, same Bat-channel.
(#cloudstack-meeting on Freenode, 17:00 UTC).

That's 1 p.m. Eastern, 10 a.m. Pacific, and 6 p.m. in London.

Also - I have a meeting that may carry over into the IRC meeting, so I'd
like to ask if we can get someone else to moderate the meeting tomorrow,
as I may be unable to do so. 

Best,

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

Re: [VMWARE]Any way to allow concurrent operations?

[Marcus Sorensen]

Edison was saying something about executeInSequence, causing the serial
operations, and how it was a compatibility thing. He said he removed it
once as a test and it seemed to work for concurrent operations on KVM, but
I don't know much about it. Just thought it was worth mentioning.


On Tue, Apr 2, 2013 at 9:06 AM, Chip Childers wrote:

> On Tue, Apr 02, 2013 at 02:56:24PM +, Musayev, Ilya wrote:
> > Long story short - due to the fact, we do things serially, any mass
> operation will be queued, and may take very long time to complete.
> >
> > We need to improve this area, as its going to be one of the major
> complaints in the near future for corporate users that run vmware.
>
> Sounds like something that we should create as an "Improvement" ticket.
>

Re: [VMWARE]Any way to allow concurrent operations?

[Chip Childers]

On Tue, Apr 02, 2013 at 02:56:24PM +, Musayev, Ilya wrote:
> Long story short - due to the fact, we do things serially, any mass operation 
> will be queued, and may take very long time to complete.
> 
> We need to improve this area, as its going to be one of the major complaints 
> in the near future for corporate users that run vmware.

Sounds like something that we should create as an "Improvement" ticket.

Re: CLOUDSTACK-1839: Upgrade 4.0 -> 4.1 - Upgraded DB has lot more keys and indexes for many tables compare to the fresh installed 4.1 DB.

[Chip Childers]

On Tue, Apr 02, 2013 at 03:16:13PM +0530, Rohit Yadav wrote:
> Replied on the ticket, pl. reassign for now so as to meet our release
> schedule.

Thanks!

OK folks - I need someone to volunteer for this bug.  It's DB upgrade
related, so experience working with that part of the code would be good.

Anyone?

> 
> On Tue, Apr 2, 2013 at 12:52 AM, Chip Childers 
> wrote:
> 
> > Rohit,
> >
> > I know you are quasi-offline right now, but do you think you'd be able
> > to take a look at CLOUDSTACK-1839 for me in the next day or so?
> >
> > If not, just say so and we'll try to find someone else to review / fix
> > it.
> >
> > Thanks!
> >
> > -chip
> >

RE: [VMWARE]Any way to allow concurrent operations?

[Musayev, Ilya]

Long story short - due to the fact, we do things serially, any mass operation 
will be queued, and may take very long time to complete.

We need to improve this area, as its going to be one of the major complaints in 
the near future for corporate users that run vmware.

-Original Message-
From: Musayev, Ilya [mailto:imusa...@webmd.net] 
Sent: Tuesday, April 02, 2013 10:50 AM
To: dev@cloudstack.apache.org
Subject: RE: [VMWARE]Any way to allow concurrent operations?

Hi Chip,

Thanks for the feedback,

I'm well aware of that. But here is some food for thought.

I was running everything of NFS backend, primary and secondary stores.  As I 
was running out of disk space I decided to decommissioned my primary NFS store 
and use VMFS instead.

Here is a kicker, I've only had about 10 - 15 VMS in this env - very much lean 
with nothing but operating systems. This is POC, production will have several 
100s.

My attempt to place NFS store in maintenance mode and bring up these VMs on 
VMFS - is still in progress. Its been over 10 hours. Mostly due to the fact 
that it runs 1 operation at a time.

Here is another scenario to try - more realistic, on the hypervisor that has 
many VMs, preferably 30 or more, place it into maintenance mode. This operation 
will take at least an hour or two depending on your setup - again due to the 
fact that we are running it in serial.

Even if we can bump up the number of threads to 2, this will greatly increase 
productivity. 

Regards
ilya

-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com] 
Sent: Tuesday, April 02, 2013 10:30 AM
To: dev@cloudstack.apache.org
Subject: Re: [VMWARE]Any way to allow concurrent operations?

On Tue, Apr 02, 2013 at 01:35:13AM +, Musayev, Ilya wrote:
> If I need to do a mass operation on my vmware cluster, all jobs will be 
> schedule and executed one at a time.
> 
> If you need to do a mass migration from one storage to another, this may take 
> enormous amount of time. vSphere allows at least 4 concurrent operations and 
> others are scheduled until the queue frees up.
> 
> Is there any possible method of allowing concurrent operations and not 
> waiting for job X to complete before another one executes?
> 
> Thanks
> ilya

AFAIK, CloudStack takes the approach of acting as the throttling mechanism 
itself for VMware interactions.  You're right that vSphere is able to handle 
some number of concurrent operations (depending on the operation, the target 
host and / or datastore, and the version of vSphere), and that it does queue up 
tasks in Virtual Center.  I can offer a warning though, that we should probably 
be careful about trying to make any change to the way CloudStack does this.  
Virtual Center will actually time-out tasks that may not ever have a chance to 
run if they are pending for too long.  This may confuse CloudStack's logic in 
that scenario.

Re: [ACS41] Final push to an RC?

[Chip Childers]

On Tue, Apr 02, 2013 at 05:57:07AM +, Sailaja Mada wrote:
> Hi,
> 
> I have one more issue with upgrade parh from 4.0 to 4.1 [Ubuntu]:
> 
> CLOUDSTACK-1877
> 
> Thanks,
> Sailaja.M

I asked a follow up question in the bug.

RE: [VMWARE]Any way to allow concurrent operations?

[Musayev, Ilya]

Hi Chip,

Thanks for the feedback,

I'm well aware of that. But here is some food for thought.

I was running everything of NFS backend, primary and secondary stores.  As I 
was running out of disk space I decided to decommissioned my primary NFS store 
and use VMFS instead.

Here is a kicker, I've only had about 10 - 15 VMS in this env - very much lean 
with nothing but operating systems. This is POC, production will have several 
100s.

My attempt to place NFS store in maintenance mode and bring up these VMs on 
VMFS - is still in progress. Its been over 10 hours. Mostly due to the fact 
that it runs 1 operation at a time.

Here is another scenario to try - more realistic, on the hypervisor that has 
many VMs, preferably 30 or more, place it into maintenance mode. This operation 
will take at least an hour or two depending on your setup - again due to the 
fact that we are running it in serial.

Even if we can bump up the number of threads to 2, this will greatly increase 
productivity. 

Regards
ilya

-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com] 
Sent: Tuesday, April 02, 2013 10:30 AM
To: dev@cloudstack.apache.org
Subject: Re: [VMWARE]Any way to allow concurrent operations?

On Tue, Apr 02, 2013 at 01:35:13AM +, Musayev, Ilya wrote:
> If I need to do a mass operation on my vmware cluster, all jobs will be 
> schedule and executed one at a time.
> 
> If you need to do a mass migration from one storage to another, this may take 
> enormous amount of time. vSphere allows at least 4 concurrent operations and 
> others are scheduled until the queue frees up.
> 
> Is there any possible method of allowing concurrent operations and not 
> waiting for job X to complete before another one executes?
> 
> Thanks
> ilya

AFAIK, CloudStack takes the approach of acting as the throttling mechanism 
itself for VMware interactions.  You're right that vSphere is able to handle 
some number of concurrent operations (depending on the operation, the target 
host and / or datastore, and the version of vSphere), and that it does queue up 
tasks in Virtual Center.  I can offer a warning though, that we should probably 
be careful about trying to make any change to the way CloudStack does this.  
Virtual Center will actually time-out tasks that may not ever have a chance to 
run if they are pending for too long.  This may confuse CloudStack's logic in 
that scenario.

Re: [DISCUSS] Palo Alto Integration

[Will Stevens]

Thank you for clarifying this.  This was my assumption after spending a
bunch of time stepping through the code.

Will


On Tue, Apr 2, 2013 at 2:42 AM, Murali Reddy wrote:

> The 'Network' has a life cycle associated with it. Network goes from
> 'allocated' state (after the design phase) to 'implemented' (after
> implement phase). Unless a network is implemented it is not ready for use
> in 'isolated network' case. Only after network is implemented, it gets full
> identity. Can you please deploy a Vm into the network and confirm you see
> that non-overlapping CIDR's is allocated? 10.1.1.0/24 you see is the
> default CIDR network gets after design phase which will be replaced once
> network is implemented.
>
> From: Will Stevens mailto:wstev...@cloudops.com>>
> Reply-To: "dev@cloudstack.apache.org" <
> dev@cloudstack.apache.org>
> Date: Tuesday, 2 April 2013 12:33 AM
> To: "dev@cloudstack.apache.org" <
> dev@cloudstack.apache.org>
> Subject: Re: [DISCUSS] Palo Alto Integration
>
> So I have been stepping through the code and I can confirm that the
> 'design' method of ExternalGuestNetworkGuru is being hit, but it doesn't do
> anything, so it passes off work of creating the network to the 'design'
> method of GuestNetworkGuru which assigns 10.1.1.0/24
> to the network every time I create a network.
>
> Something I am finding strange is that 'config.getId()' gives -1, so the
> new network that is being created while in the 'design' method of
> ExternalGuestNetworkGuru does not hit the only logic in the function:
>
> NetworkVO config = (NetworkVO) super.design(offering, plan, userSpecified,
> owner);
> if (config == null) {
> return null;
> } else if
> (_networkModel.networkIsConfiguredForExternalNetworking(plan.getDataCenterId(),
> config.getId())) {
> /* In order to revert userSpecified network setup */
> config.setState(State.Allocated);
> }
>
> So the config.setState(State.Allocated) is not getting hit.
>
> There does seem to be some logic for updating the cidr in the 'implement'
> function of ExternalGuestNetworkGuru, but that is not run until a VM is
> added to the network (from what I understand), so that is a bit strange to
> me.
>
> Are the non-overlapping cidrs implemented only when a VM is added to the
> network and the same placeholder cidr is used until then?
>
> Thanks,
>
> Will
>
>
> On Mon, Apr 1, 2013 at 11:22 AM, Will Stevens  > wrote:
> Thank you for all your help Murali...
>
> So my Provider has been setup with isExternal = true this whole time.
> public static final Provider PaloAlto = new Provider("PaloAlto", true);
>
> If I run a debugger and then create a guest network, I see it enter the
> 'design' function of the ExternalGuestNetworkGuru, but it does not do
> anything in there because the config is not null, but the config.getId() =
> -1, so it just returns the config (Network object) and doesn't really do
> anything.
>
> Apparently the 'implement' method doesn't get called until a VM is
> attempted to be launched on the network.
>
> I must be missing something because, every Isolated guest network I create
> on my provider is defaulting to the cidr of 10.1.1.0/24.
>  Even if I have multiple Isolated networks associated with the same
> account, they all by default have that cidr.
>
> If the default behaviour of the ExternalGuestNetworkGuru is to create
> non-overlapping guest cidrs, why does it always default to the 10.1.1.0/24
>  cidr when I create a new network?  I can not specify
> a gateway or netmask because it is an external network (as you can see from
> the included screenshot).
> [Inline image 1]
>
> What am I missing here?  Why am I unable to create non-overlapping cidrs
> with the ExternalGuestNetworkGuru?
>
> Thanks,
>
> Will
>
>
> On Fri, Mar 29, 2013 at 1:23 AM, Murali Reddy  > wrote:
> On 28/03/13 10:59 PM, "Will Stevens"  wstev...@cloudops.com>> wrote:
>
> >I am trying to implement the non-overlapping cidrs right now and I have
> >some questions.  Does the ExternalGuestNetworkGuru create networks with
> >non-overlapping cidrs by default?  Or do I need to override it's 'design'
> >and 'implement' methods to implement non overlapping cidrs?
>
> Will, yes, it does by default. You can just use
> 'ExternalGuestNetworkGuru'. Just so that you know, there is check
> 'networkIsConfiguredForExternalNetworking' in ExternalGuestNetworkGuru.
> Which basically checks if provider is configured as service provider using
> external physical appliances. So when you declare provider, mark
> 'isExternal' as true in the provider constructor.
>
> >
> >If I have to write my own methods, I think I understand how to
> >override ExternalGuestNetworkGuru and then get it to run by adding it to
> >the components.xml (or nonoss-comp

Re: cloudmonkey printing enhancements proposal

[Chip Childers]

On Mon, Apr 01, 2013 at 10:21:34PM -0500, Justin Grudzien wrote:
> I created CLOUDSTACK-1875 for the JSON enhancements. I am going to begin
> filling out the ticket with the work that I have done and I will submit the
> first patch as soon as I figure out the rest of the non-comitter steps. I
> should be able to make my first patch submission attempt tomorrow. Thanks
> for all the help so far.
> 
> Justin

Great!

I just gave you permissions to work on tickets, and assigned that one
over to you.

Re: [VMWARE]Any way to allow concurrent operations?

[Chip Childers]

On Tue, Apr 02, 2013 at 01:35:13AM +, Musayev, Ilya wrote:
> If I need to do a mass operation on my vmware cluster, all jobs will be 
> schedule and executed one at a time.
> 
> If you need to do a mass migration from one storage to another, this may take 
> enormous amount of time. vSphere allows at least 4 concurrent operations and 
> others are scheduled until the queue frees up.
> 
> Is there any possible method of allowing concurrent operations and not 
> waiting for job X to complete before another one executes?
> 
> Thanks
> ilya

AFAIK, CloudStack takes the approach of acting as the throttling
mechanism itself for VMware interactions.  You're right that vSphere is
able to handle some number of concurrent operations (depending on the
operation, the target host and / or datastore, and the version of
vSphere), and that it does queue up tasks in Virtual Center.  I can
offer a warning though, that we should probably be careful about trying
to make any change to the way CloudStack does this.  Virtual Center will
actually time-out tasks that may not ever have a chance to run if they
are pending for too long.  This may confuse CloudStack's logic in that
scenario.

Re: [MERGE] bvt branch to master

[Prasanna Santhanam]

On Thu, Mar 28, 2013 at 07:36:58PM +0530, Prasanna Santhanam wrote:
> I'd like to merge the bvt branch into master. The proposal [1] was to
> stabilize master by allowing devs to quickly setup CloudStack using
> simulated hypervisors and run some basic tests against it.
> 
> The bvt branch integrates the testing of cloudstack using marvin and
> the simulator hypervisor. Alternately you may use devcloud as well
> with the appropriate maven profiles enabled. One can try the
> integrated tests today as described in [2]
> 
> While this is not to be touted as the magic pill for master stability
> I think it is a good first step towards bringing together tests as
> part of the build system. I've tested the steps on Linux and OSX.
> 
> [1] http://s.apache.org/5Lc
> [2] https://cwiki.apache.org/confluence/x/PgvMAQ
> 
> Thanks,

This branch is now merged to master. All commits were rebased
logically and grouped before push. 

b798c451141c32d46322aae83063eeaa9634b337 maven+marvin+simulator: Changes to the 
lifecycle steps
82fd9382b7497f1ee753e1298a9db1aed325fbc6 marvin+sync: apidiscovery sync and 
regenerate for marvin
5d67c98e5b7b763fde5ea87850e9cd7bafd2a4e1 marvin+apidiscovery: Extend API 
discovery plugin
9c755e11e5067bfbc14581a3a3fac9b5b7fd21a1 marvin-nose: include the plugin as 
part of marvin install
2e2046fe389b79b2b105ef40b792263cee831929 marvin changes to do an 
pre-integration and integration test

Thanks,

-- 
Prasanna.,

Re: Review Request: Change StatsCollector to be of a normal CloudStack manager component to ensure proper initialization order

[Chip Childers]

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

Ship it!


Applied to 4.1:

commit 195a4ee5260a65b9de264dc0477c8da7aafd66a1
Author: Kelven Yang 
Date:   Mon Apr 1 18:25:06 2013 -0700

CLOUDSTACK-1865: Change StatsCollector to be a manager so that it can 
initialize itself at proper run level

- Chip Childers


On April 2, 2013, 1:30 a.m., Kelven Yang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10232/
> ---
> 
> (Updated April 2, 2013, 1:30 a.m.)
> 
> 
> Review request for cloudstack and Chip Childers.
> 
> 
> Description
> ---
> 
> Change StatsCollector to be of a normal CloudStack manager component to 
> ensure proper initialization order
> 
> 
> This addresses bug CLOUDSTACK-1865.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/server/StatsCollector.java 4ae4999 
> 
> Diff: https://reviews.apache.org/r/10232/diff/
> 
> 
> Testing
> ---
> 
> Manual test to check its initialization order
> 
> 
> Thanks,
> 
> Kelven Yang
> 
>

Re: Call for 4.2 and 4.1.1 Release Managers!

[Chip Childers]

On Mon, Apr 01, 2013 at 03:47:39PM -0700, Animesh Chaturvedi wrote:
> [Animesh>] Chip my offer is still on. Like Ilya I also have some ambiguity or 
> unknowns on release management, I am thinking of putting together a wiki page 
> on release management tasks and responsibilities, and we can collaborate on 
> refining it. By the way I feel given that CloudStack is a big project there 
> can be more than one person help coordinate release activities. 
>

Great!

And yes, we've all been working together to herd each other for 4.1.  So
Animesh, if you want to take point (but not be solo) for 4.2, the first
step would be to create the release schedule and tracking page in the
wiki (and propose the schedule on the list).

-chip

Review Request: CLOUDSTACK-1830: ZWPS: NPE while create volume from snapshot

[Harikrishna Patnala]

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

Review request for cloudstack and Abhinandan Prateek.


Description
---

CLOUDSTACK-1830:  ZWPS: NPE while create volume from snapshot 

previously there is a check for hypervisor type using the virtual machine 
profile where null is being passes. 
Changed the check by getting the hypervisor type from the disk profile. 


This addresses bug CLOUDSTACK-1830.


Diffs
-

  
engine/storage/src/org/apache/cloudstack/storage/allocator/ZoneWideStoragePoolAllocator.java
 c45f8a8 

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


Testing
---


Thanks,

Harikrishna Patnala

RE: Question pertaining to the Support of ACL deny rules

[Kishan Kavala]

Chiradeep,
 Thanks for reviewing the spec.  Please find my comments inline:

> -Original Message-
> From: Chiradeep Vittal
> Sent: Saturday, 30 March 2013 3:46 AM
> To: dev@cloudstack.apache.org; Chandan Purushothama
> Cc: Kishan Kavala
> Subject: Re: Question pertaining to the Support of ACL deny rules
> 
> I would think that an ACL container is associated with a VPC and not with
> multiple VPCs.
> You could create an ACL container that makes sense for VPC #1 but not for
> VPC #2. If you update the container for VPC #1 you might unwittingly make a
> dangerous change in VPC #2.
> 
[KK] Made changes to the spec to associate ACL container to VPC instead of 
multiple VPCs.  vpc_id will be required param while creating ACL container. 

> 
> Also, isn't the term redundant? (Access Control List Container). Should the
> original API be aliased to createNetworkAclItem or createNetworkAclEntry?
> 
> I'd like to suggest the following API name changes
> * updateNetworkACL -> updateNetworkACLItem
> 
> * removeNetworkACL -> deleteNetworkACLItem (not specified but
> mentioned)
> * replaceNetworkACLContainer -> replaceNetworkACLAssociation
> * createNetworkACL -> createNetworkACLItem
> * createNetworkACLContainer -> createNetworkACLList (yes redundant, but
> not introducing new terminology)
> 
[KK] Agreed that ACL container term is redundant. We should change the API 
names and use the names similar to EC2 API. Should we use Entry instead of Item 
(e.g. createNetworkACLEntry). To implement API alias, APICommand annotation 
needs to be changed to support multiple API names for the same Cmd object. 

> 
> Other comments
> * I don't see removeNetworkACL (deleteNetworkACLItem) being specified
[KK]  removeNetworkACL API already exists. API syntax also won't change. 
ACLItem will be removed from the container instead of removing from network. 
I'll mention this in the spec.

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

> * createNetworkAclItem - adding new mandatory parameters breaks the old
> API which cannot be done in 4.2 (needs 5.0)
[KK]  New parameters can be made optional. Action param will default to "allow" 
and number can be current max + 1 when not specified.

> * createNetworkAclList - needs VPC id
[KK]  Yes needs vpc_id, since it'll be associated with single VPC.

> * deleteNetworkAclList - does this delete all the ACL items contained? Can
> you delete the default one?
[KK] All the ACL items have to be removed before deleting ACL list.  We can add 
a 'force" flag to delete all the ACL items and the container together. Default 
ACL  list cannot be deleted. 

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

> * How do you list the ACLItems inside an ACLList? Can you filter? List only
> ingress?
[KK] Existing listNetworkACLs can be used. It supports list by id, network_id, 
traffic_type. List by ACLList can be added.

> * vpc_id should be required in all APIs?
[KK]Either vpc_id or acl_id will be required. ACLList is already associated 
with a VPC. 

> * call out the asynchronous APIs vs the synchronous APIs
[KK] I'll mention these in the spec

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

> * firewall_rules - should we create a new table instead? The upgrade can
> move the rules to the new table
[KK] we can create new table network_acl. Firewall_rules table is already 
overloaded.
> 
> 
> 
> On 3/28/13 3:49 AM, "Kishan Kavala"  wrote:
> 
> >Chandan,
> >  User can assign any number as rule priority. But the number has to be
> >unique within the container. Two ACLs in the same container cannot have
> >same priority number.
> >e.g.
> >ACL1 - number 10
> >ACL2 - number 40
> >ACL3 - number 30
> >
> >In the above example, ACL1 will have the highest priority followed by
> >ACL3 and ACL2.
> >
> >Priority number of the deleted rule can be re-used. Priority number can
> >be modified using updateNetworkACL API.
> >
> >Same NetworkACLContainer can be assigned to multiple tiers (belonging
> >to two different VPCs also) as long as they belong to same account.
> >
> >Regards,
> >Kishan
> >
> >
> >> -

Re: [ACS41] Final push to an RC?

[Chip Childers]

On Mon, Apr 01, 2013 at 04:14:47PM -0500, Joe Brockmeier wrote:
> On Mon, Apr 1, 2013, at 03:08 PM, Chip Childers wrote:
> > * Joe - Release Notes
> > I think that the upgrade portion of the docs probably needs to be
> > updated to reflect Wido's notes on the wiki for how to perform the
> > upgrade process itself.  Do you have this one under control, or do you
> > want help?  I'd love to have the upgrade instructions in the release
> > itself (and will probably hold off on an RC until we have them).
> 
> Yep, I saw Wido's emails on that and have everything in front of me to
> update the release notes. I've already pushed some minor updates to the
> release notes and will get them finished shortly. 
>  
> > Any finally...  does anyone else have any outstanding work / items /
> > bugs that you believe need to be addressed before we start the voting
> > process for 4.1.0's first RC?
> 
> Are we going directly to a vote or are we going to have an RC for
> comments and *then* a vote? 

Let's do a RC for comments.  Good idea.

Given that, I'll actually cut one with the current known issues
tomorrow.  That will give us an opportunity to confirm everything's good
to go, and to get the final fixes into the branch.

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

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 2, 2013, 1:24 p.m.)


Review request for cloudstack, Sateesh Chodapuneedi and Harikrishna Patnala.


Changes
---

According to the comment from Harikrishna Patnala, change throwing 
CloudRuntimeException to debugging.


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

Re: Review Request: CLOUDSTACK-301: Fix validation of VMware cluster associated with Nexus 1000v

[Sateesh Chodapuneedi]

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

Ship it!


- Sateesh Chodapuneedi


On March 20, 2013, 4:57 a.m., Sateesh Chodapuneedi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10038/
> ---
> 
> (Updated March 20, 2013, 4:57 a.m.)
> 
> 
> Review request for cloudstack, Murali Reddy and Kelven Yang.
> 
> 
> Description
> ---
> 
> Moved validateVSMCluster method from CiscoNexusVSMDeviceManagerImpl to 
> CiscoNexusVSMElement.
> 
> 
> This addresses bug CLOUDSTACK-301.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/VmwareServerDiscoverer.java
>  94ba97d 
>   
> plugins/hypervisors/vmware/src/com/cloud/network/CiscoNexusVSMDeviceManagerImpl.java
>  e17d99d 
>   
> plugins/hypervisors/vmware/src/com/cloud/network/element/CiscoNexusVSMElement.java
>  daf7dd6 
>   
> plugins/hypervisors/vmware/src/com/cloud/network/element/CiscoNexusVSMElementService.java
>  1cc9faf 
> 
> Diff: https://reviews.apache.org/r/10038/diff/
> 
> 
> Testing
> ---
> 
> Tested adding a VMware cluster associated with Nexus 1000v.
> Tested deleting the VMware cluster.
> 
> 
> Thanks,
> 
> Sateesh Chodapuneedi
> 
>

Re: Review Request: Cloudstack-701 Support for non contiguous vlan ranges.

[bharat kumar]

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

(Updated April 2, 2013, 12:11 p.m.)


Review request for cloudstack and Abhinandan Prateek.


Summary (updated)
-

Cloudstack-701 Support for non contiguous vlan ranges.


Description
---

Cloudstack-701: Support for non contiguous vlan ranges.


Diffs
-

  api/src/com/cloud/network/NetworkService.java ab6d7bf 
  api/src/com/cloud/network/PhysicalNetwork.java 343a2b1 
  api/src/org/apache/cloudstack/api/ApiConstants.java c518830 
  
api/src/org/apache/cloudstack/api/command/admin/network/UpdatePhysicalNetworkCmd.java
 06cf38d 
  server/src/com/cloud/api/ApiResponseHelper.java 64be7f8 
  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 8dbf081 
  server/src/com/cloud/dc/dao/DataCenterVnetDao.java 79e91c4 
  server/src/com/cloud/dc/dao/DataCenterVnetDaoImpl.java 5ded0f4 
  server/src/com/cloud/network/ExternalFirewallDeviceManagerImpl.java ae00bf2 
  server/src/com/cloud/network/NetworkServiceImpl.java 4eb620c 
  server/src/com/cloud/network/dao/PhysicalNetworkVO.java e5ffcfb 
  server/src/com/cloud/network/guru/GuestNetworkGuru.java 9c0205a 
  server/src/com/cloud/resource/ResourceManagerImpl.java 82bca51 
  server/test/com/cloud/network/MockNetworkManagerImpl.java 6da48ec 
  server/test/com/cloud/network/UpdatePhysicalNetworkTest.java PRE-CREATION 
  server/test/com/cloud/vpc/MockNetworkManagerImpl.java ead0051 
  test/integration/smoke/test_non_contigiousvlan.py PRE-CREATION 

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


Testing
---

Need to test this on latest master.


Thanks,

bharat kumar

Re: Review Request: CLOUDSTACK-301: Fix validation of VMware cluster associated with Nexus 1000v

[ASF Subversion and Git Services]

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


Commit 009749fb796bc935f610921f1bdc71e8d993198d in branch refs/heads/master 
from Sateesh Chodapuneedi 
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=009749f ]

CLOUDSTACK-301 Nexus 1000v DVS integration is not functional

Moved validateVSMCluster method from CiscoNexusVSMDeviceManagerImpl to 
CiscoNexusVSMElement.

Signed-off-by: Sateesh Chodapuneedi 


- ASF Subversion and Git Services


On March 20, 2013, 4:57 a.m., Sateesh Chodapuneedi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10038/
> ---
> 
> (Updated March 20, 2013, 4:57 a.m.)
> 
> 
> Review request for cloudstack, Murali Reddy and Kelven Yang.
> 
> 
> Description
> ---
> 
> Moved validateVSMCluster method from CiscoNexusVSMDeviceManagerImpl to 
> CiscoNexusVSMElement.
> 
> 
> This addresses bug CLOUDSTACK-301.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/VmwareServerDiscoverer.java
>  94ba97d 
>   
> plugins/hypervisors/vmware/src/com/cloud/network/CiscoNexusVSMDeviceManagerImpl.java
>  e17d99d 
>   
> plugins/hypervisors/vmware/src/com/cloud/network/element/CiscoNexusVSMElement.java
>  daf7dd6 
>   
> plugins/hypervisors/vmware/src/com/cloud/network/element/CiscoNexusVSMElementService.java
>  1cc9faf 
> 
> Diff: https://reviews.apache.org/r/10038/diff/
> 
> 
> Testing
> ---
> 
> Tested adding a VMware cluster associated with Nexus 1000v.
> Tested deleting the VMware cluster.
> 
> 
> Thanks,
> 
> Sateesh Chodapuneedi
> 
>

Review Request: Cloudstack-701

[bharat kumar]

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

Review request for cloudstack and Abhinandan Prateek.


Description
---

Cloudstack-701: Support for non contiguous vlan ranges.


Diffs
-

  api/src/com/cloud/network/NetworkService.java ab6d7bf 
  api/src/com/cloud/network/PhysicalNetwork.java 343a2b1 
  api/src/org/apache/cloudstack/api/ApiConstants.java c518830 
  
api/src/org/apache/cloudstack/api/command/admin/network/UpdatePhysicalNetworkCmd.java
 06cf38d 
  server/src/com/cloud/api/ApiResponseHelper.java 64be7f8 
  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 8dbf081 
  server/src/com/cloud/dc/dao/DataCenterVnetDao.java 79e91c4 
  server/src/com/cloud/dc/dao/DataCenterVnetDaoImpl.java 5ded0f4 
  server/src/com/cloud/network/ExternalFirewallDeviceManagerImpl.java ae00bf2 
  server/src/com/cloud/network/NetworkServiceImpl.java 4eb620c 
  server/src/com/cloud/network/dao/PhysicalNetworkVO.java e5ffcfb 
  server/src/com/cloud/network/guru/GuestNetworkGuru.java 9c0205a 
  server/src/com/cloud/resource/ResourceManagerImpl.java 82bca51 
  server/test/com/cloud/network/MockNetworkManagerImpl.java 6da48ec 
  server/test/com/cloud/network/UpdatePhysicalNetworkTest.java PRE-CREATION 
  server/test/com/cloud/vpc/MockNetworkManagerImpl.java ead0051 
  test/integration/smoke/test_non_contigiousvlan.py PRE-CREATION 

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


Testing
---

Need to test this on latest master.


Thanks,

bharat kumar

RE: [DISCUSS] Have jenkins.a.o notification mails on broken build sent to dev@cloudstack.apache.org

[Hugo Trippaers]

The cloudstack builds on build.a.o do not yet email to the dev list.

Cheers,

Hugo

> -Original Message-
> From: prasanna [mailto:srivatsav.prasa...@gmail.com] On Behalf Of
> Prasanna Santhanam
> Sent: dinsdag 2 april 2013 11:40
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Have jenkins.a.o notification mails on broken build
> sent to dev@cloudstack.apache.org
> 
> On Tue, Apr 02, 2013 at 07:06:01AM +, Hugo Trippaers wrote:
> > Heya,
> >
> > Currently broken builds only sent notifications to people with commits
> > when the build was broken. I would like to have those notifications on
> > dev@cloudstack.apache.org as well.
> >
> > Preferably with a random tag so I'm not tempted to build a filter for
> > it sooner or later ;-)
> >
> 
> We already have the emails sent out to dev@ but the random tagging would
> be a useful addition.
> 
> 
> --
> Prasanna.,