Re: [ASF4.2.1] Release Notes
I might be behind on the discussions here, but I will veto an RC that does not have list of bugs fixed and proper upgrade path documented (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the docs or not. Right now I see that the bugs fix list points to a jira filter. This is not consistent with the way it was done in prior releases (explicit listing) and in 4.2 (which pointed to the RN). We need consistency. What happens if someone changes this jira filter ? I also would like to see the results of the test matrix for 4.2.1 running within jenkins.buildacloud.org. This http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against master and has been failing for a while. PS: I did test it and did the usual smoke test so -1 (binding) at this time -sebastien On Nov 14, 2013, at 4:20 PM, Chip Childers chipchild...@apache.org wrote: Except that the separation only helps if it allows RC testing + voting during doc finalization. If we announce before docs, it hurts us. I'm against another announcement that goes out with the docs in poor shape. On Thu, Nov 14, 2013 at 3:44 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Unless there are objection to the RC, I would prefer to have it released and make the announcement sooner and showcase in collab conference. As Chip mentions docs were broken out separately anyway. Animesh On 14/11/13 8:12 pm, Sebastien Goasguen run...@gmail.com wrote: Anyway we can wait next week to release. quite a few of us will be together in Amsterdam, we can dedicate a hackathon session to 4.2.1 , make sure RN are good, upgrade path etcŠthen testŠ. I'd recommend keeping the vote open until then. -sebastien On Nov 14, 2013, at 5:57 AM, Radhika Puthiyetath radhika.puthiyet...@citrix.com wrote: Hi, The master has the most up-to-date RN for 4.2.1. From: Abhinandan Prateek Sent: Thursday, November 14, 2013 2:22 PM To: CloudStack Dev Cc: Radhika Puthiyetath Subject: Re: [ASF4.2.1] Release Notes It seems the upgrade section of release notes will require a review, probably followed by a revamp (?). Can we have some volunteers who are familiar with various upgrade paths comment on it ? Me and Radhika will try to consolidate those comments, snippets and fix the RN for 4.2.1. -abhi RN for 4.2.1 = https://git-wip-us.apache.org/repos/asf?p=cloudstack-docs.git;a=tree;f =re lease-notes;h=8128d62c39236331492f3642914bf97b43ed2670;hb=refs/heads/4 .2
hackathons
H all, One last call fro all coming to CCC Europe: have a quick look at https://cwiki.apache.org/confluence/display/CLOUDSTACK/CCC+Europe and see what you want to work on on Wednesday. If it is not there feel free to submit more ideas. regards, Daan
Re: bf22f6dfe reverts commit 1762dbbb
I have reverted the same in 4.3 as well commit f84b729eb01ffc7cae1e210b58f80ff2033ad785 Author: Koushik Das kous...@apache.org Date: Fri Nov 15 12:59:48 2013 +0530 Revert CLOUDSTACK-5176: This reverts commit f29c7188ba03f1997238d50f8a11857e94fe4b55. On 15-Nov-2013, at 10:35 AM, Prasanna Santhanam t...@apache.org wrote: I've reverted 1762dbbb as it seems to have introduced ConfigurationParameterScope which didn't exist causing builds to fail on master. Thanks, -- Prasanna., Powered by BigRock.com
Re: Review Request 15507: CLOUDSTACK-4835: Update global configuration test cases failed in master
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15507/#review28951 --- Commit 52de0dc2cae33831cebb23ed4bb81d8368ed33de in branch refs/heads/4.3 from Harikrishna Patnala [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=52de0dc ] CLOUDSTACK-4835: Update global configuration test cases failed in master Changes made in update/list configuration API to use ConfigDepot CLOUDSTACK-4169: Scoped configuraion parameters logic moved to ConfigDepot CLOUDSTACK-5163: missing parameters in configuration table - ASF Subversion and Git Services On Nov. 14, 2013, 9:25 a.m., Harikrishna Patnala wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15507/ --- (Updated Nov. 14, 2013, 9:25 a.m.) Review request for cloudstack and Koushik Das. Bugs: CLOUDSTACK-4169, CLOUDSTACK-4835 and CLOUDSTACK-5163 https://issues.apache.org/jira/browse/CLOUDSTACK-4169 https://issues.apache.org/jira/browse/CLOUDSTACK-4835 https://issues.apache.org/jira/browse/CLOUDSTACK-5163 Repository: cloudstack-git Description --- CLOUDSTACK-4835: Update global configuration test cases failed in master Changes made in update/list configuration API to use ConfigDepot CLOUDSTACK-4169: Scoped configuraion parameters logic moved to ConfigDepot CLOUDSTACK-5163: missing parameters in configuration table pool.storage.capacity.disablethreshold, storage.overprovisioning.factor, pool.storage.allocated.capacity.disablethreshold, cluster.cpu.allocated.capacity.disablethreshold, cluster.memory.allocated.capacity.disablethreshold Diffs - api/src/com/cloud/deploy/DeploymentClusterPlanner.java ca73267 framework/config/src/org/apache/cloudstack/framework/config/ConfigDepot.java 2fd6efb framework/config/src/org/apache/cloudstack/framework/config/impl/ConfigDepotImpl.java 254e6d2 server/src/com/cloud/capacity/CapacityManagerImpl.java 70491bc server/src/com/cloud/configuration/Config.java bc805b7 server/src/com/cloud/configuration/ConfigurationManagerImpl.java 82256ca server/src/com/cloud/deploy/FirstFitPlanner.java 64b1124 server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java a088a4a server/src/com/cloud/server/ConfigurationServerImpl.java 8459ada server/test/org/apache/cloudstack/networkoffering/ChildTestConfiguration.java d7ac3f7 Diff: https://reviews.apache.org/r/15507/diff/ Testing --- Thanks, Harikrishna Patnala
Re: [ASF4.2.1] Release Notes
So the -1 is because of the lack of rn and upgrade path docs, right, I think I proposed earlier this thread to release after the doc hackathon privided that. I wasn't really explicit about it I think as no one commented on this strategy. Would that be acceptable to you all (especially David and Sebastien)? I agree btw that docs must be available, but I don't think these have to be as stable as the release. We should allow for improving the docs on a release if needed. The net result of what I am proposing is that there will be a release and a docs rc. This is what the splitting of of the docs was about in my view,. Makes sense? If not, we should not try to make CCC Europe with 4.2.1. I think this is what the hurry is about Daan On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen run...@gmail.com wrote: I might be behind on the discussions here, but I will veto an RC that does not have list of bugs fixed and proper upgrade path documented (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the docs or not. Right now I see that the bugs fix list points to a jira filter. This is not consistent with the way it was done in prior releases (explicit listing) and in 4.2 (which pointed to the RN). We need consistency. What happens if someone changes this jira filter ? I also would like to see the results of the test matrix for 4.2.1 running within jenkins.buildacloud.org. This http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against master and has been failing for a while. PS: I did test it and did the usual smoke test so -1 (binding) at this time -sebastien On Nov 14, 2013, at 4:20 PM, Chip Childers chipchild...@apache.org wrote: Except that the separation only helps if it allows RC testing + voting during doc finalization. If we announce before docs, it hurts us. I'm against another announcement that goes out with the docs in poor shape. On Thu, Nov 14, 2013 at 3:44 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Unless there are objection to the RC, I would prefer to have it released and make the announcement sooner and showcase in collab conference. As Chip mentions docs were broken out separately anyway. Animesh On 14/11/13 8:12 pm, Sebastien Goasguen run...@gmail.com wrote: Anyway we can wait next week to release. quite a few of us will be together in Amsterdam, we can dedicate a hackathon session to 4.2.1 , make sure RN are good, upgrade path etcŠthen testŠ. I'd recommend keeping the vote open until then. -sebastien On Nov 14, 2013, at 5:57 AM, Radhika Puthiyetath radhika.puthiyet...@citrix.com wrote: Hi, The master has the most up-to-date RN for 4.2.1. From: Abhinandan Prateek Sent: Thursday, November 14, 2013 2:22 PM To: CloudStack Dev Cc: Radhika Puthiyetath Subject: Re: [ASF4.2.1] Release Notes It seems the upgrade section of release notes will require a review, probably followed by a revamp (?). Can we have some volunteers who are familiar with various upgrade paths comment on it ? Me and Radhika will try to consolidate those comments, snippets and fix the RN for 4.2.1. -abhi RN for 4.2.1 = https://git-wip-us.apache.org/repos/asf?p=cloudstack-docs.git;a=tree;f =re lease-notes;h=8128d62c39236331492f3642914bf97b43ed2670;hb=refs/heads/4 .2
Review Request 15452: CLOUDSTACK-5147: Removing basic and sg tags from test case which is invalid for basic zone
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15452/ --- Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri. Summary (updated) - CLOUDSTACK-5147: Removing basic and sg tags from test case which is invalid for basic zone Bugs: CLOUDSTACK-5147 https://issues.apache.org/jira/browse/CLOUDSTACK-5147 Repository: cloudstack-git Description (updated) --- The test case test_resource_limits.TestMaxAccountNetworks.test_maxAccountNetworks tries to create multiple isolated networks in an account which is invalid scenario for basic zone. Diffs (updated) - test/integration/component/test_resource_limits.py 377aa74 Diff: https://reviews.apache.org/r/15452/diff/ Testing --- Thanks, Gaurav Aradhye
Re: Review Request 15570: CLOUDSTACK-5180: Increasing the timeout for uploading volume
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15570/#review28952 --- Commit a95bea08e4c41e359c137068245d04bae4d1dff4 in branch refs/heads/4.2 from Gaurav Aradhye [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a95bea0 ] CLOUDSTACK-5180: Increasing the timeout for uploading volume - ASF Subversion and Git Services On Nov. 15, 2013, 7:56 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15570/ --- (Updated Nov. 15, 2013, 7:56 a.m.) Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-5180 https://issues.apache.org/jira/browse/CLOUDSTACK-5180 Repository: cloudstack-git Description --- Some test cases are failing while uploading the volume just because the time allowed to upload the volume is less in marvin library. If timeout is increases, these tests pass. Example - component.test_stopped_vm.TestUploadAttachVolume.test_upload_attach_volume. This test case has failed in latest build but had passed earlier build. To avoid this inconsistent behaviour, increased the timeout in wait_for_upload function in Volume class in base.py The test case runs successfully with this change. Diffs - tools/marvin/marvin/integration/lib/base.py a3a5f58 Diff: https://reviews.apache.org/r/15570/diff/ Testing --- Tested locally on XenServer basic zone setup. client Log: 2013-11-14 19:43:59,017 - DEBUG - test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) - Uploading the volume: DataDisk 2013-11-14 19:44:05,299 - DEBUG - test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) - Uploading the volume: DataDisk 2013-11-14 19:51:05,568 - DEBUG - test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) - Volume: %s uploaded successfully 2013-11-14 19:51:05,568 - DEBUG - test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) - Deploying VM instance in account: test-OLJLXM Result log: test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) Test Upload volume and attach to VM in stopped state ... ok -- Ran 17 tests in 442.869s OK (skipped=16) Thanks, Gaurav Aradhye
Re: Review Request 15570: CLOUDSTACK-5180: Increasing the timeout for uploading volume
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15570/#review28953 --- Commit 08208cf427f9957514e3bcc624272c6781a1189a in branch refs/heads/4.3 from Gaurav Aradhye [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=08208cf ] CLOUDSTACK-5180: Increasing the timeout for uploading volume - ASF Subversion and Git Services On Nov. 15, 2013, 7:56 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15570/ --- (Updated Nov. 15, 2013, 7:56 a.m.) Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-5180 https://issues.apache.org/jira/browse/CLOUDSTACK-5180 Repository: cloudstack-git Description --- Some test cases are failing while uploading the volume just because the time allowed to upload the volume is less in marvin library. If timeout is increases, these tests pass. Example - component.test_stopped_vm.TestUploadAttachVolume.test_upload_attach_volume. This test case has failed in latest build but had passed earlier build. To avoid this inconsistent behaviour, increased the timeout in wait_for_upload function in Volume class in base.py The test case runs successfully with this change. Diffs - tools/marvin/marvin/integration/lib/base.py a3a5f58 Diff: https://reviews.apache.org/r/15570/diff/ Testing --- Tested locally on XenServer basic zone setup. client Log: 2013-11-14 19:43:59,017 - DEBUG - test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) - Uploading the volume: DataDisk 2013-11-14 19:44:05,299 - DEBUG - test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) - Uploading the volume: DataDisk 2013-11-14 19:51:05,568 - DEBUG - test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) - Volume: %s uploaded successfully 2013-11-14 19:51:05,568 - DEBUG - test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) - Deploying VM instance in account: test-OLJLXM Result log: test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) Test Upload volume and attach to VM in stopped state ... ok -- Ran 17 tests in 442.869s OK (skipped=16) Thanks, Gaurav Aradhye
Re: Review Request 15570: CLOUDSTACK-5180: Increasing the timeout for uploading volume
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15570/#review28954 --- Ship it! COmmitted to 4.2, 4.3 and master - Girish Shilamkar On Nov. 15, 2013, 7:56 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15570/ --- (Updated Nov. 15, 2013, 7:56 a.m.) Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-5180 https://issues.apache.org/jira/browse/CLOUDSTACK-5180 Repository: cloudstack-git Description --- Some test cases are failing while uploading the volume just because the time allowed to upload the volume is less in marvin library. If timeout is increases, these tests pass. Example - component.test_stopped_vm.TestUploadAttachVolume.test_upload_attach_volume. This test case has failed in latest build but had passed earlier build. To avoid this inconsistent behaviour, increased the timeout in wait_for_upload function in Volume class in base.py The test case runs successfully with this change. Diffs - tools/marvin/marvin/integration/lib/base.py a3a5f58 Diff: https://reviews.apache.org/r/15570/diff/ Testing --- Tested locally on XenServer basic zone setup. client Log: 2013-11-14 19:43:59,017 - DEBUG - test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) - Uploading the volume: DataDisk 2013-11-14 19:44:05,299 - DEBUG - test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) - Uploading the volume: DataDisk 2013-11-14 19:51:05,568 - DEBUG - test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) - Volume: %s uploaded successfully 2013-11-14 19:51:05,568 - DEBUG - test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) - Deploying VM instance in account: test-OLJLXM Result log: test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) Test Upload volume and attach to VM in stopped state ... ok -- Ran 17 tests in 442.869s OK (skipped=16) Thanks, Gaurav Aradhye
Re: Review Request 15570: CLOUDSTACK-5180: Increasing the timeout for uploading volume
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15570/#review28955 --- Commit c141e418e927dadc90a87ad4e1a939091cfbe54e in branch refs/heads/master from Gaurav Aradhye [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c141e41 ] CLOUDSTACK-5180: Increasing the timeout for uploading volume - ASF Subversion and Git Services On Nov. 15, 2013, 7:56 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15570/ --- (Updated Nov. 15, 2013, 7:56 a.m.) Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-5180 https://issues.apache.org/jira/browse/CLOUDSTACK-5180 Repository: cloudstack-git Description --- Some test cases are failing while uploading the volume just because the time allowed to upload the volume is less in marvin library. If timeout is increases, these tests pass. Example - component.test_stopped_vm.TestUploadAttachVolume.test_upload_attach_volume. This test case has failed in latest build but had passed earlier build. To avoid this inconsistent behaviour, increased the timeout in wait_for_upload function in Volume class in base.py The test case runs successfully with this change. Diffs - tools/marvin/marvin/integration/lib/base.py a3a5f58 Diff: https://reviews.apache.org/r/15570/diff/ Testing --- Tested locally on XenServer basic zone setup. client Log: 2013-11-14 19:43:59,017 - DEBUG - test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) - Uploading the volume: DataDisk 2013-11-14 19:44:05,299 - DEBUG - test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) - Uploading the volume: DataDisk 2013-11-14 19:51:05,568 - DEBUG - test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) - Volume: %s uploaded successfully 2013-11-14 19:51:05,568 - DEBUG - test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) - Deploying VM instance in account: test-OLJLXM Result log: test_upload_attach_volume (test_stopped_vm.TestUploadAttachVolume) Test Upload volume and attach to VM in stopped state ... ok -- Ran 17 tests in 442.869s OK (skipped=16) Thanks, Gaurav Aradhye
Re: Review Request 15452: CLOUDSTACK-5147: Removing basic and sg tags from test case which is invalid for basic zone
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15452/#review28957 --- Commit cfe3aabdc79a0702f5f12ca6b11266acf054cd6e in branch refs/heads/4.3 from Gaurav Aradhye [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cfe3aab ] CLOUDSTACK-5147: Removing basic and sg tags from the test case which is invalid for basic zone - ASF Subversion and Git Services On Nov. 15, 2013, 10:07 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15452/ --- (Updated Nov. 15, 2013, 10:07 a.m.) Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-5147 https://issues.apache.org/jira/browse/CLOUDSTACK-5147 Repository: cloudstack-git Description --- The test case test_resource_limits.TestMaxAccountNetworks.test_maxAccountNetworks tries to create multiple isolated networks in an account which is invalid scenario for basic zone. Diffs - test/integration/component/test_resource_limits.py 377aa74 Diff: https://reviews.apache.org/r/15452/diff/ Testing --- Thanks, Gaurav Aradhye
Re: Review Request 15452: CLOUDSTACK-5147: Removing basic and sg tags from test case which is invalid for basic zone
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15452/#review28956 --- Commit a6c2c6a261af4871b0a8872f43068f15cc1da3cd in branch refs/heads/master from Gaurav Aradhye [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a6c2c6a ] CLOUDSTACK-5147: Removing basic and sg tags from the test case which is invalid for basic zone - ASF Subversion and Git Services On Nov. 15, 2013, 10:07 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15452/ --- (Updated Nov. 15, 2013, 10:07 a.m.) Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-5147 https://issues.apache.org/jira/browse/CLOUDSTACK-5147 Repository: cloudstack-git Description --- The test case test_resource_limits.TestMaxAccountNetworks.test_maxAccountNetworks tries to create multiple isolated networks in an account which is invalid scenario for basic zone. Diffs - test/integration/component/test_resource_limits.py 377aa74 Diff: https://reviews.apache.org/r/15452/diff/ Testing --- Thanks, Gaurav Aradhye
Re: Review Request 15452: CLOUDSTACK-5147: Removing basic and sg tags from test case which is invalid for basic zone
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15452/#review28958 --- Ship it! Committed to 4.2, 4.3 and master - Girish Shilamkar On Nov. 15, 2013, 10:07 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15452/ --- (Updated Nov. 15, 2013, 10:07 a.m.) Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-5147 https://issues.apache.org/jira/browse/CLOUDSTACK-5147 Repository: cloudstack-git Description --- The test case test_resource_limits.TestMaxAccountNetworks.test_maxAccountNetworks tries to create multiple isolated networks in an account which is invalid scenario for basic zone. Diffs - test/integration/component/test_resource_limits.py 377aa74 Diff: https://reviews.apache.org/r/15452/diff/ Testing --- Thanks, Gaurav Aradhye
Re: Review Request 15452: CLOUDSTACK-5147: Removing basic and sg tags from test case which is invalid for basic zone
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15452/#review28959 --- Commit 057a65e9a9df80592e1360dce8dfffaddacebd02 in branch refs/heads/4.2 from Gaurav Aradhye [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=057a65e ] CLOUDSTACK-5147: Removing basic and sg tags from the test case which is invalid for basic zone - ASF Subversion and Git Services On Nov. 15, 2013, 10:07 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15452/ --- (Updated Nov. 15, 2013, 10:07 a.m.) Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-5147 https://issues.apache.org/jira/browse/CLOUDSTACK-5147 Repository: cloudstack-git Description --- The test case test_resource_limits.TestMaxAccountNetworks.test_maxAccountNetworks tries to create multiple isolated networks in an account which is invalid scenario for basic zone. Diffs - test/integration/component/test_resource_limits.py 377aa74 Diff: https://reviews.apache.org/r/15452/diff/ Testing --- Thanks, Gaurav Aradhye
Re: Review Request 15569: CLOUDSTACK-5179: Fixed test script issue related to detach volume
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15569/#review28960 --- Commit 5b2de676732ad8f8180782348cde656821728696 in branch refs/heads/4.2 from Gaurav Aradhye [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5b2de67 ] CLOUDSTACK-5179: Fixed test script issue related to detach volume - ASF Subversion and Git Services On Nov. 15, 2013, 7:41 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15569/ --- (Updated Nov. 15, 2013, 7:41 a.m.) Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-5179 https://issues.apache.org/jira/browse/CLOUDSTACK-5179 Repository: cloudstack-git Description --- component.test_stopped_vm.TestDeployVM.test_08_deploy_attached_volume test case was failing while detaching volume because the volume was not listed properly. List volumes should accept the virtualmachineid parameter to correctly list the volume belonging to the virtual machine, otherwise the volume which we are detaching from virtual machine may belong to other virtual machine, in this case test case will fail. Diffs - test/integration/component/test_stopped_vm.py 4514bb7 Diff: https://reviews.apache.org/r/15569/diff/ Testing --- Tested locally on XenServer Basic Zone setup. test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) Test Deploy Virtual Machine with startVM=false and attach volume already attached to different machine ... == client.log == 2013-11-14 19:27:10,018 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for virtual machine: 9631c 64f-a7ba-488b-951b-c425f00e1ce3 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Deploying instance in the account: test-6MG5KF 2013-11-14 19:27:31,205 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for virtual machine: 7e3de e7d-29ce-425c-95e4-e8f85143254c 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Fetching DATADISK details for instance: 7e3dee7d-29ce-425c-95e 4-e8f85143254c 2013-11-14 19:27:31,266 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Detaching the disk: DATA-32 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Datadisk DATA-32 detached! 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Attaching volume to instance: 9631c64f-a7ba-488b-951b-c425f00e 1ce3 2013-11-14 19:27:41,530 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Cleaning up the resources 2013-11-14 19:28:42,227 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Cleanup complete! == result.log == ok Thanks, Gaurav Aradhye
Re: Review Request 15569: CLOUDSTACK-5179: Fixed test script issue related to detach volume
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15569/#review28961 --- Commit e8629283000fbf7874309903da647e341854a7c6 in branch refs/heads/4.3 from Gaurav Aradhye [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e862928 ] CLOUDSTACK-5179: Fixed test script issue related to detach volume - ASF Subversion and Git Services On Nov. 15, 2013, 7:41 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15569/ --- (Updated Nov. 15, 2013, 7:41 a.m.) Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-5179 https://issues.apache.org/jira/browse/CLOUDSTACK-5179 Repository: cloudstack-git Description --- component.test_stopped_vm.TestDeployVM.test_08_deploy_attached_volume test case was failing while detaching volume because the volume was not listed properly. List volumes should accept the virtualmachineid parameter to correctly list the volume belonging to the virtual machine, otherwise the volume which we are detaching from virtual machine may belong to other virtual machine, in this case test case will fail. Diffs - test/integration/component/test_stopped_vm.py 4514bb7 Diff: https://reviews.apache.org/r/15569/diff/ Testing --- Tested locally on XenServer Basic Zone setup. test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) Test Deploy Virtual Machine with startVM=false and attach volume already attached to different machine ... == client.log == 2013-11-14 19:27:10,018 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for virtual machine: 9631c 64f-a7ba-488b-951b-c425f00e1ce3 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Deploying instance in the account: test-6MG5KF 2013-11-14 19:27:31,205 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for virtual machine: 7e3de e7d-29ce-425c-95e4-e8f85143254c 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Fetching DATADISK details for instance: 7e3dee7d-29ce-425c-95e 4-e8f85143254c 2013-11-14 19:27:31,266 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Detaching the disk: DATA-32 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Datadisk DATA-32 detached! 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Attaching volume to instance: 9631c64f-a7ba-488b-951b-c425f00e 1ce3 2013-11-14 19:27:41,530 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Cleaning up the resources 2013-11-14 19:28:42,227 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Cleanup complete! == result.log == ok Thanks, Gaurav Aradhye
Re: Review Request 15569: CLOUDSTACK-5179: Fixed test script issue related to detach volume
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15569/#review28962 --- Commit 8a1918dbe1c5fbbb60c21fa89d880a99e7b33bd6 in branch refs/heads/master from Gaurav Aradhye [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8a1918d ] CLOUDSTACK-5179: Fixed test script issue related to detach volume - ASF Subversion and Git Services On Nov. 15, 2013, 7:41 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15569/ --- (Updated Nov. 15, 2013, 7:41 a.m.) Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-5179 https://issues.apache.org/jira/browse/CLOUDSTACK-5179 Repository: cloudstack-git Description --- component.test_stopped_vm.TestDeployVM.test_08_deploy_attached_volume test case was failing while detaching volume because the volume was not listed properly. List volumes should accept the virtualmachineid parameter to correctly list the volume belonging to the virtual machine, otherwise the volume which we are detaching from virtual machine may belong to other virtual machine, in this case test case will fail. Diffs - test/integration/component/test_stopped_vm.py 4514bb7 Diff: https://reviews.apache.org/r/15569/diff/ Testing --- Tested locally on XenServer Basic Zone setup. test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) Test Deploy Virtual Machine with startVM=false and attach volume already attached to different machine ... == client.log == 2013-11-14 19:27:10,018 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for virtual machine: 9631c 64f-a7ba-488b-951b-c425f00e1ce3 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Deploying instance in the account: test-6MG5KF 2013-11-14 19:27:31,205 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for virtual machine: 7e3de e7d-29ce-425c-95e4-e8f85143254c 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Fetching DATADISK details for instance: 7e3dee7d-29ce-425c-95e 4-e8f85143254c 2013-11-14 19:27:31,266 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Detaching the disk: DATA-32 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Datadisk DATA-32 detached! 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Attaching volume to instance: 9631c64f-a7ba-488b-951b-c425f00e 1ce3 2013-11-14 19:27:41,530 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Cleaning up the resources 2013-11-14 19:28:42,227 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Cleanup complete! == result.log == ok Thanks, Gaurav Aradhye
Re: Review Request 15569: CLOUDSTACK-5179: Fixed test script issue related to detach volume
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15569/#review28963 --- Ship it! COmmitted to 4.2, 4.3 and master - Girish Shilamkar On Nov. 15, 2013, 7:41 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15569/ --- (Updated Nov. 15, 2013, 7:41 a.m.) Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-5179 https://issues.apache.org/jira/browse/CLOUDSTACK-5179 Repository: cloudstack-git Description --- component.test_stopped_vm.TestDeployVM.test_08_deploy_attached_volume test case was failing while detaching volume because the volume was not listed properly. List volumes should accept the virtualmachineid parameter to correctly list the volume belonging to the virtual machine, otherwise the volume which we are detaching from virtual machine may belong to other virtual machine, in this case test case will fail. Diffs - test/integration/component/test_stopped_vm.py 4514bb7 Diff: https://reviews.apache.org/r/15569/diff/ Testing --- Tested locally on XenServer Basic Zone setup. test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) Test Deploy Virtual Machine with startVM=false and attach volume already attached to different machine ... == client.log == 2013-11-14 19:27:10,018 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for virtual machine: 9631c 64f-a7ba-488b-951b-c425f00e1ce3 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Deploying instance in the account: test-6MG5KF 2013-11-14 19:27:31,205 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for virtual machine: 7e3de e7d-29ce-425c-95e4-e8f85143254c 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Fetching DATADISK details for instance: 7e3dee7d-29ce-425c-95e 4-e8f85143254c 2013-11-14 19:27:31,266 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Detaching the disk: DATA-32 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Datadisk DATA-32 detached! 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Attaching volume to instance: 9631c64f-a7ba-488b-951b-c425f00e 1ce3 2013-11-14 19:27:41,530 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Cleaning up the resources 2013-11-14 19:28:42,227 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Cleanup complete! == result.log == ok Thanks, Gaurav Aradhye
Review Request 15571: CLOUDSTACK-2243: base_image_updation - Adding tags to test cases
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15571/ --- Review request for cloudstack, Girish Shilamkar and Rayees Namathponnan. Bugs: CLOUDSTACK-2243 https://issues.apache.org/jira/browse/CLOUDSTACK-2243 Repository: cloudstack-git Description --- Added basic and advanced tags for the test cases. The test cases have been run on both the setups. Diffs - test/integration/component/test_base_image_updation.py 8a99350 Diff: https://reviews.apache.org/r/15571/diff/ Testing --- Tested locally on KVM advanced and XenServer basic setup. Thanks, Ashutosh Kelkar
Re: Review Request 15571: CLOUDSTACK-2243: base_image_updation - Adding tags to test cases
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15571/#review28964 --- Commit 09c0370d70721e07ff02cd907a2cab2cabc9ae5b in branch refs/heads/master from Girish Shilamkar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=09c0370 ] CLOUDSTACK-2243: base_image_updation - Adding tags to test cases - ASF Subversion and Git Services On Nov. 15, 2013, 11:09 a.m., Ashutosh Kelkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15571/ --- (Updated Nov. 15, 2013, 11:09 a.m.) Review request for cloudstack, Girish Shilamkar and Rayees Namathponnan. Bugs: CLOUDSTACK-2243 https://issues.apache.org/jira/browse/CLOUDSTACK-2243 Repository: cloudstack-git Description --- Added basic and advanced tags for the test cases. The test cases have been run on both the setups. Diffs - test/integration/component/test_base_image_updation.py 8a99350 Diff: https://reviews.apache.org/r/15571/diff/ Testing --- Tested locally on KVM advanced and XenServer basic setup. Thanks, Ashutosh Kelkar
Re: Review Request 15571: CLOUDSTACK-2243: base_image_updation - Adding tags to test cases
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15571/#review28965 --- Commit 729bf51070812db93611a732d2956207584fc3d2 in branch refs/heads/4.3 from Girish Shilamkar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=729bf51 ] CLOUDSTACK-2243: base_image_updation - Adding tags to test cases - ASF Subversion and Git Services On Nov. 15, 2013, 11:09 a.m., Ashutosh Kelkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15571/ --- (Updated Nov. 15, 2013, 11:09 a.m.) Review request for cloudstack, Girish Shilamkar and Rayees Namathponnan. Bugs: CLOUDSTACK-2243 https://issues.apache.org/jira/browse/CLOUDSTACK-2243 Repository: cloudstack-git Description --- Added basic and advanced tags for the test cases. The test cases have been run on both the setups. Diffs - test/integration/component/test_base_image_updation.py 8a99350 Diff: https://reviews.apache.org/r/15571/diff/ Testing --- Tested locally on KVM advanced and XenServer basic setup. Thanks, Ashutosh Kelkar
Re: Review Request 15571: CLOUDSTACK-2243: base_image_updation - Adding tags to test cases
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15571/#review28966 --- Commit ac9c4b0233070748e2a489df5005e65c8f890356 in branch refs/heads/4.2 from Girish Shilamkar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ac9c4b0 ] CLOUDSTACK-2243: base_image_updation - Adding tags to test cases - ASF Subversion and Git Services On Nov. 15, 2013, 11:09 a.m., Ashutosh Kelkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15571/ --- (Updated Nov. 15, 2013, 11:09 a.m.) Review request for cloudstack, Girish Shilamkar and Rayees Namathponnan. Bugs: CLOUDSTACK-2243 https://issues.apache.org/jira/browse/CLOUDSTACK-2243 Repository: cloudstack-git Description --- Added basic and advanced tags for the test cases. The test cases have been run on both the setups. Diffs - test/integration/component/test_base_image_updation.py 8a99350 Diff: https://reviews.apache.org/r/15571/diff/ Testing --- Tested locally on KVM advanced and XenServer basic setup. Thanks, Ashutosh Kelkar
Review Request 15572: LDAP import users changes
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15572/ --- Review request for cloudstack, Abhinandan Prateek and Ian Duffy. Bugs: CLOUDSTACK-4866 https://issues.apache.org/jira/browse/CLOUDSTACK-4866 Repository: cloudstack-git Description --- added LDAP group name label in add account wizard changed the parameter for domain in api importLdapUser from name to UUID improved error handling Diffs - client/WEB-INF/classes/resources/messages.properties 5885bd0 plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/command/LdapImportUsersCmd.java 063db0e plugins/user-authenticators/ldap/test/groovy/org/apache/cloudstack/ldap/LdapImportUsersCmdSpec.groovy 0455640 ui/dictionary.jsp 0ccfc23 ui/scripts/accountsWizard.js 70ef082 ui/scripts/docs.js a3151b1 ui/scripts/ui-custom/accountsWizard.js 358e29c Diff: https://reviews.apache.org/r/15572/diff/ Testing --- unit testing for all the java changes and manual testing for UI changes is done. Thanks, Rajani Karuturi
Re: [ASF4.2.1] Release Notes
On Fri, Nov 15, 2013 at 03:14:48AM -0500, Sebastien Goasguen wrote: I also would like to see the results of the test matrix for 4.2.1 running within jenkins.buildacloud.org. This http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against master and has been failing for a while. Bit behind this, I've started a fresh set of tests against 4.2 - will post the results once the job finishes. The default build now points to 4.2. Will switch it back to master post 4.2.1 announcement. http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-matrix-extended/224/ Powered by BigRock.com
Build failed in Jenkins: cloudstack-4.3-maven-build-noredist #21
See http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build-noredist/21/changes Changes: [w.zhou] remove duplicated scheduled tasks from VpcVirtualNetworkApplianceManagerImpl [jessicawang] CLOUDSTACK-999: hyper-V: UI Add Primary Storage when hypervisor type of selected cluster is Hyperv, populate Protocol dropdown with only one option SMB/cifs. [jessicawang] CLOUDSTACK-999: hyper-V: UI zone wizard Edit Traffic Type send hypervnetworklabel to addTrafficType API. [jessicawang] CLOUDSTACK-3154: UI zone detail remove VMware data center action if API returns error, stop spinning wheel and show returned error text in a pop up dialog. [nitin.mehta] CLOUDSTACK-5176: [girish] CLOUDSTACK-5166: Fixed test script issue related to egress [girish] CLOUDSTACK-5168: Fixed test script issue related to SSH [girish] CLOUDSTACK-5169: Egress rules - Improved assertion code [jayapal] CLOUDSTACK-5177: Fixed issue with running script from cron job [koushik] Revert CLOUDSTACK-5176: [koushik] CLOUDSTACK-4835: Update global configuration test cases failed in master Changes made in update/list configuration API to use ConfigDepot [milamber] Add 4.3.x messages.properties to Transifex config tool [milamber] Add 4.3 messages.properties L10N strings from Transifex to repo, branch 4.3 [girish] CLOUDSTACK-5148: Fix test_createSharedNetwork_projectSpecific [girish] CLOUDSTACK-5180: Increasing the timeout for uploading volume [girish] CLOUDSTACK-5147: Removing basic and sg tags from the test [girish] CLOUDSTACK-5179: Fixed test script issue related to detach [girish] CLOUDSTACK-2243: base_image_updation - Adding tags to test cases [girish] Fix marvin to refer to correct random_gen() function -- Started by upstream project cloudstack-4.3-maven-build build number 63 originally caused by: Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on rpmbuilder-2 in workspace http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build-noredist/ws/ Checkout:cloudstack-4.3-maven-build-noredist / http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build-noredist/ws/ - hudson.remoting.Channel@ec725c:rpmbuilder-2 Using strategy: Default Last Built Revision: Revision 2b83fa159371308ff6dc0dea688a2323b275e9d7 (origin/4.3) Cloning the remote Git repository Cloning repository https://git-wip-us.apache.org/repos/asf/cloudstack.git git --version git version 1.7.1 Fetching upstream changes from origin Commencing build of Revision 03fea0c4dfc9b1d927ded7c8f83f3148bf6c74ed (origin/4.3) Checking out Revision 03fea0c4dfc9b1d927ded7c8f83f3148bf6c74ed (origin/4.3) Deleting old artifacts from #19 [copy-to-slave] Copying 'cloudstack-nonoss-deps.tgz', excluding nothing, from 'file:/var/lib/jenkins/userContent/' on the master to 'http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build-noredist/ws/' on 'rpmbuilder-2'. [cloudstack-4.3-maven-build-noredist] $ /bin/sh -xe /tmp/hudson5586696149919246090.sh + echo 'Getting noredist patches' Getting noredist patches + which mvn /usr/bin/mvn + cd deps + tar -xvf ../cloudstack-nonoss-deps.tgz apputils.jar cloud-iControl.jar cloud-manageontap.jar cloud-netscaler.jar cloud-netscaler-sdx.jar libvirt-0.4.8.jar manageontap.jar vim25_51.jar vim25.jar vim.jar + bash -x install-non-oss.sh + mvn install:install-file -Dfile=cloud-iControl.jar -DgroupId=com.cloud.com.f5 -DartifactId=icontrol -Dversion=1.0 -Dpackaging=jar [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building Maven Stub Project (No POM) 1 [INFO] [INFO] [INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @ standalone-pom --- [INFO] Installing http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build-noredist/ws/deps/cloud-iControl.jar to /var/lib/jenkins/.m2/repository/com/cloud/com/f5/icontrol/1.0/icontrol-1.0.jar [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 4.942s [INFO] Finished at: Fri Nov 15 07:09:23 EST 2013 [INFO] Final Memory: 3M/34M [INFO] + mvn install:install-file -Dfile=cloud-netscaler-sdx.jar -DgroupId=com.cloud.com.citrix -DartifactId=netscaler-sdx -Dversion=1.0 -Dpackaging=jar [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building Maven Stub Project (No POM) 1 [INFO] [INFO] [INFO] --- maven-install-plugin:2.3.1:install-file
Re: [ASF4.2.1] Release Notes
To address the concern of RN we will not conclude the vote on RC (i.e. Not make a release) till the RN in general and upgrade instructions in particular are also of acceptable quality. As for other inconsistencies will work towards ironing those out. -abhi On 15/11/13 3:30 pm, Sebastien Goasguen run...@gmail.com wrote: On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: As a RM I had agreed to Sebatian's suggestion of fixing the docs specially the upgrade section of it. And off course doing a GA after the docs are fixed is on the cards. As for the list of fixed and known issues I was told that a filter is good enough but it should be pretty easy to get the listing in the docs itself. If someone has specific preferences it is easy to fix that. So it boils down to get opinion from folks on the following: 1. RC build, this does not contain docs. I have seen no complains or issues here. That's fine, but releasing something without the upgrade instructions committed is bad. Even if the release of such upgrade instructions happen after the release of the code. 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will think full listing is good or a query (instead of a URL?) I am in favor of consistency. Prior to 4.2 we listed all BUGS explicitly. We should keep doing that. 3. Upgrade instructions are known to be bad and we will have to wait at least till Wednesday to get these right. We have some volunteers already working on those and their effort is highly appreciated. Right, and since there is no rush, why not wait a bit till we can all look this with cool heads, double check the RN, bugs listing, upgrade instructions etc... -abhi On 15/11/13 2:50 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: So the -1 is because of the lack of rn and upgrade path docs, right, I think I proposed earlier this thread to release after the doc hackathon privided that. I wasn't really explicit about it I think as no one commented on this strategy. Would that be acceptable to you all (especially David and Sebastien)? I agree btw that docs must be available, but I don't think these have to be as stable as the release. We should allow for improving the docs on a release if needed. The net result of what I am proposing is that there will be a release and a docs rc. This is what the splitting of of the docs was about in my view,. Makes sense? If not, we should not try to make CCC Europe with 4.2.1. I think this is what the hurry is about Daan On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen run...@gmail.com wrote: I might be behind on the discussions here, but I will veto an RC that does not have list of bugs fixed and proper upgrade path documented (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the docs or not. Right now I see that the bugs fix list points to a jira filter. This is not consistent with the way it was done in prior releases (explicit listing) and in 4.2 (which pointed to the RN). We need consistency. What happens if someone changes this jira filter ? I also would like to see the results of the test matrix for 4.2.1 running within jenkins.buildacloud.org. This http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against master and has been failing for a while. PS: I did test it and did the usual smoke test so -1 (binding) at this time -sebastien On Nov 14, 2013, at 4:20 PM, Chip Childers chipchild...@apache.org wrote: Except that the separation only helps if it allows RC testing + voting during doc finalization. If we announce before docs, it hurts us. I'm against another announcement that goes out with the docs in poor shape. On Thu, Nov 14, 2013 at 3:44 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Unless there are objection to the RC, I would prefer to have it released and make the announcement sooner and showcase in collab conference. As Chip mentions docs were broken out separately anyway. Animesh On 14/11/13 8:12 pm, Sebastien Goasguen run...@gmail.com wrote: Anyway we can wait next week to release. quite a few of us will be together in Amsterdam, we can dedicate a hackathon session to 4.2.1 , make sure RN are good, upgrade path etcŠthen testŠ. I'd recommend keeping the vote open until then. -sebastien On Nov 14, 2013, at 5:57 AM, Radhika Puthiyetath radhika.puthiyet...@citrix.com wrote: Hi, The master has the most up-to-date RN for 4.2.1. From: Abhinandan Prateek Sent: Thursday, November 14, 2013 2:22 PM To: CloudStack Dev Cc: Radhika Puthiyetath Subject: Re: [ASF4.2.1] Release Notes It seems the upgrade section of release notes will require a review, probably followed by a revamp (?). Can we have some volunteers who are familiar with various upgrade paths comment on it ? Me and Radhika will try to consolidate those comments, snippets and fix the RN for 4.2.1.
Re: [ASF4.2.1] Release Notes
For listing down the fixed issues, since there are ~175 of these. I will list down some important fixes. Followed by the query to give a exhaustive list, is that acceptable ? For known issues will look at the 4.3/4.2 open tickets list down the important ones. This will go in the CHANGES in source repo and RN in code repo. -abhi On 15/11/13 5:54 pm, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: To address the concern of RN we will not conclude the vote on RC (i.e. Not make a release) till the RN in general and upgrade instructions in particular are also of acceptable quality. As for other inconsistencies will work towards ironing those out. -abhi On 15/11/13 3:30 pm, Sebastien Goasguen run...@gmail.com wrote: On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: As a RM I had agreed to Sebatian's suggestion of fixing the docs specially the upgrade section of it. And off course doing a GA after the docs are fixed is on the cards. As for the list of fixed and known issues I was told that a filter is good enough but it should be pretty easy to get the listing in the docs itself. If someone has specific preferences it is easy to fix that. So it boils down to get opinion from folks on the following: 1. RC build, this does not contain docs. I have seen no complains or issues here. That's fine, but releasing something without the upgrade instructions committed is bad. Even if the release of such upgrade instructions happen after the release of the code. 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will think full listing is good or a query (instead of a URL?) I am in favor of consistency. Prior to 4.2 we listed all BUGS explicitly. We should keep doing that. 3. Upgrade instructions are known to be bad and we will have to wait at least till Wednesday to get these right. We have some volunteers already working on those and their effort is highly appreciated. Right, and since there is no rush, why not wait a bit till we can all look this with cool heads, double check the RN, bugs listing, upgrade instructions etc... -abhi On 15/11/13 2:50 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: So the -1 is because of the lack of rn and upgrade path docs, right, I think I proposed earlier this thread to release after the doc hackathon privided that. I wasn't really explicit about it I think as no one commented on this strategy. Would that be acceptable to you all (especially David and Sebastien)? I agree btw that docs must be available, but I don't think these have to be as stable as the release. We should allow for improving the docs on a release if needed. The net result of what I am proposing is that there will be a release and a docs rc. This is what the splitting of of the docs was about in my view,. Makes sense? If not, we should not try to make CCC Europe with 4.2.1. I think this is what the hurry is about Daan On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen run...@gmail.com wrote: I might be behind on the discussions here, but I will veto an RC that does not have list of bugs fixed and proper upgrade path documented (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the docs or not. Right now I see that the bugs fix list points to a jira filter. This is not consistent with the way it was done in prior releases (explicit listing) and in 4.2 (which pointed to the RN). We need consistency. What happens if someone changes this jira filter ? I also would like to see the results of the test matrix for 4.2.1 running within jenkins.buildacloud.org. This http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against master and has been failing for a while. PS: I did test it and did the usual smoke test so -1 (binding) at this time -sebastien On Nov 14, 2013, at 4:20 PM, Chip Childers chipchild...@apache.org wrote: Except that the separation only helps if it allows RC testing + voting during doc finalization. If we announce before docs, it hurts us. I'm against another announcement that goes out with the docs in poor shape. On Thu, Nov 14, 2013 at 3:44 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Unless there are objection to the RC, I would prefer to have it released and make the announcement sooner and showcase in collab conference. As Chip mentions docs were broken out separately anyway. Animesh On 14/11/13 8:12 pm, Sebastien Goasguen run...@gmail.com wrote: Anyway we can wait next week to release. quite a few of us will be together in Amsterdam, we can dedicate a hackathon session to 4.2.1 , make sure RN are good, upgrade path etcŠthen testŠ. I'd recommend keeping the vote open until then. -sebastien On Nov 14, 2013, at 5:57 AM, Radhika Puthiyetath radhika.puthiyet...@citrix.com wrote: Hi, The master has the most up-to-date RN for 4.2.1. From: Abhinandan Prateek Sent:
Fwd: New Defects reported by Coverity Scan for cloudstack
Forward as the mail to the list is not setup yet. Sent from my iPhone Begin forwarded message: From: scan-ad...@coverity.com Date: 15 november 2013 13:47:59 CET Subject: New Defects reported by Coverity Scan for cloudstack Hi, Please find the latest report on new defect(s) introduced to cloudstack found with Coverity Scan. Defect(s) Reported-by: Coverity Scan Showing 7 of 7 defect(s) ** CID 1128965: Missing call to superclass (CALL_SUPER) /services/console-proxy-rdp/rdpconsole/src/main/java/streamer/MockSource.java: 49 in streamer.MockSource.handleEvent(streamer.Event, streamer.Direction)() ** CID 1128964: Missing call to superclass (CALL_SUPER) /services/console-proxy-rdp/rdpconsole/src/main/java/streamer/FakeSink.java: 45 in streamer.FakeSink.handleEvent(streamer.Event, streamer.Direction)() ** CID 1128966: Explicit null dereferenced (FORWARD_NULL) /server/src/com/cloud/network/NetworkServiceImpl.java: 3553 in com.cloud.network.NetworkServiceImpl.addTrafficTypeToPhysicalNetwork(java.lang.Long, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String)() ** CID 1128967: Unguarded write (GUARDED_BY_VIOLATION) /plugins/network-elements/palo-alto/src/com/cloud/network/resource/PaloAltoResource.java: 246 in com.cloud.network.resource.PaloAltoResource.configure(java.lang.String, java.util.Map)() ** CID 1128968: Using invalid iterator (INVALIDATE_ITERATOR) /services/console-proxy-rdp/rdpconsole/src/main/java/streamer/BaseElement.java: 149 in streamer.BaseElement.poll(boolean)() ** CID 1128969: Failure to restore non-local value (MISSING_RESTORE) /server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java: 1194 in com.cloud.network.lb.LoadBalancingRulesManagerImpl.assignCertToLoadBalancer(long, java.lang.Long)() ** CID 1128970: Dereference null return value (NULL_RETURNS) /services/console-proxy-rdp/rdpconsole/src/main/java/streamer/BaseElement.java: 414 in streamer.BaseElement.main(java.lang.String[])() To view the defects in Coverity Scan visit, http://scan.coverity.com To unsubscribe from the email notification for new defects, http://scan5.coverity.com/cgi-bin/unsubscribe.py
Re: [ASF4.2.1] Release Notes
Abihnandan, Why not include the output of the query instead of the query? I think this is what Sebastien means. A list of the important ones can still be prepended in more readable form afaic. Daan On Fri, Nov 15, 2013 at 1:32 PM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: For listing down the fixed issues, since there are ~175 of these. I will list down some important fixes. Followed by the query to give a exhaustive list, is that acceptable ? For known issues will look at the 4.3/4.2 open tickets list down the important ones. This will go in the CHANGES in source repo and RN in code repo. -abhi On 15/11/13 5:54 pm, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: To address the concern of RN we will not conclude the vote on RC (i.e. Not make a release) till the RN in general and upgrade instructions in particular are also of acceptable quality. As for other inconsistencies will work towards ironing those out. -abhi On 15/11/13 3:30 pm, Sebastien Goasguen run...@gmail.com wrote: On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: As a RM I had agreed to Sebatian's suggestion of fixing the docs specially the upgrade section of it. And off course doing a GA after the docs are fixed is on the cards. As for the list of fixed and known issues I was told that a filter is good enough but it should be pretty easy to get the listing in the docs itself. If someone has specific preferences it is easy to fix that. So it boils down to get opinion from folks on the following: 1. RC build, this does not contain docs. I have seen no complains or issues here. That's fine, but releasing something without the upgrade instructions committed is bad. Even if the release of such upgrade instructions happen after the release of the code. 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will think full listing is good or a query (instead of a URL?) I am in favor of consistency. Prior to 4.2 we listed all BUGS explicitly. We should keep doing that. 3. Upgrade instructions are known to be bad and we will have to wait at least till Wednesday to get these right. We have some volunteers already working on those and their effort is highly appreciated. Right, and since there is no rush, why not wait a bit till we can all look this with cool heads, double check the RN, bugs listing, upgrade instructions etc... -abhi On 15/11/13 2:50 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: So the -1 is because of the lack of rn and upgrade path docs, right, I think I proposed earlier this thread to release after the doc hackathon privided that. I wasn't really explicit about it I think as no one commented on this strategy. Would that be acceptable to you all (especially David and Sebastien)? I agree btw that docs must be available, but I don't think these have to be as stable as the release. We should allow for improving the docs on a release if needed. The net result of what I am proposing is that there will be a release and a docs rc. This is what the splitting of of the docs was about in my view,. Makes sense? If not, we should not try to make CCC Europe with 4.2.1. I think this is what the hurry is about Daan On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen run...@gmail.com wrote: I might be behind on the discussions here, but I will veto an RC that does not have list of bugs fixed and proper upgrade path documented (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the docs or not. Right now I see that the bugs fix list points to a jira filter. This is not consistent with the way it was done in prior releases (explicit listing) and in 4.2 (which pointed to the RN). We need consistency. What happens if someone changes this jira filter ? I also would like to see the results of the test matrix for 4.2.1 running within jenkins.buildacloud.org. This http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against master and has been failing for a while. PS: I did test it and did the usual smoke test so -1 (binding) at this time -sebastien On Nov 14, 2013, at 4:20 PM, Chip Childers chipchild...@apache.org wrote: Except that the separation only helps if it allows RC testing + voting during doc finalization. If we announce before docs, it hurts us. I'm against another announcement that goes out with the docs in poor shape. On Thu, Nov 14, 2013 at 3:44 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Unless there are objection to the RC, I would prefer to have it released and make the announcement sooner and showcase in collab conference. As Chip mentions docs were broken out separately anyway. Animesh On 14/11/13 8:12 pm, Sebastien Goasguen run...@gmail.com wrote: Anyway we can wait next week to release. quite a few of us will be together in Amsterdam, we can dedicate a hackathon session to 4.2.1 , make sure RN are good, upgrade path
Re: [ASF4.2.1] Release Notes
On Nov 15, 2013, at 7:32 AM, Abhinandan Prateek abhinandan.prat...@citrix.com
wrote:
For listing down the fixed issues, since there are ~175 of these. I will
list down some important fixes.
Followed by the query to give a exhaustive list, is that acceptable ?
I know jira has an api, so you could easily query jira and automatically write
the list of fixed bugs in the CHANGES file.
we should automate this:
import requests
import pprint
r=requests.get('https://issues.apache.org/jira/rest/api/2/filter/12325707')
r=requests.get('https://issues.apache.org/jira/rest/api/2/search?jql=project+%3D+CLOUDSTACK+AND+type+%3D+Bug+AND+affectedVersion+in+(%224.2.0%22,+%224.2%22)+AND+fixVersion+%3D+%224.2.1%22+AND+resolution+!%3D+%22%5C%22Unresolved%5C%22%22+ORDER+BY+created+DESC,+priority+DESC,+key+ASC')
pprint.pprint(r.json)
The ideal process is really that when a bug gets resolved, the person who
committed the patch to solve the bug should also update the CHANGES file.
For known issues will look at the 4.3/4.2 open tickets list down the
important ones.
This will go in the CHANGES in source repo and RN in code repo.
-abhi
On 15/11/13 5:54 pm, Abhinandan Prateek abhinandan.prat...@citrix.com
wrote:
To address the concern of RN we will not conclude the vote on RC (i.e. Not
make a release)
till the RN in general and upgrade instructions in particular are also of
acceptable quality.
As for other inconsistencies will work towards ironing those out.
-abhi
On 15/11/13 3:30 pm, Sebastien Goasguen run...@gmail.com wrote:
On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek
abhinandan.prat...@citrix.com wrote:
As a RM I had agreed to Sebatian's suggestion of fixing the docs
specially
the upgrade section of it.
And off course doing a GA after the docs are fixed is on the cards.
As for the list of fixed and known issues I was told that a filter is
good
enough but it should be pretty easy to get the listing in the docs
itself.
If someone has specific preferences it is easy to fix that.
So it boils down to get opinion from folks on the following:
1. RC build, this does not contain docs. I have seen no complains or
issues here.
That's fine, but releasing something without the upgrade instructions
committed is bad.
Even if the release of such upgrade instructions happen after the release
of the code.
2. Putting a full listing of bug fixes in RN Vs a filter. Even I will
think full listing is good or a query (instead of a URL?)
I am in favor of consistency. Prior to 4.2 we listed all BUGS explicitly.
We should keep doing that.
3. Upgrade instructions are known to be bad and we will have to wait at
least till Wednesday to get these right.
We have some volunteers already working on those and their effort is
highly appreciated.
Right, and since there is no rush, why not wait a bit till we can all
look this with cool heads, double check the RN, bugs listing, upgrade
instructions etc...
-abhi
On 15/11/13 2:50 pm, Daan Hoogland daan.hoogl...@gmail.com wrote:
So the -1 is because of the lack of rn and upgrade path docs, right, I
think I proposed earlier this thread to release after the doc
hackathon privided that. I wasn't really explicit about it I think as
no one commented on this strategy. Would that be acceptable to you all
(especially David and Sebastien)?
I agree btw that docs must be available, but I don't think these have
to be as stable as the release. We should allow for improving the docs
on a release if needed. The net result of what I am proposing is that
there will be a release and a docs rc. This is what the splitting of
of the docs was about in my view,. Makes sense?
If not, we should not try to make CCC Europe with 4.2.1. I think this
is what the hurry is about
Daan
On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen run...@gmail.com
wrote:
I might be behind on the discussions here, but I will veto an RC that
does not have list of bugs fixed and proper upgrade path documented
(minimum of a fix from 4.2.0 upgrade docs). Separate repo of the docs
or
not.
Right now I see that the bugs fix list points to a jira filter. This
is
not consistent with the way it was done in prior releases (explicit
listing) and in 4.2 (which pointed to the RN). We need consistency.
What
happens if someone changes this jira filter ?
I also would like to see the results of the test matrix for 4.2.1
running within jenkins.buildacloud.org. This
http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against
master
and has been failing for a while.
PS: I did test it and did the usual smoke test
so -1 (binding) at this time
-sebastien
On Nov 14, 2013, at 4:20 PM, Chip Childers chipchild...@apache.org
wrote:
Except that the separation only helps if it allows RC testing +
voting
during doc finalization. If we announce before docs, it hurts us.
I'm against another announcement that goes
Re: [ASF4.2.1] Release Notes
Ok I will go that way till someone says that listing 175 tickets in CHANGES file will needlessly clutter it. Can we focus the list to blockers and criticals at least ? -abhi On 15/11/13 6:34 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: Abihnandan, Why not include the output of the query instead of the query? I think this is what Sebastien means. A list of the important ones can still be prepended in more readable form afaic. Daan On Fri, Nov 15, 2013 at 1:32 PM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: For listing down the fixed issues, since there are ~175 of these. I will list down some important fixes. Followed by the query to give a exhaustive list, is that acceptable ? For known issues will look at the 4.3/4.2 open tickets list down the important ones. This will go in the CHANGES in source repo and RN in code repo. -abhi On 15/11/13 5:54 pm, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: To address the concern of RN we will not conclude the vote on RC (i.e. Not make a release) till the RN in general and upgrade instructions in particular are also of acceptable quality. As for other inconsistencies will work towards ironing those out. -abhi On 15/11/13 3:30 pm, Sebastien Goasguen run...@gmail.com wrote: On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: As a RM I had agreed to Sebatian's suggestion of fixing the docs specially the upgrade section of it. And off course doing a GA after the docs are fixed is on the cards. As for the list of fixed and known issues I was told that a filter is good enough but it should be pretty easy to get the listing in the docs itself. If someone has specific preferences it is easy to fix that. So it boils down to get opinion from folks on the following: 1. RC build, this does not contain docs. I have seen no complains or issues here. That's fine, but releasing something without the upgrade instructions committed is bad. Even if the release of such upgrade instructions happen after the release of the code. 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will think full listing is good or a query (instead of a URL?) I am in favor of consistency. Prior to 4.2 we listed all BUGS explicitly. We should keep doing that. 3. Upgrade instructions are known to be bad and we will have to wait at least till Wednesday to get these right. We have some volunteers already working on those and their effort is highly appreciated. Right, and since there is no rush, why not wait a bit till we can all look this with cool heads, double check the RN, bugs listing, upgrade instructions etc... -abhi On 15/11/13 2:50 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: So the -1 is because of the lack of rn and upgrade path docs, right, I think I proposed earlier this thread to release after the doc hackathon privided that. I wasn't really explicit about it I think as no one commented on this strategy. Would that be acceptable to you all (especially David and Sebastien)? I agree btw that docs must be available, but I don't think these have to be as stable as the release. We should allow for improving the docs on a release if needed. The net result of what I am proposing is that there will be a release and a docs rc. This is what the splitting of of the docs was about in my view,. Makes sense? If not, we should not try to make CCC Europe with 4.2.1. I think this is what the hurry is about Daan On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen run...@gmail.com wrote: I might be behind on the discussions here, but I will veto an RC that does not have list of bugs fixed and proper upgrade path documented (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the docs or not. Right now I see that the bugs fix list points to a jira filter. This is not consistent with the way it was done in prior releases (explicit listing) and in 4.2 (which pointed to the RN). We need consistency. What happens if someone changes this jira filter ? I also would like to see the results of the test matrix for 4.2.1 running within jenkins.buildacloud.org. This http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against master and has been failing for a while. PS: I did test it and did the usual smoke test so -1 (binding) at this time -sebastien On Nov 14, 2013, at 4:20 PM, Chip Childers chipchild...@apache.org wrote: Except that the separation only helps if it allows RC testing + voting during doc finalization. If we announce before docs, it hurts us. I'm against another announcement that goes out with the docs in poor shape. On Thu, Nov 14, 2013 at 3:44 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Unless there are objection to the RC, I would prefer to have it released and make the announcement sooner and showcase in collab conference. As Chip mentions docs were broken out separately anyway. Animesh
Unable to edit https://cwiki.apache.org/confluence/display/CLOUDSTACK/CCC+Europe#
Hi, Looking to add hackathon entry over here https://cwiki.apache.org/confluence/display/CLOUDSTACK/CCC+Europe# But unable to do so as it seems the wiki edit access permissions are not there. Can you somebody give edit access to cwiki for user 'sateeshc' ? Regards, Sateesh
Re: [ASF4.2.1] Release Notes
Ok, will make a exhaustive listing and see if it can be automated for
future releases.
On 15/11/13 6:41 pm, Sebastien Goasguen run...@gmail.com wrote:
On Nov 15, 2013, at 7:32 AM, Abhinandan Prateek
abhinandan.prat...@citrix.com wrote:
For listing down the fixed issues, since there are ~175 of these. I will
list down some important fixes.
Followed by the query to give a exhaustive list, is that acceptable ?
I know jira has an api, so you could easily query jira and automatically
write the list of fixed bugs in the CHANGES file.
we should automate this:
import requests
import pprint
r=requests.get('https://issues.apache.org/jira/rest/api/2/filter/123257
07')
r=requests.get('https://issues.apache.org/jira/rest/api/2/search?jql=pr
oject+%3D+CLOUDSTACK+AND+type+%3D+Bug+AND+affectedVersion+in+(%224.2.0%
22,+%224.2%22)+AND+fixVersion+%3D+%224.2.1%22+AND+resolution+!%3D+%22%5
C%22Unresolved%5C%22%22+ORDER+BY+created+DESC,+priority+DESC,+key+ASC')
pprint.pprint(r.json)
The ideal process is really that when a bug gets resolved, the person who
committed the patch to solve the bug should also update the CHANGES file.
For known issues will look at the 4.3/4.2 open tickets list down the
important ones.
This will go in the CHANGES in source repo and RN in code repo.
-abhi
On 15/11/13 5:54 pm, Abhinandan Prateek
abhinandan.prat...@citrix.com
wrote:
To address the concern of RN we will not conclude the vote on RC (i.e.
Not
make a release)
till the RN in general and upgrade instructions in particular are also
of
acceptable quality.
As for other inconsistencies will work towards ironing those out.
-abhi
On 15/11/13 3:30 pm, Sebastien Goasguen run...@gmail.com wrote:
On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek
abhinandan.prat...@citrix.com wrote:
As a RM I had agreed to Sebatian's suggestion of fixing the docs
specially
the upgrade section of it.
And off course doing a GA after the docs are fixed is on the cards.
As for the list of fixed and known issues I was told that a filter is
good
enough but it should be pretty easy to get the listing in the docs
itself.
If someone has specific preferences it is easy to fix that.
So it boils down to get opinion from folks on the following:
1. RC build, this does not contain docs. I have seen no complains or
issues here.
That's fine, but releasing something without the upgrade instructions
committed is bad.
Even if the release of such upgrade instructions happen after the
release
of the code.
2. Putting a full listing of bug fixes in RN Vs a filter. Even I will
think full listing is good or a query (instead of a URL?)
I am in favor of consistency. Prior to 4.2 we listed all BUGS
explicitly.
We should keep doing that.
3. Upgrade instructions are known to be bad and we will have to wait
at
least till Wednesday to get these right.
We have some volunteers already working on those and their effort is
highly appreciated.
Right, and since there is no rush, why not wait a bit till we can all
look this with cool heads, double check the RN, bugs listing, upgrade
instructions etc...
-abhi
On 15/11/13 2:50 pm, Daan Hoogland daan.hoogl...@gmail.com wrote:
So the -1 is because of the lack of rn and upgrade path docs,
right, I
think I proposed earlier this thread to release after the doc
hackathon privided that. I wasn't really explicit about it I think
as
no one commented on this strategy. Would that be acceptable to you
all
(especially David and Sebastien)?
I agree btw that docs must be available, but I don't think these
have
to be as stable as the release. We should allow for improving the
docs
on a release if needed. The net result of what I am proposing is
that
there will be a release and a docs rc. This is what the splitting of
of the docs was about in my view,. Makes sense?
If not, we should not try to make CCC Europe with 4.2.1. I think
this
is what the hurry is about
Daan
On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen
run...@gmail.com
wrote:
I might be behind on the discussions here, but I will veto an RC
that
does not have list of bugs fixed and proper upgrade path documented
(minimum of a fix from 4.2.0 upgrade docs). Separate repo of the
docs
or
not.
Right now I see that the bugs fix list points to a jira filter.
This
is
not consistent with the way it was done in prior releases (explicit
listing) and in 4.2 (which pointed to the RN). We need consistency.
What
happens if someone changes this jira filter ?
I also would like to see the results of the test matrix for 4.2.1
running within jenkins.buildacloud.org. This
http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against
master
and has been failing for a while.
PS: I did test it and did the usual smoke test
so -1 (binding) at this time
-sebastien
On Nov 14, 2013, at 4:20 PM, Chip Childers
chipchild...@apache.org
wrote:
Except that the separation only
Review Request 15578: support to enable custom root disk size when using a template to deploy vm on xenserver.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15578/ --- Review request for cloudstack and Koushik Das. Bugs: CLOUDSTACK-4738 https://issues.apache.org/jira/browse/CLOUDSTACK-4738 Repository: cloudstack-git Description --- support to enable custom root disk size when using a template to deploy vm on xenserver. Diffs - engine/storage/datamotion/src/org/apache/cloudstack/storage/motion/AncientDataMotionStrategy.java 67cc324 plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServerStorageProcessor.java 5a19aee Diff: https://reviews.apache.org/r/15578/diff/ Testing --- Tested on master. Thanks, bharat kumar
Re: Review Request 15489: Adding protocol parameter to loadbalancer response
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15489/#review28968 --- Syed I dont think you added 'protocol' to createLoadBalancerRule. There should not be 'protocol' in the LoadBalancerContainer? - Murali Reddy On Nov. 13, 2013, 6:08 p.m., Syed Ahmed wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15489/ --- (Updated Nov. 13, 2013, 6:08 p.m.) Review request for cloudstack, Alena Prokharchyk and Murali Reddy. Repository: cloudstack-git Description --- Adding protocol parameter to Loadbalancer Response Diffs - api/src/com/cloud/network/rules/LoadBalancer.java e6dadca api/src/com/cloud/network/rules/LoadBalancerContainer.java 9d5ea59 api/src/org/apache/cloudstack/api/response/LoadBalancerResponse.java 0f18097 engine/schema/src/org/apache/cloudstack/lb/ApplicationLoadBalancerRuleVO.java 37a747e server/src/com/cloud/api/ApiResponseHelper.java 903c485 Diff: https://reviews.apache.org/r/15489/diff/ Testing --- Thanks, Syed Ahmed
Re: CloudStack.next
Hi, this is a bit of a brain dump: I tend to see different types of buckets: 1-Processes Involves getting better as a community in terms of release, bug fixing, committing code, documentation and user support. Some of these have already been discussed partially but we need to come to consensus and act. For example: -we should have no unanswered questions on the lists. Anyway to have an official volunteer support team ? With a 24/7 twilio number on the site that rings up someone out there :) ? -we should catch up on bug fixing (and great job on 4.2.1 btw) -when we commit we cannot break master, and I also would argue for committing docs when it's a new feature, right now master is a catch all, instead of a super stable, high quality branch. -we need much better docs -we need to define standards for releases: RN, changes file, upgrade paths, testing etc. -our testing infra needs to get much better, continuous testing for all branches, testing on commits etc…maybe we should find a way to get help from cloudbees to get us on the right tracks. Overall we need to be able to release at any instant with confidence. -no feature should be un-documented and/or un-tested. for instance: there was a recent complaint about lack of F5 documentation, and right now I have no clue who is testing the F5 integration. 2-Ecosystem We need to build up the ecosystem around cloudstack and advertize it. We integrate with almost everything out there, yet people don't know it. I wish that: 2.1 we would improve on support in existing software: all configuration mgt systems, main cloud libraries, PaaS etc... 2.2 work with everyone in that ecosystem to advertize and demo CloudStack integration 2.3 work on extending that ecosystem (e.g Docker support, Cloudfoundry, Mesos, Spark, OpenDaylight controller) some of it is just a matter of writing a tutorial, some of it there is actual coding involved. 2.4 restart effort on AWS: as mentioned IAM is needed but there is more, we need to catch with euca and integrate with netflixOSS software. Bring EMR, ELB, CloudWatch etc…I have plans to work on this and hopefully propose a standalone AWS-ACS bridge with extended services. 3-Code (caveat, I am not a java developer) I still would love to see a lot of cleanup and review. For example I believe the KVM agent uses some python scripts in cloud-cli, those don't use Marvin. We should try to consolidate these. There is code in the tree that is unused, we should clean it up. In the UI when you add a cluster we still list 'OVM' yet it's broken, we need to clean. OStypes in image creation, we need to clean up... Packaging and mavenization, we should finish that up and really make it super strong. We need to call out to maven and package experts for a hand. We had a small thread on KVM agent and we will have a talk at the hackathon, here I will pick on Xen: We need much better support for Xen_Project without using xapi (the xapi install on XP is a pain), without xapi we could easily have ARM / Ceph support… Overall I would like to see a strong core emerge with clean code separation with UI, DB abstraction, backend drivers and plugins. ( A bit pie in the sky, but a non java guy should be able to keep the core and replace/add any other component, plug and play) Biggest item is probably a software architecture blueprint, right now we don't have that. No UML diagram, no sequence diagram, most people don't know how cloudstack actually works. -seb (I will invest time on the ecosystem bucket) On Nov 14, 2013, at 10:18 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: +1 to IAM. An Autoscale service independent of Netscaler. I'd like to see the built-in GRE controller fully fleshed out as a distributed/cross-AZ virtual network provider. Make it the out-of-the-box virtual network provider instead of VLAN. Easier service vm insertion into virtual networks. Better fidelity with AWS VPC APIs On 11/12/13 6:09 PM, Simon Murphy simon.mur...@vifx.co.nz wrote: As a CloudStack user, here are the ares that I feel need attention: - improved IAM and implementation of a full RBAC security model. This is hurting us right now. - improved VM import functionality (ie bulk import of VM's and import of running VM's from existing vSphere clusters) - improved backup functionality and integration with 3rd party tools - HA for VPC routers Cheers, Simon Murphy Solutions Architect ViFX | Cloud Infrastructure Level 7, 57 Fort Street, Auckland, New Zealand 1010 PO Box 106700, Auckland, New Zealand 1143 M +64 21 285 4519 | S simon_a_murphy www.vifx.co.nz http://www.vifx.co.nz/ follow us on twitter https://twitter.com/ViFX Auckland | Wellington | Christchurch experience. expertise. execution. This email and any files transmitted with it are confidential, without prejudice and may contain information that is subject to legal privilege. It is intended solely for the use of the individual/s to whom
Re: [ASF4.2.1] Release Notes
On Nov 15, 2013, at 8:19 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: Ok I will go that way till someone says that listing 175 tickets in CHANGES file will needlessly clutter it. Can we focus the list to blockers and criticals at least ? How was it done for 4.1.1 ? all bugs or just blockers/citricals ? I know listing 175 tickets seems like a lot, I am just arguing for consistency and automation. -abhi On 15/11/13 6:34 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: Abihnandan, Why not include the output of the query instead of the query? I think this is what Sebastien means. A list of the important ones can still be prepended in more readable form afaic. Daan On Fri, Nov 15, 2013 at 1:32 PM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: For listing down the fixed issues, since there are ~175 of these. I will list down some important fixes. Followed by the query to give a exhaustive list, is that acceptable ? For known issues will look at the 4.3/4.2 open tickets list down the important ones. This will go in the CHANGES in source repo and RN in code repo. -abhi On 15/11/13 5:54 pm, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: To address the concern of RN we will not conclude the vote on RC (i.e. Not make a release) till the RN in general and upgrade instructions in particular are also of acceptable quality. As for other inconsistencies will work towards ironing those out. -abhi On 15/11/13 3:30 pm, Sebastien Goasguen run...@gmail.com wrote: On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: As a RM I had agreed to Sebatian's suggestion of fixing the docs specially the upgrade section of it. And off course doing a GA after the docs are fixed is on the cards. As for the list of fixed and known issues I was told that a filter is good enough but it should be pretty easy to get the listing in the docs itself. If someone has specific preferences it is easy to fix that. So it boils down to get opinion from folks on the following: 1. RC build, this does not contain docs. I have seen no complains or issues here. That's fine, but releasing something without the upgrade instructions committed is bad. Even if the release of such upgrade instructions happen after the release of the code. 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will think full listing is good or a query (instead of a URL?) I am in favor of consistency. Prior to 4.2 we listed all BUGS explicitly. We should keep doing that. 3. Upgrade instructions are known to be bad and we will have to wait at least till Wednesday to get these right. We have some volunteers already working on those and their effort is highly appreciated. Right, and since there is no rush, why not wait a bit till we can all look this with cool heads, double check the RN, bugs listing, upgrade instructions etc... -abhi On 15/11/13 2:50 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: So the -1 is because of the lack of rn and upgrade path docs, right, I think I proposed earlier this thread to release after the doc hackathon privided that. I wasn't really explicit about it I think as no one commented on this strategy. Would that be acceptable to you all (especially David and Sebastien)? I agree btw that docs must be available, but I don't think these have to be as stable as the release. We should allow for improving the docs on a release if needed. The net result of what I am proposing is that there will be a release and a docs rc. This is what the splitting of of the docs was about in my view,. Makes sense? If not, we should not try to make CCC Europe with 4.2.1. I think this is what the hurry is about Daan On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen run...@gmail.com wrote: I might be behind on the discussions here, but I will veto an RC that does not have list of bugs fixed and proper upgrade path documented (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the docs or not. Right now I see that the bugs fix list points to a jira filter. This is not consistent with the way it was done in prior releases (explicit listing) and in 4.2 (which pointed to the RN). We need consistency. What happens if someone changes this jira filter ? I also would like to see the results of the test matrix for 4.2.1 running within jenkins.buildacloud.org. This http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against master and has been failing for a while. PS: I did test it and did the usual smoke test so -1 (binding) at this time -sebastien On Nov 14, 2013, at 4:20 PM, Chip Childers chipchild...@apache.org wrote: Except that the separation only helps if it allows RC testing + voting during doc finalization. If we announce before docs, it hurts us. I'm against another
Re: [ASF4.2.1] Release Notes
IMO, we should kill the CHAGES file and just get the release notes document under control. I'm fine if Changes is in bad shape for this release personally, as long as the release notes are accurate. Another thought to remind folks about in this thread: Changes to the cloudstack.git repo's 4.2 branch that we want to be in the 4.2.1 release will cause a re-spin and re-vote. Changes to the documentation repo have nothing to do with the release vote, except that we (as a community) seem to agree that our docs should be at least updated and pushed to the website *before* announcing 4.2.1. Make sense? On Fri, Nov 15, 2013 at 8:19 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: Ok I will go that way till someone says that listing 175 tickets in CHANGES file will needlessly clutter it. Can we focus the list to blockers and criticals at least ? -abhi On 15/11/13 6:34 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: Abihnandan, Why not include the output of the query instead of the query? I think this is what Sebastien means. A list of the important ones can still be prepended in more readable form afaic. Daan On Fri, Nov 15, 2013 at 1:32 PM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: For listing down the fixed issues, since there are ~175 of these. I will list down some important fixes. Followed by the query to give a exhaustive list, is that acceptable ? For known issues will look at the 4.3/4.2 open tickets list down the important ones. This will go in the CHANGES in source repo and RN in code repo. -abhi On 15/11/13 5:54 pm, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: To address the concern of RN we will not conclude the vote on RC (i.e. Not make a release) till the RN in general and upgrade instructions in particular are also of acceptable quality. As for other inconsistencies will work towards ironing those out. -abhi On 15/11/13 3:30 pm, Sebastien Goasguen run...@gmail.com wrote: On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: As a RM I had agreed to Sebatian's suggestion of fixing the docs specially the upgrade section of it. And off course doing a GA after the docs are fixed is on the cards. As for the list of fixed and known issues I was told that a filter is good enough but it should be pretty easy to get the listing in the docs itself. If someone has specific preferences it is easy to fix that. So it boils down to get opinion from folks on the following: 1. RC build, this does not contain docs. I have seen no complains or issues here. That's fine, but releasing something without the upgrade instructions committed is bad. Even if the release of such upgrade instructions happen after the release of the code. 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will think full listing is good or a query (instead of a URL?) I am in favor of consistency. Prior to 4.2 we listed all BUGS explicitly. We should keep doing that. 3. Upgrade instructions are known to be bad and we will have to wait at least till Wednesday to get these right. We have some volunteers already working on those and their effort is highly appreciated. Right, and since there is no rush, why not wait a bit till we can all look this with cool heads, double check the RN, bugs listing, upgrade instructions etc... -abhi On 15/11/13 2:50 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: So the -1 is because of the lack of rn and upgrade path docs, right, I think I proposed earlier this thread to release after the doc hackathon privided that. I wasn't really explicit about it I think as no one commented on this strategy. Would that be acceptable to you all (especially David and Sebastien)? I agree btw that docs must be available, but I don't think these have to be as stable as the release. We should allow for improving the docs on a release if needed. The net result of what I am proposing is that there will be a release and a docs rc. This is what the splitting of of the docs was about in my view,. Makes sense? If not, we should not try to make CCC Europe with 4.2.1. I think this is what the hurry is about Daan On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen run...@gmail.com wrote: I might be behind on the discussions here, but I will veto an RC that does not have list of bugs fixed and proper upgrade path documented (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the docs or not. Right now I see that the bugs fix list points to a jira filter. This is not consistent with the way it was done in prior releases (explicit listing) and in 4.2 (which pointed to the RN). We need consistency. What happens if someone changes this jira filter ? I also would like to see the results of the test matrix for 4.2.1 running within jenkins.buildacloud.org. This http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against master and has been failing for
Re: [ASF4.2.1] Release Notes
×2 mobile biligual spell checker used Op 15 nov. 2013 15:27 schreef Chip Childers chipchild...@apache.org: IMO, we should kill the CHAGES file and just get the release notes document under control. I'm fine if Changes is in bad shape for this release personally, as long as the release notes are accurate. Another thought to remind folks about in this thread: Changes to the cloudstack.git repo's 4.2 branch that we want to be in the 4.2.1 release will cause a re-spin and re-vote. Changes to the documentation repo have nothing to do with the release vote, except that we (as a community) seem to agree that our docs should be at least updated and pushed to the website *before* announcing 4.2.1. Make sense? On Fri, Nov 15, 2013 at 8:19 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: Ok I will go that way till someone says that listing 175 tickets in CHANGES file will needlessly clutter it. Can we focus the list to blockers and criticals at least ? -abhi On 15/11/13 6:34 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: Abihnandan, Why not include the output of the query instead of the query? I think this is what Sebastien means. A list of the important ones can still be prepended in more readable form afaic. Daan On Fri, Nov 15, 2013 at 1:32 PM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: For listing down the fixed issues, since there are ~175 of these. I will list down some important fixes. Followed by the query to give a exhaustive list, is that acceptable ? For known issues will look at the 4.3/4.2 open tickets list down the important ones. This will go in the CHANGES in source repo and RN in code repo. -abhi On 15/11/13 5:54 pm, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: To address the concern of RN we will not conclude the vote on RC (i.e. Not make a release) till the RN in general and upgrade instructions in particular are also of acceptable quality. As for other inconsistencies will work towards ironing those out. -abhi On 15/11/13 3:30 pm, Sebastien Goasguen run...@gmail.com wrote: On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: As a RM I had agreed to Sebatian's suggestion of fixing the docs specially the upgrade section of it. And off course doing a GA after the docs are fixed is on the cards. As for the list of fixed and known issues I was told that a filter is good enough but it should be pretty easy to get the listing in the docs itself. If someone has specific preferences it is easy to fix that. So it boils down to get opinion from folks on the following: 1. RC build, this does not contain docs. I have seen no complains or issues here. That's fine, but releasing something without the upgrade instructions committed is bad. Even if the release of such upgrade instructions happen after the release of the code. 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will think full listing is good or a query (instead of a URL?) I am in favor of consistency. Prior to 4.2 we listed all BUGS explicitly. We should keep doing that. 3. Upgrade instructions are known to be bad and we will have to wait at least till Wednesday to get these right. We have some volunteers already working on those and their effort is highly appreciated. Right, and since there is no rush, why not wait a bit till we can all look this with cool heads, double check the RN, bugs listing, upgrade instructions etc... -abhi On 15/11/13 2:50 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: So the -1 is because of the lack of rn and upgrade path docs, right, I think I proposed earlier this thread to release after the doc hackathon privided that. I wasn't really explicit about it I think as no one commented on this strategy. Would that be acceptable to you all (especially David and Sebastien)? I agree btw that docs must be available, but I don't think these have to be as stable as the release. We should allow for improving the docs on a release if needed. The net result of what I am proposing is that there will be a release and a docs rc. This is what the splitting of of the docs was about in my view,. Makes sense? If not, we should not try to make CCC Europe with 4.2.1. I think this is what the hurry is about Daan On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen run...@gmail.com wrote: I might be behind on the discussions here, but I will veto an RC that does not have list of bugs fixed and proper upgrade path documented (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the docs or not. Right now I see that the bugs fix list points to a jira filter. This is not consistent with the way it was done in prior releases (explicit listing) and in 4.2 (which pointed to the RN). We need
Re: [ASF4.2.1] Release Notes
Yes - it's hard to maintain, and it's yet another place to point people to. Let's deprecate it in favor of decent RN. --David On Fri, Nov 15, 2013 at 9:27 AM, Chip Childers chipchild...@apache.org wrote: IMO, we should kill the CHAGES file and just get the release notes document under control. I'm fine if Changes is in bad shape for this release personally, as long as the release notes are accurate. Another thought to remind folks about in this thread: Changes to the cloudstack.git repo's 4.2 branch that we want to be in the 4.2.1 release will cause a re-spin and re-vote. Changes to the documentation repo have nothing to do with the release vote, except that we (as a community) seem to agree that our docs should be at least updated and pushed to the website *before* announcing 4.2.1. Make sense? On Fri, Nov 15, 2013 at 8:19 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: Ok I will go that way till someone says that listing 175 tickets in CHANGES file will needlessly clutter it. Can we focus the list to blockers and criticals at least ? -abhi On 15/11/13 6:34 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: Abihnandan, Why not include the output of the query instead of the query? I think this is what Sebastien means. A list of the important ones can still be prepended in more readable form afaic. Daan On Fri, Nov 15, 2013 at 1:32 PM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: For listing down the fixed issues, since there are ~175 of these. I will list down some important fixes. Followed by the query to give a exhaustive list, is that acceptable ? For known issues will look at the 4.3/4.2 open tickets list down the important ones. This will go in the CHANGES in source repo and RN in code repo. -abhi On 15/11/13 5:54 pm, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: To address the concern of RN we will not conclude the vote on RC (i.e. Not make a release) till the RN in general and upgrade instructions in particular are also of acceptable quality. As for other inconsistencies will work towards ironing those out. -abhi On 15/11/13 3:30 pm, Sebastien Goasguen run...@gmail.com wrote: On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: As a RM I had agreed to Sebatian's suggestion of fixing the docs specially the upgrade section of it. And off course doing a GA after the docs are fixed is on the cards. As for the list of fixed and known issues I was told that a filter is good enough but it should be pretty easy to get the listing in the docs itself. If someone has specific preferences it is easy to fix that. So it boils down to get opinion from folks on the following: 1. RC build, this does not contain docs. I have seen no complains or issues here. That's fine, but releasing something without the upgrade instructions committed is bad. Even if the release of such upgrade instructions happen after the release of the code. 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will think full listing is good or a query (instead of a URL?) I am in favor of consistency. Prior to 4.2 we listed all BUGS explicitly. We should keep doing that. 3. Upgrade instructions are known to be bad and we will have to wait at least till Wednesday to get these right. We have some volunteers already working on those and their effort is highly appreciated. Right, and since there is no rush, why not wait a bit till we can all look this with cool heads, double check the RN, bugs listing, upgrade instructions etc... -abhi On 15/11/13 2:50 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: So the -1 is because of the lack of rn and upgrade path docs, right, I think I proposed earlier this thread to release after the doc hackathon privided that. I wasn't really explicit about it I think as no one commented on this strategy. Would that be acceptable to you all (especially David and Sebastien)? I agree btw that docs must be available, but I don't think these have to be as stable as the release. We should allow for improving the docs on a release if needed. The net result of what I am proposing is that there will be a release and a docs rc. This is what the splitting of of the docs was about in my view,. Makes sense? If not, we should not try to make CCC Europe with 4.2.1. I think this is what the hurry is about Daan On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen run...@gmail.com wrote: I might be behind on the discussions here, but I will veto an RC that does not have list of bugs fixed and proper upgrade path documented (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the docs or not. Right now I see that the bugs fix list points to a jira filter. This is not consistent with the way it was done in prior releases (explicit listing) and in 4.2 (which pointed to the RN). We need consistency. What happens if someone changes this jira
Re: Unable to edit https://cwiki.apache.org/confluence/display/CLOUDSTACK/CCC+Europe#
done On Fri, Nov 15, 2013 at 8:18 AM, Sateesh Chodapuneedi sateesh.chodapune...@citrix.com wrote: Hi, Looking to add hackathon entry over here https://cwiki.apache.org/confluence/display/CLOUDSTACK/CCC+Europe# But unable to do so as it seems the wiki edit access permissions are not there. Can you somebody give edit access to cwiki for user 'sateeshc' ? Regards, Sateesh
Re: 4.3 System VM Templates
Bump... Still trying to find system vm templates for 4.3. Are they generated somewhere when I do a clean install and I can manually put them on secondary storage? If not, is there a publicly accessible URL where I can get the 4.3 system vm templates for 4.3? Thanks... On Thu, Nov 14, 2013 at 5:01 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: On a related note, when does the vm_template table in the DB get updated with the new paths? On Thu, Nov 14, 2013 at 2:51 PM, Will Stevens wstev...@cloudops.com wrote: Where are these located? The path shown in the docs does not resolve for me. Doc: https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+CloudStack Path: http:// jenkins.cloudstack.org/view/master/job/build-systemvm-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvmtemplate-2013-08-29-master-xen.vhd.bz2 Thanks... -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloudhttp://solidfire.com/solution/overview/?video=play *™*
Re: Review Request 15489: Adding protocol parameter to loadbalancer response
On Nov. 15, 2013, 1:53 p.m., Murali Reddy wrote: Syed I dont think you added 'protocol' to createLoadBalancerRule. There should not be 'protocol' in the LoadBalancerContainer? I actually did add the 'protocol' parameter to createLoadBalancerRule. This maps to `lb_protocol` field in the `load_balancing_rules` table. I added getLbProtocol() to LoabalacnerContainer because I thought that is the right palce as other parameters like algorithm ( getAlgorithm() ) scheme etc are present here. Does this sound correct? - Syed --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15489/#review28968 --- On Nov. 13, 2013, 6:08 p.m., Syed Ahmed wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15489/ --- (Updated Nov. 13, 2013, 6:08 p.m.) Review request for cloudstack, Alena Prokharchyk and Murali Reddy. Repository: cloudstack-git Description --- Adding protocol parameter to Loadbalancer Response Diffs - api/src/com/cloud/network/rules/LoadBalancer.java e6dadca api/src/com/cloud/network/rules/LoadBalancerContainer.java 9d5ea59 api/src/org/apache/cloudstack/api/response/LoadBalancerResponse.java 0f18097 engine/schema/src/org/apache/cloudstack/lb/ApplicationLoadBalancerRuleVO.java 37a747e server/src/com/cloud/api/ApiResponseHelper.java 903c485 Diff: https://reviews.apache.org/r/15489/diff/ Testing --- Thanks, Syed Ahmed
Re: Review Request 15489: Adding protocol parameter to loadbalancer response
Syed, that sounds correct to me. Container should have the properties algorithm, protocol, public Ip, etc. While LoadBalancer represents only the rule itself (the port combination) -Alena. From: Syed Ahmed sah...@cloudops.commailto:sah...@cloudops.com Reply-To: Syed Ahmed sah...@cloudops.commailto:sah...@cloudops.com Date: Friday, November 15, 2013 9:21 AM To: Murali Reddy muralimmre...@gmail.commailto:muralimmre...@gmail.com, Alena Prokharchyk alena.prokharc...@citrix.commailto:alena.prokharc...@citrix.com Cc: Syed Ahmed sah...@cloudops.commailto:sah...@cloudops.com, cloudstack dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: Review Request 15489: Adding protocol parameter to loadbalancer response This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15489/ On November 15th, 2013, 1:53 p.m. UTC, Murali Reddy wrote: Syed I dont think you added 'protocol' to createLoadBalancerRule. There should not be 'protocol' in the LoadBalancerContainer? I actually did add the 'protocol' parameter to createLoadBalancerRule. This maps to `lb_protocol` field in the `load_balancing_rules` table. I added getLbProtocol() to LoabalacnerContainer because I thought that is the right palce as other parameters like algorithm ( getAlgorithm() ) scheme etc are present here. Does this sound correct? - Syed On November 13th, 2013, 6:08 p.m. UTC, Syed Ahmed wrote: Review request for cloudstack, Alena Prokharchyk and Murali Reddy. By Syed Ahmed. Updated Nov. 13, 2013, 6:08 p.m. Repository: cloudstack-git Description Adding protocol parameter to Loadbalancer Response Diffs * api/src/com/cloud/network/rules/LoadBalancer.java (e6dadca) * api/src/com/cloud/network/rules/LoadBalancerContainer.java (9d5ea59) * api/src/org/apache/cloudstack/api/response/LoadBalancerResponse.java (0f18097) * engine/schema/src/org/apache/cloudstack/lb/ApplicationLoadBalancerRuleVO.java (37a747e) * server/src/com/cloud/api/ApiResponseHelper.java (903c485) View Diffhttps://reviews.apache.org/r/15489/diff/
Re: Review Request 15489: Adding protocol parameter to loadbalancer response
On Nov. 15, 2013, 1:53 p.m., Murali Reddy wrote: Syed I dont think you added 'protocol' to createLoadBalancerRule. There should not be 'protocol' in the LoadBalancerContainer? Syed Ahmed wrote: I actually did add the 'protocol' parameter to createLoadBalancerRule. This maps to `lb_protocol` field in the `load_balancing_rules` table. I added getLbProtocol() to LoabalacnerContainer because I thought that is the right palce as other parameters like algorithm ( getAlgorithm() ) scheme etc are present here. Does this sound correct? Syed, that sounds correct to me. Container should have the properties algorithm, protocol, public Ip, etc. While LoadBalancer represents only the rule itself (the port combination) - Alena --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15489/#review28968 --- On Nov. 13, 2013, 6:08 p.m., Syed Ahmed wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15489/ --- (Updated Nov. 13, 2013, 6:08 p.m.) Review request for cloudstack, Alena Prokharchyk and Murali Reddy. Repository: cloudstack-git Description --- Adding protocol parameter to Loadbalancer Response Diffs - api/src/com/cloud/network/rules/LoadBalancer.java e6dadca api/src/com/cloud/network/rules/LoadBalancerContainer.java 9d5ea59 api/src/org/apache/cloudstack/api/response/LoadBalancerResponse.java 0f18097 engine/schema/src/org/apache/cloudstack/lb/ApplicationLoadBalancerRuleVO.java 37a747e server/src/com/cloud/api/ApiResponseHelper.java 903c485 Diff: https://reviews.apache.org/r/15489/diff/ Testing --- Thanks, Syed Ahmed
Re: Coverage Analysis: Few Issues
I have looked into this briefly. It appears that these commands are not
needed, so I will remove them and only keep the Palo Alto specific commands.
addPaloAltoFirewall=1
deletePaloAltoFirewall=1
configurePaloAltoFirewall=1
listPaloAltoFirewalls=1
listPaloAltoFirewallNetworks=1
Cheers,
Will
On Thu, Nov 14, 2013 at 11:49 PM, Will Stevens wstev...@cloudops.comwrote:
Yes, I will look into the naming of the API commands in the Palo Alto
plugin. When you say 'they are supposed to be merged as one command', what
do you mean?
These were the commands that I exposed.
Palo Alto firewall commands
addExternalFirewall=1
deleteExternalFirewall=1
listExternalFirewalls=1
addPaloAltoFirewall=1
deletePaloAltoFirewall=1
configurePaloAltoFirewall=1
listPaloAltoFirewalls=1
listPaloAltoFirewallNetworks=1
When I started working on this I was using the SRX as a model as it was
the only documentation I had at the time. I was under the impression that
I was supposed to override those commands. Once I got things working I did
not go back over this, so I am sure I can improve this aspect of the plugin.
Thanks,
Will
On Thu, Nov 14, 2013 at 9:01 PM, Sheng Yang sh...@yasker.org wrote:
Hi Will,
Could you check on Palo Alto's duplicate api commands? They suppose to be
merged as one command I think.
BTW, how can this works? Did it broke SRX?
--Sheng
On Thu, Nov 14, 2013 at 2:55 AM, Santhosh Edukulla
santhosh.eduku...@citrix.com wrote:
Team,
While running code coverage analysis with sonar for integration tests,
based upon the errors thrown, i could see the below issues\notes with CS
project.
Issue1:
The coverage tool is complaining about duplicate sources for below
files. These are available with same name under folders
./cloudstack/plugins/network-elements/juniper-srx and as well under
/palo-alto.
./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/AddExternalFirewallCmd.java
./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/DeleteExternalFirewallCmd.java
./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/ListExternalFirewallCmd.java
I renamed one while running analysis to a different name. It proceeded
further with its analysis once renamed.
Is it intentional to have same name or can be renamed?
Issue2:
The source directory does not correspond to package declaration for
code files under
/root/softwares/cscode/cloudstack/services/console-proxy-rdp/rdpconsole/src/main/java/rdpclient/
This error when compared to other files in the similar path has a
different package convention and usage.
/root/softwares/cscode/cloudstack/services/secondary-storage/src/org/apache/cloudstack/storage/
Changing tool configuration properties worked to over come this, but Is
it intentional to have a different package structure for rdpclient code
base against others?
Thanks!
Santhosh
Request: Help designing a 'powered by' logo for CloudStack
Hi folks: If you happen to have some graphical design talent (I have none) I have a great opportunity for you :) CloudStack needs a 'powered by' logo that is easy to consume, and is also attractive. A couple examples of powered by logos: http://tomcat.apache.org/images/tomcat-power.gif https://cwiki.apache.org/confluence/download/attachments/80899/mahout-logo-poweredby-100.png?version=1modificationDate=1312880703000 https://netbeans.org/images_www/screenshots/6.0/baseIDE_ant_powered_150px.png A couple of constraints: * Please don't use the Apache feather. (we could, but lets not; it will make life simpler) * Please try and produce a vector format as source (this allows us to scale/etc) * Because this will become a trademark (which is vastly different that copyright) - we will likely need some explicit email agreement around trademarks rights for the image. (I promise, it isn't as scary as that sentence makes it out to be.) Anyone interested? --David
RE: [ASF4.2.1] Release Notes
-Original Message- From: Chip Childers [mailto:chipchild...@apache.org] Sent: Friday, November 15, 2013 6:28 AM To: dev@cloudstack.apache.org Subject: Re: [ASF4.2.1] Release Notes IMO, we should kill the CHAGES file and just get the release notes document under control. I'm fine if Changes is in bad shape for this release personally, as long as the release notes are accurate. Animesh Yes we followed the same approach for 4.2 as I was pointed out to me that there was a prior discussion on keeping things in release notes. I had added link to JIRA filter for known issues and fixed issues [1]. Another thought to remind folks about in this thread: Changes to the cloudstack.git repo's 4.2 branch that we want to be in the 4.2.1 release will cause a re-spin and re-vote. Changes to the documentation repo have nothing to do with the release vote, except that we (as a community) seem to agree that our docs should be at least updated and pushed to the website *before* announcing 4.2.1. Make sense? Animesh Yes thanks for calling it out clearly. I will update the Release Management page on wiki for future reference. [1] http://markmail.org/message/rkzzyg5i26mshpbt On Fri, Nov 15, 2013 at 8:19 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: Ok I will go that way till someone says that listing 175 tickets in CHANGES file will needlessly clutter it. Can we focus the list to blockers and criticals at least ? -abhi On 15/11/13 6:34 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: Abihnandan, Why not include the output of the query instead of the query? I think this is what Sebastien means. A list of the important ones can still be prepended in more readable form afaic. Daan On Fri, Nov 15, 2013 at 1:32 PM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: For listing down the fixed issues, since there are ~175 of these. I will list down some important fixes. Followed by the query to give a exhaustive list, is that acceptable ? For known issues will look at the 4.3/4.2 open tickets list down the important ones. This will go in the CHANGES in source repo and RN in code repo. -abhi On 15/11/13 5:54 pm, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: To address the concern of RN we will not conclude the vote on RC (i.e. Not make a release) till the RN in general and upgrade instructions in particular are also of acceptable quality. As for other inconsistencies will work towards ironing those out. -abhi On 15/11/13 3:30 pm, Sebastien Goasguen run...@gmail.com wrote: On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: As a RM I had agreed to Sebatian's suggestion of fixing the docs specially the upgrade section of it. And off course doing a GA after the docs are fixed is on the cards. As for the list of fixed and known issues I was told that a filter is good enough but it should be pretty easy to get the listing in the docs itself. If someone has specific preferences it is easy to fix that. So it boils down to get opinion from folks on the following: 1. RC build, this does not contain docs. I have seen no complains or issues here. That's fine, but releasing something without the upgrade instructions committed is bad. Even if the release of such upgrade instructions happen after the release of the code. 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will think full listing is good or a query (instead of a URL?) I am in favor of consistency. Prior to 4.2 we listed all BUGS explicitly. We should keep doing that. 3. Upgrade instructions are known to be bad and we will have to wait at least till Wednesday to get these right. We have some volunteers already working on those and their effort is highly appreciated. Right, and since there is no rush, why not wait a bit till we can all look this with cool heads, double check the RN, bugs listing, upgrade instructions etc... -abhi On 15/11/13 2:50 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: So the -1 is because of the lack of rn and upgrade path docs, right, I think I proposed earlier this thread to release after the doc hackathon privided that. I wasn't really explicit about it I think as no one commented on this strategy. Would that be acceptable to you all (especially David and Sebastien)? I agree btw that docs must be available, but I don't think these have to be as stable as the release. We should allow for improving the docs on a release if needed. The net result of what I am proposing is that there will be a release and a docs rc. This is what the splitting of of the docs was about in my view,. Makes sense? If not, we should not try to make CCC Europe with 4.2.1. I think this is what the hurry is about Daan On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen run...@gmail.com wrote: I might be behind on the discussions here, but I will veto an RC that
Re: Request: Help designing a 'powered by' logo for CloudStack
May have deleted the thread but wasn¹t this being covered off earlier in @marketing or is this a new request? On 11/15/13, 12:56 PM, David Nalley da...@gnsa.us wrote: Hi folks: If you happen to have some graphical design talent (I have none) I have a great opportunity for you :) CloudStack needs a 'powered by' logo that is easy to consume, and is also attractive. A couple examples of powered by logos: http://tomcat.apache.org/images/tomcat-power.gif https://cwiki.apache.org/confluence/download/attachments/80899/mahout-logo -poweredby-100.png?version=1modificationDate=1312880703000 https://netbeans.org/images_www/screenshots/6.0/baseIDE_ant_powered_150px. png A couple of constraints: * Please don't use the Apache feather. (we could, but lets not; it will make life simpler) * Please try and produce a vector format as source (this allows us to scale/etc) * Because this will become a trademark (which is vastly different that copyright) - we will likely need some explicit email agreement around trademarks rights for the image. (I promise, it isn't as scary as that sentence makes it out to be.) Anyone interested? --David
Re: 4.3 System VM Templates
I found http://jenkins.buildacloud.org/view/master/job/build-systemvm-master/lastSuccessfulBuild/artifact/tools/appliance/dist/ Let me know if this is valid. I'll update the wiki Thanks, -Syed On Fri 15 Nov 2013 12:03:16 PM EST, Will Stevens wrote: Bump... Still trying to find system vm templates for 4.3. Are they generated somewhere when I do a clean install and I can manually put them on secondary storage? If not, is there a publicly accessible URL where I can get the 4.3 system vm templates for 4.3? Thanks... On Thu, Nov 14, 2013 at 5:01 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: On a related note, when does the vm_template table in the DB get updated with the new paths? On Thu, Nov 14, 2013 at 2:51 PM, Will Stevens wstev...@cloudops.com wrote: Where are these located? The path shown in the docs does not resolve for me. Doc: https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+CloudStack Path: http:// jenkins.cloudstack.org/view/master/job/build-systemvm-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvmtemplate-2013-08-29-master-xen.vhd.bz2 Thanks... -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloudhttp://solidfire.com/solution/overview/?video=play *™*
Re: 4.3 System VM Templates
Thanks Syed. I will test them. On Fri, Nov 15, 2013 at 1:28 PM, Syed Ahmed sah...@cloudops.com wrote: I found http://jenkins.buildacloud.org/view/master/job/build-systemvm-master/ lastSuccessfulBuild/artifact/tools/appliance/dist/ Let me know if this is valid. I'll update the wiki Thanks, -Syed On Fri 15 Nov 2013 12:03:16 PM EST, Will Stevens wrote: Bump... Still trying to find system vm templates for 4.3. Are they generated somewhere when I do a clean install and I can manually put them on secondary storage? If not, is there a publicly accessible URL where I can get the 4.3 system vm templates for 4.3? Thanks... On Thu, Nov 14, 2013 at 5:01 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: On a related note, when does the vm_template table in the DB get updated with the new paths? On Thu, Nov 14, 2013 at 2:51 PM, Will Stevens wstev...@cloudops.com wrote: Where are these located? The path shown in the docs does not resolve for me. Doc: https://cwiki.apache.org/confluence/display/CLOUDSTACK/ How+to+build+CloudStack Path: http:// jenkins.cloudstack.org/view/master/job/build-systemvm- master/lastSuccessfulBuild/artifact/tools/appliance/dist/ systemvmtemplate-2013-08-29-master-xen.vhd.bz2 Thanks... -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloudhttp://solidfire.com/solution/overview/?video=play *™*
Re: Request: Help designing a 'powered by' logo for CloudStack
This is really a follow on to that request. Chip commented to me on IRC that he was running out of time to work on it, so hence my request. --David On Fri, Nov 15, 2013 at 1:23 PM, Kelly Hair kelly.h...@citrix.com wrote: May have deleted the thread but wasn¹t this being covered off earlier in @marketing or is this a new request? On 11/15/13, 12:56 PM, David Nalley da...@gnsa.us wrote: Hi folks: If you happen to have some graphical design talent (I have none) I have a great opportunity for you :) CloudStack needs a 'powered by' logo that is easy to consume, and is also attractive. A couple examples of powered by logos: http://tomcat.apache.org/images/tomcat-power.gif https://cwiki.apache.org/confluence/download/attachments/80899/mahout-logo -poweredby-100.png?version=1modificationDate=1312880703000 https://netbeans.org/images_www/screenshots/6.0/baseIDE_ant_powered_150px. png A couple of constraints: * Please don't use the Apache feather. (we could, but lets not; it will make life simpler) * Please try and produce a vector format as source (this allows us to scale/etc) * Because this will become a trademark (which is vastly different that copyright) - we will likely need some explicit email agreement around trademarks rights for the image. (I promise, it isn't as scary as that sentence makes it out to be.) Anyone interested? --David
Re: Request: Help designing a 'powered by' logo for CloudStack
Yep - that's the deal... I gave some initial designs, we got some feedback... would love for someone to take a crack at round 2 options. On Fri, Nov 15, 2013 at 1:33 PM, David Nalley da...@gnsa.us wrote: This is really a follow on to that request. Chip commented to me on IRC that he was running out of time to work on it, so hence my request. --David On Fri, Nov 15, 2013 at 1:23 PM, Kelly Hair kelly.h...@citrix.com wrote: May have deleted the thread but wasn¹t this being covered off earlier in @marketing or is this a new request? On 11/15/13, 12:56 PM, David Nalley da...@gnsa.us wrote: Hi folks: If you happen to have some graphical design talent (I have none) I have a great opportunity for you :) CloudStack needs a 'powered by' logo that is easy to consume, and is also attractive. A couple examples of powered by logos: http://tomcat.apache.org/images/tomcat-power.gif https://cwiki.apache.org/confluence/download/attachments/80899/mahout-logo -poweredby-100.png?version=1modificationDate=1312880703000 https://netbeans.org/images_www/screenshots/6.0/baseIDE_ant_powered_150px. png A couple of constraints: * Please don't use the Apache feather. (we could, but lets not; it will make life simpler) * Please try and produce a vector format as source (this allows us to scale/etc) * Because this will become a trademark (which is vastly different that copyright) - we will likely need some explicit email agreement around trademarks rights for the image. (I promise, it isn't as scary as that sentence makes it out to be.) Anyone interested? --David
Upgrading nitro API to 10.1
Hi All, I was wondering if it was possible to update the nitro packet which is required for Netscaler API from 10.0 to 10.1. The new 10.1 supports the bundle parameter which makes it possible to upload certificate and the trust chain in a single file which makes it very easy for certificate management. Thanks, -Syed
Re: Coverage Analysis: Few Issues
Sure, if you don't need these addExternalFirewall etc., you can just remove
them.
Because the name of addExternalFirewall etc. is too generic, so I thought
if you need them as well, you should able to merge your version and SRX
version into one command.
--Sheng
On Fri, Nov 15, 2013 at 9:47 AM, Will Stevens wstev...@cloudops.com wrote:
I have looked into this briefly. It appears that these commands are not
needed, so I will remove them and only keep the Palo Alto specific commands.
addPaloAltoFirewall=1
deletePaloAltoFirewall=1
configurePaloAltoFirewall=1
listPaloAltoFirewalls=1
listPaloAltoFirewallNetworks=1
Cheers,
Will
On Thu, Nov 14, 2013 at 11:49 PM, Will Stevens wstev...@cloudops.comwrote:
Yes, I will look into the naming of the API commands in the Palo Alto
plugin. When you say 'they are supposed to be merged as one command', what
do you mean?
These were the commands that I exposed.
Palo Alto firewall commands
addExternalFirewall=1
deleteExternalFirewall=1
listExternalFirewalls=1
addPaloAltoFirewall=1
deletePaloAltoFirewall=1
configurePaloAltoFirewall=1
listPaloAltoFirewalls=1
listPaloAltoFirewallNetworks=1
When I started working on this I was using the SRX as a model as it was
the only documentation I had at the time. I was under the impression that
I was supposed to override those commands. Once I got things working I did
not go back over this, so I am sure I can improve this aspect of the plugin.
Thanks,
Will
On Thu, Nov 14, 2013 at 9:01 PM, Sheng Yang sh...@yasker.org wrote:
Hi Will,
Could you check on Palo Alto's duplicate api commands? They suppose to
be merged as one command I think.
BTW, how can this works? Did it broke SRX?
--Sheng
On Thu, Nov 14, 2013 at 2:55 AM, Santhosh Edukulla
santhosh.eduku...@citrix.com wrote:
Team,
While running code coverage analysis with sonar for integration tests,
based upon the errors thrown, i could see the below issues\notes with CS
project.
Issue1:
The coverage tool is complaining about duplicate sources for below
files. These are available with same name under folders
./cloudstack/plugins/network-elements/juniper-srx and as well under
/palo-alto.
./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/AddExternalFirewallCmd.java
./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/DeleteExternalFirewallCmd.java
./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/ListExternalFirewallCmd.java
I renamed one while running analysis to a different name. It proceeded
further with its analysis once renamed.
Is it intentional to have same name or can be renamed?
Issue2:
The source directory does not correspond to package declaration for
code files under
/root/softwares/cscode/cloudstack/services/console-proxy-rdp/rdpconsole/src/main/java/rdpclient/
This error when compared to other files in the similar path has a
different package convention and usage.
/root/softwares/cscode/cloudstack/services/secondary-storage/src/org/apache/cloudstack/storage/
Changing tool configuration properties worked to over come this, but Is
it intentional to have a different package structure for rdpclient code
base against others?
Thanks!
Santhosh
Re: CloudStack.next
+1 especially to CI process improvement. IMO, we need to improve the patch review process. Sometimes we encounter that the master branch is broken. Low quality commit slows down our developing and testing on the master branch. I think we should change the patch review process to check that a patch pass unit test before it is merged to the master. There are Jenkins plugins that help pre-commit testing. They observe a patch submission, create a test branch that merges the master branch and the patch, run tests on the branch, and write back the result on the ReviewBoard or the Github PullRequest. https://wiki.jenkins-ci.org/display/JENKINS/Jenkins-Reviewbot (for ReviewBoard) https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin (for Github PullRequest) we need to consider these kind pre-commit auto testing tool adoption. -our testing infra needs to get much better, continuous testing for all branches, testing on commits etc…maybe we should find a way to get help from cloudbees to get us on the right tracks. Overall we need to be able to release at any instant with confidence. - Noji 2013/11/15 Sebastien Goasguen run...@gmail.com: Hi, this is a bit of a brain dump: I tend to see different types of buckets: 1-Processes Involves getting better as a community in terms of release, bug fixing, committing code, documentation and user support. Some of these have already been discussed partially but we need to come to consensus and act. For example: -we should have no unanswered questions on the lists. Anyway to have an official volunteer support team ? With a 24/7 twilio number on the site that rings up someone out there :) ? -we should catch up on bug fixing (and great job on 4.2.1 btw) -when we commit we cannot break master, and I also would argue for committing docs when it's a new feature, right now master is a catch all, instead of a super stable, high quality branch. -we need much better docs -we need to define standards for releases: RN, changes file, upgrade paths, testing etc. -our testing infra needs to get much better, continuous testing for all branches, testing on commits etc…maybe we should find a way to get help from cloudbees to get us on the right tracks. Overall we need to be able to release at any instant with confidence. -no feature should be un-documented and/or un-tested. for instance: there was a recent complaint about lack of F5 documentation, and right now I have no clue who is testing the F5 integration. 2-Ecosystem We need to build up the ecosystem around cloudstack and advertize it. We integrate with almost everything out there, yet people don't know it. I wish that: 2.1 we would improve on support in existing software: all configuration mgt systems, main cloud libraries, PaaS etc... 2.2 work with everyone in that ecosystem to advertize and demo CloudStack integration 2.3 work on extending that ecosystem (e.g Docker support, Cloudfoundry, Mesos, Spark, OpenDaylight controller) some of it is just a matter of writing a tutorial, some of it there is actual coding involved. 2.4 restart effort on AWS: as mentioned IAM is needed but there is more, we need to catch with euca and integrate with netflixOSS software. Bring EMR, ELB, CloudWatch etc…I have plans to work on this and hopefully propose a standalone AWS-ACS bridge with extended services. 3-Code (caveat, I am not a java developer) I still would love to see a lot of cleanup and review. For example I believe the KVM agent uses some python scripts in cloud-cli, those don't use Marvin. We should try to consolidate these. There is code in the tree that is unused, we should clean it up. In the UI when you add a cluster we still list 'OVM' yet it's broken, we need to clean. OStypes in image creation, we need to clean up... Packaging and mavenization, we should finish that up and really make it super strong. We need to call out to maven and package experts for a hand. We had a small thread on KVM agent and we will have a talk at the hackathon, here I will pick on Xen: We need much better support for Xen_Project without using xapi (the xapi install on XP is a pain), without xapi we could easily have ARM / Ceph support… Overall I would like to see a strong core emerge with clean code separation with UI, DB abstraction, backend drivers and plugins. ( A bit pie in the sky, but a non java guy should be able to keep the core and replace/add any other component, plug and play) Biggest item is probably a software architecture blueprint, right now we don't have that. No UML diagram, no sequence diagram, most people don't know how cloudstack actually works. -seb (I will invest time on the ecosystem bucket) On Nov 14, 2013, at 10:18 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: +1 to IAM. An Autoscale service independent of Netscaler. I'd like to see the built-in GRE controller fully fleshed out as
Re: [ACS421] Closing Resolved defects
I've closed one of mine. But the others would need QA to verify. Thanks. --Sheng On Thu, Nov 14, 2013 at 10:31 PM, Sudha Ponnaganti sudha.ponnaga...@citrix.com wrote: Below are the defects which are fixed in 4.2.1 but not validated. Can you pl take few min to review fix done and close these defects Reporter Total Grand Total77 angeline shen6 Sailaja Mada 6 Prachi Damle 4 Rayees Namathponnan4 Sheng Yang 4 Chandan Purushothama 3 Likitha Shetty 3 Nitin Mehta3 shweta agarwal3 Ahmad Emneina 2 Alena Prokharchyk 2 Chris Sciarrino2 Harikrishna Patnala 2 prashant kumar mishra 2 Sateesh Chodapuneedi 2 Anshul Gangwar 1 Dave Cahill 1 Douglas Almquist 1 edison su 1 Francois Gaudreault 1 frank zhang1 Gaurav Aradhye 1 gavin lee 1 Gerard Lynch 1 Jayapal Reddy 1 John Kinsella 1 Kelven Yang 1 Kiran Koneti 1 Koushik Das1 Marcus Sorensen 1 Milamber1 Naoki Sakamoto 1 Parth Jagirdar1 Ron Wheeler 1 sadhu suresh 1 Saksham Srivastava 1 Sangeetha Hariharan 1 Sanjay Tripathi 1 Sowmya Krishnan1 Sudha Ponnaganti 1 Timothy Ehlers 1 Valery Ciareszka 1 venkata swamybabu budumuru 1 Wei Zhou 1
Re: Request: Help designing a 'powered by' logo for CloudStack
Not that I have great graphical skills, but I will give it a try to see if I can compete with the pros :-) Are there any deadlines? On Fri, Nov 15, 2013 at 6:56 PM, David Nalley da...@gnsa.us wrote: Hi folks: If you happen to have some graphical design talent (I have none) I have a great opportunity for you :) CloudStack needs a 'powered by' logo that is easy to consume, and is also attractive. A couple examples of powered by logos: http://tomcat.apache.org/images/tomcat-power.gif https://cwiki.apache.org/confluence/download/attachments/80899/mahout-logo-poweredby-100.png?version=1modificationDate=1312880703000 https://netbeans.org/images_www/screenshots/6.0/baseIDE_ant_powered_150px.png A couple of constraints: * Please don't use the Apache feather. (we could, but lets not; it will make life simpler) * Please try and produce a vector format as source (this allows us to scale/etc) * Because this will become a trademark (which is vastly different that copyright) - we will likely need some explicit email agreement around trademarks rights for the image. (I promise, it isn't as scary as that sentence makes it out to be.) Anyone interested? --David -- EOF
Re: Request: Help designing a 'powered by' logo for CloudStack
Awesome!!! Thanks! Not really - sooner is generally better than later, but getting it done is better than not. --David On Fri, Nov 15, 2013 at 2:03 PM, Laszlo Hornyak laszlo.horn...@gmail.com wrote: Not that I have great graphical skills, but I will give it a try to see if I can compete with the pros :-) Are there any deadlines? On Fri, Nov 15, 2013 at 6:56 PM, David Nalley da...@gnsa.us wrote: Hi folks: If you happen to have some graphical design talent (I have none) I have a great opportunity for you :) CloudStack needs a 'powered by' logo that is easy to consume, and is also attractive. A couple examples of powered by logos: http://tomcat.apache.org/images/tomcat-power.gif https://cwiki.apache.org/confluence/download/attachments/80899/mahout-logo-poweredby-100.png?version=1modificationDate=1312880703000 https://netbeans.org/images_www/screenshots/6.0/baseIDE_ant_powered_150px.png A couple of constraints: * Please don't use the Apache feather. (we could, but lets not; it will make life simpler) * Please try and produce a vector format as source (this allows us to scale/etc) * Because this will become a trademark (which is vastly different that copyright) - we will likely need some explicit email agreement around trademarks rights for the image. (I promise, it isn't as scary as that sentence makes it out to be.) Anyone interested? --David -- EOF
Re: Coverage Analysis: Few Issues
I will just remove them. It appears the only reason they are there is for
backwards compatibility. I have checked other plugins and they all just
expose the device specific api commands (Other than SRX which exposes both).
The problem with merging them into one command is the PaloAlto plugin is in
core and the SRX plugin is in 'noredist', so I don't really want to create
any dependency requirements on other plugins.
Cheers,
Will
On Fri, Nov 15, 2013 at 1:56 PM, Sheng Yang sh...@yasker.org wrote:
Sure, if you don't need these addExternalFirewall etc., you can just
remove them.
Because the name of addExternalFirewall etc. is too generic, so I thought
if you need them as well, you should able to merge your version and SRX
version into one command.
--Sheng
On Fri, Nov 15, 2013 at 9:47 AM, Will Stevens wstev...@cloudops.comwrote:
I have looked into this briefly. It appears that these commands are not
needed, so I will remove them and only keep the Palo Alto specific commands.
addPaloAltoFirewall=1
deletePaloAltoFirewall=1
configurePaloAltoFirewall=1
listPaloAltoFirewalls=1
listPaloAltoFirewallNetworks=1
Cheers,
Will
On Thu, Nov 14, 2013 at 11:49 PM, Will Stevens wstev...@cloudops.comwrote:
Yes, I will look into the naming of the API commands in the Palo Alto
plugin. When you say 'they are supposed to be merged as one command', what
do you mean?
These were the commands that I exposed.
Palo Alto firewall commands
addExternalFirewall=1
deleteExternalFirewall=1
listExternalFirewalls=1
addPaloAltoFirewall=1
deletePaloAltoFirewall=1
configurePaloAltoFirewall=1
listPaloAltoFirewalls=1
listPaloAltoFirewallNetworks=1
When I started working on this I was using the SRX as a model as it was
the only documentation I had at the time. I was under the impression that
I was supposed to override those commands. Once I got things working I did
not go back over this, so I am sure I can improve this aspect of the plugin.
Thanks,
Will
On Thu, Nov 14, 2013 at 9:01 PM, Sheng Yang sh...@yasker.org wrote:
Hi Will,
Could you check on Palo Alto's duplicate api commands? They suppose to
be merged as one command I think.
BTW, how can this works? Did it broke SRX?
--Sheng
On Thu, Nov 14, 2013 at 2:55 AM, Santhosh Edukulla
santhosh.eduku...@citrix.com wrote:
Team,
While running code coverage analysis with sonar for integration tests,
based upon the errors thrown, i could see the below issues\notes with CS
project.
Issue1:
The coverage tool is complaining about duplicate sources for below
files. These are available with same name under folders
./cloudstack/plugins/network-elements/juniper-srx and as well under
/palo-alto.
./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/AddExternalFirewallCmd.java
./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/DeleteExternalFirewallCmd.java
./cloudstack/plugins/network-elements/palo-alto/src/com/cloud/api/commands/ListExternalFirewallCmd.java
I renamed one while running analysis to a different name. It
proceeded further with its analysis once renamed.
Is it intentional to have same name or can be renamed?
Issue2:
The source directory does not correspond to package declaration for
code files under
/root/softwares/cscode/cloudstack/services/console-proxy-rdp/rdpconsole/src/main/java/rdpclient/
This error when compared to other files in the similar path has a
different package convention and usage.
/root/softwares/cscode/cloudstack/services/secondary-storage/src/org/apache/cloudstack/storage/
Changing tool configuration properties worked to over come this, but
Is it intentional to have a different package structure for rdpclient code
base against others?
Thanks!
Santhosh
Re: Request: Help designing a 'powered by' logo for CloudStack
May be a silly question, but why not just add powered by the existing logo? Regards, Kirk Jantzer http://about.me/kirkjantzer On Fri, Nov 15, 2013 at 2:06 PM, David Nalley da...@gnsa.us wrote: Awesome!!! Thanks! Not really - sooner is generally better than later, but getting it done is better than not. --David On Fri, Nov 15, 2013 at 2:03 PM, Laszlo Hornyak laszlo.horn...@gmail.com wrote: Not that I have great graphical skills, but I will give it a try to see if I can compete with the pros :-) Are there any deadlines? On Fri, Nov 15, 2013 at 6:56 PM, David Nalley da...@gnsa.us wrote: Hi folks: If you happen to have some graphical design talent (I have none) I have a great opportunity for you :) CloudStack needs a 'powered by' logo that is easy to consume, and is also attractive. A couple examples of powered by logos: http://tomcat.apache.org/images/tomcat-power.gif https://cwiki.apache.org/confluence/download/attachments/80899/mahout-logo-poweredby-100.png?version=1modificationDate=1312880703000 https://netbeans.org/images_www/screenshots/6.0/baseIDE_ant_powered_150px.png A couple of constraints: * Please don't use the Apache feather. (we could, but lets not; it will make life simpler) * Please try and produce a vector format as source (this allows us to scale/etc) * Because this will become a trademark (which is vastly different that copyright) - we will likely need some explicit email agreement around trademarks rights for the image. (I promise, it isn't as scary as that sentence makes it out to be.) Anyone interested? --David -- EOF
Re: A question on vm migrations when hosts are set into a maintenance mode.
I hate to sending the same emails over and over again, but I really need to
finalize this feature to be included in the next code freeze because this
feature is very critical in our inside project.
Anyone who can help, please?
Thanks
Alex Ough
On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough alex.o...@sungard.com wrote:
Not sure if Alex Huang checked this, but can anyone help to resolve this?
Thanks
Alex Ough
On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough alex.o...@sungard.com wrote:
It sounds a little scary...
I looked at the history and found these.
8/9/ : file moved to engine by Alex Huang
9/16 : '_mgmtServer.getExecuteInSequence()' changed to
'getExecuteInSequence()' by Alex Huang
Hi Alex Huang,
I'm not sure if you're aware of this, but can you check this for me?
Thanks
Alex Ough
On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen shadow...@gmail.comwrote:
I'm not sure. I know in the past when I've seen files change locations
it has also clobbered updates to that file. Someone branched, did the
reorganization work, and merged, while in-between the original file
changed.
On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough alex.o...@sungard.com
wrote:
All,
While merging my changes to 4.3 branch, I found that the option,
'execute.in.sequence.hypervisor.commands' is NOT used in
Start/Stop/Copy
commands in 'VirtualMachineManagerImpl.java' any more as below.
*StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
*protected boolean getExecuteInSequence() {*
* return false;*
*}*
As you see in the above, the function, 'getExecuteInSequence', just
returns
false instead of getting the value from the global variable.
And one more change is that the file has been moved to
'engine/orchestration/src/com/cloud/vm' from 'server/src/com/cloud/vm'.
Am I missing something related with this or do we stop supporting this
option in 4.3?
I'm a little confused, so please help me resolve this.
Thanks
Alex Ough
On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough alex.o...@sungard.com
wrote:
Thanks a lot for your confirmation, Marcus.
I'll create a review request unless anyone has an objection.
Thanks
Alex Ough
On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen shadow...@gmail.com
wrote:
I have done parallel KVM migrations without issue, it's supposed to
work. Really I think it's in the same boat as parallel start/stop.
It
should work, but the config option is there just in case. I think we
should add it.
On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
chip.child...@sungard.com wrote:
On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
I'm not sure what else commands 'MigrateCommand' actually execute
in
addition to 'Start/Stop/CopyCommand', but can we include
'MigrateCommand'
if it consists of only those 3 commands?
Thanks
Alex Ough
In the case of VMware, the migrate command is executed via the
MigrateVMTask that's part of the VMware SDK (see
vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
For VMware, I know that vCenter will queue and process concurrent
requests for migrations. Specifically, it will throttle the
migrations
happening, based on it's internal concurrency constraints, but the
task
queue will still accept more connections. Obviously the risk are
the
VMware layer tasks timing out if it takes too long for the task
queue to
complete.
As for XenServer, it's happening in what appears to be a similar
way
(although the source host is the target for the migration API
call).
Check
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
I'm not familiar enough with XenServer's concurrency model for
migrations. Any experts know the answer to if it can handle
concurrency
in a stable way?
With KVM, it's obviously executing via the agent. Similarly to
XenServer, I'm not familiar enough to know about concurrent
operations.
So do the HV experts on the list have any opinions about XenServer
and
KVM migration concurrency?
-chip
Re: Review Request 15569: CLOUDSTACK-5179: Fixed test script issue related to detach volume
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15569/#review28986 --- Commit 8a1918dbe1c5fbbb60c21fa89d880a99e7b33bd6 in branch refs/heads/ui-restyle from Gaurav Aradhye [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8a1918d ] CLOUDSTACK-5179: Fixed test script issue related to detach volume - ASF Subversion and Git Services On Nov. 15, 2013, 7:41 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15569/ --- (Updated Nov. 15, 2013, 7:41 a.m.) Review request for cloudstack, Girish Shilamkar and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-5179 https://issues.apache.org/jira/browse/CLOUDSTACK-5179 Repository: cloudstack-git Description --- component.test_stopped_vm.TestDeployVM.test_08_deploy_attached_volume test case was failing while detaching volume because the volume was not listed properly. List volumes should accept the virtualmachineid parameter to correctly list the volume belonging to the virtual machine, otherwise the volume which we are detaching from virtual machine may belong to other virtual machine, in this case test case will fail. Diffs - test/integration/component/test_stopped_vm.py 4514bb7 Diff: https://reviews.apache.org/r/15569/diff/ Testing --- Tested locally on XenServer Basic Zone setup. test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) Test Deploy Virtual Machine with startVM=false and attach volume already attached to different machine ... == client.log == 2013-11-14 19:27:10,018 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for virtual machine: 9631c 64f-a7ba-488b-951b-c425f00e1ce3 2013-11-14 19:27:10,039 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Deploying instance in the account: test-6MG5KF 2013-11-14 19:27:31,205 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Deployed instance in account: test-6MG5KF 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Verify listVirtualMachines response for virtual machine: 7e3de e7d-29ce-425c-95e4-e8f85143254c 2013-11-14 19:27:31,240 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Fetching DATADISK details for instance: 7e3dee7d-29ce-425c-95e 4-e8f85143254c 2013-11-14 19:27:31,266 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Detaching the disk: DATA-32 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Datadisk DATA-32 detached! 2013-11-14 19:27:36,379 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Attaching volume to instance: 9631c64f-a7ba-488b-951b-c425f00e 1ce3 2013-11-14 19:27:41,530 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Cleaning up the resources 2013-11-14 19:28:42,227 - DEBUG - test_08_deploy_attached_volume (test_stopped_vm.TestDeployVM) - Cleanup complete! == result.log == ok Thanks, Gaurav Aradhye
Re: Review Request 15571: CLOUDSTACK-2243: base_image_updation - Adding tags to test cases
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15571/#review28987 --- Commit 09c0370d70721e07ff02cd907a2cab2cabc9ae5b in branch refs/heads/ui-restyle from Girish Shilamkar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=09c0370 ] CLOUDSTACK-2243: base_image_updation - Adding tags to test cases - ASF Subversion and Git Services On Nov. 15, 2013, 11:09 a.m., Ashutosh Kelkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15571/ --- (Updated Nov. 15, 2013, 11:09 a.m.) Review request for cloudstack, Girish Shilamkar and Rayees Namathponnan. Bugs: CLOUDSTACK-2243 https://issues.apache.org/jira/browse/CLOUDSTACK-2243 Repository: cloudstack-git Description --- Added basic and advanced tags for the test cases. The test cases have been run on both the setups. Diffs - test/integration/component/test_base_image_updation.py 8a99350 Diff: https://reviews.apache.org/r/15571/diff/ Testing --- Tested locally on KVM advanced and XenServer basic setup. Thanks, Ashutosh Kelkar
Jenkins build is back to normal : cloudstack-4.3-maven-build-noredist #22
See http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build-noredist/22/changes
RE: [VOTE] Release Apache CloudStack 4.2.1
+1(binding) Tested on my local machine with one KVM host, basic marvin vm test passed. -Original Message- From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] Sent: Tuesday, November 12, 2013 7:53 AM To: CloudStack Dev Subject: [VOTE] Release Apache CloudStack 4.2.1 This vote is to approve the current RC build for 4.2.1 maintenance release. For this particular release various upgrade paths have been tested apart from regression tests and BVTs. Around 175 bugs have been fixed some new features added (see CHANGES). Following are the particulars for this release: https://git-wip- us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.2 commit: 0b9eadaf14513f5c72de672963b0e2f12ee7206f List of changes: https://git-wip- us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.2. 1 Source release revision 3492 (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.2.1/ PGP release keys (signed using RSA Key ID = 42443AA1): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Vote will be open for 72 hours (until 11/15 End of day PST). For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why)
Re: [VOTE] Release Apache CloudStack 4.2.1
+1.
Did some basic testing like creating vms, attaching volume, creating
snapshots etc. and they all worked fine.
Thanks,
-Nitin
On 14/11/13 8:40 AM, Daan Hoogland daan.hoogl...@gmail.com wrote:
+1 binding (I had not been clear on this in this thread it seems)
On Thu, Nov 14, 2013 at 6:05 AM, Abhinandan Prateek
abhinandan.prat...@citrix.com wrote:
Marcus,
Just summarising your concerns so that they can be followed upon:
1. Due to a VR script change a restart of VR is required. This should be
noted down in upgrade instructions in RN. (Radhika to note)
2. For a maintenance release we should limit the scope to only
blockers. I
guess what is done is done probably for better as the main release had
so
many new features that a whole lot fixes were expected in the
maintenance
release. But again for further maintenance releases scope should be
restricted to important fixes.
Any other thing that has been missed ?
-abhi
On 14/11/13 12:06 am, Marcus Sorensen shadow...@gmail.com wrote:
I'm unable to deploy virtual machines after upgrading an existing
4.2.0 to this release.
It looks like the file savepassword.sh was added at the end of October
as a virtual router script. This would likely mean that people
upgrading to 4.2.1 will need to upgrade/redeploy their routers. I can
verify that deploy works if I reboot the router.
Looking over the current state of 4.2, I'm actually pretty surprised
at how much has changed. I'm seeing lots of whitespace fixes, changes
to interfaces, etc. My impression was that we'd only commit fixes for
blocker bugs once a release has gone production, only touching it if
we had to. This went pretty well with 4.1, I thought, but everything
was going through the RM that round.
2013-11-13 11:25:24,917 DEBUG
[resource.virtualnetwork.VirtualRoutingResource]
(agentRequest-Handler-2:null) Executing:
/usr/share/cloudstack-common/scripts/network/domr/router_proxy.sh
savepassword.sh 169.254.1.163 -v 10.2.4.116 -p fnirq_cnffjbeq
2013-11-13 11:25:25,000 DEBUG
[resource.virtualnetwork.VirtualRoutingResource]
(agentRequest-Handler-2:null) Exit value is 127
2013-11-13 11:25:25,001 DEBUG
[resource.virtualnetwork.VirtualRoutingResource]
(agentRequest-Handler-2:null) bash: /opt/cloud/bin/savepassword.sh: No
such file or directory
2013-11-13 11:25:25,002 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-2:null) Seq 21-289734823: { Ans: , MgmtId:
90520732090445, via: 21, Ver: v1, Flags: 110,
[{com.cloud.agent.api.Answer:{result:false,details:Unable to
save password to
DomR.,wait:0}},{com.cloud.agent.api.Answer:{result:false,details
:
Stopped
by previous failure,wait:0}}] }
On Wed, Nov 13, 2013 at 10:26 AM, Chip Childers
chipchild...@apache.org
wrote:
On Tue, Nov 12, 2013 at 10:52 AM, Abhinandan Prateek
abhinandan.prat...@citrix.com wrote:
This vote is to approve the current RC build for 4.2.1 maintenance
release.
For this particular release various upgrade paths have been tested
apart from regression tests and BVTs.
Around 175 bugs have been fixed some new features added (see
CHANGES).
Following are the particulars for this release:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=
re
fs/heads/4.2
commit: 0b9eadaf14513f5c72de672963b0e2f12ee7206f
List of changes:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;
f=
CHANGES;hb=4.2.1
Source release revision 3492 (checksums and signatures are available
at the same location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.2.1/
PGP release keys (signed using RSA Key ID = 42443AA1):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS
Vote will be open for 72 hours (until 11/15 End of day PST).
For sanity in tallying the vote, can PMC members please be sure to
indicate (binding) with their vote?
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
+1 (binding)
I only performed very rudimentary functional testing, but the
artifact's look legit.
Thanks for doing this Abhi!
Re: [VOTE] Release Apache CloudStack 4.2.1
+1(binding) Tested on my local dev setup with one Xen host and basic zone, marvin vm test passed. Thanks -min On 11/15/13 3:21 PM, Edison Su edison...@citrix.com wrote: +1(binding) Tested on my local machine with one KVM host, basic marvin vm test passed. -Original Message- From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] Sent: Tuesday, November 12, 2013 7:53 AM To: CloudStack Dev Subject: [VOTE] Release Apache CloudStack 4.2.1 This vote is to approve the current RC build for 4.2.1 maintenance release. For this particular release various upgrade paths have been tested apart from regression tests and BVTs. Around 175 bugs have been fixed some new features added (see CHANGES). Following are the particulars for this release: https://git-wip- us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.2 commit: 0b9eadaf14513f5c72de672963b0e2f12ee7206f List of changes: https://git-wip- us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.2. 1 Source release revision 3492 (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.2.1/ PGP release keys (signed using RSA Key ID = 42443AA1): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Vote will be open for 72 hours (until 11/15 End of day PST). For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why)
RE: [VOTE] Release Apache CloudStack 4.2.1
-Original Message-
From: Marcus Sorensen [mailto:shadow...@gmail.com]
Sent: Thursday, November 14, 2013 11:42 PM
To: dev@cloudstack.apache.org
Cc: Radhika Puthiyetath
Subject: Re: [VOTE] Release Apache CloudStack 4.2.1
Ok, that may be my fault as I've got various 4.2.0 systems built from testing
various RCs. I just chose one and tried to upgrade it. Thanks for clearing that
up.
Animesh So Marcus this is not a -1 then right?
On Fri, Nov 15, 2013 at 12:14 AM, Abhinandan Prateek
abhinandan.prat...@citrix.com wrote:
Marcus,
I am trying to understand the upgrade issue that you are facing.
It seems there were changes during various rounds of RC that we had
for
4.2.0 .
The fix that you have mentioned in the email actually got introduced
in the 4.2 GA.
So someone upgrading to 4.2 GA will not have that constraint on the
vpc_service_map table.
Just for clarity this does not affect the upgrade from 4.2 GA to 4.2.1.
If you have any doubts please specify those with clarity so these it
can get rectified at the earliest.
David,
I think it is still not a ³-1².
-abhi
On 15/11/13 10:40 am, Marcus Sorensen shadow...@gmail.com wrote:
Yes, I'd say that upgrade from 4.2.0 to 4.2.1 needs to work.
On Nov 14, 2013 5:58 PM, David Nalley da...@gnsa.us wrote:
Marcus:
Is this is a -1?
I don't have any legal concerns, and the release builds and tests
for me (though I haven't tried VPC). I am somewhat concerned about
what appears to be drifting away from adhering to semver. (features
appear to have made it into the 4.2.1 release that weren't in 4.2.0)
and I am also concerned about sys vm update fatigue, especially
given the problems we had in 4.2.0 around sysvm updates.
--David
On Thu, Nov 14, 2013 at 1:08 PM, Marcus Sorensen
shadow...@gmail.com
wrote:
Yeah, I understand that 4.2.0 had a lot of post-release work needed.
We are unable to create VPNs. This is reported second hand from
one of my admins. He seems to think that it was caused by the
following, which added a for loop inside a for loop. The error is:
'com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationExc
epti
on:
Duplicate entry '146-Lb' for key 'vpc_id'
We did the following to fix it, something should be added to the
sql
upgrade.
mysql -D cloud -t -e 'alter table vpc_service_map drop key vpc_id,
add unique key vpc_id (vpc_id,service,provider)'
commit 9050cfad3da673370d6ad1ed7570e31314069996
CLOUDSTACK-4704: 41-42 db upgrade - populate vpc_service_map
table with the services/providers supported by VPC
@Override
@DB
-public void persistVpcServiceProviders(long vpcId, MapString,
String serviceProviderMap) {
+public void persistVpcServiceProviders(long vpcId,
+ MapString,
ListString serviceProviderMap) {
Transaction txn = Transaction.currentTxn();
txn.start();
for (String service : serviceProviderMap.keySet()) {
-VpcServiceMapVO serviceMap = new VpcServiceMapVO(vpcId,
Network.Service.getService(service),
Network.Provider.getProvider(serviceProviderMap.get(service)));
-_vpcSvcMap.persist(serviceMap);
+for (String provider : serviceProviderMap.get(service)) {
+VpcServiceMapVO serviceMap = new
VpcServiceMapVO(vpcId, Network.Service.getService(service),
Network.Provider.getProvider(provider));
+_vpcSvcMap.persist(serviceMap);
+}
}
txn.commit();
}
On Thu, Nov 14, 2013 at 9:40 AM, Daan Hoogland
daan.hoogl...@gmail.com
wrote:
+1 binding (I had not been clear on this in this thread it seems)
On Thu, Nov 14, 2013 at 6:05 AM, Abhinandan Prateek
abhinandan.prat...@citrix.com wrote:
Marcus,
Just summarising your concerns so that they can be followed upon:
1. Due to a VR script change a restart of VR is required. This
should
be
noted down in upgrade instructions in RN. (Radhika to note) 2.
For a maintenance release we should limit the scope to only
blockers. I
guess what is done is done probably for better as the main
release
had
so
many new features that a whole lot fixes were expected in the
maintenance
release. But again for further maintenance releases scope should
be restricted to important fixes.
Any other thing that has been missed ?
-abhi
On 14/11/13 12:06 am, Marcus Sorensen shadow...@gmail.com wrote:
I'm unable to deploy virtual machines after upgrading an
existing
4.2.0 to this release.
It looks like the file savepassword.sh was added at the end of
October
as a virtual router script. This would likely mean that people
upgrading to 4.2.1 will need to upgrade/redeploy their routers.
I
can
verify that deploy works if I reboot the router.
Looking over the current state of 4.2, I'm actually pretty
surprised at how much has changed. I'm seeing lots of whitespace
fixes,
changes
Re: [VOTE] Release Apache CloudStack 4.2.1
As long as we document the router reboot requirement in the release
notes, yes, I'm +1.
On a side note, we have an upgradeRouterScripts API call (in our
plugin) that just scps the new systemvm tar up to a given router and
extracts it, which allows us to avoid reboots, but we've been leary of
pushing it as a feature because we only use it on things that we know
don't need service restarts (this new savepassword.sh is a good
example). In other words it's not really end-user friendly. We should
put something like this on the list for improvements next time around,
if we can come up with a way to reinitialize the cloud-early init
service.
On Fri, Nov 15, 2013 at 4:30 PM, Animesh Chaturvedi
animesh.chaturv...@citrix.com wrote:
-Original Message-
From: Marcus Sorensen [mailto:shadow...@gmail.com]
Sent: Thursday, November 14, 2013 11:42 PM
To: dev@cloudstack.apache.org
Cc: Radhika Puthiyetath
Subject: Re: [VOTE] Release Apache CloudStack 4.2.1
Ok, that may be my fault as I've got various 4.2.0 systems built from testing
various RCs. I just chose one and tried to upgrade it. Thanks for clearing
that up.
Animesh So Marcus this is not a -1 then right?
On Fri, Nov 15, 2013 at 12:14 AM, Abhinandan Prateek
abhinandan.prat...@citrix.com wrote:
Marcus,
I am trying to understand the upgrade issue that you are facing.
It seems there were changes during various rounds of RC that we had
for
4.2.0 .
The fix that you have mentioned in the email actually got introduced
in the 4.2 GA.
So someone upgrading to 4.2 GA will not have that constraint on the
vpc_service_map table.
Just for clarity this does not affect the upgrade from 4.2 GA to 4.2.1.
If you have any doubts please specify those with clarity so these it
can get rectified at the earliest.
David,
I think it is still not a ³-1².
-abhi
On 15/11/13 10:40 am, Marcus Sorensen shadow...@gmail.com wrote:
Yes, I'd say that upgrade from 4.2.0 to 4.2.1 needs to work.
On Nov 14, 2013 5:58 PM, David Nalley da...@gnsa.us wrote:
Marcus:
Is this is a -1?
I don't have any legal concerns, and the release builds and tests
for me (though I haven't tried VPC). I am somewhat concerned about
what appears to be drifting away from adhering to semver. (features
appear to have made it into the 4.2.1 release that weren't in 4.2.0)
and I am also concerned about sys vm update fatigue, especially
given the problems we had in 4.2.0 around sysvm updates.
--David
On Thu, Nov 14, 2013 at 1:08 PM, Marcus Sorensen
shadow...@gmail.com
wrote:
Yeah, I understand that 4.2.0 had a lot of post-release work needed.
We are unable to create VPNs. This is reported second hand from
one of my admins. He seems to think that it was caused by the
following, which added a for loop inside a for loop. The error is:
'com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationExc
epti
on:
Duplicate entry '146-Lb' for key 'vpc_id'
We did the following to fix it, something should be added to the
sql
upgrade.
mysql -D cloud -t -e 'alter table vpc_service_map drop key vpc_id,
add unique key vpc_id (vpc_id,service,provider)'
commit 9050cfad3da673370d6ad1ed7570e31314069996
CLOUDSTACK-4704: 41-42 db upgrade - populate vpc_service_map
table with the services/providers supported by VPC
@Override
@DB
-public void persistVpcServiceProviders(long vpcId, MapString,
String serviceProviderMap) {
+public void persistVpcServiceProviders(long vpcId,
+ MapString,
ListString serviceProviderMap) {
Transaction txn = Transaction.currentTxn();
txn.start();
for (String service : serviceProviderMap.keySet()) {
-VpcServiceMapVO serviceMap = new VpcServiceMapVO(vpcId,
Network.Service.getService(service),
Network.Provider.getProvider(serviceProviderMap.get(service)));
-_vpcSvcMap.persist(serviceMap);
+for (String provider : serviceProviderMap.get(service)) {
+VpcServiceMapVO serviceMap = new
VpcServiceMapVO(vpcId, Network.Service.getService(service),
Network.Provider.getProvider(provider));
+_vpcSvcMap.persist(serviceMap);
+}
}
txn.commit();
}
On Thu, Nov 14, 2013 at 9:40 AM, Daan Hoogland
daan.hoogl...@gmail.com
wrote:
+1 binding (I had not been clear on this in this thread it seems)
On Thu, Nov 14, 2013 at 6:05 AM, Abhinandan Prateek
abhinandan.prat...@citrix.com wrote:
Marcus,
Just summarising your concerns so that they can be followed upon:
1. Due to a VR script change a restart of VR is required. This
should
be
noted down in upgrade instructions in RN. (Radhika to note) 2.
For a maintenance release we should limit the scope to only
blockers. I
guess what is done is done probably for better as the main
release
had
so
many new features that a whole lot fixes were expected in the
maintenance
RE: [VOTE] Release Apache CloudStack 4.2.1
-Original Message-
From: Marcus Sorensen [mailto:shadow...@gmail.com]
Sent: Friday, November 15, 2013 4:19 PM
To: dev@cloudstack.apache.org
Cc: Radhika Puthiyetath
Subject: Re: [VOTE] Release Apache CloudStack 4.2.1
As long as we document the router reboot requirement in the release notes, yes,
I'm +1.
Animesh Yes that should be in release notes
On a side note, we have an upgradeRouterScripts API call (in our
plugin) that just scps the new systemvm tar up to a given router and extracts
it, which allows us to avoid reboots, but we've been leary of pushing it as a
feature because we only use it on things that we know don't need service
restarts (this new savepassword.sh is a good example). In other words it's not
really end-user friendly. We should put something like this on the list for
improvements next time around, if we can come up with a way to reinitialize the
cloud-early init service
Animesh Do you want to start a separate thread on it. Master is now open for
4.4 enhancements and features
On Fri, Nov 15, 2013 at 4:30 PM, Animesh Chaturvedi
animesh.chaturv...@citrix.com wrote:
-Original Message-
From: Marcus Sorensen [mailto:shadow...@gmail.com]
Sent: Thursday, November 14, 2013 11:42 PM
To: dev@cloudstack.apache.org
Cc: Radhika Puthiyetath
Subject: Re: [VOTE] Release Apache CloudStack 4.2.1
Ok, that may be my fault as I've got various 4.2.0 systems built from testing
various RCs. I just chose one and tried to upgrade it. Thanks for clearing
that up.
Animesh So Marcus this is not a -1 then right?
On Fri, Nov 15, 2013 at 12:14 AM, Abhinandan Prateek
abhinandan.prat...@citrix.com wrote:
Marcus,
I am trying to understand the upgrade issue that you are facing.
It seems there were changes during various rounds of RC that we had
for
4.2.0 .
The fix that you have mentioned in the email actually got introduced
in the 4.2 GA.
So someone upgrading to 4.2 GA will not have that constraint on the
vpc_service_map table.
Just for clarity this does not affect the upgrade from 4.2 GA to 4.2.1.
If you have any doubts please specify those with clarity so these it
can get rectified at the earliest.
David,
I think it is still not a ³-1².
-abhi
On 15/11/13 10:40 am, Marcus Sorensen shadow...@gmail.com wrote:
Yes, I'd say that upgrade from 4.2.0 to 4.2.1 needs to work.
On Nov 14, 2013 5:58 PM, David Nalley da...@gnsa.us wrote:
Marcus:
Is this is a -1?
I don't have any legal concerns, and the release builds and tests
for me (though I haven't tried VPC). I am somewhat concerned about
what appears to be drifting away from adhering to semver. (features
appear to have made it into the 4.2.1 release that weren't in
4.2.0) and I am also concerned about sys vm update fatigue,
especially given the problems we had in 4.2.0 around sysvm updates.
--David
On Thu, Nov 14, 2013 at 1:08 PM, Marcus Sorensen
shadow...@gmail.com
wrote:
Yeah, I understand that 4.2.0 had a lot of post-release work needed.
We are unable to create VPNs. This is reported second hand from
one of my admins. He seems to think that it was caused by the
following, which added a for loop inside a for loop. The error is:
'com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationEx
c
epti
on:
Duplicate entry '146-Lb' for key 'vpc_id'
We did the following to fix it, something should be added to the
sql
upgrade.
mysql -D cloud -t -e 'alter table vpc_service_map drop key
vpc_id, add unique key vpc_id (vpc_id,service,provider)'
commit 9050cfad3da673370d6ad1ed7570e31314069996
CLOUDSTACK-4704: 41-42 db upgrade - populate vpc_service_map
table with the services/providers supported by VPC
@Override
@DB
-public void persistVpcServiceProviders(long vpcId, MapString,
String serviceProviderMap) {
+public void persistVpcServiceProviders(long vpcId,
+ MapString,
ListString serviceProviderMap) {
Transaction txn = Transaction.currentTxn();
txn.start();
for (String service : serviceProviderMap.keySet()) {
-VpcServiceMapVO serviceMap = new VpcServiceMapVO(vpcId,
Network.Service.getService(service),
Network.Provider.getProvider(serviceProviderMap.get(service)));
-_vpcSvcMap.persist(serviceMap);
+for (String provider : serviceProviderMap.get(service)) {
+VpcServiceMapVO serviceMap = new
VpcServiceMapVO(vpcId, Network.Service.getService(service),
Network.Provider.getProvider(provider));
+_vpcSvcMap.persist(serviceMap);
+}
}
txn.commit();
}
On Thu, Nov 14, 2013 at 9:40 AM, Daan Hoogland
daan.hoogl...@gmail.com
wrote:
+1 binding (I had not been clear on this in this thread it
+seems)
On Thu, Nov 14, 2013 at 6:05 AM, Abhinandan Prateek
abhinandan.prat...@citrix.com wrote:
Marcus,
Just summarising your concerns
Re: [VOTE] Release Apache CloudStack 4.2.1
For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) +1 (binding) (with the assumption that we won't announce until after docs are finished) Verified sigs and hashes, checked rat run, built, ran unit tests, built RPMs and tested some simple VM lifecycle --David
Re: Trunk interface to VM
You want to pass the vlan tags into a VM that is actually a XenServer? On 11/14/13 3:02 PM, Francois Gaudreault fgaudrea...@cloudops.com wrote: Is there a way to assign a trunked interface to a VM running in CS? Like assign the entire guest interface. We have a use case where we need to run XenServer hosts within a cloudstack managed infra. Thanks! Francois
Re: A question on vm migrations when hosts are set into a maintenance mode.
Alex, Could you just do a git blame on the file and copy the emails of
people who changed that bit of code? They may be able to help if Cc-ed
directly.
Thanks,
On Fri, Nov 15, 2013 at 01:49:07PM -0600, Alex Ough wrote:
I hate to sending the same emails over and over again, but I really need to
finalize this feature to be included in the next code freeze because this
feature is very critical in our inside project.
Anyone who can help, please?
Thanks
Alex Ough
On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough alex.o...@sungard.com wrote:
Not sure if Alex Huang checked this, but can anyone help to resolve this?
Thanks
Alex Ough
On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough alex.o...@sungard.com wrote:
It sounds a little scary...
I looked at the history and found these.
8/9/ : file moved to engine by Alex Huang
9/16 : '_mgmtServer.getExecuteInSequence()' changed to
'getExecuteInSequence()' by Alex Huang
Hi Alex Huang,
I'm not sure if you're aware of this, but can you check this for me?
Thanks
Alex Ough
On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen
shadow...@gmail.comwrote:
I'm not sure. I know in the past when I've seen files change locations
it has also clobbered updates to that file. Someone branched, did the
reorganization work, and merged, while in-between the original file
changed.
On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough alex.o...@sungard.com
wrote:
All,
While merging my changes to 4.3 branch, I found that the option,
'execute.in.sequence.hypervisor.commands' is NOT used in
Start/Stop/Copy
commands in 'VirtualMachineManagerImpl.java' any more as below.
*StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
*protected boolean getExecuteInSequence() {*
* return false;*
*}*
As you see in the above, the function, 'getExecuteInSequence', just
returns
false instead of getting the value from the global variable.
And one more change is that the file has been moved to
'engine/orchestration/src/com/cloud/vm' from 'server/src/com/cloud/vm'.
Am I missing something related with this or do we stop supporting this
option in 4.3?
I'm a little confused, so please help me resolve this.
Thanks
Alex Ough
On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough alex.o...@sungard.com
wrote:
Thanks a lot for your confirmation, Marcus.
I'll create a review request unless anyone has an objection.
Thanks
Alex Ough
On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen shadow...@gmail.com
wrote:
I have done parallel KVM migrations without issue, it's supposed to
work. Really I think it's in the same boat as parallel start/stop.
It
should work, but the config option is there just in case. I think we
should add it.
On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
chip.child...@sungard.com wrote:
On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
I'm not sure what else commands 'MigrateCommand' actually execute
in
addition to 'Start/Stop/CopyCommand', but can we include
'MigrateCommand'
if it consists of only those 3 commands?
Thanks
Alex Ough
In the case of VMware, the migrate command is executed via the
MigrateVMTask that's part of the VMware SDK (see
vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
For VMware, I know that vCenter will queue and process concurrent
requests for migrations. Specifically, it will throttle the
migrations
happening, based on it's internal concurrency constraints, but the
task
queue will still accept more connections. Obviously the risk are
the
VMware layer tasks timing out if it takes too long for the task
queue to
complete.
As for XenServer, it's happening in what appears to be a similar
way
(although the source host is the target for the migration API
call).
Check
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
I'm not familiar enough with XenServer's concurrency model for
migrations. Any experts know the answer to if it can handle
concurrency
in a stable way?
With KVM, it's obviously executing via the agent. Similarly to
XenServer, I'm not familiar enough to know about concurrent
operations.
So do the HV experts on the list have any opinions about XenServer
and
KVM migration concurrency?
-chip
--
Prasanna.,
Powered by BigRock.com
Re: Upgrading nitro API to 10.1
On Fri, Nov 15, 2013 at 01:36:49PM -0500, Syed Ahmed wrote: Hi All, I was wondering if it was possible to update the nitro packet which is required for Netscaler API from 10.0 to 10.1. The new 10.1 supports the bundle parameter which makes it possible to upload certificate and the trust chain in a single file which makes it very easy for certificate management. q1. Is this a jar update? q2. Is the corresponding source here - https://github.com/netscaler/nitro? Thanks, -Syed -- Prasanna., Powered by BigRock.com
Re: Upgrading nitro API to 10.1
Yes Prasanna. This is a jar upgrade and yes that is the source code. This means that we could remove the noredist from netscaler plugin. Thanks, -Syed On Fri 15 Nov 2013 10:26:51 PM EST, Prasanna Santhanam wrote: On Fri, Nov 15, 2013 at 01:36:49PM -0500, Syed Ahmed wrote: Hi All, I was wondering if it was possible to update the nitro packet which is required for Netscaler API from 10.0 to 10.1. The new 10.1 supports the bundle parameter which makes it possible to upload certificate and the trust chain in a single file which makes it very easy for certificate management. q1. Is this a jar update? q2. Is the corresponding source here - https://github.com/netscaler/nitro? Thanks, -Syed
Re: Upgrading nitro API to 10.1
that should be ok - i was supposed to have moved the netscaler plugin from noredist to oss but never got around to it. would you be able to take that up as part of your change? On Fri, Nov 15, 2013 at 10:29:56PM -0500, Syed Ahmed wrote: Yes Prasanna. This is a jar upgrade and yes that is the source code. This means that we could remove the noredist from netscaler plugin. Thanks, -Syed -- Prasanna., Powered by BigRock.com
Re: Upgrading nitro API to 10.1
Sure. No problems. Thanks, -Syed On Fri 15 Nov 2013 10:35:04 PM EST, Prasanna Santhanam wrote: that should be ok - i was supposed to have moved the netscaler plugin from noredist to oss but never got around to it. would you be able to take that up as part of your change? On Fri, Nov 15, 2013 at 10:29:56PM -0500, Syed Ahmed wrote: Yes Prasanna. This is a jar upgrade and yes that is the source code. This means that we could remove the noredist from netscaler plugin. Thanks, -Syed
Re: Upgrading nitro API to 10.1
awesome. thanks syed! On Fri, Nov 15, 2013 at 10:39:18PM -0500, Syed Ahmed wrote: Sure. No problems. Thanks, -Syed On Fri 15 Nov 2013 10:35:04 PM EST, Prasanna Santhanam wrote: that should be ok - i was supposed to have moved the netscaler plugin from noredist to oss but never got around to it. would you be able to take that up as part of your change? On Fri, Nov 15, 2013 at 10:29:56PM -0500, Syed Ahmed wrote: Yes Prasanna. This is a jar upgrade and yes that is the source code. This means that we could remove the noredist from netscaler plugin. Thanks, -Syed -- Prasanna., Powered by BigRock.com
Re: Upgrading nitro API to 10.1
@Syed: I just did that for the Palo Alto plugin, so let me know if you have questions... Will On Fri, Nov 15, 2013 at 10:42 PM, Prasanna Santhanam t...@apache.org wrote: awesome. thanks syed! On Fri, Nov 15, 2013 at 10:39:18PM -0500, Syed Ahmed wrote: Sure. No problems. Thanks, -Syed On Fri 15 Nov 2013 10:35:04 PM EST, Prasanna Santhanam wrote: that should be ok - i was supposed to have moved the netscaler plugin from noredist to oss but never got around to it. would you be able to take that up as part of your change? On Fri, Nov 15, 2013 at 10:29:56PM -0500, Syed Ahmed wrote: Yes Prasanna. This is a jar upgrade and yes that is the source code. This means that we could remove the noredist from netscaler plugin. Thanks, -Syed -- Prasanna., Powered by BigRock.com
Re: Upgrading nitro API to 10.1
Thanks Will. Will Do. On Fri 15 Nov 2013 10:52:27 PM EST, Will Stevens wrote: @Syed: I just did that for the Palo Alto plugin, so let me know if you have questions... Will On Fri, Nov 15, 2013 at 10:42 PM, Prasanna Santhanam t...@apache.org mailto:t...@apache.org wrote: awesome. thanks syed! On Fri, Nov 15, 2013 at 10:39:18PM -0500, Syed Ahmed wrote: Sure. No problems. Thanks, -Syed On Fri 15 Nov 2013 10:35:04 PM EST, Prasanna Santhanam wrote: that should be ok - i was supposed to have moved the netscaler plugin from noredist to oss but never got around to it. would you be able to take that up as part of your change? On Fri, Nov 15, 2013 at 10:29:56PM -0500, Syed Ahmed wrote: Yes Prasanna. This is a jar upgrade and yes that is the source code. This means that we could remove the noredist from netscaler plugin. Thanks, -Syed -- Prasanna., Powered by BigRock.com
Re: Trunk interface to VM
Yes. We want to be able spin XS within CloudStack. We also need those XS to consume VLAN tags to do advanced networking (kind of CS inside CS). Lets say we do have devs with ambitious needs :) Francois On 2013-11-15 9:46 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: You want to pass the vlan tags into a VM that is actually a XenServer? On 11/14/13 3:02 PM, Francois Gaudreault fgaudrea...@cloudops.com wrote: Is there a way to assign a trunked interface to a VM running in CS? Like assign the entire guest interface. We have a use case where we need to run XenServer hosts within a cloudstack managed infra. Thanks! Francois
