Re: easy bug to fix for new comer
One other thing: You can skip pep8-ing the integration module since that will be deprecated in the future. There's a lot of classes in there so it'll save you time. On Thu, Jun 20, 2013 at 01:04:55PM -0400, Sebastien Goasguen wrote: Daan, Your patches applied cleanly and have been committed to master. Please mark the review as submitted In your next patches try to use the bug id in at the start of the comment, that way the commit will automatically show up in JIRA and review board?magic. do something like that: git commit -m CLOUDSTACK-3096: blah blah blah?. You can also send everything as a single commit?just edit the files, stage them, git add?.and do a single commit. thanks a lot?I told you this was an easy one :) -sebastien On Jun 20, 2013, at 11:44 AM, Sebastien Goasguen run...@gmail.com wrote: -- Prasanna., Powered by BigRock.com
Re: easy bug to fix for new comer
On Thu, Jun 20, 2013 at 02:01:54PM +, Daan Hoogland wrote: Btw Sebastien, Newcomer as I am; how do I test the test-code tests? The first step would be to see if you are able to build marvin $ mvn -Pdeveloper -pl :cloud-marvin clean install You can run tests suitable for basic zone within devcloud if you have it setup. See the section on devcloud tests in the marvin wiki. [0] Then you can try and run the checkin tests [1] (which are broken at the moment as a result of a merge) but I hope to fix that today. Automated tests will be run on the test infra @ jenkins.buildacloud.org [2] so any issues in the formatting will show up there as well. [0] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Marvin+-+Testing+with+Python [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Marvin+-+Testing+with+Python#Marvin-TestingwithPython- [2] http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/ Thanks for the patches! -Original Message- From: Daan Hoogland [mailto:dhoogl...@schubergphilis.com] Sent: donderdag 20 juni 2013 15:43 To: 'dev@cloudstack.apache.org' Subject: RE: easy bug to fix for new comer Sure, One file at a time! -Original Message- From: Sebastien Goasguen [mailto:run...@gmail.com] Sent: donderdag 20 juni 2013 14:35 To: dev@cloudstack.apache.org Subject: easy bug to fix for new comer Hi, Here is an easy bug to fix for a newcomer to cloudstack: https://issues.apache.org/jira/browse/CLOUDSTACK-3096 install pep8 on your machine git clone cloudstack repo go to the marvin directory run pep8 like I show in the bug. edit the python scripts to fix the errors once pep8 is clean, git commit everything, create a patch and send to review board. Any takers ? -Sebastien -- Prasanna., Powered by BigRock.com
Re: Review Request: Test Snapshot Services
On June 18, 2013, 6:40 a.m., Prasanna Santhanam wrote: This test actually passes on jenkins. What are we changing here? sanjeev n wrote: In an environment created with apche master, I see ssvm type as SecondaryStorageVM in host table. So I modified the script accordingly. I guess this is now relevant since the object_store merge removed secondarystorage from the host table. Would you be reworking on this? - Prasanna --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11904/#review22054 --- On June 17, 2013, 6:37 a.m., sanjeev n wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11904/ --- (Updated June 17, 2013, 6:37 a.m.) Review request for cloudstack, Prasanna Santhanam and SrikanteswaraRao Talluri. Description --- Secondary Storage vm type has been modified from SecondaryStorage to SecondaryStorageVM in host table in Cloud db. Modified the same in the test. Diffs - test/integration/component/test_snapshots.py 014b55a Diff: https://reviews.apache.org/r/11904/diff/ Testing --- Yes Thanks, sanjeev n
Re: Review Request: jsonHelper.py cleanup
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12017/#review22240 --- Ship it! c03ba0c8e6904b86d46d86055f05a0c047af190d - Prasanna Santhanam On June 20, 2013, 9:49 p.m., daan Hoogland wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12017/ --- (Updated June 20, 2013, 9:49 p.m.) Review request for cloudstack and Sebastien Goasguen. Description --- .jsonHelper cleanup I took some artistic freedom regarding long strings in json structs. It would have defeated the purpose of formatting (readability) if I hadn't I feel. As a result the file has still one message on a pep8 run. This addresses bug CLOUDSTACK-3096. Diffs - tools/marvin/marvin/jsonHelper.py 79a6369 Diff: https://reviews.apache.org/r/12017/diff/ Testing --- Thanks, daan Hoogland
Re: Review Request: Test Volumes Services
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12021/#review22239 --- Ship it! 64e3074c7ea74afa3f48c21949335bb9208aca40 - Prasanna Santhanam On June 21, 2013, 5:39 a.m., sanjeev n wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12021/ --- (Updated June 21, 2013, 5:39 a.m.) Review request for cloudstack, Prasanna Santhanam and SrikanteswaraRao Talluri. Description --- 1.Current Implementation assumes 6 as the max volumes that can be attached to disk. Actually it depends on the hypervisor capabilities. 2.Modified the script to get the max limit from hypervsior capabilities. Diffs - test/integration/component/test_volumes.py 369cefc Diff: https://reviews.apache.org/r/12021/diff/ Testing --- Thanks, sanjeev n
Re: Review Request: Fix for CLOUDSTACK-3021: fixed for TesttemplateHierachy.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11994/#review22242 --- Ship it! 4c51c60 - Prasanna Santhanam On June 20, 2013, 1:53 p.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11994/ --- (Updated June 20, 2013, 1:53 p.m.) Review request for cloudstack and Prasanna Santhanam. Description --- Fixed Issue 3021 for TesttemplateHierarchy too. Link: https://issues.apache.org/jira/browse/CLOUDSTACK-3021 Also fixed one indentation issue. The indentation of cleanup list (self._cleanup) in TestServiceOfferingHierarchy was wrong. Diffs - test/integration/component/test_accounts.py 39ff3ea Diff: https://reviews.apache.org/r/11994/diff/ Testing --- Thanks, Gaurav Aradhye
Re: Review Request: Fix for CLOUDSTACK-3021: fixed for TesttemplateHierachy.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11994/#review22241 --- Commit 4c51c60ef7517a7719764da94d81cd082caafdf9 in branch refs/heads/master from Gaurav Aradhye [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4c51c60 ] CLOUDSTACK-3021: Order removal of resources Sub domain removed before parent domain. Also fixed indentation issue in cleanup list of class TestServiceOfferingHierarchy Signed-off-by: Prasanna Santhanam t...@apache.org - ASF Subversion and Git Services On June 20, 2013, 1:53 p.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11994/ --- (Updated June 20, 2013, 1:53 p.m.) Review request for cloudstack and Prasanna Santhanam. Description --- Fixed Issue 3021 for TesttemplateHierarchy too. Link: https://issues.apache.org/jira/browse/CLOUDSTACK-3021 Also fixed one indentation issue. The indentation of cleanup list (self._cleanup) in TestServiceOfferingHierarchy was wrong. Diffs - test/integration/component/test_accounts.py 39ff3ea Diff: https://reviews.apache.org/r/11994/diff/ Testing --- Thanks, Gaurav Aradhye
Re: [GSoC] Update
On Jun 20, 2013, at 10:58 PM, Shiva Teja shivate...@gmail.com wrote: I am studying the current ui and still working on the prototype with angular.js. Hoping to finish it by sunday. Ok thanks, don't forget to add sub-tasks in your JIRA ticket. I recommend starting simple with only the USER api and creating a user view… Once we iron out a clear plan, we can think about domain and root apis.. On Fri, Jun 21, 2013 at 2:17 AM, Sebastien Goasguen run...@gmail.comwrote: Dharmesh, Shiva, how are you guys doing ? -sebastien
Re: fixPath (was: committer wanted for review)
On Fri, Jun 21, 2013 at 6:18 AM, Prasanna Santhanam t...@apache.org wrote: rantTo my mind, we overuse String throughout the codebase when we should either be using richer types provided by the Java runtime (e.g. java.net.URI) or defining custom value objects. In addition to better levering the type checking of the compiler and potentially exploiting polymorphism, rich value objects allow business rules to be neatly encapsulated -- DRYing out the code base and allowing them to reliably unit tested./rant +1 to the rant. String is over-(ab)-used. Sometimes even to do XML. Happy to help moving all that if there's a plan you guys work out Sunday. Please bring it back to the lists. John and Prasanna, You are being an architect, excuse my Dutch. Of course you are right, for CloudStack 5.0. In the meantime I have real users with real customers that don't care if I use File or my own custom Directory object or String(Buffer). So +1 for your sunday proposal but 'duhuh' for your rant. I still need to backport my patch to 4.1 and 4.2 of CLoudStack, with or without the apache.org bit. Had to get that of my chest. regards, Daan
Re: easy bug to fix for new comer
how about sandbox? It doesn't sound like really long term strategic code either. On Fri, Jun 21, 2013 at 8:02 AM, Prasanna Santhanam t...@apache.org wrote: One other thing: You can skip pep8-ing the integration module since that will be deprecated in the future. There's a lot of classes in there so it'll save you time. On Thu, Jun 20, 2013 at 01:04:55PM -0400, Sebastien Goasguen wrote: Daan, Your patches applied cleanly and have been committed to master. Please mark the review as submitted In your next patches try to use the bug id in at the start of the comment, that way the commit will automatically show up in JIRA and review board?magic. do something like that: git commit -m CLOUDSTACK-3096: blah blah blah?. You can also send everything as a single commit?just edit the files, stage them, git add?.and do a single commit. thanks a lot?I told you this was an easy one :) -sebastien On Jun 20, 2013, at 11:44 AM, Sebastien Goasguen run...@gmail.com wrote: -- Prasanna., Powered by BigRock.com
Re: fixPath (was: committer wanted for review)
On Fri, Jun 21, 2013 at 09:38:56AM +0200, Daan Hoogland wrote: On Fri, Jun 21, 2013 at 6:18 AM, Prasanna Santhanam t...@apache.org wrote: rantTo my mind, we overuse String throughout the codebase when we should either be using richer types provided by the Java runtime (e.g. java.net.URI) or defining custom value objects. In addition to better levering the type checking of the compiler and potentially exploiting polymorphism, rich value objects allow business rules to be neatly encapsulated -- DRYing out the code base and allowing them to reliably unit tested./rant +1 to the rant. String is over-(ab)-used. Sometimes even to do XML. Happy to help moving all that if there's a plan you guys work out Sunday. Please bring it back to the lists. John and Prasanna, You are being an architect, excuse my Dutch. Of course you are right, for CloudStack 5.0. In the meantime I have real users with real customers that don't care if I use File or my own custom Directory object or String(Buffer). So +1 for your sunday proposal but 'duhuh' for your rant. I still need to backport my patch to 4.1 and 4.2 of CLoudStack, with or without the apache.org bit. Had to get that of my chest. Of course users and operators don't care. I think architecture astronauts know that ;) But to make cloudstack easier to hack for the larger community of java developers it is essential to start thinking about fixing the codebase too. That's not to say this is the utmost important activity right now, but is certainly something the code should evolve into. -- Prasanna., Powered by BigRock.com
Re: easy bug to fix for new comer
Yup - please skip that too. On Fri, Jun 21, 2013 at 09:56:47AM +0200, Daan Hoogland wrote: how about sandbox? It doesn't sound like really long term strategic code either. On Fri, Jun 21, 2013 at 8:02 AM, Prasanna Santhanam t...@apache.org wrote: One other thing: You can skip pep8-ing the integration module since that will be deprecated in the future. There's a lot of classes in there so it'll save you time. On Thu, Jun 20, 2013 at 01:04:55PM -0400, Sebastien Goasguen wrote: Daan, Your patches applied cleanly and have been committed to master. Please mark the review as submitted In your next patches try to use the bug id in at the start of the comment, that way the commit will automatically show up in JIRA and review board?magic. do something like that: git commit -m CLOUDSTACK-3096: blah blah blah?. You can also send everything as a single commit?just edit the files, stage them, git add?.and do a single commit. thanks a lot?I told you this was an easy one :) -sebastien On Jun 20, 2013, at 11:44 AM, Sebastien Goasguen run...@gmail.com wrote: -- Prasanna., Powered by BigRock.com -- Prasanna., Powered by BigRock.com
Re: easy bug to fix for new comer
I submitted a biggy. please review this and consider whether pep8 is beating the purpose of formatting. Espacially line length of 80 seems not what you want. You'll want your terminals show more character then that in this century. On Fri, Jun 21, 2013 at 10:07 AM, Prasanna Santhanam t...@apache.org wrote: Yup - please skip that too. On Fri, Jun 21, 2013 at 09:56:47AM +0200, Daan Hoogland wrote: how about sandbox? It doesn't sound like really long term strategic code either. On Fri, Jun 21, 2013 at 8:02 AM, Prasanna Santhanam t...@apache.org wrote: One other thing: You can skip pep8-ing the integration module since that will be deprecated in the future. There's a lot of classes in there so it'll save you time. On Thu, Jun 20, 2013 at 01:04:55PM -0400, Sebastien Goasguen wrote: Daan, Your patches applied cleanly and have been committed to master. Please mark the review as submitted In your next patches try to use the bug id in at the start of the comment, that way the commit will automatically show up in JIRA and review board?magic. do something like that: git commit -m CLOUDSTACK-3096: blah blah blah?. You can also send everything as a single commit?just edit the files, stage them, git add?.and do a single commit. thanks a lot?I told you this was an easy one :) -sebastien On Jun 20, 2013, at 11:44 AM, Sebastien Goasguen run...@gmail.com wrote: -- Prasanna., Powered by BigRock.com -- Prasanna., Powered by BigRock.com
Review Request: deployDataCentrer formatted
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12022/ --- Review request for cloudstack and Sebastien Goasguen. Description --- deployDataCentrer formatted This addresses bug CLOUDSTACK-3096. Diffs - tools/marvin/marvin/deployDataCenter.py d6f19b0 Diff: https://reviews.apache.org/r/12022/diff/ Testing --- Thanks, daan Hoogland
[GSoC] Encrypted passwords on LDAP.
Hi Guys, I'm using JNDI to connect to LDAP for user authentication. At the moment I'm just testing against an OpenLDAP server. I have my Context.SECURITY_AUTHENTICATION set to simple, however when some password encryption are used within LDAP it fails. Any idea how to solve this? clear - works blowfish - fails crypt - works ext_des - works md5 - works k5key - fails md5crypt - works sha - works smd5 - fails ssha - works sha512 - fails
Review Request: format deployAndRun.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12023/ --- Review request for cloudstack and Sebastien Goasguen. Description --- format deployAndRun.py Diffs - tools/marvin/marvin/deployAndRun.py c83065a Diff: https://reviews.apache.org/r/12023/diff/ Testing --- Thanks, daan Hoogland
Review Request: format dbConnection.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12024/ --- Review request for cloudstack and Sebastien Goasguen. Description --- format dbConnection.py This addresses bug CLOUDSTACK-3096. Diffs - tools/marvin/marvin/dbConnection.py 958299a Diff: https://reviews.apache.org/r/12024/diff/ Testing --- Thanks, daan Hoogland
Unable to add kvm host on latest master
Hi All,
Am not able to add the kvm host in mgmt. server.
I suspect something related to deserialization of json .
Below is the exception log am getting. :
462-3878-9dfe-376b05a1bdfe-LibvirtComputingResource,name:kvm56,id:5,version:4.2.0-SNAPSHOT,resourceName:LibvirtComputingResource,contextMap:{},wait:0}}]
given the type class [Lcom.cloud.agent.api.Command;
at
com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDeserializerExceptionWrapper.java:64)
at
com.google.gson.JsonDeserializationVisitor.invokeCustomDeserializer(JsonDeserializationVisitor.java:92)
at
com.google.gson.JsonDeserializationVisitor.visitUsingCustomHandler(JsonDeserializationVisitor.java:80)
at com.google.gson.ObjectNavigator.accept(ObjectNavigator.java:101)
at
com.google.gson.JsonDeserializationContextDefault.fromJsonArray(JsonDeserializationContextDefault.java:67)
at
com.google.gson.JsonDeserializationContextDefault.deserialize(JsonDeserializationContextDefault.java:52)
at com.google.gson.Gson.fromJson(Gson.java:551)
at com.google.gson.Gson.fromJson(Gson.java:498)
at com.cloud.agent.transport.Request.getCommands(Request.java:235)
at
com.cloud.agent.manager.AgentManagerImpl$AgentHandler.processRequest(AgentManagerImpl.java:1193)
at
com.cloud.agent.manager.AgentManagerImpl$AgentHandler.doTask(AgentManagerImpl.java:1346)
at
com.cloud.agent.manager.ClusteredAgentManagerImpl$ClusteredAgentHandler.doTask(ClusteredAgentManagerImpl.java:659)
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:722)
Caused by: com.cloud.utils.exception.CloudRuntimeException: can't find
StartupRoutingCommand
at
com.cloud.agent.transport.ArrayTypeAdaptor.deserialize(ArrayTypeAdaptor.java:77)
at
com.cloud.agent.transport.ArrayTypeAdaptor.deserialize(ArrayTypeAdaptor.java:37)
at
com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDeserializerExceptionWrapper.java:51)
... 15 more
2013-06-21 17:43:33,697 WARN [utils.nio.Task] (AgentManager-Handler-12:null)
Caught the following exception but pushing on
com.google.gson.JsonParseException: The JsonDeserializer
com.cloud.agent.transport.ArrayTypeAdaptor@b71e3d failed to deserialize json
object
[{StartupRoutingCommand:{cpus:4,speed:1799,memory:16640241664,dom0MinMemory:805306368,poolSync:false,vms:{},caps:hvm,snapshot,pool:/root,hypervisorType:KVM,hostDetails:{com.cloud.network.Networks.RouterPrivateIpStrategy:HostLocal,Host.OS:Red,Host.OS.Kernel.Version:2.6.32-279.el6.x86_64,Host.OS.Version:Enterprise},type:Routing,dataCenter:1,pod:1,cluster:2,guid:eb98ae45-6462-3878-9dfe-376b05a1bdfe-LibvirtComputingResource,name:kvm56,id:5,version:4.2.0-SNAPSHOT,publicIpAddress:10.102.192.56,publicNetmask:255.255.252.0,publicMacAddress:d4:ae:52:ad:fc:a5,privateIpAddress:10.102.192.56,privateMacAddress:d4:ae:52:ad:fc:a5,privateNetmask:255.255.252.0,storageIpAddress:10.102.192.56,storageNetmask:255.255.252.0,storageMacAddress:d4:ae:52:ad:fc:a5,resourceName:LibvirtComputingResource,gatewayIpAddress:10.102.192.1,contextMap:{},wait:0}},{StartupStorageCommand:{totalSize:0,poolInfo:{uuid:41edfd96-c5a5-429a-b192-06a41c2709cc,host:10.102.192.56,localPath:/var/lib/libvirt/images,hostPath:/var/lib/libvirt/images,poolType:Filesystem,capacityBytes:52844687360,availableBytes:50144874496},resourceType:STORAGE_POOL,hostDetails:{},type:Storage,dataCenter:1,pod:1,guid:eb98ae45-6462-3878-9dfe-376b05a1bdfe-LibvirtComputingResource,name:kvm56,id:5,version:4.2.0-SNAPSHOT,resourceName:LibvirtComputingResource,contextMap:{},wait:0}}]
given the type class [Lcom.cloud.agent.api.Command;
at
com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDeserializerExceptionWrapper.java:64)
at
com.google.gson.JsonDeserializationVisitor.invokeCustomDeserializer(JsonDeserializationVisitor.java:92)
at
com.google.gson.JsonDeserializationVisitor.visitUsingCustomHandler(JsonDeserializationVisitor.java:80)
at com.google.gson.ObjectNavigator.accept(ObjectNavigator.java:101)
at
com.google.gson.JsonDeserializationContextDefault.fromJsonArray(JsonDeserializationContextDefault.java:67)
at
com.google.gson.JsonDeserializationContextDefault.deserialize(JsonDeserializationContextDefault.java:52)
at com.google.gson.Gson.fromJson(Gson.java:551)
at com.google.gson.Gson.fromJson(Gson.java:498)
at com.cloud.agent.transport.Request.getCommands(Request.java:235)
at
com.cloud.agent.manager.AgentManagerImpl$AgentHandler.processRequest(AgentManagerImpl.java:1193)
at
com.cloud.agent.manager.AgentManagerImpl$AgentHandler.doTask(AgentManagerImpl.java:1346)
at
Re: Review Request: deployDataCentrer formatted
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12022/#review22243 --- Ship it! applied to master a65d2153f1a31b12cbb123109f4b4b128c26731a thks please submit review - Sebastien Goasguen On June 21, 2013, 9:34 a.m., daan Hoogland wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12022/ --- (Updated June 21, 2013, 9:34 a.m.) Review request for cloudstack and Sebastien Goasguen. Description --- deployDataCentrer formatted This addresses bug CLOUDSTACK-3096. Diffs - tools/marvin/marvin/deployDataCenter.py d6f19b0 Diff: https://reviews.apache.org/r/12022/diff/ Testing --- Thanks, daan Hoogland
Review Request: CLOUDSTACK-2304 [ZWPS]NPE while migrating volume from one zone wide primary to another
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12025/ --- Review request for cloudstack, Sateesh Chodapuneedi, edison su, Alex Huang, and Ram Ganesh. Description --- Issue : while migrating the volume from one ZWPS to another ZWPS then NPE is having which is failing the migration of volume Fixed: The issue is, if the volume is in ZWPS then the volume object won't be having podid. while volume migration, ZWPS specific volume cases are not handled. Fixed the issues by adding a new constructor in VolumeVO and taken care in VolumeServiceImpl to handle ZWPS volume while migration. This addresses bug CLOUDSTACK-2304. Diffs - engine/schema/src/com/cloud/storage/VolumeVO.java 02c09a2 engine/storage/volume/src/org/apache/cloudstack/storage/volume/VolumeServiceImpl.java 1d36f93 Diff: https://reviews.apache.org/r/12025/diff/ Testing --- Setup: Create a KVM cluster and add zwps to the primary storage. ZWPS got mounted on KVM. Created instances in KVM. 1. Create a Volume and attach the volume to the running VM. volume got successfully attached to the VM. 2. Detach the Volume and then try to Migrate the Volume to another ZWPS added to the ZONE. volume got migrated successfully to another ZWPS. Observed Volume got copied to the new ZWPS and then the old volume is deleted. Verified db, the volume uuid got updated and necessary fields. Addition Testing: Created Xenserver cluster add cluster scope storage. 1. create a volume and attach the instance running in Xenserver. Success. 2. detach the volume and try to migrate the volume to another cluster scope storage. Volume got successfully migrate to another storage. Observed Volume got copied to the new PS and then the old volume is deleted. Verified db, the volume uuid got updated and necessary fields. Thanks, Rajesh Battala
Re: Review Request: format deployAndRun.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12023/#review22244 --- Ship it! applied to master 16e4f2ff7221bfbd4ac171aae4702e62f43574d3 thx please submit review - Sebastien Goasguen On June 21, 2013, 10:03 a.m., daan Hoogland wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12023/ --- (Updated June 21, 2013, 10:03 a.m.) Review request for cloudstack and Sebastien Goasguen. Description --- format deployAndRun.py Diffs - tools/marvin/marvin/deployAndRun.py c83065a Diff: https://reviews.apache.org/r/12023/diff/ Testing --- Thanks, daan Hoogland
Re: Review Request: format dbConnection.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12024/#review22245 --- Ship it! applied to master 3e5937e01d7dd490309e5e9fb2122fbcdb77266b thx please close review - Sebastien Goasguen On June 21, 2013, 10:04 a.m., daan Hoogland wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12024/ --- (Updated June 21, 2013, 10:04 a.m.) Review request for cloudstack and Sebastien Goasguen. Description --- format dbConnection.py This addresses bug CLOUDSTACK-3096. Diffs - tools/marvin/marvin/dbConnection.py 958299a Diff: https://reviews.apache.org/r/12024/diff/ Testing --- Thanks, daan Hoogland
Review Request: format configGenerator
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12026/ --- Review request for cloudstack and Sebastien Goasguen. Description --- format configGenerator This addresses bug CLOUDSTACK-3096. Diffs - tools/marvin/marvin/configGenerator.py b53c46e Diff: https://reviews.apache.org/r/12026/diff/ Testing --- Thanks, daan Hoogland
Resource Management/Allocation for CS
Hi All, Does anybody can tell me which parts of CloudStack's source code are related to its Resource Allocation (RA) process? By RA, I mean the part of code that is responsible for VM migration or process migration, if there is any. As you know, there are two kinds of RA, to wit: 1) server side such as VM migration, or 2) client side such as clients' proprietary schedulers. Furthermore, client side's RA's success is dependent on knowing sever side's RA very well. So, since i am interested to work on RA of CloudStack, if, with regard to the above information, you have any idea, please tell me? Also, if your are working on it, please let me know. Finally, it would be really approciated if you tell me which parts of the source code is related to implementation of CloudStack's RA algorithms. Best regards, Pouya
Re: Review Request: format configGenerator
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12026/#review22246 --- Ship it! applied to master f0ab05dc041ddf48ba1584e7dcec16622b2004e0 See how I reformatted your commit message to get the automatic logging, no square brackets around the bug ID submit review thx - Sebastien Goasguen On June 21, 2013, 12:44 p.m., daan Hoogland wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12026/ --- (Updated June 21, 2013, 12:44 p.m.) Review request for cloudstack and Sebastien Goasguen. Description --- format configGenerator This addresses bug CLOUDSTACK-3096. Diffs - tools/marvin/marvin/configGenerator.py b53c46e Diff: https://reviews.apache.org/r/12026/diff/ Testing --- Thanks, daan Hoogland
Re: Resource Management/Allocation for CS
Pouya, What problem/issue/enhancements do you have in mind? If you are attending CloudStack Collab 2013, I will speaking on this topic on Monday @ 2:30 (How to Run from a Zombie: CloudStack Distributed Process Management). My slides will be available online after the talk as well. Thanks, -John On Jun 21, 2013, at 8:47 AM, Linux TUX azgil.i...@yahoo.com wrote: Hi All, Does anybody can tell me which parts of CloudStack's source code are related to its Resource Allocation (RA) process? By RA, I mean the part of code that is responsible for VM migration or process migration, if there is any. As you know, there are two kinds of RA, to wit: 1) server side such as VM migration, or 2) client side such as clients' proprietary schedulers. Furthermore, client side's RA's success is dependent on knowing sever side's RA very well. So, since i am interested to work on RA of CloudStack, if, with regard to the above information, you have any idea, please tell me? Also, if your are working on it, please let me know. Finally, it would be really approciated if you tell me which parts of the source code is related to implementation of CloudStack's RA algorithms. Best regards, Pouya
Re: VMWare changing the default vSwitch Name
Thanks for you assistance Sateesh certainly got my understanding further. I had an offline chat with Paul Angus about this and he advised to create a brand new zone which picked up the correct switch. On this switch I learned that I cannot use the portgroup we created, but just let cloudstack use the ones it creates. I hope this response may help others in the future. Kind regards Noel On 20 June 2013 19:16, Noel King noelk...@gmail.com wrote: Hi Sateesh, Did not realise unitl I started looking at the code that you contributed greatly to it, great to get reply from you.I have done some investigation around the VmwareManagerImpl.java which uses this configuration and see that change was made for 4.2 branch, sadly. Do you have any feedback on version 4.1 Thanks Noel On 20 June 2013 18:27, Noel King noelk...@gmail.com wrote: Hi Sateesh, Sorry replied too quick from phone when I away from my desk, Are those global config changes in 4.1 as well as I dont see them but will have a quick search in docs for them. private.network.vswitch.name public.network.vswitch.name guest.network.vswitch.name Thanks Noel On 20 June 2013 18:19, Noel King noelk...@gmail.com wrote: Apologies if I did not state that, but had restarted the management server and error message sent was after the restart. So looks like its not picking up the change. thanks Noel On Jun 20, 2013 6:16 p.m., Sateesh Chodapuneedi sateesh.chodapune...@citrix.com wrote: -Original Message- From: Noel King [mailto:noelk...@gmail.com] Sent: 20 June 2013 22:37 To: dev@cloudstack.apache.org Subject: Re: VMWare changing the default vSwitch Name Hi Sateesh Thanks for your reply, I have made those changes and restarted but with no joy and am still seeing vSwitch0 being used in the log and my portgroup is returning Message: Uable to find management port group MyPortGroup INFO [vmware.resource.VmwareResource] (ClusteredAgentManager Timer:) VmwareResource network configuration info. private vSwitch: vSwitch0, public vSwitch: vSwitch0, guest network: vSwitch0 Any further insight would be greatly appreciated. Can you set following global configuration parameters based on the traffic type? private.network.vswitch.name public.network.vswitch.name guest.network.vswitch.name Need to restart management server once these parameters are modified. Hope that helps! Regards, Sateesh Kind regards Noel On 20 June 2013 17:42, Sateesh Chodapuneedi sateesh.chodapune...@citrix.com wrote: -Original Message- From: Noel King [mailto:noelk...@gmail.com] Sent: 20 June 2013 20:16 To: dev@cloudstack.apache.org Subject: VMWare changing the default vSwitch Name Hi All, I am currently working on a Cloudstack VMWare integration project and we have setup up a dedicated vSwitch and PortGroup for cloudstack. On reading the VMware vSphere Installation and Configuration ( http://cloudstack.apache.org/docs/en- US/Apache_CloudStack/4.0.2/html/Installation_Guide/ vmware-install.ht ml ) I see the following advise: 8.3.5.1. Configure Virtual Switch A default virtual switch vSwitch0 is created. CloudStack requires all ESXi hosts in the cloud to use the same set of virtual switch names. If you change the default virtual switch name, you will need to configure one or more CloudStack configuration variables as well. Would you mind explaining *you will need to configure one or more CloudStack configuration variables as well*. What settings these are and where they can be changed. Edit the physical network traffic label to specify the vswitch name to be used for particular traffic. Ex: If you would like to use vSwitch2 for guest traffic then edit the guest network traffic label as vSwitch2. Kind regards Noel Kind regards, Noel
Re: VMWare changing the default vSwitch Name
On Jun 21, 2013, at 9:11 AM, Noel King noelk...@gmail.com wrote: Thanks for you assistance Sateesh certainly got my understanding further. I had an offline chat with Paul Angus about this and he advised to create a brand new zone which picked up the correct switch. On this switch I learned that I cannot use the portgroup we created, but just let cloudstack use the ones it creates. I hope this response may help others in the future. Kind regards Noel So you have things working now ? Could be a nice quick blog post On 20 June 2013 19:16, Noel King noelk...@gmail.com wrote: Hi Sateesh, Did not realise unitl I started looking at the code that you contributed greatly to it, great to get reply from you.I have done some investigation around the VmwareManagerImpl.java which uses this configuration and see that change was made for 4.2 branch, sadly. Do you have any feedback on version 4.1 Thanks Noel On 20 June 2013 18:27, Noel King noelk...@gmail.com wrote: Hi Sateesh, Sorry replied too quick from phone when I away from my desk, Are those global config changes in 4.1 as well as I dont see them but will have a quick search in docs for them. private.network.vswitch.name public.network.vswitch.name guest.network.vswitch.name Thanks Noel On 20 June 2013 18:19, Noel King noelk...@gmail.com wrote: Apologies if I did not state that, but had restarted the management server and error message sent was after the restart. So looks like its not picking up the change. thanks Noel On Jun 20, 2013 6:16 p.m., Sateesh Chodapuneedi sateesh.chodapune...@citrix.com wrote: -Original Message- From: Noel King [mailto:noelk...@gmail.com] Sent: 20 June 2013 22:37 To: dev@cloudstack.apache.org Subject: Re: VMWare changing the default vSwitch Name Hi Sateesh Thanks for your reply, I have made those changes and restarted but with no joy and am still seeing vSwitch0 being used in the log and my portgroup is returning Message: Uable to find management port group MyPortGroup INFO [vmware.resource.VmwareResource] (ClusteredAgentManager Timer:) VmwareResource network configuration info. private vSwitch: vSwitch0, public vSwitch: vSwitch0, guest network: vSwitch0 Any further insight would be greatly appreciated. Can you set following global configuration parameters based on the traffic type? private.network.vswitch.name public.network.vswitch.name guest.network.vswitch.name Need to restart management server once these parameters are modified. Hope that helps! Regards, Sateesh Kind regards Noel On 20 June 2013 17:42, Sateesh Chodapuneedi sateesh.chodapune...@citrix.com wrote: -Original Message- From: Noel King [mailto:noelk...@gmail.com] Sent: 20 June 2013 20:16 To: dev@cloudstack.apache.org Subject: VMWare changing the default vSwitch Name Hi All, I am currently working on a Cloudstack VMWare integration project and we have setup up a dedicated vSwitch and PortGroup for cloudstack. On reading the VMware vSphere Installation and Configuration ( http://cloudstack.apache.org/docs/en- US/Apache_CloudStack/4.0.2/html/Installation_Guide/ vmware-install.ht ml ) I see the following advise: 8.3.5.1. Configure Virtual Switch A default virtual switch vSwitch0 is created. CloudStack requires all ESXi hosts in the cloud to use the same set of virtual switch names. If you change the default virtual switch name, you will need to configure one or more CloudStack configuration variables as well. Would you mind explaining *you will need to configure one or more CloudStack configuration variables as well*. What settings these are and where they can be changed. Edit the physical network traffic label to specify the vswitch name to be used for particular traffic. Ex: If you would like to use vSwitch2 for guest traffic then edit the guest network traffic label as vSwitch2. Kind regards Noel Kind regards, Noel
Review Request: format codegenerator.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12027/ --- Review request for cloudstack and Sebastien Goasguen. Description --- format codegenerator.py This addresses bug CLOUDSTACK-3096. Diffs - tools/marvin/marvin/codegenerator.py 36ba180 Diff: https://reviews.apache.org/r/12027/diff/ Testing --- Thanks, daan Hoogland
Re: easy bug to fix for new comer
five files to go. I may finish it on the plane or else next week. On Fri, Jun 21, 2013 at 11:12 AM, Daan Hoogland daan.hoogl...@gmail.comwrote: I submitted a biggy. please review this and consider whether pep8 is beating the purpose of formatting. Espacially line length of 80 seems not what you want. You'll want your terminals show more character then that in this century. On Fri, Jun 21, 2013 at 10:07 AM, Prasanna Santhanam t...@apache.orgwrote: Yup - please skip that too. On Fri, Jun 21, 2013 at 09:56:47AM +0200, Daan Hoogland wrote: how about sandbox? It doesn't sound like really long term strategic code either. On Fri, Jun 21, 2013 at 8:02 AM, Prasanna Santhanam t...@apache.org wrote: One other thing: You can skip pep8-ing the integration module since that will be deprecated in the future. There's a lot of classes in there so it'll save you time. On Thu, Jun 20, 2013 at 01:04:55PM -0400, Sebastien Goasguen wrote: Daan, Your patches applied cleanly and have been committed to master. Please mark the review as submitted In your next patches try to use the bug id in at the start of the comment, that way the commit will automatically show up in JIRA and review board?magic. do something like that: git commit -m CLOUDSTACK-3096: blah blah blah?. You can also send everything as a single commit?just edit the files, stage them, git add?.and do a single commit. thanks a lot?I told you this was an easy one :) -sebastien On Jun 20, 2013, at 11:44 AM, Sebastien Goasguen run...@gmail.com wrote: -- Prasanna., Powered by BigRock.com -- Prasanna., Powered by BigRock.com
Re: fixPath (was: committer wanted for review)
On Fri, Jun 21, 2013 at 09:38:56AM +0200, Daan Hoogland wrote: On Fri, Jun 21, 2013 at 6:18 AM, Prasanna Santhanam t...@apache.org wrote: rantTo my mind, we overuse String throughout the codebase when we should either be using richer types provided by the Java runtime (e.g. java.net.URI) or defining custom value objects. In addition to better levering the type checking of the compiler and potentially exploiting polymorphism, rich value objects allow business rules to be neatly encapsulated -- DRYing out the code base and allowing them to reliably unit tested./rant +1 to the rant. String is over-(ab)-used. Sometimes even to do XML. Happy to help moving all that if there's a plan you guys work out Sunday. Please bring it back to the lists. John and Prasanna, You are being an architect, excuse my Dutch. Of course you are right, for CloudStack 5.0. In the meantime I have real users with real customers that don't care if I use File or my own custom Directory object or String(Buffer). So +1 for your sunday proposal but 'duhuh' for your rant. I still need to backport my patch to 4.1 and 4.2 of CLoudStack, with or without the apache.org bit. Had to get that of my chest. regards, Daan Let's all remember to keep discussions focused on the code itself please, and not be personal about things.
Re: easy bug to fix for new comer
On Fri, Jun 21, 2013 at 03:28:48PM +0200, Daan Hoogland wrote: five files to go. I may finish it on the plane or else next week. Very productive week for you! Thanks Daan.
Re: VMWare changing the default vSwitch Name
Hi Sebastien No problem at all, I am blogging about it internally, so will share it. Cheers, Noel On 21 June 2013 14:18, Sebastien Goasguen run...@gmail.com wrote: On Jun 21, 2013, at 9:11 AM, Noel King noelk...@gmail.com wrote: Thanks for you assistance Sateesh certainly got my understanding further. I had an offline chat with Paul Angus about this and he advised to create a brand new zone which picked up the correct switch. On this switch I learned that I cannot use the portgroup we created, but just let cloudstack use the ones it creates. I hope this response may help others in the future. Kind regards Noel So you have things working now ? Could be a nice quick blog post On 20 June 2013 19:16, Noel King noelk...@gmail.com wrote: Hi Sateesh, Did not realise unitl I started looking at the code that you contributed greatly to it, great to get reply from you.I have done some investigation around the VmwareManagerImpl.java which uses this configuration and see that change was made for 4.2 branch, sadly. Do you have any feedback on version 4.1 Thanks Noel On 20 June 2013 18:27, Noel King noelk...@gmail.com wrote: Hi Sateesh, Sorry replied too quick from phone when I away from my desk, Are those global config changes in 4.1 as well as I dont see them but will have a quick search in docs for them. private.network.vswitch.name public.network.vswitch.name guest.network.vswitch.name Thanks Noel On 20 June 2013 18:19, Noel King noelk...@gmail.com wrote: Apologies if I did not state that, but had restarted the management server and error message sent was after the restart. So looks like its not picking up the change. thanks Noel On Jun 20, 2013 6:16 p.m., Sateesh Chodapuneedi sateesh.chodapune...@citrix.com wrote: -Original Message- From: Noel King [mailto:noelk...@gmail.com] Sent: 20 June 2013 22:37 To: dev@cloudstack.apache.org Subject: Re: VMWare changing the default vSwitch Name Hi Sateesh Thanks for your reply, I have made those changes and restarted but with no joy and am still seeing vSwitch0 being used in the log and my portgroup is returning Message: Uable to find management port group MyPortGroup INFO [vmware.resource.VmwareResource] (ClusteredAgentManager Timer:) VmwareResource network configuration info. private vSwitch: vSwitch0, public vSwitch: vSwitch0, guest network: vSwitch0 Any further insight would be greatly appreciated. Can you set following global configuration parameters based on the traffic type? private.network.vswitch.name public.network.vswitch.name guest.network.vswitch.name Need to restart management server once these parameters are modified. Hope that helps! Regards, Sateesh Kind regards Noel On 20 June 2013 17:42, Sateesh Chodapuneedi sateesh.chodapune...@citrix.com wrote: -Original Message- From: Noel King [mailto:noelk...@gmail.com] Sent: 20 June 2013 20:16 To: dev@cloudstack.apache.org Subject: VMWare changing the default vSwitch Name Hi All, I am currently working on a Cloudstack VMWare integration project and we have setup up a dedicated vSwitch and PortGroup for cloudstack. On reading the VMware vSphere Installation and Configuration ( http://cloudstack.apache.org/docs/en- US/Apache_CloudStack/4.0.2/html/Installation_Guide/ vmware-install.ht ml ) I see the following advise: 8.3.5.1. Configure Virtual Switch A default virtual switch vSwitch0 is created. CloudStack requires all ESXi hosts in the cloud to use the same set of virtual switch names. If you change the default virtual switch name, you will need to configure one or more CloudStack configuration variables as well. Would you mind explaining *you will need to configure one or more CloudStack configuration variables as well*. What settings these are and where they can be changed. Edit the physical network traffic label to specify the vswitch name to be used for particular traffic. Ex: If you would like to use vSwitch2 for guest traffic then edit the guest network traffic label as vSwitch2. Kind regards Noel Kind regards, Noel
Re: Review Request: format codegenerator.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12027/#review22247 --- Ship it! applied to master 1c50f1c75665524857f7410f1b3525717dcfcd03 thx mark review as submitted - Sebastien Goasguen On June 21, 2013, 1:24 p.m., daan Hoogland wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12027/ --- (Updated June 21, 2013, 1:24 p.m.) Review request for cloudstack and Sebastien Goasguen. Description --- format codegenerator.py This addresses bug CLOUDSTACK-3096. Diffs - tools/marvin/marvin/codegenerator.py 36ba180 Diff: https://reviews.apache.org/r/12027/diff/ Testing --- Thanks, daan Hoogland
Re: NFS Cache storage query
Edison, As I understand Chip's concern, if we can't safely disassociate a staging area from a zone, we will break zone deletion. My understanding of your 4.2 proposal is that the system administrator/operation can place the staging area in maintenance mod How would this address disassociating from the zone to allow deletion? It feels like the shortest path would be to support detaching a staging area from a zone. It also seems like behavior we would want to support going forward. Also, what would it mean to put a secondary store in maintenance mode? My understanding is that we haven't worked out the functionality of secondary storage maintenance mode. Also, why don't we define a detach methods adjoining each of the attach methods? Thanks, -John On Jun 19, 2013, at 3:11 PM, Edison Su edison...@citrix.com wrote: -Original Message- From: John Burwell [mailto:jburw...@basho.com] Sent: Wednesday, June 19, 2013 11:43 AM To: Edison Su Cc: dev@cloudstack.apache.org Subject: Re: NFS Cache storage query Edison, Based on the stance you have outlined, the usage of NFS in the object_store branch and 4.1 are not comparable. In 4.1, NFS is the store of record for data. Therefore, presence of the file in the NFS volume indicates that the data is permanently stored. However, in object_store, presence in NFS in the object_store branch means that the data may be awaiting permanent stage (dependent on the type of pending transfer operation). As such, I think we will need to provide insurance that in-flight operations are completed before a staging/temporary area is destroyed. Another option I can see is to change the way these staging/temporary areas are associated with zones. If we approached them as standalone entities that are attached or detached from a zone, we could define the detach operation as only disassociation from a zone without impacting in-flight operations. This solution would allow zones to be deleted without impacting in-flight operations. The interface is there: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob;f=engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/DataStoreLifeCycle.java;h=1e893db6bb5b1dbae0142e8a26019ae34d44320a;hb=refs/heads/object_store Admin should be able to put the data store into maintenance mode, and then delete it, but the implementation is not there yet for both NFS secondary storage and staging area. For NFS, S3 secondary storage, we should at least implement maintenance/cancelMaintain in 4.2 For NFS staging area, we should at least implement maintenance/cancelMaintain in 4.2, the delete method in 4.3. How do you think? Thanks, -John On Jun 19, 2013, at 2:15 PM, Edison Su edison...@citrix.com wrote: Yes and No:) Yes, as all the hypervisors(KVM/Vmware/Xenserver) still need NFS in 4.2, even S3 is used as the place to store templates. No, we make NFS is optional, if you don't want to use NFS. E.g the HyperV implementation will not depend on NFS. In 4.3, we can start work on the hypervisor side refactor, to eliminate the dependence on NFS as much as possible, then we may can truly make the statement that, S3 will be the secondary storage. -Original Message- From: John Burwell [mailto:jburw...@basho.com] Sent: Wednesday, June 19, 2013 11:00 AM To: Edison Su Cc: dev@cloudstack.apache.org Subject: Re: NFS Cache storage query Edison, For 4.2, are we going to state that the object store is just a backup of NFS (i.e. the same as 4.1)? Thanks, -John On Jun 19, 2013, at 1:58 PM, Edison Su edison...@citrix.com wrote: -Original Message- From: John Burwell [mailto:jburw...@basho.com] Sent: Wednesday, June 19, 2013 10:42 AM To: dev@cloudstack.apache.org Cc: Edison Su Subject: Re: NFS Cache storage query Chip, Your concern had not occurred to me -- making me realize that either destroy or a zone attach/detach operation for the staging/temporary area mechanism in 4.2. Thinking through it, there are two types of operations occurring with the staging/temporary area. The first is data being pulled from the object store to support some activity (e.g. copying a template down to create a VM). From a data integrity perspective, it is safe to kill these operations since the data has already been persisted to the object store. The second is data being pushed to the object store which are much more problematic. Of particular concern would be snapshots that are in the staging/temporary area, but not yet transferred to the object store. Edison/Min: Does the current implementation provide a destroy or attach/detach behavior? If so, how are in-flight operations handled to ensure there is no data loss? The current mater branch, there is no such operation for secondary storage yet, so does the object_store branch. Maybe we can discuss/implement a better life cycle management of both nfs
Re: Resource Management/Allocation for CS
Dear John, More specifically, I'd been working on RA in distributed systems awhile, and also, I've presented a prototype for it. The most important thing that I've learnt is: talking about RA without regarding to workloads (e.g., HTC, MTC, BoT, Scientific, Data-Intensive, etc.) is not optimal at all. So, I am thinking about providing different RA modules for each workload. It means, when the api gets a client's workload, first, some workload characterizations are needed (e.g., statistical modeling, classification, multi-queue, etc.), then, based on nature of the workload the RA process by using the appropriate RA module can be near optimal, I hope. By optimal, I mean less resource consumption as compared to a general RA for all workloads. Nevertheless, since I am coming from theory (i.e., simulation of RA for distributed systems) to here and I don't have a big image about RA in CloudStack in mind, I'm wondering if someone gives some clues to make me ready for putting my idea into practice. Also, unfortunately, I cannot attend in CloudStack Collab 2013, but I will follow its news and your slides. Best regards, Pouya From: John Burwell jburw...@basho.com To: dev@cloudstack.apache.org; Linux TUX azgil.i...@yahoo.com Sent: Friday, 21 June 2013, 17:26 Subject: Re: Resource Management/Allocation for CS Pouya, What problem/issue/enhancements do you have in mind? If you are attending CloudStack Collab 2013, I will speaking on this topic on Monday @ 2:30 (How to Run from a Zombie: CloudStack Distributed Process Management). My slides will be available online after the talk as well. Thanks, -John On Jun 21, 2013, at 8:47 AM, Linux TUX azgil.i...@yahoo.com wrote: Hi All, Does anybody can tell me which parts of CloudStack's source code are related to its Resource Allocation (RA) process? By RA, I mean the part of code that is responsible for VM migration or process migration, if there is any. As you know, there are two kinds of RA, to wit: 1) server side such as VM migration, or 2) client side such as clients' proprietary schedulers. Furthermore, client side's RA's success is dependent on knowing sever side's RA very well. So, since i am interested to work on RA of CloudStack, if, with regard to the above information, you have any idea, please tell me? Also, if your are working on it, please let me know. Finally, it would be really approciated if you tell me which parts of the source code is related to implementation of CloudStack's RA algorithms. Best regards, Pouya
Review Request: CLOUDSTACK-3064: Able to create VM from different account of the same domain without using Affinity group even the Zone is dedicated to an Account.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12028/ --- Review request for cloudstack and Devdeep Singh. Description --- When a zone is dedicated to an account, other accounts should not be able to deploy vms on that zone. Also if no explicit dedication type affinity group is chosen, vm deployment from the same account should fail. This addresses bug 3064. Diffs - server/src/com/cloud/deploy/DeploymentPlanningManagerImpl.java 4ef2152 Diff: https://reviews.apache.org/r/12028/diff/ Testing --- Tested dedicating zone, then deploying vms from other accounts, it fails now. Also if no affinity group is chosen for the same account, vm deployment fails. Thanks, Saksham Srivastava
Re: Query String Request Authentication(QSRA) support by S3 providers
Min, (I apologize for my belated reply -- I lost track of this draft in the chaos of the last couple of days.) Upon further review, I think I feel into the confusion between management server and ssvm. This code is executing on the management server side, correct? Based on my corrected understanding is correct, I would like to amend my thoughts. Namely, I would like to see the driver operations pushed out to the SSVM where we can use the stream. As I think about it, the management server should not need to interact with the driver. Simply yard up the DataStore attributes + details map and other extract parameters, and send them to the SSVM. Using this information, the S3 driver could open a stream to write the template out to the bucket/directory. I recognize it changes the protocol between the management server and SSVM, but it simply both sides of the operation by allowing the DataStore information to be treated opaquely until it is consumed by the driver to execute the write operation. I also recognize that we may a little late in the cycle to address it for 4.2, and it may need to be part of the 4.3 enhancements. Thanks, -John On Jun 18, 2013, at 3:55 PM, Min Chen min.c...@citrix.com wrote: John, In that case, how do we keep backward compatibility of extractTemplate api, which requires a URL in the response? Thanks -min On 6/18/13 11:53 AM, John Burwell jburw...@basho.com wrote: Min, Looking through the code, I think we can simplify driver operation and increase robustness by changing ImageStoreDriver#createEntityExtractUrl() : String to ImageStoreDriver#readEntity(Š) : InputStream. My first concern with the current implementation is that it circumvents any connection pooling/resource management underlying client libraries provide. I/O streams provide a higher-level abstraction that allows drivers to provide the orchestration components with actual resources rather String references. Second, the current interface seems to appears to assume that an http/https URL will be returned. With I/O streams, we can support any client library capable of using the standard I/O framework -- enabling us to support other protocols for downloading templates in the future (e.g. RBD, local filesystem, NBD, etc). Thanks, -John On Jun 18, 2013, at 1:11 PM, Min Chen min.c...@citrix.com wrote: A new version of using generatePresignedUrl in S3ImageStoreDriverImpl is checked into object_store. THanks -min On 6/18/13 8:29 AM, Min Chen min.c...@citrix.com wrote: Yes, current code is in S3ImageStoreDriverImpl.createEntityExtractUrl, which has a security issue mentioned in CLOUDSTACK-3030. I am going to change it to use generatePresignedUrl api from AWS S3 api. Thanks -min From: John Burwell jburw...@basho.commailto:jburw...@basho.com Date: Tuesday, June 18, 2013 8:07 AM To: Min Chen min.c...@citrix.commailto:min.c...@citrix.com Cc: Thomas O'Dowd tpod...@cloudian.commailto:tpod...@cloudian.com, dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: Query String Request Authentication(QSRA) support by S3 providers Min, Is the code checked into the object_store branch? If so, which lines in S3TemplateDownloader? Thanks, -John On Jun 18, 2013, at 12:39 AM, Min Chen min.c...@citrix.commailto:min.c...@citrix.com wrote: Hi John, This is regarding extractTemplate api, where for extractable template, users can click Download Template button from UI to get a http url to download the template already stored at S3 without providing S3 credentials. In 4.1, we don't have this issue, since the URL returned is the public web server location hosted in ssvm, and in 4.2, we are returning URL pointing to s3 object. Without setting ACL to the S3 object, user cannot directly click the URL returned from extractTemplate api to download the template without providing credentials. By reading the AWS SDK doc today, I ran across the following API that I may be able to use for this purpose: URLhttp://java.sun.com/j2se/1.5.0/docs/api/java/net/URL.html?is-externa l= true generatePresignedUrlhttp://docs.aws.amazon.com/AWSJavaSDK/latest/javado c/ com/amazonaws/services/s3/AmazonS3Client.html#generatePresignedUrl%28jav a. lang.String,%20java.lang.String,%20java.util.Date,%20com.amazonaws.HttpM et hod%29(Stringhttp://java.sun.com/j2se/1.5.0/docs/api/java/lang/String. ht ml?is-external=true bucketName, Stringhttp://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html?is- ex ternal=true key, Datehttp://java.sun.com/j2se/1.5.0/docs/api/java/util/Date.html?is-exte rn al=true expiration, HttpMethodhttp://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amaz on aws/HttpMethod.html method) Returns a pre-signed URL for accessing an Amazon S3 resource. This is along the same line as QSRA
ha-handler
LS, Who is the goto-guy for the ha-handler (and will he be at ccc)? regards,
HA Question
Hi, I have a quick question about VM HA. Does CloudStack depend on the HA features of the hypervisor or does it handle VM HA itself? 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: HA Question
On Fri, Jun 21, 2013 at 10:19:51AM -0600, Mike Tutkowski wrote: Hi, I have a quick question about VM HA. Does CloudStack depend on the HA features of the hypervisor or does it handle VM HA itself? The CloudStack HA feature is outside of the HV. You really have 3 choices - implement HA in the HV, but disable it in CS; the reverse; or do nothing for HA. -chip
Re: HA Question
Great - thanks, Chip! On Fri, Jun 21, 2013 at 10:21 AM, Chip Childers chip.child...@sungard.comwrote: On Fri, Jun 21, 2013 at 10:19:51AM -0600, Mike Tutkowski wrote: Hi, I have a quick question about VM HA. Does CloudStack depend on the HA features of the hypervisor or does it handle VM HA itself? The CloudStack HA feature is outside of the HV. You really have 3 choices - implement HA in the HV, but disable it in CS; the reverse; or do nothing for HA. -chip -- *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 *™*
Early for CCC13
Hi, I'm an hour and a half(LAX) from Santa Clara. Anyone else in town early? Send me your numbers... Sent from my HTC
Re: Review Request: SolidFire storage plug-in and enhancements to the storage framework and GUI
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11479/ --- (Updated June 21, 2013, 4:35 p.m.) Review request for cloudstack, edison su and John Burwell. Changes --- Made a small change and re-uploaded the entire diff of my changes for this feature Description --- This patch implements a storage plug-in for SolidFire. The plug-in is based on the new storage framework that went in with 4.2, as well. In addition, there are GUI (and related) changes to enable admins and end users to specify a Min, Max, and Burst number of IOPS for a Disk Offering. These fields (although optional) tend to follow the pattern previously established for the Disk Size field. Also, the storage framework itself has been enhanced. For example, it now supports creating and deleting storage repositories as is necessary for a dynamic type of zone-wide primary storage (such as the SolidFire plug-in is). The desired behavior of the software is as such: * Allow an admin to invoke the CloudStack API to add Primary Storage based on the SolidFire plug-in. * Allow an admin to create a Disk Offering that specifies a Min, Max, and Burst number of IOPS or allows the admin to pass this ability on to the end user. * Allow an end user to execute such a Disk Offering. As is the case for any Disk Offering, this leads to the creation of a row in the volumes table. * Allow an end user to attach the resultant volume (noted in the DB) to a VM. The storage framework invokes logic in the plug-in and the plug-in creates a volume on its SAN with the correct size and IOPS values. The agent software for XenServer detects that such an attach is being requested and creates a Storage Repository (and single VDI within the SR) based on the storage IP address of the SAN and the IQN of the volume. The VDI is then hooked up to the VM. * Allow an end user to detach the volume. This leads to the destruction of the SR, but the SAN volume remains intact and can be reattached later to any VM running in a XenServer resource pool in the zone. * Allow an end user to delete the volume. This leads to the volume being deleted on the SAN and being marked in the CloudStack DB as deleted. Diffs (updated) - api/src/com/cloud/offering/DiskOffering.java ae4528c api/src/com/cloud/storage/StoragePool.java 8b95383 api/src/com/cloud/storage/Volume.java 4903594 api/src/org/apache/cloudstack/api/ApiConstants.java 1704ca3 api/src/org/apache/cloudstack/api/command/admin/offering/CreateDiskOfferingCmd.java a2c5f77 api/src/org/apache/cloudstack/api/command/admin/storage/CreateStoragePoolCmd.java 74eb2b9 api/src/org/apache/cloudstack/api/command/user/volume/CreateVolumeCmd.java 86a494b api/src/org/apache/cloudstack/api/response/DiskOfferingResponse.java 35cf21a api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java 965407d api/src/org/apache/cloudstack/api/response/VolumeResponse.java e3463bd client/WEB-INF/classes/resources/messages.properties a0a36c8 client/pom.xml ab758eb client/tomcatconf/applicationContext.xml.in 049e483 core/src/com/cloud/agent/api/AttachVolumeAnswer.java b377b7c core/src/com/cloud/agent/api/AttachVolumeCommand.java 2658262 core/test/org/apache/cloudstack/api/agent/test/AttachVolumeAnswerTest.java 251a6cb core/test/org/apache/cloudstack/api/agent/test/AttachVolumeCommandTest.java 1ec416a core/test/org/apache/cloudstack/api/agent/test/BackupSnapshotCommandTest.java 44d53aa core/test/org/apache/cloudstack/api/agent/test/SnapshotCommandTest.java c2d69c0 core/test/src/com/cloud/agent/api/test/ResizeVolumeCommandTest.java 02085f5 engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/DataStoreDriver.java cf5759b engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/PrimaryDataStoreParameters.java b2b787c engine/api/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java d461d58 engine/api/src/org/apache/cloudstack/storage/datastore/db/StoragePoolVO.java 0262f65 engine/schema/src/com/cloud/storage/DiskOfferingVO.java 44f9e8f engine/schema/src/com/cloud/storage/VolumeVO.java 1699afd engine/schema/src/com/cloud/storage/dao/VolumeDao.java 2513181 engine/schema/src/com/cloud/storage/dao/VolumeDaoImpl.java 12ca3c7 engine/storage/image/src/org/apache/cloudstack/storage/image/ImageServiceImpl.java 99b1013 engine/storage/image/src/org/apache/cloudstack/storage/image/driver/AncientImageDataStoreDriverImpl.java 4c16f2f engine/storage/image/src/org/apache/cloudstack/storage/image/driver/DefaultImageDataStoreDriverImpl.java 3d46c73 engine/storage/integration-test/test/org/apache/cloudstack/storage/allocator/StorageAllocatorTest.java 9444fa5
Re: ACS 4.1.1 release - bugfixes to backport
I don't get this. Based on my previous question on the dev list, we should
create a new schema-410to411.sql and Upgrade410to411 to handle any upgrade
from 4.1.0 to 4.1.1, that is how I made the commit in 4.1 for
CLOUDSTACK-3015
(https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=11cfc0
34e0b45cf032c1e9dcfe32021fb73789d5). Why do we need to change existing
Upgrade40to41 file?
Thanks
-min
On 6/20/13 6:31 PM, Hiroaki KAWAI ka...@stratosphere.co.jp wrote:
I found there is an issue about versioning.
When we cut 4.1.1 release, we have to patch like this:
---
diff --git a/server/src/com/cloud/upgrade/dao/Upgrade40to41.java
b/server/src/com/cloud/upgrade/dao/Upgrade40to41.java
index 9e386b9..89f54bc 100644
--- a/server/src/com/cloud/upgrade/dao/Upgrade40to41.java
+++ b/server/src/com/cloud/upgrade/dao/Upgrade40to41.java
@@ -39,7 +39,7 @@ public class Upgrade40to41 implements DbUpgrade {
@Override
public String getUpgradedVersion() {
-return 4.1.0;
+return 4.1.1;
}
@Override
---
(2013/06/06 3:22), Musayev, Ilya wrote:
Hi All,
Sorry I was a bit disconnected from the community - as my $dayjob kept
me very busy.
I would like to start of this thread to keep track of bugfixes we need
to back port from 4.1 to 4.1.1 release.
Please use this thread and reference bug fixes we need to add into
4.1.1, I will be creating a new 4.1.1 branch/tag shortly.
Regards
ilya
Re: ACS 4.1.1 release - bugfixes to backport
Min is right. We should never change existing upgrade paths as it will
affect users who updated to 4.1.0.
Instead as Min suggesting, we should add a new upgrade path from 4.1.0 to
4.1.1. We should do it even when there are no changes.
Min, we don't need schema-410to411.sql if there were no mysql changes. All
we need is Upgrade410to411. Can you merge your changes to master branch?
-alena.
On 6/21/13 9:39 AM, Min Chen min.c...@citrix.com wrote:
I don't get this. Based on my previous question on the dev list, we should
create a new schema-410to411.sql and Upgrade410to411 to handle any upgrade
from 4.1.0 to 4.1.1, that is how I made the commit in 4.1 for
CLOUDSTACK-3015
(https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=11cfc
0
34e0b45cf032c1e9dcfe32021fb73789d5). Why do we need to change existing
Upgrade40to41 file?
Thanks
-min
On 6/20/13 6:31 PM, Hiroaki KAWAI ka...@stratosphere.co.jp wrote:
I found there is an issue about versioning.
When we cut 4.1.1 release, we have to patch like this:
---
diff --git a/server/src/com/cloud/upgrade/dao/Upgrade40to41.java
b/server/src/com/cloud/upgrade/dao/Upgrade40to41.java
index 9e386b9..89f54bc 100644
--- a/server/src/com/cloud/upgrade/dao/Upgrade40to41.java
+++ b/server/src/com/cloud/upgrade/dao/Upgrade40to41.java
@@ -39,7 +39,7 @@ public class Upgrade40to41 implements DbUpgrade {
@Override
public String getUpgradedVersion() {
-return 4.1.0;
+return 4.1.1;
}
@Override
---
(2013/06/06 3:22), Musayev, Ilya wrote:
Hi All,
Sorry I was a bit disconnected from the community - as my $dayjob kept
me very busy.
I would like to start of this thread to keep track of bugfixes we need
to back port from 4.1 to 4.1.1 release.
Please use this thread and reference bug fixes we need to add into
4.1.1, I will be creating a new 4.1.1 branch/tag shortly.
Regards
ilya
Re: Review Request: CLOUDSTACK-702: Tests for Multiple IP Ranges
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11026/#review22259 --- Commit a6a49490fbcc344f8a37d8c2ef0254da3ae39d89 in branch refs/heads/master from Sheng Yang [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a6a4949 ] Fix baremetal functionality 1. Baremetal doesn't have secondary storage, so we don't need check them. 2. The new AddBaremetalHostCmd hasn't been used by UI, so keep the validity checking out for now. AddHostCmd would still works. 3. Baremetal haven't implemented multiple ip range feature(CLOUDSTACK-702), return true for now for single range. - ASF Subversion and Git Services On May 9, 2013, 1:23 p.m., sanjeev n wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11026/ --- (Updated May 9, 2013, 1:23 p.m.) Review request for cloudstack, Prasanna Santhanam and SrikanteswaraRao Talluri. Description --- CLOUDSTACK-702: Tests for Multiple IP Ranges 1. Add ip range super set to existing CIDR 2. Add ip range subset to existing CIDR This addresses bug CLOUDSTACK-702. Diffs - test/integration/component/test_multiple_ip_ranges.py 7e9eeb1 Diff: https://reviews.apache.org/r/11026/diff/ Testing --- yes Thanks, sanjeev n
Re: ACS 4.1.1 release - bugfixes to backport
My fix involves mysql change, so I have to create schema-410to411.sql. The
fix is already in master.
Thanks
-min
On 6/21/13 9:59 AM, Alena Prokharchyk alena.prokharc...@citrix.com
wrote:
Min is right. We should never change existing upgrade paths as it will
affect users who updated to 4.1.0.
Instead as Min suggesting, we should add a new upgrade path from 4.1.0 to
4.1.1. We should do it even when there are no changes.
Min, we don't need schema-410to411.sql if there were no mysql changes. All
we need is Upgrade410to411. Can you merge your changes to master branch?
-alena.
On 6/21/13 9:39 AM, Min Chen min.c...@citrix.com wrote:
I don't get this. Based on my previous question on the dev list, we
should
create a new schema-410to411.sql and Upgrade410to411 to handle any
upgrade
from 4.1.0 to 4.1.1, that is how I made the commit in 4.1 for
CLOUDSTACK-3015
(https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=11cf
c
0
34e0b45cf032c1e9dcfe32021fb73789d5). Why do we need to change existing
Upgrade40to41 file?
Thanks
-min
On 6/20/13 6:31 PM, Hiroaki KAWAI ka...@stratosphere.co.jp wrote:
I found there is an issue about versioning.
When we cut 4.1.1 release, we have to patch like this:
---
diff --git a/server/src/com/cloud/upgrade/dao/Upgrade40to41.java
b/server/src/com/cloud/upgrade/dao/Upgrade40to41.java
index 9e386b9..89f54bc 100644
--- a/server/src/com/cloud/upgrade/dao/Upgrade40to41.java
+++ b/server/src/com/cloud/upgrade/dao/Upgrade40to41.java
@@ -39,7 +39,7 @@ public class Upgrade40to41 implements DbUpgrade {
@Override
public String getUpgradedVersion() {
-return 4.1.0;
+return 4.1.1;
}
@Override
---
(2013/06/06 3:22), Musayev, Ilya wrote:
Hi All,
Sorry I was a bit disconnected from the community - as my $dayjob kept
me very busy.
I would like to start of this thread to keep track of bugfixes we need
to back port from 4.1 to 4.1.1 release.
Please use this thread and reference bug fixes we need to add into
4.1.1, I will be creating a new 4.1.1 branch/tag shortly.
Regards
ilya
RE: [DISCUSS] Do we need code review process for code changes related to storage subsystem?
-Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Thursday, June 20, 2013 5:42 PM To: dev@cloudstack.apache.org Cc: Edison Su Subject: Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem? On Thu, Jun 20, 2013 at 05:59:01PM +, Edison Su wrote: For interface/API changes, we'd better have a code review, as more storage vendors and more developers outside Citrix are contributing code to CloudStack storage subsystem. The code change should have less surprise for everybody who cares about storage subsystem. I'm not following what you are saying Edison. What are we not doing in this regard right now? I'm also not getting the Citrix point of reference here. We don't have a code review process for each commit currently, the result of that, as the code evolving, people add more and more code, features, bug fixes etc, etc. Then maybe one month later, when you take a look at the code, which may be quite different than what you known about. So I want to add a code review process here, maybe start from storage subsystem at first. The reason I add Citrix here, let's take a look at what happened in the last month: Mike, from SolidFire, is asking why there is a hypervisor field in the storage pool, simply, the hypervisor field breaks his code. And I don't understand why there is a column, called dynamicallyScalable, in vm_template table. I think you will understand my problem here... -chip
Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem?
Just as an FYI, the code I sent off to John Burwell for review accepts the fact that we require a hypervisor type when creating primary storage now and expects the admin to pass in the type of Any. I then made a small change elsewhere in the codebase so this would work in my situation. It might be late in the game to change this hypervisor field being required, but I just wanted to let you guys know that I've written code for my situation to get around it. Thanks! On Fri, Jun 21, 2013 at 12:15 PM, Edison Su edison...@citrix.com wrote: -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Thursday, June 20, 2013 5:42 PM To: dev@cloudstack.apache.org Cc: Edison Su Subject: Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem? On Thu, Jun 20, 2013 at 05:59:01PM +, Edison Su wrote: For interface/API changes, we'd better have a code review, as more storage vendors and more developers outside Citrix are contributing code to CloudStack storage subsystem. The code change should have less surprise for everybody who cares about storage subsystem. I'm not following what you are saying Edison. What are we not doing in this regard right now? I'm also not getting the Citrix point of reference here. We don't have a code review process for each commit currently, the result of that, as the code evolving, people add more and more code, features, bug fixes etc, etc. Then maybe one month later, when you take a look at the code, which may be quite different than what you known about. So I want to add a code review process here, maybe start from storage subsystem at first. The reason I add Citrix here, let's take a look at what happened in the last month: Mike, from SolidFire, is asking why there is a hypervisor field in the storage pool, simply, the hypervisor field breaks his code. And I don't understand why there is a column, called dynamicallyScalable, in vm_template table. I think you will understand my problem here... -chip -- *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: [DISCUSS] Do we need code review process for code changes related to storage subsystem?
-Original Message- From: John Burwell [mailto:jburw...@basho.com] Sent: Friday, June 21, 2013 11:43 AM To: dev@cloudstack.apache.org Cc: 'Chip Childers' Subject: Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem? Edison, My understanding of our process is that the merges of significant changes should be proposed to the mailing list with the [MERGE] tag and wait up to 72 hours for feedback. I consider interface changes to meet that criteria given the potential to break other folks work. It sounds like we had a change that inadvertently slipped through without notice to list. Going forward, I The problem of current merge request, is that, you don't know what kind of change the merge request did, unless you dig into the code. Let's say, there is a merge request, the code touches both vm and storage code, then how do I know, by just taking look at the request, that, the storage part of code is been changed. As there are lot of merge requests, a single person can't review all the merge requests, then likely, the change is slipped without the notice to other people who wants to review storage related code, even if the merge request is send out to the list. Maybe, we should ask for each merge request, need to add a list of files been changed: like the output of git diff --stat? propose that we follow this process for significant patches and, additionally, push them to Review Board. As a matter of collaboration, it might also be a good idea to open a [DISCUSS] thread during the design/planning stages, but I don't think we need to require it. Do you think this approach will properly balance to our needs to coordinate/review work with maintaining a smooth flow? Thanks, -John On Jun 21, 2013, at 2:15 PM, Edison Su edison...@citrix.com wrote: -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Thursday, June 20, 2013 5:42 PM To: dev@cloudstack.apache.org Cc: Edison Su Subject: Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem? On Thu, Jun 20, 2013 at 05:59:01PM +, Edison Su wrote: For interface/API changes, we'd better have a code review, as more storage vendors and more developers outside Citrix are contributing code to CloudStack storage subsystem. The code change should have less surprise for everybody who cares about storage subsystem. I'm not following what you are saying Edison. What are we not doing in this regard right now? I'm also not getting the Citrix point of reference here. We don't have a code review process for each commit currently, the result of that, as the code evolving, people add more and more code, features, bug fixes etc, etc. Then maybe one month later, when you take a look at the code, which may be quite different than what you known about. So I want to add a code review process here, maybe start from storage subsystem at first. The reason I add Citrix here, let's take a look at what happened in the last month: Mike, from SolidFire, is asking why there is a hypervisor field in the storage pool, simply, the hypervisor field breaks his code. And I don't understand why there is a column, called dynamicallyScalable, in vm_template table. I think you will understand my problem here... -chip
Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem?
Edison, The person pushing the merge request should highlight that it includes interface changes (regardless of whether or not it is a storage patch). I also think that we should be pushing all patches that rise to merge requests into Review Board to allow potential reviewers a place to cleanly communicate and discuss issues. Thanks, -John On Jun 21, 2013, at 3:53 PM, Edison Su edison...@citrix.com wrote: -Original Message- From: John Burwell [mailto:jburw...@basho.com] Sent: Friday, June 21, 2013 11:43 AM To: dev@cloudstack.apache.org Cc: 'Chip Childers' Subject: Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem? Edison, My understanding of our process is that the merges of significant changes should be proposed to the mailing list with the [MERGE] tag and wait up to 72 hours for feedback. I consider interface changes to meet that criteria given the potential to break other folks work. It sounds like we had a change that inadvertently slipped through without notice to list. Going forward, I The problem of current merge request, is that, you don't know what kind of change the merge request did, unless you dig into the code. Let's say, there is a merge request, the code touches both vm and storage code, then how do I know, by just taking look at the request, that, the storage part of code is been changed. As there are lot of merge requests, a single person can't review all the merge requests, then likely, the change is slipped without the notice to other people who wants to review storage related code, even if the merge request is send out to the list. Maybe, we should ask for each merge request, need to add a list of files been changed: like the output of git diff --stat? propose that we follow this process for significant patches and, additionally, push them to Review Board. As a matter of collaboration, it might also be a good idea to open a [DISCUSS] thread during the design/planning stages, but I don't think we need to require it. Do you think this approach will properly balance to our needs to coordinate/review work with maintaining a smooth flow? Thanks, -John On Jun 21, 2013, at 2:15 PM, Edison Su edison...@citrix.com wrote: -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Thursday, June 20, 2013 5:42 PM To: dev@cloudstack.apache.org Cc: Edison Su Subject: Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem? On Thu, Jun 20, 2013 at 05:59:01PM +, Edison Su wrote: For interface/API changes, we'd better have a code review, as more storage vendors and more developers outside Citrix are contributing code to CloudStack storage subsystem. The code change should have less surprise for everybody who cares about storage subsystem. I'm not following what you are saying Edison. What are we not doing in this regard right now? I'm also not getting the Citrix point of reference here. We don't have a code review process for each commit currently, the result of that, as the code evolving, people add more and more code, features, bug fixes etc, etc. Then maybe one month later, when you take a look at the code, which may be quite different than what you known about. So I want to add a code review process here, maybe start from storage subsystem at first. The reason I add Citrix here, let's take a look at what happened in the last month: Mike, from SolidFire, is asking why there is a hypervisor field in the storage pool, simply, the hypervisor field breaks his code. And I don't understand why there is a column, called dynamicallyScalable, in vm_template table. I think you will understand my problem here... -chip
[ACS 42] Status of Features
Hi, Animesh mentioned that he is offline this week, so I am sending the report Current status of new features and Improvements [1]. -Some cleanup is required as there are 54 tickets in resolved status. Once Dev / QA and Doc activity is done, we can close these. If those respective owners can take action on the sub tasks, I can close the tickets. Other than that there are Automation tasks which will be in unresolved status. Those need to be tracked independently. -There are 39 tickets where dev work is still pending. Pl note deadline for these to be completed ( to have code in master) is 6/28 [2] Status Total Closed 8 In Progress 13 Open 23 Ready To Review 2 Reopened 1 Resolved 54 Grand Total101 [1] https://issues.apache.org/jira/issues/#?jql=project%20%3D%20CLOUDSTACK%20AND%20issuetype%20in%20(Improvement%2C%20%22New%20Feature%22)%20AND%20fixVersion%20%3D%20%224.2.0%22 [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+4.2+Release Thanks /Sudha
RE: [DISCUSS] Do we need code review process for code changes related to storage subsystem?
How about, for all the interfaces, DB schema changes, related to storage subsystem, need to send out a merge request and push the patches into review board? It's not only for feature development, but also for bug fixes. I am not sure how many people want to review the changes related to storage subsystem, though. If only I am interested in it, then don't need to do that:) -Original Message- From: John Burwell [mailto:jburw...@basho.com] Sent: Friday, June 21, 2013 1:00 PM To: dev@cloudstack.apache.org Cc: 'Chip Childers' Subject: Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem? Edison, The person pushing the merge request should highlight that it includes interface changes (regardless of whether or not it is a storage patch). I also think that we should be pushing all patches that rise to merge requests into Review Board to allow potential reviewers a place to cleanly communicate and discuss issues. Thanks, -John On Jun 21, 2013, at 3:53 PM, Edison Su edison...@citrix.com wrote: -Original Message- From: John Burwell [mailto:jburw...@basho.com] Sent: Friday, June 21, 2013 11:43 AM To: dev@cloudstack.apache.org Cc: 'Chip Childers' Subject: Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem? Edison, My understanding of our process is that the merges of significant changes should be proposed to the mailing list with the [MERGE] tag and wait up to 72 hours for feedback. I consider interface changes to meet that criteria given the potential to break other folks work. It sounds like we had a change that inadvertently slipped through without notice to list. Going forward, I The problem of current merge request, is that, you don't know what kind of change the merge request did, unless you dig into the code. Let's say, there is a merge request, the code touches both vm and storage code, then how do I know, by just taking look at the request, that, the storage part of code is been changed. As there are lot of merge requests, a single person can't review all the merge requests, then likely, the change is slipped without the notice to other people who wants to review storage related code, even if the merge request is send out to the list. Maybe, we should ask for each merge request, need to add a list of files been changed: like the output of git diff --stat? propose that we follow this process for significant patches and, additionally, push them to Review Board. As a matter of collaboration, it might also be a good idea to open a [DISCUSS] thread during the design/planning stages, but I don't think we need to require it. Do you think this approach will properly balance to our needs to coordinate/review work with maintaining a smooth flow? Thanks, -John On Jun 21, 2013, at 2:15 PM, Edison Su edison...@citrix.com wrote: -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Thursday, June 20, 2013 5:42 PM To: dev@cloudstack.apache.org Cc: Edison Su Subject: Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem? On Thu, Jun 20, 2013 at 05:59:01PM +, Edison Su wrote: For interface/API changes, we'd better have a code review, as more storage vendors and more developers outside Citrix are contributing code to CloudStack storage subsystem. The code change should have less surprise for everybody who cares about storage subsystem. I'm not following what you are saying Edison. What are we not doing in this regard right now? I'm also not getting the Citrix point of reference here. We don't have a code review process for each commit currently, the result of that, as the code evolving, people add more and more code, features, bug fixes etc, etc. Then maybe one month later, when you take a look at the code, which may be quite different than what you known about. So I want to add a code review process here, maybe start from storage subsystem at first. The reason I add Citrix here, let's take a look at what happened in the last month: Mike, from SolidFire, is asking why there is a hypervisor field in the storage pool, simply, the hypervisor field breaks his code. And I don't understand why there is a column, called dynamicallyScalable, in vm_template table. I think you will understand my problem here... -chip
Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem?
On Jun 21, 2013, at 4:18 PM, Edison Su edison...@citrix.com wrote: How about, for all the interfaces, DB schema changes, related to storage subsystem, need to send out a merge request and push the patches into review board? It's not only for feature development, but also for bug fixes. I am not sure how many people want to review the changes related to storage subsystem, though. If only I am interested in it, then don't need to do that:) I don't understand why storage is different from the rest of the code. -Original Message- From: John Burwell [mailto:jburw...@basho.com] Sent: Friday, June 21, 2013 1:00 PM To: dev@cloudstack.apache.org Cc: 'Chip Childers' Subject: Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem? Edison, The person pushing the merge request should highlight that it includes interface changes (regardless of whether or not it is a storage patch). I also think that we should be pushing all patches that rise to merge requests into Review Board to allow potential reviewers a place to cleanly communicate and discuss issues. Thanks, -John On Jun 21, 2013, at 3:53 PM, Edison Su edison...@citrix.com wrote: -Original Message- From: John Burwell [mailto:jburw...@basho.com] Sent: Friday, June 21, 2013 11:43 AM To: dev@cloudstack.apache.org Cc: 'Chip Childers' Subject: Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem? Edison, My understanding of our process is that the merges of significant changes should be proposed to the mailing list with the [MERGE] tag and wait up to 72 hours for feedback. I consider interface changes to meet that criteria given the potential to break other folks work. It sounds like we had a change that inadvertently slipped through without notice to list. Going forward, I The problem of current merge request, is that, you don't know what kind of change the merge request did, unless you dig into the code. Let's say, there is a merge request, the code touches both vm and storage code, then how do I know, by just taking look at the request, that, the storage part of code is been changed. As there are lot of merge requests, a single person can't review all the merge requests, then likely, the change is slipped without the notice to other people who wants to review storage related code, even if the merge request is send out to the list. Maybe, we should ask for each merge request, need to add a list of files been changed: like the output of git diff --stat? propose that we follow this process for significant patches and, additionally, push them to Review Board. As a matter of collaboration, it might also be a good idea to open a [DISCUSS] thread during the design/planning stages, but I don't think we need to require it. Do you think this approach will properly balance to our needs to coordinate/review work with maintaining a smooth flow? Thanks, -John On Jun 21, 2013, at 2:15 PM, Edison Su edison...@citrix.com wrote: -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Thursday, June 20, 2013 5:42 PM To: dev@cloudstack.apache.org Cc: Edison Su Subject: Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem? On Thu, Jun 20, 2013 at 05:59:01PM +, Edison Su wrote: For interface/API changes, we'd better have a code review, as more storage vendors and more developers outside Citrix are contributing code to CloudStack storage subsystem. The code change should have less surprise for everybody who cares about storage subsystem. I'm not following what you are saying Edison. What are we not doing in this regard right now? I'm also not getting the Citrix point of reference here. We don't have a code review process for each commit currently, the result of that, as the code evolving, people add more and more code, features, bug fixes etc, etc. Then maybe one month later, when you take a look at the code, which may be quite different than what you known about. So I want to add a code review process here, maybe start from storage subsystem at first. The reason I add Citrix here, let's take a look at what happened in the last month: Mike, from SolidFire, is asking why there is a hypervisor field in the storage pool, simply, the hypervisor field breaks his code. And I don't understand why there is a column, called dynamicallyScalable, in vm_template table. I think you will understand my problem here... -chip
[ACS 42] Defect Metrics
Below is summary of defect status [1] - Unassigned and unresolved should be picked up by community members. Pl review if you can take them up (atleast blockers and critical on priority) Un Assigned and Un resolved Blocker 8 Critical 21 Major113 Minor34 Trivial2 Total 178 Total Defect Status Blocker 19 Critical 56 Major213 Minor62 Trivial2 Total 352 More detailed reports can be seen on incoming rates, fix rates and close rates on dashboard [1] [1] https://issues.apache.org/jira/secure/Dashboard.jspa
RE: [DISCUSS] Do we need code review process for code changes related to storage subsystem?
-Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Friday, June 21, 2013 1:22 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem? On Jun 21, 2013, at 4:18 PM, Edison Su edison...@citrix.com wrote: How about, for all the interfaces, DB schema changes, related to storage subsystem, need to send out a merge request and push the patches into review board? It's not only for feature development, but also for bug fixes. I am not sure how many people want to review the changes related to storage subsystem, though. If only I am interested in it, then don't need to do that:) I don't understand why storage is different from the rest of the code. Because, there is no other body call for reviewing the change before. If we can make it as a standard process for all the changes related to interfaces, db changes, on cloudstack code, and there are people like to review the changes, then let's do it. -Original Message- From: John Burwell [mailto:jburw...@basho.com] Sent: Friday, June 21, 2013 1:00 PM To: dev@cloudstack.apache.org Cc: 'Chip Childers' Subject: Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem? Edison, The person pushing the merge request should highlight that it includes interface changes (regardless of whether or not it is a storage patch). I also think that we should be pushing all patches that rise to merge requests into Review Board to allow potential reviewers a place to cleanly communicate and discuss issues. Thanks, -John On Jun 21, 2013, at 3:53 PM, Edison Su edison...@citrix.com wrote: -Original Message- From: John Burwell [mailto:jburw...@basho.com] Sent: Friday, June 21, 2013 11:43 AM To: dev@cloudstack.apache.org Cc: 'Chip Childers' Subject: Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem? Edison, My understanding of our process is that the merges of significant changes should be proposed to the mailing list with the [MERGE] tag and wait up to 72 hours for feedback. I consider interface changes to meet that criteria given the potential to break other folks work. It sounds like we had a change that inadvertently slipped through without notice to list. Going forward, I The problem of current merge request, is that, you don't know what kind of change the merge request did, unless you dig into the code. Let's say, there is a merge request, the code touches both vm and storage code, then how do I know, by just taking look at the request, that, the storage part of code is been changed. As there are lot of merge requests, a single person can't review all the merge requests, then likely, the change is slipped without the notice to other people who wants to review storage related code, even if the merge request is send out to the list. Maybe, we should ask for each merge request, need to add a list of files been changed: like the output of git diff --stat? propose that we follow this process for significant patches and, additionally, push them to Review Board. As a matter of collaboration, it might also be a good idea to open a [DISCUSS] thread during the design/planning stages, but I don't think we need to require it. Do you think this approach will properly balance to our needs to coordinate/review work with maintaining a smooth flow? Thanks, -John On Jun 21, 2013, at 2:15 PM, Edison Su edison...@citrix.com wrote: -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Thursday, June 20, 2013 5:42 PM To: dev@cloudstack.apache.org Cc: Edison Su Subject: Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem? On Thu, Jun 20, 2013 at 05:59:01PM +, Edison Su wrote: For interface/API changes, we'd better have a code review, as more storage vendors and more developers outside Citrix are contributing code to CloudStack storage subsystem. The code change should have less surprise for everybody who cares about storage subsystem. I'm not following what you are saying Edison. What are we not doing in this regard right now? I'm also not getting the Citrix point of reference here. We don't have a code review process for each commit currently, the result of that, as the code evolving, people add more and more code, features, bug fixes etc, etc. Then maybe one month later, when you take a look at the code, which may be quite different than what you known about. So I want to add a code review process here, maybe start from storage subsystem at first. The reason I add Citrix here, let's take a look at what happened in the last month: Mike, from SolidFire, is asking why there is a
RE: Resource Management/Allocation for CS
Hi Pouya, All of CloudStack's RA heuristics are applied by deployment planner modules and host/storagepool allocators to decide the order in which resource(pods,clusters,hosts,storage pools) will be considered for a VM deployment/migration. Following are the existing flavors of these modules: random: This just shuffles the list of clusters/hosts/pools that is returned by the DB lookup. Random does not mean round-robin - So if you are looking for a new host being picked up on every deployment - that may not happen. firstfit: This makes sure that clusters are ordered by available capacity and first hosts/pools having enough capacity is chosen within a cluster. userdispersing: For a given account, this makes sure that VM's are dispersed - so clusters/hosts with minimum number of running VM's for that account are chosen first. Storage Pool with minimum number of Ready storage pools for the account is chosen first. Userconcentratedpod: Always choose the pod/cluster with max. number of VMs for the account - concentrating VM's at one pod. You can find the source code related to above under: server/src/com/cloud/deploy, plugins/deployment-planners, plugins/host-allocators, plugins/storage-allocators Hope this helps. Thanks, Prachi -Original Message- From: Linux TUX [mailto:azgil.i...@yahoo.com] Sent: Friday, June 21, 2013 5:48 AM To: dev@cloudstack.apache.org Subject: Resource Management/Allocation for CS Hi All, Does anybody can tell me which parts of CloudStack's source code are related to its Resource Allocation (RA) process? By RA, I mean the part of code that is responsible for VM migration or process migration, if there is any. As you know, there are two kinds of RA, to wit: 1) server side such as VM migration, or 2) client side such as clients' proprietary schedulers. Furthermore, client side's RA's success is dependent on knowing sever side's RA very well. So, since i am interested to work on RA of CloudStack, if, with regard to the above information, you have any idea, please tell me? Also, if your are working on it, please let me know. Finally, it would be really approciated if you tell me which parts of the source code is related to implementation of CloudStack's RA algorithms. Best regards, Pouya
Re: Review Request: CLOUDSTACK-2304 [ZWPS]NPE while migrating volume from one zone wide primary to another
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12025/#review22276 --- engine/schema/src/com/cloud/storage/VolumeVO.java https://reviews.apache.org/r/12025/#comment45766 I don't get it for this change. if that.getPodId() is null, then this.podId = this.getPodId() will still work, right? engine/storage/volume/src/org/apache/cloudstack/storage/volume/VolumeServiceImpl.java https://reviews.apache.org/r/12025/#comment45767 Again, if pool.getPodId() == null, then newVol.setPodId(pool.getPodId()) will work. - edison su On June 21, 2013, 12:32 p.m., Rajesh Battala wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12025/ --- (Updated June 21, 2013, 12:32 p.m.) Review request for cloudstack, Sateesh Chodapuneedi, edison su, Alex Huang, and Ram Ganesh. Description --- Issue : while migrating the volume from one ZWPS to another ZWPS then NPE is having which is failing the migration of volume Fixed: The issue is, if the volume is in ZWPS then the volume object won't be having podid. while volume migration, ZWPS specific volume cases are not handled. Fixed the issues by adding a new constructor in VolumeVO and taken care in VolumeServiceImpl to handle ZWPS volume while migration. This addresses bug CLOUDSTACK-2304. Diffs - engine/schema/src/com/cloud/storage/VolumeVO.java 02c09a2 engine/storage/volume/src/org/apache/cloudstack/storage/volume/VolumeServiceImpl.java 1d36f93 Diff: https://reviews.apache.org/r/12025/diff/ Testing --- Setup: Create a KVM cluster and add zwps to the primary storage. ZWPS got mounted on KVM. Created instances in KVM. 1. Create a Volume and attach the volume to the running VM. volume got successfully attached to the VM. 2. Detach the Volume and then try to Migrate the Volume to another ZWPS added to the ZONE. volume got migrated successfully to another ZWPS. Observed Volume got copied to the new ZWPS and then the old volume is deleted. Verified db, the volume uuid got updated and necessary fields. Addition Testing: Created Xenserver cluster add cluster scope storage. 1. create a volume and attach the instance running in Xenserver. Success. 2. detach the volume and try to migrate the volume to another cluster scope storage. Volume got successfully migrate to another storage. Observed Volume got copied to the new PS and then the old volume is deleted. Verified db, the volume uuid got updated and necessary fields. Thanks, Rajesh Battala
Re: Resource Management/Allocation for CS
HiPrachi, Thank you for your reply. Surely, this helps. I will work on these implementations, and then report my ideas back to the community. Thanks, Pouya From: Prachi Damle prachi.da...@citrix.com To: dev@cloudstack.apache.org dev@cloudstack.apache.org; Linux TUX azgil.i...@yahoo.com Sent: Saturday, 22 June 2013, 1:28 Subject: RE: Resource Management/Allocation for CS Hi Pouya, All of CloudStack's RA heuristics are applied by deployment planner modules and host/storagepool allocators to decide the order in which resource(pods,clusters,hosts,storage pools) will be considered for a VM deployment/migration. Following are the existing flavors of these modules: random: This just shuffles the list of clusters/hosts/pools that is returned by the DB lookup. Random does not mean round-robin - So if you are looking for a new host being picked up on every deployment - that may not happen. firstfit: This makes sure that clusters are ordered by available capacity and first hosts/pools having enough capacity is chosen within a cluster. userdispersing: For a given account, this makes sure that VM's are dispersed - so clusters/hosts with minimum number of running VM's for that account are chosen first. Storage Pool with minimum number of Ready storage pools for the account is chosen first. Userconcentratedpod: Always choose the pod/cluster with max. number of VMs for the account - concentrating VM's at one pod. You can find the source code related to above under: server/src/com/cloud/deploy, plugins/deployment-planners, plugins/host-allocators, plugins/storage-allocators Hope this helps. Thanks, Prachi -Original Message- From: Linux TUX [mailto:azgil.i...@yahoo.com] Sent: Friday, June 21, 2013 5:48 AM To: dev@cloudstack.apache.org Subject: Resource Management/Allocation for CS Hi All, Does anybody can tell me which parts of CloudStack's source code are related to its Resource Allocation (RA) process? By RA, I mean the part of code that is responsible for VM migration or process migration, if there is any. As you know, there are two kinds of RA, to wit: 1) server side such as VM migration, or 2) client side such as clients' proprietary schedulers. Furthermore, client side's RA's success is dependent on knowing sever side's RA very well. So, since i am interested to work on RA of CloudStack, if, with regard to the above information, you have any idea, please tell me? Also, if your are working on it, please let me know. Finally, it would be really approciated if you tell me which parts of the source code is related to implementation of CloudStack's RA algorithms. Best regards, Pouya
RE: NFS Cache storage query - an UI change where you can create a NFS Cache Storage independently
Sanjeev, I've made an UI change where you can create a NFS Cache Storage independently. After getting latest code from master branch, you'll see a new dropdown Select view in Infrastructure menu Secondary Storage. Change Select view to Cache Storage, then you'll see Add NFS Cache Storage button on right top corner. Jessica -Original Message- From: Sanjeev Neelarapu [mailto:sanjeev.neelar...@citrix.com] Sent: Friday, June 14, 2013 6:07 AM To: dev@cloudstack.apache.org Subject: NFS Cache storage query Hi, I have a query on how to add NFS Cache storage. Before creating a zone if we create a secondary storage with s3 as the storage provider and don't select NFS Cache Storage then we treat it as S3 at region level. Later I create a zone and at add secondary storage creation wizard in UI if I select NFS as secondary storage provider will it be treated as NFS Cache Storage? If not is there a way to add NFS cache storage for that zone? Thanks, Sanjeev
Advanced Network Question
Hello, Is it possible to convert a basic network to an advanced network without jeopardizing the current instances? - Maurice
Re: Advanced Network Question
No sir, 2 separate architectures. You can download your templates or transfer then to the new zone however. Sent from my HTC - Reply message - From: Maurice L. maur...@daoenix.com To: dev@cloudstack.apache.org Subject: Advanced Network Question Date: Fri, Jun 21, 2013 6:44 PM Hello, Is it possible to convert a basic network to an advanced network without jeopardizing the current instances? - Maurice
Re: Advanced Network Question
Great -- Thank you for the prompt response. - Maurice On 6/21/2013 8:50 PM, kel...@backbonetechnology.com wrote: No sir, 2 separate architectures. You can download your templates or transfer then to the new zone however. Sent from my HTC - Reply message - From: Maurice L. maur...@daoenix.com To: dev@cloudstack.apache.org Subject: Advanced Network Question Date: Fri, Jun 21, 2013 6:44 PM Hello, Is it possible to convert a basic network to an advanced network without jeopardizing the current instances? - Maurice
Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem?
On Fri, Jun 21, 2013 at 07:53:21PM +, Edison Su wrote: Edison, My understanding of our process is that the merges of significant changes should be proposed to the mailing list with the [MERGE] tag and wait up to 72 hours for feedback. I consider interface changes to meet that criteria given the potential to break other folks work. It sounds like we had a change that inadvertently slipped through without notice to list. Going forward, I The problem of current merge request, is that, you don't know what kind of change the merge request did, unless you dig into the code. Let's say, there is a merge request, the code touches both vm and storage code, then how do I know, by just taking look at the request, that, the storage part of code is been changed. As there are lot of merge requests, a single person can't review all the merge requests, then likely, the change is slipped without the notice to other people who wants to review storage related code, even if the merge request is send out to the list. Maybe, we should ask for each merge request, need to add a list of files been changed: like the output of git diff --stat? Edison, I think the problem is easily solved if people learn to do rebase instead of merge. When we diverge into topic branches for our features we end up in complete silos. If you do a regular rebase of your topic branch you are aware of the changes happening on the master branch. That precludes everyone from having to look at review/merge requests. Eg: If dev A is doing feature X that disrupts dev B doing feature Y both in their own branches. If dev A brings in his feature first to master and dev B rebases on top, B knows that his feature breaks when he rebases against master above dev A's feature X. By doing a merge B simply assumes his feature works alongside A's feature. At least then B, even if he ignored the merge request from A, will make noise on the list to fix it appropriately in collaboration with A. Our proposals /specs already include all the db changes and api changes. But like you said, not everyone is looking at them and preemptively nipping the possiblity of such conflicts. So a more pro-active process of keeping master as the one true state of the project and working additively on top of each other will prevent these frustrations. What do you think? -- Prasanna., Powered by BigRock.com
Re: Resource Management/Allocation for CS
On Fri, Jun 21, 2013 at 10:17:53PM +, Edison Su wrote: Haven't read the whole paper yet, but the above problem statement resonates with me. Our current centralized allocation algorithm may have problem in case of a large of concurrent VMs allocation. Speaking of which CLOUDSTACK-2843 makes some inroads in this direction. Not sure what the scale of this change is and testing complexities are. -- Prasanna., Powered by BigRock.com
