Re: [DISCUSS][PROPOSAL] git workflow

[Erik Weber]

24. juli 2014 08:39 skrev "Rajani Karuturi" 
følgende:
>
>
> 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)

Sub releases, ie. 4.4.1,  is generally just hotfixes / bugfixes, yes? In
that case you can branch it off 'master' and merge back to master as a new
release after voting, and merge to develop if the fix is applicable there.

Erik
>
> ~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 'develop' to '4.5' and 'master'
> 
> 
> 
>  On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen 
>  wrote:
> >
> > On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen 
>  wrote:
> >
> >>
> >> On Jul 23, 2014, at 12:21 PM, Nate Gordon 
>  wrote:
> >>
> >>> Let me ask the question, why have master be develop and a release
>  branch be
> >>> "master"? If we are going to follow gitflow, why not just stick
with
>  the
> >>> norm? If master is the development branch, it might not be
stable. I
>  think
> >>> the goal here is that we have an obvious stable branch. Anyone
could
>  come
> >>> check out master and have the latest useable.
> >>
> >> I am in favor of following the norm, so ideally master should be
our
>  stable branch (agreed).
> >>
> >> The issue is with the transition.
> >>
> >> Our latest releasable product is the 4.4 branch (4.4.0 tag), so
ideally
>  we could start a stable branch of this tag and build up bug fix
releases
>  all the way to 4.5 from there.
> >>
> >> But all features for 4.5 are already in master.
> >>
> >> So if we create a 'develop' branch of master and stabilize 'master'
>  then develop is now started from a stable tag (4.4.0).
> >>
> >
> > *not* started from a stable tag, and merges will be tricky, no ?
> >
> >> So what's the best way to flip ? There is most likely some git
magic
>  that can we do.
> >>
> >>
> >> The new git workflow and the transition process need to be part of
a
>  proposal that we get consensus on.
> >>
> >> getting there :)
> >>
> >> -seb
> >>
> >>>
> >>> Also, I'm struggling to understand the benefit of cherry-pick. If
you
> >>> completely squash history, you lose a tremendous amount of
context,
>  which I
> >>> use extensively to fig

Re: [DISCUSS][PROPOSAL] git workflow

[Daan Hoogland]

That's where the 4.5-hotfixes branch comes in.

On Thu, Jul 24, 2014 at 8:39 AM, Rajani Karuturi
 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  
>>> 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 
 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 'develop' to '4.5' and 'master'
>
>
>
> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen 
> wrote:
>>
>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen 
> wrote:
>>
>>>
>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon 
> wrote:
>>>
 Let me ask the question, why have master be develop and a release
> branch be
 "master"? If we are going to follow gitflow, why not just stick with
> the
 norm? If master is the development branch, it might not be stable. I
> think
 the goal here is that we have an obvious stable branch. Anyone could
> come
 check out master and have the latest useable.
>>>
>>> I am in favor of following the norm, so ideally master should be our
> stable branch (agreed).
>>>
>>> The issue is with the transition.
>>>
>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally
> we could start a stable branch of this tag and build up bug fix releases
> all the way to 4.5 from there.
>>>
>>> But all features for 4.5 are already in master.
>>>
>>> So if we create a 'develop' branch of master and stabilize 'master'
> then develop is now started from a stable tag (4.4.0).
>>>
>>
>> *not* started from a stable tag, and merges will be tricky, no ?
>>
>>> So what's the best way to flip ? There is most likely some git magic
> that can we do.
>>>
>>>
>>> The new git workflow and the transition process need to be part of a
> proposal that we get consensus on.
>>>
>>> getting there :)
>>>
>>> -seb
>>>

 Also, I'm struggling to understand the benefit of cherry-pick. If you
 completely squash history, you lose a tremendous amount of context,
> which I
 use extensively to figure out why a bug is the way it is. Only knowing
> that
 the branch was merged at a given point in time doesn't give any
> context.
 Seeing the individual commit history of the branch helps to preserve
> the
 rationale for why the code was written the way it was. In theory i

Re: Test Failures

[Daan Hoogland]

On Thu, Jul 24, 2014 at 8:47 AM, Priyanka Deepala
 wrote:
> C:\cygwin64\home\priya\cloudstack-oss\cloudstack\core\target\surefire-reports

in this directory you should find files with stacktraces for the following:

Failed tests:
testFirewallRulesCommand(com.
cloud.agent.resource.virtualnetwork.VirtualRoutingResourceTest):
expected:<...1.2/24:,64.10.10.10:[reverted:0:0:0:,64.10.10.10:TCP:22:80:
10.10.1.1/24-10.10.1.2/24]:,> but was:<...1.2/24:,64.10.10.10:[TCP:22:80:
10.10.1.1/24-10.10.1.2/24:,64.10.10.10:reverted:0:0:0]:,>

testAggregationCommands(com.cloud.agent.resource.virtualnetwork.VirtualRoutingResourceTest):
expected:<...1.2/24:,64.10.10.10:[reverted:0:0:0:,64.10.10.10:TCP:22:80:
10.10.1.1/24-10.10.1.2/24]:,(..)



-- 
Daan

Re: Test Failures

[Priyanka Deepala]

This is the snapshot of errors
---
 T E S T S
---
Running com.cloud.agent.resource.virtualnetwork.VirtualRoutingResourceTest
log4j:WARN No appenders could be found for logger
(org.springframework.test.context.junit4.SpringJUnit4ClassRunner).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
more info.
Tests run: 20, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 1.027 sec
<<< FAILURE!
Running com.cloud.agent.transport.RequestTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.423 sec
Running com.cloud.network.HAProxyConfiguratorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Running org.apache.cloudstack.api.agent.test.AgentControlAnswerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running org.apache.cloudstack.api.agent.test.AgentControlCommandTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running org.apache.cloudstack.api.agent.test.AnswerTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Running org.apache.cloudstack.api.agent.test.AttachIsoCommandTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Running org.apache.cloudstack.api.agent.test.AttachVolumeAnswerTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running org.apache.cloudstack.api.agent.test.AttachVolumeCommandTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running org.apache.cloudstack.api.agent.test.BackupSnapshotAnswerTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec
Running org.apache.cloudstack.api.agent.test.BackupSnapshotCommandTest
Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running org.apache.cloudstack.api.agent.test.BumpUpPriorityCommandTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running org.apache.cloudstack.api.agent.test.CancelCommandTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.cloudstack.api.agent.test.ChangeAgentAnswerTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
Running org.apache.cloudstack.api.agent.test.ChangeAgentCommandTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running org.apache.cloudstack.api.agent.test.CheckHealthAnswerTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Running org.apache.cloudstack.api.agent.test.CheckHealthCommandTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Running org.apache.cloudstack.api.agent.test.CheckNetworkAnswerTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
Running org.apache.cloudstack.api.agent.test.CheckNetworkCommandTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
Running org.apache.cloudstack.api.agent.test.CheckOnHostCommandTest
Tests run: 42, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec
Running org.apache.cloudstack.api.agent.test.SnapshotCommandTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec

Results :

Failed tests:
testFirewallRulesCommand(com.cloud.agent.resource.virtualnetwork.VirtualRoutingResourceTest):
expected:<...1.2/24:,64.10.10.10:[reverted:0:0:0:,64.10.10.10:TCP:22:80:
10.10.1.1/24-10.10.1.2/24]:,> but was:<...1.2/24:,64.10.10.10:[TCP:22:80:
10.10.1.1/24-10.10.1.2/24:,64.10.10.10:reverted:0:0:0]:,>

testAggregationCommands(com.cloud.agent.resource.virtualnetwork.VirtualRoutingResourceTest):
expected:<...1.2/24:,64.10.10.10:[reverted:0:0:0:,64.10.10.10:TCP:22:80:
10.10.1.1/24-10.10.1.2/24]:,(..)

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

[INFO]

[INFO] Reactor Summary:
[INFO]
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration SUCCESS
[  1.713 s]
[INFO] Apache CloudStack .. SUCCESS [
 2.205 s]
[INFO] Apache CloudStack Maven Conventions Parent . SUCCESS [
 1.252 s]
[INFO] Apache CloudStack Framework - Managed Context .. SUCCESS [
 2.646 s]
[INFO] Apache CloudStack Utils  SUCCESS [
 8.078 s]
[INFO] Apache CloudStack Framework  SUCCESS [
 0.214 s]
[INFO] Apache CloudStack Framework - Event Notification ... SUCCESS [
 3.856 s]
[INFO] Apache CloudStack Framework - Configuration  SUCCESS [
 2.083 s]
[INFO] Apache CloudStack API .. SUCCESS [
 7.264 s]
[INFO] Apache CloudStack Framework - REST . SUCCESS [
 1.256 s]
[INFO] Apache CloudStack Framework - IPC .. SUCCESS [
 2.793 s]
[INFO] Apache CloudStack Cloud Engine . SUCCESS [
 0.139 s]
[INFO] A

Re: Review Request 23257: Cloudstack network-element plugin to orchestrate Juniper's switches (for L2 services)

[Pradeep HK]

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

(Updated July 24, 2014, 6:45 a.m.)


Review request for cloudstack and Hugo Trippaers.


Changes
---

Changes done:
(1)Incorporate some of the review comments
   - avoid repository statements in the pom files
   - removed TODO
(2)Additional code changes


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


Repository: cloudstack-git


Description
---

Pls refer to the Design document available @
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+network-element+plugin+to+orchestrate+Juniper%27s+switches+%28for+L2+services%29

This feature is about a Cloudstack network-element plugin to orchestrate 
Juniper's switches.

As a first-cut, we are focussing on L2 services and we will write a 
NetworkGuru. As part of it's implement() method we will:
(1)Create the required logical interfaces on the Juniper switches (EX,QFX)
(2)Create the required VLANs on the Juniper switches (EX,QFX).
(3)Configure VLAN membership on the interfaces

Our customers need this plugin in Cloudstack deployments to automatically 
orchestrate the Juniper switches to create Virtual Networks.
Without this plugin, there will be a manual intervention needed to configure 
the switches (after figuring out the
current configuration of the switch).

We have a Network Management Platform (called JUNOS SPACE) which is heavily 
used by customers to orchestrate Juniper's networking devices.
It also exposes REST-ful APIs for integration with 3rdParty tools.
The proposed Juniper's Cloudstack network-element plugin leverages these 
REST-ful APIs to appropriately orchestrate Juniper's switches to
create Virtual Networks


Diffs (updated)
-

  client/pom.xml 29fef4f 
  debian/cloudstack-management.install ea3f93b 
  debian/rules 197e243 
  deps/install-non-oss.sh 940bd32 
  plugins/network-elements/juniper-networkguru/pom.xml PRE-CREATION 
  
plugins/network-elements/juniper-networkguru/resources/META-INF/cloudstack/junipernetworkguru/module.properties
 PRE-CREATION 
  
plugins/network-elements/juniper-networkguru/resources/META-INF/cloudstack/junipernetworkguru/spring-junipernetworkguru-context.xml
 PRE-CREATION 
  
plugins/network-elements/juniper-networkguru/src/JuniperNetworkGuru.properties 
PRE-CREATION 
  
plugins/network-elements/juniper-networkguru/src/com/cloud/network/JuniperNDAPINaasServiceNetworkMapVO.java
 PRE-CREATION 
  
plugins/network-elements/juniper-networkguru/src/com/cloud/network/guru/JuniperNetworkGuru.java
 PRE-CREATION 
  
plugins/network-elements/juniper-networkguru/src/com/cloud/network/naas/dao/JuniperNDAPINaasServiceNetworkMapDao.java
 PRE-CREATION 
  
plugins/network-elements/juniper-networkguru/src/com/cloud/network/naas/dao/JuniperNDAPINaasServiceNetworkMapDaoImpl.java
 PRE-CREATION 
  
plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/DeviceInterfacesMap.java
 PRE-CREATION 
  
plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/ELSJunosL2XMLConfigs.java
 PRE-CREATION 
  
plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/JuniperNDAPIConstants.java
 PRE-CREATION 
  
plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/JunosL2XMLConfigs.java
 PRE-CREATION 
  
plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/LLDPNeighbors.java
 PRE-CREATION 
  
plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/ShowHardwareModel.java
 PRE-CREATION 
  
plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/Utils.java
 PRE-CREATION 
  
plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/netconfOperations/NetconfOperations.java
 PRE-CREATION 
  plugins/pom.xml b5e6a61 

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


Testing
---

When a Network created from Cloudstack UI is assigned a vlan-id, the same gets 
orchestrated on the Juniper switches.

We have tested the above scenarios :
(1)Various Hypervisors like KVM,VMWare,Xen
(2)LLDP is enabled on switches and hosts (to get info abt the switch-port 
connected to hosts)
(3)Integration with Network Director API 1.6


Thanks,

Pradeep HK

Re: [DISCUSS][PROPOSAL] git workflow

[Rajani Karuturi]

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  
>> 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 
>>> 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 'develop' to '4.5' and 'master'
 
 
 
 On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen 
 wrote:
> 
> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen 
 wrote:
> 
>> 
>> On Jul 23, 2014, at 12:21 PM, Nate Gordon 
 wrote:
>> 
>>> Let me ask the question, why have master be develop and a release
 branch be
>>> "master"? If we are going to follow gitflow, why not just stick with
 the
>>> norm? If master is the development branch, it might not be stable. I
 think
>>> the goal here is that we have an obvious stable branch. Anyone could
 come
>>> check out master and have the latest useable.
>> 
>> I am in favor of following the norm, so ideally master should be our
 stable branch (agreed).
>> 
>> The issue is with the transition.
>> 
>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally
 we could start a stable branch of this tag and build up bug fix releases
 all the way to 4.5 from there.
>> 
>> But all features for 4.5 are already in master.
>> 
>> So if we create a 'develop' branch of master and stabilize 'master'
 then develop is now started from a stable tag (4.4.0).
>> 
> 
> *not* started from a stable tag, and merges will be tricky, no ?
> 
>> So what's the best way to flip ? There is most likely some git magic
 that can we do.
>> 
>> 
>> The new git workflow and the transition process need to be part of a
 proposal that we get consensus on.
>> 
>> getting there :)
>> 
>> -seb
>> 
>>> 
>>> Also, I'm struggling to understand the benefit of cherry-pick. If you
>>> completely squash history, you lose a tremendous amount of context,
 which I
>>> use extensively to figure out why a bug is the way it is. Only knowing
 that
>>> the branch was merged at a given point in time doesn't give any
 context.
>>> Seeing the individual commit history of the branch helps to preserve
 the
>>> rationale for why the code was written the way it was. In theory if
 every
>>> change starts out as a branch (feature, hotfix, release), then why not
 just
>>> merge the branch once it is in a good and acceptable state?
>>> 
>>> I also agree with Mike that this

Re: [DISCUSS][PROPOSAL] git workflow

[Erik Weber]

24. juli 2014 06:28 skrev "Rajani Karuturi" 
følgende:
>
> 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?

After feature freeze or whenever it's decided to finish a release you
create a branch called release-version, e.g. release-4.6.

>From then on 'develop' focus is on 4.7 or whatever the next version is
called.

Whenever something gets merged to release-4.6 it should also get merged to
develop.

> I would prefer merges to cherry-picks.

A lot of the point in this workflow is visibility / traceability, so
merging should really be the way we work

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

If code is merged instead of cherry-picked it is easier to see / trace what
has happened , and potentially revert.

It is important though that RM's job isn't made much more difficult to
manage .

Erik

> 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 
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 
> > 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 'develop' to '4.5' and 'master'
> >>
> >>
> >>
> >> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen 
> >> wrote:
> >>>
> >>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen 
> >> wrote:
> >>>
> 
>  On Jul 23, 2014, at 12:21 PM, Nate Gordon 
> >> wrote:
> 
> > Let me ask the question, why have master be develop and a release
> >> branch be
> > "master"? If we are going to follow gitflow, why not just stick with
> >> the
> > norm? If master is the development branch, it might not be stable. I
> >> think
> > the goal here is that we have an obvious stable branch. Anyone could
> >> come
> > check out master and have the latest useable.
> 
>  I am in favor of following the norm, so ideally master should be our
> >> stable branch (agreed).
> 
>  The issue is with the transition.
> 
>  Our latest releasable product is the 4.4 branch (4.4.0 tag), so
ideally
> >> we could start a stable branch of this tag and build up bug fix
releases
> >> all the way to 4.5 from there.
> 
>  But all features for 4.5 are already in master.
> 
>  So if we create a 'develop' branch of master and stabilize 'master'
> >> then develop is now started from a stable tag (4.4.0).
> 
> >>>
> >>> *not* started from a stable tag, and merges will be tricky, no ?
> >>>
>  So what's the best way to flip ? There is most likely some git magic
> >> that can we do.
> 
> 
>  The new git workflow and the transition process need to be part of a
> >> proposal that we get consensus on.
> 
>  getting there :)
> 
>  -seb
> 
> >
> > Also, I'm struggling to understand the benefit of cherry-pick. If
you
> > completely squash history, you lose a tremendous amount of context,
> >> which I
> > use extensively to figure out why a bug is the way it is. Only
knowing
> >> that
> > the branch was merged at a given point in time doesn't give any
> >> context.
> > Seeing the individual commit history of the branch helps to preserve
> >> the
> > rationale for why the code was written the way it was. In theory if
> >> every
> > change starts out as a branch (feature, hotfix, release), then why
not
> >> just
> > merge the branch once it is in a good and acceptable state?
> >
> > I also agree with Mike that this will have to be a transition over
> >> time. It
> > will take some time to clean up master to the point where it can be
> > considered a solid stable branch. Possibly as part of the 4.5
release.
> >
> >
> > On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <
run...@gmail.com
> >>>
> > wrote:
> >
> >>
> >> On Jul 23, 2014

Re: Test Failures

[Daan Hoogland]

Priyanka,

what branch? Did you look into the surfire-reports to find out what
the test failures are?

On Thu, Jul 24, 2014 at 7:10 AM, Priyanka Deepala
 wrote:
> After running mvn install -P developer,systemvm
> Error:Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test) on
> project cloud-core: There are test failures.
> How to solve this error?



-- 
Daan

Re: [DISCUSS][PROPOSAL] git workflow

[Daan Hoogland]

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  
> 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 
>> 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 'develop' to '4.5' and 'master'
>>>
>>>
>>>
>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen 
>>> wrote:

 On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen 
>>> wrote:

>
> On Jul 23, 2014, at 12:21 PM, Nate Gordon 
>>> wrote:
>
>> Let me ask the question, why have master be develop and a release
>>> branch be
>> "master"? If we are going to follow gitflow, why not just stick with
>>> the
>> norm? If master is the development branch, it might not be stable. I
>>> think
>> the goal here is that we have an obvious stable branch. Anyone could
>>> come
>> check out master and have the latest useable.
>
> I am in favor of following the norm, so ideally master should be our
>>> stable branch (agreed).
>
> The issue is with the transition.
>
> Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally
>>> we could start a stable branch of this tag and build up bug fix releases
>>> all the way to 4.5 from there.
>
> But all features for 4.5 are already in master.
>
> So if we create a 'develop' branch of master and stabilize 'master'
>>> then develop is now started from a stable tag (4.4.0).
>

 *not* started from a stable tag, and merges will be tricky, no ?

> So what's the best way to flip ? There is most likely some git magic
>>> that can we do.
>
>
> The new git workflow and the transition process need to be part of a
>>> proposal that we get consensus on.
>
> getting there :)
>
> -seb
>
>>
>> Also, I'm struggling to understand the benefit of cherry-pick. If you
>> completely squash history, you lose a tremendous amount of context,
>>> which I
>> use extensively to figure out why a bug is the way it is. Only knowing
>>> that
>> the branch was merged at a given point in time doesn't give any
>>> context.
>> Seeing the individual commit history of the branch helps to preserve
>>> the
>> rationale for why the code was written the way it was. In theory if
>>> every
>> change starts out as a branch (feature, hotfix, release), then why not
>>> just
>> merge the branch once it is in a good and acceptable state?
>>
>> I also agree with Mike that this will have to be a transition over
>>> time. It
>> will take some time to clean up master to the point where it can be
>> considered a solid stable branch. Possibly as part of the 4.5 release.
>>
>>
>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen >>>
>> wrote:
>>
>>>
>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland 
>>> wrote:
>>>
 Sebastien,

 It seems we can do what you are calling for is creating a branch
 called 'release'. We can merge back into that branch from 4.4,
>>> master,
 4.3. I would like to see people that want a feature or bug fix in a
 branch make a fork of that branch and when that fork is working do a
 cherry-pick. The -forward conce

Re: xapi jar as separate release

[Daan Hoogland]

4.4.1:)

On Thu, Jul 24, 2014 at 2:23 AM, Alex Huang  wrote:
> Daan,
>
> The commits are
>
> e9c81c78b9ded178c983b8a50650641fb0f8ac0e
> c1c2be423099c786ccfabf960c25f651f4e19928
>
> I didn't put it into 4.4 because I thought it would be too big a risk but 
> it's been in master for 3 months now and people seem to be fine with it.  
> You'll be the judge if you like to pull it in.
>
> --Alex
>
>> -Original Message-
>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> Sent: Wednesday, July 16, 2014 7:48 AM
>> To: dev
>> Subject: Re: xapi jar as separate release
>>
>> The question put in line with actuality: is the rc I just baked ready for
>> consumption? it contains a fixed up version to deal with Ove's issue with the
>> last RC.
>>
>> On Wed, Jul 16, 2014 at 4:20 PM, Stephen Turner
>>  wrote:
>> > This is just the xapi SDK we're talking about, isn't it? Which is BSD 
>> > licensed.
>> >
>> > --
>> > Stephen Turner
>> >
>> >
>> > -Original Message-
>> > From: Tim Mackey [mailto:tmac...@gmail.com]
>> > Sent: 16 July 2014 14:39
>> > To: dev@cloudstack.apache.org
>> > Subject: Re: xapi jar as separate release
>> >
>> > Curious if XAPI being LGPL2 matters for this discussion.
>> >
>> > http://www.xenproject.org/developers/teams/xapi.html
>> >
>> > -tim
>> >
>> >
>> > On Wed, Jul 16, 2014 at 9:28 AM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>> >
>> >> Doh! I mixed up master (4.5) with 4.4 in my e-mail. My mistake. I
>> >> understand your question now, Daan.
>> >>
>> >> On Wednesday, July 16, 2014, Daan Hoogland
>> 
>> >> wrote:
>> >>
>> >> > Hey, I missed this mail. Should I have picked something into 4.4
>> >> > before calling a vote?
>> >> >
>> >> > On Wed, Jul 16, 2014 at 6:42 AM, Mike Tutkowski
>> >> > > wrote:
>> >> > > That's exactly what I was wondering, Alex. :)
>> >> > >
>> >> > >
>> >> > > On Tue, Jul 15, 2014 at 3:13 PM, Alex Huang
>> >> > > > >> > > wrote:
>> >> > >
>> >> > >> I checked into master the changes that remove our copy and just
>> >> > >> use
>> >> the
>> >> > >> copy the XenServer team checked into maven.  Is there any reason
>> >> > >> we're talking about this?
>> >> > >>
>> >> > >> --Alex
>> >> > >>
>> >> > >> > -Original Message-
>> >> > >> > From: David Nalley [mailto:da...@gnsa.us ]
>> >> > >> > Sent: Tuesday, July 15, 2014 1:40 AM
>> >> > >> > To: dev@cloudstack.apache.org 
>> >> > >> > Subject: Re: xapi jar as separate release
>> >> > >> >
>> >> > >> > XAPI is not an apache project. I do not believe that we can
>> >> > >> > sanely
>> >> > make a
>> >> > >> > separate release. Compared to bundling it with our release as
>> >> > >> > we We
>> >> > have
>> >> > >> > essentially 'forked' XAPI from the upstream at Xen Project and
>> >> > >> > made
>> >> > our
>> >> > >> > own changes. Those changes are in the latest version AIUI, but
>> >> > >> > not
>> >> the
>> >> > >> > version that we are currently using.
>> >> > >> >
>> >> > >> > --David
>> >> > >> >
>> >> > >> >
>> >> > >> > On Mon, Jul 14, 2014 at 6:17 AM, Daan Hoogland <
>> >> > daan.hoogl...@gmail.com >
>> >> > >> > wrote:
>> >> > >> > > LS,
>> >> > >> > >
>> >> > >> > > One of the issues with the last RC was that the cloudstack
>> >> > >> > > xapi
>> >> was
>> >> > >> > > not a released version (i.e. 6.2.0-1-SNAPSHOT). In the
>> >> > >> > > release
>> >> build
>> >> > >> > > it was numbered as 6.2.0-1 but not referred by that release
>> >> > >> > > number
>> >> > but
>> >> > >> > > by the snapshot id. There are several solutions to this. The
>> >> > >> > > most correct would seem to be to release the xapi module
>> >> > >> > > separately and create a release for it. I know that there
>> >> > >> > > has been some shifting
>> >> > back
>> >> > >> > > and forth with this module and I would like to get consensus
>> >> > >> > > to
>> >> > create
>> >> > >> > > a separate module and release for it.
>> >> > >> > >
>> >> > >> > > So my question: How do I get a version into the maven repo?
>> >> > >> > >
>> >> > >> > > thanks,
>> >> > >> > > --
>> >> > >> > > Daan
>> >> > >>
>> >> > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > *Mike Tutkowski*
>> >> > > *Senior CloudStack Developer, SolidFire Inc.*
>> >> > > e: mike.tutkow...@solidfire.com 
>> >> > > o: 303.746.7302
>> >> > > Advancing the way the world uses the cloud
>> >> > > *™*
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Daan
>> >> >
>> >>
>> >>
>> >> --
>> >> *Mike Tutkowski*
>> >> *Senior CloudStack Developer, SolidFire Inc.*
>> >> e: mike.tutkow...@solidfire.com
>> >> o: 303.746.7302
>> >> Advancing the way the world uses the cloud
>> >> *™*
>> >>
>>
>>
>>
>> --
>> Daan



-- 
Daan

Re: jclouds support for CloudStack

[Priyanka Deepala]

count me jclouds integration for more recent API features

Regards
Priyanka


On Wed, Jul 23, 2014 at 9:07 PM, Sebastien Goasguen 
wrote:

>
> On Jul 23, 2014, at 11:32 AM, Aled Sage  wrote:
>
> > Hi all,
> >
> > We are keen users of and contributors to jclouds [1], including for the
> CloudStack integration.
> >
> > For those who don't know it, Apache jclouds is the leading java cloud
> portability library, used by a lot of companies and several Apache projects
> including Brooklyn (for which I'm a lead) and Stratos.
> >
> > Would anyone in the CloudStack community be interested in helping out
> with updating and improving the jclouds integration? Unfortunately the
> jclouds CloudStack code hasn't had as much attention as it deserves over
> the past couple of releases.
> >
> > I just targeted Exoscale [2] (i.e. CloudStack 4.3) for the jclouds live
> test suite, and got a range of failures. There are some concrete tasks that
> can come out of this:
> >
> > * Ability to automatically skip inappropriate tests - e.g. if only
> >   basic networking is available, then report the advanced networking
> >   tests as skipped rather than failed.
> >   (This could use the API Discovery [3])
> > * Investigate other failures, to make the test suite more robust (or
> >   potentially to find regressions in CloudStack).
> > * Extend the jclouds integration for more recent API features (e.g.
> >   for API Discovery [3])
> > * Improve the publicity and documentation for jclouds CloudStack -
> >   e.g. it's not even mentioned in [4]
> >
>
> +1 from me of course. I take care of libcloud, but jclouds also needs
> attention.
>
> > It's also worth noting that the jclouds live test suite is a great
> regression test suite that could be run at least once on every CloudStack
> release. For example, it would most likely spot regressions such as
> CLOUDSTACK-6508 [5,6].
> >
>
> I applied the patch for 6508 in the 4.3 branch, so you will see it in 4.3.1
>
> > Aled
> >
> > [1] jclouds.apache.org 
> > [2] www.exoscale.ch 
> > [3] http://cloudstack.apache.org/docs/api/apidocs-4.3/user/listApis.html
> > [4] https://jclouds.apache.org/guides/
> > [5] https://issues.apache.org/jira/browse/CLOUDSTACK-6508
> > [6] https://issues.apache.org/jira/browse/JCLOUDS-557
>
>

Re: Big Switch Network Plug-in for CloudStack update

[Kuang-Ching Wang]

Hi Go, it does work with our new Big Cloud Fabric controller.

On Jul 22, 2014, at 6:13 PM, Go Chiba  wrote:

> Hi Kuang,
> 
> Does it based on your new leaf-spine architecture?
> 
> Go Chiba
> E-mail:go.ch...@gmail.com
> 
> 
> On Wed, Jul 23, 2014 at 5:33 AM, Kuang-Ching Wang  
> wrote:
> Hi,
> 
> we will be updating the Big Switch Network plugin for Cloudstack, targeting 
> the 4.6 release.  The design doc for the proposed update can be seen at 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/BigSwitch+Networking+Plugin.
>   This is a first draft, any questions and suggestions for improvements are 
> welcome.
> 
> Thanks!
> KC
> 
> 

RE: jclouds support for CloudStack

[Suresh Sadhu]

+1 
Count me on testing this integration.

-Original Message-
From: Aled Sage [mailto:aled.s...@gmail.com] 
Sent: 23 July 2014 21:02
To: dev@cloudstack.apache.org
Subject: jclouds support for CloudStack

Hi all,

We are keen users of and contributors to jclouds [1], including for the 
CloudStack integration.

For those who don't know it, Apache jclouds is the leading java cloud 
portability library, used by a lot of companies and several Apache projects 
including Brooklyn (for which I'm a lead) and Stratos.

Would anyone in the CloudStack community be interested in helping out with 
updating and improving the jclouds integration? Unfortunately the jclouds 
CloudStack code hasn't had as much attention as it deserves over the past 
couple of releases.

I just targeted Exoscale [2] (i.e. CloudStack 4.3) for the jclouds live test 
suite, and got a range of failures. There are some concrete tasks that can come 
out of this:

  * Ability to automatically skip inappropriate tests - e.g. if only
basic networking is available, then report the advanced networking
tests as skipped rather than failed.
(This could use the API Discovery [3])
  * Investigate other failures, to make the test suite more robust (or
potentially to find regressions in CloudStack).
  * Extend the jclouds integration for more recent API features (e.g.
for API Discovery [3])
  * Improve the publicity and documentation for jclouds CloudStack -
e.g. it's not even mentioned in [4]

It's also worth noting that the jclouds live test suite is a great regression 
test suite that could be run at least once on every CloudStack release. For 
example, it would most likely spot regressions such as CLOUDSTACK-6508 [5,6].

Aled

[1] jclouds.apache.org  [2] www.exoscale.ch 
 [3] 
http://cloudstack.apache.org/docs/api/apidocs-4.3/user/listApis.html
[4] https://jclouds.apache.org/guides/
[5] https://issues.apache.org/jira/browse/CLOUDSTACK-6508
[6] https://issues.apache.org/jira/browse/JCLOUDS-557

Review Request 23877: CLOUDSTACK-7177: AlertSyslogAppender does not honor a non-default port specified in syslog host parameter

[Anshul Gangwar]

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

Review request for cloudstack, Devdeep Singh, Rajesh Battala, and Sateesh 
Chodapuneedi.


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


Repository: cloudstack-git


Description
---

was filtering the ip address with ports as invalid address and hence the alerts 
were not sent to non-default ports


Diffs
-

  
plugins/alert-handlers/syslog-alerts/src/org/apache/cloudstack/syslog/AlertsSyslogAppender.java
 50ccbc1 

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


Testing
---

tested by starting the rsyslog on non-default port and sending the alerts to 
non-default port


Thanks,

Anshul Gangwar

Re: Review Request 17736: CLOUDSTACK-5999: Virtual Router does not start if Guest VM is rebooted from CloudStack

[ASF Subversion and Git Services]

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


Commit 0f85e649b64b38cf80bc1e86ac15b206bef65117 in cloudstack's branch 
refs/heads/master from Saksham Srivastava
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0f85e64 ]

CLOUDSTACK-5999: Virtual Router does not start if Guest VM is rebooted from 
CloudStack


- ASF Subversion and Git Services


On March 13, 2014, 7:31 a.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17736/
> ---
> 
> (Updated March 13, 2014, 7:31 a.m.)
> 
> 
> Review request for cloudstack, John Burwell and Murali Reddy.
> 
> 
> Bugs: CLOUDSTACK-5999
> https://issues.apache.org/jira/browse/CLOUDSTACK-5999
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> When a guest is rebooted from CloudStack, if the virtual router managing the 
> guest network of that guest is down, CloudStack will not start the virtual 
> router.
> However the router is started in case the guest vm is stopped and then 
> started.
> To mantain similarity between the 2 process it is necessary to start the VR 
> in case it is not running.
> The fix will address the same.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/vm/UserVmManagerImpl.java be00aa8 
> 
> Diff: https://reviews.apache.org/r/17736/diff/
> 
> 
> Testing
> ---
> 
> Testing:
> 1) vm in a single guest network :
>vm Reboot : If the VR is stopped: VR is first started and then 
> the VM reboots.
>vm Reboot : If the VR is running, VM reboots as it used to.
> vm Stop/Start continue to work the same.
> 
> 2)  vm having nics in multi networks :
>vm Reboot : If VR in any/all network is stopped: VRs are first 
> started and then the VM reboots.
>vm Reboot : If the VRs are running, VM reboots as it used to.
> vm Stop/Start continue to work the same.
> 
> 3) vpc :
>Tested the above scenarios for vpc also, works fine.
> 
> Patch applies cleanly.
> Build passes succesfully.
> FindBug is passed.
> Rebased against latest master.
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Re: Review Request 23257: Cloudstack network-element plugin to orchestrate Juniper's switches (for L2 services)

[Pradeep Cloudstack]

Yes Hugo

We have addressed some of your comments

-Pradeep




 From: Hugo Trippaers 
To: Hugo Trippaers  
Cc: Pradeep HK ; cloudstack 
 
Sent: Wednesday, July 23, 2014 12:57 PM
Subject: Re: Review Request 23257: Cloudstack network-element plugin to 
orchestrate Juniper's switches (for L2 services)
 



> On July 3, 2014, 11:54 a.m., Hugo Trippaers wrote:
> > plugins/network-elements/juniper-networkguru/src/com/cloud/network/JuniperNDAPINaasServiceNetworkMapVO.java,
> >  line 43
> > 
> >
> >     Possible to fix this TODO before submitting?

Pradeep,

are you planning to continue working on this?


- Hugo


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


On July 3, 2014, 11:54 a.m., Pradeep HK wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23257/
> ---
> 
> (Updated July 3, 2014, 11:54 a.m.)
> 
> 
> Review request for cloudstack and Hugo Trippaers.



> 
> 
> Bugs: CLOUDSTACK-5398
>    https://issues.apache.org/jira/browse/CLOUDSTACK-5398
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Pls refer to the Design document available @
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+network-element+plugin+to+orchestrate+Juniper%27s+switches+%28for+L2+services%29
> 
> This feature is about a Cloudstack network-element plugin to orchestrate 
> Juniper's switches.
> 
> As a first-cut, we are focussing on L2 services and we will write a 
> NetworkGuru. As part of it's implement() method we will:
> (1)Create the required logical interfaces on the Juniper switches (EX,QFX)
> (2)Create the required VLANs on the Juniper switches (EX,QFX).
> (3)Configure VLAN membership on the interfaces
> 
> Our customers need this plugin in Cloudstack deployments to automatically 
> orchestrate the Juniper switches to create Virtual Networks.
> Without this plugin, there will be a manual intervention needed to configure 
> the switches (after figuring out the
> current configuration of the switch).
> 
> We have a Network Management Platform (called JUNOS SPACE) which is heavily 
> used by customers to orchestrate Juniper's networking devices.
> It also exposes REST-ful APIs for integration with 3rdParty tools.
> The proposed Juniper's Cloudstack network-element plugin leverages these 
> REST-ful APIs to appropriately orchestrate Juniper's switches to
> create Virtual Networks
> 
> 
> Diffs
> -
> 
>   client/pom.xml 29fef4f 
>   debian/cloudstack-management.install ea3f93b 
>   debian/rules 197e243 
>   deps/install-non-oss.sh 940bd32 
>   plugins/network-elements/juniper-networkguru/pom.xml PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/resources/META-INF/cloudstack/junipernetworkguru/module.properties
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/resources/META-INF/cloudstack/junipernetworkguru/spring-junipernetworkguru-context.xml
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/JuniperNetworkGuru.properties 
>PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/JuniperNDAPINaasServiceNetworkMapVO.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/guru/JuniperNetworkGuru.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/naas/dao/JuniperNDAPINaasServiceNetworkMapDao.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/naas/dao/JuniperNDAPINaasServiceNetworkMapDaoImpl.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/DeviceInterfacesMap.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/ELSJunosL2XMLConfigs.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/JuniperNDAPIConstants.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/JunosL2XMLConfigs.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/LLDPNeighbors.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/ShowHardwareModel.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/Utils.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/netconfOperations/NetconfOperations.java
> PRE-CREATION 
>   plugins/pom.xml b5e6a61 
> 
> Diff: https://reviews.apache.org/r/23257/diff/
> 
> 
> Testing

Test Failures

[Priyanka Deepala]

After running mvn install -P developer,systemvm
Error:Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test) on
project cloud-core: There are test failures.
How to solve this error?

Re: [DISCUSS][PROPOSAL] git workflow

[Rajani Karuturi]

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  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 
> 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 'develop' to '4.5' and 'master'
>> 
>> 
>> 
>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen 
>> wrote:
>>> 
>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen 
>> wrote:
>>> 
 
 On Jul 23, 2014, at 12:21 PM, Nate Gordon 
>> wrote:
 
> Let me ask the question, why have master be develop and a release
>> branch be
> "master"? If we are going to follow gitflow, why not just stick with
>> the
> norm? If master is the development branch, it might not be stable. I
>> think
> the goal here is that we have an obvious stable branch. Anyone could
>> come
> check out master and have the latest useable.
 
 I am in favor of following the norm, so ideally master should be our
>> stable branch (agreed).
 
 The issue is with the transition.
 
 Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally
>> we could start a stable branch of this tag and build up bug fix releases
>> all the way to 4.5 from there.
 
 But all features for 4.5 are already in master.
 
 So if we create a 'develop' branch of master and stabilize 'master'
>> then develop is now started from a stable tag (4.4.0).
 
>>> 
>>> *not* started from a stable tag, and merges will be tricky, no ?
>>> 
 So what's the best way to flip ? There is most likely some git magic
>> that can we do.
 
 
 The new git workflow and the transition process need to be part of a
>> proposal that we get consensus on.
 
 getting there :)
 
 -seb
 
> 
> Also, I'm struggling to understand the benefit of cherry-pick. If you
> completely squash history, you lose a tremendous amount of context,
>> which I
> use extensively to figure out why a bug is the way it is. Only knowing
>> that
> the branch was merged at a given point in time doesn't give any
>> context.
> Seeing the individual commit history of the branch helps to preserve
>> the
> rationale for why the code was written the way it was. In theory if
>> every
> change starts out as a branch (feature, hotfix, release), then why not
>> just
> merge the branch once it is in a good and acceptable state?
> 
> I also agree with Mike that this will have to be a transition over
>> time. It
> will take some time to clean up master to the point where it can be
> considered a solid stable branch. Possibly as part of the 4.5 release.
> 
> 
> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen >> 
> wrote:
> 
>> 
>> On Jul 23, 2014, at 11:38 AM, daan Hoogland 
>> wrote:
>> 
>>> Sebastien,
>>> 
>>> It seems we can do what you are calling for is creating a branch
>>> called 'release'. We can merge back into that branch from 4.4,
>> master,
>>> 4.3. I would like to see people that want a feature or bug fix in a
>>> branch make a fork of that branch and when that fork is working do a
>>> cherry-pick. The -forward concept is now used for that but it is
>>> broken because more then for one piece of work there are commits on
>>> it. This caused me conflicts during the release. Especially painfull
>>> as not all was intended to get into the release. We can create this
>>> 'release' branch now on the basis of 4.4 and start pulling in
>> changes.
>> 
>> Yes, that's what I am thinking about too, so +1
>> 
>> Our master would become the -d

Use "OVSTunnelxxx" but not "cloudbr1" result exception

[Michael Li]

In 4.4, Can somebody explain, why use "OVSTunnelxxx" for GRE tunnel device, and 
not "cloudbr1" ?
When create VM,  this will result an exception:

2014-07-23 21:03:35,886 WARN  [kvm.resource.LibvirtComputingResource] 
(agentRequest-Handler-5:null) LibvirtException 
org.libvirt.LibvirtException: Cannot get interface MTU on 'OVSTunnel460': no 
such device   
at org.libvirt.ErrorHandler.processError(Unknown Source)
 
at org.libvirt.Connect.processError(Unknown Source) 
 
at org.libvirt.Connect.processError(Unknown Source) 
 
at org.libvirt.Connect.domainCreateXML(Unknown Source)  
 
at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1239)

at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3798)

at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:133
3)  
 
at com.cloud.agent.Agent.processRequest(Agent.java:501) 
 
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808) 
 
at com.cloud.utils.nio.Task.run(Task.java:84)   
 
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) 
  
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
  
at java.lang.Thread.run(Thread.java:722)  

I found code as below:
public InterfaceDef plug(NicTO nic, String guestOsType)
} else if (nic.getBroadcastType() == Networks.BroadcastDomainType.Vswitch) {
String vnetId = 
Networks.BroadcastDomainType.getValue(nic.getBroadcastUri());
String brName = "OVSTunnel" + vnetId;

RE: xapi jar as separate release

[Alex Huang]

Daan,

The commits are 

e9c81c78b9ded178c983b8a50650641fb0f8ac0e
c1c2be423099c786ccfabf960c25f651f4e19928

I didn't put it into 4.4 because I thought it would be too big a risk but it's 
been in master for 3 months now and people seem to be fine with it.  You'll be 
the judge if you like to pull it in.

--Alex

> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Wednesday, July 16, 2014 7:48 AM
> To: dev
> Subject: Re: xapi jar as separate release
> 
> The question put in line with actuality: is the rc I just baked ready for
> consumption? it contains a fixed up version to deal with Ove's issue with the
> last RC.
> 
> On Wed, Jul 16, 2014 at 4:20 PM, Stephen Turner
>  wrote:
> > This is just the xapi SDK we're talking about, isn't it? Which is BSD 
> > licensed.
> >
> > --
> > Stephen Turner
> >
> >
> > -Original Message-
> > From: Tim Mackey [mailto:tmac...@gmail.com]
> > Sent: 16 July 2014 14:39
> > To: dev@cloudstack.apache.org
> > Subject: Re: xapi jar as separate release
> >
> > Curious if XAPI being LGPL2 matters for this discussion.
> >
> > http://www.xenproject.org/developers/teams/xapi.html
> >
> > -tim
> >
> >
> > On Wed, Jul 16, 2014 at 9:28 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
> >
> >> Doh! I mixed up master (4.5) with 4.4 in my e-mail. My mistake. I
> >> understand your question now, Daan.
> >>
> >> On Wednesday, July 16, 2014, Daan Hoogland
> 
> >> wrote:
> >>
> >> > Hey, I missed this mail. Should I have picked something into 4.4
> >> > before calling a vote?
> >> >
> >> > On Wed, Jul 16, 2014 at 6:42 AM, Mike Tutkowski
> >> > > wrote:
> >> > > That's exactly what I was wondering, Alex. :)
> >> > >
> >> > >
> >> > > On Tue, Jul 15, 2014 at 3:13 PM, Alex Huang
> >> > >  >> > > wrote:
> >> > >
> >> > >> I checked into master the changes that remove our copy and just
> >> > >> use
> >> the
> >> > >> copy the XenServer team checked into maven.  Is there any reason
> >> > >> we're talking about this?
> >> > >>
> >> > >> --Alex
> >> > >>
> >> > >> > -Original Message-
> >> > >> > From: David Nalley [mailto:da...@gnsa.us ]
> >> > >> > Sent: Tuesday, July 15, 2014 1:40 AM
> >> > >> > To: dev@cloudstack.apache.org 
> >> > >> > Subject: Re: xapi jar as separate release
> >> > >> >
> >> > >> > XAPI is not an apache project. I do not believe that we can
> >> > >> > sanely
> >> > make a
> >> > >> > separate release. Compared to bundling it with our release as
> >> > >> > we We
> >> > have
> >> > >> > essentially 'forked' XAPI from the upstream at Xen Project and
> >> > >> > made
> >> > our
> >> > >> > own changes. Those changes are in the latest version AIUI, but
> >> > >> > not
> >> the
> >> > >> > version that we are currently using.
> >> > >> >
> >> > >> > --David
> >> > >> >
> >> > >> >
> >> > >> > On Mon, Jul 14, 2014 at 6:17 AM, Daan Hoogland <
> >> > daan.hoogl...@gmail.com >
> >> > >> > wrote:
> >> > >> > > LS,
> >> > >> > >
> >> > >> > > One of the issues with the last RC was that the cloudstack
> >> > >> > > xapi
> >> was
> >> > >> > > not a released version (i.e. 6.2.0-1-SNAPSHOT). In the
> >> > >> > > release
> >> build
> >> > >> > > it was numbered as 6.2.0-1 but not referred by that release
> >> > >> > > number
> >> > but
> >> > >> > > by the snapshot id. There are several solutions to this. The
> >> > >> > > most correct would seem to be to release the xapi module
> >> > >> > > separately and create a release for it. I know that there
> >> > >> > > has been some shifting
> >> > back
> >> > >> > > and forth with this module and I would like to get consensus
> >> > >> > > to
> >> > create
> >> > >> > > a separate module and release for it.
> >> > >> > >
> >> > >> > > So my question: How do I get a version into the maven repo?
> >> > >> > >
> >> > >> > > thanks,
> >> > >> > > --
> >> > >> > > Daan
> >> > >>
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > *Mike Tutkowski*
> >> > > *Senior CloudStack Developer, SolidFire Inc.*
> >> > > e: mike.tutkow...@solidfire.com 
> >> > > o: 303.746.7302
> >> > > Advancing the way the world uses the cloud
> >> > > *™*
> >> >
> >> >
> >> >
> >> > --
> >> > Daan
> >> >
> >>
> >>
> >> --
> >> *Mike Tutkowski*
> >> *Senior CloudStack Developer, SolidFire Inc.*
> >> e: mike.tutkow...@solidfire.com
> >> o: 303.746.7302
> >> Advancing the way the world uses the cloud
> >> *™*
> >>
> 
> 
> 
> --
> Daan

Re: [CLOUDSTACK-6181] RBD Support not implemented

[Logan Barfield]

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=173909e99d85cfcc85b017bc426950
>>> f9f16fddf0
>>>
>>> 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: download template -> delete vhd

[Nitin Mehta]

Tomas - Its not the same, there have been fixes made in ACS master/4.4.
But as Min pointed out in current ACS it works fine and deletes only the
symlink.
To work around the situation in 4.2.1 you can try setting
extract.url.expiration.interval (the value is in seconds ) in global
settings to a large value (say 1440 -- 4000 hrs ) so that the download
url never expire and do not delete the template.
Hope it helps. 

Thanks,
-Nitin



On 23/07/14 10:48 AM, "Min Chen"  wrote:

>In current ACS master, Template is not deleted from secondary storage when
>extractTemplate is called, just its symlink is deleted.
>
>Thanks
>-min
>
>On 7/23/14 4:15 AM, "Tomasz Zięba"  wrote:
>
>>Hello,
>>
>>Could someone confirm that download template deletes the vhd file from
>>secondary storage.
>>
>>We are testing on the ACS version 4.2.1 but the code responsible for
>>removing is the same in version 4.4
>>
>>https://github.com/apache/cloudstack/blob/8b6dc7ce2f0058b9cf29bd9c72e4e0d
>>b
>>9162fe6e/services/secondary-storage/server/src/org/apache/cloudstack/stor
>>a
>>ge/template/UploadManagerImpl.java
>>
>>funkcja: handleDeleteEntityDownloadURLCommand
>>
>>
>>-- 
>>Regards,
>>Tomasz Zięba
>>Twitter: @TZieba
>>LinkedIn: pl.linkedin.com/pub/tomasz-zięba-ph-d/3b/7a8/ab6/
>>
>

Re: Failed add KVM agent to CS with latest master

[Amogh Vasekar]

Reverted the offending commit 4523490d44160b054de9e943f72db1d0ce06054a,
should work now.

Thanks,
Amogh

On 7/23/14 5:40 AM, "Alex Brett"  wrote:

>> I am unable to add KVM agent with latest master build,  this issue is
>>tracked
>> in https://issues.apache.org/jira/browse/CLOUDSTACK-7170
>> 
>> Those made changes in master yesterday/today, can you please check it
>> regressed from you commit or not ?
>
>As noted on the ticket I've narrowed this down to one of the following
>three changesets:
>
>commit 3b32732459730bfd4848678c95c27e2eb653cc04
>Author: Min Chen 
>Date:   Tue Jul 22 09:47:27 2014 -0700
>
>CLOUDSTACK-7162:queryAsyncJobResult api does not return jobinstanceid.
>
>commit 1d2124dcbf48d15d23ddbdea23a29f0ab21be6f3
>Author: Hugo Trippaers 
>Date:   Tue Jul 22 17:43:49 2014 +0200
>
>Fix NPE reported on IRC, provide the user an informative error message
>
>commit 4523490d44160b054de9e943f72db1d0ce06054a
>Author: Santhosh Edukulla 
>Date:   Mon Jul 21 20:49:03 2014 +0530
>
>Fixed Coverity Issues reported
>
>Signed-off-by: Santhosh Edukulla 
>
>Alex

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

[pdion891]

Github user pdion891 commented on the pull request:

https://github.com/apache/cloudstack-docs-rn/pull/16#issuecomment-49943266
  
PR merge on master and 4.4.0 branches.
this PR can be close.


---
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: [CLOUDSTACK-6181] RBD Support not implemented

[Logan Barfield]

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=173909e99d85cfcc85b017bc426950
>> f9f16fddf0
>>
>> 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
>
>
>
>>>
>

Getting built artifacts from Jenkins

[Ian Duffy]

Hi All,

For getting the simulator up fast it would be very handy to just pull down
the cloud-client-ui.war from jenkins.

Is there any reason why we don't show built artifacts for the build master
job?

Thanks,

Ian

Re: [DISCUSS][PROPOSAL] git workflow

[Mike Tutkowski]

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 
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 'develop' to '4.5' and 'master'
>
>
>
> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen 
> wrote:
> >
> > On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen 
> wrote:
> >
> >>
> >> On Jul 23, 2014, at 12:21 PM, Nate Gordon 
> wrote:
> >>
> >>> Let me ask the question, why have master be develop and a release
> branch be
> >>> "master"? If we are going to follow gitflow, why not just stick with
> the
> >>> norm? If master is the development branch, it might not be stable. I
> think
> >>> the goal here is that we have an obvious stable branch. Anyone could
> come
> >>> check out master and have the latest useable.
> >>
> >> I am in favor of following the norm, so ideally master should be our
> stable branch (agreed).
> >>
> >> The issue is with the transition.
> >>
> >> Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally
> we could start a stable branch of this tag and build up bug fix releases
> all the way to 4.5 from there.
> >>
> >> But all features for 4.5 are already in master.
> >>
> >> So if we create a 'develop' branch of master and stabilize 'master'
> then develop is now started from a stable tag (4.4.0).
> >>
> >
> > *not* started from a stable tag, and merges will be tricky, no ?
> >
> >> So what's the best way to flip ? There is most likely some git magic
> that can we do.
> >>
> >>
> >> The new git workflow and the transition process need to be part of a
> proposal that we get consensus on.
> >>
> >> getting there :)
> >>
> >> -seb
> >>
> >>>
> >>> Also, I'm struggling to understand the benefit of cherry-pick. If you
> >>> completely squash history, you lose a tremendous amount of context,
> which I
> >>> use extensively to figure out why a bug is the way it is. Only knowing
> that
> >>> the branch was merged at a given point in time doesn't give any
> context.
> >>> Seeing the individual commit history of the branch helps to preserve
> the
> >>> rationale for why the code was written the way it was. In theory if
> every
> >>> change starts out as a branch (feature, hotfix, release), then why not
> just
> >>> merge the branch once it is in a good and acceptable state?
> >>>
> >>> I also agree with Mike that this will have to be a transition over
> time. It
> >>> will take some time to clean up master to the point where it can be
> >>> considered a solid stable branch. Possibly as part of the 4.5 release.
> >>>
> >>>
> >>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen  >
> >>> wrote:
> >>>
> 
>  On Jul 23, 2014, at 11:38 AM, daan Hoogland 
>  wrote:
> 
> > Sebastien,
> >
> > It seems we can do what you are calling for is creating a branch
> > called 'release'. We can merge back into that branch from 4.4,
> master,
> > 4.3. I would like to see people that want a feature or bug fix in a
> > branch make a fork of that branch and when that fork is working do a
> > cherry-pick. The -forward concept is now used for that but it is
> > broken because more then for one piece of work there are commits on
> > it. This caused me conflicts during the release. Especially painfull
> > as not all was intended to get into the release. We can create this
> > 'release' branch now on the basis of 4.4 and start pulling in
> changes.
> 
>  Yes, that's what I am thinking about too, so +1
> 
>  Our master would become the -develop- in gitflow terms
>  The release branch you mention would become the -master- in gitflow
> terms
> 
>  If we start now, indeed we can create 'release' from 4.4 release tag
>  (voted and shipped).
> 
>  That means that to create 4.5 we will need to merge features back into
>  'release'. it might be messy because some of those features are
> already in
>  our current master.
> 
>  But all of this will keep 'release' clean (we can keep track of bugs
> and
>  features that are in it in CHANGES file etc..)
> 
> 
> > There is a question of control. Do we allow all committers to manage
> > the release? I am for that but can imagine not everybody is.
> >
> 
>  At first I would say that only the RM can commit to 'release'. As we
> get
>  the CI in place  w

RE: Review Request 22863: CLOUDSTACK-6823 : First code drop for Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity.

[Ritu Sabharwal]

That's right Hugo.

Thanks & Regards,
Ritu S.

-Original Message-
From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
Sent: Wednesday, July 23, 2014 5:29 AM
To: dev@cloudstack.apache.org
Cc: Ritu Sabharwal
Subject: Re: Review Request 22863: CLOUDSTACK-6823 : First code drop for 
Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity.

Sudha,

I think those tests are in test/integration/component/test_brocade_vcs.py that 
Ritu included.

Cheers,

Hugo

On 23 jul. 2014, at 14:07, Sudha Ponnaganti  wrote:

> Ritu,
> 
> Would be good to add automated tests for the procedure you have outlined.  
> Marvin has already similar tests and you should be able to reuse them. 
> 
> Thanks
> /sudha
> 
>>> Testing
>>> ---
>>> 
>>> *   Create an isolated network; verify that the port-profile is created on 
>>> the Brocade switch.
>>> *   Attach a VM to the network; verify that the VMs MAC address is 
>>> associated with the port profile of the network on the Brocade switch.
>>> *   Delete VMs for an isolated network; verify that the VMs MAC address is 
>>> disassociated with the port profile of the network on the Brocade switch.
>>> *   Delete the isolated network; verify that the port-profile is deleted 
>>> from the Brocade switch.
>>> 
>>> Integration test result:
>>> 
>>> Test Brocade Network and VM Creation ... === TestName: 
>>> test_network_vcs | Status : SUCCESS === ok
>>> 
> 
> -Original Message-
> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> Sent: Wednesday, July 23, 2014 2:15 AM
> To: 
> Cc: Ritu Sabharwal
> Subject: Re: Review Request 22863: CLOUDSTACK-6823 : First code drop for 
> Brocade Network plugin to orchestrate Brocade VDX switches for L2 
> connectivity.
> 
> Hey all,
> 
> Just pushed the brocade VDX code into master.
> 
> * fing bugs is not showing any issues
> * decent unit test coverage
> * includes functional test procedure
> * majority of the functional code is contained in a plugin, minimal 
> changes to core
> 
> Cheers,
> 
> Hugo
> 
> 
> 
> On 23 jul. 2014, at 11:12, Hugo Trippaers  
> wrote:
> 
>> 
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/22863/#review48487
>> ---
>> 
>> Ship it!
>> 
>> 
>> commit 628d8e66f77053de9819436739325720710175ed
>> Author: Ritu Sabharwal 
>> Date:   Wed Jul 23 08:51:20 2014 +0200
>> 
>>   CLOUDSTACK-6823 : First code drop for Brocade Network plugin to 
>> orchestrate Brocade VDX switches for L2 connectivity
>> 
>>   Signed-off-by: Hugo Trippaers 
>> 
>> 
>> - Hugo Trippaers
>> 
>> 
>> On July 22, 2014, 9:44 p.m., Ritu  Sabharwal wrote:
>>> 
>>> ---
>>> This is an automatically generated e-mail. To reply, visit:
>>> https://reviews.apache.org/r/22863/
>>> ---
>>> 
>>> (Updated July 22, 2014, 9:44 p.m.)
>>> 
>>> 
>>> Review request for cloudstack and Hugo Trippaers.
>>> 
>>> 
>>> Bugs: CLOUDSTACK-6823
>>>   https://issues.apache.org/jira/browse/CLOUDSTACK-6823
>>> 
>>> 
>>> Repository: cloudstack-git
>>> 
>>> 
>>> Description
>>> ---
>>> 
>>> First code drop for Brocade Network plugin to orchestrate Brocade VDX 
>>> switches for L2 connectivity. Please create a new branch for Brocade plugin.
>>> 
>>> 
>>> Diffs
>>> -
>>> 
>>> api/src/com/cloud/network/Network.java 0a08f28 
>>> api/src/com/cloud/network/Networks.java 1ad3350 
>>> api/src/com/cloud/network/PhysicalNetwork.java 024b3ce 
>>> api/src/org/apache/cloudstack/network/ExternalNetworkDeviceManager.j
>>> a va e73f526  client/WEB-INF/classes/resources/messages.properties
>>> bb75b08  client/WEB-INF/classes/resources/messages_zh_CN.properties
>>> d7a0ca9  client/pom.xml 410cb19
>>> client/tomcatconf/commands.properties.in aa03949 
>>> plugins/network-elements/brocade-vcs/pom.xml PRE-CREATION 
>>> plugins/network-elements/brocade-vcs/resources/BrocadeInterfaceSchem
>>> a
>>> .xsd PRE-CREATION
>>> plugins/network-elements/brocade-vcs/resources/BrocadePortProfileSch
>>> e
>>> ma.xsd PRE-CREATION
>>> plugins/network-elements/brocade-vcs/resources/BrocadeShowVcsSchema.
>>> x
>>> sd PRE-CREATION
>>> plugins/network-elements/brocade-vcs/resources/META-INF/cloudstack/v
>>> c
>>> s/module.properties PRE-CREATION
>>> plugins/network-elements/brocade-vcs/resources/META-INF/cloudstack/v
>>> c s/spring-vcs-context.xml PRE-CREATION 
>>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/Associa
>>> t eMacToNetworkAnswer.java PRE-CREATION 
>>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/Associa
>>> t eMacToNetworkCommand.java PRE-CREATION 
>>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/CreateN
>>> e
>>> tworkAnswer.java PRE-CREATION
>>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/CreateN
>>> e
>>> 

RE: Review Request 22863: CLOUDSTACK-6823 : First code drop for Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity.

[Ritu Sabharwal]

Hi Hugo,

Thanks for reviewing and approving the Brocade VCS plugin.

Thanks & Regards,
Ritu Sabharwal.

-Original Message-
From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
Sent: Wednesday, July 23, 2014 2:15 AM
To: 
Cc: Ritu Sabharwal
Subject: Re: Review Request 22863: CLOUDSTACK-6823 : First code drop for 
Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity.

Hey all,

Just pushed the brocade VDX code into master.

* fing bugs is not showing any issues
* decent unit test coverage
* includes functional test procedure
* majority of the functional code is contained in a plugin, minimal changes to 
core

Cheers,

Hugo



On 23 jul. 2014, at 11:12, Hugo Trippaers  wrote:

> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22863/#review48487
> ---
> 
> Ship it!
> 
> 
> commit 628d8e66f77053de9819436739325720710175ed
> Author: Ritu Sabharwal 
> Date:   Wed Jul 23 08:51:20 2014 +0200
> 
>CLOUDSTACK-6823 : First code drop for Brocade Network plugin to 
> orchestrate Brocade VDX switches for L2 connectivity
> 
>Signed-off-by: Hugo Trippaers 
> 
> 
> - Hugo Trippaers
> 
> 
> On July 22, 2014, 9:44 p.m., Ritu  Sabharwal wrote:
>> 
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/22863/
>> ---
>> 
>> (Updated July 22, 2014, 9:44 p.m.)
>> 
>> 
>> Review request for cloudstack and Hugo Trippaers.
>> 
>> 
>> Bugs: CLOUDSTACK-6823
>>https://issues.apache.org/jira/browse/CLOUDSTACK-6823
>> 
>> 
>> Repository: cloudstack-git
>> 
>> 
>> Description
>> ---
>> 
>> First code drop for Brocade Network plugin to orchestrate Brocade VDX 
>> switches for L2 connectivity. Please create a new branch for Brocade plugin.
>> 
>> 
>> Diffs
>> -
>> 
>>  api/src/com/cloud/network/Network.java 0a08f28  
>> api/src/com/cloud/network/Networks.java 1ad3350  
>> api/src/com/cloud/network/PhysicalNetwork.java 024b3ce  
>> api/src/org/apache/cloudstack/network/ExternalNetworkDeviceManager.ja
>> va e73f526  client/WEB-INF/classes/resources/messages.properties 
>> bb75b08  client/WEB-INF/classes/resources/messages_zh_CN.properties 
>> d7a0ca9  client/pom.xml 410cb19  
>> client/tomcatconf/commands.properties.in aa03949  
>> plugins/network-elements/brocade-vcs/pom.xml PRE-CREATION  
>> plugins/network-elements/brocade-vcs/resources/BrocadeInterfaceSchema
>> .xsd PRE-CREATION  
>> plugins/network-elements/brocade-vcs/resources/BrocadePortProfileSche
>> ma.xsd PRE-CREATION  
>> plugins/network-elements/brocade-vcs/resources/BrocadeShowVcsSchema.x
>> sd PRE-CREATION  
>> plugins/network-elements/brocade-vcs/resources/META-INF/cloudstack/vc
>> s/module.properties PRE-CREATION  
>> plugins/network-elements/brocade-vcs/resources/META-INF/cloudstack/vc
>> s/spring-vcs-context.xml PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/Associat
>> eMacToNetworkAnswer.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/Associat
>> eMacToNetworkCommand.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/CreateNe
>> tworkAnswer.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/CreateNe
>> tworkCommand.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/DeleteNe
>> tworkAnswer.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/DeleteNe
>> tworkCommand.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/Disassoc
>> iateMacFromNetworkAnswer.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/Disassoc
>> iateMacFromNetworkCommand.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/StartupB
>> rocadeVcsCommand.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/api/commands/AddBr
>> ocadeVcsDeviceCmd.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/api/commands/Delet
>> eBrocadeVcsDeviceCmd.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/api/commands/ListB
>> rocadeVcsDeviceNetworksCmd.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/api/commands/ListB
>> rocadeVcsDevicesCmd.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/api/response/Broca
>> deVcsDeviceResponse.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/network/BrocadeVcs
>> DeviceVO.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/network/BrocadeVcs
>> NetworkVlanMappingVO.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/network/brocade/

Re: [DISCUSS][PROPOSAL] git workflow

[Daan Hoogland]

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 'develop' to '4.5' and 'master'



On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen  wrote:
>
> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen  wrote:
>
>>
>> On Jul 23, 2014, at 12:21 PM, Nate Gordon  wrote:
>>
>>> Let me ask the question, why have master be develop and a release branch be
>>> "master"? If we are going to follow gitflow, why not just stick with the
>>> norm? If master is the development branch, it might not be stable. I think
>>> the goal here is that we have an obvious stable branch. Anyone could come
>>> check out master and have the latest useable.
>>
>> I am in favor of following the norm, so ideally master should be our stable 
>> branch (agreed).
>>
>> The issue is with the transition.
>>
>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally we 
>> could start a stable branch of this tag and build up bug fix releases all 
>> the way to 4.5 from there.
>>
>> But all features for 4.5 are already in master.
>>
>> So if we create a 'develop' branch of master and stabilize 'master' then 
>> develop is now started from a stable tag (4.4.0).
>>
>
> *not* started from a stable tag, and merges will be tricky, no ?
>
>> So what's the best way to flip ? There is most likely some git magic that 
>> can we do.
>>
>>
>> The new git workflow and the transition process need to be part of a 
>> proposal that we get consensus on.
>>
>> getting there :)
>>
>> -seb
>>
>>>
>>> Also, I'm struggling to understand the benefit of cherry-pick. If you
>>> completely squash history, you lose a tremendous amount of context, which I
>>> use extensively to figure out why a bug is the way it is. Only knowing that
>>> the branch was merged at a given point in time doesn't give any context.
>>> Seeing the individual commit history of the branch helps to preserve the
>>> rationale for why the code was written the way it was. In theory if every
>>> change starts out as a branch (feature, hotfix, release), then why not just
>>> merge the branch once it is in a good and acceptable state?
>>>
>>> I also agree with Mike that this will have to be a transition over time. It
>>> will take some time to clean up master to the point where it can be
>>> considered a solid stable branch. Possibly as part of the 4.5 release.
>>>
>>>
>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen 
>>> wrote:
>>>

 On Jul 23, 2014, at 11:38 AM, daan Hoogland 
 wrote:

> Sebastien,
>
> It seems we can do what you are calling for is creating a branch
> called 'release'. We can merge back into that branch from 4.4, master,
> 4.3. I would like to see people that want a feature or bug fix in a
> branch make a fork of that branch and when that fork is working do a
> cherry-pick. The -forward concept is now used for that but it is
> broken because more then for one piece of work there are commits on
> it. This caused me conflicts during the release. Especially painfull
> as not all was intended to get into the release. We can create this
> 'release' branch now on the basis of 4.4 and start pulling in changes.

 Yes, that's what I am thinking about too, so +1

 Our master would become the -develop- in gitflow terms
 The release branch you mention would become the -master- in gitflow terms

 If we start now, indeed we can create 'release' from 4.4 release tag
 (voted and shipped).

 That means that to create 4.5 we will need to merge features back into
 'release'. it might be messy because some of those features are already in
 our current master.

 But all of this will keep 'release' clean (we can keep track of bugs and
 features that are in it in CHANGES file etc..)


> There is a question of control. Do we allow all committers to manage
> the release? I am for that but can imagine not everybody is.
>

 At first I would say that only the RM can commit to 'release'. As we get
 the CI in place  we could relax this and allow commits that pass the CI to
 get into 'release', but right now I would vote for a tighter control of
 'release'.

> rule number 1 will be: you are going to do something to the code, you
> start by creating a branch.
>
> right?
>
> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen 
 wrote:
>>
>> On Jul 23, 2014, at 11:19 AM, Sam Schmit 
 wrote:
>>
>>> Hey everyone,
>>>
>>> I've been a developer for a handful of years and have had my share of
>>> experience with d

Re: GSoC update

[Mike Tutkowski]

Nice job! :)


On Wed, Jul 23, 2014 at 12:36 PM, Sebastien Goasguen 
wrote:

> Darren's work (and Ian from last year) featured on google open source blog:
>
> http://google-opensource.blogspot.com
>
> Congrats to both of them,
>
> -sebastien
>



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

GSoC update

[Sebastien Goasguen]

Darren's work (and Ian from last year) featured on google open source blog:

http://google-opensource.blogspot.com

Congrats to both of them,

-sebastien

Re: download template -> delete vhd

[Min Chen]

In current ACS master, Template is not deleted from secondary storage when
extractTemplate is called, just its symlink is deleted.

Thanks
-min

On 7/23/14 4:15 AM, "Tomasz Zięba"  wrote:

>Hello,
>
>Could someone confirm that download template deletes the vhd file from
>secondary storage.
>
>We are testing on the ACS version 4.2.1 but the code responsible for
>removing is the same in version 4.4
>
>https://github.com/apache/cloudstack/blob/8b6dc7ce2f0058b9cf29bd9c72e4e0db
>9162fe6e/services/secondary-storage/server/src/org/apache/cloudstack/stora
>ge/template/UploadManagerImpl.java
>
>funkcja: handleDeleteEntityDownloadURLCommand
>
>
>-- 
>Regards,
>Tomasz Zięba
>Twitter: @TZieba
>LinkedIn: pl.linkedin.com/pub/tomasz-zięba-ph-d/3b/7a8/ab6/
>

RE: Need edit rights for Wiki to improve Marvin - Testing with Python tutorial

[Santhosh Edukulla]

its not the nose version, its the Marvin plugin which has change.
It was changed in 4.4-forward and master 

From: Luis Henrique Okama [ok...@corp.globo.com]
Sent: Wednesday, July 23, 2014 1:25 PM
To: dev@cloudstack.apache.org
Cc: Santhosh Edukulla; Daan Hoogland; int-toolkit
Subject: Re: Need edit rights for Wiki to improve Marvin - Testing with Python 
tutorial

Hi Miguel and Santhosh,

I actually was the person who edited the wiki page and inserted the '--load' 
option to run nosetest in the past.
I'm running nosetest v. 1.3.3 and without '--load' option, the nosetest returns 
an error.

Which version of nosetest are you guys using?

cheers,



On Wed, Jul 23, 2014 at 9:46 AM, Miguel Ferreira 
mailto:mferre...@schubergphilis.com>> wrote:
I’ve fixed all problems I found with that page.

Cheers,
Miguel

On 23 Jul 2014, at 12:28, Santhosh Edukulla 
mailto:santhosh.eduku...@citrix.com>> wrote:

> These were new changes done to marvin, during the same time, we edited wiki 
> pages to reflect the changes, either it was reedited by some body or this 
> particular place got missed. Please add the one with latest.
>
> I can add that change for you if you require.
>
> Santhosh
> 
> From: Miguel Ferreira 
> [mferre...@schubergphilis.com]
> Sent: Wednesday, July 23, 2014 6:23 AM
> To: Daan Hoogland
> Cc: dev; int-toolkit
> Subject: Re: Need edit rights for Wiki to improve Marvin - Testing with 
> Python tutorial
>
> Thanks Daan,
>
> By the way, just posted this on IRC dev channel, but got no reply there so 
> here it goes:
>> In the section about running a test from command line, there is a command 
>> like this: "nosetests --with-marvin --marvin-config=demo.cfg --load 
>> test_deploy_vm.py"
>> However, the version I have of nosetests (installed recently) does not have 
>> a "—load" options
>> Furthermore, running the smoke tests from command line always fails because 
>> the nose-marvin-plugin does not inject the apiclient into the test case 
>> (that is because te plugin only doe injection when loading tests form 
>> TestCase class and not from name, as it happens from the command line)
>
> Should I be using a specific/patched version of nosetests?
> Or should the “run from command line” section be removed?
>
> Cheers,
> Miguel
>
>
> On 23 Jul 2014, at 12:16, Daan Hoogland 
> mailto:daan.hoogl...@gmail.com>> wrote:
>
>> On Wed, Jul 23, 2014 at 11:56 AM, Miguel Ferreira
>> mailto:mferre...@schubergphilis.com>> wrote:
>>> miguelferreira
>>
>>
>> in
>>
>> --
>> Daan
>




--
Atc,

Okama

Re: [DISCUSS][PROPOSAL] git workflow

[Mike Tutkowski]

Right, 'master' should - theoretically - be somewhat stable at present as
we are post 4.5 Feature Freeze.

I guess we should address Daan's question of what 'develop' means in this
new model? When can code be checked into 'develop', but not 'master'? Code
that goes into 'master' must be deemed 'stable.' What about 'develop'? Why
do we have it if we're using our own branches for development?

Thanks for clarifying.


On Wed, Jul 23, 2014 at 11:01 AM, Erik Weber  wrote:

> Must it start today, or when (if) the vote passes? Feature freeze for 4.5
> has theoretically passed, so basically master branch should now be work in
> progress towards a stable branch.
>
> So I'd say; create a 'develop' branch off the current master.
>
> Keep master as is, and only merge bugfixes until it is deemed stable and
> 4.5 is released.
>
> 4.6 development and new features goes into branches of 'develop'.
>
> Erik
> 23. juli 2014 18:30 skrev "Sebastien Goasguen" 
> følgende:
>
> >
> > On Jul 23, 2014, at 12:21 PM, Nate Gordon 
> wrote:
> >
> > > Let me ask the question, why have master be develop and a release
> branch
> > be
> > > "master"? If we are going to follow gitflow, why not just stick with
> the
> > > norm? If master is the development branch, it might not be stable. I
> > think
> > > the goal here is that we have an obvious stable branch. Anyone could
> come
> > > check out master and have the latest useable.
> >
> > I am in favor of following the norm, so ideally master should be our
> > stable branch (agreed).
> >
> > The issue is with the transition.
> >
> > Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally
> we
> > could start a stable branch of this tag and build up bug fix releases all
> > the way to 4.5 from there.
> >
> > But all features for 4.5 are already in master.
> >
> > So if we create a 'develop' branch of master and stabilize 'master' then
> > develop is now started from a stable tag (4.4.0).
> >
> > So what's the best way to flip ? There is most likely some git magic that
> > can we do.
> >
> >
> > The new git workflow and the transition process need to be part of a
> > proposal that we get consensus on.
> >
> > getting there :)
> >
> > -seb
> >
> > >
> > > Also, I'm struggling to understand the benefit of cherry-pick. If you
> > > completely squash history, you lose a tremendous amount of context,
> > which I
> > > use extensively to figure out why a bug is the way it is. Only knowing
> > that
> > > the branch was merged at a given point in time doesn't give any
> context.
> > > Seeing the individual commit history of the branch helps to preserve
> the
> > > rationale for why the code was written the way it was. In theory if
> every
> > > change starts out as a branch (feature, hotfix, release), then why not
> > just
> > > merge the branch once it is in a good and acceptable state?
> > >
> > > I also agree with Mike that this will have to be a transition over
> time.
> > It
> > > will take some time to clean up master to the point where it can be
> > > considered a solid stable branch. Possibly as part of the 4.5 release.
> > >
> > >
> > > On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen  >
> > > wrote:
> > >
> > >>
> > >> On Jul 23, 2014, at 11:38 AM, daan Hoogland 
> > >> wrote:
> > >>
> > >>> Sebastien,
> > >>>
> > >>> It seems we can do what you are calling for is creating a branch
> > >>> called 'release'. We can merge back into that branch from 4.4,
> master,
> > >>> 4.3. I would like to see people that want a feature or bug fix in a
> > >>> branch make a fork of that branch and when that fork is working do a
> > >>> cherry-pick. The -forward concept is now used for that but it is
> > >>> broken because more then for one piece of work there are commits on
> > >>> it. This caused me conflicts during the release. Especially painfull
> > >>> as not all was intended to get into the release. We can create this
> > >>> 'release' branch now on the basis of 4.4 and start pulling in
> changes.
> > >>
> > >> Yes, that's what I am thinking about too, so +1
> > >>
> > >> Our master would become the -develop- in gitflow terms
> > >> The release branch you mention would become the -master- in gitflow
> > terms
> > >>
> > >> If we start now, indeed we can create 'release' from 4.4 release tag
> > >> (voted and shipped).
> > >>
> > >> That means that to create 4.5 we will need to merge features back into
> > >> 'release'. it might be messy because some of those features are
> already
> > in
> > >> our current master.
> > >>
> > >> But all of this will keep 'release' clean (we can keep track of bugs
> and
> > >> features that are in it in CHANGES file etc..)
> > >>
> > >>
> > >>> There is a question of control. Do we allow all committers to manage
> > >>> the release? I am for that but can imagine not everybody is.
> > >>>
> > >>
> > >> At first I would say that only the RM can commit to 'release'. As we
> get
> > >> the CI in place  we could relax this and allow commits that pass the

Re: Need edit rights for Wiki to improve Marvin - Testing with Python tutorial

[Luis Henrique Okama]

Hi Miguel and Santhosh,

I actually was the person who edited the wiki page and inserted the
'--load' option to run nosetest in the past.
I'm running nosetest v. 1.3.3 and without '--load' option, the nosetest
returns an error.

Which version of nosetest are you guys using?

cheers,



On Wed, Jul 23, 2014 at 9:46 AM, Miguel Ferreira <
mferre...@schubergphilis.com> wrote:

> I’ve fixed all problems I found with that page.
>
> Cheers,
> Miguel
>
> On 23 Jul 2014, at 12:28, Santhosh Edukulla 
> wrote:
>
> > These were new changes done to marvin, during the same time, we edited
> wiki pages to reflect the changes, either it was reedited by some body or
> this particular place got missed. Please add the one with latest.
> >
> > I can add that change for you if you require.
> >
> > Santhosh
> > 
> > From: Miguel Ferreira [mferre...@schubergphilis.com]
> > Sent: Wednesday, July 23, 2014 6:23 AM
> > To: Daan Hoogland
> > Cc: dev; int-toolkit
> > Subject: Re: Need edit rights for Wiki to improve Marvin - Testing with
> Python tutorial
> >
> > Thanks Daan,
> >
> > By the way, just posted this on IRC dev channel, but got no reply there
> so here it goes:
> >> In the section about running a test from command line, there is a
> command like this: "nosetests --with-marvin --marvin-config=demo.cfg --load
> test_deploy_vm.py"
> >> However, the version I have of nosetests (installed recently) does not
> have a "—load" options
> >> Furthermore, running the smoke tests from command line always fails
> because the nose-marvin-plugin does not inject the apiclient into the test
> case (that is because te plugin only doe injection when loading tests form
> TestCase class and not from name, as it happens from the command line)
> >
> > Should I be using a specific/patched version of nosetests?
> > Or should the “run from command line” section be removed?
> >
> > Cheers,
> > Miguel
> >
> >
> > On 23 Jul 2014, at 12:16, Daan Hoogland  wrote:
> >
> >> On Wed, Jul 23, 2014 at 11:56 AM, Miguel Ferreira
> >>  wrote:
> >>> miguelferreira
> >>
> >>
> >> in
> >>
> >> --
> >> Daan
> >
>
>


-- 
Atc,

Okama

Re: [DISCUSS][PROPOSAL] git workflow

[Erik Weber]

Must it start today, or when (if) the vote passes? Feature freeze for 4.5
has theoretically passed, so basically master branch should now be work in
progress towards a stable branch.

So I'd say; create a 'develop' branch off the current master.

Keep master as is, and only merge bugfixes until it is deemed stable and
4.5 is released.

4.6 development and new features goes into branches of 'develop'.

Erik
23. juli 2014 18:30 skrev "Sebastien Goasguen"  følgende:

>
> On Jul 23, 2014, at 12:21 PM, Nate Gordon  wrote:
>
> > Let me ask the question, why have master be develop and a release branch
> be
> > "master"? If we are going to follow gitflow, why not just stick with the
> > norm? If master is the development branch, it might not be stable. I
> think
> > the goal here is that we have an obvious stable branch. Anyone could come
> > check out master and have the latest useable.
>
> I am in favor of following the norm, so ideally master should be our
> stable branch (agreed).
>
> The issue is with the transition.
>
> Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally we
> could start a stable branch of this tag and build up bug fix releases all
> the way to 4.5 from there.
>
> But all features for 4.5 are already in master.
>
> So if we create a 'develop' branch of master and stabilize 'master' then
> develop is now started from a stable tag (4.4.0).
>
> So what's the best way to flip ? There is most likely some git magic that
> can we do.
>
>
> The new git workflow and the transition process need to be part of a
> proposal that we get consensus on.
>
> getting there :)
>
> -seb
>
> >
> > Also, I'm struggling to understand the benefit of cherry-pick. If you
> > completely squash history, you lose a tremendous amount of context,
> which I
> > use extensively to figure out why a bug is the way it is. Only knowing
> that
> > the branch was merged at a given point in time doesn't give any context.
> > Seeing the individual commit history of the branch helps to preserve the
> > rationale for why the code was written the way it was. In theory if every
> > change starts out as a branch (feature, hotfix, release), then why not
> just
> > merge the branch once it is in a good and acceptable state?
> >
> > I also agree with Mike that this will have to be a transition over time.
> It
> > will take some time to clean up master to the point where it can be
> > considered a solid stable branch. Possibly as part of the 4.5 release.
> >
> >
> > On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen 
> > wrote:
> >
> >>
> >> On Jul 23, 2014, at 11:38 AM, daan Hoogland 
> >> wrote:
> >>
> >>> Sebastien,
> >>>
> >>> It seems we can do what you are calling for is creating a branch
> >>> called 'release'. We can merge back into that branch from 4.4, master,
> >>> 4.3. I would like to see people that want a feature or bug fix in a
> >>> branch make a fork of that branch and when that fork is working do a
> >>> cherry-pick. The -forward concept is now used for that but it is
> >>> broken because more then for one piece of work there are commits on
> >>> it. This caused me conflicts during the release. Especially painfull
> >>> as not all was intended to get into the release. We can create this
> >>> 'release' branch now on the basis of 4.4 and start pulling in changes.
> >>
> >> Yes, that's what I am thinking about too, so +1
> >>
> >> Our master would become the -develop- in gitflow terms
> >> The release branch you mention would become the -master- in gitflow
> terms
> >>
> >> If we start now, indeed we can create 'release' from 4.4 release tag
> >> (voted and shipped).
> >>
> >> That means that to create 4.5 we will need to merge features back into
> >> 'release'. it might be messy because some of those features are already
> in
> >> our current master.
> >>
> >> But all of this will keep 'release' clean (we can keep track of bugs and
> >> features that are in it in CHANGES file etc..)
> >>
> >>
> >>> There is a question of control. Do we allow all committers to manage
> >>> the release? I am for that but can imagine not everybody is.
> >>>
> >>
> >> At first I would say that only the RM can commit to 'release'. As we get
> >> the CI in place  we could relax this and allow commits that pass the CI
> to
> >> get into 'release', but right now I would vote for a tighter control of
> >> 'release'.
> >>
> >>> rule number 1 will be: you are going to do something to the code, you
> >>> start by creating a branch.
> >>>
> >>> right?
> >>>
> >>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen 
> >> wrote:
> 
>  On Jul 23, 2014, at 11:19 AM, Sam Schmit 
> >> wrote:
> 
> > Hey everyone,
> >
> > I've been a developer for a handful of years and have had my share of
> > experience with different version control systems.  I've used (for
> >> better
> > or worse) Git, Perforce, Rational ClearCast, and SVN.
> >
> > Each of these solutions offers their own unique set of features,

Re: [DISCUSS][PROPOSAL] git workflow

[Sebastien Goasguen]

On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen  wrote:

> 
> On Jul 23, 2014, at 12:21 PM, Nate Gordon  wrote:
> 
>> Let me ask the question, why have master be develop and a release branch be
>> "master"? If we are going to follow gitflow, why not just stick with the
>> norm? If master is the development branch, it might not be stable. I think
>> the goal here is that we have an obvious stable branch. Anyone could come
>> check out master and have the latest useable.
> 
> I am in favor of following the norm, so ideally master should be our stable 
> branch (agreed).
> 
> The issue is with the transition.
> 
> Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally we 
> could start a stable branch of this tag and build up bug fix releases all the 
> way to 4.5 from there.
> 
> But all features for 4.5 are already in master.
> 
> So if we create a 'develop' branch of master and stabilize 'master' then 
> develop is now started from a stable tag (4.4.0).
> 

*not* started from a stable tag, and merges will be tricky, no ?

> So what's the best way to flip ? There is most likely some git magic that can 
> we do.
> 
> 
> The new git workflow and the transition process need to be part of a proposal 
> that we get consensus on.
> 
> getting there :)
> 
> -seb
> 
>> 
>> Also, I'm struggling to understand the benefit of cherry-pick. If you
>> completely squash history, you lose a tremendous amount of context, which I
>> use extensively to figure out why a bug is the way it is. Only knowing that
>> the branch was merged at a given point in time doesn't give any context.
>> Seeing the individual commit history of the branch helps to preserve the
>> rationale for why the code was written the way it was. In theory if every
>> change starts out as a branch (feature, hotfix, release), then why not just
>> merge the branch once it is in a good and acceptable state?
>> 
>> I also agree with Mike that this will have to be a transition over time. It
>> will take some time to clean up master to the point where it can be
>> considered a solid stable branch. Possibly as part of the 4.5 release.
>> 
>> 
>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen 
>> wrote:
>> 
>>> 
>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland 
>>> wrote:
>>> 
 Sebastien,
 
 It seems we can do what you are calling for is creating a branch
 called 'release'. We can merge back into that branch from 4.4, master,
 4.3. I would like to see people that want a feature or bug fix in a
 branch make a fork of that branch and when that fork is working do a
 cherry-pick. The -forward concept is now used for that but it is
 broken because more then for one piece of work there are commits on
 it. This caused me conflicts during the release. Especially painfull
 as not all was intended to get into the release. We can create this
 'release' branch now on the basis of 4.4 and start pulling in changes.
>>> 
>>> Yes, that's what I am thinking about too, so +1
>>> 
>>> Our master would become the -develop- in gitflow terms
>>> The release branch you mention would become the -master- in gitflow terms
>>> 
>>> If we start now, indeed we can create 'release' from 4.4 release tag
>>> (voted and shipped).
>>> 
>>> That means that to create 4.5 we will need to merge features back into
>>> 'release'. it might be messy because some of those features are already in
>>> our current master.
>>> 
>>> But all of this will keep 'release' clean (we can keep track of bugs and
>>> features that are in it in CHANGES file etc..)
>>> 
>>> 
 There is a question of control. Do we allow all committers to manage
 the release? I am for that but can imagine not everybody is.
 
>>> 
>>> At first I would say that only the RM can commit to 'release'. As we get
>>> the CI in place  we could relax this and allow commits that pass the CI to
>>> get into 'release', but right now I would vote for a tighter control of
>>> 'release'.
>>> 
 rule number 1 will be: you are going to do something to the code, you
 start by creating a branch.
 
 right?
 
 On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen 
>>> wrote:
> 
> On Jul 23, 2014, at 11:19 AM, Sam Schmit 
>>> wrote:
> 
>> Hey everyone,
>> 
>> I've been a developer for a handful of years and have had my share of
>> experience with different version control systems.  I've used (for
>>> better
>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>> 
>> Each of these solutions offers their own unique set of features,
>>> strengths
>> and weaknesses.  As there are so many systems that are good at specific
>> things, it seems best to use the features that the chosen system is
>>> best at.
>> 
>> Git is great at branching, merging and using that structure to
>>> maintain and
>> control how changes get into the primary branches.  Git tools even make
>> this easy by integrating directly into 

Re: Review Request 22939: CLOUDSTACK-6460 - CLVM primary storage migration fails due to incorrect identification of source format.

[Simon Weller]

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

(Updated July 23, 2014, 4:30 p.m.)


Review request for cloudstack, edison su and Marcus Sorensen.


Changes
---

Added a couple of committers with knowledge of KVM and the CLVM implementation.


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


Repository: cloudstack-git


Description
---

Addresses CLOUDSTACK-6460.
CLVM storage source was being identified as QCOW2, rather than raw when 
attempting a primary storage migration.  This caused the migration to fail when 
qemu-img attempted to image the file back from secondary storage to the new 
primary storage selected. This patch forces CLVM to be treated as RAW while 
continuing to acquire sourceFormat from other storage types via 
disk.getFormat();


Diffs
-

  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java
 ecf3e08 

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


Testing
---

Stop VM. Migrate from one primary storage to another. Migration completes 
successfully. Start vm.


Thanks,

Simon Weller

Re: [DISCUSS][PROPOSAL] git workflow

[Sebastien Goasguen]

On Jul 23, 2014, at 12:21 PM, Nate Gordon  wrote:

> Let me ask the question, why have master be develop and a release branch be
> "master"? If we are going to follow gitflow, why not just stick with the
> norm? If master is the development branch, it might not be stable. I think
> the goal here is that we have an obvious stable branch. Anyone could come
> check out master and have the latest useable.

I am in favor of following the norm, so ideally master should be our stable 
branch (agreed).

The issue is with the transition.

Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally we 
could start a stable branch of this tag and build up bug fix releases all the 
way to 4.5 from there.

But all features for 4.5 are already in master.

So if we create a 'develop' branch of master and stabilize 'master' then 
develop is now started from a stable tag (4.4.0).

So what's the best way to flip ? There is most likely some git magic that can 
we do.


The new git workflow and the transition process need to be part of a proposal 
that we get consensus on.

getting there :)

-seb

> 
> Also, I'm struggling to understand the benefit of cherry-pick. If you
> completely squash history, you lose a tremendous amount of context, which I
> use extensively to figure out why a bug is the way it is. Only knowing that
> the branch was merged at a given point in time doesn't give any context.
> Seeing the individual commit history of the branch helps to preserve the
> rationale for why the code was written the way it was. In theory if every
> change starts out as a branch (feature, hotfix, release), then why not just
> merge the branch once it is in a good and acceptable state?
> 
> I also agree with Mike that this will have to be a transition over time. It
> will take some time to clean up master to the point where it can be
> considered a solid stable branch. Possibly as part of the 4.5 release.
> 
> 
> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen 
> wrote:
> 
>> 
>> On Jul 23, 2014, at 11:38 AM, daan Hoogland 
>> wrote:
>> 
>>> Sebastien,
>>> 
>>> It seems we can do what you are calling for is creating a branch
>>> called 'release'. We can merge back into that branch from 4.4, master,
>>> 4.3. I would like to see people that want a feature or bug fix in a
>>> branch make a fork of that branch and when that fork is working do a
>>> cherry-pick. The -forward concept is now used for that but it is
>>> broken because more then for one piece of work there are commits on
>>> it. This caused me conflicts during the release. Especially painfull
>>> as not all was intended to get into the release. We can create this
>>> 'release' branch now on the basis of 4.4 and start pulling in changes.
>> 
>> Yes, that's what I am thinking about too, so +1
>> 
>> Our master would become the -develop- in gitflow terms
>> The release branch you mention would become the -master- in gitflow terms
>> 
>> If we start now, indeed we can create 'release' from 4.4 release tag
>> (voted and shipped).
>> 
>> That means that to create 4.5 we will need to merge features back into
>> 'release'. it might be messy because some of those features are already in
>> our current master.
>> 
>> But all of this will keep 'release' clean (we can keep track of bugs and
>> features that are in it in CHANGES file etc..)
>> 
>> 
>>> There is a question of control. Do we allow all committers to manage
>>> the release? I am for that but can imagine not everybody is.
>>> 
>> 
>> At first I would say that only the RM can commit to 'release'. As we get
>> the CI in place  we could relax this and allow commits that pass the CI to
>> get into 'release', but right now I would vote for a tighter control of
>> 'release'.
>> 
>>> rule number 1 will be: you are going to do something to the code, you
>>> start by creating a branch.
>>> 
>>> right?
>>> 
>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen 
>> wrote:
 
 On Jul 23, 2014, at 11:19 AM, Sam Schmit 
>> wrote:
 
> Hey everyone,
> 
> I've been a developer for a handful of years and have had my share of
> experience with different version control systems.  I've used (for
>> better
> or worse) Git, Perforce, Rational ClearCast, and SVN.
> 
> Each of these solutions offers their own unique set of features,
>> strengths
> and weaknesses.  As there are so many systems that are good at specific
> things, it seems best to use the features that the chosen system is
>> best at.
> 
> Git is great at branching, merging and using that structure to
>> maintain and
> control how changes get into the primary branches.  Git tools even make
> this easy by integrating directly into the "Gitflow" to make branching
>> and
> merging that much easier.  It would seem counter-intuitive to NOT make
>> use
> of these built-in capabilities.
> 
> In addition to that, I know that the current method of change
>> management is
> incredibly frustr

Re: Build failed in Jenkins: cloudstack-4.4-maven-build #389

[Will Stevens]

I am getting this same error when I try to build the 4.4 branch.

I am in the position to test this right now if there is a fix.

Cheers,

Will


*Will STEVENS*
Lead Developer

*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_


On Wed, Jul 23, 2014 at 11:02 AM,  wrote:

> See <
> http://jenkins.buildacloud.org/job/cloudstack-4.4-maven-build/389/changes>
>
> Changes:
>
> [Daan Hoogland] Updating pom.xml version numbers for release 4.4.1-SNAPSHOT
>
> --
> [...truncated 20 lines...]
> [INFO] Apache CloudStack Framework - REST
> [INFO] Apache CloudStack Framework - IPC
> [INFO] Apache CloudStack Cloud Engine
> [INFO] Apache CloudStack Cloud Engine API
> [INFO] Apache CloudStack Framework - Security
> [INFO] Apache CloudStack Core
> [INFO] Apache CloudStack Agents
> [INFO] Apache CloudStack Framework - Clustering
> [INFO] Apache CloudStack Framework - Event Notification
> [INFO] Apache CloudStack Cloud Engine Schema Component
> [INFO] Apache CloudStack Framework - Jobs
> [INFO] Apache CloudStack Cloud Engine Internal Components API
> [INFO] Apache CloudStack Server
> [INFO] Apache CloudStack Usage Server
> [INFO] Apache XenSource XAPI
> [INFO] Apache CloudStack Cloud Engine Orchestration Component
> [INFO] Apache CloudStack Cloud Services
> [INFO] Apache CloudStack Secondary Storage
> [INFO] Apache CloudStack Secondary Storage Service
> [INFO] Apache CloudStack Engine Storage Component
> [INFO] Apache CloudStack Engine Storage Volume Component
> [INFO] Apache CloudStack Engine Storage Image Component
> [INFO] Apache CloudStack Engine Storage Data Motion Component
> [INFO] Apache CloudStack Engine Storage Cache Component
> [INFO] Apache CloudStack Engine Storage Snapshot Component
> [INFO] Apache CloudStack Cloud Engine API
> [INFO] Apache CloudStack Cloud Engine Service
> [INFO] Apache CloudStack Plugin POM
> [INFO] Apache CloudStack Plugin - API Rate Limit
> [INFO] Apache CloudStack Plugin - API Discovery
> [INFO] Apache CloudStack Plugin - ACL Static Role Based
> [INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor
> [INFO] Apache CloudStack Plugin - Explicit Dedication Processor
> [INFO] Apache CloudStack Plugin - User Concentrated Pod Deployment Planner
> [INFO] Apache CloudStack Plugin - User Dispersing Deployment Planner
> [INFO] Apache CloudStack Plugin - Implicit Dedication Planner
> [INFO] Apache CloudStack Plugin - Skip Heurestics Planner
> [INFO] Apache CloudStack Plugin - Host Allocator Random
> [INFO] Apache CloudStack Plugin - Dedicated Resources
> [INFO] Apache CloudStack Plugin - Hypervisor OracleVM
> [INFO] Apache CloudStack Plugin - Open vSwitch
> [INFO] Apache CloudStack Plugin - Hypervisor Xen
> [INFO] Apache CloudStack Plugin - Hypervisor KVM
> [INFO] Apache CloudStack Plugin - RabbitMQ Event Bus
> [INFO] Apache CloudStack Plugin - In Memory Event Bus
> [INFO] Apache CloudStack Plugin - Hypervisor Baremetal
> [INFO] Apache CloudStack Plugin - Hypervisor UCS
> [INFO] Apache CloudStack Plugin - Hypervisor Hyper-V
> [INFO] Apache CloudStack Plugin - Network Elastic Load Balancer
> [INFO] Apache CloudStack Plugin - Network Internal Load Balancer
> [INFO] Apache CloudStack Framework - Spring Life Cycle
> [INFO] Apache CloudStack Plugin - Network Juniper Contrail
> [INFO] Apache CloudStack Plugin - Palo Alto
> [INFO] Apache CloudStack Plugin - Network Netscaler
> [INFO] Apache CloudStack Plugin - Network Nicira NVP
> [INFO] Apache CloudStack Plugin - BigSwitch Virtual Network Segment
> [INFO] Apache CloudStack Plugin - Midokura Midonet
> [INFO] Apache CloudStack Plugin - Stratosphere SSP
> [INFO] Apache CloudStack Plugin - Network Opendaylight
> [INFO] Apache CloudStack Plugin - Storage Allocator Random
> [INFO] Apache CloudStack Plugin - User Authenticator LDAP
> [INFO] Apache CloudStack Plugin - User Authenticator MD5
> [INFO] Apache CloudStack Plugin - User Authenticator Plain Text
> [INFO] Apache CloudStack Plugin - User Authenticator SHA256 Salted
> [INFO] Apache CloudStack Plugin - Dns Notifier Example
> [INFO] Apache CloudStack Plugin - Storage Image S3
> [INFO] Apache CloudStack Plugin - Storage Image Swift provider
> [INFO] Apache CloudStack Plugin - Storage Image default provider
> [INFO] Apache CloudStack Plugin - Storage Image sample provider
> [INFO] Apache CloudStack Plugin - Storage Volume Nexenta Provider
> [INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider
> [INFO] Apache CloudStack Plugin - Storage Volume default provider
> [INFO] Apache CloudStack Plugin - Storage Volume CloudByte Provider
> [INFO] Apache CloudStack Plugin - Storage Volume sample provider
> [INFO] Apache CloudStack Plugin - SNMP Alerts
> [INFO] Apache CloudStack Plugin - Syslog Alerts
> [INFO] Apache CloudStack Plugin - Network VXLAN
> [INFO] Apache CloudStack Framework - Spring Module
> [INFO] Apache CloudStack Secondary Storage Controller
> [INFO] Apache CloudStack Client U

Re: [DISCUSS][PROPOSAL] git workflow

[Daan Hoogland]

Mike,

Why not then just rename master to develop? people can still commit to
it. We don't need to have a branch named master and we can name any
branch so. in line with the gitflow article we could fork master of
off 4.4...

On Wed, Jul 23, 2014 at 6:13 PM, Mike Tutkowski
 wrote:
> To start this all off, what about making a new branch call 'develop' off of
> 'master'? People can continue to commit to 'develop' as needed (as they
> were doing previously to 'master'), but only cherry pick well-tested
> features into 'master'.
>
> I know 'master' might not be currently in a shippable state (or maybe it
> is), but we can allow it to slowly make such a transition during the 4.5
> release and then keep it in a shippable going forward.
>
>
> On Wed, Jul 23, 2014 at 9:51 AM, Sebastien Goasguen 
> wrote:
>
>>
>> On Jul 23, 2014, at 11:38 AM, daan Hoogland 
>> wrote:
>>
>> > Sebastien,
>> >
>> > It seems we can do what you are calling for is creating a branch
>> > called 'release'. We can merge back into that branch from 4.4, master,
>> > 4.3. I would like to see people that want a feature or bug fix in a
>> > branch make a fork of that branch and when that fork is working do a
>> > cherry-pick. The -forward concept is now used for that but it is
>> > broken because more then for one piece of work there are commits on
>> > it. This caused me conflicts during the release. Especially painfull
>> > as not all was intended to get into the release. We can create this
>> > 'release' branch now on the basis of 4.4 and start pulling in changes.
>>
>> Yes, that's what I am thinking about too, so +1
>>
>> Our master would become the -develop- in gitflow terms
>> The release branch you mention would become the -master- in gitflow terms
>>
>> If we start now, indeed we can create 'release' from 4.4 release tag
>> (voted and shipped).
>>
>> That means that to create 4.5 we will need to merge features back into
>> 'release'. it might be messy because some of those features are already in
>> our current master.
>>
>> But all of this will keep 'release' clean (we can keep track of bugs and
>> features that are in it in CHANGES file etc..)
>>
>>
>> > There is a question of control. Do we allow all committers to manage
>> > the release? I am for that but can imagine not everybody is.
>> >
>>
>> At first I would say that only the RM can commit to 'release'. As we get
>> the CI in place  we could relax this and allow commits that pass the CI to
>> get into 'release', but right now I would vote for a tighter control of
>> 'release'.
>>
>> > rule number 1 will be: you are going to do something to the code, you
>> > start by creating a branch.
>> >
>> > right?
>> >
>> > On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen 
>> wrote:
>> >>
>> >> On Jul 23, 2014, at 11:19 AM, Sam Schmit 
>> wrote:
>> >>
>> >>> Hey everyone,
>> >>>
>> >>> I've been a developer for a handful of years and have had my share of
>> >>> experience with different version control systems.  I've used (for
>> better
>> >>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>> >>>
>> >>> Each of these solutions offers their own unique set of features,
>> strengths
>> >>> and weaknesses.  As there are so many systems that are good at specific
>> >>> things, it seems best to use the features that the chosen system is
>> best at.
>> >>>
>> >>> Git is great at branching, merging and using that structure to
>> maintain and
>> >>> control how changes get into the primary branches.  Git tools even make
>> >>> this easy by integrating directly into the "Gitflow" to make branching
>> and
>> >>> merging that much easier.  It would seem counter-intuitive to NOT make
>> use
>> >>> of these built-in capabilities.
>> >>>
>> >>> In addition to that, I know that the current method of change
>> management is
>> >>> incredibly frustrating to work with, and works directly against the
>> way a
>> >>> typical Git user would expect it to be structured.  I should NEVER have
>> >>> problem compiling and running something on master.  I should not have
>> >>> problems building anything on a release branch.  A feature/bugfix
>> branch is
>> >>> where things can be, and often are, broken or unstable.  There have
>> been
>> >>> many times working in Cloudstack where I've had to search for a stable
>> >>> revision on master, and that's just plain wrong.
>> >>>
>> >>> I do realize that having this many developers working on so many
>> features
>> >>> and bugfixes will result in a large number of branches.  I don't
>> believe
>> >>> this is a good argument against using a branching method, though - I
>> >>> believe that the current system is even more confusing and difficult
>> to use.
>> >>>
>> >>> I could pontificate on change management quite a bit more, but my
>> opinion
>> >>> in summary would basically be:  use Git the way it was meant to be
>> used,
>> >>> and things will be better.  Just my two cents.
>> >>>
>> >>> Sam
>> >>>
>> >>>
>> >>
>> >> Sam, I think we are in agreement (at least wi

Re: [DISCUSS][PROPOSAL] git workflow

[Nate Gordon]

Let me ask the question, why have master be develop and a release branch be
"master"? If we are going to follow gitflow, why not just stick with the
norm? If master is the development branch, it might not be stable. I think
the goal here is that we have an obvious stable branch. Anyone could come
check out master and have the latest useable.

Also, I'm struggling to understand the benefit of cherry-pick. If you
completely squash history, you lose a tremendous amount of context, which I
use extensively to figure out why a bug is the way it is. Only knowing that
the branch was merged at a given point in time doesn't give any context.
Seeing the individual commit history of the branch helps to preserve the
rationale for why the code was written the way it was. In theory if every
change starts out as a branch (feature, hotfix, release), then why not just
merge the branch once it is in a good and acceptable state?

I also agree with Mike that this will have to be a transition over time. It
will take some time to clean up master to the point where it can be
considered a solid stable branch. Possibly as part of the 4.5 release.


On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen 
wrote:

>
> On Jul 23, 2014, at 11:38 AM, daan Hoogland 
> wrote:
>
> > Sebastien,
> >
> > It seems we can do what you are calling for is creating a branch
> > called 'release'. We can merge back into that branch from 4.4, master,
> > 4.3. I would like to see people that want a feature or bug fix in a
> > branch make a fork of that branch and when that fork is working do a
> > cherry-pick. The -forward concept is now used for that but it is
> > broken because more then for one piece of work there are commits on
> > it. This caused me conflicts during the release. Especially painfull
> > as not all was intended to get into the release. We can create this
> > 'release' branch now on the basis of 4.4 and start pulling in changes.
>
> Yes, that's what I am thinking about too, so +1
>
> Our master would become the -develop- in gitflow terms
> The release branch you mention would become the -master- in gitflow terms
>
> If we start now, indeed we can create 'release' from 4.4 release tag
> (voted and shipped).
>
> That means that to create 4.5 we will need to merge features back into
> 'release'. it might be messy because some of those features are already in
> our current master.
>
> But all of this will keep 'release' clean (we can keep track of bugs and
> features that are in it in CHANGES file etc..)
>
>
> > There is a question of control. Do we allow all committers to manage
> > the release? I am for that but can imagine not everybody is.
> >
>
> At first I would say that only the RM can commit to 'release'. As we get
> the CI in place  we could relax this and allow commits that pass the CI to
> get into 'release', but right now I would vote for a tighter control of
> 'release'.
>
> > rule number 1 will be: you are going to do something to the code, you
> > start by creating a branch.
> >
> > right?
> >
> > On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen 
> wrote:
> >>
> >> On Jul 23, 2014, at 11:19 AM, Sam Schmit 
> wrote:
> >>
> >>> Hey everyone,
> >>>
> >>> I've been a developer for a handful of years and have had my share of
> >>> experience with different version control systems.  I've used (for
> better
> >>> or worse) Git, Perforce, Rational ClearCast, and SVN.
> >>>
> >>> Each of these solutions offers their own unique set of features,
> strengths
> >>> and weaknesses.  As there are so many systems that are good at specific
> >>> things, it seems best to use the features that the chosen system is
> best at.
> >>>
> >>> Git is great at branching, merging and using that structure to
> maintain and
> >>> control how changes get into the primary branches.  Git tools even make
> >>> this easy by integrating directly into the "Gitflow" to make branching
> and
> >>> merging that much easier.  It would seem counter-intuitive to NOT make
> use
> >>> of these built-in capabilities.
> >>>
> >>> In addition to that, I know that the current method of change
> management is
> >>> incredibly frustrating to work with, and works directly against the
> way a
> >>> typical Git user would expect it to be structured.  I should NEVER have
> >>> problem compiling and running something on master.  I should not have
> >>> problems building anything on a release branch.  A feature/bugfix
> branch is
> >>> where things can be, and often are, broken or unstable.  There have
> been
> >>> many times working in Cloudstack where I've had to search for a stable
> >>> revision on master, and that's just plain wrong.
> >>>
> >>> I do realize that having this many developers working on so many
> features
> >>> and bugfixes will result in a large number of branches.  I don't
> believe
> >>> this is a good argument against using a branching method, though - I
> >>> believe that the current system is even more confusing and difficult
> to use.
> >>>
> >>> I coul

Re: [DISCUSS][PROPOSAL] git workflow

[Mike Tutkowski]

To start this all off, what about making a new branch call 'develop' off of
'master'? People can continue to commit to 'develop' as needed (as they
were doing previously to 'master'), but only cherry pick well-tested
features into 'master'.

I know 'master' might not be currently in a shippable state (or maybe it
is), but we can allow it to slowly make such a transition during the 4.5
release and then keep it in a shippable going forward.


On Wed, Jul 23, 2014 at 9:51 AM, Sebastien Goasguen 
wrote:

>
> On Jul 23, 2014, at 11:38 AM, daan Hoogland 
> wrote:
>
> > Sebastien,
> >
> > It seems we can do what you are calling for is creating a branch
> > called 'release'. We can merge back into that branch from 4.4, master,
> > 4.3. I would like to see people that want a feature or bug fix in a
> > branch make a fork of that branch and when that fork is working do a
> > cherry-pick. The -forward concept is now used for that but it is
> > broken because more then for one piece of work there are commits on
> > it. This caused me conflicts during the release. Especially painfull
> > as not all was intended to get into the release. We can create this
> > 'release' branch now on the basis of 4.4 and start pulling in changes.
>
> Yes, that's what I am thinking about too, so +1
>
> Our master would become the -develop- in gitflow terms
> The release branch you mention would become the -master- in gitflow terms
>
> If we start now, indeed we can create 'release' from 4.4 release tag
> (voted and shipped).
>
> That means that to create 4.5 we will need to merge features back into
> 'release'. it might be messy because some of those features are already in
> our current master.
>
> But all of this will keep 'release' clean (we can keep track of bugs and
> features that are in it in CHANGES file etc..)
>
>
> > There is a question of control. Do we allow all committers to manage
> > the release? I am for that but can imagine not everybody is.
> >
>
> At first I would say that only the RM can commit to 'release'. As we get
> the CI in place  we could relax this and allow commits that pass the CI to
> get into 'release', but right now I would vote for a tighter control of
> 'release'.
>
> > rule number 1 will be: you are going to do something to the code, you
> > start by creating a branch.
> >
> > right?
> >
> > On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen 
> wrote:
> >>
> >> On Jul 23, 2014, at 11:19 AM, Sam Schmit 
> wrote:
> >>
> >>> Hey everyone,
> >>>
> >>> I've been a developer for a handful of years and have had my share of
> >>> experience with different version control systems.  I've used (for
> better
> >>> or worse) Git, Perforce, Rational ClearCast, and SVN.
> >>>
> >>> Each of these solutions offers their own unique set of features,
> strengths
> >>> and weaknesses.  As there are so many systems that are good at specific
> >>> things, it seems best to use the features that the chosen system is
> best at.
> >>>
> >>> Git is great at branching, merging and using that structure to
> maintain and
> >>> control how changes get into the primary branches.  Git tools even make
> >>> this easy by integrating directly into the "Gitflow" to make branching
> and
> >>> merging that much easier.  It would seem counter-intuitive to NOT make
> use
> >>> of these built-in capabilities.
> >>>
> >>> In addition to that, I know that the current method of change
> management is
> >>> incredibly frustrating to work with, and works directly against the
> way a
> >>> typical Git user would expect it to be structured.  I should NEVER have
> >>> problem compiling and running something on master.  I should not have
> >>> problems building anything on a release branch.  A feature/bugfix
> branch is
> >>> where things can be, and often are, broken or unstable.  There have
> been
> >>> many times working in Cloudstack where I've had to search for a stable
> >>> revision on master, and that's just plain wrong.
> >>>
> >>> I do realize that having this many developers working on so many
> features
> >>> and bugfixes will result in a large number of branches.  I don't
> believe
> >>> this is a good argument against using a branching method, though - I
> >>> believe that the current system is even more confusing and difficult
> to use.
> >>>
> >>> I could pontificate on change management quite a bit more, but my
> opinion
> >>> in summary would basically be:  use Git the way it was meant to be
> used,
> >>> and things will be better.  Just my two cents.
> >>>
> >>> Sam
> >>>
> >>>
> >>
> >> Sam, I think we are in agreement (at least with folks who responded to
> this thread).
> >> Or maybe I am not reading your mail right and you don't agree with Leo ?
> >>
> >> My own take and reason for calling for a change we are currently doing
> things is mostly due to the way we release.
> >>
> >> I would like to see a stable master (and I think we are in agreement
> with that).
> >> That means that development should not happen on master and that 

Re: [ACS44] release work to do

[Daan Hoogland]

not sure if these are really needed though, given Pierre-Lucs report.

On Wed, Jul 23, 2014 at 6:08 PM, Daan Hoogland  wrote:
> Rayees,
>
> I build templates and uploded them to 
> http://cloudstack.apt-get.eu/systemvm/4.4
>
> you can get them from there.
>
>
> On Wed, Jul 23, 2014 at 1:53 PM, Rayees Namathponnan
>  wrote:
>> I can help on posting template to download.cloud.com
>>
>> Latest 4.4 64bit and 32-bit template jobs failing from 
>> http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-systemvm64/77/console;
>>  we need to update the URL for downloading debian-7.4.0-amd64-netinst.iso
>>
>> Regards,
>> Rayees
>>
>> -Original Message-
>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> Sent: Wednesday, July 23, 2014 2:26 AM
>> To: dev
>> Subject: [ACS44] release work to do
>>
>> H,
>>
>> As far as I can see only the following two jobs are remaining:
>>
>> 1. generate the 32 and 64 bit system vms and upload them to the right place 
>> 2. change the site.
>>
>> I think I can do 2. I also can generate the templates. I am just wondering 
>> where to put them. Are these still going to download.cloud.com?
>>
>> --
>> Daan
>
>
>
> --
> Daan



-- 
Daan

Re: [ACS44] release work to do

[Daan Hoogland]

Rayees,

I build templates and uploded them to http://cloudstack.apt-get.eu/systemvm/4.4

you can get them from there.


On Wed, Jul 23, 2014 at 1:53 PM, Rayees Namathponnan
 wrote:
> I can help on posting template to download.cloud.com
>
> Latest 4.4 64bit and 32-bit template jobs failing from 
> http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-systemvm64/77/console;
>  we need to update the URL for downloading debian-7.4.0-amd64-netinst.iso
>
> Regards,
> Rayees
>
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Wednesday, July 23, 2014 2:26 AM
> To: dev
> Subject: [ACS44] release work to do
>
> H,
>
> As far as I can see only the following two jobs are remaining:
>
> 1. generate the 32 and 64 bit system vms and upload them to the right place 
> 2. change the site.
>
> I think I can do 2. I also can generate the templates. I am just wondering 
> where to put them. Are these still going to download.cloud.com?
>
> --
> Daan



-- 
Daan

Re: [DISCUSS][PROPOSAL] git workflow

[Sebastien Goasguen]

On Jul 23, 2014, at 11:38 AM, daan Hoogland  wrote:

> Sebastien,
> 
> It seems we can do what you are calling for is creating a branch
> called 'release'. We can merge back into that branch from 4.4, master,
> 4.3. I would like to see people that want a feature or bug fix in a
> branch make a fork of that branch and when that fork is working do a
> cherry-pick. The -forward concept is now used for that but it is
> broken because more then for one piece of work there are commits on
> it. This caused me conflicts during the release. Especially painfull
> as not all was intended to get into the release. We can create this
> 'release' branch now on the basis of 4.4 and start pulling in changes.

Yes, that's what I am thinking about too, so +1

Our master would become the -develop- in gitflow terms
The release branch you mention would become the -master- in gitflow terms

If we start now, indeed we can create 'release' from 4.4 release tag (voted and 
shipped).

That means that to create 4.5 we will need to merge features back into 
'release'. it might be messy because some of those features are already in our 
current master.

But all of this will keep 'release' clean (we can keep track of bugs and 
features that are in it in CHANGES file etc..) 


> There is a question of control. Do we allow all committers to manage
> the release? I am for that but can imagine not everybody is.
> 

At first I would say that only the RM can commit to 'release'. As we get the CI 
in place  we could relax this and allow commits that pass the CI to get into 
'release', but right now I would vote for a tighter control of 'release'.

> rule number 1 will be: you are going to do something to the code, you
> start by creating a branch.
> 
> right?
> 
> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen  wrote:
>> 
>> On Jul 23, 2014, at 11:19 AM, Sam Schmit  wrote:
>> 
>>> Hey everyone,
>>> 
>>> I've been a developer for a handful of years and have had my share of
>>> experience with different version control systems.  I've used (for better
>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>>> 
>>> Each of these solutions offers their own unique set of features, strengths
>>> and weaknesses.  As there are so many systems that are good at specific
>>> things, it seems best to use the features that the chosen system is best at.
>>> 
>>> Git is great at branching, merging and using that structure to maintain and
>>> control how changes get into the primary branches.  Git tools even make
>>> this easy by integrating directly into the "Gitflow" to make branching and
>>> merging that much easier.  It would seem counter-intuitive to NOT make use
>>> of these built-in capabilities.
>>> 
>>> In addition to that, I know that the current method of change management is
>>> incredibly frustrating to work with, and works directly against the way a
>>> typical Git user would expect it to be structured.  I should NEVER have
>>> problem compiling and running something on master.  I should not have
>>> problems building anything on a release branch.  A feature/bugfix branch is
>>> where things can be, and often are, broken or unstable.  There have been
>>> many times working in Cloudstack where I've had to search for a stable
>>> revision on master, and that's just plain wrong.
>>> 
>>> I do realize that having this many developers working on so many features
>>> and bugfixes will result in a large number of branches.  I don't believe
>>> this is a good argument against using a branching method, though - I
>>> believe that the current system is even more confusing and difficult to use.
>>> 
>>> I could pontificate on change management quite a bit more, but my opinion
>>> in summary would basically be:  use Git the way it was meant to be used,
>>> and things will be better.  Just my two cents.
>>> 
>>> Sam
>>> 
>>> 
>> 
>> Sam, I think we are in agreement (at least with folks who responded to this 
>> thread).
>> Or maybe I am not reading your mail right and you don't agree with Leo ?
>> 
>> My own take and reason for calling for a change we are currently doing 
>> things is mostly due to the way we release.
>> 
>> I would like to see a stable master (and I think we are in agreement with 
>> that).
>> That means that development should not happen on master and that every 
>> commit that lands on master should be shippable.
>> 
>> I personally have no issues with cherry-picking. So I would be fine cherry 
>> picking from a hot-fix branch into master, to fix a bug.
>> The end result is that the next commit on master would still mean master is 
>> shippable/releasable.
>> 
>> If we agree with this basic concept. The question becomes how do we get 
>> there, considering that master is now full of dev work and potential bug.
>> The only releasable product we have are on the 4.3, 4.4 and previous release 
>> branches.
>> 
>> Ideally, I would like to see master becomes 4.4. And work our way back, 
>> merging the new features that are already in ma

Re: [DISCUSS][PROPOSAL] git workflow

[Daan Hoogland]

Sebastien,

It seems we can do what you are calling for is creating a branch
called 'release'. We can merge back into that branch from 4.4, master,
4.3. I would like to see people that want a feature or bug fix in a
branch make a fork of that branch and when that fork is working do a
cherry-pick. The -forward concept is now used for that but it is
broken because more then for one piece of work there are commits on
it. This caused me conflicts during the release. Especially painfull
as not all was intended to get into the release. We can create this
'release' branch now on the basis of 4.4 and start pulling in changes.
There is a question of control. Do we allow all committers to manage
the release? I am for that but can imagine not everybody is.

rule number 1 will be: you are going to do something to the code, you
start by creating a branch.

right?

On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen  wrote:
>
> On Jul 23, 2014, at 11:19 AM, Sam Schmit  wrote:
>
>> Hey everyone,
>>
>> I've been a developer for a handful of years and have had my share of
>> experience with different version control systems.  I've used (for better
>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>>
>> Each of these solutions offers their own unique set of features, strengths
>> and weaknesses.  As there are so many systems that are good at specific
>> things, it seems best to use the features that the chosen system is best at.
>>
>> Git is great at branching, merging and using that structure to maintain and
>> control how changes get into the primary branches.  Git tools even make
>> this easy by integrating directly into the "Gitflow" to make branching and
>> merging that much easier.  It would seem counter-intuitive to NOT make use
>> of these built-in capabilities.
>>
>> In addition to that, I know that the current method of change management is
>> incredibly frustrating to work with, and works directly against the way a
>> typical Git user would expect it to be structured.  I should NEVER have
>> problem compiling and running something on master.  I should not have
>> problems building anything on a release branch.  A feature/bugfix branch is
>> where things can be, and often are, broken or unstable.  There have been
>> many times working in Cloudstack where I've had to search for a stable
>> revision on master, and that's just plain wrong.
>>
>> I do realize that having this many developers working on so many features
>> and bugfixes will result in a large number of branches.  I don't believe
>> this is a good argument against using a branching method, though - I
>> believe that the current system is even more confusing and difficult to use.
>>
>> I could pontificate on change management quite a bit more, but my opinion
>> in summary would basically be:  use Git the way it was meant to be used,
>> and things will be better.  Just my two cents.
>>
>> Sam
>>
>>
>
> Sam, I think we are in agreement (at least with folks who responded to this 
> thread).
> Or maybe I am not reading your mail right and you don't agree with Leo ?
>
> My own take and reason for calling for a change we are currently doing things 
> is mostly due to the way we release.
>
> I would like to see a stable master (and I think we are in agreement with 
> that).
> That means that development should not happen on master and that every commit 
> that lands on master should be shippable.
>
> I personally have no issues with cherry-picking. So I would be fine cherry 
> picking from a hot-fix branch into master, to fix a bug.
> The end result is that the next commit on master would still mean master is 
> shippable/releasable.
>
> If we agree with this basic concept. The question becomes how do we get 
> there, considering that master is now full of dev work and potential bug.
> The only releasable product we have are on the 4.3, 4.4 and previous release 
> branches.
>
> Ideally, I would like to see master becomes 4.4. And work our way back, 
> merging the new features that are already in master into the new master 
> (based on 4.4).
> This could be quite complicated but we need to do it (or something like it).
>
> To move forward, we should make a proposal to the list and call for a vote.
>
> Any takers to start a wiki page proposing a new git process and how we could 
> move to it (transition path) ?
>
>
> -Sebastien
>
>
>>
>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons 
>> wrote:
>>
>>> Hey folks,
>>>
>>> With 4.4.0 tagged, is now an opportune time to go and implement this?
>>>
>>> I would enthousiastically +1 and get crackin', but I’m not a committer so
>>> its not that practical for me to volunteer!
>>>
>>> I wanted to point out atlassian’s description of gitflow
>>>
>>>  https://www.atlassian.com/git/workflows#!workflow-gitflow
>>>
>>> which might be easier to read.
>>>
>>> Similarly, the git-flow scripts that help out with implementing this stuff
>>>
>>>  https://github.com/nvie/gitflow
>>>
>>> they also describe the relationship between git

jclouds support for CloudStack

[Aled Sage]

Hi all,

We are keen users of and contributors to jclouds [1], including for the 
CloudStack integration.


For those who don't know it, Apache jclouds is the leading java cloud 
portability library, used by a lot of companies and several Apache 
projects including Brooklyn (for which I'm a lead) and Stratos.


Would anyone in the CloudStack community be interested in helping out 
with updating and improving the jclouds integration? Unfortunately the 
jclouds CloudStack code hasn't had as much attention as it deserves over 
the past couple of releases.


I just targeted Exoscale [2] (i.e. CloudStack 4.3) for the jclouds live 
test suite, and got a range of failures. There are some concrete tasks 
that can come out of this:


 * Ability to automatically skip inappropriate tests - e.g. if only
   basic networking is available, then report the advanced networking
   tests as skipped rather than failed.
   (This could use the API Discovery [3])
 * Investigate other failures, to make the test suite more robust (or
   potentially to find regressions in CloudStack).
 * Extend the jclouds integration for more recent API features (e.g.
   for API Discovery [3])
 * Improve the publicity and documentation for jclouds CloudStack -
   e.g. it's not even mentioned in [4]

It's also worth noting that the jclouds live test suite is a great 
regression test suite that could be run at least once on every 
CloudStack release. For example, it would most likely spot regressions 
such as CLOUDSTACK-6508 [5,6].


Aled

[1] jclouds.apache.org 
[2] www.exoscale.ch 
[3] http://cloudstack.apache.org/docs/api/apidocs-4.3/user/listApis.html
[4] https://jclouds.apache.org/guides/
[5] https://issues.apache.org/jira/browse/CLOUDSTACK-6508
[6] https://issues.apache.org/jira/browse/JCLOUDS-557

Re: Review Request 23847: Check if config specifies zones before iterating

[Miguel Ferreira]

> On July 23, 2014, 2:58 p.m., Santhosh Edukulla wrote:
> > Ship It!
> 
> Santhosh Edukulla wrote:
> Pushed the patch to master:   9f4f921..bb1c70b  master -> master
> 
> One small note though. Please add branch and bug information to review 
> requests.
>

Sure. Thanks


- Miguel


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


On July 23, 2014, 12:17 p.m., Miguel Ferreira wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23847/
> ---
> 
> (Updated July 23, 2014, 12:17 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Santhosh Edukulla, and Hugo 
> Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Running a marvin test that does not specify a zone in the config file will 
> produce an exception while parsing the config:
> 
> Exception Occurred Under init ['Traceback (most recent call last):\n', '  
> File "/usr/local/lib/python2.7/site-packages/marvin/marvinInit.py", line 118, 
> in __setHypervisorAndZoneInfo\nfor zone in self.__parsedConfig.zones:\n', 
> "TypeError: 'NoneType' object is not iterable\n"]
> 
> This happens when the code starts iterating over a list of zones that does 
> not exist.
> I've added a check for the existence of the list of zones before iterating.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/marvinInit.py ce9b43f 
> 
> Diff: https://reviews.apache.org/r/23847/diff/
> 
> 
> Testing
> ---
> 
> Tests now run without the mentioned exception
> 
> 
> Thanks,
> 
> Miguel Ferreira
> 
>

Re: jclouds support for CloudStack

[Sebastien Goasguen]

On Jul 23, 2014, at 11:32 AM, Aled Sage  wrote:

> Hi all,
> 
> We are keen users of and contributors to jclouds [1], including for the 
> CloudStack integration.
> 
> For those who don't know it, Apache jclouds is the leading java cloud 
> portability library, used by a lot of companies and several Apache projects 
> including Brooklyn (for which I'm a lead) and Stratos.
> 
> Would anyone in the CloudStack community be interested in helping out with 
> updating and improving the jclouds integration? Unfortunately the jclouds 
> CloudStack code hasn't had as much attention as it deserves over the past 
> couple of releases.
> 
> I just targeted Exoscale [2] (i.e. CloudStack 4.3) for the jclouds live test 
> suite, and got a range of failures. There are some concrete tasks that can 
> come out of this:
> 
> * Ability to automatically skip inappropriate tests - e.g. if only
>   basic networking is available, then report the advanced networking
>   tests as skipped rather than failed.
>   (This could use the API Discovery [3])
> * Investigate other failures, to make the test suite more robust (or
>   potentially to find regressions in CloudStack).
> * Extend the jclouds integration for more recent API features (e.g.
>   for API Discovery [3])
> * Improve the publicity and documentation for jclouds CloudStack -
>   e.g. it's not even mentioned in [4]
> 

+1 from me of course. I take care of libcloud, but jclouds also needs attention.

> It's also worth noting that the jclouds live test suite is a great regression 
> test suite that could be run at least once on every CloudStack release. For 
> example, it would most likely spot regressions such as CLOUDSTACK-6508 [5,6].
> 

I applied the patch for 6508 in the 4.3 branch, so you will see it in 4.3.1

> Aled
> 
> [1] jclouds.apache.org 
> [2] www.exoscale.ch 
> [3] http://cloudstack.apache.org/docs/api/apidocs-4.3/user/listApis.html
> [4] https://jclouds.apache.org/guides/
> [5] https://issues.apache.org/jira/browse/CLOUDSTACK-6508
> [6] https://issues.apache.org/jira/browse/JCLOUDS-557

Review Request 23856: Use local test configuration to enable testing of distributed routing

[Miguel Ferreira]

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

Review request for cloudstack, daan Hoogland, Murali Reddy, Hugo Trippaers, and 
SrikanteswaraRao Talluri.


Repository: cloudstack-git


Description
---

The first test in the class is failing on asserting that distributed routing is 
enabled:

Traceback (most recent call last):
  File 
"/usr/local/Cellar/python/2.7.8/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py",
 line 329, in run
testMethod()
  File 
"/Users/mferreira/development/workspace/cloudstack-sbp-vpc-tests/src/vpc-tests/all/test_vpc_distributed_routing_offering.py",
 line 292, in 
test_01_create_vpc_offering_with_distributedrouter_service_capability
self.validate_vpc_offering(vpc_off)
  File 
"/Users/mferreira/development/workspace/cloudstack-sbp-vpc-tests/src/vpc-tests/all/test_vpc_distributed_routing_offering.py",
 line 245, in validate_vpc_offering
"VPC offering is not set up for Distributed routing"
  File 
"/usr/local/Cellar/python/2.7.8/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py",
 line 513, in assertEqual
assertion_func(first, second, msg=msg)
  File 
"/usr/local/Cellar/python/2.7.8/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py",
 line 506, in _baseAssertEqual
raise self.failureException(msg)
AssertionError: VPC offering is not set up for Distributed routing
 >> begin captured stdout << -
=== TestName: 
test_01_create_vpc_offering_with_distributedrouter_service_capability | Status 
: FAILED ===


That is because it is using the global services configuration instead of the 
local one (where the distributed routing is enabled).
I've changed that and also added two new lines in between every python method 
to make the class more readable.

I did not manage to runt the other 2 tests in the class because my development 
setup does not support Ovs.


Diffs
-

  test/integration/component/test_vpc_distributed_routing_offering.py cc9a191 

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


Testing
---

The test that was failing now passes.


Thanks,

Miguel Ferreira

Re: [DISCUSS][PROPOSAL] git workflow

[Sebastien Goasguen]

On Jul 23, 2014, at 11:19 AM, Sam Schmit  wrote:

> Hey everyone,
> 
> I've been a developer for a handful of years and have had my share of
> experience with different version control systems.  I've used (for better
> or worse) Git, Perforce, Rational ClearCast, and SVN.
> 
> Each of these solutions offers their own unique set of features, strengths
> and weaknesses.  As there are so many systems that are good at specific
> things, it seems best to use the features that the chosen system is best at.
> 
> Git is great at branching, merging and using that structure to maintain and
> control how changes get into the primary branches.  Git tools even make
> this easy by integrating directly into the "Gitflow" to make branching and
> merging that much easier.  It would seem counter-intuitive to NOT make use
> of these built-in capabilities.
> 
> In addition to that, I know that the current method of change management is
> incredibly frustrating to work with, and works directly against the way a
> typical Git user would expect it to be structured.  I should NEVER have
> problem compiling and running something on master.  I should not have
> problems building anything on a release branch.  A feature/bugfix branch is
> where things can be, and often are, broken or unstable.  There have been
> many times working in Cloudstack where I've had to search for a stable
> revision on master, and that's just plain wrong.
> 
> I do realize that having this many developers working on so many features
> and bugfixes will result in a large number of branches.  I don't believe
> this is a good argument against using a branching method, though - I
> believe that the current system is even more confusing and difficult to use.
> 
> I could pontificate on change management quite a bit more, but my opinion
> in summary would basically be:  use Git the way it was meant to be used,
> and things will be better.  Just my two cents.
> 
> Sam
> 
> 

Sam, I think we are in agreement (at least with folks who responded to this 
thread).
Or maybe I am not reading your mail right and you don't agree with Leo ?

My own take and reason for calling for a change we are currently doing things 
is mostly due to the way we release.

I would like to see a stable master (and I think we are in agreement with that).
That means that development should not happen on master and that every commit 
that lands on master should be shippable.

I personally have no issues with cherry-picking. So I would be fine cherry 
picking from a hot-fix branch into master, to fix a bug. 
The end result is that the next commit on master would still mean master is 
shippable/releasable.

If we agree with this basic concept. The question becomes how do we get there, 
considering that master is now full of dev work and potential bug.
The only releasable product we have are on the 4.3, 4.4 and previous release 
branches.

Ideally, I would like to see master becomes 4.4. And work our way back, merging 
the new features that are already in master into the new master (based on 4.4).
This could be quite complicated but we need to do it (or something like it).

To move forward, we should make a proposal to the list and call for a vote.

Any takers to start a wiki page proposing a new git process and how we could 
move to it (transition path) ?


-Sebastien


> 
> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons 
> wrote:
> 
>> Hey folks,
>> 
>> With 4.4.0 tagged, is now an opportune time to go and implement this?
>> 
>> I would enthousiastically +1 and get crackin', but I’m not a committer so
>> its not that practical for me to volunteer!
>> 
>> I wanted to point out atlassian’s description of gitflow
>> 
>>  https://www.atlassian.com/git/workflows#!workflow-gitflow
>> 
>> which might be easier to read.
>> 
>> Similarly, the git-flow scripts that help out with implementing this stuff
>> 
>>  https://github.com/nvie/gitflow
>> 
>> they also describe the relationship between gitflow and dealing with
>> multiple remotes
>> 
>>  https://www.atlassian.com/git/workflows#!pull-request
>> 
>> Finally note atlassian’s free sourcetree GUI has built-in support for
>> git-flow
>> 
>>  http://www.sourcetreeapp.com/
>> 
>> Because cloudstack currently is full of rebasing and squashing and
>> cherry-picking, you get very little benefit from a tree visualization tool
>> (like this or gitk or ...) right now, but it would be *great* to have going
>> forward.
>> 
>> 
>> cheers,
>> 
>> 
>> Leo
>> 
>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen  wrote:
>> 
>>> I would like to re-start this discussion.
>>> 
>>> Rajani made some good points and someone mentioned Gitflow:
>>> 
>>> http://nvie.com/posts/a-successful-git-branching-model/
>>> 
>>> Thinking about our release procedure, we clearly need more tests and a
>> CI. However it looks like this is going to take some time.
>>> 
>>> In the meantime I think there is nothing preventing us from agreeing to
>> 'git practices', we don't need tests or new infra,

Re: [DISCUSS][PROPOSAL] git workflow

[Sam Schmit]

Hey everyone,

I've been a developer for a handful of years and have had my share of
experience with different version control systems.  I've used (for better
or worse) Git, Perforce, Rational ClearCast, and SVN.

Each of these solutions offers their own unique set of features, strengths
and weaknesses.  As there are so many systems that are good at specific
things, it seems best to use the features that the chosen system is best at.

Git is great at branching, merging and using that structure to maintain and
control how changes get into the primary branches.  Git tools even make
this easy by integrating directly into the "Gitflow" to make branching and
merging that much easier.  It would seem counter-intuitive to NOT make use
of these built-in capabilities.

In addition to that, I know that the current method of change management is
incredibly frustrating to work with, and works directly against the way a
typical Git user would expect it to be structured.  I should NEVER have
problem compiling and running something on master.  I should not have
problems building anything on a release branch.  A feature/bugfix branch is
where things can be, and often are, broken or unstable.  There have been
many times working in Cloudstack where I've had to search for a stable
revision on master, and that's just plain wrong.

I do realize that having this many developers working on so many features
and bugfixes will result in a large number of branches.  I don't believe
this is a good argument against using a branching method, though - I
believe that the current system is even more confusing and difficult to use.

I could pontificate on change management quite a bit more, but my opinion
in summary would basically be:  use Git the way it was meant to be used,
and things will be better.  Just my two cents.

Sam



On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons 
wrote:

> Hey folks,
>
> With 4.4.0 tagged, is now an opportune time to go and implement this?
>
> I would enthousiastically +1 and get crackin', but I’m not a committer so
> its not that practical for me to volunteer!
>
> I wanted to point out atlassian’s description of gitflow
>
>   https://www.atlassian.com/git/workflows#!workflow-gitflow
>
> which might be easier to read.
>
> Similarly, the git-flow scripts that help out with implementing this stuff
>
>   https://github.com/nvie/gitflow
>
> they also describe the relationship between gitflow and dealing with
> multiple remotes
>
>   https://www.atlassian.com/git/workflows#!pull-request
>
> Finally note atlassian’s free sourcetree GUI has built-in support for
> git-flow
>
>   http://www.sourcetreeapp.com/
>
> Because cloudstack currently is full of rebasing and squashing and
> cherry-picking, you get very little benefit from a tree visualization tool
> (like this or gitk or ...) right now, but it would be *great* to have going
> forward.
>
>
> cheers,
>
>
> Leo
>
> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen  wrote:
>
> > I would like to re-start this discussion.
> >
> > Rajani made some good points and someone mentioned Gitflow:
> >
> > http://nvie.com/posts/a-successful-git-branching-model/
> >
> > Thinking about our release procedure, we clearly need more tests and a
> CI. However it looks like this is going to take some time.
> >
> > In the meantime I think there is nothing preventing us from agreeing to
> 'git practices', we don't need tests or new infra, we just need to agree on
> the git workflow.
> >
> > Right now Master is really a development branch, we should make it a
> stable branch for production with very few commits.
> > This does not mean that we would release less, in contrary this would
> ensure that a commit to master means it's a production release.
> >
> > In addition gitflow [1] does not do cherry-picks (gets back to Rajani's
> point) everything is based on merges.
> >
> > I am of the opinion that git flow provides a nice process. It basically
> freezes master. Development happens in a 'develop' branch, releases
> branches are branched off of that and merged into master and back into
> develop….etc
> >
> > Please read [1] it's a good read.
> >
> > And let's discuss,
> >
> > [1] http://nvie.com/posts/a-successful-git-branching-model/
> >
> > -Sebastien
> >
> > On Jun 2, 2014, at 11:58 PM, Rajani Karuturi 
> wrote:
> >
> >> There is also the problem of cherry-picking.
> >> As a contributor, I always endup creating multiple patches for each
> branch as they don’t cleanly apply on the upward branches. which means
> distinct commits for each branch and I don’t easily know which all branches
> my commit exists unless I do grep.
> >> if we follow merging strategy properly, apart from the first merge of
> the branch, everything else on top of it should be a painless merge.
> >>
> >>
> >>
> >> ~Rajani
> >>
> >>
> >>
> >> On 02-Jun-2014, at 10:51 pm, Marcus  wrote:
> >>
> >>> I think many of the bullet points are what we are currently doing
> >>> (guidelines for commit comments, feature branches need

Re: Review Request 23847: Check if config specifies zones before iterating

[Santhosh Edukulla]

> On July 23, 2014, 2:58 p.m., Santhosh Edukulla wrote:
> > Ship It!

Pushed the patch to master:   9f4f921..bb1c70b  master -> master

One small note though. Please add branch and bug information to review requests.


- Santhosh


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


On July 23, 2014, 12:17 p.m., Miguel Ferreira wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23847/
> ---
> 
> (Updated July 23, 2014, 12:17 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Santhosh Edukulla, and Hugo 
> Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Running a marvin test that does not specify a zone in the config file will 
> produce an exception while parsing the config:
> 
> Exception Occurred Under init ['Traceback (most recent call last):\n', '  
> File "/usr/local/lib/python2.7/site-packages/marvin/marvinInit.py", line 118, 
> in __setHypervisorAndZoneInfo\nfor zone in self.__parsedConfig.zones:\n', 
> "TypeError: 'NoneType' object is not iterable\n"]
> 
> This happens when the code starts iterating over a list of zones that does 
> not exist.
> I've added a check for the existence of the list of zones before iterating.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/marvinInit.py ce9b43f 
> 
> Diff: https://reviews.apache.org/r/23847/diff/
> 
> 
> Testing
> ---
> 
> Tests now run without the mentioned exception
> 
> 
> Thanks,
> 
> Miguel Ferreira
> 
>

Build failed in Jenkins: cloudstack-4.4-maven-build #389

[jenkins]

See 

Changes:

[Daan Hoogland] Updating pom.xml version numbers for release 4.4.1-SNAPSHOT

--
[...truncated 20 lines...]
[INFO] Apache CloudStack Framework - REST
[INFO] Apache CloudStack Framework - IPC
[INFO] Apache CloudStack Cloud Engine
[INFO] Apache CloudStack Cloud Engine API
[INFO] Apache CloudStack Framework - Security
[INFO] Apache CloudStack Core
[INFO] Apache CloudStack Agents
[INFO] Apache CloudStack Framework - Clustering
[INFO] Apache CloudStack Framework - Event Notification
[INFO] Apache CloudStack Cloud Engine Schema Component
[INFO] Apache CloudStack Framework - Jobs
[INFO] Apache CloudStack Cloud Engine Internal Components API
[INFO] Apache CloudStack Server
[INFO] Apache CloudStack Usage Server
[INFO] Apache XenSource XAPI
[INFO] Apache CloudStack Cloud Engine Orchestration Component
[INFO] Apache CloudStack Cloud Services
[INFO] Apache CloudStack Secondary Storage
[INFO] Apache CloudStack Secondary Storage Service
[INFO] Apache CloudStack Engine Storage Component
[INFO] Apache CloudStack Engine Storage Volume Component
[INFO] Apache CloudStack Engine Storage Image Component
[INFO] Apache CloudStack Engine Storage Data Motion Component
[INFO] Apache CloudStack Engine Storage Cache Component
[INFO] Apache CloudStack Engine Storage Snapshot Component
[INFO] Apache CloudStack Cloud Engine API
[INFO] Apache CloudStack Cloud Engine Service
[INFO] Apache CloudStack Plugin POM
[INFO] Apache CloudStack Plugin - API Rate Limit
[INFO] Apache CloudStack Plugin - API Discovery
[INFO] Apache CloudStack Plugin - ACL Static Role Based
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor
[INFO] Apache CloudStack Plugin - Explicit Dedication Processor
[INFO] Apache CloudStack Plugin - User Concentrated Pod Deployment Planner
[INFO] Apache CloudStack Plugin - User Dispersing Deployment Planner
[INFO] Apache CloudStack Plugin - Implicit Dedication Planner
[INFO] Apache CloudStack Plugin - Skip Heurestics Planner
[INFO] Apache CloudStack Plugin - Host Allocator Random
[INFO] Apache CloudStack Plugin - Dedicated Resources
[INFO] Apache CloudStack Plugin - Hypervisor OracleVM
[INFO] Apache CloudStack Plugin - Open vSwitch
[INFO] Apache CloudStack Plugin - Hypervisor Xen
[INFO] Apache CloudStack Plugin - Hypervisor KVM
[INFO] Apache CloudStack Plugin - RabbitMQ Event Bus
[INFO] Apache CloudStack Plugin - In Memory Event Bus
[INFO] Apache CloudStack Plugin - Hypervisor Baremetal
[INFO] Apache CloudStack Plugin - Hypervisor UCS
[INFO] Apache CloudStack Plugin - Hypervisor Hyper-V
[INFO] Apache CloudStack Plugin - Network Elastic Load Balancer
[INFO] Apache CloudStack Plugin - Network Internal Load Balancer
[INFO] Apache CloudStack Framework - Spring Life Cycle
[INFO] Apache CloudStack Plugin - Network Juniper Contrail
[INFO] Apache CloudStack Plugin - Palo Alto
[INFO] Apache CloudStack Plugin - Network Netscaler
[INFO] Apache CloudStack Plugin - Network Nicira NVP
[INFO] Apache CloudStack Plugin - BigSwitch Virtual Network Segment
[INFO] Apache CloudStack Plugin - Midokura Midonet
[INFO] Apache CloudStack Plugin - Stratosphere SSP
[INFO] Apache CloudStack Plugin - Network Opendaylight
[INFO] Apache CloudStack Plugin - Storage Allocator Random
[INFO] Apache CloudStack Plugin - User Authenticator LDAP
[INFO] Apache CloudStack Plugin - User Authenticator MD5
[INFO] Apache CloudStack Plugin - User Authenticator Plain Text
[INFO] Apache CloudStack Plugin - User Authenticator SHA256 Salted
[INFO] Apache CloudStack Plugin - Dns Notifier Example
[INFO] Apache CloudStack Plugin - Storage Image S3
[INFO] Apache CloudStack Plugin - Storage Image Swift provider
[INFO] Apache CloudStack Plugin - Storage Image default provider
[INFO] Apache CloudStack Plugin - Storage Image sample provider
[INFO] Apache CloudStack Plugin - Storage Volume Nexenta Provider
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider
[INFO] Apache CloudStack Plugin - Storage Volume default provider
[INFO] Apache CloudStack Plugin - Storage Volume CloudByte Provider
[INFO] Apache CloudStack Plugin - Storage Volume sample provider
[INFO] Apache CloudStack Plugin - SNMP Alerts
[INFO] Apache CloudStack Plugin - Syslog Alerts
[INFO] Apache CloudStack Plugin - Network VXLAN
[INFO] Apache CloudStack Framework - Spring Module
[INFO] Apache CloudStack Secondary Storage Controller
[INFO] Apache CloudStack Client UI
[INFO] Apache CloudStack Console Proxy - RDP Client
[INFO] Apache CloudStack Console Proxy
[INFO] Apache CloudStack Console Proxy - Server
[INFO] Apache CloudStack Framework - QuickCloud
[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Developer Tools - Checkstyle Configuration 
4.4.0
[INFO] 
[INFO

Re: Eclipse STS Checkstyle problem

[Hugo Trippaers]

Heya,

Checkstyle is only reporting the errors. You need to configure eclipse to use 
for example spaces instead of tabs to automagically fix it.

In the directory tools/eclipse in cloudstack there is an XML files that you can 
import in the eclipse formatter.

Cheers,

Hugo

On 23 jul. 2014, at 16:56, Seif Eddine Jemli  wrote:

> Hi,
> 
> 
> I  have checkstyle erros in my code, in Eclipse STS. I am using 
> "cloud-style.xml", for checkstyle configuration.
> 
> But I keep getting errors like : "trailing space" and "line contains tab 
> characters".
> 
> Are there any steps I need to follow to resolve this problem?
> 
> 
> thanks

Re: Review Request 23847: Check if config specifies zones before iterating

[Santhosh Edukulla]

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

Ship it!


Ship It!

- Santhosh Edukulla


On July 23, 2014, 12:17 p.m., Miguel Ferreira wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23847/
> ---
> 
> (Updated July 23, 2014, 12:17 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Santhosh Edukulla, and Hugo 
> Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Running a marvin test that does not specify a zone in the config file will 
> produce an exception while parsing the config:
> 
> Exception Occurred Under init ['Traceback (most recent call last):\n', '  
> File "/usr/local/lib/python2.7/site-packages/marvin/marvinInit.py", line 118, 
> in __setHypervisorAndZoneInfo\nfor zone in self.__parsedConfig.zones:\n', 
> "TypeError: 'NoneType' object is not iterable\n"]
> 
> This happens when the code starts iterating over a list of zones that does 
> not exist.
> I've added a check for the existence of the list of zones before iterating.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/marvinInit.py ce9b43f 
> 
> Diff: https://reviews.apache.org/r/23847/diff/
> 
> 
> Testing
> ---
> 
> Tests now run without the mentioned exception
> 
> 
> Thanks,
> 
> Miguel Ferreira
> 
>

Eclipse STS Checkstyle problem

[Seif Eddine Jemli]

Hi,


I  have checkstyle erros in my code, in Eclipse STS. I am using
"cloud-style.xml",
for checkstyle configuration.

But I keep getting errors like : "trailing space" and "line contains tab
characters".

Are there any steps I need to follow to resolve this problem?


thanks

Re: [JENKINS] devcloud-continuous-tests

[Srikanteswararao Talluri]

Ahmad,

Do you have any information about this jenkins slave?

Thanks,
~Talluri

On Fri, Jul 18, 2014 at 6:08 PM, Hugo Trippaers  wrote:
> Hey Talluri,
>
> Do you know what happend to this jenkins slave? The console log tells me that 
> the system was halted?
>
> Cheers,
>
> Hugo

Re: [ACS44] release work to do

[Pierre-Luc Dion]

I just test an upgraded installation from 4.3, download the new systemvm
template and name it systemvm-xenserver-4.4. The column "Required Upgrade"
in the console for VR remain to "No". So I guest no new system-vm template
is required since 4.3...





*Pierre-Luc DION*
Architecte de Solution Cloud | Cloud Solutions Architect
t 855.652.5683

*CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_



On Wed, Jul 23, 2014 at 8:51 AM, Pierre-Luc Dion  wrote:

> It would mean someone running 4.3 wouldn't need to update is systemvm
> then?  That's what I've understand so far...
>
>
>
> *Pierre-Luc DION*
> Architecte de Solution Cloud | Cloud Solutions Architect
> t 855.652.5683
>
> *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
>
>
> On Wed, Jul 23, 2014 at 8:46 AM, Daan Hoogland 
> wrote:
>
>> Pierre,
>>
>> I wouldn't swear to it but it seems to me that systemvm updates have
>> been done since the last release and we need to update.
>>
>> On Wed, Jul 23, 2014 at 2:43 PM, Pierre-Luc Dion 
>> wrote:
>> > Ok, So i've never had answer on:  does 4.4 require systemvm template
>> > upgrade?
>> > The current RN does not consider upgrading sysvm. So I will need to
>> update
>> > RN when confirmed.
>> >
>> > thanks,
>> >
>> > PL
>> >
>> >
>> > On Wed, Jul 23, 2014 at 7:53 AM, Rayees Namathponnan <
>> > rayees.namathpon...@citrix.com> wrote:
>> >
>> >> I can help on posting template to download.cloud.com
>> >>
>> >> Latest 4.4 64bit and 32-bit template jobs failing from
>> >>
>> http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-systemvm64/77/console
>> ;
>> >> we need to update the URL for downloading
>> debian-7.4.0-amd64-netinst.iso
>> >>
>> >> Regards,
>> >> Rayees
>> >>
>> >> -Original Message-
>> >> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> >> Sent: Wednesday, July 23, 2014 2:26 AM
>> >> To: dev
>> >> Subject: [ACS44] release work to do
>> >>
>> >> H,
>> >>
>> >> As far as I can see only the following two jobs are remaining:
>> >>
>> >> 1. generate the 32 and 64 bit system vms and upload them to the right
>> >> place 2. change the site.
>> >>
>> >> I think I can do 2. I also can generate the templates. I am just
>> wondering
>> >> where to put them. Are these still going to download.cloud.com?
>> >>
>> >> --
>> >> Daan
>> >>
>>
>>
>>
>> --
>> Daan
>>
>
>

Re: Review Request 23838: CLOUDSTACK-5986: Test scipt to verify the fix in isolated network for non-vpc networks

[ASF Subversion and Git Services]

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


Commit 9f4f9211d0aecbfeadfa626b6202109f40200125 in cloudstack's branch 
refs/heads/master from sanjeev
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9f4f921 ]

CLOUDSTACK-5986: Test scipt to verify the fix in isolated network for non-vpc 
networks

Signed-off-by: sanjeev 


- ASF Subversion and Git Services


On July 23, 2014, 9:14 a.m., sanjeev n wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23838/
> ---
> 
> (Updated July 23, 2014, 9:14 a.m.)
> 
> 
> 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.
> Test does the following:
> 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_escalations_instances.py 79fd3b1 
> 
> Diff: https://reviews.apache.org/r/23838/diff/
> 
> 
> Testing
> ---
> 
> Yes
> 
> 
> Thanks,
> 
> sanjeev n
> 
>

Re: [ACS44] release work to do

[Pierre-Luc Dion]

It would mean someone running 4.3 wouldn't need to update is systemvm then?
 That's what I've understand so far...



*Pierre-Luc DION*
Architecte de Solution Cloud | Cloud Solutions Architect
t 855.652.5683

*CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_



On Wed, Jul 23, 2014 at 8:46 AM, Daan Hoogland 
wrote:

> Pierre,
>
> I wouldn't swear to it but it seems to me that systemvm updates have
> been done since the last release and we need to update.
>
> On Wed, Jul 23, 2014 at 2:43 PM, Pierre-Luc Dion 
> wrote:
> > Ok, So i've never had answer on:  does 4.4 require systemvm template
> > upgrade?
> > The current RN does not consider upgrading sysvm. So I will need to
> update
> > RN when confirmed.
> >
> > thanks,
> >
> > PL
> >
> >
> > On Wed, Jul 23, 2014 at 7:53 AM, Rayees Namathponnan <
> > rayees.namathpon...@citrix.com> wrote:
> >
> >> I can help on posting template to download.cloud.com
> >>
> >> Latest 4.4 64bit and 32-bit template jobs failing from
> >>
> http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-systemvm64/77/console
> ;
> >> we need to update the URL for downloading debian-7.4.0-amd64-netinst.iso
> >>
> >> Regards,
> >> Rayees
> >>
> >> -Original Message-
> >> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> >> Sent: Wednesday, July 23, 2014 2:26 AM
> >> To: dev
> >> Subject: [ACS44] release work to do
> >>
> >> H,
> >>
> >> As far as I can see only the following two jobs are remaining:
> >>
> >> 1. generate the 32 and 64 bit system vms and upload them to the right
> >> place 2. change the site.
> >>
> >> I think I can do 2. I also can generate the templates. I am just
> wondering
> >> where to put them. Are these still going to download.cloud.com?
> >>
> >> --
> >> Daan
> >>
>
>
>
> --
> Daan
>

Review Request 23852: Testdata configuration changes required for vGPU automation

[sailaja mada]

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

Review request for cloudstack, Doug Clark, Sanjay Tripathi, and Santhosh 
Edukulla.


Repository: cloudstack-git


Description
---

This patch contains below changes:

1. vGPU service offerings configurations are added test data file
2. Windows template details to register windows template
3. Timeout for windows template to get it downloaded


Diffs
-

  tools/marvin/marvin/config/test_data.py 2b60626 

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


Testing
---

Tested vGPU automated script using this testdata configuration file


Thanks,

sailaja mada

Re: [ACS44] release work to do

[Daan Hoogland]

Pierre,

I wouldn't swear to it but it seems to me that systemvm updates have
been done since the last release and we need to update.

On Wed, Jul 23, 2014 at 2:43 PM, Pierre-Luc Dion  wrote:
> Ok, So i've never had answer on:  does 4.4 require systemvm template
> upgrade?
> The current RN does not consider upgrading sysvm. So I will need to update
> RN when confirmed.
>
> thanks,
>
> PL
>
>
> On Wed, Jul 23, 2014 at 7:53 AM, Rayees Namathponnan <
> rayees.namathpon...@citrix.com> wrote:
>
>> I can help on posting template to download.cloud.com
>>
>> Latest 4.4 64bit and 32-bit template jobs failing from
>> http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-systemvm64/77/console;
>> we need to update the URL for downloading debian-7.4.0-amd64-netinst.iso
>>
>> Regards,
>> Rayees
>>
>> -Original Message-
>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> Sent: Wednesday, July 23, 2014 2:26 AM
>> To: dev
>> Subject: [ACS44] release work to do
>>
>> H,
>>
>> As far as I can see only the following two jobs are remaining:
>>
>> 1. generate the 32 and 64 bit system vms and upload them to the right
>> place 2. change the site.
>>
>> I think I can do 2. I also can generate the templates. I am just wondering
>> where to put them. Are these still going to download.cloud.com?
>>
>> --
>> Daan
>>



-- 
Daan

Re: Need edit rights for Wiki to improve Marvin - Testing with Python tutorial

[Miguel Ferreira]

I’ve fixed all problems I found with that page.

Cheers,
Miguel

On 23 Jul 2014, at 12:28, Santhosh Edukulla  
wrote:

> These were new changes done to marvin, during the same time, we edited wiki 
> pages to reflect the changes, either it was reedited by some body or this 
> particular place got missed. Please add the one with latest.
> 
> I can add that change for you if you require.
> 
> Santhosh
> 
> From: Miguel Ferreira [mferre...@schubergphilis.com]
> Sent: Wednesday, July 23, 2014 6:23 AM
> To: Daan Hoogland
> Cc: dev; int-toolkit
> Subject: Re: Need edit rights for Wiki to improve Marvin - Testing with 
> Python tutorial
> 
> Thanks Daan,
> 
> By the way, just posted this on IRC dev channel, but got no reply there so 
> here it goes:
>> In the section about running a test from command line, there is a command 
>> like this: "nosetests --with-marvin --marvin-config=demo.cfg --load 
>> test_deploy_vm.py"
>> However, the version I have of nosetests (installed recently) does not have 
>> a "—load" options
>> Furthermore, running the smoke tests from command line always fails because 
>> the nose-marvin-plugin does not inject the apiclient into the test case 
>> (that is because te plugin only doe injection when loading tests form 
>> TestCase class and not from name, as it happens from the command line)
> 
> Should I be using a specific/patched version of nosetests?
> Or should the “run from command line” section be removed?
> 
> Cheers,
> Miguel
> 
> 
> On 23 Jul 2014, at 12:16, Daan Hoogland  wrote:
> 
>> On Wed, Jul 23, 2014 at 11:56 AM, Miguel Ferreira
>>  wrote:
>>> miguelferreira
>> 
>> 
>> in
>> 
>> --
>> Daan
> 

Re: [ACS44] release work to do

[Pierre-Luc Dion]

Ok, So i've never had answer on:  does 4.4 require systemvm template
upgrade?
The current RN does not consider upgrading sysvm. So I will need to update
RN when confirmed.

thanks,

PL


On Wed, Jul 23, 2014 at 7:53 AM, Rayees Namathponnan <
rayees.namathpon...@citrix.com> wrote:

> I can help on posting template to download.cloud.com
>
> Latest 4.4 64bit and 32-bit template jobs failing from
> http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-systemvm64/77/console;
> we need to update the URL for downloading debian-7.4.0-amd64-netinst.iso
>
> Regards,
> Rayees
>
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Wednesday, July 23, 2014 2:26 AM
> To: dev
> Subject: [ACS44] release work to do
>
> H,
>
> As far as I can see only the following two jobs are remaining:
>
> 1. generate the 32 and 64 bit system vms and upload them to the right
> place 2. change the site.
>
> I think I can do 2. I also can generate the templates. I am just wondering
> where to put them. Are these still going to download.cloud.com?
>
> --
> Daan
>

RE: Failed add KVM agent to CS with latest master

[Alex Brett]

> I am unable to add KVM agent with latest master build,  this issue is tracked
> in https://issues.apache.org/jira/browse/CLOUDSTACK-7170
> 
> Those made changes in master yesterday/today, can you please check it
> regressed from you commit or not ?

As noted on the ticket I've narrowed this down to one of the following three 
changesets:

commit 3b32732459730bfd4848678c95c27e2eb653cc04
Author: Min Chen 
Date:   Tue Jul 22 09:47:27 2014 -0700

CLOUDSTACK-7162:queryAsyncJobResult api does not return jobinstanceid.

commit 1d2124dcbf48d15d23ddbdea23a29f0ab21be6f3
Author: Hugo Trippaers 
Date:   Tue Jul 22 17:43:49 2014 +0200

Fix NPE reported on IRC, provide the user an informative error message

commit 4523490d44160b054de9e943f72db1d0ce06054a
Author: Santhosh Edukulla 
Date:   Mon Jul 21 20:49:03 2014 +0530

Fixed Coverity Issues reported

Signed-off-by: Santhosh Edukulla 

Alex

Re: Review Request 22863: CLOUDSTACK-6823 : First code drop for Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity.

[Hugo Trippaers]

Sudha,

I think those tests are in test/integration/component/test_brocade_vcs.py that 
Ritu included.

Cheers,

Hugo

On 23 jul. 2014, at 14:07, Sudha Ponnaganti  wrote:

> Ritu,
> 
> Would be good to add automated tests for the procedure you have outlined.  
> Marvin has already similar tests and you should be able to reuse them. 
> 
> Thanks
> /sudha
> 
>>> Testing
>>> ---
>>> 
>>> *   Create an isolated network; verify that the port-profile is created on 
>>> the Brocade switch.
>>> *   Attach a VM to the network; verify that the VMs MAC address is 
>>> associated with the port profile of the network on the Brocade switch.
>>> *   Delete VMs for an isolated network; verify that the VMs MAC address is 
>>> disassociated with the port profile of the network on the Brocade switch.
>>> *   Delete the isolated network; verify that the port-profile is deleted 
>>> from the Brocade switch.
>>> 
>>> Integration test result:
>>> 
>>> Test Brocade Network and VM Creation ... === TestName: 
>>> test_network_vcs | Status : SUCCESS === ok
>>> 
> 
> -Original Message-
> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> Sent: Wednesday, July 23, 2014 2:15 AM
> To: 
> Cc: Ritu Sabharwal
> Subject: Re: Review Request 22863: CLOUDSTACK-6823 : First code drop for 
> Brocade Network plugin to orchestrate Brocade VDX switches for L2 
> connectivity.
> 
> Hey all,
> 
> Just pushed the brocade VDX code into master.
> 
> * fing bugs is not showing any issues
> * decent unit test coverage
> * includes functional test procedure
> * majority of the functional code is contained in a plugin, minimal changes 
> to core
> 
> Cheers,
> 
> Hugo
> 
> 
> 
> On 23 jul. 2014, at 11:12, Hugo Trippaers  
> wrote:
> 
>> 
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/22863/#review48487
>> ---
>> 
>> Ship it!
>> 
>> 
>> commit 628d8e66f77053de9819436739325720710175ed
>> Author: Ritu Sabharwal 
>> Date:   Wed Jul 23 08:51:20 2014 +0200
>> 
>>   CLOUDSTACK-6823 : First code drop for Brocade Network plugin to 
>> orchestrate Brocade VDX switches for L2 connectivity
>> 
>>   Signed-off-by: Hugo Trippaers 
>> 
>> 
>> - Hugo Trippaers
>> 
>> 
>> On July 22, 2014, 9:44 p.m., Ritu  Sabharwal wrote:
>>> 
>>> ---
>>> This is an automatically generated e-mail. To reply, visit:
>>> https://reviews.apache.org/r/22863/
>>> ---
>>> 
>>> (Updated July 22, 2014, 9:44 p.m.)
>>> 
>>> 
>>> Review request for cloudstack and Hugo Trippaers.
>>> 
>>> 
>>> Bugs: CLOUDSTACK-6823
>>>   https://issues.apache.org/jira/browse/CLOUDSTACK-6823
>>> 
>>> 
>>> Repository: cloudstack-git
>>> 
>>> 
>>> Description
>>> ---
>>> 
>>> First code drop for Brocade Network plugin to orchestrate Brocade VDX 
>>> switches for L2 connectivity. Please create a new branch for Brocade plugin.
>>> 
>>> 
>>> Diffs
>>> -
>>> 
>>> api/src/com/cloud/network/Network.java 0a08f28  
>>> api/src/com/cloud/network/Networks.java 1ad3350  
>>> api/src/com/cloud/network/PhysicalNetwork.java 024b3ce  
>>> api/src/org/apache/cloudstack/network/ExternalNetworkDeviceManager.ja
>>> va e73f526  client/WEB-INF/classes/resources/messages.properties 
>>> bb75b08  client/WEB-INF/classes/resources/messages_zh_CN.properties 
>>> d7a0ca9  client/pom.xml 410cb19  
>>> client/tomcatconf/commands.properties.in aa03949  
>>> plugins/network-elements/brocade-vcs/pom.xml PRE-CREATION  
>>> plugins/network-elements/brocade-vcs/resources/BrocadeInterfaceSchema
>>> .xsd PRE-CREATION  
>>> plugins/network-elements/brocade-vcs/resources/BrocadePortProfileSche
>>> ma.xsd PRE-CREATION  
>>> plugins/network-elements/brocade-vcs/resources/BrocadeShowVcsSchema.x
>>> sd PRE-CREATION  
>>> plugins/network-elements/brocade-vcs/resources/META-INF/cloudstack/vc
>>> s/module.properties PRE-CREATION  
>>> plugins/network-elements/brocade-vcs/resources/META-INF/cloudstack/vc
>>> s/spring-vcs-context.xml PRE-CREATION  
>>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/Associat
>>> eMacToNetworkAnswer.java PRE-CREATION  
>>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/Associat
>>> eMacToNetworkCommand.java PRE-CREATION  
>>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/CreateNe
>>> tworkAnswer.java PRE-CREATION  
>>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/CreateNe
>>> tworkCommand.java PRE-CREATION  
>>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/DeleteNe
>>> tworkAnswer.java PRE-CREATION  
>>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/DeleteNe
>>> tworkCommand.java PRE-CREATION  
>>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/Disassoc
>>> iateMacFromNetworkAnswer.java PRE-CREATION  
>>> plugins/network-e

Re: Review Request 23847: Check if config specifies zones before iterating

[Miguel Ferreira]

> On July 23, 2014, 12:05 p.m., Santhosh Edukulla wrote:
> > tools/marvin/marvin/marvinInit.py, line 114
> > 
> >
> > please use is not None, rather !=
> 
> Miguel Ferreira wrote:
> I will do this this time, but if something is broken, I fix it and you 
> see better ways of fixing it, please be my guest and do it yourself. after 
> all that is the spirit of open-source, right?
> 
> Santhosh Edukulla wrote:
> sure, but lets make the submitter realize some better ways if there are, 
> after all it helps the review submission and cleaner approach Agree? The 
> review iam doing signifies its open source for your submission. Functionally, 
> modifying your review submission is like altering the behavior and may add 
> bugs, also resubmitting my review again.
> 
> Miguel Ferreira wrote:
> Patch was not in. Will submit it again.

Of course that the reviewer has the responsibility to make sure that the 
submitter adheres to the guidelines of a project. But the reviewer is not the 
manager of the submitter. I could even understand if this patch (and others 
I've submitted) where about new features. But they are not. They are fixing 
things that are broken.

If I decide to take the time to contribute back what I do to fix the code in 
the project, and address bugs in the system, I do not expect to get push back 
based on "there are better ways to do it". Because it was broken to begin with, 
so my patch is in fact a better way to do it. I'll be very happy if you say, 
sorry but I don't accept your patch because I know better ways to fix the code 
and I will do it myself.
However, what you are doing is leveraging my time to get things done the way 
you see best, and again, I'm not here to be managed.


- Miguel


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


On July 23, 2014, 12:17 p.m., Miguel Ferreira wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23847/
> ---
> 
> (Updated July 23, 2014, 12:17 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Santhosh Edukulla, and Hugo 
> Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Running a marvin test that does not specify a zone in the config file will 
> produce an exception while parsing the config:
> 
> Exception Occurred Under init ['Traceback (most recent call last):\n', '  
> File "/usr/local/lib/python2.7/site-packages/marvin/marvinInit.py", line 118, 
> in __setHypervisorAndZoneInfo\nfor zone in self.__parsedConfig.zones:\n', 
> "TypeError: 'NoneType' object is not iterable\n"]
> 
> This happens when the code starts iterating over a list of zones that does 
> not exist.
> I've added a check for the existence of the list of zones before iterating.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/marvinInit.py ce9b43f 
> 
> Diff: https://reviews.apache.org/r/23847/diff/
> 
> 
> Testing
> ---
> 
> Tests now run without the mentioned exception
> 
> 
> Thanks,
> 
> Miguel Ferreira
> 
>

Re: Review Request 23847: Check if config specifies zones before iterating

[Miguel Ferreira]

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

(Updated July 23, 2014, 12:17 p.m.)


Review request for cloudstack, daan Hoogland, Santhosh Edukulla, and Hugo 
Trippaers.


Changes
---

Update diff to address remark (previous update sent the initial patch)


Repository: cloudstack-git


Description
---

Running a marvin test that does not specify a zone in the config file will 
produce an exception while parsing the config:

Exception Occurred Under init ['Traceback (most recent call last):\n', '  File 
"/usr/local/lib/python2.7/site-packages/marvin/marvinInit.py", line 118, in 
__setHypervisorAndZoneInfo\nfor zone in self.__parsedConfig.zones:\n', 
"TypeError: 'NoneType' object is not iterable\n"]

This happens when the code starts iterating over a list of zones that does not 
exist.
I've added a check for the existence of the list of zones before iterating.


Diffs (updated)
-

  tools/marvin/marvin/marvinInit.py ce9b43f 

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


Testing
---

Tests now run without the mentioned exception


Thanks,

Miguel Ferreira

Re: Review Request 23847: Check if config specifies zones before iterating

[Miguel Ferreira]

> On July 23, 2014, 12:05 p.m., Santhosh Edukulla wrote:
> > tools/marvin/marvin/marvinInit.py, line 114
> > 
> >
> > please use is not None, rather !=
> 
> Miguel Ferreira wrote:
> I will do this this time, but if something is broken, I fix it and you 
> see better ways of fixing it, please be my guest and do it yourself. after 
> all that is the spirit of open-source, right?
> 
> Santhosh Edukulla wrote:
> sure, but lets make the submitter realize some better ways if there are, 
> after all it helps the review submission and cleaner approach Agree? The 
> review iam doing signifies its open source for your submission. Functionally, 
> modifying your review submission is like altering the behavior and may add 
> bugs, also resubmitting my review again.

Patch was not in. Will submit it again.


- Miguel


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


On July 23, 2014, 12:17 p.m., Miguel Ferreira wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23847/
> ---
> 
> (Updated July 23, 2014, 12:17 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Santhosh Edukulla, and Hugo 
> Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Running a marvin test that does not specify a zone in the config file will 
> produce an exception while parsing the config:
> 
> Exception Occurred Under init ['Traceback (most recent call last):\n', '  
> File "/usr/local/lib/python2.7/site-packages/marvin/marvinInit.py", line 118, 
> in __setHypervisorAndZoneInfo\nfor zone in self.__parsedConfig.zones:\n', 
> "TypeError: 'NoneType' object is not iterable\n"]
> 
> This happens when the code starts iterating over a list of zones that does 
> not exist.
> I've added a check for the existence of the list of zones before iterating.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/marvinInit.py ce9b43f 
> 
> Diff: https://reviews.apache.org/r/23847/diff/
> 
> 
> Testing
> ---
> 
> Tests now run without the mentioned exception
> 
> 
> Thanks,
> 
> Miguel Ferreira
> 
>

Re: Review Request 23847: Check if config specifies zones before iterating

[Santhosh Edukulla]

> On July 23, 2014, 12:05 p.m., Santhosh Edukulla wrote:
> > tools/marvin/marvin/marvinInit.py, line 114
> > 
> >
> > please use is not None, rather !=
> 
> Miguel Ferreira wrote:
> I will do this this time, but if something is broken, I fix it and you 
> see better ways of fixing it, please be my guest and do it yourself. after 
> all that is the spirit of open-source, right?

sure, but lets make the submitter realize some better ways if there are, after 
all it helps the review submission and cleaner approach Agree? The review iam 
doing signifies its open source for your submission. Functionally, modifying 
your review submission is like altering the behavior and may add bugs, also 
resubmitting my review again.  


- Santhosh


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


On July 23, 2014, 12:10 p.m., Miguel Ferreira wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23847/
> ---
> 
> (Updated July 23, 2014, 12:10 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Santhosh Edukulla, and Hugo 
> Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Running a marvin test that does not specify a zone in the config file will 
> produce an exception while parsing the config:
> 
> Exception Occurred Under init ['Traceback (most recent call last):\n', '  
> File "/usr/local/lib/python2.7/site-packages/marvin/marvinInit.py", line 118, 
> in __setHypervisorAndZoneInfo\nfor zone in self.__parsedConfig.zones:\n', 
> "TypeError: 'NoneType' object is not iterable\n"]
> 
> This happens when the code starts iterating over a list of zones that does 
> not exist.
> I've added a check for the existence of the list of zones before iterating.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/marvinInit.py ce9b43f 
> 
> Diff: https://reviews.apache.org/r/23847/diff/
> 
> 
> Testing
> ---
> 
> Tests now run without the mentioned exception
> 
> 
> Thanks,
> 
> Miguel Ferreira
> 
>

Re: Review Request 23847: Check if config specifies zones before iterating

[Miguel Ferreira]

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

(Updated July 23, 2014, 12:10 p.m.)


Review request for cloudstack, daan Hoogland, Santhosh Edukulla, and Hugo 
Trippaers.


Changes
---

Address remark


Repository: cloudstack-git


Description
---

Running a marvin test that does not specify a zone in the config file will 
produce an exception while parsing the config:

Exception Occurred Under init ['Traceback (most recent call last):\n', '  File 
"/usr/local/lib/python2.7/site-packages/marvin/marvinInit.py", line 118, in 
__setHypervisorAndZoneInfo\nfor zone in self.__parsedConfig.zones:\n', 
"TypeError: 'NoneType' object is not iterable\n"]

This happens when the code starts iterating over a list of zones that does not 
exist.
I've added a check for the existence of the list of zones before iterating.


Diffs (updated)
-

  tools/marvin/marvin/marvinInit.py ce9b43f 

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


Testing
---

Tests now run without the mentioned exception


Thanks,

Miguel Ferreira

Re: Review Request 23847: Check if config specifies zones before iterating

[Miguel Ferreira]

> On July 23, 2014, 12:05 p.m., Santhosh Edukulla wrote:
> > tools/marvin/marvin/marvinInit.py, line 114
> > 
> >
> > please use is not None, rather !=

I will do this this time, but if something is broken, I fix it and you see 
better ways of fixing it, please be my guest and do it yourself. after all that 
is the spirit of open-source, right?


- Miguel


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


On July 23, 2014, 11:56 a.m., Miguel Ferreira wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23847/
> ---
> 
> (Updated July 23, 2014, 11:56 a.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Santhosh Edukulla, and Hugo 
> Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Running a marvin test that does not specify a zone in the config file will 
> produce an exception while parsing the config:
> 
> Exception Occurred Under init ['Traceback (most recent call last):\n', '  
> File "/usr/local/lib/python2.7/site-packages/marvin/marvinInit.py", line 118, 
> in __setHypervisorAndZoneInfo\nfor zone in self.__parsedConfig.zones:\n', 
> "TypeError: 'NoneType' object is not iterable\n"]
> 
> This happens when the code starts iterating over a list of zones that does 
> not exist.
> I've added a check for the existence of the list of zones before iterating.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/marvinInit.py ce9b43f 
> 
> Diff: https://reviews.apache.org/r/23847/diff/
> 
> 
> Testing
> ---
> 
> Tests now run without the mentioned exception
> 
> 
> Thanks,
> 
> Miguel Ferreira
> 
>

RE: Review Request 22863: CLOUDSTACK-6823 : First code drop for Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity.

[Sudha Ponnaganti]

Ritu,

Would be good to add automated tests for the procedure you have outlined.  
Marvin has already similar tests and you should be able to reuse them. 

Thanks
/sudha

>> Testing
>> ---
>> 
>> *Create an isolated network; verify that the port-profile is created on 
>> the Brocade switch.
>> *Attach a VM to the network; verify that the VMs MAC address is 
>> associated with the port profile of the network on the Brocade switch.
>> *Delete VMs for an isolated network; verify that the VMs MAC address is 
>> disassociated with the port profile of the network on the Brocade switch.
>> *Delete the isolated network; verify that the port-profile is deleted 
>> from the Brocade switch.
>> 
>> Integration test result:
>> 
>> Test Brocade Network and VM Creation ... === TestName: 
>> test_network_vcs | Status : SUCCESS === ok
>>

-Original Message-
From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
Sent: Wednesday, July 23, 2014 2:15 AM
To: 
Cc: Ritu Sabharwal
Subject: Re: Review Request 22863: CLOUDSTACK-6823 : First code drop for 
Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity.

Hey all,

Just pushed the brocade VDX code into master.

* fing bugs is not showing any issues
* decent unit test coverage
* includes functional test procedure
* majority of the functional code is contained in a plugin, minimal changes to 
core

Cheers,

Hugo



On 23 jul. 2014, at 11:12, Hugo Trippaers  wrote:

> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22863/#review48487
> ---
> 
> Ship it!
> 
> 
> commit 628d8e66f77053de9819436739325720710175ed
> Author: Ritu Sabharwal 
> Date:   Wed Jul 23 08:51:20 2014 +0200
> 
>CLOUDSTACK-6823 : First code drop for Brocade Network plugin to 
> orchestrate Brocade VDX switches for L2 connectivity
> 
>Signed-off-by: Hugo Trippaers 
> 
> 
> - Hugo Trippaers
> 
> 
> On July 22, 2014, 9:44 p.m., Ritu  Sabharwal wrote:
>> 
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/22863/
>> ---
>> 
>> (Updated July 22, 2014, 9:44 p.m.)
>> 
>> 
>> Review request for cloudstack and Hugo Trippaers.
>> 
>> 
>> Bugs: CLOUDSTACK-6823
>>https://issues.apache.org/jira/browse/CLOUDSTACK-6823
>> 
>> 
>> Repository: cloudstack-git
>> 
>> 
>> Description
>> ---
>> 
>> First code drop for Brocade Network plugin to orchestrate Brocade VDX 
>> switches for L2 connectivity. Please create a new branch for Brocade plugin.
>> 
>> 
>> Diffs
>> -
>> 
>>  api/src/com/cloud/network/Network.java 0a08f28  
>> api/src/com/cloud/network/Networks.java 1ad3350  
>> api/src/com/cloud/network/PhysicalNetwork.java 024b3ce  
>> api/src/org/apache/cloudstack/network/ExternalNetworkDeviceManager.ja
>> va e73f526  client/WEB-INF/classes/resources/messages.properties 
>> bb75b08  client/WEB-INF/classes/resources/messages_zh_CN.properties 
>> d7a0ca9  client/pom.xml 410cb19  
>> client/tomcatconf/commands.properties.in aa03949  
>> plugins/network-elements/brocade-vcs/pom.xml PRE-CREATION  
>> plugins/network-elements/brocade-vcs/resources/BrocadeInterfaceSchema
>> .xsd PRE-CREATION  
>> plugins/network-elements/brocade-vcs/resources/BrocadePortProfileSche
>> ma.xsd PRE-CREATION  
>> plugins/network-elements/brocade-vcs/resources/BrocadeShowVcsSchema.x
>> sd PRE-CREATION  
>> plugins/network-elements/brocade-vcs/resources/META-INF/cloudstack/vc
>> s/module.properties PRE-CREATION  
>> plugins/network-elements/brocade-vcs/resources/META-INF/cloudstack/vc
>> s/spring-vcs-context.xml PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/Associat
>> eMacToNetworkAnswer.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/Associat
>> eMacToNetworkCommand.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/CreateNe
>> tworkAnswer.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/CreateNe
>> tworkCommand.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/DeleteNe
>> tworkAnswer.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/DeleteNe
>> tworkCommand.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/Disassoc
>> iateMacFromNetworkAnswer.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/Disassoc
>> iateMacFromNetworkCommand.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/StartupB
>> rocadeVcsCommand.java PRE-CREATION  
>> plugins/network-elements/brocade-vcs/src/com/cloud/api/commands/AddBr
>> ocadeVcsDeviceCmd.java PRE-CREATION  
>> plugins/netw

RE: deb http://cloudstack.apt-get.eu/ubuntu precise 4.3 - ISSUE

[Paul Angus]

Great, thanks Wido.

Regards

Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
paul.an...@shapeblue.com

-Original Message-
From: Wido den Hollander [mailto:w...@widodh.nl]
Sent: 23 July 2014 13:49
To: dev@cloudstack.apache.org
Subject: Re: deb http://cloudstack.apt-get.eu/ubuntu precise 4.3 - ISSUE



On 07/23/2014 01:39 PM, Wido den Hollander wrote:
>
>
> On 07/23/2014 01:32 PM, Paul Angus wrote:
>> Hi All,
>>
>> Installs from:
>>
>> deb http://cloudstack.apt-get.eu/ubuntu precise 4.3
>>
>> Fails the key check and appears to be returning CloudStack 4.4 if you
>> override the key check.
>>
>> Can someone have a look please.
>
> On it! Added the 4.4 packages this morning and that probably broke
> something.
>

Should be resolved by now. My apologies!

>>
>> Regards,
>>
>> Paul Angus
>>
>> *Senior Consultant / Cloud Architect*
>>
>> cid:image003.png@01CEF0F0.9C9104D0
>>
>> S: +44 20 3603 0540  | M: +4
>> 47711418784 | T: @CloudyAngus
>>
>> paul.an...@shapeblue.com  |
>> www.shapeblue.com  | Twitter:@shapeblue
>> 
>>
>> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>>
>> Find out more about ShapeBlue and our range of CloudStack related
>> services
>>
>> IaaS Cloud Design & Build
>> 
>> CSForge – rapid IaaS deployment framework
>>  CloudStack Consulting
>> 
>> CloudStack Infrastructure Support
>> 
>> CloudStack Bootcamp Training Courses
>> 
>>
>> This email and any attachments to it may be confidential and are
>> intended solely for the use of the individual to whom it is addressed.
>> Any views or opinions expressed are solely those of the author and do
>> not necessarily represent those of Shape Blue Ltd or related companies.
>> If you are not the intended recipient of this email, you must neither
>> take any action based upon its contents, nor copy or show it to anyone.
>> Please contact the sender if you believe you have received this email
>> in error. Shape Blue Ltd is a company incorporated in England & Wales.
>> ShapeBlue Services India LLP is a company incorporated in India and
>> is operated under license from Shape Blue Ltd. Shape Blue Brasil
>> Consultoria Ltda is a company incorporated in Brasil and is operated
>> under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company
>> registered by The Republic of South Africa and is traded under
>> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: Review Request 23847: Check if config specifies zones before iterating

[Santhosh Edukulla]

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



tools/marvin/marvin/marvinInit.py


please use is not None, rather !=


- Santhosh Edukulla


On July 23, 2014, 11:56 a.m., Miguel Ferreira wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23847/
> ---
> 
> (Updated July 23, 2014, 11:56 a.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Santhosh Edukulla, and Hugo 
> Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Running a marvin test that does not specify a zone in the config file will 
> produce an exception while parsing the config:
> 
> Exception Occurred Under init ['Traceback (most recent call last):\n', '  
> File "/usr/local/lib/python2.7/site-packages/marvin/marvinInit.py", line 118, 
> in __setHypervisorAndZoneInfo\nfor zone in self.__parsedConfig.zones:\n', 
> "TypeError: 'NoneType' object is not iterable\n"]
> 
> This happens when the code starts iterating over a list of zones that does 
> not exist.
> I've added a check for the existence of the list of zones before iterating.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/marvinInit.py ce9b43f 
> 
> Diff: https://reviews.apache.org/r/23847/diff/
> 
> 
> Testing
> ---
> 
> Tests now run without the mentioned exception
> 
> 
> Thanks,
> 
> Miguel Ferreira
> 
>

Review Request 23847: Check if config specifies zones before iterating

[Miguel Ferreira]

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

Review request for cloudstack, daan Hoogland, Santhosh Edukulla, and Hugo 
Trippaers.


Repository: cloudstack-git


Description
---

Running a marvin test that does not specify a zone in the config file will 
produce an exception while parsing the config:

Exception Occurred Under init ['Traceback (most recent call last):\n', '  File 
"/usr/local/lib/python2.7/site-packages/marvin/marvinInit.py", line 118, in 
__setHypervisorAndZoneInfo\nfor zone in self.__parsedConfig.zones:\n', 
"TypeError: 'NoneType' object is not iterable\n"]

This happens when the code starts iterating over a list of zones that does not 
exist.
I've added a check for the existence of the list of zones before iterating.


Diffs
-

  tools/marvin/marvin/marvinInit.py ce9b43f 

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


Testing
---

Tests now run without the mentioned exception


Thanks,

Miguel Ferreira

RE: [ACS44] release work to do

[Rayees Namathponnan]

I can help on posting template to download.cloud.com

Latest 4.4 64bit and 32-bit template jobs failing from 
http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-systemvm64/77/console;
 we need to update the URL for downloading debian-7.4.0-amd64-netinst.iso

Regards,
Rayees 

-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
Sent: Wednesday, July 23, 2014 2:26 AM
To: dev
Subject: [ACS44] release work to do

H,

As far as I can see only the following two jobs are remaining:

1. generate the 32 and 64 bit system vms and upload them to the right place 2. 
change the site.

I think I can do 2. I also can generate the templates. I am just wondering 
where to put them. Are these still going to download.cloud.com?

--
Daan

Re: deb http://cloudstack.apt-get.eu/ubuntu precise 4.3 - ISSUE

[Wido den Hollander]

On 07/23/2014 01:39 PM, Wido den Hollander wrote:



On 07/23/2014 01:32 PM, Paul Angus wrote:

Hi All,

Installs from:

deb http://cloudstack.apt-get.eu/ubuntu precise 4.3

Fails the key check and appears to be returning CloudStack 4.4 if you
override the key check.

Can someone have a look please.


On it! Added the 4.4 packages this morning and that probably broke
something.



Should be resolved by now. My apologies!



Regards,

Paul Angus

*Senior Consultant / Cloud Architect*

cid:image003.png@01CEF0F0.9C9104D0

S: +44 20 3603 0540  | M: +4
47711418784 | T: @CloudyAngus

paul.an...@shapeblue.com  |
www.shapeblue.com  | Twitter:@shapeblue


ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS

Find out more about ShapeBlue and our range of CloudStack related
services

IaaS Cloud Design & Build

CSForge – rapid IaaS deployment framework 
CloudStack Consulting 
CloudStack Infrastructure Support

CloudStack Bootcamp Training Courses


This email and any attachments to it may be confidential and are
intended solely for the use of the individual to whom it is addressed.
Any views or opinions expressed are solely those of the author and do
not necessarily represent those of Shape Blue Ltd or related companies.
If you are not the intended recipient of this email, you must neither
take any action based upon its contents, nor copy or show it to anyone.
Please contact the sender if you believe you have received this email in
error. Shape Blue Ltd is a company incorporated in England & Wales.
ShapeBlue Services India LLP is a company incorporated in India and is
operated under license from Shape Blue Ltd. Shape Blue Brasil
Consultoria Ltda is a company incorporated in Brasil and is operated
under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company
registered by The Republic of South Africa and is traded under license
from Shape Blue Ltd. ShapeBlue is a registered trademark.

Review Request 23845: vGPU test automation

[sailaja mada]

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

Review request for cloudstack, Doug Clark, Sanjay Tripathi, and Santhosh 
Edukulla.


Repository: cloudstack-git


Description
---

This patch contains below changes :

1. Skips tests with unsupported hypervisor environment 
2. Deploy VM with all supported vGPU service offerings 
3. Validation of VM is limited to verifying the state of the VM.


Diffs
-

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

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


Testing
---

Testing :

1. Executed the script on non GPU test setup and ensured tests being skipped 
2. Executed on K2 GPU drivers installed setup and ensured deploy VM cases 
working fine


Thanks,

sailaja mada

[RESULT][VOTE][ACS44]Apache CloudStack 4.4.0 RC 2 in branch 4.4-RC20140716T1409

[Daan Hoogland]

Hi all,

Though the release procedure states that my previous less formal mail
is enough, this is to emphasize
After 72 hours, the vote for CloudStack 4.4.0 [1] *passes* with
3 PMC + 0 non-PMC votes.

+1 (PMC / binding) 3 people

0 none

-1 none

Thanks to everyone participating.

I will now prepare the release announcement to go out after 24 hours
to give the mirrors time to catch up.


On Wed, Jul 16, 2014 at 2:24 PM, Daan Hoogland  wrote:
> Hi All,
>
> I've created a 4.4.0 release, with the following artifacts up for a vote:
>
> Git Branch and Commit SH:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20140716T1409
> Commit: c9672d8b5710e597bca3a81a7b06dc90c7f5b1f7
>
> List of changes:
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/
>
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.4.0/
>
> PGP release keys (signed using 4096R/AA4736F3):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours.
>
> 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)
>
>
>
> --
> Daan



-- 
Daan

Re: Review Request 23737: Improve usability of deployDataCenter.py and advanced zone config

[Miguel Ferreira]

> On July 21, 2014, 2:12 p.m., Santhosh Edukulla wrote:
> > tools/devcloud/devcloud-advanced.cfg, line 86
> > 
> >
> > whats the significance of this change?

As I said in the description, I reordered some parameters to increase 
readability. for instance having startip before endip, I think, increases 
readability.


> On July 21, 2014, 2:12 p.m., Santhosh Edukulla wrote:
> > tools/devcloud/devcloud-advanced.cfg, line 126
> > 
> >
> > Instead of these elements, please use advanced.cfg for reference and 
> > use logger element in similar, now marvin and test cases as such do not 
> > worry about testclient.log or testcase.log. Instead, logging was simplified 
> > to dump failed exception logs, run log and result log for each test suite, 
> > these elements can be removed, but log path can still be used.

I did not introduce that. The elements were already there.


- Miguel


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


On July 21, 2014, 1:42 p.m., Miguel Ferreira wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23737/
> ---
> 
> (Updated July 21, 2014, 1:42 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Hugo Trippaers, and Wei Zhou.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added step-wise log messages during deploy data center.
> 
> Also reordered some parameters in the advanced zone config for better 
> readability.
> 
> 
> Diffs
> -
> 
>   tools/devcloud/devcloud-advanced.cfg 74b6366 
>   tools/marvin/marvin/deployDataCenter.py ae48839 
> 
> Diff: https://reviews.apache.org/r/23737/diff/
> 
> 
> Testing
> ---
> 
> Used deployDataCenter.py together with advanced zone config to deploy a zone 
> in my development environment
> 
> 
> Thanks,
> 
> Miguel Ferreira
> 
>

Review Request 23843: Removed duplicated code block

[Miguel Ferreira]

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

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: deb http://cloudstack.apt-get.eu/ubuntu precise 4.3 - ISSUE

[Wido den Hollander]

On 07/23/2014 01:32 PM, Paul Angus wrote:

Hi All,

Installs from:

deb http://cloudstack.apt-get.eu/ubuntu precise 4.3

Fails the key check and appears to be returning CloudStack 4.4 if you
override the key check.

Can someone have a look please.


On it! Added the 4.4 packages this morning and that probably broke 
something.




Regards,

Paul Angus

*Senior Consultant / Cloud Architect*

cid:image003.png@01CEF0F0.9C9104D0

S: +44 20 3603 0540  | M: +4
47711418784 | T: @CloudyAngus

paul.an...@shapeblue.com  |
www.shapeblue.com  | Twitter:@shapeblue


ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS

Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build

CSForge – rapid IaaS deployment framework 
CloudStack Consulting 
CloudStack Infrastructure Support

CloudStack Bootcamp Training Courses


This email and any attachments to it may be confidential and are
intended solely for the use of the individual to whom it is addressed.
Any views or opinions expressed are solely those of the author and do
not necessarily represent those of Shape Blue Ltd or related companies.
If you are not the intended recipient of this email, you must neither
take any action based upon its contents, nor copy or show it to anyone.
Please contact the sender if you believe you have received this email in
error. Shape Blue Ltd is a company incorporated in England & Wales.
ShapeBlue Services India LLP is a company incorporated in India and is
operated under license from Shape Blue Ltd. Shape Blue Brasil
Consultoria Ltda is a company incorporated in Brasil and is operated
under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company
registered by The Republic of South Africa and is traded under license
from Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [ACS44] release work to do

[Daan Hoogland]

Sally,

Our beloved VP pointed out that I should contact you as well about a
press release. I cc Pierre-Luc in as he wrote the release notes and I
remember that you wanted them for the last press release, correct?

I am still busy building the last artifacts and uploading them to  the
proper sources, but I think bringing out a message tomorow or maybe on
friday or monday is appropriate.

kind regards,
Daan Hoogland

On Wed, Jul 23, 2014 at 11:25 AM, Daan Hoogland  wrote:
> H,
>
> As far as I can see only the following two jobs are remaining:
>
> 1. generate the 32 and 64 bit system vms and upload them to the right place
> 2. change the site.
>
> I think I can do 2. I also can generate the templates. I am just
> wondering where to put them. Are these still going to
> download.cloud.com?
>
> --
> Daan



-- 
Daan

deb http://cloudstack.apt-get.eu/ubuntu precise 4.3 - ISSUE

[Paul Angus]

Hi All,

Installs from:

deb http://cloudstack.apt-get.eu/ubuntu precise 4.3

Fails the key check and appears to be returning CloudStack 4.4 if you override 
the key check.

Can someone have a look please.


Regards,

Paul Angus
Senior Consultant / Cloud Architect
[cid:image003.png@01CEF0F0.9C9104D0]

S: +44 20 3603 0540 | M: +447711418784 | 
T: @CloudyAngus
paul.an...@shapeblue.com | 
www.shapeblue.com | 
Twitter:@shapeblue
ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS

Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge - rapid IaaS deployment framework
CloudStack Consulting
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

download template -> delete vhd

[Tomasz Zięba]

Hello,

Could someone confirm that download template deletes the vhd file from
secondary storage.

We are testing on the ACS version 4.2.1 but the code responsible for
removing is the same in version 4.4

https://github.com/apache/cloudstack/blob/8b6dc7ce2f0058b9cf29bd9c72e4e0db9162fe6e/services/secondary-storage/server/src/org/apache/cloudstack/storage/template/UploadManagerImpl.java

funkcja: handleDeleteEntityDownloadURLCommand


-- 
Regards,
Tomasz Zięba
Twitter: @TZieba
LinkedIn: pl.linkedin.com/pub/tomasz-zięba-ph-d/3b/7a8/ab6/

Re: Replace primary & secondary storage

[Tejas Gadaria]

Hi Min,

Thanks for information,
Once i will replace Secondary Storage successfully i will update the
result.

Regards,
Tejas


On Tue, Jul 22, 2014 at 10:56 PM, Min Chen  wrote:

> I am not sure if we have any document for ACS 4.3. But you may be able to
> reference the old document, and just remember that we have replaced the
> following old 3 tables:
>
> template_host_ref  ->  template_store_ref
> volume_host_ref-> volume_store_ref
> snapshot_host_ref  -> snapshot_store_ref
> And image_store table stores the secondary storage information.
>
> Hope that this can help.
>
> Thanks
> -min
>
> On 7/21/14 10:34 PM, "Tejas Gadaria"  wrote:
>
> >Hi Min,
> >
> >Thanks for clarification,
> >
> >"template_store_ref" provided me install_path & secondary storage id
> >information. it was quite helpful.
> >
> >I found this blog
> >http://stankirdey.com/content/cloudstack-merging-secondary-storages
> >
> >but he is using `template_host_ref`for ACS 4.2.
> >
> >Is there any documented procedure to replace secondary storage for ACS 4.3
> >?
> >
> >Regards,
> >Tejas
> >
> >
> >
> >On Mon, Jul 21, 2014 at 10:18 PM, Min Chen  wrote:
> >
> >> That article only applied to ACS 4.1 and older versions. In ACS 4.2
> >> storage refactor, db tables are changed. template_host_ref has been
> >> deprecated and replaced with template_store_ref.
> >>
> >> Thanks
> >> -min
> >>
> >> On 7/21/14 3:47 AM, "Tejas Gadaria"  wrote:
> >>
> >> >Hi,
> >> >
> >> >I found this article http://support.citrix.com/article/CTX135229
> >> >
> >> >I was just going through this but could not get some of the points.
> >> >
> >> >Currently I have no snapshots and all templates are public & another
> >> >secondary storage is not added yet.
> >> >
> >> >1) In above article 2nd point says "Copy the snapshots and templates
> >>from
> >> >Secondary Storage host S2 to S1."
> >> >& 6th  point in article says "You must copy only private templates on
> >> >Secondary storage host S2 to S1."
> >> >
> >> >Here I got confused a little.
> >> >
> >> >2) currently both tables are showing empty as shown below. Am I doing
> >> >anything wrong or it is normal?
> >> >
> >> >mysql> select sechost_id from snapshots;
> >> >Empty set (0.00 sec)
> >> >
> >> >mysql> select host_id from template_host_ref;
> >> >Empty set (0.00 sec)
> >> >
> >> >
> >> >Regards,
> >> >Tejas
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >On Mon, Jul 21, 2014 at 1:02 PM, Tejas Gadaria 
> >> >wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> I have production vms running on ACS 4.3 with xen 6.2 SP1.
> >> >>
> >> >> I have requirement to change primary & Secondary storage. I am
> >>planning
> >> >> live storage migration for all running vms, after adding new storage
> >>as
> >> >> primary storage storage in same cluster. ( correct me if i am missing
> >> >> anything)..but how can i replace secondary storage?
> >> >>
> >> >> Regards,
> >> >> Tejas
> >> >>
> >>
> >>
>
>

Re: Review Request 23735: Fix deployment of data center with marvin

[Santhosh Edukulla]

> On July 21, 2014, 1:56 p.m., Santhosh Edukulla wrote:
> > tools/marvin/marvin/marvinLog.py, line 168
> > 
> >
> > Make it more abstract and see if is not aware of cfg(log_cfg), i mean 
> > pass the logfile path, as similar to create log from directory, where we 
> > pass log folder dir.

Make it more abstract and see if is not aware of cfg(log_cfg), i mean pass the 
logfile path, as similar to create log from directory, where we pass log folder 
dir. 


- Santhosh


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


On July 22, 2014, 7:24 a.m., Miguel Ferreira wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23735/
> ---
> 
> (Updated July 22, 2014, 7:24 a.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, John Dilley, Santhosh Edukulla, 
> and Hugo Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The DevCloud wiki page [1] instructs developers to deploy a DC with basic 
> networking with the following command:
> $ python tools/marvin/marvin/deployDataCenter.py -i 
> tools/devcloud/devcloud-advanced.cfg
> 
> 
> However, that produces the error message bellow:
> 
>   Exception Occurred Under createLogs :['Traceback (most recent call 
> last):\n', '  File 
> "/Users/mferreira/development/git/cloudstack-sbp/tools/marvin/marvin/marvinLog.py",
>  line 157, in createLogs\n(\'LogFolderPath\' in log_cfg.__dict__.keys()) 
> and\n', "AttributeError: 'list' object has no attribute '__dict__'\n"]
> 
>   ===Log Creation Failed. Please Check===
> 
> 
> The cause of the error is the unexpected format of the logger element in 
> tools/devcloud/devcloud-advanced.cfg
> The patch I'm submitting add support for lists in the logger element of the 
> configuration.
> 
> [1] - https://cwiki.apache.org/confluence/display/CLOUDSTACK/DevCloud
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/deployDataCenter.py ae48839 
>   tools/marvin/marvin/marvinLog.py ea8eaee 
> 
> Diff: https://reviews.apache.org/r/23735/diff/
> 
> 
> Testing
> ---
> 
> With the patch I was able to deploy a zone in cloudstack.
> 
> 
> Thanks,
> 
> Miguel Ferreira
> 
>

Re: Review Request 23838: CLOUDSTACK-5986: Test scipt to verify the fix in isolated network for non-vpc networks

[Santhosh Edukulla]

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

Ship it!


Ship It!

- Santhosh Edukulla


On July 23, 2014, 9:14 a.m., sanjeev n wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23838/
> ---
> 
> (Updated July 23, 2014, 9:14 a.m.)
> 
> 
> 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.
> Test does the following:
> 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_escalations_instances.py 79fd3b1 
> 
> Diff: https://reviews.apache.org/r/23838/diff/
> 
> 
> Testing
> ---
> 
> Yes
> 
> 
> Thanks,
> 
> sanjeev n
> 
>

RE: Need edit rights for Wiki to improve Marvin - Testing with Python tutorial

[Santhosh Edukulla]

These were new changes done to marvin, during the same time, we edited wiki 
pages to reflect the changes, either it was reedited by some body or this 
particular place got missed. Please add the one with latest.

I can add that change for you if you require.

Santhosh

From: Miguel Ferreira [mferre...@schubergphilis.com]
Sent: Wednesday, July 23, 2014 6:23 AM
To: Daan Hoogland
Cc: dev; int-toolkit
Subject: Re: Need edit rights for Wiki to improve Marvin - Testing with Python 
tutorial

Thanks Daan,

By the way, just posted this on IRC dev channel, but got no reply there so here 
it goes:
> In the section about running a test from command line, there is a command 
> like this: "nosetests --with-marvin --marvin-config=demo.cfg --load 
> test_deploy_vm.py"
> However, the version I have of nosetests (installed recently) does not have a 
> "—load" options
> Furthermore, running the smoke tests from command line always fails because 
> the nose-marvin-plugin does not inject the apiclient into the test case (that 
> is because te plugin only doe injection when loading tests form TestCase 
> class and not from name, as it happens from the command line)

Should I be using a specific/patched version of nosetests?
Or should the “run from command line” section be removed?

Cheers,
Miguel


On 23 Jul 2014, at 12:16, Daan Hoogland  wrote:

> On Wed, Jul 23, 2014 at 11:56 AM, Miguel Ferreira
>  wrote:
>> miguelferreira
>
>
> in
>
> --
> Daan

RE: Setting cloudstack dev on windows7

[Donal Lafferty]

Can you confirm whether the instructions on the wiki are still correct?

> -Original Message-
> From: Priyanka Deepala [mailto:priyanka.deepal...@gmail.com]
> Sent: 23 July 2014 07:08
> To: dev@cloudstack.apache.org
> Subject: Re: Setting cloudstack dev on windows7
> 
> I restarted the system and tried again it's working now. Thank you
> 
> 
> --Regards
>   Priyanka
> 
> 
> On Wed, Jul 23, 2014 at 11:06 AM, Rajani Karuturi <
> rajani.karut...@citrix.com> wrote:
> 
> > Did you check if C:\Apache Maven\apache-maven-3.0.5\bin exists and
> > there is mvn in it??
> >
> > From the wiki page
> > “
> > Choose folder such that there are no spaces in the path!  E.g.
> > C:\bin\maven "
> >
> > ~Rajani
> >
> >
> >
> > On 23-Jul-2014, at 10:57 am, Priyanka Deepala <
> > priyanka.deepal...@gmail.com>
> wrote:
> >
> > I followed the same steps & added variable M2_HOME and specified the
> > path as C:\Apache Maven\apache-maven-3.0.5. %M2_HOME%\bin is
> added to
> > to PATH variable but still I'm getting the same error
> >
> >
> > Regards
> > Priyanka
> >
> >
> > On Wed, Jul 23, 2014 at 10:37 AM, Rajani Karuturi <
> > rajani.karut...@citrix.com> wrote:
> >
> > What did you add to the PATH? did you miss M2_HOME/bin??
> >
> > FYI,
> > This came on the first page when googled for “cygwin maven windows”
> > http://www.mkyong.com/maven/how-to-install-maven-in-windows/
> >
> >
> >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Setting+up+a+Cl
> > oudStack+dev+environment+on+Windows
> > Step-8 has details on how to setup maven
> >
> > Please spend a little time on google.
> >
> >
> >
> > ~Rajani
> >
> >
> >
> > On 23-Jul-2014, at 10:27 am, Priyanka Deepala <
> > priyanka.deepal...@gmail.com>
> wrote:
> >
> > I Installed maven-3.0.5.src and specified the path in environment
> > variable PATH. When I'm trying to test it in  Cygwin shell by typing
> > 'which mvn' it is displaying as "no mvn in that path..So What should I do
> now??
> >
> >
> >
> >

Re: Need edit rights for Wiki to improve Marvin - Testing with Python tutorial

[Miguel Ferreira]

Thanks Daan,

By the way, just posted this on IRC dev channel, but got no reply there so here 
it goes:
> In the section about running a test from command line, there is a command 
> like this: "nosetests --with-marvin --marvin-config=demo.cfg --load 
> test_deploy_vm.py"
> However, the version I have of nosetests (installed recently) does not have a 
> "—load" options
> Furthermore, running the smoke tests from command line always fails because 
> the nose-marvin-plugin does not inject the apiclient into the test case (that 
> is because te plugin only doe injection when loading tests form TestCase 
> class and not from name, as it happens from the command line)

Should I be using a specific/patched version of nosetests?
Or should the “run from command line” section be removed?

Cheers,
Miguel


On 23 Jul 2014, at 12:16, Daan Hoogland  wrote:

> On Wed, Jul 23, 2014 at 11:56 AM, Miguel Ferreira
>  wrote:
>> miguelferreira
> 
> 
> in
> 
> -- 
> Daan

Re: Need edit rights for Wiki to improve Marvin - Testing with Python tutorial

[Daan Hoogland]

On Wed, Jul 23, 2014 at 11:56 AM, Miguel Ferreira
 wrote:
> miguelferreira


in

-- 
Daan

Re: [DISCUSS][PROPOSAL] git workflow

[Leo Simons]

Hey folks,

With 4.4.0 tagged, is now an opportune time to go and implement this?

I would enthousiastically +1 and get crackin', but I’m not a committer so its 
not that practical for me to volunteer!

I wanted to point out atlassian’s description of gitflow

  https://www.atlassian.com/git/workflows#!workflow-gitflow

which might be easier to read.

Similarly, the git-flow scripts that help out with implementing this stuff

  https://github.com/nvie/gitflow

they also describe the relationship between gitflow and dealing with multiple 
remotes

  https://www.atlassian.com/git/workflows#!pull-request

Finally note atlassian’s free sourcetree GUI has built-in support for git-flow

  http://www.sourcetreeapp.com/

Because cloudstack currently is full of rebasing and squashing and 
cherry-picking, you get very little benefit from a tree visualization tool 
(like this or gitk or ...) right now, but it would be *great* to have going 
forward.


cheers,


Leo

On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen  wrote:

> I would like to re-start this discussion.
> 
> Rajani made some good points and someone mentioned Gitflow:
> 
> http://nvie.com/posts/a-successful-git-branching-model/
> 
> Thinking about our release procedure, we clearly need more tests and a CI. 
> However it looks like this is going to take some time.
> 
> In the meantime I think there is nothing preventing us from agreeing to 'git 
> practices', we don't need tests or new infra, we just need to agree on the 
> git workflow.
> 
> Right now Master is really a development branch, we should make it a stable 
> branch for production with very few commits.
> This does not mean that we would release less, in contrary this would ensure 
> that a commit to master means it's a production release.
> 
> In addition gitflow [1] does not do cherry-picks (gets back to Rajani's 
> point) everything is based on merges.
> 
> I am of the opinion that git flow provides a nice process. It basically 
> freezes master. Development happens in a 'develop' branch, releases branches 
> are branched off of that and merged into master and back into develop….etc
> 
> Please read [1] it's a good read.
> 
> And let's discuss,
> 
> [1] http://nvie.com/posts/a-successful-git-branching-model/
> 
> -Sebastien
> 
> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi  
> wrote:
> 
>> There is also the problem of cherry-picking.
>> As a contributor, I always endup creating multiple patches for each branch 
>> as they don’t cleanly apply on the upward branches. which means distinct 
>> commits for each branch and I don’t easily know which all branches my commit 
>> exists unless I do grep.
>> if we follow merging strategy properly, apart from the first merge of the 
>> branch, everything else on top of it should be a painless merge. 
>> 
>> 
>> 
>> ~Rajani
>> 
>> 
>> 
>> On 02-Jun-2014, at 10:51 pm, Marcus  wrote:
>> 
>>> I think many of the bullet points are what we are currently doing
>>> (guidelines for commit comments, feature branches need to stay in sync with
>>> master, no back-merging). I also think that much of what we do now is done
>>> the way it is simply because there *are* vast changes between versions.
>>> Classes are getting shuffled around and changed all the time. If its
>>> feasible to merge branch fixes to master, that's fine, but some quick tests
>>> seem to indicate that this will be messy getting started.
>>> 
>>> That leaves us with how we do releases. I'm fine with having single
>>> branches for major releases(4.3) and tagging the commits where each
>>> incremental release (4.3.x) is done. I'm trying to remember why we went
>>> with the -forward, I'm sure it's in the mailing list somewhere, but one of
>>> the nice things it provides is the ability for the release manager to
>>> control what changes are made during code freeze while giving people a
>>> place to stage fixes (though admittedly this is not always followed).
>>> Without -forward, would the flow be for each dev to have their own repo and
>>> issue pull requests for bugfixes?
>>> 
>>> 
>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi 
>>> wrote:
>>> 
 Any other suggestions/objections/comments??
 Can we discuss this in detail and agree to a process??
 
 
 ~Rajani
 
 
 
 On 02-Jun-2014, at 9:32 am, Rajani Karuturi 
 wrote:
 
> Yes as mike said, if its a one-off case we can do a empty merge(merge -s
 ours) for it and git will assume its merged but will not bring in any
 changes.
> 
> If the branches diverged a lot, for example after a major rewrite, we
 could stop merging to that branch and above and make the fix manually.
> 
> 
> ~Rajani
> 
> 
> 
> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
 mike.tutkow...@solidfire.com> wrote:
> 
>> Yep, that's what I was referring to in that a particular fix for an old
>> release may not apply to newer versions. That does happen.
>> 
>> We used to 

Need edit rights for Wiki to improve Marvin - Testing with Python tutorial

[Miguel Ferreira]

Hi,

I’m following the "Marvin - Testing with Python" tutorial and found some 
problems with the first example already.
I would like to contribute what I found back, but for that I need to be able to 
edit the page.

Username: miguelferreira

Cheers,
Miguel

RE: Guidelines on Functional Test for plugins

[Santhosh Edukulla]

One suggestion if we agree,

we can move all "plugin" related functional test cases added so far like 
nuage,brocade or others, in to test/integration/component/"plugins"/.   Not 
always, we may run them with equipment available for those plugins, in regular 
regression we can still run normal functional suites, otherwise picking up 
complete component folder enables all test suites to be picked up for 
automation run.

Santhosh

From: Trippie [trip...@gmail.com] on behalf of Hugo Trippaers [h...@apache.org]
Sent: Wednesday, July 23, 2014 5:16 AM
To: 
Subject: Re: Guidelines on Functional Test for plugins

Talluri,

Can you also add the new functional tests in the brocade plugin?

test/integration/component/test_brocade_vcs.py

Cheers,

Hugo

On 21 jul. 2014, at 12:09, Hugo Trippaers  wrote:

> Santosh, Talluri,
>
> Can you guys make sure the functional tests created by Suresh are integrated 
> in the CI runs?
>
> test/integration//component/test_nuage_vsp.py
>
> Cheers,
>
> Hugo
>
>
> On 15 jul. 2014, at 14:07, Suresh Ramamurthy 
>  wrote:
>
>> Hi All,
>>
>> Can any one please point me to any document or example for sample FT for
>> plugins.
>> Testing plugin needs some setup tp be available.
>>
>> Is there any way in ACS framework where we can bypass the setup and still
>> test the functionality?
>> In some cases where the client library can not be redistributed, how do we
>> test it?
>>
>> Please let me know so that I can write some FT for plugin that we are
>> developing.
>>
>> Thanks,
>> Suresh
>

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

[Gaurav Aradhye]

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

Review request for cloudstack, sanjeev n and SrikanteswaraRao Talluri.


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