Re: implementing git workflow
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 rajani.karut...@citrix.com 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 da...@gnsa.usmailto:da...@gnsa.us wrote: On Tue, Aug 5, 2014 at 2:51 PM, Alena Prokharchyk alena.prokharc...@citrix.commailto: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?pageId=30738915selectedPageVersions=32selectedPageVersions=22 Agreement to do something and the following implementation are not necessarily instantaneous. -- Daan
Re: implementing git workflow
I added a pre push hook to the [wiki page] which rejects any commits which doesn’t start with ‘Merge branch’ on master [wiki page] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-githooks ~Rajani On 05-Aug-2014, at 6:48 pm, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: That sound good to me On Tue, Aug 5, 2014 at 2:15 PM, Rajani Karuturi rajani.karut...@citrix.commailto:rajani.karut...@citrix.com wrote: On 05-Aug-2014, at 4:47 pm, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: On Tue, Aug 5, 2014 at 12:45 PM, Rohit Yadav rohit.ya...@shapeblue.commailto:rohit.ya...@shapeblue.com wrote: 1. Can we enable a git hook to prevent the commits to master post the switch? It’s possible theoretically but to do that in less than 48 hours could be a challenge, you can open a ticket on JIRA/ASF-infra or contact the fine folks on ASF infra such as humbledooh (irc etc.). Let's not do this. Next problem will be who and when can commit on master. Committers have responsibility to do this and to do it at the right time. agreed. Will try to update the wiki with some pre-commit hook which committers can use locally. -- Daan ~Rajani -- Daan
Re: [VOTE] git workflow
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 daan.hoogl...@gmail.com 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 prerelease dates at which we merge as well. We don't have to do it at that date but can decide to do that the next day or week as well. This would kind of resemble Alena's #1 (as opposed to the more pure gitflow #2). An argument for #2 is that I don't think every customer greps the rpms for some release. I know our operators at Schuberg Philis investigate the code and check it out from git. They like to compare release and look at the latest easily. just checking out master would be very convenient for them. Of course they can check out a branch as well. But I doubt if they know exactly what to checkout then. I usually see them just look at the latest for a branch. All in all, I am very skeptic on whether this will work as planned. It is us who need to work neatly and only if we do that we can help ourselves with improving our process. I do feel that the present way of working, mainly the use forward branches but in general the lack of using branches to test individual changes, is hindering us in doing releases. The proposal at hand is very good but can only work if supported by the people that need to work with it. It doesn't do our release process for us. We still need to do it and not just program some code and check it in. That will never work in any process. Your code is not done until somebody somewhere finds it worth running it in a production environment. So let's keep discussing and educating each other. done ranting, feel free to react or contact me in person Daan On Wed, Aug 6, 2014 at 3:15 AM, David Nalley da...@gnsa.us wrote: On Tue, Aug 5, 2014 at 7:44 PM, Erik Weber terbol...@gmail.com wrote: On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle prachi.da...@citrix.com wrote: I fail to understand how will this model help us with the maintenance releases? That's what gitflow support branches is for. I find this quite descriptive: https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH06CuKT0J For CloudStack we also keep working on prior releases and ship out maintenance releases. I suppose we will be cutting the maintenance releases from the release branches? So we will have to keep around the release branches for that purpose. I've asked
Build failed in Jenkins: simulator-singlerun #61
See http://jenkins.buildacloud.org/job/simulator-singlerun/61/changes Changes: [santhosh.edukulla] Fixed coverity reported concurrency issue -- [...truncated 7290 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: http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/../utils/conf/db.properties.override [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: http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/../utils/conf/db.properties.override 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 http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/target/db/create-schema-simulator.sql Processing SQL file at http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/target/db/templates.simulator.sql Processing SQL file at http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/target/db/hypervisor_capabilities.simulator.sql 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 http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/pom.xml 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.383s [INFO] Finished at: Wed Aug 06 01:58:17 EDT 2014 [INFO] Final Memory: 41M/181M [INFO] [simulator-singlerun] $ /bin/bash -x /tmp/hudson4058535375448883036.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=31332 + 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 +
Re: [VOTE] git workflow
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 rajani.karut...@citrix.com 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 daan.hoogl...@gmail.com 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 prerelease dates at which we merge as well. We don't have to do it at that date but can decide to do that the next day or week as well. This would kind of resemble Alena's #1 (as opposed to the more pure gitflow #2). An argument for #2 is that I don't think every customer greps the rpms for some release. I know our operators at Schuberg Philis investigate the code and check it out from git. They like to compare release and look at the latest easily. just checking out master would be very convenient for them. Of course they can check out a branch as well. But I doubt if they know exactly what to checkout then. I usually see them just look at the latest for a branch. All in all, I am very skeptic on whether this will work as planned. It is us who need to work neatly and only if we do that we can help ourselves with improving our process. I do feel that the present way of working, mainly the use forward branches but in general the lack of using branches to test individual changes, is hindering us in doing releases. The proposal at hand is very good but can only work if supported by the people that need to work with it. It doesn't do our release process for us. We still need to do it and not just program some code and check it in. That will never work in any process. Your code is not done until somebody somewhere finds it worth running it in a production environment. So let's keep discussing and educating each other. done ranting, feel free to react or contact me in person Daan On Wed, Aug 6, 2014 at 3:15 AM, David Nalley da...@gnsa.us wrote: On Tue, Aug 5, 2014 at 7:44 PM, Erik Weber terbol...@gmail.com wrote: On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle prachi.da...@citrix.com wrote: I fail to understand how will this model help us with the maintenance releases? That's what gitflow support branches is for. I find this quite descriptive: https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH06CuKT0J For CloudStack we also keep working on prior releases and ship out maintenance releases. I suppose
Re: Review Request 24313: CLOUDSTACK-7255: Fixed marvin issue related to creating random account usernames
--- 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'
--- 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
--- 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
[ACS44] release 4.4.1
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
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
--- 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
See http://jenkins.buildacloud.org/job/simulator-singlerun/63/changes
Re: Review Request 24302: CLOUDSTACK-7241: Fixed error in test_escalations_ipaddresses.py
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
--- 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 santhosh.eduku...@gmail.com - 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'
--- 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 https://reviews.apache.org/r/24298/#comment87033 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
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
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 nitin.me...@citrix.com 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
--- 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
Awesome, thank you! Sent from my iPhone On Aug 6, 2014, at 5:08 AM, Wido den Hollander w...@widodh.nl 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
--- 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 santhosh.eduku...@gmail.com - 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
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
See http://jenkins.buildacloud.org/job/simulator-singlerun/changes
Re: master branch will be frozen for direct commits on 7 Aug 2014
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 rajani.karut...@citrix.commailto: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
+ Dev ML This is great thanks for Sharing Vladimir! On 05-Aug-2014, at 10:48 pm, Vladimir Melnik v.mel...@uplink.ua 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 Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://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.
jenkins changes post git-flow shift
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
On Wed, Aug 6, 2014 at 1:39 PM, Rajani Karuturi raj...@apache.org 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
On Wed, Aug 6, 2014 at 10:54 AM, Daan Hoogland daan.hoogl...@gmail.com 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
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 raj...@apache.org 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
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 m...@daoenix.com 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
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 h...@apache.org 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 raj...@apache.org 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
See http://jenkins.buildacloud.org/job/simulator-singlerun/65/changes 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: http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/../utils/conf/db.properties.override 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 http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/target/db/create-schema-simulator.sql Processing SQL file at http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/target/db/templates.simulator.sql Processing SQL file at http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/target/db/hypervisor_capabilities.simulator.sql 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 http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/pom.xml 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-output.out + sleep 5 + COUNTER=17 +
RE: [DB-CHANGE] Infrastructure tab fails to load with db exception
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 nitin.me...@citrix.com 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
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'
--- 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'
On Aug. 6, 2014, 3:31 p.m., Santhosh Edukulla wrote: test/integration/smoke/misc/test_deploy_vm.py, line 85 https://reviews.apache.org/r/24298/diff/3/?file=652043#file652043line85 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
Re: branch hotfix/coverity-fixes
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 h...@trippaers.nl 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 Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: branch hotfix/coverity-fixes
On 6 aug. 2014, at 15:06, Rohit Yadav rohit.ya...@shapeblue.com 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 h...@trippaers.nl 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 Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: branch hotfix/coverity-fixes
Hey, On 06-Aug-2014, at 3:10 pm, Hugo Trippaers h...@trippaers.nl wrote: On 6 aug. 2014, at 15:06, Rohit Yadav rohit.ya...@shapeblue.com 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 h...@trippaers.nl 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 Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://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 Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://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
Re: branch hotfix/coverity-fixes
On 6 aug. 2014, at 15:15, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hey, On 06-Aug-2014, at 3:10 pm, Hugo Trippaers h...@trippaers.nl wrote: On 6 aug. 2014, at 15:06, Rohit Yadav rohit.ya...@shapeblue.com 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 h...@trippaers.nl 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 Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://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 Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://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
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'
--- 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 https://reviews.apache.org/r/24298/#comment87042 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 https://reviews.apache.org/r/24298/#comment87041 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 https://reviews.apache.org/r/24298/#comment87040 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
Jenkins build is unstable: simulator-singlerun #66
See http://jenkins.buildacloud.org/job/simulator-singlerun/66/changes
Re: How to config linux native bridge to forward vxlan encapsulated pkts
Do u turned neteork forward on? Sysctl -p can tell you the configuration On Aug 6, 2014 7:09 PM, Michael Li cloudcomp...@163.com 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
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 rayees.namathpon...@citrix.com 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 animesh.chaturv...@citrix.com 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
Re: [VOTE] git workflow
On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav rohit.ya...@shapeblue.com 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. 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
See http://jenkins.buildacloud.org/job/simulator-hotfix-trigger/15/ -- [...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: http://jenkins.buildacloud.org/job/simulator-hotfix-trigger/ws/developer/../utils/conf/db.properties.override 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 http://jenkins.buildacloud.org/job/simulator-hotfix-trigger/ws/developer/target/db/create-schema-simulator.sql Processing SQL file at http://jenkins.buildacloud.org/job/simulator-hotfix-trigger/ws/developer/target/db/templates.simulator.sql Processing SQL file at http://jenkins.buildacloud.org/job/simulator-hotfix-trigger/ws/developer/target/db/hypervisor_capabilities.simulator.sql 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 http://jenkins.buildacloud.org/job/simulator-hotfix-trigger/ws/developer/pom.xml 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 127.0.0.1 is up'
Re: Review Request 23982: CLOUDSTACK-7192: Skip tests on Hyper-V which don't apply
--- 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
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 da...@gnsa.us wrote: On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav rohit.ya...@shapeblue.com 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. 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
Re: [VOTE] git workflow
Hi David, On 06-Aug-2014, at 4:10 pm, David Nalley da...@gnsa.us wrote: On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav rohit.ya...@shapeblue.com 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 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, less divergent branches (release and master) - Make it less painful for RMs and other
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
--- 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
--- 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
On Wed, Aug 6, 2014 at 10:53 AM, Hugo Trippaers h...@trippaers.nl 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 da...@gnsa.us wrote: On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav rohit.ya...@shapeblue.com 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. 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
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
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 nitin.me...@citrix.com 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 -- *Mike Tutkowski*
Build failed in Jenkins: simulator-singlerun #67
See http://jenkins.buildacloud.org/job/simulator-singlerun/67/changes 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: http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/../utils/conf/db.properties.override [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: http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/../utils/conf/db.properties.override 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 http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/target/db/create-schema-simulator.sql Processing SQL file at http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/target/db/templates.simulator.sql Processing SQL file at http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/target/db/hypervisor_capabilities.simulator.sql 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 http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/pom.xml 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 server node 127.0.0.1 is up'
Re: [VOTE] git workflow
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 rohit.ya...@shapeblue.com 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). 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 rayees.namathpon...@citrix.com 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
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'
On Aug. 6, 2014, 1:19 p.m., Doug Clark wrote: test/integration/smoke/misc/test_deploy_vm.py, line 1 https://reviews.apache.org/r/24298/diff/4/?file=653689#file653689line1 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 https://reviews.apache.org/r/24298/diff/4/?file=653693#file653693line253 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
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 daan.hoogl...@gmail.com 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 rajani.karut...@citrix.com 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 daan.hoogl...@gmail.com 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 prerelease dates at which we merge as well. We don't have to do it at that date but can decide to do that the
Re: implementing git workflow
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 daan.hoogl...@gmail.com 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 rajani.karut...@citrix.com 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 da...@gnsa.usmailto:da...@gnsa.us wrote: On Tue, Aug 5, 2014 at 2:51 PM, Alena Prokharchyk alena.prokharc...@citrix.commailto: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=30738915selectedPageVersions=32selectedPageVersions=22 Agreement to do something and the following implementation are not necessarily instantaneous. -- Daan
Re: [VOTE] git workflow
On 06-Aug-2014, at 6:58 pm, Alena Prokharchyk alena.prokharc...@citrix.com 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 tag 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 release, if branch is not merged you’ve to force it with -D: git branch -D release To cut a maintenance release from a release version, all you’ll have to do it: git checkout -b support-branch tag 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 daan.hoogl...@gmail.com 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 rajani.karut...@citrix.com 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 daan.hoogl...@gmail.com 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!
Re: [VOTE] git workflow
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 rohit.ya...@shapeblue.com wrote: On 06-Aug-2014, at 6:58 pm, Alena Prokharchyk alena.prokharc...@citrix.com 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 tag 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 release, if branch is not merged you’ve to force it with -D: git branch -D release To cut a maintenance release from a release version, all you’ll have to do it: git checkout -b support-branch tag 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 daan.hoogl...@gmail.com 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 rajani.karut...@citrix.com 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 daan.hoogl...@gmail.com 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
Re: Review Request 24314: CLOUDSTACK-6695: UI: Added support for uploading a chain of certificates
--- 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
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 koushik@citrix.com 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 nitin.me...@citrix.com 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
Re: [VOTE] git workflow
Hi, On 06-Aug-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. 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 rohit.ya...@shapeblue.com wrote: On 06-Aug-2014, at 6:58 pm, Alena Prokharchyk alena.prokharc...@citrix.com 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 tag 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 release, if branch is not merged you’ve to force it with -D: git branch -D release To cut a maintenance release from a release version, all you’ll have to do it: git checkout -b support-branch tag 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
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
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 nitin.me...@citrix.com 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 koushik@citrix.com 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 nitin.me...@citrix.com 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
Re: [VOTE] git workflow
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 rohit.ya...@shapeblue.com wrote: Hi, On 06-Aug-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. 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 rohit.ya...@shapeblue.com wrote: On 06-Aug-2014, at 6:58 pm, Alena Prokharchyk alena.prokharc...@citrix.com 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 tag and see the history: git log --graph --decorate --pretty=oneline --abbrev-commit —all So, it’s safe to delete a branch
Re: [VOTE] git workflow
On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, On 06-Aug-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. 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
Agreed. Added that information in the bug. On 06/08/14 11:08 AM, Alena Prokharchyk alena.prokharc...@citrix.com wrote: Thank you, Nitin. I think we should add one more item to the things that the script checks: modifications to the older upgrade paths shouldn¹t be allowed. If we already released 4.4, db upgrade changes should be accepted only to 4.4-4.5 scripts. If someone makes the changes to, say 4.3-4.4, the mailing list should be notified, and the changes have to be reverted. -Alena. On 8/6/14, 11:03 AM, Nitin Mehta nitin.me...@citrix.com 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 koushik@citrix.com 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 nitin.me...@citrix.com 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
Re: [VOTE] git workflow
On 8/6/14, 11:22 AM, David Nalley da...@gnsa.us wrote: On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, On 06-Aug-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. 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
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 nitin.me...@citrix.com wrote: Agreed. Added that information in the bug. On 06/08/14 11:08 AM, Alena Prokharchyk alena.prokharc...@citrix.com javascript:; 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 nitin.me...@citrix.com javascript:; 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 koushik@citrix.com javascript:; 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 javascript:;] Sent: Wednesday, 6 August 2014 3:37 PM To: dev@cloudstack.apache.org javascript:; 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 nitin.me...@citrix.com javascript:; 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,
Getting Refusing to design this network, the physical isolation type is not MIDO while deploying a VM with new network from UI
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=createNetworkresponse=jsonsessionkey=IyiV1YiWuFVSGa7GynZv5T12nLk%3DnetworkOfferingId=94cef53e-49ec-4a9f-a0fc-f82f0e40aba5name=testdisplayText=testzoneId=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=createNetworkresponse=jsonsessionkey=IyiV1YiWuFVSGa7GynZv5T12nLk%3DnetworkOfferingId=94cef53e-49ec-4a9f-a0fc-f82f0e40aba5name=testdisplayText=testzoneId=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=deployVirtualMachineresponse=jsonsessionkey=IyiV1YiWuFVSGa7GynZv5T12nLk%3Dzoneid=29d069ac-e1ea-45dc-8c35-dd5b6c628ce2templateid=991edabc-9662-4244-ad92-85f732a9f024hypervisor=XenServerserviceofferingid=d4206400-e06a-4c58-bdf1-97df6bf06592iptonetworklist%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 VM:
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com Date: Wednesday, August 6, 2014 at 11:33 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Cc: Alena Prokharchyk alena.prokharc...@citrix.commailto:alena.prokharc...@citrix.com, Koushik Das koushik@citrix.commailto: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 nitin.me...@citrix.commailto:nitin.me...@citrix.com wrote: Agreed. Added that information in the bug. On 06/08/14 11:08 AM, Alena Prokharchyk alena.prokharc...@citrix.comjavascript:; 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 nitin.me...@citrix.comjavascript:; 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 koushik@citrix.comjavascript:; 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.comjavascript:;] Sent: Wednesday, 6 August 2014 3:37 PM To: dev@cloudstack.apache.orgjavascript:; 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 nitin.me...@citrix.comjavascript:; 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.idhttp://vm_instance.id id, vm_instance.namehttp://vm_instance.name name, account.idhttp://account.id account_id, account.uuid account_uuid, account.account_name account_name, account.type account_type, domain.idhttp://domain.id domain_id, domain.uuid domain_uuid, domain.namehttp://domain.name domain_name, domain.path domain_path, projects.idhttp://projects.id project_id, projects.uuid project_uuid, projects.namehttp://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.idhttp://data_center.id data_center_id, data_center.uuid data_center_uuid, data_center.namehttp://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.idhttp://host.id host_id, host.uuid host_uuid, host.namehttp://host.name host_name, host.hypervisor_type, host.cluster_id cluster_id, vm_template.idhttp://vm_template.id template_id, vm_template.uuid template_uuid, service_offering.idhttp://service_offering.id service_offering_id, disk_offering.uuid service_offering_uuid, disk_offering.namehttp://disk_offering.name service_offering_name, nics.idhttp://nics.id nic_id, nics.uuid
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
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 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com Date: Wednesday, August 6, 2014 at 11:33 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Cc: Alena Prokharchyk alena.prokharc...@citrix.commailto:alena.prokharc...@citrix.com, Koushik Das koushik@citrix.commailto: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 nitin.me...@citrix.commailto:nitin.me...@citrix.com wrote: Agreed. Added that information in the bug. On 06/08/14 11:08 AM, Alena Prokharchyk alena.prokharc...@citrix.comjavascript:; 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 nitin.me...@citrix.comjavascript:; 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 koushik@citrix.comjavascript:; 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.comjavascript:;] Sent: Wednesday, 6 August 2014 3:37 PM To: dev@cloudstack.apache.orgjavascript:; 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 nitin.me...@citrix.comjavascript:; 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.idhttp://vm_instance.id id, vm_instance.namehttp://vm_instance.name name, account.idhttp://account.id account_id, account.uuid account_uuid, account.account_name account_name, account.type account_type, domain.idhttp://domain.id domain_id, domain.uuid domain_uuid, domain.namehttp://domain.name domain_name, domain.path domain_path, projects.idhttp://projects.id project_id, projects.uuid project_uuid, projects.namehttp://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.idhttp://data_center.id data_center_id, data_center.uuid data_center_uuid, data_center.namehttp://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,
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
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 mike.tutkow...@solidfire.com javascript:_e(%7B%7D,'cvml','mike.tutkow...@solidfire.com'); Date: Wednesday, August 6, 2014 at 11:33 AM To: dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); Cc: Alena Prokharchyk alena.prokharc...@citrix.com javascript:_e(%7B%7D,'cvml','alena.prokharc...@citrix.com');, Koushik Das koushik@citrix.com javascript:_e(%7B%7D,'cvml','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 nitin.me...@citrix.com javascript:_e(%7B%7D,'cvml','nitin.me...@citrix.com'); wrote: Agreed. Added that information in the bug. On 06/08/14 11:08 AM, Alena Prokharchyk alena.prokharc...@citrix.com wrote: Thank you, Nitin. I think we should add one more item to the things that the script checks: modifications to the older upgrade paths shouldn¹t be allowed. If we already released 4.4, db upgrade changes should be accepted only to 4.4-4.5 scripts. If someone makes the changes to, say 4.3-4.4, the mailing list should be notified, and the changes have to be reverted. -Alena. On 8/6/14, 11:03 AM, Nitin Mehta nitin.me...@citrix.com 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 koushik@citrix.com 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 nitin.me...@citrix.com 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
Re: [VOTE] git workflow
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 alena.prokharc...@citrix.com wrote: On 8/6/14, 11:22 AM, David Nalley da...@gnsa.us wrote: On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, On 06-Aug-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. 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 Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://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
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
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 mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.com javascript:_e(%7B%7D,'cvml','mike.tutkow...@solidfire.com'); Date: Wednesday, August 6, 2014 at 11:33 AM To: dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); Cc: Alena Prokharchyk alena.prokharc...@citrix.com javascript:_e(%7B%7D,'cvml','alena.prokharc...@citrix.com');, Koushik Das koushik@citrix.com javascript:_e(%7B%7D,'cvml','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 nitin.me...@citrix.com javascript:_e(%7B%7D,'cvml','nitin.me...@citrix.com'); wrote: Agreed. Added that information in the bug. On 06/08/14 11:08 AM, Alena Prokharchyk alena.prokharc...@citrix.com wrote: Thank you, Nitin. I think we should add one more item to the things that the script checks: modifications to the older upgrade paths shouldn¹t be allowed. If we already released 4.4, db upgrade changes should be accepted only to 4.4-4.5 scripts. If someone makes the changes to, say 4.3-4.4, the mailing list should be notified, and the changes have to be reverted. -Alena. On 8/6/14, 11:03 AM, Nitin Mehta nitin.me...@citrix.com 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 koushik@citrix.com 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 nitin.me...@citrix.com 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
Re: Getting Refusing to design this network, the physical isolation type is not MIDO while deploying a VM with new network from UI
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 abhinav@citrix.com 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=createNetworkresponse=jsonsessionkey=IyiV1YiWuFVSGa7GynZv5T12nLk%3DnetworkOfferingId=94cef53e-49ec-4a9f-a0fc-f82f0e40aba5name=testdisplayText=testzoneId=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=createNetworkresponse=jsonsessionkey=IyiV1YiWuFVSGa7GynZv5T12nLk%3DnetworkOfferingId=94cef53e-49ec-4a9f-a0fc-f82f0e40aba5name=testdisplayText=testzoneId=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=deployVirtualMachineresponse=jsonsessionkey=IyiV1YiWuFVSGa7GynZv5T12nLk%3Dzoneid=29d069ac-e1ea-45dc-8c35-dd5b6c628ce2templateid=991edabc-9662-4244-ad92-85f732a9f024hypervisor=XenServerserviceofferingid=d4206400-e06a-4c58-bdf1-97df6bf06592iptonetworklist%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
Re: [VOTE] git workflow
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 rohit.ya...@shapeblue.com 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 alena.prokharc...@citrix.com wrote: On 8/6/14, 11:22 AM, David Nalley da...@gnsa.us wrote: On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, On 06-Aug-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. 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
Re: [VOTE] git workflow
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
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 rohit.ya...@shapeblue.com wrote: Hi David, On 06-Aug-2014, at 4:10 pm, David Nalley da...@gnsa.us wrote: On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav rohit.ya...@shapeblue.com 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 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
Re: [VOTE] git workflow
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
On 8/6/14, 12:52 PM, Erik Weber terbol...@gmail.com 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)
--- 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)
--- 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
--- 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
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 abhinav@citrix.com 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=createNetworkresponse=jsonsessionkey=IyiV1YiWuFVSGa7GynZv5T12nLk%3DnetworkOfferingId=94cef53e-49ec-4a9f-a0fc-f82f0e40aba5name=testdisplayText=testzoneId=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=createNetworkresponse=jsonsessionkey=IyiV1YiWuFVSGa7GynZv5T12nLk%3DnetworkOfferingId=94cef53e-49ec-4a9f-a0fc-f82f0e40aba5name=testdisplayText=testzoneId=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=deployVirtualMachineresponse=jsonsessionkey=IyiV1YiWuFVSGa7GynZv5T12nLk%3Dzoneid=29d069ac-e1ea-45dc-8c35-dd5b6c628ce2templateid=991edabc-9662-4244-ad92-85f732a9f024hypervisor=XenServerserviceofferingid=d4206400-e06a-4c58-bdf1-97df6bf06592iptonetworklist%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
Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
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 rohit.ya...@shapeblue.com 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 mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.com javascript:_e(%7B%7D,'cvml','mike.tutkow...@solidfire.com'); Date: Wednesday, August 6, 2014 at 11:33 AM To: dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); dev@cloudstack.apache.org javascript:_e(%7B%7D,'cvml','dev@cloudstack.apache.org'); Cc: Alena Prokharchyk alena.prokharc...@citrix.com javascript:_e(%7B%7D,'cvml','alena.prokharc...@citrix.com');, Koushik Das koushik@citrix.com javascript:_e(%7B%7D,'cvml','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 nitin.me...@citrix.com javascript:_e(%7B%7D,'cvml','nitin.me...@citrix.com'); wrote: Agreed. Added that information in the bug. On 06/08/14 11:08 AM, Alena Prokharchyk alena.prokharc...@citrix.com wrote: Thank you, Nitin. I think we should add one more item to the things that the script checks: modifications to the older upgrade paths shouldn¹t be allowed. If we already released 4.4, db upgrade changes should be accepted only to 4.4-4.5 scripts. If someone makes the changes to, say 4.3-4.4, the mailing list should be notified, and the changes have to be reverted. -Alena. On 8/6/14, 11:03 AM, Nitin Mehta nitin.me...@citrix.com 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 koushik@citrix.com 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 nitin.me...@citrix.com 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
Re: [VOTE] git workflow
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 alena.prokharc...@citrix.com wrote: On 8/6/14, 12:52 PM, Erik Weber terbol...@gmail.com 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
-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 terbol...@gmail.com 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
Daan, thank you for the summary. See my answers below. On 8/6/14, 1:59 PM, Daan Hoogland daan.hoogl...@gmail.com 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 alena.prokharc...@citrix.com wrote: On 8/6/14, 12:52 PM, Erik Weber terbol...@gmail.com 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
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 edison...@citrix.com 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 terbol...@gmail.com 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
See http://jenkins.buildacloud.org/job/simulator-singlerun/68/changes
RE: [VOTE] git workflow
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 edison...@citrix.com 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 terbol...@gmail.com 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
[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 alena.prokharc...@citrix.com 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 edison...@citrix.com 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 terbol...@gmail.com 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
Re: [VOTE] git workflow
On Aug 6, 2014, at 6:13 PM, Prachi Damle prachi.da...@citrix.com 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 edison...@citrix.com 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 terbol...@gmail.com 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
Re: [VOTE] git workflow
On 8/6/14, 3:18 PM, Sebastien Goasguen run...@gmail.com 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 alena.prokharc...@citrix.com 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 edison...@citrix.com 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 terbol...@gmail.com 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,
RE: [VOTE] git workflow
-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 prachi.da...@citrix.com 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 edison...@citrix.com 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 terbol...@gmail.com 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,
Jenkins build is still unstable: simulator-singlerun #69
See http://jenkins.buildacloud.org/job/simulator-singlerun/changes
RE: [VOTE] git workflow
-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 alena.prokharc...@citrix.com 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 edison...@citrix.com 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 terbol...@gmail.com 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
Re: [VOTE] git workflow
On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk alena.prokharc...@citrix.com 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
Review Board 22799
Hey Tim, What is the current status of this Review Board item from your point of view? https://reviews.apache.org/r/22799/ Is this far enough along that we might soon consider merging it in for 4.5? Talk to you later! -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*
Re:Re: How to config linux native bridge to forward vxlan encapsulated pkts
I have resolved this issue by disable snooping echo 0 /sys/devices/virtual/net/cloudbr1/bridge/multicast_snooping sysctl -p Thanks Yitao anyway At 2014-08-06 09:44:46, Yitao Jiang willier...@gmail.com wrote: Do u turned neteork forward on? Sysctl -p can tell you the configuration On Aug 6, 2014 7:09 PM, Michael Li cloudcomp...@163.com 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
Build failed in Jenkins: simulator-singlerun #70
See http://jenkins.buildacloud.org/job/simulator-singlerun/70/changes Changes: [nitin.mehta] CLOUDSTACK-7272: Router stop fails with NPE. Fixing it by making the hostId as Long object than native type long. The issue was the response was checking for getHostId() != null to populate attribute hypervisor. But since the hostId is declared as long it will never be null, resulting in the NPE when populating hypervisor. Fixed that -- [...truncated 7276 lines...] [INFO] [INFO] --- properties-maven-plugin:1.0-alpha-2:read-project-properties (default) @ cloud-developer --- [WARNING] Ignoring missing properties file: http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/../utils/conf/db.properties.override [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: http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/../utils/conf/db.properties.override 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 http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/target/db/create-schema-simulator.sql Processing SQL file at http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/target/db/templates.simulator.sql Processing SQL file at http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/target/db/hypervisor_capabilities.simulator.sql 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 http://jenkins.buildacloud.org/job/simulator-singlerun/ws/developer/pom.xml 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: 31.987s [INFO] Finished at: Wed Aug 06 21:39:05 EDT 2014 [INFO] Final Memory: 41M/189M [INFO] [simulator-singlerun] $ /bin/bash -x /tmp/hudson8264436907114391815.sh + grep -q Launcher + jps -l + 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=19846 + 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
