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