[ovirt-devel] Entity names in DB scripts

Thu Jun 12 09:05:48 UTC 2014

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>, "Oved Ourfalli" <ovedo at redhat.com>
> Cc: devel at ovirt.org
> Sent: Thursday, June 12, 2014 11:19:42 AM
> Subject: Re: [ovirt-devel] Entity names in DB scripts
> 
> On 05/27/2014 06:44 AM, Gilad Chaplik wrote:
> > ----- Original Message -----
> >> From: "Oved Ourfalli" <ovedo at redhat.com>
> >> To: "Gilad Chaplik" <gchaplik at redhat.com>
> >> Cc: "Moti Asayag" <masayag at redhat.com>, devel at ovirt.org
> >> Sent: Tuesday, May 27, 2014 1:30:43 PM
> >> Subject: Re: [ovirt-devel] Entity names in DB scripts
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Gilad Chaplik" <gchaplik at redhat.com>
> >>> To: "Moti Asayag" <masayag at redhat.com>
> >>> Cc: devel at ovirt.org
> >>> Sent: Tuesday, May 27, 2014 1:27:10 PM
> >>> Subject: Re: [ovirt-devel] Entity names in DB scripts
> >>>
> >>> ----- Original Message -----
> >>>> From: "Moti Asayag" <masayag at redhat.com>
> >>>> To: "Martin Perina" <mperina at redhat.com>
> >>>> Cc: devel at ovirt.org
> >>>> Sent: Monday, May 26, 2014 12:39:17 PM
> >>>> Subject: Re: [ovirt-devel] Entity names in DB scripts
> >>>>
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Martin Perina" <mperina at redhat.com>
> >>>>> To: "Eli Mesika" <emesika at redhat.com>
> >>>>> Cc: devel at ovirt.org
> >>>>> Sent: Monday, May 19, 2014 12:43:32 PM
> >>>>> Subject: Re: [ovirt-devel] Entity names in DB scripts
> >>>>>
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Eli Mesika" <emesika at redhat.com>
> >>>>>> To: "Barak Azulay" <bazulay at redhat.com>
> >>>>>> Cc: devel at ovirt.org
> >>>>>> Sent: Monday, May 19, 2014 11:37:23 AM
> >>>>>> Subject: Re: [ovirt-devel] Entity names in DB scripts
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Barak Azulay" <bazulay at redhat.com>
> >>>>>>> To: "Eli Mesika" <emesika at redhat.com>
> >>>>>>> Cc: "Moti Asayag" <masayag at redhat.com>, devel at ovirt.org
> >>>>>>> Sent: Sunday, May 18, 2014 8:42:47 PM
> >>>>>>> Subject: Re: [ovirt-devel] Entity names in DB scripts
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Eli Mesika" <emesika at redhat.com>
> >>>>>>>> To: "Moti Asayag" <masayag at redhat.com>
> >>>>>>>> Cc: devel at ovirt.org
> >>>>>>>> Sent: Sunday, May 18, 2014 4:08:45 PM
> >>>>>>>> Subject: Re: [ovirt-devel] Entity names in DB scripts
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: "Moti Asayag" <masayag at redhat.com>
> >>>>>>>>> To: "Eli Mesika" <emesika at redhat.com>
> >>>>>>>>> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, devel at ovirt.org
> >>>>>>>>> Sent: Thursday, May 15, 2014 7:33:06 PM
> >>>>>>>>> Subject: Re: [ovirt-devel] Entity names in DB scripts
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ----- Original Message -----
> >>>>>>>>>> From: "Eli Mesika" <emesika at redhat.com>
> >>>>>>>>>> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> >>>>>>>>>> Cc: devel at ovirt.org
> >>>>>>>>>> Sent: Thursday, May 15, 2014 4:56:50 PM
> >>>>>>>>>> Subject: Re: [ovirt-devel] Entity names in DB scripts
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> ----- Original Message -----
> >>>>>>>>>>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> >>>>>>>>>>> To: devel at ovirt.org
> >>>>>>>>>>> Sent: Thursday, May 15, 2014 3:20:18 PM
> >>>>>>>>>>> Subject: [ovirt-devel] Entity names in DB scripts
> >>>>>>>>>>>
> >>>>>>>>>>> Hi all,
> >>>>>>>>>>> I have a feeling there is some inconsistency in using
> >>>>>>>>>>> entity
> >>>>>>>>>>> names
> >>>>>>>>>>> in
> >>>>>>>>>>> the
> >>>>>>>>>>> DB
> >>>>>>>>>>> scripts.
> >>>>>>>>>>> For example, should we use Host or VDS?
> >>>>>>>>>>> I am not talking about existing tables or columns but about
> >>>>>>>>>>> new
> >>>>>>>>>>> ones
> >>>>>>>>>>> (and
> >>>>>>>>>>> new
> >>>>>>>>>>> stored procedures).
> >>>>>>>>>>>
> >>>>>>>>>>> I am quite sure I saw patches containing both approaches.
> >>>>>>>>>
> >>>>>>>>> I guess that includes any recent patches around the network
> >>>>>>>>> area.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> You are right
> >>>>>>>>>> I think old should be kept until we have the time to do a
> >>>>>>>>>> global
> >>>>>>>>>> find/replace
> >>>>>>>>>> of all old names.
> >>>>>>>>>
> >>>>>>>>> Without enabling the "new" (or more appropriate) naming to new
> >>>>>>>>> code
> >>>>>>>>> we:
> >>>>>>>>> 1. Increase the amount of 'old' code in the system (gaining
> >>>>>>>>> more
> >>>>>>>>> debts)
> >>>>>>>>> 2. As a result - more work when and if global change will take
> >>>>>>>>> affect.
> >>>>>>>>> 3. Double the entire work flow: code + review.
> >>>>>>>>>
> >>>>>>>>> That change should start at some point, and having it
> >>>>>>>>> incrementally
> >>>>>>>>> is
> >>>>>>>>> a
> >>>>>>>>> valid approach
> >>>>>>>>> to achieve that goal.
> >>>>>>>>
> >>>>>>>> I basically agree, but first someone (that can say that) should
> >>>>>>>> say
> >>>>>>>> that
> >>>>>>>> we
> >>>>>>>> are going to do that and allocate resources to this tasks ,
> >>>>>>>> unless
> >>>>>>>> ,
> >>>>>>>> you
> >>>>>>>> are
> >>>>>>>> left in hybrid ugly condition
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Guys please post the list of Entities and let's agree on new names.
> >>>>>>
> >>>>>> Top 3 :
> >>>>>>
> >>>>>> StoragePool => DC
> >>>>>> VdsGroup => Cluster
> >>>
> >>> IMO VdsGroup should be named MigrationDomain[1].
> >>> cluster is too general[2].
> >>>
> >>
> >> IMHO we should name it Cluster, just like it is in the UI.
> >
> > I think the UI name it 'racimo' in Spanish, and समूह in Hindi, and not
> > 'Cluster', you have a point on REST though.
> >
> >> I wouldn't change it into MigrationDomain.
> >> Moreover, in some cases VMs might not be able to migrate to all the hosts
> >> in
> >> the cluster, depending on your configuration, so it isn't even true at all
> >> times.
> >
> > You only re-enforcing my argument :) MigrationDomain fits better than
> > Cluster.
> 
> not when we are considering more granular migration domains inside
> clusters in the future as the scheduler gets more sophisticated.
> a cluster is a group of hosts providing a set of services. so far it was
> a migration domain. it may not be in the future.

How do you understand by the word 'cluster' that cluster is a group of hosts providing a set of services?
As for granular migration domains, you can take an example from groups of users, there are also groups of groups; they're still called groups, I think it's pretty understandable. by introducing 'migration domain' for granularity your simply maintaining the virtual 'datacenter' notion, but lowering down its level (s/data center -> clusters/cluster-> migration domains/g), so the complexity sticks, and the recursion may break some when in the future: clusters/cluster-> migration domains -> ??? -> ???.

anyway Eli ACKed cluster, so I rested my case anyway (a while ago).

> 
>