[Engine-devel] vds_dynamic refactor

Gilad Chaplik gchaplik at redhat.com
Thu Apr 3 17:40:08 UTC 2014


----- Original Message -----
> From: "Liran Zelkha" <liran.zelkha at gmail.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "Omer Frenkel" <ofrenkel at redhat.com>, "Eli Mesika" <emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>,
> devel at linode01.ovirt.org
> Sent: Thursday, April 3, 2014 7:51:39 PM
> Subject: Re: [Engine-devel] vds_dynamic refactor
> 
> On Thu, Apr 3, 2014 at 5:33 PM, Gilad Chaplik <gchaplik at redhat.com> wrote:
> 
> > *From: *"Liran Zelkha" <liran.zelkha at gmail.com>
> > *To: *"Gilad Chaplik" <gchaplik at redhat.com>
> > *Cc: *"Omer Frenkel" <ofrenkel at redhat.com>, "Eli Mesika" <
> > emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> > *Sent: *Thursday, April 3, 2014 5:27:56 PM
> > *Subject: *Re: [Engine-devel] vds_dynamic refactor
> >
> > True but that's no reason to have a bad schema
> >
> > I'm open to new ideas and truly want to understand what is bad?
> >
> The problem is with both updates and selects.
> For selects - to get all the information for the VDS we have multiple
> joins. Adding another one will hurt performance even more.

What about creating the VDS list in the db. i.e. your patch [1] about constructing VDS objects in the engine, should occur in the db within a SP, and should be transparent to the server. that will solve the multiple table join.

[1] http://gerrit.ovirt.org/#/c/21662/

> For updates - we have vds_static thats hardly changed. vds_statistics that
> changes all the time. vds_dynamic is not changed allot - but is updated all
> the time because of the status. I think it's best to split it to the two
> existing tables (BTW - relevant for VM as well)
> 

- As omer stated in a separate thread static stores users config.
- Updating status/pending resources in statistics sounds very racy.

saying that, I think I have a valid argument for vds_on_boot table.

Thanks, 
Gilad.


> > On Apr 3, 2014 5:18 PM, "Gilad Chaplik" <gchaplik at redhat.com> wrote:
> >
> >> ----- Original Message -----
> >> > From: "Liran Zelkha" <liran.zelkha at gmail.com>
> >> > To: "Gilad Chaplik" <gchaplik at redhat.com>
> >> > Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel" <
> >> engine-devel at ovirt.org>
> >> > Sent: Thursday, April 3, 2014 5:16:51 PM
> >> > Subject: Re: [Engine-devel] vds_dynamic refactor
> >> >
> >> > Don't go down that road.  Status shouldn't be saved in the db.
> >> > But anyway statistics is rapidly changing. So it fits...
> >>
> >> First let's have a notion of caching, then notion of shared caching, then
> >> I can start thinking of not going down that road...
> >>
> >> > On Apr 3, 2014 5:14 PM, "Gilad Chaplik" <gchaplik at redhat.com> wrote:
> >> >
> >> > > ----- Original Message -----
> >> > > > From: "Liran Zelkha" <liran.zelkha at gmail.com>
> >> > > > To: "Eli Mesika" <emesika at redhat.com>
> >> > > > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "engine-devel" <
> >> > > engine-devel at ovirt.org>
> >> > > > Sent: Thursday, April 3, 2014 4:36:07 PM
> >> > > > Subject: Re: [Engine-devel] vds_dynamic refactor
> >> > > >
> >> > > > I would be happy if we can lose vds_dynamic all together, and just
> >> keep
> >> > > > vds_static and vds_statistics. Our performance will be happy too ;-)
> >> > > >
> >> > >
> >> > > @Liran, status and pending fields are very fragile ones, IMO need
> >> separate
> >> > > table.
> >> > > @Eli, iirc, you don't have a problem with adding more tables :-)
> >> > >
> >> > > >
> >> > > > On Thu, Apr 3, 2014 at 4:33 PM, Eli Mesika <emesika at redhat.com>
> >> wrote:
> >> > > >
> >> > > > >
> >> > > > >
> >> > > > > ----- Original Message -----
> >> > > > > > From: "Gilad Chaplik" <gchaplik at redhat.com>
> >> > > > > > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> >> > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> >> > > > > > Sent: Thursday, April 3, 2014 4:00:25 PM
> >> > > > > > Subject: Re: [Engine-devel] vds_dynamic refactor
> >> > > > > >
> >> > > > > > ----- Original Message -----
> >> > > > > > > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> >> > > > > > > To: "Liran Zelkha" <liran.zelkha at gmail.com>
> >> > > > > > > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "engine-devel"
> >> > > > > > > <engine-devel at ovirt.org>
> >> > > > > > > Sent: Thursday, April 3, 2014 2:12:59 PM
> >> > > > > > > Subject: Re: [Engine-devel] vds_dynamic refactor
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > ----- Original Message -----
> >> > > > > > > > From: "Liran Zelkha" <liran.zelkha at gmail.com>
> >> > > > > > > > To: "Gilad Chaplik" <gchaplik at redhat.com>
> >> > > > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> >> > > > > > > > Sent: Thursday, April 3, 2014 2:04:29 PM
> >> > > > > > > > Subject: Re: [Engine-devel] vds_dynamic refactor
> >> > > > > > > >
> >> > > > > > > > Why not move it to vds_static?
> >> > > > > > >
> >> > > > > > > +1 on Liran's comment.
> >> > > > >
> >> > > > > +1 as well , vds_static is the place for that
> >> > > > >
> >> > > > > > > I would prefer not to add more complexity to the  vds tables
> >> > > family.
> >> > > > > > > Such complexity may effect performs of queries/views.
> >> > > > > > > If you wish, you can create a view on top of vds_static named
> >> > > > > vds_on_boot
> >> > > > > > > for
> >> > > > > > > querying of vds on boot info.
> >> > > > > > >
> >> > > > > > > Yair
> >> > > > > >
> >> > > > > > That means moving almost all of vds_dynamic into vds_static
> >> except of
> >> > > > > memory,
> >> > > > > > pending resources and status (maybe more but not much);
> >> > > > > > and there will not be any db separation between user input and
> >> > > on_boot
> >> > > > > data.
> >> > > > >
> >> > > > > Why we should have such separation ?
> >> > > > >
> >> > > > > >
> >> > > > > > Thanks,
> >> > > > > > Gilad.
> >> > > > > >
> >> > > > > > >
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > On Thu, Apr 3, 2014 at 2:00 PM, Gilad Chaplik <
> >> > > gchaplik at redhat.com>
> >> > > > > > > > wrote:
> >> > > > > > > >
> >> > > > > > > > > Hi list,
> >> > > > > > > > >
> >> > > > > > > > > I propose to split vds_dynamic table into 2 tables:
> >> > > > > > > > > - vds_dynamic
> >> > > > > > > > > - vds_on_boot
> >> > > > > > > > > We need a place to put all non-dynamic data that gets
> >> updated
> >> > > once
> >> > > > > the
> >> > > > > > > > > host is booted, and I think dynamic isn't the place for
> >> it.
> >> > > > > > > > > In first phase we will put there NUMA host topoplogy, but
> >> > > later on
> >> > > > > > > > > migrate
> >> > > > > > > > > all non-dynamic host data (cpu, os, etc.).
> >> > > > > > > > >
> >> > > > > > > > > thoughts?
> >> > > > > > > > >
> >> > > > > > > > > Thanks,
> >> > > > > > > > > Gilad.
> >> > > > > > > > > _______________________________________________
> >> > > > > > > > > Engine-devel mailing list
> >> > > > > > > > > Engine-devel at ovirt.org
> >> > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > > > _______________________________________________
> >> > > > > > > > Engine-devel mailing list
> >> > > > > > > > Engine-devel at ovirt.org
> >> > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >> > > > > > > >
> >> > > > > > >
> >> > > > > > _______________________________________________
> >> > > > > > Engine-devel mailing list
> >> > > > > > Engine-devel at ovirt.org
> >> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >> > > > > >
> >> > > > > _______________________________________________
> >> > > > > Engine-devel mailing list
> >> > > > > Engine-devel at ovirt.org
> >> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
> 



More information about the Engine-devel mailing list