cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prachi Damle <Prachi.Da...@citrix.com>
Subject RE: VMEntityVO and VMInstanceVO
Date Mon, 16 Dec 2013 21:48:16 GMT
Koushik,

This is part of the cloud-engine / orchestration layer refactoring started in 4.1. The final
idea is to separate out the cloudstack API layer and  the orchestration logic into different
services. Each service will have its own set of VO's as per the view the service works with.
Thus the VO will populate/retrieve only those fields that are visible/essential for that service
functionality. Hence you see some difference in the two VO's you mention.
The VM deployment API layer works with VMInstanceVO ; while the orchestration flow works with
VMEntityVO.

There are many other entities for which this has been done so far, Alex has put everything
under cloud-engine-schema recently where you can find some more of such examples.

Prachi

-----Original Message-----
From: Koushik Das 
Sent: Sunday, December 15, 2013 9:50 PM
To: <dev@cloudstack.apache.org>
Cc: Prachi Damle
Subject: Re: VMEntityVO and VMInstanceVO

Prachi, From the history I see that you added VMEntityVO. Any specific reason for having both?

On 12-Dec-2013, at 2:36 PM, Koushik Das <koushik.das@citrix.com> wrote:

> I see that both the VOs uses the same vm_instance table. What is the need for having
2 VOs for the same table? Should one be removed?
> Also VMEntityVO I see a field called "speed" which is not there in VMInstanceVO. Why
this discrepancy?
> 
> Thanks,
> Koushik


Mime
View raw message