abount usage-server config

[李栋]

*hi all:**
**We followed the document
(http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/usage.html)
configured usage-server and it worked
*
*

then modify the global variable parameters, as follows: *





*But the usage of the database is still no data, there is only one
unfinished task record in usage_job in: *



*usage_log is this: *
2014-08-07 05:34:50,600 INFO
[context.support.ClassPathXmlApplicationContext] (main:null) Refreshing
org.springframework.context.support.ClassPathXmlApplicationContext@5d5bdc50:
startup date [Thu Aug 07 13:34:50 CST 2014]; root of context hierarchy
2014-08-07 05:34:50,850 INFO [factory.xml.XmlBeanDefinitionReader]
(main:null) Loading XML bean definitions from class path resource
[usageApplicationContext.xml]
2014-08-07 05:34:51,508 INFO
[context.annotation.ClassPathBeanDefinitionScanner] (main:null) JSR-330
'javax.inject.Named' annotation found and supported for component scanning
2014-08-07 05:34:52,469 INFO
[factory.annotation.AutowiredAnnotationBeanPostProcessor] (main:null)
JSR-330 'javax.inject.Inject' annotation found and supported for autowiring
2014-08-07 05:34:52,557 INFO
[context.support.ClassPathXmlApplicationContext] (main:null) Bean
'transactionContextBuilder' of type [class
com.cloud.utils.db.TransactionContextBuilder] is not eligible for
getting processed by all BeanPostProcessors (for example: not eligible
for auto-proxying)
2014-08-07 05:34:52,603 INFO
[factory.support.DefaultListableBeanFactory] (main:null)
Pre-instantiating singletons in
org.springframework.beans.factory.support.DefaultListableBeanFactory@44d6b059:
defining beans
[org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,usageAlertManagerImpl,usageManagerImpl,networkOfferingUsageParser,VMInstanceUsageParser,loadBalancerUsageParser,volumeUsageParser,vmDiskUsageParser,networkUsageParser,securityGroupUsageParser,VPNUserUsageParser,IPAddressUsageParser,portForwardingUsageParser,VMSnapshotUsageParser,storageUsageParser,usageJobDaoImpl,usageVMInstanceDaoImpl,usageSecurityGroupDaoImpl,usagePortForwardingRuleDaoImpl,usageVmDiskDaoImpl,usageDaoImpl,externalPublicIpStatisticsDaoImpl,usageVMSnapshotDaoImpl,usageStorageDaoImpl,usageVPNUserDaoImpl,usageIPAddressDaoImpl,usageLoadBalancerPolicyDaoImpl,usageNetworkOfferingDaoImpl,usageNetworkDaoImpl,usageVolumeDaoImpl,eventDaoImpl,usageEventDaoImpl,eventJoinDaoImpl,accountDaoImpl,vmDiskStatisticsDaoImpl,userStatsLogDaoImpl,userAccountDaoImpl,userStatisticsDaoImpl,SSHKeyPairDaoImpl,userDaoImpl,resourceCountDaoImpl,resourceLimitDaoImpl,configurationDaoImpl,alertDaoImpl,domainDaoImpl,transactionContextBuilder,instantiatePostProcessor,ComponentContext,org.springframework.context.annotation.ConfigurationClassPostProcessor$ImportAwareBeanPostProcessor#0];
root of factory hierarchy
2014-08-07 05:34:53,233 DEBUG [utils.crypt.EncryptionSecretKeyChecker]
(main:null) Encryption Type: file
2014-08-07 05:34:56,686 INFO [utils.component.ComponentContext]
(main:null) Setup Spring Application context
2014-08-07 05:34:59,507 INFO [utils.component.ComponentContext]
(main:null) Configuring
com.cloud.configuration.dao.ConfigurationDaoImpl_EnhancerByCloudStack_10af8e24
2014-08-07 05:34:59,514 INFO [utils.component.ComponentContext]
(main:null) Configuring
com.cloud.configuration.dao.ResourceCountDaoImpl_EnhancerByCloudStack_17475fe1
2014-08-07 05:34:59,522 INFO [utils.component.ComponentContext]
(main:null) Configuring
com.cloud.usage.dao.UsageSecurityGroupDaoImpl_EnhancerByCloudStack_132b816b
2014-08-07 05:34:59,522 INFO [utils.component.ComponentContext]
(main:null) Configuring
com.cloud.user.dao.SSHKeyPairDaoImpl_EnhancerByCloudStack_c87a2086
2014-08-07 05:34:59,523 INFO [utils.component.ComponentContext]
(main:null) Configuring
com.cloud.usage.dao.ExternalPublicIpStatisticsDaoImpl_EnhancerByCloudStack_abdd868b
2014-08-07 05:34:59,524 INFO [utils.component.ComponentContext]
(main:null) Configuring
com.cloud.user.dao.AccountDaoImpl_EnhancerByCloudStack_d3b285cc
2014-08-07 05:34:59,524 INFO [utils.component.ComponentContext]
(main:null) Configuring
com.cloud.domain.dao.DomainDaoImpl_EnhancerByCloudStack_ba7a7fbc
2014-08-07 05:34:59,525 INFO [utils.component.ComponentContext]
(main:null) Configuring
com.cloud.usage.dao.UsageVPNUserDaoImpl_EnhancerByCloudStack_5f95c12b
2014-08-07 05:34:59,525 INFO [utils.component.ComponentContext]
(main:null) Configuring
com.cloud.usage.dao.UsageNetworkOfferingDaoImpl_EnhancerByCloudStack_5287ae4e
2014-08-07 05:34:59,534 INFO [utils.component.ComponentContext]
(main:null) Configuring
com.cloud.usage.dao.UsageVmDiskDaoImpl_EnhancerByCloudStack_3d51f22a
2014-08-07 05:34:59,534 INFO [utils.component.ComponentContext]
(main:null) Configuring
com.cloud.usage.dao.UsageLoadBal

Re: [VOTE] git workflow

[Daan Hoogland]

Animesh, cherry-picking from a single branch will cause conflicts in
the long run (of two to three months) so it is a major problem with
the way we release now. Also it will add the code and I was not
convinced that merging was better until Leo showed me a history graph
as example. With merging a lot more history is preserved and it is
easier to see how the present state of the code came to be. I don't
think it is an end goal but it is very convenient for an RM.

On Thu, Aug 7, 2014 at 8:40 AM, Animesh Chaturvedi
 wrote:
>
>>
>> (Like most of the internet...) I strongly believe using cherry picks as the 
>> basic
>> tool for (release) branch management is one of the worst choices you can
>> make.
>>
>> But. Please. Can. We. Just. Stop. Cherry. Picking!!! :-D [1]
>>
> [Animesh] Leo I don't mind moving to merging branches rather than 
> cherry-picking for technical reasons, but I am not sure cherry-picking is to 
> blame entirely. Using it all the time caused the pain. When Chip and I were 
> running releases we started cherry-picks when we got closer to RC. I did not 
> see cherry-pick as a big pain for 4.2 and 4.3 where I was the RM.  RM cannot 
> scale if they are spending most of their time in cherry-picking or merging 
> branches into release branch.  It needs to be done when they  are reasonably 
> confident that the churn will be limited otherwise RM will get drowned in all 
> these requests (be it cherry-pick or merge branch).  And also I have used 
> cherry-pick with -x flag which appends "cherry-picked from ...'  to the 
> original commit message in order to indicate which commit this change was 
> cherry-picked from.
>
>
>
>



-- 
Daan

Re: abount usage-server config

[李栋]

cloudstack version is 4.2.1

于 2014/8/7 15:02, 李栋 写道:
> *hi all:**
> **We followed the document
> (http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/usage.html)
> configured usage-server and it worked
> *
> *
>
> then modify the global variable parameters, as follows: *
>
>
>
>
>
> *But the usage of the database is still no data, there is only one
> unfinished task record in usage_job in: *
>
>
>
> *usage_log is this: *
> 2014-08-07 05:34:50,600 INFO
> [context.support.ClassPathXmlApplicationContext] (main:null)
> Refreshing
> org.springframework.context.support.ClassPathXmlApplicationContext@5d5bdc50:
> startup date [Thu Aug 07 13:34:50 CST 2014]; root of context hierarchy
> 2014-08-07 05:34:50,850 INFO [factory.xml.XmlBeanDefinitionReader]
> (main:null) Loading XML bean definitions from class path resource
> [usageApplicationContext.xml]
> 2014-08-07 05:34:51,508 INFO
> [context.annotation.ClassPathBeanDefinitionScanner] (main:null)
> JSR-330 'javax.inject.Named' annotation found and supported for
> component scanning
> 2014-08-07 05:34:52,469 INFO
> [factory.annotation.AutowiredAnnotationBeanPostProcessor] (main:null)
> JSR-330 'javax.inject.Inject' annotation found and supported for
> autowiring
> 2014-08-07 05:34:52,557 INFO
> [context.support.ClassPathXmlApplicationContext] (main:null) Bean
> 'transactionContextBuilder' of type [class
> com.cloud.utils.db.TransactionContextBuilder] is not eligible for
> getting processed by all BeanPostProcessors (for example: not eligible
> for auto-proxying)
> 2014-08-07 05:34:52,603 INFO
> [factory.support.DefaultListableBeanFactory] (main:null)
> Pre-instantiating singletons in
> org.springframework.beans.factory.support.DefaultListableBeanFactory@44d6b059:
> defining beans
> [org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,usageAlertManagerImpl,usageManagerImpl,networkOfferingUsageParser,VMInstanceUsageParser,loadBalancerUsageParser,volumeUsageParser,vmDiskUsageParser,networkUsageParser,securityGroupUsageParser,VPNUserUsageParser,IPAddressUsageParser,portForwardingUsageParser,VMSnapshotUsageParser,storageUsageParser,usageJobDaoImpl,usageVMInstanceDaoImpl,usageSecurityGroupDaoImpl,usagePortForwardingRuleDaoImpl,usageVmDiskDaoImpl,usageDaoImpl,externalPublicIpStatisticsDaoImpl,usageVMSnapshotDaoImpl,usageStorageDaoImpl,usageVPNUserDaoImpl,usageIPAddressDaoImpl,usageLoadBalancerPolicyDaoImpl,usageNetworkOfferingDaoImpl,usageNetworkDaoImpl,usageVolumeDaoImpl,eventDaoImpl,usageEventDaoImpl,eventJoinDa
> oImpl,accountDaoImpl,vmDiskStatisticsDaoImpl,userStatsLogDaoImpl,userAccountDaoImpl,userStatisticsDaoImpl,SSHKeyPairDaoImpl,userDaoImpl,resourceCountDaoImpl,resourceLimitDaoImpl,configurationDaoImpl,alertDaoImpl,domainDaoImpl,transactionContextBuilder,instantiatePostProcessor,ComponentContext,org.springframework.context.annotation.ConfigurationClassPostProcessor$ImportAwareBeanPostProcessor#0];
> root of factory hierarchy
> 2014-08-07 05:34:53,233 DEBUG [utils.crypt.EncryptionSecretKeyChecker]
> (main:null) Encryption Type: file
> 2014-08-07 05:34:56,686 INFO [utils.component.ComponentContext]
> (main:null) Setup Spring Application context
> 2014-08-07 05:34:59,507 INFO [utils.component.ComponentContext]
> (main:null) Configuring
> com.cloud.configuration.dao.ConfigurationDaoImpl_EnhancerByCloudStack_10af8e24
> 2014-08-07 05:34:59,514 INFO [utils.component.ComponentContext]
> (main:null) Configuring
> com.cloud.configuration.dao.ResourceCountDaoImpl_EnhancerByCloudStack_17475fe1
> 2014-08-07 05:34:59,522 INFO [utils.component.ComponentContext]
> (main:null) Configuring
> com.cloud.usage.dao.UsageSecurityGroupDaoImpl_EnhancerByCloudStack_132b816b
> 2014-08-07 05:34:59,522 INFO [utils.component.ComponentContext]
> (main:null) Configuring
> com.cloud.user.dao.SSHKeyPairDaoImpl_EnhancerByCloudStack_c87a2086
> 2014-08-07 05:34:59,523 INFO [utils.component.ComponentContext]
> (main:null) Configuring
> com.cloud.usage.dao.ExternalPublicIpStatisticsDaoImpl_EnhancerByCloudStack_abdd868b
> 2014-08-07 05:34:59,524 INFO [utils.component.ComponentContext]
> (main:null) Configuring
> com.cloud.user.dao.AccountDaoImpl_EnhancerByCloudStack_d3b285cc
> 2014-08-07 05:34:59,524 INFO [utils.component.ComponentContext]
> (main:null) Configuring
> com.cloud.domain.dao.DomainDaoImpl_EnhancerByCloudStack_ba7a7fbc
> 2014-08-07 05:34:59,525 INFO [utils.component.ComponentContext]
> (main:null) Configuring
> com.cloud.usage.dao.UsageVPNUserDaoImpl_EnhancerByCloudStack_5f95c12b
> 2014-08-07 05:34:59,525 INFO [utils.component.ComponentContext]
> (main:null) Configuring
> com.cloud.usage.dao.UsageNetworkOfferingDaoImpl_EnhancerByCloudStack_5287ae4e
> 2014-08-07 05:34:59,534 INFO [utils.component.ComponentContext]
> (ma

Re: Review Request 24298: CLOUDSTACK-6873: Moved test cases that run only on simulator and those should be run serially to misc folder and also tagged them with required_hardware='simulator only'

[ASF Subversion and Git Services]

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


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

CLOUDSTACK-6873: Moved test cases that run only on simulator and those should 
be run serially to misc folder and also tagged them with 
required_hardware='simulator only'

Signed-off-by: Santhosh Edukulla 


- ASF Subversion and Git Services


On Aug. 7, 2014, 6:19 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24298/
> ---
> 
> (Updated Aug. 7, 2014, 6:19 a.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6873
> https://issues.apache.org/jira/browse/CLOUDSTACK-6873
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The tests in test suites test_deploy_vm.py and test_vm_ha.py need to be run 
> serially, hence moved them to misc folder.
> Also tagged the tests as "required_hardware='simulator only'" which require 
> to be run only on simulator.
> 
> Moved the normal tests (for which above criteria don't apply) from 
> test_deploy_vm.py to test_vm_life_cycle.py in smoke folder.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/misc/__init__.py PRE-CREATION 
>   test/integration/smoke/misc/test_deploy_vm.py PRE-CREATION 
>   test/integration/smoke/misc/test_vm_ha.py PRE-CREATION 
>   test/integration/smoke/test_deploy_vm.py 29cdb96 
>   test/integration/smoke/test_vm_ha.py c7d1648 
>   test/integration/smoke/test_vm_life_cycle.py eef4dc1 
> 
> Diff: https://reviews.apache.org/r/24298/diff/
> 
> 
> Testing
> ---
> 
> Yes, tested test_vm_life_cycle.py with python command.
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 24378: CLOUDSTACK-7268: Ignore "already exists" error in createEgressFirewallRule

[Santhosh Edukulla]

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



tools/marvin/marvin/lib/base.py


may be to keep simple check if not string in e.. and raise, pass can be 
removed. As well, is the exception thrown is only cloudstackAPIException or 
some other type? add a default handler if possible and fail in case so?

Do a lower comparison of message again for both left and right hand vlaue.


- Santhosh Edukulla


On Aug. 6, 2014, 2:58 p.m., John Dilley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24378/
> ---
> 
> (Updated Aug. 6, 2014, 2:58 p.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-7268
> https://issues.apache.org/jira/browse/CLOUDSTACK-7268
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Although we could search for an existing firewall rule, this fix is simpler, 
> and also less prone to race conditions if multiple threads are running.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/lib/base.py 3a1f7e6 
> 
> Diff: https://reviews.apache.org/r/24378/diff/
> 
> 
> Testing
> ---
> 
> Tested on KVM advanced zone
> 
> 
> Thanks,
> 
> John Dilley
> 
>

Re: [VOTE] git workflow

[Leo Simons]

On Aug 7, 2014, at 8:40 AM, Animesh Chaturvedi  
wrote:
>> (Like most of the internet...) I strongly believe using cherry picks as the 
>> basic
>> tool for (release) branch management is one of the worst choices you can
>> make. 
>> 
>> But. Please. Can. We. Just. Stop. Cherry. Picking!!! :-D [1]
>> 
> [Animesh] Leo I don't mind moving to merging branches rather than 
> cherry-picking for technical reasons, but I am not sure cherry-picking is to 
> blame entirely. Using it all the time caused the pain.

Yes, I completely agree with that! It was a bit tongue-in-cheek, in fact the 
joke at the [1] reference...

> [1] ... Using 'git cherry-pick' when there are actual cherries
> to actually pick is fully endorsed by LSD Enterprises LTD.
> Picking things other than cherries voids warranty. ...

...tries to make the same point. I really should stop trying to be funny! More 
seriously,


Use distributed version control.
Commit early and often. Push often enough.
Strive for idempotent commits.
Write good commit messages.
Ask and give review liberally.
Keep history though rewriting some of it is ok.
Branch pre-emptively, except when you are sure you don’t need to.
Rebase when it is safe to do so.
Merge deliberately to combine branches.
Stabilize a branch before you merge from it.
Merge from the more stable onto the less stable branches.
Pick cherries from a less stable branch you won’t merge.
Know your tools.
Know when to break the rules.


happy hacking,


Leo

Re: Review Request 24383: CLOUDSTACK-7271: Accept any hypervisor in error message for integration.smoke.test_deploy_vm_root_resize.TestDeployVM.test_00_deploy_vm_root_resize

[Santhosh Edukulla]

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

Ship it!


Ship It!

- Santhosh Edukulla


On Aug. 6, 2014, 2:57 p.m., John Dilley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24383/
> ---
> 
> (Updated Aug. 6, 2014, 2:57 p.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-7271
> https://issues.apache.org/jira/browse/CLOUDSTACK-7271
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> In test 
> integration.smoke.test_deploy_vm_root_resize.TestDeployVM.test_00_deploy_vm_root_resize,
>  the error message should accept any hypervisor in the error message
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_deploy_vm_root_resize.py 029e7db 
> 
> Diff: https://reviews.apache.org/r/24383/diff/
> 
> 
> Testing
> ---
> 
> Tested on VMWare
> 
> 
> Thanks,
> 
> John Dilley
> 
>

Re: [VOTE] git workflow

[Sebastien Goasguen]

On Aug 6, 2014, at 7:15 PM, David Nalley  wrote:

> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>  wrote:
>> Edison, thank you for raising the concern about the BVT/CI. Somebody
>> mentioned earlier that we should separate git workflow implementation from
>> the CI effort, but I do think we have to do in in conjunction. Otherwise
>> what is the point in introducing staging/develop branch? If there is no
>> daily automation run verifying all the code merged from hotFixes/feature
>> branches (and possibly reverting wrong checkins), we can as well merge the
>> code directly to master.
>> 
> 
> Yes! - please.
> Doing this without CI as a gating factor buys us very little.
> 
> --David

David, can you clarify. Are you going to be against any change of git workflow 
until we get CI/BVT in place ?

Re: Review Request 24378: CLOUDSTACK-7268: Ignore "already exists" error in createEgressFirewallRule

[John Dilley]

> On Aug. 7, 2014, 7:21 a.m., Santhosh Edukulla wrote:
> > tools/marvin/marvin/lib/base.py, line 350
> > 
> >
> > may be to keep simple check if not string in e.. and raise, pass can be 
> > removed. As well, is the exception thrown is only cloudstackAPIException or 
> > some other type? add a default handler if possible and fail in case so?
> > 
> > Do a lower comparison of message again for both left and right hand 
> > vlaue.

The failure we want to ignore will always be cloudstackAPI exception. Any other 
type of exception will not match an except block, so will be raised rather than 
handled.


- John


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


On Aug. 7, 2014, 7:41 a.m., John Dilley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24378/
> ---
> 
> (Updated Aug. 7, 2014, 7:41 a.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-7268
> https://issues.apache.org/jira/browse/CLOUDSTACK-7268
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Although we could search for an existing firewall rule, this fix is simpler, 
> and also less prone to race conditions if multiple threads are running.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/lib/base.py 3a1f7e6 
> 
> Diff: https://reviews.apache.org/r/24378/diff/
> 
> 
> Testing
> ---
> 
> Tested on KVM advanced zone
> 
> 
> Thanks,
> 
> John Dilley
> 
>

Re: Review Request 24378: CLOUDSTACK-7268: Ignore "already exists" error in createEgressFirewallRule

[John Dilley]

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

(Updated Aug. 7, 2014, 7:41 a.m.)


Review request for cloudstack and Santhosh Edukulla.


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


Repository: cloudstack-git


Description
---

Although we could search for an existing firewall rule, this fix is simpler, 
and also less prone to race conditions if multiple threads are running.


Diffs (updated)
-

  tools/marvin/marvin/lib/base.py 3a1f7e6 

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


Testing
---

Tested on KVM advanced zone


Thanks,

John Dilley

Re: [VOTE] git workflow

[Sebastien Goasguen]

Here is where we stand:

1-We have a successful VOTE that got derailed after the voting period ended 
with a few -1
-> Since we should have a strong consensus on this that means that the VOTE is 
canned and folks who want a change are send back to the drawing board.

2-The main concerns I can see from the -1 are:
-> No quality control in place so any change in git workflow will not help.
-> Gitflow is for rolling releases and hence no suitable for cloudstack.

Any other concerns ?

3-I would love for us to agree on what is wrong with our current model ? Can 
folks start sharing their (bullet list) thoughts.
-> Master is not stable
-> Too many cherry picks.

Once we agree on what's wrong and what are the main concerns with the proposed 
git workflow, we can start drafting a plan to correct it ?

-Sebastien


On Aug 7, 2014, at 3:38 AM, Sebastien Goasguen  wrote:

> 
> On Aug 6, 2014, at 7:15 PM, David Nalley  wrote:
> 
>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>>  wrote:
>>> Edison, thank you for raising the concern about the BVT/CI. Somebody
>>> mentioned earlier that we should separate git workflow implementation from
>>> the CI effort, but I do think we have to do in in conjunction. Otherwise
>>> what is the point in introducing staging/develop branch? If there is no
>>> daily automation run verifying all the code merged from hotFixes/feature
>>> branches (and possibly reverting wrong checkins), we can as well merge the
>>> code directly to master.
>>> 
>> 
>> Yes! - please.
>> Doing this without CI as a gating factor buys us very little.
>> 
>> --David
> 
> David, can you clarify. Are you going to be against any change of git 
> workflow until we get CI/BVT in place ?
> 

Re: [VOTE] git workflow

[Rohit Yadav]

Hey,

On 07-Aug-2014, at 9:22 am, Leo Simons  wrote:

> On Aug 7, 2014, at 8:40 AM, Animesh Chaturvedi 
>  wrote:
>>> (Like most of the internet...) I strongly believe using cherry picks as the 
>>> basic
>>> tool for (release) branch management is one of the worst choices you can
>>> make.
>>>
>>> But. Please. Can. We. Just. Stop. Cherry. Picking!!! :-D [1]
>>>
>> [Animesh] Leo I don't mind moving to merging branches rather than 
>> cherry-picking for technical reasons, but I am not sure cherry-picking is to 
>> blame entirely. Using it all the time caused the pain.
>
> Yes, I completely agree with that! It was a bit tongue-in-cheek, in fact the 
> joke at the [1] reference...
>
>> [1] ... Using 'git cherry-pick' when there are actual cherries
>> to actually pick is fully endorsed by LSD Enterprises LTD.
>> Picking things other than cherries voids warranty. ...
>
> ...tries to make the same point. I really should stop trying to be funny! 
> More seriously,
>
>
> Use distributed version control.
> Commit early and often. Push often enough.
> Strive for idempotent commits.
> Write good commit messages.
> Ask and give review liberally.
> Keep history though rewriting some of it is ok.
> Branch pre-emptively, except when you are sure you don’t need to.
> Rebase when it is safe to do so.
> Merge deliberately to combine branches.
> Stabilize a branch before you merge from it.
> Merge from the more stable onto the less stable branches.
> Pick cherries from a less stable branch you won’t merge.
> Know your tools.
> Know when to break the rules.

Very well said. May I add a solution to the cherry-picking problem, use a 
baseline protocol:

1. Once a release branch is cut out, all the committers and contributors 
“should” only work on release branch only. Only the new feature development and 
its enhancements/bugfixes should continue to land on master directly or merged 
from their respective branches.

2. The RMs or developers keep merging the release branch with fast forward 
only, this way we don’t have to cherry-pick from master to release branch but 
instead master gets all the good stuff from release branch and the release 
branch gets “more attention”.

3. If we somehow can reduce the release cycle timeline/length, the divergence 
will be less causing less conflicts/issues when following 1 and 2 above.

Thoughts?

Regards.

>
>
> happy hacking,
>
>
> Leo
>

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



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: [DB-CHANGE] Infrastructure tab fails to load with db exception

[Daan Hoogland]

We are but the solution seems to be to complicated for us. I think we
should go to a model of per commit migrations. (and maybe even
downgrades)

Any answer on my sysvm question?

On Thu, Aug 7, 2014 at 6:04 AM, Rajani Karuturi
 wrote:
> Don’t you think we are overlooking the actual problem of handle migrations on 
> the development branch?
>
> ~Rajani
>
>
>
> On 07-Aug-2014, at 12:21 am, Mike Tutkowski  
> wrote:
>
>> Yep, I agree.
>>
>> I guess my point was that a manually created e-mail should still be issued
>> by the developer.
>>
>> On Wednesday, August 6, 2014, Alena Prokharchyk <
>> alena.prokharc...@citrix.com> wrote:
>>
>>> I doubt we can fully automate this one, Mike, for the case when data
>>> migration/modification is involved (.java file is modified in this case).
>>> Only for the changes to .sql files we can automate the instructions. For
>>> data modification, the developer who’s made the changes, still needs to
>>> provide the instructions on the dev list.
>>>
>>> -Alena.
>>>
>>>  From: Mike Tutkowski >> >
>>> Date: Wednesday, August 6, 2014 at 11:33 AM
>>> To: "dev@cloudstack.apache.org
>>> " <
>>> dev@cloudstack.apache.org
>>> >
>>> Cc: Alena Prokharchyk >> >, Koushik
>>> Das >> >
>>> Subject: Re: [DB-CHANGE] Infrastructure tab fails to load with db
>>> exception
>>>
>>> What about the details for updating your DB?
>>>
>>> If we just receive a general e-mail notification, then each dev will
>>> independently have to examine the DB changes to come up with a workaround
>>> to keep his/her current env running properly after a code update.
>>>
>>> On Wednesday, August 6, 2014, Nitin Mehta >> > wrote:
>>>
 Agreed. Added that information in the bug.

 On 06/08/14 11:08 AM, "Alena Prokharchyk" 
 wrote:

> Thank you, Nitin. I think we should add one more item to the things that
> the script checks: modifications to the older upgrade paths shouldn¹t be
> allowed. If we already released 4.4, db upgrade changes should be
 accepted
> only to 4.4-4.5 scripts. If someone makes the changes to, say 4.3-4.4,
 the
> mailing list should be notified, and the changes have to be reverted.
>
> -Alena.
>
> On 8/6/14, 11:03 AM, "Nitin Mehta"  wrote:
>
>> This should be automated. We can't rely on the good intentions of dev.
>> All we need is a script which checks changes in the schema/java Upgrade
>> files and to sends a notification to the dev list.
>> Filed a bug for this -
>> https://issues.apache.org/jira/browse/CLOUDSTACK-7273
>>
>>
>> Thanks,
>> -Nitin
>>
>> On 06/08/14 5:28 AM, "Koushik Das"  wrote:
>>
>>> Thanks Saksham. This fixed the initial issue. But I noticed a new one,
>>> after destroying the last VR if you select the infra view it again
>>> results in exception. Not sure if anything else needs to be fixed.
>>>
>>> -Original Message-
>>> From: Saksham Srivastava [mailto:saksham.srivast...@citrix.com]
>>> Sent: Wednesday, 6 August 2014 3:37 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: [DB-CHANGE] Infrastructure tab fails to load with db exception
>>>
>>> I remember we used to follow the practice of informing others in case
 db
>>> changes are committed, but we do not do it anymore.
>>> In case you are on dev setup on master branch post the following commit
>>> :
>>> commit b9d834e83854009483f6d061f9996e5ffaa9b883
>>> Author: Nitin Mehta 
>>> Date:   Tue Aug 5 17:29:34 2014 -0700
>>> CLOUDSTACK-4200: listSystemVMs API and listRouters API should return
>>> hypervisor property since dynamic scaling is not enabled for all the
>>> hypervisors and that action can be showed only for the hypervisors t
>>>
>>> Update your database with :
>>>
>>> DROP VIEW IF EXISTS `cloud`.`domain_router_view`; CREATE VIEW
>>> `cloud`.`domain_router_view` AS
>>>   select
>>>   vm_instance.id id,
>>>   vm_instance.name name,
>>>   account.id account_id,
>>>   account.uuid account_uuid,
>>>   account.account_name account_name,
>>>   account.type account_type,
>>>   domain.id domain_id,
>>>   domain.uuid domain_uuid,
>>>   domain.name domain_name,
>>>   domain.path domain_path,
>>>   projects.id project_id,
>>>   projects.uuid project_uuid,
>>>   projects.name project_name,
>>>   vm_instance.uuid uuid,
>>>   vm_instance.created created,
>>>   vm_instance.state state,
>>>   vm_instance.removed removed,
>>>   vm_instance.pod_id pod_id,
>>>   vm_instance.instance_name instance_name,
>>>   host_pod_ref.uuid pod_uuid,
>>>   data_center.id data_center_id,
>>>   data_center.uuid data_center_uuid,
>>>   data_center.name data_center_name,
>>>   data_center.networktype data_center_type,
>>>   data_center.dns

Re: [VOTE] git workflow

[Daan Hoogland]

I am not for grand proposals so I don't agree that we should first
make an inventory of all problems. The idea that we are going to do CI
on a staging branch I take for a fact for the moment. Given that I
would like to propose that we:


work on a 'development' branch.
merge on a nightly basis to a stable branch given the status of
'development' is 'passing'
branch release branches as 'x.y' from 'stable'
merge them back to 'stable' when stable and tag them as 'x.y.z'.
branch from 'x.y.z' when support branches need to be made as 'x.y' again
do not merge those back in principle but keep those around for users
to play with and because 'stable' and 'develop' continue


Whether we use gitflow is irrelevant in this. What other changes we do
as well. i.e. git pull instead of review board, using ci on
'development' or other branches.

Is this good enough for a vote?

regards,
Daan


On Thu, Aug 7, 2014 at 10:15 AM, Rohit Yadav  wrote:
> Hey,
>
> On 07-Aug-2014, at 9:22 am, Leo Simons  wrote:
>
>> On Aug 7, 2014, at 8:40 AM, Animesh Chaturvedi 
>>  wrote:
 (Like most of the internet...) I strongly believe using cherry picks as 
 the basic
 tool for (release) branch management is one of the worst choices you can
 make.

 But. Please. Can. We. Just. Stop. Cherry. Picking!!! :-D [1]

>>> [Animesh] Leo I don't mind moving to merging branches rather than 
>>> cherry-picking for technical reasons, but I am not sure cherry-picking is 
>>> to blame entirely. Using it all the time caused the pain.
>>
>> Yes, I completely agree with that! It was a bit tongue-in-cheek, in fact the 
>> joke at the [1] reference...
>>
>>> [1] ... Using 'git cherry-pick' when there are actual cherries
>>> to actually pick is fully endorsed by LSD Enterprises LTD.
>>> Picking things other than cherries voids warranty. ...
>>
>> ...tries to make the same point. I really should stop trying to be funny! 
>> More seriously,
>>
>>
>> Use distributed version control.
>> Commit early and often. Push often enough.
>> Strive for idempotent commits.
>> Write good commit messages.
>> Ask and give review liberally.
>> Keep history though rewriting some of it is ok.
>> Branch pre-emptively, except when you are sure you don’t need to.
>> Rebase when it is safe to do so.
>> Merge deliberately to combine branches.
>> Stabilize a branch before you merge from it.
>> Merge from the more stable onto the less stable branches.
>> Pick cherries from a less stable branch you won’t merge.
>> Know your tools.
>> Know when to break the rules.
>
> Very well said. May I add a solution to the cherry-picking problem, use a 
> baseline protocol:
>
> 1. Once a release branch is cut out, all the committers and contributors 
> “should” only work on release branch only. Only the new feature development 
> and its enhancements/bugfixes should continue to land on master directly or 
> merged from their respective branches.
>
> 2. The RMs or developers keep merging the release branch with fast forward 
> only, this way we don’t have to cherry-pick from master to release branch but 
> instead master gets all the good stuff from release branch and the release 
> branch gets “more attention”.
>
> 3. If we somehow can reduce the release cycle timeline/length, the divergence 
> will be less causing less conflicts/issues when following 1 and 2 above.
>
> Thoughts?
>
> Regards.
>
>>
>>
>> happy hacking,
>>
>>
>> Leo
>>
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> 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 lic

Re: Review Request 24383: CLOUDSTACK-7271: Accept any hypervisor in error message for integration.smoke.test_deploy_vm_root_resize.TestDeployVM.test_00_deploy_vm_root_resize

[ASF Subversion and Git Services]

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


Commit 5f816e3e3fcee259fbdd2153d72625254126ba25 in cloudstack's branch 
refs/heads/master from John Dilley
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5f816e3 ]

CLOUDSTACK-7271: Accept any hypervisor in error message

Signed-off-by: Santhosh Edukulla 


- ASF Subversion and Git Services


On Aug. 6, 2014, 2:57 p.m., John Dilley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24383/
> ---
> 
> (Updated Aug. 6, 2014, 2:57 p.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-7271
> https://issues.apache.org/jira/browse/CLOUDSTACK-7271
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> In test 
> integration.smoke.test_deploy_vm_root_resize.TestDeployVM.test_00_deploy_vm_root_resize,
>  the error message should accept any hypervisor in the error message
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_deploy_vm_root_resize.py 029e7db 
> 
> Diff: https://reviews.apache.org/r/24383/diff/
> 
> 
> Testing
> ---
> 
> Tested on VMWare
> 
> 
> Thanks,
> 
> John Dilley
> 
>

Jenkins build is unstable: simulator-singlerun #72

[jenkins]

See 

[PROPOSAL] Solving the cherry-picking problem

[Rohit Yadav]

Hi,

I think the following can solve the cherry-picking problem but it needs 
everyone’s support to work:

- Once a release branch is cut out, all the committers and contributors 
“should” only work on the release branch. It can be discussed if we want to 
work on it directly or branch out on it and work in that branch and have RMs to 
merge that branch on the release branch. IMO if we work directly on the release 
branch we potentially reduce a lot of RM’s work.

- Only (new) feature development and related enhancements/bugfixes can land on 
master directly or merged from their respective branches.

- The RMs or anyone would keep merging the release branch with fast forward 
only on regular basis:
  git checkout master
  git merge --ff 
  

This way ‘master' gets all the good stuff from release branch and the release 
branch gets “more attention”.

If we somehow can reduce the release cycle timeline/length, the divergence 
between master and release branches can be potentially less causing less 
conflicts/issues when following the above.

Thoughts, flames?

Regards.

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



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: [PROPOSAL] Solving the cherry-picking problem

[Daan Hoogland]

Ah, an even smaller proposal then mine, good.

On Thu, Aug 7, 2014 at 10:39 AM, Rohit Yadav  wrote:
> Hi,
>
> I think the following can solve the cherry-picking problem but it needs 
> everyone’s support to work:
>
> - Once a release branch is cut out, all the committers and contributors 
> “should” only work on the release branch. It can be discussed if we want to 
> work on it directly or branch out on it and work in that branch and have RMs 
> to merge that branch on the release branch. IMO if we work directly on the 
> release branch we potentially reduce a lot of RM’s work.
>
> - Only (new) feature development and related enhancements/bugfixes can land 
> on master directly or merged from their respective branches.
>
> - The RMs or anyone would keep merging the release branch with fast forward 
> only on regular basis:
>   git checkout master
>   git merge --ff 
>   
>
> This way ‘master' gets all the good stuff from release branch and the release 
> branch gets “more attention”.
>
> If we somehow can reduce the release cycle timeline/length, the divergence 
> between master and release branches can be potentially less causing less 
> conflicts/issues when following the above.
>
> Thoughts, flames?
>
> Regards.
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> 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.



-- 
Daan

issues remaining for 4.4.1

[Daan Hoogland]

H,

have a look at 
https://issues.apache.org/jira/browse/CLOUDSTACK-6358?filter=12328007

It is a disappointing 280+ list of issues with 4.4 but I think a lot
of them can be marked as won't solve, future releases or resolved.

Please help me weed through these.

thanks,
-- 
Daan

Re: Review Request 24378: CLOUDSTACK-7268: Ignore "already exists" error in createEgressFirewallRule

[Santhosh Edukulla]

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

Ship it!


Ship It!

- Santhosh Edukulla


On Aug. 7, 2014, 7:41 a.m., John Dilley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24378/
> ---
> 
> (Updated Aug. 7, 2014, 7:41 a.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-7268
> https://issues.apache.org/jira/browse/CLOUDSTACK-7268
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Although we could search for an existing firewall rule, this fix is simpler, 
> and also less prone to race conditions if multiple threads are running.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/lib/base.py 3a1f7e6 
> 
> Diff: https://reviews.apache.org/r/24378/diff/
> 
> 
> Testing
> ---
> 
> Tested on KVM advanced zone
> 
> 
> Thanks,
> 
> John Dilley
> 
>

Re: Review Request 24378: CLOUDSTACK-7268: Ignore "already exists" error in createEgressFirewallRule

[ASF Subversion and Git Services]

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


Commit 7ff7e9cf5ae4d5ababa0bf7e7ccb4a8cb1064045 in cloudstack's branch 
refs/heads/master from John Dilley
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7ff7e9c ]

CLOUDSTACK-7268: Ignore "already exists" error in createEgressFirewallRule

Signed-off-by: Santhosh Edukulla 


- ASF Subversion and Git Services


On Aug. 7, 2014, 7:41 a.m., John Dilley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24378/
> ---
> 
> (Updated Aug. 7, 2014, 7:41 a.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-7268
> https://issues.apache.org/jira/browse/CLOUDSTACK-7268
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Although we could search for an existing firewall rule, this fix is simpler, 
> and also less prone to race conditions if multiple threads are running.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/lib/base.py 3a1f7e6 
> 
> Diff: https://reviews.apache.org/r/24378/diff/
> 
> 
> Testing
> ---
> 
> Tested on KVM advanced zone
> 
> 
> Thanks,
> 
> John Dilley
> 
>

RE: [VOTE] git workflow

[Raja Pullela]

If we are using "Development" branch as a shadow branch for "Stable" - is not 
worth going that route because the existing automation may not find all the 
issues.  As a result, "Stable" is not completely protected from breakage or 
failure.

"Stable" should have the last stable released code.
"Development" should be the release in progress and not a shadow branch for 
"Stable"
There should be merges from "Stable" to "Development"  if there are any 
HOTFIX/Maintenance releases that get released from "Stable" before the 
"Development"/Release in progress goes out
After QA completes testing, "Development" should get into "Stable"
Following the "development" merge into "Stable", cut a "Release" Branch
Any final bug fixes that are absolutely necessary before the Release, will get 
fixed on the "Release" Branch
Release software from the "Release" Branch
After Release, "Release" Branch goes into "Stable"
From then onwards, "Stable" will have the new Release code 

A similar approach was discussed in the wikis/blogs shared by Rajani and Sheng.

Thanks,
Raja
-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
Sent: Thursday, August 07, 2014 2:03 PM
To: dev
Subject: Re: [VOTE] git workflow

I am not for grand proposals so I don't agree that we should first make an 
inventory of all problems. The idea that we are going to do CI on a staging 
branch I take for a fact for the moment. Given that I would like to propose 
that we:


work on a 'development' branch.
merge on a nightly basis to a stable branch given the status of 'development' 
is 'passing'
branch release branches as 'x.y' from 'stable'
merge them back to 'stable' when stable and tag them as 'x.y.z'.
branch from 'x.y.z' when support branches need to be made as 'x.y' again do not 
merge those back in principle but keep those around for users to play with and 
because 'stable' and 'develop' continue 

Whether we use gitflow is irrelevant in this. What other changes we do as well. 
i.e. git pull instead of review board, using ci on 'development' or other 
branches.

Is this good enough for a vote?

regards,
Daan


On Thu, Aug 7, 2014 at 10:15 AM, Rohit Yadav  wrote:
> Hey,
>
> On 07-Aug-2014, at 9:22 am, Leo Simons  wrote:
>
>> On Aug 7, 2014, at 8:40 AM, Animesh Chaturvedi 
>>  wrote:
 (Like most of the internet...) I strongly believe using cherry 
 picks as the basic tool for (release) branch management is one of 
 the worst choices you can make.

 But. Please. Can. We. Just. Stop. Cherry. Picking!!! :-D [1]

>>> [Animesh] Leo I don't mind moving to merging branches rather than 
>>> cherry-picking for technical reasons, but I am not sure cherry-picking is 
>>> to blame entirely. Using it all the time caused the pain.
>>
>> Yes, I completely agree with that! It was a bit tongue-in-cheek, in fact the 
>> joke at the [1] reference...
>>
>>> [1] ... Using 'git cherry-pick' when there are actual cherries to 
>>> actually pick is fully endorsed by LSD Enterprises LTD.
>>> Picking things other than cherries voids warranty. ...
>>
>> ...tries to make the same point. I really should stop trying to be 
>> funny! More seriously,
>>
>>
>> Use distributed version control.
>> Commit early and often. Push often enough.
>> Strive for idempotent commits.
>> Write good commit messages.
>> Ask and give review liberally.
>> Keep history though rewriting some of it is ok.
>> Branch pre-emptively, except when you are sure you don’t need to.
>> Rebase when it is safe to do so.
>> Merge deliberately to combine branches.
>> Stabilize a branch before you merge from it.
>> Merge from the more stable onto the less stable branches.
>> Pick cherries from a less stable branch you won’t merge.
>> Know your tools.
>> Know when to break the rules.
>
> Very well said. May I add a solution to the cherry-picking problem, use a 
> baseline protocol:
>
> 1. Once a release branch is cut out, all the committers and contributors 
> “should” only work on release branch only. Only the new feature development 
> and its enhancements/bugfixes should continue to land on master directly or 
> merged from their respective branches.
>
> 2. The RMs or developers keep merging the release branch with fast forward 
> only, this way we don’t have to cherry-pick from master to release branch but 
> instead master gets all the good stuff from release branch and the release 
> branch gets “more attention”.
>
> 3. If we somehow can reduce the release cycle timeline/length, the divergence 
> will be less causing less conflicts/issues when following 1 and 2 above.
>
> Thoughts?
>
> Regards.
>
>>
>>
>> happy hacking,
>>
>>
>> Leo
>>
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related 
> services
>
> IaaS Cloud Design & 
> Build
> CSForge – rapid Ia

Re: [VOTE] git workflow

[Daan Hoogland]

Raja,

On Thu, Aug 7, 2014 at 11:03 AM, Raja Pullela  wrote:
> If we are using "Development" branch as a shadow branch for "Stable" - is not 
> worth going that route because the existing automation may not find all the 
> issues.  As a result, "Stable" is not completely protected from breakage or 
> failure.
>
> "Stable" should have the last stable released code.
> "Development" should be the release in progress and not a shadow branch for 
> "Stable"
> There should be merges from "Stable" to "Development"  if there are any 
> HOTFIX/Maintenance releases that get released from "Stable" before the 
> "Development"/Release in progress goes out
> After QA completes testing, "Development" should get into "Stable"
> Following the "development" merge into "Stable", cut a "Release" Branch
> Any final bug fixes that are absolutely necessary before the Release, will 
> get fixed on the "Release" Branch
> Release software from the "Release" Branch
> After Release, "Release" Branch goes into "Stable"
> From then onwards, "Stable" will have the new Release code

I could read your response both as a +1 and as a counter proposal.
What is your point? We do not protect our users against breakage
completely now and we will not in the future. Is your point that we
should only change to something if that completely protects us from
all failure?

> A similar approach was discussed in the wikis/blogs shared by Rajani and 
> Sheng.
Yes, and...

can we,
> work on a 'development' branch.
> merge on a nightly basis to a stable branch given the status of 'development' 
> is 'passing'
> branch release branches as 'x.y' from 'stable'
> merge them back to 'stable' when stable and tag them as 'x.y.z'.
> branch from 'x.y.z' when support branches need to be made as 'x.y' again do 
> not merge those back in principle but keep those around for users to play 
> with and because 'stable' and 'develop' continue 


-- 
Daan

Re: [PROPOSAL] Solving the cherry-picking problem

[Rajani Karuturi]

Hi Rohit,
Thanks for the proposal.

I do not agree to the third point that RM should keep merging to master. We
could do that at the end of the release with a single merge.

That said, its definitely better than what we currently do and hence a +1
from me.



On Thu, Aug 7, 2014 at 2:09 PM, Rohit Yadav 
wrote:

> Hi,
>
> I think the following can solve the cherry-picking problem but it needs
> everyone’s support to work:
>
> - Once a release branch is cut out, all the committers and contributors
> “should” only work on the release branch. It can be discussed if we want to
> work on it directly or branch out on it and work in that branch and have
> RMs to merge that branch on the release branch. IMO if we work directly on
> the release branch we potentially reduce a lot of RM’s work.
>
> - Only (new) feature development and related enhancements/bugfixes can
> land on master directly or merged from their respective branches.
>
> - The RMs or anyone would keep merging the release branch with fast
> forward only on regular basis:
>   git checkout master
>   git merge --ff 
>   
>
> This way ‘master' gets all the good stuff from release branch and the
> release branch gets “more attention”.
>
> If we somehow can reduce the release cycle timeline/length, the divergence
> between master and release branches can be potentially less causing less
> conflicts/issues when following the above.
>
> Thoughts, flames?
>
> Regards.
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
>
> 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.
>



-- 
~Rajani

Jenkins build is still unstable: simulator-singlerun #73

[jenkins]

See 

Re: [PROPOSAL] Solving the cherry-picking problem

[Rohit Yadav]

On 07-Aug-2014, at 11:23 am, Rajani Karuturi  wrote:

> Hi Rohit,
> Thanks for the proposal.
>
> I do not agree to the third point that RM should keep merging to master. We
> could do that at the end of the release with a single merge.

By landing changes from release to master, we get continuous supply of bugfixes 
etc. to master since master will need them as well. And we do that at the time 
of release as well.

>From technical view, there is nothing wrong in landing changes from stable 
>branches to master and feature branches continuously.

> That said, its definitely better than what we currently do and hence a +1
> from me.

This is not a voting thread yet but thanks for your comments.

Cheers.

>
>
>
> On Thu, Aug 7, 2014 at 2:09 PM, Rohit Yadav 
> wrote:
>
>> Hi,
>>
>> I think the following can solve the cherry-picking problem but it needs
>> everyone’s support to work:
>>
>> - Once a release branch is cut out, all the committers and contributors
>> “should” only work on the release branch. It can be discussed if we want to
>> work on it directly or branch out on it and work in that branch and have
>> RMs to merge that branch on the release branch. IMO if we work directly on
>> the release branch we potentially reduce a lot of RM’s work.
>>
>> - Only (new) feature development and related enhancements/bugfixes can
>> land on master directly or merged from their respective branches.
>>
>> - The RMs or anyone would keep merging the release branch with fast
>> forward only on regular basis:
>>  git checkout master
>>  git merge --ff 
>>  
>>
>> This way ‘master' gets all the good stuff from release branch and the
>> release branch gets “more attention”.
>>
>> If we somehow can reduce the release cycle timeline/length, the divergence
>> between master and release branches can be potentially less causing less
>> conflicts/issues when following the above.
>>
>> Thoughts, flames?
>>
>> Regards.
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +41 779015219 | rohit.ya...@shapeblue.com
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design & Build<
>> http://shapeblue.com/iaas-cloud-design-and-build//>
>> CSForge – rapid IaaS deployment framework
>> CloudStack Consulting
>> CloudStack Infrastructure Support<
>> http://shapeblue.com/cloudstack-infrastructure-support/>
>> CloudStack Bootcamp Training Courses<
>> http://shapeblue.com/cloudstack-training/>
>>
>> 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.
>>
>
>
>
> --
> ~Rajani

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



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

Re: [PROPOSAL] Solving the cherry-picking problem

[Rajani Karuturi]

On Thu, Aug 7, 2014 at 3:09 PM, Rohit Yadav 
wrote:

>
> On 07-Aug-2014, at 11:23 am, Rajani Karuturi  wrote:
>
> > Hi Rohit,
> > Thanks for the proposal.
> >
> > I do not agree to the third point that RM should keep merging to master.
> We
> > could do that at the end of the release with a single merge.
>
> By landing changes from release to master, we get continuous supply of
> bugfixes etc. to master since master will need them as well. And we do that
> at the time of release as well.
>
> From technical view, there is nothing wrong in landing changes from stable
> branches to master and feature branches continuously.
>


the change flow is right from stable to master. But, I am worried it may
add to RM's load again. Since master is under active development, it may
lead to merge conflicts.



>
> > That said, its definitely better than what we currently do and hence a +1
> > from me.
>
> This is not a voting thread yet but thanks for your comments.
>

oops.. ;)
-- 
~Rajani

Jenkins build is still unstable: simulator-singlerun #74

[jenkins]

See 

RE: [VOTE] git workflow

[Raja Pullela]

Daan,  

+1 for having stable master branch wherein we bring only tested "development" 
branches into master.  
-1 against having a shadow branches to stable/master and pushing changes into 
stable based on just CI test runs.  I agree it is better than what we have 
currently.  But does not solve/address the stability issue completely.

Thanks,
Raja
-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
Sent: Thursday, August 07, 2014 2:46 PM
To: dev
Subject: Re: [VOTE] git workflow

Raja,

On Thu, Aug 7, 2014 at 11:03 AM, Raja Pullela  wrote:
> If we are using "Development" branch as a shadow branch for "Stable" - is not 
> worth going that route because the existing automation may not find all the 
> issues.  As a result, "Stable" is not completely protected from breakage or 
> failure.
>
> "Stable" should have the last stable released code.
> "Development" should be the release in progress and not a shadow branch for 
> "Stable"
> There should be merges from "Stable" to "Development"  if there are 
> any HOTFIX/Maintenance releases that get released from "Stable" before the 
> "Development"/Release in progress goes out After QA completes testing, 
> "Development" should get into "Stable"
> Following the "development" merge into "Stable", cut a "Release" 
> Branch Any final bug fixes that are absolutely necessary before the 
> Release, will get fixed on the "Release" Branch Release software from 
> the "Release" Branch After Release, "Release" Branch goes into "Stable"
> From then onwards, "Stable" will have the new Release code

I could read your response both as a +1 and as a counter proposal.
What is your point? We do not protect our users against breakage completely now 
and we will not in the future. Is your point that we should only change to 
something if that completely protects us from all failure?

> A similar approach was discussed in the wikis/blogs shared by Rajani and 
> Sheng.
Yes, and...

can we,
> work on a 'development' branch.
> merge on a nightly basis to a stable branch given the status of 'development' 
> is 'passing'
> branch release branches as 'x.y' from 'stable'
> merge them back to 'stable' when stable and tag them as 'x.y.z'.
> branch from 'x.y.z' when support branches need to be made as 'x.y' 
> again do not merge those back in principle but keep those around for 
> users to play with and because 'stable' and 'develop' continue 
> 


--
Daan

[DISCUSS] reviewer process guide amended

[Daan Hoogland]

Folks

please look at the following

Fixing things for folks

In short, please don't. If non-committers have a patch 95% of the way
- comment and tell them what is necessary to make the patch
acceptable. Let them fix their own patch and resubmit. Yes you can
probably fix things more quickly, but it's important for community
growth (both in number and experience) that folks do this themselves.

from the wiki. I think this is not good enough to guarantee quality
and growth for our community. It is mentioned under a chapter called
'Words of wisdom'.

I think we will not invite people to become part of our community if
we tell them how to do their work. We should help them, yes but in a
more constructive way. You can suggest a piece of code if you see
something you don't like or even supply them with an altered patch as
a proposal to change their review request.

If we follow the above literally I think we drive people away. I have
seen this happen to colleagues but also to others that were trying to
substantially contribute. Our way of working hinders us in the sense
of attracting good development power and an important objective of
this project should be to have more contributors of (good) code.

thoughts?
-- 
Daan

Jenkins build is still unstable: simulator-singlerun #75

[jenkins]

See 

GRE Tunnel can not decapsulate and forward pkts

[Michael Li]

Hi all,
I have used CS4.4+OVS for GRE tunnel tests,
Use two hosts: host1 and host2
create vm1 on host1, vm2 on host2, VR is created on host1
Result:
OVSTunnel117 is created on host1 and host2 with gre port and options remote_ip, 
this is the expectation result
But vm2 can not be assigned ip by VR
After I assigned the ip and route to this vm2 manually, ping from vm1 on host1 
to vm2 on host2
the pkts have been encapsulated and forward to host2's OVSTunnel117, but not 
decapsulate and forward out to vnet10 which is connected to vm2.
Has anyone met this issue ? Is the flow entries in OVS installed automatically ?

Thanks

GRE Tunnel can not decapsulate and forward pkts

[Michael Li]

Hi all,
I have used CS4.4+OVS for GRE tunnel tests,
Use two hosts: host1 and host2
create vm1 on host1, vm2 on host2, VR is created on host1
Result:
OVSTunnel117 is created on host1 and host2 with gre port and options remote_ip, 
this is the expectation result
But vm2 can not be assigned ip by VR
After I assigned the ip and route to this vm2 manually, ping from vm1 on host1 
to vm2 on host2
the pkts have been encapsulated and forward to host2's OVSTunnel117, but not 
decapsulate and forward out to vnet10 which is connected to vm2.
Has anyone met this issue ? Is the flow entries in OVS installed automatically ?

Thanks

Re: [VOTE] git workflow

[David Nalley]

On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen  wrote:
>
> On Aug 6, 2014, at 7:15 PM, David Nalley  wrote:
>
>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>>  wrote:
>>> Edison, thank you for raising the concern about the BVT/CI. Somebody
>>> mentioned earlier that we should separate git workflow implementation from
>>> the CI effort, but I do think we have to do in in conjunction. Otherwise
>>> what is the point in introducing staging/develop branch? If there is no
>>> daily automation run verifying all the code merged from hotFixes/feature
>>> branches (and possibly reverting wrong checkins), we can as well merge the
>>> code directly to master.
>>>
>>
>> Yes! - please.
>> Doing this without CI as a gating factor buys us very little.
>>
>> --David
>
> David, can you clarify. Are you going to be against any change of git 
> workflow until we get CI/BVT in place ?
>

No, please don't take it that way.
I understand Leo's point about Cherry-picking being for fruit, and not
code. But, I don't think that the workflow changes I've seen proposed
affect quality. So shifting for quality's sake doesn't make a lot of
sense in my mind. They could be a component of fixing the quality
problem.

--David

Re: [PROPOSAL] Solving the cherry-picking problem

[David Nalley]

On Thu, Aug 7, 2014 at 4:39 AM, Rohit Yadav  wrote:
> Hi,
>
> I think the following can solve the cherry-picking problem but it needs 
> everyone’s support to work:
>
> - Once a release branch is cut out, all the committers and contributors 
> “should” only work on the release branch. It can be discussed if we want to 
> work on it directly or branch out on it and work in that branch and have RMs 
> to merge that branch on the release branch. IMO if we work directly on the 
> release branch we potentially reduce a lot of RM’s work.
>
> - Only (new) feature development and related enhancements/bugfixes can land 
> on master directly or merged from their respective branches.
>
> - The RMs or anyone would keep merging the release branch with fast forward 
> only on regular basis:
>   git checkout master
>   git merge --ff 
>   
>
> This way ‘master' gets all the good stuff from release branch and the release 
> branch gets “more attention”.
>
> If we somehow can reduce the release cycle timeline/length, the divergence 
> between master and release branches can be potentially less causing less 
> conflicts/issues when following the above.
>
> Thoughts, flames?

Hi Rohit:

Help me understand some of the dynamics here:

Folks focus on the release branch while trying to get a release out.
Does that prohibit work being done on release+1 (e.g. pushing work to
develop that didn't make it in to a release by feature freeze?)

--David

Re: [PROPOSAL] Solving the cherry-picking problem

[Harikrishna Patnala]

Hi Rohit,
Thanks for the proposal.

I’ve some concerns.
If we work directly on release branch only (with out forward branch) I’m not 
sure how we control regressions in the release time. 

In case of forward branch cut from the release branch RMs will merge only 
critical bug fixes to release branch, where do the non-critical bug fixes go 
into ? according to your 2nd statement minor/major bug fixes remain in forward 
branch only.

Thanks,
Harikrishna

On 07-Aug-2014, at 2:09 pm, Rohit Yadav  wrote:

> Hi,
> 
> I think the following can solve the cherry-picking problem but it needs 
> everyone’s support to work:
> 
> - Once a release branch is cut out, all the committers and contributors 
> “should” only work on the release branch. It can be discussed if we want to 
> work on it directly or branch out on it and work in that branch and have RMs 
> to merge that branch on the release branch. IMO if we work directly on the 
> release branch we potentially reduce a lot of RM’s work.
> 
> - Only (new) feature development and related enhancements/bugfixes can land 
> on master directly or merged from their respective branches.
> 
> - The RMs or anyone would keep merging the release branch with fast forward 
> only on regular basis:
>  git checkout master
>  git merge --ff 
>  
> 
> This way ‘master' gets all the good stuff from release branch and the release 
> branch gets “more attention”.
> 
> If we somehow can reduce the release cycle timeline/length, the divergence 
> between master and release branches can be potentially less causing less 
> conflicts/issues when following the above.
> 
> Thoughts, flames?
> 
> Regards.
> 
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
> 
> 
> 
> 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 4.4.1

[Xerex Bueno]

Is 4.4.0 more reliable/stable than 4.3?




On 8/6/14, 3:54 AM, "Daan Hoogland"  wrote:

>People,
>
>Since there are some problems in 4.4.0 I am planning a bugfix release.
>
>I created a wiki page for it. This only contains dates so far. I am
>offline starting the 16th so I want to have it out by the 14th,
>optimist that I am. For this to happen a successful RC must be
>available by the 10th. This is maybe a tight schedule but I hope
>everybody is putting their full attention to having a viable 4.4 out
>there.
>
>Please add any important info to
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.4.1+Bu
>gFix+Release
>
>Thanks
>--
>Daan




This document is PROPRIETARY and CONFIDENTIAL and may not be duplicated, 
redistributed, or displayed to any other party without the expressed written 
permission of LPS Integration, Inc. If you are not the intended recipient and 
have received this email in error, please destroy the email and contact the LPS 
Integration Security Officer at 866-577-2902 (Phone), 615-349-9009 (Fax) or 230 
Great Circle Rd. Suite 218 Nashville, TN 37228 (US Mail)

Re: [PROPOSAL] Solving the cherry-picking problem

[Daan Hoogland]

Hari,

if we merge we can no longer distinguish between minor and trivial or
major till block. And we shouldn't as we validate any staging branch
periodically before merging.

On Thu, Aug 7, 2014 at 2:51 PM, Harikrishna Patnala
 wrote:
> Hi Rohit,
> Thanks for the proposal.
>
> I’ve some concerns.
> If we work directly on release branch only (with out forward branch) I’m not 
> sure how we control regressions in the release time.
>
> In case of forward branch cut from the release branch RMs will merge only 
> critical bug fixes to release branch, where do the non-critical bug fixes go 
> into ? according to your 2nd statement minor/major bug fixes remain in 
> forward branch only.
>
> Thanks,
> Harikrishna
>
> On 07-Aug-2014, at 2:09 pm, Rohit Yadav  wrote:
>
>> Hi,
>>
>> I think the following can solve the cherry-picking problem but it needs 
>> everyone’s support to work:
>>
>> - Once a release branch is cut out, all the committers and contributors 
>> “should” only work on the release branch. It can be discussed if we want to 
>> work on it directly or branch out on it and work in that branch and have RMs 
>> to merge that branch on the release branch. IMO if we work directly on the 
>> release branch we potentially reduce a lot of RM’s work.
>>
>> - Only (new) feature development and related enhancements/bugfixes can land 
>> on master directly or merged from their respective branches.
>>
>> - The RMs or anyone would keep merging the release branch with fast forward 
>> only on regular basis:
>>  git checkout master
>>  git merge --ff 
>>  
>>
>> This way ‘master' gets all the good stuff from release branch and the 
>> release branch gets “more attention”.
>>
>> If we somehow can reduce the release cycle timeline/length, the divergence 
>> between master and release branches can be potentially less causing less 
>> conflicts/issues when following the above.
>>
>> Thoughts, flames?
>>
>> Regards.
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +41 779015219 | rohit.ya...@shapeblue.com
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>
>>
>> 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.
>



-- 
Daan

Re: [ACS44] release 4.4.1

[Daan Hoogland]

depends on what you are using Xerex.

Not for KVM it seems and there are some problems with the xen sytemvm.

On Thu, Aug 7, 2014 at 2:55 PM, Xerex Bueno  wrote:
> Is 4.4.0 more reliable/stable than 4.3?
>
>
>
>
> On 8/6/14, 3:54 AM, "Daan Hoogland"  wrote:
>
>>People,
>>
>>Since there are some problems in 4.4.0 I am planning a bugfix release.
>>
>>I created a wiki page for it. This only contains dates so far. I am
>>offline starting the 16th so I want to have it out by the 14th,
>>optimist that I am. For this to happen a successful RC must be
>>available by the 10th. This is maybe a tight schedule but I hope
>>everybody is putting their full attention to having a viable 4.4 out
>>there.
>>
>>Please add any important info to
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.4.1+Bu
>>gFix+Release
>>
>>Thanks
>>--
>>Daan
>
>
> 
>
> This document is PROPRIETARY and CONFIDENTIAL and may not be duplicated, 
> redistributed, or displayed to any other party without the expressed written 
> permission of LPS Integration, Inc. If you are not the intended recipient and 
> have received this email in error, please destroy the email and contact the 
> LPS Integration Security Officer at 866-577-2902 (Phone), 615-349-9009 (Fax) 
> or 230 Great Circle Rd. Suite 218 Nashville, TN 37228 (US Mail)
>



-- 
Daan

Re: [PROPOSAL] Solving the cherry-picking problem

[Rohit Yadav]

Hi David,

On 07-Aug-2014, at 2:37 pm, David Nalley  wrote:

> On Thu, Aug 7, 2014 at 4:39 AM, Rohit Yadav  wrote:
>> Hi,
>>
>> I think the following can solve the cherry-picking problem but it needs 
>> everyone’s support to work:
>>
>> - Once a release branch is cut out, all the committers and contributors 
>> “should” only work on the release branch. It can be discussed if we want to 
>> work on it directly or branch out on it and work in that branch and have RMs 
>> to merge that branch on the release branch. IMO if we work directly on the 
>> release branch we potentially reduce a lot of RM’s work.
>>
>> - Only (new) feature development and related enhancements/bugfixes can land 
>> on master directly or merged from their respective branches.
>>
>> - The RMs or anyone would keep merging the release branch with fast forward 
>> only on regular basis:
>>  git checkout master
>>  git merge --ff 
>>  
>>
>> This way ‘master' gets all the good stuff from release branch and the 
>> release branch gets “more attention”.
>>
>> If we somehow can reduce the release cycle timeline/length, the divergence 
>> between master and release branches can be potentially less causing less 
>> conflicts/issues when following the above.
>>
>> Thoughts, flames?
>
> Hi Rohit:
>
> Help me understand some of the dynamics here:
>
> Folks focus on the release branch while trying to get a release out.
> Does that prohibit work being done on release+1 (e.g. pushing work to
> develop that didn't make it in to a release by feature freeze?)

Yes, people can work on master branch and commit/merge their feature branches 
after the release branch is cut out for stuff that did not make into a release 
by the freeze. Note, in such a workflow people should only do bugfixing and 
smaller enhancement on the release branch.

Therefore, master will become independent of the release (branch) and continue 
to get new stuff, while release branch gets only bugfixes and enhancements 
(such as packaging fixes etc.).

When we merge fast-forward (by —ff it won’t create any merge commit) from 
release branch to master it may lead to conflicts since people will land/merge 
their features (that did not make into release) so we fix it.  By doing this 
process frequently we can fix smaller conflicts instead of one big conflict at 
the end when we graduate the release branch to a release.

The protocol is simple — You fix on release branch first, test it and commit on 
release branch, your changes land on master eventually by a fast forward merge 
on master.

What do you think about having this?

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



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.

[ACS44] help on 4.4.1 wanted

[Daan Hoogland]

H all,

There are 6 issues marked as fixVersion 4.4.1 but also 106 with
affectedVersion 4.4.0. Can all of you please weed through those/help
triage them. I feel like I am alone in the desert and at the same time
looking at a forest from between the trees, i.e. helpless

Please help me get something out that is an improvement on the current
state of things?
-- 
Daan

Re: [PROPOSAL] Solving the cherry-picking problem

[Rohit Yadav]

Hi Hari,

You’ve a valid concern, but on master when we’re pushing bugfixes for multiple 
issues the RM eventually picks them to release branch anyway.

At the end of the day, usage of automated tests, build/unit tests will ensure 
some quality control. This proposal will solve issues for RM (the cherry-pick 
and losing commits ones) and it does not do much about code quality or control.

To get it working:
- During codefreeze, a contributor should not slip in half baked features and 
use bugfix as an excuse to finish/fix the feature
- On the release branch you work first, fix/commit only bug/fixes and release 
specific enhancements (such as docs, config files, scripts, packaging etc.)
- Master branch is free and you can do wild development, merge your feature 
branch that did not went in release etc. but you merge —fast-forward the 
release branch on it often (couple of times a day is recommended), fix 
conflicts and carry on

Cheers.

On 07-Aug-2014, at 2:51 pm, Harikrishna Patnala 
 wrote:

> Hi Rohit,
> Thanks for the proposal.
>
> I’ve some concerns.
> If we work directly on release branch only (with out forward branch) I’m not 
> sure how we control regressions in the release time.
>
> In case of forward branch cut from the release branch RMs will merge only 
> critical bug fixes to release branch, where do the non-critical bug fixes go 
> into ? according to your 2nd statement minor/major bug fixes remain in 
> forward branch only.
>
> Thanks,
> Harikrishna
>
> On 07-Aug-2014, at 2:09 pm, Rohit Yadav  wrote:
>
>> Hi,
>>
>> I think the following can solve the cherry-picking problem but it needs 
>> everyone’s support to work:
>>
>> - Once a release branch is cut out, all the committers and contributors 
>> “should” only work on the release branch. It can be discussed if we want to 
>> work on it directly or branch out on it and work in that branch and have RMs 
>> to merge that branch on the release branch. IMO if we work directly on the 
>> release branch we potentially reduce a lot of RM’s work.
>>
>> - Only (new) feature development and related enhancements/bugfixes can land 
>> on master directly or merged from their respective branches.
>>
>> - The RMs or anyone would keep merging the release branch with fast forward 
>> only on regular basis:
>> git checkout master
>> git merge --ff 
>> 
>>
>> This way ‘master' gets all the good stuff from release branch and the 
>> release branch gets “more attention”.
>>
>> If we somehow can reduce the release cycle timeline/length, the divergence 
>> between master and release branches can be potentially less causing less 
>> conflicts/issues when following the above.
>>
>> Thoughts, flames?
>>
>> Regards.
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +41 779015219 | rohit.ya...@shapeblue.com
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>
>>
>> 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.
>

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



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

RE: issues remaining for 4.4.1

[Simon Weller]

Daan,

I have a patch in reviewboard for CLOUDSTACK-6460. 

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

- Si

From: Daan Hoogland 
Sent: Thursday, August 07, 2014 3:53 AM
To: dev
Subject: issues remaining for 4.4.1

H,

have a look at 
https://issues.apache.org/jira/browse/CLOUDSTACK-6358?filter=12328007

It is a disappointing 280+ list of issues with 4.4 but I think a lot
of them can be marked as won't solve, future releases or resolved.

Please help me weed through these.

thanks,
--
Daan

Re: [VOTE] git workflow

[Tracy Phillips]

Alena,

Check this out and see if it would resolve your concern regarding
maintaining multiple releases

http://stackoverflow.com/questions/16562339/git-flow-and-master-with-multiple-parallel-release-branches

git-flow uses support branches to support releases that are not on master.





On Wed, Aug 6, 2014 at 6:28 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

>
>
> On 8/6/14, 3:18 PM, "Sebastien Goasguen"  wrote:
>
> >[top posting, apologies in advance]
> >
> >I am on vacation, so I will go straight to it :)
> >
> >This all discussion is not about gitflow specifically, it is about
> >modifying our git workflow and our commit practices to something more
> >standard that can:
> >
> >- ultimately help improve quality (in itself it won't but it can help lay
> >a foundation)
> >- provide a stable master (it keeps breaking, it has regressions, it
> >moves really fast etc..)
> >- help cut releases
> >
> >Any committer has write privileges and can do whatever it wants to the
> >repos, so we need to get a nice big consensus on what problems we are
> >trying to solve, and how best to get there. So let's not make this a
> >debate of yeah or neah gitflow.
> >
> >A better CI is coming but it's not yet there and we have no ETA. Even
> >with a CI infra in place, we will need commit discipline to improve
> >quality (covertity, unitests, simulator tests). Changing our git commit
> >practices has no cost (just emails and self discipline), so can we agree
> >to do that first ?
> >
> >Here are couple high level things that I have in mind ( and I confess I
> >have not read the entire threads on this yet and ti ma conflict with
> >gitflow).
> >
> >-Master: what goes in master is only something that has been put into a
> >release (aside from the maintenance releases fixes maybe...). Master is
> >the base for any release branch (until we get to 4.5, master will still
> >see some high churn to stabilize it, after 4.5 release branch is cut we
> >should enter into a stable master mode).
>
>
> Sebastian, we can’t adopt this particular high level thing - when master
> reflects the latest stable release with the tags for all previous releases
> - because support maintenance releases for multiple CS versions in
> parallel. And while master’s latest version is 4.4, 4.2.1 and 4.3.1 can be
> released. And there is no way to merge them back to master w/o breaking
> the branch history.
>
> The model when master reflects the latest released branch, can be used for
> the systems with rolling upgrades only, no maintenance releases for
> previous versions of the software.
>
> To get more details, please read the latest email exchange (today’s) on
> git workflow between me/Rohit and Dave Nalley.
>
>
>
> >
> >-Release: from the time a release branch is cut, features are only merged
> >by RM. hot fixes are only merged by RM. the RM is responsible for the
> >entire release process. Since he defines the scope and is the primary
> >person responsible to check BVT for the release branch he should be able
> >to release on-time. Major release gets merged back into master.
> >
> >-Devs: folks working on features and fixes are responsible to merge into
> >the develop branch and call the RM for a merge into a release branch
> >(this may vary with gitflow, where release branch is cut from develop)
> >
> >Once we have CI, it should run on every branch.
> >
> >-sebastien
> >
> >
> >On Aug 6, 2014, at 5:36 PM, Alena Prokharchyk
> > wrote:
> >
> >> Edison, thank you for raising the concern about the BVT/CI. Somebody
> >> mentioned earlier that we should separate git workflow implementation
> >>from
> >> the CI effort, but I do think we have to do in in conjunction. Otherwise
> >> what is the point in introducing staging/develop branch? If there is no
> >> daily automation run verifying all the code merged from hotFixes/feature
> >> branches (and possibly reverting wrong checkins), we can as well merge
> >>the
> >> code directly to master.
> >>
> >> -Alena.
> >>
> >> On 8/6/14, 2:30 PM, "Edison Su"  wrote:
> >>
> >>>
> >>>
>  -Original Message-
>  From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
>  Sent: Wednesday, August 06, 2014 12:59 PM
>  To: dev@cloudstack.apache.org
>  Subject: Re: [VOTE] git workflow
> 
> 
> 
>  On 8/6/14, 12:52 PM, "Erik Weber"  wrote:
> 
> > On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
> > alena.prokharc...@citrix.com> wrote:
> >
> >> Agree with you, Rohit. The changes to the git model we use, are
> >> needed  indeed. But we should address only the problems that CS
> >>faces,
> >> and the  main problem - quality control. The proposal should be
> >> limited just to the  changes that are really needed for the CS, and
> >> that will work with the  current CS model (minor maintenance
> >>releases
> >> support is a part of it)
> >>
> >>
> >
> > Theoretically you don't really have to change anything 

RE: issues remaining for 4.4.1

[Daan Hoogland]

Will look at it tomorow at the latest

biligual spelling checker used.read at your own risk
Op 7 aug. 2014 15:32 schreef "Simon Weller" :

> Daan,
>
> I have a patch in reviewboard for CLOUDSTACK-6460.
>
> https://reviews.apache.org/r/22939/
>
> - Si
> 
> From: Daan Hoogland 
> Sent: Thursday, August 07, 2014 3:53 AM
> To: dev
> Subject: issues remaining for 4.4.1
>
> H,
>
> have a look at
> https://issues.apache.org/jira/browse/CLOUDSTACK-6358?filter=12328007
>
> It is a disappointing 280+ list of issues with 4.4 but I think a lot
> of them can be marked as won't solve, future releases or resolved.
>
> Please help me weed through these.
>
> thanks,
> --
> Daan

Re: [ACS44] release 4.4.1

[Andrei Mikhailovsky]

Daan, apart from the template issues, which I believe were already solved, are 
there any other issues with KVM that might prevent one to upgrade?

I was planning to upgrade this this weekend, but are now considering postponing 
the upgrade.

Thanks



-- 
Andrei Mikhailovsky
Director
Arhont Information Security

Web: http://www.arhont.com
http://www.wi-foo.com
Tel: +44 (0)870 4431337
Fax: +44 (0)208 429 3111
PGP: Key ID - 0x2B3438DE
PGP: Server - keyserver.pgp.com

DISCLAIMER

The information contained in this email is intended only for the use of the 
person(s) to whom it is addressed and may be confidential or contain legally 
privileged information. If you are not the intended recipient you are hereby 
notified that any perusal, use, distribution, copying or disclosure is strictly 
prohibited. If you have received this email in error please immediately advise 
us by return email at and...@arhont.com and delete and purge the email and any 
attachments without making a copy.


- Original Message -
From: "Daan Hoogland" 
To: "dev" 
Cc: us...@cloudstack.apache.org
Sent: Thursday, 7 August, 2014 1:58:45 PM
Subject: Re: [ACS44] release 4.4.1

depends on what you are using Xerex.

Not for KVM it seems and there are some problems with the xen sytemvm.

On Thu, Aug 7, 2014 at 2:55 PM, Xerex Bueno  wrote:
> Is 4.4.0 more reliable/stable than 4.3?
>
>
>
>
> On 8/6/14, 3:54 AM, "Daan Hoogland"  wrote:
>
>>People,
>>
>>Since there are some problems in 4.4.0 I am planning a bugfix release.
>>
>>I created a wiki page for it. This only contains dates so far. I am
>>offline starting the 16th so I want to have it out by the 14th,
>>optimist that I am. For this to happen a successful RC must be
>>available by the 10th. This is maybe a tight schedule but I hope
>>everybody is putting their full attention to having a viable 4.4 out
>>there.
>>
>>Please add any important info to
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.4.1+Bu
>>gFix+Release
>>
>>Thanks
>>--
>>Daan
>
>
> 
>
> This document is PROPRIETARY and CONFIDENTIAL and may not be duplicated, 
> redistributed, or displayed to any other party without the expressed written 
> permission of LPS Integration, Inc. If you are not the intended recipient and 
> have received this email in error, please destroy the email and contact the 
> LPS Integration Security Officer at 866-577-2902 (Phone), 615-349-9009 (Fax) 
> or 230 Great Circle Rd. Suite 218 Nashville, TN 37228 (US Mail)
>



-- 
Daan

Re: FreeBSD

[mo]

I am using Cloudstack 4.4 | FreeBSD 9.3, however, choosing other 64-bit and 
installing the 64-bit of FreeBSD 10 or 9.3 hangs at boot. 


-- 
mo
Sent with Airmail

On August 7, 2014 at 11:45:57 AM, Osay Osman Yuuni (oyu...@gmail.com) wrote:

"... currently testing CS 4.4 with XenServer, although I am concern about  
license with XenServer ... "  
Motty what do you mean by license issue? Aside from being able to use  
XenCentre for patch management I believe you don't need any license for  
Xenserver. Been using Xenserver 6.2 on CS 4.3 with all patches done via  
command line and it's working swell.  


On 7 August 2014 12:56, Shanker Balan  wrote:  

> Comments inline.  
>  
> On 06-Aug-2014, at 12:09 am, mo  wrote:  
>  
> > Odd, 32-bit worked without issue. I wonder why this is Anyone have any  
> input on why it’s  
> > next to impossible to spin up a 64-bit FreeBSD?  
> >  
>  
> Perhaps, you could rephrase the above statement to mention your specific  
> FreeBSD version  
> as not working as expected? :P  
>  
> FreeBSD 10 and -CURRENT are working just fine on my ACS 4.3 setup on  
> XenServer.  
> I use the “other” os-type.  
>  
>   
>  
> --  
> @shankerbalan  
>  
> M: +91 98860 60539 | O: +91 (80) 67935867  
> shanker.ba...@shapeblue.com | www.shapeblue.com | Twitter:@shapeblue  
> ShapeBlue Services India LLP, 22nd floor, Unit 2201A, World Trade Centre,  
> Bangalore - 560 055  
>  
> Find out more about ShapeBlue and our range of CloudStack related services  
>  
> IaaS Cloud Design & Build<  
> http://shapeblue.com/iaas-cloud-design-and-build//>  
> CSForge – rapid IaaS deployment framework  
> CloudStack Consulting  
> CloudStack Infrastructure Support<  
> http://shapeblue.com/cloudstack-infrastructure-support/>  
> CloudStack Bootcamp Training Courses<  
> http://shapeblue.com/cloudstack-training/>  
>  
> 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: [VOTE] git workflow

[Nate Gordon]

I'm not sure what to think about this discussion any more. But in response
to Sebastien's request for thoughts I was originally very excited about a
git-flow solution because of some very specific things:

* Create a branch for everything. This is amazingly useful for a number of
reasons:

** It supports better CI in the future, specifically build per branch.
Committing directly to a shared branch with CI is not the same thing. I see
great utility in running CI *twice* for every change coming in. Once in
isolation, and again once it is merged in with the rest of the community
work. This enables you to validate that your code is good before subjecting
others to it, and isolates regression testing to just that. It gets much
more difficult to determine if the problem is basic logic in your code or a
regression somewhere else when you don't isolate the changes.

** It encourages people to not force others to deal with something that
isn't completely done or tested, but allows them to still have frequent
commits and share through the central repo. Any time you modify a shared
branch you should be extremely confident that what you have done will only
be a positive impact on the others using that branch. If something breaks,
you are potentially disrupting the work of a large number of other people
in the process. Internally we follow a strict branch and peer review
process for every change. As much as I would like to propose a strict peer
review process for all changes, I have a feeling that it would get even
more pushback than this proposal. I also want to highlight the force part
of my statement. If your change breaks something unrelated to my code, and
now I have to go fix that so that I can get back to what I was originally
doing, I have no choice but to deal with that breakage and am probably very
angry because of that.

* The release process happens in parallel to active development. By using a
release branch to work through QA, testing, bugfixes you enable that work
to happen independent of anything else happening in the code base. I
realize that we already have this process in place for the most part, I
just wanted to highlight that it is something we are already doing in some
form and get to keep doing.

* A stable branch is maintained that only contains code that has been
through a release process. I understand the desire for a nightly process
that merges code from dev to stable, but what is this solving that CI on
all of the branches wouldn't solve? It also assumes that the CI process is
perfect and that all new code has extensive unit/integration tests. Both of
these should be true, but rarely are in the real world and are nowhere
close in today's ACS environment and will take a long time to fix. I also
don't see the momentum to accomplish this in the very near term, so it
feels a bit like we are betting on the the weather a month from now to save
us.

I also realize that git-flow isn't a perfect match for how this community
works, but rolling releases versus maintenance releases doesn't seem major
enough to drop the entire thing. It is fairly easy to have a
maintenance/support branch for older releases that lives on forever once it
is needed. You can also merge any two arbitrary items in git. It might not
be the cleanest merge, but you can merge the maintenance branch into master
once the release of the maintenance branch is done. You could treat it much
like a new release or development branch that comes from master instead of
develop. If this didn't work, long running branches would never work in git.

The TLDR proposal:

* Always make a branch for everything
* Have a branch that is only released code. Not just stable and CI tested,
released.
* Have a development branch where features that haven't been through a
release process can branch from and land when complete
* Use a release branch to move all changes from development to stable to
isolate testing, QA, and release bugfixes
* Create a maintenance branch from the release tag in master once a
maintenance release is needed

I don't care if we call it git-flow, I just liked that it provided a basic
framework from which we could operate and extend.

Thanks,

-Nate


On Thu, Aug 7, 2014 at 8:39 AM, Tracy Phillips 
wrote:

> Alena,
>
> Check this out and see if it would resolve your concern regarding
> maintaining multiple releases
>
>
> http://stackoverflow.com/questions/16562339/git-flow-and-master-with-multiple-parallel-release-branches
>
> git-flow uses support branches to support releases that are not on master.
>
>
>
>
>
> On Wed, Aug 6, 2014 at 6:28 PM, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
>
> >
> >
> > On 8/6/14, 3:18 PM, "Sebastien Goasguen"  wrote:
> >
> > >[top posting, apologies in advance]
> > >
> > >I am on vacation, so I will go straight to it :)
> > >
> > >This all discussion is not about gitflow specifically, it is about
> > >modifying our git workflow and our commit practices to something more
> > >standard tha

Jenkins build is still unstable: simulator-singlerun #76

[jenkins]

See 

List APIs Behavior

[Gaurav Aradhye]

I want to understand the output of the list APIs when the entity is not
present / deleted. Suppose I create an account, create a network within it
and acquire a public IP address in the network.

1) ListPublicIpAddresses  - public ip id passed, returns public IP
2) ListPublicIpAddresses - account, domainid passed, returns public IP

Now I delete the public IP (Disassociate).

After this operation, I expect following results:
1) ListPublicIpAddreses - account,domain id passed, result: None (assuming
there was only one)
2) ListPublicIpAddresses - public ip id passed, I expect exception here
because the id must have been removed from DB. But I get "None" as result
here.

If I get None, then can I assume that id is still present in DB but it is
marked as obsolete?

When can I expect an exception in return? And when can I expect None?
Ideally, when we search by Id, then exception should be thrown and when we
expect by passing account/domainid/projectid/networkid etc, then None
should be returned. Do all List APIs follow a similar guideline?

Regards,
Gaurav

Re: [VOTE] git workflow

[Alena Prokharchyk]

Not quite. That’s what the article suggests:

"If you want to fix bugs for older releases or do any other develop there,
you will fork a support branch from the appropriate commit in master (you
will have all versions ever created there). These branches are just
started and not intended to be merged back to master nor develop. This is
usually fine, as fixes to "ancient" releases or features requested by
customers to be implemented in "ancient" releases can't or should not go
back into master. If you still think, you want to port a fix to your main
development line (represented by master and develop), just start a hotfix,
cherry-pick your changes and finish the hotfix."


That doesn’t seem right to me - that NOT ALL the fixes done to 4.2.1/4.3.1
maintenance releases for example, will go back to master/develop? Plus it
suggests “cherry-picking” stuff if we decide that some fixes worth being
back ported. Cherry-picking again? :) Defeats our cherry-pick witch hunt
purpose. I think ALL fixes done to any forked branch, should make it into
master via merge.


On 8/7/14, 6:39 AM, "Tracy Phillips"  wrote:

>Alena,
>
>Check this out and see if it would resolve your concern regarding
>maintaining multiple releases
>
>http://stackoverflow.com/questions/16562339/git-flow-and-master-with-multi
>ple-parallel-release-branches
>
>git-flow uses support branches to support releases that are not on master.
>
>
>
>
>
>On Wed, Aug 6, 2014 at 6:28 PM, Alena Prokharchyk <
>alena.prokharc...@citrix.com> wrote:
>
>>
>>
>> On 8/6/14, 3:18 PM, "Sebastien Goasguen"  wrote:
>>
>> >[top posting, apologies in advance]
>> >
>> >I am on vacation, so I will go straight to it :)
>> >
>> >This all discussion is not about gitflow specifically, it is about
>> >modifying our git workflow and our commit practices to something more
>> >standard that can:
>> >
>> >- ultimately help improve quality (in itself it won't but it can help
>>lay
>> >a foundation)
>> >- provide a stable master (it keeps breaking, it has regressions, it
>> >moves really fast etc..)
>> >- help cut releases
>> >
>> >Any committer has write privileges and can do whatever it wants to the
>> >repos, so we need to get a nice big consensus on what problems we are
>> >trying to solve, and how best to get there. So let's not make this a
>> >debate of yeah or neah gitflow.
>> >
>> >A better CI is coming but it's not yet there and we have no ETA. Even
>> >with a CI infra in place, we will need commit discipline to improve
>> >quality (covertity, unitests, simulator tests). Changing our git commit
>> >practices has no cost (just emails and self discipline), so can we
>>agree
>> >to do that first ?
>> >
>> >Here are couple high level things that I have in mind ( and I confess I
>> >have not read the entire threads on this yet and ti ma conflict with
>> >gitflow).
>> >
>> >-Master: what goes in master is only something that has been put into a
>> >release (aside from the maintenance releases fixes maybe...). Master is
>> >the base for any release branch (until we get to 4.5, master will still
>> >see some high churn to stabilize it, after 4.5 release branch is cut we
>> >should enter into a stable master mode).
>>
>>
>> Sebastian, we can’t adopt this particular high level thing - when master
>> reflects the latest stable release with the tags for all previous
>>releases
>> - because support maintenance releases for multiple CS versions in
>> parallel. And while master’s latest version is 4.4, 4.2.1 and 4.3.1 can
>>be
>> released. And there is no way to merge them back to master w/o breaking
>> the branch history.
>>
>> The model when master reflects the latest released branch, can be used
>>for
>> the systems with rolling upgrades only, no maintenance releases for
>> previous versions of the software.
>>
>> To get more details, please read the latest email exchange (today’s) on
>> git workflow between me/Rohit and Dave Nalley.
>>
>>
>>
>> >
>> >-Release: from the time a release branch is cut, features are only
>>merged
>> >by RM. hot fixes are only merged by RM. the RM is responsible for the
>> >entire release process. Since he defines the scope and is the primary
>> >person responsible to check BVT for the release branch he should be
>>able
>> >to release on-time. Major release gets merged back into master.
>> >
>> >-Devs: folks working on features and fixes are responsible to merge
>>into
>> >the develop branch and call the RM for a merge into a release branch
>> >(this may vary with gitflow, where release branch is cut from develop)
>> >
>> >Once we have CI, it should run on every branch.
>> >
>> >-sebastien
>> >
>> >
>> >On Aug 6, 2014, at 5:36 PM, Alena Prokharchyk
>> > wrote:
>> >
>> >> Edison, thank you for raising the concern about the BVT/CI. Somebody
>> >> mentioned earlier that we should separate git workflow implementation
>> >>from
>> >> the CI effort, but I do think we have to do in in conjunction.
>>Otherwise
>> >> what is the point in introducing staging/develop branch? I

Re: [PROPOSAL] Solving the cherry-picking problem

[Min Chen]

Hi Rohit,

IMHO, the root cause for RM cherry-pick problem is code quality. Without
solving that first based on some kind of enforcement, this will not help
much. The reason to use forward branch and RM cherry-picking is to control
what can go to release branch. Your proposal removed that part, then I am
not sure how you can guarantee a quality release.

Thanks
-min

On 8/7/14 6:06 AM, "Rohit Yadav"  wrote:

>Hi Hari,
>
>You¹ve a valid concern, but on master when we¹re pushing bugfixes for
>multiple issues the RM eventually picks them to release branch anyway.
>
>At the end of the day, usage of automated tests, build/unit tests will
>ensure some quality control. This proposal will solve issues for RM (the
>cherry-pick and losing commits ones) and it does not do much about code
>quality or control.
>
>To get it working:
>- During codefreeze, a contributor should not slip in half baked features
>and use bugfix as an excuse to finish/fix the feature
>- On the release branch you work first, fix/commit only bug/fixes and
>release specific enhancements (such as docs, config files, scripts,
>packaging etc.)
>- Master branch is free and you can do wild development, merge your
>feature branch that did not went in release etc. but you merge
>‹fast-forward the release branch on it often (couple of times a day is
>recommended), fix conflicts and carry on
>
>Cheers.
>
>On 07-Aug-2014, at 2:51 pm, Harikrishna Patnala
> wrote:
>
>> Hi Rohit,
>> Thanks for the proposal.
>>
>> I¹ve some concerns.
>> If we work directly on release branch only (with out forward branch)
>>I¹m not sure how we control regressions in the release time.
>>
>> In case of forward branch cut from the release branch RMs will merge
>>only critical bug fixes to release branch, where do the non-critical bug
>>fixes go into ? according to your 2nd statement minor/major bug fixes
>>remain in forward branch only.
>>
>> Thanks,
>> Harikrishna
>>
>> On 07-Aug-2014, at 2:09 pm, Rohit Yadav 
>>wrote:
>>
>>> Hi,
>>>
>>> I think the following can solve the cherry-picking problem but it
>>>needs everyone¹s support to work:
>>>
>>> - Once a release branch is cut out, all the committers and
>>>contributors ³should² only work on the release branch. It can be
>>>discussed if we want to work on it directly or branch out on it and
>>>work in that branch and have RMs to merge that branch on the release
>>>branch. IMO if we work directly on the release branch we potentially
>>>reduce a lot of RM¹s work.
>>>
>>> - Only (new) feature development and related enhancements/bugfixes can
>>>land on master directly or merged from their respective branches.
>>>
>>> - The RMs or anyone would keep merging the release branch with fast
>>>forward only on regular basis:
>>> git checkout master
>>> git merge --ff 
>>> 
>>>
>>> This way Œmaster' gets all the good stuff from release branch and the
>>>release branch gets ³more attention².
>>>
>>> If we somehow can reduce the release cycle timeline/length, the
>>>divergence between master and release branches can be potentially less
>>>causing less conflicts/issues when following the above.
>>>
>>> Thoughts, flames?
>>>
>>> Regards.
>>>
>>> Regards,
>>> Rohit Yadav
>>> Software Architect, ShapeBlue
>>> M. +41 779015219 | rohit.ya...@shapeblue.com
>>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>>
>>>
>>>
>>> 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.
>>
>
>Regards,
>Rohit Yadav
>Software Architect, ShapeBlue
>M. +41 779015219 | rohit.ya...@shapeblue.com
>Blog: bhaisa

Re: [VOTE] git workflow

[Alena Prokharchyk]

Plus if you read the discussion below the article, you will see that
people agree that this model doesn’t work well for the case when the
product support maintenance for older releases, like CS does.

"I think this model does not work for bugfixing in older releases, though.
It messes up the neat ordering.

1. Say we have released Version 1.0.1 and later added features and
released 1.1.0.
2. We discover a bug in 1.0.1 and want to fix it in both version
3. We have to add 1.0.2 after 1.1.0 in master and then directly atfer (or
before) also 1.1.1.”


Thanks,
Alena.

On 8/7/14, 10:19 AM, "Alena Prokharchyk" 
wrote:

>Not quite. That’s what the article suggests:
>
>"If you want to fix bugs for older releases or do any other develop there,
>you will fork a support branch from the appropriate commit in master (you
>will have all versions ever created there). These branches are just
>started and not intended to be merged back to master nor develop. This is
>usually fine, as fixes to "ancient" releases or features requested by
>customers to be implemented in "ancient" releases can't or should not go
>back into master. If you still think, you want to port a fix to your main
>development line (represented by master and develop), just start a hotfix,
>cherry-pick your changes and finish the hotfix."
>
>
>That doesn’t seem right to me - that NOT ALL the fixes done to 4.2.1/4.3.1
>maintenance releases for example, will go back to master/develop? Plus it
>suggests “cherry-picking” stuff if we decide that some fixes worth being
>back ported. Cherry-picking again? :) Defeats our cherry-pick witch hunt
>purpose. I think ALL fixes done to any forked branch, should make it into
>master via merge.
>
>
>On 8/7/14, 6:39 AM, "Tracy Phillips"  wrote:
>
>>Alena,
>>
>>Check this out and see if it would resolve your concern regarding
>>maintaining multiple releases
>>
>>http://stackoverflow.com/questions/16562339/git-flow-and-master-with-mult
>>i
>>ple-parallel-release-branches
>>
>>git-flow uses support branches to support releases that are not on
>>master.
>>
>>
>>
>>
>>
>>On Wed, Aug 6, 2014 at 6:28 PM, Alena Prokharchyk <
>>alena.prokharc...@citrix.com> wrote:
>>
>>>
>>>
>>> On 8/6/14, 3:18 PM, "Sebastien Goasguen"  wrote:
>>>
>>> >[top posting, apologies in advance]
>>> >
>>> >I am on vacation, so I will go straight to it :)
>>> >
>>> >This all discussion is not about gitflow specifically, it is about
>>> >modifying our git workflow and our commit practices to something more
>>> >standard that can:
>>> >
>>> >- ultimately help improve quality (in itself it won't but it can help
>>>lay
>>> >a foundation)
>>> >- provide a stable master (it keeps breaking, it has regressions, it
>>> >moves really fast etc..)
>>> >- help cut releases
>>> >
>>> >Any committer has write privileges and can do whatever it wants to the
>>> >repos, so we need to get a nice big consensus on what problems we are
>>> >trying to solve, and how best to get there. So let's not make this a
>>> >debate of yeah or neah gitflow.
>>> >
>>> >A better CI is coming but it's not yet there and we have no ETA. Even
>>> >with a CI infra in place, we will need commit discipline to improve
>>> >quality (covertity, unitests, simulator tests). Changing our git
>>>commit
>>> >practices has no cost (just emails and self discipline), so can we
>>>agree
>>> >to do that first ?
>>> >
>>> >Here are couple high level things that I have in mind ( and I confess
>>>I
>>> >have not read the entire threads on this yet and ti ma conflict with
>>> >gitflow).
>>> >
>>> >-Master: what goes in master is only something that has been put into
>>>a
>>> >release (aside from the maintenance releases fixes maybe...). Master
>>>is
>>> >the base for any release branch (until we get to 4.5, master will
>>>still
>>> >see some high churn to stabilize it, after 4.5 release branch is cut
>>>we
>>> >should enter into a stable master mode).
>>>
>>>
>>> Sebastian, we can’t adopt this particular high level thing - when
>>>master
>>> reflects the latest stable release with the tags for all previous
>>>releases
>>> - because support maintenance releases for multiple CS versions in
>>> parallel. And while master’s latest version is 4.4, 4.2.1 and 4.3.1 can
>>>be
>>> released. And there is no way to merge them back to master w/o breaking
>>> the branch history.
>>>
>>> The model when master reflects the latest released branch, can be used
>>>for
>>> the systems with rolling upgrades only, no maintenance releases for
>>> previous versions of the software.
>>>
>>> To get more details, please read the latest email exchange (today’s) on
>>> git workflow between me/Rohit and Dave Nalley.
>>>
>>>
>>>
>>> >
>>> >-Release: from the time a release branch is cut, features are only
>>>merged
>>> >by RM. hot fixes are only merged by RM. the RM is responsible for the
>>> >entire release process. Since he defines the scope and is the primary
>>> >person responsible to check BVT for the release branch he should be
>>>able
>>> >t

Re: [DB-CHANGE] Infrastructure tab fails to load with db exception

[Mike Tutkowski]

That is true. It was not my intent to address that problem, though. I was
simply commenting on the question of whether we should continue to use the
[DB-CHANGE] e-mail tag (I believe we should).


On Wed, Aug 6, 2014 at 10:04 PM, Rajani Karuturi  wrote:

> Don’t you think we are overlooking the actual problem of handle migrations
> on the development branch?
>
> ~Rajani
>
>
>
> On 07-Aug-2014, at 12:21 am, Mike Tutkowski 
> wrote:
>
> > Yep, I agree.
> >
> > I guess my point was that a manually created e-mail should still be
> issued
> > by the developer.
> >
> > On Wednesday, August 6, 2014, Alena Prokharchyk <
> > alena.prokharc...@citrix.com> wrote:
> >
> >> I doubt we can fully automate this one, Mike, for the case when data
> >> migration/modification is involved (.java file is modified in this
> case).
> >> Only for the changes to .sql files we can automate the instructions. For
> >> data modification, the developer who’s made the changes, still needs to
> >> provide the instructions on the dev list.
> >>
> >> -Alena.
> >>
> >>  From: Mike Tutkowski  >> >
> >> Date: Wednesday, August 6, 2014 at 11:33 AM
> >> To: "dev@cloudstack.apache.org
> >> " <
> >> dev@cloudstack.apache.org
> >> >
> >> Cc: Alena Prokharchyk  >> >,
> Koushik
> >> Das  >> >
> >> Subject: Re: [DB-CHANGE] Infrastructure tab fails to load with db
> >> exception
> >>
> >> What about the details for updating your DB?
> >>
> >> If we just receive a general e-mail notification, then each dev will
> >> independently have to examine the DB changes to come up with a
> workaround
> >> to keep his/her current env running properly after a code update.
> >>
> >> On Wednesday, August 6, 2014, Nitin Mehta  >> > wrote:
> >>
> >>> Agreed. Added that information in the bug.
> >>>
> >>> On 06/08/14 11:08 AM, "Alena Prokharchyk" <
> alena.prokharc...@citrix.com>
> >>> wrote:
> >>>
>  Thank you, Nitin. I think we should add one more item to the things
> that
>  the script checks: modifications to the older upgrade paths shouldn¹t
> be
>  allowed. If we already released 4.4, db upgrade changes should be
> >>> accepted
>  only to 4.4-4.5 scripts. If someone makes the changes to, say 4.3-4.4,
> >>> the
>  mailing list should be notified, and the changes have to be reverted.
> 
>  -Alena.
> 
>  On 8/6/14, 11:03 AM, "Nitin Mehta"  wrote:
> 
> > This should be automated. We can't rely on the good intentions of
> dev.
> > All we need is a script which checks changes in the schema/java
> Upgrade
> > files and to sends a notification to the dev list.
> > Filed a bug for this -
> > https://issues.apache.org/jira/browse/CLOUDSTACK-7273
> >
> >
> > Thanks,
> > -Nitin
> >
> > On 06/08/14 5:28 AM, "Koushik Das"  wrote:
> >
> >> Thanks Saksham. This fixed the initial issue. But I noticed a new
> one,
> >> after destroying the last VR if you select the infra view it again
> >> results in exception. Not sure if anything else needs to be fixed.
> >>
> >> -Original Message-
> >> From: Saksham Srivastava [mailto:saksham.srivast...@citrix.com]
> >> Sent: Wednesday, 6 August 2014 3:37 PM
> >> To: dev@cloudstack.apache.org
> >> Subject: [DB-CHANGE] Infrastructure tab fails to load with db
> exception
> >>
> >> I remember we used to follow the practice of informing others in
> case
> >>> db
> >> changes are committed, but we do not do it anymore.
> >> In case you are on dev setup on master branch post the following
> commit
> >> :
> >> commit b9d834e83854009483f6d061f9996e5ffaa9b883
> >> Author: Nitin Mehta 
> >> Date:   Tue Aug 5 17:29:34 2014 -0700
> >> CLOUDSTACK-4200: listSystemVMs API and listRouters API should return
> >> hypervisor property since dynamic scaling is not enabled for all the
> >> hypervisors and that action can be showed only for the hypervisors t
> >>
> >> Update your database with :
> >>
> >> DROP VIEW IF EXISTS `cloud`.`domain_router_view`; CREATE VIEW
> >> `cloud`.`domain_router_view` AS
> >>   select
> >>   vm_instance.id id,
> >>   vm_instance.name name,
> >>   account.id account_id,
> >>   account.uuid account_uuid,
> >>   account.account_name account_name,
> >>   account.type account_type,
> >>   domain.id domain_id,
> >>   domain.uuid domain_uuid,
> >>   domain.name domain_name,
> >>   domain.path domain_path,
> >>   projects.id project_id,
> >>   projects.uuid project_uuid,
> >>   projects.name project_name,
> >>   vm_instance.uuid uuid,
> >>   vm_instance.created created,
> >>   vm_instance.state state,
> >>   vm_instance.removed removed,
> >>   vm_instance.pod_id pod_id,
> >>   vm_instance.instance_name instance_name,
> >>   host_pod_ref.uuid pod_uuid,
> >>   data_center.id data_cent

Jenkins build is still unstable: simulator-singlerun #77

[jenkins]

See 

Re: [PROPOSAL] Solving the cherry-picking problem

[Rohit Yadav]

Hi Min,

On 07-Aug-2014, at 7:22 pm, Min Chen  wrote:

> Hi Rohit,
>
> IMHO, the root cause for RM cherry-pick problem is code quality. Without
> solving that first based on some kind of enforcement, this will not help
> much. The reason to use forward branch and RM cherry-picking is to control
> what can go to release branch. Your proposal removed that part, then I am
> not sure how you can guarantee a quality release.

Please read the initial proposal and subject again, IMHO you can never 
guarantee code/commit quality.

This is to address the sync issue, from release branch to master and have 
people give more attention to release branch.
This is followed by a lot of companies such as fb, google, perforce etc.
Please search about “baseline protocol” and “tofu scale” to know more.

TL;DR -- “commit first on release branch, use merge --fast-forward  over 
cherry-picking”.

Cheers.

>
> Thanks
> -min
>
> On 8/7/14 6:06 AM, "Rohit Yadav"  wrote:
>
>> Hi Hari,
>>
>> You¹ve a valid concern, but on master when we¹re pushing bugfixes for
>> multiple issues the RM eventually picks them to release branch anyway.
>>
>> At the end of the day, usage of automated tests, build/unit tests will
>> ensure some quality control. This proposal will solve issues for RM (the
>> cherry-pick and losing commits ones) and it does not do much about code
>> quality or control.
>>
>> To get it working:
>> - During codefreeze, a contributor should not slip in half baked features
>> and use bugfix as an excuse to finish/fix the feature
>> - On the release branch you work first, fix/commit only bug/fixes and
>> release specific enhancements (such as docs, config files, scripts,
>> packaging etc.)
>> - Master branch is free and you can do wild development, merge your
>> feature branch that did not went in release etc. but you merge
>> ‹fast-forward the release branch on it often (couple of times a day is
>> recommended), fix conflicts and carry on
>>
>> Cheers.
>>
>> On 07-Aug-2014, at 2:51 pm, Harikrishna Patnala
>>  wrote:
>>
>>> Hi Rohit,
>>> Thanks for the proposal.
>>>
>>> I¹ve some concerns.
>>> If we work directly on release branch only (with out forward branch)
>>> I¹m not sure how we control regressions in the release time.
>>>
>>> In case of forward branch cut from the release branch RMs will merge
>>> only critical bug fixes to release branch, where do the non-critical bug
>>> fixes go into ? according to your 2nd statement minor/major bug fixes
>>> remain in forward branch only.
>>>
>>> Thanks,
>>> Harikrishna
>>>
>>> On 07-Aug-2014, at 2:09 pm, Rohit Yadav 
>>> wrote:
>>>
 Hi,

 I think the following can solve the cherry-picking problem but it
 needs everyone¹s support to work:

 - Once a release branch is cut out, all the committers and
 contributors ³should² only work on the release branch. It can be
 discussed if we want to work on it directly or branch out on it and
 work in that branch and have RMs to merge that branch on the release
 branch. IMO if we work directly on the release branch we potentially
 reduce a lot of RM¹s work.

 - Only (new) feature development and related enhancements/bugfixes can
 land on master directly or merged from their respective branches.

 - The RMs or anyone would keep merging the release branch with fast
 forward only on regular basis:
git checkout master
git merge --ff 


 This way Œmaster' gets all the good stuff from release branch and the
 release branch gets ³more attention².

 If we somehow can reduce the release cycle timeline/length, the
 divergence between master and release branches can be potentially less
 causing less conflicts/issues when following the above.

 Thoughts, flames?

 Regards.

 Regards,
 Rohit Yadav
 Software Architect, ShapeBlue
 M. +41 779015219 | rohit.ya...@shapeblue.com
 Blog: bhaisaab.org | Twitter: @_bhaisaab



 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 

Unable to add host exception

[Elapavuluri, Jaya]

I am trying to add a KVM host on to the Management server. However, I am 
getting an error while adding the host. It says unable to add the host.

The log at the management server says:
Discovery exception
error code list for exceptions
WARN  [o.a.c.a.c.a.h.AddHostCmd] (1690201491@qtp-794886538-14:ctx-7544e509 
ctx-fc750325) Exception:
com.cloud.exception.DiscoveryException: Unable to add the host
   at 
com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:791)
   at 
com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces

The log at the KVM host says:
2014-08-07 09:55:57,600 INFO  [utils.nio.NioClient] (Agent-Selector:null) 
Connecting to 192.168.182.149:8250
2014-08-07 09:57:00,600 WARN  [utils.nio.NioConnection] (Agent-Selector:null) 
Unable to connect to remote: is there a server running on port 8250
2014-08-07 09:57:05,601 INFO  [utils.nio.NioClient] (Agent-Selector:null) 
Connecting to 192.168.182.149:8250
2014-08-07 09:58:08,618 WARN  [utils.nio.NioConnection] (Agent-Selector:null) 
Unable to connect to remote: is there a server running on port 8250
2014-08-07 09:58:13,619 INFO  [utils.nio.NioClient] (Agent-Selector:null) 
Connecting to 192.168.182.149:8250
2014-08-07 09:59:16,630 WARN  [utils.nio.NioConnection] (Agent-Selector:null) 
Unable to connect to remote: is there a server running on port 8250
2014-08-07 09:59:21,631 INFO  [utils.nio.NioClient] (Agent-Selector:null) 
Connecting to 192.168.182.149:8250

Can someone give an insight into this?

Re: Unable to add host exception

[Erik Weber]

Is there a firewall between?

Check that mgmt server listen on port 8250 and that the kvm host can
connect to it

Erik
7. aug. 2014 20:44 skrev "Elapavuluri, Jaya" 
følgende:

> I am trying to add a KVM host on to the Management server. However, I am
> getting an error while adding the host. It says unable to add the host.
>
> The log at the management server says:
> Discovery exception
> error code list for exceptions
> WARN  [o.a.c.a.c.a.h.AddHostCmd] (1690201491@qtp-794886538-14:ctx-7544e509
> ctx-fc750325) Exception:
> com.cloud.exception.DiscoveryException: Unable to add the host
>at
> com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:791)
>at
> com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
>
> The log at the KVM host says:
> 2014-08-07 09:55:57,600 INFO  [utils.nio.NioClient] (Agent-Selector:null)
> Connecting to 192.168.182.149:8250
> 2014-08-07 09:57:00,600 WARN  [utils.nio.NioConnection]
> (Agent-Selector:null) Unable to connect to remote: is there a server
> running on port 8250
> 2014-08-07 09:57:05,601 INFO  [utils.nio.NioClient] (Agent-Selector:null)
> Connecting to 192.168.182.149:8250
> 2014-08-07 09:58:08,618 WARN  [utils.nio.NioConnection]
> (Agent-Selector:null) Unable to connect to remote: is there a server
> running on port 8250
> 2014-08-07 09:58:13,619 INFO  [utils.nio.NioClient] (Agent-Selector:null)
> Connecting to 192.168.182.149:8250
> 2014-08-07 09:59:16,630 WARN  [utils.nio.NioConnection]
> (Agent-Selector:null) Unable to connect to remote: is there a server
> running on port 8250
> 2014-08-07 09:59:21,631 INFO  [utils.nio.NioClient] (Agent-Selector:null)
> Connecting to 192.168.182.149:8250
>
> Can someone give an insight into this?
>

Re: Unable to add host exception

[Amogh Vasekar]

Firewall may be?
Can you telnet to the mentioned IP and port?

Amogh

On 8/7/14 11:43 AM, "Elapavuluri, Jaya" 
wrote:

>I am trying to add a KVM host on to the Management server. However, I am
>getting an error while adding the host. It says unable to add the host.
>
>The log at the management server says:
>Discovery exception
>error code list for exceptions
>WARN  [o.a.c.a.c.a.h.AddHostCmd]
>(1690201491@qtp-794886538-14:ctx-7544e509 ctx-fc750325) Exception:
>com.cloud.exception.DiscoveryException: Unable to add the host
>   at 
>com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerIm
>pl.java:791)
>   at 
>com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.j
>ava:586)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>Method)
>   at 
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
>57)
>   at 
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
>
>The log at the KVM host says:
>2014-08-07 09:55:57,600 INFO  [utils.nio.NioClient] (Agent-Selector:null)
>Connecting to 192.168.182.149:8250
>2014-08-07 09:57:00,600 WARN  [utils.nio.NioConnection]
>(Agent-Selector:null) Unable to connect to remote: is there a server
>running on port 8250
>2014-08-07 09:57:05,601 INFO  [utils.nio.NioClient] (Agent-Selector:null)
>Connecting to 192.168.182.149:8250
>2014-08-07 09:58:08,618 WARN  [utils.nio.NioConnection]
>(Agent-Selector:null) Unable to connect to remote: is there a server
>running on port 8250
>2014-08-07 09:58:13,619 INFO  [utils.nio.NioClient] (Agent-Selector:null)
>Connecting to 192.168.182.149:8250
>2014-08-07 09:59:16,630 WARN  [utils.nio.NioConnection]
>(Agent-Selector:null) Unable to connect to remote: is there a server
>running on port 8250
>2014-08-07 09:59:21,631 INFO  [utils.nio.NioClient] (Agent-Selector:null)
>Connecting to 192.168.182.149:8250
>
>Can someone give an insight into this?

[GSoC] End of second term approaching

[Darren Brogan]

Hi all,

With the second term of GSOC coming to an end I thought I'd update you on
what I've been doing since my last email.

Ec2stack user profiles can now be configured / used in a similar way to
gstack. You can configure a profile of your choice with the optional -p or
--profile flag at configuration time.

$ ec2stack-configure -p exampleprofile

And run ec2stack with that profile configuration.

$ ec2stack -p exampleprofile

Ec2stack now has support for VPC operations. CreateVpc, DeleteVpc &
DescribeVpc actions were all added. To be able to use VPC actions ec2stack
will have to be configured with an advanced zone.

$ ec2stack-configure -a True

Snapshot support is being worked on on a branch called snapshot_support[1],
this should be completed shortly.

In terms of gstack, it was modified to allow it to work with the latest
release of the google_cloud_sdk. This means the setup of gstack will be
slightly different than it used to be. Check out the user guide[2] on the
wiki for more information.

[1] https://github.com/BroganD1993/ec2stack/tree/snapshot_support
[2] https://github.com/NOPping/gstack/wiki/User-Guide

If you have any questions about either ec2stack or gstack don't hesitate
get in touch.

Thanks,
Darren

RE: Unable to add host exception

[Elapavuluri, Jaya]

I think it was the problem with the firewall. 

-Original Message-
From: Amogh Vasekar [mailto:amogh.vase...@citrix.com] 
Sent: Thursday, August 07, 2014 3:00 PM
To: dev@cloudstack.apache.org
Subject: Re: Unable to add host exception

Firewall may be?
Can you telnet to the mentioned IP and port?

Amogh

On 8/7/14 11:43 AM, "Elapavuluri, Jaya" 
wrote:

>I am trying to add a KVM host on to the Management server. However, I 
>am getting an error while adding the host. It says unable to add the host.
>
>The log at the management server says:
>Discovery exception
>error code list for exceptions
>WARN  [o.a.c.a.c.a.h.AddHostCmd]
>(1690201491@qtp-794886538-14:ctx-7544e509 ctx-fc750325) Exception:
>com.cloud.exception.DiscoveryException: Unable to add the host
>   at
>com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManage
>rIm
>pl.java:791)
>   at
>com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImp
>l.j
>ava:586)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>Method)
>   at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
>57)
>   at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
>
>The log at the KVM host says:
>2014-08-07 09:55:57,600 INFO  [utils.nio.NioClient] 
>(Agent-Selector:null) Connecting to 192.168.182.149:8250
>2014-08-07 09:57:00,600 WARN  [utils.nio.NioConnection]
>(Agent-Selector:null) Unable to connect to remote: is there a server 
>running on port 8250
>2014-08-07 09:57:05,601 INFO  [utils.nio.NioClient] 
>(Agent-Selector:null) Connecting to 192.168.182.149:8250
>2014-08-07 09:58:08,618 WARN  [utils.nio.NioConnection]
>(Agent-Selector:null) Unable to connect to remote: is there a server 
>running on port 8250
>2014-08-07 09:58:13,619 INFO  [utils.nio.NioClient] 
>(Agent-Selector:null) Connecting to 192.168.182.149:8250
>2014-08-07 09:59:16,630 WARN  [utils.nio.NioConnection]
>(Agent-Selector:null) Unable to connect to remote: is there a server 
>running on port 8250
>2014-08-07 09:59:21,631 INFO  [utils.nio.NioClient] 
>(Agent-Selector:null) Connecting to 192.168.182.149:8250
>
>Can someone give an insight into this?

Re: [VOTE] git workflow

[Daan Hoogland]

On Thu, Aug 7, 2014 at 7:23 PM, Alena Prokharchyk
 wrote:
> Plus if you read the discussion below the article, you will see that
> people agree that this model doesn’t work well for the case when the
> product support maintenance for older releases, like CS does.

Not at all, Alena. I don't agree that this model won't work for CS and
I think you are over estimating the amount of people that think so.
This model does work using support branches. It will work very well in
the CS case and is not very far removed from what we are doing right
now. There will always be port work when fixes in older versions need
to be made. You don't merge back support branches to tag the
maintainance release on the master branch. The fix-release-tag can
remain on the branche whether it is merged back or not. The witch hunt
on cherry picking is only perceived. There will be occasions it is
necessary but seldom so.

>
> "I think this model does not work for bugfixing in older releases, though.
> It messes up the neat ordering.
>
> 1. Say we have released Version 1.0.1 and later added features and
> released 1.1.0.
> 2. We discover a bug in 1.0.1 and want to fix it in both version
> 3. We have to add 1.0.2 after 1.1.0 in master and then directly atfer (or
> before) also 1.1.1.”

No this is not true. You can branch 1.0.1 to make 1.0.2 and merge
after it is done, next you can branch from 1.1.0 to make 1.1.1  and
merge that. the commits that point to 1.0.2 and 1.1.1 wil not be
removed when deleting the branches and when the fixes are the same and
the merge of 1.0.2 is clean they 1.1.0 doesn't even have to be
branched. if 1.0.1 or 1.0.2 is a conflicting fix then yes. that is the
one exception. you don't merge back. you keep the support branch.

This is not to far from what we do right now except that we keep old
branches preemptively right now.

>
>
> Thanks,
> Alena.
>
> On 8/7/14, 10:19 AM, "Alena Prokharchyk" 
> wrote:
>
>>Not quite. That’s what the article suggests:
>>
>>"If you want to fix bugs for older releases or do any other develop there,
>>you will fork a support branch from the appropriate commit in master (you
>>will have all versions ever created there). These branches are just
>>started and not intended to be merged back to master nor develop. This is
>>usually fine, as fixes to "ancient" releases or features requested by
>>customers to be implemented in "ancient" releases can't or should not go
>>back into master. If you still think, you want to port a fix to your main
>>development line (represented by master and develop), just start a hotfix,
>>cherry-pick your changes and finish the hotfix."
>>
>>
>>That doesn’t seem right to me - that NOT ALL the fixes done to 4.2.1/4.3.1
>>maintenance releases for example, will go back to master/develop? Plus it
>>suggests “cherry-picking” stuff if we decide that some fixes worth being
>>back ported. Cherry-picking again? :) Defeats our cherry-pick witch hunt
>>purpose. I think ALL fixes done to any forked branch, should make it into
>>master via merge.
>>
>>
>>On 8/7/14, 6:39 AM, "Tracy Phillips"  wrote:
>>
>>>Alena,
>>>
>>>Check this out and see if it would resolve your concern regarding
>>>maintaining multiple releases
>>>
>>>http://stackoverflow.com/questions/16562339/git-flow-and-master-with-mult
>>>i
>>>ple-parallel-release-branches
>>>
>>>git-flow uses support branches to support releases that are not on
>>>master.
>>>
>>>
>>>
>>>
>>>
>>>On Wed, Aug 6, 2014 at 6:28 PM, Alena Prokharchyk <
>>>alena.prokharc...@citrix.com> wrote:
>>>


 On 8/6/14, 3:18 PM, "Sebastien Goasguen"  wrote:

 >[top posting, apologies in advance]
 >
 >I am on vacation, so I will go straight to it :)
 >
 >This all discussion is not about gitflow specifically, it is about
 >modifying our git workflow and our commit practices to something more
 >standard that can:
 >
 >- ultimately help improve quality (in itself it won't but it can help
lay
 >a foundation)
 >- provide a stable master (it keeps breaking, it has regressions, it
 >moves really fast etc..)
 >- help cut releases
 >
 >Any committer has write privileges and can do whatever it wants to the
 >repos, so we need to get a nice big consensus on what problems we are
 >trying to solve, and how best to get there. So let's not make this a
 >debate of yeah or neah gitflow.
 >
 >A better CI is coming but it's not yet there and we have no ETA. Even
 >with a CI infra in place, we will need commit discipline to improve
 >quality (covertity, unitests, simulator tests). Changing our git
commit
 >practices has no cost (just emails and self discipline), so can we
agree
 >to do that first ?
 >
 >Here are couple high level things that I have in mind ( and I confess
I
 >have not read the entire threads on this yet and ti ma conflict with
 >gitflow).
 >
 >-Master: what goes in master is only something that has been

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

[daan Hoogland]

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



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


can you remove the trailing whitespace?


- daan Hoogland


On July 23, 2014, 4:30 p.m., Simon Weller wrote:
> 
> ---
> 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.
> 
> 
> 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: issues remaining for 4.4.1

[Daan Hoogland]

Marcus, Edison,

Can you have a look? It looks alright by me, but I have no time/env to test.

thanks,
Daan

On Thu, Aug 7, 2014 at 3:31 PM, Simon Weller  wrote:
> Daan,
>
> I have a patch in reviewboard for CLOUDSTACK-6460.
>
> https://reviews.apache.org/r/22939/
>
> - Si
> 
> From: Daan Hoogland 
> Sent: Thursday, August 07, 2014 3:53 AM
> To: dev
> Subject: issues remaining for 4.4.1
>
> H,
>
> have a look at 
> https://issues.apache.org/jira/browse/CLOUDSTACK-6358?filter=12328007
>
> It is a disappointing 280+ list of issues with 4.4 but I think a lot
> of them can be marked as won't solve, future releases or resolved.
>
> Please help me weed through these.
>
> thanks,
> --
> Daan



-- 
Daan

Re: [VOTE] git workflow

[Sebastien Goasguen]

On Aug 7, 2014, at 8:33 AM, David Nalley  wrote:

> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen  wrote:
>> 
>> On Aug 6, 2014, at 7:15 PM, David Nalley  wrote:
>> 
>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>>>  wrote:
 Edison, thank you for raising the concern about the BVT/CI. Somebody
 mentioned earlier that we should separate git workflow implementation from
 the CI effort, but I do think we have to do in in conjunction. Otherwise
 what is the point in introducing staging/develop branch? If there is no
 daily automation run verifying all the code merged from hotFixes/feature
 branches (and possibly reverting wrong checkins), we can as well merge the
 code directly to master.
 
>>> 
>>> Yes! - please.
>>> Doing this without CI as a gating factor buys us very little.
>>> 
>>> --David
>> 
>> David, can you clarify. Are you going to be against any change of git 
>> workflow until we get CI/BVT in place ?
>> 
> 
> No, please don't take it that way.
> I understand Leo's point about Cherry-picking being for fruit, and not
> code. But, I don't think that the workflow changes I've seen proposed
> affect quality. So shifting for quality's sake doesn't make a lot of
> sense in my mind. They could be a component of fixing the quality
> problem.
> 
> --David

Agreed, the changes don't affect quality but should support a CI infra that 
helps improves quality.

I do think the changes provide

-a stable master that represent released software
-a clean way to merge features and bug fixes
-a clean way to create a release that should reduce our time to release

Re: [VOTE] git workflow

[Alena Prokharchyk]

Daan, thank you. Please see my comments inline.


On 8/7/14, 1:19 PM, "Daan Hoogland"  wrote:

>On Thu, Aug 7, 2014 at 7:23 PM, Alena Prokharchyk
> wrote:
>> Plus if you read the discussion below the article, you will see that
>> people agree that this model doesn’t work well for the case when the
>> product support maintenance for older releases, like CS does.
>
>Not at all, Alena. I don't agree that this model won't work for CS and
>I think you are over estimating the amount of people that think so.
>This model does work using support branches. It will work very well in
>the CS case and is not very far removed from what we are doing right
>now. There will always be port work when fixes in older versions need
>to be made. You don't merge back support branches to tag the
>maintainance release on the master branch. The fix-release-tag can
>remain on the branche whether it is merged back or not. The witch hunt
>on cherry picking is only perceived. There will be occasions it is
>necessary but seldom so.


Does it mean that our master branch will miss the fixes from support
branches? Or you say we should cherry-pick them all on the top of the
master branch.

Again, I don’t see how maintaining master branch to reflect the latest
release branch, can stabilize our release process. You will still continue
to cut the release branches from *develop, which you can’t really call
“stable” with this model.


I’m still convinced that the best solution in our case would be
introducing:

 * develop branch as a staging branch
 * merging develop branch to master on a regular basis after the CI test
passes
 * cut release branch from the stable master branch when its time for the
release


I’m really trying to find the advantages of git-flow model where master
reflects the latest release branch, and can’t find any considering that in
the CS we are still going to keep those release/support branches, and if
people need the latest release code, they can simply get it from there.

From the developer stand point, I would be more interested in getting the
latest stable code, not the latest stable release. And with the model I
propose, that would be the master branch you get the latest stable code
from.

From release management perspective, I would be more interested in cutting
the release branches from the stable branch - gitflow suggests to cut it
them from *develop branch rather than master - and *develop is not a
stable branch. I don’t see the use of stable master branch during the
release, as it reflects already released versions of the CS.

May be I am missing the point. Would appreciate people explaining the
purpose of a git-flow way of keeping master branch, to solve the existing
CS problems. Just because “its a best practice for others” doesn’t sound
very convincing. 


>
>>
>> "I think this model does not work for bugfixing in older releases,
>>though.
>> It messes up the neat ordering.
>>
>> 1. Say we have released Version 1.0.1 and later added features and
>> released 1.1.0.
>> 2. We discover a bug in 1.0.1 and want to fix it in both version
>> 3. We have to add 1.0.2 after 1.1.0 in master and then directly atfer
>>(or
>> before) also 1.1.1.”
>
>No this is not true. You can branch 1.0.1 to make 1.0.2 and merge
>after it is done,




> 

Merge on a top of 1.1.0, which is the top of master branch?




>next you can branch from 1.1.0 to make 1.1.1  and
>merge that.
>the commits that point to 1.0.2 and 1.1.1 wil not be
>removed when deleting the branches and when the fixes are the same and
>the merge of 1.0.2 is clean they 1.1.0 doesn't even have to be
>branched. if 1.0.1 or 1.0.2 is a conflicting fix then yes. that is the
>one exception. you don't merge back. you keep the support branch.
>
>This is not to far from what we do right now except that we keep old
>branches preemptively right now.
>
>>
>>
>> Thanks,
>> Alena.
>>
>> On 8/7/14, 10:19 AM, "Alena Prokharchyk" 
>> wrote:
>>
>>>Not quite. That’s what the article suggests:
>>>
>>>"If you want to fix bugs for older releases or do any other develop
>>>there,
>>>you will fork a support branch from the appropriate commit in master
>>>(you
>>>will have all versions ever created there). These branches are just
>>>started and not intended to be merged back to master nor develop. This
>>>is
>>>usually fine, as fixes to "ancient" releases or features requested by
>>>customers to be implemented in "ancient" releases can't or should not go
>>>back into master. If you still think, you want to port a fix to your
>>>main
>>>development line (represented by master and develop), just start a
>>>hotfix,
>>>cherry-pick your changes and finish the hotfix."
>>>
>>>
>>>That doesn’t seem right to me - that NOT ALL the fixes done to
>>>4.2.1/4.3.1
>>>maintenance releases for example, will go back to master/develop? Plus
>>>it
>>>suggests “cherry-picking” stuff if we decide that some fixes worth being
>>>back ported. Cherry-picking again? :) Defeats our cherry-pick witch hunt
>>>purpose. I thin

Re: [VOTE] git workflow

[Alena Prokharchyk]

On 8/7/14, 1:42 PM, "Sebastien Goasguen"  wrote:

>
>On Aug 7, 2014, at 8:33 AM, David Nalley  wrote:
>
>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen 
>>wrote:
>>> 
>>> On Aug 6, 2014, at 7:15 PM, David Nalley  wrote:
>>> 
 On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
  wrote:
> Edison, thank you for raising the concern about the BVT/CI. Somebody
> mentioned earlier that we should separate git workflow
>implementation from
> the CI effort, but I do think we have to do in in conjunction.
>Otherwise
> what is the point in introducing staging/develop branch? If there is
>no
> daily automation run verifying all the code merged from
>hotFixes/feature
> branches (and possibly reverting wrong checkins), we can as well
>merge the
> code directly to master.
> 
 
 Yes! - please.
 Doing this without CI as a gating factor buys us very little.
 
 --David
>>> 
>>> David, can you clarify. Are you going to be against any change of git
>>>workflow until we get CI/BVT in place ?
>>> 
>> 
>> No, please don't take it that way.
>> I understand Leo's point about Cherry-picking being for fruit, and not
>> code. But, I don't think that the workflow changes I've seen proposed
>> affect quality. So shifting for quality's sake doesn't make a lot of
>> sense in my mind. They could be a component of fixing the quality
>> problem.
>> 
>> --David
>
>Agreed, the changes don't affect quality but should support a CI infra
>that helps improves quality.
>
>I do think the changes provide
>
>-a stable master that represent released software


You can always look at the latest release branch to get it, as we are
planning to keep them around to support maintenance. From the developer
stand point, I would be more interested in getting the latest stable code,
not the latest stable release.

I don¹t see the use of stable master branch during the release either, as
it reflects already released versions of the CS. And you never cut the
release from the stable master branch; you do cut it from *develop -
that¹s what the git workflow suggests.




>-a clean way to merge features and bug fixes

+1

>-a clean way to create a release that should reduce our time to release

+1 Although I still think that slowness for our release was mostly caused
by the last minute regression bugs caused by missing quality control +
lack of CI. This new way would just take off the load from RM by
eliminating endless cherry-picking.


>

[CLOUDSTACK-6114][GSoC] End of second term approaching

[Ian Duffy]

Hi All,

Giving a very brief overview of everything that has been done. If any
questions or expansion is wanted please reply back.

TL;DR "vagrant up" for: Cloudstack basic zone from source, Cloudstack
advanced zone from source, Cloudstack Simulator, Cloudstack binary
installation and configuration. All provisioning/setup done by chef.

VagrantFiles / Example usage: https://github.com/imduffy15/GSoC-2014

Chef recipe: https://github.com/imduffy15/cookbook_cloudstack


*CLOUDSTACK-6114 - GSoC: Create config management recipes to install
CloudStack. ( https://issues.apache.org/jira/browse/CLOUDSTACK-6114
 ) *

*"Devcloud" basic (https://github.com/imduffy15/GSoC-2014/tree/master/basic
)*

Re-jigged version of devcloud using vagrant and chef.

Made up of:
 1) "Management" VM. Acts as NFS, MySQL and a Gateway.
 2)  XenServer VM. (Built using packer
https://github.com/imduffy15/packer-xenserver)

Cloudstack is ran on the developers machine.
Marvin is also ran on the developers machine with a supplied configuration
for a basic zone.

MySQL is forwarded from the VM to localhost 3306. This means deploydb works
without issue.

Unlike the old implementation, the VMs brought up by cloudstack have
internet access.

VagrantFile and Marvin config can be found at
https://github.com/imduffy15/GSoC-2014/tree/master/basic

*"Devcloud" advanced
(https://github.com/imduffy15/GSoC-2014/tree/master/advanced
)*

Extension of the above described "Devcloud" basic.

This extension introduces more virtual network cards. This allows for an
advanced zone to be deployed.

Again, Cloudstack and Marvin will the ran on the developers machine. A
marvin config file has been supplied for this.

VagrantFile and Marvin config can be found at
https://github.com/imduffy15/GSoC-2014/tree/master/advanced

 Note 
*The ttylinux_vhd supplied with devcloud has hard coded dns servers in
resolv.conf.*

*These are not overwrote by the DHCP lease.*

*As a side project and workaround I have supplied Debian
images http://dl.openvm.eu/cloudstack/debian/vanilla/7/x86_64/
 Thanks to Nux for
hosting and exoscale supplying boxes to build the images automatically. *

*Simulator (https://github.com/imduffy15/GSoC-2014/tree/master/simulator
)*

This is a single virtual machine. All development tools and mysql are
installed onto this box. A specified version of Cloudstack source is
downloaded and compiled.

The simulator is booted, when completed marvin is executed on the box and
the simulator is configured.

Takes a bit of time to come up... faster solution below.

VagrantFile at https://github.com/imduffy15/GSoC-2014/tree/master/simulator

*Simulator fast
(https://github.com/imduffy15/GSoC-2014/tree/master/simulator-fast
)*

This is a single virtual machine that supplies the cloudstack simulator. I*t
comes up in however fast you can download the 128mb cloud-client-ui war.*

This is restricted to running the cloud-client.war I have supplied (based
of 4.4). This is due to inflexibility around the database. I was hoping to
just use the basic create-schema files and let the upgrade handle the rest
however the upgrade fails. If anybody has a solution to this I would love
to hear it.

This works by taking the cloud-client.war and deploying it with jetty.

VagrantFile at
https://github.com/imduffy15/GSoC-2014/tree/master/simulator-fast

*Binary Installation
(https://github.com/imduffy15/GSoC-2014/tree/master/binary-installation
)*

Takes the Cloudstack RPMs, installs them and all requirements.

Installs marvin and executes it against a configuration supplied within the
chef recipe to configure your cloud.

The hypervisor is to be considered a static node. In a real world
environment it must exist before executing the chef recipe.

For demoing and testing purposes a VagrantFile for this can be found at
https://github.com/imduffy15/GSoC-2014/tree/master/binary-installation

 Note 

All of the above described boxes are not baked. They are fried on boot up
using chef, this means you can use the recipe outside of vagrant for
achieving the same thing.

The recipe can be found at https://github.com/imduffy15/cookbook_cloudstack
for usage please see the above mentioned vagrantfiles and their run lists
along with the chef attributes defination file.

Re: [VOTE] git workflow

[Mike Tutkowski]

I admit that I'm a bit confused, as well, regarding the value of 'master'
if it only points to the most recently released version of CloudStack.

If you want the most recently released version, you can just go back in
time - as necessary - to arrive at the applicable commit.

I think the problem we really want to solve relates to the constant
instability of our work-in-progress branch (currently called 'master').
Without consideration for CI, our new 'develop' branch simply assumes all
of the faults currently associated with 'master'.

The way I see us taking a step toward solving the real problem is via what
Alena mention:

 * develop branch as a staging branch
 * merging develop branch to master on a regular basis after the CI test
passes
 * cut release branch from the stable master branch when its time for the
release


On Thu, Aug 7, 2014 at 2:44 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

> Daan, thank you. Please see my comments inline.
>
>
> On 8/7/14, 1:19 PM, "Daan Hoogland"  wrote:
>
> >On Thu, Aug 7, 2014 at 7:23 PM, Alena Prokharchyk
> > wrote:
> >> Plus if you read the discussion below the article, you will see that
> >> people agree that this model doesn’t work well for the case when the
> >> product support maintenance for older releases, like CS does.
> >
> >Not at all, Alena. I don't agree that this model won't work for CS and
> >I think you are over estimating the amount of people that think so.
> >This model does work using support branches. It will work very well in
> >the CS case and is not very far removed from what we are doing right
> >now. There will always be port work when fixes in older versions need
> >to be made. You don't merge back support branches to tag the
> >maintainance release on the master branch. The fix-release-tag can
> >remain on the branche whether it is merged back or not. The witch hunt
> >on cherry picking is only perceived. There will be occasions it is
> >necessary but seldom so.
>
>
> Does it mean that our master branch will miss the fixes from support
> branches? Or you say we should cherry-pick them all on the top of the
> master branch.
>
> Again, I don’t see how maintaining master branch to reflect the latest
> release branch, can stabilize our release process. You will still continue
> to cut the release branches from *develop, which you can’t really call
> “stable” with this model.
>
>
> I’m still convinced that the best solution in our case would be
> introducing:
>
>  * develop branch as a staging branch
>  * merging develop branch to master on a regular basis after the CI test
> passes
>  * cut release branch from the stable master branch when its time for the
> release
>
>
> I’m really trying to find the advantages of git-flow model where master
> reflects the latest release branch, and can’t find any considering that in
> the CS we are still going to keep those release/support branches, and if
> people need the latest release code, they can simply get it from there.
>
> From the developer stand point, I would be more interested in getting the
> latest stable code, not the latest stable release. And with the model I
> propose, that would be the master branch you get the latest stable code
> from.
>
> From release management perspective, I would be more interested in cutting
> the release branches from the stable branch - gitflow suggests to cut it
> them from *develop branch rather than master - and *develop is not a
> stable branch. I don’t see the use of stable master branch during the
> release, as it reflects already released versions of the CS.
>
> May be I am missing the point. Would appreciate people explaining the
> purpose of a git-flow way of keeping master branch, to solve the existing
> CS problems. Just because “its a best practice for others” doesn’t sound
> very convincing.
>
>
> >
> >>
> >> "I think this model does not work for bugfixing in older releases,
> >>though.
> >> It messes up the neat ordering.
> >>
> >> 1. Say we have released Version 1.0.1 and later added features and
> >> released 1.1.0.
> >> 2. We discover a bug in 1.0.1 and want to fix it in both version
> >> 3. We have to add 1.0.2 after 1.1.0 in master and then directly atfer
> >>(or
> >> before) also 1.1.1.”
> >
> >No this is not true. You can branch 1.0.1 to make 1.0.2 and merge
> >after it is done,
>
>
>
>
> >
>
> Merge on a top of 1.1.0, which is the top of master branch?
>
>
>
>
> >next you can branch from 1.1.0 to make 1.1.1  and
> >merge that.
> >the commits that point to 1.0.2 and 1.1.1 wil not be
> >removed when deleting the branches and when the fixes are the same and
> >the merge of 1.0.2 is clean they 1.1.0 doesn't even have to be
> >branched. if 1.0.1 or 1.0.2 is a conflicting fix then yes. that is the
> >one exception. you don't merge back. you keep the support branch.
> >
> >This is not to far from what we do right now except that we keep old
> >branches preemptively right now.
> >
> >>
> >>
> >> Thanks,
> >> Alena.
> >>
> >> On 8/7

Re: [VOTE] git workflow

[Sebastien Goasguen]

On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk  
wrote:

> 
> 
> On 8/7/14, 1:42 PM, "Sebastien Goasguen"  wrote:
> 
>> 
>> On Aug 7, 2014, at 8:33 AM, David Nalley  wrote:
>> 
>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen 
>>> wrote:
 
 On Aug 6, 2014, at 7:15 PM, David Nalley  wrote:
 
> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>  wrote:
>> Edison, thank you for raising the concern about the BVT/CI. Somebody
>> mentioned earlier that we should separate git workflow
>> implementation from
>> the CI effort, but I do think we have to do in in conjunction.
>> Otherwise
>> what is the point in introducing staging/develop branch? If there is
>> no
>> daily automation run verifying all the code merged from
>> hotFixes/feature
>> branches (and possibly reverting wrong checkins), we can as well
>> merge the
>> code directly to master.
>> 
> 
> Yes! - please.
> Doing this without CI as a gating factor buys us very little.
> 
> --David
 
 David, can you clarify. Are you going to be against any change of git
 workflow until we get CI/BVT in place ?
 
>>> 
>>> No, please don't take it that way.
>>> I understand Leo's point about Cherry-picking being for fruit, and not
>>> code. But, I don't think that the workflow changes I've seen proposed
>>> affect quality. So shifting for quality's sake doesn't make a lot of
>>> sense in my mind. They could be a component of fixing the quality
>>> problem.
>>> 
>>> --David
>> 
>> Agreed, the changes don't affect quality but should support a CI infra
>> that helps improves quality.
>> 
>> I do think the changes provide
>> 
>> -a stable master that represent released software
> 
> 
> You can always look at the latest release branch to get it,

Yes I know how to get to the latest released software.

I actually don't have good answers for your questions but I think Nate's email 
(couple emails back) answers a lot of them.

> as we are
> planning to keep them around to support maintenance. From the developer
> stand point, I would be more interested in getting the latest stable code,
> not the latest stable release.

I think that's fine from a developer standpoint. I tend to look at things from 
a user standpoint.
I think a basic user who wants to check out source (because he builds his own 
packages), would like to checkout the latest master to get the latest released 
software (not everybody software projects works like this of course).

The main issue with master right now is that it moves really fast as a shared 
branch, people merge features without warning, we see regressions etc..
By the time we release a major version, master has moved so much that it feels 
like starting over with the next release. It's almost as if we are forking our 
own software. CI alone (even if it were really good) will not fix this.

So assuming we have CI in place, we do need a better workflow (let's not call 
it gitflow anymore) to self-discipline ourselves.

> 
> I don¹t see the use of stable master branch during the release either, as
> it reflects already released versions of the CS. And you never cut the
> release from the stable master branch; you do cut it from *develop -
> that¹s what the git workflow suggests.

That's where our use case differs from gitflow. Several folks have already 
mentioned that we are going to deviate from pure gitflow, it is just a nice 
framework to start creating our own workflow.

Personally, I would love to cut the release branches from master (instead of 
develop). that way you always start from a clean slate, instead of the mess 
with start with right now.

Say develop is more of a staging branch, as you have advocated. We can run 
CI/BVT on that branch (we should run it everywhere…but anyway) and make sure 
features merged in work as advertized.

When time comes to release, we cut from master and merge the features that have 
been merged in develop already, then go into QA, merge the fixes back to 
develop etc….when released, we merge back to master.

If/since we don't do rolling releases, we branch out from the main version tag 
and do a maintenance release that leaves on, assuming it can't get merged back 
into master.

> 
>> -a clean way to merge features and bug fixes
> 
> +1
> 
>> -a clean way to create a release that should reduce our time to release
> 
> +1 Although I still think that slowness for our release was mostly caused
> by the last minute regression bugs caused by missing quality control +
> lack of CI.

True, but it is also due to the fact that we start a release branch from a 
messy master where regressions happen.

> This new way would just take off the load from RM by
> eliminating endless cherry-picking.
> 

I would love to have a workflow where the RM has a very clean job (pick the 
features that should be in the release, pick the hot fixes release). It should 
just be a series of git merge and that's it.

master bra

Re: [VOTE] git workflow

[Erik Weber]

On Thu, Aug 7, 2014 at 10:44 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

> Daan, thank you. Please see my comments inline.
>
>
> On 8/7/14, 1:19 PM, "Daan Hoogland"  wrote:
>
> >On Thu, Aug 7, 2014 at 7:23 PM, Alena Prokharchyk
> > wrote:
> >> Plus if you read the discussion below the article, you will see that
> >> people agree that this model doesn’t work well for the case when the
> >> product support maintenance for older releases, like CS does.
> >
> >Not at all, Alena. I don't agree that this model won't work for CS and
> >I think you are over estimating the amount of people that think so.
> >This model does work using support branches. It will work very well in
> >the CS case and is not very far removed from what we are doing right
> >now. There will always be port work when fixes in older versions need
> >to be made. You don't merge back support branches to tag the
> >maintainance release on the master branch. The fix-release-tag can
> >remain on the branche whether it is merged back or not. The witch hunt
> >on cherry picking is only perceived. There will be occasions it is
> >necessary but seldom so.
>
>
> Does it mean that our master branch will miss the fixes from support
> branches? Or you say we should cherry-pick them all on the top of the
> master branch.
>


'master' reflects the latest released version. If that release misses the
fix, then master does as well.
For master to have it you would either roll out a new version or hotfix it.



> Again, I don’t see how maintaining master branch to reflect the latest
> release branch, can stabilize our release process. You will still continue
> to cut the release branches from *develop, which you can’t really call
> “stable” with this model.
>
>
It doesn't. master could just as easily have been called 'stable' or
'latest'.


>
> I’m still convinced that the best solution in our case would be
> introducing:
>
>  * develop branch as a staging branch
>

develop is the staging branch in gitflow as well, you do your development
in feature branches.
when your feature is done and passes CI you merge to develop.

 * merging develop branch to master on a regular basis after the CI test
> passes
>


there's no guarantee that it's stable at all, CI can only cover so much.
besides, this is what gitflow proposes, except that you merge from your
feature branch to develop, instead of from develop to master.



>  * cut release branch from the stable master branch when its time for the
> release
>

see previous, besides if the only thing deeming if master is stable or not
is CI, then you might as well cut from develop



> I’m really trying to find the advantages of git-flow model where master
> reflects the latest release branch, and can’t find any considering that in
> the CS we are still going to keep those release/support branches, and if
> people need the latest release code, they can simply get it from there.
>
>
What's the downside of having master represent the latest released version?


> From the developer stand point, I would be more interested in getting the
> latest stable code, not the latest stable release. And with the model I
> propose, that would be the master branch you get the latest stable code
> from.
>

So you have to do a 'git checkout develop' first. unless you use the
gitflow tools,
then you do a simple 'gitflow feature start ' and don't really care
about branch names at all.


> From release management perspective, I would be more interested in cutting
> the release branches from the stable branch - gitflow suggests to cut it
> them from *develop branch rather than master - and *develop is not a
> stable branch. I don’t see the use of stable master branch during the
> release, as it reflects already released versions of the CS.
>

develop should be as stable as the master you propose, after all they
should contain the same code.



> May be I am missing the point. Would appreciate people explaining the
> purpose of a git-flow way of keeping master branch, to solve the existing
> CS problems. Just because “its a best practice for others” doesn’t sound
> very convincing.
>


If the master branch is what confuses you the most, then forget about
master branch.
As a developer you are not really interested in it anyway, you never really
commit to it besides new releases / hotfixes to the latest release.
Think of develop as your master and treat it like that, and think of master
as a shortcut to the latest release tag.

-- 
Erik

Re: issues remaining for 4.4.1

[Mike Tutkowski]

CloudStack is a huge project. That being the case, I'm personally not
overly concerned about the number of open tickets in JIRA. As far as we
know, none of them is a blocker. I'd only be concerned if a substantial
number of these tickets are "Critical" in nature.

I worked on a SAN technology at HP for almost seven years. It was a huge
project and we always seemed to have 100s of open tickets. You know what,
though? It was also an awesome technology that our customers loved.


On Thu, Aug 7, 2014 at 2:27 PM, Daan Hoogland 
wrote:

> Marcus, Edison,
>
> Can you have a look? It looks alright by me, but I have no time/env to
> test.
>
> thanks,
> Daan
>
> On Thu, Aug 7, 2014 at 3:31 PM, Simon Weller  wrote:
> > Daan,
> >
> > I have a patch in reviewboard for CLOUDSTACK-6460.
> >
> > https://reviews.apache.org/r/22939/
> >
> > - Si
> > 
> > From: Daan Hoogland 
> > Sent: Thursday, August 07, 2014 3:53 AM
> > To: dev
> > Subject: issues remaining for 4.4.1
> >
> > H,
> >
> > have a look at
> https://issues.apache.org/jira/browse/CLOUDSTACK-6358?filter=12328007
> >
> > It is a disappointing 280+ list of issues with 4.4 but I think a lot
> > of them can be marked as won't solve, future releases or resolved.
> >
> > Please help me weed through these.
> >
> > thanks,
> > --
> > Daan
>
>
>
> --
> 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
*™*

Re: [VOTE] git workflow

[Tracy Phillips]

Any process is better than what is being used right now.

git-flow is just a proven process that is working for folks who use it.
That is a fact.

git-flow somewhat enforces a process, especially if you use the git-flow
plugin:

git flow feature start 2345-eye-candy

git flow feature publish etc, etc, etc.

It took me a bit to wrap my head around the concepts but when I did, it
*really* started to make sense. It does seem like a like for forking and
rebasing but that is what git is good at.

git-flow keeps things nice and tidy.

Re: [VOTE] git workflow

[Alena Prokharchyk]

Erik, addressing "What's the downside of having master represent the
latest released version?²

No real downside (rather than the pain when it comes to managing
maintenance releases for earlier versions of CS), but what are the
advantages really? 

If you are the user who wants to get the latest stable release, you just
get it from the release branch (or specific tag on that branch if you want
a particular minor release), the release branch that - again - we must
keep around because of subsequent maintenance releases that we support in
CS. Unlike in git-workflow, when release branch is removed right after its
merged to master.

And if you are a RM who wants to cut the release, you do it from the
stable branch with the latest code. And that branch won¹t be master.

So why implement something that doesn¹t serve any practical purpose for
CS? I don¹t argue against other items of git-workflow (merges vs
cherry-picks, feature/hotfix branches), my main concern is about master
branch maintenance.

=Alena.

On 8/7/14, 2:17 PM, "Erik Weber"  wrote:

>On Thu, Aug 7, 2014 at 10:44 PM, Alena Prokharchyk <
>alena.prokharc...@citrix.com> wrote:
>
>> Daan, thank you. Please see my comments inline.
>>
>>
>> On 8/7/14, 1:19 PM, "Daan Hoogland"  wrote:
>>
>> >On Thu, Aug 7, 2014 at 7:23 PM, Alena Prokharchyk
>> > wrote:
>> >> Plus if you read the discussion below the article, you will see that
>> >> people agree that this model doesn¹t work well for the case when the
>> >> product support maintenance for older releases, like CS does.
>> >
>> >Not at all, Alena. I don't agree that this model won't work for CS and
>> >I think you are over estimating the amount of people that think so.
>> >This model does work using support branches. It will work very well in
>> >the CS case and is not very far removed from what we are doing right
>> >now. There will always be port work when fixes in older versions need
>> >to be made. You don't merge back support branches to tag the
>> >maintainance release on the master branch. The fix-release-tag can
>> >remain on the branche whether it is merged back or not. The witch hunt
>> >on cherry picking is only perceived. There will be occasions it is
>> >necessary but seldom so.
>>
>>
>> Does it mean that our master branch will miss the fixes from support
>> branches? Or you say we should cherry-pick them all on the top of the
>> master branch.
>>
>
>
>'master' reflects the latest released version. If that release misses the
>fix, then master does as well.
>For master to have it you would either roll out a new version or hotfix
>it.
>
>
>
>> Again, I don¹t see how maintaining master branch to reflect the latest
>> release branch, can stabilize our release process. You will still
>>continue
>> to cut the release branches from *develop, which you can¹t really call
>> ³stable² with this model.
>>
>>
>It doesn't. master could just as easily have been called 'stable' or
>'latest'.
>
>
>>
>> I¹m still convinced that the best solution in our case would be
>> introducing:
>>
>>  * develop branch as a staging branch
>>
>
>develop is the staging branch in gitflow as well, you do your development
>in feature branches.
>when your feature is done and passes CI you merge to develop.
>
> * merging develop branch to master on a regular basis after the CI test
>> passes
>>
>
>
>there's no guarantee that it's stable at all, CI can only cover so much.
>besides, this is what gitflow proposes, except that you merge from your
>feature branch to develop, instead of from develop to master.
>
>
>
>>  * cut release branch from the stable master branch when its time for
>>the
>> release
>>
>
>see previous, besides if the only thing deeming if master is stable or not
>is CI, then you might as well cut from develop
>
>
>
>> I¹m really trying to find the advantages of git-flow model where master
>> reflects the latest release branch, and can¹t find any considering that
>>in
>> the CS we are still going to keep those release/support branches, and if
>> people need the latest release code, they can simply get it from there.
>>
>>
>What's the downside of having master represent the latest released
>version?
>
>
>> From the developer stand point, I would be more interested in getting
>>the
>> latest stable code, not the latest stable release. And with the model I
>> propose, that would be the master branch you get the latest stable code
>> from.
>>
>
>So you have to do a 'git checkout develop' first. unless you use the
>gitflow tools,
>then you do a simple 'gitflow feature start similar>' and don't really care
>about branch names at all.
>
>
>> From release management perspective, I would be more interested in
>>cutting
>> the release branches from the stable branch - gitflow suggests to cut it
>> them from *develop branch rather than master - and *develop is not a
>> stable branch. I don¹t see the use of stable master branch during the
>> release, as it reflects already released versions of the CS.
>>
>
>develop should be as stabl

Re: [VOTE] git workflow

[Alena Prokharchyk]

Sebastian, addressing the following comment of yours


"The main issue with master right now is that it moves really fast as a
shared branch, people merge features without warning, we see regressions
etc..
By the time we release a major version, master has moved so much that it
feels like starting over with the next release. It's almost as if we are
forking our own software. CI alone (even if it were really good) will not
fix this.”


You will still have this problem. You cut the next release branch from the
*develop branch, not from master. And the *develop branch will move with
the same pace as the old master, after the release branch is cut. So
“master moving really fast” problem would become “develop moving really
fast”. 

The problems you’ve mentioned - people merge features without warning, we
see regressions - can be fixed only with automation in place and the
requirement to run this automation (CI/BVT) before the merge is done.
Otherwise you are just shifting all existing problems from master to
develop. 


-Alena.



On 8/7/14, 2:15 PM, "Sebastien Goasguen"  wrote:

>
>On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
> wrote:
>
>> 
>> 
>> On 8/7/14, 1:42 PM, "Sebastien Goasguen"  wrote:
>> 
>>> 
>>> On Aug 7, 2014, at 8:33 AM, David Nalley  wrote:
>>> 
 On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen 
 wrote:
> 
> On Aug 6, 2014, at 7:15 PM, David Nalley  wrote:
> 
>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>>  wrote:
>>> Edison, thank you for raising the concern about the BVT/CI.
>>>Somebody
>>> mentioned earlier that we should separate git workflow
>>> implementation from
>>> the CI effort, but I do think we have to do in in conjunction.
>>> Otherwise
>>> what is the point in introducing staging/develop branch? If there
>>>is
>>> no
>>> daily automation run verifying all the code merged from
>>> hotFixes/feature
>>> branches (and possibly reverting wrong checkins), we can as well
>>> merge the
>>> code directly to master.
>>> 
>> 
>> Yes! - please.
>> Doing this without CI as a gating factor buys us very little.
>> 
>> --David
> 
> David, can you clarify. Are you going to be against any change of git
> workflow until we get CI/BVT in place ?
> 
 
 No, please don't take it that way.
 I understand Leo's point about Cherry-picking being for fruit, and not
 code. But, I don't think that the workflow changes I've seen proposed
 affect quality. So shifting for quality's sake doesn't make a lot of
 sense in my mind. They could be a component of fixing the quality
 problem.
 
 --David
>>> 
>>> Agreed, the changes don't affect quality but should support a CI infra
>>> that helps improves quality.
>>> 
>>> I do think the changes provide
>>> 
>>> -a stable master that represent released software
>> 
>> 
>> You can always look at the latest release branch to get it,
>
>Yes I know how to get to the latest released software.
>
>I actually don't have good answers for your questions but I think Nate's
>email (couple emails back) answers a lot of them.
>
>> as we are
>> planning to keep them around to support maintenance. From the developer
>> stand point, I would be more interested in getting the latest stable
>>code,
>> not the latest stable release.
>
>I think that's fine from a developer standpoint. I tend to look at things
>from a user standpoint.
>I think a basic user who wants to check out source (because he builds his
>own packages), would like to checkout the latest master to get the latest
>released software (not everybody software projects works like this of
>course).
>
>The main issue with master right now is that it moves really fast as a
>shared branch, people merge features without warning, we see regressions
>etc..
>By the time we release a major version, master has moved so much that it
>feels like starting over with the next release. It's almost as if we are
>forking our own software. CI alone (even if it were really good) will not
>fix this.
>
>So assuming we have CI in place, we do need a better workflow (let's not
>call it gitflow anymore) to self-discipline ourselves.
>
>> 
>> I don¹t see the use of stable master branch during the release either,
>>as
>> it reflects already released versions of the CS. And you never cut the
>> release from the stable master branch; you do cut it from *develop -
>> that¹s what the git workflow suggests.
>
>That's where our use case differs from gitflow. Several folks have
>already mentioned that we are going to deviate from pure gitflow, it is
>just a nice framework to start creating our own workflow.
>
>Personally, I would love to cut the release branches from master (instead
>of develop). that way you always start from a clean slate, instead of the
>mess with start with right now.
>
>Say develop is more of a staging branch, as you have advocated. We can
>run CI/BVT on that branch (we shoul

Re: [VOTE] git workflow

[Mike Tutkowski]

This is what I was wondering about, as well. It seems all of our 'master'
problems become 'develop' problems.

I do like the idea of merging versus cherry picking (as a general rule),
though.


On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

> Sebastian, addressing the following comment of yours
>
>
> "The main issue with master right now is that it moves really fast as a
> shared branch, people merge features without warning, we see regressions
> etc..
> By the time we release a major version, master has moved so much that it
> feels like starting over with the next release. It's almost as if we are
> forking our own software. CI alone (even if it were really good) will not
> fix this.”
>
>
> You will still have this problem. You cut the next release branch from the
> *develop branch, not from master. And the *develop branch will move with
> the same pace as the old master, after the release branch is cut. So
> “master moving really fast” problem would become “develop moving really
> fast”.
>
> The problems you’ve mentioned - people merge features without warning, we
> see regressions - can be fixed only with automation in place and the
> requirement to run this automation (CI/BVT) before the merge is done.
> Otherwise you are just shifting all existing problems from master to
> develop.
>
>
> -Alena.
>
>
>
> On 8/7/14, 2:15 PM, "Sebastien Goasguen"  wrote:
>
> >
> >On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
> > wrote:
> >
> >>
> >>
> >> On 8/7/14, 1:42 PM, "Sebastien Goasguen"  wrote:
> >>
> >>>
> >>> On Aug 7, 2014, at 8:33 AM, David Nalley  wrote:
> >>>
>  On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen 
>  wrote:
> >
> > On Aug 6, 2014, at 7:15 PM, David Nalley  wrote:
> >
> >> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
> >>  wrote:
> >>> Edison, thank you for raising the concern about the BVT/CI.
> >>>Somebody
> >>> mentioned earlier that we should separate git workflow
> >>> implementation from
> >>> the CI effort, but I do think we have to do in in conjunction.
> >>> Otherwise
> >>> what is the point in introducing staging/develop branch? If there
> >>>is
> >>> no
> >>> daily automation run verifying all the code merged from
> >>> hotFixes/feature
> >>> branches (and possibly reverting wrong checkins), we can as well
> >>> merge the
> >>> code directly to master.
> >>>
> >>
> >> Yes! - please.
> >> Doing this without CI as a gating factor buys us very little.
> >>
> >> --David
> >
> > David, can you clarify. Are you going to be against any change of git
> > workflow until we get CI/BVT in place ?
> >
> 
>  No, please don't take it that way.
>  I understand Leo's point about Cherry-picking being for fruit, and not
>  code. But, I don't think that the workflow changes I've seen proposed
>  affect quality. So shifting for quality's sake doesn't make a lot of
>  sense in my mind. They could be a component of fixing the quality
>  problem.
> 
>  --David
> >>>
> >>> Agreed, the changes don't affect quality but should support a CI infra
> >>> that helps improves quality.
> >>>
> >>> I do think the changes provide
> >>>
> >>> -a stable master that represent released software
> >>
> >>
> >> You can always look at the latest release branch to get it,
> >
> >Yes I know how to get to the latest released software.
> >
> >I actually don't have good answers for your questions but I think Nate's
> >email (couple emails back) answers a lot of them.
> >
> >> as we are
> >> planning to keep them around to support maintenance. From the developer
> >> stand point, I would be more interested in getting the latest stable
> >>code,
> >> not the latest stable release.
> >
> >I think that's fine from a developer standpoint. I tend to look at things
> >from a user standpoint.
> >I think a basic user who wants to check out source (because he builds his
> >own packages), would like to checkout the latest master to get the latest
> >released software (not everybody software projects works like this of
> >course).
> >
> >The main issue with master right now is that it moves really fast as a
> >shared branch, people merge features without warning, we see regressions
> >etc..
> >By the time we release a major version, master has moved so much that it
> >feels like starting over with the next release. It's almost as if we are
> >forking our own software. CI alone (even if it were really good) will not
> >fix this.
> >
> >So assuming we have CI in place, we do need a better workflow (let's not
> >call it gitflow anymore) to self-discipline ourselves.
> >
> >>
> >> I don¹t see the use of stable master branch during the release either,
> >>as
> >> it reflects already released versions of the CS. And you never cut the
> >> release from the stable master branch; you do cut it from *develop -
> >> that¹s what the git workflow 

What is the behaviour of VPC Reset?

[Suresh Ramamurthy]

Hi Alena, Sheng Yang,

Could you please shed some light on the behaviour of VPC Reset
functionality?

When I went through the code, VPC Reset shuts down the VR and restarts it.
Does it also clean all ACL, NAT etc associated to all the tiers in the VPC
and then reconfigure the current value?

Is there any document that I can read to get an idea about the behaviour?

Thanks,
Suresh Ramamurthy

Re: Getting "Refusing to design this network, the physical isolation type is not MIDO" while deploying a VM with new network from UI

[Carlos Reategui]

I think this is where your problem is:

2014-08-06 21:42:23,476 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
(API-Job-Executor-2:ctx-e92d4da4 job-420 ctx-8546dbd9) Checking resources
in Cluster: 1 under Pod: 1
2014-08-06 21:42:23,477 DEBUG [c.c.a.m.a.i.FirstFitAllocator]
(API-Job-Executor-2:ctx-e92d4da4 job-420 ctx-8546dbd9
FirstFitRoutingAllocator) Looking for hosts in dc: 1  pod:1  cluster:1
2014-08-06 21:42:23,481 DEBUG [c.c.a.m.a.i.FirstFitAllocator]
(API-Job-Executor-2:ctx-e92d4da4 job-420 ctx-8546dbd9
FirstFitRoutingAllocator) FirstFitAllocator has 1 hosts to check for
allocation: [Host[-1-Routing]]
2014-08-06 21:42:23,486 DEBUG [c.c.a.m.a.i.FirstFitAllocator]
(API-Job-Executor-2:ctx-e92d4da4 job-420 ctx-8546dbd9
FirstFitRoutingAllocator) Found 1 hosts for allocation after
prioritization: [Host[-1-Routing]]
2014-08-06 21:42:23,486 DEBUG [c.c.a.m.a.i.FirstFitAllocator]
(API-Job-Executor-2:ctx-e92d4da4 job-420 ctx-8546dbd9
FirstFitRoutingAllocator) Looking for speed=3200Mhz, Ram=3072

*2014-08-06 21:42:23,493 DEBUG [c.c.r.ResourceManagerImpl]
(API-Job-Executor-2:ctx-e92d4da4 job-420 ctx-8546dbd9
FirstFitRoutingAllocator) Host ID: 1 does not have GPU device
available*2014-08-06
21:42:23,493 INFO  [c.c.a.m.a.i.FirstFitAllocator]
(API-Job-Executor-2:ctx-e92d4da4
job-420 ctx-8546dbd9 FirstFitRoutingAllocator) Host name: cldstk-R720-10,
hostId: 1 does not have required GPU devices available
2014-08-06 21:42:23,493 DEBUG [c.c.a.m.a.i.FirstFitAllocator]
(API-Job-Executor-2:ctx-e92d4da4 job-420 ctx-8546dbd9
FirstFitRoutingAllocator) Host Allocator returning 0 suitable hosts
2014-08-06 21:42:23,493 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
(API-Job-Executor-2:ctx-e92d4da4 job-420 ctx-8546dbd9) No suitable hosts
found
2014-08-06 21:42:23,493 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
(API-Job-Executor-2:ctx-e92d4da4 job-420 ctx-8546dbd9) No suitable hosts
found under this Cluster: 1

Does your host have a properly configured GPU and does CloudStack know
about it?



On Wed, Aug 6, 2014 at 11:36 AM, Abhinav Roy  wrote:

> Hi,
>
>
> I am getting this error while deploying a VM on XENSERVER :
>
> 2014-08-06 21:42:22,774 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-2:ctx-6c894fdd) ===START===  10.144.7.6 -- GET
>  
> command=createNetwork&response=json&sessionkey=IyiV1YiWuFVSGa7GynZv5T12nLk%3D&networkOfferingId=94cef53e-49ec-4a9f-a0fc-f82f0e40aba5&name=test&displayText=test&zoneId=29d069ac-e1ea-45dc-8c35-dd5b6c628ce2&_=1407340991296
> 2014-08-06 21:42:22,798 DEBUG [o.a.c.a.BaseCmd]
> (catalina-exec-2:ctx-6c894fdd ctx-99f95792) Ignoring paremeter
> displaynetwork as the caller is not authorized to pass it in
> 2014-08-06 21:42:22,803 DEBUG [o.a.c.a.BaseCmd]
> (catalina-exec-2:ctx-6c894fdd ctx-99f95792) Ignoring paremeter
> displaynetwork as the caller is not authorized to pass it in
> 2014-08-06 21:42:22,872 DEBUG [o.a.c.n.c.m.ContrailGuru]
> (catalina-exec-2:ctx-6c894fdd ctx-99f95792) Refusing to design this network
> 2014-08-06 21:42:22,873 DEBUG [c.c.n.g.MidoNetGuestNetworkGuru]
> (catalina-exec-2:ctx-6c894fdd ctx-99f95792) design called
> 2014-08-06 21:42:22,875 DEBUG [c.c.n.g.MidoNetGuestNetworkGuru]
> (catalina-exec-2:ctx-6c894fdd ctx-99f95792) Refusing to design this
> network, the physical isolation type is not MIDO
> 2014-08-06 21:42:22,877 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru]
> (catalina-exec-2:ctx-6c894fdd ctx-99f95792) Refusing to design this network
> 2014-08-06 21:42:22,879 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru]
> (catalina-exec-2:ctx-6c894fdd ctx-99f95792) Refusing to design this network
> 2014-08-06 21:42:22,881 DEBUG [c.c.n.g.OvsGuestNetworkGuru]
> (catalina-exec-2:ctx-6c894fdd ctx-99f95792) Refusing to design this network
> 2014-08-06 21:42:22,915 DEBUG [o.a.c.n.g.SspGuestNetworkGuru]
> (catalina-exec-2:ctx-6c894fdd ctx-99f95792) SSP not configured to be active
> 2014-08-06 21:42:22,917 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru]
> (catalina-exec-2:ctx-6c894fdd ctx-99f95792) Refusing to design this network
> 2014-08-06 21:42:22,919 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru]
> (catalina-exec-2:ctx-6c894fdd ctx-99f95792) Refusing to design this network
> 2014-08-06 21:42:22,920 DEBUG [o.a.c.e.o.NetworkOrchestrator]
> (catalina-exec-2:ctx-6c894fdd ctx-99f95792) Releasing lock for
> Acct[6ee1e382-fe5b-4571-a9cb-a8a7cb85665d-test]
> 2014-08-06 21:42:22,967 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-2:ctx-6c894fdd ctx-99f95792) ===END===  10.144.7.6 -- GET
>  
> command=createNetwork&response=json&sessionkey=IyiV1YiWuFVSGa7GynZv5T12nLk%3D&networkOfferingId=94cef53e-49ec-4a9f-a0fc-f82f0e40aba5&name=test&displayText=test&zoneId=29d069ac-e1ea-45dc-8c35-dd5b6c628ce2&_=1407340991296
> 2014-08-06 21:42:23,018 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-25:ctx-e2a0589a) ===START===  10.144.7.6 -- GET
>  
> command=deployVirtualMachine&response=json&sessionkey=IyiV1YiWuFVSGa7GynZv5T12nLk%3D&zoneid=29d069ac-e1ea-45dc-8c35-dd5b6c628ce2&templateid=991edabc-9662-4244-ad92-85f732a9f024&hypervisor=XenServer&servi

Jenkins build is still unstable: simulator-singlerun #78

[jenkins]

See 

Re: What is the behaviour of VPC Reset?

[Alena Prokharchyk]

Suresh,

Yes, it does. All the rules for all the networks inside the VPC, are being
reapplied on the VPC VR after its up.

I don¹t see it being documented neither in the FS, nor in the API itself.
Please file a CS doc bug on that.

-Alena.

On 8/7/14, 3:40 PM, "Suresh Ramamurthy"
 wrote:

>Hi Alena, Sheng Yang,
>
>Could you please shed some light on the behaviour of VPC Reset
>functionality?
>
>When I went through the code, VPC Reset shuts down the VR and restarts it.
>Does it also clean all ACL, NAT etc associated to all the tiers in the VPC
>and then reconfigure the current value?
>
>Is there any document that I can read to get an idea about the behaviour?
>
>Thanks,
>Suresh Ramamurthy

Re: What is the behaviour of VPC Reset?

[Suresh Ramamurthy]

Hi Alena,

Thanks for quick response.

But, I do not see any code that makes a call to delete the rules and
reapplies it. If it reapplies how does it get the information for each tier
to reapply the ACLs.
I see that just shutdownVpc() API call is made and VPCVRElement just
invokes destroyRouter...

Am I missing something here. Can you please point me to code that deletes
and re-applies all Rules, NAT etc. Is it in VR code? I am trying to
understand the behaviour
so that I can replicate in our SDN solution.

I see this happening in case of Network Restart with clean up option.

Thanks,
Suresh




On Thu, Aug 7, 2014 at 4:32 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

> Suresh,
>
> Yes, it does. All the rules for all the networks inside the VPC, are being
> reapplied on the VPC VR after its up.
>
> I don¹t see it being documented neither in the FS, nor in the API itself.
> Please file a CS doc bug on that.
>
> -Alena.
>
> On 8/7/14, 3:40 PM, "Suresh Ramamurthy"
>  wrote:
>
> >Hi Alena, Sheng Yang,
> >
> >Could you please shed some light on the behaviour of VPC Reset
> >functionality?
> >
> >When I went through the code, VPC Reset shuts down the VR and restarts it.
> >Does it also clean all ACL, NAT etc associated to all the tiers in the VPC
> >and then reconfigure the current value?
> >
> >Is there any document that I can read to get an idea about the behaviour?
> >
> >Thanks,
> >Suresh Ramamurthy
>
>

Jenkins build is still unstable: simulator-singlerun #79

[jenkins]

See 

Jenkins build is still unstable: simulator-singlerun #80

[jenkins]

See 

Jenkins build is still unstable: simulator-singlerun #81

[jenkins]

See 

Jenkins build is still unstable: simulator-singlerun #82

[jenkins]

See 

Re: [ACS44] help on 4.4.1 wanted

[Rajani Karuturi]

Hi Daan,
I moved 5724,5744, 5753, 5910, 5975 to 'Future'

I am working 6634. However, this wont affect the release cycle as this is a
doc bug. I see that around 30 in the filter are also documentation bugs.
You might want to filter them out.

I will try to take a look at few more over the weekend.



On Thu, Aug 7, 2014 at 6:34 PM, Daan Hoogland 
wrote:

> H all,
>
> There are 6 issues marked as fixVersion 4.4.1 but also 106 with
> affectedVersion 4.4.0. Can all of you please weed through those/help
> triage them. I feel like I am alone in the desert and at the same time
> looking at a forest from between the trees, i.e. helpless
>
> Please help me get something out that is an improvement on the current
> state of things?
> --
> Daan
>



-- 
~Rajani