Re: Review Request 24313: CLOUDSTACK-7255: Fixed marvin issue related to creating random account usernames

[Gaurav Aradhye]

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


Gentle Reminder

- Gaurav Aradhye


On Aug. 5, 2014, 7:37 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24313/
> ---
> 
> (Updated Aug. 5, 2014, 7:37 p.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-7255
> https://issues.apache.org/jira/browse/CLOUDSTACK-7255
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Few test cases failed with "Entity already exists" while creating account 
> because the account name already existed in the setup.
> We append random string to the username to make account names unique. Also 
> the account name should be less than 99 chars.
> But in case where the original username becomes greater than 99 chars, 
> appending random string to it and trimming it back to 99 chars does not make 
> any difference to the original string.
> 
> In this case the username should be trimmed first and then random string 
> should be appended to make the account name unique.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/lib/base.py eb05a18 
> 
> Diff: https://reviews.apache.org/r/24313/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> Test router internal basic zone ... SKIP: Marvin configuration has no host 
> credentials to check router services
> 
> --
> Ran 1 test in 141.558s
> 
> OK (SKIP=1)
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

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'

[Gaurav Aradhye]

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


Gentle Reminder

- Gaurav Aradhye


On Aug. 5, 2014, 8:43 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24298/
> ---
> 
> (Updated Aug. 5, 2014, 8:43 p.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 1386830 
> 
> 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 24232: Removing invalid and unused import from test_escalations_templates.py

[Gaurav Aradhye]

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


Gentle Reminder

- Gaurav Aradhye


On Aug. 5, 2014, 6:28 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24232/
> ---
> 
> (Updated Aug. 5, 2014, 6:28 p.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Removed invalid and unused import which was causing failure.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_escalations_templates.py 06e3d42 
> 
> Diff: https://reviews.apache.org/r/24232/diff/
> 
> 
> Testing
> ---
> 
> Tested with python command.
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 24302: CLOUDSTACK-7241: Fixed error in test_escalations_ipaddresses.py

[Gaurav Aradhye]

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


Gentle Reminder

- Gaurav Aradhye


On Aug. 5, 2014, 5:34 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24302/
> ---
> 
> (Updated Aug. 5, 2014, 5:34 p.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-7241
> https://issues.apache.org/jira/browse/CLOUDSTACK-7241
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Test cases failed due to invalid expung (should have been expunge). But now 
> expunge method call is not needed as by default the VMs will get expunged 
> when destroyed.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_escalations_ipaddresses.py 66be52e 
> 
> Diff: https://reviews.apache.org/r/24302/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> 
> @summary: Test to Assign and Remove Load Balancer Rule to an Instance ... === 
> TestName: test_07_assign_remove_lbrule_toinstance | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 423.142s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Build failed in Jenkins: simulator-singlerun #62

[jenkins]

See 

--
[...truncated 7278 lines...]
[INFO] 
[INFO] --- properties-maven-plugin:1.0-alpha-2:read-project-properties 
(default) @ cloud-developer ---
[WARNING] Ignoring missing properties file: 

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-developer ---
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run (default) @ cloud-developer ---
[INFO] Executing tasks

main:
[INFO] Executed tasks
[INFO] 
[INFO] >>> exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer >>>
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-developer ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] <<< exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer <<<
[INFO] 
[INFO] --- exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer ---
log4j:WARN No appenders could be found for logger 
(org.springframework.core.env.StandardEnvironment).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.
> WARNING: Provided file does not exist: 

> Initializing database=simulator with host=localhost port=3306 
username=cloud password=cloud
> Running query: drop database if exists `simulator`
> Running query: create database `simulator`
> Running query: GRANT ALL ON simulator.* to 'cloud'@`localhost` 
identified by 'cloud'
> Running query: GRANT ALL ON simulator.* to 'cloud'@`%` identified 
by 'cloud'
> Processing SQL file at 

> Processing SQL file at 

> Processing SQL file at 

> Processing upgrade: com.cloud.upgrade.DatabaseUpgradeChecker
[INFO] 
[INFO] --- maven-site-plugin:3.3:attach-descriptor (attach-descriptor) @ 
cloud-developer ---
[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ 
cloud-developer ---
[INFO] Installing 
 
to 
/var/lib/jenkins/.m2/repository/org/apache/cloudstack/cloud-developer/4.5.0-SNAPSHOT/cloud-developer-4.5.0-SNAPSHOT.pom
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 20.166s
[INFO] Finished at: Wed Aug 06 02:52:11 EDT 2014
[INFO] Final Memory: 41M/174M
[INFO] 
[simulator-singlerun] $ /bin/bash -x /tmp/hudson8292279352517421091.sh
+ jps -l
+ grep -q Launcher
+ rm -f xunit.xml
+ rm -rf /tmp/MarvinLogs
+ echo Check for initialization of the management server
Check for initialization of the management server
+ COUNTER=0
+ SERVER_PID=6448
+ mvn -P systemvm,simulator -pl :cloud-client-ui jetty:run
+ '[' 0 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=1
+ '[' 1 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=2
+ '[' 2 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=3
+ '[' 3 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=4
+ '[' 4 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=5
+ '[' 5 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=6
+ '[' 6 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=7
+ '[' 7 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=8
+ '[' 8 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=9
+ '[' 9 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=10
+ '[' 10 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=11
+ '[' 11 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=12
+ '[' 12 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=13
+ '[' 13 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' je

Build failed in Jenkins: simulator-hotfix-trigger #14

[jenkins]

See 

Changes:

[Daan Hoogland] README: some sections from the prior version copied back in.

--
[...truncated 7093 lines...]
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-developer ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- properties-maven-plugin:1.0-alpha-2:read-project-properties 
(default) @ cloud-developer ---
[WARNING] Ignoring missing properties file: 

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-developer ---
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run (default) @ cloud-developer ---
[INFO] Executing tasks

main:
[INFO] Executed tasks
[INFO] 
[INFO] >>> exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer >>>
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-developer ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] <<< exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer <<<
[INFO] 
[INFO] --- exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer ---
log4j:WARN No appenders could be found for logger 
(org.springframework.core.env.StandardEnvironment).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.
> WARNING: Provided file does not exist: 

> Initializing database=simulator with host=localhost port=3306 
username=cloud password=cloud
> Running query: drop database if exists `simulator`
> Running query: create database `simulator`
> Running query: GRANT ALL ON simulator.* to 'cloud'@`localhost` 
identified by 'cloud'
> Running query: GRANT ALL ON simulator.* to 'cloud'@`%` identified 
by 'cloud'
> Processing SQL file at 

> Processing SQL file at 

> Processing SQL file at 

> Processing upgrade: com.cloud.upgrade.DatabaseUpgradeChecker
[INFO] 
[INFO] --- maven-site-plugin:3.3:attach-descriptor (attach-descriptor) @ 
cloud-developer ---
[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ 
cloud-developer ---
[INFO] Installing 

 to 
/var/lib/jenkins/.m2/repository/org/apache/cloudstack/cloud-developer/4.4.1-SNAPSHOT/cloud-developer-4.4.1-SNAPSHOT.pom
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 21.340s
[INFO] Finished at: Wed Aug 06 03:46:25 EDT 2014
[INFO] Final Memory: 41M/189M
[INFO] 
[simulator-hotfix-trigger] $ /bin/bash -x /tmp/hudson8652306815743348280.sh
+ jps -l
+ grep -q Launcher
+ rm -f xunit.xml
+ rm -rf /tmp/MarvinLogs
+ echo Check for initialization of the management server
Check for initialization of the management server
+ COUNTER=0
+ SERVER_PID=13965
+ '[' 0 -lt 44 ']'
+ mvn -P systemvm,simulator -pl :cloud-client-ui jetty:run
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=1
+ '[' 1 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=2
+ '[' 2 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=3
+ '[' 3 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=4
+ '[' 4 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=5
+ '[' 5 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=6
+ '[' 6 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=7
+ '[' 7 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=8
+ '[' 8 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=9
+ '[' 9 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=10
+ '[' 10 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=11
+ '[' 11 -lt 44 ']'
+ grep -

[ACS44] release 4.4.1

[Daan Hoogland]

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+BugFix+Release

Thanks
-- 
Daan

Re: Locking Down Hypervisor

[Wido den Hollander]

On 08/05/2014 11:51 PM, mo wrote:

Hello,

Is it permutable to install SSH keys on the hypervisor. Does Cloudstack speak 
often to the hypervisor, as I have ALL in one, KVM Centos 6.5



No problem. The management server doesn't require SSH access into the 
hypervisor after installation.


Wido


Please advise.

- Maurice

Re: Review Request 24313: CLOUDSTACK-7255: Fixed marvin issue related to creating random account usernames

[Gaurav Aradhye]

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

(Updated Aug. 6, 2014, 3:19 p.m.)


Review request for cloudstack and Santhosh Edukulla.


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


Repository: cloudstack-git


Description
---

Few test cases failed with "Entity already exists" while creating account 
because the account name already existed in the setup.
We append random string to the username to make account names unique. Also the 
account name should be less than 99 chars.
But in case where the original username becomes greater than 99 chars, 
appending random string to it and trimming it back to 99 chars does not make 
any difference to the original string.

In this case the username should be trimmed first and then random string should 
be appended to make the account name unique.


Diffs (updated)
-

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

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


Testing
---

Yes.

Test router internal basic zone ... SKIP: Marvin configuration has no host 
credentials to check router services

--
Ran 1 test in 141.558s

OK (SKIP=1)


Thanks,

Gaurav Aradhye

Jenkins build is unstable: simulator-singlerun #63

[jenkins]

See 

Re: Review Request 24302: CLOUDSTACK-7241: Fixed error in test_escalations_ipaddresses.py

[Santhosh Edukulla]

> On Aug. 6, 2014, 7:09 a.m., Gaurav Aradhye wrote:
> > Gentle Reminder

Pushed to master.dda2820..adcfdf2  master -> master


- Santhosh


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


On Aug. 5, 2014, 12:04 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24302/
> ---
> 
> (Updated Aug. 5, 2014, 12:04 p.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-7241
> https://issues.apache.org/jira/browse/CLOUDSTACK-7241
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Test cases failed due to invalid expung (should have been expunge). But now 
> expunge method call is not needed as by default the VMs will get expunged 
> when destroyed.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_escalations_ipaddresses.py 66be52e 
> 
> Diff: https://reviews.apache.org/r/24302/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> 
> @summary: Test to Assign and Remove Load Balancer Rule to an Instance ... === 
> TestName: test_07_assign_remove_lbrule_toinstance | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 423.142s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 24302: CLOUDSTACK-7241: Fixed error in test_escalations_ipaddresses.py

[ASF Subversion and Git Services]

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


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

CLOUDSTACK-7241: Fixed error in test_escalations_ipaddresses.py

Signed-off-by: Santhosh Edukulla 


- ASF Subversion and Git Services


On Aug. 5, 2014, 12:04 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24302/
> ---
> 
> (Updated Aug. 5, 2014, 12:04 p.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-7241
> https://issues.apache.org/jira/browse/CLOUDSTACK-7241
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Test cases failed due to invalid expung (should have been expunge). But now 
> expunge method call is not needed as by default the VMs will get expunged 
> when destroyed.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_escalations_ipaddresses.py 66be52e 
> 
> Diff: https://reviews.apache.org/r/24302/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> 
> @summary: Test to Assign and Remove Load Balancer Rule to an Instance ... === 
> TestName: test_07_assign_remove_lbrule_toinstance | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 423.142s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

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'

[Santhosh Edukulla]

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



test/integration/smoke/misc/test_deploy_vm.py


why we need a new tag?


- Santhosh Edukulla


On Aug. 5, 2014, 3:13 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24298/
> ---
> 
> (Updated Aug. 5, 2014, 3:13 p.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 1386830 
> 
> 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 24232: Removing invalid and unused import from test_escalations_templates.py

[Santhosh Edukulla]

> On Aug. 6, 2014, 7:09 a.m., Gaurav Aradhye wrote:
> > Gentle Reminder

 adcfdf2..c38a15f  master -> master


- Santhosh


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


On Aug. 5, 2014, 12:58 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24232/
> ---
> 
> (Updated Aug. 5, 2014, 12:58 p.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Removed invalid and unused import which was causing failure.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_escalations_templates.py 06e3d42 
> 
> Diff: https://reviews.apache.org/r/24232/diff/
> 
> 
> Testing
> ---
> 
> Tested with python command.
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

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

[Saksham Srivastava]

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.dns1 dns1,
data_center.dns2 dns2,
data_center.ip6_dns1 ip6_dns1,
data_center.ip6_dns2 ip6_dns2,
host.id host_id,
host.uuid host_uuid,
host.name host_name,
   host.hypervisor_type,
host.cluster_id cluster_id,
vm_template.id template_id,
vm_template.uuid template_uuid,
service_offering.id service_offering_id,
disk_offering.uuid service_offering_uuid,
disk_offering.name service_offering_name,
nics.id nic_id,
nics.uuid nic_uuid,
nics.network_id network_id,
nics.ip4_address ip_address,
nics.ip6_address ip6_address,
nics.ip6_gateway ip6_gateway,
nics.ip6_cidr ip6_cidr,
nics.default_nic is_default_nic,
nics.gateway gateway,
nics.netmask netmask,
nics.mac_address mac_address,
nics.broadcast_uri broadcast_uri,
nics.isolation_uri isolation_uri,
vpc.id vpc_id,
vpc.uuid vpc_uuid,
networks.uuid network_uuid,
networks.name network_name,
networks.network_domain network_domain,
networks.traffic_type traffic_type,
networks.guest_type guest_type,
async_job.id job_id,
async_job.uuid job_uuid,
async_job.job_status job_status,
async_job.account_id job_account_id,
domain_router.template_version template_version,
domain_router.scripts_version scripts_version,
domain_router.is_redundant_router is_redundant_router,
domain_router.redundant_state redundant_state,
domain_router.stop_pending stop_pending,
domain_router.role role
from
`cloud`.`domain_router`
   inner join
`cloud`.`vm_instance` ON vm_instance.id = domain_router.id
inner join
`cloud`.`account` ON vm_instance.account_id = account.id
inner join
`cloud`.`domain` ON vm_instance.domain_id = domain.id
left join
`cloud`.`host_pod_ref` ON vm_instance.pod_id = host_pod_ref.id
left join
`cloud`.`projects` ON projects.project_account_id = account.id
left join
`cloud`.`data_center` ON vm_instance.data_center_id = data_center.id
left join
`cloud`.`host` ON vm_instance.host_id = host.id
left join
`cloud`.`vm_template` ON vm_instance.vm_template_id = vm_template.id
left join
   `cloud`.`service_offering` ON vm_instance.service_offering_id = 
service_offering.id
left join
`cloud`.`disk_offering` ON vm_instance.service_offering_id = 
disk_offering.id
left join
`cloud`.`nics` ON vm_instance.id = nics.instance_id and nics.removed is 
null
left join
`cloud`.`networks` ON nics.network_id = networks.id
left join
`cloud`.`vpc` ON domain_router.vpc_id = vpc.id and vpc.removed is null
left join
`cloud`.`async_job` ON async_job.instance_id = vm_instance.id
and async_job.instance_type = 'DomainRouter'
and async_job.job_status = 0;



Thanks,
Saksham

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

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: Locking Down Hypervisor

[Mo]

Awesome, thank you!

Sent from my iPhone

> On Aug 6, 2014, at 5:08 AM, Wido den Hollander  wrote:
> 
> 
> 
>> On 08/05/2014 11:51 PM, mo wrote:
>> Hello,
>> 
>> Is it permutable to install SSH keys on the hypervisor. Does Cloudstack 
>> speak often to the hypervisor, as I have ALL in one, KVM Centos 6.5
> 
> No problem. The management server doesn't require SSH access into the 
> hypervisor after installation.
> 
> Wido
> 
>> Please advise.
>> 
>> - Maurice
>> 

Re: Review Request 24313: CLOUDSTACK-7255: Fixed marvin issue related to creating random account usernames

[ASF Subversion and Git Services]

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


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

CLOUDSTACK-7255: Fixed marvin issue related to creating random account usernames

Signed-off-by: Santhosh Edukulla 


- ASF Subversion and Git Services


On Aug. 6, 2014, 9:49 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24313/
> ---
> 
> (Updated Aug. 6, 2014, 9:49 a.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-7255
> https://issues.apache.org/jira/browse/CLOUDSTACK-7255
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Few test cases failed with "Entity already exists" while creating account 
> because the account name already existed in the setup.
> We append random string to the username to make account names unique. Also 
> the account name should be less than 99 chars.
> But in case where the original username becomes greater than 99 chars, 
> appending random string to it and trimming it back to 99 chars does not make 
> any difference to the original string.
> 
> In this case the username should be trimmed first and then random string 
> should be appended to make the account name unique.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/lib/base.py 3a1f7e6 
> 
> Diff: https://reviews.apache.org/r/24313/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> Test router internal basic zone ... SKIP: Marvin configuration has no host 
> credentials to check router services
> 
> --
> Ran 1 test in 141.558s
> 
> OK (SKIP=1)
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

How to config linux native bridge to forward vxlan encapsulated pkts

[Michael Li]

Does anyone meet this issue:
Create VM using vxlan for isolation guest network,
 both brvx-139 and vxlan139 is created,
tcpdump can see the pkts has been encapsulated and forward to cloudbr1, but 
cloudbr1 does not forward pkts out from eth1, is there some special 
configuration on eth1, cloudbr1 or routes ? Does the fdb or mdb learn the 
address automically ?

Regards

Jenkins build is still unstable: simulator-singlerun #64

[jenkins]

See 

Re: master branch will be frozen for direct commits on 7 Aug 2014

[Rajani Karuturi]

Since we have seen some activity and -1s on the [vote thread], I planning to 
postpone this activity until we agree.

[vote thread] http://markmail.org/message/3qq7ihq6pg3ii7bu

~Rajani



On 05-Aug-2014, at 3:59 pm, Rajani Karuturi 
mailto:rajani.karut...@citrix.com>> wrote:

I deleted the develop branch and will be recreating it in 48hrs.

As per the new git flow which we agreed, all the next release work should move 
to develop branch and there shouldn’t be any direct commits on master.

Please make sure you go through wiki @ 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git and plan your work 
accordingly.

Thanks,
~Rajani

Re: MonkeyMan-1.0.0

[Rohit Yadav]

+ Dev ML

This is great thanks for Sharing Vladimir!

On 05-Aug-2014, at 10:48 pm, Vladimir Melnik  wrote:

> Dear colleagues,
>
> The 1.0.0 version has been released, the development branch has been merged 
> to the stable one.
>
> Now you can use bin/makesnapshots.pl to automatically create snapshots by 
> your own schedule. For example, you want snapshots for some volumes to be 
> taken only in the night, but some of them should be taken only on Saturdays, 
> also you want the planner to start not more than 2 parallel jobs for a 
> storagepool, oldest snapshots shall be deleted, but 2 latest snapshots shall 
> be kept, etc... And you can easily configure it, make sure how easy it is: 
> https://github.com/melnik13/monkeyman/blob/stables/etc/backup_schedule.conf.example
>  :)
>
> Feel free to download and use MonkeyMan, any feedback will be greatly 
> appreciated.
>
> The project's website: http://monkeyman.tucha.ua/
> The project's Twitter: https://twitter.com/monkey13man
>
> --
> V.Melnik

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.

jenkins changes post git-flow shift

[Rajani Karuturi]

Hi all,
post git flow related branching changes, we need to change the jenkins jobs
which run on master to the new unstable branch(develop)

everything under master tab @ http://jenkins.buildacloud.org/ should change
to the new branch.

looking for volunteers who can help with this. Anyone?

-- 
~Rajani

Re: jenkins changes post git-flow shift

[Erik Weber]

On Wed, Aug 6, 2014 at 1:39 PM, Rajani Karuturi  wrote:

> Hi all,
> post git flow related branching changes, we need to change the jenkins jobs
> which run on master to the new unstable branch(develop)
>
> everything under master tab @ http://jenkins.buildacloud.org/ should
> change
> to the new branch.
>
> looking for volunteers who can help with this. Anyone?
>
>

I don't mind giving a hand as long as time allows.

-- 
Erik Weber

Re: [ACS44] release 4.4.1

[Erik Weber]

On Wed, Aug 6, 2014 at 10: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+BugFix+Release
>
>
Thanks for your effort Daan.

I'll do my best to test what i consider the most critical part of the 4.4.0
release, the system vms, as time allows. Unfortunately it won't be until
later this week.

It would be great if as many as possible test this release, particularily
if you have changed or introduced something new.
Get those hypervisors running and verify that it's running smoothly.


-- 
Erik

Re: jenkins changes post git-flow shift

[Hugo Trippaers]

I’ll configure a new develop branch pipeline and configure jobs to check 
feature and hotfix branches both with the simulator and the regular builds when 
we create the develop branch. We don’t need to change the master build, just 
add another pipeline for develop.

Cheers,

Hugo



On 6 aug. 2014, at 13:39, Rajani Karuturi  wrote:

> Hi all,
> post git flow related branching changes, we need to change the jenkins jobs
> which run on master to the new unstable branch(develop)
> 
> everything under master tab @ http://jenkins.buildacloud.org/ should change
> to the new branch.
> 
> looking for volunteers who can help with this. Anyone?
> 
> -- 
> ~Rajani

Re: DashBoard Stats

[Pierre-Luc Dion]

Do you look for something like the Resources tab under :  Infrastructure->
Zones-> zonename -> Resources ?



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

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



On Tue, Aug 5, 2014 at 1:11 PM, mo  wrote:

> Hello,
>
> Could someone please tell me, how I can obtain latest stats to be included
> in % for Secondary Storage | Primary Storage. It shows what I have used so
> far, but not the precent, like the others.
>
>
>

Re: jenkins changes post git-flow shift

[Rajani Karuturi]

Thanks Erik and Hugo.
coverity job should be moved to develop branch. Rest all can exist both on
master and develop.


On Wed, Aug 6, 2014 at 5:38 PM, Hugo Trippaers  wrote:

> I’ll configure a new develop branch pipeline and configure jobs to check
> feature and hotfix branches both with the simulator and the regular builds
> when we create the develop branch. We don’t need to change the master
> build, just add another pipeline for develop.
>
> Cheers,
>
> Hugo
>
>
>
> On 6 aug. 2014, at 13:39, Rajani Karuturi  wrote:
>
> > Hi all,
> > post git flow related branching changes, we need to change the jenkins
> jobs
> > which run on master to the new unstable branch(develop)
> >
> > everything under master tab @ http://jenkins.buildacloud.org/ should
> change
> > to the new branch.
> >
> > looking for volunteers who can help with this. Anyone?
> >
> > --
> > ~Rajani
>
>


-- 
~Rajani

Build failed in Jenkins: simulator-singlerun #65

[jenkins]

See 

Changes:

[santhosh.edukulla] CLOUDSTACK-7255: Fixed marvin issue related to creating 
random account usernames

--
[...truncated 7294 lines...]

main:
[INFO] Executed tasks
[INFO] 
[INFO] >>> exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer >>>
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-developer ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] <<< exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer <<<
[INFO] 
[INFO] --- exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer ---
log4j:WARN No appenders could be found for logger 
(org.springframework.core.env.StandardEnvironment).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.
> WARNING: Provided file does not exist: 

> Initializing database=simulator with host=localhost port=3306 
username=cloud password=cloud
> Running query: drop database if exists `simulator`
> Running query: create database `simulator`
> Running query: GRANT ALL ON simulator.* to 'cloud'@`localhost` 
identified by 'cloud'
> Running query: GRANT ALL ON simulator.* to 'cloud'@`%` identified 
by 'cloud'
> Processing SQL file at 

> Processing SQL file at 

> Processing SQL file at 

> Processing upgrade: com.cloud.upgrade.DatabaseUpgradeChecker
[INFO] 
[INFO] --- maven-site-plugin:3.3:attach-descriptor (attach-descriptor) @ 
cloud-developer ---
[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ 
cloud-developer ---
[INFO] Installing 
 
to 
/var/lib/jenkins/.m2/repository/org/apache/cloudstack/cloud-developer/4.5.0-SNAPSHOT/cloud-developer-4.5.0-SNAPSHOT.pom
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 34.145s
[INFO] Finished at: Wed Aug 06 07:36:24 EDT 2014
[INFO] Final Memory: 41M/182M
[INFO] 
[simulator-singlerun] $ /bin/bash -x /tmp/hudson6077538196103336035.sh
+ jps -l
+ grep -q Launcher
+ rm -f xunit.xml
+ rm -rf /tmp/MarvinLogs
+ echo Check for initialization of the management server
Check for initialization of the management server
+ COUNTER=0
+ SERVER_PID=4821
+ '[' 0 -lt 44 ']'
+ mvn -P systemvm,simulator -pl :cloud-client-ui jetty:run
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=1
+ '[' 1 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=2
+ '[' 2 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=3
+ '[' 3 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=4
+ '[' 4 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=5
+ '[' 5 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=6
+ '[' 6 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=7
+ '[' 7 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=8
+ '[' 8 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=9
+ '[' 9 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=10
+ '[' 10 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=11
+ '[' 11 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=12
+ '[' 12 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=13
+ '[' 13 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=14
+ '[' 14 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=15
+ '[' 15 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=16
+ '[' 16 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-out

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

[Koushik Das]

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.dns1 dns1,
data_center.dns2 dns2,
data_center.ip6_dns1 ip6_dns1,
data_center.ip6_dns2 ip6_dns2,
host.id host_id,
host.uuid host_uuid,
host.name host_name,
   host.hypervisor_type,
host.cluster_id cluster_id,
vm_template.id template_id,
vm_template.uuid template_uuid,
service_offering.id service_offering_id,
disk_offering.uuid service_offering_uuid,
disk_offering.name service_offering_name,
nics.id nic_id,
nics.uuid nic_uuid,
nics.network_id network_id,
nics.ip4_address ip_address,
nics.ip6_address ip6_address,
nics.ip6_gateway ip6_gateway,
nics.ip6_cidr ip6_cidr,
nics.default_nic is_default_nic,
nics.gateway gateway,
nics.netmask netmask,
nics.mac_address mac_address,
nics.broadcast_uri broadcast_uri,
nics.isolation_uri isolation_uri,
vpc.id vpc_id,
vpc.uuid vpc_uuid,
networks.uuid network_uuid,
networks.name network_name,
networks.network_domain network_domain,
networks.traffic_type traffic_type,
networks.guest_type guest_type,
async_job.id job_id,
async_job.uuid job_uuid,
async_job.job_status job_status,
async_job.account_id job_account_id,
domain_router.template_version template_version,
domain_router.scripts_version scripts_version,
domain_router.is_redundant_router is_redundant_router,
domain_router.redundant_state redundant_state,
domain_router.stop_pending stop_pending,
domain_router.role role
from
`cloud`.`domain_router`
   inner join
`cloud`.`vm_instance` ON vm_instance.id = domain_router.id
inner join
`cloud`.`account` ON vm_instance.account_id = account.id
inner join
`cloud`.`domain` ON vm_instance.domain_id = domain.id
left join
`cloud`.`host_pod_ref` ON vm_instance.pod_id = host_pod_ref.id
left join
`cloud`.`projects` ON projects.project_account_id = account.id
left join
`cloud`.`data_center` ON vm_instance.data_center_id = data_center.id
left join
`cloud`.`host` ON vm_instance.host_id = host.id
left join
`cloud`.`vm_template` ON vm_instance.vm_template_id = vm_template.id
left join
   `cloud`.`service_offering` ON vm_instance.service_offering_id = 
service_offering.id
left join
`cloud`.`disk_offering` ON vm_instance.service_offering_id = 
disk_offering.id
left join
`cloud`.`nics` ON vm_instance.id = nics.instance_id and nics.removed is 
null
left join
`cloud`.`networks` ON nics.network_id = networks.id
left join
`cloud`.`vpc` ON domain_router.vpc_id = vpc.id and vpc.removed is null
left join
`cloud`.`async_job` ON async_job.instance_id = 

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'

[Gaurav Aradhye]

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

(Updated Aug. 6, 2014, 6:03 p.m.)


Review request for cloudstack and Santhosh Edukulla.


Changes
---

Instead of adding new simulator_only tag, set value of 
required_hardware="simulator only"


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 (updated)
-

  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 1386830 

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

[Gaurav Aradhye]

> On Aug. 6, 2014, 3:31 p.m., Santhosh Edukulla wrote:
> > test/integration/smoke/misc/test_deploy_vm.py, line 85
> > 
> >
> > why we need a new tag?

Removed the new tag and assigned "simulator only" value to required_hardware 
flag.


- Gaurav


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


On Aug. 6, 2014, 6:03 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24298/
> ---
> 
> (Updated Aug. 6, 2014, 6:03 p.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 1386830 
> 
> Diff: https://reviews.apache.org/r/24298/diff/
> 
> 
> Testing
> ---
> 
> Yes, tested test_vm_life_cycle.py with python command.
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

branch hotfix/coverity-fixes

[Hugo Trippaers]

Heya,

How about we name the branches for coverity fixes after the relevant CID?  
Something like /hotfix/CID-xx.  That would make it very easy for everyone 
to track which coverity fixes are tracked where and who is working on which CID.

The name hotfix coverity fix is a bit too generic and will probably not help 
developers pinpoint where an issue was introduced.


Cheers,

Hugo

Re: branch hotfix/coverity-fixes

[Rohit Yadav]

Hi Hugo,

+1

On a totally different issue, if we’re going to adopt git-flow let’s not use 
bug fix branch names with the prefix “hotfix/“ because as the per convention 
it’s for already released versions and for serious production issues. Instead, 
I recommend that we can either go with “feature/CID-” as all features 
should have bug ids and bugfixes should have them too.

Lastly, we can in-fact use custom names in git-flow so we can use something 
like “bugfix/ID” like “bugfix/1234” so we don’t even have to add the 
"CLOUDSTACK-“ prefix and it’s more readable. The commits though should have the 
full name “CLOUDSTACK-xxx” to be picked up by ASFBot.

Cheers.


On 06-Aug-2014, at 2:39 pm, Hugo Trippaers  wrote:

> Heya,
>
> How about we name the branches for coverity fixes after the relevant CID?  
> Something like /hotfix/CID-xx.  That would make it very easy for everyone 
> to track which coverity fixes are tracked where and who is working on which 
> CID.
>
> The name hotfix coverity fix is a bit too generic and will probably not help 
> developers pinpoint where an issue was introduced.
>
>
> Cheers,
>
> Hugo

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: branch hotfix/coverity-fixes

[Hugo Trippaers]

On 6 aug. 2014, at 15:06, Rohit Yadav  wrote:

> Hi Hugo,
> 
> +1
> 
> On a totally different issue, if we’re going to adopt git-flow let’s not use 
> bug fix branch names with the prefix “hotfix/“ because as the per convention 
> it’s for already released versions and for serious production issues. 
> Instead, I recommend that we can either go with “feature/CID-” as all 
> features should have bug ids and bugfixes should have them too.

Feature sounds a bit strange to me for bugs coming out of static code analysis. 
Typically they are bugs in released versions (unless we really fix the lot of 
them ;-) ) The seriousness is up for debate and varies issue by issue.

> 
> Lastly, we can in-fact use custom names in git-flow so we can use something 
> like “bugfix/ID” like “bugfix/1234” so we don’t even have to add the 
> "CLOUDSTACK-“ prefix and it’s more readable. The commits though should have 
> the full name “CLOUDSTACK-xxx” to be picked up by ASFBot.

These are not jira issues, but coverity issues. ASFbot doesn’t now about them.  
They are for now manually tracked in the coverity interface.


> 
> Cheers.
> 
> 
> On 06-Aug-2014, at 2:39 pm, Hugo Trippaers  wrote:
> 
>> Heya,
>> 
>> How about we name the branches for coverity fixes after the relevant CID?  
>> Something like /hotfix/CID-xx.  That would make it very easy for 
>> everyone to track which coverity fixes are tracked where and who is working 
>> on which CID.
>> 
>> The name hotfix coverity fix is a bit too generic and will probably not help 
>> developers pinpoint where an issue was introduced.
>> 
>> 
>> Cheers,
>> 
>> Hugo
> 
> 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: branch hotfix/coverity-fixes

[Rohit Yadav]

Hey,

On 06-Aug-2014, at 3:10 pm, Hugo Trippaers  wrote:

>
> On 6 aug. 2014, at 15:06, Rohit Yadav  wrote:
>
>> Hi Hugo,
>>
>> +1
>>
>> On a totally different issue, if we’re going to adopt git-flow let’s not use 
>> bug fix branch names with the prefix “hotfix/“ because as the per convention 
>> it’s for already released versions and for serious production issues. 
>> Instead, I recommend that we can either go with “feature/CID-” as all 
>> features should have bug ids and bugfixes should have them too.
>
> Feature sounds a bit strange to me for bugs coming out of static code 
> analysis. Typically they are bugs in released versions (unless we really fix 
> the lot of them ;-) ) The seriousness is up for debate and varies issue by 
> issue.

Oh, the CID abbr looked like you’re saying CLOUDSTACKID.

>
>>
>> Lastly, we can in-fact use custom names in git-flow so we can use something 
>> like “bugfix/ID” like “bugfix/1234” so we don’t even have to add the 
>> "CLOUDSTACK-“ prefix and it’s more readable. The commits though should have 
>> the full name “CLOUDSTACK-xxx” to be picked up by ASFBot.
>
> These are not jira issues, but coverity issues. ASFbot doesn’t now about 
> them.  They are for now manually tracked in the coverity interface.

“hotfix/" sounds like the branch will have a serious/production issue getting 
fixed.
How about you give it, bugfix/coverity/xxx ?



Regards.

>
>
>>
>> Cheers.
>>
>>
>> On 06-Aug-2014, at 2:39 pm, Hugo Trippaers  wrote:
>>
>>> Heya,
>>>
>>> How about we name the branches for coverity fixes after the relevant CID?  
>>> Something like /hotfix/CID-xx.  That would make it very easy for 
>>> everyone to track which coverity fixes are tracked where and who is working 
>>> on which CID.
>>>
>>> The name hotfix coverity fix is a bit too generic and will probably not 
>>> help developers pinpoint where an issue was introduced.
>>>
>>>
>>> Cheers,
>>>
>>> Hugo
>>
>> 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

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 

Re: branch hotfix/coverity-fixes

[Hugo Trippaers]

On 6 aug. 2014, at 15:15, Rohit Yadav  wrote:

> Hey,
> 
> On 06-Aug-2014, at 3:10 pm, Hugo Trippaers  wrote:
> 
>> 
>> On 6 aug. 2014, at 15:06, Rohit Yadav  wrote:
>> 
>>> Hi Hugo,
>>> 
>>> +1
>>> 
>>> On a totally different issue, if we’re going to adopt git-flow let’s not 
>>> use bug fix branch names with the prefix “hotfix/“ because as the per 
>>> convention it’s for already released versions and for serious production 
>>> issues. Instead, I recommend that we can either go with “feature/CID-” 
>>> as all features should have bug ids and bugfixes should have them too.
>> 
>> Feature sounds a bit strange to me for bugs coming out of static code 
>> analysis. Typically they are bugs in released versions (unless we really fix 
>> the lot of them ;-) ) The seriousness is up for debate and varies issue by 
>> issue.
> 
> Oh, the CID abbr looked like you’re saying CLOUDSTACKID.
> 
>> 
>>> 
>>> Lastly, we can in-fact use custom names in git-flow so we can use something 
>>> like “bugfix/ID” like “bugfix/1234” so we don’t even have to add the 
>>> "CLOUDSTACK-“ prefix and it’s more readable. The commits though should have 
>>> the full name “CLOUDSTACK-xxx” to be picked up by ASFBot.
>> 
>> These are not jira issues, but coverity issues. ASFbot doesn’t now about 
>> them.  They are for now manually tracked in the coverity interface.
> 
> “hotfix/" sounds like the branch will have a serious/production issue getting 
> fixed.
> How about you give it, bugfix/coverity/xxx ?

That sounds about right.  :-)

Ranjani, Santosh agreed?

> 
> 
> 
> Regards.
> 
>> 
>> 
>>> 
>>> Cheers.
>>> 
>>> 
>>> On 06-Aug-2014, at 2:39 pm, Hugo Trippaers  wrote:
>>> 
 Heya,
 
 How about we name the branches for coverity fixes after the relevant CID?  
 Something like /hotfix/CID-xx.  That would make it very easy for 
 everyone to track which coverity fixes are tracked where and who is 
 working on which CID.
 
 The name hotfix coverity fix is a bit too generic and will probably not 
 help developers pinpoint where an issue was introduced.
 
 
 Cheers,
 
 Hugo
>>> 
>>> 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
> 
> 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 t

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'

[Doug Clark]

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



test/integration/smoke/misc/test_deploy_vm.py


Generally, how does putting these test in a separate directory help?  
Doesn't nosetests recursively search for tests.



test/integration/smoke/misc/test_deploy_vm.py


In the previous comment an exception in tearDown resulted in an exception 
being raised - here we just output a debug to the logs - can we make this 
consistent?



test/integration/smoke/test_vm_life_cycle.py


What is the advantage of catching an exception only to immediately re-raise 
it?

Will the stack trace for the original exception still appear in the logs?


- Doug Clark


On Aug. 6, 2014, 12:33 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24298/
> ---
> 
> (Updated Aug. 6, 2014, 12:33 p.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 1386830 
> 
> Diff: https://reviews.apache.org/r/24298/diff/
> 
> 
> Testing
> ---
> 
> Yes, tested test_vm_life_cycle.py with python command.
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Usage: Network deletion causes IP address entry to be permanently removed

[Rohit Yadav]

Hi,

When public IP range or a shared network is removed, we found that the ip 
address DB entries were getting permanently removed instead of being marked as 
released/removed. The issue is that the usage server still holds reference to 
these resources (ip address in this case) and listing of usage records causes 
NPE because the (user_ip_address) rows don’t exist. [1]

It was tested to be found in 4.2.1 and 4.3.0, and from code in 4.4.0 and master 
as well. Is this intentional or how should we fix it? Remove entries from 
usage, or add a column in cloud_usage that says this entry’s ref was removed or 
should we mark the entry in user_ip_address table as removed but not actually 
delete the entry?

[1] https://issues.apache.org/jira/browse/CLOUDSTACK-7270

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: branch hotfix/coverity-fixes

[Daan Hoogland]

Let's consider gitflow and the number of prefixes it suppprts.

biligual spelling checker used.read at your own risk
Op 6 aug. 2014 15:18 schreef "Hugo Trippaers" :

>
> On 6 aug. 2014, at 15:15, Rohit Yadav  wrote:
>
> > Hey,
> >
> > On 06-Aug-2014, at 3:10 pm, Hugo Trippaers  wrote:
> >
> >>
> >> On 6 aug. 2014, at 15:06, Rohit Yadav 
> wrote:
> >>
> >>> Hi Hugo,
> >>>
> >>> +1
> >>>
> >>> On a totally different issue, if we’re going to adopt git-flow let’s
> not use bug fix branch names with the prefix “hotfix/“ because as the per
> convention it’s for already released versions and for serious production
> issues. Instead, I recommend that we can either go with “feature/CID-”
> as all features should have bug ids and bugfixes should have them too.
> >>
> >> Feature sounds a bit strange to me for bugs coming out of static code
> analysis. Typically they are bugs in released versions (unless we really
> fix the lot of them ;-) ) The seriousness is up for debate and varies issue
> by issue.
> >
> > Oh, the CID abbr looked like you’re saying CLOUDSTACKID.
> >
> >>
> >>>
> >>> Lastly, we can in-fact use custom names in git-flow so we can use
> something like “bugfix/ID” like “bugfix/1234” so we don’t even have to add
> the "CLOUDSTACK-“ prefix and it’s more readable. The commits though should
> have the full name “CLOUDSTACK-xxx” to be picked up by ASFBot.
> >>
> >> These are not jira issues, but coverity issues. ASFbot doesn’t now
> about them.  They are for now manually tracked in the coverity interface.
> >
> > “hotfix/" sounds like the branch will have a serious/production issue
> getting fixed.
> > How about you give it, bugfix/coverity/xxx ?
>
> That sounds about right.  :-)
>
> Ranjani, Santosh agreed?
>
> >
> >
> >
> > Regards.
> >
> >>
> >>
> >>>
> >>> Cheers.
> >>>
> >>>
> >>> On 06-Aug-2014, at 2:39 pm, Hugo Trippaers  wrote:
> >>>
>  Heya,
> 
>  How about we name the branches for coverity fixes after the relevant
> CID?  Something like /hotfix/CID-xx.  That would make it very easy for
> everyone to track which coverity fixes are tracked where and who is working
> on which CID.
> 
>  The name hotfix coverity fix is a bit too generic and will probably
> not help developers pinpoint where an issue was introduced.
> 
> 
>  Cheers,
> 
>  Hugo
> >>>
> >>> 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<
> http://shapeblue.com/csforge/>
> >>> 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.
> >
> > 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 re

Jenkins build is unstable: simulator-singlerun #66

[jenkins]

See 

Re: [VOTE] git workflow

[Rohit Yadav]

Hi,

Comments in-line;

On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk  
wrote:

> Rayees,
>
> I think you have the same misunderstanding as a lot of other folks
> (including myself) had in the beginning - seeing develop branch as a trunk
> branch that gets merged into master on a regular basis after the BVT/CI
> tests pass. So the master branch reflects the develop branch minus changes
> that didn¹t pass the tests and weren¹t merged into master -  lets refer to
> it as implementation #1
>
> That¹s not what git workflow/this thread proposes. In git workflow master
> branch reflects the latest stable release instead. So for example, we
> released 4.4, and that what you would see the master to be as we merge the
> *release branch to master, not the *develop to master. And develop branch
> becomes the trunk branch where all the new fixes go to. I would look at
> the master as at the stable branch, where you can track the history for
> all the major releases as for each of them the master branch has
> corresponding tags - lets call it implementation #2
>
> I still don¹t see many advantages in implementation #2 - making the master
> build stable by simply making it reflect the latest release branch.
> Because you:
>
> * never cut the release from master branch

We’ve a stable branch that gets rolling/continuous releases which is good.

> * if you are the customer, and need the latest stable code, you download
> the official RPM
> * if you are a developer, you always want to download the latest code, and
> that comes from *develop branch
> * if you want to look at the latest stable release, you look at the
> release branch as per CS git workflow implementation we never remove the
> release branches (they are needed for maintenance releases)

IMO We “should" remove the release branches when done. Instead there is a 
support workflow with git-flow (see support 
http://yakiloo.com/getting-started-git-flow/) and also in the tooling (git flow 
support etc. though experimental).

I’ll create a video to describe what we can do with this workflow, instead of 
going back and forth on the ML.
We don’t need to change our workflow, we can learn from this and adapt to our 
workflow.


> It would be great if anyone can point the advantages of #2 approach over
> #1, as to me #1 seems to be the approach most people will find more
> intuitive and its used a lot in the field.
>
> -Alena.
>
>
>
> On 8/5/14, 1:22 PM, "Rayees Namathponnan" 
> wrote:
>
>> How frequent we can planning to merge from develop to master ?  during
>> release ?
>>
>> Regards,
>> Rayees
>>
>>
>> -Original Message-
>> From: Prachi Damle [mailto:prachi.da...@citrix.com]
>> Sent: Tuesday, August 05, 2014 11:51 AM
>> To: dev@cloudstack.apache.org
>> Subject: RE: [VOTE] git workflow
>>
>> Sorry if this is already discussed, but few areas that are unclear to me
>> with this process are:
>>
>> - does every fix, however minor it be(say a signle line), needs to be
>> developed in a separate branch? And then we have to merge these
>> individual branches to develop for every fix?
>> - In that case will direct check-ins to 'develop' branch be not allowed?
>> - If not, if CI fails on develop branch, how will one know what caused
>> the failure? Was it some direct checkin Vs some feature/fix merged? Will
>> we revert all the small feature/fixes that were merged to develop branch
>> upto the CI baseline? If yes, wont the developers that did not cause the
>> break get penalized unnecessary?
>>
>> - Lastly, why can't this process be implemented on master? Why are we
>> introducing another branch for the same purposes which the master branch
>> usually serves?
>>
>>
>> I am -1 on this.  We should not start implementing this until all
>> processes are clear.
>>
>> Prachi
>>
>> -Original Message-
>> From: Jessica Wang [mailto:jessica.w...@citrix.com]
>> Sent: Tuesday, August 05, 2014 11:33 AM
>> To: dev@cloudstack.apache.org
>> Subject: RE: [VOTE] git workflow
>>
>> Exactly. This just shifts pain from one branch to another.
>> I don't see any gains from this, either.
>> I vote "-1".
>>
>> Jessica
>>
>>
>> -Original Message-
>> From: Min Chen [mailto:min.c...@citrix.com]
>> Sent: Tuesday, August 05, 2014 11:27 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [VOTE] git workflow
>>
>> Agree with Animesh. Didn't see any gains from this, we just shift pain
>> from one branch to another, so vote -1.
>>
>> -min
>>
>> On 8/2/14 9:50 PM, "Animesh Chaturvedi" 
>> wrote:
>>
>>> +0
>>>
>>> While this protects master with only commits which are merges from
>>> release branch and keeps it clean but the issues that we have shift to
>>> develop branch.
>>>
>>>
 -Original Message-
 From: Rajani Karuturi [mailto:rajani.karut...@citrix.com]
 Sent: Thursday, July 31, 2014 3:28 AM
 To: dev
 Subject: [VOTE] git workflow

 Hi All,

 We had long discussions on the git flow.
 I tried to capture the summary of it @
 http://m

Re: How to config linux native bridge to forward vxlan encapsulated pkts

[Yitao Jiang]

Do u turned neteork forward on? Sysctl -p can tell you the configuration
On Aug 6, 2014 7:09 PM, "Michael Li"  wrote:

> Does anyone meet this issue:
> Create VM using vxlan for isolation guest network,
>  both brvx-139 and vxlan139 is created,
> tcpdump can see the pkts has been encapsulated and forward to cloudbr1,
> but cloudbr1 does not forward pkts out from eth1, is there some special
> configuration on eth1, cloudbr1 or routes ? Does the fdb or mdb learn the
> address automically ?
>
> Regards
>

Re: [VOTE] git workflow

[Nate Gordon]

I think the core difference between your implementations is that #1 assumes
that BVT/CI will catch 100% of errors, resulting in a stable master branch
with no problems. Or that development changes can be blindly merged if they
pass CI. The goal of git-flow is to allow a stream of development changes
that don't impact the stable release or process, and the process of making
a release is assumed to take a separate effort and cleanup.

The other major benefit that I think is getting missed by having a stable
master branch is an ease with creating hotfixes. Sure, you can branch from
a tag in a development branch, but it feels cleaner to me to branch from
the release branch and then selectively merge back into any other affected
areas.


On Tue, Aug 5, 2014 at 3:45 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

> Rayees,
>
> I think you have the same misunderstanding as a lot of other folks
> (including myself) had in the beginning - seeing develop branch as a trunk
> branch that gets merged into master on a regular basis after the BVT/CI
> tests pass. So the master branch reflects the develop branch minus changes
> that didn¹t pass the tests and weren¹t merged into master -  lets refer to
> it as implementation #1
>
> That¹s not what git workflow/this thread proposes. In git workflow master
> branch reflects the latest stable release instead. So for example, we
> released 4.4, and that what you would see the master to be as we merge the
> *release branch to master, not the *develop to master. And develop branch
> becomes the trunk branch where all the new fixes go to. I would look at
> the master as at the stable branch, where you can track the history for
> all the major releases as for each of them the master branch has
> corresponding tags - lets call it implementation #2
>
> I still don¹t see many advantages in implementation #2 - making the master
> build stable by simply making it reflect the latest release branch.
> Because you:
>
> * never cut the release from master branch
> * if you are the customer, and need the latest stable code, you download
> the official RPM
> * if you are a developer, you always want to download the latest code, and
> that comes from *develop branch
> * if you want to look at the latest stable release, you look at the
> release branch as per CS git workflow implementation we never remove the
> release branches (they are needed for maintenance releases)
>
>
> It would be great if anyone can point the advantages of #2 approach over
> #1, as to me #1 seems to be the approach most people will find more
> intuitive and its used a lot in the field.
>
> -Alena.
>
>
>
> On 8/5/14, 1:22 PM, "Rayees Namathponnan" 
> wrote:
>
> >How frequent we can planning to merge from develop to master ?  during
> >release ?
> >
> >Regards,
> >Rayees
> >
> >
> >-Original Message-
> >From: Prachi Damle [mailto:prachi.da...@citrix.com]
> >Sent: Tuesday, August 05, 2014 11:51 AM
> >To: dev@cloudstack.apache.org
> >Subject: RE: [VOTE] git workflow
> >
> >Sorry if this is already discussed, but few areas that are unclear to me
> >with this process are:
> >
> >- does every fix, however minor it be(say a signle line), needs to be
> >developed in a separate branch? And then we have to merge these
> >individual branches to develop for every fix?
> >- In that case will direct check-ins to 'develop' branch be not allowed?
> >- If not, if CI fails on develop branch, how will one know what caused
> >the failure? Was it some direct checkin Vs some feature/fix merged? Will
> >we revert all the small feature/fixes that were merged to develop branch
> >upto the CI baseline? If yes, wont the developers that did not cause the
> >break get penalized unnecessary?
> >
> >- Lastly, why can't this process be implemented on master? Why are we
> >introducing another branch for the same purposes which the master branch
> >usually serves?
> >
> >
> >I am -1 on this.  We should not start implementing this until all
> >processes are clear.
> >
> >Prachi
> >
> >-Original Message-
> >From: Jessica Wang [mailto:jessica.w...@citrix.com]
> >Sent: Tuesday, August 05, 2014 11:33 AM
> >To: dev@cloudstack.apache.org
> >Subject: RE: [VOTE] git workflow
> >
> >Exactly. This just shifts pain from one branch to another.
> >I don't see any gains from this, either.
> >I vote "-1".
> >
> >Jessica
> >
> >
> >-Original Message-
> >From: Min Chen [mailto:min.c...@citrix.com]
> >Sent: Tuesday, August 05, 2014 11:27 AM
> >To: dev@cloudstack.apache.org
> >Subject: Re: [VOTE] git workflow
> >
> >Agree with Animesh. Didn't see any gains from this, we just shift pain
> >from one branch to another, so vote -1.
> >
> >-min
> >
> >On 8/2/14 9:50 PM, "Animesh Chaturvedi" 
> >wrote:
> >
> >>+0
> >>
> >>While this protects master with only commits which are merges from
> >>release branch and keeps it clean but the issues that we have shift to
> >>develop branch.
> >>
> >>
> >>> -Original Message-
> >>> From: Rajani

Re: [VOTE] git workflow

[David Nalley]

On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav  wrote:
>
> Hi,
>
> Comments in-line;
>
> On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk  
> wrote:
>
> > Rayees,
> >
> > I think you have the same misunderstanding as a lot of other folks
> > (including myself) had in the beginning - seeing develop branch as a trunk
> > branch that gets merged into master on a regular basis after the BVT/CI
> > tests pass. So the master branch reflects the develop branch minus changes
> > that didn¹t pass the tests and weren¹t merged into master -  lets refer to
> > it as implementation #1
> >
> > That¹s not what git workflow/this thread proposes. In git workflow master
> > branch reflects the latest stable release instead. So for example, we
> > released 4.4, and that what you would see the master to be as we merge the
> > *release branch to master, not the *develop to master. And develop branch
> > becomes the trunk branch where all the new fixes go to. I would look at
> > the master as at the stable branch, where you can track the history for
> > all the major releases as for each of them the master branch has
> > corresponding tags - lets call it implementation #2
> >
> > I still don¹t see many advantages in implementation #2 - making the master
> > build stable by simply making it reflect the latest release branch.
> > Because you:
> >
> > * never cut the release from master branch
>
> We’ve a stable branch that gets rolling/continuous releases which is good.
>
> > * if you are the customer, and need the latest stable code, you download
> > the official RPM
> > * if you are a developer, you always want to download the latest code, and
> > that comes from *develop branch
> > * if you want to look at the latest stable release, you look at the
> > release branch as per CS git workflow implementation we never remove the
> > release branches (they are needed for maintenance releases)
>
> IMO We “should" remove the release branches when done. Instead there is a 
> support workflow with git-flow (see support 
> http://yakiloo.com/getting-started-git-flow/) and also in the tooling (git 
> flow support etc. though experimental).
>

You aren't aiding your case by suggesting that we use experimental tooling.

So removing a release branch worries me. Will there be loss of commit
information? I know that heretofore, each release has contained
commits that aren't in master. Whether that's good, bad or
indifferent, that is the fact, and I personally think that is unlikely
to change in the short term.

Or put more succinctly, what does removing a release branch buy us?

So I like most of the things about this proposal - I like doing all
the work in the feature/bug branches. But the rest of this workflow
befuddles me a bit. I don't think that the workflow will result in a
stable 'master' or that we are really doing anything significant by
pushing what is master now to become the develop branch. In the page
describing this, pushes to the develop branch seem welcome 'when a
feature is completed' - so develop will be as messy as master is
today, frequently broken, and no improvement in quality. This attempts
to solve a quality problem with workflow, and I don't think it can do
that. Instead, we end up with develop being cluttered and as messy as
current master, and we spend time trying to get merge commits from
develop -> master and hoping things don't diverge so far in our
release branches that we can merge fixes from develop -> master ->
release-branches.

This is a bit of a change from what we are doing now; why are we doing
it? A stable master? I am not sure how a workflow change enforces a
stable master. Improved quality? A workflow change might be a part of
the solution, but there seems to be missing something that enforces
quality or gates on working functionality.

--David

Build failed in Jenkins: simulator-hotfix-trigger #15

[jenkins]

See 

--
[...truncated 7428 lines...]

main:
[INFO] Executed tasks
[INFO] 
[INFO] >>> exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer >>>
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-developer ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] <<< exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer <<<
[INFO] 
[INFO] --- exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer ---
log4j:WARN No appenders could be found for logger 
(org.springframework.core.env.StandardEnvironment).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.
> WARNING: Provided file does not exist: 

> Initializing database=simulator with host=localhost port=3306 
username=cloud password=cloud
> Running query: drop database if exists `simulator`
> Running query: create database `simulator`
> Running query: GRANT ALL ON simulator.* to 'cloud'@`localhost` 
identified by 'cloud'
> Running query: GRANT ALL ON simulator.* to 'cloud'@`%` identified 
by 'cloud'
> Processing SQL file at 

> Processing SQL file at 

> Processing SQL file at 

> Processing upgrade: com.cloud.upgrade.DatabaseUpgradeChecker
[INFO] 
[INFO] --- maven-site-plugin:3.3:attach-descriptor (attach-descriptor) @ 
cloud-developer ---
[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ 
cloud-developer ---
[INFO] Installing 

 to 
/var/lib/jenkins/.m2/repository/org/apache/cloudstack/cloud-developer/4.5.0-SNAPSHOT/cloud-developer-4.5.0-SNAPSHOT.pom
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 21.981s
[INFO] Finished at: Wed Aug 06 09:49:34 EDT 2014
[INFO] Final Memory: 43M/175M
[INFO] 
[simulator-hotfix-trigger] $ /bin/bash -x /tmp/hudson2812457981103650382.sh
+ jps -l
+ grep -q Launcher
+ rm -f xunit.xml
+ rm -rf /tmp/MarvinLogs
+ echo Check for initialization of the management server
Check for initialization of the management server
+ COUNTER=0
+ SERVER_PID=20241
+ mvn -P systemvm,simulator -pl :cloud-client-ui jetty:run
+ '[' 0 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=1
+ '[' 1 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=2
+ '[' 2 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=3
+ '[' 3 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=4
+ '[' 4 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=5
+ '[' 5 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=6
+ '[' 6 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=7
+ '[' 7 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=8
+ '[' 8 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=9
+ '[' 9 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=10
+ '[' 10 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=11
+ '[' 11 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=12
+ '[' 12 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=13
+ '[' 13 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=14
+ '[' 14 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=15
+ '[' 15 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=16
+ '[' 16 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=17
+ '[' 17 -lt 44 ']'
+ grep -q 'Management server node

Re: Review Request 23982: CLOUDSTACK-7192: Skip tests on Hyper-V which don't apply

[John Dilley]

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

(Updated Aug. 6, 2014, 2:41 p.m.)


Review request for cloudstack, sanjeev n and Santhosh Edukulla.


Changes
---

Where possible I've put the items in the setup method. The notable exception is 
the test_primary_storage.py file, because we should add an SMB primary storage 
test at some point, and it should go in that file.


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


Repository: cloudstack-git


Description
---

A number of tests in the following files don't apply to Hyper-V. This patch 
means they are skipped if an attempt is made to run them.

test_nic.py
test_primary_storage.py 
test_scale_vm.py
test_snapshots.py
test_vm_snapshots.py
test_volumes.py(test7 and test8 only)


Diffs (updated)
-

  test/integration/smoke/test_nic.py dd6de96 
  test/integration/smoke/test_primary_storage.py 66aec59 
  test/integration/smoke/test_scale_vm.py b5c89be 
  test/integration/smoke/test_snapshots.py 8b6fdd1 
  test/integration/smoke/test_vm_snapshots.py 01626f5 
  test/integration/smoke/test_volumes.py 6e9ea75 

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


Testing
---


Thanks,

John Dilley

Re: [VOTE] git workflow

[Hugo Trippaers]

To me this pretty much ties in to the discussion about the simulator and the 
BVT/CI suite. This works very neatly with the work Alex has been doing and his 
proposal on how to deal with the BVT test suite.

His original proposal was about constantly checking master and reverting any 
commits that would cause master to break. If we would adopt another branching 
model like git flow we can change this around to, merge only when all checks 
are green. Given an community that cares about the quality of the software that 
they are releasing it will help having a more stable develop/master branch.

The big idea is that we get small chunks that we can test individually from 
each other and once verified merge them into the various branches where we need 
them. Master would be a special case where only the release manager merges the 
individual branches that are going to be part of a release. If i got everything 
correctly (which i doubt, so please correct me).

X develops feature F1
Y develops feature F2
Z develops bugfix B1

They are all tested individually and after green light merged into develop, so 
developers can work with the latest greatest.

On release time we can all decide to take F1 and B1 into the release because 
they are release grade, so they get merged into master. At all times we can 
track what is where because of the merging the git commit ids will be the same 
so a simple check on which branches contain a commit id will tell you where a 
certain feature or bug fix is included.


It requires discipline and a trustworthily CI system, but with those things in 
place it’s pretty sweet. We run other projects with a similar branching scheme 
and it works really well. It’s worth to keep pointing out that this is not a 
standalone thing, it should be regarded with the context of a CI system (or 
committers doing reviews) that can actually tell us if CloudStack works .


Cheers,

Hugo


On 6 aug. 2014, at 16:10, David Nalley  wrote:

> On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav  wrote:
>> 
>> Hi,
>> 
>> Comments in-line;
>> 
>> On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk 
>>  wrote:
>> 
>>> Rayees,
>>> 
>>> I think you have the same misunderstanding as a lot of other folks
>>> (including myself) had in the beginning - seeing develop branch as a trunk
>>> branch that gets merged into master on a regular basis after the BVT/CI
>>> tests pass. So the master branch reflects the develop branch minus changes
>>> that didn¹t pass the tests and weren¹t merged into master -  lets refer to
>>> it as implementation #1
>>> 
>>> That¹s not what git workflow/this thread proposes. In git workflow master
>>> branch reflects the latest stable release instead. So for example, we
>>> released 4.4, and that what you would see the master to be as we merge the
>>> *release branch to master, not the *develop to master. And develop branch
>>> becomes the trunk branch where all the new fixes go to. I would look at
>>> the master as at the stable branch, where you can track the history for
>>> all the major releases as for each of them the master branch has
>>> corresponding tags - lets call it implementation #2
>>> 
>>> I still don¹t see many advantages in implementation #2 - making the master
>>> build stable by simply making it reflect the latest release branch.
>>> Because you:
>>> 
>>> * never cut the release from master branch
>> 
>> We’ve a stable branch that gets rolling/continuous releases which is good.
>> 
>>> * if you are the customer, and need the latest stable code, you download
>>> the official RPM
>>> * if you are a developer, you always want to download the latest code, and
>>> that comes from *develop branch
>>> * if you want to look at the latest stable release, you look at the
>>> release branch as per CS git workflow implementation we never remove the
>>> release branches (they are needed for maintenance releases)
>> 
>> IMO We “should" remove the release branches when done. Instead there is a 
>> support workflow with git-flow (see support 
>> http://yakiloo.com/getting-started-git-flow/) and also in the tooling (git 
>> flow support etc. though experimental).
>> 
> 
> You aren't aiding your case by suggesting that we use experimental tooling.
> 
> So removing a release branch worries me. Will there be loss of commit
> information? I know that heretofore, each release has contained
> commits that aren't in master. Whether that's good, bad or
> indifferent, that is the fact, and I personally think that is unlikely
> to change in the short term.
> 
> Or put more succinctly, what does removing a release branch buy us?
> 
> So I like most of the things about this proposal - I like doing all
> the work in the feature/bug branches. But the rest of this workflow
> befuddles me a bit. I don't think that the workflow will result in a
> stable 'master' or that we are really doing anything significant by
> pushing what is master now to become the develop branch. In the page
> describing this, pushes to the deve

Re: [VOTE] git workflow

[Rohit Yadav]

Hi David,

On 06-Aug-2014, at 4:10 pm, David Nalley  wrote:

> On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav  wrote:
>>
>> Hi,
>>
>> Comments in-line;
>>
>> On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk 
>>  wrote:
>>
>>> Rayees,
>>>
>>> I think you have the same misunderstanding as a lot of other folks
>>> (including myself) had in the beginning - seeing develop branch as a trunk
>>> branch that gets merged into master on a regular basis after the BVT/CI
>>> tests pass. So the master branch reflects the develop branch minus changes
>>> that didn¹t pass the tests and weren¹t merged into master -  lets refer to
>>> it as implementation #1
>>>
>>> That¹s not what git workflow/this thread proposes. In git workflow master
>>> branch reflects the latest stable release instead. So for example, we
>>> released 4.4, and that what you would see the master to be as we merge the
>>> *release branch to master, not the *develop to master. And develop branch
>>> becomes the trunk branch where all the new fixes go to. I would look at
>>> the master as at the stable branch, where you can track the history for
>>> all the major releases as for each of them the master branch has
>>> corresponding tags - lets call it implementation #2
>>>
>>> I still don¹t see many advantages in implementation #2 - making the master
>>> build stable by simply making it reflect the latest release branch.
>>> Because you:
>>>
>>> * never cut the release from master branch
>>
>> We’ve a stable branch that gets rolling/continuous releases which is good.
>>
>>> * if you are the customer, and need the latest stable code, you download
>>> the official RPM
>>> * if you are a developer, you always want to download the latest code, and
>>> that comes from *develop branch
>>> * if you want to look at the latest stable release, you look at the
>>> release branch as per CS git workflow implementation we never remove the
>>> release branches (they are needed for maintenance releases)
>>
>> IMO We “should" remove the release branches when done. Instead there is a 
>> support workflow with git-flow (see support 
>> http://yakiloo.com/getting-started-git-flow/) and also in the tooling (git 
>> flow support etc. though experimental).
>>
>
> You aren't aiding your case by suggesting that we use experimental tooling.

No, if you know you git-chops you can do it by hand, I mean to say -- the tool 
is under development for support stuff.

> So removing a release branch worries me. Will there be loss of commit
> information?

Once you merge release branch it on master/stable branch, you don’t lose commit 
if you delete it. It’s like removing a feature branch once it’s merged on 
master/target branch.

> I know that heretofore, each release has contained
> commits that aren't in master. Whether that's good, bad or
> indifferent, that is the fact, and I personally think that is unlikely
> to change in the short term.

Once merged on master/stable branch, one can checkout the release version tag 
to get the same branch.

> Or put more succinctly, what does removing a release branch buy us?

Less cluttered branches. You’ve the release branch merged on master and tags 
why do you want to keep branches? You can always checkout the tags to get the 
release branch.

> So I like most of the things about this proposal - I like doing all
> the work in the feature/bug branches. But the rest of this workflow
> befuddles me a bit. I don't think that the workflow will result in a
> stable 'master' or that we are really doing anything significant by
> pushing what is master now to become the develop branch.

You’re right. It’s just a convention of doing things, like we’ve traffic rules.
They won’t stop you to break anything if you don’t follow.

> In the page
> describing this, pushes to the develop branch seem welcome 'when a
> feature is completed' - so develop will be as messy as master is
> today, frequently broken, and no improvement in quality. This attempts
> to solve a quality problem with workflow, and I don't think it can do
> that. Instead, we end up with develop being cluttered and as messy as
> current master, and we spend time trying to get merge commits from
> develop -> master and hoping things don't diverge so far in our
> release branches that we can merge fixes from develop -> master ->
> release-branches.

I’m not here to "defend git-flow", I like it just because IMO it's better than 
status quo.

We have several threads on this issue now, it adds divergence to the topic in 
the community just like length/divergence/state/stability between release 
branches and master which need to be fixed, so we need some sort of 
protocol/convention that we all agree to. That’s all :)

Let me list out the things I want with our workflow(s) (adaptation from 
git-flow and other places etc.; skipping posting video)

- Baseline protocol, continuous flow of changes and respect for the “tofu 
scale": More -- http://markmail.org/message/4hk2jwvxt4lcpqig
- Shorter release cycles, le

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

[John Dilley]

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

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

[David Nalley]

On Wed, Aug 6, 2014 at 10:53 AM, Hugo Trippaers  wrote:
> To me this pretty much ties in to the discussion about the simulator and the 
> BVT/CI suite. This works very neatly with the work Alex has been doing and 
> his proposal on how to deal with the BVT test suite.
>
> His original proposal was about constantly checking master and reverting any 
> commits that would cause master to break.

IIRC his proposal was to gate commits entering master or a release
branch based on them passing BVT/CI. E.g. you had to prove it worked
before it was allowed in. Given our velocity, and the amount of time
that it takes for a CI run there really isn't much choice.

 If we would adopt another branching model like git flow we can change
this around to, merge only when all checks are green. Given an
community that cares about the quality of the software that they are
releasing it will help having a more stable develop/master branch.
>

This makes sense to me. Adopting git flow (or some other workflow) to
keep work out of master/develop until proven that it passes CI - the
workflow change itself, alone does not.

> The big idea is that we get small chunks that we can test individually from 
> each other and once verified merge them into the various branches where we 
> need them. Master would be a special case where only the release manager 
> merges the individual branches that are going to be part of a release. If i 
> got everything correctly (which i doubt, so please correct me).
>
> X develops feature F1
> Y develops feature F2
> Z develops bugfix B1
>
> They are all tested individually and after green light merged into develop, 
> so developers can work with the latest greatest.
>
> On release time we can all decide to take F1 and B1 into the release because 
> they are release grade, so they get merged into master. At all times we can 
> track what is where because of the merging the git commit ids will be the 
> same so a simple check on which branches contain a commit id will tell you 
> where a certain feature or bug fix is included.
>
>
> It requires discipline and a trustworthily CI system, but with those things 
> in place it’s pretty sweet. We run other projects with a similar branching 
> scheme and it works really well. It’s worth to keep pointing out that this is 
> not a standalone thing, it should be regarded with the context of a CI system 
> (or committers doing reviews) that can actually tell us if CloudStack works .
>
>
> Cheers,
>
> Hugo
>
>
> On 6 aug. 2014, at 16:10, David Nalley  wrote:
>
>> On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav  
>> wrote:
>>>
>>> Hi,
>>>
>>> Comments in-line;
>>>
>>> On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk 
>>>  wrote:
>>>
 Rayees,

 I think you have the same misunderstanding as a lot of other folks
 (including myself) had in the beginning - seeing develop branch as a trunk
 branch that gets merged into master on a regular basis after the BVT/CI
 tests pass. So the master branch reflects the develop branch minus changes
 that didn¹t pass the tests and weren¹t merged into master -  lets refer to
 it as implementation #1

 That¹s not what git workflow/this thread proposes. In git workflow master
 branch reflects the latest stable release instead. So for example, we
 released 4.4, and that what you would see the master to be as we merge the
 *release branch to master, not the *develop to master. And develop branch
 becomes the trunk branch where all the new fixes go to. I would look at
 the master as at the stable branch, where you can track the history for
 all the major releases as for each of them the master branch has
 corresponding tags - lets call it implementation #2

 I still don¹t see many advantages in implementation #2 - making the master
 build stable by simply making it reflect the latest release branch.
 Because you:

 * never cut the release from master branch
>>>
>>> We’ve a stable branch that gets rolling/continuous releases which is good.
>>>
 * if you are the customer, and need the latest stable code, you download
 the official RPM
 * if you are a developer, you always want to download the latest code, and
 that comes from *develop branch
 * if you want to look at the latest stable release, you look at the
 release branch as per CS git workflow implementation we never remove the
 release branches (they are needed for maintenance releases)
>>>
>>> IMO We “should" remove the release branches when done. Instead there is a 
>>> support workflow with git-flow (see support 
>>> http://yakiloo.com/getting-started-git-flow/) and also in the tooling (git 
>>> flow support etc. though experimental).
>>>
>>
>> You aren't aiding your case by suggesting that we use experimental tooling.
>>
>> So removing a release branch worries me. Will there be loss of commit
>> information? I know that heretofore, each release has contained
>> commits that a

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

[Mike Tutkowski]

Thanks for sending this out! These can be really helpful.


On Wed, Aug 6, 2014 at 4:06 AM, Saksham Srivastava <
saksham.srivast...@citrix.com> wrote:

> 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.dns1 dns1,
> data_center.dns2 dns2,
> data_center.ip6_dns1 ip6_dns1,
> data_center.ip6_dns2 ip6_dns2,
> host.id host_id,
> host.uuid host_uuid,
> host.name host_name,
>host.hypervisor_type,
> host.cluster_id cluster_id,
> vm_template.id template_id,
> vm_template.uuid template_uuid,
> service_offering.id service_offering_id,
> disk_offering.uuid service_offering_uuid,
> disk_offering.name service_offering_name,
> nics.id nic_id,
> nics.uuid nic_uuid,
> nics.network_id network_id,
> nics.ip4_address ip_address,
> nics.ip6_address ip6_address,
> nics.ip6_gateway ip6_gateway,
> nics.ip6_cidr ip6_cidr,
> nics.default_nic is_default_nic,
> nics.gateway gateway,
> nics.netmask netmask,
> nics.mac_address mac_address,
> nics.broadcast_uri broadcast_uri,
> nics.isolation_uri isolation_uri,
> vpc.id vpc_id,
> vpc.uuid vpc_uuid,
> networks.uuid network_uuid,
> networks.name network_name,
> networks.network_domain network_domain,
> networks.traffic_type traffic_type,
> networks.guest_type guest_type,
> async_job.id job_id,
> async_job.uuid job_uuid,
> async_job.job_status job_status,
> async_job.account_id job_account_id,
> domain_router.template_version template_version,
> domain_router.scripts_version scripts_version,
> domain_router.is_redundant_router is_redundant_router,
> domain_router.redundant_state redundant_state,
> domain_router.stop_pending stop_pending,
> domain_router.role role
> from
> `cloud`.`domain_router`
>inner join
> `cloud`.`vm_instance` ON vm_instance.id = domain_router.id
> inner join
> `cloud`.`account` ON vm_instance.account_id = account.id
> inner join
> `cloud`.`domain` ON vm_instance.domain_id = domain.id
> left join
> `cloud`.`host_pod_ref` ON vm_instance.pod_id = host_pod_ref.id
> left join
> `cloud`.`projects` ON projects.project_account_id = account.id
> left join
> `cloud`.`data_center` ON vm_instance.data_center_id =
> data_center.id
> left join
> `cloud`.`host` ON vm_instance.host_id = host.id
> left join
> `cloud`.`vm_template` ON vm_instance.vm_template_id =
> vm_template.id
> left join
>`cloud`.`service_offering` ON vm_instance.service_offering_id =
> service_offering.id
> left join
> `cloud`.`disk_offering` ON vm_instance.service_offering_id =
> disk_offering.id
> left join
> `cloud`.`nics` ON vm_instance.id = nics.instance_id and
> nics.removed is null
> left join
> `cloud`.`networks` ON nics.network_id = networks.id
> left join
> `cloud`.`vpc` ON domain_router.vpc_id = vpc.id and vpc.removed is
> null
> left join
> `cloud`.`async_job` ON async_job.instance_id = vm_instance.id
> and async_job.instance_type = 'D

Build failed in Jenkins: simulator-singlerun #67

[jenkins]

See 

Changes:

[kishan.kavala] CLOUDSTACK-7237 : Added TAR image processor for templates with 
tar extension

--
[...truncated 7273 lines...]
[INFO] 
[INFO] Building Apache CloudStack Developer Mode 4.5.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-developer ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- properties-maven-plugin:1.0-alpha-2:read-project-properties 
(default) @ cloud-developer ---
[WARNING] Ignoring missing properties file: 

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-developer ---
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run (default) @ cloud-developer ---
[INFO] Executing tasks

main:
[INFO] Executed tasks
[INFO] 
[INFO] >>> exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer >>>
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-developer ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] <<< exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer <<<
[INFO] 
[INFO] --- exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer ---
log4j:WARN No appenders could be found for logger 
(org.springframework.core.env.StandardEnvironment).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.
> WARNING: Provided file does not exist: 

> Initializing database=simulator with host=localhost port=3306 
username=cloud password=cloud
> Running query: drop database if exists `simulator`
> Running query: create database `simulator`
> Running query: GRANT ALL ON simulator.* to 'cloud'@`localhost` 
identified by 'cloud'
> Running query: GRANT ALL ON simulator.* to 'cloud'@`%` identified 
by 'cloud'
> Processing SQL file at 

> Processing SQL file at 

> Processing SQL file at 

> Processing upgrade: com.cloud.upgrade.DatabaseUpgradeChecker
[INFO] 
[INFO] --- maven-site-plugin:3.3:attach-descriptor (attach-descriptor) @ 
cloud-developer ---
[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ 
cloud-developer ---
[INFO] Installing 
 
to 
/var/lib/jenkins/.m2/repository/org/apache/cloudstack/cloud-developer/4.5.0-SNAPSHOT/cloud-developer-4.5.0-SNAPSHOT.pom
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 21.666s
[INFO] Finished at: Wed Aug 06 10:54:36 EDT 2014
[INFO] Final Memory: 41M/213M
[INFO] 
[simulator-singlerun] $ /bin/bash -x /tmp/hudson4543160547305992812.sh
+ jps -l
+ grep -q Launcher
+ rm -f xunit.xml
+ rm -rf /tmp/MarvinLogs
+ echo Check for initialization of the management server
Check for initialization of the management server
+ COUNTER=0
+ SERVER_PID=27893
+ '[' 0 -lt 44 ']'
+ mvn -P systemvm,simulator -pl :cloud-client-ui jetty:run
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=1
+ '[' 1 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=2
+ '[' 2 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=3
+ '[' 3 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=4
+ '[' 4 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=5
+ '[' 5 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=6
+ '[' 6 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=7
+ '[' 7 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=8
+ '[' 8 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=9
+ '[' 9 -lt 44 ']'
+ grep -q 'Management

Re: [VOTE] git workflow

[Alena Prokharchyk]

Rohit, addressing the following comment:

"IMO We “should" remove the release branches when done. Instead there is a
support workflow with git-flow (see support
http://yakiloo.com/getting-started-git-flow/) and also in the tooling (git
flow support etc. though experimental).”

If we remove the release branches, how are we going to handle maintenance
releases for older versions of the code? It wouldn’t work as its
impossible to cut a maintenance release from develop branch.

I think the model the article proposes, fits the products like SAS, when
there are no maintenance releases and support is provided just for the
latest release.  Then of course, to get the latest stable release, it
would make sense to access master branch which is always stable. In case
when multiple releases are being maintained at the same time - like CS -
it would make sense to keep release branches. Otherwise how are you going
to handle this situation:

4.2, 4.3 and 4.4 are released
Master reflects 4.4
Maintenance 4.2.1 and 4.3.1 releases are needed

Questions:
How do you create those releases, from what branch?
How do you merge and tag them into master branch considering that the
latest version there is 4.4?

Thanks,
Alena.


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

>Hi,
>
>Comments in-line;
>
>On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk
> wrote:
>
>> Rayees,
>>
>> I think you have the same misunderstanding as a lot of other folks
>> (including myself) had in the beginning - seeing develop branch as a
>>trunk
>> branch that gets merged into master on a regular basis after the BVT/CI
>> tests pass. So the master branch reflects the develop branch minus
>>changes
>> that didn¹t pass the tests and weren¹t merged into master -  lets refer
>>to
>> it as implementation #1
>>
>> That¹s not what git workflow/this thread proposes. In git workflow
>>master
>> branch reflects the latest stable release instead. So for example, we
>> released 4.4, and that what you would see the master to be as we merge
>>the
>> *release branch to master, not the *develop to master. And develop
>>branch
>> becomes the trunk branch where all the new fixes go to. I would look at
>> the master as at the stable branch, where you can track the history for
>> all the major releases as for each of them the master branch has
>> corresponding tags - lets call it implementation #2
>>
>> I still don¹t see many advantages in implementation #2 - making the
>>master
>> build stable by simply making it reflect the latest release branch.
>> Because you:
>>
>> * never cut the release from master branch
>
>We’ve a stable branch that gets rolling/continuous releases which is good.
>
>> * if you are the customer, and need the latest stable code, you download
>> the official RPM
>> * if you are a developer, you always want to download the latest code,
>>and
>> that comes from *develop branch
>> * if you want to look at the latest stable release, you look at the
>> release branch as per CS git workflow implementation we never remove the
>> release branches (they are needed for maintenance releases)
>
>IMO We “should" remove the release branches when done. Instead there is a
>support workflow with git-flow (see support
>http://yakiloo.com/getting-started-git-flow/) and also in the tooling
>(git flow support etc. though experimental).
>
>I’ll create a video to describe what we can do with this workflow,
>instead of going back and forth on the ML.
>We don’t need to change our workflow, we can learn from this and adapt to
>our workflow.
>
>
>> It would be great if anyone can point the advantages of #2 approach over
>> #1, as to me #1 seems to be the approach most people will find more
>> intuitive and its used a lot in the field.
>>
>> -Alena.
>>
>>
>>
>> On 8/5/14, 1:22 PM, "Rayees Namathponnan"
>>
>> wrote:
>>
>>> How frequent we can planning to merge from develop to master ?  during
>>> release ?
>>>
>>> Regards,
>>> Rayees
>>>
>>>
>>> -Original Message-
>>> From: Prachi Damle [mailto:prachi.da...@citrix.com]
>>> Sent: Tuesday, August 05, 2014 11:51 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: RE: [VOTE] git workflow
>>>
>>> Sorry if this is already discussed, but few areas that are unclear to
>>>me
>>> with this process are:
>>>
>>> - does every fix, however minor it be(say a signle line), needs to be
>>> developed in a separate branch? And then we have to merge these
>>> individual branches to develop for every fix?
>>> - In that case will direct check-ins to 'develop' branch be not
>>>allowed?
>>> - If not, if CI fails on develop branch, how will one know what caused
>>> the failure? Was it some direct checkin Vs some feature/fix merged?
>>>Will
>>> we revert all the small feature/fixes that were merged to develop
>>>branch
>>> upto the CI baseline? If yes, wont the developers that did not cause
>>>the
>>> break get penalized unnecessary?
>>>
>>> - Lastly, why can't this process be implemented on master? Why are we
>>> introducing another branch for the same purpo

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'

[Santhosh Edukulla]

> On Aug. 6, 2014, 1:19 p.m., Doug Clark wrote:
> > test/integration/smoke/misc/test_deploy_vm.py, line 1
> > 
> >
> > Generally, how does putting these test in a separate directory help?  
> > Doesn't nosetests recursively search for tests.

No, it wont.


> On Aug. 6, 2014, 1:19 p.m., Doug Clark wrote:
> > test/integration/smoke/test_vm_life_cycle.py, line 253
> > 
> >
> > What is the advantage of catching an exception only to immediately 
> > re-raise it?
> > 
> > Will the stack trace for the original exception still appear in the 
> > logs?

Its not an issue though, uncaught exceptions cause script to exit, in case of 
this, it can still continue with other tests. Gaurav, dump to log if we want, 
but output can be caught to console and be viewed easily from jenkins.


- Santhosh


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


On Aug. 6, 2014, 12:33 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24298/
> ---
> 
> (Updated Aug. 6, 2014, 12:33 p.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 1386830 
> 
> Diff: https://reviews.apache.org/r/24298/diff/
> 
> 
> Testing
> ---
> 
> Yes, tested test_vm_life_cycle.py with python command.
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: [VOTE] git workflow

[Alena Prokharchyk]

Why implement something that doesn¹t serve any practical purpose for CS??
We should adopt only things that would address current CS problems -
regressions, unstable releases, etc. That would mean - running the
automation (CI, BVT) on *develop branch, cut the *fix branches for hot
fixes/critical/feature bugs only and run BVT on them before merging to
*develop; merge only stable code from *develop to master branch.

There would be no use for master branch if it reflects the latest release
branch, which will always be present in CS model as opposed to what
original article suggests. Below the explanation from the other email
thread on why the release branches can¹t be removed in CS model:

Rohit:


"IMO We ³should" remove the release branches when done. Instead there is a
support workflow with git-flow (see support
http://yakiloo.com/getting-started-git-flow/) and also in the tooling (git
flow support etc. though experimental).²

Alena:
==
If we remove the release branches, how are we going to handle maintenance
releases for older versions of the code? It wouldn¹t work as its
impossible to cut a maintenance release from develop branch.

I think the model the article proposes, fits the products like SAS, when
there are no maintenance releases and support is provided just for the
latest release.  Then of course, to get the latest stable release, it
would make sense to access master branch which is always stable. In case
when multiple releases are being maintained at the same time - like CS -
it would make sense to keep release branches. Otherwise how are you going
to handle this situation:

4.2, 4.3 and 4.4 are released
Master reflects 4.4
Maintenance 4.2.1 and 4.3.1 releases are needed

Questions:
How do you create those releases, from what branch?
How do you merge and tag them into master branch considering that the
latest version there is 4.4?

Thanks,
Alena.




On 8/5/14, 11:36 PM, "Daan Hoogland"  wrote:

>Exactly Rajani, and other solutions are possible. The issue is not how
>branches are called ;)
>
>On Wed, Aug 6, 2014 at 8:29 AM, Rajani Karuturi
> wrote:
>> I am just wondering if the shift to a new develop branch is causing the
>>problems. Its a simple branch shift and should be no different from the
>>current master.
>>
>> may be we should leave the master as is and create a Œstable' branch
>>which would act like master in git-flow ?
>>
>> ie)
>> ACS master -> develop in git-flow
>> ACS stable -> master in git-flow
>>
>>
>> ~Rajani
>>
>>
>>
>> On 06-Aug-2014, at 10:56 am, Daan Hoogland 
>>wrote:
>>
>>> Hello devs and especially committters,
>>>
>>> I see some -1s coming by, days after the vote was closed. That is
>>> disturbing as it means we accepted a proposal that will not be
>>> supported by the community. So let me try to find that support in
>>> hindsight;
>>>
>>> The argument of Animesh that we are shifting the burden from one
>>> branch to another is real and present danger. I share his concern. It
>>> is not the only feature of this proposal and in it self does not
>>> warrant a -1. It does not worsen the situation at hand or add to our
>>> workload in any way. If there is no advantage to you and no
>>> disadvantage either then why -1 something that others do find useful?
>>> This is 'kind of' a rhetorical question. It is a real concern, however
>>> though not the biggest at this moment.
>>>
>>> branching is recommended but as people are rightfully wondering
>>> "should I make a branch for a single line fix". I would, probably but
>>> maybe not always. That doesn't mean you must. In case you are making a
>>> fix on a release then yes you do. It is how the git-flow workflow
>>> goes.
>>>
>>> Committers can merge and commit where ever they feel the need. That
>>> doesn't exempt them from thinking if it is a good idea. It doesn't now
>>> and it won't in the future. Doing what your boss tells you to do can
>>> be a crime!
>>>
>>> Reverting something should only be done when the code that is a
>>> culprit has been identified. Reverting a big change or even a bunch of
>>> changes is a cowards way out. We shouldn't do it now or using gitflow.
>>> It is not really related to git flow or its use. So we shouldn't
>>> penalize developers that didn't cause a problem or ones that did. We
>>> should help them help us make a better system.
>>>
>>> The question of why this process isn't implemented on master is valid.
>>> It could. It isn't however. It is a choice the authors of gitflow
>>> made. I think it is not really the time anymore to be nitpicking about
>>> this. Unless we find a very valid reason to alter the accepted
>>> proposal we should all try and implement it as good as possible. I
>>> have been RM for 4.4.0 and one thing I don't want anymore is people
>>> share a 4.4-forward to cherry-pick commits from. It caused me a lot of
>>> headaches.
>>>
>>> The release is what drives the merges back to master according to
>>> git-flow. We can decide that we define a number of pr

Re: implementing git workflow

[Alena Prokharchyk]

Agree with Daan. The first vote was needed to get the peoples opinions on
whether we need to change our current git model (we certainly do as there
are so many problems in the current flow), and the article was just the
point of reference on how other people do it on the field. Now we have to
see what exactly would benefit CS from this model, and what won’t be
applicable or useful at all. There are many software models, and what
suits one, might not be applicable to another.

So only after all the questions are cleared out and the process is
documented, we should start the second vote. And I think we can’t change
the document after the vote has started; it makes previous voting
obsolete. Only after the second vote passes, we can start implementing it.


Thanks,
Alena.

On 8/5/14, 11:05 PM, "Daan Hoogland"  wrote:

>I don't think we should hold on improving our way of working just
>because it is not perfect yet. Some things are unclear so we can't do
>those. Other things are perfectly clear and need to wait for nothing
>else. That doesn't mean that a second vote isn't needed. It is if not
>for anything else then for making sure we all want to go in the same
>direction. I posted a lengthy reply on the vote thread to answer any
>concerns and provoke more discussion. Let's see if that breeds further
>ideas and then decide on a next phase/vote.
>
>makes sense?
>
>On Wed, Aug 6, 2014 at 6:23 AM, Rajani Karuturi
> wrote:
>> For a proposal which got all +1’s[1] what are the next steps to do?? It
>>was made clear on the voting thread that required branching changes
>>would be done if the vote passes[2]
>>
>> Though the content in the document changed, the original proposal
>>hasn’t changed. Its still the same.
>> It is explained in details with all the commands and more details in
>>the wiki. Hence there is quite a bit of text changes. It is not a
>>diversion from what is already discussed.
>>
>> [1] http://markmail.org/message/h7nh6ozseien7ezh
>> [2] http://markmail.org/message/u7k6wv5kslb4ysyn
>>
>> ~Rajani
>>
>>
>>
>> On 06-Aug-2014, at 12:56 am, David Nalley
>>mailto:da...@gnsa.us>> wrote:
>>
>> On Tue, Aug 5, 2014 at 2:51 PM, Alena Prokharchyk
>> mailto:alena.prokharc...@citrix.com>>
>>wrote:
>> I think we should hold on with the git workflow implementation till all
>> the decisions on the items written by Leo, are discussed and finalized.
>>
>> The very beginning of ³git workflow vote² shows that the vote was just
>>to
>> get people opinion on the proposal. Before adopting it and cutting the
>> develop branch, all the questions should be cleared out.
>>
>>
>> I agree with Alena - the vote was framed as opinion, not adoption.
>> Moreover, the document voted on has been changed ~10 times since we
>> started the vote, and the differences are substantial:
>>
>> 
>>https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageI
>>d=30738915&selectedPageVersions=32&selectedPageVersions=22
>>
>> Agreement to do something and the following implementation are not
>> necessarily instantaneous.
>>
>
>
>
>-- 
>Daan

Re: [VOTE] git workflow

[Rohit Yadav]

On 06-Aug-2014, at 6:58 pm, Alena Prokharchyk  
wrote:

> Why implement something that doesn¹t serve any practical purpose for CS??
> We should adopt only things that would address current CS problems -
> regressions, unstable releases, etc. That would mean - running the
> automation (CI, BVT) on *develop branch, cut the *fix branches for hot
> fixes/critical/feature bugs only and run BVT on them before merging to
> *develop; merge only stable code from *develop to master branch.
>
> There would be no use for master branch if it reflects the latest release
> branch, which will always be present in CS model as opposed to what
> original article suggests. Below the explanation from the other email
> thread on why the release branches can¹t be removed in CS model:
>
> Rohit:
> 
>
> "IMO We ³should" remove the release branches when done. Instead there is a
> support workflow with git-flow (see support
> http://yakiloo.com/getting-started-git-flow/) and also in the tooling (git
> flow support etc. though experimental).²
>
> Alena:
> ==
> If we remove the release branches, how are we going to handle maintenance
> releases for older versions of the code? It wouldn¹t work as its
> impossible to cut a maintenance release from develop branch.

When you merge --no-ff a release/any branch on master/target branch, the 
version history stays with it.
Not only we merge it on master, we do a tag on it as well. Now to get the 
history/branch back you can always checkout the tag: git checkout  and see 
the history:
git log --graph --decorate --pretty=oneline --abbrev-commit —all

So, it’s safe to delete a branch when it’s merged to a target/master branch.
If you have never deleted a feature branch once it was merged, you should try 
and see for yourself. At the end of the day, git is all but link-list logic at 
the core. The branch too tracks just the HEAD, if you’ve refs/tag/sha of a 
branch you can checkout to get the branch back.

When a branch is merged, git allows you do delete the branch with: git branch 
-d , if branch is not merged you’ve to force it with -D: git branch -D 

To cut a maintenance release from a release version, all you’ll have to do it:
git checkout -b  

HTH.

> I think the model the article proposes, fits the products like SAS, when
> there are no maintenance releases and support is provided just for the
> latest release.  Then of course, to get the latest stable release, it
> would make sense to access master branch which is always stable. In case
> when multiple releases are being maintained at the same time - like CS -
> it would make sense to keep release branches. Otherwise how are you going
> to handle this situation:
>
> 4.2, 4.3 and 4.4 are released
> Master reflects 4.4
> Maintenance 4.2.1 and 4.3.1 releases are needed
>
> Questions:
> How do you create those releases, from what branch?
> How do you merge and tag them into master branch considering that the
> latest version there is 4.4?
>
> Thanks,
> Alena.
>
>
>
>
> On 8/5/14, 11:36 PM, "Daan Hoogland"  wrote:
>
>> Exactly Rajani, and other solutions are possible. The issue is not how
>> branches are called ;)
>>
>> On Wed, Aug 6, 2014 at 8:29 AM, Rajani Karuturi
>>  wrote:
>>> I am just wondering if the shift to a new develop branch is causing the
>>> problems. Its a simple branch shift and should be no different from the
>>> current master.
>>>
>>> may be we should leave the master as is and create a Œstable' branch
>>> which would act like master in git-flow ?
>>>
>>> ie)
>>> ACS master -> develop in git-flow
>>> ACS stable -> master in git-flow
>>>
>>>
>>> ~Rajani
>>>
>>>
>>>
>>> On 06-Aug-2014, at 10:56 am, Daan Hoogland 
>>> wrote:
>>>
 Hello devs and especially committters,

 I see some -1s coming by, days after the vote was closed. That is
 disturbing as it means we accepted a proposal that will not be
 supported by the community. So let me try to find that support in
 hindsight;

 The argument of Animesh that we are shifting the burden from one
 branch to another is real and present danger. I share his concern. It
 is not the only feature of this proposal and in it self does not
 warrant a -1. It does not worsen the situation at hand or add to our
 workload in any way. If there is no advantage to you and no
 disadvantage either then why -1 something that others do find useful?
 This is 'kind of' a rhetorical question. It is a real concern, however
 though not the biggest at this moment.

 branching is recommended but as people are rightfully wondering
 "should I make a branch for a single line fix". I would, probably but
 maybe not always. That doesn't mean you must. In case you are making a
 fix on a release then yes you do. It is how the git-flow workflow
 goes.

 Committers can merge and commit where ever they feel the need. That
 doesn't exempt them from thinking if it is a good idea. It doesn't now
 a

Re: [VOTE] git workflow

[Alena Prokharchyk]

Rohit, thank you for the explanation. So we cut the maintenance release
from the master branch, not *develop as opposed to the major release
branch.

One more open question. Its clear that we cut the maintenance release from
the master branch, but what would be the right way to merge it back if
this is a maintenance release for say 4.2, and 4.4 is the top of the
master branch? Where would the 4.2.1 tag appear? It can’t be on a top of
4.4


All the above should be documented in the proposal. The original proposal
didn’t mention anything about how we are going to do maintenance branches.
And we were originally thinking about leaving the release branches around.

Thanks,
Alena.


On 8/6/14, 10:16 AM, "Rohit Yadav"  wrote:

>
>On 06-Aug-2014, at 6:58 pm, Alena Prokharchyk
> wrote:
>
>> Why implement something that doesn¹t serve any practical purpose for
>>CS??
>> We should adopt only things that would address current CS problems -
>> regressions, unstable releases, etc. That would mean - running the
>> automation (CI, BVT) on *develop branch, cut the *fix branches for hot
>> fixes/critical/feature bugs only and run BVT on them before merging to
>> *develop; merge only stable code from *develop to master branch.
>>
>> There would be no use for master branch if it reflects the latest
>>release
>> branch, which will always be present in CS model as opposed to what
>> original article suggests. Below the explanation from the other email
>> thread on why the release branches can¹t be removed in CS model:
>>
>> Rohit:
>> 
>>
>> "IMO We ³should" remove the release branches when done. Instead there
>>is a
>> support workflow with git-flow (see support
>> http://yakiloo.com/getting-started-git-flow/) and also in the tooling
>>(git
>> flow support etc. though experimental).²
>>
>> Alena:
>> ==
>> If we remove the release branches, how are we going to handle
>>maintenance
>> releases for older versions of the code? It wouldn¹t work as its
>> impossible to cut a maintenance release from develop branch.
>
>When you merge --no-ff a release/any branch on master/target branch, the
>version history stays with it.
>Not only we merge it on master, we do a tag on it as well. Now to get the
>history/branch back you can always checkout the tag: git checkout 
>and see the history:
>git log --graph --decorate --pretty=oneline --abbrev-commit —all
>
>So, it’s safe to delete a branch when it’s merged to a target/master
>branch.
>If you have never deleted a feature branch once it was merged, you should
>try and see for yourself. At the end of the day, git is all but link-list
>logic at the core. The branch too tracks just the HEAD, if you’ve
>refs/tag/sha of a branch you can checkout to get the branch back.
>
>When a branch is merged, git allows you do delete the branch with: git
>branch -d , if branch is not merged you’ve to force it with -D:
>git branch -D 
>To cut a maintenance release from a release version, all you’ll have to
>do it:
>git checkout -b  
>
>HTH.
>
>> I think the model the article proposes, fits the products like SAS, when
>> there are no maintenance releases and support is provided just for the
>> latest release.  Then of course, to get the latest stable release, it
>> would make sense to access master branch which is always stable. In case
>> when multiple releases are being maintained at the same time - like CS -
>> it would make sense to keep release branches. Otherwise how are you
>>going
>> to handle this situation:
>>
>> 4.2, 4.3 and 4.4 are released
>> Master reflects 4.4
>> Maintenance 4.2.1 and 4.3.1 releases are needed
>>
>> Questions:
>> How do you create those releases, from what branch?
>> How do you merge and tag them into master branch considering that the
>> latest version there is 4.4?
>>
>> Thanks,
>> Alena.
>>
>>
>>
>>
>> On 8/5/14, 11:36 PM, "Daan Hoogland"  wrote:
>>
>>> Exactly Rajani, and other solutions are possible. The issue is not how
>>> branches are called ;)
>>>
>>> On Wed, Aug 6, 2014 at 8:29 AM, Rajani Karuturi
>>>  wrote:
 I am just wondering if the shift to a new develop branch is causing
the
 problems. Its a simple branch shift and should be no different from
the
 current master.

 may be we should leave the master as is and create a Œstable' branch
 which would act like master in git-flow ?

 ie)
 ACS master -> develop in git-flow
 ACS stable -> master in git-flow


 ~Rajani



 On 06-Aug-2014, at 10:56 am, Daan Hoogland 
 wrote:

> Hello devs and especially committters,
>
> I see some -1s coming by, days after the vote was closed. That is
> disturbing as it means we accepted a proposal that will not be
> supported by the community. So let me try to find that support in
> hindsight;
>
> The argument of Animesh that we are shifting the burden from one
> branch to another is real and present danger. I share his concern. It
> is not the on

Re: Review Request 24314: CLOUDSTACK-6695: UI: Added support for uploading a chain of certificates

[Nitin Mehta]

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


I tested the flow and it looks good to me.
I did review the code but best to have a UI expert to take a look as well.

- Nitin Mehta


On Aug. 5, 2014, 9:03 p.m., Mihaela Stoica wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24314/
> ---
> 
> (Updated Aug. 5, 2014, 9:03 p.m.)
> 
> 
> Review request for cloudstack, Brian Federle, Jessica Wang, and Nitin Mehta.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6695: Added support to the UI for uploading a chain of certificates
> 
> In the "SSL Certificate" dialog we added:
> - new field for the root certificate; 
> - a button to add intermediate certificates if necessary; when this is 
> pressed, a new field, called "Intermediate certificate 1" is added; pressed 
> again, "Intermediate certificate 2" field is added, and so on.
> 
> We upload the certificates in order: first the root certificate (with id=1), 
> then the intermediate certificates (with id=2,3,..) and finally the server 
> certificate.
> When uploading a certificate, we wait for the upload to be completed 
> succesfully and only then we proceed to uploading the next one. If one fails, 
> we report failure and don't continue with the remaining.
> 
> 
> Diffs
> -
> 
>   client/WEB-INF/classes/resources/messages.properties a0205e1 
>   ui/css/cloudstack3.css 23681a7 
>   ui/dictionary.jsp 10aeaf9 
>   ui/scripts/ui-custom/physicalResources.js ac379b4 
> 
> Diff: https://reviews.apache.org/r/24314/diff/
> 
> 
> Testing
> ---
> 
> Yes, with a sample certificate chain.
> 
> 
> Thanks,
> 
> Mihaela Stoica
> 
>

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

[Nitin Mehta]

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.dns1 dns1,
>data_center.dns2 dns2,
>data_center.ip6_dns1 ip6_dns1,
>data_center.ip6_dns2 ip6_dns2,
>host.id host_id,
>host.uuid host_uuid,
>host.name host_name,
>   host.hypervisor_type,
>host.cluster_id cluster_id,
>vm_template.id template_id,
>vm_template.uuid template_uuid,
>service_offering.id service_offering_id,
>disk_offering.uuid service_offering_uuid,
>disk_offering.name service_offering_name,
>nics.id nic_id,
>nics.uuid nic_uuid,
>nics.network_id network_id,
>nics.ip4_address ip_address,
>nics.ip6_address ip6_address,
>nics.ip6_gateway ip6_gateway,
>nics.ip6_cidr ip6_cidr,
>nics.default_nic is_default_nic,
>nics.gateway gateway,
>nics.netmask netmask,
>nics.mac_address mac_address,
>nics.broadcast_uri broadcast_uri,
>nics.isolation_uri isolation_uri,
>vpc.id vpc_id,
>vpc.uuid vpc_uuid,
>networks.uuid network_uuid,
>networks.name network_name,
>networks.network_domain network_domain,
>networks.traffic_type traffic_type,
>networks.guest_type guest_type,
>async_job.id job_id,
>async_job.uuid job_uuid,
>async_job.job_status job_status,
>async_job.account_id job_account_id,
>domain_router.template_version template_version,
>domain_router.scripts_version scripts_version,
>domain_router.is_redundant_router is_redundant_router,
>domain_router.redundant_state redundant_state,
>domain_router.stop_pending stop_pending,
>domain_router.role role
>from
>`cloud`.`domain_router`
>   inner join
>`cloud`.`vm_instance` ON vm_instance.id = domain_router.id
>inner join
>`cloud`.`account` ON vm_instance.account_id = account.id
>inner join
>`cloud`.`domain` ON vm_instance.domain_id = domain.id
>left join
>`cloud`.`host_pod_ref` ON vm_instance.pod_id = host_pod_ref.id
>left join
>`cloud`.`projects` ON projects.project_account_id = account.id
>left join
>`cloud`.`data_center` ON vm_instance.data_center_id =
>data_center.id
>left join
>`cloud`.`host` ON vm_instance.host_id = host.id
>left join
>`cloud`.`vm_template` ON vm_instance.vm_template_id =
>vm_template.id
>left join
>   `cloud`.`service_offering` ON vm_instance.service_offering_id =
>service_offering.id
>left join
>`clo

Re: [VOTE] git workflow

[Rohit Yadav]

Hi,

On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk  
wrote:

> Rohit, thank you for the explanation. So we cut the maintenance release
> from the master branch, not *develop as opposed to the major release
> branch.
>
> One more open question. Its clear that we cut the maintenance release from
> the master branch, but what would be the right way to merge it back if
> this is a maintenance release for say 4.2, and 4.4 is the top of the
> master branch? Where would the 4.2.1 tag appear? It can’t be on a top of
> 4.4

You checkout a support branch from 4.2 tag (or for that matter you may keep the 
4.2 release branch, it’s same) for LTS/support.
You tag 4.2.1 on the support branch. (it’s the same way you would do like we do 
it now). I think git-flow is suitable for rolling releases and may not 100% 
work with our deployment/release process. One thing I’ve suggested is 
shortening of our release cycles which can help.

The flow of commits/fixes/changes would follow the baseline protocol — from 
firm branch to soft branches chronologically, so if there is a bug on 4.2 
release you fix it on 4.2 support branch and cherry-pick/apply/merge that 
branch/commit(s) to 4.3 release branch and then to 4.4 support branch … to 4.5 
release branch to develop branch.

I think git-flow assumes the releases will be chronological so you don’t 
release 4.3.1 after 4.4 etc and you always progress? I’m not sure.
We can think of better ways of doing things, we can also learn from how other 
projects do it.

Maintaining major versions/releases such as 4.2, 4.3, 4.4 will be painful, that 
always felt to me like maintaining a whole different product. If we can do 
something about that, we’re going to make a lot of people happy IMO.

>
>
> All the above should be documented in the proposal. The original proposal
> didn’t mention anything about how we are going to do maintenance branches.
> And we were originally thinking about leaving the release branches around.
>
> Thanks,
> Alena.
>
>
> On 8/6/14, 10:16 AM, "Rohit Yadav"  wrote:
>
>>
>> On 06-Aug-2014, at 6:58 pm, Alena Prokharchyk
>>  wrote:
>>
>>> Why implement something that doesn¹t serve any practical purpose for
>>> CS??
>>> We should adopt only things that would address current CS problems -
>>> regressions, unstable releases, etc. That would mean - running the
>>> automation (CI, BVT) on *develop branch, cut the *fix branches for hot
>>> fixes/critical/feature bugs only and run BVT on them before merging to
>>> *develop; merge only stable code from *develop to master branch.
>>>
>>> There would be no use for master branch if it reflects the latest
>>> release
>>> branch, which will always be present in CS model as opposed to what
>>> original article suggests. Below the explanation from the other email
>>> thread on why the release branches can¹t be removed in CS model:
>>>
>>> Rohit:
>>> 
>>>
>>> "IMO We ³should" remove the release branches when done. Instead there
>>> is a
>>> support workflow with git-flow (see support
>>> http://yakiloo.com/getting-started-git-flow/) and also in the tooling
>>> (git
>>> flow support etc. though experimental).²
>>>
>>> Alena:
>>> ==
>>> If we remove the release branches, how are we going to handle
>>> maintenance
>>> releases for older versions of the code? It wouldn¹t work as its
>>> impossible to cut a maintenance release from develop branch.
>>
>> When you merge --no-ff a release/any branch on master/target branch, the
>> version history stays with it.
>> Not only we merge it on master, we do a tag on it as well. Now to get the
>> history/branch back you can always checkout the tag: git checkout 
>> and see the history:
>> git log --graph --decorate --pretty=oneline --abbrev-commit —all
>>
>> So, it’s safe to delete a branch when it’s merged to a target/master
>> branch.
>> If you have never deleted a feature branch once it was merged, you should
>> try and see for yourself. At the end of the day, git is all but link-list
>> logic at the core. The branch too tracks just the HEAD, if you’ve
>> refs/tag/sha of a branch you can checkout to get the branch back.
>>
>> When a branch is merged, git allows you do delete the branch with: git
>> branch -d , if branch is not merged you’ve to force it with -D:
>> git branch -D 
>> To cut a maintenance release from a release version, all you’ll have to
>> do it:
>> git checkout -b  
>>
>> HTH.
>>
>>> I think the model the article proposes, fits the products like SAS, when
>>> there are no maintenance releases and support is provided just for the
>>> latest release.  Then of course, to get the latest stable release, it
>>> would make sense to access master branch which is always stable. In case
>>> when multiple releases are being maintained at the same time - like CS -
>>> it would make sense to keep release branches. Otherwise how are you
>>> going
>>> to handle this situation:
>>>
>>> 4.2, 4.3 and 4.4 are released
>>> Master reflects 4.4
>>> Maintenance 4.2.1 and 4.3.1 rel

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

[Alena Prokharchyk]

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.dns1 dns1,
>>data_center.dns2 dns2,
>>data_center.ip6_dns1 ip6_dns1,
>>data_center.ip6_dns2 ip6_dns2,
>>host.id host_id,
>>host.uuid host_uuid,
>>host.name host_name,
>>   host.hypervisor_type,
>>host.cluster_id cluster_id,
>>vm_template.id template_id,
>>vm_template.uuid template_uuid,
>>service_offering.id service_offering_id,
>>disk_offering.uuid service_offering_uuid,
>>disk_offering.name service_offering_name,
>>nics.id nic_id,
>>nics.uuid nic_uuid,
>>nics.network_id network_id,
>>nics.ip4_address ip_address,
>>nics.ip6_address ip6_address,
>>nics.ip6_gateway ip6_gateway,
>>nics.ip6_cidr ip6_cidr,
>>nics.default_nic is_default_nic,
>>nics.gateway gateway,
>>nics.netmask netmask,
>>nics.mac_address mac_address,
>>nics.broadcast_uri broadcast_uri,
>>nics.isolation_uri isolation_uri,
>>vpc.id vpc_id,
>>vpc.uuid vpc_uuid,
>>networks.uuid network_uuid,
>>networks.name network_name,
>>networks.network_domain network_domain,
>>networks.traffic_type traffic_type,
>>networks.guest_type guest_type,
>>async_job.id job_id,
>>async_job.uuid job_uuid,
>>async_job.job_status job_status,
>>async_job.account_id job_account_id,
>>domain_router.template_version template_version,
>>domain_router.scripts_version scripts_version,
>>domain_router.is_redundant_router is_redundant_router,
>>domain_router.redundant_state redundant_state,
>>domain_router.stop_pending stop_pending,
>>domain_router.role role
>>from
>>`cloud`.`domain_router`
>>   inner join
>>`cloud`.`vm_instance` ON vm_instance.id = domain_router.id
>>inner join
>>`cloud`.`account` ON vm_instance.account_id = account.id
>>inner join
>>`cloud`.`domain` ON vm_instance.domain_id = domain.id
>>left join
>>`cloud`.`host_pod_ref` ON vm_instance.pod_id = host_pod_ref

Re: [VOTE] git workflow

[Alena Prokharchyk]

Rohit, whatever you say below, just proves our original worry about
handling the maintenance minor releases (see my comments below). We can’t
possibly adopt the way where release branches get removed since we always
support maintenance releases for multiple versions at a time: 4.2.1,
4.3.1, 4.4.1.

Thanks,
Alena.

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

>Hi,
>
>On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk
> wrote:
>
>> Rohit, thank you for the explanation. So we cut the maintenance release
>> from the master branch, not *develop as opposed to the major release
>> branch.
>>
>> One more open question. Its clear that we cut the maintenance release
>>from
>> the master branch, but what would be the right way to merge it back if
>> this is a maintenance release for say 4.2, and 4.4 is the top of the
>> master branch? Where would the 4.2.1 tag appear? It can’t be on a top of
>> 4.4
>
>You checkout a support branch from 4.2 tag (or for that matter you may
>keep the 4.2 release branch, it’s same) for LTS/support.
>You tag 4.2.1 on the support branch. (it’s the same way you would do like
>we do it now). I think git-flow is suitable for rolling releases and may
>not 100% work with our deployment/release process. One thing I’ve
>suggested is shortening of our release cycles which can help.

The argument - "I’ve suggested is shortening of our release cycles which
can help.” - can’t be taken to consideration as its not implemented. Only
after its implemented, and we agree that we don’t support minor releases,
then we can use it.


>
>The flow of commits/fixes/changes would follow the baseline protocol —
>from firm branch to soft branches chronologically, so if there is a bug
>on 4.2 release you fix it on 4.2 support branch and
>cherry-pick/apply/merge that branch/commit(s) to 4.3 release branch and
>then to 4.4 support branch … to 4.5 release branch to develop branch.


So we do keep the releases branches? :) Which what “support” branch
eventually becomes. You get rid of release branch by merging and tagging
it to master, but eventually you bring it back once its time for minor
maintenance release, but now call it “support”. And if you are cutting
support branch for 4.2.1, you need to merge changes to all the branches on
master! By creating support branches for 4.2, 4.3, 4.4, 4.5. That doesn’t
seem like a valid model to me.



>
>I think git-flow assumes the releases will be chronological so you don’t
>release 4.3.1 after 4.4 etc and you always progress? I’m not sure.
>We can think of better ways of doing things, we can also learn from how
>other projects do it.


That’s what I was afraid of, and already pointed it out that the model the
article suggest, suits only SAAS like models, when there is no support for
minor maintenance releases.


>
>Maintaining major versions/releases such as 4.2, 4.3, 4.4 will be
>painful, that always felt to me like maintaining a whole different
>product. If we can do something about that, we’re going to make a lot of
>people happy IMO.
>
>>
>>
>> All the above should be documented in the proposal. The original
>>proposal
>> didn’t mention anything about how we are going to do maintenance
>>branches.
>> And we were originally thinking about leaving the release branches
>>around.
>>
>> Thanks,
>> Alena.
>>
>>
>> On 8/6/14, 10:16 AM, "Rohit Yadav"  wrote:
>>
>>>
>>> On 06-Aug-2014, at 6:58 pm, Alena Prokharchyk
>>>  wrote:
>>>
 Why implement something that doesn¹t serve any practical purpose for
 CS??
 We should adopt only things that would address current CS problems -
 regressions, unstable releases, etc. That would mean - running the
 automation (CI, BVT) on *develop branch, cut the *fix branches for hot
 fixes/critical/feature bugs only and run BVT on them before merging to
 *develop; merge only stable code from *develop to master branch.

 There would be no use for master branch if it reflects the latest
 release
 branch, which will always be present in CS model as opposed to what
 original article suggests. Below the explanation from the other email
 thread on why the release branches can¹t be removed in CS model:

 Rohit:
 

 "IMO We ³should" remove the release branches when done. Instead there
 is a
 support workflow with git-flow (see support
 http://yakiloo.com/getting-started-git-flow/) and also in the tooling
 (git
 flow support etc. though experimental).²

 Alena:
 ==
 If we remove the release branches, how are we going to handle
 maintenance
 releases for older versions of the code? It wouldn¹t work as its
 impossible to cut a maintenance release from develop branch.
>>>
>>> When you merge --no-ff a release/any branch on master/target branch,
>>>the
>>> version history stays with it.
>>> Not only we merge it on master, we do a tag on it as well. Now to get
>>>the
>>> history/branch back you can always checkout the tag: git checkou

Re: [VOTE] git workflow

[David Nalley]

On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav  wrote:
> Hi,
>
> On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk  
> wrote:
>
>> Rohit, thank you for the explanation. So we cut the maintenance release
>> from the master branch, not *develop as opposed to the major release
>> branch.
>>
>> One more open question. Its clear that we cut the maintenance release from
>> the master branch, but what would be the right way to merge it back if
>> this is a maintenance release for say 4.2, and 4.4 is the top of the
>> master branch? Where would the 4.2.1 tag appear? It can’t be on a top of
>> 4.4
>
> You checkout a support branch from 4.2 tag (or for that matter you may keep 
> the 4.2 release branch, it’s same) for LTS/support.
> You tag 4.2.1 on the support branch. (it’s the same way you would do like we 
> do it now). I think git-flow is suitable for rolling releases and may not 
> 100% work with our deployment/release process. One thing I’ve suggested is 
> shortening of our release cycles which can help.
>

So I suspect that checking out a tag would work. I don't know that
once we create a tag, that we would be able to merge that back into
master. Especially true for maintenance releases. How and where would
we merge 4.5.1 back into master? Moreover, I don't see us getting out
of checking out the tag, and creating a branch to work in. That means
we'd delete a branch, check out a tag, create a branch, create a new
tag, delete a branch - and repeat.

That said, we don't currently have rolling releases - and now you are
suggesting it may not 100% work. *sigh*

> The flow of commits/fixes/changes would follow the baseline protocol — from 
> firm branch to soft branches chronologically, so if there is a bug on 4.2 
> release you fix it on 4.2 support branch and cherry-pick/apply/merge that 
> branch/commit(s) to 4.3 release branch and then to 4.4 support branch … to 
> 4.5 release branch to develop branch.
>
> I think git-flow assumes the releases will be chronological so you don’t 
> release 4.3.1 after 4.4 etc and you always progress? I’m not sure.
> We can think of better ways of doing things, we can also learn from how other 
> projects do it.
>
> Maintaining major versions/releases such as 4.2, 4.3, 4.4 will be painful, 
> that always felt to me like maintaining a whole different product. If we can 
> do something about that, we’re going to make a lot of people happy IMO.
>
>>

So we've set the expectation that we'll follow SemVer - and adhering
to that is a good thing. Rolling releases are interesting, but we are
a long way from being able to do anything remotely close IMO.

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

[Nitin Mehta]

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.dns1 dns1,
>>>data_center.dns2 dns2,
>>>data_center.ip6_dns1 ip6_dns1,
>>>data_center.ip6_dns2 ip6_dns2,
>>>host.id host_id,
>>>host.uuid host_uuid,
>>>host.name host_name,
>>>   host.hypervisor_type,
>>>host.cluster_id cluster_id,
>>>vm_template.id template_id,
>>>vm_template.uuid template_uuid,
>>>service_offering.id service_offering_id,
>>>disk_offering.uuid service_offering_uuid,
>>>disk_offering.name service_offering_name,
>>>nics.id nic_id,
>>>nics.uuid nic_uuid,
>>>nics.network_id network_id,
>>>nics.ip4_address ip_address,
>>>nics.ip6_address ip6_address,
>>>nics.ip6_gateway ip6_gateway,
>>>nics.ip6_cidr ip6_cidr,
>>>nics.default_nic is_default_nic,
>>>nics.gateway gateway,
>>>nics.netmask netmask,
>>>nics.mac_address mac_address,
>>>nics.broadcast_uri broadcast_uri,
>>>nics.isolation_uri isolation_uri,
>>>vpc.id vpc_id,
>>>vpc.uuid vpc_uuid,
>>>networks.uuid network_uuid,
>>>networks.name network_name,
>>>networks.network_domain network_domain,
>>>networks.traffic_type traffic_type,
>>>networks.guest_type guest_type,
>>>async_job.id job_id,
>>>async_job.uuid job_uuid,
>>>async_job.job_status job_status,
>>>async_job.account_id job_account_id,
>>>domain_router.template_version template_version,
>>>domain_router.scripts_version scripts_version,
>>>domain_router.is_redundant_router is_redundant_router,
>>>domain_router.redundant_state redundant_state,
>>>domain_router.stop_pending stop_pending,
>>>domain_router.role role
>>>from
>>>`cloud`.`domain_router`
>>>   inner join
>>>`cloud`.`vm_instance` ON vm_instance.id = domain_router.id
>>>inner join
>>>`cloud`.`account` ON

Re: [VOTE] git workflow

[Alena Prokharchyk]

On 8/6/14, 11:22 AM, "David Nalley"  wrote:

>On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav 
>wrote:
>> Hi,
>>
>> On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk
>> wrote:
>>
>>> Rohit, thank you for the explanation. So we cut the maintenance release
>>> from the master branch, not *develop as opposed to the major release
>>> branch.
>>>
>>> One more open question. Its clear that we cut the maintenance release
>>>from
>>> the master branch, but what would be the right way to merge it back if
>>> this is a maintenance release for say 4.2, and 4.4 is the top of the
>>> master branch? Where would the 4.2.1 tag appear? It can¹t be on a top
>>>of
>>> 4.4
>>
>> You checkout a support branch from 4.2 tag (or for that matter you may
>>keep the 4.2 release branch, it¹s same) for LTS/support.
>> You tag 4.2.1 on the support branch. (it¹s the same way you would do
>>like we do it now). I think git-flow is suitable for rolling releases
>>and may not 100% work with our deployment/release process. One thing
>>I¹ve suggested is shortening of our release cycles which can help.
>>
>
>So I suspect that checking out a tag would work. I don't know that
>once we create a tag, that we would be able to merge that back into
>master. Especially true for maintenance releases. How and where would
>we merge 4.5.1 back into master? Moreover, I don't see us getting out
>of checking out the tag, and creating a branch to work in. That means
>we'd delete a branch, check out a tag, create a branch, create a new
>tag, delete a branch - and repeat.
>
>That said, we don't currently have rolling releases - and now you are
>suggesting it may not 100% work. *sigh*

Dave, you are right, we can¹t. There is no way to merge back minor
releases back to master branch, and preserve the history. The model works
only for rolling releases. So making master reflect release branch won¹t
make sense in CS case.

>
>> The flow of commits/fixes/changes would follow the baseline protocol ‹
>>from firm branch to soft branches chronologically, so if there is a bug
>>on 4.2 release you fix it on 4.2 support branch and
>>cherry-pick/apply/merge that branch/commit(s) to 4.3 release branch and
>>then to 4.4 support branch Š to 4.5 release branch to develop branch.
>>
>> I think git-flow assumes the releases will be chronological so you
>>don¹t release 4.3.1 after 4.4 etc and you always progress? I¹m not sure.
>> We can think of better ways of doing things, we can also learn from how
>>other projects do it.
>>
>> Maintaining major versions/releases such as 4.2, 4.3, 4.4 will be
>>painful, that always felt to me like maintaining a whole different
>>product. If we can do something about that, we¹re going to make a lot of
>>people happy IMO.
>>
>>>
>
>So we've set the expectation that we'll follow SemVer - and adhering
>to that is a good thing. Rolling releases are interesting, but we are
>a long way from being able to do anything remotely close IMO.

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

[Mike Tutkowski]

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.dns1 dns1,
> >>>data_center.dns2 dns2,
> >>>data_center.ip6_dns1 ip6_dns1,
> >>>data_center.ip6_dns2 ip6_dns2,
> >>>host.id host_id,
> >>>host.uuid host_uuid,
> >>>host.name host_name,
> >>>   host.hypervisor_type,
> >>>host.cluster_id cluster_id,
> >>>vm_template.id template_id,
> >>>vm_template.uuid template_uuid,
> >>>service_offering.id service_offering_id,
> >>>disk_offering.uuid service_offering_uuid,
> >>>disk_offering.name service_offering_name,
> >>>nics.id nic_id,
> >>>nics.uuid nic_uuid,
> >>>nics.network_id network_id,
> >>>nics.ip4_address ip_address,
> >>>nics.ip6_address ip6_address,
> >>>nics.ip6_gateway ip6_gateway,
> >>>nics.ip6_cidr ip6_cidr,
> >>>nics.default_nic is_default_nic,
> >>>nics.gateway gateway,
> >>>nics.netmask netmask,
> >>>nics.mac_address mac_address,
> >>>nics.broadcast_uri broadcast_uri,
> >>>nics.isolation_uri isolation_uri,
> >>>vpc.id vpc_id,
> >>>vpc.uuid vpc_uuid,
> >>>networks.uuid network_uuid,
> >>>networks.name network_name,
> >>>networks.network_domain network_domain,
> >>>networks.traffic_type traffic_type,
> >>>networks.guest_type guest_type,
> >>>async_job.id job_id,
> >>>async_job.uuid job_uuid,
> >>>async_job.job_status job_status,
> >>>async_job.account_

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

[Abhinav Roy]

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&serviceofferingid=d4206400-e06a-4c58-bdf1-97df6bf06592&iptonetworklist%5B0%5D.networkid=190a586d-833e-4ff8-ba0c-6c5ce7bbfd2e&_=1407340991465
2014-08-06 21:42:23,043 DEBUG [o.a.c.a.BaseCmd] (catalina-exec-25:ctx-e2a0589a 
ctx-7a1d3c27) Ignoring paremeter displayvm as the caller is not authorized to 
pass it in
2014-08-06 21:42:23,043 DEBUG [o.a.c.a.BaseCmd] (catalina-exec-25:ctx-e2a0589a 
ctx-7a1d3c27) Ignoring paremeter deploymentplanner as the caller is not 
authorized to pass it in
2014-08-06 21:42:23,069 DEBUG [o.a.c.a.BaseCmd] (catalina-exec-25:ctx-e2a0589a 
ctx-7a1d3c27) Ignoring paremeter displayvm as the caller is not authorized to 
pass it in
2014-08-06 21:42:23,069 DEBUG [o.a.c.a.BaseCmd] (catalina-exec-25:ctx-e2a0589a 
ctx-7a1d3c27) Ignoring paremeter deploymentplanner as the caller is not 
authorized to pass it in
2014-08-06 21:42:23,190 DEBUG [c.c.n.NetworkModelImpl] 
(catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Service SecurityGroup is not 
supported in the network id=222
2014-08-06 21:42:23,207 DEBUG [c.c.v.UserVmManagerImpl] 
(catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Allocating in the DB for vm
2014-08-06 21:42:23,225 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Allocating entries for VM: 
VM[User|i-41-64-VM]
2014-08-06 21:42:23,228 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Allocating nics for 
VM[User|i-41-64-VM]
2014-08-06 21:42:23,229 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
(catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Allocating nic for vm 
VM[User|i-41-64-VM] in network Ntwk[222|Guest|8] with requested profile 
NicProfile[0-0-null-null-null
2014-08-06 21:42:23,256 DEBUG [c.c.n.NetworkModelImpl] 
(catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Service SecurityGroup is not 
supported in the network id=222
2014-08-06 21:42:23,258 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Allocating disks for 
VM[User|i-41-64-VM]
2014-08-06 21:42:23,274 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Allocation completed for V

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

[Alena Prokharchyk]

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 
mailto:mike.tutkow...@solidfire.com>>
Date: Wednesday, August 6, 2014 at 11:33 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Cc: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>, Koushik 
Das mailto:koushik@citrix.com>>
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 
mailto:nitin.me...@citrix.com>> 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.dns1 dns1,
>>>data_center.dns2 dns2,
>>>data_center.ip6_dns1 ip6_dns1,
>>>data_center.ip6_dns2 ip6_dns2,
>>>host.id host_id,
>>>host.uuid host_uuid,
>>>host.name host_name,
>>>   host.hypervisor_type,
>>>host.cluster_id cluster_id,
>>>vm_template.id template_id,
>>>vm_template.uuid template_uuid,
>>>service_offering.id service_offering_id,
>>>disk_offering.uuid service_offering_uuid,
>>>disk_offering.name service_offering_name,
>>>nics.id nic_id,
>>>nics.uuid nic

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

[Nitin Mehta]

Mike - I agree that automation might not resolve the issue completely but
will better devs lives.
I think for schema file changes just the diffs published should do. For
Java files it might sometimes require some more analysis and manual input
from dev.
Nevertheless it will always send a notification that some db changes were
made and so people pulling in from master won't be in dark whether there
were some db changes or not.

Thanks,
-Nitin



On 06/08/14 11:40 AM, "Alena Prokharchyk" 
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
>mailto:mike.tutkow...@solidfire.com>>
>Date: Wednesday, August 6, 2014 at 11:33 AM
>To: "dev@cloudstack.apache.org"
>mailto:dev@cloudstack.apache.org>>
>Cc: Alena Prokharchyk
>mailto:alena.prokharc...@citrix.com>>,
>Koushik Das mailto:koushik@citrix.com>>
>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
>mailto:nitin.me...@citrix.com>> 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.dns1 dns1,
data_center.dns2 dns2,
data_center.ip6_dns1 ip6_dns1,
data

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

[Mike Tutkowski]

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.dns1 dns1,
>> >>>data_center.dns2 dns2,
>> >>>data_center.ip6_dns1 ip6_dns1,
>> >>>data_center.ip6_dns2 ip6_dns2,
>> >>>host.id host_id,
>> >>>host.uuid host_uuid,
>> >>>host.name host_name,
>> >>>   host.hypervisor_type,
>> >>>host.cluster_id cluster_id,
>> >>>vm_template.id template_id,
>> >>>vm_template.uuid template_uuid,
>> >>>service_offering.id service_offering_id,
>> >>>disk_offering.uuid service_offering_uuid,
>> >>>disk_offering.name service_offering_name,
>> >>>nics.id nic_id,

Re: [VOTE] git workflow

[Rohit Yadav]

Hi,

If it was not clear, let me re-state — just because I’m participating in this 
thread does not mean I fully support git-flow, or I am here to defend it.

The proposal thread warriors Rajani, Daan, Leo and others can comment and 
advise?

I like couple of good ideas in it, and I think it’s better than what we do, 
especially the baseline protocol. I want to take good stuff from it and adapt 
them to our workflow. As I see now, this won't change our process/workflow a 
lot or that it can stop bad commits or practices from happening in our 
repositories.

I’ve emailed git-flow’s author about raised issues, will keep everyone posted.

Cheers.

On 06-Aug-2014, at 8:29 pm, Alena Prokharchyk  
wrote:
>
> On 8/6/14, 11:22 AM, "David Nalley"  wrote:
>
>> On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav 
>> wrote:
>>> Hi,
>>>
>>> On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk
>>>  wrote:
>>>
 Rohit, thank you for the explanation. So we cut the maintenance release
 from the master branch, not *develop as opposed to the major release
 branch.

 One more open question. Its clear that we cut the maintenance release
 from
 the master branch, but what would be the right way to merge it back if
 this is a maintenance release for say 4.2, and 4.4 is the top of the
 master branch? Where would the 4.2.1 tag appear? It can¹t be on a top
 of
 4.4
>>>
>>> You checkout a support branch from 4.2 tag (or for that matter you may
>>> keep the 4.2 release branch, it¹s same) for LTS/support.
>>> You tag 4.2.1 on the support branch. (it¹s the same way you would do
>>> like we do it now). I think git-flow is suitable for rolling releases
>>> and may not 100% work with our deployment/release process. One thing
>>> I¹ve suggested is shortening of our release cycles which can help.
>>>
>>
>> So I suspect that checking out a tag would work. I don't know that
>> once we create a tag, that we would be able to merge that back into
>> master. Especially true for maintenance releases. How and where would
>> we merge 4.5.1 back into master? Moreover, I don't see us getting out
>> of checking out the tag, and creating a branch to work in. That means
>> we'd delete a branch, check out a tag, create a branch, create a new
>> tag, delete a branch - and repeat.
>>
>> That said, we don't currently have rolling releases - and now you are
>> suggesting it may not 100% work. *sigh*
>
> Dave, you are right, we can¹t. There is no way to merge back minor
> releases back to master branch, and preserve the history. The model works
> only for rolling releases. So making master reflect release branch won¹t
> make sense in CS case.
>
>>
>>> The flow of commits/fixes/changes would follow the baseline protocol ‹
>>> from firm branch to soft branches chronologically, so if there is a bug
>>> on 4.2 release you fix it on 4.2 support branch and
>>> cherry-pick/apply/merge that branch/commit(s) to 4.3 release branch and
>>> then to 4.4 support branch Š to 4.5 release branch to develop branch.
>>>
>>> I think git-flow assumes the releases will be chronological so you
>>> don¹t release 4.3.1 after 4.4 etc and you always progress? I¹m not sure.
>>> We can think of better ways of doing things, we can also learn from how
>>> other projects do it.
>>>
>>> Maintaining major versions/releases such as 4.2, 4.3, 4.4 will be
>>> painful, that always felt to me like maintaining a whole different
>>> product. If we can do something about that, we¹re going to make a lot of
>>> people happy IMO.
>>>

>>
>> So we've set the expectation that we'll follow SemVer - and adhering
>> to that is a good thing. Rolling releases are interesting, but we are
>> a long way from being able to do anything remotely close IMO.

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 oper

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

[Rohit Yadav]

If you care, why not self-police use git hooks:
http://markmail.org/message/h5yb27jy6qrrw4dh

Cheers.

On 06-Aug-2014, at 8:51 pm, 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.dns1 dns1,
>>   data_center.dns2 dns2,
>>   data_center.ip6_dns1 ip6_dns1,
>>   data_center.ip6_dns2 ip6_dns2,
>>   host.id host_id,
>>   host.uuid host_uuid,
>>   host.name host_name,
>>  host.hypervisor_type,
>>   host.cluster_id cluster_id,
>>   vm_template.id template_id,
>>   vm_template.uuid template_

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

[Kuang-Ching Wang]

Since you turned in DEBUG logging, the “Refusing to design” messages are 
normally expected.  The code steps through all registered network gurus, and 
only those with the right type you requested will design the network.  All 
others will produce the “refusing” statement.

KC

On 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&serviceofferingid=d4206400-e06a-4c58-bdf1-97df6bf06592&iptonetworklist%5B0%5D.networkid=190a586d-833e-4ff8-ba0c-6c5ce7bbfd2e&_=1407340991465
> 2014-08-06 21:42:23,043 DEBUG [o.a.c.a.BaseCmd] 
> (catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Ignoring paremeter displayvm as 
> the caller is not authorized to pass it in
> 2014-08-06 21:42:23,043 DEBUG [o.a.c.a.BaseCmd] 
> (catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Ignoring paremeter 
> deploymentplanner as the caller is not authorized to pass it in
> 2014-08-06 21:42:23,069 DEBUG [o.a.c.a.BaseCmd] 
> (catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Ignoring paremeter displayvm as 
> the caller is not authorized to pass it in
> 2014-08-06 21:42:23,069 DEBUG [o.a.c.a.BaseCmd] 
> (catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Ignoring paremeter 
> deploymentplanner as the caller is not authorized to pass it in
> 2014-08-06 21:42:23,190 DEBUG [c.c.n.NetworkModelImpl] 
> (catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Service SecurityGroup is not 
> supported in the network id=222
> 2014-08-06 21:42:23,207 DEBUG [c.c.v.UserVmManagerImpl] 
> (catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Allocating in the DB for vm
> 2014-08-06 21:42:23,225 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Allocating entries for VM: 
> VM[User|i-41-64-VM]
> 2014-08-06 21:42:23,228 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Allocating nics for 
> VM[User|i-41-64-VM]
> 2014-08-06 21:42:23,229 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Allocating nic for vm 
> VM[User|i-41-64-VM] in network Ntwk[222|Guest|8] with requested profile 
> NicProfile[0-0

Re: [VOTE] git workflow

[Alena Prokharchyk]

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)

Briefly, I think we should do this:

* introduce staging branch. We can call it “develop”. Develop branch gets
merged daily into master only after CI runs/passes on it.
* Master branch reflects the latest changes from *develop, that passed the
quality control.
* release branches cut from the stable master branch only.
* people working on hot fixes/features/critical bugs (where collaboration
is needed), have to cut their own branch from *develop tree. And merge the
fix to *develop only after running automation on their branches (BVT or CI
- to be discussed). Extra daily CI run on *develop branch will ensure that
fixes committed by various people to *develop branch along the day, don’t
break anything.


Thank you,
Alena. 

On 8/6/14, 12:08 PM, "Rohit Yadav"  wrote:

>Hi,
>
>If it was not clear, let me re-state — just because I’m participating in
>this thread does not mean I fully support git-flow, or I am here to
>defend it.
>
>The proposal thread warriors Rajani, Daan, Leo and others can comment and
>advise?
>
>I like couple of good ideas in it, and I think it’s better than what we
>do, especially the baseline protocol. I want to take good stuff from it
>and adapt them to our workflow. As I see now, this won't change our
>process/workflow a lot or that it can stop bad commits or practices from
>happening in our repositories.
>
>I’ve emailed git-flow’s author about raised issues, will keep everyone
>posted.
>
>Cheers.
>
>On 06-Aug-2014, at 8:29 pm, Alena Prokharchyk
> wrote:
>>
>> On 8/6/14, 11:22 AM, "David Nalley"  wrote:
>>
>>> On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav 
>>> wrote:
 Hi,

 On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk
  wrote:

> Rohit, thank you for the explanation. So we cut the maintenance
>release
> from the master branch, not *develop as opposed to the major release
> branch.
>
> One more open question. Its clear that we cut the maintenance release
> from
> the master branch, but what would be the right way to merge it back
>if
> this is a maintenance release for say 4.2, and 4.4 is the top of the
> master branch? Where would the 4.2.1 tag appear? It can¹t be on a top
> of
> 4.4

 You checkout a support branch from 4.2 tag (or for that matter you may
 keep the 4.2 release branch, it¹s same) for LTS/support.
 You tag 4.2.1 on the support branch. (it¹s the same way you would do
 like we do it now). I think git-flow is suitable for rolling releases
 and may not 100% work with our deployment/release process. One thing
 I¹ve suggested is shortening of our release cycles which can help.

>>>
>>> So I suspect that checking out a tag would work. I don't know that
>>> once we create a tag, that we would be able to merge that back into
>>> master. Especially true for maintenance releases. How and where would
>>> we merge 4.5.1 back into master? Moreover, I don't see us getting out
>>> of checking out the tag, and creating a branch to work in. That means
>>> we'd delete a branch, check out a tag, create a branch, create a new
>>> tag, delete a branch - and repeat.
>>>
>>> That said, we don't currently have rolling releases - and now you are
>>> suggesting it may not 100% work. *sigh*
>>
>> Dave, you are right, we can¹t. There is no way to merge back minor
>> releases back to master branch, and preserve the history. The model
>>works
>> only for rolling releases. So making master reflect release branch won¹t
>> make sense in CS case.
>>
>>>
 The flow of commits/fixes/changes would follow the baseline protocol ‹
 from firm branch to soft branches chronologically, so if there is a
bug
 on 4.2 release you fix it on 4.2 support branch and
 cherry-pick/apply/merge that branch/commit(s) to 4.3 release branch
and
 then to 4.4 support branch Š to 4.5 release branch to develop branch.

 I think git-flow assumes the releases will be chronological so you
 don¹t release 4.3.1 after 4.4 etc and you always progress? I¹m not
sure.
 We can think of better ways of doing things, we can also learn from
how
 other projects do it.

 Maintaining major versions/releases such as 4.2, 4.3, 4.4 will be
 painful, that always felt to me like maintaining a whole different
 product. If we can do something about that, we¹re going to make a lot
of
 people happy IMO.

>
>>>
>>> So we've set the expectation that we'll follow SemVer - and adhering
>>> to that is a good thing. Rolling releases are interesting, but we are
>>> a long way from being able to do anything remotely close IMO.
>
>R

Re: [VOTE] git workflow

[Erik Weber]

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

> Rohit, thank you for the explanation. So we cut the maintenance release
> from the master branch, not *develop as opposed to the major release
> branch.
>
>
Here's what happens if you want to create a support (ie maintenance
release) branch, in this example I'll use 4.3.1 as example maintenance
version number.

> git checkout 4.3.0 ( this should be the release tag)
> git checkout -b support/4.3.x
> git checkout -b hotfix/4.3.1

... make your fix, then:

> git checkout support/4.3.x
> git merge hotfix/4.3.1
> git branch -d hotfix/4.3.1
> git tag 4.3.1


If you install the gitflow tools you don't do all this yourself, instead
you would do this:

> git flow support start 4.3.x 4.3.0
> git flow hotfix start 4.3.1 support/4.3.x

... make changes then:

> git flow hotfix finish 4.3.1

As you can see the support/4.3.x branch persists, and a subsequent release
4.3.2 would be branched off that.


One more open question. Its clear that we cut the maintenance release from
> the master branch, but what would be the right way to merge it back if
> this is a maintenance release for say 4.2, and 4.4 is the top of the
> master branch? Where would the 4.2.1 tag appear? It can’t be on a top of
> 4.4
>
>
You don't merge it back to master unless the maintenance would be the
latest release. (i'm not even sure if you do it then)



>
> All the above should be documented in the proposal. The original proposal
> didn’t mention anything about how we are going to do maintenance branches.
> And we were originally thinking about leaving the release branches around.
>
>
Gitflow has a concept for this, it's called support branch/releases.

-- 
Erik

Re: [VOTE] git workflow

[Tracy Phillips]

"Once you merge release branch it on master/stable branch, you don’t lose
commit if you delete it. It’s like removing a feature branch once it’s
merged on master/target branch."

Correct. At t his point your "release" is in master. If you need to bug
fix, you checkout that tag from master.

Also, as far as CI is concerned it should be ran on the feature branch and
once the feature doesn't break anything, it should only then be merged into
develop.

http://twasink.net/2011/09/20/git-feature-branches-and-jenkins-or-how-i-learned-to-stop-worrying-about-broken-builds/

http://juristr.com/blog/2014/01/git-flow-jenkins-gitlab/

The idea is that you are not pushing a broken feature into a branch.




On Wed, Aug 6, 2014 at 10:55 AM, Rohit Yadav 
wrote:

> Hi David,
>
> On 06-Aug-2014, at 4:10 pm, David Nalley  wrote:
>
> > On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav 
> wrote:
> >>
> >> Hi,
> >>
> >> Comments in-line;
> >>
> >> On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
> >>
> >>> Rayees,
> >>>
> >>> I think you have the same misunderstanding as a lot of other folks
> >>> (including myself) had in the beginning - seeing develop branch as a
> trunk
> >>> branch that gets merged into master on a regular basis after the BVT/CI
> >>> tests pass. So the master branch reflects the develop branch minus
> changes
> >>> that didn¹t pass the tests and weren¹t merged into master -  lets
> refer to
> >>> it as implementation #1
> >>>
> >>> That¹s not what git workflow/this thread proposes. In git workflow
> master
> >>> branch reflects the latest stable release instead. So for example, we
> >>> released 4.4, and that what you would see the master to be as we merge
> the
> >>> *release branch to master, not the *develop to master. And develop
> branch
> >>> becomes the trunk branch where all the new fixes go to. I would look at
> >>> the master as at the stable branch, where you can track the history for
> >>> all the major releases as for each of them the master branch has
> >>> corresponding tags - lets call it implementation #2
> >>>
> >>> I still don¹t see many advantages in implementation #2 - making the
> master
> >>> build stable by simply making it reflect the latest release branch.
> >>> Because you:
> >>>
> >>> * never cut the release from master branch
> >>
> >> We’ve a stable branch that gets rolling/continuous releases which is
> good.
> >>
> >>> * if you are the customer, and need the latest stable code, you
> download
> >>> the official RPM
> >>> * if you are a developer, you always want to download the latest code,
> and
> >>> that comes from *develop branch
> >>> * if you want to look at the latest stable release, you look at the
> >>> release branch as per CS git workflow implementation we never remove
> the
> >>> release branches (they are needed for maintenance releases)
> >>
> >> IMO We “should" remove the release branches when done. Instead there is
> a support workflow with git-flow (see support
> http://yakiloo.com/getting-started-git-flow/) and also in the tooling
> (git flow support etc. though experimental).
> >>
> >
> > You aren't aiding your case by suggesting that we use experimental
> tooling.
>
> No, if you know you git-chops you can do it by hand, I mean to say -- the
> tool is under development for support stuff.
>
> > So removing a release branch worries me. Will there be loss of commit
> > information?
>
> Once you merge release branch it on master/stable branch, you don’t lose
> commit if you delete it. It’s like removing a feature branch once it’s
> merged on master/target branch.
>
> > I know that heretofore, each release has contained
> > commits that aren't in master. Whether that's good, bad or
> > indifferent, that is the fact, and I personally think that is unlikely
> > to change in the short term.
>
> Once merged on master/stable branch, one can checkout the release version
> tag to get the same branch.
>
> > Or put more succinctly, what does removing a release branch buy us?
>
> Less cluttered branches. You’ve the release branch merged on master and
> tags why do you want to keep branches? You can always checkout the tags to
> get the release branch.
>
> > So I like most of the things about this proposal - I like doing all
> > the work in the feature/bug branches. But the rest of this workflow
> > befuddles me a bit. I don't think that the workflow will result in a
> > stable 'master' or that we are really doing anything significant by
> > pushing what is master now to become the develop branch.
>
> You’re right. It’s just a convention of doing things, like we’ve traffic
> rules.
> They won’t stop you to break anything if you don’t follow.
>
> > In the page
> > describing this, pushes to the develop branch seem welcome 'when a
> > feature is completed' - so develop will be as messy as master is
> > today, frequently broken, and no improvement in quality. This attempts
> > to solve a quality problem with workflow, and I don't think it can

Re: [VOTE] git workflow

[Erik Weber]

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 other than merging
instead of cherry picking.
That is the main issue from a release perspective.

But I still think there are good reasons to do so;

1) using a well known way of handling code/releases instantly tells new
contributors / committers how we work. add to the fact that there exists
tools to help doing this correctly is a bonus.
2) having a known stable (atleast in theory) release as master is good
practice. although not many users will be running from git, i still
consider it to be good practice.
3) there is a huge belief in this thread/discussion that as long as
something passes CI / BVT it is considered stable. The fact is that it is
not. Take the recent 4.4 release as a good example, where a new install was
not working at all at the point of release. Now, this is more a CI / test
coverage issue than git workflow issue, but i find it weird to use as an
argument for not improving the workflow.

-- 
Erik

Re: [VOTE] git workflow

[Alena Prokharchyk]

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 other than merging
>instead of cherry picking.
>That is the main issue from a release perspective.
>
>But I still think there are good reasons to do so;
>
>1) using a well known way of handling code/releases instantly tells new
>contributors / committers how we work. add to the fact that there exists
>tools to help doing this correctly is a bonus.
>2) having a known stable (atleast in theory) release as master is good
>practice. although not many users will be running from git, i still
>consider it to be good practice.
>3) there is a huge belief in this thread/discussion that as long as
>something passes CI / BVT it is considered stable. The fact is that it is
>not. Take the recent 4.4 release as a good example, where a new install
>was
>not working at all at the point of release. Now, this is more a CI / test
>coverage issue than git workflow issue, but i find it weird to use as an
>argument for not improving the workflow.
>
>-- 
>Erik

I¹m not arguing against keeping master release stable; I advocate for it.
But we can¹t adopt git workflow way of keeping master branch to be a
reflection of the latest release branch. It will not work with our way of
handling maintenance releases for multiple versions of CS - see another
thread.

Instead, master branch should reflect the latest code that passed the CI
test (the code merged from *develop after CI passes). The release branches
should be cut from stable master branch - it will ensure that we won¹t
face last minute blockers as for 4.4, because master IS a stable branch.
And yes, we should do merges instead of cherry picking.



>

Re: Review Request 24420: vGPU Test Automation ( Check for Drivers)

[abhinav roy]

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

(Updated Aug. 6, 2014, 8:37 p.m.)


Review request for cloudstack, Doug Clark and Sanjay Tripathi.


Repository: cloudstack-git


Description
---

This Patch has a function which is used to check for the presence of vGPU 
drivers in the deployed Windows VM instances


Diffs
-

  test/integration/component/test_deploy_vgpu_vm.py fd3f374 

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


Testing
---

Testing :

1. Executed the script on non GPU test setup and ensured tests being skipped. 
2. Executed on K2 GPU drivers installed setup and ensured deploy VM cases 
working fine and the function is checking for the vGPU drivers on that deployed 
VM or stopped VM or a VM in any state for that matter.


Thanks,

abhinav roy

Re: Review Request 24420: vGPU Test Automation ( Check for Drivers)

[abhinav roy]

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

(Updated Aug. 6, 2014, 8:41 p.m.)


Review request for cloudstack, Doug Clark and Sanjay Tripathi.


Repository: cloudstack-git


Description
---

This Patch has a function which is used to check for the presence of vGPU 
drivers in the deployed Windows VM instances


Diffs
-

  test/integration/component/test_deploy_vgpu_vm.py fd3f374 

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


Testing
---

Testing :

1. Executed the script on non GPU test setup and ensured tests being skipped. 
2. Executed on K2 GPU drivers installed setup and ensured deploy VM cases 
working fine and the function is checking for the vGPU drivers on that deployed 
VM or stopped VM or a VM in any state for that matter.


Thanks,

abhinav roy

Review Request 24425: vGPU Automation : VM Lifecycle Tests

[abhinav roy]

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

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


Repository: cloudstack-git


Description
---

This is a test script for vGPU VM lifecycle which includes :

1. Deploy VM
2. Stop VM
3. Start VM
4. Restore VM
5. Reboot VM
6. Destroy VM
7. Recover VM


Diffs
-

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

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


Testing
---

Testing :

Executed the tests on a vGPU setup with Hosts having K2 drivers and ensured 
that all the lifecycle testcases were working fine.


Thanks,

abhinav roy

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

[Erik Weber]

This seems to be your issue

[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

It cannot find a gpu and expects there to be one.

Erik
6. aug. 2014 20:36 skrev "Abhinav Roy"  følgende:

> 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&serviceofferingid=d4206400-e06a-4c58-bdf1-97df6bf06592&iptonetworklist%5B0%5D.networkid=190a586d-833e-4ff8-ba0c-6c5ce7bbfd2e&_=1407340991465
> 2014-08-06 21:42:23,043 DEBUG [o.a.c.a.BaseCmd]
> (catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Ignoring paremeter displayvm
> as the caller is not authorized to pass it in
> 2014-08-06 21:42:23,043 DEBUG [o.a.c.a.BaseCmd]
> (catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Ignoring paremeter
> deploymentplanner as the caller is not authorized to pass it in
> 2014-08-06 21:42:23,069 DEBUG [o.a.c.a.BaseCmd]
> (catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Ignoring paremeter displayvm
> as the caller is not authorized to pass it in
> 2014-08-06 21:42:23,069 DEBUG [o.a.c.a.BaseCmd]
> (catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Ignoring paremeter
> deploymentplanner as the caller is not authorized to pass it in
> 2014-08-06 21:42:23,190 DEBUG [c.c.n.NetworkModelImpl]
> (catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Service SecurityGroup is not
> supported in the network id=222
> 2014-08-06 21:42:23,207 DEBUG [c.c.v.UserVmManagerImpl]
> (catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Allocating in the DB for vm
> 2014-08-06 21:42:23,225 DEBUG [c.c.v.VirtualMachineManagerImpl]
> (catalina-exec-25:ctx-e2a0589a ctx-7a1d3c27) Allocating entries for VM:
> VM[User|i-41-64-VM]
> 2014-08-06 21:42:23,228 DEBUG [c.c.v.Vir

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

[Rohit Yadav]

Here you go, modify and install in your git repositories:
https://github.com/apache/cloudstack/blob/master/tools/git/db-police

It will audaciously alert you, on OSX using ‘say’ and on GNU/Linux using 
‘festival’ (if installed).
I was not sure about Windows, so if anyone can cover that case?

Cheers.


On 06-Aug-2014, at 9:14 pm, Rohit Yadav  wrote:

> If you care, why not self-police use git hooks:
> http://markmail.org/message/h5yb27jy6qrrw4dh
>
> Cheers.
>
> On 06-Aug-2014, at 8:51 pm, 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,
>>> 

Re: [VOTE] git workflow

[Daan Hoogland]

Alena,

I think this is a matter of semantics. If you call the latest version
that got through the CI a pre-release and add them as releases in the
git-flow way of working on master you've got what you envision.

In spite of my mail this morning I am not a warrior (though I like the
compliment, Rohit) of gitflow but I feel that it fits whatever we need
so far. I have read no contradiction to that so far. The only real
change to our present way of working , given that we will use support
branches, is that we don't build releases on the basis of cherry-picks
anymore, which is not a very big change. Other then that, naming is
all that is left.

Maybe I lost view on the obstacles and objections and am being short
sighted here, please advice,
Daan

On Wed, Aug 6, 2014 at 9:59 PM, Alena Prokharchyk
 wrote:
>
>
> 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 other than merging
>>instead of cherry picking.
>>That is the main issue from a release perspective.
>>
>>But I still think there are good reasons to do so;
>>
>>1) using a well known way of handling code/releases instantly tells new
>>contributors / committers how we work. add to the fact that there exists
>>tools to help doing this correctly is a bonus.
>>2) having a known stable (atleast in theory) release as master is good
>>practice. although not many users will be running from git, i still
>>consider it to be good practice.
>>3) there is a huge belief in this thread/discussion that as long as
>>something passes CI / BVT it is considered stable. The fact is that it is
>>not. Take the recent 4.4 release as a good example, where a new install
>>was
>>not working at all at the point of release. Now, this is more a CI / test
>>coverage issue than git workflow issue, but i find it weird to use as an
>>argument for not improving the workflow.
>>
>>--
>>Erik
>
> I¹m not arguing against keeping master release stable; I advocate for it.
> But we can¹t adopt git workflow way of keeping master branch to be a
> reflection of the latest release branch. It will not work with our way of
> handling maintenance releases for multiple versions of CS - see another
> thread.
>
> Instead, master branch should reflect the latest code that passed the CI
> test (the code merged from *develop after CI passes). The release branches
> should be cut from stable master branch - it will ensure that we won¹t
> face last minute blockers as for 4.4, because master IS a stable branch.
> And yes, we should do merges instead of cherry picking.
>
>
>
>>
>



-- 
Daan

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

[Daan Hoogland]

H,

I got a review that I should remove the update to 4.3 system templates
from the 4.4 upgrade path when I added the 4.4 upgrade. Shouldn't I
have done that? It seems in contradiction with what you said in this
thread.

Maybe it is a special case as the upgrade will fail if you don't have
them, but you do not want them in the end. I think not trying to
upgrade to an intermediate set of templates (hence changing the
upgrade code) is not bad in this case.

Agree?

Daan

On Wed, Aug 6, 2014 at 10:51 PM, Rohit Yadav  wrote:
> Here you go, modify and install in your git repositories:
> https://github.com/apache/cloudstack/blob/master/tools/git/db-police
>
> It will audaciously alert you, on OSX using ‘say’ and on GNU/Linux using 
> ‘festival’ (if installed).
> I was not sure about Windows, so if anyone can cover that case?
>
> Cheers.
>
>
> On 06-Aug-2014, at 9:14 pm, Rohit Yadav  wrote:
>
>> If you care, why not self-police use git hooks:
>> http://markmail.org/message/h5yb27jy6qrrw4dh
>>
>> Cheers.
>>
>> On 06-Aug-2014, at 8:51 pm, 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,
  doma

RE: [VOTE] git workflow

[Edison Su]

> -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 other than
> >merging instead of cherry picking.
> >That is the main issue from a release perspective.
> >
> >But I still think there are good reasons to do so;
> >
> >1) using a well known way of handling code/releases instantly tells new
> >contributors / committers how we work. add to the fact that there
> >exists tools to help doing this correctly is a bonus.
> >2) having a known stable (atleast in theory) release as master is good
> >practice. although not many users will be running from git, i still
> >consider it to be good practice.
> >3) there is a huge belief in this thread/discussion that as long as
> >something passes CI / BVT it is considered stable. The fact is that it
> >is not. Take the recent 4.4 release as a good example, where a new
> >install was not working at all at the point of release. Now, this is
> >more a CI / test coverage issue than git workflow issue, but i find it
> >weird to use as an argument for not improving the workflow.
> >
> >--
> >Erik
> 
> I¹m not arguing against keeping master release stable; I advocate for it.

+1, we need to take action to make sure master is stable. Frankly speaking, 
I don't want to fix the regression on the master, I assume nobody want to do 
that.
Here is the list of regression issues(not introduced by myself) I fixed on 
master after 4.4:

CLOUDSTACK-7123
CLOUDSTACK-7110
CLOUDSTACK-7166
CLOUDSTACK-7164
Most of this issues will be caught even by a simulator BVT. I want to make it 
clear, that,
If we don't take action to reduce/eliminate the regression as much as possible 
in the future, I will not fix any of this regression issues.
I remember there is discussion about setting up a staging branch, run BVT 
against it for each commit, what's the conclusion if any? Why so difficult to 
make it happen? Is there anything I can help to make it happen?

> But we can¹t adopt git workflow way of keeping master branch to be a
> reflection of the latest release branch. It will not work with our way of
> handling maintenance releases for multiple versions of CS - see another
> thread.


+1, I'll -1 on any of proposal, if it doesn't solve problem most of us are 
concerning about.

> 
> Instead, master branch should reflect the latest code that passed the CI test
> (the code merged from *develop after CI passes). The release branches
> should be cut from stable master branch - it will ensure that we won¹t face
> last minute blockers as for 4.4, because master IS a stable branch.
> And yes, we should do merges instead of cherry picking.
> 
> 
> 
> >

Re: [VOTE] git workflow

[Alena Prokharchyk]

Daan, thank you for the summary. See my answers below.



On 8/6/14, 1:59 PM, "Daan Hoogland"  wrote:

>Alena,
>
>I think this is a matter of semantics. If you call the latest version
>that got through the CI a pre-release and add them as releases in the
>git-flow way of working on master you've got what you envision.

Yes.

>
>In spite of my mail this morning I am not a warrior (though I like the
>compliment, Rohit) of gitflow but I feel that it fits whatever we need
>so far. 

My main point of objection was the way they maintain the master branch -
to reflect the latest release, which doesn’t suit the CS maintenance
releases model. Plus we can’t remove the release branches like the
original model does.



>I have read no contradiction to that so far. The only real
>change to our present way of working , given that we will use support
>branches, is that we don't build releases on the basis of cherry-picks
>anymore, which is not a very big change. Other then that, naming is
>all that is left.

Yes, merges instead of cherry-picks and introducing a staging (*develop,
or *pre-release) branch - that was all missing in the CS before, and we
have to implement it.

>
>Maybe I lost view on the obstacles and objections and am being short
>sighted here, please advice,
>Daan
>
>On Wed, Aug 6, 2014 at 9:59 PM, Alena Prokharchyk
> wrote:
>>
>>
>> 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 other than
>>>merging
>>>instead of cherry picking.
>>>That is the main issue from a release perspective.
>>>
>>>But I still think there are good reasons to do so;
>>>
>>>1) using a well known way of handling code/releases instantly tells new
>>>contributors / committers how we work. add to the fact that there exists
>>>tools to help doing this correctly is a bonus.
>>>2) having a known stable (atleast in theory) release as master is good
>>>practice. although not many users will be running from git, i still
>>>consider it to be good practice.
>>>3) there is a huge belief in this thread/discussion that as long as
>>>something passes CI / BVT it is considered stable. The fact is that it
>>>is
>>>not. Take the recent 4.4 release as a good example, where a new install
>>>was
>>>not working at all at the point of release. Now, this is more a CI /
>>>test
>>>coverage issue than git workflow issue, but i find it weird to use as an
>>>argument for not improving the workflow.
>>>
>>>--
>>>Erik
>>
>> I¹m not arguing against keeping master release stable; I advocate for
>>it.
>> But we can¹t adopt git workflow way of keeping master branch to be a
>> reflection of the latest release branch. It will not work with our way
>>of
>> handling maintenance releases for multiple versions of CS - see another
>> thread.
>>
>> Instead, master branch should reflect the latest code that passed the CI
>> test (the code merged from *develop after CI passes). The release
>>branches
>> should be cut from stable master branch - it will ensure that we won¹t
>> face last minute blockers as for 4.4, because master IS a stable branch.
>> And yes, we should do merges instead of cherry picking.
>>
>>
>>
>>>
>>
>
>
>
>-- 
>Daan

Re: [VOTE] git workflow

[Alena Prokharchyk]

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 other than
>> >merging instead of cherry picking.
>> >That is the main issue from a release perspective.
>> >
>> >But I still think there are good reasons to do so;
>> >
>> >1) using a well known way of handling code/releases instantly tells new
>> >contributors / committers how we work. add to the fact that there
>> >exists tools to help doing this correctly is a bonus.
>> >2) having a known stable (atleast in theory) release as master is good
>> >practice. although not many users will be running from git, i still
>> >consider it to be good practice.
>> >3) there is a huge belief in this thread/discussion that as long as
>> >something passes CI / BVT it is considered stable. The fact is that it
>> >is not. Take the recent 4.4 release as a good example, where a new
>> >install was not working at all at the point of release. Now, this is
>> >more a CI / test coverage issue than git workflow issue, but i find it
>> >weird to use as an argument for not improving the workflow.
>> >
>> >--
>> >Erik
>> 
>> I¹m not arguing against keeping master release stable; I advocate for
>>it.
>
>+1, we need to take action to make sure master is stable. Frankly
>speaking, 
>I don't want to fix the regression on the master, I assume nobody want to
>do that.
>Here is the list of regression issues(not introduced by myself) I fixed
>on master after 4.4:
>
>CLOUDSTACK-7123
>CLOUDSTACK-7110
>CLOUDSTACK-7166
>CLOUDSTACK-7164
>Most of this issues will be caught even by a simulator BVT. I want to
>make it clear, that,
>If we don't take action to reduce/eliminate the regression as much as
>possible in the future, I will not fix any of this regression issues.
>I remember there is discussion about setting up a staging branch, run BVT
>against it for each commit, what's the conclusion if any? Why so
>difficult to make it happen? Is there anything I can help to make it
>happen?
>
>> But we can¹t adopt git workflow way of keeping master branch to be a
>> reflection of the latest release branch. It will not work with our way
>>of
>> handling maintenance releases for multiple versions of CS - see another
>> thread.
>
>
>+1, I'll -1 on any of proposal, if it doesn't solve problem most of us
>are concerning about.
>
>> 
>> Instead, master branch should reflect the latest code that passed the
>>CI test
>> (the code merged from *develop after CI passes). The release branches
>> should be cut from stable master branch - it will ensure that we won¹t
>>face
>> last minute blockers as for 4.4, because master IS a stable branch.
>> And yes, we should do merges instead of cherry picking.
>> 
>> 
>> 
>> >
>

Jenkins build is unstable: simulator-singlerun #68

[jenkins]

See 

RE: [VOTE] git workflow

[Prachi Damle]

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


I agree to this. 

1) If we are introducing the 'develop' branch, it intuitively seems that it 
should act as a staging branch where we have some quality control before things 
move to master.
2) Plus as discussed in the thread, the git workflow is not solving the CS 
maintenance release process. So we need to have some tweaks there to support 
the non-rolling release model of CS.

The reservation is not due to mere a 'naming' change -it's because apart from 
the naming change, we are still facing issues. The proposal needs to address 
the above, if we are planning to introduce a change, why not solve our 
quality/test problems with it.

Thanks,
Prachi

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 other than 
>> >merging instead of cherry picking.
>> >That is the main issue from a release perspective.
>> >
>> >But I still think there are good reasons to do so;
>> >
>> >1) using a well known way of handling code/releases instantly tells 
>> >new contributors / committers how we work. add to the fact that 
>> >there exists tools to help doing this correctly is a bonus.
>> >2) having a known stable (atleast in theory) release as master is 
>> >good practice. although not many users will be running from git, i 
>> >still consider it to be good practice.
>> >3) there is a huge belief in this thread/discussion that as long as 
>> >something passes CI / BVT it is considered stable. The fact is that 
>> >it is not. Take the recent 4.4 release as a good example, where a 
>> >new install was not working at all at the point of release. Now, 
>> >this is more a CI / test coverage issue than git workflow issue, but 
>> >i find it weird to use as an argument for not improving the workflow.
>> >
>> >--
>> >Erik
>> 
>> I¹m not arguing against keeping master release stable; I advocate for 
>>it.
>
>+1, we need to take action to make sure master is stable. Frankly
>speaking,
>I don't want to fix the regression on the master, I assume nobody want 
>to do that.
>Here is the list of regression issues(not introduced by myself) I fixed 
>on master after 4.4:
>
>CLOUDSTACK-7123
>CLOUDSTACK-7110
>CLOUDSTACK-7166
>CLOUDSTACK-7164
>Most of this issues will be caught even by a simulator BVT. I want to 
>make it clear, that, If we don't take action to reduce/eliminate the 
>regression as much as possible in the future, I will not fix any of 
>this regression issues.
>I remember there is discussion about setting up a staging branch, run 
>BVT against it for each commit, what's the conclusion if any? Why so 
>difficult to make it happen? Is there anything I can help to make it 
>happen?
>
>> But we can¹t adopt git workflow way of keeping master branch to be a  
>>reflection of the latest release branch. It will not work with our way 
>>of  handling maintenance releases for multiple versions of CS - see 
>>another  thread.
>
>
>+1, I'll -1 on any of proposal, if it doesn't solve problem most of us
>are concerning about.
>
>> 
>> Instead, master branch should reflect the latest code that passed the 
>>CI test  (the code merged from *develop after CI passes). The release 
>>branches  should be cut from stable master branch - it will ensure 
>>that we won¹t face  last minute blockers as for 4.4, because master IS 
>>a stable branch.
>> And yes, we should do merges instead of cherry picking.
>> 
>> 
>> 
>> >
>

Re: [VOTE] git workflow

[Sebastien Goasguen]

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

-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 other than
 merging instead of cherry picking.
 That is the main issue from a release perspective.
 
 But I still think there are good reasons to do so;
 
 1) using a well known way of handling code/releases instantly tells new
 contributors / committers how we work. add to the fact that there
 exists tools to help doing this correctly is a bonus.
 2) having a known stable (atleast in theory) release as master is good
 practice. although not many users will be running from git, i still
 consider it to be good practice.
 3) there is a huge belief in this thread/discussion that as long as
 something passes CI / BVT it is considered stable. The fact is that it
 is not. Take the recent 4.4 release as a good example, where a new
 install was not working at all at the point of release. Now, this is
 more a CI / test coverage issue than git workflow issue, but i find it
 weird to use as an argument for not improving the workflow.
 
 --
 Erik
>>> 
>>> I¹m not arguing against keeping master release stable; I advocate for
>>> it.
>> 
>> +1, we need to take action to make sure master is stable. Frankly
>> speaking, 
>> I don't want to fix the regression on the master, I assume nobody want to
>> do that.
>> Here is the list of regression issues(not introduced by myself) I fixed
>> on master after 4.4:
>> 
>> CLOUDSTACK-712

Re: [VOTE] git workflow

[Sebastien Goasguen]

On Aug 6, 2014, at 6:13 PM, Prachi Damle  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.
> 
> 
> I agree to this. 
> 
> 1) If we are introducing the 'develop' branch, it intuitively seems that it 
> should act as a staging branch where we have some quality control before 
> things move to master.
> 2) Plus as discussed in the thread, the git workflow is not solving the CS 
> maintenance release process. So we need to have some tweaks there to support 
> the non-rolling release model of CS.
> 
> The reservation is not due to mere a 'naming' change -it's because apart from 
> the naming change, we are still facing issues.

Can you list them specifically, one by one ?


> The proposal needs to address the above, if we are planning to introduce a 
> change, why not solve our quality/test problems with it.
> 

Let's assume we have a CI/BVT infra available in apache and that every 
branch/commit can go through it. 
What would be your ideal git workflow to have:

-stable master (meaning that you checkout master and you have the latest 
shippable product)
-always release on-time.
-always know where a fix should be applied (and if it has been applied 
everywhere)

(those are my top three, we may want to add others)



> Thanks,
> Prachi
> 
> 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 other than 
 merging instead of cherry picking.
 That is the main issue from a release perspective.
 
 But I still think there are good reasons to do so;
 
 1) using a well known way of handling code/releases instantly tells 
 new contributors / committers how we work. add to the fact that 
 there exists tools to help doing this correctly is a bonus.
 2) having a known stable (atleast in theory) release as master is 
 good practice. although not many users will be running from git, i 
 still consider it to be good practice.
 3) there is a huge belief in this thread/discussion that as long as 
 something passes CI / BVT it is considered stable. The fact is that 
 it is not. Take the recent 4.4 release as a good example, where a 
 new install was not working at all at the point of release. Now, 
 this is more a CI / test coverage issue than git workflow issue, but 
 i find it weird to use as an argument for not improving the workflow.
 
 --
 Erik
>>> 
>>> I¹m not arguing against keeping master release stable; I advocate for 
>>> it.
>> 
>> +1, we need to take action to make sure master is stable. Frankly
>> speaking,
>> I don't want to fix the regression on the master, I assume nobody want 
>> to do that.
>> Here is the list of regression issues(not introduced by myself) I fixed 
>> on master after 4.4:
>> 
>> CLOUDSTACK-7123
>> CLOUDSTACK-7110
>> CLOUDSTACK-7166
>> CLOUDSTACK-7164
>> Most of this issues will be caught even by a simulator BVT. I want to 
>> make it clear, that, If we don't take action to reduce/eliminate the 
>> regression as much as possible in the future, I will not fix any of 
>> this regression issues.
>> I remember there is discussion about setting up a staging branch, run 
>> BVT against it for each commit, what's the conclusion if any? Why so 
>> difficult to make it happen? Is there anything I can help to make it 
>> happen?
>> 
>>> But we can¹t adopt git workflow way of keeping master branch to be a  
>>> reflection of the latest release branch. It will not work with our way 
>>> of  handling maintenance releases for multiple versions of CS - see 
>>> another  thread.
>> 
>> 
>> +1, I'll -1 on any of proposal, if it doesn't solve problem most of us
>> are concerning about.
>> 
>>> 
>>> Instead, master branch shoul

Re: [VOTE] git workflow

[Alena Prokharchyk]

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 other than
> merging instead of cherry picking.
> That is the main issue from a release perspective.
> 
> But I still think there are good reasons to do so;
> 
> 1) using a well known way of handling code/releases instantly tells
>new
> contributors / committers how we work. add to the fact that there
> exists tools to help doing this correctly is a bonus.
> 2) having a known stable (atleast in theory) release as master is
>good
> practice. although not many users will be running from git, i still
> consider it to be good practice.

RE: [VOTE] git workflow

[Prachi Damle]

-Original Message-
From: Sebastien Goasguen [mailto:run...@gmail.com] 
Sent: Wednesday, August 06, 2014 3:23 PM
To: dev@cloudstack.apache.org
Cc: Edison Su
Subject: Re: [VOTE] git workflow


On Aug 6, 2014, at 6:13 PM, Prachi Damle  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.
> 
> 
> I agree to this. 
> 
> 1) If we are introducing the 'develop' branch, it intuitively seems that it 
> should act as a staging branch where we have some quality control before 
> things move to master.
> 2) Plus as discussed in the thread, the git workflow is not solving the CS 
> maintenance release process. So we need to have some tweaks there to support 
> the non-rolling release model of CS.
> 
> The reservation is not due to mere a 'naming' change -it's because apart from 
> the naming change, we are still facing issues.

Can you list them specifically, one by one ?

That's what is listed above #1 and #2 - We are introducing 'develop' without 
any quality benefit and we will possibly break the maintenance release CS model.

> The proposal needs to address the above, if we are planning to introduce a 
> change, why not solve our quality/test problems with it.
> 

Let's assume we have a CI/BVT infra available in apache and that every 
branch/commit can go through it. 
What would be your ideal git workflow to have:

-stable master (meaning that you checkout master and you have the latest 
shippable product) -always release on-time.
-always know where a fix should be applied (and if it has been applied 
everywhere)

(those are my top three, we may want to add others)



> Thanks,
> Prachi
> 
> 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 other than 
 merging instead of cherry picking.
 That is the main issue from a release perspective.
 
 But I still think there are good reasons to do so;
 
 1) using a well known way of handling code/releases instantly tells 
 new contributors / committers how we work. add to the fact that 
 there exists tools to help doing this correctly is a bonus.
 2) having a known stable (atleast in theory) release as master is 
 good practice. although not many users will be running from git, i 
 still consider it to be good practice.
 3) there is a huge belief in this thread/discussion that as long as 
 something passes CI / BVT it is considered stable. The fact is that 
 it is not. Take the recent 4.4 release as a good example, where a 
 new install was not working at all at the point of release. Now, 
 this is more a CI / test coverage issue than git workflow issue, 
 but i find it weird to use as an argument for not improving the workflow.
 
 --
 Erik
>>> 
>>> I¹m not arguing against keeping master release stable; I advocate 
>>> for it.
>> 
>> +1, we need to take action to make sure master is stable. Frankly
>> speaking,
>> I don't want to fix the regression on the master, I assume nobody 
>> want to do that.
>> Here is the list of regression issues(not introduced by myself) I 
>> fixed on master after 4.4:
>> 
>> CLOUDSTACK-7123
>> CLOUDSTACK-7110
>> CLOUDSTACK-7166
>> CLOUDSTACK-7164
>> Most of this issues will be caught even by a simulator BVT. I want to 
>> make it clear, that, If we don't take action to reduce/eliminate the 
>> regression as much as possible in the future, I will not fix any of 
>> this regression issues.
>> I remember there is discussion about setting up a staging branch, run 
>> BVT against it for each commit, what's the conclusion if any? Why so 
>> difficult to make it happen? Is there anything I can help to make it 
>> happen?
>> 
>>> But we can¹t adopt git workflo

Jenkins build is still unstable: simulator-singlerun #69

[jenkins]

See 

RE: [VOTE] git workflow

[Animesh Chaturvedi]

> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: Wednesday, August 06, 2014 3:19 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] git workflow
> 
> [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).
> 
> -Release: from the time a release branch is cut, features are only merged by
> RM. 
[Animesh] Features have to be merged into develop branch before the feature 
freeze date in order to make into release branch. This is not done by RM but 
the feature developer.  Release branch should already have features that made 
it by the feature freeze date


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)
[Animesh] I want to be clear on timing for this otherwise RM cannot scale and 
will drown in these requests. 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. 
> 
> 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 other than
>  merging instead of cherry picking.
>  That is the main issue from a release perspective.
> 
>  But I still think there are good reasons to do so;
> 
>  1) using a well known way of handling code/releases instantly tells
>  new contributors / committers how we work. add to the fact that
>  there exists tools to help doing this correctly is a bonus.
>  2) having a known stable (atleast in theory) release as master is
>  good practice. although not many users will be running from git, i

Re: [VOTE] git workflow

[David Nalley]

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