Re: [PROPOSAL] Introduce API returning you an answer from CloudStack storage/host allocators whethere there is enough resources for vm deployment

[Tim Mackey]

How deep into dependencies would this go?  For example, if a new router VM
was required would that also be checked?

A chunk of the race conditions and state change issues should be resolvable
with ticket reservation system logic, but I'd be concerned the required
locks could create problems during infrastructure failures and with HA
enabled.  We ran into a ton of these types of problems implementing the
placement logic in XenServer's workload balancing with HA enabled.


On Sat, Feb 1, 2014 at 12:10 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> I like the idea in principal. We should fail as fast as is practical.
>
> I wonder, are you just checking if the resources are available? If so, it's
> still possible for deployVM to fail even if this check said all was good
> because the state of the system could change before the actual deployVM is
> started.
>
>
> On Fri, Jan 31, 2014 at 7:20 PM, Madan Ganesh Velayudham <
> madangan...@me.com
> > wrote:
>
> > Makes lot of sense. Would the same API allow the caller just to check
> (not
> > actually proceed to create) whether resources are present for a
> particular
> > payload? This may be useful for the client who want to proactively check
> > and avoid returning failure.
> >
> > Are there any race condition possibilities when multiple requests are
> > received?
> > 
> >
> > Madan Ganesh Velayudham P.M.P, C.S.M.,
> > madangan...@me.com
> >
> >
> >
> >
> > On 01-Feb-2014, at 5:56 am, Alena Prokharchyk <
> > alena.prokharc...@citrix.com> wrote:
> >
> > > Currently there is no way to know if there is enough resources for vm
> > deployment, before actual deployVm call is made. The sequence is the
> > following:
> > >
> > > 1) Deploy Vm is called
> > > 2) DB record is created for the Vm
> > > 3) Storage/Host allocators determine whethere there are enough
> resources
> > for vm to be deployed, and return deploy destination to the caller stack.
> > > 4) If allocator returns valid deploy destination, VM gets actually
> > created/started on the backend. If allocators don't return the
> destination,
> > the DB record created on step 2) gets destroyed, and ResourceAllocation
> > exception is thrown back to the API caller.
> > >
> > > The API I'm going to introduce, would help you to determine whether CS
> > physical resources - hosts, storages - can potentially accomodate vm
> > deployment (considering template/service/diskOffering) at a given time,
> w/o
> > actually calling the deploy vm. Some admins might find this call useful
> as
> > they can always make this check before submitting the deployVm, so in
> case
> > it returns NO, you can fail the deployment immediately, w/o calling
> > deployVm. Also you can make this call to determine what is lacking for
> > certain vm deployment, and expand your physical resources accordingly.
> > >
> > > Please let me know if see any pitfalls in the proposal, as well if you
> > see any other use cases that can be solved using this API.
> > >
> > > Prachi, can you please point me to an existing method (or interface)
> > defined in Allocators code serving this purpose?
> > >
> > > Thanks,
> > > -Alena.
> >
> >
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *(tm)*
>

Re: [RFC] adding volume provisioning method option

[Nux!]

On 01.02.2014 07:14, Marcus wrote:

Oh yes, and storage overprovisioning doesn't currently work for KVM
storage types, but it's a relatively simple fix:


Let me know when you need someone to ask for a cherry pick. :-)
Qcow files scream overprovisioning.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: [RFC] adding volume provisioning method option

[Nux!]

On 01.02.2014 06:43, Marcus wrote:


[root@server ~]# qemu-img create -f qcow2 -o preallocation=metadata
imagepre.qcow2 10G
Formatting 'imagepre.qcow2', fmt=qcow2 size=10737418240 encryption=off
cluster_size=65536 preallocation='metadata'
[root@server ~]# qemu info imagepre.qcow2
-bash: qemu: command not found
[root@server ~]# qemu-img info imagepre.qcow2
image: imagepre.qcow2
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 1.7M
cluster_size: 65536

preallocation=metadata leaves disk as 1.7M, it's also sparse, but a 
bit bigger.


I think just a global switch might be enough given the above.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Contrail issues in current master

[Hugo Trippaers]

Hey Contrail friends,

I’m noticing some issues with the contrail plugin in current master. 

When you startup CloudStack master with a fresh database it will die with a 
NullPointerException at ContrailManagerImpl.java:locateVpcOffering(). After 
killing and restarting CloudStack it works fine.

Second during runtime i get the following: 
INFO  [n.j.c.a.ApiConnector] (DBSyncTimer:null) http connection  does not exit
WARN  [o.a.c.n.c.m.ServerDBSync] (DBSyncTimer:null) syncDomain
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at java.net.Socket.(Socket.java:425)
at java.net.Socket.(Socket.java:208)
at 
net.juniper.contrail.api.ApiConnectorImpl.checkConnection(ApiConnectorImpl.java:127)
at 
net.juniper.contrail.api.ApiConnectorImpl.execute(ApiConnectorImpl.java:156)
at 
net.juniper.contrail.api.ApiConnectorImpl.list(ApiConnectorImpl.java:433)
at 
org.apache.cloudstack.network.contrail.management.ServerDBSyncImpl.syncDomain(ServerDBSyncImpl.java:240)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.apache.cloudstack.network.contrail.management.DBSyncGeneric.sync(DBSyncGeneric.java:113)
at 
org.apache.cloudstack.network.contrail.management.ServerDBSyncImpl.syncAll(ServerDBSyncImpl.java:149)
at 
org.apache.cloudstack.network.contrail.management.ContrailManagerImpl.syncNetworkDB(ContrailManagerImpl.java:496)
at 
org.apache.cloudstack.network.contrail.management.ContrailManagerImpl$DBSyncTask.run(ContrailManagerImpl.java:514)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)

Even though i didn’t activate anything for Contrail.

Can you guys have a look?

Cheers,

Hugo

RE: Not able to add primary Storage Cloudstack 4.3

[Paul Angus]

Tejas,

I guess that your entering the path as an smb path \\server\share\directory
For primary storage try 'share/folder' and the 'server' without the \\

There were issues with shared primary storage, so I've included one of the devs 
working on the feature.

The same is true for secondary storage (although the UI may need 
\share\directory in the path).

Regards

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

-Original Message-
From: Sean Hamilton [mailto:s...@seanhamilton.co.uk]
Sent: 01 February 2014 11:55
To: us...@cloudstack.apache.org
Cc: us...@cloudstack.apache.org
Subject: Re: Not able to add primary Storage Cloudstack 4.3

Hi Tejas,

What hypervisor are you using?
I can't remember if CIFS is a valid protocol for hypervisors other than 
Hyper-V. NFS is used for other hypervisors.

Cheers,
Sean

> On 1 Feb 2014, at 09:26, Tejas Gadaria  wrote:
>
> Hi,
>
> While adding primary Storage I am getting
>
>  
> "cifs://10.129.151.155/\\hcloud\primary\?user=administrator&password=abc_123&domain=nwx.com
>  is not a valid uri"
>
> Similar error I am facing while adding secondary storage also.
>
> Please find attachment for logs,
>
>
> Regards,
> Tejas
> 
> 
Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure 
Support offers the 
best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2.1 training
18th-19th February 2014, Brazil. 
Classroom
17th-23rd March 2014, Region A. Instructor led, 
On-line
24th-28th March 2014, Region B. Instructor led, 
On-line
16th-20th June 2014, Region A. Instructor led, 
On-line
23rd-27th June 2014, Region B. Instructor led, 
On-line

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 a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: Add new KVM hypervisor host into CloudStack

[Indra Pramana]

Hi Sugandh, Serge and Lucian,

Good day to you, and thank you for all your replies!

What I can conclude is that CPU is important to be exactly the same -- to
allow the capabilities of live VM instance migration from one host to
another. However, chassis and motherboard doesn't have to be the same --
it's normal to bring in better servers over time. Please CMIIW.

Will try ordering the server now and will update again if I encounter
further issues. Thanks!

Cheers.


On Thu, Jan 30, 2014 at 5:45 PM, Nux!  wrote:

> On 30.01.2014 08:57, Indra Pramana wrote:
>
>> Hi,
>>
>> It's time for me to add new KVM hypervisor host into our CloudStack and I
>> read these requirements:
>>
>> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/
>> 4.2.0/html/Installation_Guide/hypervisor-kvm-install-flow.html
>> - Same distribution version, is it referring to same OS and version? E.g.
>> Ubuntu 12.04 (Precise)?
>> - All hosts must be homogenous, does it mean that the new server has to be
>> exactly the same chassis, motherboard, type of CPU and RAM? Can I use a
>> different type of chassis and motherboard, but use the same type of CPU?
>>
>> Thank you.
>>
>
> Yes, I think the CPU is the important bit here and imho it should be equal
> or better than what you have if you want certain stuff like live migration
> to work. This is especially important if you use host-passthrough for CPU
> type. I do not think anyone expect you to have indentical servers
> throughout your setup; it's normal to bring in better servers as time
> passes.
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>

Re: Add new KVM hypervisor host into CloudStack

[Serge van Ginderachter]

On 1 February 2014 14:39, Indra Pramana  wrote:

> What I can conclude is that CPU is important to be exactly the same -- to
> allow the capabilities of live VM instance migration from one host to
> another.
>

Live migration I should have add to that. Offline migration shouldn't be a
problem.
Also note, KVM can be configured to support only a (common) subset of cpu
capabilities, to have a common base over all hosts.
​​

> However, chassis and motherboard doesn't have to be the same --
> it's normal to bring in better servers over time
>

[EVENT] Last day for submission to CCC NA Denver April 9-11

[Sebastien Goasguen]

Hi,

Today is supposed to be the last day for paper submissions to CloudStack collab 
Denver april 9-11th.

http://cloudstackcollab.org

Get them in :)

-Sebastien

Re: [PROPOSAL] Introduce API returning you an answer from CloudStack storage/host allocators whethere there is enough resources for vm deployment

[Ryan Lei]

I believe it's a nice idea. A lot of us have experienced the
annoying InsufficientCapacityException in Deploying Virtual Machines, but
we can't tell exactly why just by reading the logs.

If this new API could help us debug this VM deployment process to determine
exactly which resource is lacking, or probably other internal reasons that
cause this InsufficientCapacityException, it would be very helpful!

---
Yu-Heng (Ryan) Lei, Associate Researcher
Cloud Computing Dept, Chunghwa Telecom Labs
ryan...@cht.com.tw or ryanlei750...@gmail.com



On Sat, Feb 1, 2014 at 8:26 AM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

> Currently there is no way to know if there is enough resources for vm
> deployment, before actual deployVm call is made. The sequence is the
> following:
>
> 1) Deploy Vm is called
> 2) DB record is created for the Vm
> 3) Storage/Host allocators determine whethere there are enough resources
> for vm to be deployed, and return deploy destination to the caller stack.
> 4) If allocator returns valid deploy destination, VM gets actually
> created/started on the backend. If allocators don't return the destination,
> the DB record created on step 2) gets destroyed, and ResourceAllocation
> exception is thrown back to the API caller.
>
> The API I'm going to introduce, would help you to determine whether CS
> physical resources - hosts, storages - can potentially accomodate vm
> deployment (considering template/service/diskOffering) at a given time, w/o
> actually calling the deploy vm. Some admins might find this call useful as
> they can always make this check before submitting the deployVm, so in case
> it returns NO, you can fail the deployment immediately, w/o calling
> deployVm. Also you can make this call to determine what is lacking for
> certain vm deployment, and expand your physical resources accordingly.
>
> Please let me know if see any pitfalls in the proposal, as well if you see
> any other use cases that can be solved using this API.
>
> Prachi, can you please point me to an existing method (or interface)
> defined in Allocators code serving this purpose?
>
> Thanks,
> -Alena.
>

RE: Create GRE tunnel failed in 4.2 with XenServer.

[Paul Angus]

Hey Tuna, (and anyone else working on this)

I filed bug 5967 which looks like it might relate to this - I was trying to use 
GRE tunnel isolation in 4.3 and got VM_REQUIRES_NETWORK errors from the 
XenServer when trying to start a new virtual router.

https://issues.apache.org/jira/browse/CLOUDSTACK-5967

What's the status of GRE Tunnel isolation as a feature at the moment?

Regards

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

-Original Message-
From:  [mailto:ng.t...@gmail.com] On Behalf Of Nguyen Anh Tu
Sent: 24 January 2014 05:59
To: dev@cloudstack.apache.org
Cc: Florin Dumitrascu; Sebastien Goasguen; Chiradeep Vittal
Subject: Re: Create GRE tunnel failed in 4.2 with XenServer.

Yes, my fixes will be put to 4.3 tomorrow! I get the flu today. Back to work 
tomorrow.

--Tuna

Sent from my GT-N7000
On Jan 24, 2014 12:43 PM, "Murali Reddy"  wrote:

>
> On 23/01/14 5:48 PM, "Florin Dumitrascu"
>  wrote:
>
> >Hi Murali, Tuna,
> >
> >Thank you for this piece of information. All starts to make sense now.
> >I am wondering if there is a better way to communicate this issue to
> >end users. It would save others a couple of weeks struggling.
> >If GRE is not just a technology preview (meaning it has been
> >explicitly mentioned in previous release notes), the known issues
> >lists for 4.2.0 and 4.2.1 should be explicitly updated.
> >
> >Leaving 4.2 behind now, which will be the first release to include
> >GRE refactoring with OVS service provider ?
>
> Ideally Tuna's fix (to make OVS as Connectivity service provider)
> should have gone into 4.2.1. Looks like they did not go into 4.2.1
>
> Tuna,
>
> Can you please ensure your fixes (excluding support for KVM/XCP) went
> into 4.2, 4.3 branches as well.
>
> Thanks,
> Murali
>
> >
> >Regards,
> >Florin
> >
> >-Original Message-
> >From: ng.t...@gmail.com [mailto:ng.t...@gmail.com] On Behalf Of
> >Nguyen Anh Tu
> >Sent: Thursday, January 23, 2014 11:56 AM
> >To: Murali Reddy
> >Cc: dev@cloudstack.apache.org; Chiradeep Vittal; Sebastien Goasguen
> >Subject: Re: Create GRE tunnel failed in 4.2 with XenServer.
> >
> >Wow... I thought everything was done in XenServer before my submitted
> >patch.
> >
> >--Tuna
> >
> >Sent from my GT-N7000
> >On Jan 23, 2014 6:49 PM, "Murali Reddy"  wrote:
> >
> >> Please see the thread
> >>
> >> https://www.mail-archive.com/dev@cloudstack.apache.org/msg17396.htm
> >> l
> >>
> >>
> >>
> >> On 23/01/14 5:10 PM, "Florin Dumitrascu"
> >>  wrote:
> >>
> >> >Hi,
> >> >
> >> >Just want to add a few of my observations to what Tuna said.
> >> >
> >> >
> >> >a.   I managed to have GRE isolation working with CloudStack 4.1.1
> >> >and a quick patch to bypass "enableXenserverNetwork" method.
> >> >
> >> >
> >> >
> >> >b.  I tried GRE isolation with CloudStack 4.2.1 with the same quick
> >> >patch for bypassing "enableXenserverNetwork".
> >> >
> >> >Once that method was bypassed, guest VMs came up, but the tunnel
> >> >was not created. It seems to me that OvsElement methods
> >> >(implement,
> >> >prepare) are not invoked.
> >> >
> >> >Did something change in 4.2 to affect this ? I am setting
> >> >"sdn.ovs.controller=true" in global settings and select GRE
> >> >isolation method in the guest physical network.
> >> >
> >> >
> >> >Thank you,
> >> >Florin
> >> >
> >> >
> >> >
> >> >From: ng.t...@gmail.com [mailto:ng.t...@gmail.com] On Behalf Of
> >> >Nguyen Anh Tu
> >> >Sent: Thursday, January 23, 2014 10:15 AM
> >> >To: dev@cloudstack.apache.org; Sebastien Goasguen; Chiradeep
> >> >Vittal; Florin Dumitrascu
> >> >Subject: Create GRE tunnel failed in 4.2 with XenServer.
> >> >
> >> >
> >> >Guys,
> >> >
> >> >Florin raised a problem in creating GRE tunnel with ACS 4.2
> >> >release and XenServer 6.2. I found the problem come from
> >> >enableXenserverNetwork method. CloudStack made a tricky to create
> >> >network when plugging a VIF to
> >> >dom0 and then unplugging immediately. With XCP version I done in
> >> >GSOC, I bypassed that step so that no problem.
> >> >
> >> >Didn't know why we need that tricky and how to solve it. I'm
> >> >working on it. Any help or explaination?
> >> >
> >> >Thanks,
> >> >
> >> >--Tuna
> >> >
> >> >Sent from my GT-N7000
> >> >
> >> >IMPORTANT NOTE: The information in this e-mail (and any
> >> >attachments) is confidential. The contents may not be disclosed or
> >> >used by anyone other than the addressee. If you are not the
> >> >intended recipient, please notify the sender immediately or telephone: 
> >> >+353 (0)1 6204700.
> >> >We cannot accept any responsibility for the accuracy or
> >> >completeness of this message as it has been transmitted over a
> >> >public network. If you suspect that the message may have been
> >> >intercepted or amended,
> >>please call the sender.
> >> >
> >>
> >>
> >>
> >
> >IMPORTANT NOTE: The information in this e-mail (and any attachments)
> >is confidential. The contents may not be disclosed or used b

Re: [PROPOSAL] Introduce API returning you an answer from CloudStack storage/host allocators whethere there is enough resources for vm deployment

[abhisek basu]

Great idea, this would certainly reduce vm deployment failures.

VR including RVR if needs to be created, should get included in this check.

Also, can we include ways to check if a VM can be launched in a certain 
cluster? The idea is to allow users / admins to  be able to launch vm in a 
certain cluster, but that might be the next functionality.

Sent from my iPhone

> On 1 Feb 2014, at 8:50 pm, "Ryan Lei"  wrote:
> 
> I believe it's a nice idea. A lot of us have experienced the
> annoying InsufficientCapacityException in Deploying Virtual Machines, but
> we can't tell exactly why just by reading the logs.
> 
> If this new API could help us debug this VM deployment process to determine
> exactly which resource is lacking, or probably other internal reasons that
> cause this InsufficientCapacityException, it would be very helpful!
> 
> ---
> Yu-Heng (Ryan) Lei, Associate Researcher
> Cloud Computing Dept, Chunghwa Telecom Labs
> ryan...@cht.com.tw or ryanlei750...@gmail.com
> 
> 
> 
> On Sat, Feb 1, 2014 at 8:26 AM, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
> 
>> Currently there is no way to know if there is enough resources for vm
>> deployment, before actual deployVm call is made. The sequence is the
>> following:
>> 
>> 1) Deploy Vm is called
>> 2) DB record is created for the Vm
>> 3) Storage/Host allocators determine whethere there are enough resources
>> for vm to be deployed, and return deploy destination to the caller stack.
>> 4) If allocator returns valid deploy destination, VM gets actually
>> created/started on the backend. If allocators don't return the destination,
>> the DB record created on step 2) gets destroyed, and ResourceAllocation
>> exception is thrown back to the API caller.
>> 
>> The API I'm going to introduce, would help you to determine whether CS
>> physical resources - hosts, storages - can potentially accomodate vm
>> deployment (considering template/service/diskOffering) at a given time, w/o
>> actually calling the deploy vm. Some admins might find this call useful as
>> they can always make this check before submitting the deployVm, so in case
>> it returns NO, you can fail the deployment immediately, w/o calling
>> deployVm. Also you can make this call to determine what is lacking for
>> certain vm deployment, and expand your physical resources accordingly.
>> 
>> Please let me know if see any pitfalls in the proposal, as well if you see
>> any other use cases that can be solved using this API.
>> 
>> Prachi, can you please point me to an existing method (or interface)
>> defined in Allocators code serving this purpose?
>> 
>> Thanks,
>> -Alena.
>> 

Re: [PROPOSAL] Introduce API returning you an answer from CloudStack storage/host allocators whethere there is enough resources for vm deployment

[Daan Hoogland]

I like the idea.  Would the api query the db or the bakends (i.e. hosts,
storage,  etc)?

mobile bilingual spell checker used
Op 1 feb. 2014 17:13 schreef "abhisek basu" :

> Great idea, this would certainly reduce vm deployment failures.
>
> VR including RVR if needs to be created, should get included in this check.
>
> Also, can we include ways to check if a VM can be launched in a certain
> cluster? The idea is to allow users / admins to  be able to launch vm in a
> certain cluster, but that might be the next functionality.
>
> Sent from my iPhone
>
> > On 1 Feb 2014, at 8:50 pm, "Ryan Lei"  wrote:
> >
> > I believe it's a nice idea. A lot of us have experienced the
> > annoying InsufficientCapacityException in Deploying Virtual Machines, but
> > we can't tell exactly why just by reading the logs.
> >
> > If this new API could help us debug this VM deployment process to
> determine
> > exactly which resource is lacking, or probably other internal reasons
> that
> > cause this InsufficientCapacityException, it would be very helpful!
> >
> >
> ---
> > Yu-Heng (Ryan) Lei, Associate Researcher
> > Cloud Computing Dept, Chunghwa Telecom Labs
> > ryan...@cht.com.tw or ryanlei750...@gmail.com
> >
> >
> >
> > On Sat, Feb 1, 2014 at 8:26 AM, Alena Prokharchyk <
> > alena.prokharc...@citrix.com> wrote:
> >
> >> Currently there is no way to know if there is enough resources for vm
> >> deployment, before actual deployVm call is made. The sequence is the
> >> following:
> >>
> >> 1) Deploy Vm is called
> >> 2) DB record is created for the Vm
> >> 3) Storage/Host allocators determine whethere there are enough resources
> >> for vm to be deployed, and return deploy destination to the caller
> stack.
> >> 4) If allocator returns valid deploy destination, VM gets actually
> >> created/started on the backend. If allocators don't return the
> destination,
> >> the DB record created on step 2) gets destroyed, and ResourceAllocation
> >> exception is thrown back to the API caller.
> >>
> >> The API I'm going to introduce, would help you to determine whether CS
> >> physical resources - hosts, storages - can potentially accomodate vm
> >> deployment (considering template/service/diskOffering) at a given time,
> w/o
> >> actually calling the deploy vm. Some admins might find this call useful
> as
> >> they can always make this check before submitting the deployVm, so in
> case
> >> it returns NO, you can fail the deployment immediately, w/o calling
> >> deployVm. Also you can make this call to determine what is lacking for
> >> certain vm deployment, and expand your physical resources accordingly.
> >>
> >> Please let me know if see any pitfalls in the proposal, as well if you
> see
> >> any other use cases that can be solved using this API.
> >>
> >> Prachi, can you please point me to an existing method (or interface)
> >> defined in Allocators code serving this purpose?
> >>
> >> Thanks,
> >> -Alena.
> >>
>

Re: Question about selecting an EndPoint

[Mike Tutkowski]

The biggest problem I've noticed with selecting an EndPoint like this when
the storage for the template can be deployed on zone-wide primary storage
is that you won't necessarily select a host of the right hypervisor type to
deploy the template to (ex. you could have a template for XenServer and
select an ESX host as an EndPoint).

In my case, the zone-wide primary storage is a SAN and we carve out volumes
from it as needed. The SAN can be leveraged by different hypervisor types
across the zone.

It looks like I'll have to add logic to this EndPoint selection to confine
itself to a particular hypervisor type (in the zone-wide primary storage
case).


On Sat, Feb 1, 2014 at 12:02 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hi,
>
> In the copyObject method of AncientDataMotionStrategy, we have the
> following code to select an EndPoint:
>
> EndPoint ep = selector.select(srcForCopy, destData);
>
> if (ep == null) {
>
> String errMsg = "No remote endpoint to send command,
> check if host or ssvm is down?";
>
> s_logger.error(errMsg);
>
> answer = new Answer(cmd, false, errMsg);
>
> } else {
>
> answer = ep.sendMessage(cmd);
>
> }
> If you needed to know which EndPoint was going to be selected BEFORE this
> copyObject method was invoked, how could one do that?
>
> For example, I have a use case in 4.4 where I need to have CloudStack tell
> the storage driver in use to create a volume on its storage system.
> CloudStack then needs to tell the driver to grant hosts in a particular
> cluster access to this volume. After this, CloudStack needs to tell the
> hypervisor in use for the cluster to copy the template down to the recently
> created storage (this is a case where we are spinning up a VM based on a
> template that uses managed storage).
>
> The way I was planning on doing this was to select an EndPoint using
> similar logic to what's above and then pass that EndPoint in to both the
> method that grants hosts access to the recently created volume AND pass
> that same EndPoint in to the copyObject method (this necessitates creating
> a new method on the interface that AncientDataMotionStrategy implements).
>
> Thoughts on this? These are the steps in outline form:
>
> * CloudStack wants to deploy a VM that uses a template to managed storage
> (an example of managed storage is that the XenServer SR does not exist
> before we kick off the VM...the SR (and the VDI that represents the
> template) is created on the fly to house the root disk of the VM).
>
> * CloudStack tells the storage driver in use to create a volume on its
> storage system (this volume will be used for our XenServer SR).
>
> * CloudStack tells the storage driver to grant hosts in the applicable
> cluster access to the volume the driver just created (this is where we
> first need to know of a host in the applicable cluster).
>
> * CloudStack sends a command to a host in the applicable cluster to create
> an SR based on the volume the driver just created, then the host downloads
> a template to the SR.
>
> Once this has completed, you now have a single template as a root disk on
> a newly created SR. The volume the SR is on has guaranteed IOPS (Quality of
> Service is the reason we want only a single template on the SR). When the
> VM is expunged, its root disk (and the SR it was housed on) are destroyed.
>
> Thanks!
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the 
> cloud
> *(tm)*
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*

Re: Findbugs report on 4.3-forward

[Sebastien Goasguen]

On Jan 31, 2014, at 12:02 PM, Ian Duffy  wrote:

> Just continuing this for my own learning experience as I still don't see
> it. I also don't see why the outputs from the commited code are OK, on
> testing I'm getting things like: [55, 107, 73, 50, 87, 100, 119, 49, 121,
> 76, 56, 43, 104, 48, 112, 105, 107, 102, 111, 88, 87, 73, 98, 113, 120, 52,
> 85, 61]. I expected this to be a string made up of different characters to
> form a random password, what looks like an array converted to a string.
> 
> With the char set know, it would be easy to decode the password than the
>> previous encoded version.
> 
> 
> So the argument being put forward is we know the charset that makes up the
> password? This is true but we know the charset for a base64 string,
> its A-Z,a-z,0-9,and +. Even still, with the charset exposed I don't see how
> this is an issue(bare with my math here). Its a roughly 72 charset
> generating a password of length 20. Thats 72^20 different possible
> combinations. If we say it takes a second to brute each combination you are

Ian, I will let Rajani and Daan reply to you, but you can get much faster than 
1 combination per second:

http://hackaday.com/2012/12/06/25-gpus-brute-force-348-billion-hashes-per-second-to-crack-your-passwords/



> looking at roughly (4.445×10^29) years to test all combinations. (
> http://www.wolframalpha.com/input/?i=72%5E20+seconds+to+years )
> 
> The function in question is suppose to return a string that acts as the
> password given to AccountService to create the new user account on
> testing the code that has been committed into the 4.3 branch I'm just
> getting back stuff like the following: [55, 107, 73, 50, 87, 100, 119, 49,
> 121, 76, 56, 43, 104, 48, 112, 105, 107, 102, 111, 88, 87, 73, 98, 113,
> 120, 52, 85, 61]
> 
> I executed the test manually by just pulling the code out and running it
> alone from command line:
> https://gist.github.com/imduffy15/ae7a809aa7bb6cb198e3.
> 
> Regards,
> Ian
> 
> 
> On 31 January 2014 04:38, Rajani Karuturi wrote:
> 
>> With the char set know, it would be easy to decode the password than the
>> previous encoded version.
>> This is a concern because even for ldap users we also check authentication
>> against db.
>> 
>> Thanks a lot for taking Daan and Ian.
>> 
>> 
>> ~Rajani
>> 
>> 
>> 
>> On 31-Jan-2014, at 1:20 am, Ian Duffy  wrote:
>> 
>>> Hi,
>>> 
>>> Sorry about the delay in replying to this have been doing exams at uni
>> all
>>> week.
>>> 
>>> Daan's change looks to change Rajani concern.
>>> 
>>> Might be me being naive but I fail to understand the concern fully...
>>> The given character selection was roughly 72 with a string of length 20.
>> If
>>> my math is correct thats 72^20 different possible combinations...
>>> 
>>> Anyways, thanks for taking care of this Daan.
>>> 
>>> On 30 January 2014 13:28, Daan Hoogland  wrote:
>>> 
 Guys,
 
 I found two reported issues of category 'scary'. To satify Rajuri's
 concerns I would like to revert Ian's commit and checkin two changes
 that change returning
 byte[].toString()
 into
 Arrays.toString(byte[])
 on return statements of generatePassword methods.
 
 if no objections come in within a few...,
 Daan
 
 On Thu, Jan 30, 2014 at 1:53 PM, Daan Hoogland >> 
 wrote:
> Animesh, Ian,
> 
> Can you comment on this?
> 
> I couldn't find any findbugs issues of the the scariest kind in
> yesterdays version of the 4.3 branch. What was solved that needs to go
> in in spite of Rajuri's reservations?
> 
> thanks,
> Daan
> 
> On Thu, Jan 30, 2014 at 11:21 AM, Daan Hoogland <
>> daan.hoogl...@gmail.com>
 wrote:
>> Sorry Rajani,
>> 
>> I had seen no reaction to Ian's explenation  and the request by
>> Animesh to pull it so I just did. let me look into it for a minute
>> 
>> On Thu, Jan 30, 2014 at 5:36 AM, Rajani Karuturi
>>  wrote:
>>> I see that the commit 9776e1af1c92486f5081b1ee8fa95cf0edb86b97 is
 already pushed to 4.3. I don't see any response on my concern as well.
>>> Is it just me or anyone else sees a security issue with the generate
 password change?
>>> Ian/Animesh/Daan, can you please respond?
>>> 
>>> Thanks,
>>> ~Rajani
>>> 
>>> 
>>> 
>>> On 29-Jan-2014, at 10:59 am, Rajani Karuturi <
 rajani.karut...@citrix.com> wrote:
>>> 
 Hi Ian,
 Before it is pushed to 4.3, can you fix the generate password change
 like i suggested in the other mail? This current change would make it
>> less
 secure.
 
 Thanks,
 ~Rajani
 
 
 
 On 29-Jan-2014, at 8:03 am, Ian Duffy  wrote:
 
> Hi Animesh,
> 
> Tested all those changes to detail. Those lines were removed due to
> unexpected behavior that I had not spotted until now.
> 
> They were suppose to allow for be

Re: Devcloud 2 - veewee/Vagrant projects

[Sebastien Goasguen]

On Jan 31, 2014, at 12:25 PM, chris snow  wrote:

> I finally got the packer built devcloud box to boot with vagrant, but
> running 'xe vm-list' in it results in:
> 
> Error: Connection refused (calling connect )
> 
> I'm going to do some more investigation, but could take a while as I
> get to learn xen.
> 
> To make things easy while working on this I've created a github project here 
> [2]
> 

I cloned it, the packer builds works and the vagrant export as well.
I was able to vagrant up/ssh.

I noticed couple things.

1-the Xen setup. Check Rohit's blog http://bhaisaab.org he has a section on DIY 
Devcloud, where he shows how to setup Xen, namely xapi toolstack and creating a 
echo plugin.I think that's what you are missing, you can probably add this to 
your posinstall script

2-We switched master to java 7, so you should switch to openjdk-7

3- you might be missing a mysql-python-connector package and you should setup 
the mysql password as null (for dev).

This is looking quite nice :)

> I've added the problem above as an issue on github.
> 
> ---
> [1] https://wiki.openstack.org/wiki/XenServer/VirtualBox#Installing_XCP
> [2] https://github.com/snowch/devcloud
> 
> On Thu, Jan 30, 2014 at 7:18 AM, Rohit Yadav  wrote:
>> On Thu, Jan 30, 2014 at 4:14 AM, Sebastien Goasguen  wrote:
>>> 
>>> On Jan 29, 2014, at 1:57 PM, chris snow  wrote:
>>> 
 I have started thinking about some options:
 
 1)  use packer to convert the devcloud2 veewee definition as a starting 
 point
 2) create devcloud3 from scratch
 3) start with an existing packer definition (e.g. [1])
 
 Do you have a view on which option may be most suitable?
 
>>> 
>>> My view would be to start from scratch but of course looking at what has 
>>> been done.
>>> 
>>> In an ideal world, I would love to see a packer/vagrant file that would do:
>>> 
>>> -Ubuntu and CentOS
>>> -Xen and KVM
>>> 
>>> That way we can decide on what to build. Of course there might be issues 
>>> due to the PV/HVM support in vbox and the OS chosen.
>>> I don't recall what the issue was that made Rohit use Debian (but see 
>>> http://bhaisaab.org/logs/devcloud/), but ideally it would be good to use 
>>> stock ubuntu 12.04 or 13.04
>> 
>> DevCloud is just an appliance that facilitates a virtual host
>> (hypervisor) for development with CloudStack. So, I chose Debian
>> because well it's the best in terms of packages, stability, security
>> and is usually rock solid. Ubuntu at the time had a networking issue
>> that did not let me use xenbr0 for use over host-only network, I did
>> not invest much time on it but rather switched to Debian.
>> 
>> I suggest we stick to Debian as it would be least painful for anyone
>> IMO and the problem we're trying to solve is to enable developers have
>> a robust (possibly multi-vm) hypervisor host in box (vm) over a
>> desktop virtualization platform (virtualbox, kvm etc.)
>> 
>> (IMHO -- I wonder if you've tried latest rock-solid Fedora 20, Ubuntu
>> should have been least recommended distro by now don't use it please).
>> 
>>> I list 13.04 because there seems to be an issue with libvirt in 12.04 in 
>>> the case that you want ceph 
>>> (http://ceph.com/docs/master/rbd/rbd-cloudstack/). Of course ceph on a 
>>> single node does not make sense, but for a devcloud3 setup we could imagine 
>>> setting up ceph in it and use it as primary storage.
>> 
>> Why not build libvirt version we want? In case we want to stay updated
>> I can help you with Fedora 20 based base or Arch based base for
>> devcloud. I've been using Fedora for some months now and I guess if
>> someone want latest and greatest but want to avoid a lot of sysadmin
>> work as with Arch Linux just go with Fedora. Linux users (new and old)
>> have more or less been inclined to Debian because yum-based distros
>> were in really bad shape few years ago and that's when like others I
>> shifted to using Ubuntu. But it's not the case anymore and Ubuntu has
>> tons of problems now and rpm-based distros deserver one shot.
>> 
>>> 
>>> I mention KVM because if one uses VMware workstation than KVM would be an 
>>> option.
>>> 
>>> What I am doing these days is taking a veewee bare definition and using 
>>> veewee-to-packer to get started with packer. I install chef/salt/puppet 
>>> agents in the image so that I can use the 3 of them if I want to.
>>> 
 If we go with option 2 or 3, do you think debian 7.0 should be used as
 a starting point, or another version such as 7.2 or 7.3?  Or even
 another distro?
>> 
>> Feel free to choose whatever distro gives us all the tools and whatnot
>> to solve our problem. Distros and tools are not the problem having a
>> host in a box for CloudStack development is the problem.
>> 
 
 Are these goals still valid for devcloud3?
 
 - Two network interfaces, host-only adapter so that the VM is
 reachable from host os and a NAT so VMs can access Internet.
>> 
>> This I guess will be most appreci

Re: Devcloud 2 - veewee/Vagrant projects

[Sebastien Goasguen]

On Feb 1, 2014, at 4:03 PM, Sebastien Goasguen  wrote:

> 
> On Jan 31, 2014, at 12:25 PM, chris snow  wrote:
> 
>> I finally got the packer built devcloud box to boot with vagrant, but
>> running 'xe vm-list' in it results in:
>> 
>> Error: Connection refused (calling connect )
>> 
>> I'm going to do some more investigation, but could take a while as I
>> get to learn xen.
>> 
>> To make things easy while working on this I've created a github project here 
>> [2]
>> 
> 
> I cloned it, the packer builds works and the vagrant export as well.
> I was able to vagrant up/ssh.
> 
> I noticed couple things.
> 
> 1-the Xen setup. Check Rohit's blog http://bhaisaab.org he has a section on 
> DIY Devcloud, where he shows how to setup Xen, namely xapi toolstack and 
> creating a echo plugin.I think that's what you are missing, you can probably 
> add this to your posinstall script
> 
> 2-We switched master to java 7, so you should switch to openjdk-7
> 
> 3- you might be missing a mysql-python-connector package and you should setup 
> the mysql password as null (for dev).
> 

One more. It looks like there is only one interface (NAT), probably need to 
play with the pressed.cfg to add a host only interface:
https://github.com/snowch/devcloud/blob/master/http/preseed.cfg

> This is looking quite nice :)
> 
>> I've added the problem above as an issue on github.
>> 
>> ---
>> [1] https://wiki.openstack.org/wiki/XenServer/VirtualBox#Installing_XCP
>> [2] https://github.com/snowch/devcloud
>> 
>> On Thu, Jan 30, 2014 at 7:18 AM, Rohit Yadav  wrote:
>>> On Thu, Jan 30, 2014 at 4:14 AM, Sebastien Goasguen  
>>> wrote:
 
 On Jan 29, 2014, at 1:57 PM, chris snow  wrote:
 
> I have started thinking about some options:
> 
> 1)  use packer to convert the devcloud2 veewee definition as a starting 
> point
> 2) create devcloud3 from scratch
> 3) start with an existing packer definition (e.g. [1])
> 
> Do you have a view on which option may be most suitable?
> 
 
 My view would be to start from scratch but of course looking at what has 
 been done.
 
 In an ideal world, I would love to see a packer/vagrant file that would do:
 
 -Ubuntu and CentOS
 -Xen and KVM
 
 That way we can decide on what to build. Of course there might be issues 
 due to the PV/HVM support in vbox and the OS chosen.
 I don't recall what the issue was that made Rohit use Debian (but see 
 http://bhaisaab.org/logs/devcloud/), but ideally it would be good to use 
 stock ubuntu 12.04 or 13.04
>>> 
>>> DevCloud is just an appliance that facilitates a virtual host
>>> (hypervisor) for development with CloudStack. So, I chose Debian
>>> because well it's the best in terms of packages, stability, security
>>> and is usually rock solid. Ubuntu at the time had a networking issue
>>> that did not let me use xenbr0 for use over host-only network, I did
>>> not invest much time on it but rather switched to Debian.
>>> 
>>> I suggest we stick to Debian as it would be least painful for anyone
>>> IMO and the problem we're trying to solve is to enable developers have
>>> a robust (possibly multi-vm) hypervisor host in box (vm) over a
>>> desktop virtualization platform (virtualbox, kvm etc.)
>>> 
>>> (IMHO -- I wonder if you've tried latest rock-solid Fedora 20, Ubuntu
>>> should have been least recommended distro by now don't use it please).
>>> 
 I list 13.04 because there seems to be an issue with libvirt in 12.04 in 
 the case that you want ceph 
 (http://ceph.com/docs/master/rbd/rbd-cloudstack/). Of course ceph on a 
 single node does not make sense, but for a devcloud3 setup we could 
 imagine setting up ceph in it and use it as primary storage.
>>> 
>>> Why not build libvirt version we want? In case we want to stay updated
>>> I can help you with Fedora 20 based base or Arch based base for
>>> devcloud. I've been using Fedora for some months now and I guess if
>>> someone want latest and greatest but want to avoid a lot of sysadmin
>>> work as with Arch Linux just go with Fedora. Linux users (new and old)
>>> have more or less been inclined to Debian because yum-based distros
>>> were in really bad shape few years ago and that's when like others I
>>> shifted to using Ubuntu. But it's not the case anymore and Ubuntu has
>>> tons of problems now and rpm-based distros deserver one shot.
>>> 
 
 I mention KVM because if one uses VMware workstation than KVM would be an 
 option.
 
 What I am doing these days is taking a veewee bare definition and using 
 veewee-to-packer to get started with packer. I install chef/salt/puppet 
 agents in the image so that I can use the 3 of them if I want to.
 
> If we go with option 2 or 3, do you think debian 7.0 should be used as
> a starting point, or another version such as 7.2 or 7.3?  Or even
> another distro?
>>> 
>>> Feel free to choose whatever distro gives us al

Re: ReviewBoard

[Daan Hoogland]

H David,

have you started on this yet?
I can't reach the review board at the moment.

On Mon, Jan 27, 2014 at 8:59 PM, David Nalley  wrote:
> Hi folks:
>
> ReviewBoard is pretty bloated. There are currently 93 reviews that are open.
>
> Some of those haven't been updated in 7 months old.
>
> Unless someone objects (and promptly begins reviewing and applying
> patches) I will close any patch that hasn't been updated in 2 months.
>
> Please take a few minutes to go look through ReviewBoard and update
> things as appropriate.
>
> --David

Re: Devcloud 2 - veewee/Vagrant projects

[chris snow]

Thanks for the feedback Sebastien, it's much appreciated.

I'll investigate in more detail over the next few days...

On Sat, Feb 1, 2014 at 9:06 PM, Sebastien Goasguen  wrote:
>
> On Feb 1, 2014, at 4:03 PM, Sebastien Goasguen  wrote:
>
>>
>> On Jan 31, 2014, at 12:25 PM, chris snow  wrote:
>>
>>> I finally got the packer built devcloud box to boot with vagrant, but
>>> running 'xe vm-list' in it results in:
>>>
>>> Error: Connection refused (calling connect )
>>>
>>> I'm going to do some more investigation, but could take a while as I
>>> get to learn xen.
>>>
>>> To make things easy while working on this I've created a github project 
>>> here [2]
>>>
>>
>> I cloned it, the packer builds works and the vagrant export as well.
>> I was able to vagrant up/ssh.
>>
>> I noticed couple things.
>>
>> 1-the Xen setup. Check Rohit's blog http://bhaisaab.org he has a section on 
>> DIY Devcloud, where he shows how to setup Xen, namely xapi toolstack and 
>> creating a echo plugin.I think that's what you are missing, you can probably 
>> add this to your posinstall script
>>
>> 2-We switched master to java 7, so you should switch to openjdk-7
>>
>> 3- you might be missing a mysql-python-connector package and you should 
>> setup the mysql password as null (for dev).
>>
>
> One more. It looks like there is only one interface (NAT), probably need to 
> play with the pressed.cfg to add a host only interface:
> https://github.com/snowch/devcloud/blob/master/http/preseed.cfg
>
>> This is looking quite nice :)
>>
>>> I've added the problem above as an issue on github.
>>>
>>> ---
>>> [1] https://wiki.openstack.org/wiki/XenServer/VirtualBox#Installing_XCP
>>> [2] https://github.com/snowch/devcloud
>>>
>>> On Thu, Jan 30, 2014 at 7:18 AM, Rohit Yadav  wrote:
 On Thu, Jan 30, 2014 at 4:14 AM, Sebastien Goasguen  
 wrote:
>
> On Jan 29, 2014, at 1:57 PM, chris snow  wrote:
>
>> I have started thinking about some options:
>>
>> 1)  use packer to convert the devcloud2 veewee definition as a starting 
>> point
>> 2) create devcloud3 from scratch
>> 3) start with an existing packer definition (e.g. [1])
>>
>> Do you have a view on which option may be most suitable?
>>
>
> My view would be to start from scratch but of course looking at what has 
> been done.
>
> In an ideal world, I would love to see a packer/vagrant file that would 
> do:
>
> -Ubuntu and CentOS
> -Xen and KVM
>
> That way we can decide on what to build. Of course there might be issues 
> due to the PV/HVM support in vbox and the OS chosen.
> I don't recall what the issue was that made Rohit use Debian (but see 
> http://bhaisaab.org/logs/devcloud/), but ideally it would be good to use 
> stock ubuntu 12.04 or 13.04

 DevCloud is just an appliance that facilitates a virtual host
 (hypervisor) for development with CloudStack. So, I chose Debian
 because well it's the best in terms of packages, stability, security
 and is usually rock solid. Ubuntu at the time had a networking issue
 that did not let me use xenbr0 for use over host-only network, I did
 not invest much time on it but rather switched to Debian.

 I suggest we stick to Debian as it would be least painful for anyone
 IMO and the problem we're trying to solve is to enable developers have
 a robust (possibly multi-vm) hypervisor host in box (vm) over a
 desktop virtualization platform (virtualbox, kvm etc.)

 (IMHO -- I wonder if you've tried latest rock-solid Fedora 20, Ubuntu
 should have been least recommended distro by now don't use it please).

> I list 13.04 because there seems to be an issue with libvirt in 12.04 in 
> the case that you want ceph 
> (http://ceph.com/docs/master/rbd/rbd-cloudstack/). Of course ceph on a 
> single node does not make sense, but for a devcloud3 setup we could 
> imagine setting up ceph in it and use it as primary storage.

 Why not build libvirt version we want? In case we want to stay updated
 I can help you with Fedora 20 based base or Arch based base for
 devcloud. I've been using Fedora for some months now and I guess if
 someone want latest and greatest but want to avoid a lot of sysadmin
 work as with Arch Linux just go with Fedora. Linux users (new and old)
 have more or less been inclined to Debian because yum-based distros
 were in really bad shape few years ago and that's when like others I
 shifted to using Ubuntu. But it's not the case anymore and Ubuntu has
 tons of problems now and rpm-based distros deserver one shot.

>
> I mention KVM because if one uses VMware workstation than KVM would be an 
> option.
>
> What I am doing these days is taking a veewee bare definition and using 
> veewee-to-packer to get started with packer. I install chef/salt/puppet 
> agents in the image so that I

Review Request 17638: Rest client moved to utils. Nvp extended.

[Antonio Fornie]

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

Review request for cloudstack, daan Hoogland and Hugo Trippaers.


Repository: cloudstack-git


Description
---

Rest client moved to utils in a generic way so it can be reused (from 
opendaylight, for example). Incremented integration tests. Also include 
cobertura and it-cobertura. Nvp extended with a few methods missing.


Diffs
-

  plugins/network-elements/nicira-nvp/pom.xml a4b4c49 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/AccessConfiguration.java
 74fe19d 
  plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/Acl.java 
3a9b387 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/BaseNiciraEntity.java
 PRE-CREATION 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/BaseNiciraNamedEntity.java
 PRE-CREATION 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/LogicalRouter.java
 PRE-CREATION 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/LogicalRouterConfig.java
 5c99e15 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/LogicalRouterPort.java
 ed1b8da 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/LogicalSwitch.java
 c2d75a7 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/LogicalSwitchPort.java
 da58c78 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraNvpApi.java
 92c23eb 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/SingleDefaultRouteImplicitRoutingConfig.java
 PRE-CREATION 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/SingleDefaultRouteImplictRoutingConfig.java
 d386e70 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/VifAttachment.java
 7b37ac1 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/resource/NiciraNvpResource.java
 8c99a81 
  
plugins/network-elements/nicira-nvp/test/com/cloud/network/element/NiciraNvpElementTest.java
 436c86c 
  
plugins/network-elements/nicira-nvp/test/com/cloud/network/guru/NiciraNvpGuestNetworkGuruTest.java
 3e303b8 
  
plugins/network-elements/nicira-nvp/test/com/cloud/network/nicira/NatRuleTest.java
 1a63527 
  
plugins/network-elements/nicira-nvp/test/com/cloud/network/nicira/NiciraNvpApiIT.java
 c541d87 
  
plugins/network-elements/nicira-nvp/test/com/cloud/network/nicira/NiciraNvpApiTest.java
 2e4cfaf 
  
plugins/network-elements/nicira-nvp/test/com/cloud/network/nicira/NiciraTagTest.java
 7512803 
  
plugins/network-elements/nicira-nvp/test/com/cloud/network/resource/NiciraNvpResourceTest.java
 ad01218 
  pom.xml 85cfb89 
  utils/pom.xml f63d7c4 
  utils/src/com/cloud/utils/rest/BasicEncodedRESTValidationStrategy.java 
PRE-CREATION 
  utils/src/com/cloud/utils/rest/CloudstackRESTException.java PRE-CREATION 
  utils/src/com/cloud/utils/rest/RESTServiceConnector.java PRE-CREATION 
  utils/src/com/cloud/utils/rest/RESTValidationStrategy.java PRE-CREATION 
  utils/test/com/cloud/utils/rest/RESTServiceConnectorTest.java PRE-CREATION 

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


Testing
---

mvn full build plus unit and integration tests


Thanks,

Antonio Fornie