For now I have removed cpu, ram and cpu speed fields from vm_instance table.
On 18-Dec-2013, at 6:22 AM, Prachi Damle <prachi.da...@citrix.com> wrote: > 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 >> >
