Re: Review Request: Meng's Proposal for GSOC 2013 in Docbook format

[Sebastien Goasguen]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11775/#review21643
---

Ship it!


Thanks, patch applied to the master branch with commit 
6e2454228313c3373bfa96ef623a4b6ceb88d0ee
You can close this review as submitted.

- Sebastien Goasguen


On June 9, 2013, 11:17 p.m., meng han wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11775/
> ---
> 
> (Updated June 9, 2013, 11:17 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Description
> ---
> 
> This is the docbook for meng's GSOC project: "Improving CloudStack Support 
> for Apache Whirr and Incubator-provisionr in Hadoop Provisioning "
> 
> 
> Diffs
> -
> 
>   docs/en-US/CloudStack_GSoC_Guide.xml 243a0ca 
>   docs/en-US/gsoc-meng.xml PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/11775/diff/
> 
> 
> Testing
> ---
> 
> The added and modified xml files were build with publican successfully.
> 
> 
> Thanks,
> 
> meng han
> 
>

What are the standard commands to setup 4.1 development environment

[Ryan Lei]

CloudStack 4.1 has been released, but I see two "versions" of instructions
in setting up the oss development environment.

(1) From the official website:
http://cloudstack.apache.org/develop/environment.html

# Compile
$ mvn -P developer clean install
# Deploy both the management server and the database
$ mvn -P developer -pl developer,tools/devcloud -Ddeploydb
# Deploy the database again (??, devcloud involved?)
$ mvn -P developer -pl tools/devcloud -Ddeploysvr
# Start the Jetty server
$ mvn -pl :cloud-client-ui jetty:run

(2) From INSTALL.md in the source code:

# Compile
$ mvn clean install -P systemvm,developer
# Deploy both the management server and the database
$ mvn -P developer -pl developer -Ddeploydb
# Export this if using remote debugging
$ export MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=500m -Xdebug
-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"
# Start the Jetty server
$ mvn -pl :cloud-client-ui jetty:run

I'm using a physical host for XCP/XenServer, not devcloud, with CloudStack
+ MySQL running on a separate CentOS VM.
I previously used version (2) to compile git 4.1 branch, but I used
"-DskipTests=true" in the compile step to save time. Is this the right way?
What does the "-P systemvm" actually mean in the command?

Thanks in advance.

- Ryan Lei

Re: What are the standard commands to setup 4.1 development environment

[Prasanna Santhanam]

On Mon, Jun 10, 2013 at 03:52:19PM +0800, Ryan Lei wrote:
> CloudStack 4.1 has been released, but I see two "versions" of instructions
> in setting up the oss development environment.
> 
> (1) From the official website:
> http://cloudstack.apache.org/develop/environment.html
> 
> # Compile
> $ mvn -P developer clean install
> # Deploy both the management server and the database
> $ mvn -P developer -pl developer,tools/devcloud -Ddeploydb
> # Deploy the database again (??, devcloud involved?)
> $ mvn -P developer -pl tools/devcloud -Ddeploysvr
> # Start the Jetty server
> $ mvn -pl :cloud-client-ui jetty:run
> 
> (2) From INSTALL.md in the source code:
> 
> # Compile
> $ mvn clean install -P systemvm,developer
> # Deploy both the management server and the database
> $ mvn -P developer -pl developer -Ddeploydb
> # Export this if using remote debugging
> $ export MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=500m -Xdebug
> -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"
> # Start the Jetty server
> $ mvn -pl :cloud-client-ui jetty:run
> 
> I'm using a physical host for XCP/XenServer, not devcloud, with CloudStack
> + MySQL running on a separate CentOS VM.
> I previously used version (2) to compile git 4.1 branch, but I used
> "-DskipTests=true" in the compile step to save time. Is this the right way?
> What does the "-P systemvm" actually mean in the command?

(2) will work against 4.1. The systemvm profile builds the
systemvm.iso which is used to patch scripts on the systemVMs.  To use
an external host, you can skip deploysvr step and add your hosts from
the UI. In build/replace.properties you will need to specify the
DBHOST to point to your mysql instance. Or else deploydb assumes you
are running the db on localhost.

In (1) the order of steps are wrong. One should  do jetty:run before
doing -Ddeploysvr.

HTH

-- 
Prasanna.,


Powered by BigRock.com

Cloud Usage and API

[CK]

Can someone please provide further information on what the API call:
generateUsageRecords actually does?

I know it generates usage records, but:

1. Does the Usage Server service call the generateUsageRecords API when it
runs at the scheduled time(=usage.stats.job.exec.time) or does the service
do more than that?

2. Does the generateUsageRecords API execute the Usage Server service on
demand to generate the usage records?

3. For what period does it generate the usage records eg.
i. from the last time this API function was called
ii. from the last time the usage server ran

4. If I create a VM and the corresponding ACS events are created in the
Cloud DB, if I then run generateUsageRecords soon after will the usage
records be generated for up to that point?

5. Are there any other documented details available on this API command
other than the API document?

Re: What are the standard commands to setup 4.1 development environment

[Ryan Lei]

Thanks for the quick explanation.
Then should the cloud-install-sys-tmplt script be run before or after the
systemvm profile? Or does it matter at all?


On Mon, Jun 10, 2013 at 4:03 PM, Prasanna Santhanam  wrote:

> On Mon, Jun 10, 2013 at 03:52:19PM +0800, Ryan Lei wrote:
> > CloudStack 4.1 has been released, but I see two "versions" of
> instructions
> > in setting up the oss development environment.
> >
> > (1) From the official website:
> > http://cloudstack.apache.org/develop/environment.html
> >
> > # Compile
> > $ mvn -P developer clean install
> > # Deploy both the management server and the database
> > $ mvn -P developer -pl developer,tools/devcloud -Ddeploydb
> > # Deploy the database again (??, devcloud involved?)
> > $ mvn -P developer -pl tools/devcloud -Ddeploysvr
> > # Start the Jetty server
> > $ mvn -pl :cloud-client-ui jetty:run
> >
> > (2) From INSTALL.md in the source code:
> >
> > # Compile
> > $ mvn clean install -P systemvm,developer
> > # Deploy both the management server and the database
> > $ mvn -P developer -pl developer -Ddeploydb
> > # Export this if using remote debugging
> > $ export MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=500m -Xdebug
> > -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"
> > # Start the Jetty server
> > $ mvn -pl :cloud-client-ui jetty:run
> >
> > I'm using a physical host for XCP/XenServer, not devcloud, with
> CloudStack
> > + MySQL running on a separate CentOS VM.
> > I previously used version (2) to compile git 4.1 branch, but I used
> > "-DskipTests=true" in the compile step to save time. Is this the right
> way?
> > What does the "-P systemvm" actually mean in the command?
>
> (2) will work against 4.1. The systemvm profile builds the
> systemvm.iso which is used to patch scripts on the systemVMs.  To use
> an external host, you can skip deploysvr step and add your hosts from
> the UI. In build/replace.properties you will need to specify the
> DBHOST to point to your mysql instance. Or else deploydb assumes you
> are running the db on localhost.
>
> In (1) the order of steps are wrong. One should  do jetty:run before
> doing -Ddeploysvr.
>
> HTH
>
> --
> Prasanna.,
>
> 
> Powered by BigRock.com
>
>

Re: What are the standard commands to setup 4.1 development environment

[Prasanna Santhanam]

On Mon, Jun 10, 2013 at 04:52:22PM +0800, Ryan Lei wrote:
> Thanks for the quick explanation.
> Then should the cloud-install-sys-tmplt script be run before or after the
> systemvm profile? Or does it matter at all?

The install-sys-tmplt script still will need to be run (before you
launch the management server). That will place the systemVM images
(from which systemvms become systemVMs) on your secondary storage. It
is from these that they will be spawned and then systemv.iso patches
the latest scripts

-- 
Prasanna.,


Powered by BigRock.com

Re: Review Request: generalisation of network code (needed for CLOUDSTACK-1532)

[daan Hoogland]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/10970/
---

(Updated June 10, 2013, 9:20 a.m.)


Review request for cloudstack, Murali Reddy, Hugo Trippaers, and Chiradeep 
Vittal.


Changes
---

getHost() changed to getSchemeSpecificPart() in CiscoVnmcElement


Description
---

converting vlan id to uri to support a broader range of networks in for 
instance vpc gateway connections


Diffs (updated)
-

  api/src/com/cloud/agent/api/to/IpAddressTO.java 82c7d99 
  api/src/com/cloud/agent/api/to/NetworkTO.java 3edd4c0 
  api/src/com/cloud/network/NetworkService.java 405cecd 
  api/src/com/cloud/network/Networks.java 5aede05 
  api/src/com/cloud/network/vpc/PrivateIp.java eb68433 
  api/src/com/cloud/network/vpc/StaticRouteProfile.java 54aa6e4 
  api/src/com/cloud/network/vpc/VpcGateway.java 5d278e9 
  api/src/com/cloud/network/vpc/VpcService.java 7a444c0 
  
api/src/org/apache/cloudstack/api/command/admin/vpc/CreatePrivateGatewayCmd.java
 22dfb9e 
  api/src/org/apache/cloudstack/api/response/PrivateGatewayResponse.java 
c5c7df5 
  core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java 
8b996d1 
  engine/schema/src/com/cloud/network/vpc/VpcGatewayVO.java 7df2dfd 
  
plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BaremetaNetworkGuru.java
 6d14e3f 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
 b897df2 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
 f979cfe 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/OvsVifDriver.java 
eac3248 
  plugins/hypervisors/ovm/src/com/cloud/ovm/hypervisor/OvmResourceBase.java 
a626e31 
  
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
 0a15d4b 
  
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
 7626d12 
  
plugins/network-elements/cisco-vnmc/src/com/cloud/network/element/CiscoVnmcElement.java
 9118bad 
  
plugins/network-elements/cisco-vnmc/test/com/cloud/network/element/CiscoVnmcElementTest.java
 a16733b 
  
plugins/network-elements/f5/src/com/cloud/network/resource/F5BigIpResource.java 
1733712 
  
plugins/network-elements/juniper-srx/src/com/cloud/network/resource/JuniperSrxResource.java
 fd065d5 
  
plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
 c0d4599 
  
plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsTunnelManagerImpl.java
 b1ecaac 
  server/src/com/cloud/api/ApiResponseHelper.java cf79ff8 
  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 59e70cf 
  server/src/com/cloud/network/ExternalFirewallDeviceManagerImpl.java 9d24e47 
  server/src/com/cloud/network/ExternalLoadBalancerDeviceManagerImpl.java 
04f9682 
  server/src/com/cloud/network/ExternalLoadBalancerUsageManagerImpl.java 
2c8031c 
  server/src/com/cloud/network/NetworkManager.java 8627251 
  server/src/com/cloud/network/NetworkManagerImpl.java b92ef4b 
  server/src/com/cloud/network/NetworkServiceImpl.java 9899284 
  server/src/com/cloud/network/guru/DirectPodBasedNetworkGuru.java cf27986 
  server/src/com/cloud/network/guru/PrivateNetworkGuru.java 2e266e7 
  server/src/com/cloud/network/guru/PublicNetworkGuru.java a83cdb3 
  
server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java 
9992b7c 
  server/src/com/cloud/network/vpc/PrivateGatewayProfile.java d6480cd 
  server/src/com/cloud/network/vpc/PrivateIpAddress.java 2f3cf53 
  server/src/com/cloud/network/vpc/VpcManagerImpl.java 380a95e 
  server/test/com/cloud/network/CreatePrivateNetworkTest.java PRE-CREATION 
  server/test/com/cloud/network/MockNetworkManagerImpl.java 7ab322b 
  server/test/com/cloud/vpc/MockNetworkManagerImpl.java d46be7c 
  server/test/com/cloud/vpc/MockVpcManagerImpl.java 921321f 
  setup/db/db/schema-410to420.sql 196706f 

Diff: https://reviews.apache.org/r/10970/diff/


Testing
---

the NetworkTO is tested to accept uris with several initial states.
createPrivateNetwork in NetworkServiceImpl is tested (to accept only vlan or 
lswitch based networks for now)
test code that used to use 'vlan://#' now uses 'vlan:#'


Thanks,

daan Hoogland

VMWare systemVM template

[Abhinandan Prateek]

Rohit,

   I have the new Debian 7 system VM template and related vmx file for
VMWare.
 
I am not sure how much of VMWare fusion stuff it can be automated via
virtual box ?

-abhi

Re: Review Request: Automation: Add testcases for Affinity/Anti-Affinity Rules

[Girish Shilamkar]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11067/
---

(Updated June 10, 2013, 10:03 a.m.)


Review request for cloudstack, Prachi Damle, Prasanna Santhanam, and sangeetha 
hariharan.


Changes
---

Fixed the patch by removing trailing whitespaces


Description
---

Add testcases for Affinity/Anti-Affinity Rules


This addresses bug CLOUDSTACK-2254.


Diffs (updated)
-

  test/integration/component/test_affinity_groups.py PRE-CREATION 

Diff: https://reviews.apache.org/r/11067/diff/


Testing
---

The tests which are not skipped are working.


Thanks,

Girish Shilamkar

VPC and shared networks

[Prasanna Santhanam]

Can we create shared networks inside a VPC? If yes - why does the UI
filter out the network offerings in the VPC dialog on listing networks
using forvpc=true & guestiptype=Isolated?

If no - we can get rid of a test suite - TestVMLifeCycleSharedNwVPC.
But was it supported before and dropped recently? I was able to create
a networkoffering with vpc=true and guestIpType=Shared, but the VPC
network creation fails with 

"""
Network offering can't be used for VPC networks
"""

-- 
Prasanna.,


Powered by BigRock.com

Re: VPC and shared networks

[Prasanna Santhanam]

On Mon, Jun 10, 2013 at 03:39:08PM +0530, Prasanna Santhanam wrote:
> Can we create shared networks inside a VPC? If yes - why does the UI
> filter out the network offerings in the VPC dialog on listing networks
> using forvpc=true & guestiptype=Isolated?
> 
> If no - we can get rid of a test suite - TestVMLifeCycleSharedNwVPC.
> But was it supported before and dropped recently? I was able to create
> a networkoffering with vpc=true and guestIpType=Shared, but the VPC
> network creation fails with 
> 
> """
> Network offering can't be used for VPC networks
> """
> 

Filed: CLOUDSTACK-2920


Powered by BigRock.com

Re: Runtime Error: "could not find systemvmiso" in master branch

[Nguyen Anh Tu]

@Ke4qqq: Okie I'll note to document it :-)


2013/6/10 Vijay Venkatachalam 

> Glad to know it is was useful!
>
> Thanks,
> Vijay V.
>
> > -Original Message-
> > From: Nguyen Anh Tu [mailto:ng.t...@gmail.com]
> > Sent: Saturday, June 08, 2013 3:57 PM
> > To: cloudstack-...@incubator.apache.org
> > Subject: Re: Runtime Error: "could not find systemvmiso" in master branch
> >
> > Thanks Vijay. It helps me alot. Pheww. It should be noted! Someone
> doesn't
> > know about clear tags
> >
> >
> > 2012/10/29 Vijay Venkatachalam 
> >
> > > Identified the reason for the problem: The host did not contain
> > > system-vm.iso vhd-util etc. Basically, the patch files were not
> > > applied. There was a CS host tag that erroneously marked the XenServer
> > > was already patched even though it was not patched. Hence remove
> > > /re-add of the host did not patch the files.
> > >
> > > The following sequence of steps should help fix the problem.
> > > 1. Remove the host
> > > 2. Cleanup the host as usual (clear vbd and any vms) 3. Remove cs tags
> > > of the host using the following command.
> > >   xe host-param-clear uuid= param-name=tags 4. Add the host
> > > back
> > >
> > > Hope the sequence of steps will help someone in the future.
> > >
> > > > -Original Message-
> > > > From: Rohit Yadav [mailto:rohit.ya...@citrix.com]
> > > > Sent: Friday, October 26, 2012 5:07 PM
> > > > To: cloudstack-...@incubator.apache.org
> > > > Subject: Re: Runtime Error: "could not find systemvmiso" in master
> > > > branch
> > > >
> > > >
> > > > On 26-Oct-2012, at 4:22 PM, Vijay Venkatachalam
> > > >  wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I am trying to setup a zone out of master and I get  "can not find
> > > > systemvmiso" repeatedly.
> > > > > No system vms are created in the xenserver host.
> > > > > Anyone else facing the same problem?
> > > > >
> > > > > Steps
> > > > > *
> > > > > 0. copy vhd-util to scripts/vm/hypervisor/xenserver/vhd-util
> > > > > 1. "mvn -P deps"  && "mvn install"
> > > >
> > > > Assuming you're doing this on asf master, mvn -P deps is no longer
> > > required
> > > > (this was only for ant).
> > > > start afresh; mvn clean install and other commands;
> > > >
> > > >
> > > > > 2.  mvn -P developer -pl developer -Ddeploydb 3.export
> > > > > MAVEN_OPTS="-Xmx1024m -Xdebug -
> > > > Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"
> > > > > 4. mvn -pl :cloud-client-ui jetty:run 5. Create an advanced zone
> > > > >
> > > > >
> > > > >
> > > > > Extract from vmops.log
> > > > > 
> > > > >
> > > > > 2012-10-26 14:55:23,775 DEBUG [xen.resource.CitrixResourceBase]
> > > > > (DirectAgent-15:null) VBD 93e0dd7a-0630-6e82-a12a-d9a65dc8fb25
> > created
> > > > > for Vol[2|ROOT|1e8db6aa-cb60-40ec-8162-6d50907c900b|2147483648]
> > > > > 2012-10-26 14:55:24,041 WARN  [xen.resource.CitrixResourceBase]
> > > > > (DirectAgent-15:null) Catch Exception: class
> > > > > com.cloud.utils.exception.CloudRuntimeException due to
> > > > > com.cloud.utils.exception.CloudRuntimeException: can not find
> > > > > systemvmiso
> > > > > com.cloud.utils.exception.CloudRuntimeException: can not find
> > > > systemvmiso
> > > > >at
> > > >
> > com.cloud.hypervisor.xen.resource.CitrixResourceBase.createPatchVbd(Citri
> > > > xResourceBase.java:1140)
> > > > >at
> > > >
> > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResou
> > > > rceBase.java:1285)
> > > > >at
> > > >
> > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(Citr
> > > > ixResourceBase.java:497)
> > > > >at
> > > >
> > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(
> > > > XenServer56Resource.java:73)
> > > > >at
> > > >
> > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache
> > > > .java:191)
> > > > >at
> > > >
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> > > > >at
> > > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> > > > >at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> > > > >at
> > > >
> > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.ac
> > > > cess$201(ScheduledThreadPoolExecutor.java:178)
> > > > >at
> > > >
> > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.ru
> > > > n(ScheduledThreadPoolExecutor.java:292)
> > > > >at
> > > >
> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav
> > > > a:1110)
> > > > >at
> > > >
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja
> > > > va:603)
> > > > >at java.lang.Thread.run(Thread.java:722)
> > > > > 2012-10-26 14:55:24,042 WARN  [xen.resource.CitrixResourceBase]
> > > > > (DirectAgent-15:null) Unable to start v-2-VM due to
> > > > > com.cloud.utils.exception.CloudRuntimeException: can not find
> > > > > systemvmiso
> > > >
> > > > 

[OFFLINE] 6/12 and 6/13

[Prasanna Santhanam]

Will be away mid-week and won't be able to make it to the meeting
and/or check emails.

Thanks,

-- 
Prasanna.,


Powered by BigRock.com

Re: Review Request: (CLOUDSTACK-2707) use executeBatch instead of persist when Usage Server createNetworkHelperEntry

[ASF Subversion and Git Services]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11461/#review21649
---


Commit 76ce304411259dc4a29e0e070de829b79b46efe2 in branch refs/heads/master 
from Wei Zhou
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=76ce304 ]

CLOUDSTACK-2707: use executeBatch instead of persist in Usage Server


- ASF Subversion and Git Services


On May 28, 2013, 7:42 a.m., Wei Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11461/
> ---
> 
> (Updated May 28, 2013, 7:42 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Description
> ---
> 
> use executeBatch instead of persist can reduce the time spent on inserting 
> records into database.
> 
> 
> This addresses bug CLOUDSTACK-2707.
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/usage/dao/UsageNetworkDao.java 0f7c771 
>   engine/schema/src/com/cloud/usage/dao/UsageNetworkDaoImpl.java d64fd80 
>   usage/src/com/cloud/usage/UsageManagerImpl.java 16fe67b 
> 
> Diff: https://reviews.apache.org/r/11461/diff/
> 
> 
> Testing
> ---
> 
> Testing ok.
> 
> 
> Thanks,
> 
> Wei Zhou
> 
>

RE: Contributing as a non-committer

[Paul Angus]

Thanks Seb,
I've bought pro git as extra reading too.

Now I'm trying to setup my dev environment, the 'Setting Up an Apache 
CloudStack Development Environment' says
"Most Apache CloudStack developers use Eclipse as their primary IDE. CloudStack 
source code already includes Eclipse .project file in each project folder"

But I can't find the .project file in the CloudStack directory...?


Regards,

Paul Angus
S: +44 20 3603 0540 | M: +447711418784
paul.an...@shapeblue.com

-Original Message-
From: Sebastien Goasguen [mailto:run...@gmail.com]
Sent: 09 June 2013 08:46
To: dev@cloudstack.apache.org
Subject: Re: Contributing as a non-committer

Paul, I fixed the wiki link.

Thanks for reporting it, note that if you have a wiki account you can edit the 
page yourself and edit it.

Let us know if the instructions are not clear. I also have a screencast on git 
basics for non-committers:
http://www.youtube.com/watch?v=3c5JIW4onGk&list=PLb899uhkHRoZCRE00h_9CRgUSiHEgFDbC&index=5



-sebastien

On Jun 9, 2013, at 2:28 AM, Paul Angus  wrote:

> Hi Joe,
>
> It's on
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Home
> under 'Developer Docs and Resources'
>
>
>
> Regards,
>
> Paul Angus
> S: +44 20 3603 0540 | M: +447711418784 paul.an...@shapeblue.com
>
> -Original Message-
> From: Joe Brockmeier [mailto:j...@zonker.net]
> Sent: 08 June 2013 23:04
> To: dev@cloudstack.apache.org
> Subject: Re: Contributing as a non-committer
>
> Paul, where are you seeing that link?
>
> On Fri, Jun 7, 2013, at 03:55 PM, Paul Angus wrote:
>> Guys,
>>
>> I'm just trying to get up to speed with how I can contribute more
>> (starting with a minor doc fix) but the link
>> http://cloudstack.apache.org/develop/non-contributors.html is broken.
>>
>> Can it be fixed pls (does it count as a bug that I need to report).
>> Is there an alternate link for the time being?
>>
>>
>> Regards
>>
>> Paul Angus
>> Senior Consultant / Cloud Architect
>>
>> [cid:image002.png@01CE1071.C6CC9C10]
>>
>> S: +44 20 3603 0540 | M:
>> +447711418784
>> paul.an...@shapeblue.com |
>> www.shapeblue.com | Twitter:@shapeblue
>> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>>
>> ShapeBlue are proud to be sponsoring CloudStack Collaboration
>> Conference NA
>> [https://cwiki.apache.org/confluence/download/attachments/30760149/Cl
>> o
>> udStack+Collaboration+Conference+Banner+v2+Blue+Background+Only.jpg?v
>> udStack+Collaboration+Conference+Banner+v2+Blue+Background+e
>> rsion=3&modificationDate=1367282397297]> e
>> t/>
>>
>> Apache CloudStack Bootcamp training courses
>> 19/20 June,
>> London
>> 22/23 June, Santa Clara
>> CA
>> 10/11 July, Bangalore,
>> India
>> 21/22 August,
>> London
>>
>> This email and any attachments to it may be confidential and are
>> intended solely for the use of the individual to whom it is addressed.
>> Any views or opinions expressed are solely those of the author and do
>> not necessarily represent those of Shape Blue Ltd or related
>> companies. If you are not the intended recipient of this email, you
>> must neither take any action based upon its contents, nor copy or
>> show it to anyone. Please contact the sender if you believe you have 
>> received this email in error.
>> Shape Blue Ltd is a company incorporated in England & Wales.
>> ShapeBlue Services India LLP is operated under license from Shape Blue Ltd.
>> ShapeBlue is a registered trademark.
>
>
> Best,
>
> jzb
> --
> Joe Brockmeier
> j...@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
>
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is operated 
> under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>


This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or sh

Re: Contributing as a non-committer

[Sebastien Goasguen]

On Jun 10, 2013, at 9:40 AM, Paul Angus  wrote:

> Thanks Seb,
> I've bought pro git as extra reading too.
> 
> Now I'm trying to setup my dev environment, the 'Setting Up an Apache 
> CloudStack Development Environment' says
> "Most Apache CloudStack developers use Eclipse as their primary IDE. 
> CloudStack source code already includes Eclipse .project file in each project 
> folder"
> 
> But I can't find the .project file in the CloudStack directory…?

Forget about eclipse for now :) just use vi :)



> 
> 
> Regards,
> 
> Paul Angus
> S: +44 20 3603 0540 | M: +447711418784
> paul.an...@shapeblue.com
> 
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: 09 June 2013 08:46
> To: dev@cloudstack.apache.org
> Subject: Re: Contributing as a non-committer
> 
> Paul, I fixed the wiki link.
> 
> Thanks for reporting it, note that if you have a wiki account you can edit 
> the page yourself and edit it.
> 
> Let us know if the instructions are not clear. I also have a screencast on 
> git basics for non-committers:
> http://www.youtube.com/watch?v=3c5JIW4onGk&list=PLb899uhkHRoZCRE00h_9CRgUSiHEgFDbC&index=5
> 
> 
> 
> -sebastien
> 
> On Jun 9, 2013, at 2:28 AM, Paul Angus  wrote:
> 
>> Hi Joe,
>> 
>> It's on
>> 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Home
>> under 'Developer Docs and Resources'
>> 
>> 
>> 
>> Regards,
>> 
>> Paul Angus
>> S: +44 20 3603 0540 | M: +447711418784 paul.an...@shapeblue.com
>> 
>> -Original Message-
>> From: Joe Brockmeier [mailto:j...@zonker.net]
>> Sent: 08 June 2013 23:04
>> To: dev@cloudstack.apache.org
>> Subject: Re: Contributing as a non-committer
>> 
>> Paul, where are you seeing that link?
>> 
>> On Fri, Jun 7, 2013, at 03:55 PM, Paul Angus wrote:
>>> Guys,
>>> 
>>> I'm just trying to get up to speed with how I can contribute more
>>> (starting with a minor doc fix) but the link
>>> http://cloudstack.apache.org/develop/non-contributors.html is broken.
>>> 
>>> Can it be fixed pls (does it count as a bug that I need to report).
>>> Is there an alternate link for the time being?
>>> 
>>> 
>>> Regards
>>> 
>>> Paul Angus
>>> Senior Consultant / Cloud Architect
>>> 
>>> [cid:image002.png@01CE1071.C6CC9C10]
>>> 
>>> S: +44 20 3603 0540 | M:
>>> +447711418784
>>> paul.an...@shapeblue.com |
>>> www.shapeblue.com | Twitter:@shapeblue
>>> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>>> 
>>> ShapeBlue are proud to be sponsoring CloudStack Collaboration
>>> Conference NA
>>> [https://cwiki.apache.org/confluence/download/attachments/30760149/Cl
>>> o
>>> udStack+Collaboration+Conference+Banner+v2+Blue+Background+Only.jpg?v
>>> udStack+Collaboration+Conference+Banner+v2+Blue+Background+e
>>> rsion=3&modificationDate=1367282397297]>> e
>>> t/>
>>> 
>>> Apache CloudStack Bootcamp training courses
>>> 19/20 June,
>>> London
>>> 22/23 June, Santa Clara
>>> CA
>>> 10/11 July, Bangalore,
>>> India
>>> 21/22 August,
>>> London
>>> 
>>> This email and any attachments to it may be confidential and are
>>> intended solely for the use of the individual to whom it is addressed.
>>> Any views or opinions expressed are solely those of the author and do
>>> not necessarily represent those of Shape Blue Ltd or related
>>> companies. If you are not the intended recipient of this email, you
>>> must neither take any action based upon its contents, nor copy or
>>> show it to anyone. Please contact the sender if you believe you have 
>>> received this email in error.
>>> Shape Blue Ltd is a company incorporated in England & Wales.
>>> ShapeBlue Services India LLP is operated under license from Shape Blue Ltd.
>>> ShapeBlue is a registered trademark.
>> 
>> 
>> Best,
>> 
>> jzb
>> --
>> Joe Brockmeier
>> j...@zonker.net
>> Twitter: @jzb
>> http://www.dissociatedpress.net/
>> 
>> This email and any attachments to it may be confidential and are intended 
>> solely for the use of the individual to whom it is addressed. Any views or 
>> opinions expressed are solely those of the author and do not necessarily 
>> represent those of Shape Blue Ltd or related companies. If you are not the 
>> intended recipient of this email, you must neither take any action based 
>> upon its contents, nor copy or show it to anyone. Please contact the sender 
>> if you believe you have received this email in error. Shape Blue Ltd is a 
>> company incorporated in England & Wales. ShapeBlue Services India LLP is 
>> operated under license from Shape Blue Ltd. ShapeBlue is a registered 
>> trademark.
>> 
> 
> 
> This email and any attachments to it may be confidential and are intended 
> solely for the use of

[GSOC] NullPointerException when deployVM using GRE isolation method. Help me!

[Nguyen Anh Tu]

Hi forks,

I'm trying OVS tunnel with XCP 1.6 and get error NullPointerException when
executing deployVM.

I found this error starting from the below code.

*NetworkManagerImpl.java*

*NicProfile profile = guru.allocate(network, requested, vm); (1)*
if (isDefaultNic != null) {
profile.setDefaultNic(
isDefaultNic);
}

*ExtenalGuestNetworkGuru.java*

@Override
   * public NicProfile allocate(Network config, NicProfile nic,
VirtualMachineProfile vm) throws
InsufficientVirtualNetworkCapcityException,
InsufficientAddressCapacityException* {

if
(_networkModel.networkIsConfiguredForExternalNetworking(config.getDataCenterId(),
config.getId()) && nic != null && nic.getRequestedIpv4() != null) {
throw new CloudRuntimeException("Does not support custom ip
allocation at this time: " + nic);
}

NicProfile profile = super.allocate(config, nic, vm);

*boolean _isEnabled =
Boolean.parseBoolean(_configDao.getValue(Config.OvsTunnelNetwork.key()));
(2)
if (_isEnabled) {
return null;
}*

if
(_networkModel.networkIsConfiguredForExternalNetworking(config.getDataCenterId(),
config.getId())) {
profile.setStrategy(ReservationStrategy.Start);
/* We won't clear IP address, because router may set gateway as
it IP, and it would be updated properly later */
//profile.setIp4Address(null);
profile.setGateway(null);
profile.setNetmask(null);
}

return profile;
}*

*
The return from (1) is NULL, because at (2) *sdn.ovs.controller* set to
true. So profile = NULL and then we get NullPointerException error in the
next step.

This error prevents me to deployVM using GRE isolation method. If I set *
sdn.ovs.controller* = false, no error anymore but can't using GRE.

How can I fix this? Thanks for any help.

-- 

N.g.U.y.e.N.A.n.H.t.U

Re: Handling Self Signed Certs

[Will Stevens]

When I went looking in CS for the HTTP clients that were already available,
I found the one that Soheil is using as well as the new apache one.  I am
using the new apache one because I was assuming it was going to be the
preferred one going forward.

I will clean up my wrapper and make it available in the cloud-utils
package.

The only question now is if the 'allow unverified certs' should be a global
setting or a per device setting.  I tend to think that it should be per
device because that isolates the functionality a little better.  However,
by creating a global setting it makes the concept more accessible to other
developers and centralizes the setting for the user so they only have to
specify the setting in one place and all devices which have been written to
conform to that setting will allow unverified certs.

I think there are pros and cons to both approaches.  I am fine to implement
my code either way, so more feedback on this choice would be appreciated.

ws


On Thu, Jun 6, 2013 at 6:40 PM, Kelven Yang  wrote:

> Will,
>
> We don't have a common HTTPS client yet, as far as I know, different
> module developers probably are using slight different way to deal with
> self-signed certificate, it is a good time to consolidate it now if it is
> not too late. You may make the facility available in cloud-utils package
> and encourage adoption from these modules.
>
> Some modules, i.e., download manager, API module to hypervisor hosts have
> the similar situation.
>
>
> Kelven
>
> On 6/6/13 2:33 PM, "Soheil Eizadi"  wrote:
>
> >What is missing is a facility to import a certificate into the store. If
> >it was available you could use it for self signed CERTS. Ideally it
> >should be part of GUI to add devices.
> >
> >I am implementing a similar HTTP Client. You are using DefaultHttpClient
> >so it is based on the newer Apache libraries. The ones I found in
> >CloudStack were older Commons HttpClient which was EOL.
> >
> >In my case I planned to wrap the Client as you have for development and
> >for production have an API to import a certificate for SSL into the
> >Certificate Store.
> >
> >I would call to AuthScope(host, 443) to limit access to only the specific
> >host and port.
> >
> >-Soheil
> >
> >From: williamstev...@gmail.com [williamstev...@gmail.com] on behalf of
> >Will Stevens [wstev...@cloudops.com]
> >Sent: Thursday, June 06, 2013 1:08 PM
> >To: dev@cloudstack.apache.org
> >Subject: Re: Handling Self Signed Certs
> >
> >Hey Kelven,
> >I am using the same https client libraries as elsewhere in Cloudstack
> >(well
> >one of them because there is more than one version of http client libs
> >currently available in CS).
> >
> >I am using this client:
> >import org.apache.http.impl.client.DefaultHttpClient;
> >
> >I initialize it like this:
> >_httpclient = new DefaultHttpClient();
> >
> >Then if self signed certs are allowed, I currently have a utility library
> >in my plugin which allows me to do this:
> >// Allows you to connect via SSL using unverified certs
> >_httpclient = HttpClientWrapper.wrapClient(_httpclient);
> >
> >Is there a class that already exists in CloudStack which I can use to wrap
> >my client to enable unverified certs, or will I need to add one?  Should I
> >create a global setting such as 'Allow unverified SSL certs' which would
> >be
> >checked by the code to determine if the http client should be wrapped?
> >
> >Thx, Will
> >
> >
> >On Thu, Jun 6, 2013 at 2:43 PM, Kelven Yang 
> >wrote:
> >
> >> Will,
> >>
> >> We have several other integrated components that have the similar
> >> situation, it makes sense to consolidate the HTTPS client we used across
> >> CloudStack and have a global configuration to deal with self-signed
> >> certificate for all in testing or POC.
> >>
> >> To help testing/POC process to be smooth, we may allow self-signed
> >> certificate by default(which is the current behave), security sensitive
> >> customers should disallow self-signed certificates in their production
> >> environment.
> >>
> >> Kelven
> >>
> >> On 6/6/13 9:08 AM, "Will Stevens"  wrote:
> >>
> >> >Hey All,
> >> >I am building integration between CS and an external Palo Alto Firewall
> >> >device.  The API calls to the PA device are done over HTTPS.  In some
> >> >cases
> >> >(like testing or a POC), it makes sense to use a self signed cert for
> >>this
> >> >connection.
> >> >
> >> >Currently I have a little http client wrapper which allows the use of a
> >> >self signed cert.  Obviously, I do not want to use the wrapper when a
> >>real
> >> >cert is used.
> >> >
> >> >What I am thinking of doing is adding a checkbox on the 'Add Palo Alto
> >> >Device' configuration overlay with an option for 'Using a self signed
> >> >cert'.  If this checkbox is checked, then the http client wrapper is
> >>used
> >> >so the self signed cert will not throw errors, if it is not checked,
> >>the
> >> >the http client wrapper will not be used and errors will be t

buildbot success in ASF Buildbot on cloudstack-site-staging

[buildbot]

The Buildbot has detected a restored build on builder cloudstack-site-staging 
while building ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/cloudstack-site-staging/builds/168

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: bb-cms-slave

Build Reason: scheduler
Build Source Stamp: [branch cloudstack/site] 1491515
Blamelist: jzb

Build succeeded!

sincerely,
 -The Buildbot

Re: Review Request: Cloudstack-2511 Multiple_Ip_Ranges: Adding guest ip range in subset/superset to existing CIDR is allowed https://issues.apache.org/jira/browse/CLOUDSTACK-2511, Cloudstack-2651 [Sha

[Koushik Das]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11600/#review21654
---


Don't combine multiple fixes in a single commit. Keep it simple -> 1 commit = 1 
bug fix

- Koushik Das


On June 4, 2013, 2:51 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11600/
> ---
> 
> (Updated June 4, 2013, 2:51 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> Cloudstack-2511 Multiple_Ip_Ranges: Adding guest ip range in subset/superset 
> to existing CIDR is allowed
> https://issues.apache.org/jira/browse/CLOUDSTACK-2511
> 
> Cloudstack-2651 [Shared n/w]Add IP range should not ask for gateway and 
> netmask while adding the ip range to the existing subnet.
> https://issues.apache.org/jira/browse/CLOUDSTACK-2651
> 
> 
> This addresses bugs Cloudstack-2511 and Cloudstack-2651.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 59e70cf 
>   server/test/com/cloud/configuration/ValidateIpRangeTest.java 7681667 
>   utils/src/com/cloud/utils/net/NetUtils.java 8c094c8 
> 
> Diff: https://reviews.apache.org/r/11600/diff/
> 
> 
> Testing
> ---
> 
> Tested with master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Handling Self Signed Certs

[Chiradeep Vittal]

+1 to per-device

On 6/10/13 9:04 AM, "Will Stevens"  wrote:

>When I went looking in CS for the HTTP clients that were already
>available,
>I found the one that Soheil is using as well as the new apache one.  I am
>using the new apache one because I was assuming it was going to be the
>preferred one going forward.
>
>I will clean up my wrapper and make it available in the cloud-utils
>package.
>
>The only question now is if the 'allow unverified certs' should be a
>global
>setting or a per device setting.  I tend to think that it should be per
>device because that isolates the functionality a little better.  However,
>by creating a global setting it makes the concept more accessible to other
>developers and centralizes the setting for the user so they only have to
>specify the setting in one place and all devices which have been written
>to
>conform to that setting will allow unverified certs.
>
>I think there are pros and cons to both approaches.  I am fine to
>implement
>my code either way, so more feedback on this choice would be appreciated.
>
>ws
>
>
>On Thu, Jun 6, 2013 at 6:40 PM, Kelven Yang 
>wrote:
>
>> Will,
>>
>> We don't have a common HTTPS client yet, as far as I know, different
>> module developers probably are using slight different way to deal with
>> self-signed certificate, it is a good time to consolidate it now if it
>>is
>> not too late. You may make the facility available in cloud-utils package
>> and encourage adoption from these modules.
>>
>> Some modules, i.e., download manager, API module to hypervisor hosts
>>have
>> the similar situation.
>>
>>
>> Kelven
>>
>> On 6/6/13 2:33 PM, "Soheil Eizadi"  wrote:
>>
>> >What is missing is a facility to import a certificate into the store.
>>If
>> >it was available you could use it for self signed CERTS. Ideally it
>> >should be part of GUI to add devices.
>> >
>> >I am implementing a similar HTTP Client. You are using
>>DefaultHttpClient
>> >so it is based on the newer Apache libraries. The ones I found in
>> >CloudStack were older Commons HttpClient which was EOL.
>> >
>> >In my case I planned to wrap the Client as you have for development and
>> >for production have an API to import a certificate for SSL into the
>> >Certificate Store.
>> >
>> >I would call to AuthScope(host, 443) to limit access to only the
>>specific
>> >host and port.
>> >
>> >-Soheil
>> >
>> >From: williamstev...@gmail.com [williamstev...@gmail.com] on behalf of
>> >Will Stevens [wstev...@cloudops.com]
>> >Sent: Thursday, June 06, 2013 1:08 PM
>> >To: dev@cloudstack.apache.org
>> >Subject: Re: Handling Self Signed Certs
>> >
>> >Hey Kelven,
>> >I am using the same https client libraries as elsewhere in Cloudstack
>> >(well
>> >one of them because there is more than one version of http client libs
>> >currently available in CS).
>> >
>> >I am using this client:
>> >import org.apache.http.impl.client.DefaultHttpClient;
>> >
>> >I initialize it like this:
>> >_httpclient = new DefaultHttpClient();
>> >
>> >Then if self signed certs are allowed, I currently have a utility
>>library
>> >in my plugin which allows me to do this:
>> >// Allows you to connect via SSL using unverified certs
>> >_httpclient = HttpClientWrapper.wrapClient(_httpclient);
>> >
>> >Is there a class that already exists in CloudStack which I can use to
>>wrap
>> >my client to enable unverified certs, or will I need to add one?
>>Should I
>> >create a global setting such as 'Allow unverified SSL certs' which
>>would
>> >be
>> >checked by the code to determine if the http client should be wrapped?
>> >
>> >Thx, Will
>> >
>> >
>> >On Thu, Jun 6, 2013 at 2:43 PM, Kelven Yang 
>> >wrote:
>> >
>> >> Will,
>> >>
>> >> We have several other integrated components that have the similar
>> >> situation, it makes sense to consolidate the HTTPS client we used
>>across
>> >> CloudStack and have a global configuration to deal with self-signed
>> >> certificate for all in testing or POC.
>> >>
>> >> To help testing/POC process to be smooth, we may allow self-signed
>> >> certificate by default(which is the current behave), security
>>sensitive
>> >> customers should disallow self-signed certificates in their
>>production
>> >> environment.
>> >>
>> >> Kelven
>> >>
>> >> On 6/6/13 9:08 AM, "Will Stevens"  wrote:
>> >>
>> >> >Hey All,
>> >> >I am building integration between CS and an external Palo Alto
>>Firewall
>> >> >device.  The API calls to the PA device are done over HTTPS.  In
>>some
>> >> >cases
>> >> >(like testing or a POC), it makes sense to use a self signed cert
>>for
>> >>this
>> >> >connection.
>> >> >
>> >> >Currently I have a little http client wrapper which allows the use
>>of a
>> >> >self signed cert.  Obviously, I do not want to use the wrapper when
>>a
>> >>real
>> >> >cert is used.
>> >> >
>> >> >What I am thinking of doing is adding a checkbox on the 'Add Palo
>>Alto
>> >> >Device' configuration overlay with an option for 'Using a self
>>signed
>> >> >

Re: VPC and shared networks

[Chiradeep Vittal]

Not sure what the test case is trying to achieve, but you can have a VM
with a nic on a VPC subnet and another nic on a shared subnet.

On 6/10/13 3:18 AM, "Prasanna Santhanam"  wrote:

>On Mon, Jun 10, 2013 at 03:39:08PM +0530, Prasanna Santhanam wrote:
>> Can we create shared networks inside a VPC? If yes - why does the UI
>> filter out the network offerings in the VPC dialog on listing networks
>> using forvpc=true & guestiptype=Isolated?
>> 
>> If no - we can get rid of a test suite - TestVMLifeCycleSharedNwVPC.
>> But was it supported before and dropped recently? I was able to create
>> a networkoffering with vpc=true and guestIpType=Shared, but the VPC
>> network creation fails with
>> 
>> """
>> Network offering can't be used for VPC networks
>> """
>> 
>
>Filed: CLOUDSTACK-2920
>
>
>Powered by BigRock.com
>

Re: Handling Self Signed Certs

[Kelven Yang]

Will,

Thanks for the effort in getting a common wrapper into utils package.

As for the policy decision(whether or not to make a global flag or a
per-device option), both have pros and cons, we can wait and see the
feedbacks from others in the community.

Considering the legacy installations and the fact that we allow
self-signed certificates by default in existing releases, I personally
think that having a global flag is a much economic way to get this feature
in without too much disruptions. Of course, to have fine-control of it, we
can always allow per-device overridden policy as well.

Kelven


On 6/10/13 9:04 AM, "Will Stevens"  wrote:

>When I went looking in CS for the HTTP clients that were already
>available,
>I found the one that Soheil is using as well as the new apache one.  I am
>using the new apache one because I was assuming it was going to be the
>preferred one going forward.
>
>I will clean up my wrapper and make it available in the cloud-utils
>package.
>
>The only question now is if the 'allow unverified certs' should be a
>global
>setting or a per device setting.  I tend to think that it should be per
>device because that isolates the functionality a little better.  However,
>by creating a global setting it makes the concept more accessible to other
>developers and centralizes the setting for the user so they only have to
>specify the setting in one place and all devices which have been written
>to
>conform to that setting will allow unverified certs.
>
>I think there are pros and cons to both approaches.  I am fine to
>implement
>my code either way, so more feedback on this choice would be appreciated.
>
>ws
>
>
>On Thu, Jun 6, 2013 at 6:40 PM, Kelven Yang 
>wrote:
>
>> Will,
>>
>> We don't have a common HTTPS client yet, as far as I know, different
>> module developers probably are using slight different way to deal with
>> self-signed certificate, it is a good time to consolidate it now if it
>>is
>> not too late. You may make the facility available in cloud-utils package
>> and encourage adoption from these modules.
>>
>> Some modules, i.e., download manager, API module to hypervisor hosts
>>have
>> the similar situation.
>>
>>
>> Kelven
>>
>> On 6/6/13 2:33 PM, "Soheil Eizadi"  wrote:
>>
>> >What is missing is a facility to import a certificate into the store.
>>If
>> >it was available you could use it for self signed CERTS. Ideally it
>> >should be part of GUI to add devices.
>> >
>> >I am implementing a similar HTTP Client. You are using
>>DefaultHttpClient
>> >so it is based on the newer Apache libraries. The ones I found in
>> >CloudStack were older Commons HttpClient which was EOL.
>> >
>> >In my case I planned to wrap the Client as you have for development and
>> >for production have an API to import a certificate for SSL into the
>> >Certificate Store.
>> >
>> >I would call to AuthScope(host, 443) to limit access to only the
>>specific
>> >host and port.
>> >
>> >-Soheil
>> >
>> >From: williamstev...@gmail.com [williamstev...@gmail.com] on behalf of
>> >Will Stevens [wstev...@cloudops.com]
>> >Sent: Thursday, June 06, 2013 1:08 PM
>> >To: dev@cloudstack.apache.org
>> >Subject: Re: Handling Self Signed Certs
>> >
>> >Hey Kelven,
>> >I am using the same https client libraries as elsewhere in Cloudstack
>> >(well
>> >one of them because there is more than one version of http client libs
>> >currently available in CS).
>> >
>> >I am using this client:
>> >import org.apache.http.impl.client.DefaultHttpClient;
>> >
>> >I initialize it like this:
>> >_httpclient = new DefaultHttpClient();
>> >
>> >Then if self signed certs are allowed, I currently have a utility
>>library
>> >in my plugin which allows me to do this:
>> >// Allows you to connect via SSL using unverified certs
>> >_httpclient = HttpClientWrapper.wrapClient(_httpclient);
>> >
>> >Is there a class that already exists in CloudStack which I can use to
>>wrap
>> >my client to enable unverified certs, or will I need to add one?
>>Should I
>> >create a global setting such as 'Allow unverified SSL certs' which
>>would
>> >be
>> >checked by the code to determine if the http client should be wrapped?
>> >
>> >Thx, Will
>> >
>> >
>> >On Thu, Jun 6, 2013 at 2:43 PM, Kelven Yang 
>> >wrote:
>> >
>> >> Will,
>> >>
>> >> We have several other integrated components that have the similar
>> >> situation, it makes sense to consolidate the HTTPS client we used
>>across
>> >> CloudStack and have a global configuration to deal with self-signed
>> >> certificate for all in testing or POC.
>> >>
>> >> To help testing/POC process to be smooth, we may allow self-signed
>> >> certificate by default(which is the current behave), security
>>sensitive
>> >> customers should disallow self-signed certificates in their
>>production
>> >> environment.
>> >>
>> >> Kelven
>> >>
>> >> On 6/6/13 9:08 AM, "Will Stevens"  wrote:
>> >>
>> >> >Hey All,
>> >> >I am building integration between CS and an external Palo 

Review Request: Fix for CLOUDSTACK-1622, CLOUDSTACK-1704

[Harikrishna Patnala]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11780/
---

Review request for cloudstack, Abhinandan Prateek and Nitin Mehta.


Description
---

Global parameter "cluster.memory.allocated.capacity.disablethreshold" and 
"cluster.cpu.allocated.capacity.disablethreshold" are not disabling cluster 
after threshold values.

This is due to unhandled sql query when these parameters have null values in 
the DB. Fixed by adding that case in the query.


This addresses bugs CLOUDSTACK-1622 and CLOUDSTACK-1704.


Diffs
-

  engine/schema/src/com/cloud/capacity/dao/CapacityDaoImpl.java 0b9ff1a 

Diff: https://reviews.apache.org/r/11780/diff/


Testing
---

Tested locally


Thanks,

Harikrishna Patnala

Fwd: Unable to adjust firewall rules on VR since upgrade

[Francois Gaudreault]

Hi,

I posted this on the users mailing list, but didn't get any reply. Maybe 
I will get more attention here :)


Let me know if I should open a bug report.

Thanks!

 Original Message 
Subject:Unable to adjust firewall rules on VR since upgrade
Date:   Fri, 07 Jun 2013 12:52:42 -0400
From:   Francois Gaudreault 
Reply-To:   fgaudrea...@cloudops.com
To: us...@cloudstack.apache.org 



Hi,

Before posting a bug report for this, I am curious to see if anyone else
faced that issue.

We were running on 4.0.0, and we had couple isolated networks (hence
couple VRs) with firewall rules.  When we upgraded to 4.1.0, we were not
able to adjust/delete firewall rules for the existing VRs.  The error in
the log was:
WARN  [network.firewall.FirewallManagerImpl] (Job-Executor-83:job-461)
Failed to apply firewall rules due to
com.cloud.exception.ResourceUnavailableException: Resource
[DataCenter:1] is unreachable: Unable to apply firewall rules on router
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3431)
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyFirewallRules(VirtualNetworkApplianceManagerImpl.java:3287)
at
com.cloud.network.element.VirtualRouterElement.applyFWRules(VirtualRouterElement.java:229)
at
com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerImpl.java:544)
at
com.cloud.network.NetworkManagerImpl.applyRules(NetworkManagerImpl.java:2344)
at
com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerImpl.java:500)
at
com.cloud.network.firewall.FirewallManagerImpl.applyFirewallRules(FirewallManagerImpl.java:630)
at
com.cloud.network.firewall.FirewallManagerImpl.revokeFirewallRule(FirewallManagerImpl.java:670)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
com.cloud.network.firewall.FirewallManagerImpl.revokeFirewallRule(FirewallManagerImpl.java:683)
at
org.apache.cloudstack.api.command.user.firewall.DeleteEgressFirewallRuleCmd.execute(DeleteEgressFirewallRuleCmd.java:97)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:162)
at
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:679)

Thanks!

--
Francois Gaudreault
Architecte de Solution Cloud | Cloud Solutions Architect
fgaudrea...@cloudops.com
514-629-6775
- - -
CloudOps
420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_

Re: [DISCUSS] NFS cache storage issue on object_store

[Chiradeep Vittal]

>
>From a code perspective, I think it would behove us to implement a more
>functional approach to command execution in order to ensure reference
>counting, error handling, resource management are handled in a consistent
>manner.  I implemented such an approach in
>com.cloud.utils.db.GlobalLock#executeWithLock where locking around a
>particular operation is managed separately form the actual operation
>being performed.

This one confused me: this is called from NfsSecondaryStorageResource
which does not have access to the management server database. Since if you
call the lock() function, it will try to access a db row.

RE: Contributing as a non-committer

[Soheil Eizadi]

CloudStack uses Maven you need to use M2e - Eclipse Maven Plugin that will 
create the Projects for you.
-Soheil

From: Sebastien Goasguen [run...@gmail.com]
Sent: Monday, June 10, 2013 6:45 AM
To: dev@cloudstack.apache.org
Subject: Re: Contributing as a non-committer

On Jun 10, 2013, at 9:40 AM, Paul Angus  wrote:

> Thanks Seb,
> I've bought pro git as extra reading too.
>
> Now I'm trying to setup my dev environment, the 'Setting Up an Apache 
> CloudStack Development Environment' says
> "Most Apache CloudStack developers use Eclipse as their primary IDE. 
> CloudStack source code already includes Eclipse .project file in each project 
> folder"
>
> But I can't find the .project file in the CloudStack directory…?

Forget about eclipse for now :) just use vi :)



>
>
> Regards,
>
> Paul Angus
> S: +44 20 3603 0540 | M: +447711418784
> paul.an...@shapeblue.com
>
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: 09 June 2013 08:46
> To: dev@cloudstack.apache.org
> Subject: Re: Contributing as a non-committer
>
> Paul, I fixed the wiki link.
>
> Thanks for reporting it, note that if you have a wiki account you can edit 
> the page yourself and edit it.
>
> Let us know if the instructions are not clear. I also have a screencast on 
> git basics for non-committers:
> http://www.youtube.com/watch?v=3c5JIW4onGk&list=PLb899uhkHRoZCRE00h_9CRgUSiHEgFDbC&index=5
>
>
>
> -sebastien
>
> On Jun 9, 2013, at 2:28 AM, Paul Angus  wrote:
>
>> Hi Joe,
>>
>> It's on
>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Home
>> under 'Developer Docs and Resources'
>>
>>
>>
>> Regards,
>>
>> Paul Angus
>> S: +44 20 3603 0540 | M: +447711418784 paul.an...@shapeblue.com
>>
>> -Original Message-
>> From: Joe Brockmeier [mailto:j...@zonker.net]
>> Sent: 08 June 2013 23:04
>> To: dev@cloudstack.apache.org
>> Subject: Re: Contributing as a non-committer
>>
>> Paul, where are you seeing that link?
>>
>> On Fri, Jun 7, 2013, at 03:55 PM, Paul Angus wrote:
>>> Guys,
>>>
>>> I'm just trying to get up to speed with how I can contribute more
>>> (starting with a minor doc fix) but the link
>>> http://cloudstack.apache.org/develop/non-contributors.html is broken.
>>>
>>> Can it be fixed pls (does it count as a bug that I need to report).
>>> Is there an alternate link for the time being?
>>>
>>>
>>> Regards
>>>
>>> Paul Angus
>>> Senior Consultant / Cloud Architect
>>>
>>> [cid:image002.png@01CE1071.C6CC9C10]
>>>
>>> S: +44 20 3603 0540 | M:
>>> +447711418784
>>> paul.an...@shapeblue.com |
>>> www.shapeblue.com | Twitter:@shapeblue
>>> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>>>
>>> ShapeBlue are proud to be sponsoring CloudStack Collaboration
>>> Conference NA
>>> [https://cwiki.apache.org/confluence/download/attachments/30760149/Cl
>>> o
>>> udStack+Collaboration+Conference+Banner+v2+Blue+Background+Only.jpg?v
>>> udStack+Collaboration+Conference+Banner+v2+Blue+Background+e
>>> rsion=3&modificationDate=1367282397297]>> e
>>> t/>
>>>
>>> Apache CloudStack Bootcamp training courses
>>> 19/20 June,
>>> London
>>> 22/23 June, Santa Clara
>>> CA
>>> 10/11 July, Bangalore,
>>> India
>>> 21/22 August,
>>> London
>>>
>>> This email and any attachments to it may be confidential and are
>>> intended solely for the use of the individual to whom it is addressed.
>>> Any views or opinions expressed are solely those of the author and do
>>> not necessarily represent those of Shape Blue Ltd or related
>>> companies. If you are not the intended recipient of this email, you
>>> must neither take any action based upon its contents, nor copy or
>>> show it to anyone. Please contact the sender if you believe you have 
>>> received this email in error.
>>> Shape Blue Ltd is a company incorporated in England & Wales.
>>> ShapeBlue Services India LLP is operated under license from Shape Blue Ltd.
>>> ShapeBlue is a registered trademark.
>>
>>
>> Best,
>>
>> jzb
>> --
>> Joe Brockmeier
>> j...@zonker.net
>> Twitter: @jzb
>> http://www.dissociatedpress.net/
>>
>> This email and any attachments to it may be confidential and are intended 
>> solely for the use of the individual to whom it is addressed. Any views or 
>> opinions expressed are solely those of the author and do not necessarily 
>> represent those of Shape Blue Ltd or related companies. If you are not the 
>> intended recipient of this email, you must neither take any action based 
>> upon its contents, nor copy or show it to anyone. Please contact the sender 
>> if you believe you have received this email in error. Shape Blue Ltd is a 
>> 

Re: [DISCUSS] NFS cache storage issue on object_store

[John Burwell]

Chiradeep,

Looks like I have a rookie mistake in S3-backed Secondary Storage.  I will 
investigate, and send a patch to lock on the management server side.

Thanks,
-John

On Jun 10, 2013, at 1:30 PM, Chiradeep Vittal  
wrote:

> 
>> 
>> From a code perspective, I think it would behove us to implement a more
>> functional approach to command execution in order to ensure reference
>> counting, error handling, resource management are handled in a consistent
>> manner.  I implemented such an approach in
>> com.cloud.utils.db.GlobalLock#executeWithLock where locking around a
>> particular operation is managed separately form the actual operation
>> being performed.
> 
> This one confused me: this is called from NfsSecondaryStorageResource
> which does not have access to the management server database. Since if you
> call the lock() function, it will try to access a db row.
> 

Re: Unable to adjust firewall rules on VR since upgrade

[Chiradeep Vittal]

Need more logs

On 6/10/13 10:28 AM, "Francois Gaudreault" 
wrote:

>Hi,
>
>I posted this on the users mailing list, but didn't get any reply. Maybe
>I will get more attention here :)
>
>Let me know if I should open a bug report.
>
>Thanks!
>
> Original Message 
>Subject:   Unable to adjust firewall rules on VR since upgrade
>Date:  Fri, 07 Jun 2013 12:52:42 -0400
>From:  Francois Gaudreault 
>Reply-To:  fgaudrea...@cloudops.com
>To:us...@cloudstack.apache.org 
>
>
>
>Hi,
>
>Before posting a bug report for this, I am curious to see if anyone else
>faced that issue.
>
>We were running on 4.0.0, and we had couple isolated networks (hence
>couple VRs) with firewall rules.  When we upgraded to 4.1.0, we were not
>able to adjust/delete firewall rules for the existing VRs.  The error in
>the log was:
>WARN  [network.firewall.FirewallManagerImpl] (Job-Executor-83:job-461)
>Failed to apply firewall rules due to
>com.cloud.exception.ResourceUnavailableException: Resource
>[DataCenter:1] is unreachable: Unable to apply firewall rules on router
> at
>com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(Vir
>tualNetworkApplianceManagerImpl.java:3431)
> at
>com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyFirewallR
>ules(VirtualNetworkApplianceManagerImpl.java:3287)
> at
>com.cloud.network.element.VirtualRouterElement.applyFWRules(VirtualRouterE
>lement.java:229)
> at
>com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerI
>mpl.java:544)
> at
>com.cloud.network.NetworkManagerImpl.applyRules(NetworkManagerImpl.java:23
>44)
> at
>com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerI
>mpl.java:500)
> at
>com.cloud.network.firewall.FirewallManagerImpl.applyFirewallRules(Firewall
>ManagerImpl.java:630)
> at
>com.cloud.network.firewall.FirewallManagerImpl.revokeFirewallRule(Firewall
>ManagerImpl.java:670)
> at
>com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorD
>ispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
>com.cloud.network.firewall.FirewallManagerImpl.revokeFirewallRule(Firewall
>ManagerImpl.java:683)
> at
>org.apache.cloudstack.api.command.user.firewall.DeleteEgressFirewallRuleCm
>d.execute(DeleteEgressFirewallRuleCmd.java:97)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:162)
> at
>com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
> at
>java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:
>1146)
> at
>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java
>:615)
> at java.lang.Thread.run(Thread.java:679)
>
>Thanks!
>
>-- 
>Francois Gaudreault
>Architecte de Solution Cloud | Cloud Solutions Architect
>fgaudrea...@cloudops.com
>514-629-6775
>- - -
>CloudOps
>420 rue Guy
>Montréal QC  H3J 1S6
>www.cloudops.com
>@CloudOps_
>
>
>

Re: Unable to adjust firewall rules on VR since upgrade

[Francois Gaudreault]

Interesting... I can't reproduce it today :S So maybe that was just a 
temporary issue?  (I hate those issues!)


What would cause this actually?  VR not running? Agent on the VR not 
running?


Thanks!

Francois

On 2013-06-10 1:34 PM, Chiradeep Vittal wrote:

Need more logs

On 6/10/13 10:28 AM, "Francois Gaudreault" 
wrote:


Hi,

I posted this on the users mailing list, but didn't get any reply. Maybe
I will get more attention here :)

Let me know if I should open a bug report.

Thanks!

 Original Message 
Subject:Unable to adjust firewall rules on VR since upgrade
Date:   Fri, 07 Jun 2013 12:52:42 -0400
From:   Francois Gaudreault 
Reply-To:   fgaudrea...@cloudops.com
To: us...@cloudstack.apache.org 



Hi,

Before posting a bug report for this, I am curious to see if anyone else
faced that issue.

We were running on 4.0.0, and we had couple isolated networks (hence
couple VRs) with firewall rules.  When we upgraded to 4.1.0, we were not
able to adjust/delete firewall rules for the existing VRs.  The error in
the log was:
WARN  [network.firewall.FirewallManagerImpl] (Job-Executor-83:job-461)
Failed to apply firewall rules due to
com.cloud.exception.ResourceUnavailableException: Resource
[DataCenter:1] is unreachable: Unable to apply firewall rules on router
 at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(Vir
tualNetworkApplianceManagerImpl.java:3431)
 at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyFirewallR
ules(VirtualNetworkApplianceManagerImpl.java:3287)
 at
com.cloud.network.element.VirtualRouterElement.applyFWRules(VirtualRouterE
lement.java:229)
 at
com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerI
mpl.java:544)
 at
com.cloud.network.NetworkManagerImpl.applyRules(NetworkManagerImpl.java:23
44)
 at
com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerI
mpl.java:500)
 at
com.cloud.network.firewall.FirewallManagerImpl.applyFirewallRules(Firewall
ManagerImpl.java:630)
 at
com.cloud.network.firewall.FirewallManagerImpl.revokeFirewallRule(Firewall
ManagerImpl.java:670)
 at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorD
ispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at
com.cloud.network.firewall.FirewallManagerImpl.revokeFirewallRule(Firewall
ManagerImpl.java:683)
 at
org.apache.cloudstack.api.command.user.firewall.DeleteEgressFirewallRuleCm
d.execute(DeleteEgressFirewallRuleCmd.java:97)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:162)
 at
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
 at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:
1146)
 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java
:615)
 at java.lang.Thread.run(Thread.java:679)

Thanks!

--
Francois Gaudreault
Architecte de Solution Cloud | Cloud Solutions Architect
fgaudrea...@cloudops.com
514-629-6775
- - -
CloudOps
420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_









--
Francois Gaudreault
Architecte de Solution Cloud | Cloud Solutions Architect
fgaudrea...@cloudops.com
514-629-6775
- - -
CloudOps
420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_

Review Request: (CLOUDSTACK-1301) VM Disk I/O Throttling

[Wei Zhou]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11782/
---

Review request for cloudstack, Wido den Hollander and John Burwell.


Description
---

The patch for VM Disk I/O throttling based on commit 
3f3c6aa35f64c4129c203d54840524e6aa2c4621


This addresses bug CLOUDSTACK-1301.


Diffs
-

  api/src/com/cloud/agent/api/to/VolumeTO.java 4cbe82b 
  api/src/com/cloud/offering/DiskOffering.java dd77c70 
  api/src/com/cloud/vm/DiskProfile.java e3a3386 
  api/src/org/apache/cloudstack/api/ApiConstants.java ab1402c 
  
api/src/org/apache/cloudstack/api/command/admin/offering/CreateDiskOfferingCmd.java
 aa11599 
  
api/src/org/apache/cloudstack/api/command/admin/offering/CreateServiceOfferingCmd.java
 4c54a4e 
  api/src/org/apache/cloudstack/api/response/DiskOfferingResponse.java 377e66e 
  api/src/org/apache/cloudstack/api/response/ServiceOfferingResponse.java 
31533f8 
  api/src/org/apache/cloudstack/api/response/VolumeResponse.java 21d7d1a 
  client/WEB-INF/classes/resources/messages.properties 2b17359 
  core/src/com/cloud/agent/api/AttachVolumeCommand.java 302b8f8 
  engine/schema/src/com/cloud/storage/DiskOfferingVO.java 909d7fe 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
 bab53bc 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtDomainXMLParser.java
 b8645e1 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java 
9cddb2e 
  server/src/com/cloud/api/query/dao/DiskOfferingJoinDaoImpl.java 283181f 
  server/src/com/cloud/api/query/dao/ServiceOfferingJoinDaoImpl.java 56e4d0a 
  server/src/com/cloud/api/query/dao/VolumeJoinDaoImpl.java e27e2d9 
  server/src/com/cloud/api/query/vo/DiskOfferingJoinVO.java 6d3cdcb 
  server/src/com/cloud/api/query/vo/ServiceOfferingJoinVO.java e87a101 
  server/src/com/cloud/api/query/vo/VolumeJoinVO.java 6ef8c91 
  server/src/com/cloud/configuration/Config.java 5ee0fad 
  server/src/com/cloud/configuration/ConfigurationManager.java 8db037b 
  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 59e70cf 
  server/src/com/cloud/storage/StorageManager.java d49a7f8 
  server/src/com/cloud/storage/StorageManagerImpl.java d38b35e 
  server/src/com/cloud/storage/VolumeManagerImpl.java 43f3681 
  server/src/com/cloud/test/DatabaseConfig.java 70c8178 
  server/test/com/cloud/vpc/MockConfigurationManagerImpl.java 21b3590 
  setup/db/db/schema-410to420.sql bcfbcc9 
  ui/dictionary.jsp a5f0662 
  ui/scripts/configuration.js cb15598 
  ui/scripts/instances.js 7149815 

Diff: https://reviews.apache.org/r/11782/diff/


Testing
---

testing ok.


Thanks,

Wei Zhou

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[Wei ZHOU]

Guys,

I would like to merge disk_io_throttling branch into master.
Please review the code on https://reviews.apache.org/r/11782

If nobody object, I will merge into master in 72 hours.

-Wei

2013/5/30 Wei ZHOU 

> Hi,
> I would like to merge disk_io_throttling branch into master.
> If nobody object, I will merge into master in 48 hours.
> The purpose is :
>
> Virtual machines are running on the same storage device (local storage or
> share strage). Because of the rate limitation of device (such as iops), if
> one VM has large disk operation, it may affect the disk performance of
> other VMs running on the same storage device.
> It is neccesary to set the maximum rate and limit the disk I/O of VMs.
>
> The feature includes:
>
> (1) set the maximum rate of VMs (in disk_offering, and global
> configuration)
> (2) change the maximum rate of VMs
> (3) limit the disk rate (total bps and iops)
> JIRA ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-1192
> FS (I will update later) :
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Disk+IO+Throttling
>  Merge check list :-
>
> * Did you check the branch's RAT execution success?
> Yes
>
> * Are there new dependencies introduced?
> No
>
> * What automated testing (unit and integration) is included in the new
> feature?
> Unit tests are added.
>
> * What testing has been done to check for potential regressions?
> (1) set the bytes rate and IOPS rate on CloudStack UI.
> (2) VM operations, including
>  deploy, stop, start, reboot, destroy, expunge. migrate, restore
> (3) Volume operations, including
> Attach, Detach
>
> To review the code, you can try
>  git diff c30057635d04a2396f84c588127d7ebe42e503a7
> f2e5591b710d04cc86815044f5823e73a4a58944
>
> Best regards,
> Wei
>
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Disk+IO+Throttling
> [2] refs/heads/disk_io_throttling
> [3] 
> https://issues.apache.org/jira/browse/CLOUDSTACK-1301(CLOUDSTACK-1301
>  - VM Disk I/O Throttling)
>

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[John Burwell]

Wei,

Have Mike Tutkowski and you reconciled the potential conflict between a 
throttled I/O VM and a provisioned IOPs volume?  If so, what solution did you 
select?

Thanks,
-John

On Jun 10, 2013, at 1:54 PM, Wei ZHOU  wrote:

> Guys,
> 
> I would like to merge disk_io_throttling branch into master.
> Please review the code on https://reviews.apache.org/r/11782
> 
> If nobody object, I will merge into master in 72 hours.
> 
> -Wei
> 
> 2013/5/30 Wei ZHOU 
> 
>> Hi,
>> I would like to merge disk_io_throttling branch into master.
>> If nobody object, I will merge into master in 48 hours.
>> The purpose is :
>> 
>> Virtual machines are running on the same storage device (local storage or
>> share strage). Because of the rate limitation of device (such as iops), if
>> one VM has large disk operation, it may affect the disk performance of
>> other VMs running on the same storage device.
>> It is neccesary to set the maximum rate and limit the disk I/O of VMs.
>> 
>> The feature includes:
>> 
>> (1) set the maximum rate of VMs (in disk_offering, and global
>> configuration)
>> (2) change the maximum rate of VMs
>> (3) limit the disk rate (total bps and iops)
>> JIRA ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-1192
>> FS (I will update later) :
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Disk+IO+Throttling
>> Merge check list :-
>> 
>> * Did you check the branch's RAT execution success?
>> Yes
>> 
>> * Are there new dependencies introduced?
>> No
>> 
>> * What automated testing (unit and integration) is included in the new
>> feature?
>> Unit tests are added.
>> 
>> * What testing has been done to check for potential regressions?
>> (1) set the bytes rate and IOPS rate on CloudStack UI.
>> (2) VM operations, including
>> deploy, stop, start, reboot, destroy, expunge. migrate, restore
>> (3) Volume operations, including
>> Attach, Detach
>> 
>> To review the code, you can try
>> git diff c30057635d04a2396f84c588127d7ebe42e503a7
>> f2e5591b710d04cc86815044f5823e73a4a58944
>> 
>> Best regards,
>> Wei
>> 
>> [1]
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Disk+IO+Throttling
>> [2] refs/heads/disk_io_throttling
>> [3] 
>> https://issues.apache.org/jira/browse/CLOUDSTACK-1301(CLOUDSTACK-1301
>>  - VM Disk I/O Throttling)
>> 

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[Mike Tutkowski]

Perhaps Wei could send me some screen shots of what he's changed in the GUI
for his feature?

Thanks!


On Mon, Jun 10, 2013 at 11:56 AM, John Burwell  wrote:

> Wei,
>
> Have Mike Tutkowski and you reconciled the potential conflict between a
> throttled I/O VM and a provisioned IOPs volume?  If so, what solution did
> you select?
>
> Thanks,
> -John
>
> On Jun 10, 2013, at 1:54 PM, Wei ZHOU  wrote:
>
> > Guys,
> >
> > I would like to merge disk_io_throttling branch into master.
> > Please review the code on https://reviews.apache.org/r/11782
> >
> > If nobody object, I will merge into master in 72 hours.
> >
> > -Wei
> >
> > 2013/5/30 Wei ZHOU 
> >
> >> Hi,
> >> I would like to merge disk_io_throttling branch into master.
> >> If nobody object, I will merge into master in 48 hours.
> >> The purpose is :
> >>
> >> Virtual machines are running on the same storage device (local storage
> or
> >> share strage). Because of the rate limitation of device (such as iops),
> if
> >> one VM has large disk operation, it may affect the disk performance of
> >> other VMs running on the same storage device.
> >> It is neccesary to set the maximum rate and limit the disk I/O of VMs.
> >>
> >> The feature includes:
> >>
> >> (1) set the maximum rate of VMs (in disk_offering, and global
> >> configuration)
> >> (2) change the maximum rate of VMs
> >> (3) limit the disk rate (total bps and iops)
> >> JIRA ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-1192
> >> FS (I will update later) :
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Disk+IO+Throttling
> >> Merge check list :-
> >>
> >> * Did you check the branch's RAT execution success?
> >> Yes
> >>
> >> * Are there new dependencies introduced?
> >> No
> >>
> >> * What automated testing (unit and integration) is included in the new
> >> feature?
> >> Unit tests are added.
> >>
> >> * What testing has been done to check for potential regressions?
> >> (1) set the bytes rate and IOPS rate on CloudStack UI.
> >> (2) VM operations, including
> >> deploy, stop, start, reboot, destroy, expunge. migrate, restore
> >> (3) Volume operations, including
> >> Attach, Detach
> >>
> >> To review the code, you can try
> >> git diff c30057635d04a2396f84c588127d7ebe42e503a7
> >> f2e5591b710d04cc86815044f5823e73a4a58944
> >>
> >> Best regards,
> >> Wei
> >>
> >> [1]
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Disk+IO+Throttling
> >> [2] refs/heads/disk_io_throttling
> >> [3] https://issues.apache.org/jira/browse/CLOUDSTACK-1301<
> https://issues.apache.org/jira/browse/CLOUDSTACK-2071>(CLOUDSTACK-1301 -
> VM Disk I/O Throttling)
> >>
>
>


-- 
*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: [MERGE] disk_io_throttling to MASTER (Second Round)

[John Burwell]

Mike,

Have Wei and you figured out the system level as well (e.g. allowing either 
storage provisioned IOPS or hypervisor throttling, but no both)?

Thanks,
-John

On Jun 10, 2013, at 2:12 PM, Mike Tutkowski  
wrote:

> Perhaps Wei could send me some screen shots of what he's changed in the GUI
> for his feature?
> 
> Thanks!
> 
> 
> On Mon, Jun 10, 2013 at 11:56 AM, John Burwell  wrote:
> 
>> Wei,
>> 
>> Have Mike Tutkowski and you reconciled the potential conflict between a
>> throttled I/O VM and a provisioned IOPs volume?  If so, what solution did
>> you select?
>> 
>> Thanks,
>> -John
>> 
>> On Jun 10, 2013, at 1:54 PM, Wei ZHOU  wrote:
>> 
>>> Guys,
>>> 
>>> I would like to merge disk_io_throttling branch into master.
>>> Please review the code on https://reviews.apache.org/r/11782
>>> 
>>> If nobody object, I will merge into master in 72 hours.
>>> 
>>> -Wei
>>> 
>>> 2013/5/30 Wei ZHOU 
>>> 
 Hi,
 I would like to merge disk_io_throttling branch into master.
 If nobody object, I will merge into master in 48 hours.
 The purpose is :
 
 Virtual machines are running on the same storage device (local storage
>> or
 share strage). Because of the rate limitation of device (such as iops),
>> if
 one VM has large disk operation, it may affect the disk performance of
 other VMs running on the same storage device.
 It is neccesary to set the maximum rate and limit the disk I/O of VMs.
 
 The feature includes:
 
 (1) set the maximum rate of VMs (in disk_offering, and global
 configuration)
 (2) change the maximum rate of VMs
 (3) limit the disk rate (total bps and iops)
 JIRA ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-1192
 FS (I will update later) :
 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Disk+IO+Throttling
 Merge check list :-
 
 * Did you check the branch's RAT execution success?
 Yes
 
 * Are there new dependencies introduced?
 No
 
 * What automated testing (unit and integration) is included in the new
 feature?
 Unit tests are added.
 
 * What testing has been done to check for potential regressions?
 (1) set the bytes rate and IOPS rate on CloudStack UI.
 (2) VM operations, including
 deploy, stop, start, reboot, destroy, expunge. migrate, restore
 (3) Volume operations, including
 Attach, Detach
 
 To review the code, you can try
 git diff c30057635d04a2396f84c588127d7ebe42e503a7
 f2e5591b710d04cc86815044f5823e73a4a58944
 
 Best regards,
 Wei
 
 [1]
 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Disk+IO+Throttling
 [2] refs/heads/disk_io_throttling
 [3] https://issues.apache.org/jira/browse/CLOUDSTACK-1301<
>> https://issues.apache.org/jira/browse/CLOUDSTACK-2071>(CLOUDSTACK-1301 -
>>VM Disk I/O Throttling)
 
>> 
>> 
> 
> 
> -- 
> *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: [GSOC] NullPointerException when deployVM using GRE isolation method. Help me!

[Sebastien Goasguen]

On Jun 10, 2013, at 10:17 AM, Nguyen Anh Tu  wrote:

> Hi forks,
> 

I think we say "folks" but that's not solving the NPE error.

I cc Chiradeep who might have some insight here.

-sebastien

> I'm trying OVS tunnel with XCP 1.6 and get error NullPointerException when
> executing deployVM.
> 
> I found this error starting from the below code.
> 
> *NetworkManagerImpl.java*
> 
> *NicProfile profile = guru.allocate(network, requested, vm); (1)*
>if (isDefaultNic != null) {
>profile.setDefaultNic(
> isDefaultNic);
>}
> 
> *ExtenalGuestNetworkGuru.java*
> 
>@Override
>   * public NicProfile allocate(Network config, NicProfile nic,
> VirtualMachineProfile vm) throws
> InsufficientVirtualNetworkCapcityException,
>InsufficientAddressCapacityException* {
> 
>if
> (_networkModel.networkIsConfiguredForExternalNetworking(config.getDataCenterId(),
> config.getId()) && nic != null && nic.getRequestedIpv4() != null) {
>throw new CloudRuntimeException("Does not support custom ip
> allocation at this time: " + nic);
>}
> 
>NicProfile profile = super.allocate(config, nic, vm);
> 
>*boolean _isEnabled =
> Boolean.parseBoolean(_configDao.getValue(Config.OvsTunnelNetwork.key()));
> (2)
>if (_isEnabled) {
>return null;
>}*
> 
>if
> (_networkModel.networkIsConfiguredForExternalNetworking(config.getDataCenterId(),
> config.getId())) {
>profile.setStrategy(ReservationStrategy.Start);
>/* We won't clear IP address, because router may set gateway as
> it IP, and it would be updated properly later */
>//profile.setIp4Address(null);
>profile.setGateway(null);
>profile.setNetmask(null);
>}
> 
>return profile;
>}*
> 
> *
> The return from (1) is NULL, because at (2) *sdn.ovs.controller* set to
> true. So profile = NULL and then we get NullPointerException error in the
> next step.
> 
> This error prevents me to deployVM using GRE isolation method. If I set *
> sdn.ovs.controller* = false, no error anymore but can't using GRE.
> 
> How can I fix this? Thanks for any help.
> 
> -- 
> 
> N.g.U.y.e.N.A.n.H.t.U

Re: [GSOC] NullPointerException when deployVM using GRE isolation method. Help me!

[Chiradeep Vittal]

The check for the config is incorrect. The check should be whether the
network in the input parameter has the isolation method 'GRE'. You can see
the canHandle method on how to check for this. Although, I don't see why
this check should even be necessary. The network will be associated with
the guru at design time.


On 6/10/13 7:17 AM, "Nguyen Anh Tu"  wrote:

>Hi forks,
>
>I'm trying OVS tunnel with XCP 1.6 and get error NullPointerException when
>executing deployVM.
>
>I found this error starting from the below code.
>
>*NetworkManagerImpl.java*
>
>*NicProfile profile = guru.allocate(network, requested, vm); (1)*
>if (isDefaultNic != null) {
>profile.setDefaultNic(
>isDefaultNic);
>}
>
>*ExtenalGuestNetworkGuru.java*
>
>@Override
>   * public NicProfile allocate(Network config, NicProfile nic,
>VirtualMachineProfile vm) throws
>InsufficientVirtualNetworkCapcityException,
>InsufficientAddressCapacityException* {
>
>if
>(_networkModel.networkIsConfiguredForExternalNetworking(config.getDataCent
>erId(),
>config.getId()) && nic != null && nic.getRequestedIpv4() != null) {
>throw new CloudRuntimeException("Does not support custom ip
>allocation at this time: " + nic);
>}
>
>NicProfile profile = super.allocate(config, nic, vm);
>
>*boolean _isEnabled =
>Boolean.parseBoolean(_configDao.getValue(Config.OvsTunnelNetwork.key()));
>(2)
>if (_isEnabled) {
>return null;
>}*
>
>if
>(_networkModel.networkIsConfiguredForExternalNetworking(config.getDataCent
>erId(),
>config.getId())) {
>profile.setStrategy(ReservationStrategy.Start);
>/* We won't clear IP address, because router may set gateway
>as
>it IP, and it would be updated properly later */
>//profile.setIp4Address(null);
>profile.setGateway(null);
>profile.setNetmask(null);
>}
>
>return profile;
>}*
>
>*
>The return from (1) is NULL, because at (2) *sdn.ovs.controller* set to
>true. So profile = NULL and then we get NullPointerException error in the
>next step.
>
>This error prevents me to deployVM using GRE isolation method. If I set *
>sdn.ovs.controller* = false, no error anymore but can't using GRE.
>
>How can I fix this? Thanks for any help.
>
>-- 
>
>N.g.U.y.e.N.A.n.H.t.U

Re: Unable to adjust firewall rules on VR since upgrade

[Chiradeep Vittal]

Technically there is no agent running inside the VR. They are all handled
by ssh scripts. But generally, communication problems between the mgmt
server and the dom0 or a stuck (kernel OOM f.e) VR can cause this issue.

On 6/10/13 10:45 AM, "Francois Gaudreault" 
wrote:

>Interesting... I can't reproduce it today :S So maybe that was just a
>temporary issue?  (I hate those issues!)
>
>What would cause this actually?  VR not running? Agent on the VR not
>running?
>
>Thanks!
>
>Francois
>
>On 2013-06-10 1:34 PM, Chiradeep Vittal wrote:
>> Need more logs
>>
>> On 6/10/13 10:28 AM, "Francois Gaudreault" 
>> wrote:
>>
>>> Hi,
>>>
>>> I posted this on the users mailing list, but didn't get any reply.
>>>Maybe
>>> I will get more attention here :)
>>>
>>> Let me know if I should open a bug report.
>>>
>>> Thanks!
>>>
>>>  Original Message 
>>> Subject:Unable to adjust firewall rules on VR since upgrade
>>> Date:   Fri, 07 Jun 2013 12:52:42 -0400
>>> From:   Francois Gaudreault 
>>> Reply-To:   fgaudrea...@cloudops.com
>>> To: us...@cloudstack.apache.org 
>>>
>>>
>>>
>>> Hi,
>>>
>>> Before posting a bug report for this, I am curious to see if anyone
>>>else
>>> faced that issue.
>>>
>>> We were running on 4.0.0, and we had couple isolated networks (hence
>>> couple VRs) with firewall rules.  When we upgraded to 4.1.0, we were
>>>not
>>> able to adjust/delete firewall rules for the existing VRs.  The error
>>>in
>>> the log was:
>>> WARN  [network.firewall.FirewallManagerImpl] (Job-Executor-83:job-461)
>>> Failed to apply firewall rules due to
>>> com.cloud.exception.ResourceUnavailableException: Resource
>>> [DataCenter:1] is unreachable: Unable to apply firewall rules on router
>>>  at
>>> 
>>>com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(V
>>>ir
>>> tualNetworkApplianceManagerImpl.java:3431)
>>>  at
>>> 
>>>com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyFirewal
>>>lR
>>> ules(VirtualNetworkApplianceManagerImpl.java:3287)
>>>  at
>>> 
>>>com.cloud.network.element.VirtualRouterElement.applyFWRules(VirtualRoute
>>>rE
>>> lement.java:229)
>>>  at
>>> 
>>>com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManage
>>>rI
>>> mpl.java:544)
>>>  at
>>> 
>>>com.cloud.network.NetworkManagerImpl.applyRules(NetworkManagerImpl.java:
>>>23
>>> 44)
>>>  at
>>> 
>>>com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManage
>>>rI
>>> mpl.java:500)
>>>  at
>>> 
>>>com.cloud.network.firewall.FirewallManagerImpl.applyFirewallRules(Firewa
>>>ll
>>> ManagerImpl.java:630)
>>>  at
>>> 
>>>com.cloud.network.firewall.FirewallManagerImpl.revokeFirewallRule(Firewa
>>>ll
>>> ManagerImpl.java:670)
>>>  at
>>> 
>>>com.cloud.utils.component.ComponentInstantiationPostProcessor$Intercepto
>>>rD
>>> ispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>>>  at
>>> 
>>>com.cloud.network.firewall.FirewallManagerImpl.revokeFirewallRule(Firewa
>>>ll
>>> ManagerImpl.java:683)
>>>  at
>>> 
>>>org.apache.cloudstack.api.command.user.firewall.DeleteEgressFirewallRule
>>>Cm
>>> d.execute(DeleteEgressFirewallRuleCmd.java:97)
>>>  at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:162)
>>>  at
>>> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
>>>  at
>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>>>  at 
>>>java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>>>  at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>>>  at
>>> 
>>>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav
>>>a:
>>> 1146)
>>>  at
>>> 
>>>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja
>>>va
>>> :615)
>>>  at java.lang.Thread.run(Thread.java:679)
>>>
>>> Thanks!
>>>
>>> -- 
>>> Francois Gaudreault
>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>> fgaudrea...@cloudops.com
>>> 514-629-6775
>>> - - -
>>> CloudOps
>>> 420 rue Guy
>>> Montréal QC  H3J 1S6
>>> www.cloudops.com
>>> @CloudOps_
>>>
>>>
>>>
>>
>>
>
>
>-- 
>Francois Gaudreault
>Architecte de Solution Cloud | Cloud Solutions Architect
>fgaudrea...@cloudops.com
>514-629-6775
>- - -
>CloudOps
>420 rue Guy
>Montréal QC  H3J 1S6
>www.cloudops.com
>@CloudOps_
>

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[Mike Tutkowski]

Wei has sent me the screen shots.

I don't support Compute Offerings for 4.2, so that's not an issue here.

I do support Disk Offerings.

It looks like Wei has added four new fields to the Disk Offering.

I have added three (Min, Max, and Burst IOPS).

We just need to decide if we should toggle between his and mine.

I doubt a user would want to use both features at the same time.


On Mon, Jun 10, 2013 at 12:30 PM, John Burwell  wrote:

> Mike,
>
> Have Wei and you figured out the system level as well (e.g. allowing
> either storage provisioned IOPS or hypervisor throttling, but no both)?
>
> Thanks,
> -John
>
> On Jun 10, 2013, at 2:12 PM, Mike Tutkowski 
> wrote:
>
> > Perhaps Wei could send me some screen shots of what he's changed in the
> GUI
> > for his feature?
> >
> > Thanks!
> >
> >
> > On Mon, Jun 10, 2013 at 11:56 AM, John Burwell 
> wrote:
> >
> >> Wei,
> >>
> >> Have Mike Tutkowski and you reconciled the potential conflict between a
> >> throttled I/O VM and a provisioned IOPs volume?  If so, what solution
> did
> >> you select?
> >>
> >> Thanks,
> >> -John
> >>
> >> On Jun 10, 2013, at 1:54 PM, Wei ZHOU  wrote:
> >>
> >>> Guys,
> >>>
> >>> I would like to merge disk_io_throttling branch into master.
> >>> Please review the code on https://reviews.apache.org/r/11782
> >>>
> >>> If nobody object, I will merge into master in 72 hours.
> >>>
> >>> -Wei
> >>>
> >>> 2013/5/30 Wei ZHOU 
> >>>
>  Hi,
>  I would like to merge disk_io_throttling branch into master.
>  If nobody object, I will merge into master in 48 hours.
>  The purpose is :
> 
>  Virtual machines are running on the same storage device (local storage
> >> or
>  share strage). Because of the rate limitation of device (such as
> iops),
> >> if
>  one VM has large disk operation, it may affect the disk performance of
>  other VMs running on the same storage device.
>  It is neccesary to set the maximum rate and limit the disk I/O of VMs.
> 
>  The feature includes:
> 
>  (1) set the maximum rate of VMs (in disk_offering, and global
>  configuration)
>  (2) change the maximum rate of VMs
>  (3) limit the disk rate (total bps and iops)
>  JIRA ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-1192
>  FS (I will update later) :
> 
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Disk+IO+Throttling
>  Merge check list :-
> 
>  * Did you check the branch's RAT execution success?
>  Yes
> 
>  * Are there new dependencies introduced?
>  No
> 
>  * What automated testing (unit and integration) is included in the new
>  feature?
>  Unit tests are added.
> 
>  * What testing has been done to check for potential regressions?
>  (1) set the bytes rate and IOPS rate on CloudStack UI.
>  (2) VM operations, including
>  deploy, stop, start, reboot, destroy, expunge. migrate, restore
>  (3) Volume operations, including
>  Attach, Detach
> 
>  To review the code, you can try
>  git diff c30057635d04a2396f84c588127d7ebe42e503a7
>  f2e5591b710d04cc86815044f5823e73a4a58944
> 
>  Best regards,
>  Wei
> 
>  [1]
> 
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Disk+IO+Throttling
>  [2] refs/heads/disk_io_throttling
>  [3] https://issues.apache.org/jira/browse/CLOUDSTACK-1301<
> >> https://issues.apache.org/jira/browse/CLOUDSTACK-2071>(CLOUDSTACK-1301
> -
> >>VM Disk I/O Throttling)
> 
> >>
> >>
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud
> > *™*
>
>


-- 
*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: [MERGE] disk_io_throttling to MASTER (Second Round)

[John Burwell]

Mike,

I agree -- I can't image a situation where you would want to use IOPS 
provisioned by both the hypervisor and storage.  There are two points of 
concern -- the UI and the management server.  We have to ensure that the user 
can't create a VM from a compute/disk offering combination where hypervisor 
throttled I/O would contradict/conflict with storage provisioned IOPS.  I think 
this functional conflict must be resolved in the management server to ensure 
that API calls are properly validated with a UX that avoids user confusion.  
Have Wei and you worked out an approach to resolving this conflict?

Thanks,
-John

On Jun 10, 2013, at 3:24 PM, Mike Tutkowski  
wrote:

> Wei has sent me the screen shots.
> 
> I don't support Compute Offerings for 4.2, so that's not an issue here.
> 
> I do support Disk Offerings.
> 
> It looks like Wei has added four new fields to the Disk Offering.
> 
> I have added three (Min, Max, and Burst IOPS).
> 
> We just need to decide if we should toggle between his and mine.
> 
> I doubt a user would want to use both features at the same time.
> 
> 
> On Mon, Jun 10, 2013 at 12:30 PM, John Burwell  wrote:
> 
>> Mike,
>> 
>> Have Wei and you figured out the system level as well (e.g. allowing
>> either storage provisioned IOPS or hypervisor throttling, but no both)?
>> 
>> Thanks,
>> -John
>> 
>> On Jun 10, 2013, at 2:12 PM, Mike Tutkowski 
>> wrote:
>> 
>>> Perhaps Wei could send me some screen shots of what he's changed in the
>> GUI
>>> for his feature?
>>> 
>>> Thanks!
>>> 
>>> 
>>> On Mon, Jun 10, 2013 at 11:56 AM, John Burwell 
>> wrote:
>>> 
 Wei,
 
 Have Mike Tutkowski and you reconciled the potential conflict between a
 throttled I/O VM and a provisioned IOPs volume?  If so, what solution
>> did
 you select?
 
 Thanks,
 -John
 
 On Jun 10, 2013, at 1:54 PM, Wei ZHOU  wrote:
 
> Guys,
> 
> I would like to merge disk_io_throttling branch into master.
> Please review the code on https://reviews.apache.org/r/11782
> 
> If nobody object, I will merge into master in 72 hours.
> 
> -Wei
> 
> 2013/5/30 Wei ZHOU 
> 
>> Hi,
>> I would like to merge disk_io_throttling branch into master.
>> If nobody object, I will merge into master in 48 hours.
>> The purpose is :
>> 
>> Virtual machines are running on the same storage device (local storage
 or
>> share strage). Because of the rate limitation of device (such as
>> iops),
 if
>> one VM has large disk operation, it may affect the disk performance of
>> other VMs running on the same storage device.
>> It is neccesary to set the maximum rate and limit the disk I/O of VMs.
>> 
>> The feature includes:
>> 
>> (1) set the maximum rate of VMs (in disk_offering, and global
>> configuration)
>> (2) change the maximum rate of VMs
>> (3) limit the disk rate (total bps and iops)
>> JIRA ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-1192
>> FS (I will update later) :
>> 
 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Disk+IO+Throttling
>> Merge check list :-
>> 
>> * Did you check the branch's RAT execution success?
>> Yes
>> 
>> * Are there new dependencies introduced?
>> No
>> 
>> * What automated testing (unit and integration) is included in the new
>> feature?
>> Unit tests are added.
>> 
>> * What testing has been done to check for potential regressions?
>> (1) set the bytes rate and IOPS rate on CloudStack UI.
>> (2) VM operations, including
>> deploy, stop, start, reboot, destroy, expunge. migrate, restore
>> (3) Volume operations, including
>> Attach, Detach
>> 
>> To review the code, you can try
>> git diff c30057635d04a2396f84c588127d7ebe42e503a7
>> f2e5591b710d04cc86815044f5823e73a4a58944
>> 
>> Best regards,
>> Wei
>> 
>> [1]
>> 
 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Disk+IO+Throttling
>> [2] refs/heads/disk_io_throttling
>> [3] https://issues.apache.org/jira/browse/CLOUDSTACK-1301<
 https://issues.apache.org/jira/browse/CLOUDSTACK-2071>(CLOUDSTACK-1301
>> -
   VM Disk I/O Throttling)
>> 
 
 
>>> 
>>> 
>>> --
>>> *Mike Tutkowski*
>>> *Senior CloudStack Developer, SolidFire Inc.*
>>> e: mike.tutkow...@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the
>>> cloud
>>> *™*
>> 
>> 
> 
> 
> -- 
> *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: [MERGE] disk_io_throttling to MASTER (Second Round)

[Mike Tutkowski]

What do you think, Wei?

Should we come up with a way for only one feature (yours or mine) to be
used at a time on the new Disk Offering dialog?

Since most storage-side provisioned IOPS don't break it down into separate
read and write categories, I think that's the way to go (only one feature
or the other).

Any suggestions from a usability standpoint how we want to implement this?
It could be as simple as a radio button to turn on your feature and mine
off or vice versa.

Thanks!


On Mon, Jun 10, 2013 at 1:33 PM, John Burwell  wrote:

> Mike,
>
> I agree -- I can't image a situation where you would want to use IOPS
> provisioned by both the hypervisor and storage.  There are two points of
> concern -- the UI and the management server.  We have to ensure that the
> user can't create a VM from a compute/disk offering combination where
> hypervisor throttled I/O would contradict/conflict with storage provisioned
> IOPS.  I think this functional conflict must be resolved in the management
> server to ensure that API calls are properly validated with a UX that
> avoids user confusion.  Have Wei and you worked out an approach to
> resolving this conflict?
>
> Thanks,
> -John
>
> On Jun 10, 2013, at 3:24 PM, Mike Tutkowski 
> wrote:
>
> > Wei has sent me the screen shots.
> >
> > I don't support Compute Offerings for 4.2, so that's not an issue here.
> >
> > I do support Disk Offerings.
> >
> > It looks like Wei has added four new fields to the Disk Offering.
> >
> > I have added three (Min, Max, and Burst IOPS).
> >
> > We just need to decide if we should toggle between his and mine.
> >
> > I doubt a user would want to use both features at the same time.
> >
> >
> > On Mon, Jun 10, 2013 at 12:30 PM, John Burwell 
> wrote:
> >
> >> Mike,
> >>
> >> Have Wei and you figured out the system level as well (e.g. allowing
> >> either storage provisioned IOPS or hypervisor throttling, but no both)?
> >>
> >> Thanks,
> >> -John
> >>
> >> On Jun 10, 2013, at 2:12 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com>
> >> wrote:
> >>
> >>> Perhaps Wei could send me some screen shots of what he's changed in the
> >> GUI
> >>> for his feature?
> >>>
> >>> Thanks!
> >>>
> >>>
> >>> On Mon, Jun 10, 2013 at 11:56 AM, John Burwell 
> >> wrote:
> >>>
>  Wei,
> 
>  Have Mike Tutkowski and you reconciled the potential conflict between
> a
>  throttled I/O VM and a provisioned IOPs volume?  If so, what solution
> >> did
>  you select?
> 
>  Thanks,
>  -John
> 
>  On Jun 10, 2013, at 1:54 PM, Wei ZHOU  wrote:
> 
> > Guys,
> >
> > I would like to merge disk_io_throttling branch into master.
> > Please review the code on https://reviews.apache.org/r/11782
> >
> > If nobody object, I will merge into master in 72 hours.
> >
> > -Wei
> >
> > 2013/5/30 Wei ZHOU 
> >
> >> Hi,
> >> I would like to merge disk_io_throttling branch into master.
> >> If nobody object, I will merge into master in 48 hours.
> >> The purpose is :
> >>
> >> Virtual machines are running on the same storage device (local
> storage
>  or
> >> share strage). Because of the rate limitation of device (such as
> >> iops),
>  if
> >> one VM has large disk operation, it may affect the disk performance
> of
> >> other VMs running on the same storage device.
> >> It is neccesary to set the maximum rate and limit the disk I/O of
> VMs.
> >>
> >> The feature includes:
> >>
> >> (1) set the maximum rate of VMs (in disk_offering, and global
> >> configuration)
> >> (2) change the maximum rate of VMs
> >> (3) limit the disk rate (total bps and iops)
> >> JIRA ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-1192
> >> FS (I will update later) :
> >>
> 
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Disk+IO+Throttling
> >> Merge check list :-
> >>
> >> * Did you check the branch's RAT execution success?
> >> Yes
> >>
> >> * Are there new dependencies introduced?
> >> No
> >>
> >> * What automated testing (unit and integration) is included in the
> new
> >> feature?
> >> Unit tests are added.
> >>
> >> * What testing has been done to check for potential regressions?
> >> (1) set the bytes rate and IOPS rate on CloudStack UI.
> >> (2) VM operations, including
> >> deploy, stop, start, reboot, destroy, expunge. migrate, restore
> >> (3) Volume operations, including
> >> Attach, Detach
> >>
> >> To review the code, you can try
> >> git diff c30057635d04a2396f84c588127d7ebe42e503a7
> >> f2e5591b710d04cc86815044f5823e73a4a58944
> >>
> >> Best regards,
> >> Wei
> >>
> >> [1]
> >>
> 
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Disk+IO+Throttling
> >> [2] refs/heads/disk_io_throttling
> >> [3] https://issues.apache.org/jira/browse/CLOUDSTACK-1301

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[Mike Tutkowski]

Here is my thinking:

Two radio buttons (whatever we want to call them):

1) Hypervisor IOPS
2) Storage IOPS

Leave them both un-checked by default.

If the user checks one or the other, the relevant fields appear.


On Mon, Jun 10, 2013 at 1:38 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> What do you think, Wei?
>
> Should we come up with a way for only one feature (yours or mine) to be
> used at a time on the new Disk Offering dialog?
>
> Since most storage-side provisioned IOPS don't break it down into separate
> read and write categories, I think that's the way to go (only one feature
> or the other).
>
> Any suggestions from a usability standpoint how we want to implement this?
> It could be as simple as a radio button to turn on your feature and mine
> off or vice versa.
>
> Thanks!
>
>
> On Mon, Jun 10, 2013 at 1:33 PM, John Burwell  wrote:
>
>> Mike,
>>
>> I agree -- I can't image a situation where you would want to use IOPS
>> provisioned by both the hypervisor and storage.  There are two points of
>> concern -- the UI and the management server.  We have to ensure that the
>> user can't create a VM from a compute/disk offering combination where
>> hypervisor throttled I/O would contradict/conflict with storage provisioned
>> IOPS.  I think this functional conflict must be resolved in the management
>> server to ensure that API calls are properly validated with a UX that
>> avoids user confusion.  Have Wei and you worked out an approach to
>> resolving this conflict?
>>
>> Thanks,
>> -John
>>
>> On Jun 10, 2013, at 3:24 PM, Mike Tutkowski 
>> wrote:
>>
>> > Wei has sent me the screen shots.
>> >
>> > I don't support Compute Offerings for 4.2, so that's not an issue here.
>> >
>> > I do support Disk Offerings.
>> >
>> > It looks like Wei has added four new fields to the Disk Offering.
>> >
>> > I have added three (Min, Max, and Burst IOPS).
>> >
>> > We just need to decide if we should toggle between his and mine.
>> >
>> > I doubt a user would want to use both features at the same time.
>> >
>> >
>> > On Mon, Jun 10, 2013 at 12:30 PM, John Burwell 
>> wrote:
>> >
>> >> Mike,
>> >>
>> >> Have Wei and you figured out the system level as well (e.g. allowing
>> >> either storage provisioned IOPS or hypervisor throttling, but no both)?
>> >>
>> >> Thanks,
>> >> -John
>> >>
>> >> On Jun 10, 2013, at 2:12 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com>
>> >> wrote:
>> >>
>> >>> Perhaps Wei could send me some screen shots of what he's changed in
>> the
>> >> GUI
>> >>> for his feature?
>> >>>
>> >>> Thanks!
>> >>>
>> >>>
>> >>> On Mon, Jun 10, 2013 at 11:56 AM, John Burwell 
>> >> wrote:
>> >>>
>>  Wei,
>> 
>>  Have Mike Tutkowski and you reconciled the potential conflict
>> between a
>>  throttled I/O VM and a provisioned IOPs volume?  If so, what solution
>> >> did
>>  you select?
>> 
>>  Thanks,
>>  -John
>> 
>>  On Jun 10, 2013, at 1:54 PM, Wei ZHOU  wrote:
>> 
>> > Guys,
>> >
>> > I would like to merge disk_io_throttling branch into master.
>> > Please review the code on https://reviews.apache.org/r/11782
>> >
>> > If nobody object, I will merge into master in 72 hours.
>> >
>> > -Wei
>> >
>> > 2013/5/30 Wei ZHOU 
>> >
>> >> Hi,
>> >> I would like to merge disk_io_throttling branch into master.
>> >> If nobody object, I will merge into master in 48 hours.
>> >> The purpose is :
>> >>
>> >> Virtual machines are running on the same storage device (local
>> storage
>>  or
>> >> share strage). Because of the rate limitation of device (such as
>> >> iops),
>>  if
>> >> one VM has large disk operation, it may affect the disk
>> performance of
>> >> other VMs running on the same storage device.
>> >> It is neccesary to set the maximum rate and limit the disk I/O of
>> VMs.
>> >>
>> >> The feature includes:
>> >>
>> >> (1) set the maximum rate of VMs (in disk_offering, and global
>> >> configuration)
>> >> (2) change the maximum rate of VMs
>> >> (3) limit the disk rate (total bps and iops)
>> >> JIRA ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-1192
>> >> FS (I will update later) :
>> >>
>> 
>> >>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Disk+IO+Throttling
>> >> Merge check list :-
>> >>
>> >> * Did you check the branch's RAT execution success?
>> >> Yes
>> >>
>> >> * Are there new dependencies introduced?
>> >> No
>> >>
>> >> * What automated testing (unit and integration) is included in the
>> new
>> >> feature?
>> >> Unit tests are added.
>> >>
>> >> * What testing has been done to check for potential regressions?
>> >> (1) set the bytes rate and IOPS rate on CloudStack UI.
>> >> (2) VM operations, including
>> >> deploy, stop, start, reboot, destroy, expunge. migrate, restore
>> >> (3) Volume operations, inc

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[Wei ZHOU]

Mike,
I do not think users can select only one of them, as they are implemented
on different sides.
Have you investigated the parameters other storage devices support, besides
min/max/burst IOPS? You'd better add all possible fields in your
implementation.

What do you think about this?
Hypersivor IOPS is fixed, and there is a drop-down box which includes all
supported storage vendors.
If users select "SolidFire", min/max/burst IOPS will appear.
If users select other vendors, relevant fields will appear.
Actually I still insist that it is better to add the storage-related fields
in another table.

-Wei


2013/6/10 Mike Tutkowski 

> Here is my thinking:
>
> Two radio buttons (whatever we want to call them):
>
> 1) Hypervisor IOPS
> 2) Storage IOPS
>
> Leave them both un-checked by default.
>
> If the user checks one or the other, the relevant fields appear.
>
>
> On Mon, Jun 10, 2013 at 1:38 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > What do you think, Wei?
> >
> > Should we come up with a way for only one feature (yours or mine) to be
> > used at a time on the new Disk Offering dialog?
> >
> > Since most storage-side provisioned IOPS don't break it down into
> separate
> > read and write categories, I think that's the way to go (only one feature
> > or the other).
> >
> > Any suggestions from a usability standpoint how we want to implement
> this?
> > It could be as simple as a radio button to turn on your feature and mine
> > off or vice versa.
> >
> > Thanks!
> >
> >
> > On Mon, Jun 10, 2013 at 1:33 PM, John Burwell 
> wrote:
> >
> >> Mike,
> >>
> >> I agree -- I can't image a situation where you would want to use IOPS
> >> provisioned by both the hypervisor and storage.  There are two points of
> >> concern -- the UI and the management server.  We have to ensure that the
> >> user can't create a VM from a compute/disk offering combination where
> >> hypervisor throttled I/O would contradict/conflict with storage
> provisioned
> >> IOPS.  I think this functional conflict must be resolved in the
> management
> >> server to ensure that API calls are properly validated with a UX that
> >> avoids user confusion.  Have Wei and you worked out an approach to
> >> resolving this conflict?
> >>
> >> Thanks,
> >> -John
> >>
> >> On Jun 10, 2013, at 3:24 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com>
> >> wrote:
> >>
> >> > Wei has sent me the screen shots.
> >> >
> >> > I don't support Compute Offerings for 4.2, so that's not an issue
> here.
> >> >
> >> > I do support Disk Offerings.
> >> >
> >> > It looks like Wei has added four new fields to the Disk Offering.
> >> >
> >> > I have added three (Min, Max, and Burst IOPS).
> >> >
> >> > We just need to decide if we should toggle between his and mine.
> >> >
> >> > I doubt a user would want to use both features at the same time.
> >> >
> >> >
> >> > On Mon, Jun 10, 2013 at 12:30 PM, John Burwell 
> >> wrote:
> >> >
> >> >> Mike,
> >> >>
> >> >> Have Wei and you figured out the system level as well (e.g. allowing
> >> >> either storage provisioned IOPS or hypervisor throttling, but no
> both)?
> >> >>
> >> >> Thanks,
> >> >> -John
> >> >>
> >> >> On Jun 10, 2013, at 2:12 PM, Mike Tutkowski <
> >> mike.tutkow...@solidfire.com>
> >> >> wrote:
> >> >>
> >> >>> Perhaps Wei could send me some screen shots of what he's changed in
> >> the
> >> >> GUI
> >> >>> for his feature?
> >> >>>
> >> >>> Thanks!
> >> >>>
> >> >>>
> >> >>> On Mon, Jun 10, 2013 at 11:56 AM, John Burwell 
> >> >> wrote:
> >> >>>
> >>  Wei,
> >> 
> >>  Have Mike Tutkowski and you reconciled the potential conflict
> >> between a
> >>  throttled I/O VM and a provisioned IOPs volume?  If so, what
> solution
> >> >> did
> >>  you select?
> >> 
> >>  Thanks,
> >>  -John
> >> 
> >>  On Jun 10, 2013, at 1:54 PM, Wei ZHOU 
> wrote:
> >> 
> >> > Guys,
> >> >
> >> > I would like to merge disk_io_throttling branch into master.
> >> > Please review the code on https://reviews.apache.org/r/11782
> >> >
> >> > If nobody object, I will merge into master in 72 hours.
> >> >
> >> > -Wei
> >> >
> >> > 2013/5/30 Wei ZHOU 
> >> >
> >> >> Hi,
> >> >> I would like to merge disk_io_throttling branch into master.
> >> >> If nobody object, I will merge into master in 48 hours.
> >> >> The purpose is :
> >> >>
> >> >> Virtual machines are running on the same storage device (local
> >> storage
> >>  or
> >> >> share strage). Because of the rate limitation of device (such as
> >> >> iops),
> >>  if
> >> >> one VM has large disk operation, it may affect the disk
> >> performance of
> >> >> other VMs running on the same storage device.
> >> >> It is neccesary to set the maximum rate and limit the disk I/O of
> >> VMs.
> >> >>
> >> >> The feature includes:
> >> >>
> >> >> (1) set the maximum rate of VMs (in disk_offering, and global
> >> >> configurat

Re: [GSOC] NullPointerException when deployVM using GRE isolation method. Help me!

[Sebastien Goasguen]

On Jun 10, 2013, at 3:07 PM, Chiradeep Vittal  
wrote:

> The check for the config is incorrect. The check should be whether the
> network in the input parameter has the isolation method 'GRE'. You can see
> the canHandle method on how to check for this. Although, I don't see why
> this check should even be necessary. The network will be associated with
> the guru at design time.

Chiradeep, that's a bug then ?

> 
> 
> On 6/10/13 7:17 AM, "Nguyen Anh Tu"  wrote:
> 
>> Hi forks,
>> 
>> I'm trying OVS tunnel with XCP 1.6 and get error NullPointerException when
>> executing deployVM.
>> 
>> I found this error starting from the below code.
>> 
>> *NetworkManagerImpl.java*
>> 
>> *NicProfile profile = guru.allocate(network, requested, vm); (1)*
>>   if (isDefaultNic != null) {
>>   profile.setDefaultNic(
>> isDefaultNic);
>>   }
>> 
>> *ExtenalGuestNetworkGuru.java*
>> 
>>   @Override
>>  * public NicProfile allocate(Network config, NicProfile nic,
>> VirtualMachineProfile vm) throws
>> InsufficientVirtualNetworkCapcityException,
>>   InsufficientAddressCapacityException* {
>> 
>>   if
>> (_networkModel.networkIsConfiguredForExternalNetworking(config.getDataCent
>> erId(),
>> config.getId()) && nic != null && nic.getRequestedIpv4() != null) {
>>   throw new CloudRuntimeException("Does not support custom ip
>> allocation at this time: " + nic);
>>   }
>> 
>>   NicProfile profile = super.allocate(config, nic, vm);
>> 
>>   *boolean _isEnabled =
>> Boolean.parseBoolean(_configDao.getValue(Config.OvsTunnelNetwork.key()));
>> (2)
>>   if (_isEnabled) {
>>   return null;
>>   }*
>> 
>>   if
>> (_networkModel.networkIsConfiguredForExternalNetworking(config.getDataCent
>> erId(),
>> config.getId())) {
>>   profile.setStrategy(ReservationStrategy.Start);
>>   /* We won't clear IP address, because router may set gateway
>> as
>> it IP, and it would be updated properly later */
>>   //profile.setIp4Address(null);
>>   profile.setGateway(null);
>>   profile.setNetmask(null);
>>   }
>> 
>>   return profile;
>>   }*
>> 
>> *
>> The return from (1) is NULL, because at (2) *sdn.ovs.controller* set to
>> true. So profile = NULL and then we get NullPointerException error in the
>> next step.
>> 
>> This error prevents me to deployVM using GRE isolation method. If I set *
>> sdn.ovs.controller* = false, no error anymore but can't using GRE.
>> 
>> How can I fix this? Thanks for any help.
>> 
>> -- 
>> 
>> N.g.U.y.e.N.A.n.H.t.U
> 

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[Mike Tutkowski]

I'm not sure how that would work if the user picks SolidFire, but then
specifies a Storage Tag that doesn't include SolidFire.

As far as I know, Min, Max, and Burst is a superset for current storage
vendors that do provisioned IOPS of some sort.


On Mon, Jun 10, 2013 at 1:59 PM, Wei ZHOU  wrote:

> Mike,
> I do not think users can select only one of them, as they are implemented
> on different sides.
> Have you investigated the parameters other storage devices support, besides
> min/max/burst IOPS? You'd better add all possible fields in your
> implementation.
>
> What do you think about this?
> Hypersivor IOPS is fixed, and there is a drop-down box which includes all
> supported storage vendors.
> If users select "SolidFire", min/max/burst IOPS will appear.
> If users select other vendors, relevant fields will appear.
> Actually I still insist that it is better to add the storage-related fields
> in another table.
>
> -Wei
>
>
> 2013/6/10 Mike Tutkowski 
>
> > Here is my thinking:
> >
> > Two radio buttons (whatever we want to call them):
> >
> > 1) Hypervisor IOPS
> > 2) Storage IOPS
> >
> > Leave them both un-checked by default.
> >
> > If the user checks one or the other, the relevant fields appear.
> >
> >
> > On Mon, Jun 10, 2013 at 1:38 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> > > What do you think, Wei?
> > >
> > > Should we come up with a way for only one feature (yours or mine) to be
> > > used at a time on the new Disk Offering dialog?
> > >
> > > Since most storage-side provisioned IOPS don't break it down into
> > separate
> > > read and write categories, I think that's the way to go (only one
> feature
> > > or the other).
> > >
> > > Any suggestions from a usability standpoint how we want to implement
> > this?
> > > It could be as simple as a radio button to turn on your feature and
> mine
> > > off or vice versa.
> > >
> > > Thanks!
> > >
> > >
> > > On Mon, Jun 10, 2013 at 1:33 PM, John Burwell 
> > wrote:
> > >
> > >> Mike,
> > >>
> > >> I agree -- I can't image a situation where you would want to use IOPS
> > >> provisioned by both the hypervisor and storage.  There are two points
> of
> > >> concern -- the UI and the management server.  We have to ensure that
> the
> > >> user can't create a VM from a compute/disk offering combination where
> > >> hypervisor throttled I/O would contradict/conflict with storage
> > provisioned
> > >> IOPS.  I think this functional conflict must be resolved in the
> > management
> > >> server to ensure that API calls are properly validated with a UX that
> > >> avoids user confusion.  Have Wei and you worked out an approach to
> > >> resolving this conflict?
> > >>
> > >> Thanks,
> > >> -John
> > >>
> > >> On Jun 10, 2013, at 3:24 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com>
> > >> wrote:
> > >>
> > >> > Wei has sent me the screen shots.
> > >> >
> > >> > I don't support Compute Offerings for 4.2, so that's not an issue
> > here.
> > >> >
> > >> > I do support Disk Offerings.
> > >> >
> > >> > It looks like Wei has added four new fields to the Disk Offering.
> > >> >
> > >> > I have added three (Min, Max, and Burst IOPS).
> > >> >
> > >> > We just need to decide if we should toggle between his and mine.
> > >> >
> > >> > I doubt a user would want to use both features at the same time.
> > >> >
> > >> >
> > >> > On Mon, Jun 10, 2013 at 12:30 PM, John Burwell 
> > >> wrote:
> > >> >
> > >> >> Mike,
> > >> >>
> > >> >> Have Wei and you figured out the system level as well (e.g.
> allowing
> > >> >> either storage provisioned IOPS or hypervisor throttling, but no
> > both)?
> > >> >>
> > >> >> Thanks,
> > >> >> -John
> > >> >>
> > >> >> On Jun 10, 2013, at 2:12 PM, Mike Tutkowski <
> > >> mike.tutkow...@solidfire.com>
> > >> >> wrote:
> > >> >>
> > >> >>> Perhaps Wei could send me some screen shots of what he's changed
> in
> > >> the
> > >> >> GUI
> > >> >>> for his feature?
> > >> >>>
> > >> >>> Thanks!
> > >> >>>
> > >> >>>
> > >> >>> On Mon, Jun 10, 2013 at 11:56 AM, John Burwell <
> jburw...@basho.com>
> > >> >> wrote:
> > >> >>>
> > >>  Wei,
> > >> 
> > >>  Have Mike Tutkowski and you reconciled the potential conflict
> > >> between a
> > >>  throttled I/O VM and a provisioned IOPs volume?  If so, what
> > solution
> > >> >> did
> > >>  you select?
> > >> 
> > >>  Thanks,
> > >>  -John
> > >> 
> > >>  On Jun 10, 2013, at 1:54 PM, Wei ZHOU 
> > wrote:
> > >> 
> > >> > Guys,
> > >> >
> > >> > I would like to merge disk_io_throttling branch into master.
> > >> > Please review the code on https://reviews.apache.org/r/11782
> > >> >
> > >> > If nobody object, I will merge into master in 72 hours.
> > >> >
> > >> > -Wei
> > >> >
> > >> > 2013/5/30 Wei ZHOU 
> > >> >
> > >> >> Hi,
> > >> >> I would like to merge disk_io_throttling branch into master.
> > >> >> If nobody object, I will merge into master in 48 hours.
> > >> 

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[Mike Tutkowski]

What if you specified multiple storage tags that mapped to different
storage vendors' storage?

I'm not sure how they could enter fields for all of those vendors if you
can only select one vendors' fields.


On Mon, Jun 10, 2013 at 2:21 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> I'm not sure how that would work if the user picks SolidFire, but then
> specifies a Storage Tag that doesn't include SolidFire.
>
> As far as I know, Min, Max, and Burst is a superset for current storage
> vendors that do provisioned IOPS of some sort.
>
>
> On Mon, Jun 10, 2013 at 1:59 PM, Wei ZHOU  wrote:
>
>> Mike,
>> I do not think users can select only one of them, as they are implemented
>> on different sides.
>> Have you investigated the parameters other storage devices support,
>> besides
>> min/max/burst IOPS? You'd better add all possible fields in your
>> implementation.
>>
>> What do you think about this?
>> Hypersivor IOPS is fixed, and there is a drop-down box which includes all
>> supported storage vendors.
>> If users select "SolidFire", min/max/burst IOPS will appear.
>> If users select other vendors, relevant fields will appear.
>> Actually I still insist that it is better to add the storage-related
>> fields
>> in another table.
>>
>> -Wei
>>
>>
>> 2013/6/10 Mike Tutkowski 
>>
>> > Here is my thinking:
>> >
>> > Two radio buttons (whatever we want to call them):
>> >
>> > 1) Hypervisor IOPS
>> > 2) Storage IOPS
>> >
>> > Leave them both un-checked by default.
>> >
>> > If the user checks one or the other, the relevant fields appear.
>> >
>> >
>> > On Mon, Jun 10, 2013 at 1:38 PM, Mike Tutkowski <
>> > mike.tutkow...@solidfire.com> wrote:
>> >
>> > > What do you think, Wei?
>> > >
>> > > Should we come up with a way for only one feature (yours or mine) to
>> be
>> > > used at a time on the new Disk Offering dialog?
>> > >
>> > > Since most storage-side provisioned IOPS don't break it down into
>> > separate
>> > > read and write categories, I think that's the way to go (only one
>> feature
>> > > or the other).
>> > >
>> > > Any suggestions from a usability standpoint how we want to implement
>> > this?
>> > > It could be as simple as a radio button to turn on your feature and
>> mine
>> > > off or vice versa.
>> > >
>> > > Thanks!
>> > >
>> > >
>> > > On Mon, Jun 10, 2013 at 1:33 PM, John Burwell 
>> > wrote:
>> > >
>> > >> Mike,
>> > >>
>> > >> I agree -- I can't image a situation where you would want to use IOPS
>> > >> provisioned by both the hypervisor and storage.  There are two
>> points of
>> > >> concern -- the UI and the management server.  We have to ensure that
>> the
>> > >> user can't create a VM from a compute/disk offering combination where
>> > >> hypervisor throttled I/O would contradict/conflict with storage
>> > provisioned
>> > >> IOPS.  I think this functional conflict must be resolved in the
>> > management
>> > >> server to ensure that API calls are properly validated with a UX that
>> > >> avoids user confusion.  Have Wei and you worked out an approach to
>> > >> resolving this conflict?
>> > >>
>> > >> Thanks,
>> > >> -John
>> > >>
>> > >> On Jun 10, 2013, at 3:24 PM, Mike Tutkowski <
>> > mike.tutkow...@solidfire.com>
>> > >> wrote:
>> > >>
>> > >> > Wei has sent me the screen shots.
>> > >> >
>> > >> > I don't support Compute Offerings for 4.2, so that's not an issue
>> > here.
>> > >> >
>> > >> > I do support Disk Offerings.
>> > >> >
>> > >> > It looks like Wei has added four new fields to the Disk Offering.
>> > >> >
>> > >> > I have added three (Min, Max, and Burst IOPS).
>> > >> >
>> > >> > We just need to decide if we should toggle between his and mine.
>> > >> >
>> > >> > I doubt a user would want to use both features at the same time.
>> > >> >
>> > >> >
>> > >> > On Mon, Jun 10, 2013 at 12:30 PM, John Burwell > >
>> > >> wrote:
>> > >> >
>> > >> >> Mike,
>> > >> >>
>> > >> >> Have Wei and you figured out the system level as well (e.g.
>> allowing
>> > >> >> either storage provisioned IOPS or hypervisor throttling, but no
>> > both)?
>> > >> >>
>> > >> >> Thanks,
>> > >> >> -John
>> > >> >>
>> > >> >> On Jun 10, 2013, at 2:12 PM, Mike Tutkowski <
>> > >> mike.tutkow...@solidfire.com>
>> > >> >> wrote:
>> > >> >>
>> > >> >>> Perhaps Wei could send me some screen shots of what he's changed
>> in
>> > >> the
>> > >> >> GUI
>> > >> >>> for his feature?
>> > >> >>>
>> > >> >>> Thanks!
>> > >> >>>
>> > >> >>>
>> > >> >>> On Mon, Jun 10, 2013 at 11:56 AM, John Burwell <
>> jburw...@basho.com>
>> > >> >> wrote:
>> > >> >>>
>> > >>  Wei,
>> > >> 
>> > >>  Have Mike Tutkowski and you reconciled the potential conflict
>> > >> between a
>> > >>  throttled I/O VM and a provisioned IOPs volume?  If so, what
>> > solution
>> > >> >> did
>> > >>  you select?
>> > >> 
>> > >>  Thanks,
>> > >>  -John
>> > >> 
>> > >>  On Jun 10, 2013, at 1:54 PM, Wei ZHOU 
>> > wrote:
>> > >> 
>> > >> > Guys,
>> > >> >
>> > >> > I would li

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[John Burwell]

Wei,

In this case, we can have the hypervisor or storage providing the quality of 
service guarantee.  Naively, it seems reasonable to separate hypervisor and 
storage QoS parameters and enforce mutually exclusion.  Not only does this 
approach simplify a whole range of operations, it also avoids reconciling the 
data models.  The only question I have about the storage provision IOPS is 
whether or not "Burst IOPS" is an industry standard or vendor specific concept.

Thanks,
-John

On Jun 10, 2013, at 3:59 PM, Wei ZHOU  wrote:

> Mike,
> I do not think users can select only one of them, as they are implemented
> on different sides.
> Have you investigated the parameters other storage devices support, besides
> min/max/burst IOPS? You'd better add all possible fields in your
> implementation.
> 
> What do you think about this?
> Hypersivor IOPS is fixed, and there is a drop-down box which includes all
> supported storage vendors.
> If users select "SolidFire", min/max/burst IOPS will appear.
> If users select other vendors, relevant fields will appear.
> Actually I still insist that it is better to add the storage-related fields
> in another table.
> 
> -Wei
> 
> 
> 2013/6/10 Mike Tutkowski 
> 
>> Here is my thinking:
>> 
>> Two radio buttons (whatever we want to call them):
>> 
>> 1) Hypervisor IOPS
>> 2) Storage IOPS
>> 
>> Leave them both un-checked by default.
>> 
>> If the user checks one or the other, the relevant fields appear.
>> 
>> 
>> On Mon, Jun 10, 2013 at 1:38 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>> 
>>> What do you think, Wei?
>>> 
>>> Should we come up with a way for only one feature (yours or mine) to be
>>> used at a time on the new Disk Offering dialog?
>>> 
>>> Since most storage-side provisioned IOPS don't break it down into
>> separate
>>> read and write categories, I think that's the way to go (only one feature
>>> or the other).
>>> 
>>> Any suggestions from a usability standpoint how we want to implement
>> this?
>>> It could be as simple as a radio button to turn on your feature and mine
>>> off or vice versa.
>>> 
>>> Thanks!
>>> 
>>> 
>>> On Mon, Jun 10, 2013 at 1:33 PM, John Burwell 
>> wrote:
>>> 
 Mike,
 
 I agree -- I can't image a situation where you would want to use IOPS
 provisioned by both the hypervisor and storage.  There are two points of
 concern -- the UI and the management server.  We have to ensure that the
 user can't create a VM from a compute/disk offering combination where
 hypervisor throttled I/O would contradict/conflict with storage
>> provisioned
 IOPS.  I think this functional conflict must be resolved in the
>> management
 server to ensure that API calls are properly validated with a UX that
 avoids user confusion.  Have Wei and you worked out an approach to
 resolving this conflict?
 
 Thanks,
 -John
 
 On Jun 10, 2013, at 3:24 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com>
 wrote:
 
> Wei has sent me the screen shots.
> 
> I don't support Compute Offerings for 4.2, so that's not an issue
>> here.
> 
> I do support Disk Offerings.
> 
> It looks like Wei has added four new fields to the Disk Offering.
> 
> I have added three (Min, Max, and Burst IOPS).
> 
> We just need to decide if we should toggle between his and mine.
> 
> I doubt a user would want to use both features at the same time.
> 
> 
> On Mon, Jun 10, 2013 at 12:30 PM, John Burwell 
 wrote:
> 
>> Mike,
>> 
>> Have Wei and you figured out the system level as well (e.g. allowing
>> either storage provisioned IOPS or hypervisor throttling, but no
>> both)?
>> 
>> Thanks,
>> -John
>> 
>> On Jun 10, 2013, at 2:12 PM, Mike Tutkowski <
 mike.tutkow...@solidfire.com>
>> wrote:
>> 
>>> Perhaps Wei could send me some screen shots of what he's changed in
 the
>> GUI
>>> for his feature?
>>> 
>>> Thanks!
>>> 
>>> 
>>> On Mon, Jun 10, 2013 at 11:56 AM, John Burwell 
>> wrote:
>>> 
 Wei,
 
 Have Mike Tutkowski and you reconciled the potential conflict
 between a
 throttled I/O VM and a provisioned IOPs volume?  If so, what
>> solution
>> did
 you select?
 
 Thanks,
 -John
 
 On Jun 10, 2013, at 1:54 PM, Wei ZHOU 
>> wrote:
 
> Guys,
> 
> I would like to merge disk_io_throttling branch into master.
> Please review the code on https://reviews.apache.org/r/11782
> 
> If nobody object, I will merge into master in 72 hours.
> 
> -Wei
> 
> 2013/5/30 Wei ZHOU 
> 
>> Hi,
>> I would like to merge disk_io_throttling branch into master.
>> If nobody object, I will merge into master in 48 hours.
>> The purpose is :
>> 
>> Virt

Re: Review Request: Windows 8 (64 bit) guest OS enablement for KVM deployments in cloudstack

[Min Chen]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11611/#review21670
---


The code looks fine to me, what about test results?

- Min Chen


On June 3, 2013, 10:10 p.m., Venkata Siva Vijayendra Bhamidipati wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11611/
> ---
> 
> (Updated June 3, 2013, 10:10 p.m.)
> 
> 
> Review request for cloudstack, edison su and Min Chen.
> 
> 
> Description
> ---
> 
> Putting in Windows 8 (64 bit) as one of the options for guest OSes for KVM in 
> cloudstack.
> 
> 
> This addresses bug CS-2827.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/KVMGuestOsMapper.java
>  bd1573c 
>   setup/db/templates.sql 1685dce 
> 
> Diff: https://reviews.apache.org/r/11611/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Venkata Siva Vijayendra Bhamidipati
> 
>

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[Mike Tutkowski]

My thinking is that Min and Max are industry standard and Burst is a new
concept that could catch on.


On Mon, Jun 10, 2013 at 2:29 PM, John Burwell  wrote:

> Wei,
>
> In this case, we can have the hypervisor or storage providing the quality
> of service guarantee.  Naively, it seems reasonable to separate hypervisor
> and storage QoS parameters and enforce mutually exclusion.  Not only does
> this approach simplify a whole range of operations, it also avoids
> reconciling the data models.  The only question I have about the storage
> provision IOPS is whether or not "Burst IOPS" is an industry standard or
> vendor specific concept.
>
> Thanks,
> -John
>
> On Jun 10, 2013, at 3:59 PM, Wei ZHOU  wrote:
>
> > Mike,
> > I do not think users can select only one of them, as they are implemented
> > on different sides.
> > Have you investigated the parameters other storage devices support,
> besides
> > min/max/burst IOPS? You'd better add all possible fields in your
> > implementation.
> >
> > What do you think about this?
> > Hypersivor IOPS is fixed, and there is a drop-down box which includes all
> > supported storage vendors.
> > If users select "SolidFire", min/max/burst IOPS will appear.
> > If users select other vendors, relevant fields will appear.
> > Actually I still insist that it is better to add the storage-related
> fields
> > in another table.
> >
> > -Wei
> >
> >
> > 2013/6/10 Mike Tutkowski 
> >
> >> Here is my thinking:
> >>
> >> Two radio buttons (whatever we want to call them):
> >>
> >> 1) Hypervisor IOPS
> >> 2) Storage IOPS
> >>
> >> Leave them both un-checked by default.
> >>
> >> If the user checks one or the other, the relevant fields appear.
> >>
> >>
> >> On Mon, Jun 10, 2013 at 1:38 PM, Mike Tutkowski <
> >> mike.tutkow...@solidfire.com> wrote:
> >>
> >>> What do you think, Wei?
> >>>
> >>> Should we come up with a way for only one feature (yours or mine) to be
> >>> used at a time on the new Disk Offering dialog?
> >>>
> >>> Since most storage-side provisioned IOPS don't break it down into
> >> separate
> >>> read and write categories, I think that's the way to go (only one
> feature
> >>> or the other).
> >>>
> >>> Any suggestions from a usability standpoint how we want to implement
> >> this?
> >>> It could be as simple as a radio button to turn on your feature and
> mine
> >>> off or vice versa.
> >>>
> >>> Thanks!
> >>>
> >>>
> >>> On Mon, Jun 10, 2013 at 1:33 PM, John Burwell 
> >> wrote:
> >>>
>  Mike,
> 
>  I agree -- I can't image a situation where you would want to use IOPS
>  provisioned by both the hypervisor and storage.  There are two points
> of
>  concern -- the UI and the management server.  We have to ensure that
> the
>  user can't create a VM from a compute/disk offering combination where
>  hypervisor throttled I/O would contradict/conflict with storage
> >> provisioned
>  IOPS.  I think this functional conflict must be resolved in the
> >> management
>  server to ensure that API calls are properly validated with a UX that
>  avoids user confusion.  Have Wei and you worked out an approach to
>  resolving this conflict?
> 
>  Thanks,
>  -John
> 
>  On Jun 10, 2013, at 3:24 PM, Mike Tutkowski <
> >> mike.tutkow...@solidfire.com>
>  wrote:
> 
> > Wei has sent me the screen shots.
> >
> > I don't support Compute Offerings for 4.2, so that's not an issue
> >> here.
> >
> > I do support Disk Offerings.
> >
> > It looks like Wei has added four new fields to the Disk Offering.
> >
> > I have added three (Min, Max, and Burst IOPS).
> >
> > We just need to decide if we should toggle between his and mine.
> >
> > I doubt a user would want to use both features at the same time.
> >
> >
> > On Mon, Jun 10, 2013 at 12:30 PM, John Burwell 
>  wrote:
> >
> >> Mike,
> >>
> >> Have Wei and you figured out the system level as well (e.g. allowing
> >> either storage provisioned IOPS or hypervisor throttling, but no
> >> both)?
> >>
> >> Thanks,
> >> -John
> >>
> >> On Jun 10, 2013, at 2:12 PM, Mike Tutkowski <
>  mike.tutkow...@solidfire.com>
> >> wrote:
> >>
> >>> Perhaps Wei could send me some screen shots of what he's changed in
>  the
> >> GUI
> >>> for his feature?
> >>>
> >>> Thanks!
> >>>
> >>>
> >>> On Mon, Jun 10, 2013 at 11:56 AM, John Burwell  >
> >> wrote:
> >>>
>  Wei,
> 
>  Have Mike Tutkowski and you reconciled the potential conflict
>  between a
>  throttled I/O VM and a provisioned IOPs volume?  If so, what
> >> solution
> >> did
>  you select?
> 
>  Thanks,
>  -John
> 
>  On Jun 10, 2013, at 1:54 PM, Wei ZHOU 
> >> wrote:
> 
> > Guys,
> >
> > I would like to merge disk_io_throttling branch into master.
> 

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[Mike Tutkowski]

A major issue for current QoS providers is not being able to utilize over a
Max amount even when it is highly desirable and the storage system can
support it. That's why I'm thinking it will be a feature others attempt to
imitate.


On Mon, Jun 10, 2013 at 2:44 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> My thinking is that Min and Max are industry standard and Burst is a new
> concept that could catch on.
>
>
> On Mon, Jun 10, 2013 at 2:29 PM, John Burwell  wrote:
>
>> Wei,
>>
>> In this case, we can have the hypervisor or storage providing the quality
>> of service guarantee.  Naively, it seems reasonable to separate hypervisor
>> and storage QoS parameters and enforce mutually exclusion.  Not only does
>> this approach simplify a whole range of operations, it also avoids
>> reconciling the data models.  The only question I have about the storage
>> provision IOPS is whether or not "Burst IOPS" is an industry standard or
>> vendor specific concept.
>>
>> Thanks,
>> -John
>>
>> On Jun 10, 2013, at 3:59 PM, Wei ZHOU  wrote:
>>
>> > Mike,
>> > I do not think users can select only one of them, as they are
>> implemented
>> > on different sides.
>> > Have you investigated the parameters other storage devices support,
>> besides
>> > min/max/burst IOPS? You'd better add all possible fields in your
>> > implementation.
>> >
>> > What do you think about this?
>> > Hypersivor IOPS is fixed, and there is a drop-down box which includes
>> all
>> > supported storage vendors.
>> > If users select "SolidFire", min/max/burst IOPS will appear.
>> > If users select other vendors, relevant fields will appear.
>> > Actually I still insist that it is better to add the storage-related
>> fields
>> > in another table.
>> >
>> > -Wei
>> >
>> >
>> > 2013/6/10 Mike Tutkowski 
>> >
>> >> Here is my thinking:
>> >>
>> >> Two radio buttons (whatever we want to call them):
>> >>
>> >> 1) Hypervisor IOPS
>> >> 2) Storage IOPS
>> >>
>> >> Leave them both un-checked by default.
>> >>
>> >> If the user checks one or the other, the relevant fields appear.
>> >>
>> >>
>> >> On Mon, Jun 10, 2013 at 1:38 PM, Mike Tutkowski <
>> >> mike.tutkow...@solidfire.com> wrote:
>> >>
>> >>> What do you think, Wei?
>> >>>
>> >>> Should we come up with a way for only one feature (yours or mine) to
>> be
>> >>> used at a time on the new Disk Offering dialog?
>> >>>
>> >>> Since most storage-side provisioned IOPS don't break it down into
>> >> separate
>> >>> read and write categories, I think that's the way to go (only one
>> feature
>> >>> or the other).
>> >>>
>> >>> Any suggestions from a usability standpoint how we want to implement
>> >> this?
>> >>> It could be as simple as a radio button to turn on your feature and
>> mine
>> >>> off or vice versa.
>> >>>
>> >>> Thanks!
>> >>>
>> >>>
>> >>> On Mon, Jun 10, 2013 at 1:33 PM, John Burwell 
>> >> wrote:
>> >>>
>>  Mike,
>> 
>>  I agree -- I can't image a situation where you would want to use IOPS
>>  provisioned by both the hypervisor and storage.  There are two
>> points of
>>  concern -- the UI and the management server.  We have to ensure that
>> the
>>  user can't create a VM from a compute/disk offering combination where
>>  hypervisor throttled I/O would contradict/conflict with storage
>> >> provisioned
>>  IOPS.  I think this functional conflict must be resolved in the
>> >> management
>>  server to ensure that API calls are properly validated with a UX that
>>  avoids user confusion.  Have Wei and you worked out an approach to
>>  resolving this conflict?
>> 
>>  Thanks,
>>  -John
>> 
>>  On Jun 10, 2013, at 3:24 PM, Mike Tutkowski <
>> >> mike.tutkow...@solidfire.com>
>>  wrote:
>> 
>> > Wei has sent me the screen shots.
>> >
>> > I don't support Compute Offerings for 4.2, so that's not an issue
>> >> here.
>> >
>> > I do support Disk Offerings.
>> >
>> > It looks like Wei has added four new fields to the Disk Offering.
>> >
>> > I have added three (Min, Max, and Burst IOPS).
>> >
>> > We just need to decide if we should toggle between his and mine.
>> >
>> > I doubt a user would want to use both features at the same time.
>> >
>> >
>> > On Mon, Jun 10, 2013 at 12:30 PM, John Burwell 
>>  wrote:
>> >
>> >> Mike,
>> >>
>> >> Have Wei and you figured out the system level as well (e.g.
>> allowing
>> >> either storage provisioned IOPS or hypervisor throttling, but no
>> >> both)?
>> >>
>> >> Thanks,
>> >> -John
>> >>
>> >> On Jun 10, 2013, at 2:12 PM, Mike Tutkowski <
>>  mike.tutkow...@solidfire.com>
>> >> wrote:
>> >>
>> >>> Perhaps Wei could send me some screen shots of what he's changed
>> in
>>  the
>> >> GUI
>> >>> for his feature?
>> >>>
>> >>> Thanks!
>> >>>
>> >>>
>> >>> On Mon, Jun 10, 2013 at 11:56 AM, John Burwell <
>> jburw...@basho.com>
>> 

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[Wei ZHOU]

Mike,

Glad to see this. This is what I have questioned about.

I accepted John's and your opnion that hypervisor IOPS and storage IOPS are
mutually exclusion. The way  you mentioned is a good way to go.

A small question is, will burst IOPS only appear when storage device is
SolidFire?

-Wei


2013/6/10 Mike Tutkowski 

> My thinking is that Min and Max are industry standard and Burst is a new
> concept that could catch on.
>
>
> On Mon, Jun 10, 2013 at 2:29 PM, John Burwell  wrote:
>
> > Wei,
> >
> > In this case, we can have the hypervisor or storage providing the quality
> > of service guarantee.  Naively, it seems reasonable to separate
> hypervisor
> > and storage QoS parameters and enforce mutually exclusion.  Not only does
> > this approach simplify a whole range of operations, it also avoids
> > reconciling the data models.  The only question I have about the storage
> > provision IOPS is whether or not "Burst IOPS" is an industry standard or
> > vendor specific concept.
> >
> > Thanks,
> > -John
> >
> > On Jun 10, 2013, at 3:59 PM, Wei ZHOU  wrote:
> >
> > > Mike,
> > > I do not think users can select only one of them, as they are
> implemented
> > > on different sides.
> > > Have you investigated the parameters other storage devices support,
> > besides
> > > min/max/burst IOPS? You'd better add all possible fields in your
> > > implementation.
> > >
> > > What do you think about this?
> > > Hypersivor IOPS is fixed, and there is a drop-down box which includes
> all
> > > supported storage vendors.
> > > If users select "SolidFire", min/max/burst IOPS will appear.
> > > If users select other vendors, relevant fields will appear.
> > > Actually I still insist that it is better to add the storage-related
> > fields
> > > in another table.
> > >
> > > -Wei
> > >
> > >
> > > 2013/6/10 Mike Tutkowski 
> > >
> > >> Here is my thinking:
> > >>
> > >> Two radio buttons (whatever we want to call them):
> > >>
> > >> 1) Hypervisor IOPS
> > >> 2) Storage IOPS
> > >>
> > >> Leave them both un-checked by default.
> > >>
> > >> If the user checks one or the other, the relevant fields appear.
> > >>
> > >>
> > >> On Mon, Jun 10, 2013 at 1:38 PM, Mike Tutkowski <
> > >> mike.tutkow...@solidfire.com> wrote:
> > >>
> > >>> What do you think, Wei?
> > >>>
> > >>> Should we come up with a way for only one feature (yours or mine) to
> be
> > >>> used at a time on the new Disk Offering dialog?
> > >>>
> > >>> Since most storage-side provisioned IOPS don't break it down into
> > >> separate
> > >>> read and write categories, I think that's the way to go (only one
> > feature
> > >>> or the other).
> > >>>
> > >>> Any suggestions from a usability standpoint how we want to implement
> > >> this?
> > >>> It could be as simple as a radio button to turn on your feature and
> > mine
> > >>> off or vice versa.
> > >>>
> > >>> Thanks!
> > >>>
> > >>>
> > >>> On Mon, Jun 10, 2013 at 1:33 PM, John Burwell 
> > >> wrote:
> > >>>
> >  Mike,
> > 
> >  I agree -- I can't image a situation where you would want to use
> IOPS
> >  provisioned by both the hypervisor and storage.  There are two
> points
> > of
> >  concern -- the UI and the management server.  We have to ensure that
> > the
> >  user can't create a VM from a compute/disk offering combination
> where
> >  hypervisor throttled I/O would contradict/conflict with storage
> > >> provisioned
> >  IOPS.  I think this functional conflict must be resolved in the
> > >> management
> >  server to ensure that API calls are properly validated with a UX
> that
> >  avoids user confusion.  Have Wei and you worked out an approach to
> >  resolving this conflict?
> > 
> >  Thanks,
> >  -John
> > 
> >  On Jun 10, 2013, at 3:24 PM, Mike Tutkowski <
> > >> mike.tutkow...@solidfire.com>
> >  wrote:
> > 
> > > Wei has sent me the screen shots.
> > >
> > > I don't support Compute Offerings for 4.2, so that's not an issue
> > >> here.
> > >
> > > I do support Disk Offerings.
> > >
> > > It looks like Wei has added four new fields to the Disk Offering.
> > >
> > > I have added three (Min, Max, and Burst IOPS).
> > >
> > > We just need to decide if we should toggle between his and mine.
> > >
> > > I doubt a user would want to use both features at the same time.
> > >
> > >
> > > On Mon, Jun 10, 2013 at 12:30 PM, John Burwell  >
> >  wrote:
> > >
> > >> Mike,
> > >>
> > >> Have Wei and you figured out the system level as well (e.g.
> allowing
> > >> either storage provisioned IOPS or hypervisor throttling, but no
> > >> both)?
> > >>
> > >> Thanks,
> > >> -John
> > >>
> > >> On Jun 10, 2013, at 2:12 PM, Mike Tutkowski <
> >  mike.tutkow...@solidfire.com>
> > >> wrote:
> > >>
> > >>> Perhaps Wei could send me some screen shots of what he's changed
> in
> >  the
> > >> GUI
> > >>> for his feat

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[Mike Tutkowski]

Hi,

I don't think we can restrict Burst to SolidFire only because there really
is no way to know that the Disk Offering will be serviced by SolidFire.

This really is a flaw with the way CloudStack handles storage tags.

For example, the Disk Offering could use a storage tag that references
SolidFire and, say, NetApp. For example, say the storage tag is simply
"Fast". Both SolidFire and NetApp could have storage that supports this
requirement to the admin's liking. In this situation, you don't know which
vendor will actually have the volume deployed to it (so you don't know
which subset of fields to have the admin fill out).

I'm thinking we need to have a superset of the fields (Min, Max, and Bust)
and the admin needs to know which vendors can satisfy the Disk Offering
(listed with the storage tags field) and fill in the fields as is
applicable. Let's say another vendor adds a field that SolidFire doesn't
support. It would be available for entry and if the Disk Offering was
deployed to SolidFire, I would ignore that field.


On Mon, Jun 10, 2013 at 2:57 PM, Wei ZHOU  wrote:

> Mike,
>
> Glad to see this. This is what I have questioned about.
>
> I accepted John's and your opnion that hypervisor IOPS and storage IOPS are
> mutually exclusion. The way  you mentioned is a good way to go.
>
> A small question is, will burst IOPS only appear when storage device is
> SolidFire?
>
> -Wei
>
>
> 2013/6/10 Mike Tutkowski 
>
> > My thinking is that Min and Max are industry standard and Burst is a new
> > concept that could catch on.
> >
> >
> > On Mon, Jun 10, 2013 at 2:29 PM, John Burwell 
> wrote:
> >
> > > Wei,
> > >
> > > In this case, we can have the hypervisor or storage providing the
> quality
> > > of service guarantee.  Naively, it seems reasonable to separate
> > hypervisor
> > > and storage QoS parameters and enforce mutually exclusion.  Not only
> does
> > > this approach simplify a whole range of operations, it also avoids
> > > reconciling the data models.  The only question I have about the
> storage
> > > provision IOPS is whether or not "Burst IOPS" is an industry standard
> or
> > > vendor specific concept.
> > >
> > > Thanks,
> > > -John
> > >
> > > On Jun 10, 2013, at 3:59 PM, Wei ZHOU  wrote:
> > >
> > > > Mike,
> > > > I do not think users can select only one of them, as they are
> > implemented
> > > > on different sides.
> > > > Have you investigated the parameters other storage devices support,
> > > besides
> > > > min/max/burst IOPS? You'd better add all possible fields in your
> > > > implementation.
> > > >
> > > > What do you think about this?
> > > > Hypersivor IOPS is fixed, and there is a drop-down box which includes
> > all
> > > > supported storage vendors.
> > > > If users select "SolidFire", min/max/burst IOPS will appear.
> > > > If users select other vendors, relevant fields will appear.
> > > > Actually I still insist that it is better to add the storage-related
> > > fields
> > > > in another table.
> > > >
> > > > -Wei
> > > >
> > > >
> > > > 2013/6/10 Mike Tutkowski 
> > > >
> > > >> Here is my thinking:
> > > >>
> > > >> Two radio buttons (whatever we want to call them):
> > > >>
> > > >> 1) Hypervisor IOPS
> > > >> 2) Storage IOPS
> > > >>
> > > >> Leave them both un-checked by default.
> > > >>
> > > >> If the user checks one or the other, the relevant fields appear.
> > > >>
> > > >>
> > > >> On Mon, Jun 10, 2013 at 1:38 PM, Mike Tutkowski <
> > > >> mike.tutkow...@solidfire.com> wrote:
> > > >>
> > > >>> What do you think, Wei?
> > > >>>
> > > >>> Should we come up with a way for only one feature (yours or mine)
> to
> > be
> > > >>> used at a time on the new Disk Offering dialog?
> > > >>>
> > > >>> Since most storage-side provisioned IOPS don't break it down into
> > > >> separate
> > > >>> read and write categories, I think that's the way to go (only one
> > > feature
> > > >>> or the other).
> > > >>>
> > > >>> Any suggestions from a usability standpoint how we want to
> implement
> > > >> this?
> > > >>> It could be as simple as a radio button to turn on your feature and
> > > mine
> > > >>> off or vice versa.
> > > >>>
> > > >>> Thanks!
> > > >>>
> > > >>>
> > > >>> On Mon, Jun 10, 2013 at 1:33 PM, John Burwell 
> > > >> wrote:
> > > >>>
> > >  Mike,
> > > 
> > >  I agree -- I can't image a situation where you would want to use
> > IOPS
> > >  provisioned by both the hypervisor and storage.  There are two
> > points
> > > of
> > >  concern -- the UI and the management server.  We have to ensure
> that
> > > the
> > >  user can't create a VM from a compute/disk offering combination
> > where
> > >  hypervisor throttled I/O would contradict/conflict with storage
> > > >> provisioned
> > >  IOPS.  I think this functional conflict must be resolved in the
> > > >> management
> > >  server to ensure that API calls are properly validated with a UX
> > that
> > >  avoids user confusion.  Have Wei and you worked out an approach to

Re: [MERGE] disk_io_throttling to MASTER

[Mike Tutkowski]

Right...all of that makes sense to me, Edison.

I think John's concern with my patch file (which implements the approach
you outlined in your last paragraph) is that he didn't like the "attach"
command performing logic to create an SR if the SR isn't present.

He wanted a new hypervisor command to create the SR and he wanted this
invoked from the CS MS if the driver (or it could be the lifecycle object)
says it's managed.

We have at least one issue to deal with:

1) Will we allow hypervisor calls in the storage plug-in code?

If 'no', then the default storage plug-in is in violation of this
restriction.

This also means the "attach" hypervisor command needs to create the SR, if
need be (the way my patch is coded up already) or the management server has
to send a command to the hypervisor to create the SR if the driver needs it
(and the driver has to have some way to tell the CS MS to do this).

Re: [GSOC] NullPointerException when deployVM using GRE isolation method. Help me!

[Chiradeep Vittal]

Yes

On 6/10/13 1:12 PM, "Sebastien Goasguen"  wrote:

>
>On Jun 10, 2013, at 3:07 PM, Chiradeep Vittal
> wrote:
>
>> The check for the config is incorrect. The check should be whether the
>> network in the input parameter has the isolation method 'GRE'. You can
>>see
>> the canHandle method on how to check for this. Although, I don't see why
>> this check should even be necessary. The network will be associated with
>> the guru at design time.
>
>Chiradeep, that's a bug then ?
>
>> 
>> 
>> On 6/10/13 7:17 AM, "Nguyen Anh Tu"  wrote:
>> 
>>> Hi forks,
>>> 
>>> I'm trying OVS tunnel with XCP 1.6 and get error NullPointerException
>>>when
>>> executing deployVM.
>>> 
>>> I found this error starting from the below code.
>>> 
>>> *NetworkManagerImpl.java*
>>> 
>>> *NicProfile profile = guru.allocate(network, requested, vm); (1)*
>>>   if (isDefaultNic != null) {
>>>   profile.setDefaultNic(
>>> isDefaultNic);
>>>   }
>>> 
>>> *ExtenalGuestNetworkGuru.java*
>>> 
>>>   @Override
>>>  * public NicProfile allocate(Network config, NicProfile nic,
>>> VirtualMachineProfile vm) throws
>>> InsufficientVirtualNetworkCapcityException,
>>>   InsufficientAddressCapacityException* {
>>> 
>>>   if
>>> 
>>>(_networkModel.networkIsConfiguredForExternalNetworking(config.getDataCe
>>>nt
>>> erId(),
>>> config.getId()) && nic != null && nic.getRequestedIpv4() != null) {
>>>   throw new CloudRuntimeException("Does not support custom ip
>>> allocation at this time: " + nic);
>>>   }
>>> 
>>>   NicProfile profile = super.allocate(config, nic, vm);
>>> 
>>>   *boolean _isEnabled =
>>> 
>>>Boolean.parseBoolean(_configDao.getValue(Config.OvsTunnelNetwork.key()))
>>>;
>>> (2)
>>>   if (_isEnabled) {
>>>   return null;
>>>   }*
>>> 
>>>   if
>>> 
>>>(_networkModel.networkIsConfiguredForExternalNetworking(config.getDataCe
>>>nt
>>> erId(),
>>> config.getId())) {
>>>   profile.setStrategy(ReservationStrategy.Start);
>>>   /* We won't clear IP address, because router may set gateway
>>> as
>>> it IP, and it would be updated properly later */
>>>   //profile.setIp4Address(null);
>>>   profile.setGateway(null);
>>>   profile.setNetmask(null);
>>>   }
>>> 
>>>   return profile;
>>>   }*
>>> 
>>> *
>>> The return from (1) is NULL, because at (2) *sdn.ovs.controller* set to
>>> true. So profile = NULL and then we get NullPointerException error in
>>>the
>>> next step.
>>> 
>>> This error prevents me to deployVM using GRE isolation method. If I
>>>set *
>>> sdn.ovs.controller* = false, no error anymore but can't using GRE.
>>> 
>>> How can I fix this? Thanks for any help.
>>> 
>>> -- 
>>> 
>>> N.g.U.y.e.N.A.n.H.t.U
>> 
>

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[John Burwell]

Mike,

My concern becomes that we start ballooning the data model and user interface 
with a fields that are documented as, "If using SolidFire, then Burst IOPS is 
honored and foo and bar are not.  For solution X, Burst IOPS is ignored, but 
foo and bar apply."  It may have to hold until 4.3, but it seems like we need 
an extended data concept for storage drivers that allow them to define an 
additional set of properties, and persist them into the database as a JSON 
document.  Such an enhancement would also require some UI fanciness to consume 
the metadata provided by the driver and adjust the UI.  Would it be possible to 
defer Burst IOPS until 4.3 when we could address extended driver data in a 
holistic manner?

Thanks,
-John

On Jun 10, 2013, at 4:44 PM, Mike Tutkowski  
wrote:

> My thinking is that Min and Max are industry standard and Burst is a new
> concept that could catch on.
> 
> 
> On Mon, Jun 10, 2013 at 2:29 PM, John Burwell  wrote:
> 
>> Wei,
>> 
>> In this case, we can have the hypervisor or storage providing the quality
>> of service guarantee.  Naively, it seems reasonable to separate hypervisor
>> and storage QoS parameters and enforce mutually exclusion.  Not only does
>> this approach simplify a whole range of operations, it also avoids
>> reconciling the data models.  The only question I have about the storage
>> provision IOPS is whether or not "Burst IOPS" is an industry standard or
>> vendor specific concept.
>> 
>> Thanks,
>> -John
>> 
>> On Jun 10, 2013, at 3:59 PM, Wei ZHOU  wrote:
>> 
>>> Mike,
>>> I do not think users can select only one of them, as they are implemented
>>> on different sides.
>>> Have you investigated the parameters other storage devices support,
>> besides
>>> min/max/burst IOPS? You'd better add all possible fields in your
>>> implementation.
>>> 
>>> What do you think about this?
>>> Hypersivor IOPS is fixed, and there is a drop-down box which includes all
>>> supported storage vendors.
>>> If users select "SolidFire", min/max/burst IOPS will appear.
>>> If users select other vendors, relevant fields will appear.
>>> Actually I still insist that it is better to add the storage-related
>> fields
>>> in another table.
>>> 
>>> -Wei
>>> 
>>> 
>>> 2013/6/10 Mike Tutkowski 
>>> 
 Here is my thinking:
 
 Two radio buttons (whatever we want to call them):
 
 1) Hypervisor IOPS
 2) Storage IOPS
 
 Leave them both un-checked by default.
 
 If the user checks one or the other, the relevant fields appear.
 
 
 On Mon, Jun 10, 2013 at 1:38 PM, Mike Tutkowski <
 mike.tutkow...@solidfire.com> wrote:
 
> What do you think, Wei?
> 
> Should we come up with a way for only one feature (yours or mine) to be
> used at a time on the new Disk Offering dialog?
> 
> Since most storage-side provisioned IOPS don't break it down into
 separate
> read and write categories, I think that's the way to go (only one
>> feature
> or the other).
> 
> Any suggestions from a usability standpoint how we want to implement
 this?
> It could be as simple as a radio button to turn on your feature and
>> mine
> off or vice versa.
> 
> Thanks!
> 
> 
> On Mon, Jun 10, 2013 at 1:33 PM, John Burwell 
 wrote:
> 
>> Mike,
>> 
>> I agree -- I can't image a situation where you would want to use IOPS
>> provisioned by both the hypervisor and storage.  There are two points
>> of
>> concern -- the UI and the management server.  We have to ensure that
>> the
>> user can't create a VM from a compute/disk offering combination where
>> hypervisor throttled I/O would contradict/conflict with storage
 provisioned
>> IOPS.  I think this functional conflict must be resolved in the
 management
>> server to ensure that API calls are properly validated with a UX that
>> avoids user confusion.  Have Wei and you worked out an approach to
>> resolving this conflict?
>> 
>> Thanks,
>> -John
>> 
>> On Jun 10, 2013, at 3:24 PM, Mike Tutkowski <
 mike.tutkow...@solidfire.com>
>> wrote:
>> 
>>> Wei has sent me the screen shots.
>>> 
>>> I don't support Compute Offerings for 4.2, so that's not an issue
 here.
>>> 
>>> I do support Disk Offerings.
>>> 
>>> It looks like Wei has added four new fields to the Disk Offering.
>>> 
>>> I have added three (Min, Max, and Burst IOPS).
>>> 
>>> We just need to decide if we should toggle between his and mine.
>>> 
>>> I doubt a user would want to use both features at the same time.
>>> 
>>> 
>>> On Mon, Jun 10, 2013 at 12:30 PM, John Burwell 
>> wrote:
>>> 
 Mike,
 
 Have Wei and you figured out the system level as well (e.g. allowing
 either storage provisioned IOPS or hypervisor throttling, but no
 both)?
 
 Thanks,
 -John

Re: haproxy on VMWare systemVM template

[Chiradeep Vittal]

The jenkins build of the systemvm has been failing for a couple of days.
Can someone clean it up?

On 6/7/13 5:35 PM, "Chiradeep Vittal"  wrote:

>This is now done.
>http://s.apache.org/wy
>
>
>
>On 5/28/13 3:35 PM, "Chiradeep Vittal" 
>wrote:
>
>>Thanks. I'll wait for the i386 bits to land as well.
>>
>>On 5/28/13 3:07 PM, "Milamber"  wrote:
>>
>>>Hello Chiradeep,
>>>
>>>Please note, haproxy has been backported in Debian Wheezy (7.0):
>>>http://lists.debian.org/debian-backports-changes/2013/05/msg00050.html
>>>http://packages.debian.org/wheezy-backports/haproxy
>>>
>>>Milamber
>>>
>>>Le 11/05/2013 01:14, Chiradeep Vittal a ecrit :
 Fixed by fetching haproxy 1.4.8-1 from squeeze-backports

 On 5/9/13 4:16 PM, "Sheng Yang"  wrote:

> Don't know. We can use Ubuntu package for now if it possible.
>
> or just use sid packages if possible?
>
> dnsmasq version is 0.62, which is good enough for ipv6.
>
> --Sheng
>
>
> On Thu, May 9, 2013 at 4:04 PM, Chiradeep Vittal <
> chiradeep.vit...@citrix.com> wrote:
>
>> How old? When did it disappear?
>>
>> I propose using the Ubuntu  package.
>> In tools/appliance/definitions/systemvmtemplate/postinstall.sh
>>
>> wget
>>
>> 
>>http://security.ubuntu.com/ubuntu/pool/main/h/haproxy/haproxy_1.4.18-
>>0
>>u
>>bu
>> nt
>> u2.1_i386.deb
>>
>> dpkg -i haproxy_1.4.18-0ubuntu2.1_i386.deb
>>
>> Also do we know if the system vm template contains the version of
>> dnsmasq
>> that is known to work for ipv6 support?
>>
>> --
>> Chiradeep
>>
>> On 5/9/13 3:48 PM, "Sheng Yang"  wrote:
>>
>>> No idea. Probably we should just grab some old generated systemvm
>>>for
>> now.
>>> --Sheng
>>>
>>>
>>> On Thu, May 9, 2013 at 3:37 PM, Chiradeep Vittal <
>>> chiradeep.vit...@citrix.com> wrote:
>>>
 Should we use the Ubuntu package for now?

 On 5/9/13 2:03 PM, "Sheng Yang"  wrote:

> HAproxy is missing in Debian 7.0's repo, due to old maintainer is
 missing.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674447
> http://lists.debian.org/debian-qa/2013/04/msg00039.html
>
> The new maintainer took over it at Apr 20th, but there is no
>> schedule
 of
> recovering yet.
>
> That's why depends on everyday generated systemvm template is
 dangerous.
> --Sheng
>
>
> On Tue, Apr 23, 2013 at 12:09 AM, Rohit Yadav
>
 wrote:
>> On Mon, Apr 22, 2013 at 11:45 AM, Abhinandan Prateek <
>> agneya2...@hotmail.com
>>> wrote:
>>> The haproxy and port map services are not installed on VMWare
 system
>> VM
>>> template. Is the path used to create the templates different
>>>for
>> different
>>> Hypervisor templates ? I was under the assumption that the
>> services
>>> installed on all the system VM templates meant for different
>> hypervisors
>>> should be same ?
>>>
>> No? Pl. see tools/appliance/systemvmtemplate/postinstall.sh, if
>> it's
>> there
>> those pkgs will be installed.
>> For the template I created, I had built it with veewee on my
>> system
 and
>> then imported it in vmware fusion to install the vmware-tools.
>>
>> Cheers.
>>
>>
>>> -abhi
>>>

>>

>>>
>>
>

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[Mike Tutkowski]

Just to make sure I understand your request, are you looking to display Min
and Max (as long as Wei's feature is not in use), but not display Burst
IOPS?


On Mon, Jun 10, 2013 at 3:50 PM, John Burwell  wrote:

> Mike,
>
> My concern becomes that we start ballooning the data model and user
> interface with a fields that are documented as, "If using SolidFire, then
> Burst IOPS is honored and foo and bar are not.  For solution X, Burst IOPS
> is ignored, but foo and bar apply."  It may have to hold until 4.3, but it
> seems like we need an extended data concept for storage drivers that allow
> them to define an additional set of properties, and persist them into the
> database as a JSON document.  Such an enhancement would also require some
> UI fanciness to consume the metadata provided by the driver and adjust the
> UI.  Would it be possible to defer Burst IOPS until 4.3 when we could
> address extended driver data in a holistic manner?
>
> Thanks,
> -John
>
> On Jun 10, 2013, at 4:44 PM, Mike Tutkowski 
> wrote:
>
> > My thinking is that Min and Max are industry standard and Burst is a new
> > concept that could catch on.
> >
> >
> > On Mon, Jun 10, 2013 at 2:29 PM, John Burwell 
> wrote:
> >
> >> Wei,
> >>
> >> In this case, we can have the hypervisor or storage providing the
> quality
> >> of service guarantee.  Naively, it seems reasonable to separate
> hypervisor
> >> and storage QoS parameters and enforce mutually exclusion.  Not only
> does
> >> this approach simplify a whole range of operations, it also avoids
> >> reconciling the data models.  The only question I have about the storage
> >> provision IOPS is whether or not "Burst IOPS" is an industry standard or
> >> vendor specific concept.
> >>
> >> Thanks,
> >> -John
> >>
> >> On Jun 10, 2013, at 3:59 PM, Wei ZHOU  wrote:
> >>
> >>> Mike,
> >>> I do not think users can select only one of them, as they are
> implemented
> >>> on different sides.
> >>> Have you investigated the parameters other storage devices support,
> >> besides
> >>> min/max/burst IOPS? You'd better add all possible fields in your
> >>> implementation.
> >>>
> >>> What do you think about this?
> >>> Hypersivor IOPS is fixed, and there is a drop-down box which includes
> all
> >>> supported storage vendors.
> >>> If users select "SolidFire", min/max/burst IOPS will appear.
> >>> If users select other vendors, relevant fields will appear.
> >>> Actually I still insist that it is better to add the storage-related
> >> fields
> >>> in another table.
> >>>
> >>> -Wei
> >>>
> >>>
> >>> 2013/6/10 Mike Tutkowski 
> >>>
>  Here is my thinking:
> 
>  Two radio buttons (whatever we want to call them):
> 
>  1) Hypervisor IOPS
>  2) Storage IOPS
> 
>  Leave them both un-checked by default.
> 
>  If the user checks one or the other, the relevant fields appear.
> 
> 
>  On Mon, Jun 10, 2013 at 1:38 PM, Mike Tutkowski <
>  mike.tutkow...@solidfire.com> wrote:
> 
> > What do you think, Wei?
> >
> > Should we come up with a way for only one feature (yours or mine) to
> be
> > used at a time on the new Disk Offering dialog?
> >
> > Since most storage-side provisioned IOPS don't break it down into
>  separate
> > read and write categories, I think that's the way to go (only one
> >> feature
> > or the other).
> >
> > Any suggestions from a usability standpoint how we want to implement
>  this?
> > It could be as simple as a radio button to turn on your feature and
> >> mine
> > off or vice versa.
> >
> > Thanks!
> >
> >
> > On Mon, Jun 10, 2013 at 1:33 PM, John Burwell 
>  wrote:
> >
> >> Mike,
> >>
> >> I agree -- I can't image a situation where you would want to use
> IOPS
> >> provisioned by both the hypervisor and storage.  There are two
> points
> >> of
> >> concern -- the UI and the management server.  We have to ensure that
> >> the
> >> user can't create a VM from a compute/disk offering combination
> where
> >> hypervisor throttled I/O would contradict/conflict with storage
>  provisioned
> >> IOPS.  I think this functional conflict must be resolved in the
>  management
> >> server to ensure that API calls are properly validated with a UX
> that
> >> avoids user confusion.  Have Wei and you worked out an approach to
> >> resolving this conflict?
> >>
> >> Thanks,
> >> -John
> >>
> >> On Jun 10, 2013, at 3:24 PM, Mike Tutkowski <
>  mike.tutkow...@solidfire.com>
> >> wrote:
> >>
> >>> Wei has sent me the screen shots.
> >>>
> >>> I don't support Compute Offerings for 4.2, so that's not an issue
>  here.
> >>>
> >>> I do support Disk Offerings.
> >>>
> >>> It looks like Wei has added four new fields to the Disk Offering.
> >>>
> >>> I have added three (Min, Max, and Burst IOPS).
> >>>
> >>> We just need to decide if

[REVIEW] Merging of VMSync improvement into master

[Kelven Yang]

Hi there,

Alex Huang and I are targeting to finish the debugging process on VMsync 
improvement by the end of this week. I'd like to encourage those who are 
interested or having concerns about this  project to review it as soon as 
possible on branch vmsync. We are going to propose the official merge request 
soon after it has passed our internal test.

Some details have been posted to wiki a while ago at 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+VMSync+improvement. 
 Here is a summary about this change.


  1.  We changed the underlying VM state sync modeling.

For those who are familiar with the old Microsoft COM model, they may recall 
"Free threading model" and "Thread-apartment model",  VM state sync modeling 
change is similar to switching from free-threading to thread-apartment 
modeling.  Previously, VM state changes are reported and processed in 
management server in a "free-threading" fashion, regardless  whether or not 
there is active process with the subject VM, the state sync process is always 
executed in place.  This approach has issues with the concurrency complexity by 
nature, since all sync-process has been concentrated into one place and caused 
complex code logic that is hard to change and maintain.

A major modeling shift is introduced in this change, we now switch to an 
approach which we can call it "job-apartment" model, comparable to Microsoft's 
COM "thread-apartment model", that is, making the sync logic within the process 
context and de-centralize it across the board.  This approach can simplify VM 
state sync logic individually and leave the complexity to underlying framework, 
which in the future, the framework can be optimized separately without 
affecting business layer (separating of concerns at architecture level)

2. De-couple hypervisor resource agent from managing VM state in Cloud layer

We also changed the way on how resource agent is involved in the overall VM 
state sync process. Previously, resource agent needs to participate VM state 
management in the Cloud layer closely, this requirement is removed and resource 
agent is no longer required to help maintain "delta" state in the overall VM 
state management, all it needs is to report what it knows about the VM state at 
virtualization layer, leaving all the handling to CloudStack management server.

The reason for this change is to simplify the architecture between agent 
resource and management server, de-coupling in this way can lower the 
requirement for developers to write a new hypervisor resource agent and also 
give room for management server developers to optimize sync logic 
independently. (Again, separating of concerns at architecture level)


3. Job framework has been improved

To make the proposal possible, job framework has been refactored to support 
more explicit management of jobs,  job joining, wake-up scheduling and 
serializing job execution has been added together with a topic-based message 
bus facility.

4. Compile-time strong typing of Java generic usage in VirtualMachineManagerImpl

Job scheduling change require more flexible run-time handling, however, 
previously VirtualMachineManagerImpl has a heavy-weight usage of Java generic 
to take advantage of compile-time strong typing provided by Java, this has 
brought some troubles with object serialization the occurs between boundaries 
of "job-apartments", VirtualMachineManagerImpl has been refactored because of 
that.

Flames and Comment? all are welcome.

Kelven

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[Mike Tutkowski]

More generally speaking, you're looking to remove Burst IOPS from
CloudStack for 4.2, but we would keep Min and Max (and they would be
displayed in the Disk Offering dialog as I've proposed)?


On Mon, Jun 10, 2013 at 3:52 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Just to make sure I understand your request, are you looking to display
> Min and Max (as long as Wei's feature is not in use), but not display Burst
> IOPS?
>
>
> On Mon, Jun 10, 2013 at 3:50 PM, John Burwell  wrote:
>
>> Mike,
>>
>> My concern becomes that we start ballooning the data model and user
>> interface with a fields that are documented as, "If using SolidFire, then
>> Burst IOPS is honored and foo and bar are not.  For solution X, Burst IOPS
>> is ignored, but foo and bar apply."  It may have to hold until 4.3, but it
>> seems like we need an extended data concept for storage drivers that allow
>> them to define an additional set of properties, and persist them into the
>> database as a JSON document.  Such an enhancement would also require some
>> UI fanciness to consume the metadata provided by the driver and adjust the
>> UI.  Would it be possible to defer Burst IOPS until 4.3 when we could
>> address extended driver data in a holistic manner?
>>
>> Thanks,
>> -John
>>
>> On Jun 10, 2013, at 4:44 PM, Mike Tutkowski 
>> wrote:
>>
>> > My thinking is that Min and Max are industry standard and Burst is a new
>> > concept that could catch on.
>> >
>> >
>> > On Mon, Jun 10, 2013 at 2:29 PM, John Burwell 
>> wrote:
>> >
>> >> Wei,
>> >>
>> >> In this case, we can have the hypervisor or storage providing the
>> quality
>> >> of service guarantee.  Naively, it seems reasonable to separate
>> hypervisor
>> >> and storage QoS parameters and enforce mutually exclusion.  Not only
>> does
>> >> this approach simplify a whole range of operations, it also avoids
>> >> reconciling the data models.  The only question I have about the
>> storage
>> >> provision IOPS is whether or not "Burst IOPS" is an industry standard
>> or
>> >> vendor specific concept.
>> >>
>> >> Thanks,
>> >> -John
>> >>
>> >> On Jun 10, 2013, at 3:59 PM, Wei ZHOU  wrote:
>> >>
>> >>> Mike,
>> >>> I do not think users can select only one of them, as they are
>> implemented
>> >>> on different sides.
>> >>> Have you investigated the parameters other storage devices support,
>> >> besides
>> >>> min/max/burst IOPS? You'd better add all possible fields in your
>> >>> implementation.
>> >>>
>> >>> What do you think about this?
>> >>> Hypersivor IOPS is fixed, and there is a drop-down box which includes
>> all
>> >>> supported storage vendors.
>> >>> If users select "SolidFire", min/max/burst IOPS will appear.
>> >>> If users select other vendors, relevant fields will appear.
>> >>> Actually I still insist that it is better to add the storage-related
>> >> fields
>> >>> in another table.
>> >>>
>> >>> -Wei
>> >>>
>> >>>
>> >>> 2013/6/10 Mike Tutkowski 
>> >>>
>>  Here is my thinking:
>> 
>>  Two radio buttons (whatever we want to call them):
>> 
>>  1) Hypervisor IOPS
>>  2) Storage IOPS
>> 
>>  Leave them both un-checked by default.
>> 
>>  If the user checks one or the other, the relevant fields appear.
>> 
>> 
>>  On Mon, Jun 10, 2013 at 1:38 PM, Mike Tutkowski <
>>  mike.tutkow...@solidfire.com> wrote:
>> 
>> > What do you think, Wei?
>> >
>> > Should we come up with a way for only one feature (yours or mine)
>> to be
>> > used at a time on the new Disk Offering dialog?
>> >
>> > Since most storage-side provisioned IOPS don't break it down into
>>  separate
>> > read and write categories, I think that's the way to go (only one
>> >> feature
>> > or the other).
>> >
>> > Any suggestions from a usability standpoint how we want to implement
>>  this?
>> > It could be as simple as a radio button to turn on your feature and
>> >> mine
>> > off or vice versa.
>> >
>> > Thanks!
>> >
>> >
>> > On Mon, Jun 10, 2013 at 1:33 PM, John Burwell 
>>  wrote:
>> >
>> >> Mike,
>> >>
>> >> I agree -- I can't image a situation where you would want to use
>> IOPS
>> >> provisioned by both the hypervisor and storage.  There are two
>> points
>> >> of
>> >> concern -- the UI and the management server.  We have to ensure
>> that
>> >> the
>> >> user can't create a VM from a compute/disk offering combination
>> where
>> >> hypervisor throttled I/O would contradict/conflict with storage
>>  provisioned
>> >> IOPS.  I think this functional conflict must be resolved in the
>>  management
>> >> server to ensure that API calls are properly validated with a UX
>> that
>> >> avoids user confusion.  Have Wei and you worked out an approach to
>> >> resolving this conflict?
>> >>
>> >> Thanks,
>> >> -John
>> >>
>> >> On Jun 10, 2013, at 3:24 PM, Mike Tutkowski <
>>  mike.tutkow

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[John Burwell]

Mike,

I am asking whether or not we can defer the entire notion of Burst IOPS in the 
data model (e.g. the driver could default it to Max IOPS when configuring a SAN 
volume) for 4.2.  In 4.3, we design a facility for extended driver data that 
would allow drivers to expose these implementation-specific parameters in a 
generic manner.  Using this facility, we would enhance the SolidFire driver to 
support Burst IOPS configuration.

Thanks,
-John

On Jun 10, 2013, at 5:52 PM, Mike Tutkowski  
wrote:

> Just to make sure I understand your request, are you looking to display Min
> and Max (as long as Wei's feature is not in use), but not display Burst
> IOPS?
> 
> 
> On Mon, Jun 10, 2013 at 3:50 PM, John Burwell  wrote:
> 
>> Mike,
>> 
>> My concern becomes that we start ballooning the data model and user
>> interface with a fields that are documented as, "If using SolidFire, then
>> Burst IOPS is honored and foo and bar are not.  For solution X, Burst IOPS
>> is ignored, but foo and bar apply."  It may have to hold until 4.3, but it
>> seems like we need an extended data concept for storage drivers that allow
>> them to define an additional set of properties, and persist them into the
>> database as a JSON document.  Such an enhancement would also require some
>> UI fanciness to consume the metadata provided by the driver and adjust the
>> UI.  Would it be possible to defer Burst IOPS until 4.3 when we could
>> address extended driver data in a holistic manner?
>> 
>> Thanks,
>> -John
>> 
>> On Jun 10, 2013, at 4:44 PM, Mike Tutkowski 
>> wrote:
>> 
>>> My thinking is that Min and Max are industry standard and Burst is a new
>>> concept that could catch on.
>>> 
>>> 
>>> On Mon, Jun 10, 2013 at 2:29 PM, John Burwell 
>> wrote:
>>> 
 Wei,
 
 In this case, we can have the hypervisor or storage providing the
>> quality
 of service guarantee.  Naively, it seems reasonable to separate
>> hypervisor
 and storage QoS parameters and enforce mutually exclusion.  Not only
>> does
 this approach simplify a whole range of operations, it also avoids
 reconciling the data models.  The only question I have about the storage
 provision IOPS is whether or not "Burst IOPS" is an industry standard or
 vendor specific concept.
 
 Thanks,
 -John
 
 On Jun 10, 2013, at 3:59 PM, Wei ZHOU  wrote:
 
> Mike,
> I do not think users can select only one of them, as they are
>> implemented
> on different sides.
> Have you investigated the parameters other storage devices support,
 besides
> min/max/burst IOPS? You'd better add all possible fields in your
> implementation.
> 
> What do you think about this?
> Hypersivor IOPS is fixed, and there is a drop-down box which includes
>> all
> supported storage vendors.
> If users select "SolidFire", min/max/burst IOPS will appear.
> If users select other vendors, relevant fields will appear.
> Actually I still insist that it is better to add the storage-related
 fields
> in another table.
> 
> -Wei
> 
> 
> 2013/6/10 Mike Tutkowski 
> 
>> Here is my thinking:
>> 
>> Two radio buttons (whatever we want to call them):
>> 
>> 1) Hypervisor IOPS
>> 2) Storage IOPS
>> 
>> Leave them both un-checked by default.
>> 
>> If the user checks one or the other, the relevant fields appear.
>> 
>> 
>> On Mon, Jun 10, 2013 at 1:38 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>> 
>>> What do you think, Wei?
>>> 
>>> Should we come up with a way for only one feature (yours or mine) to
>> be
>>> used at a time on the new Disk Offering dialog?
>>> 
>>> Since most storage-side provisioned IOPS don't break it down into
>> separate
>>> read and write categories, I think that's the way to go (only one
 feature
>>> or the other).
>>> 
>>> Any suggestions from a usability standpoint how we want to implement
>> this?
>>> It could be as simple as a radio button to turn on your feature and
 mine
>>> off or vice versa.
>>> 
>>> Thanks!
>>> 
>>> 
>>> On Mon, Jun 10, 2013 at 1:33 PM, John Burwell 
>> wrote:
>>> 
 Mike,
 
 I agree -- I can't image a situation where you would want to use
>> IOPS
 provisioned by both the hypervisor and storage.  There are two
>> points
 of
 concern -- the UI and the management server.  We have to ensure that
 the
 user can't create a VM from a compute/disk offering combination
>> where
 hypervisor throttled I/O would contradict/conflict with storage
>> provisioned
 IOPS.  I think this functional conflict must be resolved in the
>> management
 server to ensure that API calls are properly validated with a UX
>> that
 avoids user confusion.  Have Wei and you worked out an approach to
 

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[John Burwell]

Mike,

Yes.  I realize my other reply did not explicitly state leaving the Min and Max 
IOPS fields in the data model as these seem to generic terms across storage 
implementations.

Thanks,
-John

On Jun 10, 2013, at 5:57 PM, Mike Tutkowski  
wrote:

> More generally speaking, you're looking to remove Burst IOPS from
> CloudStack for 4.2, but we would keep Min and Max (and they would be
> displayed in the Disk Offering dialog as I've proposed)?
> 
> 
> On Mon, Jun 10, 2013 at 3:52 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
> 
>> Just to make sure I understand your request, are you looking to display
>> Min and Max (as long as Wei's feature is not in use), but not display Burst
>> IOPS?
>> 
>> 
>> On Mon, Jun 10, 2013 at 3:50 PM, John Burwell  wrote:
>> 
>>> Mike,
>>> 
>>> My concern becomes that we start ballooning the data model and user
>>> interface with a fields that are documented as, "If using SolidFire, then
>>> Burst IOPS is honored and foo and bar are not.  For solution X, Burst IOPS
>>> is ignored, but foo and bar apply."  It may have to hold until 4.3, but it
>>> seems like we need an extended data concept for storage drivers that allow
>>> them to define an additional set of properties, and persist them into the
>>> database as a JSON document.  Such an enhancement would also require some
>>> UI fanciness to consume the metadata provided by the driver and adjust the
>>> UI.  Would it be possible to defer Burst IOPS until 4.3 when we could
>>> address extended driver data in a holistic manner?
>>> 
>>> Thanks,
>>> -John
>>> 
>>> On Jun 10, 2013, at 4:44 PM, Mike Tutkowski 
>>> wrote:
>>> 
 My thinking is that Min and Max are industry standard and Burst is a new
 concept that could catch on.
 
 
 On Mon, Jun 10, 2013 at 2:29 PM, John Burwell 
>>> wrote:
 
> Wei,
> 
> In this case, we can have the hypervisor or storage providing the
>>> quality
> of service guarantee.  Naively, it seems reasonable to separate
>>> hypervisor
> and storage QoS parameters and enforce mutually exclusion.  Not only
>>> does
> this approach simplify a whole range of operations, it also avoids
> reconciling the data models.  The only question I have about the
>>> storage
> provision IOPS is whether or not "Burst IOPS" is an industry standard
>>> or
> vendor specific concept.
> 
> Thanks,
> -John
> 
> On Jun 10, 2013, at 3:59 PM, Wei ZHOU  wrote:
> 
>> Mike,
>> I do not think users can select only one of them, as they are
>>> implemented
>> on different sides.
>> Have you investigated the parameters other storage devices support,
> besides
>> min/max/burst IOPS? You'd better add all possible fields in your
>> implementation.
>> 
>> What do you think about this?
>> Hypersivor IOPS is fixed, and there is a drop-down box which includes
>>> all
>> supported storage vendors.
>> If users select "SolidFire", min/max/burst IOPS will appear.
>> If users select other vendors, relevant fields will appear.
>> Actually I still insist that it is better to add the storage-related
> fields
>> in another table.
>> 
>> -Wei
>> 
>> 
>> 2013/6/10 Mike Tutkowski 
>> 
>>> Here is my thinking:
>>> 
>>> Two radio buttons (whatever we want to call them):
>>> 
>>> 1) Hypervisor IOPS
>>> 2) Storage IOPS
>>> 
>>> Leave them both un-checked by default.
>>> 
>>> If the user checks one or the other, the relevant fields appear.
>>> 
>>> 
>>> On Mon, Jun 10, 2013 at 1:38 PM, Mike Tutkowski <
>>> mike.tutkow...@solidfire.com> wrote:
>>> 
 What do you think, Wei?
 
 Should we come up with a way for only one feature (yours or mine)
>>> to be
 used at a time on the new Disk Offering dialog?
 
 Since most storage-side provisioned IOPS don't break it down into
>>> separate
 read and write categories, I think that's the way to go (only one
> feature
 or the other).
 
 Any suggestions from a usability standpoint how we want to implement
>>> this?
 It could be as simple as a radio button to turn on your feature and
> mine
 off or vice versa.
 
 Thanks!
 
 
 On Mon, Jun 10, 2013 at 1:33 PM, John Burwell 
>>> wrote:
 
> Mike,
> 
> I agree -- I can't image a situation where you would want to use
>>> IOPS
> provisioned by both the hypervisor and storage.  There are two
>>> points
> of
> concern -- the UI and the management server.  We have to ensure
>>> that
> the
> user can't create a VM from a compute/disk offering combination
>>> where
> hypervisor throttled I/O would contradict/conflict with storage
>>> provisioned
> IOPS.  I think this functional conflict must be resolved in the
>>

Re: [MERGE] disk_io_throttling to MASTER

[Mike Tutkowski]

I see the unmanaged() method in the life cycle object now (didn't know this
was there before). I also notice it is not being invoked anywhere.

I can make use of this method to help the storage framework determine if it
should send a message to the hypervisor in use to create an SR (or
datastore for VMware).

By the way, if I set the StoragePoolType of my plug-in to Iscsi, exceptions
are thrown. I think CloudStack is trying to handle my storage in a way it
shouldn't when that value is used.

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[Mike Tutkowski]

I am pretty sure it is not a blocker for me to drop Burst IOPS. Let me run
that past Product Management, but I don't think it's a problem.


On Mon, Jun 10, 2013 at 4:01 PM, John Burwell  wrote:

> Mike,
>
> Yes.  I realize my other reply did not explicitly state leaving the Min
> and Max IOPS fields in the data model as these seem to generic terms across
> storage implementations.
>
> Thanks,
> -John
>
> On Jun 10, 2013, at 5:57 PM, Mike Tutkowski 
> wrote:
>
> > More generally speaking, you're looking to remove Burst IOPS from
> > CloudStack for 4.2, but we would keep Min and Max (and they would be
> > displayed in the Disk Offering dialog as I've proposed)?
> >
> >
> > On Mon, Jun 10, 2013 at 3:52 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> >> Just to make sure I understand your request, are you looking to display
> >> Min and Max (as long as Wei's feature is not in use), but not display
> Burst
> >> IOPS?
> >>
> >>
> >> On Mon, Jun 10, 2013 at 3:50 PM, John Burwell 
> wrote:
> >>
> >>> Mike,
> >>>
> >>> My concern becomes that we start ballooning the data model and user
> >>> interface with a fields that are documented as, "If using SolidFire,
> then
> >>> Burst IOPS is honored and foo and bar are not.  For solution X, Burst
> IOPS
> >>> is ignored, but foo and bar apply."  It may have to hold until 4.3,
> but it
> >>> seems like we need an extended data concept for storage drivers that
> allow
> >>> them to define an additional set of properties, and persist them into
> the
> >>> database as a JSON document.  Such an enhancement would also require
> some
> >>> UI fanciness to consume the metadata provided by the driver and adjust
> the
> >>> UI.  Would it be possible to defer Burst IOPS until 4.3 when we could
> >>> address extended driver data in a holistic manner?
> >>>
> >>> Thanks,
> >>> -John
> >>>
> >>> On Jun 10, 2013, at 4:44 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com>
> >>> wrote:
> >>>
>  My thinking is that Min and Max are industry standard and Burst is a
> new
>  concept that could catch on.
> 
> 
>  On Mon, Jun 10, 2013 at 2:29 PM, John Burwell 
> >>> wrote:
> 
> > Wei,
> >
> > In this case, we can have the hypervisor or storage providing the
> >>> quality
> > of service guarantee.  Naively, it seems reasonable to separate
> >>> hypervisor
> > and storage QoS parameters and enforce mutually exclusion.  Not only
> >>> does
> > this approach simplify a whole range of operations, it also avoids
> > reconciling the data models.  The only question I have about the
> >>> storage
> > provision IOPS is whether or not "Burst IOPS" is an industry standard
> >>> or
> > vendor specific concept.
> >
> > Thanks,
> > -John
> >
> > On Jun 10, 2013, at 3:59 PM, Wei ZHOU  wrote:
> >
> >> Mike,
> >> I do not think users can select only one of them, as they are
> >>> implemented
> >> on different sides.
> >> Have you investigated the parameters other storage devices support,
> > besides
> >> min/max/burst IOPS? You'd better add all possible fields in your
> >> implementation.
> >>
> >> What do you think about this?
> >> Hypersivor IOPS is fixed, and there is a drop-down box which
> includes
> >>> all
> >> supported storage vendors.
> >> If users select "SolidFire", min/max/burst IOPS will appear.
> >> If users select other vendors, relevant fields will appear.
> >> Actually I still insist that it is better to add the storage-related
> > fields
> >> in another table.
> >>
> >> -Wei
> >>
> >>
> >> 2013/6/10 Mike Tutkowski 
> >>
> >>> Here is my thinking:
> >>>
> >>> Two radio buttons (whatever we want to call them):
> >>>
> >>> 1) Hypervisor IOPS
> >>> 2) Storage IOPS
> >>>
> >>> Leave them both un-checked by default.
> >>>
> >>> If the user checks one or the other, the relevant fields appear.
> >>>
> >>>
> >>> On Mon, Jun 10, 2013 at 1:38 PM, Mike Tutkowski <
> >>> mike.tutkow...@solidfire.com> wrote:
> >>>
>  What do you think, Wei?
> 
>  Should we come up with a way for only one feature (yours or mine)
> >>> to be
>  used at a time on the new Disk Offering dialog?
> 
>  Since most storage-side provisioned IOPS don't break it down into
> >>> separate
>  read and write categories, I think that's the way to go (only one
> > feature
>  or the other).
> 
>  Any suggestions from a usability standpoint how we want to
> implement
> >>> this?
>  It could be as simple as a radio button to turn on your feature
> and
> > mine
>  off or vice versa.
> 
>  Thanks!
> 
> 
>  On Mon, Jun 10, 2013 at 1:33 PM, John Burwell  >
> >>> wrote:
> 
> > Mike,
> >
> > I agree -- I can't imag

Re: [MERGE] disk_io_throttling to MASTER (Second Round)

[John Burwell]

Mike,

From a CloudStack perspective, it will keep implementation specific concepts 
from the base data model, and provide a great test case to develop a mechanism 
to capture this information in 4.3.  Ideally, I want CloudStack to exploit 
these implementation specific features.  I just want to provide a facility to 
manage that data that does not leak across implementations.

Thanks,
-John

On Jun 10, 2013, at 6:07 PM, Mike Tutkowski  
wrote:

> I am pretty sure it is not a blocker for me to drop Burst IOPS. Let me run
> that past Product Management, but I don't think it's a problem.
> 
> 
> On Mon, Jun 10, 2013 at 4:01 PM, John Burwell  wrote:
> 
>> Mike,
>> 
>> Yes.  I realize my other reply did not explicitly state leaving the Min
>> and Max IOPS fields in the data model as these seem to generic terms across
>> storage implementations.
>> 
>> Thanks,
>> -John
>> 
>> On Jun 10, 2013, at 5:57 PM, Mike Tutkowski 
>> wrote:
>> 
>>> More generally speaking, you're looking to remove Burst IOPS from
>>> CloudStack for 4.2, but we would keep Min and Max (and they would be
>>> displayed in the Disk Offering dialog as I've proposed)?
>>> 
>>> 
>>> On Mon, Jun 10, 2013 at 3:52 PM, Mike Tutkowski <
>>> mike.tutkow...@solidfire.com> wrote:
>>> 
 Just to make sure I understand your request, are you looking to display
 Min and Max (as long as Wei's feature is not in use), but not display
>> Burst
 IOPS?
 
 
 On Mon, Jun 10, 2013 at 3:50 PM, John Burwell 
>> wrote:
 
> Mike,
> 
> My concern becomes that we start ballooning the data model and user
> interface with a fields that are documented as, "If using SolidFire,
>> then
> Burst IOPS is honored and foo and bar are not.  For solution X, Burst
>> IOPS
> is ignored, but foo and bar apply."  It may have to hold until 4.3,
>> but it
> seems like we need an extended data concept for storage drivers that
>> allow
> them to define an additional set of properties, and persist them into
>> the
> database as a JSON document.  Such an enhancement would also require
>> some
> UI fanciness to consume the metadata provided by the driver and adjust
>> the
> UI.  Would it be possible to defer Burst IOPS until 4.3 when we could
> address extended driver data in a holistic manner?
> 
> Thanks,
> -John
> 
> On Jun 10, 2013, at 4:44 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com>
> wrote:
> 
>> My thinking is that Min and Max are industry standard and Burst is a
>> new
>> concept that could catch on.
>> 
>> 
>> On Mon, Jun 10, 2013 at 2:29 PM, John Burwell 
> wrote:
>> 
>>> Wei,
>>> 
>>> In this case, we can have the hypervisor or storage providing the
> quality
>>> of service guarantee.  Naively, it seems reasonable to separate
> hypervisor
>>> and storage QoS parameters and enforce mutually exclusion.  Not only
> does
>>> this approach simplify a whole range of operations, it also avoids
>>> reconciling the data models.  The only question I have about the
> storage
>>> provision IOPS is whether or not "Burst IOPS" is an industry standard
> or
>>> vendor specific concept.
>>> 
>>> Thanks,
>>> -John
>>> 
>>> On Jun 10, 2013, at 3:59 PM, Wei ZHOU  wrote:
>>> 
 Mike,
 I do not think users can select only one of them, as they are
> implemented
 on different sides.
 Have you investigated the parameters other storage devices support,
>>> besides
 min/max/burst IOPS? You'd better add all possible fields in your
 implementation.
 
 What do you think about this?
 Hypersivor IOPS is fixed, and there is a drop-down box which
>> includes
> all
 supported storage vendors.
 If users select "SolidFire", min/max/burst IOPS will appear.
 If users select other vendors, relevant fields will appear.
 Actually I still insist that it is better to add the storage-related
>>> fields
 in another table.
 
 -Wei
 
 
 2013/6/10 Mike Tutkowski 
 
> Here is my thinking:
> 
> Two radio buttons (whatever we want to call them):
> 
> 1) Hypervisor IOPS
> 2) Storage IOPS
> 
> Leave them both un-checked by default.
> 
> If the user checks one or the other, the relevant fields appear.
> 
> 
> On Mon, Jun 10, 2013 at 1:38 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
> 
>> What do you think, Wei?
>> 
>> Should we come up with a way for only one feature (yours or mine)
> to be
>> used at a time on the new Disk Offering dialog?
>> 
>> Since most storage-side provisioned IOPS don't break it down into
> separate
>> read and write categories

Re: [MERGE] disk_io_throttling to MASTER

[Mike Tutkowski]

That's a good point about the "managed" property being storable in the
storage_pool_details table. We don't need another column for it in the
storage_pool table. In the current url field is where this kind of
information can be passed along and it can be stored in the
storage_pool_details table, if the plug-in wants to do so.

Let's decide on how the hypervisor code should operate, though. Should we
pass in info to the "attach" command to have it create an SR if need be?
This is sort of how I did it in the patch code I submitted (but I used the
StoragePoolType.Dynamic field, which we don't have to use).

Re: Review Request: The equals method checks type against Pair

[Alex Huang]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11752/#review21676
---

Ship it!


Commit ID on master: a1a68ed0c4b722f6f83733d0b110debde2a1041e

- Alex Huang


On June 8, 2013, 9:12 p.m., Laszlo Hornyak wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11752/
> ---
> 
> (Updated June 8, 2013, 9:12 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Description
> ---
> 
> The equals method checks type against Pair - may be a copy-paste error
> 
> 
> Diffs
> -
> 
>   utils/src/com/cloud/utils/Ternary.java fee69ee 
>   utils/test/com/cloud/utils/TernaryTest.java PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/11752/diff/
> 
> 
> Testing
> ---
> 
> Test included
> 
> 
> Thanks,
> 
> Laszlo Hornyak
> 
>

RE: [MERGE] disk_io_throttling to MASTER

[Edison Su]

> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Monday, June 10, 2013 4:07 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [MERGE] disk_io_throttling to MASTER
> 
> That's a good point about the "managed" property being storable in the
> storage_pool_details table. We don't need another column for it in the
> storage_pool table. In the current url field is where this kind of information
> can be passed along and it can be stored in the storage_pool_details table, if
> the plug-in wants to do so.

+1. CreateStoragePoolCmd->details field is the place to pass extra info about a 
storage pool to storage provider.

> 
> Let's decide on how the hypervisor code should operate, though. Should we
> pass in info to the "attach" command to have it create an SR if need be?
> This is sort of how I did it in the patch code I submitted (but I used the
> StoragePoolType.Dynamic field, which we don't have to use).

Master branch doesn't carry a VolumeTO in attach command, which means, there is 
no place for storage provider to pass down some extra info to hypervisor 
resource.
While on object_store branch, it has the place to hook up with storage provider.
So there are two options:
1. Use your StoragePoolType.Dynamic as it is, and merge into master branch. 
After your patch is merged, and also object_store branch is merged, then we can 
remove StoragePoolType.Dynamic totally.
2. Rebase your patch on object_store branch, merge your patch after 
object_store. It will take extra time for you, I don't think it's worth the 
effort though, as I can consolidate your patch with object_store during 
object_store merge into master.

So I'd prefer option 1, as you only did few line of changes on the mgt server 
common code(regardless of iops), it should be easy for me to consolidate your 
patch with object_store branch.

Re: Review Request: use commons-lang StringUtils

[Alex Huang]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11767/#review21678
---


The patch did not apply cleanly.  Please resubmit.  Since you have to resubmit 
anyways, I think why not just change all of the code to use the commons.lang 
version.  I see no point in keeping the method in StringUtils if it's 
replaceable by one in a standard library.


- Alex Huang


On June 9, 2013, 7:47 p.m., Laszlo Hornyak wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11767/
> ---
> 
> (Updated June 9, 2013, 7:47 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Description
> ---
> 
> commons-lang is already a transitive dependency of the utils project, which 
> allows removing some duplicated functionality.
> This patch replaces StringUtils.join(String, Object...) with it's 
> commons-lang counterpart.
> It also replaces calls to String join(Iterable, String) in 
> cases where an array is already exist and it is only wrapped into a List.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/storage/s3/S3ManagerImpl.java 61e5573 
>   
> services/secondary-storage/src/org/apache/cloudstack/storage/resource/NfsSecondaryStorageResource.java
>  e7fa5b2 
>   utils/src/com/cloud/utils/S3Utils.java b7273a1 
>   utils/src/com/cloud/utils/StringUtils.java 14ff4b1 
>   utils/test/com/cloud/utils/StringUtilsTest.java 3c162c7 
> 
> Diff: https://reviews.apache.org/r/11767/diff/
> 
> 
> Testing
> ---
> 
> - Unit test added
> 
> 
> Thanks,
> 
> Laszlo Hornyak
> 
>

Re: [GSOC] NullPointerException when deployVM using GRE isolation method. Help me!

[Nguyen Anh Tu]

Hi,

I'll look around this bug.


2013/6/11 Chiradeep Vittal 

> Yes
>
> On 6/10/13 1:12 PM, "Sebastien Goasguen"  wrote:
>
> >
> >On Jun 10, 2013, at 3:07 PM, Chiradeep Vittal
> > wrote:
> >
> >> The check for the config is incorrect. The check should be whether the
> >> network in the input parameter has the isolation method 'GRE'. You can
> >>see
> >> the canHandle method on how to check for this. Although, I don't see why
> >> this check should even be necessary. The network will be associated with
> >> the guru at design time.
> >
> >Chiradeep, that's a bug then ?
> >
> >>
> >>
> >> On 6/10/13 7:17 AM, "Nguyen Anh Tu"  wrote:
> >>
> >>> Hi forks,
> >>>
> >>> I'm trying OVS tunnel with XCP 1.6 and get error NullPointerException
> >>>when
> >>> executing deployVM.
> >>>
> >>> I found this error starting from the below code.
> >>>
> >>> *NetworkManagerImpl.java*
> >>>
> >>> *NicProfile profile = guru.allocate(network, requested, vm); (1)*
> >>>   if (isDefaultNic != null) {
> >>>   profile.setDefaultNic(
> >>> isDefaultNic);
> >>>   }
> >>>
> >>> *ExtenalGuestNetworkGuru.java*
> >>>
> >>>   @Override
> >>>  * public NicProfile allocate(Network config, NicProfile nic,
> >>> VirtualMachineProfile vm) throws
> >>> InsufficientVirtualNetworkCapcityException,
> >>>   InsufficientAddressCapacityException* {
> >>>
> >>>   if
> >>>
> >>>(_networkModel.networkIsConfiguredForExternalNetworking(config.getDataCe
> >>>nt
> >>> erId(),
> >>> config.getId()) && nic != null && nic.getRequestedIpv4() != null) {
> >>>   throw new CloudRuntimeException("Does not support custom ip
> >>> allocation at this time: " + nic);
> >>>   }
> >>>
> >>>   NicProfile profile = super.allocate(config, nic, vm);
> >>>
> >>>   *boolean _isEnabled =
> >>>
> >>>Boolean.parseBoolean(_configDao.getValue(Config.OvsTunnelNetwork.key()))
> >>>;
> >>> (2)
> >>>   if (_isEnabled) {
> >>>   return null;
> >>>   }*
> >>>
> >>>   if
> >>>
> >>>(_networkModel.networkIsConfiguredForExternalNetworking(config.getDataCe
> >>>nt
> >>> erId(),
> >>> config.getId())) {
> >>>   profile.setStrategy(ReservationStrategy.Start);
> >>>   /* We won't clear IP address, because router may set gateway
> >>> as
> >>> it IP, and it would be updated properly later */
> >>>   //profile.setIp4Address(null);
> >>>   profile.setGateway(null);
> >>>   profile.setNetmask(null);
> >>>   }
> >>>
> >>>   return profile;
> >>>   }*
> >>>
> >>> *
> >>> The return from (1) is NULL, because at (2) *sdn.ovs.controller* set to
> >>> true. So profile = NULL and then we get NullPointerException error in
> >>>the
> >>> next step.
> >>>
> >>> This error prevents me to deployVM using GRE isolation method. If I
> >>>set *
> >>> sdn.ovs.controller* = false, no error anymore but can't using GRE.
> >>>
> >>> How can I fix this? Thanks for any help.
> >>>
> >>> --
> >>>
> >>> N.g.U.y.e.N.A.n.H.t.U
> >>
> >
>
>


-- 

N.g.U.y.e.N.A.n.H.t.U

Re: [DISCUSS] We have a videographer. What videos do we want to make?

[Jessica Tomechak]

Mike, thanks for the idea! A pointer to the existing presentation video
would be great. Maybe Gregg can edit that together with animation, or demo
footage from our lab to show the corresponding hardware setup...just
brainstorming...Gregg is likely to have ideas of his own.

This is in addition to the one you mentioned earlier about storage
plug-ins.[1] That's a huge exciting new feature, so it might be another
fruitful topic for a "how-to."

Gregg and I will have to scope out how many videos there will be time for
this summer and which ones match his skills best. It's starting to look
like we have some good suggestions to pursue, which is very encouraging.
We're ahead of where we were last year at this time, and that's a good
thing.

[1]
http://buildacloud.org/cloud-computing-vids/video/latest/storage-plug-ins-by-mike-tutkowski.html

Jessica T.


On Wed, Jun 5, 2013 at 6:41 PM, Mike Tutkowski  wrote:

> Hi,
>
> I'd be happy to do a video on primary storage in CloudStack (and/or I could
> point you to an existing video where I presented on this topic).
>
> Thanks
>
>
> On Wed, Jun 5, 2013 at 6:36 PM, Jessica Tomechak <
> jessica.tomec...@gmail.com
> > wrote:
>
> > On Fri, May 31, 2013 at 6:00 AM, Chip Childers <
> chip.child...@sungard.com
> > >wrote:
> >
> > > On Fri, May 31, 2013 at 12:05:56AM -0700, Jessica Tomechak wrote:
> > > > On Thu, May 30, 2013 at 1:59 PM, Chip Childers <
> > > chip.child...@sungard.com>wrote:
> > > >
> > > > > On Thu, May 30, 2013 at 01:12:40PM -0700, Jessica Tomechak wrote:
> > > > > > Now Urgent!! Gregg will be starting in just a couple of weeks.
> Last
> > > year,
> > > > > > we churned for several weeks after his arrival. Let's avoid that
> > this
> > > > > time.
> > > > > >
> > > > > > What do we want?
> > > > > > Education videos from Sebastien's list?
> > > > > > How-to videos left over from last year's Video Plan?
> > > > > >
> > > > > > Need to know in the next few days, so the correct person can
> attend
> > > the
> > > > > > Mentor Orientation from Gregg's sponsoring organization.
> > > > > >
> > > > > > Mathias/Sebastien, if you want to use Gregg for education videos,
> > > please
> > > > > > speak up and make some materials available. We'll need outlines
> and
> > > > > > storyboards. Gregg can help generate those if all you have so far
> > is
> > > > > ideas.
> > > > > >
> > > > > > If you're not going to be ready to take advantage of Gregg's
> > > presence, I
> > > > > > will plan to work with him as I did last year. We still have a
> list
> > > of
> > > > > > video requests that we didn't get around to last time.
> > > > > >
> > > > > > Jessica T.
> > > > >
> > > > > Perhaps you can run with this Jessica?
> > > > >
> > > >
> > > > Chip,
> > > > I am totally on board to run with this. I am just looking to
> > collaborate
> > > > with the community on which direction to go. From much previous
> > > discussion
> > > > on this list, I've seen that showing up with a finished work item and
> > > > "throwing it over the wall" is frowned upon. We're intended to
> develop
> > in
> > > > the open, and get feedback on proposed projects.
> > >
> > > Absolutely true!  But your email above is asking for someone to "take
> > > point".  I was asking if you wanted to do it yourself.
> > >
> >
> > I am fine with being the point person.
> >
> >
> > >
> > > >
> > > > Perhaps if I throw out some more specific suggestions, people can
> vote
> > or
> > > > respond.
> > > >
> > > > I just want to get some suggestions of what topics would be most
> > helpful
> > > to
> > > > cover. I don’t want to waste the short time that Gregg has to act as
> a
> > > > contributor to the project.
> > > >
> > > > Some Visual Styles:
> > > >
> > > > Whiteboard talk
> > > >
> > > > "Talking head" interview
> > > >
> > > > Screencast
> > > >
> > > > Animation
> > > >
> > > > Tongue in cheek animation (xtranormal?)
> > > >
> > > >  Sketchnotes (hand drawn animation with narration)
> > > >
> > >
> > > IMO, style depends on the topic.
> > >
> > > >
> > > > Some Possible Technical Topics:
> > > >
> > > > What's new in 4.1, in 4.2
> > >
> > > I think that longevity of a video about the releases is too short.  -0
> > > on that one.
> > >
> > > >
> > > > How to install (quick install, or advanced install)
> > > >
> > >
> > > We already have some of these floating around, so -0.
> > >
> > > > Hypervisor installation (for each supported hypervisor)
> > > >
> > >
> > > -0
> > >
> > > > How to set up networking
> > > >
> > >
> > > +0 - It's really complex though, so I'd be curious how it would be put
> > > into video form.
> > >
> > > > Top 10 interesting clouds people have set up
> > > >
> > >
> > > +100 - if we have users willing to do it.
> > >
> > > > Conceptual overview of Cloudstack deployment (zones, pods, etc)
> > > >
> > >
> > > +1 on this one too.  Conceptual constructs aren't likely to change
> > > dramatically in the short term.
> > >
> > >
> > > > Datacenter concepts (what is a datacenter, what hardware w

Re: [MERGE] disk_io_throttling to MASTER

[Mike Tutkowski]

"+1 -- Burst IOPS can be implemented while avoiding implementation
attributes.  I always wondered about the details field.  I think we should
beef up the description in the documentation regarding the expected format
of the field.  In 4.1, I noticed that the details are not returned on the
createStoratePool updateStoragePool, or listStoragePool response.  Why
don't we return it?  It seems like it would be useful for clients to be
able to inspect the contents of the details field."

Not sure how this would work storing Burst IOPS here.

Burst IOPS need to be variable on a Disk Offering-by-Disk Offering basis.
For each Disk Offering created, you have to be able to associate unique
Burst IOPS. There is a disk_offering_details table. Maybe it could go there?

I'm also not sure how you would accept the Burst IOPS in the GUI if it's
not stored like the Min and Max fields are in the DB.

RE: Contributing as a non-committer

[Alex Huang]

Paul,

That line is old.  You should follow this page.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Setting+up+CloudStack+Development+Environment

--Alex

> -Original Message-
> From: Paul Angus [mailto:paul.an...@shapeblue.com]
> Sent: Monday, June 10, 2013 6:41 AM
> To: dev@cloudstack.apache.org
> Subject: RE: Contributing as a non-committer
> 
> Thanks Seb,
> I've bought pro git as extra reading too.
> 
> Now I'm trying to setup my dev environment, the 'Setting Up an Apache
> CloudStack Development Environment' says "Most Apache CloudStack
> developers use Eclipse as their primary IDE. CloudStack source code already
> includes Eclipse .project file in each project folder"
> 
> But I can't find the .project file in the CloudStack directory...?
> 
> 
> Regards,
> 
> Paul Angus
> S: +44 20 3603 0540 | M: +447711418784
> paul.an...@shapeblue.com
> 
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: 09 June 2013 08:46
> To: dev@cloudstack.apache.org
> Subject: Re: Contributing as a non-committer
> 
> Paul, I fixed the wiki link.
> 
> Thanks for reporting it, note that if you have a wiki account you can edit the
> page yourself and edit it.
> 
> Let us know if the instructions are not clear. I also have a screencast on git
> basics for non-committers:
> http://www.youtube.com/watch?v=3c5JIW4onGk&list=PLb899uhkHRoZCRE
> 00h_9CRgUSiHEgFDbC&index=5
> 
> 
> 
> -sebastien
> 
> On Jun 9, 2013, at 2:28 AM, Paul Angus  wrote:
> 
> > Hi Joe,
> >
> > It's on
> >
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Home
> > under 'Developer Docs and Resources'
> >
> >
> >
> > Regards,
> >
> > Paul Angus
> > S: +44 20 3603 0540 | M: +447711418784 paul.an...@shapeblue.com
> >
> > -Original Message-
> > From: Joe Brockmeier [mailto:j...@zonker.net]
> > Sent: 08 June 2013 23:04
> > To: dev@cloudstack.apache.org
> > Subject: Re: Contributing as a non-committer
> >
> > Paul, where are you seeing that link?
> >
> > On Fri, Jun 7, 2013, at 03:55 PM, Paul Angus wrote:
> >> Guys,
> >>
> >> I'm just trying to get up to speed with how I can contribute more
> >> (starting with a minor doc fix) but the link
> >> http://cloudstack.apache.org/develop/non-contributors.html is broken.
> >>
> >> Can it be fixed pls (does it count as a bug that I need to report).
> >> Is there an alternate link for the time being?
> >>
> >>
> >> Regards
> >>
> >> Paul Angus
> >> Senior Consultant / Cloud Architect
> >>
> >> [cid:image002.png@01CE1071.C6CC9C10]
> >>
> >> S: +44 20 3603 0540 | M:
> >> +447711418784
> >> paul.an...@shapeblue.com
> |
> >> www.shapeblue.com | Twitter:@shapeblue
> >> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
> >>
> >> ShapeBlue are proud to be sponsoring CloudStack Collaboration
> >> Conference NA
> >>
> [https://cwiki.apache.org/confluence/download/attachments/30760149/Cl
> >> o
> >>
> udStack+Collaboration+Conference+Banner+v2+Blue+Background+Only.jpg
> ?v
> >> udStack+Collaboration+Conference+Banner+v2+Blue+Background+e
> >>
> rsion=3&modificationDate=1367282397297] >> e
> >> t/>
> >>
> >> Apache CloudStack Bootcamp training courses
> >> 19/20 June,
> >> London course/>
> >> 22/23 June, Santa Clara
> >> CA
> >> 10/11 July, Bangalore,
> >> India
> >> 21/22 August,
> >> London course/>
> >>
> >> This email and any attachments to it may be confidential and are
> >> intended solely for the use of the individual to whom it is addressed.
> >> Any views or opinions expressed are solely those of the author and do
> >> not necessarily represent those of Shape Blue Ltd or related
> >> companies. If you are not the intended recipient of this email, you
> >> must neither take any action based upon its contents, nor copy or
> >> show it to anyone. Please contact the sender if you believe you have
> received this email in error.
> >> Shape Blue Ltd is a company incorporated in England & Wales.
> >> ShapeBlue Services India LLP is operated under license from Shape Blue
> Ltd.
> >> ShapeBlue is a registered trademark.
> >
> >
> > Best,
> >
> > jzb
> > --
> > Joe Brockmeier
> > j...@zonker.net
> > Twitter: @jzb
> > http://www.dissociatedpress.net/
> >
> > This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender if
> you believe y

RE: Contributing as a non-committer

[Alex Huang]

> Forget about eclipse for now :) just use vi :)

Why don't we just go back to ed?  

--Alex

Re: [MERGE] disk_io_throttling to MASTER

[Mike Tutkowski]

Let me make sure I follow where we're going here:

1) There should be NO references to hypervisor code in the storage plug-ins
code (this includes the default storage plug-in, which currently sends
several commands to the hypervisor in use (although it does not know which
hypervisor (XenServer, ESX(i), etc.) is actually in use))

2) managed=true or managed=false can be placed in the url field (if not
present, we default to false). This info is stored in the
storage_pool_details table.

3) When the "attach" command is sent to the hypervisor in question, we pass
the managed property along (this takes the place of the
StoragePoolType.Dynamic check).

4) execute(AttachVolumeCommand) in the hypervisor checks for the managed
property. If true for an attach, the necessary hypervisor data structure is
created and the rest of the attach command executes to attach the volume.

5) When execute(AttachVolumeCommand) is invoked to detach a volume, the
same check is made. If managed, the hypervisor data structure is removed.

6) I do not see an clear way to support Burst IOPS in 4.2 unless it is
stored in the volumes and disk_offerings table. If we have some idea,
that'd be cool.

Thanks!


On Mon, Jun 10, 2013 at 8:58 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> "+1 -- Burst IOPS can be implemented while avoiding implementation
> attributes.  I always wondered about the details field.  I think we should
> beef up the description in the documentation regarding the expected format
> of the field.  In 4.1, I noticed that the details are not returned on the
> createStoratePool updateStoragePool, or listStoragePool response.  Why
> don't we return it?  It seems like it would be useful for clients to be
> able to inspect the contents of the details field."
>
> Not sure how this would work storing Burst IOPS here.
>
> Burst IOPS need to be variable on a Disk Offering-by-Disk Offering basis.
> For each Disk Offering created, you have to be able to associate unique
> Burst IOPS. There is a disk_offering_details table. Maybe it could go there?
>
> I'm also not sure how you would accept the Burst IOPS in the GUI if it's
> not stored like the Min and Max fields are in the DB.
>



-- 
*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: [MERGE] disk_io_throttling to MASTER

[Mike Tutkowski]

Also, if we are good with Edison merging my code into his branch before
going into master, I am good with that.

We can remove the StoragePoolType.Dynamic code after his merge and we can
deal with Burst IOPS then, as well.


On Mon, Jun 10, 2013 at 9:08 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Let me make sure I follow where we're going here:
>
> 1) There should be NO references to hypervisor code in the storage
> plug-ins code (this includes the default storage plug-in, which currently
> sends several commands to the hypervisor in use (although it does not know
> which hypervisor (XenServer, ESX(i), etc.) is actually in use))
>
> 2) managed=true or managed=false can be placed in the url field (if not
> present, we default to false). This info is stored in the
> storage_pool_details table.
>
> 3) When the "attach" command is sent to the hypervisor in question, we
> pass the managed property along (this takes the place of the
> StoragePoolType.Dynamic check).
>
> 4) execute(AttachVolumeCommand) in the hypervisor checks for the managed
> property. If true for an attach, the necessary hypervisor data structure is
> created and the rest of the attach command executes to attach the volume.
>
> 5) When execute(AttachVolumeCommand) is invoked to detach a volume, the
> same check is made. If managed, the hypervisor data structure is removed.
>
> 6) I do not see an clear way to support Burst IOPS in 4.2 unless it is
> stored in the volumes and disk_offerings table. If we have some idea,
> that'd be cool.
>
> Thanks!
>
>
> On Mon, Jun 10, 2013 at 8:58 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> "+1 -- Burst IOPS can be implemented while avoiding implementation
>> attributes.  I always wondered about the details field.  I think we should
>> beef up the description in the documentation regarding the expected format
>> of the field.  In 4.1, I noticed that the details are not returned on the
>> createStoratePool updateStoragePool, or listStoragePool response.  Why
>> don't we return it?  It seems like it would be useful for clients to be
>> able to inspect the contents of the details field."
>>
>> Not sure how this would work storing Burst IOPS here.
>>
>>  Burst IOPS need to be variable on a Disk Offering-by-Disk Offering
>> basis. For each Disk Offering created, you have to be able to associate
>> unique Burst IOPS. There is a disk_offering_details table. Maybe it could
>> go there?
>>
>> I'm also not sure how you would accept the Burst IOPS in the GUI if it's
>> not stored like the Min and Max fields are in the DB.
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the 
> cloud
> *™*
>



-- 
*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: Contributing as a non-committer

[Soheil Eizadi]

This was a good resource, I added a section for Remote Debugging to the Wiki.
-Soheil

From: Alex Huang [alex.hu...@citrix.com]
Sent: Monday, June 10, 2013 8:00 PM
To: dev@cloudstack.apache.org
Subject: RE: Contributing as a non-committer

Paul,

That line is old.  You should follow this page.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Setting+up+CloudStack+Development+Environment

--Alex

> -Original Message-
> From: Paul Angus [mailto:paul.an...@shapeblue.com]
> Sent: Monday, June 10, 2013 6:41 AM
> To: dev@cloudstack.apache.org
> Subject: RE: Contributing as a non-committer
>
> Thanks Seb,
> I've bought pro git as extra reading too.
>
> Now I'm trying to setup my dev environment, the 'Setting Up an Apache
> CloudStack Development Environment' says "Most Apache CloudStack
> developers use Eclipse as their primary IDE. CloudStack source code already
> includes Eclipse .project file in each project folder"
>
> But I can't find the .project file in the CloudStack directory...?
>
>
> Regards,
>
> Paul Angus
> S: +44 20 3603 0540 | M: +447711418784
> paul.an...@shapeblue.com
>
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: 09 June 2013 08:46
> To: dev@cloudstack.apache.org
> Subject: Re: Contributing as a non-committer
>
> Paul, I fixed the wiki link.
>
> Thanks for reporting it, note that if you have a wiki account you can edit the
> page yourself and edit it.
>
> Let us know if the instructions are not clear. I also have a screencast on git
> basics for non-committers:
> http://www.youtube.com/watch?v=3c5JIW4onGk&list=PLb899uhkHRoZCRE
> 00h_9CRgUSiHEgFDbC&index=5
>
>
>
> -sebastien
>
> On Jun 9, 2013, at 2:28 AM, Paul Angus  wrote:
>
> > Hi Joe,
> >
> > It's on
> >
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Home
> > under 'Developer Docs and Resources'
> >
> >
> >
> > Regards,
> >
> > Paul Angus
> > S: +44 20 3603 0540 | M: +447711418784 paul.an...@shapeblue.com
> >
> > -Original Message-
> > From: Joe Brockmeier [mailto:j...@zonker.net]
> > Sent: 08 June 2013 23:04
> > To: dev@cloudstack.apache.org
> > Subject: Re: Contributing as a non-committer
> >
> > Paul, where are you seeing that link?
> >
> > On Fri, Jun 7, 2013, at 03:55 PM, Paul Angus wrote:
> >> Guys,
> >>
> >> I'm just trying to get up to speed with how I can contribute more
> >> (starting with a minor doc fix) but the link
> >> http://cloudstack.apache.org/develop/non-contributors.html is broken.
> >>
> >> Can it be fixed pls (does it count as a bug that I need to report).
> >> Is there an alternate link for the time being?
> >>
> >>
> >> Regards
> >>
> >> Paul Angus
> >> Senior Consultant / Cloud Architect
> >>
> >> [cid:image002.png@01CE1071.C6CC9C10]
> >>
> >> S: +44 20 3603 0540 | M:
> >> +447711418784
> >> paul.an...@shapeblue.com
> |
> >> www.shapeblue.com | Twitter:@shapeblue
> >> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
> >>
> >> ShapeBlue are proud to be sponsoring CloudStack Collaboration
> >> Conference NA
> >>
> [https://cwiki.apache.org/confluence/download/attachments/30760149/Cl
> >> o
> >>
> udStack+Collaboration+Conference+Banner+v2+Blue+Background+Only.jpg
> ?v
> >> udStack+Collaboration+Conference+Banner+v2+Blue+Background+e
> >>
> rsion=3&modificationDate=1367282397297] >> e
> >> t/>
> >>
> >> Apache CloudStack Bootcamp training courses
> >> 19/20 June,
> >> London course/>
> >> 22/23 June, Santa Clara
> >> CA
> >> 10/11 July, Bangalore,
> >> India
> >> 21/22 August,
> >> London course/>
> >>
> >> This email and any attachments to it may be confidential and are
> >> intended solely for the use of the individual to whom it is addressed.
> >> Any views or opinions expressed are solely those of the author and do
> >> not necessarily represent those of Shape Blue Ltd or related
> >> companies. If you are not the intended recipient of this email, you
> >> must neither take any action based upon its contents, nor copy or
> >> show it to anyone. Please contact the sender if you believe you have
> received this email in error.
> >> Shape Blue Ltd is a company incorporated in England & Wales.
> >> ShapeBlue Services India LLP is operated under license from Shape Blue
> Ltd.
> >> ShapeBlue is a registered trademark.
> >
> >
> > Best,
> >
> > jzb
> > --
> > Joe Brockmeier
> > j...@zonker.net
> > Twitter: @jzb
> > http://www.dissociatedpress.net/
> >
> > This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do

Re: Review Request: Cloudstack-2511 Multiple_Ip_Ranges: Adding guest ip range in subset/superset to existing CIDR is allowed https://issues.apache.org/jira/browse/CLOUDSTACK-2511, Cloudstack-2651 [Sha

[bharat kumar]

> On June 10, 2013, 4:23 p.m., Koushik Das wrote:
> > Don't combine multiple fixes in a single commit. Keep it simple -> 1 commit 
> > = 1 bug fix

These issues are closely related to each other and so i think combining them is 
not bad


- bharat


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11600/#review21654
---


On June 4, 2013, 2:51 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11600/
> ---
> 
> (Updated June 4, 2013, 2:51 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> Cloudstack-2511 Multiple_Ip_Ranges: Adding guest ip range in subset/superset 
> to existing CIDR is allowed
> https://issues.apache.org/jira/browse/CLOUDSTACK-2511
> 
> Cloudstack-2651 [Shared n/w]Add IP range should not ask for gateway and 
> netmask while adding the ip range to the existing subnet.
> https://issues.apache.org/jira/browse/CLOUDSTACK-2651
> 
> 
> This addresses bugs Cloudstack-2511 and Cloudstack-2651.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 59e70cf 
>   server/test/com/cloud/configuration/ValidateIpRangeTest.java 7681667 
>   utils/src/com/cloud/utils/net/NetUtils.java 8c094c8 
> 
> Diff: https://reviews.apache.org/r/11600/diff/
> 
> 
> Testing
> ---
> 
> Tested with master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request: Cloudstack-2621 [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C

[Koushik Das]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11435/#review21688
---



server/src/com/cloud/configuration/ConfigurationManagerImpl.java


Where is the txn started? Where is the txn marked as complete?



server/src/com/cloud/configuration/ConfigurationManagerImpl.java


nit: handel -> handle



server/src/com/cloud/configuration/ConfigurationManagerImpl.java


Move this comment to the place where the code is moved



server/src/com/cloud/configuration/ConfigurationManagerImpl.java


Instead of using _accountDao.findById(Account.ACCOUNT_ID_SYSTEM) why don't 
you pass the 'caller' parameter from the calling function 



server/src/com/cloud/configuration/ConfigurationManagerImpl.java


result_final is set to false, but the code is still moving ahead. 
Previously there was a return So the remaining code should only be executed if 
(result == true).



- Koushik Das


On June 3, 2013, 10:27 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11435/
> ---
> 
> (Updated June 3, 2013, 10:27 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C
> https://issues.apache.org/jira/browse/CLOUDSTACK-2621
> 
> 
> This addresses bug Cloudstack-2621.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 59e70cf 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> c71d037 
> 
> Diff: https://reviews.apache.org/r/11435/diff/
> 
> 
> Testing
> ---
> 
> tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request: Cloudstack-2621 [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C

[Koushik Das]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11435/#review21692
---



server/src/com/cloud/configuration/ConfigurationManagerImpl.java


if result_final == false, why is txn committed?


- Koushik Das


On June 3, 2013, 10:27 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11435/
> ---
> 
> (Updated June 3, 2013, 10:27 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C
> https://issues.apache.org/jira/browse/CLOUDSTACK-2621
> 
> 
> This addresses bug Cloudstack-2621.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 59e70cf 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> c71d037 
> 
> Diff: https://reviews.apache.org/r/11435/diff/
> 
> 
> Testing
> ---
> 
> tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: [DISCUSS] We have a videographer. What videos do we want to make?

[Mike Tutkowski]

Hi Jessica,

It looks like the presentation I did in San Francisco last month is not yet
available on Build a Cloud.

I would expect it to be up soon.

Just let me know if you'd like me to do something here.

Thanks!


On Mon, Jun 10, 2013 at 7:44 PM, Jessica Tomechak <
jessica.tomec...@gmail.com> wrote:

> Mike, thanks for the idea! A pointer to the existing presentation video
> would be great. Maybe Gregg can edit that together with animation, or demo
> footage from our lab to show the corresponding hardware setup...just
> brainstorming...Gregg is likely to have ideas of his own.
>
> This is in addition to the one you mentioned earlier about storage
> plug-ins.[1] That's a huge exciting new feature, so it might be another
> fruitful topic for a "how-to."
>
> Gregg and I will have to scope out how many videos there will be time for
> this summer and which ones match his skills best. It's starting to look
> like we have some good suggestions to pursue, which is very encouraging.
> We're ahead of where we were last year at this time, and that's a good
> thing.
>
> [1]
>
> http://buildacloud.org/cloud-computing-vids/video/latest/storage-plug-ins-by-mike-tutkowski.html
>
> Jessica T.
>
>
> On Wed, Jun 5, 2013 at 6:41 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com
> > wrote:
>
> > Hi,
> >
> > I'd be happy to do a video on primary storage in CloudStack (and/or I
> could
> > point you to an existing video where I presented on this topic).
> >
> > Thanks
> >
> >
> > On Wed, Jun 5, 2013 at 6:36 PM, Jessica Tomechak <
> > jessica.tomec...@gmail.com
> > > wrote:
> >
> > > On Fri, May 31, 2013 at 6:00 AM, Chip Childers <
> > chip.child...@sungard.com
> > > >wrote:
> > >
> > > > On Fri, May 31, 2013 at 12:05:56AM -0700, Jessica Tomechak wrote:
> > > > > On Thu, May 30, 2013 at 1:59 PM, Chip Childers <
> > > > chip.child...@sungard.com>wrote:
> > > > >
> > > > > > On Thu, May 30, 2013 at 01:12:40PM -0700, Jessica Tomechak wrote:
> > > > > > > Now Urgent!! Gregg will be starting in just a couple of weeks.
> > Last
> > > > year,
> > > > > > > we churned for several weeks after his arrival. Let's avoid
> that
> > > this
> > > > > > time.
> > > > > > >
> > > > > > > What do we want?
> > > > > > > Education videos from Sebastien's list?
> > > > > > > How-to videos left over from last year's Video Plan?
> > > > > > >
> > > > > > > Need to know in the next few days, so the correct person can
> > attend
> > > > the
> > > > > > > Mentor Orientation from Gregg's sponsoring organization.
> > > > > > >
> > > > > > > Mathias/Sebastien, if you want to use Gregg for education
> videos,
> > > > please
> > > > > > > speak up and make some materials available. We'll need outlines
> > and
> > > > > > > storyboards. Gregg can help generate those if all you have so
> far
> > > is
> > > > > > ideas.
> > > > > > >
> > > > > > > If you're not going to be ready to take advantage of Gregg's
> > > > presence, I
> > > > > > > will plan to work with him as I did last year. We still have a
> > list
> > > > of
> > > > > > > video requests that we didn't get around to last time.
> > > > > > >
> > > > > > > Jessica T.
> > > > > >
> > > > > > Perhaps you can run with this Jessica?
> > > > > >
> > > > >
> > > > > Chip,
> > > > > I am totally on board to run with this. I am just looking to
> > > collaborate
> > > > > with the community on which direction to go. From much previous
> > > > discussion
> > > > > on this list, I've seen that showing up with a finished work item
> and
> > > > > "throwing it over the wall" is frowned upon. We're intended to
> > develop
> > > in
> > > > > the open, and get feedback on proposed projects.
> > > >
> > > > Absolutely true!  But your email above is asking for someone to "take
> > > > point".  I was asking if you wanted to do it yourself.
> > > >
> > >
> > > I am fine with being the point person.
> > >
> > >
> > > >
> > > > >
> > > > > Perhaps if I throw out some more specific suggestions, people can
> > vote
> > > or
> > > > > respond.
> > > > >
> > > > > I just want to get some suggestions of what topics would be most
> > > helpful
> > > > to
> > > > > cover. I don’t want to waste the short time that Gregg has to act
> as
> > a
> > > > > contributor to the project.
> > > > >
> > > > > Some Visual Styles:
> > > > >
> > > > > Whiteboard talk
> > > > >
> > > > > "Talking head" interview
> > > > >
> > > > > Screencast
> > > > >
> > > > > Animation
> > > > >
> > > > > Tongue in cheek animation (xtranormal?)
> > > > >
> > > > >  Sketchnotes (hand drawn animation with narration)
> > > > >
> > > >
> > > > IMO, style depends on the topic.
> > > >
> > > > >
> > > > > Some Possible Technical Topics:
> > > > >
> > > > > What's new in 4.1, in 4.2
> > > >
> > > > I think that longevity of a video about the releases is too short.
>  -0
> > > > on that one.
> > > >
> > > > >
> > > > > How to install (quick install, or advanced install)
> > > > >
> > > >
> > > > We already have some of these floating around, so -0.
> > > >
> > 

Object_Store storage refactor GoToMeeting Tomorrow

[Min Chen]

Hi there,

To reach consensus on some remaining NFS cache issues on object_store storage 
refactor work in a more effective manner, John, Edison and I have scheduled a 
GoToMeeting tomorrow to discuss them over the phone, any interested parties are 
welcome to join and brainstorm. Here are detailed GTM information:

Meeting Time: 10:30 AM – 12:30 PM PST

Meeting Details:

1.  Please join my meeting.
https://www1.gotomeeting.com/join/188620897

2.  Use your microphone and speakers (VoIP) - a headset is recommended.  Or, 
call in using your telephone.

United States: +1 (626) 521-0017
United States (toll-free): 1 877 309 2070

Access Code: 188-620-897
Audio PIN: Shown after joining the meeting

Meeting ID: 188-620-897

GoToMeeting®
Online Meetings Made Easy®

Not at your computer? Click the link to join this meeting from your iPhone®, 
iPad® or Android® device via the GoToMeeting app.

Thanks
-min

RE: Build failed in Jenkins: cloudstack-rat-master #1468

[Animesh Chaturvedi]

Seeing this again, shouldn't jenkins just pull and compile? 
> -Original Message-
> From: David Nalley [mailto:da...@gnsa.us]
> Sent: Thursday, June 06, 2013 6:06 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Build failed in Jenkins: cloudstack-rat-master #1468
> 
> Why is jenkins trying to create a tag in our repo?
> 
> --David
> 
> On Thu, Jun 6, 2013 at 9:00 AM, Apache Jenkins Server
>  wrote:
> > See 
> >
> > --
> > Started by an SCM change
> > Building remotely on ubuntu2 in workspace
> > 
> > Checkout:cloudstack-rat-master /
> >  -
> > hudson.remoting.Channel@9907404:ubuntu2
> > Using strategy: Default
> > Last Built Revision: Revision d98289baca7fbc8a793adadfa386e6ab234952f7
> > (origin/master) Fetching changes from 1 remote Git repository Fetching
> > upstream changes from
> > https://git-wip-us.apache.org/repos/asf/cloudstack.git
> > Commencing build of Revision c0d894346a57e61626f332a9ef25efa9b5e77646
> > (origin/master) Checking out Revision
> > c0d894346a57e61626f332a9ef25efa9b5e77646 (origin/master)
> > FATAL: Could not apply tag jenkins-cloudstack-rat-master-1468
> > hudson.plugins.git.GitException: Could not apply tag jenkins-
> cloudstack-rat-master-1468
> > at hudson.plugins.git.GitAPI.tag(GitAPI.java:829)
> > at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1270)
> > at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1231)
> > at
> hudson.FilePath$FileCallableWrapper.call(FilePath.java:2348)
> > at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> > at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> > at hudson.remoting.Request$2.run(Request.java:326)
> > at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorS
> ervice.java:72)
> > at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> > at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav
> a:1146)
> > at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja
> va:615)
> > at java.lang.Thread.run(Thread.java:679)
> > Caused by: hudson.plugins.git.GitException: Command "git tag -a -f -m
> Jenkins Build #1468 jenkins-cloudstack-rat-master-1468" returned status
> code 128:
> > stdout:
> > stderr:
> > *** Please tell me who you are.
> >
> > Run
> >
> >   git config --global user.email "y...@example.com"
> >   git config --global user.name "Your Name"
> >
> > to set your account's default identity.
> > Omit --global to set the identity only in this repository.
> >
> > fatal: empty ident   not allowed
> >
> > at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:897)
> > at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:858)
> > at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:868)
> > at hudson.plugins.git.GitAPI.tag(GitAPI.java:827)
> > ... 12 more

Re: Object_Store storage refactor GoToMeeting Tomorrow

[Nitin Mehta]

Hi Min,
When you say tomorrow, what date is it 11th June or 12th ? Can the time be
preponed by an hour please - its too late here ?

Thanks,
-Nitin

On 11/06/13 11:06 AM, "Min Chen"  wrote:

>Hi there,
>
>To reach consensus on some remaining NFS cache issues on object_store
>storage refactor work in a more effective manner, John, Edison and I have
>scheduled a GoToMeeting tomorrow to discuss them over the phone, any
>interested parties are welcome to join and brainstorm. Here are detailed
>GTM information:
>
>Meeting Time: 10:30 AM ­ 12:30 PM PST
>
>Meeting Details:
>
>1.  Please join my meeting.
>https://www1.gotomeeting.com/join/188620897
>
>2.  Use your microphone and speakers (VoIP) - a headset is recommended.
>Or, call in using your telephone.
>
>United States: +1 (626) 521-0017
>United States (toll-free): 1 877 309 2070
>
>Access Code: 188-620-897
>Audio PIN: Shown after joining the meeting
>
>Meeting ID: 188-620-897
>
>GoToMeeting®
>Online Meetings Made Easy®
>
>Not at your computer? Click the link to join this meeting from your
>iPhone®, iPad® or Android® device via the GoToMeeting app.
>
>Thanks
>-min

Re: Object_Store storage refactor GoToMeeting Tomorrow

[Min Chen]

It is 11th June. John is not free between 9:15am to 10am, that is why we
schedule it at 10:30am.

Thanks
-min

On 6/10/13 10:52 PM, "Nitin Mehta"  wrote:

>Hi Min,
>When you say tomorrow, what date is it 11th June or 12th ? Can the time be
>preponed by an hour please - its too late here ?
>
>Thanks,
>-Nitin
>
>On 11/06/13 11:06 AM, "Min Chen"  wrote:
>
>>Hi there,
>>
>>To reach consensus on some remaining NFS cache issues on object_store
>>storage refactor work in a more effective manner, John, Edison and I have
>>scheduled a GoToMeeting tomorrow to discuss them over the phone, any
>>interested parties are welcome to join and brainstorm. Here are detailed
>>GTM information:
>>
>>Meeting Time: 10:30 AM ­ 12:30 PM PST
>>
>>Meeting Details:
>>
>>1.  Please join my meeting.
>>https://www1.gotomeeting.com/join/188620897
>>
>>2.  Use your microphone and speakers (VoIP) - a headset is recommended.
>>Or, call in using your telephone.
>>
>>United States: +1 (626) 521-0017
>>United States (toll-free): 1 877 309 2070
>>
>>Access Code: 188-620-897
>>Audio PIN: Shown after joining the meeting
>>
>>Meeting ID: 188-620-897
>>
>>GoToMeeting®
>>Online Meetings Made Easy®
>>
>>Not at your computer? Click the link to join this meeting from your
>>iPhone®, iPad® or Android® device via the GoToMeeting app.
>>
>>Thanks
>>-min
>

Re: Review Request: Cloudstack-2621 [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C

[bharat kumar]

> On June 11, 2013, 5:19 a.m., Koushik Das wrote:
> > server/src/com/cloud/configuration/ConfigurationManagerImpl.java, line 3037
> > 
> >
> > Instead of using _accountDao.findById(Account.ACCOUNT_ID_SYSTEM) why 
> > don't you pass the 'caller' parameter from the calling function

The ip alias is a system managed ip so think it should not belong to any of the 
caller's account 


- bharat


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11435/#review21688
---


On June 3, 2013, 10:27 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11435/
> ---
> 
> (Updated June 3, 2013, 10:27 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C
> https://issues.apache.org/jira/browse/CLOUDSTACK-2621
> 
> 
> This addresses bug Cloudstack-2621.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 59e70cf 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> c71d037 
> 
> Diff: https://reviews.apache.org/r/11435/diff/
> 
> 
> Testing
> ---
> 
> tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request: Updated account and domain id for nic secondary ips for shared networks

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11458/
---

(Updated June 11, 2013, 6:24 a.m.)


Review request for cloudstack, Abhinandan Prateek and Murali Reddy.


Changes
---

Updated to ipOwner


Description
---

Updated account and domain id for nic secondary ips for shared networks.
Fixed by getting accoundId and domainId from the caller instead of network


This addresses bug CLOUDSTACK-2609.


Diffs (updated)
-

  server/src/com/cloud/network/NetworkServiceImpl.java d5a59d6 

Diff: https://reviews.apache.org/r/11458/diff/


Testing
---

Tested on isolated and shared networks.


Thanks,

Jayapal Reddy

Re: Review Request: Cloudstack-2621 [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C

[bharat kumar]

> On June 11, 2013, 5:22 a.m., Koushik Das wrote:
> > server/src/com/cloud/configuration/ConfigurationManagerImpl.java, line 3083
> > 
> >
> > if result_final == false, why is txn committed?

i missed the txn.rollback here, the txn.commit is okay.


- bharat


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11435/#review21692
---


On June 3, 2013, 10:27 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11435/
> ---
> 
> (Updated June 3, 2013, 10:27 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C
> https://issues.apache.org/jira/browse/CLOUDSTACK-2621
> 
> 
> This addresses bug Cloudstack-2621.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 59e70cf 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> c71d037 
> 
> Diff: https://reviews.apache.org/r/11435/diff/
> 
> 
> Testing
> ---
> 
> tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request: Updated account and domain id for nic secondary ips for shared networks

[Jayapal Reddy]

> On June 4, 2013, 5:47 a.m., Murali Reddy wrote:
> > Should set the owner to be entity owner passed as ipowner instead of caller.

Updated to ipOwner


- Jayapal


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11458/#review21409
---


On May 28, 2013, 7:27 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11458/
> ---
> 
> (Updated May 28, 2013, 7:27 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Murali Reddy.
> 
> 
> Description
> ---
> 
> Updated account and domain id for nic secondary ips for shared networks.
> Fixed by getting accoundId and domainId from the caller instead of network
> 
> 
> This addresses bug CLOUDSTACK-2609.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/network/NetworkServiceImpl.java f880bcc 
> 
> Diff: https://reviews.apache.org/r/11458/diff/
> 
> 
> Testing
> ---
> 
> Tested on isolated and shared networks.
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Re: Review Request: Cloudstack-2621 [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C

[bharat kumar]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11435/
---

(Updated June 11, 2013, 6:33 a.m.)


Review request for cloudstack, Abhinandan Prateek and Koushik Das.


Description
---

[Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C
https://issues.apache.org/jira/browse/CLOUDSTACK-2621


This addresses bug Cloudstack-2621.


Diffs (updated)
-

  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 59e70cf 
  server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
c71d037 

Diff: https://reviews.apache.org/r/11435/diff/


Testing
---

tested on master.


Thanks,

bharat kumar

Re: Review Request: Cloudstack-2621 [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C

[bharat kumar]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11435/
---

(Updated June 11, 2013, 6:38 a.m.)


Review request for cloudstack, Abhinandan Prateek and Koushik Das.


Description
---

[Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C
https://issues.apache.org/jira/browse/CLOUDSTACK-2621


This addresses bug Cloudstack-2621.


Diffs (updated)
-

  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 59e70cf 
  server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
c71d037 

Diff: https://reviews.apache.org/r/11435/diff/


Testing
---

tested on master.


Thanks,

bharat kumar