date:20140725

Rightful question Erik,

Rajani mentioned that release branches will be deleted. This will only
happen once the release is no longer supported. Any hotfix branch will
still have to merged on that (and master possibly) until we stop
supporting that branch.

On the other hand you can branch from any commit.

btw 4.4.1 is a bad example of you as we will still maintain that
without gitflow. But it is valid for for instance 4.5.2 or 5.0.1.

On Fri, Jul 25, 2014 at 8:04 AM, Erik Weber  wrote:
> This is out of my git league, but how do you handle minor versions that way?
>
> Assuming 4.8.0 is the latest stable release and HEAD on master.
>
> Then you want to release 4.4.1.
>
> First of all can you develop bugfixes for 4.4 along the way, when both
> develop and master HEAD might be hugely different?
>
> Second, can you commit  behind HEAD? You don't want the 4.4.1 release
> instead of 4.8.0 to be HEAD
>
> Someone might have good solutions to this, but if not I would propose to
> keep the release branches for future bugfixes.
>
> Erik
> 25. juli 2014 06:02 skrev "Rajani Karuturi" 
> følgende:
>
>> On 24-Jul-2014, at 10:25 pm, Mike Tutkowski 
>> wrote:
>>
>> > I believe I agree with these steps.
>> >
>> > A couple questions:
>> >
>> > Is 'master' simply always going to be equal to what's the most recent
>> > version of the code that's in production?
>>
>> I think so. master will always be at the latest release and all the
>> previous releases properly tagged. The release branches would be deleted
>> once release is done.
>>
>> >
>> > Also, would 'develop' be for 4.6 code then and 4.5 code would go directly
>> > into RELEASE-4.5?
>> >
>>
>> Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes
>> should be done on the 4.5 branch.
>>
>>
>>
>> ~Rajani
>>
>>
>> >
>> > On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi <
>> > rajani.karut...@citrix.com> wrote:
>> >
>> >>
>> >> Hi Daan,
>> >> here is what i propose:
>> >>
>> >> 1. rename 'master' to 'develop’
>> >> 2. branch a new 'master' from '4.4’
>> >> 3. branch 'RELEASE-4.5' from the develop
>> >> 4. merge 'RELEASE-4.5' to master once the release voting is done.
>> >>
>> >> RELEASE-4.6 branch should be off develop as all the feature branches
>> would
>> >> be merged there before freeze for 4.6 and would be merged to master when
>> >> the release is voted.
>> >>
>> >> The other question I have is in the step:4. how are we going to manage
>> >> fixes to 4.5 post branch cut?  ( assuming no features as the freeze is
>> done)
>> >>
>> >> ~Rajani
>> >>
>> >>
>> >>
>> >> On 24-Jul-2014, at 11:52 am, Daan Hoogland 
>> >> wrote:
>> >>
>> >>> Mike, Rajani,
>> >>>
>> >>> Sebastien's point was that the current 4.4 is the closest we have to a
>> >>> releasable branch. I don't mind enting on master but it will require
>> >>> more fixing. In general all of this will require some RM work of all
>> >>> committers. Please ammend my little proposal if you will.
>> >>>
>> >>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
>> >>>  wrote:
>>  I agree with mike. I think we should start 4.5 from where master is
>> now
>>  Also create a develop branch from master and continue future work for
>> >> 4.6 there.
>> 
>>  I am not clear on how the release branches are going to be maintained.
>>  Are we saying we would create 4.5-RELEASE branch which is essentially
>> >> same as our current -FORWARD branch and continue cherry-picking?
>> 
>>  I would prefer merges to cherry-picks.
>>  Also, I think we should allow committers to commit to the RELEASE
>> >> branch after discussing about it on dev@ and have RM closely monitor
>> them.
>>  Any commit intended for 4.5 RELEASE should be checked in after
>> >> discussion in the 4.5 Release branch and then merged to develop branch.
>> 
>> 
>>  ~Rajani
>> 
>> 
>> 
>>  On 24-Jul-2014, at 1:14 am, Mike Tutkowski <
>> >> mike.tutkow...@solidfire.com> wrote:
>> 
>> > Per earlier e-mails, I don't think we want to start 4.5 where 4.4
>> left
>> >> off
>> > and then merge features from develop into 4.5.
>> >
>> > Why don't we instead start 4.5 where master is now with the
>> assumption
>> >> that
>> > since we are past Feature Freeze for 4.5 that master is stable
>> enough?
>> >
>> >
>> > On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <
>> >> daan.hoogl...@gmail.com>
>> > wrote:
>> >
>> >> so to start formulate a proposal:
>> >>
>> >> all work shall be done in a new branch (it is advisable to prefix
>> your
>> >> branches with your id)
>> >> when working, features will be cherry-picked/merged into the release
>> >> branch they are for and next into master.
>> >> hotfixes will be done in -hotfixes
>> >>
>> >> as transition we will
>> >>
>> >> rename 'master' to 'develop'
>> >> branch a new 'master' from '4.4'
>> >> branch '4.5' from the new 'master'
>> >> merge any features from the new

Re: Review Request 23915: Fixing some coverity reported issues


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


Looks ok, did you verify whether the called functions at all return null? If 
they don't this would seem a false positive. Your change wouldn't hurt anyhow.

- daan Hoogland


On July 25, 2014, 6:10 a.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23915/
> ---
> 
> (Updated July 25, 2014, 6:10 a.m.)
> 
> 
> Review request for cloudstack, Rajani Karuturi and Santhosh Kumar.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixing some coverity reported issues in CitrixResourceBase.java
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
>  71aa01e 
> 
> Diff: https://reviews.apache.org/r/23915/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Re: [CLOUDSTACK-6181] RBD Support not implemented

2014-07-25 Thread Wido den Hollander

On 07/24/2014 06:38 PM, Logan Barfield wrote:

I think I've found the cause of the resize failure. When using RBD for
primary storage the disk is not allocated before the VM starts. The resize
operation runs before the disk exists, and instead of failing completely it
just updates the database with the new disk size and returns success.
Deploying the VM in a stopped state doesn't work either, because the disk
isn't created until the VM starts.

Ah, ok. So that's something that has to be fixed there.

I've been able to get a resize operation to work by manually running
deployVM -> wait for ~5 seconds -> resizeVolume. This obviously doesn't
help when passing the 'rootdisksize' parameter to deployVM.

True, true. Weird however that the resize runs prior to the creation of
the drive.

To fix this I think the deployment logic would need to be changed to
allocate the VM's disk before starting it, or to run the resize operation
once the disk has been created. I'm assuming the only reason this issue is
appearing with RBD is due to how templates are deployed from an RBD
snapshot instead of being copied from secondary storage every time.

Thoughts?

Fully agree with you. I think the logic sounds sane.

Wido

Thank You,

Logan Barfield
Tranquil Hosting

On Wed, Jul 23, 2014 at 7:13 PM, Logan Barfield
wrote:

The change I mentioned appears to fix the resize error. Resizing the root
disk with deployVM still doesn't work however.

To test I created a VM from a 5GB template with "rootdisksize" = "20".
The VM is successfully created, and CloudStack lists the ROOT volume as
20GB, but the RBD volume is still 5GB in size.

Resizing the volume manually via virsh seems to work fine. I'll look
through it again tomorrow.

Thank You,

Logan Barfield
Tranquil Hosting

On Wed, Jul 23, 2014 at 5:49 PM, Logan Barfield
wrote:

Just an FYI, RBD resizing still fails because libvirt is throwing an
invalid flags error. I'm testing the following patch:

plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java:

-if (conn.getLibVirVersion() > 1001000 &&
vol.getFormat() == PhysicalDiskFormat.RAW) {
+if (conn.getLibVirVersion() > 1001000 &&
vol.getFormat() == PhysicalDiskFormat.RAW && pool.getType() !=
StoragePoolType.RBD) {
flags = 1;
}

If it resolves the issue I'll submit it.

Thank You,

Logan Barfield
Tranquil Hosting

On Tue, Jul 22, 2014 at 4:38 PM, Logan Barfield
wrote:

Wido,

Excellent. As long as it passes testing we'll be golden.

Thank You,

Logan Barfield
Tranquil Hosting

On Tue, Jul 22, 2014 at 4:30 PM, Wido den Hollander
wrote:

On 07/22/2014 10:13 PM, Logan Barfield wrote:

Wido,

I appreciate the confirmation. Would you mind posting an update here
when
you've submitted the patch? As I mentioned in another post we will
probably end up just having to go into production with a non-official
build. We won't be able to wait for 4.5 or 4.4.x unfortunately.

I just pushed a patch: https://git-wip-us.apache.org/
repos/asf?p=cloudstack.git;a=commitdiff;h=
173909e99d85cfcc85b017bc426950f9f16fddf0

That should also apply on 4.4 very easily, a simple cherry-pick should
be sufficient.

Wido

Thank You,

Logan Barfield
Tranquil Hosting

On Tue, Jul 22, 2014 at 4:09 PM, Wido den Hollander
wrote:

On 07/22/2014 09:53 PM, Logan Barfield wrote:

I was testing on a recent 4.4 build today and noticed that volume

resizing
for RBD volumes is not working as intended.

In LibvirtComputingResource.java the 'getResizeScriptType()' function
doesn't have logic for type = RBD and format = RAW or QCOW2, so it
returns
'null' and the resize operation fails.

In CLOUDSTACK-6181 there was some discussion regarding RBD support,
and it
was signed off on by Wido (who appears to be the only contributor
actively
supporting Ceph in CloudStack). Was the mentioned functionality just
never
implemented, or am I overlooking something?

So it seems you are right. I can't remember anymore why I signed it

off
(probably because it worked locally), but what you are saying is true.

RBD are block devices which do not exist in kernel space, so a script
can
never check if the volume exists.

The fix is rather simple, since libvirt can resize the volume it's
just a
matter of a few if-statements in LibvirtComputing resouce, I'll get
right
to that, but it will never make it into 4.4. Hopefully 4.4.1

Wido

Thank You,

Logan Barfield
Tranquil Hosting

Re: Review Request 23915: Fixing some coverity reported issues


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



plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java


please log a message incase rec is null


- Rajani Karuturi


On July 25, 2014, 6:10 a.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23915/
> ---
> 
> (Updated July 25, 2014, 6:10 a.m.)
> 
> 
> Review request for cloudstack, Rajani Karuturi and Santhosh Kumar.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixing some coverity reported issues in CitrixResourceBase.java
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
>  71aa01e 
> 
> Diff: https://reviews.apache.org/r/23915/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

editting the website

I am sure I should know this: How do I edit the downloads.html on
cloudstack.apache.org? Is this in a apacha cms or do we have it in a
'private' svn somewhere?

-- 
Daan

Re: [DISCUSS][PROPOSAL] git workflow

I went on and read the comments in
http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html

It contains a big warning on using gitflow that has been between my
lines in this thread all along. Git flow is not going to solve our
problem. It is a discipline that is captured in it that will save us.
Please everybody educate yourselves on the subject. If we are going to
get along as a community we need to get this right. We'll be able to
support old releases and make new ones just like we dream. gitflow
wont give us that by itself.

Daan (sounding desperate and impatient but being eager)

On Fri, Jul 25, 2014 at 9:01 AM, Daan Hoogland  wrote:
> Rightful question Erik,
>
> Rajani mentioned that release branches will be deleted. This will only
> happen once the release is no longer supported. Any hotfix branch will
> still have to merged on that (and master possibly) until we stop
> supporting that branch.
>
> On the other hand you can branch from any commit.
>
> btw 4.4.1 is a bad example of you as we will still maintain that
> without gitflow. But it is valid for for instance 4.5.2 or 5.0.1.
>
> On Fri, Jul 25, 2014 at 8:04 AM, Erik Weber  wrote:
>> This is out of my git league, but how do you handle minor versions that way?
>>
>> Assuming 4.8.0 is the latest stable release and HEAD on master.
>>
>> Then you want to release 4.4.1.
>>
>> First of all can you develop bugfixes for 4.4 along the way, when both
>> develop and master HEAD might be hugely different?
>>
>> Second, can you commit  behind HEAD? You don't want the 4.4.1 release
>> instead of 4.8.0 to be HEAD
>>
>> Someone might have good solutions to this, but if not I would propose to
>> keep the release branches for future bugfixes.
>>
>> Erik
>> 25. juli 2014 06:02 skrev "Rajani Karuturi" 
>> følgende:
>>
>>> On 24-Jul-2014, at 10:25 pm, Mike Tutkowski 
>>> wrote:
>>>
>>> > I believe I agree with these steps.
>>> >
>>> > A couple questions:
>>> >
>>> > Is 'master' simply always going to be equal to what's the most recent
>>> > version of the code that's in production?
>>>
>>> I think so. master will always be at the latest release and all the
>>> previous releases properly tagged. The release branches would be deleted
>>> once release is done.
>>>
>>> >
>>> > Also, would 'develop' be for 4.6 code then and 4.5 code would go directly
>>> > into RELEASE-4.5?
>>> >
>>>
>>> Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes
>>> should be done on the 4.5 branch.
>>>
>>>
>>>
>>> ~Rajani
>>>
>>>
>>> >
>>> > On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi <
>>> > rajani.karut...@citrix.com> wrote:
>>> >
>>> >>
>>> >> Hi Daan,
>>> >> here is what i propose:
>>> >>
>>> >> 1. rename 'master' to 'develop’
>>> >> 2. branch a new 'master' from '4.4’
>>> >> 3. branch 'RELEASE-4.5' from the develop
>>> >> 4. merge 'RELEASE-4.5' to master once the release voting is done.
>>> >>
>>> >> RELEASE-4.6 branch should be off develop as all the feature branches
>>> would
>>> >> be merged there before freeze for 4.6 and would be merged to master when
>>> >> the release is voted.
>>> >>
>>> >> The other question I have is in the step:4. how are we going to manage
>>> >> fixes to 4.5 post branch cut?  ( assuming no features as the freeze is
>>> done)
>>> >>
>>> >> ~Rajani
>>> >>
>>> >>
>>> >>
>>> >> On 24-Jul-2014, at 11:52 am, Daan Hoogland 
>>> >> wrote:
>>> >>
>>> >>> Mike, Rajani,
>>> >>>
>>> >>> Sebastien's point was that the current 4.4 is the closest we have to a
>>> >>> releasable branch. I don't mind enting on master but it will require
>>> >>> more fixing. In general all of this will require some RM work of all
>>> >>> committers. Please ammend my little proposal if you will.
>>> >>>
>>> >>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
>>> >>>  wrote:
>>>  I agree with mike. I think we should start 4.5 from where master is
>>> now
>>>  Also create a develop branch from master and continue future work for
>>> >> 4.6 there.
>>> 
>>>  I am not clear on how the release branches are going to be maintained.
>>>  Are we saying we would create 4.5-RELEASE branch which is essentially
>>> >> same as our current -FORWARD branch and continue cherry-picking?
>>> 
>>>  I would prefer merges to cherry-picks.
>>>  Also, I think we should allow committers to commit to the RELEASE
>>> >> branch after discussing about it on dev@ and have RM closely monitor
>>> them.
>>>  Any commit intended for 4.5 RELEASE should be checked in after
>>> >> discussion in the 4.5 Release branch and then merged to develop branch.
>>> 
>>> 
>>>  ~Rajani
>>> 
>>> 
>>> 
>>>  On 24-Jul-2014, at 1:14 am, Mike Tutkowski <
>>> >> mike.tutkow...@solidfire.com> wrote:
>>> 
>>> > Per earlier e-mails, I don't think we want to start 4.5 where 4.4
>>> left
>>> >> off
>>> > and then merge features from develop into 4.5.
>>> >
>>> > Why don't we instead start 4.5 where master is now with the
>>> assumption
>

Review Request 23918: CLOUDSTACK-7180: Tagging test case with product bug ID


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

Review request for cloudstack and Girish Shilamkar.


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


Repository: cloudstack-git


Description
---

Tagging test case with product Bug ID - CLOUDSTACK-7180


Diffs
-

  test/integration/component/test_dynamic_compute_offering.py 3939777 

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


Testing
---


Thanks,

Gaurav Aradhye

Re: Review Request 23843: Removed duplicated code block


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

Ship it!


ad640e2fda383dde56fbb02504678e5971e2a2b9

- daan Hoogland


On July 23, 2014, 11:40 a.m., Miguel Ferreira wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23843/
> ---
> 
> (Updated July 23, 2014, 11:40 a.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, sanjeev n, and Hugo Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Removed duplicated code block in method to create service offering.
> The clone was setting storage type just a few lines bellow another code block 
> that does the same.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/lib/base.py 8d40591 
> 
> Diff: https://reviews.apache.org/r/23843/diff/
> 
> 
> Testing
> ---
> 
> Tests I'm running that create service offerings produce the same results 
> before and after the change.
> 
> 
> Thanks,
> 
> Miguel Ferreira
> 
>

Re: Review Request 23395: CLOUDSTACK-5663 :- Handled the NULL check for network's cidr field to avoid NPE for createNetwork and listNetwork


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



server/src/com/cloud/network/NetworkModelImpl.java


Makes sense but shouldn't this check be done inside 
getAvailableIps(network, null)?


- daan Hoogland


On July 24, 2014, 10:45 a.m., Girish Chaudhari wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23395/
> ---
> 
> (Updated July 24, 2014, 10:45 a.m.)
> 
> 
> Review request for cloudstack, daan Hoogland and Parth Jagirdar.
> 
> 
> Bugs: CLOUDSTACK-5663
> https://issues.apache.org/jira/browse/CLOUDSTACK-5663
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-5663 - API:MS: Network with NULL CIDR raises NPE for createNetwork 
> and listNetwork
> 
> Root Cause:
> In the listNetworks and createNetworks API execution flow, existing networks 
> analysed to check whether they can be used for deploy. In this step, all the 
> available IPs are calculated using the Network CIDR. In case the CIDR is NULL 
> it results into the NPE. 
> 
> Solution:
> Added the NULL check to avoid NPE, in case of NULL CIDR, API populate the 
> "canusefordeploy" attribute as false.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/network/NetworkModelImpl.java 0ef5cb9 
> 
> Diff: https://reviews.apache.org/r/23395/diff/
> 
> 
> Testing
> ---
> 
> Tested on master for listNetworks and createNetwork command with NULL network 
> cidr. 
> 
> 
> Thanks,
> 
> Girish Chaudhari
> 
>

Re: Review Request 23915: Fixing some coverity reported issues



> On July 25, 2014, 7:05 a.m., daan Hoogland wrote:
> > Looks ok, did you verify whether the called functions at all return null? 
> > If they don't this would seem a false positive. Your change wouldn't hurt 
> > anyhow.

I checked the xen code base they are returning null values as well.


- Damodar Reddy


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


On July 25, 2014, 6:10 a.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23915/
> ---
> 
> (Updated July 25, 2014, 6:10 a.m.)
> 
> 
> Review request for cloudstack, Rajani Karuturi and Santhosh Kumar.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixing some coverity reported issues in CitrixResourceBase.java
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
>  71aa01e 
> 
> Diff: https://reviews.apache.org/r/23915/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Re: Review Request 23915: Fixing some coverity reported issues


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

(Updated July 25, 2014, 9:12 a.m.)


Review request for cloudstack, Rajani Karuturi and Santhosh Kumar.


Changes
---

incorporated Rajain's comments


Repository: cloudstack-git


Description
---

Fixing some coverity reported issues in CitrixResourceBase.java


Diffs (updated)
-

  
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
 71aa01e 

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


Testing
---


Thanks,

Damodar Reddy Talakanti

Review Request 23920: CLOUDSTACK-7181: Skip tests on KVM - changing service offering when VM is in running state - not supported on KVM


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

Review request for cloudstack and Girish Shilamkar.


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


Repository: cloudstack-git


Description
---

Skipping the tests which try to change the service offering of VM when it is in 
running state on KVM as the feature is not supported for KVM hypervisor.


Diffs
-

  test/integration/component/test_dynamic_compute_offering.py 3939777 

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


Testing
---

yes.


Thanks,

Gaurav Aradhye

Re: editting the website

2014-07-25 Thread Ian Duffy

https://svn.apache.org/repos/asf/cloudstack/site/trunk

Anything committed to there will get built to:
cloudstack.staging.apache.org

Once you are happy, we can publish via the cms:
https://cms.apache.org/cloudstack/publish

Its all password protected with your apache id/password.



On 25 July 2014 08:19, Daan Hoogland  wrote:

> I am sure I should know this: How do I edit the downloads.html on
> cloudstack.apache.org? Is this in a apacha cms or do we have it in a
> 'private' svn somewhere?
>
> --
> Daan
>

Review Request 23922: Fixed CLOUDSTACK-6980: UI for RegisterTemplate API does not expose requireshvm parameter


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

Review request for cloudstack and Jessica Wang.


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


Repository: cloudstack-git


Description
---

added requireshvm to the create form fields


Diffs
-

  client/WEB-INF/classes/resources/messages.properties 271ffec 
  ui/dictionary.jsp beb082b 
  ui/scripts/docs.js 2075e30 
  ui/scripts/templates.js e12927c 

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


Testing
---

manually tested register template


Thanks,

Rajani Karuturi

Re: Review Request 23915: Fixing some coverity reported issues


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

Ship it!


Ship It!

- Rajani Karuturi


On July 25, 2014, 9:12 a.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23915/
> ---
> 
> (Updated July 25, 2014, 9:12 a.m.)
> 
> 
> Review request for cloudstack, Rajani Karuturi and Santhosh Kumar.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixing some coverity reported issues in CitrixResourceBase.java
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
>  71aa01e 
> 
> Diff: https://reviews.apache.org/r/23915/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Re: Review Request 23915: Fixing some coverity reported issues



> On July 25, 2014, 10:11 a.m., Rajani Karuturi wrote:
> > Ship It!

commit 0a5940c9a80cfff827c469f92640a70b9037829a
Author: Damodar 
AuthorDate: Fri Jul 25 14:40:21 2014 +0530
Commit: Rajani Karuturi 
CommitDate: Fri Jul 25 15:34:20 2014 +0530

Coverity: Fixing some of the coverity issues reported in 
CitrixResourceBase.java.

Signed-off-by: Rajani Karuturi 


- Rajani


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


On July 25, 2014, 9:12 a.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23915/
> ---
> 
> (Updated July 25, 2014, 9:12 a.m.)
> 
> 
> Review request for cloudstack, Rajani Karuturi and Santhosh Kumar.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixing some coverity reported issues in CitrixResourceBase.java
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
>  71aa01e 
> 
> Diff: https://reviews.apache.org/r/23915/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Review Request 23924: Fixed some more Coverity issues in CitrixResourceBase.java


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

Review request for cloudstack, Jayapal Reddy and Rajani Karuturi.


Repository: cloudstack-git


Description
---

Fixed some more Coverity reported issues in CitrixResourceBase.java.

Coverity issue ids are : 1222191, 1222186, 1222185, 1222181, 1222180


Diffs
-

  
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
 e961250 

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


Testing
---


Thanks,

Damodar Reddy Talakanti

SSL keystore file name

2014-07-25 Thread Kishan Kavala

SSl keystore was changed from cloud.keystore to cloudmanagementserver.keystore 
with below commit [1]. Later, related code change were over-written in commit 
[2]. I made changes [3] to keep keystore filename as 
cloudmanagementserver.keystore in all references. 
Please let me know if you see any issues.

[1] 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=57ba367f3c985e80ea1b34267e298b481a353298
[2] 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=2774b62d64989bddc1e4664ef7a93dff11c77657
[3] 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=c61c636ce8a1d74fd22d89026d40ba904fff6cf8

Re: [DISCUSS][PROPOSAL] git workflow

branches will be deleted after the release or hotfix if you use the git-flow 
commands.

This would be the flow for a hotfix:
1. branch off from the release tag on master. in this case it would be 
release/4.4.0 
2. commit the fixes in hotfix/4.4.1
3. do the release
4. merge to develop
5. merge to master and update tags
6. delete hotfix branch

But, I agree that there can be a problem when we wish to do 4.4.2 if we delete 
the hotfix branch

may be we should use git-flow support instead of hotfix which doesn’t delete 
the branch
http://stackoverflow.com/a/16866118/201514

~Rajani



On 25-Jul-2014, at 12:31 pm, Daan Hoogland  wrote:

> Rightful question Erik,
> 
> Rajani mentioned that release branches will be deleted. This will only
> happen once the release is no longer supported. Any hotfix branch will
> still have to merged on that (and master possibly) until we stop
> supporting that branch.
> 
> On the other hand you can branch from any commit.
> 
> btw 4.4.1 is a bad example of you as we will still maintain that
> without gitflow. But it is valid for for instance 4.5.2 or 5.0.1.
> 
> On Fri, Jul 25, 2014 at 8:04 AM, Erik Weber  wrote:
>> This is out of my git league, but how do you handle minor versions that way?
>> 
>> Assuming 4.8.0 is the latest stable release and HEAD on master.
>> 
>> Then you want to release 4.4.1.
>> 
>> First of all can you develop bugfixes for 4.4 along the way, when both
>> develop and master HEAD might be hugely different?
>> 
>> Second, can you commit  behind HEAD? You don't want the 4.4.1 release
>> instead of 4.8.0 to be HEAD
>> 
>> Someone might have good solutions to this, but if not I would propose to
>> keep the release branches for future bugfixes.
>> 
>> Erik
>> 25. juli 2014 06:02 skrev "Rajani Karuturi" 
>> følgende:
>> 
>>> On 24-Jul-2014, at 10:25 pm, Mike Tutkowski 
>>> wrote:
>>> 
 I believe I agree with these steps.
 
 A couple questions:
 
 Is 'master' simply always going to be equal to what's the most recent
 version of the code that's in production?
>>> 
>>> I think so. master will always be at the latest release and all the
>>> previous releases properly tagged. The release branches would be deleted
>>> once release is done.
>>> 
 
 Also, would 'develop' be for 4.6 code then and 4.5 code would go directly
 into RELEASE-4.5?
 
>>> 
>>> Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes
>>> should be done on the 4.5 branch.
>>> 
>>> 
>>> 
>>> ~Rajani
>>> 
>>> 
 
 On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi <
 rajani.karut...@citrix.com> wrote:
 
> 
> Hi Daan,
> here is what i propose:
> 
> 1. rename 'master' to 'develop’
> 2. branch a new 'master' from '4.4’
> 3. branch 'RELEASE-4.5' from the develop
> 4. merge 'RELEASE-4.5' to master once the release voting is done.
> 
> RELEASE-4.6 branch should be off develop as all the feature branches
>>> would
> be merged there before freeze for 4.6 and would be merged to master when
> the release is voted.
> 
> The other question I have is in the step:4. how are we going to manage
> fixes to 4.5 post branch cut?  ( assuming no features as the freeze is
>>> done)
> 
> ~Rajani
> 
> 
> 
> On 24-Jul-2014, at 11:52 am, Daan Hoogland 
> wrote:
> 
>> Mike, Rajani,
>> 
>> Sebastien's point was that the current 4.4 is the closest we have to a
>> releasable branch. I don't mind enting on master but it will require
>> more fixing. In general all of this will require some RM work of all
>> committers. Please ammend my little proposal if you will.
>> 
>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
>>  wrote:
>>> I agree with mike. I think we should start 4.5 from where master is
>>> now
>>> Also create a develop branch from master and continue future work for
> 4.6 there.
>>> 
>>> I am not clear on how the release branches are going to be maintained.
>>> Are we saying we would create 4.5-RELEASE branch which is essentially
> same as our current -FORWARD branch and continue cherry-picking?
>>> 
>>> I would prefer merges to cherry-picks.
>>> Also, I think we should allow committers to commit to the RELEASE
> branch after discussing about it on dev@ and have RM closely monitor
>>> them.
>>> Any commit intended for 4.5 RELEASE should be checked in after
> discussion in the 4.5 Release branch and then merged to develop branch.
>>> 
>>> 
>>> ~Rajani
>>> 
>>> 
>>> 
>>> On 24-Jul-2014, at 1:14 am, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>>> 
 Per earlier e-mails, I don't think we want to start 4.5 where 4.4
>>> left
> off
 and then merge features from develop into 4.5.
 
 Why don't we instead start 4.5 where master is now with the
>>> assumption
> that
 since we are past Featu

Re: Review Request 23924: Fixed some more Coverity issues in CitrixResourceBase.java


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

(Updated July 25, 2014, 11:21 a.m.)


Review request for cloudstack, Jayapal Reddy, Murali Reddy, and Rajani Karuturi.


Changes
---

Adding Murali to the reviewers


Repository: cloudstack-git


Description
---

Fixed some more Coverity reported issues in CitrixResourceBase.java.

Coverity issue ids are : 1222191, 1222186, 1222185, 1222181, 1222180


Diffs
-

  
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
 e961250 

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


Testing
---


Thanks,

Damodar Reddy Talakanti

Review Request 23925: CLOUDSTACK-7183: Fixing cleanup issue in test_escalations_instances.py


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

Review request for cloudstack and Girish Shilamkar.


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


Repository: cloudstack-git


Description
---

The test case test_23_deply_vm_multiple_securitygroups fails because it tries 
to delete the security group before deleting the VMs in it.
Added different cleanup list for VMs for which cleanup will be executed before 
the regular cleanup list, and also passed expunge=True so that it is expunged 
immediately.


Diffs
-

  test/integration/component/test_escalations_instances.py 0cd8b68 

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


Testing
---

Yes.

tested on KVM basic zone with SG.


Thanks,

Gaurav Aradhye

Re: [DISCUSS][PROPOSAL] git workflow

On Fri, Jul 25, 2014 at 1:16 PM, Rajani Karuturi
 wrote:
> may be we should use git-flow support instead of hotfix which doesn’t delete 
> the branch


Good call Rajani

-- 
Daan

Review Request 23926: Removing basic tag from few test case which should not be run basic zone


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

Review request for cloudstack and Girish Shilamkar.


Repository: cloudstack-git


Description
---

Few of the Multiple Ips per NIC test cases had basic tags, removed them. The 
feature is not supported in basic zone.


Diffs
-

  test/integration/component/test_multiple_ips_per_nic.py abe9474 

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


Testing
---


Thanks,

Gaurav Aradhye

Review Request 23927: Skipping test instead of raising exception in case enough zones are not present for it to run on


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

Review request for cloudstack and Girish Shilamkar.


Repository: cloudstack-git


Description
---

The test case is raising exception if more than one zones are not present in 
the setup. In this case, it should be skipped.


Diffs
-

  test/integration/component/test_escalations_isos.py 387a681 

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


Testing
---

Yes.


Thanks,

Gaurav Aradhye

Review Request 23928: Test script to verify CS-5986 fix for vpc networks

2014-07-25 Thread sanjeev n


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

Review request for cloudstack and Santhosh Edukulla.


Bugs: CS-5986
https://issues.apache.org/jira/browse/CS-5986


Repository: cloudstack-git


Description
---

Test script is to verify the fix for dnsmasq lease issue while reallocating the 
same ip address to new vm in vpc networks.
Test does the following:
Create vpc and deploy vms in vpc network
Deploy two vms:
VM1 used name: VM1, 10.1.1.10
VM2 used name: VM2, 10.1.1.11
Destroy both the vms
Deploy vm3 with name VM1 and ip 10.1.1.11
Deploy vm4 with name vm3 and ip 10.1.1.10
Before fix vm4 would not get the ip because of dnsmasq lease issue. After fix 
vm4 would get the ip address properly.


Diffs
-

  test/integration/component/test_vpc_vms_deployment.py 1c1f93d 

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


Testing
---

yes


Thanks,

sanjeev n

Re: Review Request 23839: CLOUDSTACK-2251: Automation tests for dedicated guest vlan ranges per tenant feature


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

(Updated July 25, 2014, 5:47 p.m.)


Review request for cloudstack, suresh sadhu, sailaja mada, sanjeev n, Sowmya 
Krishnan, and SrikanteswaraRao Talluri.


Changes
---

Adding reviewers.


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


Repository: cloudstack-git


Description
---

Adding first set of automation tests for "Dedicated guest VLAN range per 
tenant" feature.
More test cases to follow.


Diffs
-

  test/integration/component/test_dedicate_guest_vlan_ranges.py PRE-CREATION 
  tools/marvin/marvin/lib/base.py 8d40591 
  tools/marvin/marvin/lib/common.py 187ede6 

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


Testing
---

Yes.


Thanks,

Gaurav Aradhye

Re: Review Request 23452: CLOUDSTACK-4840: Automation tests - LB for secondary IP

2014-07-25 Thread Ashutosh Kelkar


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

(Updated July 25, 2014, 12:25 p.m.)


Review request for cloudstack, suresh sadhu, sailaja mada, sanjeev n, Sowmya 
Krishnan, and SrikanteswaraRao Talluri.


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


Repository: cloudstack-git


Description
---

Adding automation tests for LB for secondary IP


Diffs
-

  test/integration/component/test_lb_secondary_ip.py PRE-CREATION 
  tools/marvin/marvin/lib/base.py 1a32275 

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


Testing
---

Yes.


Thanks,

Ashutosh Kelkar

RE: Failed add KVM agent to CS with latest master

2014-07-25 Thread Santhosh Edukulla

I just pushed individual commits, so all should be in.

Santhosh

From: Santhosh Edukulla
Sent: Thursday, July 24, 2014 5:05 AM
To: dev@cloudstack.apache.org; Santhosh Edukulla
Subject: RE: Failed add KVM agent to CS with latest master

Agree. I decided to split it into multiple smaller ones going ahead.   Instead 
of revert, may be we would have identified root cause and helped to fix the 
issue.

Santhosh

From: Daan Hoogland [daan.hoogl...@gmail.com]
Sent: Thursday, July 24, 2014 4:57 AM
To: dev; Santhosh Edukulla
Subject: Re: Failed add KVM agent to CS with latest master

On Thu, Jul 24, 2014 at 12:12 AM, Amogh Vasekar
 wrote:
> 4523490d44160b054de9e943f72db1d0ce06054a

Another big coverity fix reverted Santhosh. Could you split this one
as well. A shame if all that work is getting lost this way.

--
Daan

Re: Review Request 23929: Code refactor - using library functions instead of repetative code


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

(Updated July 25, 2014, 6:13 p.m.)


Review request for cloudstack and Girish Shilamkar.


Summary (updated)
-

Code refactor - using library functions instead of repetative code


Repository: cloudstack-git


Description
---

Many test cases in test_stopped_vm.py had redundant code to check the state of 
the VM. We already have library function to check the state of the virtual 
machine.


Diffs
-

  test/integration/component/test_stopped_vm.py 04dd859 

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


Testing
---

Yes.


Thanks,

Gaurav Aradhye

Review Request 23929: Code rector - using library functions instead of repetative code


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

Review request for cloudstack and Girish Shilamkar.


Repository: cloudstack-git


Description
---

Many test cases in test_stopped_vm.py had redundant code to check the state of 
the VM. We already have library function to check the state of the virtual 
machine.


Diffs
-

  test/integration/component/test_stopped_vm.py 04dd859 

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


Testing
---

Yes.


Thanks,

Gaurav Aradhye

Re: [DISCUSS][PROPOSAL] git workflow

2014-07-25 Thread Erik Weber

That seems to handle my concern :-)

Erik
25. juli 2014 13:16 skrev "Rajani Karuturi" 
følgende:

> branches will be deleted after the release or hotfix if you use the
> git-flow commands.
>
> This would be the flow for a hotfix:
> 1. branch off from the release tag on master. in this case it would be
> release/4.4.0
> 2. commit the fixes in hotfix/4.4.1
> 3. do the release
> 4. merge to develop
> 5. merge to master and update tags
> 6. delete hotfix branch
>
> But, I agree that there can be a problem when we wish to do 4.4.2 if we
> delete the hotfix branch
>
> may be we should use git-flow support instead of hotfix which doesn’t
> delete the branch
> http://stackoverflow.com/a/16866118/201514
>
> ~Rajani
>
>
>
> On 25-Jul-2014, at 12:31 pm, Daan Hoogland 
> wrote:
>
> > Rightful question Erik,
> >
> > Rajani mentioned that release branches will be deleted. This will only
> > happen once the release is no longer supported. Any hotfix branch will
> > still have to merged on that (and master possibly) until we stop
> > supporting that branch.
> >
> > On the other hand you can branch from any commit.
> >
> > btw 4.4.1 is a bad example of you as we will still maintain that
> > without gitflow. But it is valid for for instance 4.5.2 or 5.0.1.
> >
> > On Fri, Jul 25, 2014 at 8:04 AM, Erik Weber  wrote:
> >> This is out of my git league, but how do you handle minor versions that
> way?
> >>
> >> Assuming 4.8.0 is the latest stable release and HEAD on master.
> >>
> >> Then you want to release 4.4.1.
> >>
> >> First of all can you develop bugfixes for 4.4 along the way, when both
> >> develop and master HEAD might be hugely different?
> >>
> >> Second, can you commit  behind HEAD? You don't want the 4.4.1 release
> >> instead of 4.8.0 to be HEAD
> >>
> >> Someone might have good solutions to this, but if not I would propose to
> >> keep the release branches for future bugfixes.
> >>
> >> Erik
> >> 25. juli 2014 06:02 skrev "Rajani Karuturi"  >
> >> følgende:
> >>
> >>> On 24-Jul-2014, at 10:25 pm, Mike Tutkowski <
> mike.tutkow...@solidfire.com>
> >>> wrote:
> >>>
>  I believe I agree with these steps.
> 
>  A couple questions:
> 
>  Is 'master' simply always going to be equal to what's the most recent
>  version of the code that's in production?
> >>>
> >>> I think so. master will always be at the latest release and all the
> >>> previous releases properly tagged. The release branches would be
> deleted
> >>> once release is done.
> >>>
> 
>  Also, would 'develop' be for 4.6 code then and 4.5 code would go
> directly
>  into RELEASE-4.5?
> 
> >>>
> >>> Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes
> >>> should be done on the 4.5 branch.
> >>>
> >>>
> >>>
> >>> ~Rajani
> >>>
> >>>
> 
>  On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi <
>  rajani.karut...@citrix.com> wrote:
> 
> >
> > Hi Daan,
> > here is what i propose:
> >
> > 1. rename 'master' to 'develop’
> > 2. branch a new 'master' from '4.4’
> > 3. branch 'RELEASE-4.5' from the develop
> > 4. merge 'RELEASE-4.5' to master once the release voting is done.
> >
> > RELEASE-4.6 branch should be off develop as all the feature branches
> >>> would
> > be merged there before freeze for 4.6 and would be merged to master
> when
> > the release is voted.
> >
> > The other question I have is in the step:4. how are we going to
> manage
> > fixes to 4.5 post branch cut?  ( assuming no features as the freeze
> is
> >>> done)
> >
> > ~Rajani
> >
> >
> >
> > On 24-Jul-2014, at 11:52 am, Daan Hoogland 
> > wrote:
> >
> >> Mike, Rajani,
> >>
> >> Sebastien's point was that the current 4.4 is the closest we have
> to a
> >> releasable branch. I don't mind enting on master but it will require
> >> more fixing. In general all of this will require some RM work of all
> >> committers. Please ammend my little proposal if you will.
> >>
> >> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
> >>  wrote:
> >>> I agree with mike. I think we should start 4.5 from where master is
> >>> now
> >>> Also create a develop branch from master and continue future work
> for
> > 4.6 there.
> >>>
> >>> I am not clear on how the release branches are going to be
> maintained.
> >>> Are we saying we would create 4.5-RELEASE branch which is
> essentially
> > same as our current -FORWARD branch and continue cherry-picking?
> >>>
> >>> I would prefer merges to cherry-picks.
> >>> Also, I think we should allow committers to commit to the RELEASE
> > branch after discussing about it on dev@ and have RM closely monitor
> >>> them.
> >>> Any commit intended for 4.5 RELEASE should be checked in after
> > discussion in the 4.5 Release branch and then merged to develop
> branch.
> >>>
> >>>
> >>> ~Rajani
> >>>
> >>>
> >>>
>

Re: Review Request 23918: CLOUDSTACK-7180: Tagging test case with product bug ID

2014-07-25 Thread ASF Subversion and Git Services


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


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

CLOUDSTACK-7180: Tagging test case with product bug ID


- ASF Subversion and Git Services


On July 25, 2014, 7:50 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23918/
> ---
> 
> (Updated July 25, 2014, 7:50 a.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-7180
> https://issues.apache.org/jira/browse/CLOUDSTACK-7180
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Tagging test case with product Bug ID - CLOUDSTACK-7180
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_dynamic_compute_offering.py 3939777 
> 
> Diff: https://reviews.apache.org/r/23918/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 23925: CLOUDSTACK-7183: Fixing cleanup issue in test_escalations_instances.py

2014-07-25 Thread ASF Subversion and Git Services


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


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

CLOUDSTACK-7183: Fixing cleanup issue in tsest_escalations_instances.py


- ASF Subversion and Git Services


On July 25, 2014, 11:22 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23925/
> ---
> 
> (Updated July 25, 2014, 11:22 a.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-7183
> https://issues.apache.org/jira/browse/CLOUDSTACK-7183
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The test case test_23_deply_vm_multiple_securitygroups fails because it tries 
> to delete the security group before deleting the VMs in it.
> Added different cleanup list for VMs for which cleanup will be executed 
> before the regular cleanup list, and also passed expunge=True so that it is 
> expunged immediately.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_escalations_instances.py 0cd8b68 
> 
> Diff: https://reviews.apache.org/r/23925/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> tested on KVM basic zone with SG.
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Failed add KVM agent to CS with latest master

I saw them coming in, great work. Let's hope the ones that caused the
issue will trigger people to find the root cause this time.

On Fri, Jul 25, 2014 at 2:28 PM, Santhosh Edukulla
 wrote:
> I just pushed individual commits, so all should be in.
>
> Santhosh
> 
> From: Santhosh Edukulla
> Sent: Thursday, July 24, 2014 5:05 AM
> To: dev@cloudstack.apache.org; Santhosh Edukulla
> Subject: RE: Failed add KVM agent to CS with latest master
>
> Agree. I decided to split it into multiple smaller ones going ahead.   
> Instead of revert, may be we would have identified root cause and helped to 
> fix the issue.
>
> Santhosh
> 
> From: Daan Hoogland [daan.hoogl...@gmail.com]
> Sent: Thursday, July 24, 2014 4:57 AM
> To: dev; Santhosh Edukulla
> Subject: Re: Failed add KVM agent to CS with latest master
>
> On Thu, Jul 24, 2014 at 12:12 AM, Amogh Vasekar
>  wrote:
>> 4523490d44160b054de9e943f72db1d0ce06054a
>
> Another big coverity fix reverted Santhosh. Could you split this one
> as well. A shame if all that work is getting lost this way.
>
>
> --
> Daan



-- 
Daan

Re: Review Request 21696: CLOUDSTACK-6716: /usr volume is to small on SVMs. Reshuffling some space to fix that.



> On May 24, 2014, 7:29 a.m., Rohit Yadav wrote:
> > Thanks for the patch, the variables are subjective and would need testing 
> > before merging. Looks good.

Joris, correct me if I am wrong: We are using these in our environments at the 
moment.


- daan


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


On May 20, 2014, 2:30 p.m., Joris van Lieshout wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21696/
> ---
> 
> (Updated May 20, 2014, 2:30 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Ian Duffy, Rohit Yadav, and 
> Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-6716
> https://issues.apache.org/jira/browse/CLOUDSTACK-6716
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> We noticed after upgrading our svms to 4.3 that the /usr volume was nearly 
> full. When inspecting this on SSVMs and CVMs we noticed that on thse 
> instances it was already 100% full (because ACS jars get copied to this 
> volume). By reshuffling some space the /usr volume should end up around 80% 
> full. Also i've reduced swap a bit because this does not make a lot of sense 
> on virtual instances.
> 
> 
> Diffs
> -
> 
>   tools/appliance/definitions/systemvm64template/preseed.cfg 635432a 
>   tools/appliance/definitions/systemvmtemplate/preseed.cfg deb2f94 
> 
> Diff: https://reviews.apache.org/r/21696/diff/
> 
> 
> Testing
> ---
> 
> Used the ACS tooling/procedure to build both systemvmtemplate and 
> systemvm64template.
> 
> 
> Thanks,
> 
> Joris van Lieshout
> 
>

Re: Review Request 21696: CLOUDSTACK-6716: /usr volume is to small on SVMs. Reshuffling some space to fix that.

2014-07-25 Thread Joris van Lieshout



> On May 24, 2014, 7:29 a.m., Rohit Yadav wrote:
> > Thanks for the patch, the variables are subjective and would need testing 
> > before merging. Looks good.
> 
> daan Hoogland wrote:
> Joris, correct me if I am wrong: We are using these in our environments 
> at the moment.

Nope we are not. I did however build a fresh template using the build scripts 
to test the result. 


- Joris


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


On May 20, 2014, 2:30 p.m., Joris van Lieshout wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21696/
> ---
> 
> (Updated May 20, 2014, 2:30 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Ian Duffy, Rohit Yadav, and 
> Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-6716
> https://issues.apache.org/jira/browse/CLOUDSTACK-6716
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> We noticed after upgrading our svms to 4.3 that the /usr volume was nearly 
> full. When inspecting this on SSVMs and CVMs we noticed that on thse 
> instances it was already 100% full (because ACS jars get copied to this 
> volume). By reshuffling some space the /usr volume should end up around 80% 
> full. Also i've reduced swap a bit because this does not make a lot of sense 
> on virtual instances.
> 
> 
> Diffs
> -
> 
>   tools/appliance/definitions/systemvm64template/preseed.cfg 635432a 
>   tools/appliance/definitions/systemvmtemplate/preseed.cfg deb2f94 
> 
> Diff: https://reviews.apache.org/r/21696/diff/
> 
> 
> Testing
> ---
> 
> Used the ACS tooling/procedure to build both systemvmtemplate and 
> systemvm64template.
> 
> 
> Thanks,
> 
> Joris van Lieshout
> 
>

Re: Review Request 23920: CLOUDSTACK-7181: Skip tests on KVM - changing service offering when VM is in running state - not supported on KVM

2014-07-25 Thread ASF Subversion and Git Services


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


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

CLOUDSTACK-7181: Skip tests on KVM - changing service offering when VM is in 
running state - not supported on KVM


- ASF Subversion and Git Services


On July 25, 2014, 9:19 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23920/
> ---
> 
> (Updated July 25, 2014, 9:19 a.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-7181
> https://issues.apache.org/jira/browse/CLOUDSTACK-7181
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Skipping the tests which try to change the service offering of VM when it is 
> in running state on KVM as the feature is not supported for KVM hypervisor.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_dynamic_compute_offering.py 3939777 
> 
> Diff: https://reviews.apache.org/r/23920/diff/
> 
> 
> Testing
> ---
> 
> yes.
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 21696: CLOUDSTACK-6716: /usr volume is to small on SVMs. Reshuffling some space to fix that.



> On May 24, 2014, 7:29 a.m., Rohit Yadav wrote:
> > Thanks for the patch, the variables are subjective and would need testing 
> > before merging. Looks good.
> 
> daan Hoogland wrote:
> Joris, correct me if I am wrong: We are using these in our environments 
> at the moment.
> 
> Joris van Lieshout wrote:
> Nope we are not. I did however build a fresh template using the build 
> scripts to test the result.

So what to do to be sure it works? Other then merge and run and see.


- daan


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


On May 20, 2014, 2:30 p.m., Joris van Lieshout wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21696/
> ---
> 
> (Updated May 20, 2014, 2:30 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Ian Duffy, Rohit Yadav, and 
> Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-6716
> https://issues.apache.org/jira/browse/CLOUDSTACK-6716
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> We noticed after upgrading our svms to 4.3 that the /usr volume was nearly 
> full. When inspecting this on SSVMs and CVMs we noticed that on thse 
> instances it was already 100% full (because ACS jars get copied to this 
> volume). By reshuffling some space the /usr volume should end up around 80% 
> full. Also i've reduced swap a bit because this does not make a lot of sense 
> on virtual instances.
> 
> 
> Diffs
> -
> 
>   tools/appliance/definitions/systemvm64template/preseed.cfg 635432a 
>   tools/appliance/definitions/systemvmtemplate/preseed.cfg deb2f94 
> 
> Diff: https://reviews.apache.org/r/21696/diff/
> 
> 
> Testing
> ---
> 
> Used the ACS tooling/procedure to build both systemvmtemplate and 
> systemvm64template.
> 
> 
> Thanks,
> 
> Joris van Lieshout
> 
>

Re: Review Request 21696: CLOUDSTACK-6716: /usr volume is to small on SVMs. Reshuffling some space to fix that.

2014-07-25 Thread Joris van Lieshout



> On May 24, 2014, 7:29 a.m., Rohit Yadav wrote:
> > Thanks for the patch, the variables are subjective and would need testing 
> > before merging. Looks good.
> 
> daan Hoogland wrote:
> Joris, correct me if I am wrong: We are using these in our environments 
> at the moment.
> 
> Joris van Lieshout wrote:
> Nope we are not. I did however build a fresh template using the build 
> scripts to test the result.
> 
> daan Hoogland wrote:
> So what to do to be sure it works? Other then merge and run and see.

My tests where good so nothing more to be done there. Merge, run, see would 
work for me.


- Joris


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


On May 20, 2014, 2:30 p.m., Joris van Lieshout wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21696/
> ---
> 
> (Updated May 20, 2014, 2:30 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Ian Duffy, Rohit Yadav, and 
> Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-6716
> https://issues.apache.org/jira/browse/CLOUDSTACK-6716
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> We noticed after upgrading our svms to 4.3 that the /usr volume was nearly 
> full. When inspecting this on SSVMs and CVMs we noticed that on thse 
> instances it was already 100% full (because ACS jars get copied to this 
> volume). By reshuffling some space the /usr volume should end up around 80% 
> full. Also i've reduced swap a bit because this does not make a lot of sense 
> on virtual instances.
> 
> 
> Diffs
> -
> 
>   tools/appliance/definitions/systemvm64template/preseed.cfg 635432a 
>   tools/appliance/definitions/systemvmtemplate/preseed.cfg deb2f94 
> 
> Diff: https://reviews.apache.org/r/21696/diff/
> 
> 
> Testing
> ---
> 
> Used the ACS tooling/procedure to build both systemvmtemplate and 
> systemvm64template.
> 
> 
> Thanks,
> 
> Joris van Lieshout
> 
>

RE: SSL keystore file name

2014-07-25 Thread Rajesh Battala

Thanks Kishan for the info.

-Original Message-
From: Kishan Kavala [mailto:kishan.kav...@citrix.com] 
Sent: Friday, July 25, 2014 4:41 PM
To: dev@cloudstack.apache.org
Cc: Wei Zhou; wilderrodrigues
Subject: SSL keystore file name

SSl keystore was changed from cloud.keystore to cloudmanagementserver.keystore 
with below commit [1]. Later, related code change were over-written in commit 
[2]. I made changes [3] to keep keystore filename as 
cloudmanagementserver.keystore in all references. 
Please let me know if you see any issues.

[1] 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=57ba367f3c985e80ea1b34267e298b481a353298
[2] 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=2774b62d64989bddc1e4664ef7a93dff11c77657
[3] 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=c61c636ce8a1d74fd22d89026d40ba904fff6cf8

Re: CLOUDSTACK-7184

2014-07-25 Thread Tim Mackey

Remi,

Did you have the native XenServer HA enabled at the same time?

-tim
On Jul 25, 2014 8:31 AM, "Remi Bergsma"  wrote:

> Hi guys,
>
> We had some serious corruption today, described in CLOUDSTACK-7184
> (XenServer specific).
> https://issues.apache.org/jira/browse/CLOUDSTACK-7184
>
> Some discussion/help on how to prevent these issues is appreciated. Thx!
>
> Kind Regards,
> Remi Bergsma
>
>

CLOUDSTACK-7184

2014-07-25 Thread Remi Bergsma

Hi guys,

We had some serious corruption today, described in CLOUDSTACK-7184 (XenServer 
specific).
https://issues.apache.org/jira/browse/CLOUDSTACK-7184

Some discussion/help on how to prevent these issues is appreciated. Thx!

Kind Regards,
Remi Bergsma

Re: CLOUDSTACK-7184

2014-07-25 Thread Remi Bergsma

Hi Tim,

No, we do not use XenServer HA.

Remi



On 7/25/14, 5:46 PM, "Tim Mackey"  wrote:

>Remi,
>
>Did you have the native XenServer HA enabled at the same time?
>
>-tim
>On Jul 25, 2014 8:31 AM, "Remi Bergsma" 
>wrote:
>
>> Hi guys,
>>
>> We had some serious corruption today, described in CLOUDSTACK-7184
>> (XenServer specific).
>> https://issues.apache.org/jira/browse/CLOUDSTACK-7184
>>
>> Some discussion/help on how to prevent these issues is appreciated. Thx!
>>
>> Kind Regards,
>> Remi Bergsma
>>
>>

Re: CLOUDSTACK-7184

2014-07-25 Thread Tim Mackey

Ok. I'm boarding a plane now, but would love to get a copy of the XenServer
logs from the relevant hosts, and the management server logs.  I'm wanting
to see why XenServer allowed a vm to start with the same disk on two hosts.
On Jul 25, 2014 8:53 AM, "Remi Bergsma"  wrote:

> Hi Tim,
>
> No, we do not use XenServer HA.
>
> Remi
>
>
>
> On 7/25/14, 5:46 PM, "Tim Mackey"  wrote:
>
> >Remi,
> >
> >Did you have the native XenServer HA enabled at the same time?
> >
> >-tim
> >On Jul 25, 2014 8:31 AM, "Remi Bergsma" 
> >wrote:
> >
> >> Hi guys,
> >>
> >> We had some serious corruption today, described in CLOUDSTACK-7184
> >> (XenServer specific).
> >> https://issues.apache.org/jira/browse/CLOUDSTACK-7184
> >>
> >> Some discussion/help on how to prevent these issues is appreciated. Thx!
> >>
> >> Kind Regards,
> >> Remi Bergsma
> >>
> >>
>
>

Re: CLOUDSTACK-7184

2014-07-25 Thread Remi Bergsma

Hi Tim,

Have a safe flight! I will make sure you¹ll get a copy of the logs.

Thanks,
Remi



On 7/25/14, 5:57 PM, "Tim Mackey"  wrote:

>Ok. I'm boarding a plane now, but would love to get a copy of the
>XenServer
>logs from the relevant hosts, and the management server logs.  I'm wanting
>to see why XenServer allowed a vm to start with the same disk on two
>hosts.
>On Jul 25, 2014 8:53 AM, "Remi Bergsma" 
>wrote:
>
>> Hi Tim,
>>
>> No, we do not use XenServer HA.
>>
>> Remi
>>
>>
>>
>> On 7/25/14, 5:46 PM, "Tim Mackey"  wrote:
>>
>> >Remi,
>> >
>> >Did you have the native XenServer HA enabled at the same time?
>> >
>> >-tim
>> >On Jul 25, 2014 8:31 AM, "Remi Bergsma" 
>> >wrote:
>> >
>> >> Hi guys,
>> >>
>> >> We had some serious corruption today, described in CLOUDSTACK-7184
>> >> (XenServer specific).
>> >> https://issues.apache.org/jira/browse/CLOUDSTACK-7184
>> >>
>> >> Some discussion/help on how to prevent these issues is appreciated.
>>Thx!
>> >>
>> >> Kind Regards,
>> >> Remi Bergsma
>> >>
>> >>
>>
>>

Re: SSL keystore file name

2014-07-25 Thread Nitin Mehta

Kishan - Thanks for the info. Can you explain a bit more on why we did
this ? Where and how is it used and whether upgrade will be affected ?

Thanks,
-Nitin

On 25/07/14 4:10 AM, "Kishan Kavala"  wrote:

>SSl keystore was changed from cloud.keystore to
>cloudmanagementserver.keystore with below commit [1]. Later, related code
>change were over-written in commit [2]. I made changes [3] to keep
>keystore filename as cloudmanagementserver.keystore in all references.
>Please let me know if you see any issues.
>
>[1] 
>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=57ba36
>7f3c985e80ea1b34267e298b481a353298
>[2] 
>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=27
>74b62d64989bddc1e4664ef7a93dff11c77657
>[3] 
>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=c6
>1c636ce8a1d74fd22d89026d40ba904fff6cf8
>
>

[ACS4.4] Formal Release Date

2014-07-25 Thread Mike Tutkowski

Hi,

Now that we are a go on 4.4, do we have a formal release date?

I know we're in the process of building artifacts, updating the web site
and all of that.

I was just curious if there is a particular date we have in mind for the
formal release?

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

Unable to build cloudstack.

2014-07-25 Thread Elapavuluri, Jaya

Hello,

I had setup cloudstack 4.4 environment which was running fine.

I recently did a git pull to get the updates after which when I tried to mvn 
clean install I was encountering with the following error.

Failed to execute goal 
org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check 
(cloudstack-checkstyle) on project cloud-maven-standard: Execution 
cloudstack-checkstyle of goal 
org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check failed: Plugin 
org.apache.maven.plugins:maven-checkstyle-plugin:2.11 or one of its 
dependencies could not be resolved: Failure to find 
org.apache.cloudstack:checkstyle:jar:4.4.1-SNAPSHOT in 
http://repository.apache.org/snapshots was cached in the local repository, 
resolution will not be reattempted until the update interval of 
apache.snapshots has elapsed or updates are forced -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :cloud-maven-standard

Could someone please help out regarding this issue?

Re: Unable to build cloudstack.

2014-07-25 Thread Erik Weber

Did you pull the branch or the tag?

Erik
25. juli 2014 21:18 skrev "Elapavuluri, Jaya" 
følgende:

> Hello,
>
> I had setup cloudstack 4.4 environment which was running fine.
>
> I recently did a git pull to get the updates after which when I tried to
> mvn clean install I was encountering with the following error.
>
> Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check
> (cloudstack-checkstyle) on project cloud-maven-standard: Execution
> cloudstack-checkstyle of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check failed: Plugin
> org.apache.maven.plugins:maven-checkstyle-plugin:2.11 or one of its
> dependencies could not be resolved: Failure to find
> org.apache.cloudstack:checkstyle:jar:4.4.1-SNAPSHOT in
> http://repository.apache.org/snapshots was cached in the local
> repository, resolution will not be reattempted until the update interval of
> apache.snapshots has elapsed or updates are forced -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR]   mvn  -rf :cloud-maven-standard
>
> Could someone please help out regarding this issue?
>
>

RE: Unable to build cloudstack.

2014-07-25 Thread Elapavuluri, Jaya

I did a git pull

-Original Message-
From: Erik Weber [mailto:terbol...@gmail.com] 
Sent: Friday, July 25, 2014 4:11 PM
To: dev
Subject: Re: Unable to build cloudstack.

Did you pull the branch or the tag?

Erik
25. juli 2014 21:18 skrev "Elapavuluri, Jaya" 
følgende:

> Hello,
>
> I had setup cloudstack 4.4 environment which was running fine.
>
> I recently did a git pull to get the updates after which when I tried 
> to mvn clean install I was encountering with the following error.
>
> Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check
> (cloudstack-checkstyle) on project cloud-maven-standard: Execution 
> cloudstack-checkstyle of goal 
> org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check failed: 
> Plugin
> org.apache.maven.plugins:maven-checkstyle-plugin:2.11 or one of its 
> dependencies could not be resolved: Failure to find 
> org.apache.cloudstack:checkstyle:jar:4.4.1-SNAPSHOT in 
> http://repository.apache.org/snapshots was cached in the local 
> repository, resolution will not be reattempted until the update 
> interval of apache.snapshots has elapsed or updates are forced -> 
> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, 
> re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, 
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionExcep
> tion
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with 
> the command
> [ERROR]   mvn  -rf :cloud-maven-standard
>
> Could someone please help out regarding this issue?
>
>

Re: Change IP subnet of cluster [SOLVED]

2014-07-25 Thread Carlos Reátegui

My system is back up and running. 

As I suspected in my second email the problem was related to the msid in the 
mshost table.  Upon bringing up my system a new mshost entry was being created 
for the same MS and for some reason it was unable to connect to my XenServer 
hosts.

I decided to go back to my edited sql with the new IPs and change the existing 
mshost entry to have the new msid value:

sed -i.bak4 's/159090355471823/159090355471825/g' cloudstack_cloud-newips.sql

I did a global replace since there are foreign key constraints on the msid that 
I saw in the host and async_job tables

After reloading this new sql and starting the MS everything is back to normal, 
but with a new subnet for my hosts and guests (this is a basic network).


Question for the Devs:

Lets say the machine my MS was running on crashed and I replaced it with a new 
machine.  Since the msid is derived from the MAC wouldn’t I have encountered 
this same problem and not been able to have the new machine connect to the 
hosts?  

thanks,
Carlos




On Jul 25, 2014, at 8:46 AM, Carlos Reátegui  wrote:

> Any thoughts out there?
> 
> It keeps trying to connect to the hosts but it is unable to and there are no 
> clues in the logs as to why.  I am successfully connected with XenCenter to 
> the pool and also am able to ssh to all the hosts from the MS.
> 
> What does “Disable Cluster” or “Unmanage Cluster” do?  Should I try that and 
> re-enable/manage?
> 
> From the UI, things appear ok but starting any instance fails.
> 
> Thanks,
> Carlos
> 
> Log snippet form this am:
> 
> 2014-07-25 21:03:19,599 DEBUG [agent.manager.ClusteredAgentAttache] 
> (StatsCollector-2:null) Seq 2-65931749: Forwarding null to 159090355471823
> 2014-07-25 21:03:19,599 DEBUG [agent.manager.ClusteredAgentAttache] 
> (AgentManager-Handler-13:null) Seq 2-65931749: Routing from 159090355471825
> 2014-07-25 21:03:19,599 DEBUG [agent.manager.ClusteredAgentAttache] 
> (AgentManager-Handler-13:null) Seq 2-65931749: Link is closed
> 2014-07-25 21:03:19,600 DEBUG [agent.manager.ClusteredAgentManagerImpl] 
> (AgentManager-Handler-13:null) Seq 2-65931749: MgmtId 159090355471825: Req: 
> Resource [Host:2] is
>  unreachable: Host 2: Link is closed
> 2014-07-25 21:03:19,600 DEBUG [agent.manager.ClusteredAgentManagerImpl] 
> (AgentManager-Handler-13:null) Seq 2--1: MgmtId 159090355471825: Req: Routing 
> to peer
> 2014-07-25 21:03:19,601 DEBUG [agent.manager.ClusteredAgentManagerImpl] 
> (AgentManager-Handler-14:null) Seq 2--1: MgmtId 159090355471825: Req: Cancel 
> request received
> 2014-07-25 21:03:19,601 DEBUG [agent.manager.AgentAttache] 
> (AgentManager-Handler-14:null) Seq 2-65931749: Cancelling.
> 2014-07-25 21:03:19,601 DEBUG [agent.manager.AgentAttache] 
> (StatsCollector-2:null) Seq 2-65931749: Waiting some more time because this 
> is the current command
> 2014-07-25 21:03:19,601 DEBUG [agent.manager.AgentAttache] 
> (StatsCollector-2:null) Seq 2-65931749: Waiting some more time because this 
> is the current command
> 2014-07-25 21:03:19,601 INFO  [utils.exception.CSExceptionErrorCode] 
> (StatsCollector-2:null) Could not find exception: 
> com.cloud.exception.OperationTimedoutException in
>  error code list for exceptions
> 2014-07-25 21:03:19,601 WARN  [agent.manager.AgentAttache] 
> (StatsCollector-2:null) Seq 2-65931749: Timed out on null
> 2014-07-25 21:03:19,601 DEBUG [agent.manager.AgentAttache] 
> (StatsCollector-2:null) Seq 2-65931749: Cancelling.
> 2014-07-25 21:03:19,601 WARN  [agent.manager.AgentManagerImpl] 
> (StatsCollector-2:null) Operation timed out: Commands 65931749 to Host 2 
> timed out after 3600
> 2014-07-25 21:03:19,601 WARN  [cloud.resource.ResourceManagerImpl] 
> (StatsCollector-2:null) Unable to obtain host 2 statistics. 
> 2014-07-25 21:03:19,601 WARN  [cloud.server.StatsCollector] 
> (StatsCollector-2:null) Received invalid host stats for host: 2
> 2014-07-25 21:03:19,606 DEBUG [agent.manager.ClusteredAgentAttache] 
> (StatsCollector-2:null) Seq 3-602278373: Forwarding null to 159090355471823
> 2014-07-25 21:03:19,607 DEBUG [agent.manager.ClusteredAgentAttache] 
> (AgentManager-Handler-15:null) Seq 3-602278373: Routing from 159090355471825
> 2014-07-25 21:03:19,607 DEBUG [agent.manager.ClusteredAgentAttache] 
> (AgentManager-Handler-15:null) Seq 3-602278373: Link is closed
> 2014-07-25 21:03:19,607 DEBUG [agent.manager.ClusteredAgentManagerImpl] 
> (AgentManager-Handler-15:null) Seq 3-602278373: MgmtId 159090355471825: Req: 
> Resource [Host:3] is unreachable: Host 3: Link is closed
> 2014-07-25 21:03:19,608 DEBUG [agent.manager.ClusteredAgentManagerImpl] 
> (AgentManager-Handler-15:null) Seq 3--1: MgmtId 159090355471825: Req: Routing 
> to peer
> 2014-07-25 21:03:19,608 DEBUG [agent.manager.ClusteredAgentManagerImpl] 
> (AgentManager-Handler-4:null) Seq 3--1: MgmtId 159090355471825: Req: Cancel 
> request received
> 2014-07-25 21:03:19,609 DEBUG [agent.manager.AgentAttache] 
> (AgentManager-Handler-4:null) Seq 3-602278373: Can

Moving SVM range

2014-07-25 Thread Carlos Reátegui

Feeling good about moving my basic network deployment from one subnet to 
another, I would now like to move the System VM ip range and expand the guest 
VM range.

I had been sharing the previous subnet with others and only had from .150 up 
through .249.  The new subnet is all mine.  As part of the re-IP I moved the 
hosts down to .30-.36.  Now I want to move the system VMs from .160-.174 to 
.50-.64 (BTW what is a good number of IPs to reserve for system VMs?).  After 
that I want to bring down the Guest VM IP start from .175 to .100 or so.

I was planning on stopping all instances and system VMs prior to shutting down 
the MS and making sure in XenCenter that they were destroyed.

My initial thought is to script iterating through each of the IPs in the 
current SVM range (i.e. .160-.180) and do a global replace with .50-.64.  This 
would take care of most tables like: host, host_pod_ref, nics, 
op_dc_ip_address_alloc, vm_instance.  Since I am not expanding/contracting this 
range of IPs it seems simple enough.

Then for the expansion of the Guest range seems like I need to edit vlan.  But 
then the tricky one appears to be the user_ip_address table.  Seems like it has 
pre-defined rows for all IPs and their current state (i.e. allocated or not).  
Will CS automatically fill this in for me if it notices a discrepancy with the 
range in vlan?  Do I need to create the missing entries myself?  Can I use 
uuidgen to generate uuids?  Can I insert the new ones after the existing ones 
(or should they all be in increasing ip values)?  If I put them in order I need 
to change the id but what about the mac_address column.  It looks like that 
value matches the last octet of the MAC in the nic table so I should probably 
leave the existing ones as is and that column won’t be ordered.  

any other thoughts? 

thanks,
Carlos

SSL Keystore functionality in CloudStack

2014-07-25 Thread Chandan Purushothama

I tried looking around to understand the role of SSL Keystore in CS and an 
exhaustive list of its functionality/Use cases in CS. I couldn't find any 
documentation that explains about it. Can anyone help me direct to any relevant 
documentation to understand keystore's role in CS,

Thank you,
Chandan.

[GitHub] cloudstack-docs-rn pull request: removed 'CloudStack on Windows' f...

2014-07-25 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack-docs-rn/pull/16


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

Re: Unable to build cloudstack.

Jaya,

an error in the setnextversion.sh script. It didn't 'upgrade' the
checkstyle pom. try again, please

On Fri, Jul 25, 2014 at 10:13 PM, Elapavuluri, Jaya
 wrote:
> I did a git pull
>
> -Original Message-
> From: Erik Weber [mailto:terbol...@gmail.com]
> Sent: Friday, July 25, 2014 4:11 PM
> To: dev
> Subject: Re: Unable to build cloudstack.
>
> Did you pull the branch or the tag?
>
> Erik
> 25. juli 2014 21:18 skrev "Elapavuluri, Jaya" 
> følgende:
>
>> Hello,
>>
>> I had setup cloudstack 4.4 environment which was running fine.
>>
>> I recently did a git pull to get the updates after which when I tried
>> to mvn clean install I was encountering with the following error.
>>
>> Failed to execute goal
>> org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check
>> (cloudstack-checkstyle) on project cloud-maven-standard: Execution
>> cloudstack-checkstyle of goal
>> org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check failed:
>> Plugin
>> org.apache.maven.plugins:maven-checkstyle-plugin:2.11 or one of its
>> dependencies could not be resolved: Failure to find
>> org.apache.cloudstack:checkstyle:jar:4.4.1-SNAPSHOT in
>> http://repository.apache.org/snapshots was cached in the local
>> repository, resolution will not be reattempted until the update
>> interval of apache.snapshots has elapsed or updates are forced ->
>> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors,
>> re-run Maven with the -e switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions,
>> please read the following articles:
>> [ERROR] [Help 1]
>> http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionExcep
>> tion
>> [ERROR]
>> [ERROR] After correcting the problems, you can resume the build with
>> the command
>> [ERROR]   mvn  -rf :cloud-maven-standard
>>
>> Could someone please help out regarding this issue?
>>
>>



-- 
Daan

Re: Change IP subnet of cluster [SOLVED]