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... On Apr 3, 2014 5:14 PM, Gilad Chaplik gchap...@redhat.com wrote: - Original Message - From: Liran Zelkha liran.zel...@gmail.com To: Eli Mesika emes...@redhat.com Cc: Gilad Chaplik gchap...@redhat.com, engine-devel engine-devel@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 emes...@redhat.com wrote: - Original Message - From: Gilad Chaplik gchap...@redhat.com To: Yair Zaslavsky yzasl...@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 yzasl...@redhat.com To: Liran Zelkha liran.zel...@gmail.com Cc: Gilad Chaplik gchap...@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.zel...@gmail.com To: Gilad Chaplik gchap...@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 gchap...@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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] vds_dynamic refactor
- Original Message - From: Liran Zelkha liran.zel...@gmail.com To: Eli Mesika emes...@redhat.com Cc: Gilad Chaplik gchap...@redhat.com, engine-devel engine-devel@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 emes...@redhat.com wrote: - Original Message - From: Gilad Chaplik gchap...@redhat.com To: Yair Zaslavsky yzasl...@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 yzasl...@redhat.com To: Liran Zelkha liran.zel...@gmail.com Cc: Gilad Chaplik gchap...@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.zel...@gmail.com To: Gilad Chaplik gchap...@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 gchap...@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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] vds_dynamic refactor
- Original Message - From: Liran Zelkha liran.zel...@gmail.com To: Gilad Chaplik gchap...@redhat.com Cc: Eli Mesika emes...@redhat.com, engine-devel engine-devel@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 gchap...@redhat.com wrote: - Original Message - From: Liran Zelkha liran.zel...@gmail.com To: Eli Mesika emes...@redhat.com Cc: Gilad Chaplik gchap...@redhat.com, engine-devel engine-devel@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 emes...@redhat.com wrote: - Original Message - From: Gilad Chaplik gchap...@redhat.com To: Yair Zaslavsky yzasl...@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 yzasl...@redhat.com To: Liran Zelkha liran.zel...@gmail.com Cc: Gilad Chaplik gchap...@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.zel...@gmail.com To: Gilad Chaplik gchap...@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 gchap...@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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] vds_dynamic refactor
True but that's no reason to have a bad schema On Apr 3, 2014 5:18 PM, Gilad Chaplik gchap...@redhat.com wrote: - Original Message - From: Liran Zelkha liran.zel...@gmail.com To: Gilad Chaplik gchap...@redhat.com Cc: Eli Mesika emes...@redhat.com, engine-devel engine-devel@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 gchap...@redhat.com wrote: - Original Message - From: Liran Zelkha liran.zel...@gmail.com To: Eli Mesika emes...@redhat.com Cc: Gilad Chaplik gchap...@redhat.com, engine-devel engine-devel@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 emes...@redhat.com wrote: - Original Message - From: Gilad Chaplik gchap...@redhat.com To: Yair Zaslavsky yzasl...@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 yzasl...@redhat.com To: Liran Zelkha liran.zel...@gmail.com Cc: Gilad Chaplik gchap...@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.zel...@gmail.com To: Gilad Chaplik gchap...@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 gchap...@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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] vds_dynamic refactor
On Thu, Apr 3, 2014 at 5:33 PM, Gilad Chaplik gchap...@redhat.com wrote: *From: *Liran Zelkha liran.zel...@gmail.com *To: *Gilad Chaplik gchap...@redhat.com *Cc: *Omer Frenkel ofren...@redhat.com, Eli Mesika emes...@redhat.com, engine-devel engine-devel@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. 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) On Apr 3, 2014 5:18 PM, Gilad Chaplik gchap...@redhat.com wrote: - Original Message - From: Liran Zelkha liran.zel...@gmail.com To: Gilad Chaplik gchap...@redhat.com Cc: Eli Mesika emes...@redhat.com, engine-devel engine-devel@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 gchap...@redhat.com wrote: - Original Message - From: Liran Zelkha liran.zel...@gmail.com To: Eli Mesika emes...@redhat.com Cc: Gilad Chaplik gchap...@redhat.com, engine-devel engine-devel@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 emes...@redhat.com wrote: - Original Message - From: Gilad Chaplik gchap...@redhat.com To: Yair Zaslavsky yzasl...@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 yzasl...@redhat.com To: Liran Zelkha liran.zel...@gmail.com Cc: Gilad Chaplik gchap...@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.zel...@gmail.com To: Gilad Chaplik gchap...@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 gchap...@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
Re: [Engine-devel] vds_dynamic refactor
From: Liran Zelkha liran.zel...@gmail.com To: Gilad Chaplik gchap...@redhat.com Cc: Omer Frenkel ofren...@redhat.com, Eli Mesika emes...@redhat.com, engine-devel engine-devel@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? On Apr 3, 2014 5:18 PM, Gilad Chaplik gchap...@redhat.com wrote: - Original Message - From: Liran Zelkha liran.zel...@gmail.com To: Gilad Chaplik gchap...@redhat.com Cc: Eli Mesika emes...@redhat.com , engine-devel engine-devel@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 gchap...@redhat.com wrote: - Original Message - From: Liran Zelkha liran.zel...@gmail.com To: Eli Mesika emes...@redhat.com Cc: Gilad Chaplik gchap...@redhat.com , engine-devel engine-devel@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 emes...@redhat.com wrote: - Original Message - From: Gilad Chaplik gchap...@redhat.com To: Yair Zaslavsky yzasl...@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 yzasl...@redhat.com To: Liran Zelkha liran.zel...@gmail.com Cc: Gilad Chaplik gchap...@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.zel...@gmail.com To: Gilad Chaplik gchap...@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 gchap...@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
Re: [Engine-devel] vds_dynamic refactor
Why not move it to vds_static? On Thu, Apr 3, 2014 at 2:00 PM, Gilad Chaplik gchap...@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
Re: [Engine-devel] vds_dynamic refactor
- Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Liran Zelkha liran.zel...@gmail.com Cc: Gilad Chaplik gchap...@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.zel...@gmail.com To: Gilad Chaplik gchap...@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 gchap...@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
Re: [Engine-devel] vds_dynamic refactor
- Original Message - From: Gilad Chaplik gchap...@redhat.com To: Yair Zaslavsky yzasl...@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 yzasl...@redhat.com To: Liran Zelkha liran.zel...@gmail.com Cc: Gilad Chaplik gchap...@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.zel...@gmail.com To: Gilad Chaplik gchap...@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 gchap...@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
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 ;-) On Thu, Apr 3, 2014 at 4:33 PM, Eli Mesika emes...@redhat.com wrote: - Original Message - From: Gilad Chaplik gchap...@redhat.com To: Yair Zaslavsky yzasl...@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 yzasl...@redhat.com To: Liran Zelkha liran.zel...@gmail.com Cc: Gilad Chaplik gchap...@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.zel...@gmail.com To: Gilad Chaplik gchap...@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 gchap...@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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
