Koushik, My comments inline.
Prachi -----Original Message----- From: Koushik Das Sent: Tuesday, December 17, 2013 4:06 AM To: Prachi Damle; <dev@cloudstack.apache.org> 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. -Koushik On 17-Dec-2013, at 3:18 AM, Prachi Damle <prachi.da...@citrix.com> 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: <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 >
