[Doc] Developer Guide API Section for Review
Hi, Developer Guide API section is ready for review. The doc is attached at https://issues.apache.org/jira/browse/CLOUDSTACK-3546 Please see section4.1. What's New in the API for 4.2, and provide your feedback. Also, please let me know other than the API changes what you think what should be covered in the What's New Section. Regards -Radhika
is jira down. ?
[Doc] Limiting Resource Usage Section for Review
Hi, Limiting Resource Usage is ready for review. The doc is attached at CLOUDSTACK-713https://issues.apache.org/jira/browse/CLOUDSTACK-713 Please see section 14.4. Limiting Resource Usage (118), and provide your feedback. Regards -Radhika
RE: is jira down. ?
Jira is up now. Looks like there was an issue with plugin and somebody Fixed it. Thanks Rajesh Battala -Original Message- From: Rajesh Battala [mailto:rajesh.batt...@citrix.com] Sent: Monday, August 5, 2013 12:19 PM To: dev@cloudstack.apache.org Subject: is jira down. ?
Re: Review Request 12934: Tests for egress firewall rules for advance zone
On Aug. 2, 2013, 10:29 a.m., Jayapal Reddy wrote: test/integration/component/test_egress_fw_rules.py, line 55 https://reviews.apache.org/r/12934/diff/4/?file=332296#file332296line55 I appreciate your effort in correcting the test cases. There are few comments from my side. Please fix those. Also the script is failed to run.Also look into this. The below exception is thrown integration.component.test_egress_fw_rules.log_test_exceptions ... ERROR == ERROR: integration.component.test_egress_fw_rules.log_test_exceptions -- Traceback (most recent call last): File /Library/Python/2.7/site-packages/nose/case.py, line 197, in runTest self.test(*self.arg) TypeError: log_test_exceptions() takes exactly 1 argument (0 given) Ashutosh Kelkar wrote: I am able to run the script without any issue. python2.7 -m marvin.deployAndRun -c $TESTPATH/run.cfg -d $TESTPATH -r /var/log/cs4.2.x-result.log -t /var/log/cs4.2.x-client.log -l testpid=$! tail --pid $testpid -f /var/log/cs4.2.x-result.log /var/log/cs4.2.x-client.log Let me know if you are still facing issues running the tests. The reason why this won't run using nosetests is that the testrunner in nose needs the testnames to start with the test_ prefix. When you wrap the decorator over each test the name of the method changes. Check the test_assign_vm.py where I made the fix. Since you are using the logger decorator often why not also move it to the utils/common module? - Prasanna --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12934/#review24517 --- On Aug. 1, 2013, 6:19 a.m., Ashutosh Kelkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12934/ --- (Updated Aug. 1, 2013, 6:19 a.m.) Review request for cloudstack, Girish Shilamkar, Jayapal Reddy, and Prasanna Santhanam. Repository: cloudstack-git Description --- Tests for egress firewall rules for advance zone. Diffs - test/integration/component/test_egress_fw_rules.py PRE-CREATION Diff: https://reviews.apache.org/r/12934/diff/ Testing --- Thanks, Ashutosh Kelkar
RE: Reverting 17267794adb2bab923fb20515a7b943780d61921
+1. Provided git allows to make a specific file as read-only. -Original Message- From: Nitin Mehta [mailto:nitin.me...@citrix.com] Sent: Monday, August 05, 2013 12:01 PM To: dev@cloudstack.apache.org; Saksham Srivastava Subject: Re: Reverting 17267794adb2bab923fb20515a7b943780d61921 Should we not try and enforce it through git ? On 02/08/13 10:44 PM, Alex Huang alex.hu...@citrix.com wrote: Ok...i spoke too soon. Just talked with Prasanna. He pointed out that it's a large change that's been in since May. So I won't revert it. But the rule is no one can change create-schema.sql until the community decided we want to based off of a new copy of the create-schema. --Alex -Original Message- From: Alex Huang [mailto:alex.hu...@citrix.com] Sent: Friday, August 2, 2013 10:01 AM To: Saksham Srivastava Cc: dev@cloudstack.apache.org Subject: Reverting 17267794adb2bab923fb20515a7b943780d61921 Saksham, I'm reverting commit id: 17267794adb2bab923fb20515a7b943780d61921 in master. It changed the create-schema.sql. We've established since 4.1 that create- schema.sql should not be changed and everything done through upgrades. I believe this commit causes a fresh deployment to fail. --Alex
[Discuss] Using XenServer 6.2's Clone-on-Boot feature on CloudStack
Hi guys, Is anyone concerned about using XenServer 6.2's clone-on-boot feature on CloudStack? With it, we can quickly deploy a huge of VMs from a single golden template. This is amazing for some scenarios. For example: we can allocate a special/dedicated cluster with only one golden template. And when an update or patch be applied to golden template, changes automatically apply to every VMs. Thought? Thanks, -- N.g.U.y.e.N.A.n.H.t.U
RE: [DISCUSS] [jira] make affectedVersion field mandatory.....
-Original Message- From: Prasanna Santhanam [mailto:t...@apache.org] Sent: 02 August 2013 23:36 To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] [jira] make affectedVersion field mandatory. On Fri, Aug 02, 2013 at 11:06:53AM +, Ram Ganesh wrote: Hi, While triaging bugs I noticed that many bugs had affectedVersion field as empty. This makes it difficult to guess the version/release the reporter was on while filing the bug. Can we make the affectedVersion field a mandatory field instead? Indeed this would be nice to have. But the reason I think we are not seeing it is not knowing what the affectsVersion should be. Bugs are coming from: 1) Users reporting from the field 2) QA filing bugs from jenkins builds 3) Bugs encountered on master faced by those working on code Those in 1) usually add the information to their description. But could use a command line method to extract this information to make reports clearer. Alex made an enhancement to add this to the jar's manifest. But it's still not something that can be extracted easily. Those in 2) don't know if an unreleased -SNAPSHOT version of the build would need to be put in the affectsVersion and if so what the HEAD of the build is. Again a tool would help. Because one who fixes the bug will almost *always* need the commit-sha1, without which reproducing the bug can be tough. and those in 3) don't have any option on JIRA so I've started to set affectsVersion to 'Future' to denote master and add the HEAD of my repo in the description. I notice these can get improperly triaged. Prasanna, For starters one need to populate just the release numbers like 4.1. or 4.2 or 4.2+( if it is from master and release number is still agreed on). I am sure users would know the specific release number the problem was noticed. -- Prasanna., Powered by BigRock.com
Re: is jira down. ?
Jira is down again. Thanks, Jayapal On 05-Aug-2013, at 12:25 PM, Rajesh Battala rajesh.batt...@citrix.commailto:rajesh.batt...@citrix.com wrote: Jira is up now. Looks like there was an issue with plugin and somebody Fixed it. Thanks Rajesh Battala -Original Message- From: Rajesh Battala [mailto:rajesh.batt...@citrix.comhttp://citrix.com] Sent: Monday, August 5, 2013 12:19 PM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: is jira down. ?
Deleting affinity group while it's still in use
Hi all, Suppose I create affinity group and deploy vm which obeys this affinity rule. Now If I delete the affinity group even when it's in use by the vm, it gets deleted , and then I can't see that affinity group in vm's affinity group list. Is this a valid behavior? One of the test cases tries to check this should not happen. Regards, Gaurav
api calls in 4.1.1
H, What is the status of 4.1.1 at this moment. I am getting several reports of api calls not working as before. I saw the vote passing by but didn't give them much attention. In jira I don't see much mention of such issues. Is this noticed by anybosy else? regards, Daan
RE: [Doc] PVLAN Doc is Ready for Review
The comments are incorporated. Please see https://issues.apache.org/jira/browse/CLOUDSTACK-850 -Radhika -Original Message- From: Sheng Yang [mailto:sh...@yasker.org] Sent: Saturday, August 03, 2013 1:54 AM To: dev@cloudstack.apache.org Cc: us...@cloudstack.apache.org; Sudha Ponnaganti Subject: Re: [Doc] PVLAN Doc is Ready for Review Hi Radhika, Thank you for your work! Some comments: quote For other Catalyst PVLAN support switch, connect the switch to upper switch by using cables. The number of cables should be greater than the number of PVLANs used. /quote This is a little confusion. Should be by using multiple cables, which one cable for each PVLAN pair. And the last sentence is not necessary. quote OVS on XenServer and KVM does not support PVLAN. Therefore, simulate PVLAN on OVS for XenServer and KVM by modifying the flow table and tagging every traffic leaving guest VMs with the secondary VLAN ID. /quote I think the following description is more clear: OVS on XenServer and KVM does not support PVLAN natively. Therefore, CloudStack managed to simulate PVLAN on OVS for XenServer and KVM by modifying the flow table. --Sheng On Fri, Aug 2, 2013 at 5:18 AM, Radhika Puthiyetath radhika.puthiyet...@citrix.com wrote: Hi, PVLAN documentation is ready for review. The doc is attached at https://issues.apache.org/jira/browse/CLOUDSTACK-850. Please see 15.14. Isolation in Advanced Zone Using Private VLAN (141), and provide your feedback. Regards -Radhika
Re: [DISCUSS] [jira] make affectedVersion field mandatory.....
+1. It would be good to have a default field probably as well ? I would also want to have the fixVersion having default field and the release manager accordingly triaging it. I recently saw some of my bugs missed this information and the UI team didn't notice it. On 05/08/13 12:57 PM, Ram Ganesh ram.gan...@citrix.com wrote: -Original Message- From: Prasanna Santhanam [mailto:t...@apache.org] Sent: 02 August 2013 23:36 To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] [jira] make affectedVersion field mandatory. On Fri, Aug 02, 2013 at 11:06:53AM +, Ram Ganesh wrote: Hi, While triaging bugs I noticed that many bugs had affectedVersion field as empty. This makes it difficult to guess the version/release the reporter was on while filing the bug. Can we make the affectedVersion field a mandatory field instead? Indeed this would be nice to have. But the reason I think we are not seeing it is not knowing what the affectsVersion should be. Bugs are coming from: 1) Users reporting from the field 2) QA filing bugs from jenkins builds 3) Bugs encountered on master faced by those working on code Those in 1) usually add the information to their description. But could use a command line method to extract this information to make reports clearer. Alex made an enhancement to add this to the jar's manifest. But it's still not something that can be extracted easily. Those in 2) don't know if an unreleased -SNAPSHOT version of the build would need to be put in the affectsVersion and if so what the HEAD of the build is. Again a tool would help. Because one who fixes the bug will almost *always* need the commit-sha1, without which reproducing the bug can be tough. and those in 3) don't have any option on JIRA so I've started to set affectsVersion to 'Future' to denote master and add the HEAD of my repo in the description. I notice these can get improperly triaged. Prasanna, For starters one need to populate just the release numbers like 4.1. or 4.2 or 4.2+( if it is from master and release number is still agreed on). I am sure users would know the specific release number the problem was noticed. -- Prasanna., Powered by BigRock.com
Re: Review Request 13240: dealt with some warnings in NetworkServiceImpl
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13240/ --- (Updated Aug. 5, 2013, 9:36 a.m.) Review request for cloudstack and Sheng Yang. Changes --- adding Sheng Repository: cloudstack-git Description --- dealt with some warnings in NetworkServiceImpl Diffs - server/src/com/cloud/network/NetworkServiceImpl.java ff753f4 Diff: https://reviews.apache.org/r/13240/diff/ Testing --- Thanks, daan Hoogland
Re: Review Request 12934: Tests for egress firewall rules for advance zone
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12934/#review24640 --- test/integration/component/test_egress_fw_rules.py https://reviews.apache.org/r/12934/#comment48746 remove the white space (red colour). Please apply the patch in your local and make sure there is no warning. # git apply patchName.patch test/integration/component/test_egress_fw_rules.py https://reviews.apache.org/r/12934/#comment48747 do we need specify vlan here ? test/integration/component/test_egress_fw_rules.py https://reviews.apache.org/r/12934/#comment48748 Hard coding vlan may not work for others setups. If specify vlan is set then query the free vlan id - Jayapal Reddy On Aug. 1, 2013, 6:19 a.m., Ashutosh Kelkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12934/ --- (Updated Aug. 1, 2013, 6:19 a.m.) Review request for cloudstack, Girish Shilamkar, Jayapal Reddy, and Prasanna Santhanam. Repository: cloudstack-git Description --- Tests for egress firewall rules for advance zone. Diffs - test/integration/component/test_egress_fw_rules.py PRE-CREATION Diff: https://reviews.apache.org/r/12934/diff/ Testing --- Thanks, Ashutosh Kelkar
Re: Review Request 12849: added backwards compatibility code to Networks enums
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12849/ --- (Updated Aug. 5, 2013, 9:57 a.m.) Review request for cloudstack, Chiradeep Vittal, Koushik Das, and Sheng Yang. Changes --- A more permanent take on toUri, using member-methods per value. Repository: cloudstack-git Description --- Both BroadcastDomainType and IsolationType needed some extra code for backwards compatibility Diffs (updated) - api/src/com/cloud/network/Networks.java c76c3d4 api/test/com/cloud/network/NetworksTest.java 31114e8 Diff: https://reviews.apache.org/r/12849/diff/ Testing --- Thanks, daan Hoogland
Re: Review Request 13240: dealt with some warnings in NetworkServiceImpl
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13240/ --- (Updated Aug. 5, 2013, 9:59 a.m.) Review request for cloudstack, Chiradeep Vittal and Sheng Yang. Changes --- added chiradeep Repository: cloudstack-git Description --- dealt with some warnings in NetworkServiceImpl Diffs - server/src/com/cloud/network/NetworkServiceImpl.java ff753f4 Diff: https://reviews.apache.org/r/13240/diff/ Testing --- Thanks, daan Hoogland
4.1.1 released yet? RPMs?
Hi All, is 4.1.1 officially released? Where are / will be the RPMs and documentation for upgrading form 4.1.0? Regards, F.
database upgrade
H,
What is the policy for adding upgrade paths?
I am working on upgrade from 4.1.1 already.
So when do we add
_upgradeMap.put(4.1.1, new DbUpgrade[] { new
Upgrade410to420(), new Upgrade420to430() });
to DatabaseUpgradeChecker?
thanks,
Daan
Re: Review Request 13223: (CLOUDSTACK-2729) use file lock to prevent concurrent refreshPool/deleteVolume on KVM shared storage pool
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13223/ --- (Updated Aug. 5, 2013, 10:38 a.m.) Review request for cloudstack, edison su and Wido den Hollander. Changes --- use atom semantics lock and unlock. Thank Edison! Bugs: CLOUDSTACK-2729 Repository: cloudstack-git Description --- The storage pool issue (CLOUDSTACK-2729) is because of a bug in libvirt (https://bugzilla.redhat.com/show_bug.cgi?id=977706) We need to prevent deleting a volume when refreshing the pool. This patch use a simple file lock to implement it. PS: I have tested another file lock similar to Read/Write file lock, but it was very unstable. Diffs (updated) - plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java a9baa52 Diff: https://reviews.apache.org/r/13223/diff/ Testing --- Applied on 4.0.2 and 4.0.1 Testing On 4.0.1 From 20,June 3 nodes, create a VM on each node every 15 minutes. Destroy the VMs 5 minutes later. expunge.inteval = 600 (10 minutes), expunge.worker = 2 Testing On 4.0.2 From 01,July 2 nodes, create two VMs on each node every 5 minutes. Destroy the VMs 4 minutes later. expunge.inteval = 600 (10 minutes), expunge.worker = 2 Thanks, Wei Zhou
unable to view content of cwiki
Hi All, Am not able to view any link of cwiki. Am getting permission denied to view any content. Please let me know how to resolve this issue. Thanks Rajesh Battala
Re: 4.1.1 released yet? RPMs?
Hi, No, it's not out there yet. The RPM and Deb packages will come online when the source has been released. It will be a minor upgrade, so it will just be a matter of installing the new packages and restarting the services. Wido On 08/05/2013 12:20 PM, France wrote: Hi All, is 4.1.1 officially released? Where are / will be the RPMs and documentation for upgrading form 4.1.0? Regards, F.
Review Request 13266: CLOUDSTACK-3925: Allow Root Admin to deploy VMs on Zone dedicated to any domain/account
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13266/ --- Review request for cloudstack, Devdeep Singh and Prachi Damle. Bugs: 3925 Repository: cloudstack-git Description --- Currently Root admin cannot deploy vms on a zone dedicated to sub-domain, the fix will ensure the private zone functionality is maintained. The fix allows root admin to deploy vms on zone dedicated to any other domain by both the methods: 1)Using affinity group Explicit Dedication 2)Not using any affinity group. Diffs - plugins/affinity-group-processors/explicit-dedication/src/org/apache/cloudstack/affinity/ExplicitDedicationProcessor.java a0eb56c server/src/com/cloud/deploy/DeploymentPlanningManagerImpl.java ebf2b0c server/test/com/cloud/vm/DeploymentPlanningManagerImplTest.java 10e23d7 Diff: https://reviews.apache.org/r/13266/diff/ Testing --- Root admin is now able to deploy vms on a zone dedicated to a sub domain. Build is successful. Thanks, Saksham Srivastava
Re: Review Request 13266: CLOUDSTACK-3925: Allow Root Admin to deploy VMs on Zone dedicated to any domain/account
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13266/#review24641 --- Review 13266 failed the build test : FAILURE The url of build cloudstack-master-with-patch #112 is : http://jenkins.cloudstack.org/job/cloudstack-master-with-patch/112/ - Jenkins Cloudstack.org On Aug. 5, 2013, 10:57 a.m., Saksham Srivastava wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13266/ --- (Updated Aug. 5, 2013, 10:57 a.m.) Review request for cloudstack, Devdeep Singh and Prachi Damle. Bugs: 3925 Repository: cloudstack-git Description --- Currently Root admin cannot deploy vms on a zone dedicated to sub-domain, the fix will ensure the private zone functionality is maintained. The fix allows root admin to deploy vms on zone dedicated to any other domain by both the methods: 1)Using affinity group Explicit Dedication 2)Not using any affinity group. Diffs - plugins/affinity-group-processors/explicit-dedication/src/org/apache/cloudstack/affinity/ExplicitDedicationProcessor.java a0eb56c server/src/com/cloud/deploy/DeploymentPlanningManagerImpl.java ebf2b0c server/test/com/cloud/vm/DeploymentPlanningManagerImplTest.java 10e23d7 Diff: https://reviews.apache.org/r/13266/diff/ Testing --- Root admin is now able to deploy vms on a zone dedicated to a sub domain. Build is successful. Thanks, Saksham Srivastava
Re: Review Request 12358: CLOUDSTACK-3228: system vms are not comming up in zone with two cluster xen and kvm
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12358/ --- (Updated Aug. 5, 2013, 11:12 a.m.) Review request for cloudstack and Nitin Mehta. Changes --- rebased with master Bugs: CLOUDSTACK-3228 and CLOUDSTACK-3631 Repository: cloudstack-git Description --- CLOUDSTACK-3228: system vms are not comming up in zone with two cluster xen and kvm;Zone host is ready, but secondary storage vm template: 3 is not ready on secondary storage: 2 CLOUDSTACK-3631: Enhance System vm deployment retry mechanism Diffs (updated) - engine/schema/src/com/cloud/storage/dao/VMTemplateDao.java c3d44bd engine/schema/src/com/cloud/storage/dao/VMTemplateDaoImpl.java 9e75990 server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 7c6fbd0 server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java b10fb7a Diff: https://reviews.apache.org/r/12358/diff/ Testing --- tested locally Thanks, Harikrishna Patnala
RE: Reverting 17267794adb2bab923fb20515a7b943780d61921
+1, Although I did not add/edit/remove any sql statements in this file, it was a blank line that got removed in my patch. Enforcing it would prevent such slips to happen. Saksham -Original Message- From: Koushik Das Sent: Monday, August 05, 2013 12:49 PM To: dev@cloudstack.apache.org; Saksham Srivastava Subject: RE: Reverting 17267794adb2bab923fb20515a7b943780d61921 +1. Provided git allows to make a specific file as read-only. -Original Message- From: Nitin Mehta [mailto:nitin.me...@citrix.com] Sent: Monday, August 05, 2013 12:01 PM To: dev@cloudstack.apache.org; Saksham Srivastava Subject: Re: Reverting 17267794adb2bab923fb20515a7b943780d61921 Should we not try and enforce it through git ? On 02/08/13 10:44 PM, Alex Huang alex.hu...@citrix.com wrote: Ok...i spoke too soon. Just talked with Prasanna. He pointed out that it's a large change that's been in since May. So I won't revert it. But the rule is no one can change create-schema.sql until the community decided we want to based off of a new copy of the create-schema. --Alex -Original Message- From: Alex Huang [mailto:alex.hu...@citrix.com] Sent: Friday, August 2, 2013 10:01 AM To: Saksham Srivastava Cc: dev@cloudstack.apache.org Subject: Reverting 17267794adb2bab923fb20515a7b943780d61921 Saksham, I'm reverting commit id: 17267794adb2bab923fb20515a7b943780d61921 in master. It changed the create-schema.sql. We've established since 4.1 that create- schema.sql should not be changed and everything done through upgrades. I believe this commit causes a fresh deployment to fail. --Alex
RE: [Discuss] Making CloudMonkey simpler to use for admin tasks
-Original Message- From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On Behalf Of Rohit Yadav Sent: 02 August 2013 22:43 To: dev@cloudstack.apache.org Subject: Re: [Discuss] Making CloudMonkey simpler to use for admin tasks On Thu, Aug 1, 2013 at 10:43 PM, Donal Lafferty donal.laffe...@citrix.comwrote: I needed a different configuration than DevCloud provided, so I turned to CloudMonkey to automate setup of my test environment. This led to a blog on automating with CloudMonkey at http://dlafferty.blogspot.co.uk/2013/07/using-cloudmonkey-to-automate. html Nice. What I forgot to mention is that automation would be a lot simpler if we were to do the following: 1. Update Apache CloudStack logging to provide API calls in a tidy format that can be fed directly. E.g. POST parameters are not logged, GET parameters are URL encoded. 2. Update CloudMonkey to allow username / password authentication +1, send patch :) How would you store the sessionkey? E.g. see written in C#: https://github.com/lafferty/cloudstack_dotnetsdk/blob/master/CloudStack.SDK/client.cs Specifically, see public void Login(string userName, string password, string domainName, bool hashPassword) 3. Update CloudMonkey to not be picky about the case of command parameters when 'api' command used. +1, send patch :) This is a one liner change, no? 4. Update CloudMonkey to allow filter option to be used with 'api' command. How do you propose using that, example? Example: apiresult=`cloudmonkey api createPhysicalNetwork zoneid=$zone name='Physical Network 1' isolationmethods='VLAN' ` physnetid=`echo $apiresult | sed -e 's/^.*id: //; s/,.*//'` becomes physnetid =`cloudmonkey filter=id api createPhysicalNetwork zoneid=$zone name='Physical Network 1' isolationmethods='VLAN' ` Regards.
Re: Review Request 12358: CLOUDSTACK-3228: system vms are not comming up in zone with two cluster xen and kvm
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12358/#review24643 --- Commit 506f2a4b94299e626b19c17c444b2d4b3bbcc49f in branch refs/heads/master from Harikrishna Patnala [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=506f2a4 ] CLOUDSTACK-3228: system vms are not comming up in zone with two cluster xen and kvm CLOUDSTACK-3631: Enhance System vm deployment retry mechanism Signed off by : Nitin Mehtanitin.me...@citrix.com - ASF Subversion and Git Services On Aug. 5, 2013, 11:12 a.m., Harikrishna Patnala wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12358/ --- (Updated Aug. 5, 2013, 11:12 a.m.) Review request for cloudstack and Nitin Mehta. Bugs: CLOUDSTACK-3228 and CLOUDSTACK-3631 Repository: cloudstack-git Description --- CLOUDSTACK-3228: system vms are not comming up in zone with two cluster xen and kvm;Zone host is ready, but secondary storage vm template: 3 is not ready on secondary storage: 2 CLOUDSTACK-3631: Enhance System vm deployment retry mechanism Diffs - engine/schema/src/com/cloud/storage/dao/VMTemplateDao.java c3d44bd engine/schema/src/com/cloud/storage/dao/VMTemplateDaoImpl.java 9e75990 server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 7c6fbd0 server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java b10fb7a Diff: https://reviews.apache.org/r/12358/diff/ Testing --- tested locally Thanks, Harikrishna Patnala
Re: Review Request 12358: CLOUDSTACK-3228: system vms are not comming up in zone with two cluster xen and kvm
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12358/#review24644 --- Commit 40e7502bcb02a3301347f2debfb09a920306e796 in branch refs/heads/4.2 from Harikrishna Patnala [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=40e7502 ] CLOUDSTACK-3228: system vms are not comming up in zone with two cluster xen and kvm CLOUDSTACK-3631: Enhance System vm deployment retry mechanism Signed off by : Nitin Mehtanitin.me...@citrix.com - ASF Subversion and Git Services On Aug. 5, 2013, 11:12 a.m., Harikrishna Patnala wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12358/ --- (Updated Aug. 5, 2013, 11:12 a.m.) Review request for cloudstack and Nitin Mehta. Bugs: CLOUDSTACK-3228 and CLOUDSTACK-3631 Repository: cloudstack-git Description --- CLOUDSTACK-3228: system vms are not comming up in zone with two cluster xen and kvm;Zone host is ready, but secondary storage vm template: 3 is not ready on secondary storage: 2 CLOUDSTACK-3631: Enhance System vm deployment retry mechanism Diffs - engine/schema/src/com/cloud/storage/dao/VMTemplateDao.java c3d44bd engine/schema/src/com/cloud/storage/dao/VMTemplateDaoImpl.java 9e75990 server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 7c6fbd0 server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java b10fb7a Diff: https://reviews.apache.org/r/12358/diff/ Testing --- tested locally Thanks, Harikrishna Patnala
Review Request 13267: CLOUDSTACK-4075: User unable to archive events.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13267/ --- Review request for cloudstack and Devdeep Singh. Bugs: CLOUDSTACK-4075 Repository: cloudstack-git Description --- CLOUDSTACK-4075: User unable to archive events. The normal user was not able to archive the events in bulk by passing the date range or by passing the event types. Diffs - server/src/com/cloud/server/ManagementServerImpl.java a181553 Diff: https://reviews.apache.org/r/13267/diff/ Testing --- Verified the fix locally on cloudstack setup. Thanks, Sanjay Tripathi
Re: unable to view content of cwiki
I've able to access the wiki all day so far. On Mon, Aug 5, 2013 at 12:43 PM, Rajesh Battala rajesh.batt...@citrix.com wrote: Hi All, Am not able to view any link of cwiki. Am getting permission denied to view any content. Please let me know how to resolve this issue. Thanks Rajesh Battala
Re: unable to view content of cwiki
Yes, I able to access them too. Rajesh, are you still can't access cwiki page? if yes, please share some example link. On Mon, Aug 5, 2013 at 10:47 PM, Daan Hoogland daan.hoogl...@gmail.comwrote: I've able to access the wiki all day so far. On Mon, Aug 5, 2013 at 12:43 PM, Rajesh Battala rajesh.batt...@citrix.com wrote: Hi All, Am not able to view any link of cwiki. Am getting permission denied to view any content. Please let me know how to resolve this issue. Thanks Rajesh Battala -- 千葉 豪 Go Chiba E-mail:go.ch...@gmail.com
Re: Review Request 13267: CLOUDSTACK-4075: User unable to archive events.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13267/#review24646 --- Commit e0c6073a80ef5c1c8cff19b86289dc872b1b36f7 in branch refs/heads/4.2 from Sanjay Tripathi [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e0c6073 ] CLOUDSTACK-4075: User unable to archive events - ASF Subversion and Git Services On Aug. 5, 2013, 12:54 p.m., Sanjay Tripathi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13267/ --- (Updated Aug. 5, 2013, 12:54 p.m.) Review request for cloudstack and Devdeep Singh. Bugs: CLOUDSTACK-4075 Repository: cloudstack-git Description --- CLOUDSTACK-4075: User unable to archive events. The normal user was not able to archive the events in bulk by passing the date range or by passing the event types. Diffs - server/src/com/cloud/server/ManagementServerImpl.java a181553 Diff: https://reviews.apache.org/r/13267/diff/ Testing --- Verified the fix locally on cloudstack setup. Thanks, Sanjay Tripathi
Re: Review Request 13267: CLOUDSTACK-4075: User unable to archive events.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13267/#review24647 --- Commit 8845aae0bc10474bf7dd59aea7be8a50ac40f9f5 in branch refs/heads/master from Sanjay Tripathi [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8845aae ] CLOUDSTACK-4075: User unable to archive events - ASF Subversion and Git Services On Aug. 5, 2013, 12:54 p.m., Sanjay Tripathi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13267/ --- (Updated Aug. 5, 2013, 12:54 p.m.) Review request for cloudstack and Devdeep Singh. Bugs: CLOUDSTACK-4075 Repository: cloudstack-git Description --- CLOUDSTACK-4075: User unable to archive events. The normal user was not able to archive the events in bulk by passing the date range or by passing the event types. Diffs - server/src/com/cloud/server/ManagementServerImpl.java a181553 Diff: https://reviews.apache.org/r/13267/diff/ Testing --- Verified the fix locally on cloudstack setup. Thanks, Sanjay Tripathi
Re: Review Request 13267: CLOUDSTACK-4075: User unable to archive events.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13267/#review24648 --- Ship it! Ship It! - Devdeep Singh On Aug. 5, 2013, 12:54 p.m., Sanjay Tripathi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13267/ --- (Updated Aug. 5, 2013, 12:54 p.m.) Review request for cloudstack and Devdeep Singh. Bugs: CLOUDSTACK-4075 Repository: cloudstack-git Description --- CLOUDSTACK-4075: User unable to archive events. The normal user was not able to archive the events in bulk by passing the date range or by passing the event types. Diffs - server/src/com/cloud/server/ManagementServerImpl.java a181553 Diff: https://reviews.apache.org/r/13267/diff/ Testing --- Verified the fix locally on cloudstack setup. Thanks, Sanjay Tripathi
Re: [DISCUSS] Should we be releasing -beta releases?
On 31.07.2013 16:30, Chip Childers wrote: On Wed, Jul 31, 2013 at 12:04:50AM +0100, Nux! wrote: On 14.05.2013 15:41, Chip Childers wrote: As a way to get more user feedback on our major feature releases, what does everyone think about releasing one or two -beta releases for each major feature release? Hi, What has been decided? Will we see any 4.2 betas? Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro I think that we realized that the upgrade support problems are significant enough to make this difficult right now. Consider it an aspiration for the future. To be honest even unsupported betas might be good. I'd be willing to test betas even without upgradability to stable, just to see what to expect, what's new, what's good, what's bad etc. I'm sure there are many like me. Sure, I can download and build it myself, but it would've been much more convenient to have some RPMs on cloudstack.apt-get.eu; plus, not everyone is comfortable building RPMs or from source etc. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: [DISCUSS] Should we be releasing -beta releases?
For this the jenkins builds might be suitable. I think if those are running on all active release branches. On Mon, Aug 5, 2013 at 4:42 PM, Nux! n...@li.nux.ro wrote: On 31.07.2013 16:30, Chip Childers wrote: On Wed, Jul 31, 2013 at 12:04:50AM +0100, Nux! wrote: On 14.05.2013 15:41, Chip Childers wrote: As a way to get more user feedback on our major feature releases, what does everyone think about releasing one or two -beta releases for each major feature release? Hi, What has been decided? Will we see any 4.2 betas? Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro I think that we realized that the upgrade support problems are significant enough to make this difficult right now. Consider it an aspiration for the future. To be honest even unsupported betas might be good. I'd be willing to test betas even without upgradability to stable, just to see what to expect, what's new, what's good, what's bad etc. I'm sure there are many like me. Sure, I can download and build it myself, but it would've been much more convenient to have some RPMs on cloudstack.apt-get.eu; plus, not everyone is comfortable building RPMs or from source etc. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Review Request 13268: fix bug CLOUDSTACK-4088 cloudstack will stop and delete vm which not belongs to cs
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13268/ --- Review request for cloudstack, Abhinandan Prateek, edison su, and mice xia. Bugs: CLOUDSTACK-4088 Repository: cloudstack-git Description --- fullSync will check if the vm is following CS naming and will stop the vms which are not belongs to CS and having the same name with CS vms. but in deltaSync it will stop all vms not belongs to CS. It is unreasonable to stop or remove a vm that not belongs to CS. Diffs - server/src/com/cloud/vm/VirtualMachineManagerImpl.java b33ee49 Diff: https://reviews.apache.org/r/13268/diff/ Testing --- vm which not belongs to CS will not removed or stopped Thanks, Hongtu Zang
Re: [DISCUSS] Should we be releasing -beta releases?
On 05.08.2013 16:09, Daan Hoogland wrote: For this the jenkins builds might be suitable. I think if those are running on all active release branches. Some URLs could be real handy now. :) -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: Unable to start domR(VR) in devcloud using laster 4.1/master.
2013/8/3 Chiradeep Vittal chiradeep.vit...@citrix.com On 4.1? It's on my local branch, cloned from master but I haven't merged for several weeks. However I concern about the reason. After re-deploying Zone, everything is ok. Problem maybe comes from id_rsa.cloud key, which was not patched to systemvm because of an unknown reason. Btw, I can access to systemvm now. -- N.g.U.y.e.N.A.n.H.t.U
Re: [DISCUSS] Should we be releasing -beta releases?
think was the keyword there, ... but I am looking for ya. moment On Mon, Aug 5, 2013 at 5:21 PM, Nux! n...@li.nux.ro wrote: On 05.08.2013 16:09, Daan Hoogland wrote: For this the jenkins builds might be suitable. I think if those are running on all active release branches. Some URLs could be real handy now. :) -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: [DISCUSS] Should we be releasing -beta releases?
the 4.1 build for rhel63 says: Apache Cloudstack RHEL 6.3 packages This project is currently disabled this one didn't happen to be the one you where looking for? Anyway look at http://jenkins.cloudstack.org and browse around. I thought you would find them there. On Mon, Aug 5, 2013 at 5:40 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: think was the keyword there, ... but I am looking for ya. moment On Mon, Aug 5, 2013 at 5:21 PM, Nux! n...@li.nux.ro wrote: On 05.08.2013 16:09, Daan Hoogland wrote: For this the jenkins builds might be suitable. I think if those are running on all active release branches. Some URLs could be real handy now. :) -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: [jira] [Commented] (CLOUDSTACK-4088) cloudstack will stop and delete vm which not belongs to cs
I agree, I think this is by design. On Mon, Aug 5, 2013 at 9:42 AM, Rajesh Battala (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/CLOUDSTACK-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13729580#comment-13729580 ] Rajesh Battala commented on CLOUDSTACK-4088: Hongtu, I think the behaviour is right. CS will treat the VM's which are not created by cloudstack as rouge vm and will delete it. In terms of security I think its correct. cloudstack will stop and delete vm which not belongs to cs -- Key: CLOUDSTACK-4088 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4088 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: XenServer Affects Versions: 4.0.2, 4.1.0, 4.2.0, Future Environment: xenserver 6.0.2 Reporter: Hongtu Zang Labels: removed, vm, xenserver Fix For: 4.2.0, Future Original Estimate: 24h Remaining Estimate: 24h 1.create vm in xenserver, by xencenter 2.add xenserver to cloudstack the vm will be stopped and removed 3.create another vm in xencenter it is also removed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Review Request 13268: fix bug CLOUDSTACK-4088 cloudstack will stop and delete vm which not belongs to cs
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13268/ --- (Updated Aug. 5, 2013, 3:59 p.m.) Review request for cloudstack, Abhinandan Prateek, edison su, and mice xia. Bugs: CLOUDSTACK-4088 Repository: cloudstack-git Description --- fullSync will check if the vm is following CS naming and will stop the vms which are not belongs to CS and having the same name with CS vms. but in deltaSync it will stop all vms not belongs to CS. It is unreasonable to stop or remove a vm that not belongs to CS. Diffs - server/src/com/cloud/vm/VirtualMachineManagerImpl.java b33ee49 Diff: https://reviews.apache.org/r/13268/diff/ Testing --- vm which not belongs to CS will not removed or stopped Thanks, Hongtu Zang
Review Request 13269: fix bug CLOUDSTACK-4088 cloudstack will stop and delete vm which not belongs to cs
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13269/ --- Review request for cloudstack, Abhinandan Prateek, edison su, and mice xia. Bugs: CLOUDSTACK-4088 Repository: cloudstack-git Description --- fullSync will check if the vm is following CS naming and will stop the vms which are not belongs to CS and having the same name with CS vms. but in deltaSync it will stop all vms not belongs to CS. It is unreasonable to stop or remove a vm that not belongs to CS. Diffs - server/src/com/cloud/vm/VirtualMachineManagerImpl.java 15a9a82 Diff: https://reviews.apache.org/r/13269/diff/ Testing --- vm which not belongs to CS will not removed or stopped Thanks, Hongtu Zang
Re: [DISCUSS] Should we be releasing -beta releases?
On 05.08.2013 16:48, Daan Hoogland wrote: the 4.1 build for rhel63 says: Apache Cloudstack RHEL 6.3 packages This project is currently disabled this one didn't happen to be the one you where looking for? Anyway look at http://jenkins.cloudstack.org and browse around. I thought you would find them there. Thanks, I'll have a look around there. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
RE: api calls in 4.1.1
Daan, Please be more specific as to which APIs don't work - and if you know what commit could have caused it. Thanks ilya -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Monday, August 05, 2013 4:43 AM To: dev Subject: api calls in 4.1.1 H, What is the status of 4.1.1 at this moment. I am getting several reports of api calls not working as before. I saw the vote passing by but didn't give them much attention. In jira I don't see much mention of such issues. Is this noticed by anybosy else? regards, Daan
Re: api calls in 4.1.1
On Mon, Aug 05, 2013 at 10:42:53AM +0200, Daan Hoogland wrote: H, What is the status of 4.1.1 at this moment. I am getting several reports of api calls not working as before. I saw the vote passing by but didn't give them much attention. In jira I don't see much mention of such issues. Is this noticed by anybosy else? regards, Daan 4.1.1 status is that we are working on pushing the docs, and then the release will be announced. -chip
Re: Review Request 13223: (CLOUDSTACK-2729) use file lock to prevent concurrent refreshPool/deleteVolume on KVM shared storage pool
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13223/#review24650
---
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java
https://reviews.apache.org/r/13223/#comment48751
if (!lockFile.exists()) {
lockFile.createNewFile();
Above stanza is not atomic. If two threads coming into this code at the
same time, both will succeed.
Maybe just if (lockFile.createNewFile()) is good enough?
- edison su
On Aug. 5, 2013, 10:38 a.m., Wei Zhou wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13223/
---
(Updated Aug. 5, 2013, 10:38 a.m.)
Review request for cloudstack, edison su and Wido den Hollander.
Bugs: CLOUDSTACK-2729
Repository: cloudstack-git
Description
---
The storage pool issue (CLOUDSTACK-2729) is because of a bug in libvirt
(https://bugzilla.redhat.com/show_bug.cgi?id=977706)
We need to prevent deleting a volume when refreshing the pool.
This patch use a simple file lock to implement it.
PS: I have tested another file lock similar to Read/Write file lock, but it
was very unstable.
Diffs
-
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java
a9baa52
Diff: https://reviews.apache.org/r/13223/diff/
Testing
---
Applied on 4.0.2 and 4.0.1
Testing On 4.0.1 From 20,June
3 nodes, create a VM on each node every 15 minutes. Destroy the VMs 5 minutes
later. expunge.inteval = 600 (10 minutes), expunge.worker = 2
Testing On 4.0.2 From 01,July
2 nodes, create two VMs on each node every 5 minutes. Destroy the VMs 4
minutes later. expunge.inteval = 600 (10 minutes), expunge.worker = 2
Thanks,
Wei Zhou
Re: database upgrade
On Mon, Aug 05, 2013 at 12:32:19PM +0200, Daan Hoogland wrote:
H,
What is the policy for adding upgrade paths?
I am working on upgrade from 4.1.1 already.
So when do we add
_upgradeMap.put(4.1.1, new DbUpgrade[] { new
Upgrade410to420(), new Upgrade420to430() });
to DatabaseUpgradeChecker?
thanks,
Daan
Yup, that should be right.
db.properties
Hi, I was looking at my db.properties file and noticed I didn't fill in a value for the db.root.password key. Can someone tell me what filling in this value will change behavior wise in CloudStack? Thanks! Mike # CloudStack database settings db.cloud.username=cloud db.cloud.password=cloud db.root.password= db.cloud.host=localhost db.cloud.port=3306 db.cloud.name=cloud -- *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 *™*
[ACS411] 4.1.1 status
Hi all, Here's where we are: DEBs (oss) are loaded into the cloustack.apt-get.eu repo. RPMs (nonoss) are being built now and will be pushed as soon as complete (soon) David is building the docs now. I'll announce once the RPM's and docs are published. -chip
RE: db.properties
Hi Mike, If when installing your mysql server, you set a password for the mysql root user, you will need to specify that here. If you haven't encountered errors in your deploydb, you probably haven't set the mysql root user password and so you don't have to change the db.properties file. Typically, if we set this password, we copy over the db.properties file to db.properties.override and fill in this field in that file and it will get picked up by the db schema creation scripts. Regards, Vijay -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Monday, August 05, 2013 10:49 AM To: dev@cloudstack.apache.org Subject: db.properties Hi, I was looking at my db.properties file and noticed I didn't fill in a value for the db.root.password key. Can someone tell me what filling in this value will change behavior wise in CloudStack? Thanks! Mike # CloudStack database settings db.cloud.username=cloud db.cloud.password=cloud db.root.password= db.cloud.host=localhost db.cloud.port=3306 db.cloud.name=cloud -- *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 *(tm)*
Re: db.properties
Ah, OK, thanks. It has been a long time since I first installed MySQL for CloudStack development and I don't recall exactly how I set it up back then, but it must have been without a password. On Mon, Aug 5, 2013 at 12:01 PM, Vijayendra Bhamidipati vijayendra.bhamidip...@citrix.com wrote: Hi Mike, If when installing your mysql server, you set a password for the mysql root user, you will need to specify that here. If you haven't encountered errors in your deploydb, you probably haven't set the mysql root user password and so you don't have to change the db.properties file. Typically, if we set this password, we copy over the db.properties file to db.properties.override and fill in this field in that file and it will get picked up by the db schema creation scripts. Regards, Vijay -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Monday, August 05, 2013 10:49 AM To: dev@cloudstack.apache.org Subject: db.properties Hi, I was looking at my db.properties file and noticed I didn't fill in a value for the db.root.password key. Can someone tell me what filling in this value will change behavior wise in CloudStack? Thanks! Mike # CloudStack database settings db.cloud.username=cloud db.cloud.password=cloud db.root.password= db.cloud.host=localhost db.cloud.port=3306 db.cloud.name=cloud -- *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 *(tm)* -- *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 13223: (CLOUDSTACK-2729) use file lock to prevent concurrent refreshPool/deleteVolume on KVM shared storage pool
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13223/ --- (Updated Aug. 5, 2013, 6:07 p.m.) Review request for cloudstack, edison su and Wido den Hollander. Bugs: CLOUDSTACK-2729 Repository: cloudstack-git Description --- The storage pool issue (CLOUDSTACK-2729) is because of a bug in libvirt (https://bugzilla.redhat.com/show_bug.cgi?id=977706) We need to prevent deleting a volume when refreshing the pool. This patch use a simple file lock to implement it. PS: I have tested another file lock similar to Read/Write file lock, but it was very unstable. Diffs (updated) - plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java b8a9f0f Diff: https://reviews.apache.org/r/13223/diff/ Testing --- Applied on 4.0.2 and 4.0.1 Testing On 4.0.1 From 20,June 3 nodes, create a VM on each node every 15 minutes. Destroy the VMs 5 minutes later. expunge.inteval = 600 (10 minutes), expunge.worker = 2 Testing On 4.0.2 From 01,July 2 nodes, create two VMs on each node every 5 minutes. Destroy the VMs 4 minutes later. expunge.inteval = 600 (10 minutes), expunge.worker = 2 Thanks, Wei Zhou
Re: [jira] [Commented] (CLOUDSTACK-4012) [UPGRADE]System VMs and VRs failed to start using KVM host after upgrading from 3.0.6 to 4.2.
org.libvirt.LibvirtException: internal error unknown timer name 'kvmclock' I've been waiting to hear what platforms will be supported in 4.2 before committing '0fa108f03895e83ccc5d4c81e058ea8f424663b9' to 4.2. We eventually want this code, as it's a critical fix for system vm clocks, but specifically the now long-in-tooth Ubuntu 12.04 doesn't support this libvirt feature. I assume we will continue to support 12.04 until 14.04 comes out, so we should probably revert it in 4.2 as well. On Mon, Aug 5, 2013 at 12:04 PM, Kishan Kavala (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/CLOUDSTACK-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13729733#comment-13729733 ] Kishan Kavala commented on CLOUDSTACK-4012: --- Could be a system Vm template issue. Related discussion: http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201307.mbox/%3c2ac317e9e0682749a5a8a3c9939ae00306415...@sinpex01cl02.citrite.net%3E Related bugs: CLOUDSTACK-2871 CLOUDSTACK-2823 [UPGRADE]System VMs and VRs failed to start using KVM host after upgrading from 3.0.6 to 4.2. --- Key: CLOUDSTACK-4012 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4012 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM, Upgrade Affects Versions: 4.2.0 Environment: KVM host--Upgrade from 3.0.6 to 4.2 Reporter: manasaveloori Assignee: Kishan Kavala Priority: Blocker Fix For: 4.2.0 Attachments: agent.log, management-server.log, mysqldump1.dmp, mysqldumpafterUpgrade.dmp, mysqldumpusage1.dmp Steps: 1.Have a CS 3.0.6 patchE with KVM and Xen hypervisors(both Advanced zones). 2.Add the external devices F5,SRX,Netscaler to CS. 3.Delpoy VMs and create firewall,LB rules using the external devices. 4.Upgrade to 4.2 build. Observed that the system VMs failed to start with KVM host. After running the cloudstack-sysvmadm script the System VMs and VRs failed to start. Observing the agent logs,it show following exception 013-08-01 17:41:02,158 WARN [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) LibvirtException org.libvirt.LibvirtException: internal error unknown timer name 'kvmclock' at org.libvirt.ErrorHandler.processError(Unknown Source) at org.libvirt.Connect.processError(Unknown Source) at org.libvirt.Connect.domainCreateXML(Unknown Source) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1128) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3295) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1224) at com.cloud.agent.Agent.processRequest(Agent.java:525) at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852) at com.cloud.utils.nio.Task.run(Task.java:83) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Attaching the Ms logs,Db dumps and agent logs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Review Request 13240: dealt with some warnings in NetworkServiceImpl
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13240/#review24654 --- Ship it! Ship It! - Sheng Yang On Aug. 5, 2013, 9:59 a.m., daan Hoogland wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13240/ --- (Updated Aug. 5, 2013, 9:59 a.m.) Review request for cloudstack, Chiradeep Vittal and Sheng Yang. Repository: cloudstack-git Description --- dealt with some warnings in NetworkServiceImpl Diffs - server/src/com/cloud/network/NetworkServiceImpl.java ff753f4 Diff: https://reviews.apache.org/r/13240/diff/ Testing --- Thanks, daan Hoogland
RE: Not getting GUI
I have not heard that Java requirement before. Is that really true? Jessica T. From: Prashant Sreedharan [prashant.sreedha...@citrix.com] Sent: Monday, August 05, 2013 10:36 AM To: us...@cloudstack.apache.org Cc: karthik.c...@gmail.com Subject: RE: Not getting GUI Please find my check list for the Cloudstack management install Make sure that the VM can reach the Internet. ping 8.8.8.8 , ping google.com , Set SELinux to be permissive by default Check JAVA version. Cloudstack requires Sun Java and not the IBM java version. $DB_SERVER be pingable, and MySQL should be listening on that address. The CloudStack management boxes should be running RHEL 6 or centos (check /etc/issue ) The NFS server mount point must work from the CloudStack management VM , Pod XenServes and the secondary storage vm ( ssvm ) To Check JAVA rpm -qa | grep -i java java-1.5.0-gcj-1.5.0.0-29.1.el6.x86_64 java_cup-0.10k-5.el6.x86_64 java-1.6.0-sun-1.6.0.37-1jpp.1.el6_3.x86_6 Please check if these ports are open 1) CloudStack Management Server TCP 9090 + 8250 (bi-directional) To/from CloudStack Management Server 2) User/Client/API TCP 8080 User/Client/API to CloudStack Management Server - Management Port (authenticated communication) 3) User/Client TCP 8096 User/Client to CloudStack Management Server - Management Port (unauthenticated communication) 4) vCenter TCP 443 CloudStack Management Server to vCenter 5) KVM TCP 22 CloudStack Management Server to KVM 6) XenServer TCP 22/80/443 CloudStack Management Server to XenServer 7) MySQL TCP 3306 CloudStack Management Server to MySQL 8) DNS TCP 53 CloudStack Management Server to DNS 9) Secondary Storage TCP 3922 CloudStack Management Server to SSVM 10) Virtual Machine (SSVM) TCP 8250 SSVM to CloudStack Management Server TCP 80/443 SSVM to HTTP(s) File Share to download VM Image TCP 111/2049 SSVM to NFS TCP 53 SSVM to DNS 11) Console Proxy VM TCP 3922 CloudStack Management Server to Console Proxy VM TCP 8250 Console Proxy VM to CloudStack Management Server TCP 53 Console Proxy VM to DNS 12) Virtual Router TCP 3922 CloudStack Management Server to Virtual Router TCP 8250 Virtual Router to CloudStack Management Server TCP 53 Virtual Router to DNS 13) NFS TCP 111/2049 CloudStack Management Server to NFS (initial deployment of SSVM and CPVM thanks Prashant Sreedharan Cloudstack XenServer Administrator , Ops T: +1 805 690 3486 | M: +1 805 453 9105 prashant.sreedha...@citrix.com Powering mobile workstyles and cloud services -Original Message- From: Karthik Kothuri [mailto:karthik.koth...@gmail.com] Sent: Monday, August 05, 2013 9:25 AM To: us...@cloudstack.apache.org Cc: karthik.c...@gmail.com Subject: Re: Not getting GUI Karthik, can you please try restarting the cloudstack management server once. Thanks, Karthik Kothuri On Mon, Aug 5, 2013 at 9:35 PM, karthi keyan karthik.c...@gmail.com wrote: using Bridged network. On Mon, Aug 5, 2013 at 9:32 PM, Bradley Hieber mercsni...@gmail.com wrote: Are you bridged or NAT'd? On Mon, Aug 5, 2013 at 11:57 AM, karthi keyan karthik.c...@gmail.com wrote: Hi Bradley, Thanks in advance. I have started these services, root@csmgmt ~]# service cloud-management start Starting cloud-management: [ OK ] [root@csmgmt ~]# service tomcat6 start Starting tomcat6: [ OK ] [root@csmgmt ~]# service mysqld start Starting mysqld: [ OK ] [root@csmgmt ~]# service nfs status rpc.svcgssd is stopped rpc.mountd (pid 1683) is running... nfsd (pid 1746 1745 1744 1743 1742 1741 1740 1739) is running... rpc.rquotad (pid 1679) is running... In the browser i have given this url: *http://192.168.1.2:8080/client* *And it is displaying a blank page. I have attached the screenshot of that web page.* I have installed CS in Centos 6.3 in VMware workstation. Regards, Karthikeyan On Mon, Aug 5, 2013 at 8:19 PM, Bradley Hieber mercsni...@gmail.com wrote: Karthik, Did you start the service? Which platform did you install CS on? On Mon, Aug 5, 2013 at 10:47 AM, karthi keyan karthik.c...@gmail.com wrote: Hi, I followed the installation Guide of cloustack-4.1.0. And each and every step was sucessfully done. But now i cant able to get the GUI. *http://192.168.1.2:8080/client* # 192.168.1.2 is the management server ip I have no idea. Pls someone help me. Regards, Karthik -- Brad -- Brad -- Thanks and Regards, Karthik Kothuri
Re: Review Request 13223: (CLOUDSTACK-2729) use file lock to prevent concurrent refreshPool/deleteVolume on KVM shared storage pool
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13223/#review24657 --- Ship it! Ship It! - edison su On Aug. 5, 2013, 6:07 p.m., Wei Zhou wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13223/ --- (Updated Aug. 5, 2013, 6:07 p.m.) Review request for cloudstack, edison su and Wido den Hollander. Bugs: CLOUDSTACK-2729 Repository: cloudstack-git Description --- The storage pool issue (CLOUDSTACK-2729) is because of a bug in libvirt (https://bugzilla.redhat.com/show_bug.cgi?id=977706) We need to prevent deleting a volume when refreshing the pool. This patch use a simple file lock to implement it. PS: I have tested another file lock similar to Read/Write file lock, but it was very unstable. Diffs - plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java b8a9f0f Diff: https://reviews.apache.org/r/13223/diff/ Testing --- Applied on 4.0.2 and 4.0.1 Testing On 4.0.1 From 20,June 3 nodes, create a VM on each node every 15 minutes. Destroy the VMs 5 minutes later. expunge.inteval = 600 (10 minutes), expunge.worker = 2 Testing On 4.0.2 From 01,July 2 nodes, create two VMs on each node every 5 minutes. Destroy the VMs 4 minutes later. expunge.inteval = 600 (10 minutes), expunge.worker = 2 Thanks, Wei Zhou
Re: Review Request 13223: (CLOUDSTACK-2729) use file lock to prevent concurrent refreshPool/deleteVolume on KVM shared storage pool
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13223/#review24656 --- Commit 0f539b4ce1b07c672a776ffa806dabb70c528afe in branch refs/heads/4.2 from Wei Zhou [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0f539b4 ] CLOUDSTACK-2729: use file lock to prevent concurrent refreshPool/deleteVolume on KVM shared storage pool Signed-off-by: Edison Su sudi...@gmail.com - ASF Subversion and Git Services On Aug. 5, 2013, 6:07 p.m., Wei Zhou wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13223/ --- (Updated Aug. 5, 2013, 6:07 p.m.) Review request for cloudstack, edison su and Wido den Hollander. Bugs: CLOUDSTACK-2729 Repository: cloudstack-git Description --- The storage pool issue (CLOUDSTACK-2729) is because of a bug in libvirt (https://bugzilla.redhat.com/show_bug.cgi?id=977706) We need to prevent deleting a volume when refreshing the pool. This patch use a simple file lock to implement it. PS: I have tested another file lock similar to Read/Write file lock, but it was very unstable. Diffs - plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java b8a9f0f Diff: https://reviews.apache.org/r/13223/diff/ Testing --- Applied on 4.0.2 and 4.0.1 Testing On 4.0.1 From 20,June 3 nodes, create a VM on each node every 15 minutes. Destroy the VMs 5 minutes later. expunge.inteval = 600 (10 minutes), expunge.worker = 2 Testing On 4.0.2 From 01,July 2 nodes, create two VMs on each node every 5 minutes. Destroy the VMs 4 minutes later. expunge.inteval = 600 (10 minutes), expunge.worker = 2 Thanks, Wei Zhou
Re: Review Request 13223: (CLOUDSTACK-2729) use file lock to prevent concurrent refreshPool/deleteVolume on KVM shared storage pool
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13223/#review24659 --- Commit 1e4ff7f4532a39355ef5e5bfaa8dbfbc1f1c27e4 in branch refs/heads/master from Wei Zhou [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1e4ff7f ] CLOUDSTACK-2729: use file lock to prevent concurrent refreshPool/deleteVolume on KVM shared storage pool Signed-off-by: Edison Su sudi...@gmail.com - ASF Subversion and Git Services On Aug. 5, 2013, 6:07 p.m., Wei Zhou wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13223/ --- (Updated Aug. 5, 2013, 6:07 p.m.) Review request for cloudstack, edison su and Wido den Hollander. Bugs: CLOUDSTACK-2729 Repository: cloudstack-git Description --- The storage pool issue (CLOUDSTACK-2729) is because of a bug in libvirt (https://bugzilla.redhat.com/show_bug.cgi?id=977706) We need to prevent deleting a volume when refreshing the pool. This patch use a simple file lock to implement it. PS: I have tested another file lock similar to Read/Write file lock, but it was very unstable. Diffs - plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java b8a9f0f Diff: https://reviews.apache.org/r/13223/diff/ Testing --- Applied on 4.0.2 and 4.0.1 Testing On 4.0.1 From 20,June 3 nodes, create a VM on each node every 15 minutes. Destroy the VMs 5 minutes later. expunge.inteval = 600 (10 minutes), expunge.worker = 2 Testing On 4.0.2 From 01,July 2 nodes, create two VMs on each node every 5 minutes. Destroy the VMs 4 minutes later. expunge.inteval = 600 (10 minutes), expunge.worker = 2 Thanks, Wei Zhou
Re: database upgrade
:) meaning now, i suppose.
On Mon, Aug 5, 2013 at 7:12 PM, Chip Childers chip.child...@sungard.com wrote:
On Mon, Aug 05, 2013 at 12:32:19PM +0200, Daan Hoogland wrote:
H,
What is the policy for adding upgrade paths?
I am working on upgrade from 4.1.1 already.
So when do we add
_upgradeMap.put(4.1.1, new DbUpgrade[] { new
Upgrade410to420(), new Upgrade420to430() });
to DatabaseUpgradeChecker?
thanks,
Daan
Yup, that should be right.
4.1.1 Build issue for CentOS - errors on AWSAPI depenencies
Hi all, Trying to build 4.1.1 into the appropriate RPMs, and I'm hitting the following error during the process. Any clues / ideas? I've cleaned our ~/.m2/repository and tried again, but same issue. [INFO] Apache CloudStack AWS API Bridge .. FAILURE [55.762s] [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 5:14.484s [INFO] Finished at: Mon Aug 05 19:20:34 IST 2013 [INFO] Final Memory: 47M/206M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on project cloud-awsapi: Compilation failure: Compilation failure: [ERROR] error: error reading /home/sg-user/.m2/repository/org/apache/axis2/mex/1.5.4/mex-1.5.4-impl.jar; error in opening zip file [ERROR] error: error reading /home/sg-user/.m2/repository/org/apache/axis2/axis2-mtompolicy/1.5.4/axis2-mtompolicy-1.5.4.jar; error in opening zip file [ERROR] error: error reading /home/sg-user/.m2/repository/org/apache/ws/commons/axiom/axiom-dom/1.2.10/axiom-dom-1.2.10.jar; error in opening zip file [ERROR] error: error reading /home/sg-user/.m2/repository/org/opensaml/opensaml1/1.1/opensaml1-1.1.jar; error in opening zip file [ERROR] error: error reading /home/sg-user/.m2/repository/commons-lang/commons-lang/2.3/commons-lang-2.3.jar; error in opening zip file [ERROR] - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn goals -rf :cloud-awsapi
Re: api calls in 4.1.1
Ilya, listVirtualMachines (as user) for one, but I got a second report that wasn't very precise yet, so I will be working on reproducing next days and report back (wit test case or patch) regards, On Mon, Aug 5, 2013 at 6:56 PM, Chip Childers chip.child...@sungard.com wrote: On Mon, Aug 05, 2013 at 10:42:53AM +0200, Daan Hoogland wrote: H, What is the status of 4.1.1 at this moment. I am getting several reports of api calls not working as before. I saw the vote passing by but didn't give them much attention. In jira I don't see much mention of such issues. Is this noticed by anybosy else? regards, Daan 4.1.1 status is that we are working on pushing the docs, and then the release will be announced. -chip
Re: Review Request 13237: Unable to resize disk with Zone wide storage
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13237/#review24653 --- engine/schema/src/com/cloud/storage/dao/VolumeDaoImpl.java https://reviews.apache.org/r/13237/#comment48754 why not just use select s.scope from storage_pool s, volumes v where s.id = v.pool_id? - edison su On Aug. 2, 2013, 10:07 a.m., Rajesh Battala wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13237/ --- (Updated Aug. 2, 2013, 10:07 a.m.) Review request for cloudstack, Devdeep Singh, edison su, and Ram Ganesh. Bugs: 3781 Repository: cloudstack-git Description --- Issue: == for Volume operations we are finding the hypervisor type. Volume can be in ZONE/Cluster scope storage pool. when volume is in ZONE scope, there is issue with they way we fetch the hypervisor type. It was written to handle Cluster scope only. fixed: == Fixed with sql queries to fetch the Hypervisor type. 1. Fetch the hypervisor type for volume from storage pool table if the voluem is in ZONE scope storage pool. 2. Fetch the hypervisor type for volume from cluster table if the voluem is in CLUSTER scope storage pool. Diffs - engine/schema/src/com/cloud/storage/dao/VolumeDao.java 7b58e7d engine/schema/src/com/cloud/storage/dao/VolumeDaoImpl.java e6595b2 Diff: https://reviews.apache.org/r/13237/diff/ Testing --- Setup: KVM and Xenserver with Adv Zone. Added pool Zone scope on KVM and Cluster Scope on Xenserver 1. created instances on KVM and xenserver. 2. Create two volumes attached to instances on KVM and Xenserver. 3. vol1 is in Zone scope and vol2 is in cluster scope. 4. Successfully performed resize opertions on vol1 and vol2. 5. Succssfully attached/detaches volumes Thanks, Rajesh Battala
Re: [ACS411] 4.1.1 status
Just fixing a typo... your missing the d in cloud http://cloudstack.apt-get.eu/ On 5 August 2013 19:01, Chip Childers chip.child...@sungard.com wrote: Hi all, Here's where we are: DEBs (oss) are loaded into the cloustack.apt-get.eu repo. RPMs (nonoss) are being built now and will be pushed as soon as complete (soon) David is building the docs now. I'll announce once the RPM's and docs are published. -chip
Re: database upgrade
On Mon, Aug 05, 2013 at 08:23:48PM +0200, Daan Hoogland wrote:
:) meaning now, i suppose.
On Mon, Aug 5, 2013 at 7:12 PM, Chip Childers chip.child...@sungard.com
wrote:
On Mon, Aug 05, 2013 at 12:32:19PM +0200, Daan Hoogland wrote:
H,
What is the policy for adding upgrade paths?
I am working on upgrade from 4.1.1 already.
So when do we add
_upgradeMap.put(4.1.1, new DbUpgrade[] { new
Upgrade410to420(), new Upgrade420to430() });
to DatabaseUpgradeChecker?
thanks,
Daan
Yup, that should be right.
Yeah, it should be added if it's not yet.
Back-port awsapi installation fixes to 4.1 branch
Hi, Seems like the awsapi installation is broken for 4.1 and 4.1.1 releases. Most of the issues have been identified and fixed in 4.2. Here is the list to start with: https://issues.apache.org/jira/browse/CLOUDSTACK-2777 https://issues.apache.org/jira/browse/CLOUDSTACK-3295 https://issues.apache.org/jira/browse/CLOUDSTACK-3112 https://issues.apache.org/jira/browse/CLOUDSTACK-2927 I plan to cherry-pick these back to the 4.1 branch for the next bug-fix release 4.1.2 Let me know if I should hold on back-porting these to 4.1 for any reason. I will start merging these later in the day. Thanks, Prachi
Re: Review Request 13240: dealt with some warnings in NetworkServiceImpl
On Aug. 5, 2013, 6:19 p.m., Sheng Yang wrote: Ship It! Pushed to 4.2 and MASTER. - Sheng --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13240/#review24654 --- On Aug. 5, 2013, 9:59 a.m., daan Hoogland wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13240/ --- (Updated Aug. 5, 2013, 9:59 a.m.) Review request for cloudstack, Chiradeep Vittal and Sheng Yang. Repository: cloudstack-git Description --- dealt with some warnings in NetworkServiceImpl Diffs - server/src/com/cloud/network/NetworkServiceImpl.java ff753f4 Diff: https://reviews.apache.org/r/13240/diff/ Testing --- Thanks, daan Hoogland
Review Request 13252: SHA256 timing attack and brute force attack fix
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13252/ --- Review request for cloudstack and John Burwell. Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-2312 and https://issues.apache.org/jira/browse/CLOUDSTACK-2314 Repository: cloudstack-git Description --- 1. Fix timing attack by using a constant-time comparison function 2. Increase salt size 3. Make flow for invalid user go through full normal execution using a fake password and salt Diffs - plugins/user-authenticators/sha256salted/src/com/cloud/server/auth/SHA256SaltedUserAuthenticator.java da93927 plugins/user-authenticators/sha256salted/src/com/cloud/server/auth/SHA256SaltedUserAuthenticator.java da93927 Diff: https://reviews.apache.org/r/13252/diff/ Testing --- Local environment Thanks, Amogh Vasekar
Re: Review Request 11858: CLOUDSTACK-2340 [AWS Style Health Checks] Response of the API listLoadBalancerRuleInstances should show the service state of a VM if health check is configured for it
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11858/#review24664 --- Commit 554c8b7ac110099cf93310660490e62ba2337f53 in branch refs/heads/master from Brian Federle [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=554c8b7 ] CLOUDSTACK-2340: Display service state for health-checked VMs - ASF Subversion and Git Services On July 10, 2013, 12:37 p.m., Rajesh Battala wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11858/ --- (Updated July 10, 2013, 12:37 p.m.) Review request for cloudstack, Alena Prokharchyk, Murali Reddy, Ram Ganesh, and Sateesh Chodapuneedi. Bugs: CLOUDSTACK-2340 Repository: cloudstack-git Description --- Issue: when healthcheck is created for LB rule then listLoadBalancerRuleInstance api should have the service state populated by LBHealthCheckManager. Fixed: Fixed the response of listLoadBalancerRuleInstance to include a servicestate:UP which tell the service state of the instance. if the healthcheck is not created on LB then api response then servicestate field won't be in the response. Diffs - api/src/com/cloud/network/lb/LoadBalancingRulesService.java 5fc41e3 api/src/org/apache/cloudstack/api/ApiConstants.java e2857b8 api/src/org/apache/cloudstack/api/command/user/loadbalancer/ListLoadBalancerRuleInstancesCmd.java 49ab42c api/src/org/apache/cloudstack/api/response/UserVmResponse.java 0df9413 server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java 6e0d0d7 Diff: https://reviews.apache.org/r/11858/diff/ Testing --- 1. Created LB rule with healthcheck policy verified the listLoadBalancerRuleInstance api response, it has the field servicestate for all the VM's assigned to the LB rule 2. Created LB rule without healthcheck policy, verified the listLoadBalancerRuleInstance api response wont have the servicestate field for all the VM's assigned to the LB rule Thanks, Rajesh Battala
Re: Review Request 11858: CLOUDSTACK-2340 [AWS Style Health Checks] Response of the API listLoadBalancerRuleInstances should show the service state of a VM if health check is configured for it
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11858/#review24663 --- Commit d1ede5430c052de5215dc1e7819d0d94752ede52 in branch refs/heads/4.2 from Brian Federle [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d1ede54 ] CLOUDSTACK-2340: Display service state for health-checked VMs - ASF Subversion and Git Services On July 10, 2013, 12:37 p.m., Rajesh Battala wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11858/ --- (Updated July 10, 2013, 12:37 p.m.) Review request for cloudstack, Alena Prokharchyk, Murali Reddy, Ram Ganesh, and Sateesh Chodapuneedi. Bugs: CLOUDSTACK-2340 Repository: cloudstack-git Description --- Issue: when healthcheck is created for LB rule then listLoadBalancerRuleInstance api should have the service state populated by LBHealthCheckManager. Fixed: Fixed the response of listLoadBalancerRuleInstance to include a servicestate:UP which tell the service state of the instance. if the healthcheck is not created on LB then api response then servicestate field won't be in the response. Diffs - api/src/com/cloud/network/lb/LoadBalancingRulesService.java 5fc41e3 api/src/org/apache/cloudstack/api/ApiConstants.java e2857b8 api/src/org/apache/cloudstack/api/command/user/loadbalancer/ListLoadBalancerRuleInstancesCmd.java 49ab42c api/src/org/apache/cloudstack/api/response/UserVmResponse.java 0df9413 server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java 6e0d0d7 Diff: https://reviews.apache.org/r/11858/diff/ Testing --- 1. Created LB rule with healthcheck policy verified the listLoadBalancerRuleInstance api response, it has the field servicestate for all the VM's assigned to the LB rule 2. Created LB rule without healthcheck policy, verified the listLoadBalancerRuleInstance api response wont have the servicestate field for all the VM's assigned to the LB rule Thanks, Rajesh Battala
Re: Back-port awsapi installation fixes to 4.1 branch
On Mon, Aug 05, 2013 at 06:29:25PM +, Prachi Damle wrote: Hi, Seems like the awsapi installation is broken for 4.1 and 4.1.1 releases. Most of the issues have been identified and fixed in 4.2. Here is the list to start with: https://issues.apache.org/jira/browse/CLOUDSTACK-2777 https://issues.apache.org/jira/browse/CLOUDSTACK-3295 https://issues.apache.org/jira/browse/CLOUDSTACK-3112 https://issues.apache.org/jira/browse/CLOUDSTACK-2927 I plan to cherry-pick these back to the 4.1 branch for the next bug-fix release 4.1.2 Let me know if I should hold on back-porting these to 4.1 for any reason. I will start merging these later in the day. Thanks, Prachi Go for it!
Re: Review Request 13252: SHA256 timing attack and brute force attack fix
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13252/ --- (Updated Aug. 5, 2013, 6:57 p.m.) Review request for cloudstack and John Burwell. Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-2312 and https://issues.apache.org/jira/browse/CLOUDSTACK-2314 Repository: cloudstack-git Description --- 1. Fix timing attack by using a constant-time comparison function 2. Increase salt size 3. Make flow for invalid user go through full normal execution using a fake password and salt Diffs (updated) - plugins/user-authenticators/sha256salted/src/com/cloud/server/auth/SHA256SaltedUserAuthenticator.java da93927 plugins/user-authenticators/sha256salted/src/com/cloud/server/auth/SHA256SaltedUserAuthenticator.java da93927 Diff: https://reviews.apache.org/r/13252/diff/ Testing --- Local environment Thanks, Amogh Vasekar
Re: Review Request 13252: SHA256 timing attack and brute force attack fix
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13252/ --- (Updated Aug. 5, 2013, 7:06 p.m.) Review request for cloudstack and John Burwell. Changes --- Getting the diff right Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-2312 and https://issues.apache.org/jira/browse/CLOUDSTACK-2314 Repository: cloudstack-git Description --- 1. Fix timing attack by using a constant-time comparison function 2. Increase salt size 3. Make flow for invalid user go through full normal execution using a fake password and salt Diffs (updated) - plugins/user-authenticators/sha256salted/src/com/cloud/server/auth/SHA256SaltedUserAuthenticator.java da939273ea10bff3b2687c9684edf8a5d0ab4b2e Diff: https://reviews.apache.org/r/13252/diff/ Testing --- Local environment Thanks, Amogh Vasekar
Re: [Discuss] Using XenServer 6.2's Clone-on-Boot feature on CloudStack
Is this the Intellicache feature? What changes does it require from CloudStack. Would just using service offering tags work? On 8/5/13 12:23 AM, Nguyen Anh Tu ng.t...@gmail.com wrote: Hi guys, Is anyone concerned about using XenServer 6.2's clone-on-boot feature on CloudStack? With it, we can quickly deploy a huge of VMs from a single golden template. This is amazing for some scenarios. For example: we can allocate a special/dedicated cluster with only one golden template. And when an update or patch be applied to golden template, changes automatically apply to every VMs. Thought? Thanks, -- N.g.U.y.e.N.A.n.H.t.U
RE: Cannot deploy db on latest 4.1 branch
Thanks Alena! I've put in the fix, will submit the patch for review in a short while. Cheers! Regards, Vijay From: Alena Prokharchyk Sent: Friday, August 02, 2013 4:51 PM To: Vijayendra Bhamidipati; dev@cloudstack.apache.org Subject: Re: Cannot deploy db on latest 4.1 branch Happens because the management server version was changed to 4.1.2 on the 4.1 branch, but the db upgrade path to 4.1.2 is not present in the databaseupgrade checker. Adding 411-412 db upgrade path - empty if there were no db changes between the releases- should fix this problem. -alena. From: Vijayendra Bhamidipati vijayendra.bhamidip...@citrix.commailto:vijayendra.bhamidip...@citrix.com Date: Friday, August 2, 2013 4:32 PM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Cc: Alena Prokharchyk alena.prokharc...@citrix.commailto:alena.prokharc...@citrix.com Subject: Cannot deploy db on latest 4.1 branch I'm trying to do a simple fresh install of the mgmt. server and db using the latest 4.1 branch, and the building of the code and the deploydb go through smoothly. However, when I attempt to startup the mgmt. server using mvn -pl :cloud-client-ui jetty:run, I run into a problem with the upgrade of the db from 4.0.0 to 4.1.2: . . INFO [utils.component.ComponentContext] (Timer-2:) Running SystemIntegrityChecker encryptionSecretKeyChecker INFO [utils.component.ComponentContext] (Timer-2:) Running SystemIntegrityChecker databaseIntegrityChecker INFO [cloud.upgrade.DatabaseIntegrityChecker] (Timer-2:) Grabbing lock to check for database integrity. INFO [cloud.upgrade.DatabaseIntegrityChecker] (Timer-2:) Performing database integrity check INFO [utils.component.ComponentContext] (Timer-2:) Running SystemIntegrityChecker managementServerNode INFO [utils.component.ComponentContext] (Timer-2:) Running SystemIntegrityChecker databaseUpgradeChecker INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) Grabbing lock to check for database upgrade. INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) DB version = 4.0.0 Code Version = 4.1.2-SNAPSHOT INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) Database upgrade must be performed from 4.0.0 to 4.1.2-SNAPSHOT ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) The end upgrade version is actually at 4.1.1 but our management server code version is at 4.1.2-SNAPSHOT ERROR [utils.component.ComponentContext] (Timer-2:) System integrity check failed. Refuse to startup 2013-08-02 09:40:39.356:INFO::Shutdown hook executing 2013-08-02 09:40:39.357:INFO::Stopped SelectChannelConnector@0.0.0.0mailto:SelectChannelConnector@0.0.0.0:8080 2013-08-02 09:40:39.862:INFO:/client:Closing Spring root WebApplicationContext . . It looks like there are three version numbers - db version, which is at 4.0.0 : mysql select * from db_version; ERROR 1146 (42S02): Table 'cloud.db_version' doesn't exist mysql select * from version; ++-+-+--+ | id | version | updated | step | ++-+-+--+ | 1 | 4.0.0 | 2013-08-02 09:38:16 | Complete | ++-+-+--+ 1 row in set (0.01 sec) mysql And then there is the current version which is 4.1.2, and then an end upgrade version, which is in a map called _upgradeMap in DatabaseUpgradeChecker.java. It looks like the last version in this map is 4.1.1, and since that is less than 4.1.2, mgmt. server startup fails as shown above. Can someone please look into this and fix it? Ccing Alena as well since she's the expert on upgrade paths for CS.. Cheers! Regards, Vijay
Re: Not getting GUI
Not exactly true. OpenJDK / IcedTea etc should work also. On 8/5/13 11:19 AM, Jessica Tomechak jessica.tomec...@citrix.com wrote: I have not heard that Java requirement before. Is that really true? Jessica T. From: Prashant Sreedharan [prashant.sreedha...@citrix.com] Sent: Monday, August 05, 2013 10:36 AM To: us...@cloudstack.apache.org Cc: karthik.c...@gmail.com Subject: RE: Not getting GUI Please find my check list for the Cloudstack management install Make sure that the VM can reach the Internet. ping 8.8.8.8 , ping google.com , Set SELinux to be permissive by default Check JAVA version. Cloudstack requires Sun Java and not the IBM java version. $DB_SERVER be pingable, and MySQL should be listening on that address. The CloudStack management boxes should be running RHEL 6 or centos (check /etc/issue ) The NFS server mount point must work from the CloudStack management VM , Pod XenServes and the secondary storage vm ( ssvm ) To Check JAVA rpm -qa | grep -i java java-1.5.0-gcj-1.5.0.0-29.1.el6.x86_64 java_cup-0.10k-5.el6.x86_64 java-1.6.0-sun-1.6.0.37-1jpp.1.el6_3.x86_6 Please check if these ports are open 1) CloudStack Management Server TCP 9090 + 8250 (bi-directional) To/from CloudStack Management Server 2) User/Client/API TCP 8080 User/Client/API to CloudStack Management Server - Management Port (authenticated communication) 3) User/Client TCP 8096 User/Client to CloudStack Management Server - Management Port (unauthenticated communication) 4) vCenter TCP 443 CloudStack Management Server to vCenter 5) KVM TCP 22 CloudStack Management Server to KVM 6) XenServer TCP 22/80/443 CloudStack Management Server to XenServer 7) MySQL TCP 3306 CloudStack Management Server to MySQL 8) DNS TCP 53 CloudStack Management Server to DNS 9) Secondary Storage TCP 3922 CloudStack Management Server to SSVM 10) Virtual Machine (SSVM) TCP 8250 SSVM to CloudStack Management Server TCP 80/443 SSVM to HTTP(s) File Share to download VM Image TCP 111/2049 SSVM to NFS TCP 53 SSVM to DNS 11) Console Proxy VM TCP 3922 CloudStack Management Server to Console Proxy VM TCP 8250 Console Proxy VM to CloudStack Management Server TCP 53 Console Proxy VM to DNS 12) Virtual Router TCP 3922 CloudStack Management Server to Virtual Router TCP 8250 Virtual Router to CloudStack Management Server TCP 53 Virtual Router to DNS 13) NFS TCP 111/2049 CloudStack Management Server to NFS (initial deployment of SSVM and CPVM thanks Prashant Sreedharan Cloudstack XenServer Administrator , Ops T: +1 805 690 3486 | M: +1 805 453 9105 prashant.sreedha...@citrix.com Powering mobile workstyles and cloud services -Original Message- From: Karthik Kothuri [mailto:karthik.koth...@gmail.com] Sent: Monday, August 05, 2013 9:25 AM To: us...@cloudstack.apache.org Cc: karthik.c...@gmail.com Subject: Re: Not getting GUI Karthik, can you please try restarting the cloudstack management server once. Thanks, Karthik Kothuri On Mon, Aug 5, 2013 at 9:35 PM, karthi keyan karthik.c...@gmail.com wrote: using Bridged network. On Mon, Aug 5, 2013 at 9:32 PM, Bradley Hieber mercsni...@gmail.com wrote: Are you bridged or NAT'd? On Mon, Aug 5, 2013 at 11:57 AM, karthi keyan karthik.c...@gmail.com wrote: Hi Bradley, Thanks in advance. I have started these services, root@csmgmt ~]# service cloud-management start Starting cloud-management: [ OK ] [root@csmgmt ~]# service tomcat6 start Starting tomcat6: [ OK ] [root@csmgmt ~]# service mysqld start Starting mysqld: [ OK ] [root@csmgmt ~]# service nfs status rpc.svcgssd is stopped rpc.mountd (pid 1683) is running... nfsd (pid 1746 1745 1744 1743 1742 1741 1740 1739) is running... rpc.rquotad (pid 1679) is running... In the browser i have given this url: *http://192.168.1.2:8080/client* *And it is displaying a blank page. I have attached the screenshot of that web page.* I have installed CS in Centos 6.3 in VMware workstation. Regards, Karthikeyan On Mon, Aug 5, 2013 at 8:19 PM, Bradley Hieber mercsni...@gmail.com wrote: Karthik, Did you start the service? Which platform did you install CS on? On Mon, Aug 5, 2013 at 10:47 AM, karthi keyan karthik.c...@gmail.com wrote: Hi, I followed the installation Guide of cloustack-4.1.0. And each and every step was sucessfully done. But now i cant able to get the GUI. *http://192.168.1.2:8080/client* # 192.168.1.2 is the management server ip I have no idea. Pls someone help me. Regards, Karthik -- Brad -- Brad -- Thanks and Regards, Karthik Kothuri
[RESULTS] (Was: Re: [VOTE] Whitespace changes to bylaws.mdtext)
We got 4 +1 votes, so the vote was successful. I'll make the changes now. Thanks peeps! On 29 July 2013 22:55, Noah Slater nsla...@apache.org wrote: Hi, I'd like to make several changes to our by-laws, but before I continue, I've prepared a changset that tidies up whitespace and hard wraps. This will make it easier to edit. The only non-whitespace change my patch makes is to correct two spelling errors: Transparancy - Transparency desicion - decision I am hoping this is a non-contentious change and can get the requisite 3 +1 votes. :) Per the by-laws, this is a lazy majority vote, and will be open for 72 hours. We need 3 +1 votes to pass, and more +1 votes than -1 votes. See the end of this email for the full patch. (Our ML does not allow attachments. And I want the change to be concretely tied to the votes.) Thanks, -- NS Index: bylaws.mdtext === --- bylaws.mdtext (revision 1508205) +++ bylaws.mdtext (working copy) @@ -1,6 +1,6 @@ Title: Apache CloudStack Project Bylaws -#1. Introduction +# 1. Introduction 1.1. This document defines the bylaws under which the Apache CloudStack project operates. It defines the roles and responsibilities of the project, who may @@ -13,26 +13,23 @@ operation and background of the foundation. 1.3. CloudStack operates under a set of principles known collectively as the -Apache Way. Those principles are: Transparancy, consensus, non-affiliation, +Apache Way. Those principles are: Transparency, consensus, non-affiliation, respect for fellow developers, and meritocracy, in no specific order. -#2. Roles and Responsibilities +# 2. Roles and Responsibilities Apache projects define a set of roles with associated rights and -responsibilities. These roles govern what tasks an individual may perform within -the project. The roles are defined in the following sections: +responsibilities. These roles govern what tasks an individual may perform +within the project. The roles are defined in the following sections: 2.1. Users The most important participants in the project are people who use our software. -Users can contribute to the Apache projects by providing feedback to -developers in -the form of bug reports and feature suggestions. As well, users can -participate in -the Apache community by helping other users on mailing lists and user support -forums. Users who participate in the project through any mechanism are -considered -to be Contributors. +Users can contribute to the Apache projects by providing feedback to developers +in the form of bug reports and feature suggestions. As well, users can +participate in the Apache community by helping other users on mailing lists and +user support forums. Users who participate in the project through any mechanism +are considered to be Contributors. 2.2. Contributors @@ -49,10 +46,10 @@ 2.3. Committers -The project's Committers are responsible for the project's technical management. -Committers have access to all project source control repositories. Committers -may cast binding votes on any technical discussion regarding the project (or any -sub-project). +The project's Committers are responsible for the project's technical +management. Committers have access to all project source control repositories. +Committers may cast binding votes on any technical discussion regarding the +project (or any sub-project). 2.3.1. Committer access is by invitation only and must be approved by a lazy consensus of the active PMC members. @@ -105,22 +102,21 @@ board quarterly on developments within the CloudStack project. The chair must be an active PMC member. -2.4.5. If the current chair of the PMC resigns, or the term of the -current chair expires, the PMC will attempt to reach consensus on a new -chair through discussion, confirming that consensus via a vote to -recommend a new chair using a lazy 2/3 majority voting method. -In the case that consensus is not achieved, the PMC -will vote for a chair using Single Transferable Vote (STV) voting. -Due to the fact that the discussions are about specific individuals, -this vote would be held on the cloudstack-private mailing list. -The decision must be ratified by the Apache board. +2.4.5. If the current chair of the PMC resigns, or the term of the current +chair expires, the PMC will attempt to reach consensus on a new chair through +discussion, confirming that consensus via a vote to recommend a new chair using +a lazy 2/3 majority voting method. In the case that consensus is not achieved, +the PMC will vote for a chair using Single Transferable Vote (STV) voting. Due +to the fact that the discussions are about specific individuals, this vote +would be held on the cloudstack-private mailing list. The decision must be +ratified by the Apache board. -2.4.6. The role of PMC chair will have a one year
Re: Review Request 13008: Fix usage of vm.instancename.flag when generating VM names on ESX hypervisor
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13008/ --- (Updated Aug. 5, 2013, 9:30 p.m.) Review request for cloudstack, Alex Huang, Chip Childers, Kelven Yang, Sateesh Chodapuneedi, and William Chan. Bugs: CLOUDSTACK-3886 Repository: cloudstack-git Description --- The vminstancename flag has been incorrectly used to simply append the displayname to the internal VM name that shows up on vCenter in vmware deployments. It was intended to show the actual name supplied as hostname, on the hypervisor. This helps admins and deployers to quickly identify VMs and resolve issues related to those VMs. Its usage is very limited as it stands now. This fix corrects it to ensure that the name of the VM on the hypervisor matches the hostname if it is supplied, and if the vm.instancename.flag is set to true. Diffs - engine/orchestration/src/org/apache/cloudstack/platform/orchestration/CloudOrchestrator.java 96fb1d9 plugins/hypervisors/vmware/src/com/cloud/hypervisor/guru/VMwareGuru.java 292f7e9 plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManagerImpl.java 8d6bdb8 plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareStorageManagerImpl.java 10b6de9 plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java 1216e17 plugins/hypervisors/vmware/src/com/cloud/storage/resource/VmwareStorageProcessor.java 112a0cb server/src/com/cloud/configuration/Config.java 0d72694 server/src/com/cloud/ha/HighAvailabilityManagerImpl.java 25c5a04 server/src/com/cloud/hypervisor/HypervisorGuruBase.java e042eb8 server/src/com/cloud/vm/UserVmManagerImpl.java 4a222c4 server/src/com/cloud/vm/VirtualMachineManagerImpl.java 6d35539 setup/db/db/schema-410to420.sql 3f25c3b vmware-base/src/com/cloud/hypervisor/vmware/mo/ClusterMO.java 04ef0f8 vmware-base/src/com/cloud/hypervisor/vmware/mo/CustomFieldConstants.java 11bc157 vmware-base/src/com/cloud/hypervisor/vmware/mo/HostMO.java 2735fb0 vmware-base/src/com/cloud/hypervisor/vmware/mo/HypervisorHostHelper.java dd0f889 vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java e2dd789 vmware-base/src/com/cloud/hypervisor/vmware/mo/VmwareHypervisorHost.java ac14328 Diff: https://reviews.apache.org/r/13008/diff/ Testing (updated) --- Post this change, all major VM operations, namely creation/destruction/expunging/start/stop/reboot of the VM have been tested and observed to work correctly. Part of this patch also puts in a fix for VMSync operations where the CS mgmt server doesn't detect that a guest VM is down, if the guest VM has been shut down/powered off in vCenter. Other operations such as VM snapshot, volume snapshots of disks belonging to the VM, volume migration across primaries, volume attach/detach have also been tested and they are working as expected. This is a functional change, and completely transparent to any of cloudstack's existing functionalities and all the test cases that cover the above code paths and APIs - all existing tests should and do pass - no new tests are necessary. UPDATE for 08/05/2013 = 4.2 code has diverged - need to refactor the patch on top of latest 4.2. Will test out refactored patch and resubmit. Thanks, Venkata Siva Vijayendra Bhamidipati
IP Address Allocation
I am trying to figure out what would be the proper way for a Plugin to interact with the CloudStack VM deployment and provide an authoritative IP Address from its database versus the local CloudStack database. It looks like the NetworkElements are not presented an opportunity to provide an IP Address and you must develop a NetworkGuru to provide this function. There is some customization of the IP Address designed into the Secondary NICs (see allocateGuestIP()). -Soheil
[VOTE] Update by-laws: non-technical decisions and other minor changes
Hi dev, I have some more by-law changes to propose. This is essentially round 2 for these changes. I incorporated feedback from the last thread. Per the by-laws, we're using a lazy majority for this vote. Please cast your vote now. I will tally the results in 72 hours. Here's my changelog: * Removed some spurious nbsp; entities * Added A technical decision is any decision that involves changes to the source code that we distribute in our official releases. to § 3.4.1 (Technical Decisions). * Added discussion-lead before consensus gathering in this section. * With the improved definition, I have tightened up the wording so that technical decisions must be made on @dev. * Added § 3.4.2, Non-Technical Decisions. Non-technical decisions are defined as in the inverse of technical decisions. They can be made on whatever list is appropriate. Formal voting will use a lazy 2/3 majority. Votes cannot be vetoed. * Changed § 3.4.3. (Release Plan) to limit decisions to @dev. * Changed § 3.4.4. (Product Release) to limit decisions to @dev. * Changed § 3.4.5. (Adoption of New Codebase) to limit decisions to @dev. * Changed § 3.4.10. (Modifying Bylaws) to limit decisions to @dev. * Added an Oxford comma to the final paras of § 3.4.1. and § 3.4.2. * Section renumbering to accommodate § 3.4.2. And here's the patch: Index: bylaws.mdtext === --- bylaws.mdtext (revision 1510739) +++ bylaws.mdtext (working copy) @@ -198,41 +198,64 @@ 3.4.1. Technical Decisions +A technical decision is any decision that involves changes to the source code +that we distribute in our official releases. + Technical decisions should normally be made by the entire community using -consensusnbsp;gathering, and not through formal voting. +discussion-lead consensus gathering, and not through formal voting. -Technical decisions must be made on a project development mailing list. +Technical decisions must be made on the project development mailing list. During the consensus gathering process, technical decisions may be vetoed by any Committer with a valid reason. If a formal vote is started for a technical decision, the vote will be held as -a lazynbsp;consensusnbsp;of active committers. +a lazy consensus of active committers. -Any user, contributor, committer or PMC member can initiate a technical +Any user, contributor, committer, or PMC member can initiate a technical decision making process. -3.4.2. Release Plan +3.4.2. Non-Technical Decisions +A non-technical decisions is any decision that does not involve changes to the +source code that we distribute in our official releases. + +Non-technical decisions should normally be made by the entire community using +discussion-lead consensus-building, and not through formal voting. + +Non-technical decisions can be made on whichever project mailing list is most +appropriate. + +Non-technical decisions cannot be vetoed, but if there is strong opposition +a formal vote can be used to resolve the dispute. + +If a formal vote is started for a non-technical decision, the vote will be held +as a lazy 2/3 majority of active committers. + +Any user, contributor, committer, or PMC member can initiate a non-technical +decision making process. + +3.4.3. Release Plan + Defines the timetable and work items for a release. The plan also nominates a Release Manager. A lazy majority of active committers is required for approval. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. -3.4.3. Product Release +3.4.4. Product Release When a release of one of the project's products is ready, a vote is required to accept the release as an official release of the project. Lazy Majority of active PMC members is required for approval. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. -3.4.4. Adoption of New Codebase +3.4.5. Adoption of New Codebase When the codebase for an existing, released product is to be replaced with an alternative codebase. If such a vote fails to gain approval, the existing code @@ -242,10 +265,10 @@ Lazy 2/3 majority of active PMC members. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. -3.4.5. New Committer +3.4.6. New Committer When a new committer is proposed for the project. @@ -254,7 +277,7 @@ Any active PMC member may call a vote. The vote must occur on the PMC private mailing list. -3.4.6. New PMC Member +3.4.7. New PMC Member When a committer is proposed for the PMC. @@ -263,7 +286,7 @@ Any active PMC member may call a vote. The vote must occur on the PMC
Breaking docs out
Hi folks: I'd like to propose breaking out a nuymber of our documents into their own repos. My thinking is that specifically; the release notes, midonet, and niciranvp documentation shares very little with the rest of the documentation, and should be broken out akin to how the QIG is currently broken out. The particular problem I am trying to solve is to deal with publishing. For instance, even though the release notes are contained in just a few xml documents, it copies content from every single xml file in thd directory - over 400 - and it also copies those up to the website. Splitting things up also allows us to prioritize l10n. Right now, we just dump 400 xml files worth of content into transifex and people translate away - they can't put a priority on release notes, or de-emphasize more esoteric documentation like Nicira or Midonet. Eventually I'd like to break out each of the individual guides into their own document - separate from the other. Right now they carry a ton of similar content so that isn't very practical; but it's what I am thinking, perhaps for 4.4 or 4.5. In the meantime, I'd like to make this change as soon as we think we have documentation pretty close to done for 4.2 to minimize the disruptive effects. Thoughts, comments, flames? --David
4.1.x KVM cloudVirBrvlan to brdev-vlan
All,
As most know, the upgrade from 4.0 to 4.1 changed the interface naming schema.
When a host in a cluster is rebooted, the interface naming changes. When this
occurs, live migration breaks to that host.
Example config:
All Management and hosts running CS 4.1.1
Hypervisor: KVM on RHEL 6.3
Host 1 has older 4.0 interface naming schema
Host 2 was rebooted and has newer interface schema
Live Migration is looking for older interface schema name (i.e.
cloudVirBrvlan) when attempting a migration from Host 1 to Host 2.
Here's a sample log:
2013-08-05 16:45:21,846 DEBUG [agent.transport.Request]
(Job-Executor-34:job-1660) Seq 19-1921285594: Sending { Cmd , MgmtId:
159090354809909, via: 19, Ver: v1, Flags: 100111,
[{MigrateCommand:{vmName:i-44-255-VM,destIp:hostip,hostGuid:91e9b633-f46b-31f3-9a4b-92285fd94b62-LibvirtComputingResource,isWindows:false,wait:0}}]
}
2013-08-05 16:45:21,926 DEBUG [agent.transport.Request] (StatsCollector-1:null)
Seq 1-1768126050: Received: { Ans: , MgmtId: 159090354809909, via: 1, Ver: v1,
Flags: 10, { GetVmStatsAnswer } }
2013-08-05 16:45:21,963 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-7:null) Ping from 5
2013-08-05 16:45:22,012 DEBUG [agent.transport.Request]
(AgentManager-Handler-9:null) Seq 19-1921285594: Processing: { Ans: , MgmtId:
159090354809909, via: 19, Ver: v1, Flags: 110,
[{MigrateAnswer:{result:false,details:Cannot get interface MTU on
'cloudVirBr18': No such device,wait:0}}] }
2013-08-05 16:45:22,012 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-9:null) Seq 19-1921285594: No more commands found
2013-08-05 16:45:22,012 DEBUG [agent.transport.Request]
(Job-Executor-34:job-1660) Seq 19-1921285594: Received: { Ans: , MgmtId:
159090354809909, via: 19, Ver: v1, Flags: 110, { MigrateAnswer } }
2013-08-05 16:45:22,012 ERROR [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-34:job-1660) Unable to migrate due to Cannot get interface MTU on
'cloudVirBr18': No such device
2013-08-05 16:45:22,013 INFO [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-34:job-1660) Migration was unsuccessful. Cleaning up:
VM[User|app01-dev]
2013-08-05 16:45:22,018
Is there any current way to change the destination network CS Management uses
so that a complete VM shutdown and restart isn't required to re-enable
migration between hosts?
Any ideas would be appreciated.
- Si
Re: 4.1.x KVM cloudVirBrvlan to brdev-vlan
Yes, the vm definition already has the bridge name chosen (on initial
startup), and that definition is migrated between hosts. This is
further exacerbated by the fact that the bridges are created on the
destination host prior to migration (so they'll be ready), rather than
somehow being able to see the existing configuration and prepare for
the vm based on that. That ultimately probably doesn't matter much
anyway, since we can't host two different bridges for the same vlan
(the advantage of detecting what bridge name a migrating VM has would
be to bring up the required bridge name for migrating VMs, and use the
new bridge name for freshly started VMs, which isn't possible).
As a workaround, if you want to force any rebooted, upgraded KVM hosts
to use the old style naming, you can create any random bridge named
'cloudVirBr', and the agent will detect it and continue to use the old
style naming until such point when you can or need to switch to the
capabilities of the new style naming. At that point you'll need to
stop any and all VMs that are using the old style name, remove any old
style bridges (or reboot the host), and then start things back up.
This really should have been documented in the release notes. I think
it was a misunderstanding that the upgrade process would require
everything be restarted.
On Mon, Aug 5, 2013 at 4:05 PM, Simon Weller swel...@ena.com wrote:
All,
As most know, the upgrade from 4.0 to 4.1 changed the interface naming
schema. When a host in a cluster is rebooted, the interface naming changes.
When this occurs, live migration breaks to that host.
Example config:
All Management and hosts running CS 4.1.1
Hypervisor: KVM on RHEL 6.3
Host 1 has older 4.0 interface naming schema
Host 2 was rebooted and has newer interface schema
Live Migration is looking for older interface schema name (i.e.
cloudVirBrvlan) when attempting a migration from Host 1 to Host 2.
Here's a sample log:
2013-08-05 16:45:21,846 DEBUG [agent.transport.Request]
(Job-Executor-34:job-1660) Seq 19-1921285594: Sending { Cmd , MgmtId:
159090354809909, via: 19, Ver: v1, Flags: 100111,
[{MigrateCommand:{vmName:i-44-255-VM,destIp:hostip,hostGuid:91e9b633-f46b-31f3-9a4b-92285fd94b62-LibvirtComputingResource,isWindows:false,wait:0}}]
}
2013-08-05 16:45:21,926 DEBUG [agent.transport.Request]
(StatsCollector-1:null) Seq 1-1768126050: Received: { Ans: , MgmtId:
159090354809909, via: 1, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
2013-08-05 16:45:21,963 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-7:null) Ping from 5
2013-08-05 16:45:22,012 DEBUG [agent.transport.Request]
(AgentManager-Handler-9:null) Seq 19-1921285594: Processing: { Ans: , MgmtId:
159090354809909, via: 19, Ver: v1, Flags: 110,
[{MigrateAnswer:{result:false,details:Cannot get interface MTU on
'cloudVirBr18': No such device,wait:0}}] }
2013-08-05 16:45:22,012 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-9:null) Seq 19-1921285594: No more commands found
2013-08-05 16:45:22,012 DEBUG [agent.transport.Request]
(Job-Executor-34:job-1660) Seq 19-1921285594: Received: { Ans: , MgmtId:
159090354809909, via: 19, Ver: v1, Flags: 110, { MigrateAnswer } }
2013-08-05 16:45:22,012 ERROR [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-34:job-1660) Unable to migrate due to Cannot get interface MTU
on 'cloudVirBr18': No such device
2013-08-05 16:45:22,013 INFO [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-34:job-1660) Migration was unsuccessful. Cleaning up:
VM[User|app01-dev]
2013-08-05 16:45:22,018
Is there any current way to change the destination network CS Management uses
so that a complete VM shutdown and restart isn't required to re-enable
migration between hosts?
Any ideas would be appreciated.
- Si
Issue with deleting a volume that's never been attached to a VM
Hi, I've noticed in 4.2 when I try to delete a volume that's never been attached to a VM that CloudStack says the operation was successful and the GUI removes the volume from the table, but when I refresh the table, the volume comes back. Has anyone else noticed this behavior as of late? If I attach the volume, then detach it, then delete it, all behaves as expected. 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.1.x KVM cloudVirBrvlan to brdev-vlan
Thanks Marcus. We already thought of creating the old bridge, but we were
hoping we had better options ;-)
- Original Message -
From: Marcus Sorensen shadow...@gmail.com
To: dev@cloudstack.apache.org
Cc: cloudstack-...@incubator.apache.org
Sent: Monday, August 5, 2013 5:42:38 PM
Subject: Re: 4.1.x KVM cloudVirBrvlan to brdev-vlan
Yes, the vm definition already has the bridge name chosen (on initial
startup), and that definition is migrated between hosts. This is
further exacerbated by the fact that the bridges are created on the
destination host prior to migration (so they'll be ready), rather than
somehow being able to see the existing configuration and prepare for
the vm based on that. That ultimately probably doesn't matter much
anyway, since we can't host two different bridges for the same vlan
(the advantage of detecting what bridge name a migrating VM has would
be to bring up the required bridge name for migrating VMs, and use the
new bridge name for freshly started VMs, which isn't possible).
As a workaround, if you want to force any rebooted, upgraded KVM hosts
to use the old style naming, you can create any random bridge named
'cloudVirBr', and the agent will detect it and continue to use the old
style naming until such point when you can or need to switch to the
capabilities of the new style naming. At that point you'll need to
stop any and all VMs that are using the old style name, remove any old
style bridges (or reboot the host), and then start things back up.
This really should have been documented in the release notes. I think
it was a misunderstanding that the upgrade process would require
everything be restarted.
On Mon, Aug 5, 2013 at 4:05 PM, Simon Weller swel...@ena.com wrote:
All,
As most know, the upgrade from 4.0 to 4.1 changed the interface naming
schema. When a host in a cluster is rebooted, the interface naming changes.
When this occurs, live migration breaks to that host.
Example config:
All Management and hosts running CS 4.1.1
Hypervisor: KVM on RHEL 6.3
Host 1 has older 4.0 interface naming schema
Host 2 was rebooted and has newer interface schema
Live Migration is looking for older interface schema name (i.e.
cloudVirBrvlan) when attempting a migration from Host 1 to Host 2.
Here's a sample log:
2013-08-05 16:45:21,846 DEBUG [agent.transport.Request]
(Job-Executor-34:job-1660) Seq 19-1921285594: Sending { Cmd , MgmtId:
159090354809909, via: 19, Ver: v1, Flags: 100111,
[{MigrateCommand:{vmName:i-44-255-VM,destIp:hostip,hostGuid:91e9b633-f46b-31f3-9a4b-92285fd94b62-LibvirtComputingResource,isWindows:false,wait:0}}]
}
2013-08-05 16:45:21,926 DEBUG [agent.transport.Request]
(StatsCollector-1:null) Seq 1-1768126050: Received: { Ans: , MgmtId:
159090354809909, via: 1, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
2013-08-05 16:45:21,963 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-7:null) Ping from 5
2013-08-05 16:45:22,012 DEBUG [agent.transport.Request]
(AgentManager-Handler-9:null) Seq 19-1921285594: Processing: { Ans: , MgmtId:
159090354809909, via: 19, Ver: v1, Flags: 110,
[{MigrateAnswer:{result:false,details:Cannot get interface MTU on
'cloudVirBr18': No such device,wait:0}}] }
2013-08-05 16:45:22,012 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-9:null) Seq 19-1921285594: No more commands found
2013-08-05 16:45:22,012 DEBUG [agent.transport.Request]
(Job-Executor-34:job-1660) Seq 19-1921285594: Received: { Ans: , MgmtId:
159090354809909, via: 19, Ver: v1, Flags: 110, { MigrateAnswer } }
2013-08-05 16:45:22,012 ERROR [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-34:job-1660) Unable to migrate due to Cannot get interface MTU
on 'cloudVirBr18': No such device
2013-08-05 16:45:22,013 INFO [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-34:job-1660) Migration was unsuccessful. Cleaning up:
VM[User|app01-dev]
2013-08-05 16:45:22,018
Is there any current way to change the destination network CS Management uses
so that a complete VM shutdown and restart isn't required to re-enable
migration between hosts?
Any ideas would be appreciated.
- Si
Re: 4.1.x KVM cloudVirBrvlan to brdev-vlan
Cloudstack will create the old bridges as it used to, you just need to have
a single 'cloudVirBr' device to trigger the behavior.
On Aug 5, 2013 6:35 PM, Simon Weller swel...@ena.com wrote:
Thanks Marcus. We already thought of creating the old bridge, but we were
hoping we had better options ;-)
- Original Message -
From: Marcus Sorensen shadow...@gmail.com
To: dev@cloudstack.apache.org
Cc: cloudstack-...@incubator.apache.org
Sent: Monday, August 5, 2013 5:42:38 PM
Subject: Re: 4.1.x KVM cloudVirBrvlan to brdev-vlan
Yes, the vm definition already has the bridge name chosen (on initial
startup), and that definition is migrated between hosts. This is
further exacerbated by the fact that the bridges are created on the
destination host prior to migration (so they'll be ready), rather than
somehow being able to see the existing configuration and prepare for
the vm based on that. That ultimately probably doesn't matter much
anyway, since we can't host two different bridges for the same vlan
(the advantage of detecting what bridge name a migrating VM has would
be to bring up the required bridge name for migrating VMs, and use the
new bridge name for freshly started VMs, which isn't possible).
As a workaround, if you want to force any rebooted, upgraded KVM hosts
to use the old style naming, you can create any random bridge named
'cloudVirBr', and the agent will detect it and continue to use the old
style naming until such point when you can or need to switch to the
capabilities of the new style naming. At that point you'll need to
stop any and all VMs that are using the old style name, remove any old
style bridges (or reboot the host), and then start things back up.
This really should have been documented in the release notes. I think
it was a misunderstanding that the upgrade process would require
everything be restarted.
On Mon, Aug 5, 2013 at 4:05 PM, Simon Weller swel...@ena.com wrote:
All,
As most know, the upgrade from 4.0 to 4.1 changed the interface naming
schema. When a host in a cluster is rebooted, the interface naming changes.
When this occurs, live migration breaks to that host.
Example config:
All Management and hosts running CS 4.1.1
Hypervisor: KVM on RHEL 6.3
Host 1 has older 4.0 interface naming schema
Host 2 was rebooted and has newer interface schema
Live Migration is looking for older interface schema name (i.e.
cloudVirBrvlan) when attempting a migration from Host 1 to Host 2.
Here's a sample log:
2013-08-05 16:45:21,846 DEBUG [agent.transport.Request]
(Job-Executor-34:job-1660) Seq 19-1921285594: Sending { Cmd , MgmtId:
159090354809909, via: 19, Ver: v1, Flags: 100111,
[{MigrateCommand:{vmName:i-44-255-VM,destIp:hostip,hostGuid:91e9b633-f46b-31f3-9a4b-92285fd94b62-LibvirtComputingResource,isWindows:false,wait:0}}]
}
2013-08-05 16:45:21,926 DEBUG [agent.transport.Request]
(StatsCollector-1:null) Seq 1-1768126050: Received: { Ans: , MgmtId:
159090354809909, via: 1, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
2013-08-05 16:45:21,963 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-7:null) Ping from 5
2013-08-05 16:45:22,012 DEBUG [agent.transport.Request]
(AgentManager-Handler-9:null) Seq 19-1921285594: Processing: { Ans: ,
MgmtId: 159090354809909, via: 19, Ver: v1, Flags: 110,
[{MigrateAnswer:{result:false,details:Cannot get interface MTU on
'cloudVirBr18': No such device,wait:0}}] }
2013-08-05 16:45:22,012 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-9:null) Seq 19-1921285594: No more commands found
2013-08-05 16:45:22,012 DEBUG [agent.transport.Request]
(Job-Executor-34:job-1660) Seq 19-1921285594: Received: { Ans: , MgmtId:
159090354809909, via: 19, Ver: v1, Flags: 110, { MigrateAnswer } }
2013-08-05 16:45:22,012 ERROR [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-34:job-1660) Unable to migrate due to Cannot get interface
MTU on 'cloudVirBr18': No such device
2013-08-05 16:45:22,013 INFO [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-34:job-1660) Migration was unsuccessful. Cleaning up:
VM[User|app01-dev]
2013-08-05 16:45:22,018
Is there any current way to change the destination network CS Management
uses so that a complete VM shutdown and restart isn't required to re-enable
migration between hosts?
Any ideas would be appreciated.
- Si
RE: unable to view content of cwiki
Am still not able to access any pages. Ex : https://cwiki.apache.org/confluence/users/viewmyprofile.action even a publicly accessable page, when I login am getting error Not Permitted You are not permitted to perform this operation. Please do the needful. Thanks Rajesh Battala -Original Message- From: Go Chiba [mailto:go.ch...@gmail.com] Sent: Monday, August 5, 2013 7:37 PM To: dev@cloudstack.apache.org Subject: Re: unable to view content of cwiki Yes, I able to access them too. Rajesh, are you still can't access cwiki page? if yes, please share some example link. On Mon, Aug 5, 2013 at 10:47 PM, Daan Hoogland daan.hoogl...@gmail.comwrote: I've able to access the wiki all day so far. On Mon, Aug 5, 2013 at 12:43 PM, Rajesh Battala rajesh.batt...@citrix.com wrote: Hi All, Am not able to view any link of cwiki. Am getting permission denied to view any content. Please let me know how to resolve this issue. Thanks Rajesh Battala -- 千葉 豪 Go Chiba E-mail:go.ch...@gmail.com
RE: IP Address Allocation
One way to achieve this behavior is to have a call out in prepareNic() to the NetworkElements before the call to the NetworkGuru allowing the NetworkElement to update the Nic Profile. In this use case the Network Element would suggest an IP Address. In the use case below the IP Address would be updated by the NetworkElement. There is logic in getIp(), the current IP Allocation that handles the case where the Nic Profile already has an IP Address. This needs to be updated to handle this new use case. The current use case assume that the VM had already been prepared once and has an IP Address allocated that could be reused. Does anyone see a problem with this approach? -Soheil From: Soheil Eizadi [seiz...@infoblox.com] Sent: Monday, August 05, 2013 2:35 PM To: dev@cloudstack.apache.org Subject: IP Address Allocation I am trying to figure out what would be the proper way for a Plugin to interact with the CloudStack VM deployment and provide an authoritative IP Address from its database versus the local CloudStack database. It looks like the NetworkElements are not presented an opportunity to provide an IP Address and you must develop a NetworkGuru to provide this function. There is some customization of the IP Address designed into the Secondary NICs (see allocateGuestIP()). -Soheil
RE: Breaking docs out
Make perfect sense. + 1 -Radhika -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Tuesday, August 06, 2013 3:13 AM To: dev@cloudstack.apache.org Subject: Breaking docs out Hi folks: I'd like to propose breaking out a nuymber of our documents into their own repos. My thinking is that specifically; the release notes, midonet, and niciranvp documentation shares very little with the rest of the documentation, and should be broken out akin to how the QIG is currently broken out. The particular problem I am trying to solve is to deal with publishing. For instance, even though the release notes are contained in just a few xml documents, it copies content from every single xml file in thd directory - over 400 - and it also copies those up to the website. Splitting things up also allows us to prioritize l10n. Right now, we just dump 400 xml files worth of content into transifex and people translate away - they can't put a priority on release notes, or de-emphasize more esoteric documentation like Nicira or Midonet. Eventually I'd like to break out each of the individual guides into their own document - separate from the other. Right now they carry a ton of similar content so that isn't very practical; but it's what I am thinking, perhaps for 4.4 or 4.5. In the meantime, I'd like to make this change as soon as we think we have documentation pretty close to done for 4.2 to minimize the disruptive effects. Thoughts, comments, flames? --David
Re: Review Request 12934: Tests for egress firewall rules for advance zone
On Aug. 5, 2013, 9:55 a.m., Jayapal Reddy wrote: test/integration/component/test_egress_fw_rules.py, line 27 https://reviews.apache.org/r/12934/diff/5/?file=336941#file336941line27 remove the white space (red colour). Please apply the patch in your local and make sure there is no warning. # git apply patchName.patch Removed the trailing white space. On Aug. 5, 2013, 9:55 a.m., Jayapal Reddy wrote: test/integration/component/test_egress_fw_rules.py, line 108 https://reviews.apache.org/r/12934/diff/5/?file=336941#file336941line108 do we need specify vlan here ? No need to specify the VLAN ID here. On Aug. 5, 2013, 9:55 a.m., Jayapal Reddy wrote: test/integration/component/test_egress_fw_rules.py, line 130 https://reviews.apache.org/r/12934/diff/5/?file=336941#file336941line130 Hard coding vlan may not work for others setups. If specify vlan is set then query the free vlan id Removed VLAN ID value from service data. - Ashutosh --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12934/#review24640 --- On Aug. 1, 2013, 6:19 a.m., Ashutosh Kelkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12934/ --- (Updated Aug. 1, 2013, 6:19 a.m.) Review request for cloudstack, Girish Shilamkar, Jayapal Reddy, and Prasanna Santhanam. Repository: cloudstack-git Description --- Tests for egress firewall rules for advance zone. Diffs - test/integration/component/test_egress_fw_rules.py PRE-CREATION Diff: https://reviews.apache.org/r/12934/diff/ Testing --- Thanks, Ashutosh Kelkar
Re: Review Request 12934: Tests for egress firewall rules for advance zone
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12934/ --- (Updated Aug. 6, 2013, 4:38 a.m.) Review request for cloudstack, Girish Shilamkar, Jayapal Reddy, and Prasanna Santhanam. Changes --- Removed hard coded value of VLAN ID from network service data. White space cleanup. Repository: cloudstack-git Description --- Tests for egress firewall rules for advance zone. Diffs (updated) - test/integration/component/test_egress_fw_rules.py PRE-CREATION Diff: https://reviews.apache.org/r/12934/diff/ Testing --- Thanks, Ashutosh Kelkar
RE: Issue with deleting a volume that's never been attached to a VM
I will try on my setup -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Tuesday, August 6, 2013 4:48 AM To: dev@cloudstack.apache.org Subject: Issue with deleting a volume that's never been attached to a VM Hi, I've noticed in 4.2 when I try to delete a volume that's never been attached to a VM that CloudStack says the operation was successful and the GUI removes the volume from the table, but when I refresh the table, the volume comes back. Has anyone else noticed this behavior as of late? If I attach the volume, then detach it, then delete it, all behaves as expected. 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 *(tm)*
[ACS42] Closure of Resolved Defects - 8/5
Below defects are resolved for 4.2 - can you pl review, validate and close the defects. If the fix is not done as per the defect logged, pl reopen the defect so developer who fixed would get a chance to review the fix before product goes to GA. Reporter Total Grand Total519 Sangeetha Hariharan 47 Prasanna Santhanam 46 Rayees Namathponnan43 Nitin Mehta29 Srikanteswararao Talluri22 Alena Prokharchyk 20 Chandan Purushothama 18 Sateesh Chodapuneedi 18 Sanjeev N 16 Sheng Yang 15 Prachi Damle 10 Murali Reddy 9 venkata swamybabu budumuru 9 Harikrishna Patnala 8 Jayapal Reddy 8 Kishan Kavala 8 Likitha Shetty 8 Sowmya Krishnan8 Parth Jagirdar7 prashant kumar mishra 7 Saksham Srivastava 7 Abhinav Roy 6 Mike Tutkowski6 sadhu suresh 6 Sailaja Mada 6 Sanjay Tripathi 6 Ahmad Emneina 5 Min Chen5 angeline shen4 Anthony Xu4 Bharat Kumar4 Francois Gaudreault 4 Isaac Chiang 4 Koushik Das4 Minying Bao 4 Rajesh Battala 4 shweta agarwal4 Devdeep Singh 3 Girish Shilamkar3 ilya musayev 3 Jessica Tomechak3 manasaveloori 3 Rohit Yadav3 Ryan Lei 3 Venkata Siva Vijayendra Bhamidipati 3 Wido den Hollander3 Dave Cahill 2 David Noland 2 Fang Wang 2 frank zhang2 Hiroaki Kawai 2 John Burwell 2 Kiran Koneti 2 Paul Angus 2 Pavan Kumar Bandarupally 2 Radhika Nair 2 Toshiaki Hatano2 Abhinandan Prateek 1 Brian Angus1 Brian Spindler1 Caleb Call 1 Chris Sears 1 Daan Hoogland 1 Dave Brosius 1 David Nalley 1 david vz1 Diogo Monteiro1 edison su 1 Hongtu Zang 1 Hugo Trippaers 1 Jeronimo 1 Jessica Wang 1 Kelven Yang 1 Mice Xia 1 Michael Dickey 1 Nick Wales 1 Nicolas Lamirault 1 Nik Martin 1 Pranav Saxena 1 roxanne chang 1 satoru nakaya1 sebastien goasguen1 Shane Witbeck 1 Sharad Yadav 1 Simon Weller 1 Sonny Chhen 1 Sreekanth Challa 1 Thomas O'Dowd 1
RE: Issue with deleting a volume that's never been attached to a VM
I able to reproduce it. Deleting unattached volume is coming back again. The removed column is not update in the db for this volume. Will create a major bug. *** 6. row *** id: 6 account_id: 2 domain_id: 1 pool_id: NULL last_pool_id: NULL instance_id: NULL device_id: NULL name: testVol uuid: 3b008262-1c52-49a7-900d-b38fbf274e89 size: 5368709120 folder: NULL path: NULL pod_id: NULL data_center_id: 1 iscsi_name: NULL host_ip: NULL volume_type: DATADISK pool_type: NULL disk_offering_id: 3 template_id: NULL first_snapshot_backup_uuid: NULL recreatable: 0 created: 2013-08-06 04:47:07 attached: NULL updated: 2013-08-06 04:47:07 removed: NULL state: Allocated chain_info: NULL update_count: 0 disk_type: NULL vm_snapshot_chain_size: NULL iso_id: 0 display_volume: 1 format: NULL min_iops: NULL max_iops: NULL 6 rows in set (0.00 sec) -Original Message- From: Rajesh Battala [mailto:rajesh.batt...@citrix.com] Sent: Tuesday, August 6, 2013 10:15 AM To: dev@cloudstack.apache.org Subject: RE: Issue with deleting a volume that's never been attached to a VM I will try on my setup -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Tuesday, August 6, 2013 4:48 AM To: dev@cloudstack.apache.org Subject: Issue with deleting a volume that's never been attached to a VM Hi, I've noticed in 4.2 when I try to delete a volume that's never been attached to a VM that CloudStack says the operation was successful and the GUI removes the volume from the table, but when I refresh the table, the volume comes back. Has anyone else noticed this behavior as of late? If I attach the volume, then detach it, then delete it, all behaves as expected. 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 *(tm)*
RE: Issue with deleting a volume that's never been attached to a VM
Hi Rajesh, I have created the issue some time back @ CLOUDSTACK-4038) State of the DATA volumes remains in Allocated state if they are deleted before using them (Attach/Detach) Thanks, Sailaja.M -Original Message- From: Rajesh Battala [mailto:rajesh.batt...@citrix.com] Sent: Tuesday, August 06, 2013 10:22 AM To: dev@cloudstack.apache.org Subject: RE: Issue with deleting a volume that's never been attached to a VM I able to reproduce it. Deleting unattached volume is coming back again. The removed column is not update in the db for this volume. Will create a major bug. *** 6. row *** id: 6 account_id: 2 domain_id: 1 pool_id: NULL last_pool_id: NULL instance_id: NULL device_id: NULL name: testVol uuid: 3b008262-1c52-49a7-900d-b38fbf274e89 size: 5368709120 folder: NULL path: NULL pod_id: NULL data_center_id: 1 iscsi_name: NULL host_ip: NULL volume_type: DATADISK pool_type: NULL disk_offering_id: 3 template_id: NULL first_snapshot_backup_uuid: NULL recreatable: 0 created: 2013-08-06 04:47:07 attached: NULL updated: 2013-08-06 04:47:07 removed: NULL state: Allocated chain_info: NULL update_count: 0 disk_type: NULL vm_snapshot_chain_size: NULL iso_id: 0 display_volume: 1 format: NULL min_iops: NULL max_iops: NULL 6 rows in set (0.00 sec) -Original Message- From: Rajesh Battala [mailto:rajesh.batt...@citrix.com] Sent: Tuesday, August 6, 2013 10:15 AM To: dev@cloudstack.apache.org Subject: RE: Issue with deleting a volume that's never been attached to a VM I will try on my setup -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Tuesday, August 6, 2013 4:48 AM To: dev@cloudstack.apache.org Subject: Issue with deleting a volume that's never been attached to a VM Hi, I've noticed in 4.2 when I try to delete a volume that's never been attached to a VM that CloudStack says the operation was successful and the GUI removes the volume from the table, but when I refresh the table, the volume comes back. Has anyone else noticed this behavior as of late? If I attach the volume, then detach it, then delete it, all behaves as expected. 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 *(tm)*
Re: Issue with deleting a volume that's never been attached to a VM
Already in the JIRA reports - CLOUDSTACK-4038 On Tue, Aug 06, 2013 at 04:51:31AM +, Rajesh Battala wrote: I able to reproduce it. Deleting unattached volume is coming back again. The removed column is not update in the db for this volume. Will create a major bug. *** 6. row *** id: 6 account_id: 2 domain_id: 1 pool_id: NULL last_pool_id: NULL instance_id: NULL device_id: NULL name: testVol uuid: 3b008262-1c52-49a7-900d-b38fbf274e89 size: 5368709120 folder: NULL path: NULL pod_id: NULL data_center_id: 1 iscsi_name: NULL host_ip: NULL volume_type: DATADISK pool_type: NULL disk_offering_id: 3 template_id: NULL first_snapshot_backup_uuid: NULL recreatable: 0 created: 2013-08-06 04:47:07 attached: NULL updated: 2013-08-06 04:47:07 removed: NULL state: Allocated chain_info: NULL update_count: 0 disk_type: NULL vm_snapshot_chain_size: NULL iso_id: 0 display_volume: 1 format: NULL min_iops: NULL max_iops: NULL 6 rows in set (0.00 sec) -Original Message- From: Rajesh Battala [mailto:rajesh.batt...@citrix.com] Sent: Tuesday, August 6, 2013 10:15 AM To: dev@cloudstack.apache.org Subject: RE: Issue with deleting a volume that's never been attached to a VM I will try on my setup -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Tuesday, August 6, 2013 4:48 AM To: dev@cloudstack.apache.org Subject: Issue with deleting a volume that's never been attached to a VM Hi, I've noticed in 4.2 when I try to delete a volume that's never been attached to a VM that CloudStack says the operation was successful and the GUI removes the volume from the table, but when I refresh the table, the volume comes back. Has anyone else noticed this behavior as of late? If I attach the volume, then detach it, then delete it, all behaves as expected. 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 *(tm)* -- Prasanna., Powered by BigRock.com
RE: [Doc] Dedicated Resources: Public IPs and VLANs per Account is Ready
Hi, Thanks for the review, Likitha. I have incorporated them. The latest doc is attached at https://issues.apache.org/jira/browse/CLOUDSTACK-817. Abhinav, let me know if you have further comments. Thanks -Radhika From: Likitha Shetty Sent: Friday, August 02, 2013 11:42 AM To: Radhika Puthiyetath; us...@cloudstack.apache.org; dev@cloudstack.apache.org; Abhinav Roy Subject: RE: [Doc] Dedicated Resources: Public IPs and VLANs per Account is Ready I just have 2 comments, 1. Since this feature allows the admin to assign (and release) the IP addresses and VLANs only to an account, not both domain and account we need to modify the introduction accordingly. 2. And could you also add the following to section 15.8, If an account has consumed all the VLANs and IPs dedicated to it, the account can acquire the 2 resources from the system. Cloudstack provides the ROOT admin with 2 configuration parameter to modify this default behavior - use.system.public.ips and use.system.guest.vlans. The 2 global configs allow the ROOT admin to disallow an account from acquiring public IPs and guest VLANs from the system if the account has dedicated resources and these dedicated resources have all been consumed. Both these configurations are configurable at the account level too. (https://issues.apache.org/jira/browse/CLOUDSTACK-3011) Everything else looks good. Thanks, Likitha From: Radhika Puthiyetath Sent: Thursday, August 01, 2013 3:51 PM To: us...@cloudstack.apache.orgmailto:us...@cloudstack.apache.org; dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org; Abhinav Roy; Likitha Shetty Subject: [Doc] Dedicated Resources: Public IPs and VLANs per Account is Ready Hi, Dedicated Resources: Public IPs and VLANs per Account is Ready documentation is ready for review. The doc is attached at https://issues.apache.org/jira/browse/CLOUDSTACK-817 Please see section 15.8. Reserving Public IP Addresses and VLANs Per Account (132), and provide your feedback. Regards -Radhika
RE: [Doc] Dedicated Resources: Public IPs and VLANs per Account is Ready
Looks good to me Radhika. Thank you! From: Radhika Puthiyetath Sent: Tuesday, August 06, 2013 11:04 AM To: Likitha Shetty; us...@cloudstack.apache.org; dev@cloudstack.apache.org; Abhinav Roy Subject: RE: [Doc] Dedicated Resources: Public IPs and VLANs per Account is Ready Hi, Thanks for the review, Likitha. I have incorporated them. The latest doc is attached at https://issues.apache.org/jira/browse/CLOUDSTACK-817. Abhinav, let me know if you have further comments. Thanks -Radhika From: Likitha Shetty Sent: Friday, August 02, 2013 11:42 AM To: Radhika Puthiyetath; us...@cloudstack.apache.org; dev@cloudstack.apache.org; Abhinav Roy Subject: RE: [Doc] Dedicated Resources: Public IPs and VLANs per Account is Ready I just have 2 comments, 1. Since this feature allows the admin to assign (and release) the IP addresses and VLANs only to an account, not both domain and account we need to modify the introduction accordingly. 2. And could you also add the following to section 15.8, If an account has consumed all the VLANs and IPs dedicated to it, the account can acquire the 2 resources from the system. Cloudstack provides the ROOT admin with 2 configuration parameter to modify this default behavior - use.system.public.ips and use.system.guest.vlans. The 2 global configs allow the ROOT admin to disallow an account from acquiring public IPs and guest VLANs from the system if the account has dedicated resources and these dedicated resources have all been consumed. Both these configurations are configurable at the account level too. (https://issues.apache.org/jira/browse/CLOUDSTACK-3011) Everything else looks good. Thanks, Likitha From: Radhika Puthiyetath Sent: Thursday, August 01, 2013 3:51 PM To: us...@cloudstack.apache.orgmailto:us...@cloudstack.apache.org; dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org; Abhinav Roy; Likitha Shetty Subject: [Doc] Dedicated Resources: Public IPs and VLANs per Account is Ready Hi, Dedicated Resources: Public IPs and VLANs per Account is Ready documentation is ready for review. The doc is attached at https://issues.apache.org/jira/browse/CLOUDSTACK-817 Please see section 15.8. Reserving Public IP Addresses and VLANs Per Account (132), and provide your feedback. Regards -Radhika
