[Engine-devel] vds_dynamic refactor
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.
Why not move it to vds_static? On Thu, Apr 3, 2014 at 2:00 PM, Gilad Chaplik <gchaplik@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Liran Zelkha" <liran.zelkha@gmail.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: "engine-devel" <engine-devel@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. 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
On Thu, Apr 3, 2014 at 2:00 PM, Gilad Chaplik <gchaplik@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Liran Zelkha" <liran.zelkha@gmail.com> Cc: "Gilad Chaplik" <gchaplik@redhat.com>, "engine-devel" <engine-devel@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@gmail.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: "engine-devel" <engine-devel@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. 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. Thanks, Gilad.
On Thu, Apr 3, 2014 at 2:00 PM, Gilad Chaplik <gchaplik@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Gilad Chaplik" <gchaplik@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Thursday, April 3, 2014 4:00:25 PM Subject: Re: [Engine-devel] vds_dynamic refactor
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Liran Zelkha" <liran.zelkha@gmail.com> Cc: "Gilad Chaplik" <gchaplik@redhat.com>, "engine-devel" <engine-devel@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@gmail.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: "engine-devel" <engine-devel@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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 ;-) On Thu, Apr 3, 2014 at 4:33 PM, Eli Mesika <emesika@redhat.com> wrote:
----- Original Message -----
From: "Gilad Chaplik" <gchaplik@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Thursday, April 3, 2014 4:00:25 PM Subject: Re: [Engine-devel] vds_dynamic refactor
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Liran Zelkha" <liran.zelkha@gmail.com> Cc: "Gilad Chaplik" <gchaplik@redhat.com>, "engine-devel" <engine-devel@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@gmail.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: "engine-devel" <engine-devel@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
participants (4)
-
Eli Mesika -
Gilad Chaplik -
Liran Zelkha -
Yair Zaslavsky