Re: fixPath (was: committer wanted for review)

[Daan Hoogland]

On Fri, Jun 21, 2013 at 6:18 AM, Prasanna Santhanam  wrote:

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

[Daan Hoogland]

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  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 
> wrote:
> >
> --
> Prasanna.,
>
> 
> Powered by BigRock.com
>
>

Re: fixPath (was: committer wanted for review)

[Prasanna Santhanam]

On Fri, Jun 21, 2013 at 09:38:56AM +0200, Daan Hoogland wrote:
> On Fri, Jun 21, 2013 at 6:18 AM, Prasanna Santhanam  wrote:
> 
> > > To 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.
> >
> > +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

[Prasanna Santhanam]

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  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 
> > wrote:
> > >
> > --
> > Prasanna.,
> >
> > 
> > Powered by BigRock.com
> >
> >

-- 
Prasanna.,


Powered by BigRock.com

Re: easy bug to fix for new comer

[Daan Hoogland]

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  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 
> 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 
> > > wrote:
> > > >
> > > --
> > > Prasanna.,
> > >
> > > 
> > > Powered by BigRock.com
> > >
> > >
>
> --
> Prasanna.,
>
> 
> Powered by BigRock.com
>
>

Review Request: deployDataCentrer formatted

[daan Hoogland]

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

[Ian Duffy]

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

[daan Hoogland]

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

[daan Hoogland]

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

[Rajesh Battala]

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

Re: Review Request: deployDataCentrer formatted

[Sebastien Goasguen]

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

[Rajesh Battala]

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

[Sebastien Goasguen]

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

[Sebastien Goasguen]

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

[daan Hoogland]

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

[Linux TUX]

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

[Sebastien Goasguen]

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

[John Burwell]

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

[Noel King]

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

[Sebastien Goasguen]

On Jun 21, 2013, at 9:11 AM, Noel King  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  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  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  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

[daan Hoogland]

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

[Daan Hoogland]

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

> 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 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 
>> 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 
>> > > wrote:
>> > > >
>> > > --
>> > > Prasanna.,
>> > >
>> > > 
>> > > Powered by BigRock.com
>> > >
>> > >
>>
>> --
>> Prasanna.,
>>
>> 
>> Powered by BigRock.com
>>
>>
>

Re: fixPath (was: committer wanted for review)

[Chip Childers]

On Fri, Jun 21, 2013 at 09:38:56AM +0200, Daan Hoogland wrote:
> On Fri, Jun 21, 2013 at 6:18 AM, Prasanna Santhanam  wrote:
> 
> > > To 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.
> >
> > +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

[Chip Childers]

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

[Noel King]

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

>
> On Jun 21, 2013, at 9:11 AM, Noel King  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  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  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  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 "vSwit

Re: Review Request: format codegenerator.py

[Sebastien Goasguen]

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

[John Burwell]

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  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  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  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, h

Re: Resource Management/Allocation for CS

[Linux TUX]

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 
To: dev@cloudstack.apache.org; Linux TUX  
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  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.

[Saksham Srivastava]

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

[John Burwell]

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  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"  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  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"  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 mailto:jburw...@basho.com>>
 Date: Tuesday, June 18, 2013 8:07 AM
 To: Min Chen mailto:min.c...@citrix.com>>
 Cc: Thomas O'Dowd mailto:tpod...@cloudian.com>>,
 "dev@cloudstack.apache.org"
 mailto: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
 mailto: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:
 
 
 
 URL
 
 generatePresignedUrl(String bucketName,
 
 String key,
 
 Date expiration,
 
 H

ha-handler

[Daan Hoogland]

LS,

Who is the goto-guy for the ha-handler (and will he be at ccc)?

regards,

HA Question

[Mike Tutkowski]

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
cloud
*™*

Re: HA Question

[Chip Childers]

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

[Mike Tutkowski]

Great - thanks, Chip!


On Fri, Jun 21, 2013 at 10:21 AM, Chip Childers
wrote:

> 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
cloud
*™*

Early for CCC13

[m...@kelceydamage.com]

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

[Mike Tutkowski]

---
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 
  
engine/storage/snapshot/src/org/apache/cloudstack/storage/snapshot/strat

Re: ACS 4.1.1 release - bugfixes to backport

[Min Chen]

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"  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] Re-enabling baremetal on master

[Sheng Yang]

Thank you all!

I would commit the change to MASTER soon.

--Sheng


On Thu, Jun 20, 2013 at 7:22 PM, David Nalley  wrote:

> Yes
> Happy to +1. Sheng, thanks for stepping up and getting this done.
>
> --David
> On Jun 20, 2013 7:19 PM, "Chip Childers" 
> wrote:
>
> > Nice!  I'm glad the feature has the benefit of tests now.  Thanks for
> > doing this Sheng!
> >
> > David - are you comfortable with this, and will you now +1 the feature?
> >
> > On Thu, Jun 20, 2013 at 9:55 PM, Sheng Yang  wrote:
> > > Hi,
> > >
> > > I've updated baremetal-4.2 branch, added integration test for some of
> > > baremetal related APIs, also fixed a bunch of baremetal API issues
> > exposed
> > > by the testing.
> > >
> > > Thanks!
> > >
> > > --Sheng
> > >
> > >
> > >
> > >
> > > On Wed, Jun 19, 2013 at 11:41 AM, Chip Childers
> > > wrote:
> > >
> > >> On Wed, Jun 19, 2013 at 11:36:11AM -0700, Sheng Yang wrote:
> > >> > On Wed, Jun 19, 2013 at 11:24 AM, Chip Childers
> > >> > wrote:
> > >> >
> > >> > > On Wed, Jun 19, 2013 at 11:00:33AM -0700, Sheng Yang wrote:
> > >> > > > Hi,
> > >> > > >
> > >> > > > I've created the https://reviews.apache.org/r/11977/  for
> review.
> > >> The
> > >> > > > branch re-enabled the baremetal for master. And all major bugs
> are
> > >> > > cleaned.
> > >> > > >
> > >> > > > https://issues.apache.org/jira/browse/CLOUDSTACK-1610
> > >> > > > https://issues.apache.org/jira/browse/CLOUDSTACK-1618
> > >> > > > https://issues.apache.org/jira/browse/CLOUDSTACK-1614
> > >> > > > https://issues.apache.org/jira/browse/CLOUDSTACK-1440
> > >> > > >
> > >> > > > In fact it's not a feature merge, because the code is already in
> > >> MASTER
> > >> > > > ready. We just disable it due to stability problem of 4.1
> release.
> > >> Now
> > >> > > I've
> > >> > > > tried to enable it, and the changeset is very small, mostly just
> > >> revert
> > >> > > the
> > >> > > > old disabling baremetal codes, and fix some issues with
> > introducing
> > >> other
> > >> > > > new features. Here is the summary:
> > >> > >
> > >> > > [snip]
> > >> > >
> > >> > > So David's standing veto was because of this comment (from him):
> > >> > >
> > >> > > "Baremetal seems to be suffering from a significant lack of unit
> > tests
> > >> > > and integration tests for marvin to consume. Let's get those in
> > place
> > >> > > before we consider re-enabling this."
> > >> > >
> > >> > > If I remember correctly, the reason that master has the code in
> it,
> > is
> > >> > > specifically because we decided that disabling the feature was
> > easier
> > >> to
> > >> > > honor the veto than reverting all of the changes.
> > >> > >
> > >> > > That being said, have we addressed the original veto's concerns?
> > >> > >
> > >> >
> > >> > Not yet. I didn't realize it's vetoed due to this. Let me see what
> > can I
> > >> do
> > >> > about it.
> > >>
> > >> Awesome.  Thanks Sheng!
> > >>
> > >> >
> > >> > In fact the above bugs cannot be detected for unit test or marvin
> > test(I
> > >> > even not sure if they're valid bugs or not, but at that time Frank
> is
> > on
> > >> > vacation and nobody took a look at these then decided disable the
> > >> feature,
> > >> > and after I re-enabled them, everything works fine for me).
> > >>
> > >> Yeah, I think that the bugs were just in need of triage.  The bugs
> > >> themselves weren't the major issue (although they were concerning), as
> > >> much as test coverage at either (or both) unit or integration levels.
> > >>
> > >> -chip
> > >>
> >
>

Re: ACS 4.1.1 release - bugfixes to backport

[Alena Prokharchyk]

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

[ASF Subversion and Git Services]

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

[Min Chen]

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" 
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"  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"  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: Error while update cloudstack from version 3.0.2 to 4.0.1

[Chip Childers]

On Thu, Jun 20, 2013 at 05:59:36PM +0800, Livio Lv wrote:
> Hi all:
> There is an error when i upgrade the version of cloudstack from 3.0.2 to
> 4.0.1.The following are my steps:
> 1. Use CloudStack-oss-3.0.2-1-rhel6.2.tar.gz. Execute ./install choose M
> and D.
> 2. Create zone and creat an instance.
> 3. Stop cloud-management service.
> 4. upgrade cloudstack from 3.0.2 to 4.0.1. Use
> CloudStack-non-OSS-13.tar.bz2. Execute ./install choose U

Where are you getting this file from?  None of the official artifacts
are named like that (I believe).

> 5. login mysql and execute "use cloud;source
> /usr/share/cloud/setup/db/schema-302to40.sql"
> 6. start cloud-management service.
> 
> After that i logged in the cloudstack'ui and stopped the instance.When i
> started the instance,there is an error.You can see the log:
> 
> 2013-06-20 17:25:01,736 ERROR [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-5:job-22) Failed to start instance VM[User|vm1]
> com.cloud.utils.exception.CloudRuntimeException: DB Exception on:
> org.apache.commons.dbcp.DelegatingPreparedStatement@26f4a444

Re: Query String Request Authentication(QSRA) support by S3 providers

[Min Chen]

John,

For S3, the api call createEntityExtractUrl is done on management server
side; while for NFS secondary storage, if the implementation of
createEntityExtractUrl will involve some code be executed in ssvm to copy
template from the install location to a public accessible web server
location.
I don't quite understand some of your comments below. This API is not
used to write any information to S3 bucket/directory. This is used for
object already existed on S3, and we just provide a URL for user to
download a template from S3, just like how Amazon provided user a way to
user to extract a S3 object through generatePresignedUrl. We can discuss
more on this on collaboration conference.

Thanks  
-min



On 6/21/13 7:25 AM, "John Burwell"  wrote:

>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  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"  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  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"  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 mailto:jburw...@basho.com>>
> Date: Tuesday, June 18, 2013 8:07 AM
> To: Min Chen mailto:min.c...@citrix.com>>
> Cc: Thomas O'Dowd
>mailto:tpod...@cloudian.com>>,
> "dev@cloudstack.apache.org"
> mailto: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
> mailto: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 

RE: [DISCUSS] Do we need code review process for code changes related to storage subsystem?

[Edison Su]

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

[Mike Tutkowski]

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  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
cloud
*™*

Re: [DISCUSS] Do we need code review process for code changes related to storage subsystem?

[John Burwell]

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 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  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 Su]

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

[John Burwell]

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

[Sudha Ponnaganti]

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?

[Edison Su]

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

[Chip Childers]

On Jun 21, 2013, at 4:18 PM, Edison Su  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  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  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

[Sudha Ponnaganti]

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?

[Edison Su]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Friday, June 21, 2013 1:22 PM
> To: 
> 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  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  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  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, peop

RE: Resource Management/Allocation for CS

[Prachi Damle]

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

[edison su]

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


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


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

[Linux TUX]

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 
To: "dev@cloudstack.apache.org" ; Linux TUX 
 
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: Resource Management/Allocation for CS

[Edison Su]

Found this paper sounds interesting: 
http://www.sigmetrics.org/sigmetrics2013/pdfs/p67.pdf

"The physical infrastructure is divided into a large pool of compute and 
storage servers. The former are organized into clusters consisting of tens of 
servers (typically 32 or so). A public cloud may contain hundreds of such 
clusters to get a large-scale deployment. The VMs from a single tenant may span 
an arbitrary set of clusters. This architecture exists for most of the 
deployments based on solutions from VMware
vSphere [27], Microsoft SCVMM [15] and others. In this environment it is 
infeasible to simply extend currently existing resource allocation mechanisms. 
The state-of-the-art today includes cluster management solutions like DRS [12] 
that collect information about VMs from each server in the cluster, and 
allocate CPU and memory re-sources based on the demand. This clustered model 
has certain advantages like facilitating VM migrations between servers if the 
total allocation to VMs on a server exceeds its physical capacity. However, 
when a tenant's VMs are spread across multiple clusters, a centralized strategy 
becomes impractical, since it requires dynamic per VM information to be made 
available at a cloud-level database shared among hundreds of clusters. Not only 
does this require a large amount of information to be frequently exchanged 
between clusters, but the centralized algorithms will be CPU intensive due to 
the large number of VMs it needs to consider.

The problem of scalable dynamic resource  and we are not aware of any practical 
existing solution. We envision our algorithm to run at the cluster-level and 
allow distributed clusters to work together to provide the customer with the 
abstraction of buying bulk capacity. 
"

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. 



> -Original Message-
> From: Linux TUX [mailto:azgil.i...@yahoo.com]
> Sent: Friday, June 21, 2013 2:27 PM
> To: Prachi Damle; dev@cloudstack.apache.org
> Subject: 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 
> To: "dev@cloudstack.apache.org" ; Linux TUX
> 
> 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

[Jessica Wang]

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

[Maurice L.]

Hello,

Is it possible to convert a basic network to an advanced network without 
jeopardizing the current instances?


- Maurice

Re: Advanced Network Question

[kel...@backbonetechnology.com]

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

[Maurice L.]

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." 
To: 
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?

[Prasanna Santhanam]

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

[Prasanna Santhanam]

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