Re: [ASF4.2.1] Release Notes

[Sebastien Goasguen]

I might be behind on the discussions here, but I will veto an RC that does not 
have list of bugs fixed and proper upgrade path documented (minimum of a fix 
from 4.2.0 upgrade docs). Separate repo of the docs or not.

Right now I see that the bugs fix list points to a jira filter. This is not 
consistent with the way it was done in prior releases (explicit listing) and in 
4.2 (which pointed to the RN). We need consistency. What happens if someone 
changes this jira filter ?

I also would like to see the results of the test matrix for 4.2.1 running 
within jenkins.buildacloud.org.  This 
http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against master and has 
been failing for a while.

PS: I did test it and did the usual smoke test

so -1 (binding) at this time

-sebastien


On Nov 14, 2013, at 4:20 PM, Chip Childers  wrote:

> Except that the separation only helps if it allows RC testing + voting
> during doc finalization.  If we announce before docs, it hurts us.
> I'm against another announcement that goes out with the docs in poor
> shape.
> 
> On Thu, Nov 14, 2013 at 3:44 PM, Animesh Chaturvedi
>  wrote:
>> Unless there are objection to the RC, I would prefer to have it released and 
>> make the announcement sooner and showcase in collab conference. As Chip 
>> mentions docs were broken out separately anyway.
>> 
>> Animesh
>> 
>> 
>> On 14/11/13 8:12 pm, "Sebastien Goasguen"  wrote:
>> 
>>> Anyway we can wait next week to release.
>>> 
>>> quite a few of us will be together in Amsterdam, we can dedicate a
>>> hackathon session to 4.2.1 , make sure RN are good, upgrade path
>>> etcŠthen testŠ.
>>> 
>>> I'd recommend keeping the vote open until then.
>>> 
>>> -sebastien
>>> 
>>> 
>>> On Nov 14, 2013, at 5:57 AM, Radhika Puthiyetath
>>>  wrote:
>>> 
 Hi,
 
 The master has the most up-to-date RN for 4.2.1.
 
 From: Abhinandan Prateek
 Sent: Thursday, November 14, 2013 2:22 PM
 To: CloudStack Dev
 Cc: Radhika Puthiyetath
 Subject: Re: [ASF4.2.1] Release Notes
 
 
 It seems the upgrade section of release notes will require a review,
 probably followed by a revamp (?).
 Can we have some volunteers who are familiar with various upgrade
 paths comment on it ?
 Me and Radhika will try to consolidate those comments, snippets and
 fix the RN for 4.2.1.
 
 -abhi
 
 RN for 4.2.1 =
 https://git-wip-us.apache.org/repos/asf?p=cloudstack-docs.git;a=tree;f
 =re
 lease-notes;h=8128d62c39236331492f3642914bf97b43ed2670;hb=refs/heads/4
 .2
 
>>> 
>> 

hackathons

[Daan Hoogland]

H all,

One last call fro all coming to CCC Europe: have a quick look at
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CCC+Europe and
see what you want to work on on Wednesday. If it is not there feel
free to submit more ideas.

regards,
Daan

Re: bf22f6dfe reverts commit 1762dbbb

[Koushik Das]

I have reverted the same in 4.3 as well

commit f84b729eb01ffc7cae1e210b58f80ff2033ad785
Author: Koushik Das 
Date:   Fri Nov 15 12:59:48 2013 +0530

Revert "CLOUDSTACK-5176:"

This reverts commit f29c7188ba03f1997238d50f8a11857e94fe4b55.

On 15-Nov-2013, at 10:35 AM, Prasanna Santhanam  wrote:

> I've reverted 1762dbbb as it seems to have introduced
> ConfigurationParameterScope which didn't exist causing builds to fail
> on master.
> 
> Thanks,
> -- 
> Prasanna.,
> 
> 
> Powered by BigRock.com
> 

Re: Review Request 15507: CLOUDSTACK-4835: Update global configuration test cases failed in master

[ASF Subversion and Git Services]

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


Commit 52de0dc2cae33831cebb23ed4bb81d8368ed33de in branch refs/heads/4.3 from 
Harikrishna Patnala
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=52de0dc ]

CLOUDSTACK-4835: Update global configuration test cases failed in master 
Changes made in update/list configuration API to use ConfigDepot

CLOUDSTACK-4169: Scoped configuraion parameters logic moved to ConfigDepot

CLOUDSTACK-5163: missing parameters in configuration table


- ASF Subversion and Git Services


On Nov. 14, 2013, 9:25 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15507/
> ---
> 
> (Updated Nov. 14, 2013, 9:25 a.m.)
> 
> 
> Review request for cloudstack and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-4169, CLOUDSTACK-4835 and CLOUDSTACK-5163
> https://issues.apache.org/jira/browse/CLOUDSTACK-4169
> https://issues.apache.org/jira/browse/CLOUDSTACK-4835
> https://issues.apache.org/jira/browse/CLOUDSTACK-5163
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-4835: Update global configuration test cases failed in master 
> Changes made in update/list configuration API to use ConfigDepot
> 
> CLOUDSTACK-4169: Scoped configuraion parameters logic moved to ConfigDepot
> 
> CLOUDSTACK-5163: missing parameters in configuration table
> pool.storage.capacity.disablethreshold, storage.overprovisioning.factor, 
> pool.storage.allocated.capacity.disablethreshold,
> cluster.cpu.allocated.capacity.disablethreshold, 
> cluster.memory.allocated.capacity.disablethreshold
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/deploy/DeploymentClusterPlanner.java ca73267 
>   
> framework/config/src/org/apache/cloudstack/framework/config/ConfigDepot.java 
> 2fd6efb 
>   
> framework/config/src/org/apache/cloudstack/framework/config/impl/ConfigDepotImpl.java
>  254e6d2 
>   server/src/com/cloud/capacity/CapacityManagerImpl.java 70491bc 
>   server/src/com/cloud/configuration/Config.java bc805b7 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 82256ca 
>   server/src/com/cloud/deploy/FirstFitPlanner.java 64b1124 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> a088a4a 
>   server/src/com/cloud/server/ConfigurationServerImpl.java 8459ada 
>   
> server/test/org/apache/cloudstack/networkoffering/ChildTestConfiguration.java 
> d7ac3f7 
> 
> Diff: https://reviews.apache.org/r/15507/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: [ASF4.2.1] Release Notes

[Daan Hoogland]

So the -1 is because of the lack of rn and upgrade path docs, right, I
think I proposed earlier this thread to release after the doc
hackathon privided that. I wasn't really explicit about it I think as
no one commented on this strategy. Would that be acceptable to you all
(especially David and Sebastien)?

I agree btw that docs must be available, but I don't think these have
to be as stable as the release. We should allow for improving the docs
on a release if needed. The net result of what I am proposing is that
there will be a release and a docs rc. This is what the splitting of
of the docs was about in my view,. Makes sense?

If not, we should not try to make CCC Europe with 4.2.1. I think this
is what the hurry is about

Daan

On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen  wrote:
> I might be behind on the discussions here, but I will veto an RC that does 
> not have list of bugs fixed and proper upgrade path documented (minimum of a 
> fix from 4.2.0 upgrade docs). Separate repo of the docs or not.
>
> Right now I see that the bugs fix list points to a jira filter. This is not 
> consistent with the way it was done in prior releases (explicit listing) and 
> in 4.2 (which pointed to the RN). We need consistency. What happens if 
> someone changes this jira filter ?
>
> I also would like to see the results of the test matrix for 4.2.1 running 
> within jenkins.buildacloud.org.  This 
> http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against master and 
> has been failing for a while.
>
> PS: I did test it and did the usual smoke test
>
> so -1 (binding) at this time
>
> -sebastien
>
>
> On Nov 14, 2013, at 4:20 PM, Chip Childers  wrote:
>
>> Except that the separation only helps if it allows RC testing + voting
>> during doc finalization.  If we announce before docs, it hurts us.
>> I'm against another announcement that goes out with the docs in poor
>> shape.
>>
>> On Thu, Nov 14, 2013 at 3:44 PM, Animesh Chaturvedi
>>  wrote:
>>> Unless there are objection to the RC, I would prefer to have it released 
>>> and make the announcement sooner and showcase in collab conference. As Chip 
>>> mentions docs were broken out separately anyway.
>>>
>>> Animesh
>>>
>>>
>>> On 14/11/13 8:12 pm, "Sebastien Goasguen"  wrote:
>>>
 Anyway we can wait next week to release.

 quite a few of us will be together in Amsterdam, we can dedicate a
 hackathon session to 4.2.1 , make sure RN are good, upgrade path
 etcŠthen testŠ.

 I'd recommend keeping the vote open until then.

 -sebastien


 On Nov 14, 2013, at 5:57 AM, Radhika Puthiyetath
  wrote:

> Hi,
>
> The master has the most up-to-date RN for 4.2.1.
>
> From: Abhinandan Prateek
> Sent: Thursday, November 14, 2013 2:22 PM
> To: CloudStack Dev
> Cc: Radhika Puthiyetath
> Subject: Re: [ASF4.2.1] Release Notes
>
>
> It seems the upgrade section of release notes will require a review,
> probably followed by a revamp (?).
> Can we have some volunteers who are familiar with various upgrade
> paths comment on it ?
> Me and Radhika will try to consolidate those comments, snippets and
> fix the RN for 4.2.1.
>
> -abhi
>
> RN for 4.2.1 =
> https://git-wip-us.apache.org/repos/asf?p=cloudstack-docs.git;a=tree;f
> =re
> lease-notes;h=8128d62c39236331492f3642914bf97b43ed2670;hb=refs/heads/4
> .2
>

>>>
>

Re: [ASF4.2.1] Release Notes

[Abhinandan Prateek]

As a RM I had agreed to Sebatian's suggestion of fixing the docs specially
the upgrade section of it.
And off course doing a GA after the docs are fixed is on the cards.

As for the list of fixed and known issues I was told that a filter is good
enough but it should be pretty easy to get the listing in the docs itself.
If someone has specific preferences it is easy to fix that.

So it boils down to get opinion from folks on the following:

1. RC build, this does not contain docs. I have seen no complains or
issues here.

2. Putting a full listing of bug fixes in RN Vs a filter. Even I will
think full listing is good or a query (instead of a URL?)

3. Upgrade instructions are known to be bad and we will have to wait at
least till Wednesday to get these right.
We have some volunteers already working on those and their effort is
highly appreciated.

-abhi


On 15/11/13 2:50 pm, "Daan Hoogland"  wrote:

>So the -1 is because of the lack of rn and upgrade path docs, right, I
>think I proposed earlier this thread to release after the doc
>hackathon privided that. I wasn't really explicit about it I think as
>no one commented on this strategy. Would that be acceptable to you all
>(especially David and Sebastien)?
>
>I agree btw that docs must be available, but I don't think these have
>to be as stable as the release. We should allow for improving the docs
>on a release if needed. The net result of what I am proposing is that
>there will be a release and a docs rc. This is what the splitting of
>of the docs was about in my view,. Makes sense?
>
>If not, we should not try to make CCC Europe with 4.2.1. I think this
>is what the hurry is about
>
>Daan
>
>On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen 
>wrote:
>> I might be behind on the discussions here, but I will veto an RC that
>>does not have list of bugs fixed and proper upgrade path documented
>>(minimum of a fix from 4.2.0 upgrade docs). Separate repo of the docs or
>>not.
>>
>> Right now I see that the bugs fix list points to a jira filter. This is
>>not consistent with the way it was done in prior releases (explicit
>>listing) and in 4.2 (which pointed to the RN). We need consistency. What
>>happens if someone changes this jira filter ?
>>
>> I also would like to see the results of the test matrix for 4.2.1
>>running within jenkins.buildacloud.org.  This
>>http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against master
>>and has been failing for a while.
>>
>> PS: I did test it and did the usual smoke test
>>
>> so -1 (binding) at this time
>>
>> -sebastien
>>
>>
>> On Nov 14, 2013, at 4:20 PM, Chip Childers 
>>wrote:
>>
>>> Except that the separation only helps if it allows RC testing + voting
>>> during doc finalization.  If we announce before docs, it hurts us.
>>> I'm against another announcement that goes out with the docs in poor
>>> shape.
>>>
>>> On Thu, Nov 14, 2013 at 3:44 PM, Animesh Chaturvedi
>>>  wrote:
 Unless there are objection to the RC, I would prefer to have it
released and make the announcement sooner and showcase in collab
conference. As Chip mentions docs were broken out separately anyway.

 Animesh


 On 14/11/13 8:12 pm, "Sebastien Goasguen"  wrote:

> Anyway we can wait next week to release.
>
> quite a few of us will be together in Amsterdam, we can dedicate a
> hackathon session to 4.2.1 , make sure RN are good, upgrade path
> etcŠthen testŠ.
>
> I'd recommend keeping the vote open until then.
>
> -sebastien
>
>
> On Nov 14, 2013, at 5:57 AM, Radhika Puthiyetath
>  wrote:
>
>> Hi,
>>
>> The master has the most up-to-date RN for 4.2.1.
>>
>> From: Abhinandan Prateek
>> Sent: Thursday, November 14, 2013 2:22 PM
>> To: CloudStack Dev
>> Cc: Radhika Puthiyetath
>> Subject: Re: [ASF4.2.1] Release Notes
>>
>>
>> It seems the upgrade section of release notes will require a review,
>> probably followed by a revamp (?).
>> Can we have some volunteers who are familiar with various upgrade
>> paths comment on it ?
>> Me and Radhika will try to consolidate those comments, snippets and
>> fix the RN for 4.2.1.
>>
>> -abhi
>>
>> RN for 4.2.1 =
>> 
>>https://git-wip-us.apache.org/repos/asf?p=cloudstack-docs.git;a=tree;
>>f
>> =re
>> 
>>lease-notes;h=8128d62c39236331492f3642914bf97b43ed2670;hb=refs/heads/
>>4
>> .2
>>
>

>>

Re: [ASF4.2.1] Release Notes

[Sebastien Goasguen]

On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek  
wrote:

> As a RM I had agreed to Sebatian's suggestion of fixing the docs specially
> the upgrade section of it.
> And off course doing a GA after the docs are fixed is on the cards.
> 
> As for the list of fixed and known issues I was told that a filter is good
> enough but it should be pretty easy to get the listing in the docs itself.
> If someone has specific preferences it is easy to fix that.
> 
> So it boils down to get opinion from folks on the following:
> 
> 1. RC build, this does not contain docs. I have seen no complains or
> issues here.

That's fine, but releasing something without the upgrade instructions committed 
is bad.
Even if the release of such upgrade instructions happen after the release of 
the code.

> 
> 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will
> think full listing is good or a query (instead of a URL?)
> 

I am in favor of consistency. Prior to 4.2 we listed all BUGS explicitly. We 
should keep doing that.

> 3. Upgrade instructions are known to be bad and we will have to wait at
> least till Wednesday to get these right.
>   We have some volunteers already working on those and their effort is
> highly appreciated.

Right, and since there is no rush, why not wait a bit till we can all look this 
with cool heads, double check the RN, bugs listing, upgrade instructions etc...

> 
> -abhi
> 
> 
> On 15/11/13 2:50 pm, "Daan Hoogland"  wrote:
> 
>> So the -1 is because of the lack of rn and upgrade path docs, right, I
>> think I proposed earlier this thread to release after the doc
>> hackathon privided that. I wasn't really explicit about it I think as
>> no one commented on this strategy. Would that be acceptable to you all
>> (especially David and Sebastien)?
>> 
>> I agree btw that docs must be available, but I don't think these have
>> to be as stable as the release. We should allow for improving the docs
>> on a release if needed. The net result of what I am proposing is that
>> there will be a release and a docs rc. This is what the splitting of
>> of the docs was about in my view,. Makes sense?
>> 
>> If not, we should not try to make CCC Europe with 4.2.1. I think this
>> is what the hurry is about
>> 
>> Daan
>> 
>> On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen 
>> wrote:
>>> I might be behind on the discussions here, but I will veto an RC that
>>> does not have list of bugs fixed and proper upgrade path documented
>>> (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the docs or
>>> not.
>>> 
>>> Right now I see that the bugs fix list points to a jira filter. This is
>>> not consistent with the way it was done in prior releases (explicit
>>> listing) and in 4.2 (which pointed to the RN). We need consistency. What
>>> happens if someone changes this jira filter ?
>>> 
>>> I also would like to see the results of the test matrix for 4.2.1
>>> running within jenkins.buildacloud.org.  This
>>> http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against master
>>> and has been failing for a while.
>>> 
>>> PS: I did test it and did the usual smoke test
>>> 
>>> so -1 (binding) at this time
>>> 
>>> -sebastien
>>> 
>>> 
>>> On Nov 14, 2013, at 4:20 PM, Chip Childers 
>>> wrote:
>>> 
 Except that the separation only helps if it allows RC testing + voting
 during doc finalization.  If we announce before docs, it hurts us.
 I'm against another announcement that goes out with the docs in poor
 shape.
 
 On Thu, Nov 14, 2013 at 3:44 PM, Animesh Chaturvedi
  wrote:
> Unless there are objection to the RC, I would prefer to have it
> released and make the announcement sooner and showcase in collab
> conference. As Chip mentions docs were broken out separately anyway.
> 
> Animesh
> 
> 
> On 14/11/13 8:12 pm, "Sebastien Goasguen"  wrote:
> 
>> Anyway we can wait next week to release.
>> 
>> quite a few of us will be together in Amsterdam, we can dedicate a
>> hackathon session to 4.2.1 , make sure RN are good, upgrade path
>> etcŠthen testŠ.
>> 
>> I'd recommend keeping the vote open until then.
>> 
>> -sebastien
>> 
>> 
>> On Nov 14, 2013, at 5:57 AM, Radhika Puthiyetath
>>  wrote:
>> 
>>> Hi,
>>> 
>>> The master has the most up-to-date RN for 4.2.1.
>>> 
>>> From: Abhinandan Prateek
>>> Sent: Thursday, November 14, 2013 2:22 PM
>>> To: CloudStack Dev
>>> Cc: Radhika Puthiyetath
>>> Subject: Re: [ASF4.2.1] Release Notes
>>> 
>>> 
>>> It seems the upgrade section of release notes will require a review,
>>> probably followed by a revamp (?).
>>> Can we have some volunteers who are familiar with various upgrade
>>> paths comment on it ?
>>> Me and Radhika will try to consolidate those comments, snippets and
>>> fix the RN for 4.2.1.
>>> 
>>> -abhi
>>> 
>>> RN for 4.2.1 =
>>> 
>>

Review Request 15452: CLOUDSTACK-5147: Removing basic and sg tags from test case which is invalid for basic zone

[Gaurav Aradhye]

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

Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri.


Summary (updated)
-

CLOUDSTACK-5147: Removing basic and sg tags from test case which is invalid for 
basic zone


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


Repository: cloudstack-git


Description (updated)
---

The test case 
test_resource_limits.TestMaxAccountNetworks.test_maxAccountNetworks tries to 
create multiple isolated networks in an account which is invalid scenario for 
basic zone.


Diffs (updated)
-

  test/integration/component/test_resource_limits.py 377aa74 

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


Testing
---


Thanks,

Gaurav Aradhye

Re: Review Request 15570: CLOUDSTACK-5180: Increasing the timeout for uploading volume

[ASF Subversion and Git Services]

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


Commit a95bea08e4c41e359c137068245d04bae4d1dff4 in branch refs/heads/4.2 from 
Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a95bea0 ]

CLOUDSTACK-5180: Increasing the timeout for uploading volume


- ASF Subversion and Git Services


On Nov. 15, 2013, 7:56 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15570/
> ---
> 
> (Updated Nov. 15, 2013, 7:56 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-5180
> https://issues.apache.org/jira/browse/CLOUDSTACK-5180
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Some test cases are failing while uploading the volume just because the time 
> allowed to upload the volume is less in marvin library.
> If timeout is increases, these tests pass. Example - 
> component.test_stopped_vm.TestUploadAttachVolume.test_upload_attach_volume. 
> This test case has failed in latest build but had passed earlier build.
> 
> To avoid this inconsistent behaviour, increased the timeout in 
> "wait_for_upload" function in Volume class in base.py
> The test case runs successfully with this change.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/integration/lib/base.py a3a5f58 
> 
> Diff: https://reviews.apache.org/r/15570/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on XenServer basic zone setup.
> 
> client Log:
> 2013-11-14 19:43:59,017 - DEBUG - test_upload_attach_volume 
> (test_stopped_vm.TestUploadAttachVolume) - Uploading the volume: DataDisk
> 2013-11-14 19:44:05,299 - DEBUG - test_upload_attach_volume 
> (test_stopped_vm.TestUploadAttachVolume) - Uploading the volume: DataDisk
> 2013-11-14 19:51:05,568 - DEBUG - test_upload_attach_volume 
> (test_stopped_vm.TestUploadAttachVolume) - Volume: %s uploaded successfully
> 2013-11-14 19:51:05,568 - DEBUG - test_upload_attach_volume 
> (test_stopped_vm.TestUploadAttachVolume) - Deploying VM instance in account: 
> test-OLJLXM
> 
> Result log:
> test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume)
> Test Upload volume and attach to VM in stopped state ... ok
> 
> 
> --
> Ran 17 tests in 442.869s
> 
> OK (skipped=16)
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 15570: CLOUDSTACK-5180: Increasing the timeout for uploading volume

[ASF Subversion and Git Services]

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


Commit 08208cf427f9957514e3bcc624272c6781a1189a in branch refs/heads/4.3 from 
Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=08208cf ]

CLOUDSTACK-5180: Increasing the timeout for uploading volume


- ASF Subversion and Git Services


On Nov. 15, 2013, 7:56 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15570/
> ---
> 
> (Updated Nov. 15, 2013, 7:56 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-5180
> https://issues.apache.org/jira/browse/CLOUDSTACK-5180
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Some test cases are failing while uploading the volume just because the time 
> allowed to upload the volume is less in marvin library.
> If timeout is increases, these tests pass. Example - 
> component.test_stopped_vm.TestUploadAttachVolume.test_upload_attach_volume. 
> This test case has failed in latest build but had passed earlier build.
> 
> To avoid this inconsistent behaviour, increased the timeout in 
> "wait_for_upload" function in Volume class in base.py
> The test case runs successfully with this change.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/integration/lib/base.py a3a5f58 
> 
> Diff: https://reviews.apache.org/r/15570/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on XenServer basic zone setup.
> 
> client Log:
> 2013-11-14 19:43:59,017 - DEBUG - test_upload_attach_volume 
> (test_stopped_vm.TestUploadAttachVolume) - Uploading the volume: DataDisk
> 2013-11-14 19:44:05,299 - DEBUG - test_upload_attach_volume 
> (test_stopped_vm.TestUploadAttachVolume) - Uploading the volume: DataDisk
> 2013-11-14 19:51:05,568 - DEBUG - test_upload_attach_volume 
> (test_stopped_vm.TestUploadAttachVolume) - Volume: %s uploaded successfully
> 2013-11-14 19:51:05,568 - DEBUG - test_upload_attach_volume 
> (test_stopped_vm.TestUploadAttachVolume) - Deploying VM instance in account: 
> test-OLJLXM
> 
> Result log:
> test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume)
> Test Upload volume and attach to VM in stopped state ... ok
> 
> 
> --
> Ran 17 tests in 442.869s
> 
> OK (skipped=16)
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 15570: CLOUDSTACK-5180: Increasing the timeout for uploading volume

[Girish Shilamkar]

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

Ship it!


COmmitted to 4.2, 4.3 and master

- Girish Shilamkar


On Nov. 15, 2013, 7:56 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15570/
> ---
> 
> (Updated Nov. 15, 2013, 7:56 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-5180
> https://issues.apache.org/jira/browse/CLOUDSTACK-5180
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Some test cases are failing while uploading the volume just because the time 
> allowed to upload the volume is less in marvin library.
> If timeout is increases, these tests pass. Example - 
> component.test_stopped_vm.TestUploadAttachVolume.test_upload_attach_volume. 
> This test case has failed in latest build but had passed earlier build.
> 
> To avoid this inconsistent behaviour, increased the timeout in 
> "wait_for_upload" function in Volume class in base.py
> The test case runs successfully with this change.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/integration/lib/base.py a3a5f58 
> 
> Diff: https://reviews.apache.org/r/15570/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on XenServer basic zone setup.
> 
> client Log:
> 2013-11-14 19:43:59,017 - DEBUG - test_upload_attach_volume 
> (test_stopped_vm.TestUploadAttachVolume) - Uploading the volume: DataDisk
> 2013-11-14 19:44:05,299 - DEBUG - test_upload_attach_volume 
> (test_stopped_vm.TestUploadAttachVolume) - Uploading the volume: DataDisk
> 2013-11-14 19:51:05,568 - DEBUG - test_upload_attach_volume 
> (test_stopped_vm.TestUploadAttachVolume) - Volume: %s uploaded successfully
> 2013-11-14 19:51:05,568 - DEBUG - test_upload_attach_volume 
> (test_stopped_vm.TestUploadAttachVolume) - Deploying VM instance in account: 
> test-OLJLXM
> 
> Result log:
> test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume)
> Test Upload volume and attach to VM in stopped state ... ok
> 
> 
> --
> Ran 17 tests in 442.869s
> 
> OK (skipped=16)
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 15570: CLOUDSTACK-5180: Increasing the timeout for uploading volume

[ASF Subversion and Git Services]

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


Commit c141e418e927dadc90a87ad4e1a939091cfbe54e in branch refs/heads/master 
from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c141e41 ]

CLOUDSTACK-5180: Increasing the timeout for uploading volume


- ASF Subversion and Git Services


On Nov. 15, 2013, 7:56 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15570/
> ---
> 
> (Updated Nov. 15, 2013, 7:56 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-5180
> https://issues.apache.org/jira/browse/CLOUDSTACK-5180
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Some test cases are failing while uploading the volume just because the time 
> allowed to upload the volume is less in marvin library.
> If timeout is increases, these tests pass. Example - 
> component.test_stopped_vm.TestUploadAttachVolume.test_upload_attach_volume. 
> This test case has failed in latest build but had passed earlier build.
> 
> To avoid this inconsistent behaviour, increased the timeout in 
> "wait_for_upload" function in Volume class in base.py
> The test case runs successfully with this change.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/integration/lib/base.py a3a5f58 
> 
> Diff: https://reviews.apache.org/r/15570/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on XenServer basic zone setup.
> 
> client Log:
> 2013-11-14 19:43:59,017 - DEBUG - test_upload_attach_volume 
> (test_stopped_vm.TestUploadAttachVolume) - Uploading the volume: DataDisk
> 2013-11-14 19:44:05,299 - DEBUG - test_upload_attach_volume 
> (test_stopped_vm.TestUploadAttachVolume) - Uploading the volume: DataDisk
> 2013-11-14 19:51:05,568 - DEBUG - test_upload_attach_volume 
> (test_stopped_vm.TestUploadAttachVolume) - Volume: %s uploaded successfully
> 2013-11-14 19:51:05,568 - DEBUG - test_upload_attach_volume 
> (test_stopped_vm.TestUploadAttachVolume) - Deploying VM instance in account: 
> test-OLJLXM
> 
> Result log:
> test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume)
> Test Upload volume and attach to VM in stopped state ... ok
> 
> 
> --
> Ran 17 tests in 442.869s
> 
> OK (skipped=16)
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 15452: CLOUDSTACK-5147: Removing basic and sg tags from test case which is invalid for basic zone

[ASF Subversion and Git Services]

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


Commit cfe3aabdc79a0702f5f12ca6b11266acf054cd6e in branch refs/heads/4.3 from 
Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cfe3aab ]

CLOUDSTACK-5147: Removing basic and sg tags from the test
 case which is invalid for basic zone


- ASF Subversion and Git Services


On Nov. 15, 2013, 10:07 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15452/
> ---
> 
> (Updated Nov. 15, 2013, 10:07 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-5147
> https://issues.apache.org/jira/browse/CLOUDSTACK-5147
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The test case 
> test_resource_limits.TestMaxAccountNetworks.test_maxAccountNetworks tries to 
> create multiple isolated networks in an account which is invalid scenario for 
> basic zone.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_resource_limits.py 377aa74 
> 
> Diff: https://reviews.apache.org/r/15452/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 15452: CLOUDSTACK-5147: Removing basic and sg tags from test case which is invalid for basic zone

[ASF Subversion and Git Services]

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


Commit a6c2c6a261af4871b0a8872f43068f15cc1da3cd in branch refs/heads/master 
from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a6c2c6a ]

CLOUDSTACK-5147: Removing basic and sg tags from the test
 case which is invalid for basic zone


- ASF Subversion and Git Services


On Nov. 15, 2013, 10:07 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15452/
> ---
> 
> (Updated Nov. 15, 2013, 10:07 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-5147
> https://issues.apache.org/jira/browse/CLOUDSTACK-5147
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The test case 
> test_resource_limits.TestMaxAccountNetworks.test_maxAccountNetworks tries to 
> create multiple isolated networks in an account which is invalid scenario for 
> basic zone.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_resource_limits.py 377aa74 
> 
> Diff: https://reviews.apache.org/r/15452/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 15452: CLOUDSTACK-5147: Removing basic and sg tags from test case which is invalid for basic zone

[Girish Shilamkar]

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

Ship it!


Committed to 4.2, 4.3 and master

- Girish Shilamkar


On Nov. 15, 2013, 10:07 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15452/
> ---
> 
> (Updated Nov. 15, 2013, 10:07 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-5147
> https://issues.apache.org/jira/browse/CLOUDSTACK-5147
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The test case 
> test_resource_limits.TestMaxAccountNetworks.test_maxAccountNetworks tries to 
> create multiple isolated networks in an account which is invalid scenario for 
> basic zone.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_resource_limits.py 377aa74 
> 
> Diff: https://reviews.apache.org/r/15452/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 15452: CLOUDSTACK-5147: Removing basic and sg tags from test case which is invalid for basic zone

[ASF Subversion and Git Services]

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


Commit 057a65e9a9df80592e1360dce8dfffaddacebd02 in branch refs/heads/4.2 from 
Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=057a65e ]

CLOUDSTACK-5147: Removing basic and sg tags from the test
 case which is invalid for basic zone


- ASF Subversion and Git Services


On Nov. 15, 2013, 10:07 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15452/
> ---
> 
> (Updated Nov. 15, 2013, 10:07 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-5147
> https://issues.apache.org/jira/browse/CLOUDSTACK-5147
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The test case 
> test_resource_limits.TestMaxAccountNetworks.test_maxAccountNetworks tries to 
> create multiple isolated networks in an account which is invalid scenario for 
> basic zone.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_resource_limits.py 377aa74 
> 
> Diff: https://reviews.apache.org/r/15452/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 15569: CLOUDSTACK-5179: Fixed test script issue related to detach volume

[ASF Subversion and Git Services]

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


Commit 5b2de676732ad8f8180782348cde656821728696 in branch refs/heads/4.2 from 
Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5b2de67 ]

CLOUDSTACK-5179: Fixed test script issue related to detach
 volume


- ASF Subversion and Git Services


On Nov. 15, 2013, 7:41 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15569/
> ---
> 
> (Updated Nov. 15, 2013, 7:41 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-5179
> https://issues.apache.org/jira/browse/CLOUDSTACK-5179
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> component.test_stopped_vm.TestDeployVM.test_08_deploy_attached_volume test 
> case was failing while detaching volume because the volume was not listed 
> properly. List volumes should accept the virtualmachineid parameter to 
> correctly list the volume belonging to the virtual machine, otherwise the 
> volume which we are detaching from virtual machine may belong to other 
> virtual machine, in this case test case will fail.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_stopped_vm.py 4514bb7 
> 
> Diff: https://reviews.apache.org/r/15569/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on XenServer Basic Zone setup.
> 
> test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM)
> Test Deploy Virtual Machine with startVM=false and attach volume already 
> attached to different machine ...
> ==> client.log <==
> 2013-11-14 19:27:10,018 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF
> 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for 
> virtual machine: 9631c
> 64f-a7ba-488b-951b-c425f00e1ce3
> 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Deploying instance in the account: 
> test-6MG5KF
> 2013-11-14 19:27:31,205 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF
> 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for 
> virtual machine: 7e3de
> e7d-29ce-425c-95e4-e8f85143254c
> 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Fetching DATADISK details for instance: 
> 7e3dee7d-29ce-425c-95e
> 4-e8f85143254c
> 2013-11-14 19:27:31,266 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Detaching the disk: DATA-32
> 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Datadisk DATA-32 detached!
> 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Attaching volume to instance: 
> 9631c64f-a7ba-488b-951b-c425f00e
> 1ce3
> 2013-11-14 19:27:41,530 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Cleaning up the resources
> 2013-11-14 19:28:42,227 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Cleanup complete!
> 
> ==> result.log <==
> ok
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 15569: CLOUDSTACK-5179: Fixed test script issue related to detach volume

[ASF Subversion and Git Services]

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


Commit e8629283000fbf7874309903da647e341854a7c6 in branch refs/heads/4.3 from 
Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e862928 ]

CLOUDSTACK-5179: Fixed test script issue related to detach
 volume


- ASF Subversion and Git Services


On Nov. 15, 2013, 7:41 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15569/
> ---
> 
> (Updated Nov. 15, 2013, 7:41 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-5179
> https://issues.apache.org/jira/browse/CLOUDSTACK-5179
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> component.test_stopped_vm.TestDeployVM.test_08_deploy_attached_volume test 
> case was failing while detaching volume because the volume was not listed 
> properly. List volumes should accept the virtualmachineid parameter to 
> correctly list the volume belonging to the virtual machine, otherwise the 
> volume which we are detaching from virtual machine may belong to other 
> virtual machine, in this case test case will fail.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_stopped_vm.py 4514bb7 
> 
> Diff: https://reviews.apache.org/r/15569/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on XenServer Basic Zone setup.
> 
> test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM)
> Test Deploy Virtual Machine with startVM=false and attach volume already 
> attached to different machine ...
> ==> client.log <==
> 2013-11-14 19:27:10,018 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF
> 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for 
> virtual machine: 9631c
> 64f-a7ba-488b-951b-c425f00e1ce3
> 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Deploying instance in the account: 
> test-6MG5KF
> 2013-11-14 19:27:31,205 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF
> 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for 
> virtual machine: 7e3de
> e7d-29ce-425c-95e4-e8f85143254c
> 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Fetching DATADISK details for instance: 
> 7e3dee7d-29ce-425c-95e
> 4-e8f85143254c
> 2013-11-14 19:27:31,266 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Detaching the disk: DATA-32
> 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Datadisk DATA-32 detached!
> 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Attaching volume to instance: 
> 9631c64f-a7ba-488b-951b-c425f00e
> 1ce3
> 2013-11-14 19:27:41,530 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Cleaning up the resources
> 2013-11-14 19:28:42,227 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Cleanup complete!
> 
> ==> result.log <==
> ok
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 15569: CLOUDSTACK-5179: Fixed test script issue related to detach volume

[ASF Subversion and Git Services]

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


Commit 8a1918dbe1c5fbbb60c21fa89d880a99e7b33bd6 in branch refs/heads/master 
from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8a1918d ]

CLOUDSTACK-5179: Fixed test script issue related to detach
 volume


- ASF Subversion and Git Services


On Nov. 15, 2013, 7:41 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15569/
> ---
> 
> (Updated Nov. 15, 2013, 7:41 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-5179
> https://issues.apache.org/jira/browse/CLOUDSTACK-5179
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> component.test_stopped_vm.TestDeployVM.test_08_deploy_attached_volume test 
> case was failing while detaching volume because the volume was not listed 
> properly. List volumes should accept the virtualmachineid parameter to 
> correctly list the volume belonging to the virtual machine, otherwise the 
> volume which we are detaching from virtual machine may belong to other 
> virtual machine, in this case test case will fail.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_stopped_vm.py 4514bb7 
> 
> Diff: https://reviews.apache.org/r/15569/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on XenServer Basic Zone setup.
> 
> test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM)
> Test Deploy Virtual Machine with startVM=false and attach volume already 
> attached to different machine ...
> ==> client.log <==
> 2013-11-14 19:27:10,018 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF
> 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for 
> virtual machine: 9631c
> 64f-a7ba-488b-951b-c425f00e1ce3
> 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Deploying instance in the account: 
> test-6MG5KF
> 2013-11-14 19:27:31,205 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF
> 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for 
> virtual machine: 7e3de
> e7d-29ce-425c-95e4-e8f85143254c
> 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Fetching DATADISK details for instance: 
> 7e3dee7d-29ce-425c-95e
> 4-e8f85143254c
> 2013-11-14 19:27:31,266 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Detaching the disk: DATA-32
> 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Datadisk DATA-32 detached!
> 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Attaching volume to instance: 
> 9631c64f-a7ba-488b-951b-c425f00e
> 1ce3
> 2013-11-14 19:27:41,530 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Cleaning up the resources
> 2013-11-14 19:28:42,227 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Cleanup complete!
> 
> ==> result.log <==
> ok
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 15569: CLOUDSTACK-5179: Fixed test script issue related to detach volume

[Girish Shilamkar]

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

Ship it!


COmmitted to 4.2, 4.3 and master

- Girish Shilamkar


On Nov. 15, 2013, 7:41 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15569/
> ---
> 
> (Updated Nov. 15, 2013, 7:41 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-5179
> https://issues.apache.org/jira/browse/CLOUDSTACK-5179
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> component.test_stopped_vm.TestDeployVM.test_08_deploy_attached_volume test 
> case was failing while detaching volume because the volume was not listed 
> properly. List volumes should accept the virtualmachineid parameter to 
> correctly list the volume belonging to the virtual machine, otherwise the 
> volume which we are detaching from virtual machine may belong to other 
> virtual machine, in this case test case will fail.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_stopped_vm.py 4514bb7 
> 
> Diff: https://reviews.apache.org/r/15569/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on XenServer Basic Zone setup.
> 
> test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM)
> Test Deploy Virtual Machine with startVM=false and attach volume already 
> attached to different machine ...
> ==> client.log <==
> 2013-11-14 19:27:10,018 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF
> 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for 
> virtual machine: 9631c
> 64f-a7ba-488b-951b-c425f00e1ce3
> 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Deploying instance in the account: 
> test-6MG5KF
> 2013-11-14 19:27:31,205 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF
> 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for 
> virtual machine: 7e3de
> e7d-29ce-425c-95e4-e8f85143254c
> 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Fetching DATADISK details for instance: 
> 7e3dee7d-29ce-425c-95e
> 4-e8f85143254c
> 2013-11-14 19:27:31,266 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Detaching the disk: DATA-32
> 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Datadisk DATA-32 detached!
> 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Attaching volume to instance: 
> 9631c64f-a7ba-488b-951b-c425f00e
> 1ce3
> 2013-11-14 19:27:41,530 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Cleaning up the resources
> 2013-11-14 19:28:42,227 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Cleanup complete!
> 
> ==> result.log <==
> ok
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Review Request 15571: CLOUDSTACK-2243: base_image_updation - Adding tags to test cases

[Ashutosh Kelkar]

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

Review request for cloudstack, Girish Shilamkar and Rayees Namathponnan.


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


Repository: cloudstack-git


Description
---

Added basic and advanced tags for the test cases.
The test cases have been run on both the setups.


Diffs
-

  test/integration/component/test_base_image_updation.py 8a99350 

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


Testing
---

Tested locally on KVM advanced and XenServer basic setup.


Thanks,

Ashutosh Kelkar

Re: Review Request 15571: CLOUDSTACK-2243: base_image_updation - Adding tags to test cases

[ASF Subversion and Git Services]

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


Commit 09c0370d70721e07ff02cd907a2cab2cabc9ae5b in branch refs/heads/master 
from Girish Shilamkar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=09c0370 ]

CLOUDSTACK-2243: base_image_updation - Adding tags to test cases


- ASF Subversion and Git Services


On Nov. 15, 2013, 11:09 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15571/
> ---
> 
> (Updated Nov. 15, 2013, 11:09 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and Rayees Namathponnan.
> 
> 
> Bugs: CLOUDSTACK-2243
> https://issues.apache.org/jira/browse/CLOUDSTACK-2243
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added basic and advanced tags for the test cases.
> The test cases have been run on both the setups.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_base_image_updation.py 8a99350 
> 
> Diff: https://reviews.apache.org/r/15571/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on KVM advanced and XenServer basic setup.
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: Review Request 15571: CLOUDSTACK-2243: base_image_updation - Adding tags to test cases

[ASF Subversion and Git Services]

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


Commit 729bf51070812db93611a732d2956207584fc3d2 in branch refs/heads/4.3 from 
Girish Shilamkar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=729bf51 ]

CLOUDSTACK-2243: base_image_updation - Adding tags to test cases


- ASF Subversion and Git Services


On Nov. 15, 2013, 11:09 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15571/
> ---
> 
> (Updated Nov. 15, 2013, 11:09 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and Rayees Namathponnan.
> 
> 
> Bugs: CLOUDSTACK-2243
> https://issues.apache.org/jira/browse/CLOUDSTACK-2243
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added basic and advanced tags for the test cases.
> The test cases have been run on both the setups.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_base_image_updation.py 8a99350 
> 
> Diff: https://reviews.apache.org/r/15571/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on KVM advanced and XenServer basic setup.
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: Review Request 15571: CLOUDSTACK-2243: base_image_updation - Adding tags to test cases

[ASF Subversion and Git Services]

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


Commit ac9c4b0233070748e2a489df5005e65c8f890356 in branch refs/heads/4.2 from 
Girish Shilamkar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ac9c4b0 ]

CLOUDSTACK-2243: base_image_updation - Adding tags to test cases


- ASF Subversion and Git Services


On Nov. 15, 2013, 11:09 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15571/
> ---
> 
> (Updated Nov. 15, 2013, 11:09 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and Rayees Namathponnan.
> 
> 
> Bugs: CLOUDSTACK-2243
> https://issues.apache.org/jira/browse/CLOUDSTACK-2243
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added basic and advanced tags for the test cases.
> The test cases have been run on both the setups.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_base_image_updation.py 8a99350 
> 
> Diff: https://reviews.apache.org/r/15571/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on KVM advanced and XenServer basic setup.
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Review Request 15572: LDAP import users changes

[Rajani Karuturi]

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

Review request for cloudstack, Abhinandan Prateek and Ian Duffy.


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


Repository: cloudstack-git


Description
---

added LDAP group name label in add account wizard

changed the parameter for domain in api importLdapUser from name to UUID

improved error handling


Diffs
-

  client/WEB-INF/classes/resources/messages.properties 5885bd0 
  
plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/command/LdapImportUsersCmd.java
 063db0e 
  
plugins/user-authenticators/ldap/test/groovy/org/apache/cloudstack/ldap/LdapImportUsersCmdSpec.groovy
 0455640 
  ui/dictionary.jsp 0ccfc23 
  ui/scripts/accountsWizard.js 70ef082 
  ui/scripts/docs.js a3151b1 
  ui/scripts/ui-custom/accountsWizard.js 358e29c 

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


Testing
---

unit testing for all the java changes and manual testing for UI changes is done.


Thanks,

Rajani Karuturi

Re: [ASF4.2.1] Release Notes

[Prasanna Santhanam]

On Fri, Nov 15, 2013 at 03:14:48AM -0500, Sebastien Goasguen wrote:
> I also would like to see the results of the test matrix for 4.2.1
> running within jenkins.buildacloud.org.  This
> http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against
> master and has been failing for a while.
> 

Bit behind this, I've started a fresh set of tests against 4.2 - will
post the results once the job finishes. The default build now points
to 4.2.  Will switch it back to master post 4.2.1 announcement.

http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-matrix-extended/224/


Powered by BigRock.com

Build failed in Jenkins: cloudstack-4.3-maven-build-noredist #21

[jenkins]

See 


Changes:

[w.zhou] remove duplicated scheduled tasks from 
VpcVirtualNetworkApplianceManagerImpl

[jessicawang] CLOUDSTACK-999: hyper-V: UI > Add Primary Storage > when 
hypervisor type of selected cluster is Hyperv, populate Protocol dropdown with 
only one option "SMB/cifs".

[jessicawang] CLOUDSTACK-999: hyper-V: UI > zone wizard > Edit Traffic Type > 
send hypervnetworklabel to addTrafficType API.

[jessicawang] CLOUDSTACK-3154: UI > zone detail > remove VMware data center 
action > if API returns error, stop spinning wheel and show returned error text 
in a pop up dialog.

[nitin.mehta] CLOUDSTACK-5176:

[girish]  CLOUDSTACK-5166: Fixed test script issue related to egress

[girish] CLOUDSTACK-5168: Fixed test script issue related to SSH

[girish] CLOUDSTACK-5169: Egress rules - Improved assertion code

[jayapal] CLOUDSTACK-5177: Fixed issue with running script from cron job

[koushik] Revert "CLOUDSTACK-5176:"

[koushik] CLOUDSTACK-4835: Update global configuration test cases failed in 
master Changes made in update/list configuration API to use ConfigDepot

[milamber] Add 4.3.x messages.properties to Transifex config tool

[milamber] Add 4.3 messages.properties L10N strings from Transifex to repo, 
branch 4.3

[girish] CLOUDSTACK-5148: Fix test_createSharedNetwork_projectSpecific

[girish] CLOUDSTACK-5180: Increasing the timeout for uploading volume

[girish] CLOUDSTACK-5147: Removing basic and sg tags from the test

[girish] CLOUDSTACK-5179: Fixed test script issue related to detach

[girish] CLOUDSTACK-2243: base_image_updation - Adding tags to test cases

[girish] Fix marvin to refer to correct random_gen() function

--
Started by upstream project "cloudstack-4.3-maven-build" build number 63
originally caused by:
 Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on rpmbuilder-2 in workspace 

Checkout:cloudstack-4.3-maven-build-noredist / 
 - 
hudson.remoting.Channel@ec725c:rpmbuilder-2
Using strategy: Default
Last Built Revision: Revision 2b83fa159371308ff6dc0dea688a2323b275e9d7 
(origin/4.3)
Cloning the remote Git repository
Cloning repository https://git-wip-us.apache.org/repos/asf/cloudstack.git
git --version
git version 1.7.1
Fetching upstream changes from origin
Commencing build of Revision 03fea0c4dfc9b1d927ded7c8f83f3148bf6c74ed 
(origin/4.3)
Checking out Revision 03fea0c4dfc9b1d927ded7c8f83f3148bf6c74ed (origin/4.3)
Deleting old artifacts from #19
[copy-to-slave] Copying 'cloudstack-nonoss-deps.tgz', excluding nothing, from 
'file:/var/lib/jenkins/userContent/' on the master to 
' 
on 'rpmbuilder-2'.
[cloudstack-4.3-maven-build-noredist] $ /bin/sh -xe 
/tmp/hudson5586696149919246090.sh
+ echo 'Getting noredist patches'
Getting noredist patches
+ which mvn
/usr/bin/mvn
+ cd deps
+ tar -xvf ../cloudstack-nonoss-deps.tgz
apputils.jar
cloud-iControl.jar
cloud-manageontap.jar
cloud-netscaler.jar
cloud-netscaler-sdx.jar
libvirt-0.4.8.jar
manageontap.jar
vim25_51.jar
vim25.jar
vim.jar
+ bash -x install-non-oss.sh
+ mvn install:install-file -Dfile=cloud-iControl.jar -DgroupId=com.cloud.com.f5 
-DartifactId=icontrol -Dversion=1.0 -Dpackaging=jar
[INFO] Scanning for projects...
[INFO] 
[INFO] 
[INFO] Building Maven Stub Project (No POM) 1
[INFO] 
[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @ 
standalone-pom ---
[INFO] Installing 

 to 
/var/lib/jenkins/.m2/repository/com/cloud/com/f5/icontrol/1.0/icontrol-1.0.jar
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 4.942s
[INFO] Finished at: Fri Nov 15 07:09:23 EST 2013
[INFO] Final Memory: 3M/34M
[INFO] 
+ mvn install:install-file -Dfile=cloud-netscaler-sdx.jar 
-DgroupId=com.cloud.com.citrix -DartifactId=netscaler-sdx -Dversion=1.0 
-Dpackaging=jar
[INFO] Scanning for projects...
[INFO] 
[INFO] 
[INFO] Building Maven Stub Project (No POM) 1
[INFO] 
[INFO] 
[INFO] --- maven-install-plugin

Re: [ASF4.2.1] Release Notes

[Abhinandan Prateek]

To address the concern of RN we will not conclude the vote on RC (i.e. Not
make a release) 
till the RN in general and upgrade instructions in particular are also of
acceptable quality.
As for other inconsistencies will work towards ironing those out.

-abhi

On 15/11/13 3:30 pm, "Sebastien Goasguen"  wrote:

>
>On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek
> wrote:
>
>> As a RM I had agreed to Sebatian's suggestion of fixing the docs
>>specially
>> the upgrade section of it.
>> And off course doing a GA after the docs are fixed is on the cards.
>> 
>> As for the list of fixed and known issues I was told that a filter is
>>good
>> enough but it should be pretty easy to get the listing in the docs
>>itself.
>> If someone has specific preferences it is easy to fix that.
>> 
>> So it boils down to get opinion from folks on the following:
>> 
>> 1. RC build, this does not contain docs. I have seen no complains or
>> issues here.
>
>That's fine, but releasing something without the upgrade instructions
>committed is bad.
>Even if the release of such upgrade instructions happen after the release
>of the code.
>
>> 
>> 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will
>> think full listing is good or a query (instead of a URL?)
>> 
>
>I am in favor of consistency. Prior to 4.2 we listed all BUGS explicitly.
>We should keep doing that.
>
>> 3. Upgrade instructions are known to be bad and we will have to wait at
>> least till Wednesday to get these right.
>>  We have some volunteers already working on those and their effort is
>> highly appreciated.
>
>Right, and since there is no rush, why not wait a bit till we can all
>look this with cool heads, double check the RN, bugs listing, upgrade
>instructions etc...
>
>> 
>> -abhi
>> 
>> 
>> On 15/11/13 2:50 pm, "Daan Hoogland"  wrote:
>> 
>>> So the -1 is because of the lack of rn and upgrade path docs, right, I
>>> think I proposed earlier this thread to release after the doc
>>> hackathon privided that. I wasn't really explicit about it I think as
>>> no one commented on this strategy. Would that be acceptable to you all
>>> (especially David and Sebastien)?
>>> 
>>> I agree btw that docs must be available, but I don't think these have
>>> to be as stable as the release. We should allow for improving the docs
>>> on a release if needed. The net result of what I am proposing is that
>>> there will be a release and a docs rc. This is what the splitting of
>>> of the docs was about in my view,. Makes sense?
>>> 
>>> If not, we should not try to make CCC Europe with 4.2.1. I think this
>>> is what the hurry is about
>>> 
>>> Daan
>>> 
>>> On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen 
>>> wrote:
 I might be behind on the discussions here, but I will veto an RC that
 does not have list of bugs fixed and proper upgrade path documented
 (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the docs
or
 not.
 
 Right now I see that the bugs fix list points to a jira filter. This
is
 not consistent with the way it was done in prior releases (explicit
 listing) and in 4.2 (which pointed to the RN). We need consistency.
What
 happens if someone changes this jira filter ?
 
 I also would like to see the results of the test matrix for 4.2.1
 running within jenkins.buildacloud.org.  This
 http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against master
 and has been failing for a while.
 
 PS: I did test it and did the usual smoke test
 
 so -1 (binding) at this time
 
 -sebastien
 
 
 On Nov 14, 2013, at 4:20 PM, Chip Childers 
 wrote:
 
> Except that the separation only helps if it allows RC testing +
>voting
> during doc finalization.  If we announce before docs, it hurts us.
> I'm against another announcement that goes out with the docs in poor
> shape.
> 
> On Thu, Nov 14, 2013 at 3:44 PM, Animesh Chaturvedi
>  wrote:
>> Unless there are objection to the RC, I would prefer to have it
>> released and make the announcement sooner and showcase in collab
>> conference. As Chip mentions docs were broken out separately anyway.
>> 
>> Animesh
>> 
>> 
>> On 14/11/13 8:12 pm, "Sebastien Goasguen"  wrote:
>> 
>>> Anyway we can wait next week to release.
>>> 
>>> quite a few of us will be together in Amsterdam, we can dedicate a
>>> hackathon session to 4.2.1 , make sure RN are good, upgrade path
>>> etcŠthen testŠ.
>>> 
>>> I'd recommend keeping the vote open until then.
>>> 
>>> -sebastien
>>> 
>>> 
>>> On Nov 14, 2013, at 5:57 AM, Radhika Puthiyetath
>>>  wrote:
>>> 
 Hi,
 
 The master has the most up-to-date RN for 4.2.1.
 
 From: Abhinandan Prateek
 Sent: Thursday, November 14, 2013 2:22 PM
 To: CloudStack Dev
 Cc: Radhika Puthiyetath
 

Re: [ASF4.2.1] Release Notes

[Abhinandan Prateek]

For listing down the fixed issues, since there are ~175 of these. I will
list down some important fixes.
Followed by the query to give a exhaustive list, is that acceptable ?

For known issues will look at the 4.3/4.2 open tickets list down the
important ones.

This will go in the CHANGES in source repo and RN in code repo.


-abhi

On 15/11/13 5:54 pm, "Abhinandan Prateek" 
wrote:

>To address the concern of RN we will not conclude the vote on RC (i.e. Not
>make a release) 
>till the RN in general and upgrade instructions in particular are also of
>acceptable quality.
>As for other inconsistencies will work towards ironing those out.
>
>-abhi
>
>On 15/11/13 3:30 pm, "Sebastien Goasguen"  wrote:
>
>>
>>On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek
>> wrote:
>>
>>> As a RM I had agreed to Sebatian's suggestion of fixing the docs
>>>specially
>>> the upgrade section of it.
>>> And off course doing a GA after the docs are fixed is on the cards.
>>> 
>>> As for the list of fixed and known issues I was told that a filter is
>>>good
>>> enough but it should be pretty easy to get the listing in the docs
>>>itself.
>>> If someone has specific preferences it is easy to fix that.
>>> 
>>> So it boils down to get opinion from folks on the following:
>>> 
>>> 1. RC build, this does not contain docs. I have seen no complains or
>>> issues here.
>>
>>That's fine, but releasing something without the upgrade instructions
>>committed is bad.
>>Even if the release of such upgrade instructions happen after the release
>>of the code.
>>
>>> 
>>> 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will
>>> think full listing is good or a query (instead of a URL?)
>>> 
>>
>>I am in favor of consistency. Prior to 4.2 we listed all BUGS explicitly.
>>We should keep doing that.
>>
>>> 3. Upgrade instructions are known to be bad and we will have to wait at
>>> least till Wednesday to get these right.
>>> We have some volunteers already working on those and their effort is
>>> highly appreciated.
>>
>>Right, and since there is no rush, why not wait a bit till we can all
>>look this with cool heads, double check the RN, bugs listing, upgrade
>>instructions etc...
>>
>>> 
>>> -abhi
>>> 
>>> 
>>> On 15/11/13 2:50 pm, "Daan Hoogland"  wrote:
>>> 
 So the -1 is because of the lack of rn and upgrade path docs, right, I
 think I proposed earlier this thread to release after the doc
 hackathon privided that. I wasn't really explicit about it I think as
 no one commented on this strategy. Would that be acceptable to you all
 (especially David and Sebastien)?
 
 I agree btw that docs must be available, but I don't think these have
 to be as stable as the release. We should allow for improving the docs
 on a release if needed. The net result of what I am proposing is that
 there will be a release and a docs rc. This is what the splitting of
 of the docs was about in my view,. Makes sense?
 
 If not, we should not try to make CCC Europe with 4.2.1. I think this
 is what the hurry is about
 
 Daan
 
 On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen 
 wrote:
> I might be behind on the discussions here, but I will veto an RC that
> does not have list of bugs fixed and proper upgrade path documented
> (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the docs
>or
> not.
> 
> Right now I see that the bugs fix list points to a jira filter. This
>is
> not consistent with the way it was done in prior releases (explicit
> listing) and in 4.2 (which pointed to the RN). We need consistency.
>What
> happens if someone changes this jira filter ?
> 
> I also would like to see the results of the test matrix for 4.2.1
> running within jenkins.buildacloud.org.  This
> http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against
>master
> and has been failing for a while.
> 
> PS: I did test it and did the usual smoke test
> 
> so -1 (binding) at this time
> 
> -sebastien
> 
> 
> On Nov 14, 2013, at 4:20 PM, Chip Childers 
> wrote:
> 
>> Except that the separation only helps if it allows RC testing +
>>voting
>> during doc finalization.  If we announce before docs, it hurts us.
>> I'm against another announcement that goes out with the docs in poor
>> shape.
>> 
>> On Thu, Nov 14, 2013 at 3:44 PM, Animesh Chaturvedi
>>  wrote:
>>> Unless there are objection to the RC, I would prefer to have it
>>> released and make the announcement sooner and showcase in collab
>>> conference. As Chip mentions docs were broken out separately
>>>anyway.
>>> 
>>> Animesh
>>> 
>>> 
>>> On 14/11/13 8:12 pm, "Sebastien Goasguen"  wrote:
>>> 
 Anyway we can wait next week to release.
 
 quite a few of us will be together in Amsterdam, we can dedicate a
 hacka

Fwd: New Defects reported by Coverity Scan for cloudstack

[Hugo Trippaers]

Forward as the mail to the list is not setup yet.

Sent from my iPhone

Begin forwarded message:

> From: scan-ad...@coverity.com
> Date: 15 november 2013 13:47:59 CET
> Subject: New Defects reported by Coverity Scan for cloudstack
> 
> 
> Hi,
> 
> 
> Please find the latest report on new defect(s) introduced to cloudstack found 
> with Coverity Scan.
> 
> Defect(s) Reported-by: Coverity Scan
> Showing 7 of 7 defect(s)
> 
> 
> ** CID 1128965:  Missing call to superclass  (CALL_SUPER)
> /services/console-proxy-rdp/rdpconsole/src/main/java/streamer/MockSource.java:
>  49 in streamer.MockSource.handleEvent(streamer.Event, streamer.Direction)()
> 
> ** CID 1128964:  Missing call to superclass  (CALL_SUPER)
> /services/console-proxy-rdp/rdpconsole/src/main/java/streamer/FakeSink.java: 
> 45 in streamer.FakeSink.handleEvent(streamer.Event, streamer.Direction)()
> 
> ** CID 1128966:  Explicit null dereferenced  (FORWARD_NULL)
> /server/src/com/cloud/network/NetworkServiceImpl.java: 3553 in 
> com.cloud.network.NetworkServiceImpl.addTrafficTypeToPhysicalNetwork(java.lang.Long,
>  java.lang.String, java.lang.String, java.lang.String, java.lang.String, 
> java.lang.String, java.lang.String, java.lang.String)()
> 
> ** CID 1128967:  Unguarded write  (GUARDED_BY_VIOLATION)
> /plugins/network-elements/palo-alto/src/com/cloud/network/resource/PaloAltoResource.java:
>  246 in 
> com.cloud.network.resource.PaloAltoResource.configure(java.lang.String, 
> java.util.Map)()
> 
> ** CID 1128968:  Using invalid iterator  (INVALIDATE_ITERATOR)
> /services/console-proxy-rdp/rdpconsole/src/main/java/streamer/BaseElement.java:
>  149 in streamer.BaseElement.poll(boolean)()
> 
> ** CID 1128969:  Failure to restore non-local value  (MISSING_RESTORE)
> /server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java: 1194 in 
> com.cloud.network.lb.LoadBalancingRulesManagerImpl.assignCertToLoadBalancer(long,
>  java.lang.Long)()
> 
> ** CID 1128970:  Dereference null return value  (NULL_RETURNS)
> /services/console-proxy-rdp/rdpconsole/src/main/java/streamer/BaseElement.java:
>  414 in streamer.BaseElement.main(java.lang.String[])()
> 
> 
> 
> 
> 
> To view the defects in Coverity Scan visit, http://scan.coverity.com
> 
> To unsubscribe from the email notification for new defects, 
> http://scan5.coverity.com/cgi-bin/unsubscribe.py
> 
> 
> 

Re: [ASF4.2.1] Release Notes

[Daan Hoogland]

Abihnandan,

Why not include the output of the query instead of the query? I think
this is what Sebastien means. A list of the important ones can still
be prepended in more readable form afaic.

Daan

On Fri, Nov 15, 2013 at 1:32 PM, Abhinandan Prateek
 wrote:
> For listing down the fixed issues, since there are ~175 of these. I will
> list down some important fixes.
> Followed by the query to give a exhaustive list, is that acceptable ?
>
> For known issues will look at the 4.3/4.2 open tickets list down the
> important ones.
>
> This will go in the CHANGES in source repo and RN in code repo.
>
>
> -abhi
>
> On 15/11/13 5:54 pm, "Abhinandan Prateek" 
> wrote:
>
>>To address the concern of RN we will not conclude the vote on RC (i.e. Not
>>make a release)
>>till the RN in general and upgrade instructions in particular are also of
>>acceptable quality.
>>As for other inconsistencies will work towards ironing those out.
>>
>>-abhi
>>
>>On 15/11/13 3:30 pm, "Sebastien Goasguen"  wrote:
>>
>>>
>>>On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek
>>> wrote:
>>>
 As a RM I had agreed to Sebatian's suggestion of fixing the docs
specially
 the upgrade section of it.
 And off course doing a GA after the docs are fixed is on the cards.

 As for the list of fixed and known issues I was told that a filter is
good
 enough but it should be pretty easy to get the listing in the docs
itself.
 If someone has specific preferences it is easy to fix that.

 So it boils down to get opinion from folks on the following:

 1. RC build, this does not contain docs. I have seen no complains or
 issues here.
>>>
>>>That's fine, but releasing something without the upgrade instructions
>>>committed is bad.
>>>Even if the release of such upgrade instructions happen after the release
>>>of the code.
>>>

 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will
 think full listing is good or a query (instead of a URL?)

>>>
>>>I am in favor of consistency. Prior to 4.2 we listed all BUGS explicitly.
>>>We should keep doing that.
>>>
 3. Upgrade instructions are known to be bad and we will have to wait at
 least till Wednesday to get these right.
 We have some volunteers already working on those and their effort is
 highly appreciated.
>>>
>>>Right, and since there is no rush, why not wait a bit till we can all
>>>look this with cool heads, double check the RN, bugs listing, upgrade
>>>instructions etc...
>>>

 -abhi


 On 15/11/13 2:50 pm, "Daan Hoogland"  wrote:

> So the -1 is because of the lack of rn and upgrade path docs, right, I
> think I proposed earlier this thread to release after the doc
> hackathon privided that. I wasn't really explicit about it I think as
> no one commented on this strategy. Would that be acceptable to you all
> (especially David and Sebastien)?
>
> I agree btw that docs must be available, but I don't think these have
> to be as stable as the release. We should allow for improving the docs
> on a release if needed. The net result of what I am proposing is that
> there will be a release and a docs rc. This is what the splitting of
> of the docs was about in my view,. Makes sense?
>
> If not, we should not try to make CCC Europe with 4.2.1. I think this
> is what the hurry is about
>
> Daan
>
> On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen 
> wrote:
>> I might be behind on the discussions here, but I will veto an RC that
>> does not have list of bugs fixed and proper upgrade path documented
>> (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the docs
>>or
>> not.
>>
>> Right now I see that the bugs fix list points to a jira filter. This
>>is
>> not consistent with the way it was done in prior releases (explicit
>> listing) and in 4.2 (which pointed to the RN). We need consistency.
>>What
>> happens if someone changes this jira filter ?
>>
>> I also would like to see the results of the test matrix for 4.2.1
>> running within jenkins.buildacloud.org.  This
>> http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against
>>master
>> and has been failing for a while.
>>
>> PS: I did test it and did the usual smoke test
>>
>> so -1 (binding) at this time
>>
>> -sebastien
>>
>>
>> On Nov 14, 2013, at 4:20 PM, Chip Childers 
>> wrote:
>>
>>> Except that the separation only helps if it allows RC testing +
>>>voting
>>> during doc finalization.  If we announce before docs, it hurts us.
>>> I'm against another announcement that goes out with the docs in poor
>>> shape.
>>>
>>> On Thu, Nov 14, 2013 at 3:44 PM, Animesh Chaturvedi
>>>  wrote:
 Unless there are objection to the RC, I would prefer to have it
 released and make the announcem

Re: [ASF4.2.1] Release Notes

[Sebastien Goasguen]

On Nov 15, 2013, at 7:32 AM, Abhinandan Prateek  
wrote:

> For listing down the fixed issues, since there are ~175 of these. I will
> list down some important fixes.
> Followed by the query to give a exhaustive list, is that acceptable ?
> 

I know jira has an api, so you could easily query jira and automatically write 
the list of fixed bugs in the CHANGES file.
we should automate this:

>>>import requests
>>>import pprint
>>> r=requests.get('https://issues.apache.org/jira/rest/api/2/filter/12325707')
>>> r=requests.get('https://issues.apache.org/jira/rest/api/2/search?jql=project+%3D+CLOUDSTACK+AND+type+%3D+Bug+AND+affectedVersion+in+(%224.2.0%22,+%224.2%22)+AND+fixVersion+%3D+%224.2.1%22+AND+resolution+!%3D+%22%5C%22Unresolved%5C%22%22+ORDER+BY+created+DESC,+priority+DESC,+key+ASC')
>>> pprint.pprint(r.json)

The ideal process is really that when a bug gets resolved, the person who 
committed the patch to solve the bug should also update the CHANGES file.


> For known issues will look at the 4.3/4.2 open tickets list down the
> important ones.
> 
> This will go in the CHANGES in source repo and RN in code repo.
> 
> 
> -abhi
> 
> On 15/11/13 5:54 pm, "Abhinandan Prateek" 
> wrote:
> 
>> To address the concern of RN we will not conclude the vote on RC (i.e. Not
>> make a release) 
>> till the RN in general and upgrade instructions in particular are also of
>> acceptable quality.
>> As for other inconsistencies will work towards ironing those out.
>> 
>> -abhi
>> 
>> On 15/11/13 3:30 pm, "Sebastien Goasguen"  wrote:
>> 
>>> 
>>> On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek
>>>  wrote:
>>> 
 As a RM I had agreed to Sebatian's suggestion of fixing the docs
 specially
 the upgrade section of it.
 And off course doing a GA after the docs are fixed is on the cards.
 
 As for the list of fixed and known issues I was told that a filter is
 good
 enough but it should be pretty easy to get the listing in the docs
 itself.
 If someone has specific preferences it is easy to fix that.
 
 So it boils down to get opinion from folks on the following:
 
 1. RC build, this does not contain docs. I have seen no complains or
 issues here.
>>> 
>>> That's fine, but releasing something without the upgrade instructions
>>> committed is bad.
>>> Even if the release of such upgrade instructions happen after the release
>>> of the code.
>>> 
 
 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will
 think full listing is good or a query (instead of a URL?)
 
>>> 
>>> I am in favor of consistency. Prior to 4.2 we listed all BUGS explicitly.
>>> We should keep doing that.
>>> 
 3. Upgrade instructions are known to be bad and we will have to wait at
 least till Wednesday to get these right.
We have some volunteers already working on those and their effort is
 highly appreciated.
>>> 
>>> Right, and since there is no rush, why not wait a bit till we can all
>>> look this with cool heads, double check the RN, bugs listing, upgrade
>>> instructions etc...
>>> 
 
 -abhi
 
 
 On 15/11/13 2:50 pm, "Daan Hoogland"  wrote:
 
> So the -1 is because of the lack of rn and upgrade path docs, right, I
> think I proposed earlier this thread to release after the doc
> hackathon privided that. I wasn't really explicit about it I think as
> no one commented on this strategy. Would that be acceptable to you all
> (especially David and Sebastien)?
> 
> I agree btw that docs must be available, but I don't think these have
> to be as stable as the release. We should allow for improving the docs
> on a release if needed. The net result of what I am proposing is that
> there will be a release and a docs rc. This is what the splitting of
> of the docs was about in my view,. Makes sense?
> 
> If not, we should not try to make CCC Europe with 4.2.1. I think this
> is what the hurry is about
> 
> Daan
> 
> On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen 
> wrote:
>> I might be behind on the discussions here, but I will veto an RC that
>> does not have list of bugs fixed and proper upgrade path documented
>> (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the docs
>> or
>> not.
>> 
>> Right now I see that the bugs fix list points to a jira filter. This
>> is
>> not consistent with the way it was done in prior releases (explicit
>> listing) and in 4.2 (which pointed to the RN). We need consistency.
>> What
>> happens if someone changes this jira filter ?
>> 
>> I also would like to see the results of the test matrix for 4.2.1
>> running within jenkins.buildacloud.org.  This
>> http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against
>> master
>> and has been failing for a while.
>> 
>> PS: I did test it and did the usual smoke test
>> 
>>

Re: [ASF4.2.1] Release Notes

[Abhinandan Prateek]

Ok I will go that way till someone says that listing 175 tickets in
CHANGES file will needlessly clutter it.
Can we focus the list to blockers and criticals at least ?

-abhi

On 15/11/13 6:34 pm, "Daan Hoogland"  wrote:

>Abihnandan,
>
>Why not include the output of the query instead of the query? I think
>this is what Sebastien means. A list of the important ones can still
>be prepended in more readable form afaic.
>
>Daan
>
>On Fri, Nov 15, 2013 at 1:32 PM, Abhinandan Prateek
> wrote:
>> For listing down the fixed issues, since there are ~175 of these. I will
>> list down some important fixes.
>> Followed by the query to give a exhaustive list, is that acceptable ?
>>
>> For known issues will look at the 4.3/4.2 open tickets list down the
>> important ones.
>>
>> This will go in the CHANGES in source repo and RN in code repo.
>>
>>
>> -abhi
>>
>> On 15/11/13 5:54 pm, "Abhinandan Prateek"
>>
>> wrote:
>>
>>>To address the concern of RN we will not conclude the vote on RC (i.e.
>>>Not
>>>make a release)
>>>till the RN in general and upgrade instructions in particular are also
>>>of
>>>acceptable quality.
>>>As for other inconsistencies will work towards ironing those out.
>>>
>>>-abhi
>>>
>>>On 15/11/13 3:30 pm, "Sebastien Goasguen"  wrote:
>>>

On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek
 wrote:

> As a RM I had agreed to Sebatian's suggestion of fixing the docs
>specially
> the upgrade section of it.
> And off course doing a GA after the docs are fixed is on the cards.
>
> As for the list of fixed and known issues I was told that a filter is
>good
> enough but it should be pretty easy to get the listing in the docs
>itself.
> If someone has specific preferences it is easy to fix that.
>
> So it boils down to get opinion from folks on the following:
>
> 1. RC build, this does not contain docs. I have seen no complains or
> issues here.

That's fine, but releasing something without the upgrade instructions
committed is bad.
Even if the release of such upgrade instructions happen after the
release
of the code.

>
> 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will
> think full listing is good or a query (instead of a URL?)
>

I am in favor of consistency. Prior to 4.2 we listed all BUGS
explicitly.
We should keep doing that.

> 3. Upgrade instructions are known to be bad and we will have to wait
>at
> least till Wednesday to get these right.
> We have some volunteers already working on those and their
>effort is
> highly appreciated.

Right, and since there is no rush, why not wait a bit till we can all
look this with cool heads, double check the RN, bugs listing, upgrade
instructions etc...

>
> -abhi
>
>
> On 15/11/13 2:50 pm, "Daan Hoogland"  wrote:
>
>> So the -1 is because of the lack of rn and upgrade path docs,
>>right, I
>> think I proposed earlier this thread to release after the doc
>> hackathon privided that. I wasn't really explicit about it I think
>>as
>> no one commented on this strategy. Would that be acceptable to you
>>all
>> (especially David and Sebastien)?
>>
>> I agree btw that docs must be available, but I don't think these
>>have
>> to be as stable as the release. We should allow for improving the
>>docs
>> on a release if needed. The net result of what I am proposing is
>>that
>> there will be a release and a docs rc. This is what the splitting of
>> of the docs was about in my view,. Makes sense?
>>
>> If not, we should not try to make CCC Europe with 4.2.1. I think
>>this
>> is what the hurry is about
>>
>> Daan
>>
>> On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen
>>
>> wrote:
>>> I might be behind on the discussions here, but I will veto an RC
>>>that
>>> does not have list of bugs fixed and proper upgrade path documented
>>> (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the
>>>docs
>>>or
>>> not.
>>>
>>> Right now I see that the bugs fix list points to a jira filter.
>>>This
>>>is
>>> not consistent with the way it was done in prior releases (explicit
>>> listing) and in 4.2 (which pointed to the RN). We need consistency.
>>>What
>>> happens if someone changes this jira filter ?
>>>
>>> I also would like to see the results of the test matrix for 4.2.1
>>> running within jenkins.buildacloud.org.  This
>>> http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against
>>>master
>>> and has been failing for a while.
>>>
>>> PS: I did test it and did the usual smoke test
>>>
>>> so -1 (binding) at this time
>>>
>>> -sebastien
>>>
>>>
>>> On Nov 14, 2013, at 4:20 PM, Chip Childers
>>>
>>> wrote:
>>>

Unable to edit https://cwiki.apache.org/confluence/display/CLOUDSTACK/CCC+Europe#

[Sateesh Chodapuneedi]

Hi,

Looking to add hackathon entry over here 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CCC+Europe#
But unable to do so as it seems the wiki edit access permissions are not there.
Can you somebody give edit access to cwiki for user 'sateeshc' ?

Regards,
Sateesh

Re: [ASF4.2.1] Release Notes

[Abhinandan Prateek]

Ok, will make a exhaustive listing and see if it can be automated for
future releases.

On 15/11/13 6:41 pm, "Sebastien Goasguen"  wrote:

>
>On Nov 15, 2013, at 7:32 AM, Abhinandan Prateek
> wrote:
>
>> For listing down the fixed issues, since there are ~175 of these. I will
>> list down some important fixes.
>> Followed by the query to give a exhaustive list, is that acceptable ?
>> 
>
>I know jira has an api, so you could easily query jira and automatically
>write the list of fixed bugs in the CHANGES file.
>we should automate this:
>
import requests
import pprint
 
r=requests.get('https://issues.apache.org/jira/rest/api/2/filter/123257
07')
 
r=requests.get('https://issues.apache.org/jira/rest/api/2/search?jql=pr
oject+%3D+CLOUDSTACK+AND+type+%3D+Bug+AND+affectedVersion+in+(%224.2.0%
22,+%224.2%22)+AND+fixVersion+%3D+%224.2.1%22+AND+resolution+!%3D+%22%5
C%22Unresolved%5C%22%22+ORDER+BY+created+DESC,+priority+DESC,+key+ASC')
 pprint.pprint(r.json)
>
>The ideal process is really that when a bug gets resolved, the person who
>committed the patch to solve the bug should also update the CHANGES file.
>
>
>> For known issues will look at the 4.3/4.2 open tickets list down the
>> important ones.
>> 
>> This will go in the CHANGES in source repo and RN in code repo.
>> 
>> 
>> -abhi
>> 
>> On 15/11/13 5:54 pm, "Abhinandan Prateek"
>>
>> wrote:
>> 
>>> To address the concern of RN we will not conclude the vote on RC (i.e.
>>>Not
>>> make a release)
>>> till the RN in general and upgrade instructions in particular are also
>>>of
>>> acceptable quality.
>>> As for other inconsistencies will work towards ironing those out.
>>> 
>>> -abhi
>>> 
>>> On 15/11/13 3:30 pm, "Sebastien Goasguen"  wrote:
>>> 
 
 On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek
  wrote:
 
> As a RM I had agreed to Sebatian's suggestion of fixing the docs
> specially
> the upgrade section of it.
> And off course doing a GA after the docs are fixed is on the cards.
> 
> As for the list of fixed and known issues I was told that a filter is
> good
> enough but it should be pretty easy to get the listing in the docs
> itself.
> If someone has specific preferences it is easy to fix that.
> 
> So it boils down to get opinion from folks on the following:
> 
> 1. RC build, this does not contain docs. I have seen no complains or
> issues here.
 
 That's fine, but releasing something without the upgrade instructions
 committed is bad.
 Even if the release of such upgrade instructions happen after the
release
 of the code.
 
> 
> 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will
> think full listing is good or a query (instead of a URL?)
> 
 
 I am in favor of consistency. Prior to 4.2 we listed all BUGS
explicitly.
 We should keep doing that.
 
> 3. Upgrade instructions are known to be bad and we will have to wait
>at
> least till Wednesday to get these right.
>   We have some volunteers already working on those and their effort is
> highly appreciated.
 
 Right, and since there is no rush, why not wait a bit till we can all
 look this with cool heads, double check the RN, bugs listing, upgrade
 instructions etc...
 
> 
> -abhi
> 
> 
> On 15/11/13 2:50 pm, "Daan Hoogland"  wrote:
> 
>> So the -1 is because of the lack of rn and upgrade path docs,
>>right, I
>> think I proposed earlier this thread to release after the doc
>> hackathon privided that. I wasn't really explicit about it I think
>>as
>> no one commented on this strategy. Would that be acceptable to you
>>all
>> (especially David and Sebastien)?
>> 
>> I agree btw that docs must be available, but I don't think these
>>have
>> to be as stable as the release. We should allow for improving the
>>docs
>> on a release if needed. The net result of what I am proposing is
>>that
>> there will be a release and a docs rc. This is what the splitting of
>> of the docs was about in my view,. Makes sense?
>> 
>> If not, we should not try to make CCC Europe with 4.2.1. I think
>>this
>> is what the hurry is about
>> 
>> Daan
>> 
>> On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen
>>
>> wrote:
>>> I might be behind on the discussions here, but I will veto an RC
>>>that
>>> does not have list of bugs fixed and proper upgrade path documented
>>> (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the
>>>docs
>>> or
>>> not.
>>> 
>>> Right now I see that the bugs fix list points to a jira filter.
>>>This
>>> is
>>> not consistent with the way it was done in prior releases (explicit
>>> listing) and in 4.2 (which pointed to the RN). We need consistency.
>>> What
>>> happe

Review Request 15578: support to enable custom root disk size when using a template to deploy vm on xenserver.

[bharat kumar]

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

Review request for cloudstack and Koushik Das.


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


Repository: cloudstack-git


Description
---

support to enable custom root disk size when using a template to deploy vm on 
xenserver.


Diffs
-

  
engine/storage/datamotion/src/org/apache/cloudstack/storage/motion/AncientDataMotionStrategy.java
 67cc324 
  
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServerStorageProcessor.java
 5a19aee 

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


Testing
---

Tested on master.


Thanks,

bharat kumar

Re: Review Request 15489: Adding protocol parameter to loadbalancer response

[Murali Reddy]

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


Syed I dont think you added 'protocol' to createLoadBalancerRule. There should 
not be 'protocol' in the LoadBalancerContainer?

- Murali Reddy


On Nov. 13, 2013, 6:08 p.m., Syed Ahmed wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15489/
> ---
> 
> (Updated Nov. 13, 2013, 6:08 p.m.)
> 
> 
> Review request for cloudstack, Alena Prokharchyk and Murali Reddy.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Adding protocol parameter to Loadbalancer Response
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/rules/LoadBalancer.java e6dadca 
>   api/src/com/cloud/network/rules/LoadBalancerContainer.java 9d5ea59 
>   api/src/org/apache/cloudstack/api/response/LoadBalancerResponse.java 
> 0f18097 
>   
> engine/schema/src/org/apache/cloudstack/lb/ApplicationLoadBalancerRuleVO.java 
> 37a747e 
>   server/src/com/cloud/api/ApiResponseHelper.java 903c485 
> 
> Diff: https://reviews.apache.org/r/15489/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Syed Ahmed
> 
>

Re: CloudStack.next

[Sebastien Goasguen]

Hi, this is a bit of a brain dump:

I tend to see different types of buckets:

1-Processes
Involves getting better as a community in terms of release, bug fixing, 
committing code, documentation and user support. Some of these have already 
been discussed partially but we need to come to consensus and act.
For example:
-we should have no unanswered questions on the lists. Anyway to have an 
official volunteer support team ? With a 24/7 twilio number on the site that 
rings up someone out there :) ?
-we should catch up on bug fixing (and great job on 4.2.1 btw)
-when we commit we cannot break master, and I also would argue for committing 
docs when it's a new feature, right now master is a catch all, instead of a 
super stable, high quality branch.
-we need much better docs
-we need to define standards for releases: RN, changes file, upgrade paths, 
testing etc.
-our testing infra needs to get much better, continuous testing for all 
branches, testing on commits etc…maybe we should find a way to get help from 
cloudbees to get us on the right tracks. Overall we need to be able to release 
at any instant with confidence.
-no feature should be un-documented and/or un-tested. for instance: there was a 
recent complaint about lack of F5 documentation, and right now I have no clue 
who is testing the F5 integration.

2-Ecosystem
We need to build up the ecosystem around cloudstack and advertize it.
We integrate with almost everything out there, yet people don't know it. I wish 
that:
2.1 we would improve on support in existing software: all configuration mgt 
systems, main cloud libraries, PaaS etc...
2.2 work with everyone in that ecosystem to advertize and demo CloudStack 
integration
2.3 work on extending that ecosystem (e.g Docker support, Cloudfoundry, Mesos, 
Spark, OpenDaylight controller) some of it is just a matter of writing a 
tutorial, some of it there is actual coding involved.
2.4 restart effort on AWS: as mentioned IAM is needed but there is more, we 
need to catch with euca and integrate with netflixOSS software. Bring EMR, ELB, 
CloudWatch etc…I have plans to work on this and hopefully propose a standalone 
AWS-ACS bridge with extended services.

3-Code (caveat, I am not a java developer)
I still would love to see a lot of cleanup and review. For example I believe 
the KVM agent uses some python scripts in cloud-cli, those don't use Marvin. We 
should try to consolidate these. There is code in the tree that is unused, we 
should clean it up. In the UI when you add a cluster we still list 'OVM' yet 
it's broken, we need to clean. OStypes in image creation, we need to clean up...
Packaging and mavenization, we should finish that up and really make it super 
strong. We need to call out to maven and package experts for a hand.
We had a small thread on KVM agent and we will have a talk at the hackathon, 
here I will pick on Xen:
We need much better support for Xen_Project without using xapi (the xapi 
install on XP is a pain), without xapi we could easily have ARM / Ceph support…
Overall I would like to see a strong core emerge with clean code separation 
with UI, DB abstraction,  backend drivers and plugins. ( A bit pie in the sky, 
but a non java guy should be able to keep the core and replace/add any other 
component, plug and play)
Biggest item is probably a software architecture blueprint, right now we don't 
have that. No UML diagram, no sequence diagram, most people don't know how 
cloudstack actually works.

-seb (I will invest time on the ecosystem bucket)

On Nov 14, 2013, at 10:18 PM, Chiradeep Vittal  
wrote:

> +1 to IAM.
> 
> An Autoscale service independent of Netscaler.
> I'd like to see the built-in GRE controller fully fleshed out as a
> distributed/cross-AZ virtual network provider. Make it the out-of-the-box
> virtual network provider instead of VLAN.
> Easier service vm insertion into virtual networks.
> Better fidelity with AWS VPC APIs
> 
> 
> 
> 
> On 11/12/13 6:09 PM, "Simon Murphy"  wrote:
> 
>> As a CloudStack user, here are the ares that I feel need attention:
>> 
>> - improved IAM and implementation of a full RBAC security model. This is
>> hurting us right now.
>> - improved VM import functionality (ie bulk import of VM's and import of
>> running VM's from existing vSphere clusters)
>> - improved backup functionality and integration with 3rd party tools
>> - HA for VPC routers
>> 
>> Cheers,
>> Simon Murphy
>> Solutions Architect
>> 
>> ViFX | Cloud Infrastructure
>> Level 7, 57 Fort Street, Auckland, New Zealand 1010
>> PO Box 106700, Auckland, New Zealand 1143
>> M +64 21 285 4519 | S simon_a_murphy
>> www.vifx.co.nz  follow us on twitter
>> 
>> Auckland | Wellington | Christchurch
>> 
>> 
>> 
>> experience. expertise. execution.
>> 
>> This email and any files transmitted with it are confidential, without
>> prejudice and may contain information that is subject to legal privilege.
>> It is intended solely for the use of

Re: [ASF4.2.1] Release Notes

[Sebastien Goasguen]

On Nov 15, 2013, at 8:19 AM, Abhinandan Prateek  
wrote:

> Ok I will go that way till someone says that listing 175 tickets in
> CHANGES file will needlessly clutter it.
> Can we focus the list to blockers and criticals at least ?
> 

How was it done for 4.1.1 ?
all bugs or just blockers/citricals ?

I know listing 175 tickets seems like a lot, I am just arguing for consistency 
and automation.


> -abhi
> 
> On 15/11/13 6:34 pm, "Daan Hoogland"  wrote:
> 
>> Abihnandan,
>> 
>> Why not include the output of the query instead of the query? I think
>> this is what Sebastien means. A list of the important ones can still
>> be prepended in more readable form afaic.
>> 
>> Daan
>> 
>> On Fri, Nov 15, 2013 at 1:32 PM, Abhinandan Prateek
>>  wrote:
>>> For listing down the fixed issues, since there are ~175 of these. I will
>>> list down some important fixes.
>>> Followed by the query to give a exhaustive list, is that acceptable ?
>>> 
>>> For known issues will look at the 4.3/4.2 open tickets list down the
>>> important ones.
>>> 
>>> This will go in the CHANGES in source repo and RN in code repo.
>>> 
>>> 
>>> -abhi
>>> 
>>> On 15/11/13 5:54 pm, "Abhinandan Prateek"
>>> 
>>> wrote:
>>> 
 To address the concern of RN we will not conclude the vote on RC (i.e.
 Not
 make a release)
 till the RN in general and upgrade instructions in particular are also
 of
 acceptable quality.
 As for other inconsistencies will work towards ironing those out.
 
 -abhi
 
 On 15/11/13 3:30 pm, "Sebastien Goasguen"  wrote:
 
> 
> On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek
>  wrote:
> 
>> As a RM I had agreed to Sebatian's suggestion of fixing the docs
>> specially
>> the upgrade section of it.
>> And off course doing a GA after the docs are fixed is on the cards.
>> 
>> As for the list of fixed and known issues I was told that a filter is
>> good
>> enough but it should be pretty easy to get the listing in the docs
>> itself.
>> If someone has specific preferences it is easy to fix that.
>> 
>> So it boils down to get opinion from folks on the following:
>> 
>> 1. RC build, this does not contain docs. I have seen no complains or
>> issues here.
> 
> That's fine, but releasing something without the upgrade instructions
> committed is bad.
> Even if the release of such upgrade instructions happen after the
> release
> of the code.
> 
>> 
>> 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will
>> think full listing is good or a query (instead of a URL?)
>> 
> 
> I am in favor of consistency. Prior to 4.2 we listed all BUGS
> explicitly.
> We should keep doing that.
> 
>> 3. Upgrade instructions are known to be bad and we will have to wait
>> at
>> least till Wednesday to get these right.
>>We have some volunteers already working on those and their
>> effort is
>> highly appreciated.
> 
> Right, and since there is no rush, why not wait a bit till we can all
> look this with cool heads, double check the RN, bugs listing, upgrade
> instructions etc...
> 
>> 
>> -abhi
>> 
>> 
>> On 15/11/13 2:50 pm, "Daan Hoogland"  wrote:
>> 
>>> So the -1 is because of the lack of rn and upgrade path docs,
>>> right, I
>>> think I proposed earlier this thread to release after the doc
>>> hackathon privided that. I wasn't really explicit about it I think
>>> as
>>> no one commented on this strategy. Would that be acceptable to you
>>> all
>>> (especially David and Sebastien)?
>>> 
>>> I agree btw that docs must be available, but I don't think these
>>> have
>>> to be as stable as the release. We should allow for improving the
>>> docs
>>> on a release if needed. The net result of what I am proposing is
>>> that
>>> there will be a release and a docs rc. This is what the splitting of
>>> of the docs was about in my view,. Makes sense?
>>> 
>>> If not, we should not try to make CCC Europe with 4.2.1. I think
>>> this
>>> is what the hurry is about
>>> 
>>> Daan
>>> 
>>> On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen
>>> 
>>> wrote:
 I might be behind on the discussions here, but I will veto an RC
 that
 does not have list of bugs fixed and proper upgrade path documented
 (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the
 docs
 or
 not.
 
 Right now I see that the bugs fix list points to a jira filter.
 This
 is
 not consistent with the way it was done in prior releases (explicit
 listing) and in 4.2 (which pointed to the RN). We need consistency.
 What
 happens if someone changes this jira filter ?
 
 I also would like 

Re: [ASF4.2.1] Release Notes

[Chip Childers]

IMO, we should kill the CHAGES file and just get the release notes
document under control.  I'm fine if "Changes" is in bad shape for
this release personally, as long as the release notes are accurate.

Another thought to remind folks about in this thread:

Changes to the cloudstack.git repo's 4.2 branch that we want to be in
the 4.2.1 release will cause a re-spin and re-vote.

Changes to the documentation repo have nothing to do with the release
vote, except that we (as a community) seem to agree that our docs
should be at least updated and pushed to the website *before*
announcing 4.2.1.

Make sense?



On Fri, Nov 15, 2013 at 8:19 AM, Abhinandan Prateek
 wrote:
> Ok I will go that way till someone says that listing 175 tickets in
> CHANGES file will needlessly clutter it.
> Can we focus the list to blockers and criticals at least ?
>
> -abhi
>
> On 15/11/13 6:34 pm, "Daan Hoogland"  wrote:
>
>>Abihnandan,
>>
>>Why not include the output of the query instead of the query? I think
>>this is what Sebastien means. A list of the important ones can still
>>be prepended in more readable form afaic.
>>
>>Daan
>>
>>On Fri, Nov 15, 2013 at 1:32 PM, Abhinandan Prateek
>> wrote:
>>> For listing down the fixed issues, since there are ~175 of these. I will
>>> list down some important fixes.
>>> Followed by the query to give a exhaustive list, is that acceptable ?
>>>
>>> For known issues will look at the 4.3/4.2 open tickets list down the
>>> important ones.
>>>
>>> This will go in the CHANGES in source repo and RN in code repo.
>>>
>>>
>>> -abhi
>>>
>>> On 15/11/13 5:54 pm, "Abhinandan Prateek"
>>>
>>> wrote:
>>>
To address the concern of RN we will not conclude the vote on RC (i.e.
Not
make a release)
till the RN in general and upgrade instructions in particular are also
of
acceptable quality.
As for other inconsistencies will work towards ironing those out.

-abhi

On 15/11/13 3:30 pm, "Sebastien Goasguen"  wrote:

>
>On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek
> wrote:
>
>> As a RM I had agreed to Sebatian's suggestion of fixing the docs
>>specially
>> the upgrade section of it.
>> And off course doing a GA after the docs are fixed is on the cards.
>>
>> As for the list of fixed and known issues I was told that a filter is
>>good
>> enough but it should be pretty easy to get the listing in the docs
>>itself.
>> If someone has specific preferences it is easy to fix that.
>>
>> So it boils down to get opinion from folks on the following:
>>
>> 1. RC build, this does not contain docs. I have seen no complains or
>> issues here.
>
>That's fine, but releasing something without the upgrade instructions
>committed is bad.
>Even if the release of such upgrade instructions happen after the
>release
>of the code.
>
>>
>> 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will
>> think full listing is good or a query (instead of a URL?)
>>
>
>I am in favor of consistency. Prior to 4.2 we listed all BUGS
>explicitly.
>We should keep doing that.
>
>> 3. Upgrade instructions are known to be bad and we will have to wait
>>at
>> least till Wednesday to get these right.
>> We have some volunteers already working on those and their
>>effort is
>> highly appreciated.
>
>Right, and since there is no rush, why not wait a bit till we can all
>look this with cool heads, double check the RN, bugs listing, upgrade
>instructions etc...
>
>>
>> -abhi
>>
>>
>> On 15/11/13 2:50 pm, "Daan Hoogland"  wrote:
>>
>>> So the -1 is because of the lack of rn and upgrade path docs,
>>>right, I
>>> think I proposed earlier this thread to release after the doc
>>> hackathon privided that. I wasn't really explicit about it I think
>>>as
>>> no one commented on this strategy. Would that be acceptable to you
>>>all
>>> (especially David and Sebastien)?
>>>
>>> I agree btw that docs must be available, but I don't think these
>>>have
>>> to be as stable as the release. We should allow for improving the
>>>docs
>>> on a release if needed. The net result of what I am proposing is
>>>that
>>> there will be a release and a docs rc. This is what the splitting of
>>> of the docs was about in my view,. Makes sense?
>>>
>>> If not, we should not try to make CCC Europe with 4.2.1. I think
>>>this
>>> is what the hurry is about
>>>
>>> Daan
>>>
>>> On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen
>>>
>>> wrote:
 I might be behind on the discussions here, but I will veto an RC
that
 does not have list of bugs fixed and proper upgrade path documented
 (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the
docs
or
 not.
>>

Re: [ASF4.2.1] Release Notes

[Daan Hoogland]

×2

mobile biligual spell checker used
Op 15 nov. 2013 15:27 schreef "Chip Childers" :

> IMO, we should kill the CHAGES file and just get the release notes
> document under control.  I'm fine if "Changes" is in bad shape for
> this release personally, as long as the release notes are accurate.
>
> Another thought to remind folks about in this thread:
>
> Changes to the cloudstack.git repo's 4.2 branch that we want to be in
> the 4.2.1 release will cause a re-spin and re-vote.
>
> Changes to the documentation repo have nothing to do with the release
> vote, except that we (as a community) seem to agree that our docs
> should be at least updated and pushed to the website *before*
> announcing 4.2.1.
>
> Make sense?
>
>
>
> On Fri, Nov 15, 2013 at 8:19 AM, Abhinandan Prateek
>  wrote:
> > Ok I will go that way till someone says that listing 175 tickets in
> > CHANGES file will needlessly clutter it.
> > Can we focus the list to blockers and criticals at least ?
> >
> > -abhi
> >
> > On 15/11/13 6:34 pm, "Daan Hoogland"  wrote:
> >
> >>Abihnandan,
> >>
> >>Why not include the output of the query instead of the query? I think
> >>this is what Sebastien means. A list of the important ones can still
> >>be prepended in more readable form afaic.
> >>
> >>Daan
> >>
> >>On Fri, Nov 15, 2013 at 1:32 PM, Abhinandan Prateek
> >> wrote:
> >>> For listing down the fixed issues, since there are ~175 of these. I
> will
> >>> list down some important fixes.
> >>> Followed by the query to give a exhaustive list, is that acceptable ?
> >>>
> >>> For known issues will look at the 4.3/4.2 open tickets list down the
> >>> important ones.
> >>>
> >>> This will go in the CHANGES in source repo and RN in code repo.
> >>>
> >>>
> >>> -abhi
> >>>
> >>> On 15/11/13 5:54 pm, "Abhinandan Prateek"
> >>>
> >>> wrote:
> >>>
> To address the concern of RN we will not conclude the vote on RC (i.e.
> Not
> make a release)
> till the RN in general and upgrade instructions in particular are also
> of
> acceptable quality.
> As for other inconsistencies will work towards ironing those out.
> 
> -abhi
> 
> On 15/11/13 3:30 pm, "Sebastien Goasguen"  wrote:
> 
> >
> >On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek
> > wrote:
> >
> >> As a RM I had agreed to Sebatian's suggestion of fixing the docs
> >>specially
> >> the upgrade section of it.
> >> And off course doing a GA after the docs are fixed is on the cards.
> >>
> >> As for the list of fixed and known issues I was told that a filter
> is
> >>good
> >> enough but it should be pretty easy to get the listing in the docs
> >>itself.
> >> If someone has specific preferences it is easy to fix that.
> >>
> >> So it boils down to get opinion from folks on the following:
> >>
> >> 1. RC build, this does not contain docs. I have seen no complains or
> >> issues here.
> >
> >That's fine, but releasing something without the upgrade instructions
> >committed is bad.
> >Even if the release of such upgrade instructions happen after the
> >release
> >of the code.
> >
> >>
> >> 2. Putting a full listing of bug fixes in RN Vs a filter. Even I
> will
> >> think full listing is good or a query (instead of a URL?)
> >>
> >
> >I am in favor of consistency. Prior to 4.2 we listed all BUGS
> >explicitly.
> >We should keep doing that.
> >
> >> 3. Upgrade instructions are known to be bad and we will have to wait
> >>at
> >> least till Wednesday to get these right.
> >> We have some volunteers already working on those and their
> >>effort is
> >> highly appreciated.
> >
> >Right, and since there is no rush, why not wait a bit till we can all
> >look this with cool heads, double check the RN, bugs listing, upgrade
> >instructions etc...
> >
> >>
> >> -abhi
> >>
> >>
> >> On 15/11/13 2:50 pm, "Daan Hoogland" 
> wrote:
> >>
> >>> So the -1 is because of the lack of rn and upgrade path docs,
> >>>right, I
> >>> think I proposed earlier this thread to release after the doc
> >>> hackathon privided that. I wasn't really explicit about it I think
> >>>as
> >>> no one commented on this strategy. Would that be acceptable to you
> >>>all
> >>> (especially David and Sebastien)?
> >>>
> >>> I agree btw that docs must be available, but I don't think these
> >>>have
> >>> to be as stable as the release. We should allow for improving the
> >>>docs
> >>> on a release if needed. The net result of what I am proposing is
> >>>that
> >>> there will be a release and a docs rc. This is what the splitting
> of
> >>> of the docs was about in my view,. Makes sense?
> >>>
> >>> If not, we should not try to make CCC Europe with 4.2.1. I think
> >>>this
> >>> is what the hurry is about
> >>>
> >>> D

Re: [ASF4.2.1] Release Notes

[David Nalley]

Yes - it's hard to maintain, and it's yet another place to point
people to. Let's deprecate it in favor of decent RN.

--David

On Fri, Nov 15, 2013 at 9:27 AM, Chip Childers  wrote:
> IMO, we should kill the CHAGES file and just get the release notes
> document under control.  I'm fine if "Changes" is in bad shape for
> this release personally, as long as the release notes are accurate.
>
> Another thought to remind folks about in this thread:
>
> Changes to the cloudstack.git repo's 4.2 branch that we want to be in
> the 4.2.1 release will cause a re-spin and re-vote.
>
> Changes to the documentation repo have nothing to do with the release
> vote, except that we (as a community) seem to agree that our docs
> should be at least updated and pushed to the website *before*
> announcing 4.2.1.
>
> Make sense?
>
>
>
> On Fri, Nov 15, 2013 at 8:19 AM, Abhinandan Prateek
>  wrote:
>> Ok I will go that way till someone says that listing 175 tickets in
>> CHANGES file will needlessly clutter it.
>> Can we focus the list to blockers and criticals at least ?
>>
>> -abhi
>>
>> On 15/11/13 6:34 pm, "Daan Hoogland"  wrote:
>>
>>>Abihnandan,
>>>
>>>Why not include the output of the query instead of the query? I think
>>>this is what Sebastien means. A list of the important ones can still
>>>be prepended in more readable form afaic.
>>>
>>>Daan
>>>
>>>On Fri, Nov 15, 2013 at 1:32 PM, Abhinandan Prateek
>>> wrote:
 For listing down the fixed issues, since there are ~175 of these. I will
 list down some important fixes.
 Followed by the query to give a exhaustive list, is that acceptable ?

 For known issues will look at the 4.3/4.2 open tickets list down the
 important ones.

 This will go in the CHANGES in source repo and RN in code repo.


 -abhi

 On 15/11/13 5:54 pm, "Abhinandan Prateek"

 wrote:

>To address the concern of RN we will not conclude the vote on RC (i.e.
>Not
>make a release)
>till the RN in general and upgrade instructions in particular are also
>of
>acceptable quality.
>As for other inconsistencies will work towards ironing those out.
>
>-abhi
>
>On 15/11/13 3:30 pm, "Sebastien Goasguen"  wrote:
>
>>
>>On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek
>> wrote:
>>
>>> As a RM I had agreed to Sebatian's suggestion of fixing the docs
>>>specially
>>> the upgrade section of it.
>>> And off course doing a GA after the docs are fixed is on the cards.
>>>
>>> As for the list of fixed and known issues I was told that a filter is
>>>good
>>> enough but it should be pretty easy to get the listing in the docs
>>>itself.
>>> If someone has specific preferences it is easy to fix that.
>>>
>>> So it boils down to get opinion from folks on the following:
>>>
>>> 1. RC build, this does not contain docs. I have seen no complains or
>>> issues here.
>>
>>That's fine, but releasing something without the upgrade instructions
>>committed is bad.
>>Even if the release of such upgrade instructions happen after the
>>release
>>of the code.
>>
>>>
>>> 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will
>>> think full listing is good or a query (instead of a URL?)
>>>
>>
>>I am in favor of consistency. Prior to 4.2 we listed all BUGS
>>explicitly.
>>We should keep doing that.
>>
>>> 3. Upgrade instructions are known to be bad and we will have to wait
>>>at
>>> least till Wednesday to get these right.
>>> We have some volunteers already working on those and their
>>>effort is
>>> highly appreciated.
>>
>>Right, and since there is no rush, why not wait a bit till we can all
>>look this with cool heads, double check the RN, bugs listing, upgrade
>>instructions etc...
>>
>>>
>>> -abhi
>>>
>>>
>>> On 15/11/13 2:50 pm, "Daan Hoogland"  wrote:
>>>
 So the -1 is because of the lack of rn and upgrade path docs,
right, I
 think I proposed earlier this thread to release after the doc
 hackathon privided that. I wasn't really explicit about it I think
as
 no one commented on this strategy. Would that be acceptable to you
all
 (especially David and Sebastien)?

 I agree btw that docs must be available, but I don't think these
have
 to be as stable as the release. We should allow for improving the
docs
 on a release if needed. The net result of what I am proposing is
that
 there will be a release and a docs rc. This is what the splitting of
 of the docs was about in my view,. Makes sense?

 If not, we should not try to make CCC Europe with 4.2.1. I think
this
 is what the hurry is about

 Daan

 On Fri, Nov 15

Re: Unable to edit https://cwiki.apache.org/confluence/display/CLOUDSTACK/CCC+Europe#

[Chip Childers]

done

On Fri, Nov 15, 2013 at 8:18 AM, Sateesh Chodapuneedi
 wrote:
> Hi,
>
> Looking to add hackathon entry over here 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CCC+Europe#
> But unable to do so as it seems the wiki edit access permissions are not 
> there.
> Can you somebody give edit access to cwiki for user 'sateeshc' ?
>
> Regards,
> Sateesh
>

Re: 4.3 System VM Templates

[Will Stevens]

Bump...  Still trying to find system vm templates for 4.3.  Are they
generated somewhere when I do a clean install and I can manually put them
on secondary storage?  If not, is there a publicly accessible URL where I
can get the 4.3 system vm templates for 4.3?

Thanks...


On Thu, Nov 14, 2013 at 5:01 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> On a related note, when does the vm_template table in the DB get updated
> with the new paths?
>
>
> On Thu, Nov 14, 2013 at 2:51 PM, Will Stevens 
> wrote:
>
> > Where are these located?  The path shown in the docs does not resolve for
> > me.
> >
> > Doc:
> >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+CloudStack
> >
> > Path: http://
> >
> >
> jenkins.cloudstack.org/view/master/job/build-systemvm-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvmtemplate-2013-08-29-master-xen.vhd.bz2
> >
> > 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: Review Request 15489: Adding protocol parameter to loadbalancer response

[Syed Ahmed]

> On Nov. 15, 2013, 1:53 p.m., Murali Reddy wrote:
> > Syed I dont think you added 'protocol' to createLoadBalancerRule. There 
> > should not be 'protocol' in the LoadBalancerContainer?

I actually did add the 'protocol' parameter to createLoadBalancerRule. This 
maps to `lb_protocol` field in the `load_balancing_rules` table. 

I added getLbProtocol() to LoabalacnerContainer because I thought that is the 
right palce as other parameters like algorithm ( getAlgorithm() ) scheme etc 
are present here. 

Does this sound correct?


- Syed


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


On Nov. 13, 2013, 6:08 p.m., Syed Ahmed wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15489/
> ---
> 
> (Updated Nov. 13, 2013, 6:08 p.m.)
> 
> 
> Review request for cloudstack, Alena Prokharchyk and Murali Reddy.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Adding protocol parameter to Loadbalancer Response
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/rules/LoadBalancer.java e6dadca 
>   api/src/com/cloud/network/rules/LoadBalancerContainer.java 9d5ea59 
>   api/src/org/apache/cloudstack/api/response/LoadBalancerResponse.java 
> 0f18097 
>   
> engine/schema/src/org/apache/cloudstack/lb/ApplicationLoadBalancerRuleVO.java 
> 37a747e 
>   server/src/com/cloud/api/ApiResponseHelper.java 903c485 
> 
> Diff: https://reviews.apache.org/r/15489/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Syed Ahmed
> 
>

Re: Review Request 15489: Adding protocol parameter to loadbalancer response

[Alena Prokharchyk]

Syed, that sounds correct to me. Container should have the properties 
algorithm, protocol, public Ip, etc. While LoadBalancer represents only the 
rule itself (the port combination)

-Alena.

From: Syed Ahmed mailto:sah...@cloudops.com>>
Reply-To: Syed Ahmed mailto:sah...@cloudops.com>>
Date: Friday, November 15, 2013 9:21 AM
To: Murali Reddy mailto:muralimmre...@gmail.com>>, 
Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Cc: Syed Ahmed mailto:sah...@cloudops.com>>, cloudstack 
mailto:dev@cloudstack.apache.org>>
Subject: Re: Review Request 15489: Adding protocol parameter to loadbalancer 
response

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


On November 15th, 2013, 1:53 p.m. UTC, Murali Reddy wrote:

Syed I dont think you added 'protocol' to createLoadBalancerRule. There should 
not be 'protocol' in the LoadBalancerContainer?

I actually did add the 'protocol' parameter to createLoadBalancerRule. This 
maps to `lb_protocol` field in the `load_balancing_rules` table.

I added getLbProtocol() to LoabalacnerContainer because I thought that is the 
right palce as other parameters like algorithm ( getAlgorithm() ) scheme etc 
are present here.

Does this sound correct?


- Syed


On November 13th, 2013, 6:08 p.m. UTC, Syed Ahmed wrote:

Review request for cloudstack, Alena Prokharchyk and Murali Reddy.
By Syed Ahmed.

Updated Nov. 13, 2013, 6:08 p.m.

Repository: cloudstack-git
Description

Adding protocol parameter to Loadbalancer Response


Diffs

  *   api/src/com/cloud/network/rules/LoadBalancer.java (e6dadca)
  *   api/src/com/cloud/network/rules/LoadBalancerContainer.java (9d5ea59)
  *   api/src/org/apache/cloudstack/api/response/LoadBalancerResponse.java 
(0f18097)
  *   
engine/schema/src/org/apache/cloudstack/lb/ApplicationLoadBalancerRuleVO.java 
(37a747e)
  *   server/src/com/cloud/api/ApiResponseHelper.java (903c485)

View Diff

Re: Review Request 15489: Adding protocol parameter to loadbalancer response

[Alena Prokharchyk]

> On Nov. 15, 2013, 1:53 p.m., Murali Reddy wrote:
> > Syed I dont think you added 'protocol' to createLoadBalancerRule. There 
> > should not be 'protocol' in the LoadBalancerContainer?
> 
> Syed Ahmed wrote:
> I actually did add the 'protocol' parameter to createLoadBalancerRule. 
> This maps to `lb_protocol` field in the `load_balancing_rules` table. 
> 
> I added getLbProtocol() to LoabalacnerContainer because I thought that is 
> the right palce as other parameters like algorithm ( getAlgorithm() ) scheme 
> etc are present here. 
> 
> Does this sound correct?

Syed, that sounds correct to me. Container should have the properties 
algorithm, protocol, public Ip, etc. While LoadBalancer represents only the 
rule itself (the port combination)


- Alena


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


On Nov. 13, 2013, 6:08 p.m., Syed Ahmed wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15489/
> ---
> 
> (Updated Nov. 13, 2013, 6:08 p.m.)
> 
> 
> Review request for cloudstack, Alena Prokharchyk and Murali Reddy.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Adding protocol parameter to Loadbalancer Response
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/rules/LoadBalancer.java e6dadca 
>   api/src/com/cloud/network/rules/LoadBalancerContainer.java 9d5ea59 
>   api/src/org/apache/cloudstack/api/response/LoadBalancerResponse.java 
> 0f18097 
>   
> engine/schema/src/org/apache/cloudstack/lb/ApplicationLoadBalancerRuleVO.java 
> 37a747e 
>   server/src/com/cloud/api/ApiResponseHelper.java 903c485 
> 
> Diff: https://reviews.apache.org/r/15489/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Syed Ahmed
> 
>

Re: Coverage Analysis: Few Issues

[Will Stevens]

I have looked into this briefly.  It appears that these commands are not
needed, so I will remove them and only keep the Palo Alto specific commands.

addPaloAltoFirewall=1
deletePaloAltoFirewall=1
configurePaloAltoFirewall=1
listPaloAltoFirewalls=1
listPaloAltoFirewallNetworks=1

Cheers,

Will




On Thu, Nov 14, 2013 at 11:49 PM, Will Stevens wrote:

> Yes, I will look into the naming of the API commands in the Palo Alto
> plugin.  When you say 'they are supposed to be merged as one command', what
> do you mean?
>
> These were the commands that I exposed.
>
>    Palo Alto firewall commands
>  addExternalFirewall=1
>  deleteExternalFirewall=1
>  listExternalFirewalls=1
>
> addPaloAltoFirewall=1
>  deletePaloAltoFirewall=1
>  configurePaloAltoFirewall=1
>  listPaloAltoFirewalls=1
>  listPaloAltoFirewallNetworks=1
>
> When I started working on this I was using the SRX as a model as it was
> the only documentation I had at the time.  I was under the impression that
> I was supposed to override those commands.  Once I got things working I did
> not go back over this, so I am sure I can improve this aspect of the plugin.
>
> Thanks,
>
> Will
>
>
>
>
> On Thu, Nov 14, 2013 at 9:01 PM, Sheng Yang  wrote:
>
>> Hi Will,
>>
>> Could you check on Palo Alto's duplicate api commands? They suppose to be
>> merged as one command I think.
>>
>> BTW, how can this works? Did it broke SRX?
>>
>> --Sheng
>>
>>
>> On Thu, Nov 14, 2013 at 2:55 AM, Santhosh Edukulla <
>> santhosh.eduku...@citrix.com> wrote:
>>
>>> Team,
>>>
>>> While running code coverage analysis with sonar for integration tests,
>>> based upon the errors thrown, i could see the below issues\notes with CS
>>> project.
>>>
>>> Issue1:
>>>
>>> The coverage tool is complaining about duplicate sources  for below
>>> files. These are available with same name under folders
>>> ./cloudstack/plugins/network-elements/juniper-srx and as well under
>>> /palo-alto.
>>>
>>>
>>> ./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/AddExternalFirewallCmd.java
>>>
>>> ./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/DeleteExternalFirewallCmd.java
>>>
>>> ./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/ListExternalFirewallCmd.java
>>>
>>> I renamed one while running analysis to a different name.  It proceeded
>>> further with its analysis once renamed.
>>>
>>> Is it intentional to have same name or can be renamed?
>>>
>>> Issue2:
>>>
>>> The source directory does not correspond to package declaration for
>>>  code files under
>>>
>>> /root/softwares/cscode/cloudstack/services/console-proxy-rdp/rdpconsole/src/main/java/rdpclient/
>>>
>>> This error when compared to other files in the similar path has a
>>> different package convention and usage.
>>>
>>> /root/softwares/cscode/cloudstack/services/secondary-storage/src/org/apache/cloudstack/storage/
>>>
>>> Changing tool configuration properties worked to over come this, but Is
>>> it intentional to have a different package structure for rdpclient code
>>> base against others?
>>>
>>>
>>>
>>> Thanks!
>>> Santhosh
>>>
>>
>>
>

Request: Help designing a 'powered by' logo for CloudStack

[David Nalley]

Hi folks:

If you happen to have some graphical design talent (I have none) I
have a great opportunity for you :)

CloudStack needs a 'powered by' logo that is easy to consume, and is
also attractive.

A couple examples of powered by logos:

http://tomcat.apache.org/images/tomcat-power.gif
https://cwiki.apache.org/confluence/download/attachments/80899/mahout-logo-poweredby-100.png?version=1&modificationDate=1312880703000
https://netbeans.org/images_www/screenshots/6.0/baseIDE_ant_powered_150px.png

A couple of constraints:
* Please don't use the Apache feather. (we could, but lets not; it
will make life simpler)
* Please try and produce a vector format as source (this allows us to
scale/etc)
* Because this will become a trademark (which is vastly different that
copyright) - we will likely need some explicit email agreement around
trademarks rights for the image. (I promise, it isn't as scary as that
sentence makes it out to be.)

Anyone interested?

--David

RE: [ASF4.2.1] Release Notes

[Animesh Chaturvedi]

-Original Message-
From: Chip Childers [mailto:chipchild...@apache.org] 
Sent: Friday, November 15, 2013 6:28 AM
To: dev@cloudstack.apache.org
Subject: Re: [ASF4.2.1] Release Notes

IMO, we should kill the CHAGES file and just get the release notes document 
under control.  I'm fine if "Changes" is in bad shape for this release 
personally, as long as the release notes are accurate.

Animesh> Yes we followed the same approach for 4.2 as I was pointed out to me 
that there was a prior discussion on keeping things in release notes. I had 
added link to JIRA filter for known issues and fixed issues [1].  

Another thought to remind folks about in this thread:

Changes to the cloudstack.git repo's 4.2 branch that we want to be in the 4.2.1 
release will cause a re-spin and re-vote.

Changes to the documentation repo have nothing to do with the release vote, 
except that we (as a community) seem to agree that our docs should be at least 
updated and pushed to the website *before* announcing 4.2.1.

Make sense?

Animesh> Yes thanks for calling it out clearly. I will update the Release 
Management page on wiki for future reference.

[1] http://markmail.org/message/rkzzyg5i26mshpbt


On Fri, Nov 15, 2013 at 8:19 AM, Abhinandan Prateek 
 wrote:
> Ok I will go that way till someone says that listing 175 tickets in 
> CHANGES file will needlessly clutter it.
> Can we focus the list to blockers and criticals at least ?
>
> -abhi
>
> On 15/11/13 6:34 pm, "Daan Hoogland"  wrote:
>
>>Abihnandan,
>>
>>Why not include the output of the query instead of the query? I think 
>>this is what Sebastien means. A list of the important ones can still 
>>be prepended in more readable form afaic.
>>
>>Daan
>>
>>On Fri, Nov 15, 2013 at 1:32 PM, Abhinandan Prateek 
>> wrote:
>>> For listing down the fixed issues, since there are ~175 of these. I 
>>> will list down some important fixes.
>>> Followed by the query to give a exhaustive list, is that acceptable ?
>>>
>>> For known issues will look at the 4.3/4.2 open tickets list down the 
>>> important ones.
>>>
>>> This will go in the CHANGES in source repo and RN in code repo.
>>>
>>>
>>> -abhi
>>>
>>> On 15/11/13 5:54 pm, "Abhinandan Prateek"
>>>
>>> wrote:
>>>
To address the concern of RN we will not conclude the vote on RC (i.e.
Not
make a release)
till the RN in general and upgrade instructions in particular are 
also of acceptable quality.
As for other inconsistencies will work towards ironing those out.

-abhi

On 15/11/13 3:30 pm, "Sebastien Goasguen"  wrote:

>
>On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek 
> wrote:
>
>> As a RM I had agreed to Sebatian's suggestion of fixing the docs 
>>specially  the upgrade section of it.
>> And off course doing a GA after the docs are fixed is on the cards.
>>
>> As for the list of fixed and known issues I was told that a 
>>filter is good  enough but it should be pretty easy to get the 
>>listing in the docs itself.
>> If someone has specific preferences it is easy to fix that.
>>
>> So it boils down to get opinion from folks on the following:
>>
>> 1. RC build, this does not contain docs. I have seen no complains 
>> or issues here.
>
>That's fine, but releasing something without the upgrade 
>instructions committed is bad.
>Even if the release of such upgrade instructions happen after the 
>release of the code.
>
>>
>> 2. Putting a full listing of bug fixes in RN Vs a filter. Even I 
>> will think full listing is good or a query (instead of a URL?)
>>
>
>I am in favor of consistency. Prior to 4.2 we listed all BUGS 
>explicitly.
>We should keep doing that.
>
>> 3. Upgrade instructions are known to be bad and we will have to 
>>wait at  least till Wednesday to get these right.
>> We have some volunteers already working on those and their 
>>effort is  highly appreciated.
>
>Right, and since there is no rush, why not wait a bit till we can 
>all look this with cool heads, double check the RN, bugs listing, 
>upgrade instructions etc...
>
>>
>> -abhi
>>
>>
>> On 15/11/13 2:50 pm, "Daan Hoogland"  wrote:
>>
>>> So the -1 is because of the lack of rn and upgrade path docs, 
>>>right, I  think I proposed earlier this thread to release after 
>>>the doc  hackathon privided that. I wasn't really explicit about 
>>>it I think as  no one commented on this strategy. Would that be 
>>>acceptable to you all  (especially David and Sebastien)?
>>>
>>> I agree btw that docs must be available, but I don't think these 
>>>have  to be as stable as the release. We should allow for 
>>>improving the docs  on a release if needed. The net result of 
>>>what I am proposing is that  there will be a release and a docs 
>>>rc. This is what the splitting of  of the docs was abou

Re: Request: Help designing a 'powered by' logo for CloudStack

[Kelly Hair]

May have deleted the thread but wasn¹t this being covered off earlier in
@marketing or is this a new request?





On 11/15/13, 12:56 PM, "David Nalley"  wrote:

>Hi folks:
>
>If you happen to have some graphical design talent (I have none) I
>have a great opportunity for you :)
>
>CloudStack needs a 'powered by' logo that is easy to consume, and is
>also attractive.
>
>A couple examples of powered by logos:
>
>http://tomcat.apache.org/images/tomcat-power.gif
>https://cwiki.apache.org/confluence/download/attachments/80899/mahout-logo
>-poweredby-100.png?version=1&modificationDate=1312880703000
>https://netbeans.org/images_www/screenshots/6.0/baseIDE_ant_powered_150px.
>png
>
>A couple of constraints:
>* Please don't use the Apache feather. (we could, but lets not; it
>will make life simpler)
>* Please try and produce a vector format as source (this allows us to
>scale/etc)
>* Because this will become a trademark (which is vastly different that
>copyright) - we will likely need some explicit email agreement around
>trademarks rights for the image. (I promise, it isn't as scary as that
>sentence makes it out to be.)
>
>Anyone interested?
>
>--David

Re: 4.3 System VM Templates

[Syed Ahmed]

I found

http://jenkins.buildacloud.org/view/master/job/build-systemvm-master/lastSuccessfulBuild/artifact/tools/appliance/dist/

Let me know if this is valid. I'll update the wiki

Thanks,
-Syed


On Fri 15 Nov 2013 12:03:16 PM EST, Will Stevens wrote:

Bump...  Still trying to find system vm templates for 4.3.  Are they
generated somewhere when I do a clean install and I can manually put them
on secondary storage?  If not, is there a publicly accessible URL where I
can get the 4.3 system vm templates for 4.3?

Thanks...


On Thu, Nov 14, 2013 at 5:01 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:


On a related note, when does the vm_template table in the DB get updated
with the new paths?


On Thu, Nov 14, 2013 at 2:51 PM, Will Stevens 
wrote:


Where are these located?  The path shown in the docs does not resolve for
me.

Doc:



https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+CloudStack


Path: http://



jenkins.cloudstack.org/view/master/job/build-systemvm-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvmtemplate-2013-08-29-master-xen.vhd.bz2


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: 4.3 System VM Templates

[Will Stevens]

Thanks Syed.  I will test them.


On Fri, Nov 15, 2013 at 1:28 PM, Syed Ahmed  wrote:

> I found
>
> http://jenkins.buildacloud.org/view/master/job/build-systemvm-master/
> lastSuccessfulBuild/artifact/tools/appliance/dist/
>
> Let me know if this is valid. I'll update the wiki
>
> Thanks,
> -Syed
>
>
>
> On Fri 15 Nov 2013 12:03:16 PM EST, Will Stevens wrote:
>
>> Bump...  Still trying to find system vm templates for 4.3.  Are they
>> generated somewhere when I do a clean install and I can manually put them
>> on secondary storage?  If not, is there a publicly accessible URL where I
>> can get the 4.3 system vm templates for 4.3?
>>
>> Thanks...
>>
>>
>> On Thu, Nov 14, 2013 at 5:01 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>>  On a related note, when does the vm_template table in the DB get updated
>>> with the new paths?
>>>
>>>
>>> On Thu, Nov 14, 2013 at 2:51 PM, Will Stevens 
>>> wrote:
>>>
>>>  Where are these located?  The path shown in the docs does not resolve
 for
 me.

 Doc:


  https://cwiki.apache.org/confluence/display/CLOUDSTACK/
>>> How+to+build+CloudStack
>>>

 Path: http://


  jenkins.cloudstack.org/view/master/job/build-systemvm-
>>> master/lastSuccessfulBuild/artifact/tools/appliance/dist/
>>> systemvmtemplate-2013-08-29-master-xen.vhd.bz2
>>>

 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: Request: Help designing a 'powered by' logo for CloudStack

[David Nalley]

This is really a follow on to that request.
Chip commented to me on IRC that he was running out of time to work on
it, so hence my request.

--David

On Fri, Nov 15, 2013 at 1:23 PM, Kelly Hair  wrote:
> May have deleted the thread but wasn¹t this being covered off earlier in
> @marketing or is this a new request?
>
>
>
>
>
> On 11/15/13, 12:56 PM, "David Nalley"  wrote:
>
>>Hi folks:
>>
>>If you happen to have some graphical design talent (I have none) I
>>have a great opportunity for you :)
>>
>>CloudStack needs a 'powered by' logo that is easy to consume, and is
>>also attractive.
>>
>>A couple examples of powered by logos:
>>
>>http://tomcat.apache.org/images/tomcat-power.gif
>>https://cwiki.apache.org/confluence/download/attachments/80899/mahout-logo
>>-poweredby-100.png?version=1&modificationDate=1312880703000
>>https://netbeans.org/images_www/screenshots/6.0/baseIDE_ant_powered_150px.
>>png
>>
>>A couple of constraints:
>>* Please don't use the Apache feather. (we could, but lets not; it
>>will make life simpler)
>>* Please try and produce a vector format as source (this allows us to
>>scale/etc)
>>* Because this will become a trademark (which is vastly different that
>>copyright) - we will likely need some explicit email agreement around
>>trademarks rights for the image. (I promise, it isn't as scary as that
>>sentence makes it out to be.)
>>
>>Anyone interested?
>>
>>--David
>

Re: Request: Help designing a 'powered by' logo for CloudStack

[Chip Childers]

Yep - that's the deal...  I gave some initial designs, we got some
feedback...  would love for someone to take a crack at round 2
options.

On Fri, Nov 15, 2013 at 1:33 PM, David Nalley  wrote:
> This is really a follow on to that request.
> Chip commented to me on IRC that he was running out of time to work on
> it, so hence my request.
>
> --David
>
> On Fri, Nov 15, 2013 at 1:23 PM, Kelly Hair  wrote:
>> May have deleted the thread but wasn¹t this being covered off earlier in
>> @marketing or is this a new request?
>>
>>
>>
>>
>>
>> On 11/15/13, 12:56 PM, "David Nalley"  wrote:
>>
>>>Hi folks:
>>>
>>>If you happen to have some graphical design talent (I have none) I
>>>have a great opportunity for you :)
>>>
>>>CloudStack needs a 'powered by' logo that is easy to consume, and is
>>>also attractive.
>>>
>>>A couple examples of powered by logos:
>>>
>>>http://tomcat.apache.org/images/tomcat-power.gif
>>>https://cwiki.apache.org/confluence/download/attachments/80899/mahout-logo
>>>-poweredby-100.png?version=1&modificationDate=1312880703000
>>>https://netbeans.org/images_www/screenshots/6.0/baseIDE_ant_powered_150px.
>>>png
>>>
>>>A couple of constraints:
>>>* Please don't use the Apache feather. (we could, but lets not; it
>>>will make life simpler)
>>>* Please try and produce a vector format as source (this allows us to
>>>scale/etc)
>>>* Because this will become a trademark (which is vastly different that
>>>copyright) - we will likely need some explicit email agreement around
>>>trademarks rights for the image. (I promise, it isn't as scary as that
>>>sentence makes it out to be.)
>>>
>>>Anyone interested?
>>>
>>>--David
>>

Upgrading nitro API to 10.1

[Syed Ahmed]

Hi All,

I was wondering if it was possible to update the nitro packet which is 
required for Netscaler API from 10.0 to 10.1. The new 10.1 supports the 
"bundle" parameter which makes it possible to upload certificate and 
the trust chain in a single file which makes it very easy for 
certificate management.


Thanks,
-Syed

Re: Coverage Analysis: Few Issues

[Sheng Yang]

Sure, if you don't need these addExternalFirewall etc., you can just remove
them.

Because the name of addExternalFirewall etc. is too generic, so I thought
if you need them as well, you should able to merge your version and SRX
version into one command.

--Sheng


On Fri, Nov 15, 2013 at 9:47 AM, Will Stevens  wrote:

> I have looked into this briefly.  It appears that these commands are not
> needed, so I will remove them and only keep the Palo Alto specific commands.
>
> addPaloAltoFirewall=1
>  deletePaloAltoFirewall=1
>  configurePaloAltoFirewall=1
>  listPaloAltoFirewalls=1
>  listPaloAltoFirewallNetworks=1
>
> Cheers,
>
> Will
>
>
>
>
> On Thu, Nov 14, 2013 at 11:49 PM, Will Stevens wrote:
>
>> Yes, I will look into the naming of the API commands in the Palo Alto
>> plugin.  When you say 'they are supposed to be merged as one command', what
>> do you mean?
>>
>> These were the commands that I exposed.
>>
>>    Palo Alto firewall commands
>>  addExternalFirewall=1
>>  deleteExternalFirewall=1
>>  listExternalFirewalls=1
>>
>> addPaloAltoFirewall=1
>>  deletePaloAltoFirewall=1
>>  configurePaloAltoFirewall=1
>>  listPaloAltoFirewalls=1
>>  listPaloAltoFirewallNetworks=1
>>
>> When I started working on this I was using the SRX as a model as it was
>> the only documentation I had at the time.  I was under the impression that
>> I was supposed to override those commands.  Once I got things working I did
>> not go back over this, so I am sure I can improve this aspect of the plugin.
>>
>> Thanks,
>>
>> Will
>>
>>
>>
>>
>> On Thu, Nov 14, 2013 at 9:01 PM, Sheng Yang  wrote:
>>
>>> Hi Will,
>>>
>>> Could you check on Palo Alto's duplicate api commands? They suppose to
>>> be merged as one command I think.
>>>
>>> BTW, how can this works? Did it broke SRX?
>>>
>>> --Sheng
>>>
>>>
>>> On Thu, Nov 14, 2013 at 2:55 AM, Santhosh Edukulla <
>>> santhosh.eduku...@citrix.com> wrote:
>>>
 Team,

 While running code coverage analysis with sonar for integration tests,
 based upon the errors thrown, i could see the below issues\notes with CS
 project.

 Issue1:

 The coverage tool is complaining about duplicate sources  for below
 files. These are available with same name under folders
 ./cloudstack/plugins/network-elements/juniper-srx and as well under
 /palo-alto.


 ./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/AddExternalFirewallCmd.java

 ./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/DeleteExternalFirewallCmd.java

 ./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/ListExternalFirewallCmd.java

 I renamed one while running analysis to a different name.  It proceeded
 further with its analysis once renamed.

 Is it intentional to have same name or can be renamed?

 Issue2:

 The source directory does not correspond to package declaration for
  code files under

 /root/softwares/cscode/cloudstack/services/console-proxy-rdp/rdpconsole/src/main/java/rdpclient/

 This error when compared to other files in the similar path has a
 different package convention and usage.

 /root/softwares/cscode/cloudstack/services/secondary-storage/src/org/apache/cloudstack/storage/

 Changing tool configuration properties worked to over come this, but Is
 it intentional to have a different package structure for rdpclient code
 base against others?



 Thanks!
 Santhosh

>>>
>>>
>>
>

Re: CloudStack.next

[Yoshikazu Nojima]

+1 especially to CI process improvement.

IMO, we need to improve the patch review process.
Sometimes we encounter that the master branch is broken. Low quality
commit slows down our developing and testing on the master branch.
I think we should change the patch review process to check that a
patch pass unit test before it is merged to the master.

There are Jenkins plugins that help pre-commit testing.
They observe a patch submission, create a test branch that merges the
master branch and the patch, run tests on the branch, and write back
the result on the ReviewBoard or the Github PullRequest.

https://wiki.jenkins-ci.org/display/JENKINS/Jenkins-Reviewbot (for ReviewBoard)
https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin
(for Github PullRequest)

we need to consider these kind pre-commit auto testing tool adoption.


> -our testing infra needs to get much better, continuous testing for all 
> branches, testing on commits etc…maybe we should find a way to get help from 
> cloudbees to get us on the right tracks. Overall > we need to be able to 
> release at any instant with confidence.

- Noji


2013/11/15 Sebastien Goasguen :
> Hi, this is a bit of a brain dump:
>
> I tend to see different types of buckets:
>
> 1-Processes
> Involves getting better as a community in terms of release, bug fixing, 
> committing code, documentation and user support. Some of these have already 
> been discussed partially but we need to come to consensus and act.
> For example:
> -we should have no unanswered questions on the lists. Anyway to have an 
> official volunteer support team ? With a 24/7 twilio number on the site that 
> rings up someone out there :) ?
> -we should catch up on bug fixing (and great job on 4.2.1 btw)
> -when we commit we cannot break master, and I also would argue for committing 
> docs when it's a new feature, right now master is a catch all, instead of a 
> super stable, high quality branch.
> -we need much better docs
> -we need to define standards for releases: RN, changes file, upgrade paths, 
> testing etc.
> -our testing infra needs to get much better, continuous testing for all 
> branches, testing on commits etc…maybe we should find a way to get help from 
> cloudbees to get us on the right tracks. Overall we need to be able to 
> release at any instant with confidence.
> -no feature should be un-documented and/or un-tested. for instance: there was 
> a recent complaint about lack of F5 documentation, and right now I have no 
> clue who is testing the F5 integration.
>
> 2-Ecosystem
> We need to build up the ecosystem around cloudstack and advertize it.
> We integrate with almost everything out there, yet people don't know it. I 
> wish that:
> 2.1 we would improve on support in existing software: all configuration mgt 
> systems, main cloud libraries, PaaS etc...
> 2.2 work with everyone in that ecosystem to advertize and demo CloudStack 
> integration
> 2.3 work on extending that ecosystem (e.g Docker support, Cloudfoundry, 
> Mesos, Spark, OpenDaylight controller) some of it is just a matter of writing 
> a tutorial, some of it there is actual coding involved.
> 2.4 restart effort on AWS: as mentioned IAM is needed but there is more, we 
> need to catch with euca and integrate with netflixOSS software. Bring EMR, 
> ELB, CloudWatch etc…I have plans to work on this and hopefully propose a 
> standalone AWS-ACS bridge with extended services.
>
> 3-Code (caveat, I am not a java developer)
> I still would love to see a lot of cleanup and review. For example I believe 
> the KVM agent uses some python scripts in cloud-cli, those don't use Marvin. 
> We should try to consolidate these. There is code in the tree that is unused, 
> we should clean it up. In the UI when you add a cluster we still list 'OVM' 
> yet it's broken, we need to clean. OStypes in image creation, we need to 
> clean up...
> Packaging and mavenization, we should finish that up and really make it super 
> strong. We need to call out to maven and package experts for a hand.
> We had a small thread on KVM agent and we will have a talk at the hackathon, 
> here I will pick on Xen:
> We need much better support for Xen_Project without using xapi (the xapi 
> install on XP is a pain), without xapi we could easily have ARM / Ceph 
> support…
> Overall I would like to see a strong core emerge with clean code separation 
> with UI, DB abstraction,  backend drivers and plugins. ( A bit pie in the 
> sky, but a non java guy should be able to keep the core and replace/add any 
> other component, plug and play)
> Biggest item is probably a software architecture blueprint, right now we 
> don't have that. No UML diagram, no sequence diagram, most people don't know 
> how cloudstack actually works.
>
> -seb (I will invest time on the ecosystem bucket)
>
> On Nov 14, 2013, at 10:18 PM, Chiradeep Vittal  
> wrote:
>
>> +1 to IAM.
>>
>> An Autoscale service independent of Netscaler.
>> I'd like to see the built

Re: [ACS421] Closing Resolved defects

[Sheng Yang]

I've closed one of mine. But the others would need QA to verify.

Thanks.

--Sheng


On Thu, Nov 14, 2013 at 10:31 PM, Sudha Ponnaganti <
sudha.ponnaga...@citrix.com> wrote:

> Below are the defects which are fixed in 4.2.1 but not validated.  Can you
> pl take few min to review fix done and close these defects
>
> Reporter  Total
> Grand Total77
> angeline shen6
> Sailaja Mada   6
> Prachi Damle  4
> Rayees Namathponnan4
> Sheng Yang 4
> Chandan Purushothama   3
> Likitha Shetty 3
> Nitin Mehta3
> shweta agarwal3
> Ahmad Emneina   2
> Alena Prokharchyk  2
> Chris Sciarrino2
> Harikrishna Patnala 2
> prashant kumar mishra 2
> Sateesh Chodapuneedi 2
> Anshul Gangwar   1
> Dave Cahill  1
> Douglas Almquist 1
> edison su 1
> Francois Gaudreault   1
> frank zhang1
> Gaurav Aradhye   1
> gavin lee  1
> Gerard Lynch 1
> Jayapal Reddy   1
> John Kinsella  1
> Kelven Yang   1
> Kiran Koneti   1
> Koushik Das1
> Marcus Sorensen 1
> Milamber1
> Naoki Sakamoto   1
> Parth Jagirdar1
> Ron Wheeler 1
> sadhu suresh 1
> Saksham Srivastava 1
> Sangeetha Hariharan  1
> Sanjay Tripathi  1
> Sowmya Krishnan1
> Sudha Ponnaganti   1
> Timothy Ehlers  1
> Valery Ciareszka   1
> venkata swamybabu budumuru   1
> Wei Zhou 1
>

Re: Request: Help designing a 'powered by' logo for CloudStack

[Laszlo Hornyak]

Not that I have great graphical skills, but I will give it a try to see if
I can compete with the pros :-)
Are there any deadlines?

On Fri, Nov 15, 2013 at 6:56 PM, David Nalley  wrote:

> Hi folks:
>
> If you happen to have some graphical design talent (I have none) I
> have a great opportunity for you :)
>
> CloudStack needs a 'powered by' logo that is easy to consume, and is
> also attractive.
>
> A couple examples of powered by logos:
>
> http://tomcat.apache.org/images/tomcat-power.gif
>
> https://cwiki.apache.org/confluence/download/attachments/80899/mahout-logo-poweredby-100.png?version=1&modificationDate=1312880703000
>
> https://netbeans.org/images_www/screenshots/6.0/baseIDE_ant_powered_150px.png
>
> A couple of constraints:
> * Please don't use the Apache feather. (we could, but lets not; it
> will make life simpler)
> * Please try and produce a vector format as source (this allows us to
> scale/etc)
> * Because this will become a trademark (which is vastly different that
> copyright) - we will likely need some explicit email agreement around
> trademarks rights for the image. (I promise, it isn't as scary as that
> sentence makes it out to be.)
>
> Anyone interested?
>
> --David
>



-- 

EOF

Re: Request: Help designing a 'powered by' logo for CloudStack

[David Nalley]

Awesome!!! Thanks!

Not really - sooner is generally better than later, but getting it
done is better than not.

--David

On Fri, Nov 15, 2013 at 2:03 PM, Laszlo Hornyak
 wrote:
> Not that I have great graphical skills, but I will give it a try to see if
> I can compete with the pros :-)
> Are there any deadlines?
>
> On Fri, Nov 15, 2013 at 6:56 PM, David Nalley  wrote:
>
>> Hi folks:
>>
>> If you happen to have some graphical design talent (I have none) I
>> have a great opportunity for you :)
>>
>> CloudStack needs a 'powered by' logo that is easy to consume, and is
>> also attractive.
>>
>> A couple examples of powered by logos:
>>
>> http://tomcat.apache.org/images/tomcat-power.gif
>>
>> https://cwiki.apache.org/confluence/download/attachments/80899/mahout-logo-poweredby-100.png?version=1&modificationDate=1312880703000
>>
>> https://netbeans.org/images_www/screenshots/6.0/baseIDE_ant_powered_150px.png
>>
>> A couple of constraints:
>> * Please don't use the Apache feather. (we could, but lets not; it
>> will make life simpler)
>> * Please try and produce a vector format as source (this allows us to
>> scale/etc)
>> * Because this will become a trademark (which is vastly different that
>> copyright) - we will likely need some explicit email agreement around
>> trademarks rights for the image. (I promise, it isn't as scary as that
>> sentence makes it out to be.)
>>
>> Anyone interested?
>>
>> --David
>>
>
>
>
> --
>
> EOF

Re: Coverage Analysis: Few Issues

[Will Stevens]

I will just remove them.  It appears the only reason they are there is for
backwards compatibility.  I have checked other plugins and they all just
expose the device specific api commands (Other than SRX which exposes both).

The problem with merging them into one command is the PaloAlto plugin is in
core and the SRX plugin is in 'noredist', so I don't really want to create
any dependency requirements on other plugins.

Cheers,

Will


On Fri, Nov 15, 2013 at 1:56 PM, Sheng Yang  wrote:

> Sure, if you don't need these addExternalFirewall etc., you can just
> remove them.
>
> Because the name of addExternalFirewall etc. is too generic, so I thought
> if you need them as well, you should able to merge your version and SRX
> version into one command.
>
> --Sheng
>
>
> On Fri, Nov 15, 2013 at 9:47 AM, Will Stevens wrote:
>
>> I have looked into this briefly.  It appears that these commands are not
>> needed, so I will remove them and only keep the Palo Alto specific commands.
>>
>> addPaloAltoFirewall=1
>>  deletePaloAltoFirewall=1
>>  configurePaloAltoFirewall=1
>>  listPaloAltoFirewalls=1
>>  listPaloAltoFirewallNetworks=1
>>
>> Cheers,
>>
>> Will
>>
>>
>>
>>
>> On Thu, Nov 14, 2013 at 11:49 PM, Will Stevens wrote:
>>
>>> Yes, I will look into the naming of the API commands in the Palo Alto
>>> plugin.  When you say 'they are supposed to be merged as one command', what
>>> do you mean?
>>>
>>> These were the commands that I exposed.
>>>
>>>    Palo Alto firewall commands
>>>  addExternalFirewall=1
>>>  deleteExternalFirewall=1
>>>  listExternalFirewalls=1
>>>
>>> addPaloAltoFirewall=1
>>>  deletePaloAltoFirewall=1
>>>  configurePaloAltoFirewall=1
>>>  listPaloAltoFirewalls=1
>>>  listPaloAltoFirewallNetworks=1
>>>
>>> When I started working on this I was using the SRX as a model as it was
>>> the only documentation I had at the time.  I was under the impression that
>>> I was supposed to override those commands.  Once I got things working I did
>>> not go back over this, so I am sure I can improve this aspect of the plugin.
>>>
>>> Thanks,
>>>
>>> Will
>>>
>>>
>>>
>>>
>>> On Thu, Nov 14, 2013 at 9:01 PM, Sheng Yang  wrote:
>>>
 Hi Will,

 Could you check on Palo Alto's duplicate api commands? They suppose to
 be merged as one command I think.

 BTW, how can this works? Did it broke SRX?

 --Sheng


 On Thu, Nov 14, 2013 at 2:55 AM, Santhosh Edukulla <
 santhosh.eduku...@citrix.com> wrote:

> Team,
>
> While running code coverage analysis with sonar for integration tests,
> based upon the errors thrown, i could see the below issues\notes with CS
> project.
>
> Issue1:
>
> The coverage tool is complaining about duplicate sources  for below
> files. These are available with same name under folders
> ./cloudstack/plugins/network-elements/juniper-srx and as well under
> /palo-alto.
>
>
> ./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/AddExternalFirewallCmd.java
>
> ./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/DeleteExternalFirewallCmd.java
>
> ./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/ListExternalFirewallCmd.java
>
> I renamed one while running analysis to a different name.  It
> proceeded further with its analysis once renamed.
>
> Is it intentional to have same name or can be renamed?
>
> Issue2:
>
> The source directory does not correspond to package declaration for
>  code files under
>
> /root/softwares/cscode/cloudstack/services/console-proxy-rdp/rdpconsole/src/main/java/rdpclient/
>
> This error when compared to other files in the similar path has a
> different package convention and usage.
>
> /root/softwares/cscode/cloudstack/services/secondary-storage/src/org/apache/cloudstack/storage/
>
> Changing tool configuration properties worked to over come this, but
> Is it intentional to have a different package structure for rdpclient code
> base against others?
>
>
>
> Thanks!
> Santhosh
>


>>>
>>
>

Re: Request: Help designing a 'powered by' logo for CloudStack

[Kirk Jantzer]

May be a silly question, but why not just add "powered by" the existing
logo?


Regards,

Kirk Jantzer
http://about.me/kirkjantzer


On Fri, Nov 15, 2013 at 2:06 PM, David Nalley  wrote:

> Awesome!!! Thanks!
>
> Not really - sooner is generally better than later, but getting it
> done is better than not.
>
> --David
>
> On Fri, Nov 15, 2013 at 2:03 PM, Laszlo Hornyak
>  wrote:
> > Not that I have great graphical skills, but I will give it a try to see
> if
> > I can compete with the pros :-)
> > Are there any deadlines?
> >
> > On Fri, Nov 15, 2013 at 6:56 PM, David Nalley  wrote:
> >
> >> Hi folks:
> >>
> >> If you happen to have some graphical design talent (I have none) I
> >> have a great opportunity for you :)
> >>
> >> CloudStack needs a 'powered by' logo that is easy to consume, and is
> >> also attractive.
> >>
> >> A couple examples of powered by logos:
> >>
> >> http://tomcat.apache.org/images/tomcat-power.gif
> >>
> >>
> https://cwiki.apache.org/confluence/download/attachments/80899/mahout-logo-poweredby-100.png?version=1&modificationDate=1312880703000
> >>
> >>
> https://netbeans.org/images_www/screenshots/6.0/baseIDE_ant_powered_150px.png
> >>
> >> A couple of constraints:
> >> * Please don't use the Apache feather. (we could, but lets not; it
> >> will make life simpler)
> >> * Please try and produce a vector format as source (this allows us to
> >> scale/etc)
> >> * Because this will become a trademark (which is vastly different that
> >> copyright) - we will likely need some explicit email agreement around
> >> trademarks rights for the image. (I promise, it isn't as scary as that
> >> sentence makes it out to be.)
> >>
> >> Anyone interested?
> >>
> >> --David
> >>
> >
> >
> >
> > --
> >
> > EOF
>

Re: A question on vm migrations when hosts are set into a maintenance mode.

[Alex Ough]

I hate to sending the same emails over and over again, but I really need to
finalize this feature to be included in the next code freeze because this
feature is very critical in our inside project.

Anyone who can help, please?
Thanks
Alex Ough


On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough  wrote:

> Not sure if Alex Huang checked this, but can anyone help to resolve this?
>
> Thanks
> Alex Ough
>
>
> On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough  wrote:
>
>> It sounds a little scary...
>>
>> I looked at the history and found these.
>>
>> 8/9/ : file moved to engine by Alex Huang
>> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
>> 'getExecuteInSequence()' by Alex Huang
>>
>>
>> Hi Alex Huang,
>> I'm not sure if you're aware of this, but can you check this for me?
>>
>> Thanks
>> Alex Ough
>>
>>
>>
>> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen wrote:
>>
>>> I'm not sure. I know in the past when I've seen files change locations
>>> it has also clobbered updates to that file. Someone branched, did the
>>> reorganization work, and merged, while in-between the original file
>>> changed.
>>>
>>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough 
>>> wrote:
>>> > All,
>>> >
>>> > While merging my changes to 4.3 branch, I found that the option,
>>> > 'execute.in.sequence.hypervisor.commands' is NOT used in
>>> Start/Stop/Copy
>>> > commands in 'VirtualMachineManagerImpl.java' any more as below.
>>> >
>>> >
>>> > *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
>>> >
>>> > *protected boolean getExecuteInSequence() {*
>>> > * return false;*
>>> > *}*
>>> >
>>> > As you see in the above, the function, 'getExecuteInSequence', just
>>> returns
>>> > false instead of getting the value from the global variable.
>>> >
>>> > And one more change is that the file has been moved to
>>> > 'engine/orchestration/src/com/cloud/vm' from 'server/src/com/cloud/vm'.
>>> >
>>> > Am I missing something related with this or do we stop supporting this
>>> > option in 4.3?
>>> > I'm a little confused, so please help me resolve this.
>>> >
>>> > Thanks
>>> > Alex Ough
>>> >
>>> >
>>> >
>>> >
>>> > On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough 
>>> wrote:
>>> >
>>> >> Thanks a lot for your confirmation, Marcus.
>>> >> I'll create a review request unless anyone has an objection.
>>> >>
>>> >> Thanks
>>> >> Alex Ough
>>> >>
>>> >>
>>> >> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen >> >wrote:
>>> >>
>>> >>>  I have done parallel KVM migrations without issue, it's "supposed to
>>> >>> work". Really I think it's in the same boat as parallel start/stop.
>>> It
>>> >>> should work, but the config option is there just in case. I think we
>>> >>> should add it.
>>> >>>
>>> >>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
>>> >>>  wrote:
>>> >>> > On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
>>> >>> >> I'm not sure what else commands 'MigrateCommand' actually execute
>>> in
>>> >>> >> addition to 'Start/Stop/CopyCommand', but can we include
>>> >>> 'MigrateCommand'
>>> >>> >> if it consists of only those 3 commands?
>>> >>> >>
>>> >>> >> Thanks
>>> >>> >> Alex Ough
>>> >>> >
>>> >>> > In the case of VMware, the migrate command is executed via the
>>> >>> > MigrateVMTask that's part of the VMware SDK (see
>>> >>> >
>>> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
>>> >>> >
>>> >>> > For VMware, I know that vCenter will queue and process concurrent
>>> >>> > requests for migrations.  Specifically, it will throttle the
>>> migrations
>>> >>> > happening, based on it's internal concurrency constraints, but the
>>> task
>>> >>> > queue will still accept more connections.  Obviously the risk are
>>> the
>>> >>> > VMware layer tasks timing out if it takes too long for the task
>>> queue to
>>> >>> > complete.
>>> >>> >
>>> >>> > As for XenServer, it's happening in what appears to be a similar
>>> way
>>> >>> > (although the source host is the target for the migration API
>>> call).
>>> >>> >
>>> >>> > Check
>>> >>> >
>>> >>>
>>> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
>>> >>> >
>>> >>> > I'm not familiar enough with XenServer's concurrency model for
>>> >>> > migrations.  Any experts know the answer to if it can handle
>>> concurrency
>>> >>> > in a stable way?
>>> >>> >
>>> >>> > With KVM, it's obviously executing via the agent.  Similarly to
>>> >>> > XenServer, I'm not familiar enough to know about concurrent
>>> operations.
>>> >>> >
>>> >>> > So do the HV experts on the list have any opinions about XenServer
>>> and
>>> >>> > KVM migration concurrency?
>>> >>> >
>>> >>> > -chip
>>> >>> >
>>> >>> >
>>> >>>
>>> >>>
>>> >>
>>>
>>>
>>
>

Re: Review Request 15569: CLOUDSTACK-5179: Fixed test script issue related to detach volume

[ASF Subversion and Git Services]

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


Commit 8a1918dbe1c5fbbb60c21fa89d880a99e7b33bd6 in branch refs/heads/ui-restyle 
from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8a1918d ]

CLOUDSTACK-5179: Fixed test script issue related to detach
 volume


- ASF Subversion and Git Services


On Nov. 15, 2013, 7:41 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15569/
> ---
> 
> (Updated Nov. 15, 2013, 7:41 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-5179
> https://issues.apache.org/jira/browse/CLOUDSTACK-5179
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> component.test_stopped_vm.TestDeployVM.test_08_deploy_attached_volume test 
> case was failing while detaching volume because the volume was not listed 
> properly. List volumes should accept the virtualmachineid parameter to 
> correctly list the volume belonging to the virtual machine, otherwise the 
> volume which we are detaching from virtual machine may belong to other 
> virtual machine, in this case test case will fail.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_stopped_vm.py 4514bb7 
> 
> Diff: https://reviews.apache.org/r/15569/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on XenServer Basic Zone setup.
> 
> test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM)
> Test Deploy Virtual Machine with startVM=false and attach volume already 
> attached to different machine ...
> ==> client.log <==
> 2013-11-14 19:27:10,018 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF
> 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for 
> virtual machine: 9631c
> 64f-a7ba-488b-951b-c425f00e1ce3
> 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Deploying instance in the account: 
> test-6MG5KF
> 2013-11-14 19:27:31,205 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF
> 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for 
> virtual machine: 7e3de
> e7d-29ce-425c-95e4-e8f85143254c
> 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Fetching DATADISK details for instance: 
> 7e3dee7d-29ce-425c-95e
> 4-e8f85143254c
> 2013-11-14 19:27:31,266 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Detaching the disk: DATA-32
> 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Datadisk DATA-32 detached!
> 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Attaching volume to instance: 
> 9631c64f-a7ba-488b-951b-c425f00e
> 1ce3
> 2013-11-14 19:27:41,530 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Cleaning up the resources
> 2013-11-14 19:28:42,227 - DEBUG - test_08_deploy_attached_volume 
> (test_stopped_vm.TestDeployVM) - Cleanup complete!
> 
> ==> result.log <==
> ok
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 15571: CLOUDSTACK-2243: base_image_updation - Adding tags to test cases

[ASF Subversion and Git Services]

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


Commit 09c0370d70721e07ff02cd907a2cab2cabc9ae5b in branch refs/heads/ui-restyle 
from Girish Shilamkar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=09c0370 ]

CLOUDSTACK-2243: base_image_updation - Adding tags to test cases


- ASF Subversion and Git Services


On Nov. 15, 2013, 11:09 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15571/
> ---
> 
> (Updated Nov. 15, 2013, 11:09 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and Rayees Namathponnan.
> 
> 
> Bugs: CLOUDSTACK-2243
> https://issues.apache.org/jira/browse/CLOUDSTACK-2243
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added basic and advanced tags for the test cases.
> The test cases have been run on both the setups.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_base_image_updation.py 8a99350 
> 
> Diff: https://reviews.apache.org/r/15571/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on KVM advanced and XenServer basic setup.
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: Review Request 15452: CLOUDSTACK-5147: Removing basic and sg tags from test case which is invalid for basic zone

[ASF Subversion and Git Services]

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


Commit a6c2c6a261af4871b0a8872f43068f15cc1da3cd in branch refs/heads/ui-restyle 
from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a6c2c6a ]

CLOUDSTACK-5147: Removing basic and sg tags from the test
 case which is invalid for basic zone


- ASF Subversion and Git Services


On Nov. 15, 2013, 10:07 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15452/
> ---
> 
> (Updated Nov. 15, 2013, 10:07 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-5147
> https://issues.apache.org/jira/browse/CLOUDSTACK-5147
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The test case 
> test_resource_limits.TestMaxAccountNetworks.test_maxAccountNetworks tries to 
> create multiple isolated networks in an account which is invalid scenario for 
> basic zone.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_resource_limits.py 377aa74 
> 
> Diff: https://reviews.apache.org/r/15452/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Request: Help designing a 'powered by' logo for CloudStack

[Robyn Bergeron]

- Original Message -
> From: "David Nalley" 
> To: market...@cloudstack.apache.org, dev@cloudstack.apache.org
> Sent: Friday, November 15, 2013 10:56:15 AM
> Subject: Request: Help designing a 'powered by' logo for CloudStack
> 
> Hi folks:
> 
> If you happen to have some graphical design talent (I have none) I
> have a great opportunity for you :)
> 
> CloudStack needs a 'powered by' logo that is easy to consume, and is
> also attractive.
> 
> A couple examples of powered by logos:
> 
> http://tomcat.apache.org/images/tomcat-power.gif
> https://cwiki.apache.org/confluence/download/attachments/80899/mahout-logo-poweredby-100.png?version=1&modificationDate=1312880703000
> https://netbeans.org/images_www/screenshots/6.0/baseIDE_ant_powered_150px.png
> 
> A couple of constraints:
> * Please don't use the Apache feather. (we could, but lets not; it
> will make life simpler)
> * Please try and produce a vector format as source (this allows us to
> scale/etc)
> * Because this will become a trademark (which is vastly different that
> copyright) - we will likely need some explicit email agreement around
> trademarks rights for the image. (I promise, it isn't as scary as that
> sentence makes it out to be.)

I also lack design skills, but am always willing to throw out ideas :)

Maybe incorporate the cloud monkey into something where he is turning a gear of 
some sort on a machine that has little clouds coming out of it? I'm not quite 
sure how to turn that into "powered by" exactly... but just a thought. (The 
monkey is super cute.)

-robyn


> 
> Anyone interested?
> 
> --David
> 

Jenkins build is back to normal : cloudstack-4.3-maven-build-noredist #22

[jenkins]

See 

RE: [VOTE] Release Apache CloudStack 4.2.1

[Edison Su]

+1(binding)
Tested on my local machine with one KVM host, basic marvin vm test passed.

> -Original Message-
> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
> Sent: Tuesday, November 12, 2013 7:53 AM
> To: CloudStack Dev
> Subject: [VOTE] Release Apache CloudStack 4.2.1
> 
> 
>This vote is to approve the current RC build for 4.2.1 maintenance release.
> For this particular release various upgrade paths have been tested apart from
> regression tests and BVTs.
> Around 175 bugs have been fixed some new features added (see CHANGES).
> 
> Following are the particulars for this release:
> 
> https://git-wip-
> us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.2
> commit: 0b9eadaf14513f5c72de672963b0e2f12ee7206f
> 
> List of changes:
> https://git-wip-
> us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.2.
> 1
> 
> Source release revision 3492 (checksums and signatures are available at the
> same location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.2.1/
> 
> PGP release keys (signed using RSA Key ID = 42443AA1):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> 
> Vote will be open for 72 hours (until 11/15 End of day PST).
> 
> For sanity in tallying the vote, can PMC members please be sure to indicate
> "(binding)" with their vote?
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)

Re: [VOTE] Release Apache CloudStack 4.2.1

[Nitin Mehta]

+1.

Did some basic testing like creating vms, attaching volume, creating
snapshots etc. and they all worked fine.

Thanks,
-Nitin


On 14/11/13 8:40 AM, "Daan Hoogland"  wrote:

>+1 binding (I had not been clear on this in this thread it seems)
>
>On Thu, Nov 14, 2013 at 6:05 AM, Abhinandan Prateek
> wrote:
>> Marcus,
>>
>>   Just summarising your concerns so that they can be followed upon:
>> 1. Due to a VR script change a restart of VR is required. This should be
>> noted down in upgrade instructions in RN. (Radhika to note)
>> 2. For a maintenance release we should limit the scope to only
>>blockers. I
>> guess what is done is done probably for better as the main release had
>>so
>> many new features that a whole lot fixes were expected in the
>>maintenance
>> release. But again for further maintenance releases scope should be
>> restricted to important fixes.
>>
>> Any other thing that has been missed ?
>>
>> -abhi
>>
>>
>> On 14/11/13 12:06 am, "Marcus Sorensen"  wrote:
>>
>>>I'm unable to deploy virtual machines after upgrading an existing
>>>4.2.0 to this release.
>>>
>>>It looks like the file savepassword.sh was added at the end of October
>>>as a virtual router script. This would likely mean that people
>>>upgrading to 4.2.1 will need to upgrade/redeploy their routers. I can
>>>verify that deploy works if I reboot the router.
>>>
>>>Looking over the current state of 4.2, I'm actually pretty surprised
>>>at how much has changed. I'm seeing lots of whitespace fixes, changes
>>>to interfaces, etc. My impression was that we'd only commit fixes for
>>>blocker bugs once a release has gone production, only touching it if
>>>we had to. This went pretty well with 4.1, I thought, but everything
>>>was going through the RM that round.
>>>
>>>2013-11-13 11:25:24,917 DEBUG
>>>[resource.virtualnetwork.VirtualRoutingResource]
>>>(agentRequest-Handler-2:null) Executing:
>>>/usr/share/cloudstack-common/scripts/network/domr/router_proxy.sh
>>>savepassword.sh 169.254.1.163 -v 10.2.4.116 -p fnirq_cnffjbeq
>>>
>>>2013-11-13 11:25:25,000 DEBUG
>>>[resource.virtualnetwork.VirtualRoutingResource]
>>>(agentRequest-Handler-2:null) Exit value is 127
>>>
>>>2013-11-13 11:25:25,001 DEBUG
>>>[resource.virtualnetwork.VirtualRoutingResource]
>>>(agentRequest-Handler-2:null) bash: /opt/cloud/bin/savepassword.sh: No
>>>such file or directory
>>>
>>>2013-11-13 11:25:25,002 DEBUG [cloud.agent.Agent]
>>>(agentRequest-Handler-2:null) Seq 21-289734823:  { Ans: , MgmtId:
>>>90520732090445, via: 21, Ver: v1, Flags: 110,
>>>[{"com.cloud.agent.api.Answer":{"result":false,"details":"Unable to
>>>save password to
>>>DomR.","wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"details
>>>":
>>>"Stopped
>>>by previous failure","wait":0}}] }
>>>
>>>On Wed, Nov 13, 2013 at 10:26 AM, Chip Childers
>>>
>>>wrote:
 On Tue, Nov 12, 2013 at 10:52 AM, Abhinandan Prateek
  wrote:
>
>This vote is to approve the current RC build for 4.2.1 maintenance
>release.
> For this particular release various upgrade paths have been tested
>apart from regression tests and BVTs.
> Around 175 bugs have been fixed some new features added (see
>CHANGES).
>
> Following are the particulars for this release:
>
>
>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=
>re
>fs/heads/4.2
> commit: 0b9eadaf14513f5c72de672963b0e2f12ee7206f
>
> List of changes:
>
>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;
>f=
>CHANGES;hb=4.2.1
>
> Source release revision 3492 (checksums and signatures are available
>at the same location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.2.1/
>
> PGP release keys (signed using RSA Key ID = 42443AA1):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours (until 11/15 End of day PST).
>
> For sanity in tallying the vote, can PMC members please be sure to
>indicate "(binding)" with their vote?
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)

 +1 (binding)

 I only performed very rudimentary functional testing, but the
 artifact's look legit.

 Thanks for doing this Abhi!

Re: [VOTE] Release Apache CloudStack 4.2.1

[Min Chen]

+1(binding)
Tested on my local dev setup with one Xen host and basic zone, marvin vm
test passed.

Thanks
-min

On 11/15/13 3:21 PM, "Edison Su"  wrote:

>+1(binding)
>Tested on my local machine with one KVM host, basic marvin vm test passed.
>
>> -Original Message-
>> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
>> Sent: Tuesday, November 12, 2013 7:53 AM
>> To: CloudStack Dev
>> Subject: [VOTE] Release Apache CloudStack 4.2.1
>> 
>> 
>>This vote is to approve the current RC build for 4.2.1 maintenance
>>release.
>> For this particular release various upgrade paths have been tested
>>apart from
>> regression tests and BVTs.
>> Around 175 bugs have been fixed some new features added (see CHANGES).
>> 
>> Following are the particulars for this release:
>> 
>> https://git-wip-
>> us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.2
>> commit: 0b9eadaf14513f5c72de672963b0e2f12ee7206f
>> 
>> List of changes:
>> https://git-wip-
>> us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.2.
>> 1
>> 
>> Source release revision 3492 (checksums and signatures are available at
>>the
>> same location):
>> https://dist.apache.org/repos/dist/dev/cloudstack/4.2.1/
>> 
>> PGP release keys (signed using RSA Key ID = 42443AA1):
>> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>> 
>> Vote will be open for 72 hours (until 11/15 End of day PST).
>> 
>> For sanity in tallying the vote, can PMC members please be sure to
>>indicate
>> "(binding)" with their vote?
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)

RE: [VOTE] Release Apache CloudStack 4.2.1

[Animesh Chaturvedi]

-Original Message-
From: Marcus Sorensen [mailto:shadow...@gmail.com] 
Sent: Thursday, November 14, 2013 11:42 PM
To: dev@cloudstack.apache.org
Cc: Radhika Puthiyetath
Subject: Re: [VOTE] Release Apache CloudStack 4.2.1

Ok, that may be my fault as I've got various 4.2.0 systems built from testing 
various RCs. I just chose one and tried to upgrade it. Thanks for clearing that 
up.

Animesh> So Marcus this is not a -1 then right?

On Fri, Nov 15, 2013 at 12:14 AM, Abhinandan Prateek 
 wrote:
> Marcus,
>
>   I am trying to understand the upgrade issue that you are facing.
> It seems there were changes during various rounds of RC that we had 
> for
> 4.2.0 .
> The fix that you have mentioned in the email actually got introduced 
> in the 4.2 GA.
> So someone upgrading to 4.2 GA will not have that constraint on the 
> vpc_service_map table.
>
>  Just for clarity this does not affect the upgrade from 4.2 GA to 4.2.1.
> If you have any doubts please specify those with clarity so these it 
> can get rectified at the earliest.
>
> David,
>   I think it is still not a ³-1².
>
> -abhi
>
> On 15/11/13 10:40 am, "Marcus Sorensen"  wrote:
>
>>Yes, I'd say that upgrade from 4.2.0 to 4.2.1 needs to work.
>>On Nov 14, 2013 5:58 PM, "David Nalley"  wrote:
>>
>>> Marcus:
>>>
>>> Is this is a -1?
>>>
>>> I don't have any legal concerns, and the release builds and tests 
>>> for me (though I haven't tried VPC).  I am somewhat concerned about 
>>> what appears to be drifting away from adhering to semver. (features 
>>> appear to have made it into the 4.2.1 release that weren't in 4.2.0) 
>>> and I am also concerned about sys vm update fatigue, especially 
>>> given the problems we had in 4.2.0 around sysvm updates.
>>>
>>> --David
>>>
>>> On Thu, Nov 14, 2013 at 1:08 PM, Marcus Sorensen 
>>> 
>>> wrote:
>>> > Yeah, I understand that 4.2.0 had a lot of post-release work needed.
>>> >
>>> > We are unable to create VPNs.  This is reported second hand from 
>>> > one of my admins. He seems to think that it was caused by the 
>>> > following, which added a for loop inside a for loop. The error is:
>>> >
>>>
>>>'com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationExc
>>>epti
>>>on:
>>> > Duplicate entry '146-Lb' for key 'vpc_id'
>>> >
>>> > We did the following to fix it, something should be added to the 
>>> > sql
>>> upgrade.
>>> > mysql -D cloud -t -e 'alter table vpc_service_map drop key vpc_id, 
>>> > add unique key vpc_id (vpc_id,service,provider)'
>>> >
>>> >
>>> > commit 9050cfad3da673370d6ad1ed7570e31314069996
>>> >
>>> > CLOUDSTACK-4704: 41-42 db upgrade - populate vpc_service_map 
>>> > table with the services/providers supported by VPC
>>> >
>>> >
>>> >  @Override
>>> >  @DB
>>> > -public void persistVpcServiceProviders(long vpcId, Map>> > String> serviceProviderMap) {
>>> > +public void persistVpcServiceProviders(long vpcId, 
>>> > + Map>> > List> serviceProviderMap) {
>>> >  Transaction txn = Transaction.currentTxn();
>>> >  txn.start();
>>> >  for (String service : serviceProviderMap.keySet()) {
>>> > -VpcServiceMapVO serviceMap = new VpcServiceMapVO(vpcId,
>>> > Network.Service.getService(service),
>>> > Network.Provider.getProvider(serviceProviderMap.get(service)));
>>> > -_vpcSvcMap.persist(serviceMap);
>>> > +for (String provider : serviceProviderMap.get(service)) {
>>> > +VpcServiceMapVO serviceMap = new
>>> > VpcServiceMapVO(vpcId, Network.Service.getService(service),
>>> > Network.Provider.getProvider(provider));
>>> > +_vpcSvcMap.persist(serviceMap);
>>> > +}
>>> >  }
>>> >  txn.commit();
>>> >  }
>>> >
>>> >
>>> > On Thu, Nov 14, 2013 at 9:40 AM, Daan Hoogland
>>>
>>> wrote:
>>> >> +1 binding (I had not been clear on this in this thread it seems)
>>> >>
>>> >> On Thu, Nov 14, 2013 at 6:05 AM, Abhinandan Prateek 
>>> >>  wrote:
>>> >>> Marcus,
>>> >>>
>>> >>>   Just summarising your concerns so that they can be followed upon:
>>> >>> 1. Due to a VR script change a restart of VR is required. This
>>>should
>>> be
>>> >>> noted down in upgrade instructions in RN. (Radhika to note) 2. 
>>> >>> For a maintenance release we should limit the scope to only
>>> blockers. I
>>> >>> guess what is done is done probably for better as the main 
>>> >>> release
>>>had
>>> so
>>> >>> many new features that a whole lot fixes were expected in the
>>> maintenance
>>> >>> release. But again for further maintenance releases scope should 
>>> >>> be restricted to important fixes.
>>> >>>
>>> >>> Any other thing that has been missed ?
>>> >>>
>>> >>> -abhi
>>> >>>
>>> >>>
>>> >>> On 14/11/13 12:06 am, "Marcus Sorensen"  wrote:
>>> >>>
>>> I'm unable to deploy virtual machines after upgrading an 
>>> existing
>>> 4.2.0 to this release.
>>> 
>>> It looks like the file savepassword.sh was added at the end of
>>>October
>>> as a virtual router scr

Re: [VOTE] Release Apache CloudStack 4.2.1

[Marcus Sorensen]

As long as we document the router reboot requirement in the release
notes, yes, I'm +1.

On a side note, we have an upgradeRouterScripts API call (in our
plugin) that just scps the new systemvm tar up to a given router and
extracts it, which allows us to avoid reboots, but we've been leary of
pushing it as a feature because we only use it on things that we know
don't need service restarts (this new savepassword.sh is a good
example). In other words it's not really end-user friendly. We should
put something like this on the list for improvements next time around,
if we can come up with a way to reinitialize the cloud-early init
service.

On Fri, Nov 15, 2013 at 4:30 PM, Animesh Chaturvedi
 wrote:
>
>
> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Thursday, November 14, 2013 11:42 PM
> To: dev@cloudstack.apache.org
> Cc: Radhika Puthiyetath
> Subject: Re: [VOTE] Release Apache CloudStack 4.2.1
>
> Ok, that may be my fault as I've got various 4.2.0 systems built from testing 
> various RCs. I just chose one and tried to upgrade it. Thanks for clearing 
> that up.
>
> Animesh> So Marcus this is not a -1 then right?
>
> On Fri, Nov 15, 2013 at 12:14 AM, Abhinandan Prateek 
>  wrote:
>> Marcus,
>>
>>   I am trying to understand the upgrade issue that you are facing.
>> It seems there were changes during various rounds of RC that we had
>> for
>> 4.2.0 .
>> The fix that you have mentioned in the email actually got introduced
>> in the 4.2 GA.
>> So someone upgrading to 4.2 GA will not have that constraint on the
>> vpc_service_map table.
>>
>>  Just for clarity this does not affect the upgrade from 4.2 GA to 4.2.1.
>> If you have any doubts please specify those with clarity so these it
>> can get rectified at the earliest.
>>
>> David,
>>   I think it is still not a ³-1².
>>
>> -abhi
>>
>> On 15/11/13 10:40 am, "Marcus Sorensen"  wrote:
>>
>>>Yes, I'd say that upgrade from 4.2.0 to 4.2.1 needs to work.
>>>On Nov 14, 2013 5:58 PM, "David Nalley"  wrote:
>>>
 Marcus:

 Is this is a -1?

 I don't have any legal concerns, and the release builds and tests
 for me (though I haven't tried VPC).  I am somewhat concerned about
 what appears to be drifting away from adhering to semver. (features
 appear to have made it into the 4.2.1 release that weren't in 4.2.0)
 and I am also concerned about sys vm update fatigue, especially
 given the problems we had in 4.2.0 around sysvm updates.

 --David

 On Thu, Nov 14, 2013 at 1:08 PM, Marcus Sorensen
 
 wrote:
 > Yeah, I understand that 4.2.0 had a lot of post-release work needed.
 >
 > We are unable to create VPNs.  This is reported second hand from
 > one of my admins. He seems to think that it was caused by the
 > following, which added a for loop inside a for loop. The error is:
 >

'com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationExc
epti
on:
 > Duplicate entry '146-Lb' for key 'vpc_id'
 >
 > We did the following to fix it, something should be added to the
 > sql
 upgrade.
 > mysql -D cloud -t -e 'alter table vpc_service_map drop key vpc_id,
 > add unique key vpc_id (vpc_id,service,provider)'
 >
 >
 > commit 9050cfad3da673370d6ad1ed7570e31314069996
 >
 > CLOUDSTACK-4704: 41-42 db upgrade - populate vpc_service_map
 > table with the services/providers supported by VPC
 >
 >
 >  @Override
 >  @DB
 > -public void persistVpcServiceProviders(long vpcId, Map>>> > String> serviceProviderMap) {
 > +public void persistVpcServiceProviders(long vpcId,
 > + Map>>> > List> serviceProviderMap) {
 >  Transaction txn = Transaction.currentTxn();
 >  txn.start();
 >  for (String service : serviceProviderMap.keySet()) {
 > -VpcServiceMapVO serviceMap = new VpcServiceMapVO(vpcId,
 > Network.Service.getService(service),
 > Network.Provider.getProvider(serviceProviderMap.get(service)));
 > -_vpcSvcMap.persist(serviceMap);
 > +for (String provider : serviceProviderMap.get(service)) {
 > +VpcServiceMapVO serviceMap = new
 > VpcServiceMapVO(vpcId, Network.Service.getService(service),
 > Network.Provider.getProvider(provider));
 > +_vpcSvcMap.persist(serviceMap);
 > +}
 >  }
 >  txn.commit();
 >  }
 >
 >
 > On Thu, Nov 14, 2013 at 9:40 AM, Daan Hoogland

 wrote:
 >> +1 binding (I had not been clear on this in this thread it seems)
 >>
 >> On Thu, Nov 14, 2013 at 6:05 AM, Abhinandan Prateek
 >>  wrote:
 >>> Marcus,
 >>>
 >>>   Just summarising your concerns so that they can be followed upon:
 >>> 1. Due to a VR script change a restart of VR is required. This
should
 be
 >>> noted down in upgrad

RE: [VOTE] Release Apache CloudStack 4.2.1

[Animesh Chaturvedi]

-Original Message-
From: Marcus Sorensen [mailto:shadow...@gmail.com] 
Sent: Friday, November 15, 2013 4:19 PM
To: dev@cloudstack.apache.org
Cc: Radhika Puthiyetath
Subject: Re: [VOTE] Release Apache CloudStack 4.2.1

As long as we document the router reboot requirement in the release notes, yes, 
I'm +1.

Animesh>  Yes that should be in release notes

On a side note, we have an upgradeRouterScripts API call (in our
plugin) that just scps the new systemvm tar up to a given router and extracts 
it, which allows us to avoid reboots, but we've been leary of pushing it as a 
feature because we only use it on things that we know don't need service 
restarts (this new savepassword.sh is a good example). In other words it's not 
really end-user friendly. We should put something like this on the list for 
improvements next time around, if we can come up with a way to reinitialize the 
cloud-early init service

Animesh> Do you want to start a separate thread on it. Master is now open for 
4.4 enhancements and features

On Fri, Nov 15, 2013 at 4:30 PM, Animesh Chaturvedi 
 wrote:
>
>
> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Thursday, November 14, 2013 11:42 PM
> To: dev@cloudstack.apache.org
> Cc: Radhika Puthiyetath
> Subject: Re: [VOTE] Release Apache CloudStack 4.2.1
>
> Ok, that may be my fault as I've got various 4.2.0 systems built from testing 
> various RCs. I just chose one and tried to upgrade it. Thanks for clearing 
> that up.
>
> Animesh> So Marcus this is not a -1 then right?
>
> On Fri, Nov 15, 2013 at 12:14 AM, Abhinandan Prateek 
>  wrote:
>> Marcus,
>>
>>   I am trying to understand the upgrade issue that you are facing.
>> It seems there were changes during various rounds of RC that we had 
>> for
>> 4.2.0 .
>> The fix that you have mentioned in the email actually got introduced 
>> in the 4.2 GA.
>> So someone upgrading to 4.2 GA will not have that constraint on the 
>> vpc_service_map table.
>>
>>  Just for clarity this does not affect the upgrade from 4.2 GA to 4.2.1.
>> If you have any doubts please specify those with clarity so these it 
>> can get rectified at the earliest.
>>
>> David,
>>   I think it is still not a ³-1².
>>
>> -abhi
>>
>> On 15/11/13 10:40 am, "Marcus Sorensen"  wrote:
>>
>>>Yes, I'd say that upgrade from 4.2.0 to 4.2.1 needs to work.
>>>On Nov 14, 2013 5:58 PM, "David Nalley"  wrote:
>>>
 Marcus:

 Is this is a -1?

 I don't have any legal concerns, and the release builds and tests 
 for me (though I haven't tried VPC).  I am somewhat concerned about 
 what appears to be drifting away from adhering to semver. (features 
 appear to have made it into the 4.2.1 release that weren't in 
 4.2.0) and I am also concerned about sys vm update fatigue, 
 especially given the problems we had in 4.2.0 around sysvm updates.

 --David

 On Thu, Nov 14, 2013 at 1:08 PM, Marcus Sorensen 
 
 wrote:
 > Yeah, I understand that 4.2.0 had a lot of post-release work needed.
 >
 > We are unable to create VPNs.  This is reported second hand from 
 > one of my admins. He seems to think that it was caused by the 
 > following, which added a for loop inside a for loop. The error is:
 >

'com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationEx
c
epti
on:
 > Duplicate entry '146-Lb' for key 'vpc_id'
 >
 > We did the following to fix it, something should be added to the 
 > sql
 upgrade.
 > mysql -D cloud -t -e 'alter table vpc_service_map drop key 
 > vpc_id, add unique key vpc_id (vpc_id,service,provider)'
 >
 >
 > commit 9050cfad3da673370d6ad1ed7570e31314069996
 >
 > CLOUDSTACK-4704: 41-42 db upgrade - populate vpc_service_map 
 > table with the services/providers supported by VPC
 >
 >
 >  @Override
 >  @DB
 > -public void persistVpcServiceProviders(long vpcId, Map>>> > String> serviceProviderMap) {
 > +public void persistVpcServiceProviders(long vpcId, 
 > + Map>>> > List> serviceProviderMap) {
 >  Transaction txn = Transaction.currentTxn();
 >  txn.start();
 >  for (String service : serviceProviderMap.keySet()) {
 > -VpcServiceMapVO serviceMap = new VpcServiceMapVO(vpcId,
 > Network.Service.getService(service),
 > Network.Provider.getProvider(serviceProviderMap.get(service)));
 > -_vpcSvcMap.persist(serviceMap);
 > +for (String provider : serviceProviderMap.get(service)) {
 > +VpcServiceMapVO serviceMap = new
 > VpcServiceMapVO(vpcId, Network.Service.getService(service),
 > Network.Provider.getProvider(provider));
 > +_vpcSvcMap.persist(serviceMap);
 > +}
 >  }
 >  txn.commit();
 >  }
 >
 >
 > On Thu, Nov 14, 2013 at 9:40 AM,

Re: [VOTE] Release Apache CloudStack 4.2.1

[David Nalley]

>
> For sanity in tallying the vote, can PMC members please be sure to indicate 
> "(binding)" with their vote?
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)


+1 (binding) (with the assumption that we won't announce until after
docs are finished)

Verified sigs and hashes, checked rat run, built, ran unit tests,
built RPMs and tested some simple VM lifecycle

--David

Re: Trunk interface to VM

[Chiradeep Vittal]

You want to pass the vlan tags into a VM that is actually a XenServer?

On 11/14/13 3:02 PM, "Francois Gaudreault" 
wrote:

>Is there a way to assign a trunked interface to a VM running in CS? Like
>assign the entire guest interface. We have a use case where we need to run
>XenServer hosts within a cloudstack managed infra.
>
>Thanks!
>
>Francois

Re: A question on vm migrations when hosts are set into a maintenance mode.

[Prasanna Santhanam]

Alex, Could you just do a git blame on the file and copy the emails of
people who changed that bit of code? They may be able to help if Cc-ed
directly.

Thanks,

On Fri, Nov 15, 2013 at 01:49:07PM -0600, Alex Ough wrote:
> I hate to sending the same emails over and over again, but I really need to
> finalize this feature to be included in the next code freeze because this
> feature is very critical in our inside project.
> 
> Anyone who can help, please?
> Thanks
> Alex Ough
> 
> 
> On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough  wrote:
> 
> > Not sure if Alex Huang checked this, but can anyone help to resolve this?
> >
> > Thanks
> > Alex Ough
> >
> >
> > On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough  wrote:
> >
> >> It sounds a little scary...
> >>
> >> I looked at the history and found these.
> >>
> >> 8/9/ : file moved to engine by Alex Huang
> >> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
> >> 'getExecuteInSequence()' by Alex Huang
> >>
> >>
> >> Hi Alex Huang,
> >> I'm not sure if you're aware of this, but can you check this for me?
> >>
> >> Thanks
> >> Alex Ough
> >>
> >>
> >>
> >> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen 
> >> wrote:
> >>
> >>> I'm not sure. I know in the past when I've seen files change locations
> >>> it has also clobbered updates to that file. Someone branched, did the
> >>> reorganization work, and merged, while in-between the original file
> >>> changed.
> >>>
> >>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough 
> >>> wrote:
> >>> > All,
> >>> >
> >>> > While merging my changes to 4.3 branch, I found that the option,
> >>> > 'execute.in.sequence.hypervisor.commands' is NOT used in
> >>> Start/Stop/Copy
> >>> > commands in 'VirtualMachineManagerImpl.java' any more as below.
> >>> >
> >>> >
> >>> > *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
> >>> >
> >>> > *protected boolean getExecuteInSequence() {*
> >>> > * return false;*
> >>> > *}*
> >>> >
> >>> > As you see in the above, the function, 'getExecuteInSequence', just
> >>> returns
> >>> > false instead of getting the value from the global variable.
> >>> >
> >>> > And one more change is that the file has been moved to
> >>> > 'engine/orchestration/src/com/cloud/vm' from 'server/src/com/cloud/vm'.
> >>> >
> >>> > Am I missing something related with this or do we stop supporting this
> >>> > option in 4.3?
> >>> > I'm a little confused, so please help me resolve this.
> >>> >
> >>> > Thanks
> >>> > Alex Ough
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough 
> >>> wrote:
> >>> >
> >>> >> Thanks a lot for your confirmation, Marcus.
> >>> >> I'll create a review request unless anyone has an objection.
> >>> >>
> >>> >> Thanks
> >>> >> Alex Ough
> >>> >>
> >>> >>
> >>> >> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen  >>> >wrote:
> >>> >>
> >>> >>>  I have done parallel KVM migrations without issue, it's "supposed to
> >>> >>> work". Really I think it's in the same boat as parallel start/stop.
> >>> It
> >>> >>> should work, but the config option is there just in case. I think we
> >>> >>> should add it.
> >>> >>>
> >>> >>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
> >>> >>>  wrote:
> >>> >>> > On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
> >>> >>> >> I'm not sure what else commands 'MigrateCommand' actually execute
> >>> in
> >>> >>> >> addition to 'Start/Stop/CopyCommand', but can we include
> >>> >>> 'MigrateCommand'
> >>> >>> >> if it consists of only those 3 commands?
> >>> >>> >>
> >>> >>> >> Thanks
> >>> >>> >> Alex Ough
> >>> >>> >
> >>> >>> > In the case of VMware, the migrate command is executed via the
> >>> >>> > MigrateVMTask that's part of the VMware SDK (see
> >>> >>> >
> >>> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
> >>> >>> >
> >>> >>> > For VMware, I know that vCenter will queue and process concurrent
> >>> >>> > requests for migrations.  Specifically, it will throttle the
> >>> migrations
> >>> >>> > happening, based on it's internal concurrency constraints, but the
> >>> task
> >>> >>> > queue will still accept more connections.  Obviously the risk are
> >>> the
> >>> >>> > VMware layer tasks timing out if it takes too long for the task
> >>> queue to
> >>> >>> > complete.
> >>> >>> >
> >>> >>> > As for XenServer, it's happening in what appears to be a similar
> >>> way
> >>> >>> > (although the source host is the target for the migration API
> >>> call).
> >>> >>> >
> >>> >>> > Check
> >>> >>> >
> >>> >>>
> >>> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
> >>> >>> >
> >>> >>> > I'm not familiar enough with XenServer's concurrency model for
> >>> >>> > migrations.  Any experts know the answer to if it can handle
> >>> concurrency
> >>> >>> > in a stable way?
> >>> >>> >
> >>> >>> > With KVM, it's obviously executing via the agent.  Similarly to
> >>> >>> > XenServer, I'm not familiar enough to know about concurrent
> >>> operations.
> >>> >>> >
> 

Re: Upgrading nitro API to 10.1

[Prasanna Santhanam]

On Fri, Nov 15, 2013 at 01:36:49PM -0500, Syed Ahmed wrote:
> Hi All,
> 
> I was wondering if it was possible to update the nitro packet which
> is required for Netscaler API from 10.0 to 10.1. The new 10.1
> supports the "bundle" parameter which makes it possible to upload
> certificate and the trust chain in a single file which makes it very
> easy for certificate management.

q1. Is this a jar update?
q2. Is the corresponding source here - https://github.com/netscaler/nitro?

> 
> Thanks,
> -Syed

-- 
Prasanna.,


Powered by BigRock.com

Re: Upgrading nitro API to 10.1

[Syed Ahmed]

Yes Prasanna. This is a jar upgrade and yes that is the source code. 
This means that we could remove the noredist from netscaler plugin.


Thanks,
-Syed


On Fri 15 Nov 2013 10:26:51 PM EST, Prasanna Santhanam wrote:

On Fri, Nov 15, 2013 at 01:36:49PM -0500, Syed Ahmed wrote:

Hi All,

I was wondering if it was possible to update the nitro packet which
is required for Netscaler API from 10.0 to 10.1. The new 10.1
supports the "bundle" parameter which makes it possible to upload
certificate and the trust chain in a single file which makes it very
easy for certificate management.


q1. Is this a jar update?
q2. Is the corresponding source here - https://github.com/netscaler/nitro?



Thanks,
-Syed

Re: Upgrading nitro API to 10.1

[Prasanna Santhanam]

that should be ok - i was supposed to have moved the netscaler plugin
from noredist to oss but never got around to it. would you be able to
take that up as part of your change?

On Fri, Nov 15, 2013 at 10:29:56PM -0500, Syed Ahmed wrote:
> Yes Prasanna. This is a jar upgrade and yes that is the source code.
> This means that we could remove the noredist from netscaler plugin.
> 
> Thanks,
> -Syed
> 
> 
-- 
Prasanna.,


Powered by BigRock.com

Re: Upgrading nitro API to 10.1

[Syed Ahmed]

Sure. No problems.

Thanks,
-Syed

On Fri 15 Nov 2013 10:35:04 PM EST, Prasanna Santhanam wrote:

that should be ok - i was supposed to have moved the netscaler plugin
from noredist to oss but never got around to it. would you be able to
take that up as part of your change?

On Fri, Nov 15, 2013 at 10:29:56PM -0500, Syed Ahmed wrote:

Yes Prasanna. This is a jar upgrade and yes that is the source code.
This means that we could remove the noredist from netscaler plugin.

Thanks,
-Syed

Re: Upgrading nitro API to 10.1

[Prasanna Santhanam]

awesome. thanks syed!

On Fri, Nov 15, 2013 at 10:39:18PM -0500, Syed Ahmed wrote:
> Sure. No problems.
> 
> Thanks,
> -Syed
> 
> On Fri 15 Nov 2013 10:35:04 PM EST, Prasanna Santhanam wrote:
> >that should be ok - i was supposed to have moved the netscaler plugin
> >from noredist to oss but never got around to it. would you be able to
> >take that up as part of your change?
> >
> >On Fri, Nov 15, 2013 at 10:29:56PM -0500, Syed Ahmed wrote:
> >>Yes Prasanna. This is a jar upgrade and yes that is the source code.
> >>This means that we could remove the noredist from netscaler plugin.
> >>
> >>Thanks,
> >>-Syed
> >>
> >>
> 

-- 
Prasanna.,


Powered by BigRock.com

Re: Upgrading nitro API to 10.1

[Will Stevens]

@Syed: I just did that for the Palo Alto plugin, so let me know if you have
questions...

Will


On Fri, Nov 15, 2013 at 10:42 PM, Prasanna Santhanam  wrote:

> awesome. thanks syed!
>
> On Fri, Nov 15, 2013 at 10:39:18PM -0500, Syed Ahmed wrote:
> > Sure. No problems.
> >
> > Thanks,
> > -Syed
> >
> > On Fri 15 Nov 2013 10:35:04 PM EST, Prasanna Santhanam wrote:
> > >that should be ok - i was supposed to have moved the netscaler plugin
> > >from noredist to oss but never got around to it. would you be able to
> > >take that up as part of your change?
> > >
> > >On Fri, Nov 15, 2013 at 10:29:56PM -0500, Syed Ahmed wrote:
> > >>Yes Prasanna. This is a jar upgrade and yes that is the source code.
> > >>This means that we could remove the noredist from netscaler plugin.
> > >>
> > >>Thanks,
> > >>-Syed
> > >>
> > >>
> >
>
> --
> Prasanna.,
>
> 
> Powered by BigRock.com
>
>

Re: Upgrading nitro API to 10.1

[Syed Ahmed]

Thanks Will. Will Do.


On Fri 15 Nov 2013 10:52:27 PM EST, Will Stevens wrote:

@Syed: I just did that for the Palo Alto plugin, so let me know if you
have questions...

Will


On Fri, Nov 15, 2013 at 10:42 PM, Prasanna Santhanam mailto:t...@apache.org>> wrote:

awesome. thanks syed!

On Fri, Nov 15, 2013 at 10:39:18PM -0500, Syed Ahmed wrote:
> Sure. No problems.
>
> Thanks,
> -Syed
>
> On Fri 15 Nov 2013 10:35:04 PM EST, Prasanna Santhanam wrote:
> >that should be ok - i was supposed to have moved the netscaler
plugin
> >from noredist to oss but never got around to it. would you be
able to
> >take that up as part of your change?
> >
> >On Fri, Nov 15, 2013 at 10:29:56PM -0500, Syed Ahmed wrote:
> >>Yes Prasanna. This is a jar upgrade and yes that is the source
code.
> >>This means that we could remove the noredist from netscaler
plugin.
> >>
> >>Thanks,
> >>-Syed
> >>
> >>
>

--
Prasanna.,


Powered by BigRock.com

Re: Trunk interface to VM

[Francois Gaudreault]

Yes. We want to be able spin XS within CloudStack. We also need those XS to
consume VLAN tags to do advanced networking (kind of CS inside CS). Lets
say we do have devs with ambitious needs :)

Francois
On 2013-11-15 9:46 PM, "Chiradeep Vittal" 
wrote:

> You want to pass the vlan tags into a VM that is actually a XenServer?
>
> On 11/14/13 3:02 PM, "Francois Gaudreault" 
> wrote:
>
> >Is there a way to assign a trunked interface to a VM running in CS? Like
> >assign the entire guest interface. We have a use case where we need to run
> >XenServer hosts within a cloudstack managed infra.
> >
> >Thanks!
> >
> >Francois
>
>