cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prachi Damle <>
Subject RE: VMEntityVO and VMInstanceVO
Date Wed, 18 Dec 2013 00:52:57 GMT

My comments inline.

-----Original Message-----
From: Koushik Das 
Sent: Tuesday, December 17, 2013 4:06 AM
To: Prachi Damle; <>
Subject: Re: VMEntityVO and VMInstanceVO

Thanks Prachi.
I was looking at CLOUDSTACK-5458 when I came across this.

I don't quite follow the logic of multiple VOs based on a subset of fields. If multiple VOs
are targeting a subset of fields for the same row in the db. then that essentially means that
the fields in each subset must be independent of each other. If there is any dependency between
the subsets/views than managing them will be very complex. One service can update its subset
of fields and make the other fields inconsistent (the specific bug I have mentioned is an
example). And if the subsets must be independent then isn't it simpler to have separate tables?

>>Ideal solution is to have independent tables. But this was the intermediate solution
we thought of to achieve the separation of services while affecting minimal functionality
and then separate out the DB's too in a later phase.

Also why the VMEntityVO has fields like cpu, speed, memory when these are already part of
service offering?
>> Orchestration layer does not have any notion of service offering - offering is a
pure business logic of the API layer.  So the view of the orchestration layer is flat and
carries all  the parameters it needs to talk to the backend inorder to get the VM running.

>>Hence these fields are carried into the VMEntityVO directly.
>>I looked at the bug and talked to Alex as well. Currently it seems correct to just
remove these extra fields from the vm_instance table and the VO for now until we resume the
refactoring further in this direction. I think these fields are not being used anywhere yet.


On 17-Dec-2013, at 3:18 AM, Prachi Damle <> wrote:

> 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: <>
> Cc: Prachi Damle
> Subject: Re: VMEntityVO and VMInstanceVO
> Prachi, From the history I see that you added VMEntityVO. Any specific reason for having
> On 12-Dec-2013, at 2:36 PM, Koushik Das <> 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

View raw message