[Engine-devel] vds_dynamic refactor

Fri Apr 4 01:30:35 UTC 2014

On Thu, Apr 3, 2014 at 8:40 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: "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.
>

The joins are happening on the server. We have a VDS view that brings in
information from many tables and we retrieve rows from it all the time.
Just run an explain on a select * from vds and see for yourself.

>
> [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
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140404/1220c62c/attachment.html>