From xiao-lei.shi at hp.com  Tue Apr  1 02:13:34 2014
From: xiao-lei.shi at hp.com (Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ))
Date: Tue, 1 Apr 2014 02:13:34 +0000
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <1690885238.11367.1396272677929.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<1290280076.419927.1395656626000.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD026@G5W2743.americas.hpqcorp.net>
	<1718882238.5076978.1396257170731.JavaMail.zimbra@redhat.com>
	<182238414.11560689.1396257704986.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD11A@G5W2743.americas.hpqcorp.net>
	<1087291412.5091657.1396259332718.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD16D@G5W2743.americas.hpqcorp.net>
	<1690885238.11367.1396272677929.JavaMail.zimbra@redhat.com>
Message-ID: <08AA403C8399104A89AF710307FA78AE243DD232@G5W2743.americas.hpqcorp.net>

Assemble the related discussions in this mail session.

Hi Vinod,
On 3/31/2014 2:38 AM, Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) wrote:
> We put host level NUMA fields in vds_dynamic because these information are from host itself, and NUMA topology may be changed if the host's hardware make a change.
Can you please elaborate ? Are you thinking about resource (cpu and/or
memory) hot plug on the host ?
[Bruce] It's not about resource hot plug. In ovirt engine, there is a scheduled task which will refresh hosts' and vms' information periodically. Only the dynamic and statistics data will be updated during the refresh. So I think the resource information, such as cpu and/or memory, should be in dynamic and statistics. And in my understanding, the information in dynamic class is the changeable information but with a low varying frequency, like cpu topology, libvirt/kernel versions, etc. The information in statistics class is the information with a high varying frequency, like the usage of cpu/memory, etc. In my opinion, it's reasonable to put host level NUMA information in vds_dynamic and host level NUMA statistics information in vds_statistics.

Hi Gilad/Roy/Omer,
I don't know if my understanding is correct. But according to this guess, I think it's also reasonable to put vm cpuPin information in vm_static. Because cpuPin is user configured information, it will not vary automatically. So we don?t need to refresh this information periodically. Please correct me if there are any mistakes.

Hi Eli,
Sorry for the nag. If my understanding above is correct, I think we should still put host level NUMA fields in vds_dynamic/vds_statistics and vm level NUMA fields in vm_static. Since vm level NUMA fields are configured by user and they will not vary automatically.


Thanks & Best Regards
Shi, Xiao-Lei (Bruce)

Hewlett-Packard Co., Ltd.
HP Servers Core Platform Software China 
Telephone +86 23 65683093
Mobile +86 18696583447
Email xiao-lei.shi at hp.com


-----Original Message-----
From: Gilad Chaplik [mailto:gchaplik at redhat.com] 
Sent: Monday, March 31, 2014 9:31 PM
To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Roy Golan; Omer Frenkel
Cc: Eli Mesika; Roy Golan; Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; engine-devel at ovirt.org
Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt

adding Roy & Omer.

why CPU topology is in dynamic?

Thanks,
Gilad.

----- Original Message -----
> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan" 
> <rgolan at redhat.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> <ydary at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, March 31, 2014 3:20:33 PM
> Subject: RE: Please help us to review our database schema design with 
> NUMA feature on ovirt
> 
> Thanks Eli.
> I will move the vm level NUMA fields to vm_dynamic, and the related 
> database schema will be updated accordingly.
> 
> Thanks & Best Regards
> Shi, Xiao-Lei (Bruce)
> 
> Hewlett-Packard Co., Ltd.
> HP Servers Core Platform Software China Telephone +86 23 65683093 
> Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> 
> -----Original Message-----
> From: Eli Mesika [mailto:emesika at redhat.com]
> Sent: Monday, March 31, 2014 5:49 PM
> To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao, 
> HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun 
> (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; 
> engine-devel at ovirt.org
> Subject: Re: Please help us to review our database schema design with 
> NUMA feature on ovirt
> 
> 
> 
> ----- Original Message -----
> > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" 
> > <xiao-lei.shi at hp.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
> > <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>
> > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang, 
> > HPservers-Core-OE-PSC)"
> > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>, 
> > engine-devel at ovirt.org
> > Sent: Monday, March 31, 2014 12:38:04 PM
> > Subject: RE: Please help us to review our database schema design 
> > with NUMA feature on ovirt
> > 
> > We put host level NUMA fields in vds_dynamic because these 
> > information are from host itself, and NUMA topology may be changed 
> > if the host's hardware make a change. NUMA information are similar 
> > to the host's cpu topology information like cpu_cores and 
> > cpu_sockets which are in vds_dynamic, we refer to this.
> > VM level NUMA fields are configured by user, and actually we 
> > originally think they should be in vm_dynamic. But we found that the 
> > field of another feature cpuPin which is similar as NUMA feature is 
> > in vm_static, so we put vm NUMA fields in vm_static.
> > Do you think we need to put VM level NUMA fields in vm_dynamic?
> 
> I think that in this case we should fix cpuPin to be in vm_dynamic and 
> put after that the other NUMA fields in vm_dynamic as well
> 
> > 
> > Thanks & Best Regards
> > Shi, Xiao-Lei (Bruce)
> > 
> > Hewlett-Packard Co., Ltd.
> > HP Servers Core Platform Software China Telephone +86 23 65683093 
> > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > 
> > 
> > -----Original Message-----
> > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > Sent: Monday, March 31, 2014 5:22 PM
> > To: Eli Mesika; Roy Golan
> > Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason 
> > Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, 
> > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; 
> > engine-devel at ovirt.org
> > Subject: Re: Please help us to review our database schema design 
> > with NUMA feature on ovirt
> > 
> > +1
> > 
> > IMO: vds data should reside in static VM need to think about it.
> > 
> > Roy?
> > 
> > Thanks,
> > Gilad.
> > 
> > 
> > ----- Original Message -----
> > > From: "Eli Mesika" <emesika at redhat.com>
> > > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" 
> > > <xiao-lei.shi at hp.com>
> > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" 
> > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Gilad 
> > > Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > <chegu_vinod at hp.com>,
> > > "Shang-Chun Liang (David Liang,
> > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > Sent: Monday, March 31, 2014 12:12:50 PM
> > > Subject: Re: Please help us to review our database schema design 
> > > with NUMA feature on ovirt
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" 
> > > > <xiao-lei.shi at hp.com>
> > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > <chuan.liao at hp.com>,
> > > > "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik" 
> > > > <gchaplik at redhat.com>, "Chegu Vinod"
> > > > <chegu_vinod at hp.com>,
> > > > "Shang-Chun Liang (David Liang,
> > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > Sent: Monday, March 31, 2014 8:56:20 AM
> > > > Subject: RE: Please help us to review our database schema design 
> > > > with NUMA feature on ovirt
> > > > 
> > > > Include the devel group.
> > > > Thanks Eli for the quick responses for our first design and 
> > > > sorry for the nag.
> > > > We appreciate any of the comments for our database design and 
> > > > will follow the design to do the implementation if no more 
> > > > comments.
> > > >  http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > 
> > > Seems OK for me except an unanswered question I had asked in my 
> > > first review
> > > :
> > > 
> > > Why in the Host level NUMA fields are added to vds_dynamic while 
> > > in the VM level it is added to vm_static ???
> > > I would expect it to be in both on static or dynamic , can you 
> > > please explain ? Thanks
> > > 
> > > > 
> > > > Thanks & Best Regards
> > > > Shi, Xiao-Lei (Bruce)
> > > > 
> > > > Hewlett-Packard Co., Ltd.
> > > > HP Servers Core Platform Software China Telephone +86 23 
> > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > 
> > > > -----Original Message-----
> > > > From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > Sent: Friday, March 28, 2014 1:30 PM
> > > > To: 'Eli Mesika'
> > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron 
> > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun (David 
> > > > Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > Subject: RE: Please help us to review our database schema design 
> > > > with NUMA feature on ovirt
> > > > 
> > > > Hi Eli,
> > > > 
> > > > After the UX design meeting, we did some modification for the 
> > > > database schema, and merged some update according to your last review comments.
> > > > Now the document has been posted on ovirt wikipage, could you 
> > > > help to review the database design again:
> > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > 
> > > > 
> > > > Thanks & Best Regards
> > > > Shi, Xiao-Lei (Bruce)
> > > > 
> > > > Hewlett-Packard Co., Ltd.
> > > > HP Servers Core Platform Software China Telephone +86 23 
> > > > 65683093 Mobile
> > > > +86
> > > > 18696583447 Email xiao-lei.shi at hp.com
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > Sent: Monday, March 24, 2014 6:24 PM
> > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron 
> > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun (David 
> > > > Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > Subject: Re: Please help us to review our database schema design 
> > > > with NUMA feature on ovirt
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" 
> > > > > <xiao-lei.shi at hp.com>
> > > > > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason 
> > > > > Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, 
> > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" 
> > > > > <shangchun.liang at hp.com>
> > > > > Sent: Monday, March 24, 2014 11:23:39 AM
> > > > > Subject: RE: Please help us to review our database schema 
> > > > > design with NUMA feature on ovirt
> > > > > 
> > > > > Hi Eli,
> > > > > 
> > > > > Thanks for your comments.
> > > > > I have updated the document according to your comments except 
> > > > > the below
> > > > > one:
> > > > > Missing from here are 2 issues:
> > > > > 
> > > > > 1) Impact on the search engine, which new columns are 
> > > > > search-able and which changes are planned in the search engine 
> > > > > code to enable that
> > > > > 
> > > > > 2) Impact on engine-reports, are those changed planned to be 
> > > > > exposed to the engine data warehouse and required new/modified reports?
> > > > > 
> > > > > Could you tell us more detailed information about the modules 
> > > > > you mentioned above? I mean "search engine" and 
> > > > > "engine-reports". I think we missed these two parts in our previous investigation.
> > > > > I just find org.ovirt.engine.core.bll.SearchQuery, is that the 
> > > > > right object for search engine?
> > > > 
> > > > Yes, actually when you are opening the admin UI, there are TABs 
> > > > for each entity , i.e. Data Center, Cluster, Host etc.
> > > > In each, you can see a text-box in which you can search for by 
> > > > writing a search expression My question is
> > > >    1) What is the impact of your work on the search on the Fost and VM
> > > >    TABs
> > > >       a) Are there any fields that are supported now in the search
> > > >       expression
> > > >       and should pop-up when you write the expression by the
> > > >       auto-completion
> > > >       mechanism ?
> > > >       b) Are there any added columns displayed in the result of such a
> > > >       search
> > > >       in the grid ?
> > > > 
> > > > > How about the engine-reports, could you give us some hints, 
> > > > > like the code location and any more detailed information that 
> > > > > we can start more investigation?
> > > > 
> > > > CCing Yaniv D who is in charge of the reports/dwh module Yaniv, 
> > > > any planned work for adding Numa features to Host/VM in the 
> > > > reports side ?
> > > > 
> > > > Thanks
> > > > 
> > > > > 
> > > > > Thanks & Best Regards
> > > > > Shi, Xiao-Lei (Bruce)
> > > > > 
> > > > > Hewlett-Packard Co., Ltd.
> > > > > HP Servers Core Platform Software China Telephone +86 23 
> > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > Sent: Sunday, March 23, 2014 4:44 PM
> > > > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > > > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, 
> > > > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei 
> > > > > (Bruce, HP
> > > > > Servers-PSC-CQ)
> > > > > Subject: Re: Please help us to review our database schema 
> > > > > design with NUMA feature on ovirt
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > <chuan.liao at hp.com>
> > > > > > To: emesika at redhat.com
> > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, 
> > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > <xiao-lei.shi at hp.com>
> > > > > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > > > > Subject: Please help us to review our database schema design 
> > > > > > with NUMA feature on ovirt
> > > > > > 
> > > > > > Hi Eli,
> > > > > > 
> > > > > > Please help us to review our database schema design with 
> > > > > > NUMA feature on ovirt 
> > > > > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWA
> > > > > > cyQo_IST
> > > > > > Y8
> > > > > > ykDr0I6VY/edit?usp=sharing
> > > > > > 
> > > > > > Feel free to take comments on document at anywhere
> > > > > 
> > > > > Done, had commented on the document.
> > > > > Eli
> > > > > 
> > > > > > 
> > > > > > Especially, 5.4 The used interface between engine core and
> > > > > > database(schema)
> > > > > > 
> > > > > > Your approve and your comments with this section will be 
> > > > > > much more appreciate for us.
> > > > > > 
> > > > > > Best Regards,
> > > > > > Jason Liao
> > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

From emesika at redhat.com  Tue Apr  1 07:10:37 2014
From: emesika at redhat.com (Eli Mesika)
Date: Tue, 1 Apr 2014 03:10:37 -0400 (EDT)
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <08AA403C8399104A89AF710307FA78AE243DD232@G5W2743.americas.hpqcorp.net>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<1718882238.5076978.1396257170731.JavaMail.zimbra@redhat.com>
	<182238414.11560689.1396257704986.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD11A@G5W2743.americas.hpqcorp.net>
	<1087291412.5091657.1396259332718.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD16D@G5W2743.americas.hpqcorp.net>
	<1690885238.11367.1396272677929.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD232@G5W2743.americas.hpqcorp.net>
Message-ID: <434209250.5741543.1396336237695.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan" <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>,
> "Eli Mesika" <emesika at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>
> Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
> "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> engine-devel at ovirt.org
> Sent: Tuesday, April 1, 2014 5:13:34 AM
> Subject: RE: Please help us to review our database schema design with NUMA feature on ovirt
> 
> Assemble the related discussions in this mail session.
> 
> Hi Vinod,
> On 3/31/2014 2:38 AM, Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) wrote:
> > We put host level NUMA fields in vds_dynamic because these information are
> > from host itself, and NUMA topology may be changed if the host's hardware
> > make a change.
> Can you please elaborate ? Are you thinking about resource (cpu and/or
> memory) hot plug on the host ?
> [Bruce] It's not about resource hot plug. In ovirt engine, there is a
> scheduled task which will refresh hosts' and vms' information periodically.
> Only the dynamic and statistics data will be updated during the refresh. So
> I think the resource information, such as cpu and/or memory, should be in
> dynamic and statistics. And in my understanding, the information in dynamic
> class is the changeable information but with a low varying frequency, like
> cpu topology, libvirt/kernel versions, etc. The information in statistics
> class is the information with a high varying frequency, like the usage of
> cpu/memory, etc. In my opinion, it's reasonable to put host level NUMA
> information in vds_dynamic and host level NUMA statistics information in
> vds_statistics.
> 
> Hi Gilad/Roy/Omer,
> I don't know if my understanding is correct. But according to this guess, I
> think it's also reasonable to put vm cpuPin information in vm_static.
> Because cpuPin is user configured information, it will not vary
> automatically. So we don?t need to refresh this information periodically.
> Please correct me if there are any mistakes.
> 
> Hi Eli,
> Sorry for the nag. If my understanding above is correct, I think we should
> still put host level NUMA fields in vds_dynamic/vds_statistics and vm level
> NUMA fields in vm_static. Since vm level NUMA fields are configured by user
> and they will not vary automatically.

Sorry, I had understood from Gilad that the NUMA fields in the host level are relatively static and the NUMA fields on the VM level are dynamic.
I have no problem of having hybrid static/dynamic fields for Host/VM as long as it has a good reason and fully documented :-)


> 
> 
> Thanks & Best Regards
> Shi, Xiao-Lei (Bruce)
> 
> Hewlett-Packard Co., Ltd.
> HP Servers Core Platform Software China
> Telephone +86 23 65683093
> Mobile +86 18696583447
> Email xiao-lei.shi at hp.com
> 
> 
> -----Original Message-----
> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> Sent: Monday, March 31, 2014 9:31 PM
> To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Roy Golan; Omer Frenkel
> Cc: Eli Mesika; Roy Golan; Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC);
> Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> HPservers-Core-OE-PSC); Yaniv Dary; engine-devel at ovirt.org
> Subject: Re: Please help us to review our database schema design with NUMA
> feature on ovirt
> 
> adding Roy & Omer.
> 
> why CPU topology is in dynamic?
> 
> Thanks,
> Gilad.
> 
> ----- Original Message -----
> > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > To: "Eli Mesika" <emesika at redhat.com>
> > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > <rgolan at redhat.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > <ydary at redhat.com>, engine-devel at ovirt.org
> > Sent: Monday, March 31, 2014 3:20:33 PM
> > Subject: RE: Please help us to review our database schema design with
> > NUMA feature on ovirt
> > 
> > Thanks Eli.
> > I will move the vm level NUMA fields to vm_dynamic, and the related
> > database schema will be updated accordingly.
> > 
> > Thanks & Best Regards
> > Shi, Xiao-Lei (Bruce)
> > 
> > Hewlett-Packard Co., Ltd.
> > HP Servers Core Platform Software China Telephone +86 23 65683093
> > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > 
> > -----Original Message-----
> > From: Eli Mesika [mailto:emesika at redhat.com]
> > Sent: Monday, March 31, 2014 5:49 PM
> > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao,
> > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun
> > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > engine-devel at ovirt.org
> > Subject: Re: Please help us to review our database schema design with
> > NUMA feature on ovirt
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > <xiao-lei.shi at hp.com>
> > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
> > > <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>
> > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > HPservers-Core-OE-PSC)"
> > > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > > engine-devel at ovirt.org
> > > Sent: Monday, March 31, 2014 12:38:04 PM
> > > Subject: RE: Please help us to review our database schema design
> > > with NUMA feature on ovirt
> > > 
> > > We put host level NUMA fields in vds_dynamic because these
> > > information are from host itself, and NUMA topology may be changed
> > > if the host's hardware make a change. NUMA information are similar
> > > to the host's cpu topology information like cpu_cores and
> > > cpu_sockets which are in vds_dynamic, we refer to this.
> > > VM level NUMA fields are configured by user, and actually we
> > > originally think they should be in vm_dynamic. But we found that the
> > > field of another feature cpuPin which is similar as NUMA feature is
> > > in vm_static, so we put vm NUMA fields in vm_static.
> > > Do you think we need to put VM level NUMA fields in vm_dynamic?
> > 
> > I think that in this case we should fix cpuPin to be in vm_dynamic and
> > put after that the other NUMA fields in vm_dynamic as well
> > 
> > > 
> > > Thanks & Best Regards
> > > Shi, Xiao-Lei (Bruce)
> > > 
> > > Hewlett-Packard Co., Ltd.
> > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > 
> > > 
> > > -----Original Message-----
> > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > Sent: Monday, March 31, 2014 5:22 PM
> > > To: Eli Mesika; Roy Golan
> > > Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason
> > > Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang,
> > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > > engine-devel at ovirt.org
> > > Subject: Re: Please help us to review our database schema design
> > > with NUMA feature on ovirt
> > > 
> > > +1
> > > 
> > > IMO: vds data should reside in static VM need to think about it.
> > > 
> > > Roy?
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > <xiao-lei.shi at hp.com>
> > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Gilad
> > > > Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > > <chegu_vinod at hp.com>,
> > > > "Shang-Chun Liang (David Liang,
> > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > Sent: Monday, March 31, 2014 12:12:50 PM
> > > > Subject: Re: Please help us to review our database schema design
> > > > with NUMA feature on ovirt
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > <xiao-lei.shi at hp.com>
> > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > <chuan.liao at hp.com>,
> > > > > "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > <chegu_vinod at hp.com>,
> > > > > "Shang-Chun Liang (David Liang,
> > > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > Sent: Monday, March 31, 2014 8:56:20 AM
> > > > > Subject: RE: Please help us to review our database schema design
> > > > > with NUMA feature on ovirt
> > > > > 
> > > > > Include the devel group.
> > > > > Thanks Eli for the quick responses for our first design and
> > > > > sorry for the nag.
> > > > > We appreciate any of the comments for our database design and
> > > > > will follow the design to do the implementation if no more
> > > > > comments.
> > > > >  http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > 
> > > > Seems OK for me except an unanswered question I had asked in my
> > > > first review
> > > > :
> > > > 
> > > > Why in the Host level NUMA fields are added to vds_dynamic while
> > > > in the VM level it is added to vm_static ???
> > > > I would expect it to be in both on static or dynamic , can you
> > > > please explain ? Thanks
> > > > 
> > > > > 
> > > > > Thanks & Best Regards
> > > > > Shi, Xiao-Lei (Bruce)
> > > > > 
> > > > > Hewlett-Packard Co., Ltd.
> > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > Sent: Friday, March 28, 2014 1:30 PM
> > > > > To: 'Eli Mesika'
> > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
> > > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun (David
> > > > > Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > > Subject: RE: Please help us to review our database schema design
> > > > > with NUMA feature on ovirt
> > > > > 
> > > > > Hi Eli,
> > > > > 
> > > > > After the UX design meeting, we did some modification for the
> > > > > database schema, and merged some update according to your last review
> > > > > comments.
> > > > > Now the document has been posted on ovirt wikipage, could you
> > > > > help to review the database design again:
> > > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > 
> > > > > 
> > > > > Thanks & Best Regards
> > > > > Shi, Xiao-Lei (Bruce)
> > > > > 
> > > > > Hewlett-Packard Co., Ltd.
> > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > 65683093 Mobile
> > > > > +86
> > > > > 18696583447 Email xiao-lei.shi at hp.com
> > > > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > Sent: Monday, March 24, 2014 6:24 PM
> > > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
> > > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun (David
> > > > > Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > > Subject: Re: Please help us to review our database schema design
> > > > > with NUMA feature on ovirt
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > <xiao-lei.shi at hp.com>
> > > > > > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason
> > > > > > Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > <shangchun.liang at hp.com>
> > > > > > Sent: Monday, March 24, 2014 11:23:39 AM
> > > > > > Subject: RE: Please help us to review our database schema
> > > > > > design with NUMA feature on ovirt
> > > > > > 
> > > > > > Hi Eli,
> > > > > > 
> > > > > > Thanks for your comments.
> > > > > > I have updated the document according to your comments except
> > > > > > the below
> > > > > > one:
> > > > > > Missing from here are 2 issues:
> > > > > > 
> > > > > > 1) Impact on the search engine, which new columns are
> > > > > > search-able and which changes are planned in the search engine
> > > > > > code to enable that
> > > > > > 
> > > > > > 2) Impact on engine-reports, are those changed planned to be
> > > > > > exposed to the engine data warehouse and required new/modified
> > > > > > reports?
> > > > > > 
> > > > > > Could you tell us more detailed information about the modules
> > > > > > you mentioned above? I mean "search engine" and
> > > > > > "engine-reports". I think we missed these two parts in our previous
> > > > > > investigation.
> > > > > > I just find org.ovirt.engine.core.bll.SearchQuery, is that the
> > > > > > right object for search engine?
> > > > > 
> > > > > Yes, actually when you are opening the admin UI, there are TABs
> > > > > for each entity , i.e. Data Center, Cluster, Host etc.
> > > > > In each, you can see a text-box in which you can search for by
> > > > > writing a search expression My question is
> > > > >    1) What is the impact of your work on the search on the Fost and
> > > > >    VM
> > > > >    TABs
> > > > >       a) Are there any fields that are supported now in the search
> > > > >       expression
> > > > >       and should pop-up when you write the expression by the
> > > > >       auto-completion
> > > > >       mechanism ?
> > > > >       b) Are there any added columns displayed in the result of such
> > > > >       a
> > > > >       search
> > > > >       in the grid ?
> > > > > 
> > > > > > How about the engine-reports, could you give us some hints,
> > > > > > like the code location and any more detailed information that
> > > > > > we can start more investigation?
> > > > > 
> > > > > CCing Yaniv D who is in charge of the reports/dwh module Yaniv,
> > > > > any planned work for adding Numa features to Host/VM in the
> > > > > reports side ?
> > > > > 
> > > > > Thanks
> > > > > 
> > > > > > 
> > > > > > Thanks & Best Regards
> > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > 
> > > > > > Hewlett-Packard Co., Ltd.
> > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > Sent: Sunday, March 23, 2014 4:44 PM
> > > > > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > > > > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang,
> > > > > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei
> > > > > > (Bruce, HP
> > > > > > Servers-PSC-CQ)
> > > > > > Subject: Re: Please help us to review our database schema
> > > > > > design with NUMA feature on ovirt
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > <chuan.liao at hp.com>
> > > > > > > To: emesika at redhat.com
> > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP
> > > > > > > Servers-PSC-CQ)"
> > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > > > > > Subject: Please help us to review our database schema design
> > > > > > > with NUMA feature on ovirt
> > > > > > > 
> > > > > > > Hi Eli,
> > > > > > > 
> > > > > > > Please help us to review our database schema design with
> > > > > > > NUMA feature on ovirt
> > > > > > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWA
> > > > > > > cyQo_IST
> > > > > > > Y8
> > > > > > > ykDr0I6VY/edit?usp=sharing
> > > > > > > 
> > > > > > > Feel free to take comments on document at anywhere
> > > > > > 
> > > > > > Done, had commented on the document.
> > > > > > Eli
> > > > > > 
> > > > > > > 
> > > > > > > Especially, 5.4 The used interface between engine core and
> > > > > > > database(schema)
> > > > > > > 
> > > > > > > Your approve and your comments with this section will be
> > > > > > > much more appreciate for us.
> > > > > > > 
> > > > > > > Best Regards,
> > > > > > > Jason Liao
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From gchaplik at redhat.com  Tue Apr  1 07:50:31 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Tue, 1 Apr 2014 03:50:31 -0400 (EDT)
Subject: [Engine-devel] Numa feature entities patch
In-Reply-To: <859B26A348D7AF42A791481A47A8B41A01026158@G1W3640.americas.hpqcorp.net>
References: <B63C858E777679458338A30A991BB524015ED524@G1W3780.americas.hpqcorp.net>
	<B63C858E777679458338A30A991BB524015EECD1@G1W3780.americas.hpqcorp.net>
	<4168C988EBDF2141B4E0B6475B6A73D11F54449E@G6W2504.americas.hpqcorp.net>
	<1094413948.8556753.1395843620830.JavaMail.zimbra@redhat.com>
	<1145870835.11188144.1396190554145.JavaMail.zimbra@redhat.com>
	<B63C858E777679458338A30A991BB524015F1D03@G1W3780.americas.hpqcorp.net>
	<675947328.740114.1396285528566.JavaMail.zimbra@redhat.com>
	<859B26A348D7AF42A791481A47A8B41A01026158@G1W3640.americas.hpqcorp.net>
Message-ID: <1621483212.1954016.1396338631756.JavaMail.zimbra@redhat.com>

Great to hear :-)

VdcQueryType and VdcActionType with parameters are not part of the initial BE patch; should part of the server's queries and commands patch.



Thanks, 
Gilad.


----- Original Message -----
> From: "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Martin Sivak" <msivak at redhat.com>,
> "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, engine-devel at ovirt.org, "Roy Golan"
> <rgolan at redhat.com>
> Sent: Tuesday, April 1, 2014 3:38:20 AM
> Subject: RE: Numa feature entities patch
> 
> Hi Gilad,
> The below are our understanding. Please correct me if anything wrong. :)
> For VdcQueryType and VdcActionType with parameters, we think it's need to
> update in doc asap because the code of this part has not started yet.
> For other parts that started the coding, We will reach an agreement in
> gerrit/review and then update in the docs accordingly.
> 
> Best Regards,
> David Liang
> 
> -----Original Message-----
> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> Sent: Tuesday, April 01, 2014 1:05 AM
> To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak; Shi, Xiao-Lei (Bruce, HP
> Servers-PSC-CQ); Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
> engine-devel at ovirt.org; Roy Golan
> Subject: Re: Numa feature entities patch
> 
> Hi Jason,
> 
> Please reply on the comments in the patch.
> Once the code is written I think it's better not to context switch back to
> the design.
> we will reach an agreement in gerrit/review and then update the design
> respectively.
> 
> 
> Thanks,
> Gilad.
> 
> ----- Original Message -----
> > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > <chuan.liao at hp.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> > <chegu_vinod at hp.com>, "Martin Sivak" <msivak at redhat.com>, "Xiao-Lei
> > Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Shang-Chun
> > Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>,
> > engine-devel at ovirt.org
> > Sent: Monday, March 31, 2014 7:48:28 PM
> > Subject: RE: Numa feature entities patch
> > 
> > Hi Gilad,
> > 
> > I have update the wiki page design of BE patch 1. add VdcQueryType and
> > VdcActionType with parameters.
> > 2. merge some of your comments and Eli's feedback.
> > 
> > Please take a look at the section
> > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA#Interface
> > _and_data_structure_in_engine_core
> > 
> > We appreciate any of the comments from community, and sorry for the nag.
> > 
> > Best Regards,
> > Jason Liao
> > 
> > -----Original Message-----
> > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > Sent: 2014?3?30? 22:43
> > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Shi, Xiao-Lei
> > (Bruce, HP Servers-PSC-CQ); Liang, Shang-Chun (David Liang,
> > HPservers-Core-OE-PSC)
> > Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak
> > Subject: Numa feature entities patch
> > 
> > Hi all,
> > 
> > I had some comments :-) IMO this patch [1] has maximum priority.
> > let's try to merge it ASAP, I will be very responsive to every new upload.
> > 
> > Thanks,
> > Gilad.
> > 
> > [1] http://gerrit.ovirt.org/#/c/23702/
> >
> 


From lxfwill1988 at gmail.com  Tue Apr  1 08:21:24 2014
From: lxfwill1988 at gmail.com (marco lin)
Date: Tue, 1 Apr 2014 04:21:24 -0400
Subject: [Engine-devel] Exit message: unsupported configuration: spice
 graphics are not supported with this QEMU.
Message-ID: <CALknHWkVLPu_f15U++ONgb9+TKw80zQD4MooGfrv=g_oRisqRA@mail.gmail.com>

Exit message: unsupported configuration: spice graphics are not supported
with this QEMU.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140401/25fc3cc8/attachment.html>

From chuan.liao at hp.com  Tue Apr  1 08:30:46 2014
From: chuan.liao at hp.com (Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC))
Date: Tue, 1 Apr 2014 08:30:46 +0000
Subject: [Engine-devel] Numa feature entities patch
In-Reply-To: <1621483212.1954016.1396338631756.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015ED524@G1W3780.americas.hpqcorp.net>
	<B63C858E777679458338A30A991BB524015EECD1@G1W3780.americas.hpqcorp.net>
	<4168C988EBDF2141B4E0B6475B6A73D11F54449E@G6W2504.americas.hpqcorp.net>
	<1094413948.8556753.1395843620830.JavaMail.zimbra@redhat.com>
	<1145870835.11188144.1396190554145.JavaMail.zimbra@redhat.com>
	<B63C858E777679458338A30A991BB524015F1D03@G1W3780.americas.hpqcorp.net>
	<675947328.740114.1396285528566.JavaMail.zimbra@redhat.com>
	<859B26A348D7AF42A791481A47A8B41A01026158@G1W3640.americas.hpqcorp.net>
	<1621483212.1954016.1396338631756.JavaMail.zimbra@redhat.com>
Message-ID: <B63C858E777679458338A30A991BB524015F23E5@G1W3780.americas.hpqcorp.net>

Hi Gilad,

Did you see updated wiki page design with VdcQueryType, VdcActionType ?

Feel free to let us know if you have any comment.

Best Regards,
Jason Liao

-----Original Message-----
From: Gilad Chaplik [mailto:gchaplik at redhat.com] 
Sent: 2014?4?1? 15:51
To: Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC)
Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Martin Sivak; Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); engine-devel at ovirt.org; Roy Golan
Subject: Re: Numa feature entities patch

Great to hear :-)

VdcQueryType and VdcActionType with parameters are not part of the initial BE patch; should part of the server's queries and commands patch.



Thanks, 
Gilad.


----- Original Message -----
> From: "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Martin Sivak" <msivak at redhat.com>,
> "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, engine-devel at ovirt.org, "Roy Golan"
> <rgolan at redhat.com>
> Sent: Tuesday, April 1, 2014 3:38:20 AM
> Subject: RE: Numa feature entities patch
> 
> Hi Gilad,
> The below are our understanding. Please correct me if anything wrong. :)
> For VdcQueryType and VdcActionType with parameters, we think it's need to
> update in doc asap because the code of this part has not started yet.
> For other parts that started the coding, We will reach an agreement in
> gerrit/review and then update in the docs accordingly.
> 
> Best Regards,
> David Liang
> 
> -----Original Message-----
> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> Sent: Tuesday, April 01, 2014 1:05 AM
> To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak; Shi, Xiao-Lei (Bruce, HP
> Servers-PSC-CQ); Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
> engine-devel at ovirt.org; Roy Golan
> Subject: Re: Numa feature entities patch
> 
> Hi Jason,
> 
> Please reply on the comments in the patch.
> Once the code is written I think it's better not to context switch back to
> the design.
> we will reach an agreement in gerrit/review and then update the design
> respectively.
> 
> 
> Thanks,
> Gilad.
> 
> ----- Original Message -----
> > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > <chuan.liao at hp.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> > <chegu_vinod at hp.com>, "Martin Sivak" <msivak at redhat.com>, "Xiao-Lei
> > Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Shang-Chun
> > Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>,
> > engine-devel at ovirt.org
> > Sent: Monday, March 31, 2014 7:48:28 PM
> > Subject: RE: Numa feature entities patch
> > 
> > Hi Gilad,
> > 
> > I have update the wiki page design of BE patch 1. add VdcQueryType and
> > VdcActionType with parameters.
> > 2. merge some of your comments and Eli's feedback.
> > 
> > Please take a look at the section
> > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA#Interface
> > _and_data_structure_in_engine_core
> > 
> > We appreciate any of the comments from community, and sorry for the nag.
> > 
> > Best Regards,
> > Jason Liao
> > 
> > -----Original Message-----
> > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > Sent: 2014?3?30? 22:43
> > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Shi, Xiao-Lei
> > (Bruce, HP Servers-PSC-CQ); Liang, Shang-Chun (David Liang,
> > HPservers-Core-OE-PSC)
> > Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak
> > Subject: Numa feature entities patch
> > 
> > Hi all,
> > 
> > I had some comments :-) IMO this patch [1] has maximum priority.
> > let's try to merge it ASAP, I will be very responsive to every new upload.
> > 
> > Thanks,
> > Gilad.
> > 
> > [1] http://gerrit.ovirt.org/#/c/23702/
> >
> 

From gchaplik at redhat.com  Tue Apr  1 08:44:05 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Tue, 1 Apr 2014 04:44:05 -0400 (EDT)
Subject: [Engine-devel] Numa feature entities patch
In-Reply-To: <B63C858E777679458338A30A991BB524015F23E5@G1W3780.americas.hpqcorp.net>
References: <B63C858E777679458338A30A991BB524015ED524@G1W3780.americas.hpqcorp.net>
	<1094413948.8556753.1395843620830.JavaMail.zimbra@redhat.com>
	<1145870835.11188144.1396190554145.JavaMail.zimbra@redhat.com>
	<B63C858E777679458338A30A991BB524015F1D03@G1W3780.americas.hpqcorp.net>
	<675947328.740114.1396285528566.JavaMail.zimbra@redhat.com>
	<859B26A348D7AF42A791481A47A8B41A01026158@G1W3640.americas.hpqcorp.net>
	<1621483212.1954016.1396338631756.JavaMail.zimbra@redhat.com>
	<B63C858E777679458338A30A991BB524015F23E5@G1W3780.americas.hpqcorp.net>
Message-ID: <1473613573.1979756.1396341845923.JavaMail.zimbra@redhat.com>

not yet it's on my TODO list :) we are still at the first patch...

Thanks, 
Gilad.


----- Original Message -----
> From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> <shangchun.liang at hp.com>
> Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Martin Sivak" <msivak at redhat.com>,
> "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, engine-devel at ovirt.org, "Roy Golan"
> <rgolan at redhat.com>
> Sent: Tuesday, April 1, 2014 11:30:46 AM
> Subject: RE: Numa feature entities patch
> 
> Hi Gilad,
> 
> Did you see updated wiki page design with VdcQueryType, VdcActionType ?
> 
> Feel free to let us know if you have any comment.
> 
> Best Regards,
> Jason Liao
> 
> -----Original Message-----
> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> Sent: 2014?4?1? 15:51
> To: Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC)
> Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod,
> Chegu; Martin Sivak; Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ);
> engine-devel at ovirt.org; Roy Golan
> Subject: Re: Numa feature entities patch
> 
> Great to hear :-)
> 
> VdcQueryType and VdcActionType with parameters are not part of the initial BE
> patch; should part of the server's queries and commands patch.
> 
> 
> 
> Thanks,
> Gilad.
> 
> 
> ----- Original Message -----
> > From: "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > <shangchun.liang at hp.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Chuan Liao (Jason Liao,
> > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> > <chegu_vinod at hp.com>, "Martin Sivak" <msivak at redhat.com>,
> > "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>,
> > engine-devel at ovirt.org, "Roy Golan"
> > <rgolan at redhat.com>
> > Sent: Tuesday, April 1, 2014 3:38:20 AM
> > Subject: RE: Numa feature entities patch
> > 
> > Hi Gilad,
> > The below are our understanding. Please correct me if anything wrong. :)
> > For VdcQueryType and VdcActionType with parameters, we think it's need to
> > update in doc asap because the code of this part has not started yet.
> > For other parts that started the coding, We will reach an agreement in
> > gerrit/review and then update in the docs accordingly.
> > 
> > Best Regards,
> > David Liang
> > 
> > -----Original Message-----
> > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > Sent: Tuesday, April 01, 2014 1:05 AM
> > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak; Shi, Xiao-Lei (Bruce, HP
> > Servers-PSC-CQ); Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
> > engine-devel at ovirt.org; Roy Golan
> > Subject: Re: Numa feature entities patch
> > 
> > Hi Jason,
> > 
> > Please reply on the comments in the patch.
> > Once the code is written I think it's better not to context switch back to
> > the design.
> > we will reach an agreement in gerrit/review and then update the design
> > respectively.
> > 
> > 
> > Thanks,
> > Gilad.
> > 
> > ----- Original Message -----
> > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > <chuan.liao at hp.com>
> > > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> > > <chegu_vinod at hp.com>, "Martin Sivak" <msivak at redhat.com>, "Xiao-Lei
> > > Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Shang-Chun
> > > Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>,
> > > engine-devel at ovirt.org
> > > Sent: Monday, March 31, 2014 7:48:28 PM
> > > Subject: RE: Numa feature entities patch
> > > 
> > > Hi Gilad,
> > > 
> > > I have update the wiki page design of BE patch 1. add VdcQueryType and
> > > VdcActionType with parameters.
> > > 2. merge some of your comments and Eli's feedback.
> > > 
> > > Please take a look at the section
> > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA#Interface
> > > _and_data_structure_in_engine_core
> > > 
> > > We appreciate any of the comments from community, and sorry for the nag.
> > > 
> > > Best Regards,
> > > Jason Liao
> > > 
> > > -----Original Message-----
> > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > Sent: 2014?3?30? 22:43
> > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Shi, Xiao-Lei
> > > (Bruce, HP Servers-PSC-CQ); Liang, Shang-Chun (David Liang,
> > > HPservers-Core-OE-PSC)
> > > Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak
> > > Subject: Numa feature entities patch
> > > 
> > > Hi all,
> > > 
> > > I had some comments :-) IMO this patch [1] has maximum priority.
> > > let's try to merge it ASAP, I will be very responsive to every new
> > > upload.
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > [1] http://gerrit.ovirt.org/#/c/23702/
> > >
> > 
> 


From gchaplik at redhat.com  Tue Apr  1 08:46:07 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Tue, 1 Apr 2014 04:46:07 -0400 (EDT)
Subject: [Engine-devel] Numa feature entities patch
In-Reply-To: <1473613573.1979756.1396341845923.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015ED524@G1W3780.americas.hpqcorp.net>
	<1145870835.11188144.1396190554145.JavaMail.zimbra@redhat.com>
	<B63C858E777679458338A30A991BB524015F1D03@G1W3780.americas.hpqcorp.net>
	<675947328.740114.1396285528566.JavaMail.zimbra@redhat.com>
	<859B26A348D7AF42A791481A47A8B41A01026158@G1W3640.americas.hpqcorp.net>
	<1621483212.1954016.1396338631756.JavaMail.zimbra@redhat.com>
	<B63C858E777679458338A30A991BB524015F23E5@G1W3780.americas.hpqcorp.net>
	<1473613573.1979756.1396341845923.JavaMail.zimbra@redhat.com>
Message-ID: <686380293.1980540.1396341967844.JavaMail.zimbra@redhat.com>

just saw you've uploaded a new patch, but still no replies to comments in the body of the patch. please handle that ASAP before we do a second review.

Thanks, 
Gilad.

----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> Cc: engine-devel at ovirt.org, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Chegu
> Vinod" <chegu_vinod at hp.com>
> Sent: Tuesday, April 1, 2014 11:44:05 AM
> Subject: Re: [Engine-devel] Numa feature entities patch
> 
> not yet it's on my TODO list :) we are still at the first patch...
> 
> Thanks,
> Gilad.
> 
> 
> ----- Original Message -----
> > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Shang-Chun Liang (David Liang,
> > HPservers-Core-OE-PSC)"
> > <shangchun.liang at hp.com>
> > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> > <chegu_vinod at hp.com>, "Martin Sivak" <msivak at redhat.com>,
> > "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>,
> > engine-devel at ovirt.org, "Roy Golan"
> > <rgolan at redhat.com>
> > Sent: Tuesday, April 1, 2014 11:30:46 AM
> > Subject: RE: Numa feature entities patch
> > 
> > Hi Gilad,
> > 
> > Did you see updated wiki page design with VdcQueryType, VdcActionType ?
> > 
> > Feel free to let us know if you have any comment.
> > 
> > Best Regards,
> > Jason Liao
> > 
> > -----Original Message-----
> > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > Sent: 2014?4?1? 15:51
> > To: Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC)
> > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod,
> > Chegu; Martin Sivak; Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ);
> > engine-devel at ovirt.org; Roy Golan
> > Subject: Re: Numa feature entities patch
> > 
> > Great to hear :-)
> > 
> > VdcQueryType and VdcActionType with parameters are not part of the initial
> > BE
> > patch; should part of the server's queries and commands patch.
> > 
> > 
> > 
> > Thanks,
> > Gilad.
> > 
> > 
> > ----- Original Message -----
> > > From: "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > <shangchun.liang at hp.com>
> > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Chuan Liao (Jason Liao,
> > > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> > > <chegu_vinod at hp.com>, "Martin Sivak" <msivak at redhat.com>,
> > > "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>,
> > > engine-devel at ovirt.org, "Roy Golan"
> > > <rgolan at redhat.com>
> > > Sent: Tuesday, April 1, 2014 3:38:20 AM
> > > Subject: RE: Numa feature entities patch
> > > 
> > > Hi Gilad,
> > > The below are our understanding. Please correct me if anything wrong. :)
> > > For VdcQueryType and VdcActionType with parameters, we think it's need to
> > > update in doc asap because the code of this part has not started yet.
> > > For other parts that started the coding, We will reach an agreement in
> > > gerrit/review and then update in the docs accordingly.
> > > 
> > > Best Regards,
> > > David Liang
> > > 
> > > -----Original Message-----
> > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > Sent: Tuesday, April 01, 2014 1:05 AM
> > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak; Shi, Xiao-Lei (Bruce, HP
> > > Servers-PSC-CQ); Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
> > > engine-devel at ovirt.org; Roy Golan
> > > Subject: Re: Numa feature entities patch
> > > 
> > > Hi Jason,
> > > 
> > > Please reply on the comments in the patch.
> > > Once the code is written I think it's better not to context switch back
> > > to
> > > the design.
> > > we will reach an agreement in gerrit/review and then update the design
> > > respectively.
> > > 
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > ----- Original Message -----
> > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > <chuan.liao at hp.com>
> > > > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> > > > <chegu_vinod at hp.com>, "Martin Sivak" <msivak at redhat.com>, "Xiao-Lei
> > > > Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Shang-Chun
> > > > Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>,
> > > > engine-devel at ovirt.org
> > > > Sent: Monday, March 31, 2014 7:48:28 PM
> > > > Subject: RE: Numa feature entities patch
> > > > 
> > > > Hi Gilad,
> > > > 
> > > > I have update the wiki page design of BE patch 1. add VdcQueryType and
> > > > VdcActionType with parameters.
> > > > 2. merge some of your comments and Eli's feedback.
> > > > 
> > > > Please take a look at the section
> > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA#Interface
> > > > _and_data_structure_in_engine_core
> > > > 
> > > > We appreciate any of the comments from community, and sorry for the
> > > > nag.
> > > > 
> > > > Best Regards,
> > > > Jason Liao
> > > > 
> > > > -----Original Message-----
> > > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > > Sent: 2014?3?30? 22:43
> > > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Shi, Xiao-Lei
> > > > (Bruce, HP Servers-PSC-CQ); Liang, Shang-Chun (David Liang,
> > > > HPservers-Core-OE-PSC)
> > > > Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak
> > > > Subject: Numa feature entities patch
> > > > 
> > > > Hi all,
> > > > 
> > > > I had some comments :-) IMO this patch [1] has maximum priority.
> > > > let's try to merge it ASAP, I will be very responsive to every new
> > > > upload.
> > > > 
> > > > Thanks,
> > > > Gilad.
> > > > 
> > > > [1] http://gerrit.ovirt.org/#/c/23702/
> > > >
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From xiao-lei.shi at hp.com  Tue Apr  1 08:59:14 2014
From: xiao-lei.shi at hp.com (Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ))
Date: Tue, 1 Apr 2014 08:59:14 +0000
Subject: [Engine-devel] Numa feature entities patch
In-Reply-To: <686380293.1980540.1396341967844.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015ED524@G1W3780.americas.hpqcorp.net>
	<1145870835.11188144.1396190554145.JavaMail.zimbra@redhat.com>
	<B63C858E777679458338A30A991BB524015F1D03@G1W3780.americas.hpqcorp.net>
	<675947328.740114.1396285528566.JavaMail.zimbra@redhat.com>
	<859B26A348D7AF42A791481A47A8B41A01026158@G1W3640.americas.hpqcorp.net>
	<1621483212.1954016.1396338631756.JavaMail.zimbra@redhat.com>
	<B63C858E777679458338A30A991BB524015F23E5@G1W3780.americas.hpqcorp.net>
	<1473613573.1979756.1396341845923.JavaMail.zimbra@redhat.com>
	<686380293.1980540.1396341967844.JavaMail.zimbra@redhat.com>
Message-ID: <08AA403C8399104A89AF710307FA78AE243DD2F1@G5W2743.americas.hpqcorp.net>

Have posted my comments now.

Thanks & Best Regards
Shi, Xiao-Lei (Bruce)

Hewlett-Packard Co., Ltd.
HP Servers Core Platform Software China 
Telephone +86 23 65683093
Mobile +86 18696583447
Email xiao-lei.shi at hp.com


-----Original Message-----
From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Gilad Chaplik
Sent: Tuesday, April 01, 2014 4:46 PM
To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
Cc: engine-devel at ovirt.org; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC)
Subject: Re: [Engine-devel] Numa feature entities patch

just saw you've uploaded a new patch, but still no replies to comments in the body of the patch. please handle that ASAP before we do a second review.

Thanks,
Gilad.

----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" 
> <chuan.liao at hp.com>
> Cc: engine-devel at ovirt.org, "Shang-Chun Liang (David Liang, 
> HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Chegu Vinod" 
> <chegu_vinod at hp.com>
> Sent: Tuesday, April 1, 2014 11:44:05 AM
> Subject: Re: [Engine-devel] Numa feature entities patch
> 
> not yet it's on my TODO list :) we are still at the first patch...
> 
> Thanks,
> Gilad.
> 
> 
> ----- Original Message -----
> > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" 
> > <chuan.liao at hp.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Shang-Chun Liang (David 
> > Liang, HPservers-Core-OE-PSC)"
> > <shangchun.liang at hp.com>
> > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> > <chegu_vinod at hp.com>, "Martin Sivak" <msivak at redhat.com>, "Xiao-Lei 
> > Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, 
> > engine-devel at ovirt.org, "Roy Golan"
> > <rgolan at redhat.com>
> > Sent: Tuesday, April 1, 2014 11:30:46 AM
> > Subject: RE: Numa feature entities patch
> > 
> > Hi Gilad,
> > 
> > Did you see updated wiki page design with VdcQueryType, VdcActionType ?
> > 
> > Feel free to let us know if you have any comment.
> > 
> > Best Regards,
> > Jason Liao
> > 
> > -----Original Message-----
> > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > Sent: 2014?4?1? 15:51
> > To: Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC)
> > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; 
> > Vinod, Chegu; Martin Sivak; Shi, Xiao-Lei (Bruce, HP 
> > Servers-PSC-CQ); engine-devel at ovirt.org; Roy Golan
> > Subject: Re: Numa feature entities patch
> > 
> > Great to hear :-)
> > 
> > VdcQueryType and VdcActionType with parameters are not part of the 
> > initial BE patch; should part of the server's queries and commands 
> > patch.
> > 
> > 
> > 
> > Thanks,
> > Gilad.
> > 
> > 
> > ----- Original Message -----
> > > From: "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > <shangchun.liang at hp.com>
> > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Chuan Liao (Jason 
> > > Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> > > <chegu_vinod at hp.com>, "Martin Sivak" <msivak at redhat.com>, 
> > > "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, 
> > > engine-devel at ovirt.org, "Roy Golan"
> > > <rgolan at redhat.com>
> > > Sent: Tuesday, April 1, 2014 3:38:20 AM
> > > Subject: RE: Numa feature entities patch
> > > 
> > > Hi Gilad,
> > > The below are our understanding. Please correct me if anything 
> > > wrong. :) For VdcQueryType and VdcActionType with parameters, we 
> > > think it's need to update in doc asap because the code of this part has not started yet.
> > > For other parts that started the coding, We will reach an 
> > > agreement in gerrit/review and then update in the docs accordingly.
> > > 
> > > Best Regards,
> > > David Liang
> > > 
> > > -----Original Message-----
> > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > Sent: Tuesday, April 01, 2014 1:05 AM
> > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak; Shi, Xiao-Lei 
> > > (Bruce, HP Servers-PSC-CQ); Liang, Shang-Chun (David Liang, 
> > > HPservers-Core-OE-PSC); engine-devel at ovirt.org; Roy Golan
> > > Subject: Re: Numa feature entities patch
> > > 
> > > Hi Jason,
> > > 
> > > Please reply on the comments in the patch.
> > > Once the code is written I think it's better not to context switch 
> > > back to the design.
> > > we will reach an agreement in gerrit/review and then update the 
> > > design respectively.
> > > 
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > ----- Original Message -----
> > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > <chuan.liao at hp.com>
> > > > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> > > > <chegu_vinod at hp.com>, "Martin Sivak" <msivak at redhat.com>, 
> > > > "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, 
> > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" 
> > > > <shangchun.liang at hp.com>, engine-devel at ovirt.org
> > > > Sent: Monday, March 31, 2014 7:48:28 PM
> > > > Subject: RE: Numa feature entities patch
> > > > 
> > > > Hi Gilad,
> > > > 
> > > > I have update the wiki page design of BE patch 1. add 
> > > > VdcQueryType and VdcActionType with parameters.
> > > > 2. merge some of your comments and Eli's feedback.
> > > > 
> > > > Please take a look at the section 
> > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA#Int
> > > > erface _and_data_structure_in_engine_core
> > > > 
> > > > We appreciate any of the comments from community, and sorry for 
> > > > the nag.
> > > > 
> > > > Best Regards,
> > > > Jason Liao
> > > > 
> > > > -----Original Message-----
> > > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > > Sent: 2014?3?30? 22:43
> > > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Shi, 
> > > > Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liang, Shang-Chun (David 
> > > > Liang,
> > > > HPservers-Core-OE-PSC)
> > > > Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak
> > > > Subject: Numa feature entities patch
> > > > 
> > > > Hi all,
> > > > 
> > > > I had some comments :-) IMO this patch [1] has maximum priority.
> > > > let's try to merge it ASAP, I will be very responsive to every 
> > > > new upload.
> > > > 
> > > > Thanks,
> > > > Gilad.
> > > > 
> > > > [1] http://gerrit.ovirt.org/#/c/23702/
> > > >
> > > 
> > 
> _______________________________________________
> 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

From chuan.liao at hp.com  Tue Apr  1 09:17:24 2014
From: chuan.liao at hp.com (Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC))
Date: Tue, 1 Apr 2014 09:17:24 +0000
Subject: [Engine-devel] NUMA feature for MOM interface
Message-ID: <B63C858E777679458338A30A991BB524015F24C5@G1W3780.americas.hpqcorp.net>

Hi Martin & Adam

I have update the wiki page design
http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA#Interface_between_VDSM_and_Host
I-1.4 Data structure that provided to MOM component

>From this design MOM could use VDSM HypervisorInterface to get NUMA from host.


We appreciate any of the comments from you and community, and sorry for the nag.

Best Regards,
Jason Liao

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140401/8a8acd86/attachment.html>

From danken at redhat.com  Tue Apr  1 11:57:37 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 1 Apr 2014 12:57:37 +0100
Subject: [Engine-devel] Exit message: unsupported configuration: spice
 graphics are not supported with this QEMU.
In-Reply-To: <CALknHWkVLPu_f15U++ONgb9+TKw80zQD4MooGfrv=g_oRisqRA@mail.gmail.com>
References: <CALknHWkVLPu_f15U++ONgb9+TKw80zQD4MooGfrv=g_oRisqRA@mail.gmail.com>
Message-ID: <20140401115737.GB2591@redhat.com>

On Tue, Apr 01, 2014 at 04:21:24AM -0400, marco lin wrote:
> Exit message: unsupported configuration: spice graphics are not supported
> with this QEMU.

Could you provide more information about your platform, the version of
qemu-kvm, libvirt and spice-server?

The relevant chunk of /var/log/libvirt/libvirtd.log might prove useful.


From chegu_vinod at hp.com  Tue Apr  1 02:25:10 2014
From: chegu_vinod at hp.com (Chegu Vinod)
Date: Mon, 31 Mar 2014 19:25:10 -0700
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <08AA403C8399104A89AF710307FA78AE243DD232@G5W2743.americas.hpqcorp.net>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<1290280076.419927.1395656626000.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD026@G5W2743.americas.hpqcorp.net>
	<1718882238.5076978.1396257170731.JavaMail.zimbra@redhat.com>
	<182238414.11560689.1396257704986.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD11A@G5W2743.americas.hpqcorp.net>
	<1087291412.5091657.1396259332718.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD16D@G5W2743.americas.hpqcorp.net>
	<1690885238.11367.1396272677929.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD232@G5W2743.americas.hpqcorp.net>
Message-ID: <533A2386.6090601@hp.com>

On 3/31/2014 7:13 PM, Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) wrote:
> Assemble the related discussions in this mail session.
>
> Hi Vinod,
> On 3/31/2014 2:38 AM, Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) wrote:
>> We put host level NUMA fields in vds_dynamic because these information are from host itself, and NUMA topology may be changed if the host's hardware make a change.
> Can you please elaborate ? Are you thinking about resource (cpu and/or
> memory) hot plug on the host ?
> [Bruce] It's not about resource hot plug. In ovirt engine, there is a scheduled task which will refresh hosts' and vms' information periodically. Only the dynamic and statistics data will be updated during the refresh. So I think the resource information, such as cpu and/or memory, should be in dynamic and statistics. And in my understanding, the information in dynamic class is the changeable information but with a low varying frequency, like cpu topology, libvirt/kernel versions, etc.

Hmm...just to be clear.

If one were to exclude resource hot-plug scenarios on the Host...then I 
would consider the following to be static and not dynamic :

- # of NUMA nodes,
- # of CPUs in each of the NUMA node
- Amount of "installed" memory in each of the NUMA node
- The NUMA node distances.

I don't know enough about oVirt features of being able to keep track of 
(or) orchestrating host level resource hot plug..but
If resource hot plug is to be included in the mix then... # of CPUs in a 
NUMA node and the amount of memory in a given NUMA node could change... 
(i.e. some CPUs or some sections of memory ranges could be offlined or 
onlined using hot plug features on the host).

I can see the libvirt, qemu versions etc. changing (with less frequency 
based on user updates etc.)..but for host kernel versions to actually 
change one would most likely require a reboot of the host at which point 
I would guess that all of the rebooted host information would have to be 
synch'd up as part of handshakes between VDSM and oVirt engine.

> The information in statistics class is the information with a high varying frequency, like the usage of cpu/memory, etc. In my opinion, it's reasonable to put host level NUMA information in vds_dynamic and host level NUMA statistics information in vds_statistics.

Got that part...

Thanks
Vinod
>
> Hi Gilad/Roy/Omer,
> I don't know if my understanding is correct. But according to this guess, I think it's also reasonable to put vm cpuPin information in vm_static. Because cpuPin is user configured information, it will not vary automatically. So we don?t need to refresh this information periodically. Please correct me if there are any mistakes.
>
> Hi Eli,
> Sorry for the nag. If my understanding above is correct, I think we should still put host level NUMA fields in vds_dynamic/vds_statistics and vm level NUMA fields in vm_static. Since vm level NUMA fields are configured by user and they will not vary automatically.
>
>
> Thanks & Best Regards
> Shi, Xiao-Lei (Bruce)
>
> Hewlett-Packard Co., Ltd.
> HP Servers Core Platform Software China
> Telephone +86 23 65683093
> Mobile +86 18696583447
> Email xiao-lei.shi at hp.com
>
>
> -----Original Message-----
> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> Sent: Monday, March 31, 2014 9:31 PM
> To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Roy Golan; Omer Frenkel
> Cc: Eli Mesika; Roy Golan; Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; engine-devel at ovirt.org
> Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt
>
> adding Roy & Omer.
>
> why CPU topology is in dynamic?
>
> Thanks,
> Gilad.
>
> ----- Original Message -----
>> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
>> To: "Eli Mesika" <emesika at redhat.com>
>> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
>> <rgolan at redhat.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
>> <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
>> <ydary at redhat.com>, engine-devel at ovirt.org
>> Sent: Monday, March 31, 2014 3:20:33 PM
>> Subject: RE: Please help us to review our database schema design with
>> NUMA feature on ovirt
>>
>> Thanks Eli.
>> I will move the vm level NUMA fields to vm_dynamic, and the related
>> database schema will be updated accordingly.
>>
>> Thanks & Best Regards
>> Shi, Xiao-Lei (Bruce)
>>
>> Hewlett-Packard Co., Ltd.
>> HP Servers Core Platform Software China Telephone +86 23 65683093
>> Mobile +86 18696583447 Email xiao-lei.shi at hp.com
>>
>> -----Original Message-----
>> From: Eli Mesika [mailto:emesika at redhat.com]
>> Sent: Monday, March 31, 2014 5:49 PM
>> To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
>> Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao,
>> HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun
>> (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
>> engine-devel at ovirt.org
>> Subject: Re: Please help us to review our database schema design with
>> NUMA feature on ovirt
>>
>>
>>
>> ----- Original Message -----
>>> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
>>> <xiao-lei.shi at hp.com>
>>> To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
>>> <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>
>>> Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
>>> <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
>>> <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
>>> HPservers-Core-OE-PSC)"
>>> <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
>>> engine-devel at ovirt.org
>>> Sent: Monday, March 31, 2014 12:38:04 PM
>>> Subject: RE: Please help us to review our database schema design
>>> with NUMA feature on ovirt
>>>
>>> We put host level NUMA fields in vds_dynamic because these
>>> information are from host itself, and NUMA topology may be changed
>>> if the host's hardware make a change. NUMA information are similar
>>> to the host's cpu topology information like cpu_cores and
>>> cpu_sockets which are in vds_dynamic, we refer to this.
>>> VM level NUMA fields are configured by user, and actually we
>>> originally think they should be in vm_dynamic. But we found that the
>>> field of another feature cpuPin which is similar as NUMA feature is
>>> in vm_static, so we put vm NUMA fields in vm_static.
>>> Do you think we need to put VM level NUMA fields in vm_dynamic?
>> I think that in this case we should fix cpuPin to be in vm_dynamic and
>> put after that the other NUMA fields in vm_dynamic as well
>>
>>> Thanks & Best Regards
>>> Shi, Xiao-Lei (Bruce)
>>>
>>> Hewlett-Packard Co., Ltd.
>>> HP Servers Core Platform Software China Telephone +86 23 65683093
>>> Mobile +86 18696583447 Email xiao-lei.shi at hp.com
>>>
>>>
>>> -----Original Message-----
>>> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
>>> Sent: Monday, March 31, 2014 5:22 PM
>>> To: Eli Mesika; Roy Golan
>>> Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason
>>> Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang,
>>> Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
>>> engine-devel at ovirt.org
>>> Subject: Re: Please help us to review our database schema design
>>> with NUMA feature on ovirt
>>>
>>> +1
>>>
>>> IMO: vds data should reside in static VM need to think about it.
>>>
>>> Roy?
>>>
>>> Thanks,
>>> Gilad.
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Eli Mesika" <emesika at redhat.com>
>>>> To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
>>>> <xiao-lei.shi at hp.com>
>>>> Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
>>>> <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Gilad
>>>> Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
>>>> <chegu_vinod at hp.com>,
>>>> "Shang-Chun Liang (David Liang,
>>>> HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
>>>> <ydary at redhat.com>, engine-devel at ovirt.org
>>>> Sent: Monday, March 31, 2014 12:12:50 PM
>>>> Subject: Re: Please help us to review our database schema design
>>>> with NUMA feature on ovirt
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
>>>>> <xiao-lei.shi at hp.com>
>>>>> To: "Eli Mesika" <emesika at redhat.com>
>>>>> Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
>>>>> <chuan.liao at hp.com>,
>>>>> "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
>>>>> <gchaplik at redhat.com>, "Chegu Vinod"
>>>>> <chegu_vinod at hp.com>,
>>>>> "Shang-Chun Liang (David Liang,
>>>>> HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
>>>>> <ydary at redhat.com>, engine-devel at ovirt.org
>>>>> Sent: Monday, March 31, 2014 8:56:20 AM
>>>>> Subject: RE: Please help us to review our database schema design
>>>>> with NUMA feature on ovirt
>>>>>
>>>>> Include the devel group.
>>>>> Thanks Eli for the quick responses for our first design and
>>>>> sorry for the nag.
>>>>> We appreciate any of the comments for our database design and
>>>>> will follow the design to do the implementation if no more
>>>>> comments.
>>>>>   http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
>>>> Seems OK for me except an unanswered question I had asked in my
>>>> first review
>>>> :
>>>>
>>>> Why in the Host level NUMA fields are added to vds_dynamic while
>>>> in the VM level it is added to vm_static ???
>>>> I would expect it to be in both on static or dynamic , can you
>>>> please explain ? Thanks
>>>>
>>>>> Thanks & Best Regards
>>>>> Shi, Xiao-Lei (Bruce)
>>>>>
>>>>> Hewlett-Packard Co., Ltd.
>>>>> HP Servers Core Platform Software China Telephone +86 23
>>>>> 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
>>>>>
>>>>> -----Original Message-----
>>>>> From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
>>>>> Sent: Friday, March 28, 2014 1:30 PM
>>>>> To: 'Eli Mesika'
>>>>> Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
>>>>> Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun (David
>>>>> Liang, HPservers-Core-OE-PSC); Yaniv Dary
>>>>> Subject: RE: Please help us to review our database schema design
>>>>> with NUMA feature on ovirt
>>>>>
>>>>> Hi Eli,
>>>>>
>>>>> After the UX design meeting, we did some modification for the
>>>>> database schema, and merged some update according to your last review comments.
>>>>> Now the document has been posted on ovirt wikipage, could you
>>>>> help to review the database design again:
>>>>> http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
>>>>>
>>>>>
>>>>> Thanks & Best Regards
>>>>> Shi, Xiao-Lei (Bruce)
>>>>>
>>>>> Hewlett-Packard Co., Ltd.
>>>>> HP Servers Core Platform Software China Telephone +86 23
>>>>> 65683093 Mobile
>>>>> +86
>>>>> 18696583447 Email xiao-lei.shi at hp.com
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Eli Mesika [mailto:emesika at redhat.com]
>>>>> Sent: Monday, March 24, 2014 6:24 PM
>>>>> To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
>>>>> Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
>>>>> Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun (David
>>>>> Liang, HPservers-Core-OE-PSC); Yaniv Dary
>>>>> Subject: Re: Please help us to review our database schema design
>>>>> with NUMA feature on ovirt
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
>>>>>> <xiao-lei.shi at hp.com>
>>>>>> To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason
>>>>>> Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
>>>>>> Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
>>>>>> <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
>>>>>> "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
>>>>>> <shangchun.liang at hp.com>
>>>>>> Sent: Monday, March 24, 2014 11:23:39 AM
>>>>>> Subject: RE: Please help us to review our database schema
>>>>>> design with NUMA feature on ovirt
>>>>>>
>>>>>> Hi Eli,
>>>>>>
>>>>>> Thanks for your comments.
>>>>>> I have updated the document according to your comments except
>>>>>> the below
>>>>>> one:
>>>>>> Missing from here are 2 issues:
>>>>>>
>>>>>> 1) Impact on the search engine, which new columns are
>>>>>> search-able and which changes are planned in the search engine
>>>>>> code to enable that
>>>>>>
>>>>>> 2) Impact on engine-reports, are those changed planned to be
>>>>>> exposed to the engine data warehouse and required new/modified reports?
>>>>>>
>>>>>> Could you tell us more detailed information about the modules
>>>>>> you mentioned above? I mean "search engine" and
>>>>>> "engine-reports". I think we missed these two parts in our previous investigation.
>>>>>> I just find org.ovirt.engine.core.bll.SearchQuery, is that the
>>>>>> right object for search engine?
>>>>> Yes, actually when you are opening the admin UI, there are TABs
>>>>> for each entity , i.e. Data Center, Cluster, Host etc.
>>>>> In each, you can see a text-box in which you can search for by
>>>>> writing a search expression My question is
>>>>>     1) What is the impact of your work on the search on the Fost and VM
>>>>>     TABs
>>>>>        a) Are there any fields that are supported now in the search
>>>>>        expression
>>>>>        and should pop-up when you write the expression by the
>>>>>        auto-completion
>>>>>        mechanism ?
>>>>>        b) Are there any added columns displayed in the result of such a
>>>>>        search
>>>>>        in the grid ?
>>>>>
>>>>>> How about the engine-reports, could you give us some hints,
>>>>>> like the code location and any more detailed information that
>>>>>> we can start more investigation?
>>>>> CCing Yaniv D who is in charge of the reports/dwh module Yaniv,
>>>>> any planned work for adding Numa features to Host/VM in the
>>>>> reports side ?
>>>>>
>>>>> Thanks
>>>>>
>>>>>> Thanks & Best Regards
>>>>>> Shi, Xiao-Lei (Bruce)
>>>>>>
>>>>>> Hewlett-Packard Co., Ltd.
>>>>>> HP Servers Core Platform Software China Telephone +86 23
>>>>>> 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Eli Mesika [mailto:emesika at redhat.com]
>>>>>> Sent: Sunday, March 23, 2014 4:44 PM
>>>>>> To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
>>>>>> Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang,
>>>>>> Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei
>>>>>> (Bruce, HP
>>>>>> Servers-PSC-CQ)
>>>>>> Subject: Re: Please help us to review our database schema
>>>>>> design with NUMA feature on ovirt
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
>>>>>>> <chuan.liao at hp.com>
>>>>>>> To: emesika at redhat.com
>>>>>>> Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
>>>>>>> <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
>>>>>>> "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
>>>>>>> <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
>>>>>>> <xiao-lei.shi at hp.com>
>>>>>>> Sent: Friday, March 21, 2014 10:42:33 AM
>>>>>>> Subject: Please help us to review our database schema design
>>>>>>> with NUMA feature on ovirt
>>>>>>>
>>>>>>> Hi Eli,
>>>>>>>
>>>>>>> Please help us to review our database schema design with
>>>>>>> NUMA feature on ovirt
>>>>>>> https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWA
>>>>>>> cyQo_IST
>>>>>>> Y8
>>>>>>> ykDr0I6VY/edit?usp=sharing
>>>>>>>
>>>>>>> Feel free to take comments on document at anywhere
>>>>>> Done, had commented on the document.
>>>>>> Eli
>>>>>>
>>>>>>> Especially, 5.4 The used interface between engine core and
>>>>>>> database(schema)
>>>>>>>
>>>>>>> Your approve and your comments with this section will be
>>>>>>> much more appreciate for us.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Jason Liao
>>>>>>>
>>>>>>>



From shangchun.liang at hp.com  Tue Apr  1 00:38:20 2014
From: shangchun.liang at hp.com (Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC))
Date: Tue, 1 Apr 2014 00:38:20 +0000
Subject: [Engine-devel] Numa feature entities patch
In-Reply-To: <675947328.740114.1396285528566.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015ED524@G1W3780.americas.hpqcorp.net>
	<4168C988EBDF2141B4E0B6475B6A73D11F543DEA@G6W2504.americas.hpqcorp.net>
	<B63C858E777679458338A30A991BB524015EECD1@G1W3780.americas.hpqcorp.net>
	<4168C988EBDF2141B4E0B6475B6A73D11F54449E@G6W2504.americas.hpqcorp.net>
	<1094413948.8556753.1395843620830.JavaMail.zimbra@redhat.com>
	<1145870835.11188144.1396190554145.JavaMail.zimbra@redhat.com>
	<B63C858E777679458338A30A991BB524015F1D03@G1W3780.americas.hpqcorp.net>
	<675947328.740114.1396285528566.JavaMail.zimbra@redhat.com>
Message-ID: <859B26A348D7AF42A791481A47A8B41A01026158@G1W3640.americas.hpqcorp.net>

Hi Gilad,
The below are our understanding. Please correct me if anything wrong. :)
For VdcQueryType and VdcActionType with parameters, we think it's need to update in doc asap because the code of this part has not started yet.
For other parts that started the coding, We will reach an agreement in gerrit/review and then update in the docs accordingly.

Best Regards,
David Liang

-----Original Message-----
From: Gilad Chaplik [mailto:gchaplik at redhat.com] 
Sent: Tuesday, April 01, 2014 1:05 AM
To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak; Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); engine-devel at ovirt.org; Roy Golan
Subject: Re: Numa feature entities patch

Hi Jason,

Please reply on the comments in the patch.
Once the code is written I think it's better not to context switch back to the design.
we will reach an agreement in gerrit/review and then update the design respectively.


Thanks,
Gilad.

----- Original Message -----
> From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" 
> <chuan.liao at hp.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod" 
> <chegu_vinod at hp.com>, "Martin Sivak" <msivak at redhat.com>, "Xiao-Lei 
> Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Shang-Chun 
> Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, 
> engine-devel at ovirt.org
> Sent: Monday, March 31, 2014 7:48:28 PM
> Subject: RE: Numa feature entities patch
> 
> Hi Gilad,
> 
> I have update the wiki page design of BE patch 1. add VdcQueryType and 
> VdcActionType with parameters.
> 2. merge some of your comments and Eli's feedback.
> 
> Please take a look at the section
> http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA#Interface
> _and_data_structure_in_engine_core
> 
> We appreciate any of the comments from community, and sorry for the nag.
> 
> Best Regards,
> Jason Liao
> 
> -----Original Message-----
> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> Sent: 2014?3?30? 22:43
> To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Shi, Xiao-Lei 
> (Bruce, HP Servers-PSC-CQ); Liang, Shang-Chun (David Liang, 
> HPservers-Core-OE-PSC)
> Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak
> Subject: Numa feature entities patch
> 
> Hi all,
> 
> I had some comments :-) IMO this patch [1] has maximum priority.
> let's try to merge it ASAP, I will be very responsive to every new upload.
> 
> Thanks,
> Gilad.
> 
> [1] http://gerrit.ovirt.org/#/c/23702/
>

From gchaplik at redhat.com  Tue Apr  1 15:34:43 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Tue, 1 Apr 2014 11:34:43 -0400 (EDT)
Subject: [Engine-devel] NUMA Support - GUI Technical Session
In-Reply-To: <1959694781.11106446.1396134419108.JavaMail.zimbra@redhat.com>
References: <1959694781.11106446.1396134419108.JavaMail.zimbra@redhat.com>
Message-ID: <1703386390.2298741.1396366483396.JavaMail.zimbra@redhat.com>

Hi all, 

Here are the resolutions from the meeting:

* option 1
1) Use gwt-dnd lib for oVirt's dnd (drag and drop) infrastructure.
2) Come up with a very simple POC that covers all of NUMA-support UX requirements.
3) Either do a POC, or get UX maintainers approval, that moving already existing dnd features to new infrastructure (setup-networks and scheduling policy dialogs) is feasible and possible.

* option 2
Extract setup network dnd capabilities to a common general infrastructure and use that as an infrastructure. NOTE that setup-networks will not use it in oVirt-3.5.

I will start with option 1, just need UX team approval that [1] will be added to ovirt-3.5, and be used for dnd for now on.
In case I fail to deliver option 1 (with the help and guidance of the UX team) in a quick cycle (a week or so), I will peruse option 2, which is trivial.

Moving forward, all new dnd enabled features will use the new infrastructure, and the motivation is to migrate existing ones as well.

Thanks, 
Gilad.

[1] http://code.google.com/p/gwt-dnd/

----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Einav Cohen" <ecohen at redhat.com>, "Alexander Wels" <awels at redhat.com>, "Eyal Edri" <eedri at redhat.com>, "Steve
> Gordon" <sgordon at redhat.com>, "Eli Mesika" <emesika at redhat.com>, "Otavio Luiz Ferranti"
> <otavio.ferranti at eldorado.org.br>, "Sandro Bonazzola" <sbonazzo at redhat.com>, "Greg Sheremeta" <gshereme at redhat.com>,
> "Doron Fediuck" <dfediuck at redhat.com>, "Lior Vernia" <lvernia at redhat.com>, "engine-devel" <engine-devel at ovirt.org>,
> "Martin Sivak" <msivak at redhat.com>, "chuan liao" <chuan.liao at hp.com>, "xiao-lei shi" <xiao-lei.shi at hp.com>, "chegu
> vinod" <chegu_vinod at hp.com>, "da-huai tang" <da-huai.tang at hp.com>
> Sent: Sunday, March 30, 2014 2:06:59 AM
> Subject: NUMA Support - GUI Technical Session
> 
> The following meeting has been modified:
> 
> Subject: NUMA Support - GUI Technical Session [MODIFIED]
> Organizer: "Gilad Chaplik" <gchaplik at redhat.com>
> 
> Time: Tuesday, April 1, 2014, 5:00:00 PM - 6:00:00 PM GMT +02:00 Jerusalem
> [MODIFIED]
>  
> Required: ecohen at redhat.com; awels at redhat.com; eedri at redhat.com;
> sgordon at redhat.com; emesika at redhat.com; otavio.ferranti at eldorado.org.br;
> sbonazzo at redhat.com; gshereme at redhat.com
> Optional: dfediuck at redhat.com; lvernia at redhat.com; engine-devel at ovirt.org;
> msivak at redhat.com; chuan.liao at hp.com; xiao-lei.shi at hp.com;
> chegu_vinod at hp.com; da-huai.tang at hp.com
> 
> *~*~*~*~*~*~*~*~*~*
> 
> We will discuss on how to implement NUMA support GUI in oVirt for version 3.5
> (see attached sketches).
> 
> Agenda:
> 1) Brainstorming
> 2) Resolution
> 3) Split work/tasks among volunteers :)
> 
> GUI maintainers please join-in.
> 
> Bluejeans (video conference) session to follow [maybe], currently dial in:
> 
> https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405
> 
> conf id: 712 886 7405#


From awels at redhat.com  Tue Apr  1 17:24:12 2014
From: awels at redhat.com (Alexander Wels)
Date: Tue, 01 Apr 2014 13:24:12 -0400
Subject: [Engine-devel] NUMA Support - GUI Technical Session
In-Reply-To: <1703386390.2298741.1396366483396.JavaMail.zimbra@redhat.com>
References: <1959694781.11106446.1396134419108.JavaMail.zimbra@redhat.com>
	<1703386390.2298741.1396366483396.JavaMail.zimbra@redhat.com>
Message-ID: <2503255.bqO8iyxaJI@awels>

On Tuesday, April 01, 2014 11:34:43 AM Gilad Chaplik wrote:
> Hi all,
> 
> Here are the resolutions from the meeting:
> 
> * option 1
> 1) Use gwt-dnd lib for oVirt's dnd (drag and drop) infrastructure.
> 2) Come up with a very simple POC that covers all of NUMA-support UX
> requirements. 3) Either do a POC, or get UX maintainers approval, that
> moving already existing dnd features to new infrastructure (setup-networks
> and scheduling policy dialogs) is feasible and possible.
> 

+1 for option 1. None of the drag and drop in the application now looks 
terribly hard. The gwt-dnd library simply makes things easier to control and 
maintain.

> * option 2
> Extract setup network dnd capabilities to a common general infrastructure
> and use that as an infrastructure. NOTE that setup-networks will not use it
> in oVirt-3.5.
> 
> I will start with option 1, just need UX team approval that [1] will be
> added to ovirt-3.5, and be used for dnd for now on. In case I fail to
> deliver option 1 (with the help and guidance of the UX team) in a quick
> cycle (a week or so), I will peruse option 2, which is trivial.
> 
> Moving forward, all new dnd enabled features will use the new
> infrastructure, and the motivation is to migrate existing ones as well.
> 
> Thanks,
> Gilad.
> 
> [1] http://code.google.com/p/gwt-dnd/
> 
> ----- Original Message -----
> 
> > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > To: "Einav Cohen" <ecohen at redhat.com>, "Alexander Wels"
> > <awels at redhat.com>, "Eyal Edri" <eedri at redhat.com>, "Steve Gordon"
> > <sgordon at redhat.com>, "Eli Mesika" <emesika at redhat.com>, "Otavio Luiz
> > Ferranti" <otavio.ferranti at eldorado.org.br>, "Sandro Bonazzola"
> > <sbonazzo at redhat.com>, "Greg Sheremeta" <gshereme at redhat.com>, "Doron
> > Fediuck" <dfediuck at redhat.com>, "Lior Vernia" <lvernia at redhat.com>,
> > "engine-devel" <engine-devel at ovirt.org>, "Martin Sivak"
> > <msivak at redhat.com>, "chuan liao" <chuan.liao at hp.com>, "xiao-lei shi"
> > <xiao-lei.shi at hp.com>, "chegu vinod" <chegu_vinod at hp.com>, "da-huai tang"
> > <da-huai.tang at hp.com>
> > Sent: Sunday, March 30, 2014 2:06:59 AM
> > Subject: NUMA Support - GUI Technical Session
> > 
> > The following meeting has been modified:
> > 
> > Subject: NUMA Support - GUI Technical Session [MODIFIED]
> > Organizer: "Gilad Chaplik" <gchaplik at redhat.com>
> > 
> > Time: Tuesday, April 1, 2014, 5:00:00 PM - 6:00:00 PM GMT +02:00 Jerusalem
> > [MODIFIED]
> > 
> > Required: ecohen at redhat.com; awels at redhat.com; eedri at redhat.com;
> > sgordon at redhat.com; emesika at redhat.com; otavio.ferranti at eldorado.org.br;
> > sbonazzo at redhat.com; gshereme at redhat.com
> > Optional: dfediuck at redhat.com; lvernia at redhat.com; engine-devel at ovirt.org;
> > msivak at redhat.com; chuan.liao at hp.com; xiao-lei.shi at hp.com;
> > chegu_vinod at hp.com; da-huai.tang at hp.com
> > 
> > *~*~*~*~*~*~*~*~*~*
> > 
> > We will discuss on how to implement NUMA support GUI in oVirt for version
> > 3.5 (see attached sketches).
> > 
> > Agenda:
> > 1) Brainstorming
> > 2) Resolution
> > 3) Split work/tasks among volunteers :)
> > 
> > GUI maintainers please join-in.
> > 
> > Bluejeans (video conference) session to follow [maybe], currently dial in:
> > 
> > https://www.intercallonline.com/listNumbersByCode.action?confCode=71288674
> > 05
> > 
> > conf id: 712 886 7405#



From masayag at redhat.com  Wed Apr  2 06:06:21 2014
From: masayag at redhat.com (Moti Asayag)
Date: Wed, 2 Apr 2014 02:06:21 -0400 (EDT)
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <756890458.3439238.1395920602583.JavaMail.zimbra@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>
	<577568761.2861329.1394657047677.JavaMail.zimbra@redhat.com>
	<1789679933.641640.1395343205633.JavaMail.zimbra@redhat.com>
	<532BDD57.1090604@redhat.com>
	<1810385690.186069.1395569606128.JavaMail.zimbra@redhat.com>
	<532EB40D.5050202@redhat.com>
	<1761608621.98742.1395578873460.JavaMail.zimbra@redhat.com>
	<756890458.3439238.1395920602583.JavaMail.zimbra@redhat.com>
Message-ID: <1979276837.3855424.1396418781688.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, March 27, 2014 1:43:22 PM
> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
> 
> 
> 
> ----- Original Message -----
> > From: "Moti Asayag" <masayag at redhat.com>
> > To: "Itamar Heim" <iheim at redhat.com>
> > Cc: "Eli Mesika" <emesika at redhat.com>, engine-devel at ovirt.org
> > Sent: Sunday, March 23, 2014 2:47:53 PM
> > Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to
> > decrease DC compatibility...
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Itamar Heim" <iheim at redhat.com>
> > > To: "Eli Mesika" <emesika at redhat.com>, engine-devel at ovirt.org
> > > Sent: Sunday, March 23, 2014 12:14:37 PM
> > > Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
> > > to
> > > decrease DC compatibility...
> > > 
> > > On 03/23/2014 12:13 PM, Eli Mesika wrote:
> > > >
> > > > So, as far a I understand for resolving this bug the following is OK :
> > > >
> > > > Block downgrading if there are Hosts or Networks (other than the
> > > > default
> > > > management network) or SD in the DC when downgrading.
> > > 
> > > yes
> > > 
> > 
> > I don't think it is enough. There is a need to verify the management
> > network
> > wasn't modified to use unsupported features in the new data-center.
> > 
> > On the same matter, we can allow downgrading if all of the networks in the
> > data center are using only features that are supported on the target DC
> > version
> > and not to restrict it only to the management network.
> 
> Since Moti is in PTO, talked with Mike K to get advanced with that , we came
> to the following conclusion:
> 
> when DC is downgraded :
>  Block downgrading if there are Hosts or Networks (other than the default
>  management network) or SD in the DC.
>  In case that only default management network exists we should check that all
>  network features are still supported (This can be done by adding a method
>  to the NetworkValidator that will check for support of all relevant
>  features)
> 
> when Cluster is downgraded :
>  Same as above , but we don't need to check for features validation since we
>  can not downgrade below the DC version and therefor the cluster network is
>  supposed to be valid already
> 
> Mike, please let me know If I miss something from our discussion (and thanks
> for your kind help :-) )

+1 from me and Mike for the above.

> 
> > 
> > > >
> > > >
> > > > ----- Original Message -----
> > > >> From: "Livnat Peer" <lpeer at redhat.com>
> > > >> To: "Moti Asayag" <masayag at redhat.com>
> > > >> Cc: engine-devel at ovirt.org
> > > >> Sent: Friday, March 21, 2014 8:33:59 AM
> > > >> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
> > > >> enable
> > > >> to decrease DC compatibility...
> > > >>
> > > >> On 03/20/2014 09:20 PM, Moti Asayag wrote:
> > > >>> ----- Original Message -----
> > > >>>> From: "Moti Asayag" <masayag at redhat.com>
> > > >>>> To: "Livnat Peer" <lpeer at redhat.com>
> > > >>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> > > >>>> Sent: Wednesday, March 12, 2014 10:44:07 PM
> > > >>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
> > > >>>> enable
> > > >>>> to decrease DC compatibility...
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> ----- Original Message -----
> > > >>>>> From: "Livnat Peer" <lpeer at redhat.com>
> > > >>>>> To: "Moti Asayag" <masayag at redhat.com>
> > > >>>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> > > >>>>> Sent: Wednesday, March 12, 2014 10:33:45 PM
> > > >>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
> > > >>>>> enable
> > > >>>>> to
> > > >>>>> decrease DC compatibility...
> > > >>>>>
> > > >>>>> On 03/12/2014 10:20 PM, Moti Asayag wrote:
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> ----- Original Message -----
> > > >>>>>>> From: "Livnat Peer" <lpeer at redhat.com>
> > > >>>>>>> To: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
> > > >>>>>>> Sent: Wednesday, March 12, 2014 12:42:44 PM
> > > >>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
> > > >>>>>>> enable
> > > >>>>>>> to	decrease DC compatibility...
> > > >>>>>>>
> > > >>>>>>> On 03/12/2014 11:59 AM, Itamar Heim wrote:
> > > >>>>>>>> On 03/12/2014 12:26 AM, emesika at redhat.com wrote:
> > > >>>>>>>>> Eli Mesika has submitted this change and it was merged.
> > > >>>>>>>>>
> > > >>>>>>>>> Change subject: core: enable to decrease DC compatibility...
> > > >>>>>>>>> ......................................................................
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> core: enable to decrease DC compatibility...
> > > >>>>>>>>>
> > > >>>>>>>>> enable to decrease DC compatibility version if DC has no
> > > >>>>>>>>> clusters
> > > >>>>>>>>>
> > > >>>>>>>>> This patch enables to decrease the DC compatibility version if
> > > >>>>>>>>> DC
> > > >>>>>>>>> has
> > > >>>>>>>>> no
> > > >>>>>>>>> clusters.
> > > >>>>>>>>
> > > >>>>>>>> Eli - just saw this. I'm pretty sure it would be *bad* to
> > > >>>>>>>> downgrade
> > > >>>>>>>> a
> > > >>>>>>>> DC
> > > >>>>>>>> version if it has storage domains as well. not sure if this is
> > > >>>>>>>> checked
> > > >>>>>>>> already or not.
> > > >>>>>>>>
> > > >>>>>>>> may also be an issue with some logical network features.
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>> Most of the network features are driven from cluster level, we
> > > >>>>>>> enable
> > > >>>>>>> using the features on all DC level (actually >=3.1) but actually
> > > >>>>>>> enable
> > > >>>>>>> /disable the feature when attaching the network to a cluster.
> > > >>>>>>>
> > > >>>>>>> So from network perspective I think it should be fine to
> > > >>>>>>> downgrade
> > > >>>>>>> the
> > > >>>>>>> DC level even if there are networks in the DC (at least now this
> > > >>>>>>> could
> > > >>>>>>> change in future versions).
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>> Actually we block adding or updating networks if the feature is
> > > >>>>>> not
> > > >>>>>> supported
> > > >>>>>> on the network's DC level, for example: STP, Jumbo frames and
> > > >>>>>> non-vm
> > > >>>>>> network.
> > > >>>>>>
> > > >>>>>
> > > >>>>>  From which DC level we support STP?  Jumbo frames? non-vm network?
> > > >>>>>  isn't
> > > >>>>> all of them supported in >=3.1 ?
> > > >>>>>
> > > >>>>
> > > >>>> Yes, mainly the problem with downgrading a DC to 3.0.
> > > >>>>
> > > >>>
> > > >>> I had a discussion with Mike (cc'ed) about several possible solutions
> > > >>> for the networks compatibility within the data-center.
> > > >>>
> > > >>> The first proposed solution would utilize the NetworkUpdateValidator,
> > > >>> a validation utility that verifies the compatibility of a network
> > > >>> to the data-center. This solution preserves the same behaviour as
> > > >>> today,
> > > >>> that the features of network-level are dictated by the DC version. No
> > > >>> need to reimplement any logic in the decrease DC version flow, just
> > > >>> use
> > > >>> an existing one to be applied for any network within the DC.
> > > >>>
> > > >>> The second solution suggests we allow any settings of a network, and
> > > >>> compatibility enforcement is done on attaching the network to the
> > > >>> clusters.
> > > >>> This modifies the existing behaviour and expands the capabilities of
> > > >>> the
> > > >>> engine to support advanced network feature in advanced cluster within
> > > >>> an
> > > >>> old data center (i.e. cluster 3.4 in 3.0 data-center could and
> > > >>> probably
> > > >>> should use non-vm network, jumbo-frames and more).
> > > >>> This option requires more work in add/update network and attach
> > > >>> network
> > > >>> to
> > > >>> cluster
> > > >>> flows, both on the backend and UI. Specifically since by default a
> > > >>> new
> > > >>> network
> > > >>> created in a DC is being attached to all of the clusters.
> > > >>> Perhaps the second option deserves to be treated as RFE and not as a
> > > >>> bug
> > > >>> fix.
> > > >>>
> > > >>> Thoughts ?
> > > >>>
> > > >>
> > > >> The second approach you suggested is equivalent to creating networks
> > > >> in
> > > >> cluster level vs. DC level, which is used today.
> > > >>
> > > >> We should consider that for 4.0 and think on the pros and cons of
> > > >> doing
> > > >> so.
> > > >>
> > > >> In general for this specific discussion I think a simple block on DC
> > > >> downgrade should be enough.
> > > >>
> > > >>> Moti
> > > >>>
> > > >>>>>> Therefore if the management network was configured with any of
> > > >>>>>> those
> > > >>>>>> feature,
> > > >>>>>> there is a need to either block the action or to 'initialize' the
> > > >>>>>> network
> > > >>>>>> to
> > > >>>>>> the default settings (as new network being added).
> > > >>>>>>
> > > >>>>>>> In general I believe the use case for this patch is mostly for
> > > >>>>>>> empty
> > > >>>>>>> DCs
> > > >>>>>>> so for simplicity we should block it if there are networks or SD
> > > >>>>>>> in
> > > >>>>>>> the
> > > >>>>>>> DC when downgrading.
> > > >>>>>>>
> > > >>>>>>> Livnat
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
> > > >>>>>>>>> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
> > > >>>>>>>>> Signed-off-by: Eli Mesika <emesika at redhat.com>
> > > >>>>>>>>> ---
> > > >>>>>>>>> M
> > > >>>>>>>>> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
> > > >>>>>>>>>
> > > >>>>>>>>> 1 file changed, 5 insertions(+), 2 deletions(-)
> > > >>>>>>>>>
> > > >>>>>>>>> Approvals:
> > > >>>>>>>>>     Eli Mesika: Verified
> > > >>>>>>>>>     Ravi Nori: Looks good to me, but someone else must approve
> > > >>>>>>>>>     Yair Zaslavsky: Looks good to me, approved
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>> _______________________________________________
> > > >>>>>>> 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
> > > >
> > > 
> > > _______________________________________________
> > > 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
> 


From chuan.liao at hp.com  Wed Apr  2 07:10:36 2014
From: chuan.liao at hp.com (Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC))
Date: Wed, 2 Apr 2014 07:10:36 +0000
Subject: [Engine-devel] FW: Discussion about NUMA feature and CPU pinning
Message-ID: <B63C858E777679458338A30A991BB524015F8CAE@G2W2441.americas.hpqcorp.net>

Forward to public group

Best Regards,
Jason Liao

From: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
Sent: 2014?4?1? 16:56
To: 'Gilad Chaplik'
Cc: Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); 'devel at ovirt.org'
Subject: Discussion about NUMA feature and CPU pinning

Hi Gilad,

When I define VdcActionType to manage Virtual NUMA node and pin Virtual NUMA node to host NUMA node.

There are some operations in list:

1.      New Virtual NUMA node ( set vcpus count, set total memory )

2.      Pin Virtual NUMA node to host NUMA node ( save host NUMA node ID into Virtual NUMA node )

3.      Save a VM?s all Virtual NUMA node

a)         Calculate VM pin to host property from host NUMA node?s host ID.

b)         Calculate VM NUMA tuning nodeset from all Virtual NUMA node?s pin to host NUMA node ID.

c)         Calculate VM CPU pinning from all Virtual NUMA node?s vcpus and related pin to host NUMA node cpus

e.g.

host NUMA node 0 cpus 0, 1, 2, 3

host NUMA node 1 cpus 4, 5, 6, 7

host NUMA node 2 cpus 8, 9, 10, 11

host NUMA node 3 cpus 12, 13, 14, 15

virtual NUMA node 0 vcpus count 2

virtual NUMA node 1 vcpus count 2



pin virtual NUMA node 0 to host NUMA node 1

pin virtual NUMA node 1 to host NUMA node 3



b. Calculate result: 1,3

c. Calculate result: 0#4,5,6,7_1#4,5,6,7_2#12,13,14,15_3#12,13,14,15

Discussion:

1.      Do we need these operations, especially method c. ?

2.      If the answer is Yes, this operation will replace the Cpu pinning configuration from VM Cpu pining input, Do we need to notify the owner ?

Best Regards,
Jason Liao

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140402/acebd94a/attachment.html>

From ecohen at redhat.com  Wed Apr  2 12:19:15 2014
From: ecohen at redhat.com (Einav Cohen)
Date: Wed, 2 Apr 2014 08:19:15 -0400 (EDT)
Subject: [Engine-devel] does anyone know if there is an ovirt weekly status
	meeting today?
In-Reply-To: <1201796524.6144718.1396441119296.JavaMail.zimbra@redhat.com>
Message-ID: <2137972428.6144915.1396441155606.JavaMail.zimbra@redhat.com>

it has been removed from the calendar (at least mine...)

Thanks,
Einav


From sbonazzo at redhat.com  Wed Apr  2 15:02:15 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 02 Apr 2014 17:02:15 +0200
Subject: [Engine-devel] oVirt 3.3.5 Release Candidate is now available
Message-ID: <533C2677.2090509@redhat.com>

The oVirt team is pleased to announce that the 3.3.5 Release Candidate is now
available for testing.

Release notes for this update and detailed installation instructions
are available on the wiki [1].

Feel free to join us testing it [2]!

A new oVirt Node build will be available soon as well.

[1] http://www.ovirt.org/OVirt_3.3.5_release_notes
[2] http://www.ovirt.org/Testing/oVirt_3.3.5_testing

Thanks,
-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From gchaplik at redhat.com  Wed Apr  2 17:00:30 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Wed, 2 Apr 2014 13:00:30 -0400 (EDT)
Subject: [Engine-devel] 3.5 SLA features overview
Message-ID: <1300500061.3638463.1396458030434.JavaMail.zimbra@redhat.com>

The following is a new meeting request:

Subject: 3.5 SLA features overview 
Organizer: "Gilad Chaplik" <gchaplik at redhat.com> 

Time: Tuesday, April 8, 2014, 5:00:00 PM - 6:00:00 PM GMT +02:00 Jerusalem
 
Required: msivak at redhat.com; jmoskovc at redhat.com; kianku at redhat.com 
Optional: dfediuck at redhat.com; sherold at redhat.com; engine-devel at ovirt.org 

*~*~*~*~*~*~*~*~*~*

Hi all, 

We will present SLA features for version 3.5:

Timeline:
* Opta planner integration, Martin, 10min
* Hosted Engine on SAN support, Jirka, 10min
* CPU limits, Kobi, 10min
* NUMA integration, 10min
* blkio limits, Gilad, 10min
* Q&A, rest of time

Dial in:
https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405 
conf id: 972 545 636 785# 

See you there, 
Gilad.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 2419 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140402/c6b6da6e/attachment.ics>

From gchaplik at redhat.com  Wed Apr  2 17:13:31 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Wed, 2 Apr 2014 13:13:31 -0400 (EDT)
Subject: [Engine-devel] 3.5 SLA features overview
Message-ID: <780187616.3672962.1396458811493.JavaMail.zimbra@redhat.com>

The following meeting has been modified:

Subject: 3.5 SLA features overview 
Organizer: "Gilad Chaplik" <gchaplik at redhat.com> 

Time: Tuesday, April 8, 2014, 5:00:00 PM - 6:00:00 PM GMT +02:00 Jerusalem
 
Required: msivak at redhat.com; jmoskovc at redhat.com; kianku at redhat.com; sgordon at redhat.com; chegu_vinod at hp.com 
Optional: dfediuck at redhat.com; sherold at redhat.com; engine-devel at ovirt.org 

*~*~*~*~*~*~*~*~*~*

Hi all, 

We will present SLA features for version 3.5: 

Timeline: 
* NUMA integration, David and Vinod (HP), 10min 
* Opta planner integration, Martin, 10min 
* Hosted Engine on SAN support, Jirka, 10min 
* CPU limits, Kobi, 10min 
* blkio limits, Gilad, 10min 
* Q&A, rest of time 

Dial in: 
https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405 
conf id: 972 545 636 785# 

See you there, 
Gilad. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 2701 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140402/7e08f778/attachment.ics>

From gchaplik at redhat.com  Thu Apr  3 01:04:55 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Wed, 2 Apr 2014 21:04:55 -0400 (EDT)
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <434209250.5741543.1396336237695.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<182238414.11560689.1396257704986.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD11A@G5W2743.americas.hpqcorp.net>
	<1087291412.5091657.1396259332718.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD16D@G5W2743.americas.hpqcorp.net>
	<1690885238.11367.1396272677929.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD232@G5W2743.americas.hpqcorp.net>
	<434209250.5741543.1396336237695.JavaMail.zimbra@redhat.com>
Message-ID: <509028518.3947921.1396487095509.JavaMail.zimbra@redhat.com>

Hi all, 
Sorry for joining-in late.

My comments (according to the db diagram section in https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_ISTY8ykDr0I6VY):
1) Join vm_numa_node and vds_numa_node to a single table (almost identical), one of the FKs can be null.
2) No templates reference in the design, need to check it out (it might be inherently designed already :-) ); vNode can be linked to a template.
3) The reason I want host's NUMA data to be in static is because it updates only once (on boot). "engineerically" speaking, dynamic table has a lot of traffic and that's not the case for NUMA info. Its feels to me like 'a hybrid' of static and dynamic, 3 suggestions comes to mind:
 - leave it in dynamic (maybe in a separate process).
 - have a separate flow that updates static.
 - come up with a third 'vds_on_boot' table (my favorite ;-P ).
I will get back to you on that.
4) vm_vds_numa_node_map is connected to vds_numa_node_statistics, why to split the tables (vds_numa_node & vds_numa_node_statistics), going back to comment #1, don't we want vNode stats as well, it can be nice to show it :-) (have a vNUMA overview of the VM using guest-agent or sth, in a future phase).
5) IMO vds_cpu_statistics shouldn't include any reference to NUMA, I gave that comment in the BE patch as well (remove vds_numa_node_id FK in vds_cpu_statistics), for that you should extract cpu_list to a connection table (anyway I don't like lists as a text/strings/etc.)
6) vm_numatune_nodeset can be removed - the vNode should hold it's pinning info; I think that vNode (node according to comment #1) should be connected to a connection table that points to vdsNode (also Node table) itself (kinda complicated but does the trick - nested link).
7) Please add delete-cascade info all over, i.e. what happens when we remove a host/vm/node.
8) Is it possible to put a db constraint that mapping between vNode and Node will be deleted once the VM isn't UP?

Thanks, 
Gilad.

----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan" <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>,
> "Chegu Vinod" <chegu_vinod at hp.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron
> Fediuck" <dfediuck at redhat.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>,
> "Yaniv Dary" <ydary at redhat.com>, engine-devel at ovirt.org
> Sent: Tuesday, April 1, 2014 10:10:37 AM
> Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt
> 
> 
> 
> ----- Original Message -----
> > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan" <rgolan at redhat.com>,
> > "Omer Frenkel" <ofrenkel at redhat.com>,
> > "Eli Mesika" <emesika at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>
> > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>,
> > "Doron Fediuck" <dfediuck at redhat.com>,
> > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > engine-devel at ovirt.org
> > Sent: Tuesday, April 1, 2014 5:13:34 AM
> > Subject: RE: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > Assemble the related discussions in this mail session.
> > 
> > Hi Vinod,
> > On 3/31/2014 2:38 AM, Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) wrote:
> > > We put host level NUMA fields in vds_dynamic because these information
> > > are
> > > from host itself, and NUMA topology may be changed if the host's hardware
> > > make a change.
> > Can you please elaborate ? Are you thinking about resource (cpu and/or
> > memory) hot plug on the host ?
> > [Bruce] It's not about resource hot plug. In ovirt engine, there is a
> > scheduled task which will refresh hosts' and vms' information periodically.
> > Only the dynamic and statistics data will be updated during the refresh. So
> > I think the resource information, such as cpu and/or memory, should be in
> > dynamic and statistics. And in my understanding, the information in dynamic
> > class is the changeable information but with a low varying frequency, like
> > cpu topology, libvirt/kernel versions, etc. The information in statistics
> > class is the information with a high varying frequency, like the usage of
> > cpu/memory, etc. In my opinion, it's reasonable to put host level NUMA
> > information in vds_dynamic and host level NUMA statistics information in
> > vds_statistics.
> > 
> > Hi Gilad/Roy/Omer,
> > I don't know if my understanding is correct. But according to this guess, I
> > think it's also reasonable to put vm cpuPin information in vm_static.
> > Because cpuPin is user configured information, it will not vary
> > automatically. So we don?t need to refresh this information periodically.
> > Please correct me if there are any mistakes.
> > 
> > Hi Eli,
> > Sorry for the nag. If my understanding above is correct, I think we should
> > still put host level NUMA fields in vds_dynamic/vds_statistics and vm level
> > NUMA fields in vm_static. Since vm level NUMA fields are configured by user
> > and they will not vary automatically.
> 
> Sorry, I had understood from Gilad that the NUMA fields in the host level are
> relatively static and the NUMA fields on the VM level are dynamic.
> I have no problem of having hybrid static/dynamic fields for Host/VM as long
> as it has a good reason and fully documented :-)
> 
> 
> > 
> > 
> > Thanks & Best Regards
> > Shi, Xiao-Lei (Bruce)
> > 
> > Hewlett-Packard Co., Ltd.
> > HP Servers Core Platform Software China
> > Telephone +86 23 65683093
> > Mobile +86 18696583447
> > Email xiao-lei.shi at hp.com
> > 
> > 
> > -----Original Message-----
> > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > Sent: Monday, March 31, 2014 9:31 PM
> > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Roy Golan; Omer Frenkel
> > Cc: Eli Mesika; Roy Golan; Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC);
> > Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > HPservers-Core-OE-PSC); Yaniv Dary; engine-devel at ovirt.org
> > Subject: Re: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > adding Roy & Omer.
> > 
> > why CPU topology is in dynamic?
> > 
> > Thanks,
> > Gilad.
> > 
> > ----- Original Message -----
> > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > To: "Eli Mesika" <emesika at redhat.com>
> > > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > > <rgolan at redhat.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > Sent: Monday, March 31, 2014 3:20:33 PM
> > > Subject: RE: Please help us to review our database schema design with
> > > NUMA feature on ovirt
> > > 
> > > Thanks Eli.
> > > I will move the vm level NUMA fields to vm_dynamic, and the related
> > > database schema will be updated accordingly.
> > > 
> > > Thanks & Best Regards
> > > Shi, Xiao-Lei (Bruce)
> > > 
> > > Hewlett-Packard Co., Ltd.
> > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > 
> > > -----Original Message-----
> > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > Sent: Monday, March 31, 2014 5:49 PM
> > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao,
> > > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun
> > > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > > engine-devel at ovirt.org
> > > Subject: Re: Please help us to review our database schema design with
> > > NUMA feature on ovirt
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > <xiao-lei.shi at hp.com>
> > > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
> > > > <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>
> > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu
> > > > Vinod"
> > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > > HPservers-Core-OE-PSC)"
> > > > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > > > engine-devel at ovirt.org
> > > > Sent: Monday, March 31, 2014 12:38:04 PM
> > > > Subject: RE: Please help us to review our database schema design
> > > > with NUMA feature on ovirt
> > > > 
> > > > We put host level NUMA fields in vds_dynamic because these
> > > > information are from host itself, and NUMA topology may be changed
> > > > if the host's hardware make a change. NUMA information are similar
> > > > to the host's cpu topology information like cpu_cores and
> > > > cpu_sockets which are in vds_dynamic, we refer to this.
> > > > VM level NUMA fields are configured by user, and actually we
> > > > originally think they should be in vm_dynamic. But we found that the
> > > > field of another feature cpuPin which is similar as NUMA feature is
> > > > in vm_static, so we put vm NUMA fields in vm_static.
> > > > Do you think we need to put VM level NUMA fields in vm_dynamic?
> > > 
> > > I think that in this case we should fix cpuPin to be in vm_dynamic and
> > > put after that the other NUMA fields in vm_dynamic as well
> > > 
> > > > 
> > > > Thanks & Best Regards
> > > > Shi, Xiao-Lei (Bruce)
> > > > 
> > > > Hewlett-Packard Co., Ltd.
> > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > > Sent: Monday, March 31, 2014 5:22 PM
> > > > To: Eli Mesika; Roy Golan
> > > > Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason
> > > > Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang,
> > > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > > > engine-devel at ovirt.org
> > > > Subject: Re: Please help us to review our database schema design
> > > > with NUMA feature on ovirt
> > > > 
> > > > +1
> > > > 
> > > > IMO: vds data should reside in static VM need to think about it.
> > > > 
> > > > Roy?
> > > > 
> > > > Thanks,
> > > > Gilad.
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > <xiao-lei.shi at hp.com>
> > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Gilad
> > > > > Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > <chegu_vinod at hp.com>,
> > > > > "Shang-Chun Liang (David Liang,
> > > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > Sent: Monday, March 31, 2014 12:12:50 PM
> > > > > Subject: Re: Please help us to review our database schema design
> > > > > with NUMA feature on ovirt
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > <xiao-lei.shi at hp.com>
> > > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > <chuan.liao at hp.com>,
> > > > > > "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > <chegu_vinod at hp.com>,
> > > > > > "Shang-Chun Liang (David Liang,
> > > > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > > Sent: Monday, March 31, 2014 8:56:20 AM
> > > > > > Subject: RE: Please help us to review our database schema design
> > > > > > with NUMA feature on ovirt
> > > > > > 
> > > > > > Include the devel group.
> > > > > > Thanks Eli for the quick responses for our first design and
> > > > > > sorry for the nag.
> > > > > > We appreciate any of the comments for our database design and
> > > > > > will follow the design to do the implementation if no more
> > > > > > comments.
> > > > > >  http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > 
> > > > > Seems OK for me except an unanswered question I had asked in my
> > > > > first review
> > > > > :
> > > > > 
> > > > > Why in the Host level NUMA fields are added to vds_dynamic while
> > > > > in the VM level it is added to vm_static ???
> > > > > I would expect it to be in both on static or dynamic , can you
> > > > > please explain ? Thanks
> > > > > 
> > > > > > 
> > > > > > Thanks & Best Regards
> > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > 
> > > > > > Hewlett-Packard Co., Ltd.
> > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > Sent: Friday, March 28, 2014 1:30 PM
> > > > > > To: 'Eli Mesika'
> > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
> > > > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun (David
> > > > > > Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > Subject: RE: Please help us to review our database schema design
> > > > > > with NUMA feature on ovirt
> > > > > > 
> > > > > > Hi Eli,
> > > > > > 
> > > > > > After the UX design meeting, we did some modification for the
> > > > > > database schema, and merged some update according to your last
> > > > > > review
> > > > > > comments.
> > > > > > Now the document has been posted on ovirt wikipage, could you
> > > > > > help to review the database design again:
> > > > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > > 
> > > > > > 
> > > > > > Thanks & Best Regards
> > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > 
> > > > > > Hewlett-Packard Co., Ltd.
> > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > 65683093 Mobile
> > > > > > +86
> > > > > > 18696583447 Email xiao-lei.shi at hp.com
> > > > > > 
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > Sent: Monday, March 24, 2014 6:24 PM
> > > > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
> > > > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun (David
> > > > > > Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > Subject: Re: Please help us to review our database schema design
> > > > > > with NUMA feature on ovirt
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason
> > > > > > > Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > <shangchun.liang at hp.com>
> > > > > > > Sent: Monday, March 24, 2014 11:23:39 AM
> > > > > > > Subject: RE: Please help us to review our database schema
> > > > > > > design with NUMA feature on ovirt
> > > > > > > 
> > > > > > > Hi Eli,
> > > > > > > 
> > > > > > > Thanks for your comments.
> > > > > > > I have updated the document according to your comments except
> > > > > > > the below
> > > > > > > one:
> > > > > > > Missing from here are 2 issues:
> > > > > > > 
> > > > > > > 1) Impact on the search engine, which new columns are
> > > > > > > search-able and which changes are planned in the search engine
> > > > > > > code to enable that
> > > > > > > 
> > > > > > > 2) Impact on engine-reports, are those changed planned to be
> > > > > > > exposed to the engine data warehouse and required new/modified
> > > > > > > reports?
> > > > > > > 
> > > > > > > Could you tell us more detailed information about the modules
> > > > > > > you mentioned above? I mean "search engine" and
> > > > > > > "engine-reports". I think we missed these two parts in our
> > > > > > > previous
> > > > > > > investigation.
> > > > > > > I just find org.ovirt.engine.core.bll.SearchQuery, is that the
> > > > > > > right object for search engine?
> > > > > > 
> > > > > > Yes, actually when you are opening the admin UI, there are TABs
> > > > > > for each entity , i.e. Data Center, Cluster, Host etc.
> > > > > > In each, you can see a text-box in which you can search for by
> > > > > > writing a search expression My question is
> > > > > >    1) What is the impact of your work on the search on the Fost and
> > > > > >    VM
> > > > > >    TABs
> > > > > >       a) Are there any fields that are supported now in the search
> > > > > >       expression
> > > > > >       and should pop-up when you write the expression by the
> > > > > >       auto-completion
> > > > > >       mechanism ?
> > > > > >       b) Are there any added columns displayed in the result of
> > > > > >       such
> > > > > >       a
> > > > > >       search
> > > > > >       in the grid ?
> > > > > > 
> > > > > > > How about the engine-reports, could you give us some hints,
> > > > > > > like the code location and any more detailed information that
> > > > > > > we can start more investigation?
> > > > > > 
> > > > > > CCing Yaniv D who is in charge of the reports/dwh module Yaniv,
> > > > > > any planned work for adding Numa features to Host/VM in the
> > > > > > reports side ?
> > > > > > 
> > > > > > Thanks
> > > > > > 
> > > > > > > 
> > > > > > > Thanks & Best Regards
> > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > 
> > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > > Sent: Sunday, March 23, 2014 4:44 PM
> > > > > > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > > > > > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang,
> > > > > > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei
> > > > > > > (Bruce, HP
> > > > > > > Servers-PSC-CQ)
> > > > > > > Subject: Re: Please help us to review our database schema
> > > > > > > design with NUMA feature on ovirt
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > > <chuan.liao at hp.com>
> > > > > > > > To: emesika at redhat.com
> > > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP
> > > > > > > > Servers-PSC-CQ)"
> > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > > > > > > Subject: Please help us to review our database schema design
> > > > > > > > with NUMA feature on ovirt
> > > > > > > > 
> > > > > > > > Hi Eli,
> > > > > > > > 
> > > > > > > > Please help us to review our database schema design with
> > > > > > > > NUMA feature on ovirt
> > > > > > > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWA
> > > > > > > > cyQo_IST
> > > > > > > > Y8
> > > > > > > > ykDr0I6VY/edit?usp=sharing
> > > > > > > > 
> > > > > > > > Feel free to take comments on document at anywhere
> > > > > > > 
> > > > > > > Done, had commented on the document.
> > > > > > > Eli
> > > > > > > 
> > > > > > > > 
> > > > > > > > Especially, 5.4 The used interface between engine core and
> > > > > > > > database(schema)
> > > > > > > > 
> > > > > > > > Your approve and your comments with this section will be
> > > > > > > > much more appreciate for us.
> > > > > > > > 
> > > > > > > > Best Regards,
> > > > > > > > Jason Liao
> > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
>


From gchaplik at redhat.com  Thu Apr  3 01:11:05 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Wed, 2 Apr 2014 21:11:05 -0400 (EDT)
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <509028518.3947921.1396487095509.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<08AA403C8399104A89AF710307FA78AE243DD11A@G5W2743.americas.hpqcorp.net>
	<1087291412.5091657.1396259332718.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD16D@G5W2743.americas.hpqcorp.net>
	<1690885238.11367.1396272677929.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD232@G5W2743.americas.hpqcorp.net>
	<434209250.5741543.1396336237695.JavaMail.zimbra@redhat.com>
	<509028518.3947921.1396487095509.JavaMail.zimbra@redhat.com>
Message-ID: <768402986.3950091.1396487465585.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: engine-devel at ovirt.org, "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>
> Sent: Thursday, April 3, 2014 4:04:55 AM
> Subject: Re: [Engine-devel] Please help us to review our database schema design with NUMA feature on ovirt
> 
> Hi all,
> Sorry for joining-in late.
> 
> My comments (according to the db diagram section in
> https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_ISTY8ykDr0I6VY):
> 1) Join vm_numa_node and vds_numa_node to a single table (almost identical),
> one of the FKs can be null.
> 2) No templates reference in the design, need to check it out (it might be
> inherently designed already :-) ); vNode can be linked to a template.
> 3) The reason I want host's NUMA data to be in static is because it updates
> only once (on boot). "engineerically" speaking, dynamic table has a lot of
> traffic and that's not the case for NUMA info. Its feels to me like 'a
> hybrid' of static and dynamic, 3 suggestions comes to mind:
>  - leave it in dynamic (maybe in a separate process).
>  - have a separate flow that updates static.
>  - come up with a third 'vds_on_boot' table (my favorite ;-P ).
> I will get back to you on that.
> 4) vm_vds_numa_node_map is connected to vds_numa_node_statistics, why to
> split the tables (vds_numa_node & vds_numa_node_statistics), going back to
> comment #1, don't we want vNode stats as well, it can be nice to show it :-)
> (have a vNUMA overview of the VM using guest-agent or sth, in a future
> phase).
> 5) IMO vds_cpu_statistics shouldn't include any reference to NUMA, I gave
> that comment in the BE patch as well (remove vds_numa_node_id FK in
> vds_cpu_statistics), for that you should extract cpu_list to a connection
> table (anyway I don't like lists as a text/strings/etc.)
> 6) vm_numatune_nodeset can be removed - the vNode should hold it's pinning
> info; I think that vNode (node according to comment #1) should be connected
> to a connection table that points to vdsNode (also Node table) itself (kinda
> complicated but does the trick - nested link).

correction: no need for another connection table, use vm_vds_numa_node_map with a flag (is_pinned)

> 7) Please add delete-cascade info all over, i.e. what happens when we remove
> a host/vm/node.
> 8) Is it possible to put a db constraint that mapping between vNode and Node
> will be deleted once the VM isn't UP?
> 
> Thanks,
> Gilad.
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan" <rgolan at redhat.com>,
> > "Omer Frenkel" <ofrenkel at redhat.com>,
> > "Chegu Vinod" <chegu_vinod at hp.com>, "Chuan Liao (Jason Liao,
> > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron
> > Fediuck" <dfediuck at redhat.com>, "Shang-Chun Liang (David Liang,
> > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>,
> > "Yaniv Dary" <ydary at redhat.com>, engine-devel at ovirt.org
> > Sent: Tuesday, April 1, 2014 10:10:37 AM
> > Subject: Re: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > > <rgolan at redhat.com>,
> > > "Omer Frenkel" <ofrenkel at redhat.com>,
> > > "Eli Mesika" <emesika at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>
> > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>,
> > > "Doron Fediuck" <dfediuck at redhat.com>,
> > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > > engine-devel at ovirt.org
> > > Sent: Tuesday, April 1, 2014 5:13:34 AM
> > > Subject: RE: Please help us to review our database schema design with
> > > NUMA
> > > feature on ovirt
> > > 
> > > Assemble the related discussions in this mail session.
> > > 
> > > Hi Vinod,
> > > On 3/31/2014 2:38 AM, Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) wrote:
> > > > We put host level NUMA fields in vds_dynamic because these information
> > > > are
> > > > from host itself, and NUMA topology may be changed if the host's
> > > > hardware
> > > > make a change.
> > > Can you please elaborate ? Are you thinking about resource (cpu and/or
> > > memory) hot plug on the host ?
> > > [Bruce] It's not about resource hot plug. In ovirt engine, there is a
> > > scheduled task which will refresh hosts' and vms' information
> > > periodically.
> > > Only the dynamic and statistics data will be updated during the refresh.
> > > So
> > > I think the resource information, such as cpu and/or memory, should be in
> > > dynamic and statistics. And in my understanding, the information in
> > > dynamic
> > > class is the changeable information but with a low varying frequency,
> > > like
> > > cpu topology, libvirt/kernel versions, etc. The information in statistics
> > > class is the information with a high varying frequency, like the usage of
> > > cpu/memory, etc. In my opinion, it's reasonable to put host level NUMA
> > > information in vds_dynamic and host level NUMA statistics information in
> > > vds_statistics.
> > > 
> > > Hi Gilad/Roy/Omer,
> > > I don't know if my understanding is correct. But according to this guess,
> > > I
> > > think it's also reasonable to put vm cpuPin information in vm_static.
> > > Because cpuPin is user configured information, it will not vary
> > > automatically. So we don?t need to refresh this information periodically.
> > > Please correct me if there are any mistakes.
> > > 
> > > Hi Eli,
> > > Sorry for the nag. If my understanding above is correct, I think we
> > > should
> > > still put host level NUMA fields in vds_dynamic/vds_statistics and vm
> > > level
> > > NUMA fields in vm_static. Since vm level NUMA fields are configured by
> > > user
> > > and they will not vary automatically.
> > 
> > Sorry, I had understood from Gilad that the NUMA fields in the host level
> > are
> > relatively static and the NUMA fields on the VM level are dynamic.
> > I have no problem of having hybrid static/dynamic fields for Host/VM as
> > long
> > as it has a good reason and fully documented :-)
> > 
> > 
> > > 
> > > 
> > > Thanks & Best Regards
> > > Shi, Xiao-Lei (Bruce)
> > > 
> > > Hewlett-Packard Co., Ltd.
> > > HP Servers Core Platform Software China
> > > Telephone +86 23 65683093
> > > Mobile +86 18696583447
> > > Email xiao-lei.shi at hp.com
> > > 
> > > 
> > > -----Original Message-----
> > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > Sent: Monday, March 31, 2014 9:31 PM
> > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Roy Golan; Omer Frenkel
> > > Cc: Eli Mesika; Roy Golan; Liao, Chuan (Jason Liao,
> > > HPservers-Core-OE-PSC);
> > > Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > > HPservers-Core-OE-PSC); Yaniv Dary; engine-devel at ovirt.org
> > > Subject: Re: Please help us to review our database schema design with
> > > NUMA
> > > feature on ovirt
> > > 
> > > adding Roy & Omer.
> > > 
> > > why CPU topology is in dynamic?
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > ----- Original Message -----
> > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > > > <rgolan at redhat.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu
> > > > Vinod"
> > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > Sent: Monday, March 31, 2014 3:20:33 PM
> > > > Subject: RE: Please help us to review our database schema design with
> > > > NUMA feature on ovirt
> > > > 
> > > > Thanks Eli.
> > > > I will move the vm level NUMA fields to vm_dynamic, and the related
> > > > database schema will be updated accordingly.
> > > > 
> > > > Thanks & Best Regards
> > > > Shi, Xiao-Lei (Bruce)
> > > > 
> > > > Hewlett-Packard Co., Ltd.
> > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > 
> > > > -----Original Message-----
> > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > Sent: Monday, March 31, 2014 5:49 PM
> > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao,
> > > > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun
> > > > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > > > engine-devel at ovirt.org
> > > > Subject: Re: Please help us to review our database schema design with
> > > > NUMA feature on ovirt
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > <xiao-lei.shi at hp.com>
> > > > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
> > > > > <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>
> > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu
> > > > > Vinod"
> > > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > > > HPservers-Core-OE-PSC)"
> > > > > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > > > > engine-devel at ovirt.org
> > > > > Sent: Monday, March 31, 2014 12:38:04 PM
> > > > > Subject: RE: Please help us to review our database schema design
> > > > > with NUMA feature on ovirt
> > > > > 
> > > > > We put host level NUMA fields in vds_dynamic because these
> > > > > information are from host itself, and NUMA topology may be changed
> > > > > if the host's hardware make a change. NUMA information are similar
> > > > > to the host's cpu topology information like cpu_cores and
> > > > > cpu_sockets which are in vds_dynamic, we refer to this.
> > > > > VM level NUMA fields are configured by user, and actually we
> > > > > originally think they should be in vm_dynamic. But we found that the
> > > > > field of another feature cpuPin which is similar as NUMA feature is
> > > > > in vm_static, so we put vm NUMA fields in vm_static.
> > > > > Do you think we need to put VM level NUMA fields in vm_dynamic?
> > > > 
> > > > I think that in this case we should fix cpuPin to be in vm_dynamic and
> > > > put after that the other NUMA fields in vm_dynamic as well
> > > > 
> > > > > 
> > > > > Thanks & Best Regards
> > > > > Shi, Xiao-Lei (Bruce)
> > > > > 
> > > > > Hewlett-Packard Co., Ltd.
> > > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > > > Sent: Monday, March 31, 2014 5:22 PM
> > > > > To: Eli Mesika; Roy Golan
> > > > > Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason
> > > > > Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang,
> > > > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > > > > engine-devel at ovirt.org
> > > > > Subject: Re: Please help us to review our database schema design
> > > > > with NUMA feature on ovirt
> > > > > 
> > > > > +1
> > > > > 
> > > > > IMO: vds data should reside in static VM need to think about it.
> > > > > 
> > > > > Roy?
> > > > > 
> > > > > Thanks,
> > > > > Gilad.
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > <xiao-lei.shi at hp.com>
> > > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Gilad
> > > > > > Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > <chegu_vinod at hp.com>,
> > > > > > "Shang-Chun Liang (David Liang,
> > > > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > > Sent: Monday, March 31, 2014 12:12:50 PM
> > > > > > Subject: Re: Please help us to review our database schema design
> > > > > > with NUMA feature on ovirt
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > <chuan.liao at hp.com>,
> > > > > > > "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > > <chegu_vinod at hp.com>,
> > > > > > > "Shang-Chun Liang (David Liang,
> > > > > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > > > Sent: Monday, March 31, 2014 8:56:20 AM
> > > > > > > Subject: RE: Please help us to review our database schema design
> > > > > > > with NUMA feature on ovirt
> > > > > > > 
> > > > > > > Include the devel group.
> > > > > > > Thanks Eli for the quick responses for our first design and
> > > > > > > sorry for the nag.
> > > > > > > We appreciate any of the comments for our database design and
> > > > > > > will follow the design to do the implementation if no more
> > > > > > > comments.
> > > > > > >  http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > > 
> > > > > > Seems OK for me except an unanswered question I had asked in my
> > > > > > first review
> > > > > > :
> > > > > > 
> > > > > > Why in the Host level NUMA fields are added to vds_dynamic while
> > > > > > in the VM level it is added to vm_static ???
> > > > > > I would expect it to be in both on static or dynamic , can you
> > > > > > please explain ? Thanks
> > > > > > 
> > > > > > > 
> > > > > > > Thanks & Best Regards
> > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > 
> > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > > Sent: Friday, March 28, 2014 1:30 PM
> > > > > > > To: 'Eli Mesika'
> > > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
> > > > > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun (David
> > > > > > > Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > > Subject: RE: Please help us to review our database schema design
> > > > > > > with NUMA feature on ovirt
> > > > > > > 
> > > > > > > Hi Eli,
> > > > > > > 
> > > > > > > After the UX design meeting, we did some modification for the
> > > > > > > database schema, and merged some update according to your last
> > > > > > > review
> > > > > > > comments.
> > > > > > > Now the document has been posted on ovirt wikipage, could you
> > > > > > > help to review the database design again:
> > > > > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > > > 
> > > > > > > 
> > > > > > > Thanks & Best Regards
> > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > 
> > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > 65683093 Mobile
> > > > > > > +86
> > > > > > > 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > 
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > > Sent: Monday, March 24, 2014 6:24 PM
> > > > > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
> > > > > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun (David
> > > > > > > Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > > Subject: Re: Please help us to review our database schema design
> > > > > > > with NUMA feature on ovirt
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason
> > > > > > > > Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > > <shangchun.liang at hp.com>
> > > > > > > > Sent: Monday, March 24, 2014 11:23:39 AM
> > > > > > > > Subject: RE: Please help us to review our database schema
> > > > > > > > design with NUMA feature on ovirt
> > > > > > > > 
> > > > > > > > Hi Eli,
> > > > > > > > 
> > > > > > > > Thanks for your comments.
> > > > > > > > I have updated the document according to your comments except
> > > > > > > > the below
> > > > > > > > one:
> > > > > > > > Missing from here are 2 issues:
> > > > > > > > 
> > > > > > > > 1) Impact on the search engine, which new columns are
> > > > > > > > search-able and which changes are planned in the search engine
> > > > > > > > code to enable that
> > > > > > > > 
> > > > > > > > 2) Impact on engine-reports, are those changed planned to be
> > > > > > > > exposed to the engine data warehouse and required new/modified
> > > > > > > > reports?
> > > > > > > > 
> > > > > > > > Could you tell us more detailed information about the modules
> > > > > > > > you mentioned above? I mean "search engine" and
> > > > > > > > "engine-reports". I think we missed these two parts in our
> > > > > > > > previous
> > > > > > > > investigation.
> > > > > > > > I just find org.ovirt.engine.core.bll.SearchQuery, is that the
> > > > > > > > right object for search engine?
> > > > > > > 
> > > > > > > Yes, actually when you are opening the admin UI, there are TABs
> > > > > > > for each entity , i.e. Data Center, Cluster, Host etc.
> > > > > > > In each, you can see a text-box in which you can search for by
> > > > > > > writing a search expression My question is
> > > > > > >    1) What is the impact of your work on the search on the Fost
> > > > > > >    and
> > > > > > >    VM
> > > > > > >    TABs
> > > > > > >       a) Are there any fields that are supported now in the
> > > > > > >       search
> > > > > > >       expression
> > > > > > >       and should pop-up when you write the expression by the
> > > > > > >       auto-completion
> > > > > > >       mechanism ?
> > > > > > >       b) Are there any added columns displayed in the result of
> > > > > > >       such
> > > > > > >       a
> > > > > > >       search
> > > > > > >       in the grid ?
> > > > > > > 
> > > > > > > > How about the engine-reports, could you give us some hints,
> > > > > > > > like the code location and any more detailed information that
> > > > > > > > we can start more investigation?
> > > > > > > 
> > > > > > > CCing Yaniv D who is in charge of the reports/dwh module Yaniv,
> > > > > > > any planned work for adding Numa features to Host/VM in the
> > > > > > > reports side ?
> > > > > > > 
> > > > > > > Thanks
> > > > > > > 
> > > > > > > > 
> > > > > > > > Thanks & Best Regards
> > > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > > 
> > > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > > > Sent: Sunday, March 23, 2014 4:44 PM
> > > > > > > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > > > > > > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang,
> > > > > > > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei
> > > > > > > > (Bruce, HP
> > > > > > > > Servers-PSC-CQ)
> > > > > > > > Subject: Re: Please help us to review our database schema
> > > > > > > > design with NUMA feature on ovirt
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > > > <chuan.liao at hp.com>
> > > > > > > > > To: emesika at redhat.com
> > > > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP
> > > > > > > > > Servers-PSC-CQ)"
> > > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > > > > > > > Subject: Please help us to review our database schema design
> > > > > > > > > with NUMA feature on ovirt
> > > > > > > > > 
> > > > > > > > > Hi Eli,
> > > > > > > > > 
> > > > > > > > > Please help us to review our database schema design with
> > > > > > > > > NUMA feature on ovirt
> > > > > > > > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWA
> > > > > > > > > cyQo_IST
> > > > > > > > > Y8
> > > > > > > > > ykDr0I6VY/edit?usp=sharing
> > > > > > > > > 
> > > > > > > > > Feel free to take comments on document at anywhere
> > > > > > > > 
> > > > > > > > Done, had commented on the document.
> > > > > > > > Eli
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Especially, 5.4 The used interface between engine core and
> > > > > > > > > database(schema)
> > > > > > > > > 
> > > > > > > > > Your approve and your comments with this section will be
> > > > > > > > > much more appreciate for us.
> > > > > > > > > 
> > > > > > > > > Best Regards,
> > > > > > > > > Jason Liao
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From xiao-lei.shi at hp.com  Thu Apr  3 04:25:11 2014
From: xiao-lei.shi at hp.com (Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ))
Date: Thu, 3 Apr 2014 04:25:11 +0000
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <509028518.3947921.1396487095509.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<182238414.11560689.1396257704986.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD11A@G5W2743.americas.hpqcorp.net>
	<1087291412.5091657.1396259332718.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD16D@G5W2743.americas.hpqcorp.net>
	<1690885238.11367.1396272677929.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD232@G5W2743.americas.hpqcorp.net>
	<434209250.5741543.1396336237695.JavaMail.zimbra@redhat.com>
	<509028518.3947921.1396487095509.JavaMail.zimbra@redhat.com>
Message-ID: <08AA403C8399104A89AF710307FA78AE243DD55D@G5W2743.americas.hpqcorp.net>

Hi all,
Please see my comments in line. 

Thanks & Best Regards
Shi, Xiao-Lei (Bruce)

Hewlett-Packard Co., Ltd.
HP Servers Core Platform Software China 
Telephone +86 23 65683093
Mobile +86 18696583447
Email xiao-lei.shi at hp.com

-----Original Message-----
From: Gilad Chaplik [mailto:gchaplik at redhat.com] 
Sent: Thursday, April 03, 2014 9:05 AM
To: Eli Mesika
Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Roy Golan; Omer Frenkel; Vinod, Chegu; Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; engine-devel at ovirt.org
Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt

Hi all,
Sorry for joining-in late.

My comments (according to the db diagram section in https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_ISTY8ykDr0I6VY):
1) Join vm_numa_node and vds_numa_node to a single table (almost identical), one of the FKs can be null.
[Bruce] I prefer two tables. Actually host level NUMA node and vm level NUMA node are different objects. In my understanding, vm level NUMA node is just a simulation of host level NUMA node, and host level NUMA node has more features that not in vm NUMA (like several levels of host NUMA topology mentioned by Vinod). We need to consider the extensions of host NUMA in the future.
   
2) No templates reference in the design, need to check it out (it might be inherently designed already :-) ); vNode can be linked to a template.
[Bruce] IMO, we can consider template as a special vm, our current design supports to create vNodes in a template just like what it does in a vm.

3) The reason I want host's NUMA data to be in static is because it updates only once (on boot). "engineerically" speaking, dynamic table has a lot of traffic and that's not the case for NUMA info. Its feels to me like 'a hybrid' of static and dynamic, 3 suggestions comes to mind:
 - leave it in dynamic (maybe in a separate process).
 - have a separate flow that updates static.
 - come up with a third 'vds_on_boot' table (my favorite ;-P ).
I will get back to you on that.
[Bruce] From the onTimer codes in vdsManager (IMO it's the scheduled vds refresh action), when vds is in normal running status (up status), only statistics data will be refreshed, so I think maybe dynamic table doesn't have so much traffic, and the varied data (I mean the data varied through a power reload, like cpu topology, numa topology, ...etc) can be refreshed meanwhile.

4) vm_vds_numa_node_map is connected to vds_numa_node_statistics, why to split the tables (vds_numa_node & vds_numa_node_statistics), going back to comment #1, don't we want vNode stats as well, it can be nice to show it :-) (have a vNUMA overview of the VM using guest-agent or sth, in a future phase).
[Bruce] Split the tables is referring to vds_interface (vds_interface_statistics) and vm_interface (vm_interface_statistics), the statistics table will be refreshed with a high frequency.
I will update the design to add the vNuma statistics for the future phase, and according to my feedback in comment #1, vNuma statistics will also in an independent table since I think there will be more statistics fields for host NUMA than for vNuma.  

5) IMO vds_cpu_statistics shouldn't include any reference to NUMA, I gave that comment in the BE patch as well (remove vds_numa_node_id FK in vds_cpu_statistics), for that you should extract cpu_list to a connection table (anyway I don't like lists as a text/strings/etc.)
[Bruce] Yes, I agree with you to remove the reference between vds_cpu_statistics and NUMA. Actually cpu_list is enough for current requirements. I think the connection table is needed when we consider to collect more cpu related information and do more cpu related actions in the future.

6) vm_numatune_nodeset can be removed - the vNode should hold it's pinning info; I think that vNode (node according to comment #1) should be connected to a connection table that points to vdsNode (also Node table) itself (kinda complicated but does the trick - nested link).
[Bruce] Yes, I will remove vm_numatune_nodeset, but according to my feedback in comment #1, vm_vds_numa_node_map table will be retained to hold the references between host nodes and vNode, since they are "m:n" relations.

7) Please add delete-cascade info all over, i.e. what happens when we remove a host/vm/node.
[Bruce] Yes, I will update the design.

8) Is it possible to put a db constraint that mapping between vNode and Node will be deleted once the VM isn't UP?
[Bruce] I have a question here. IMO, the mapping between vNode and Node is a user configuration, why it is related with the vm status? If the mapping is deleted, that means the user configuration is deleted. I don't think it's reasonable.

Thanks,
Gilad.

----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan" 
> <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>, "Chegu 
> Vinod" <chegu_vinod at hp.com>, "Chuan Liao (Jason Liao, 
> HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck" 
> <dfediuck at redhat.com>, "Shang-Chun Liang (David Liang, 
> HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary" 
> <ydary at redhat.com>, engine-devel at ovirt.org
> Sent: Tuesday, April 1, 2014 10:10:37 AM
> Subject: Re: Please help us to review our database schema design with 
> NUMA feature on ovirt
> 
> 
> 
> ----- Original Message -----
> > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" 
> > <xiao-lei.shi at hp.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan" 
> > <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>, "Eli 
> > Mesika" <emesika at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>
> > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" 
> > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, 
> > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>, 
> > engine-devel at ovirt.org
> > Sent: Tuesday, April 1, 2014 5:13:34 AM
> > Subject: RE: Please help us to review our database schema design 
> > with NUMA feature on ovirt
> > 
> > Assemble the related discussions in this mail session.
> > 
> > Hi Vinod,
> > On 3/31/2014 2:38 AM, Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) wrote:
> > > We put host level NUMA fields in vds_dynamic because these 
> > > information are from host itself, and NUMA topology may be changed 
> > > if the host's hardware make a change.
> > Can you please elaborate ? Are you thinking about resource (cpu 
> > and/or
> > memory) hot plug on the host ?
> > [Bruce] It's not about resource hot plug. In ovirt engine, there is 
> > a scheduled task which will refresh hosts' and vms' information periodically.
> > Only the dynamic and statistics data will be updated during the 
> > refresh. So I think the resource information, such as cpu and/or 
> > memory, should be in dynamic and statistics. And in my 
> > understanding, the information in dynamic class is the changeable 
> > information but with a low varying frequency, like cpu topology, 
> > libvirt/kernel versions, etc. The information in statistics class is 
> > the information with a high varying frequency, like the usage of 
> > cpu/memory, etc. In my opinion, it's reasonable to put host level 
> > NUMA information in vds_dynamic and host level NUMA statistics information in vds_statistics.
> > 
> > Hi Gilad/Roy/Omer,
> > I don't know if my understanding is correct. But according to this 
> > guess, I think it's also reasonable to put vm cpuPin information in vm_static.
> > Because cpuPin is user configured information, it will not vary 
> > automatically. So we don?t need to refresh this information periodically.
> > Please correct me if there are any mistakes.
> > 
> > Hi Eli,
> > Sorry for the nag. If my understanding above is correct, I think we 
> > should still put host level NUMA fields in 
> > vds_dynamic/vds_statistics and vm level NUMA fields in vm_static. 
> > Since vm level NUMA fields are configured by user and they will not vary automatically.
> 
> Sorry, I had understood from Gilad that the NUMA fields in the host 
> level are relatively static and the NUMA fields on the VM level are dynamic.
> I have no problem of having hybrid static/dynamic fields for Host/VM 
> as long as it has a good reason and fully documented :-)
> 
> 
> > 
> > 
> > Thanks & Best Regards
> > Shi, Xiao-Lei (Bruce)
> > 
> > Hewlett-Packard Co., Ltd.
> > HP Servers Core Platform Software China Telephone +86 23 65683093 
> > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > 
> > 
> > -----Original Message-----
> > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > Sent: Monday, March 31, 2014 9:31 PM
> > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Roy Golan; Omer 
> > Frenkel
> > Cc: Eli Mesika; Roy Golan; Liao, Chuan (Jason Liao, 
> > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, 
> > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; 
> > engine-devel at ovirt.org
> > Subject: Re: Please help us to review our database schema design 
> > with NUMA feature on ovirt
> > 
> > adding Roy & Omer.
> > 
> > why CPU topology is in dynamic?
> > 
> > Thanks,
> > Gilad.
> > 
> > ----- Original Message -----
> > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" 
> > > <xiao-lei.shi at hp.com>
> > > To: "Eli Mesika" <emesika at redhat.com>
> > > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > > <rgolan at redhat.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang, 
> > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > Sent: Monday, March 31, 2014 3:20:33 PM
> > > Subject: RE: Please help us to review our database schema design 
> > > with NUMA feature on ovirt
> > > 
> > > Thanks Eli.
> > > I will move the vm level NUMA fields to vm_dynamic, and the 
> > > related database schema will be updated accordingly.
> > > 
> > > Thanks & Best Regards
> > > Shi, Xiao-Lei (Bruce)
> > > 
> > > Hewlett-Packard Co., Ltd.
> > > HP Servers Core Platform Software China Telephone +86 23 65683093 
> > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > 
> > > -----Original Message-----
> > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > Sent: Monday, March 31, 2014 5:49 PM
> > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao, 
> > > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, 
> > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; 
> > > engine-devel at ovirt.org
> > > Subject: Re: Please help us to review our database schema design 
> > > with NUMA feature on ovirt
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > <xiao-lei.shi at hp.com>
> > > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
> > > > <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>
> > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, 
> > > > "Chegu Vinod"
> > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang, 
> > > > HPservers-Core-OE-PSC)"
> > > > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>, 
> > > > engine-devel at ovirt.org
> > > > Sent: Monday, March 31, 2014 12:38:04 PM
> > > > Subject: RE: Please help us to review our database schema design 
> > > > with NUMA feature on ovirt
> > > > 
> > > > We put host level NUMA fields in vds_dynamic because these 
> > > > information are from host itself, and NUMA topology may be 
> > > > changed if the host's hardware make a change. NUMA information 
> > > > are similar to the host's cpu topology information like 
> > > > cpu_cores and cpu_sockets which are in vds_dynamic, we refer to this.
> > > > VM level NUMA fields are configured by user, and actually we 
> > > > originally think they should be in vm_dynamic. But we found that 
> > > > the field of another feature cpuPin which is similar as NUMA 
> > > > feature is in vm_static, so we put vm NUMA fields in vm_static.
> > > > Do you think we need to put VM level NUMA fields in vm_dynamic?
> > > 
> > > I think that in this case we should fix cpuPin to be in vm_dynamic 
> > > and put after that the other NUMA fields in vm_dynamic as well
> > > 
> > > > 
> > > > Thanks & Best Regards
> > > > Shi, Xiao-Lei (Bruce)
> > > > 
> > > > Hewlett-Packard Co., Ltd.
> > > > HP Servers Core Platform Software China Telephone +86 23 
> > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > > Sent: Monday, March 31, 2014 5:22 PM
> > > > To: Eli Mesika; Roy Golan
> > > > Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason 
> > > > Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; 
> > > > Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv 
> > > > Dary; engine-devel at ovirt.org
> > > > Subject: Re: Please help us to review our database schema design 
> > > > with NUMA feature on ovirt
> > > > 
> > > > +1
> > > > 
> > > > IMO: vds data should reside in static VM need to think about it.
> > > > 
> > > > Roy?
> > > > 
> > > > Thanks,
> > > > Gilad.
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > <xiao-lei.shi at hp.com>
> > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, 
> > > > > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > <chegu_vinod at hp.com>,
> > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" 
> > > > > <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > Sent: Monday, March 31, 2014 12:12:50 PM
> > > > > Subject: Re: Please help us to review our database schema 
> > > > > design with NUMA feature on ovirt
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > <xiao-lei.shi at hp.com>
> > > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > <chuan.liao at hp.com>,
> > > > > > "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > <chegu_vinod at hp.com>,
> > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" 
> > > > > > <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > > Sent: Monday, March 31, 2014 8:56:20 AM
> > > > > > Subject: RE: Please help us to review our database schema 
> > > > > > design with NUMA feature on ovirt
> > > > > > 
> > > > > > Include the devel group.
> > > > > > Thanks Eli for the quick responses for our first design and 
> > > > > > sorry for the nag.
> > > > > > We appreciate any of the comments for our database design 
> > > > > > and will follow the design to do the implementation if no 
> > > > > > more comments.
> > > > > >  
> > > > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > 
> > > > > Seems OK for me except an unanswered question I had asked in 
> > > > > my first review
> > > > > :
> > > > > 
> > > > > Why in the Host level NUMA fields are added to vds_dynamic 
> > > > > while in the VM level it is added to vm_static ???
> > > > > I would expect it to be in both on static or dynamic , can you 
> > > > > please explain ? Thanks
> > > > > 
> > > > > > 
> > > > > > Thanks & Best Regards
> > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > 
> > > > > > Hewlett-Packard Co., Ltd.
> > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > Sent: Friday, March 28, 2014 1:30 PM
> > > > > > To: 'Eli Mesika'
> > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron 
> > > > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun 
> > > > > > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > Subject: RE: Please help us to review our database schema 
> > > > > > design with NUMA feature on ovirt
> > > > > > 
> > > > > > Hi Eli,
> > > > > > 
> > > > > > After the UX design meeting, we did some modification for 
> > > > > > the database schema, and merged some update according to 
> > > > > > your last review comments.
> > > > > > Now the document has been posted on ovirt wikipage, could 
> > > > > > you help to review the database design again:
> > > > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > > 
> > > > > > 
> > > > > > Thanks & Best Regards
> > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > 
> > > > > > Hewlett-Packard Co., Ltd.
> > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > 65683093 Mobile
> > > > > > +86
> > > > > > 18696583447 Email xiao-lei.shi at hp.com
> > > > > > 
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > Sent: Monday, March 24, 2014 6:24 PM
> > > > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron 
> > > > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun 
> > > > > > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > Subject: Re: Please help us to review our database schema 
> > > > > > design with NUMA feature on ovirt
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason 
> > > > > > > Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, 
> > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > <shangchun.liang at hp.com>
> > > > > > > Sent: Monday, March 24, 2014 11:23:39 AM
> > > > > > > Subject: RE: Please help us to review our database schema 
> > > > > > > design with NUMA feature on ovirt
> > > > > > > 
> > > > > > > Hi Eli,
> > > > > > > 
> > > > > > > Thanks for your comments.
> > > > > > > I have updated the document according to your comments 
> > > > > > > except the below
> > > > > > > one:
> > > > > > > Missing from here are 2 issues:
> > > > > > > 
> > > > > > > 1) Impact on the search engine, which new columns are 
> > > > > > > search-able and which changes are planned in the search 
> > > > > > > engine code to enable that
> > > > > > > 
> > > > > > > 2) Impact on engine-reports, are those changed planned to 
> > > > > > > be exposed to the engine data warehouse and required 
> > > > > > > new/modified reports?
> > > > > > > 
> > > > > > > Could you tell us more detailed information about the 
> > > > > > > modules you mentioned above? I mean "search engine" and 
> > > > > > > "engine-reports". I think we missed these two parts in our 
> > > > > > > previous investigation.
> > > > > > > I just find org.ovirt.engine.core.bll.SearchQuery, is that 
> > > > > > > the right object for search engine?
> > > > > > 
> > > > > > Yes, actually when you are opening the admin UI, there are 
> > > > > > TABs for each entity , i.e. Data Center, Cluster, Host etc.
> > > > > > In each, you can see a text-box in which you can search for 
> > > > > > by writing a search expression My question is
> > > > > >    1) What is the impact of your work on the search on the Fost and
> > > > > >    VM
> > > > > >    TABs
> > > > > >       a) Are there any fields that are supported now in the search
> > > > > >       expression
> > > > > >       and should pop-up when you write the expression by the
> > > > > >       auto-completion
> > > > > >       mechanism ?
> > > > > >       b) Are there any added columns displayed in the result of
> > > > > >       such
> > > > > >       a
> > > > > >       search
> > > > > >       in the grid ?
> > > > > > 
> > > > > > > How about the engine-reports, could you give us some 
> > > > > > > hints, like the code location and any more detailed 
> > > > > > > information that we can start more investigation?
> > > > > > 
> > > > > > CCing Yaniv D who is in charge of the reports/dwh module 
> > > > > > Yaniv, any planned work for adding Numa features to Host/VM 
> > > > > > in the reports side ?
> > > > > > 
> > > > > > Thanks
> > > > > > 
> > > > > > > 
> > > > > > > Thanks & Best Regards
> > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > 
> > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > > Sent: Sunday, March 23, 2014 4:44 PM
> > > > > > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > > > > > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, 
> > > > > > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi, 
> > > > > > > Xiao-Lei (Bruce, HP
> > > > > > > Servers-PSC-CQ)
> > > > > > > Subject: Re: Please help us to review our database schema 
> > > > > > > design with NUMA feature on ovirt
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > > <chuan.liao at hp.com>
> > > > > > > > To: emesika at redhat.com
> > > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > > <gchaplik at redhat.com>, "Chegu Vinod" 
> > > > > > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP 
> > > > > > > > Servers-PSC-CQ)"
> > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > > > > > > Subject: Please help us to review our database schema 
> > > > > > > > design with NUMA feature on ovirt
> > > > > > > > 
> > > > > > > > Hi Eli,
> > > > > > > > 
> > > > > > > > Please help us to review our database schema design with 
> > > > > > > > NUMA feature on ovirt 
> > > > > > > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcm
> > > > > > > > bGWA
> > > > > > > > cyQo_IST
> > > > > > > > Y8
> > > > > > > > ykDr0I6VY/edit?usp=sharing
> > > > > > > > 
> > > > > > > > Feel free to take comments on document at anywhere
> > > > > > > 
> > > > > > > Done, had commented on the document.
> > > > > > > Eli
> > > > > > > 
> > > > > > > > 
> > > > > > > > Especially, 5.4 The used interface between engine core 
> > > > > > > > and
> > > > > > > > database(schema)
> > > > > > > > 
> > > > > > > > Your approve and your comments with this section will be 
> > > > > > > > much more appreciate for us.
> > > > > > > > 
> > > > > > > > Best Regards,
> > > > > > > > Jason Liao
> > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
>

From chuan.liao at hp.com  Thu Apr  3 05:43:34 2014
From: chuan.liao at hp.com (Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC))
Date: Thu, 3 Apr 2014 05:43:34 +0000
Subject: [Engine-devel] NUMA feature for oVirt Scheduling interface
Message-ID: <B63C858E777679458338A30A991BB524015FF436@G2W2441.americas.hpqcorp.net>

Hi Gilad,

I have update the wiki page
http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA#Interface_and_data_structure_in_ovirt_scheduler

The ovirt scheduler section.

We are appreciate that you or some community members could give us some feedback and comments, and sorry for the nag.

Best Regards,
Jason Liao

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140403/c4dd5106/attachment.html>

From emesika at redhat.com  Thu Apr  3 07:54:54 2014
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 3 Apr 2014 03:54:54 -0400 (EDT)
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <08AA403C8399104A89AF710307FA78AE243DD55D@G5W2743.americas.hpqcorp.net>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<1087291412.5091657.1396259332718.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD16D@G5W2743.americas.hpqcorp.net>
	<1690885238.11367.1396272677929.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD232@G5W2743.americas.hpqcorp.net>
	<434209250.5741543.1396336237695.JavaMail.zimbra@redhat.com>
	<509028518.3947921.1396487095509.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD55D@G5W2743.americas.hpqcorp.net>
Message-ID: <134006885.6976322.1396511694070.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika" <emesika at redhat.com>
> Cc: "Roy Golan" <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Chuan
> Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Shang-Chun
> Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> engine-devel at ovirt.org
> Sent: Thursday, April 3, 2014 7:25:11 AM
> Subject: RE: Please help us to review our database schema design with NUMA feature on ovirt
> 
> Hi all,
> Please see my comments in line.
> 
> Thanks & Best Regards
> Shi, Xiao-Lei (Bruce)
> 
> Hewlett-Packard Co., Ltd.
> HP Servers Core Platform Software China
> Telephone +86 23 65683093
> Mobile +86 18696583447
> Email xiao-lei.shi at hp.com
> 
> -----Original Message-----
> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> Sent: Thursday, April 03, 2014 9:05 AM
> To: Eli Mesika
> Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Roy Golan; Omer Frenkel; Vinod,
> Chegu; Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck;
> Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> engine-devel at ovirt.org
> Subject: Re: Please help us to review our database schema design with NUMA
> feature on ovirt
> 
> Hi all,
> Sorry for joining-in late.
> 
> My comments (according to the db diagram section in
> https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_ISTY8ykDr0I6VY):
> 1) Join vm_numa_node and vds_numa_node to a single table (almost identical),
> one of the FKs can be null.
> [Bruce] I prefer two tables. Actually host level NUMA node and vm level NUMA
> node are different objects. In my understanding, vm level NUMA node is just
> a simulation of host level NUMA node, and host level NUMA node has more
> features that not in vm NUMA (like several levels of host NUMA topology
> mentioned by Vinod). We need to consider the extensions of host NUMA in the
> future.

I agree with Bruce, we have no problem with more tables and constrains should work as expected and remove entries when a Host or VM is removed.
I do not like tables that have 2 UUIDs when one of them is null , this is against simple DB normalization 

>    
> 2) No templates reference in the design, need to check it out (it might be
> inherently designed already :-) ); vNode can be linked to a template.
> [Bruce] IMO, we can consider template as a special vm, our current design
> supports to create vNodes in a template just like what it does in a vm.

We also store today templates in the VM* tables as special entities defined by the entity_type column

> 
> 3) The reason I want host's NUMA data to be in static is because it updates
> only once (on boot). "engineerically" speaking, dynamic table has a lot of
> traffic and that's not the case for NUMA info. Its feels to me like 'a
> hybrid' of static and dynamic, 3 suggestions comes to mind:
>  - leave it in dynamic (maybe in a separate process).
>  - have a separate flow that updates static.
>  - come up with a third 'vds_on_boot' table (my favorite ;-P ).
> I will get back to you on that.
> [Bruce] From the onTimer codes in vdsManager (IMO it's the scheduled vds
> refresh action), when vds is in normal running status (up status), only
> statistics data will be refreshed, so I think maybe dynamic table doesn't
> have so much traffic, and the varied data (I mean the data varied through a
> power reload, like cpu topology, numa topology, ...etc) can be refreshed
> meanwhile.
> 
> 4) vm_vds_numa_node_map is connected to vds_numa_node_statistics, why to
> split the tables (vds_numa_node & vds_numa_node_statistics), going back to
> comment #1, don't we want vNode stats as well, it can be nice to show it :-)
> (have a vNUMA overview of the VM using guest-agent or sth, in a future
> phase).
> [Bruce] Split the tables is referring to vds_interface
> (vds_interface_statistics) and vm_interface (vm_interface_statistics), the
> statistics table will be refreshed with a high frequency.
> I will update the design to add the vNuma statistics for the future phase,
> and according to my feedback in comment #1, vNuma statistics will also in an
> independent table since I think there will be more statistics fields for
> host NUMA than for vNuma.

Agree with Bruce

> 
> 5) IMO vds_cpu_statistics shouldn't include any reference to NUMA, I gave
> that comment in the BE patch as well (remove vds_numa_node_id FK in
> vds_cpu_statistics), for that you should extract cpu_list to a connection
> table (anyway I don't like lists as a text/strings/etc.)
> [Bruce] Yes, I agree with you to remove the reference between
> vds_cpu_statistics and NUMA. Actually cpu_list is enough for current
> requirements. I think the connection table is needed when we consider to
> collect more cpu related information and do more cpu related actions in the
> future.
> 
> 6) vm_numatune_nodeset can be removed - the vNode should hold it's pinning
> info; I think that vNode (node according to comment #1) should be connected
> to a connection table that points to vdsNode (also Node table) itself (kinda
> complicated but does the trick - nested link).
> [Bruce] Yes, I will remove vm_numatune_nodeset, but according to my feedback
> in comment #1, vm_vds_numa_node_map table will be retained to hold the
> references between host nodes and vNode, since they are "m:n" relations.
> 
> 7) Please add delete-cascade info all over, i.e. what happens when we remove
> a host/vm/node.
> [Bruce] Yes, I will update the design.
> 
> 8) Is it possible to put a db constraint that mapping between vNode and Node
> will be deleted once the VM isn't UP?
> [Bruce] I have a question here. IMO, the mapping between vNode and Node is a
> user configuration, why it is related with the vm status? If the mapping is
> deleted, that means the user configuration is deleted. I don't think it's
> reasonable.
> 
> Thanks,
> Gilad.
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>, "Chegu
> > Vinod" <chegu_vinod at hp.com>, "Chuan Liao (Jason Liao,
> > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck"
> > <dfediuck at redhat.com>, "Shang-Chun Liang (David Liang,
> > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > <ydary at redhat.com>, engine-devel at ovirt.org
> > Sent: Tuesday, April 1, 2014 10:10:37 AM
> > Subject: Re: Please help us to review our database schema design with
> > NUMA feature on ovirt
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > <xiao-lei.shi at hp.com>
> > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > > <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>, "Eli
> > > Mesika" <emesika at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>
> > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
> > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > > engine-devel at ovirt.org
> > > Sent: Tuesday, April 1, 2014 5:13:34 AM
> > > Subject: RE: Please help us to review our database schema design
> > > with NUMA feature on ovirt
> > > 
> > > Assemble the related discussions in this mail session.
> > > 
> > > Hi Vinod,
> > > On 3/31/2014 2:38 AM, Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) wrote:
> > > > We put host level NUMA fields in vds_dynamic because these
> > > > information are from host itself, and NUMA topology may be changed
> > > > if the host's hardware make a change.
> > > Can you please elaborate ? Are you thinking about resource (cpu
> > > and/or
> > > memory) hot plug on the host ?
> > > [Bruce] It's not about resource hot plug. In ovirt engine, there is
> > > a scheduled task which will refresh hosts' and vms' information
> > > periodically.
> > > Only the dynamic and statistics data will be updated during the
> > > refresh. So I think the resource information, such as cpu and/or
> > > memory, should be in dynamic and statistics. And in my
> > > understanding, the information in dynamic class is the changeable
> > > information but with a low varying frequency, like cpu topology,
> > > libvirt/kernel versions, etc. The information in statistics class is
> > > the information with a high varying frequency, like the usage of
> > > cpu/memory, etc. In my opinion, it's reasonable to put host level
> > > NUMA information in vds_dynamic and host level NUMA statistics
> > > information in vds_statistics.
> > > 
> > > Hi Gilad/Roy/Omer,
> > > I don't know if my understanding is correct. But according to this
> > > guess, I think it's also reasonable to put vm cpuPin information in
> > > vm_static.
> > > Because cpuPin is user configured information, it will not vary
> > > automatically. So we don?t need to refresh this information periodically.
> > > Please correct me if there are any mistakes.
> > > 
> > > Hi Eli,
> > > Sorry for the nag. If my understanding above is correct, I think we
> > > should still put host level NUMA fields in
> > > vds_dynamic/vds_statistics and vm level NUMA fields in vm_static.
> > > Since vm level NUMA fields are configured by user and they will not vary
> > > automatically.
> > 
> > Sorry, I had understood from Gilad that the NUMA fields in the host
> > level are relatively static and the NUMA fields on the VM level are
> > dynamic.
> > I have no problem of having hybrid static/dynamic fields for Host/VM
> > as long as it has a good reason and fully documented :-)
> > 
> > 
> > > 
> > > 
> > > Thanks & Best Regards
> > > Shi, Xiao-Lei (Bruce)
> > > 
> > > Hewlett-Packard Co., Ltd.
> > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > 
> > > 
> > > -----Original Message-----
> > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > Sent: Monday, March 31, 2014 9:31 PM
> > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Roy Golan; Omer
> > > Frenkel
> > > Cc: Eli Mesika; Roy Golan; Liao, Chuan (Jason Liao,
> > > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang,
> > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > > engine-devel at ovirt.org
> > > Subject: Re: Please help us to review our database schema design
> > > with NUMA feature on ovirt
> > > 
> > > adding Roy & Omer.
> > > 
> > > why CPU topology is in dynamic?
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > ----- Original Message -----
> > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > <xiao-lei.shi at hp.com>
> > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > > > <rgolan at redhat.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu
> > > > Vinod"
> > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > Sent: Monday, March 31, 2014 3:20:33 PM
> > > > Subject: RE: Please help us to review our database schema design
> > > > with NUMA feature on ovirt
> > > > 
> > > > Thanks Eli.
> > > > I will move the vm level NUMA fields to vm_dynamic, and the
> > > > related database schema will be updated accordingly.
> > > > 
> > > > Thanks & Best Regards
> > > > Shi, Xiao-Lei (Bruce)
> > > > 
> > > > Hewlett-Packard Co., Ltd.
> > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > 
> > > > -----Original Message-----
> > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > Sent: Monday, March 31, 2014 5:49 PM
> > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao,
> > > > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang,
> > > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > > > engine-devel at ovirt.org
> > > > Subject: Re: Please help us to review our database schema design
> > > > with NUMA feature on ovirt
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > <xiao-lei.shi at hp.com>
> > > > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
> > > > > <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>
> > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
> > > > > "Chegu Vinod"
> > > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > > > HPservers-Core-OE-PSC)"
> > > > > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > > > > engine-devel at ovirt.org
> > > > > Sent: Monday, March 31, 2014 12:38:04 PM
> > > > > Subject: RE: Please help us to review our database schema design
> > > > > with NUMA feature on ovirt
> > > > > 
> > > > > We put host level NUMA fields in vds_dynamic because these
> > > > > information are from host itself, and NUMA topology may be
> > > > > changed if the host's hardware make a change. NUMA information
> > > > > are similar to the host's cpu topology information like
> > > > > cpu_cores and cpu_sockets which are in vds_dynamic, we refer to this.
> > > > > VM level NUMA fields are configured by user, and actually we
> > > > > originally think they should be in vm_dynamic. But we found that
> > > > > the field of another feature cpuPin which is similar as NUMA
> > > > > feature is in vm_static, so we put vm NUMA fields in vm_static.
> > > > > Do you think we need to put VM level NUMA fields in vm_dynamic?
> > > > 
> > > > I think that in this case we should fix cpuPin to be in vm_dynamic
> > > > and put after that the other NUMA fields in vm_dynamic as well
> > > > 
> > > > > 
> > > > > Thanks & Best Regards
> > > > > Shi, Xiao-Lei (Bruce)
> > > > > 
> > > > > Hewlett-Packard Co., Ltd.
> > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > > > Sent: Monday, March 31, 2014 5:22 PM
> > > > > To: Eli Mesika; Roy Golan
> > > > > Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason
> > > > > Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu;
> > > > > Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv
> > > > > Dary; engine-devel at ovirt.org
> > > > > Subject: Re: Please help us to review our database schema design
> > > > > with NUMA feature on ovirt
> > > > > 
> > > > > +1
> > > > > 
> > > > > IMO: vds data should reside in static VM need to think about it.
> > > > > 
> > > > > Roy?
> > > > > 
> > > > > Thanks,
> > > > > Gilad.
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > <xiao-lei.shi at hp.com>
> > > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
> > > > > > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > <chegu_vinod at hp.com>,
> > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > > Sent: Monday, March 31, 2014 12:12:50 PM
> > > > > > Subject: Re: Please help us to review our database schema
> > > > > > design with NUMA feature on ovirt
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > <chuan.liao at hp.com>,
> > > > > > > "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > > <chegu_vinod at hp.com>,
> > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > > > Sent: Monday, March 31, 2014 8:56:20 AM
> > > > > > > Subject: RE: Please help us to review our database schema
> > > > > > > design with NUMA feature on ovirt
> > > > > > > 
> > > > > > > Include the devel group.
> > > > > > > Thanks Eli for the quick responses for our first design and
> > > > > > > sorry for the nag.
> > > > > > > We appreciate any of the comments for our database design
> > > > > > > and will follow the design to do the implementation if no
> > > > > > > more comments.
> > > > > > >  
> > > > > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > > 
> > > > > > Seems OK for me except an unanswered question I had asked in
> > > > > > my first review
> > > > > > :
> > > > > > 
> > > > > > Why in the Host level NUMA fields are added to vds_dynamic
> > > > > > while in the VM level it is added to vm_static ???
> > > > > > I would expect it to be in both on static or dynamic , can you
> > > > > > please explain ? Thanks
> > > > > > 
> > > > > > > 
> > > > > > > Thanks & Best Regards
> > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > 
> > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > > Sent: Friday, March 28, 2014 1:30 PM
> > > > > > > To: 'Eli Mesika'
> > > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
> > > > > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun
> > > > > > > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > > Subject: RE: Please help us to review our database schema
> > > > > > > design with NUMA feature on ovirt
> > > > > > > 
> > > > > > > Hi Eli,
> > > > > > > 
> > > > > > > After the UX design meeting, we did some modification for
> > > > > > > the database schema, and merged some update according to
> > > > > > > your last review comments.
> > > > > > > Now the document has been posted on ovirt wikipage, could
> > > > > > > you help to review the database design again:
> > > > > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > > > 
> > > > > > > 
> > > > > > > Thanks & Best Regards
> > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > 
> > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > 65683093 Mobile
> > > > > > > +86
> > > > > > > 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > 
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > > Sent: Monday, March 24, 2014 6:24 PM
> > > > > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
> > > > > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun
> > > > > > > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > > Subject: Re: Please help us to review our database schema
> > > > > > > design with NUMA feature on ovirt
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason
> > > > > > > > Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > > <shangchun.liang at hp.com>
> > > > > > > > Sent: Monday, March 24, 2014 11:23:39 AM
> > > > > > > > Subject: RE: Please help us to review our database schema
> > > > > > > > design with NUMA feature on ovirt
> > > > > > > > 
> > > > > > > > Hi Eli,
> > > > > > > > 
> > > > > > > > Thanks for your comments.
> > > > > > > > I have updated the document according to your comments
> > > > > > > > except the below
> > > > > > > > one:
> > > > > > > > Missing from here are 2 issues:
> > > > > > > > 
> > > > > > > > 1) Impact on the search engine, which new columns are
> > > > > > > > search-able and which changes are planned in the search
> > > > > > > > engine code to enable that
> > > > > > > > 
> > > > > > > > 2) Impact on engine-reports, are those changed planned to
> > > > > > > > be exposed to the engine data warehouse and required
> > > > > > > > new/modified reports?
> > > > > > > > 
> > > > > > > > Could you tell us more detailed information about the
> > > > > > > > modules you mentioned above? I mean "search engine" and
> > > > > > > > "engine-reports". I think we missed these two parts in our
> > > > > > > > previous investigation.
> > > > > > > > I just find org.ovirt.engine.core.bll.SearchQuery, is that
> > > > > > > > the right object for search engine?
> > > > > > > 
> > > > > > > Yes, actually when you are opening the admin UI, there are
> > > > > > > TABs for each entity , i.e. Data Center, Cluster, Host etc.
> > > > > > > In each, you can see a text-box in which you can search for
> > > > > > > by writing a search expression My question is
> > > > > > >    1) What is the impact of your work on the search on the Fost
> > > > > > >    and
> > > > > > >    VM
> > > > > > >    TABs
> > > > > > >       a) Are there any fields that are supported now in the
> > > > > > >       search
> > > > > > >       expression
> > > > > > >       and should pop-up when you write the expression by the
> > > > > > >       auto-completion
> > > > > > >       mechanism ?
> > > > > > >       b) Are there any added columns displayed in the result of
> > > > > > >       such
> > > > > > >       a
> > > > > > >       search
> > > > > > >       in the grid ?
> > > > > > > 
> > > > > > > > How about the engine-reports, could you give us some
> > > > > > > > hints, like the code location and any more detailed
> > > > > > > > information that we can start more investigation?
> > > > > > > 
> > > > > > > CCing Yaniv D who is in charge of the reports/dwh module
> > > > > > > Yaniv, any planned work for adding Numa features to Host/VM
> > > > > > > in the reports side ?
> > > > > > > 
> > > > > > > Thanks
> > > > > > > 
> > > > > > > > 
> > > > > > > > Thanks & Best Regards
> > > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > > 
> > > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > > > Sent: Sunday, March 23, 2014 4:44 PM
> > > > > > > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > > > > > > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang,
> > > > > > > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi,
> > > > > > > > Xiao-Lei (Bruce, HP
> > > > > > > > Servers-PSC-CQ)
> > > > > > > > Subject: Re: Please help us to review our database schema
> > > > > > > > design with NUMA feature on ovirt
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > > > <chuan.liao at hp.com>
> > > > > > > > > To: emesika at redhat.com
> > > > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > > > <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > > > > > > > HPservers-Core-OE-PSC)"
> > > > > > > > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP
> > > > > > > > > Servers-PSC-CQ)"
> > > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > > > > > > > Subject: Please help us to review our database schema
> > > > > > > > > design with NUMA feature on ovirt
> > > > > > > > > 
> > > > > > > > > Hi Eli,
> > > > > > > > > 
> > > > > > > > > Please help us to review our database schema design with
> > > > > > > > > NUMA feature on ovirt
> > > > > > > > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcm
> > > > > > > > > bGWA
> > > > > > > > > cyQo_IST
> > > > > > > > > Y8
> > > > > > > > > ykDr0I6VY/edit?usp=sharing
> > > > > > > > > 
> > > > > > > > > Feel free to take comments on document at anywhere
> > > > > > > > 
> > > > > > > > Done, had commented on the document.
> > > > > > > > Eli
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Especially, 5.4 The used interface between engine core
> > > > > > > > > and
> > > > > > > > > database(schema)
> > > > > > > > > 
> > > > > > > > > Your approve and your comments with this section will be
> > > > > > > > > much more appreciate for us.
> > > > > > > > > 
> > > > > > > > > Best Regards,
> > > > > > > > > Jason Liao
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> >
> 


From lpeer at redhat.com  Thu Apr  3 08:20:58 2014
From: lpeer at redhat.com (Livnat Peer)
Date: Thu, 03 Apr 2014 11:20:58 +0300
Subject: [Engine-devel] Change in ovirt-engine[master]: core: enable to
 decrease DC compatibility...
In-Reply-To: <1979276837.3855424.1396418781688.JavaMail.zimbra@redhat.com>
References: <gerrit.1392716300399.I73284f641b7f80b380b39efbbd7b4566f55119b6@gerrit.ovirt.org>	<577568761.2861329.1394657047677.JavaMail.zimbra@redhat.com>	<1789679933.641640.1395343205633.JavaMail.zimbra@redhat.com>	<532BDD57.1090604@redhat.com>	<1810385690.186069.1395569606128.JavaMail.zimbra@redhat.com>	<532EB40D.5050202@redhat.com>	<1761608621.98742.1395578873460.JavaMail.zimbra@redhat.com>	<756890458.3439238.1395920602583.JavaMail.zimbra@redhat.com>
	<1979276837.3855424.1396418781688.JavaMail.zimbra@redhat.com>
Message-ID: <533D19EA.9070405@redhat.com>

On 04/02/2014 09:06 AM, Moti Asayag wrote:
> 
> 
> ----- Original Message -----
>> From: "Eli Mesika" <emesika at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Thursday, March 27, 2014 1:43:22 PM
>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
>>
>>
>>
>> ----- Original Message -----
>>> From: "Moti Asayag" <masayag at redhat.com>
>>> To: "Itamar Heim" <iheim at redhat.com>
>>> Cc: "Eli Mesika" <emesika at redhat.com>, engine-devel at ovirt.org
>>> Sent: Sunday, March 23, 2014 2:47:53 PM
>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to
>>> decrease DC compatibility...
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>> To: "Eli Mesika" <emesika at redhat.com>, engine-devel at ovirt.org
>>>> Sent: Sunday, March 23, 2014 12:14:37 PM
>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
>>>> to
>>>> decrease DC compatibility...
>>>>
>>>> On 03/23/2014 12:13 PM, Eli Mesika wrote:
>>>>>
>>>>> So, as far a I understand for resolving this bug the following is OK :
>>>>>
>>>>> Block downgrading if there are Hosts or Networks (other than the
>>>>> default
>>>>> management network) or SD in the DC when downgrading.
>>>>
>>>> yes
>>>>
>>>
>>> I don't think it is enough. There is a need to verify the management
>>> network
>>> wasn't modified to use unsupported features in the new data-center.
>>>
>>> On the same matter, we can allow downgrading if all of the networks in the
>>> data center are using only features that are supported on the target DC
>>> version
>>> and not to restrict it only to the management network.
>>
>> Since Moti is in PTO, talked with Mike K to get advanced with that , we came
>> to the following conclusion:
>>
>> when DC is downgraded :
>>  Block downgrading if there are Hosts or Networks (other than the default
>>  management network) or SD in the DC.
>>  In case that only default management network exists we should check that all
>>  network features are still supported (This can be done by adding a method
>>  to the NetworkValidator that will check for support of all relevant
>>  features)
>>
>> when Cluster is downgraded :
>>  Same as above , but we don't need to check for features validation since we
>>  can not downgrade below the DC version and therefor the cluster network is
>>  supposed to be valid already
>>
>> Mike, please let me know If I miss something from our discussion (and thanks
>> for your kind help :-) )
> 
> +1 from me and Mike for the above.
> 

Eli -
please note there is no need to block the DC downgrade if there are
hosts in the DC.

Thanks, Livnat


>>
>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>>>> To: "Moti Asayag" <masayag at redhat.com>
>>>>>> Cc: engine-devel at ovirt.org
>>>>>> Sent: Friday, March 21, 2014 8:33:59 AM
>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
>>>>>> enable
>>>>>> to decrease DC compatibility...
>>>>>>
>>>>>> On 03/20/2014 09:20 PM, Moti Asayag wrote:
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Moti Asayag" <masayag at redhat.com>
>>>>>>>> To: "Livnat Peer" <lpeer at redhat.com>
>>>>>>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
>>>>>>>> Sent: Wednesday, March 12, 2014 10:44:07 PM
>>>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
>>>>>>>> enable
>>>>>>>> to decrease DC compatibility...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>>>>>>> To: "Moti Asayag" <masayag at redhat.com>
>>>>>>>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
>>>>>>>>> Sent: Wednesday, March 12, 2014 10:33:45 PM
>>>>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
>>>>>>>>> enable
>>>>>>>>> to
>>>>>>>>> decrease DC compatibility...
>>>>>>>>>
>>>>>>>>> On 03/12/2014 10:20 PM, Moti Asayag wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>>>>>>>>> To: "Itamar Heim" <iheim at redhat.com>, engine-devel at ovirt.org
>>>>>>>>>>> Sent: Wednesday, March 12, 2014 12:42:44 PM
>>>>>>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
>>>>>>>>>>> enable
>>>>>>>>>>> to	decrease DC compatibility...
>>>>>>>>>>>
>>>>>>>>>>> On 03/12/2014 11:59 AM, Itamar Heim wrote:
>>>>>>>>>>>> On 03/12/2014 12:26 AM, emesika at redhat.com wrote:
>>>>>>>>>>>>> Eli Mesika has submitted this change and it was merged.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Change subject: core: enable to decrease DC compatibility...
>>>>>>>>>>>>> ......................................................................
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> core: enable to decrease DC compatibility...
>>>>>>>>>>>>>
>>>>>>>>>>>>> enable to decrease DC compatibility version if DC has no
>>>>>>>>>>>>> clusters
>>>>>>>>>>>>>
>>>>>>>>>>>>> This patch enables to decrease the DC compatibility version if
>>>>>>>>>>>>> DC
>>>>>>>>>>>>> has
>>>>>>>>>>>>> no
>>>>>>>>>>>>> clusters.
>>>>>>>>>>>>
>>>>>>>>>>>> Eli - just saw this. I'm pretty sure it would be *bad* to
>>>>>>>>>>>> downgrade
>>>>>>>>>>>> a
>>>>>>>>>>>> DC
>>>>>>>>>>>> version if it has storage domains as well. not sure if this is
>>>>>>>>>>>> checked
>>>>>>>>>>>> already or not.
>>>>>>>>>>>>
>>>>>>>>>>>> may also be an issue with some logical network features.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Most of the network features are driven from cluster level, we
>>>>>>>>>>> enable
>>>>>>>>>>> using the features on all DC level (actually >=3.1) but actually
>>>>>>>>>>> enable
>>>>>>>>>>> /disable the feature when attaching the network to a cluster.
>>>>>>>>>>>
>>>>>>>>>>> So from network perspective I think it should be fine to
>>>>>>>>>>> downgrade
>>>>>>>>>>> the
>>>>>>>>>>> DC level even if there are networks in the DC (at least now this
>>>>>>>>>>> could
>>>>>>>>>>> change in future versions).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Actually we block adding or updating networks if the feature is
>>>>>>>>>> not
>>>>>>>>>> supported
>>>>>>>>>> on the network's DC level, for example: STP, Jumbo frames and
>>>>>>>>>> non-vm
>>>>>>>>>> network.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  From which DC level we support STP?  Jumbo frames? non-vm network?
>>>>>>>>>  isn't
>>>>>>>>> all of them supported in >=3.1 ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, mainly the problem with downgrading a DC to 3.0.
>>>>>>>>
>>>>>>>
>>>>>>> I had a discussion with Mike (cc'ed) about several possible solutions
>>>>>>> for the networks compatibility within the data-center.
>>>>>>>
>>>>>>> The first proposed solution would utilize the NetworkUpdateValidator,
>>>>>>> a validation utility that verifies the compatibility of a network
>>>>>>> to the data-center. This solution preserves the same behaviour as
>>>>>>> today,
>>>>>>> that the features of network-level are dictated by the DC version. No
>>>>>>> need to reimplement any logic in the decrease DC version flow, just
>>>>>>> use
>>>>>>> an existing one to be applied for any network within the DC.
>>>>>>>
>>>>>>> The second solution suggests we allow any settings of a network, and
>>>>>>> compatibility enforcement is done on attaching the network to the
>>>>>>> clusters.
>>>>>>> This modifies the existing behaviour and expands the capabilities of
>>>>>>> the
>>>>>>> engine to support advanced network feature in advanced cluster within
>>>>>>> an
>>>>>>> old data center (i.e. cluster 3.4 in 3.0 data-center could and
>>>>>>> probably
>>>>>>> should use non-vm network, jumbo-frames and more).
>>>>>>> This option requires more work in add/update network and attach
>>>>>>> network
>>>>>>> to
>>>>>>> cluster
>>>>>>> flows, both on the backend and UI. Specifically since by default a
>>>>>>> new
>>>>>>> network
>>>>>>> created in a DC is being attached to all of the clusters.
>>>>>>> Perhaps the second option deserves to be treated as RFE and not as a
>>>>>>> bug
>>>>>>> fix.
>>>>>>>
>>>>>>> Thoughts ?
>>>>>>>
>>>>>>
>>>>>> The second approach you suggested is equivalent to creating networks
>>>>>> in
>>>>>> cluster level vs. DC level, which is used today.
>>>>>>
>>>>>> We should consider that for 4.0 and think on the pros and cons of
>>>>>> doing
>>>>>> so.
>>>>>>
>>>>>> In general for this specific discussion I think a simple block on DC
>>>>>> downgrade should be enough.
>>>>>>
>>>>>>> Moti
>>>>>>>
>>>>>>>>>> Therefore if the management network was configured with any of
>>>>>>>>>> those
>>>>>>>>>> feature,
>>>>>>>>>> there is a need to either block the action or to 'initialize' the
>>>>>>>>>> network
>>>>>>>>>> to
>>>>>>>>>> the default settings (as new network being added).
>>>>>>>>>>
>>>>>>>>>>> In general I believe the use case for this patch is mostly for
>>>>>>>>>>> empty
>>>>>>>>>>> DCs
>>>>>>>>>>> so for simplicity we should block it if there are networks or SD
>>>>>>>>>>> in
>>>>>>>>>>> the
>>>>>>>>>>> DC when downgrading.
>>>>>>>>>>>
>>>>>>>>>>> Livnat
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
>>>>>>>>>>>>> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
>>>>>>>>>>>>> Signed-off-by: Eli Mesika <emesika at redhat.com>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> M
>>>>>>>>>>>>> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Approvals:
>>>>>>>>>>>>>     Eli Mesika: Verified
>>>>>>>>>>>>>     Ravi Nori: Looks good to me, but someone else must approve
>>>>>>>>>>>>>     Yair Zaslavsky: Looks good to me, approved
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
> 
> 



From gchaplik at redhat.com  Thu Apr  3 10:46:32 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Thu, 3 Apr 2014 06:46:32 -0400 (EDT)
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <134006885.6976322.1396511694070.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<08AA403C8399104A89AF710307FA78AE243DD16D@G5W2743.americas.hpqcorp.net>
	<1690885238.11367.1396272677929.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD232@G5W2743.americas.hpqcorp.net>
	<434209250.5741543.1396336237695.JavaMail.zimbra@redhat.com>
	<509028518.3947921.1396487095509.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD55D@G5W2743.americas.hpqcorp.net>
	<134006885.6976322.1396511694070.JavaMail.zimbra@redhat.com>
Message-ID: <1922469868.4436271.1396521992628.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan" <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>,
> "Chegu Vinod" <chegu_vinod at hp.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron
> Fediuck" <dfediuck at redhat.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>,
> "Yaniv Dary" <ydary at redhat.com>, engine-devel at ovirt.org
> Sent: Thursday, April 3, 2014 10:54:54 AM
> Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt
> 
> 
> 
> ----- Original Message -----
> > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
> > <emesika at redhat.com>
> > Cc: "Roy Golan" <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>,
> > "Chegu Vinod" <chegu_vinod at hp.com>, "Chuan
> > Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron
> > Fediuck" <dfediuck at redhat.com>, "Shang-Chun
> > Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>,
> > "Yaniv Dary" <ydary at redhat.com>,
> > engine-devel at ovirt.org
> > Sent: Thursday, April 3, 2014 7:25:11 AM
> > Subject: RE: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > Hi all,
> > Please see my comments in line.
> > 
> > Thanks & Best Regards
> > Shi, Xiao-Lei (Bruce)
> > 
> > Hewlett-Packard Co., Ltd.
> > HP Servers Core Platform Software China
> > Telephone +86 23 65683093
> > Mobile +86 18696583447
> > Email xiao-lei.shi at hp.com
> > 
> > -----Original Message-----
> > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > Sent: Thursday, April 03, 2014 9:05 AM
> > To: Eli Mesika
> > Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Roy Golan; Omer Frenkel;
> > Vinod,
> > Chegu; Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck;
> > Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > engine-devel at ovirt.org
> > Subject: Re: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > Hi all,
> > Sorry for joining-in late.
> > 
> > My comments (according to the db diagram section in
> > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_ISTY8ykDr0I6VY):
> > 1) Join vm_numa_node and vds_numa_node to a single table (almost
> > identical),
> > one of the FKs can be null.
> > [Bruce] I prefer two tables. Actually host level NUMA node and vm level
> > NUMA
> > node are different objects. In my understanding, vm level NUMA node is just
> > a simulation of host level NUMA node, and host level NUMA node has more
> > features that not in vm NUMA (like several levels of host NUMA topology
> > mentioned by Vinod). We need to consider the extensions of host NUMA in the
> > future.

Let's open the discussion and consider them right now. vNode and Node are the same.
Vinod?

> 
> I agree with Bruce, we have no problem with more tables and constrains should
> work as expected and remove entries when a Host or VM is removed.
> I do not like tables that have 2 UUIDs when one of them is null , this is
> against simple DB normalization
> 

We are going to maintain and develop this feature. there is a huge overhead in 6 table design in compare to 4.

> >    
> > 2) No templates reference in the design, need to check it out (it might be
> > inherently designed already :-) ); vNode can be linked to a template.
> > [Bruce] IMO, we can consider template as a special vm, our current design
> > supports to create vNodes in a template just like what it does in a vm.
> 
> We also store today templates in the VM* tables as special entities defined
> by the entity_type column

+1, just need to see that this is taken care of.

> 
> > 
> > 3) The reason I want host's NUMA data to be in static is because it updates
> > only once (on boot). "engineerically" speaking, dynamic table has a lot of
> > traffic and that's not the case for NUMA info. Its feels to me like 'a
> > hybrid' of static and dynamic, 3 suggestions comes to mind:
> >  - leave it in dynamic (maybe in a separate process).
> >  - have a separate flow that updates static.
> >  - come up with a third 'vds_on_boot' table (my favorite ;-P ).
> > I will get back to you on that.
> > [Bruce] From the onTimer codes in vdsManager (IMO it's the scheduled vds
> > refresh action), when vds is in normal running status (up status), only
> > statistics data will be refreshed, so I think maybe dynamic table doesn't
> > have so much traffic, and the varied data (I mean the data varied through a
> > power reload, like cpu topology, numa topology, ...etc) can be refreshed
> > meanwhile.
> > 

I beg to differ, dynamic table contains a lot of dynamic data:
host status, used memory and pending resources (maybe more).
still need to think about it, and get back to you.

> > 4) vm_vds_numa_node_map is connected to vds_numa_node_statistics, why to
> > split the tables (vds_numa_node & vds_numa_node_statistics), going back to
> > comment #1, don't we want vNode stats as well, it can be nice to show it
> > :-)
> > (have a vNUMA overview of the VM using guest-agent or sth, in a future
> > phase).
> > [Bruce] Split the tables is referring to vds_interface
> > (vds_interface_statistics) and vm_interface (vm_interface_statistics), the
> > statistics table will be refreshed with a high frequency.
> > I will update the design to add the vNuma statistics for the future phase,
> > and according to my feedback in comment #1, vNuma statistics will also in
> > an
> > independent table since I think there will be more statistics fields for
> > host NUMA than for vNuma.
> 
> Agree with Bruce

I disagree with both:
a) don't compare interface to NUMA; interface is a key element in the system.
b) if you care about high frequency, you can separate the update flows to the same table.
c) see my comment about 1, overhead.
d) vNuma = Numa, as I said we can open it now for discussion.

> 
> > 
> > 5) IMO vds_cpu_statistics shouldn't include any reference to NUMA, I gave
> > that comment in the BE patch as well (remove vds_numa_node_id FK in
> > vds_cpu_statistics), for that you should extract cpu_list to a connection
> > table (anyway I don't like lists as a text/strings/etc.)
> > [Bruce] Yes, I agree with you to remove the reference between
> > vds_cpu_statistics and NUMA. Actually cpu_list is enough for current
> > requirements. I think the connection table is needed when we consider to
> > collect more cpu related information and do more cpu related actions in the
> > future.

fine, can be done in a later phase. Please document with a bug/RFE enhancement and mark infra in whiteboard.

> > 
> > 6) vm_numatune_nodeset can be removed - the vNode should hold it's pinning
> > info; I think that vNode (node according to comment #1) should be connected
> > to a connection table that points to vdsNode (also Node table) itself
> > (kinda
> > complicated but does the trick - nested link).
> > [Bruce] Yes, I will remove vm_numatune_nodeset, but according to my
> > feedback
> > in comment #1, vm_vds_numa_node_map table will be retained to hold the
> > references between host nodes and vNode, since they are "m:n" relations.

repeating my later comment:

correction: no need for another connection table, use vm_vds_numa_node_map with a flag (is_pinned)

> > 
> > 7) Please add delete-cascade info all over, i.e. what happens when we
> > remove
> > a host/vm/node.
> > [Bruce] Yes, I will update the design.

:-) thanks!

> > 
> > 8) Is it possible to put a db constraint that mapping between vNode and
> > Node
> > will be deleted once the VM isn't UP?
> > [Bruce] I have a question here. IMO, the mapping between vNode and Node is
> > a
> > user configuration, why it is related with the vm status? If the mapping is
> > deleted, that means the user configuration is deleted. I don't think it's
> > reasonable.

see comment #6 (including the correction). there is actual real-life NUMA mapping retrieved by the host, and there is pinning info.
when a VM is down, the actual real-life mapping can be removed.

> > 
> > Thanks,
> > Gilad.
> > 
> > ----- Original Message -----
> > > From: "Eli Mesika" <emesika at redhat.com>
> > > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > > <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>, "Chegu
> > > Vinod" <chegu_vinod at hp.com>, "Chuan Liao (Jason Liao,
> > > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck"
> > > <dfediuck at redhat.com>, "Shang-Chun Liang (David Liang,
> > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > Sent: Tuesday, April 1, 2014 10:10:37 AM
> > > Subject: Re: Please help us to review our database schema design with
> > > NUMA feature on ovirt
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > <xiao-lei.shi at hp.com>
> > > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > > > <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>, "Eli
> > > > Mesika" <emesika at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>
> > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
> > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > > > engine-devel at ovirt.org
> > > > Sent: Tuesday, April 1, 2014 5:13:34 AM
> > > > Subject: RE: Please help us to review our database schema design
> > > > with NUMA feature on ovirt
> > > > 
> > > > Assemble the related discussions in this mail session.
> > > > 
> > > > Hi Vinod,
> > > > On 3/31/2014 2:38 AM, Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) wrote:
> > > > > We put host level NUMA fields in vds_dynamic because these
> > > > > information are from host itself, and NUMA topology may be changed
> > > > > if the host's hardware make a change.
> > > > Can you please elaborate ? Are you thinking about resource (cpu
> > > > and/or
> > > > memory) hot plug on the host ?
> > > > [Bruce] It's not about resource hot plug. In ovirt engine, there is
> > > > a scheduled task which will refresh hosts' and vms' information
> > > > periodically.
> > > > Only the dynamic and statistics data will be updated during the
> > > > refresh. So I think the resource information, such as cpu and/or
> > > > memory, should be in dynamic and statistics. And in my
> > > > understanding, the information in dynamic class is the changeable
> > > > information but with a low varying frequency, like cpu topology,
> > > > libvirt/kernel versions, etc. The information in statistics class is
> > > > the information with a high varying frequency, like the usage of
> > > > cpu/memory, etc. In my opinion, it's reasonable to put host level
> > > > NUMA information in vds_dynamic and host level NUMA statistics
> > > > information in vds_statistics.
> > > > 
> > > > Hi Gilad/Roy/Omer,
> > > > I don't know if my understanding is correct. But according to this
> > > > guess, I think it's also reasonable to put vm cpuPin information in
> > > > vm_static.
> > > > Because cpuPin is user configured information, it will not vary
> > > > automatically. So we don?t need to refresh this information
> > > > periodically.
> > > > Please correct me if there are any mistakes.
> > > > 
> > > > Hi Eli,
> > > > Sorry for the nag. If my understanding above is correct, I think we
> > > > should still put host level NUMA fields in
> > > > vds_dynamic/vds_statistics and vm level NUMA fields in vm_static.
> > > > Since vm level NUMA fields are configured by user and they will not
> > > > vary
> > > > automatically.
> > > 
> > > Sorry, I had understood from Gilad that the NUMA fields in the host
> > > level are relatively static and the NUMA fields on the VM level are
> > > dynamic.
> > > I have no problem of having hybrid static/dynamic fields for Host/VM
> > > as long as it has a good reason and fully documented :-)
> > > 
> > > 
> > > > 
> > > > 
> > > > Thanks & Best Regards
> > > > Shi, Xiao-Lei (Bruce)
> > > > 
> > > > Hewlett-Packard Co., Ltd.
> > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > > Sent: Monday, March 31, 2014 9:31 PM
> > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Roy Golan; Omer
> > > > Frenkel
> > > > Cc: Eli Mesika; Roy Golan; Liao, Chuan (Jason Liao,
> > > > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang,
> > > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > > > engine-devel at ovirt.org
> > > > Subject: Re: Please help us to review our database schema design
> > > > with NUMA feature on ovirt
> > > > 
> > > > adding Roy & Omer.
> > > > 
> > > > why CPU topology is in dynamic?
> > > > 
> > > > Thanks,
> > > > Gilad.
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > <xiao-lei.shi at hp.com>
> > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > > > > <rgolan at redhat.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu
> > > > > Vinod"
> > > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > Sent: Monday, March 31, 2014 3:20:33 PM
> > > > > Subject: RE: Please help us to review our database schema design
> > > > > with NUMA feature on ovirt
> > > > > 
> > > > > Thanks Eli.
> > > > > I will move the vm level NUMA fields to vm_dynamic, and the
> > > > > related database schema will be updated accordingly.
> > > > > 
> > > > > Thanks & Best Regards
> > > > > Shi, Xiao-Lei (Bruce)
> > > > > 
> > > > > Hewlett-Packard Co., Ltd.
> > > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > Sent: Monday, March 31, 2014 5:49 PM
> > > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao,
> > > > > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang,
> > > > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > > > > engine-devel at ovirt.org
> > > > > Subject: Re: Please help us to review our database schema design
> > > > > with NUMA feature on ovirt
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > <xiao-lei.shi at hp.com>
> > > > > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
> > > > > > <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>
> > > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
> > > > > > "Chegu Vinod"
> > > > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > > > > HPservers-Core-OE-PSC)"
> > > > > > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > > > > > engine-devel at ovirt.org
> > > > > > Sent: Monday, March 31, 2014 12:38:04 PM
> > > > > > Subject: RE: Please help us to review our database schema design
> > > > > > with NUMA feature on ovirt
> > > > > > 
> > > > > > We put host level NUMA fields in vds_dynamic because these
> > > > > > information are from host itself, and NUMA topology may be
> > > > > > changed if the host's hardware make a change. NUMA information
> > > > > > are similar to the host's cpu topology information like
> > > > > > cpu_cores and cpu_sockets which are in vds_dynamic, we refer to
> > > > > > this.
> > > > > > VM level NUMA fields are configured by user, and actually we
> > > > > > originally think they should be in vm_dynamic. But we found that
> > > > > > the field of another feature cpuPin which is similar as NUMA
> > > > > > feature is in vm_static, so we put vm NUMA fields in vm_static.
> > > > > > Do you think we need to put VM level NUMA fields in vm_dynamic?
> > > > > 
> > > > > I think that in this case we should fix cpuPin to be in vm_dynamic
> > > > > and put after that the other NUMA fields in vm_dynamic as well
> > > > > 
> > > > > > 
> > > > > > Thanks & Best Regards
> > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > 
> > > > > > Hewlett-Packard Co., Ltd.
> > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > 
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > > > > Sent: Monday, March 31, 2014 5:22 PM
> > > > > > To: Eli Mesika; Roy Golan
> > > > > > Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason
> > > > > > Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu;
> > > > > > Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv
> > > > > > Dary; engine-devel at ovirt.org
> > > > > > Subject: Re: Please help us to review our database schema design
> > > > > > with NUMA feature on ovirt
> > > > > > 
> > > > > > +1
> > > > > > 
> > > > > > IMO: vds data should reside in static VM need to think about it.
> > > > > > 
> > > > > > Roy?
> > > > > > 
> > > > > > Thanks,
> > > > > > Gilad.
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > > > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
> > > > > > > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > > <chegu_vinod at hp.com>,
> > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > > > Sent: Monday, March 31, 2014 12:12:50 PM
> > > > > > > Subject: Re: Please help us to review our database schema
> > > > > > > design with NUMA feature on ovirt
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > > <chuan.liao at hp.com>,
> > > > > > > > "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > > <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > > > <chegu_vinod at hp.com>,
> > > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > > <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > > > > Sent: Monday, March 31, 2014 8:56:20 AM
> > > > > > > > Subject: RE: Please help us to review our database schema
> > > > > > > > design with NUMA feature on ovirt
> > > > > > > > 
> > > > > > > > Include the devel group.
> > > > > > > > Thanks Eli for the quick responses for our first design and
> > > > > > > > sorry for the nag.
> > > > > > > > We appreciate any of the comments for our database design
> > > > > > > > and will follow the design to do the implementation if no
> > > > > > > > more comments.
> > > > > > > >  
> > > > > > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > > > 
> > > > > > > Seems OK for me except an unanswered question I had asked in
> > > > > > > my first review
> > > > > > > :
> > > > > > > 
> > > > > > > Why in the Host level NUMA fields are added to vds_dynamic
> > > > > > > while in the VM level it is added to vm_static ???
> > > > > > > I would expect it to be in both on static or dynamic , can you
> > > > > > > please explain ? Thanks
> > > > > > > 
> > > > > > > > 
> > > > > > > > Thanks & Best Regards
> > > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > > 
> > > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > > > Sent: Friday, March 28, 2014 1:30 PM
> > > > > > > > To: 'Eli Mesika'
> > > > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
> > > > > > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun
> > > > > > > > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > > > Subject: RE: Please help us to review our database schema
> > > > > > > > design with NUMA feature on ovirt
> > > > > > > > 
> > > > > > > > Hi Eli,
> > > > > > > > 
> > > > > > > > After the UX design meeting, we did some modification for
> > > > > > > > the database schema, and merged some update according to
> > > > > > > > your last review comments.
> > > > > > > > Now the document has been posted on ovirt wikipage, could
> > > > > > > > you help to review the database design again:
> > > > > > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Thanks & Best Regards
> > > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > > 
> > > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > > 65683093 Mobile
> > > > > > > > +86
> > > > > > > > 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > > 
> > > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > > > Sent: Monday, March 24, 2014 6:24 PM
> > > > > > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
> > > > > > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun
> > > > > > > > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > > > Subject: Re: Please help us to review our database schema
> > > > > > > > design with NUMA feature on ovirt
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason
> > > > > > > > > Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > > > <shangchun.liang at hp.com>
> > > > > > > > > Sent: Monday, March 24, 2014 11:23:39 AM
> > > > > > > > > Subject: RE: Please help us to review our database schema
> > > > > > > > > design with NUMA feature on ovirt
> > > > > > > > > 
> > > > > > > > > Hi Eli,
> > > > > > > > > 
> > > > > > > > > Thanks for your comments.
> > > > > > > > > I have updated the document according to your comments
> > > > > > > > > except the below
> > > > > > > > > one:
> > > > > > > > > Missing from here are 2 issues:
> > > > > > > > > 
> > > > > > > > > 1) Impact on the search engine, which new columns are
> > > > > > > > > search-able and which changes are planned in the search
> > > > > > > > > engine code to enable that
> > > > > > > > > 
> > > > > > > > > 2) Impact on engine-reports, are those changed planned to
> > > > > > > > > be exposed to the engine data warehouse and required
> > > > > > > > > new/modified reports?
> > > > > > > > > 
> > > > > > > > > Could you tell us more detailed information about the
> > > > > > > > > modules you mentioned above? I mean "search engine" and
> > > > > > > > > "engine-reports". I think we missed these two parts in our
> > > > > > > > > previous investigation.
> > > > > > > > > I just find org.ovirt.engine.core.bll.SearchQuery, is that
> > > > > > > > > the right object for search engine?
> > > > > > > > 
> > > > > > > > Yes, actually when you are opening the admin UI, there are
> > > > > > > > TABs for each entity , i.e. Data Center, Cluster, Host etc.
> > > > > > > > In each, you can see a text-box in which you can search for
> > > > > > > > by writing a search expression My question is
> > > > > > > >    1) What is the impact of your work on the search on the Fost
> > > > > > > >    and
> > > > > > > >    VM
> > > > > > > >    TABs
> > > > > > > >       a) Are there any fields that are supported now in the
> > > > > > > >       search
> > > > > > > >       expression
> > > > > > > >       and should pop-up when you write the expression by the
> > > > > > > >       auto-completion
> > > > > > > >       mechanism ?
> > > > > > > >       b) Are there any added columns displayed in the result of
> > > > > > > >       such
> > > > > > > >       a
> > > > > > > >       search
> > > > > > > >       in the grid ?
> > > > > > > > 
> > > > > > > > > How about the engine-reports, could you give us some
> > > > > > > > > hints, like the code location and any more detailed
> > > > > > > > > information that we can start more investigation?
> > > > > > > > 
> > > > > > > > CCing Yaniv D who is in charge of the reports/dwh module
> > > > > > > > Yaniv, any planned work for adding Numa features to Host/VM
> > > > > > > > in the reports side ?
> > > > > > > > 
> > > > > > > > Thanks
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Thanks & Best Regards
> > > > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > > > 
> > > > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > > > > Sent: Sunday, March 23, 2014 4:44 PM
> > > > > > > > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > > > > > > > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang,
> > > > > > > > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi,
> > > > > > > > > Xiao-Lei (Bruce, HP
> > > > > > > > > Servers-PSC-CQ)
> > > > > > > > > Subject: Re: Please help us to review our database schema
> > > > > > > > > design with NUMA feature on ovirt
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > > > > <chuan.liao at hp.com>
> > > > > > > > > > To: emesika at redhat.com
> > > > > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > > > > <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > > > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > > > > > > > > HPservers-Core-OE-PSC)"
> > > > > > > > > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP
> > > > > > > > > > Servers-PSC-CQ)"
> > > > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > > > > > > > > Subject: Please help us to review our database schema
> > > > > > > > > > design with NUMA feature on ovirt
> > > > > > > > > > 
> > > > > > > > > > Hi Eli,
> > > > > > > > > > 
> > > > > > > > > > Please help us to review our database schema design with
> > > > > > > > > > NUMA feature on ovirt
> > > > > > > > > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcm
> > > > > > > > > > bGWA
> > > > > > > > > > cyQo_IST
> > > > > > > > > > Y8
> > > > > > > > > > ykDr0I6VY/edit?usp=sharing
> > > > > > > > > > 
> > > > > > > > > > Feel free to take comments on document at anywhere
> > > > > > > > > 
> > > > > > > > > Done, had commented on the document.
> > > > > > > > > Eli
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Especially, 5.4 The used interface between engine core
> > > > > > > > > > and
> > > > > > > > > > database(schema)
> > > > > > > > > > 
> > > > > > > > > > Your approve and your comments with this section will be
> > > > > > > > > > much more appreciate for us.
> > > > > > > > > > 
> > > > > > > > > > Best Regards,
> > > > > > > > > > Jason Liao
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > >
> > 
>


From vszocs at redhat.com  Thu Apr  3 10:54:32 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Thu, 3 Apr 2014 06:54:32 -0400 (EDT)
Subject: [Engine-devel] [ANN][TechTalk] Two UI tech talks next week!
In-Reply-To: <4200583.2239489.1396520554124.JavaMail.zimbra@redhat.com>
Message-ID: <1429655157.2257627.1396522472176.JavaMail.zimbra@redhat.com>

Dear oVirt community,

next week is UI tech talk week! I've prepared two presentations:

1, oVirt JavaScript SDK (Design Proposal)
   Monday, April 7 - 3pm CET / 9am EST / 4pm TLV time

2, Writing UI plugin with AngularJS
   Tuesday, April 8 - 3pm CET / 9am EST / 4pm TLV time

Of these two, the first one is really important, as it covers
current proposal for oVirt JavaScript SDK including plans for
near future.

The second one is recommended for anyone who wants to learn
about oVirt UI plugins, AngularJS and how they fit together.

I'll send an invitation for both presentations shortly.
PDF slides will be available on day of presentation.

Regards,
Vojtech


From gchaplik at redhat.com  Thu Apr  3 11:00:18 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Thu, 3 Apr 2014 07:00:18 -0400 (EDT)
Subject: [Engine-devel] vds_dynamic refactor
In-Reply-To: <2022363066.4485973.1396522676638.JavaMail.zimbra@redhat.com>
Message-ID: <1938493531.4486794.1396522818946.JavaMail.zimbra@redhat.com>

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.


From liran.zelkha at gmail.com  Thu Apr  3 11:04:29 2014
From: liran.zelkha at gmail.com (Liran Zelkha)
Date: Thu, 3 Apr 2014 14:04:29 +0300
Subject: [Engine-devel] vds_dynamic refactor
In-Reply-To: <1938493531.4486794.1396522818946.JavaMail.zimbra@redhat.com>
References: <2022363066.4485973.1396522676638.JavaMail.zimbra@redhat.com>
	<1938493531.4486794.1396522818946.JavaMail.zimbra@redhat.com>
Message-ID: <CAJ3aYLdmuzTs-70N8SXVtB-drwuQAKdrJ-W8YrOVzSU1FT2EAA@mail.gmail.com>

Why not move it to vds_static?


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

From vszocs at redhat.com  Thu Apr  3 11:08:21 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Thu, 3 Apr 2014 07:08:21 -0400 (EDT)
Subject: [Engine-devel] oVirt JavaScript SDK (Design Proposal)
Message-ID: <1842526862.2269583.1396523300971.JavaMail.zimbra@redhat.com>

The following is a new meeting request:

Subject: oVirt JavaScript SDK (Design Proposal) 
Organizer: "Vojtech Szocs" <vszocs at redhat.com> 

Time: Monday, April 7, 2014, 3:00:00 PM - 5:00:00 PM GMT +01:00 Belgrade, Bratislava, Budapest, Ljubljana, Prague
 
Invitees: users at ovirt.org; engine-devel at ovirt.org 


*~*~*~*~*~*~*~*~*~*

Hi guys,

we're planning to move oVirt UI to use REST API [1] and this session is the first step in our journey.

Make sure to join if you want to learn about our plans for oVirt JavaScript SDK and its use in web applications.

Topics covered:
* Java SDK overview
* JavaScript SDK design overview
* JavaScript Binding API proposal
* Future plans

Estimated duration: 2 hours

To join this meeting, dial into the Intercall bridge and use following conference code: 712 886 7405 #
https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405

PDF slides will be available on day of presentation.

[1] http://www.ovirt.org/Features/Design/Using_REST_API_In_Web_UI

Regards,
Vojtech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 2263 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140403/a9065ea4/attachment.ics>

From yzaslavs at redhat.com  Thu Apr  3 11:12:59 2014
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Thu, 3 Apr 2014 07:12:59 -0400 (EDT)
Subject: [Engine-devel] vds_dynamic refactor
In-Reply-To: <CAJ3aYLdmuzTs-70N8SXVtB-drwuQAKdrJ-W8YrOVzSU1FT2EAA@mail.gmail.com>
References: <2022363066.4485973.1396522676638.JavaMail.zimbra@redhat.com>
	<1938493531.4486794.1396522818946.JavaMail.zimbra@redhat.com>
	<CAJ3aYLdmuzTs-70N8SXVtB-drwuQAKdrJ-W8YrOVzSU1FT2EAA@mail.gmail.com>
Message-ID: <1876116111.12394720.1396523579127.JavaMail.zimbra@redhat.com>



----- 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.
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 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
> 


From vszocs at redhat.com  Thu Apr  3 11:15:43 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Thu, 3 Apr 2014 07:15:43 -0400 (EDT)
Subject: [Engine-devel] Writing UI plugin with AngularJS
Message-ID: <576036574.2271649.1396523743019.JavaMail.zimbra@redhat.com>

The following is a new meeting request:

Subject: Writing UI plugin with AngularJS 
Organizer: "Vojtech Szocs" <vszocs at redhat.com> 

Time: Tuesday, April 8, 2014, 3:00:00 PM - 5:00:00 PM GMT +01:00 Belgrade, Bratislava, Budapest, Ljubljana, Prague
 
Invitees: users at ovirt.org; engine-devel at ovirt.org 


*~*~*~*~*~*~*~*~*~*

Hi guys,

this session is for those of you interested in learning about oVirt UI plugins, AngularJS and how they fit together.

Includes UI plugin & AngularJS overview, writing UI plugin step-by-step and live demo.

Topics covered:
* AngularJS fly-through
* oVirt UI plugins fly-through
* UI plugin with AngularJS walk-through
* Live demo

Estimated duration: 1.5 hours

To join this meeting, dial into the Intercall bridge and use following conference code: 712 886 7405 #
https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405

PDF slides + source code will be available on day of presentation.

Regards,
Vojtech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 2192 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140403/2d57d306/attachment.ics>

From ecohen at redhat.com  Thu Apr  3 12:17:39 2014
From: ecohen at redhat.com (Einav Cohen)
Date: Thu, 3 Apr 2014 08:17:39 -0400 (EDT)
Subject: [Engine-devel] [Users] Writing UI plugin with AngularJS
In-Reply-To: <576036574.2271649.1396523743019.JavaMail.zimbra@redhat.com>
References: <576036574.2271649.1396523743019.JavaMail.zimbra@redhat.com>
Message-ID: <1665641403.6757386.1396527459228.JavaMail.zimbra@redhat.com>

Vojtech, this is conflicting with the '3.5 SLA features overview' 
meeting. maybe move this meeting to start one hour earlier (2:00 
PM Brno time)?

----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> To: "users" <users at ovirt.org>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, April 3, 2014 7:15:43 AM
> Subject: [Users] Writing UI plugin with AngularJS
> 
> The following is a new meeting request:
> 
> Subject: Writing UI plugin with AngularJS
> Organizer: "Vojtech Szocs" <vszocs at redhat.com>
> 
> Time: Tuesday, April 8, 2014, 3:00:00 PM - 5:00:00 PM GMT +01:00 Belgrade,
> Bratislava, Budapest, Ljubljana, Prague
>  
> Invitees: users at ovirt.org; engine-devel at ovirt.org
> 
> 
> *~*~*~*~*~*~*~*~*~*
> 
> Hi guys,
> 
> this session is for those of you interested in learning about oVirt UI
> plugins, AngularJS and how they fit together.
> 
> Includes UI plugin & AngularJS overview, writing UI plugin step-by-step and
> live demo.
> 
> Topics covered:
> * AngularJS fly-through
> * oVirt UI plugins fly-through
> * UI plugin with AngularJS walk-through
> * Live demo
> 
> Estimated duration: 1.5 hours
> 
> To join this meeting, dial into the Intercall bridge and use following
> conference code: 712 886 7405 #
> https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405
> 
> PDF slides + source code will be available on day of presentation.
> 
> Regards,
> Vojtech
> 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


From bproffit at redhat.com  Thu Apr  3 12:22:21 2014
From: bproffit at redhat.com (Brian Proffitt)
Date: Thu, 3 Apr 2014 08:22:21 -0400 (EDT)
Subject: [Engine-devel] Mailing List Change
In-Reply-To: <893416432.1355948.1396527425937.JavaMail.zimbra@redhat.com>
Message-ID: <993721159.1357129.1396527741544.JavaMail.zimbra@redhat.com>

All:

We have started to implement the Arch/Engine-devel list changes.

Arch and engine-devel list subscribers are now subscribed to devel. 

At 1330 UTC (a little over one hour from now), the engine-devel mailing list will be shut down and its archives moved to devel.

Arch will remain in place, but all users there are recommended to start using devel for new conversations.

Thanks,
Brian

-- 
Brian Proffitt - oVirt Community Manager
Open Source and Standards, Red Hat - http://community.redhat.com
Phone: +1 574 383 9BKP
IRC: bkp @ OFTC


From gchaplik at redhat.com  Thu Apr  3 13:00:25 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Thu, 3 Apr 2014 09:00:25 -0400 (EDT)
Subject: [Engine-devel] vds_dynamic refactor
In-Reply-To: <1876116111.12394720.1396523579127.JavaMail.zimbra@redhat.com>
References: <2022363066.4485973.1396522676638.JavaMail.zimbra@redhat.com>
	<1938493531.4486794.1396522818946.JavaMail.zimbra@redhat.com>
	<CAJ3aYLdmuzTs-70N8SXVtB-drwuQAKdrJ-W8YrOVzSU1FT2EAA@mail.gmail.com>
	<1876116111.12394720.1396523579127.JavaMail.zimbra@redhat.com>
Message-ID: <2064308866.4626560.1396530025984.JavaMail.zimbra@redhat.com>

----- 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.
> 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 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
> > 
> 


From emesika at redhat.com  Thu Apr  3 13:03:19 2014
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 3 Apr 2014 09:03:19 -0400 (EDT)
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <1922469868.4436271.1396521992628.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<1690885238.11367.1396272677929.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD232@G5W2743.americas.hpqcorp.net>
	<434209250.5741543.1396336237695.JavaMail.zimbra@redhat.com>
	<509028518.3947921.1396487095509.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD55D@G5W2743.americas.hpqcorp.net>
	<134006885.6976322.1396511694070.JavaMail.zimbra@redhat.com>
	<1922469868.4436271.1396521992628.JavaMail.zimbra@redhat.com>
Message-ID: <1403991192.7101915.1396530199044.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Roy Golan" <rgolan at redhat.com>, "Omer Frenkel"
> <ofrenkel at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>, engine-devel at ovirt.org
> Sent: Thursday, April 3, 2014 1:46:32 PM
> Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan" <rgolan at redhat.com>,
> > "Omer Frenkel" <ofrenkel at redhat.com>,
> > "Chegu Vinod" <chegu_vinod at hp.com>, "Chuan Liao (Jason Liao,
> > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron
> > Fediuck" <dfediuck at redhat.com>, "Shang-Chun Liang (David Liang,
> > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>,
> > "Yaniv Dary" <ydary at redhat.com>, engine-devel at ovirt.org
> > Sent: Thursday, April 3, 2014 10:54:54 AM
> > Subject: Re: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
> > > <emesika at redhat.com>
> > > Cc: "Roy Golan" <rgolan at redhat.com>, "Omer Frenkel"
> > > <ofrenkel at redhat.com>,
> > > "Chegu Vinod" <chegu_vinod at hp.com>, "Chuan
> > > Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron
> > > Fediuck" <dfediuck at redhat.com>, "Shang-Chun
> > > Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>,
> > > "Yaniv Dary" <ydary at redhat.com>,
> > > engine-devel at ovirt.org
> > > Sent: Thursday, April 3, 2014 7:25:11 AM
> > > Subject: RE: Please help us to review our database schema design with
> > > NUMA
> > > feature on ovirt
> > > 
> > > Hi all,
> > > Please see my comments in line.
> > > 
> > > Thanks & Best Regards
> > > Shi, Xiao-Lei (Bruce)
> > > 
> > > Hewlett-Packard Co., Ltd.
> > > HP Servers Core Platform Software China
> > > Telephone +86 23 65683093
> > > Mobile +86 18696583447
> > > Email xiao-lei.shi at hp.com
> > > 
> > > -----Original Message-----
> > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > Sent: Thursday, April 03, 2014 9:05 AM
> > > To: Eli Mesika
> > > Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Roy Golan; Omer Frenkel;
> > > Vinod,
> > > Chegu; Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck;
> > > Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > > engine-devel at ovirt.org
> > > Subject: Re: Please help us to review our database schema design with
> > > NUMA
> > > feature on ovirt
> > > 
> > > Hi all,
> > > Sorry for joining-in late.
> > > 
> > > My comments (according to the db diagram section in
> > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_ISTY8ykDr0I6VY):
> > > 1) Join vm_numa_node and vds_numa_node to a single table (almost
> > > identical),
> > > one of the FKs can be null.
> > > [Bruce] I prefer two tables. Actually host level NUMA node and vm level
> > > NUMA
> > > node are different objects. In my understanding, vm level NUMA node is
> > > just
> > > a simulation of host level NUMA node, and host level NUMA node has more
> > > features that not in vm NUMA (like several levels of host NUMA topology
> > > mentioned by Vinod). We need to consider the extensions of host NUMA in
> > > the
> > > future.
> 
> Let's open the discussion and consider them right now. vNode and Node are the
> same.
> Vinod?
> 
> > 
> > I agree with Bruce, we have no problem with more tables and constrains
> > should
> > work as expected and remove entries when a Host or VM is removed.
> > I do not like tables that have 2 UUIDs when one of them is null , this is
> > against simple DB normalization
> > 
> 
> We are going to maintain and develop this feature. there is a huge overhead
> in 6 table design in compare to 4.

Counting how many tables you should manage is out of context.
The only thing I can care of is database design 
>From DB design perspective if you have a main table A with PK PK-A if you have any other table X that includes PK-A as a column Cx , then there should be a foreign key constraint that handles removals from A and clean corresponding X table records accordingly. This you can not do when you have 2 UUIDs as you suggested (not to mention that this is considered as bad DB design with no doubt)
Add to that the fact that when managing both UUIDs in one table, you are supposed to get deadlocks from scenarios that wouldn't cause that if each entity is managed in its own table.
I don't see any point to open this to discussion, we had worked hard to separate tables that used this bad method in the past and caused us a bunch of unexpected problems.
Please develop your DB changes according to normal well accepted guidelines I will not ack a change that violates simple DB design rules.
Thanks  

> 
> > >    
> > > 2) No templates reference in the design, need to check it out (it might
> > > be
> > > inherently designed already :-) ); vNode can be linked to a template.
> > > [Bruce] IMO, we can consider template as a special vm, our current design
> > > supports to create vNodes in a template just like what it does in a vm.
> > 
> > We also store today templates in the VM* tables as special entities defined
> > by the entity_type column
> 
> +1, just need to see that this is taken care of.
> 
> > 
> > > 
> > > 3) The reason I want host's NUMA data to be in static is because it
> > > updates
> > > only once (on boot). "engineerically" speaking, dynamic table has a lot
> > > of
> > > traffic and that's not the case for NUMA info. Its feels to me like 'a
> > > hybrid' of static and dynamic, 3 suggestions comes to mind:
> > >  - leave it in dynamic (maybe in a separate process).
> > >  - have a separate flow that updates static.
> > >  - come up with a third 'vds_on_boot' table (my favorite ;-P ).
> > > I will get back to you on that.
> > > [Bruce] From the onTimer codes in vdsManager (IMO it's the scheduled vds
> > > refresh action), when vds is in normal running status (up status), only
> > > statistics data will be refreshed, so I think maybe dynamic table doesn't
> > > have so much traffic, and the varied data (I mean the data varied through
> > > a
> > > power reload, like cpu topology, numa topology, ...etc) can be refreshed
> > > meanwhile.
> > > 
> 
> I beg to differ, dynamic table contains a lot of dynamic data:
> host status, used memory and pending resources (maybe more).
> still need to think about it, and get back to you.
> 
> > > 4) vm_vds_numa_node_map is connected to vds_numa_node_statistics, why to
> > > split the tables (vds_numa_node & vds_numa_node_statistics), going back
> > > to
> > > comment #1, don't we want vNode stats as well, it can be nice to show it
> > > :-)
> > > (have a vNUMA overview of the VM using guest-agent or sth, in a future
> > > phase).
> > > [Bruce] Split the tables is referring to vds_interface
> > > (vds_interface_statistics) and vm_interface (vm_interface_statistics),
> > > the
> > > statistics table will be refreshed with a high frequency.
> > > I will update the design to add the vNuma statistics for the future
> > > phase,
> > > and according to my feedback in comment #1, vNuma statistics will also in
> > > an
> > > independent table since I think there will be more statistics fields for
> > > host NUMA than for vNuma.
> > 
> > Agree with Bruce
> 
> I disagree with both:
> a) don't compare interface to NUMA; interface is a key element in the system.
> b) if you care about high frequency, you can separate the update flows to the
> same table.
> c) see my comment about 1, overhead.
> d) vNuma = Numa, as I said we can open it now for discussion.
> 
> > 
> > > 
> > > 5) IMO vds_cpu_statistics shouldn't include any reference to NUMA, I gave
> > > that comment in the BE patch as well (remove vds_numa_node_id FK in
> > > vds_cpu_statistics), for that you should extract cpu_list to a connection
> > > table (anyway I don't like lists as a text/strings/etc.)
> > > [Bruce] Yes, I agree with you to remove the reference between
> > > vds_cpu_statistics and NUMA. Actually cpu_list is enough for current
> > > requirements. I think the connection table is needed when we consider to
> > > collect more cpu related information and do more cpu related actions in
> > > the
> > > future.
> 
> fine, can be done in a later phase. Please document with a bug/RFE
> enhancement and mark infra in whiteboard.
> 
> > > 
> > > 6) vm_numatune_nodeset can be removed - the vNode should hold it's
> > > pinning
> > > info; I think that vNode (node according to comment #1) should be
> > > connected
> > > to a connection table that points to vdsNode (also Node table) itself
> > > (kinda
> > > complicated but does the trick - nested link).
> > > [Bruce] Yes, I will remove vm_numatune_nodeset, but according to my
> > > feedback
> > > in comment #1, vm_vds_numa_node_map table will be retained to hold the
> > > references between host nodes and vNode, since they are "m:n" relations.
> 
> repeating my later comment:
> 
> correction: no need for another connection table, use vm_vds_numa_node_map
> with a flag (is_pinned)
> 
> > > 
> > > 7) Please add delete-cascade info all over, i.e. what happens when we
> > > remove
> > > a host/vm/node.
> > > [Bruce] Yes, I will update the design.
> 
> :-) thanks!
> 
> > > 
> > > 8) Is it possible to put a db constraint that mapping between vNode and
> > > Node
> > > will be deleted once the VM isn't UP?
> > > [Bruce] I have a question here. IMO, the mapping between vNode and Node
> > > is
> > > a
> > > user configuration, why it is related with the vm status? If the mapping
> > > is
> > > deleted, that means the user configuration is deleted. I don't think it's
> > > reasonable.
> 
> see comment #6 (including the correction). there is actual real-life NUMA
> mapping retrieved by the host, and there is pinning info.
> when a VM is down, the actual real-life mapping can be removed.
> 
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > ----- Original Message -----
> > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > > > <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>, "Chegu
> > > > Vinod" <chegu_vinod at hp.com>, "Chuan Liao (Jason Liao,
> > > > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck"
> > > > <dfediuck at redhat.com>, "Shang-Chun Liang (David Liang,
> > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > Sent: Tuesday, April 1, 2014 10:10:37 AM
> > > > Subject: Re: Please help us to review our database schema design with
> > > > NUMA feature on ovirt
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > <xiao-lei.shi at hp.com>
> > > > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > > > > <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>, "Eli
> > > > > Mesika" <emesika at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>
> > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
> > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > > > > engine-devel at ovirt.org
> > > > > Sent: Tuesday, April 1, 2014 5:13:34 AM
> > > > > Subject: RE: Please help us to review our database schema design
> > > > > with NUMA feature on ovirt
> > > > > 
> > > > > Assemble the related discussions in this mail session.
> > > > > 
> > > > > Hi Vinod,
> > > > > On 3/31/2014 2:38 AM, Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) wrote:
> > > > > > We put host level NUMA fields in vds_dynamic because these
> > > > > > information are from host itself, and NUMA topology may be changed
> > > > > > if the host's hardware make a change.
> > > > > Can you please elaborate ? Are you thinking about resource (cpu
> > > > > and/or
> > > > > memory) hot plug on the host ?
> > > > > [Bruce] It's not about resource hot plug. In ovirt engine, there is
> > > > > a scheduled task which will refresh hosts' and vms' information
> > > > > periodically.
> > > > > Only the dynamic and statistics data will be updated during the
> > > > > refresh. So I think the resource information, such as cpu and/or
> > > > > memory, should be in dynamic and statistics. And in my
> > > > > understanding, the information in dynamic class is the changeable
> > > > > information but with a low varying frequency, like cpu topology,
> > > > > libvirt/kernel versions, etc. The information in statistics class is
> > > > > the information with a high varying frequency, like the usage of
> > > > > cpu/memory, etc. In my opinion, it's reasonable to put host level
> > > > > NUMA information in vds_dynamic and host level NUMA statistics
> > > > > information in vds_statistics.
> > > > > 
> > > > > Hi Gilad/Roy/Omer,
> > > > > I don't know if my understanding is correct. But according to this
> > > > > guess, I think it's also reasonable to put vm cpuPin information in
> > > > > vm_static.
> > > > > Because cpuPin is user configured information, it will not vary
> > > > > automatically. So we don?t need to refresh this information
> > > > > periodically.
> > > > > Please correct me if there are any mistakes.
> > > > > 
> > > > > Hi Eli,
> > > > > Sorry for the nag. If my understanding above is correct, I think we
> > > > > should still put host level NUMA fields in
> > > > > vds_dynamic/vds_statistics and vm level NUMA fields in vm_static.
> > > > > Since vm level NUMA fields are configured by user and they will not
> > > > > vary
> > > > > automatically.
> > > > 
> > > > Sorry, I had understood from Gilad that the NUMA fields in the host
> > > > level are relatively static and the NUMA fields on the VM level are
> > > > dynamic.
> > > > I have no problem of having hybrid static/dynamic fields for Host/VM
> > > > as long as it has a good reason and fully documented :-)
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > Thanks & Best Regards
> > > > > Shi, Xiao-Lei (Bruce)
> > > > > 
> > > > > Hewlett-Packard Co., Ltd.
> > > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > > > Sent: Monday, March 31, 2014 9:31 PM
> > > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Roy Golan; Omer
> > > > > Frenkel
> > > > > Cc: Eli Mesika; Roy Golan; Liao, Chuan (Jason Liao,
> > > > > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang,
> > > > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > > > > engine-devel at ovirt.org
> > > > > Subject: Re: Please help us to review our database schema design
> > > > > with NUMA feature on ovirt
> > > > > 
> > > > > adding Roy & Omer.
> > > > > 
> > > > > why CPU topology is in dynamic?
> > > > > 
> > > > > Thanks,
> > > > > Gilad.
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > <xiao-lei.shi at hp.com>
> > > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > > > > > <rgolan at redhat.com>, "Chuan Liao (Jason Liao,
> > > > > > HPservers-Core-OE-PSC)"
> > > > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu
> > > > > > Vinod"
> > > > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > > Sent: Monday, March 31, 2014 3:20:33 PM
> > > > > > Subject: RE: Please help us to review our database schema design
> > > > > > with NUMA feature on ovirt
> > > > > > 
> > > > > > Thanks Eli.
> > > > > > I will move the vm level NUMA fields to vm_dynamic, and the
> > > > > > related database schema will be updated accordingly.
> > > > > > 
> > > > > > Thanks & Best Regards
> > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > 
> > > > > > Hewlett-Packard Co., Ltd.
> > > > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > Sent: Monday, March 31, 2014 5:49 PM
> > > > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao,
> > > > > > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang,
> > > > > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > > > > > engine-devel at ovirt.org
> > > > > > Subject: Re: Please help us to review our database schema design
> > > > > > with NUMA feature on ovirt
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
> > > > > > > <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>
> > > > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
> > > > > > > "Chegu Vinod"
> > > > > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > > > > > HPservers-Core-OE-PSC)"
> > > > > > > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > > > > > > engine-devel at ovirt.org
> > > > > > > Sent: Monday, March 31, 2014 12:38:04 PM
> > > > > > > Subject: RE: Please help us to review our database schema design
> > > > > > > with NUMA feature on ovirt
> > > > > > > 
> > > > > > > We put host level NUMA fields in vds_dynamic because these
> > > > > > > information are from host itself, and NUMA topology may be
> > > > > > > changed if the host's hardware make a change. NUMA information
> > > > > > > are similar to the host's cpu topology information like
> > > > > > > cpu_cores and cpu_sockets which are in vds_dynamic, we refer to
> > > > > > > this.
> > > > > > > VM level NUMA fields are configured by user, and actually we
> > > > > > > originally think they should be in vm_dynamic. But we found that
> > > > > > > the field of another feature cpuPin which is similar as NUMA
> > > > > > > feature is in vm_static, so we put vm NUMA fields in vm_static.
> > > > > > > Do you think we need to put VM level NUMA fields in vm_dynamic?
> > > > > > 
> > > > > > I think that in this case we should fix cpuPin to be in vm_dynamic
> > > > > > and put after that the other NUMA fields in vm_dynamic as well
> > > > > > 
> > > > > > > 
> > > > > > > Thanks & Best Regards
> > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > 
> > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > 
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > > > > > Sent: Monday, March 31, 2014 5:22 PM
> > > > > > > To: Eli Mesika; Roy Golan
> > > > > > > Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason
> > > > > > > Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu;
> > > > > > > Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv
> > > > > > > Dary; engine-devel at ovirt.org
> > > > > > > Subject: Re: Please help us to review our database schema design
> > > > > > > with NUMA feature on ovirt
> > > > > > > 
> > > > > > > +1
> > > > > > > 
> > > > > > > IMO: vds data should reside in static VM need to think about it.
> > > > > > > 
> > > > > > > Roy?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Gilad.
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > > > > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
> > > > > > > > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > > > <chegu_vinod at hp.com>,
> > > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > > <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > > > > Sent: Monday, March 31, 2014 12:12:50 PM
> > > > > > > > Subject: Re: Please help us to review our database schema
> > > > > > > > design with NUMA feature on ovirt
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > > > <chuan.liao at hp.com>,
> > > > > > > > > "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > > > <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > > > > <chegu_vinod at hp.com>,
> > > > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > > > <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > > > > > Sent: Monday, March 31, 2014 8:56:20 AM
> > > > > > > > > Subject: RE: Please help us to review our database schema
> > > > > > > > > design with NUMA feature on ovirt
> > > > > > > > > 
> > > > > > > > > Include the devel group.
> > > > > > > > > Thanks Eli for the quick responses for our first design and
> > > > > > > > > sorry for the nag.
> > > > > > > > > We appreciate any of the comments for our database design
> > > > > > > > > and will follow the design to do the implementation if no
> > > > > > > > > more comments.
> > > > > > > > >  
> > > > > > > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > > > > 
> > > > > > > > Seems OK for me except an unanswered question I had asked in
> > > > > > > > my first review
> > > > > > > > :
> > > > > > > > 
> > > > > > > > Why in the Host level NUMA fields are added to vds_dynamic
> > > > > > > > while in the VM level it is added to vm_static ???
> > > > > > > > I would expect it to be in both on static or dynamic , can you
> > > > > > > > please explain ? Thanks
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Thanks & Best Regards
> > > > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > > > 
> > > > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > > > > Sent: Friday, March 28, 2014 1:30 PM
> > > > > > > > > To: 'Eli Mesika'
> > > > > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
> > > > > > > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun
> > > > > > > > > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > > > > Subject: RE: Please help us to review our database schema
> > > > > > > > > design with NUMA feature on ovirt
> > > > > > > > > 
> > > > > > > > > Hi Eli,
> > > > > > > > > 
> > > > > > > > > After the UX design meeting, we did some modification for
> > > > > > > > > the database schema, and merged some update according to
> > > > > > > > > your last review comments.
> > > > > > > > > Now the document has been posted on ovirt wikipage, could
> > > > > > > > > you help to review the database design again:
> > > > > > > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Thanks & Best Regards
> > > > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > > > 
> > > > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > > > 65683093 Mobile
> > > > > > > > > +86
> > > > > > > > > 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > > > > Sent: Monday, March 24, 2014 6:24 PM
> > > > > > > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
> > > > > > > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun
> > > > > > > > > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > > > > Subject: Re: Please help us to review our database schema
> > > > > > > > > design with NUMA feature on ovirt
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > > > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason
> > > > > > > > > > Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > > > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > > > > <shangchun.liang at hp.com>
> > > > > > > > > > Sent: Monday, March 24, 2014 11:23:39 AM
> > > > > > > > > > Subject: RE: Please help us to review our database schema
> > > > > > > > > > design with NUMA feature on ovirt
> > > > > > > > > > 
> > > > > > > > > > Hi Eli,
> > > > > > > > > > 
> > > > > > > > > > Thanks for your comments.
> > > > > > > > > > I have updated the document according to your comments
> > > > > > > > > > except the below
> > > > > > > > > > one:
> > > > > > > > > > Missing from here are 2 issues:
> > > > > > > > > > 
> > > > > > > > > > 1) Impact on the search engine, which new columns are
> > > > > > > > > > search-able and which changes are planned in the search
> > > > > > > > > > engine code to enable that
> > > > > > > > > > 
> > > > > > > > > > 2) Impact on engine-reports, are those changed planned to
> > > > > > > > > > be exposed to the engine data warehouse and required
> > > > > > > > > > new/modified reports?
> > > > > > > > > > 
> > > > > > > > > > Could you tell us more detailed information about the
> > > > > > > > > > modules you mentioned above? I mean "search engine" and
> > > > > > > > > > "engine-reports". I think we missed these two parts in our
> > > > > > > > > > previous investigation.
> > > > > > > > > > I just find org.ovirt.engine.core.bll.SearchQuery, is that
> > > > > > > > > > the right object for search engine?
> > > > > > > > > 
> > > > > > > > > Yes, actually when you are opening the admin UI, there are
> > > > > > > > > TABs for each entity , i.e. Data Center, Cluster, Host etc.
> > > > > > > > > In each, you can see a text-box in which you can search for
> > > > > > > > > by writing a search expression My question is
> > > > > > > > >    1) What is the impact of your work on the search on the
> > > > > > > > >    Fost
> > > > > > > > >    and
> > > > > > > > >    VM
> > > > > > > > >    TABs
> > > > > > > > >       a) Are there any fields that are supported now in the
> > > > > > > > >       search
> > > > > > > > >       expression
> > > > > > > > >       and should pop-up when you write the expression by the
> > > > > > > > >       auto-completion
> > > > > > > > >       mechanism ?
> > > > > > > > >       b) Are there any added columns displayed in the result
> > > > > > > > >       of
> > > > > > > > >       such
> > > > > > > > >       a
> > > > > > > > >       search
> > > > > > > > >       in the grid ?
> > > > > > > > > 
> > > > > > > > > > How about the engine-reports, could you give us some
> > > > > > > > > > hints, like the code location and any more detailed
> > > > > > > > > > information that we can start more investigation?
> > > > > > > > > 
> > > > > > > > > CCing Yaniv D who is in charge of the reports/dwh module
> > > > > > > > > Yaniv, any planned work for adding Numa features to Host/VM
> > > > > > > > > in the reports side ?
> > > > > > > > > 
> > > > > > > > > Thanks
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Thanks & Best Regards
> > > > > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > > > > 
> > > > > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > > > > 
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > > > > > Sent: Sunday, March 23, 2014 4:44 PM
> > > > > > > > > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > > > > > > > > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang,
> > > > > > > > > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi,
> > > > > > > > > > Xiao-Lei (Bruce, HP
> > > > > > > > > > Servers-PSC-CQ)
> > > > > > > > > > Subject: Re: Please help us to review our database schema
> > > > > > > > > > design with NUMA feature on ovirt
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > > > > > <chuan.liao at hp.com>
> > > > > > > > > > > To: emesika at redhat.com
> > > > > > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad
> > > > > > > > > > > Chaplik"
> > > > > > > > > > > <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > > > > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > > > > > > > > > HPservers-Core-OE-PSC)"
> > > > > > > > > > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP
> > > > > > > > > > > Servers-PSC-CQ)"
> > > > > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > > > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > > > > > > > > > Subject: Please help us to review our database schema
> > > > > > > > > > > design with NUMA feature on ovirt
> > > > > > > > > > > 
> > > > > > > > > > > Hi Eli,
> > > > > > > > > > > 
> > > > > > > > > > > Please help us to review our database schema design with
> > > > > > > > > > > NUMA feature on ovirt
> > > > > > > > > > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcm
> > > > > > > > > > > bGWA
> > > > > > > > > > > cyQo_IST
> > > > > > > > > > > Y8
> > > > > > > > > > > ykDr0I6VY/edit?usp=sharing
> > > > > > > > > > > 
> > > > > > > > > > > Feel free to take comments on document at anywhere
> > > > > > > > > > 
> > > > > > > > > > Done, had commented on the document.
> > > > > > > > > > Eli
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Especially, 5.4 The used interface between engine core
> > > > > > > > > > > and
> > > > > > > > > > > database(schema)
> > > > > > > > > > > 
> > > > > > > > > > > Your approve and your comments with this section will be
> > > > > > > > > > > much more appreciate for us.
> > > > > > > > > > > 
> > > > > > > > > > > Best Regards,
> > > > > > > > > > > Jason Liao
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > >
> > > 
> >
> 


From vszocs at redhat.com  Thu Apr  3 13:12:40 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Thu, 3 Apr 2014 09:12:40 -0400 (EDT)
Subject: [Engine-devel] [Users] Writing UI plugin with AngularJS
In-Reply-To: <1665641403.6757386.1396527459228.JavaMail.zimbra@redhat.com>
References: <576036574.2271649.1396523743019.JavaMail.zimbra@redhat.com>
	<1665641403.6757386.1396527459228.JavaMail.zimbra@redhat.com>
Message-ID: <1474014588.2342339.1396530760044.JavaMail.zimbra@redhat.com>

(cc'ing devel list)

Einav is right, there's "3.5 SLA features overview" meeting starting at 4pm CET.

I'll move the session one hour earlier, from 3-5pm to 2-4pm CET (to 8-10am EST).

I'll also add devel list on CC list of both sessions.

Vojtech


----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "users" <users at ovirt.org>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, April 3, 2014 2:17:39 PM
> Subject: Re: [Users] Writing UI plugin with AngularJS
> 
> Vojtech, this is conflicting with the '3.5 SLA features overview'
> meeting. maybe move this meeting to start one hour earlier (2:00
> PM Brno time)?
> 
> ----- Original Message -----
> > From: "Vojtech Szocs" <vszocs at redhat.com>
> > To: "users" <users at ovirt.org>, "engine-devel" <engine-devel at ovirt.org>
> > Sent: Thursday, April 3, 2014 7:15:43 AM
> > Subject: [Users] Writing UI plugin with AngularJS
> > 
> > The following is a new meeting request:
> > 
> > Subject: Writing UI plugin with AngularJS
> > Organizer: "Vojtech Szocs" <vszocs at redhat.com>
> > 
> > Time: Tuesday, April 8, 2014, 3:00:00 PM - 5:00:00 PM GMT +01:00 Belgrade,
> > Bratislava, Budapest, Ljubljana, Prague
> >  
> > Invitees: users at ovirt.org; engine-devel at ovirt.org
> > 
> > 
> > *~*~*~*~*~*~*~*~*~*
> > 
> > Hi guys,
> > 
> > this session is for those of you interested in learning about oVirt UI
> > plugins, AngularJS and how they fit together.
> > 
> > Includes UI plugin & AngularJS overview, writing UI plugin step-by-step and
> > live demo.
> > 
> > Topics covered:
> > * AngularJS fly-through
> > * oVirt UI plugins fly-through
> > * UI plugin with AngularJS walk-through
> > * Live demo
> > 
> > Estimated duration: 1.5 hours
> > 
> > To join this meeting, dial into the Intercall bridge and use following
> > conference code: 712 886 7405 #
> > https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405
> > 
> > PDF slides + source code will be available on day of presentation.
> > 
> > Regards,
> > Vojtech
> > 
> > _______________________________________________
> > Users mailing list
> > Users at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> > 
> 


From vszocs at redhat.com  Thu Apr  3 13:15:57 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Thu, 3 Apr 2014 09:15:57 -0400 (EDT)
Subject: [Engine-devel] Writing UI plugin with AngularJS
Message-ID: <857997243.2348010.1396530957884.JavaMail.zimbra@redhat.com>

The following meeting has been modified:

Subject: Writing UI plugin with AngularJS 
Organizer: "Vojtech Szocs" <vszocs at redhat.com> 

Time: Tuesday, April 8, 2014, 2:00:00 PM - 4:00:00 PM GMT +01:00 Belgrade, Bratislava, Budapest, Ljubljana, Prague [MODIFIED]
 
Invitees: users at ovirt.org; engine-devel at ovirt.org; tjelinek at redhat.com; lvernia at redhat.com; sgordon at redhat.com; mtayer at redhat.com; gshereme at redhat.com; awels at redhat.com; rnachimu at redhat.com; devel at ovirt.org 


*~*~*~*~*~*~*~*~*~*

UPDATE: we will start one hour earlier, at 2pm CET / 8am EST / 3pm TLV time

Hi guys, 

this session is for those of you interested in learning about oVirt UI plugins, AngularJS and how they fit together. 

Includes UI plugin & AngularJS overview, writing UI plugin step-by-step and live demo. 

Topics covered: 
* AngularJS fly-through 
* oVirt UI plugins fly-through 
* UI plugin with AngularJS walk-through 
* Live demo 

Estimated duration: 1.5 hours 

To join this meeting, dial into the Intercall bridge and use following conference code: 712 886 7405 # 
https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405 

PDF slides + source code will be available on day of presentation. 

Regards, 
Vojtech 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 3307 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140403/9b040836/attachment.ics>

From emesika at redhat.com  Thu Apr  3 13:33:34 2014
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 3 Apr 2014 09:33:34 -0400 (EDT)
Subject: [Engine-devel] vds_dynamic refactor
In-Reply-To: <2064308866.4626560.1396530025984.JavaMail.zimbra@redhat.com>
References: <2022363066.4485973.1396522676638.JavaMail.zimbra@redhat.com>
	<1938493531.4486794.1396522818946.JavaMail.zimbra@redhat.com>
	<CAJ3aYLdmuzTs-70N8SXVtB-drwuQAKdrJ-W8YrOVzSU1FT2EAA@mail.gmail.com>
	<1876116111.12394720.1396523579127.JavaMail.zimbra@redhat.com>
	<2064308866.4626560.1396530025984.JavaMail.zimbra@redhat.com>
Message-ID: <649598522.7118059.1396532014718.JavaMail.zimbra@redhat.com>



----- 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
> 


From liran.zelkha at gmail.com  Thu Apr  3 13:36:07 2014
From: liran.zelkha at gmail.com (Liran Zelkha)
Date: Thu, 3 Apr 2014 16:36:07 +0300
Subject: [Engine-devel] vds_dynamic refactor
In-Reply-To: <649598522.7118059.1396532014718.JavaMail.zimbra@redhat.com>
References: <2022363066.4485973.1396522676638.JavaMail.zimbra@redhat.com>
	<1938493531.4486794.1396522818946.JavaMail.zimbra@redhat.com>
	<CAJ3aYLdmuzTs-70N8SXVtB-drwuQAKdrJ-W8YrOVzSU1FT2EAA@mail.gmail.com>
	<1876116111.12394720.1396523579127.JavaMail.zimbra@redhat.com>
	<2064308866.4626560.1396530025984.JavaMail.zimbra@redhat.com>
	<649598522.7118059.1396532014718.JavaMail.zimbra@redhat.com>
Message-ID: <CAJ3aYLeGCBXYU9KZ5VAXtUt2LxEdYFaW-r43UcEStWif2+j97Q@mail.gmail.com>

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 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/20140403/9f891e5a/attachment.html>

From ofrenkel at redhat.com  Thu Apr  3 13:50:44 2014
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Thu, 3 Apr 2014 09:50:44 -0400 (EDT)
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <509028518.3947921.1396487095509.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<08AA403C8399104A89AF710307FA78AE243DD11A@G5W2743.americas.hpqcorp.net>
	<1087291412.5091657.1396259332718.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD16D@G5W2743.americas.hpqcorp.net>
	<1690885238.11367.1396272677929.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD232@G5W2743.americas.hpqcorp.net>
	<434209250.5741543.1396336237695.JavaMail.zimbra@redhat.com>
	<509028518.3947921.1396487095509.JavaMail.zimbra@redhat.com>
Message-ID: <149105224.6831554.1396533044477.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Roy Golan" <rgolan at redhat.com>, "Omer Frenkel"
> <ofrenkel at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>, engine-devel at ovirt.org
> Sent: Thursday, April 3, 2014 4:04:55 AM
> Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt
> 
> Hi all,
> Sorry for joining-in late.
> 
> My comments (according to the db diagram section in
> https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_ISTY8ykDr0I6VY):
> 1) Join vm_numa_node and vds_numa_node to a single table (almost identical),
> one of the FKs can be null.
> 2) No templates reference in the design, need to check it out (it might be
> inherently designed already :-) ); vNode can be linked to a template.
> 3) The reason I want host's NUMA data to be in static is because it updates
> only once (on boot). "engineerically" speaking, dynamic table has a lot of
> traffic and that's not the case for NUMA info. Its feels to me like 'a
> hybrid' of static and dynamic, 3 suggestions comes to mind:
>  - leave it in dynamic (maybe in a separate process).
>  - have a separate flow that updates static.
>  - come up with a third 'vds_on_boot' table (my favorite ;-P ).
> I will get back to you on that.

i dont agree here,
static is user options, there is no flow to automatically update it, and shouldn't be.
this is the exact definition of dynamic for vds.
there is not much updates to this table, getCaps when host moves to up
and there are few fields that are updated from the statistics cycle, which is basically bad.

> 4) vm_vds_numa_node_map is connected to vds_numa_node_statistics, why to
> split the tables (vds_numa_node & vds_numa_node_statistics), going back to
> comment #1, don't we want vNode stats as well, it can be nice to show it :-)
> (have a vNUMA overview of the VM using guest-agent or sth, in a future
> phase).
> 5) IMO vds_cpu_statistics shouldn't include any reference to NUMA, I gave
> that comment in the BE patch as well (remove vds_numa_node_id FK in
> vds_cpu_statistics), for that you should extract cpu_list to a connection
> table (anyway I don't like lists as a text/strings/etc.)
> 6) vm_numatune_nodeset can be removed - the vNode should hold it's pinning
> info; I think that vNode (node according to comment #1) should be connected
> to a connection table that points to vdsNode (also Node table) itself (kinda
> complicated but does the trick - nested link).
> 7) Please add delete-cascade info all over, i.e. what happens when we remove
> a host/vm/node.
> 8) Is it possible to put a db constraint that mapping between vNode and Node
> will be deleted once the VM isn't UP?
> 
> Thanks,
> Gilad.
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan" <rgolan at redhat.com>,
> > "Omer Frenkel" <ofrenkel at redhat.com>,
> > "Chegu Vinod" <chegu_vinod at hp.com>, "Chuan Liao (Jason Liao,
> > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron
> > Fediuck" <dfediuck at redhat.com>, "Shang-Chun Liang (David Liang,
> > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>,
> > "Yaniv Dary" <ydary at redhat.com>, engine-devel at ovirt.org
> > Sent: Tuesday, April 1, 2014 10:10:37 AM
> > Subject: Re: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > > <rgolan at redhat.com>,
> > > "Omer Frenkel" <ofrenkel at redhat.com>,
> > > "Eli Mesika" <emesika at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>
> > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>,
> > > "Doron Fediuck" <dfediuck at redhat.com>,
> > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > > engine-devel at ovirt.org
> > > Sent: Tuesday, April 1, 2014 5:13:34 AM
> > > Subject: RE: Please help us to review our database schema design with
> > > NUMA
> > > feature on ovirt
> > > 
> > > Assemble the related discussions in this mail session.
> > > 
> > > Hi Vinod,
> > > On 3/31/2014 2:38 AM, Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) wrote:
> > > > We put host level NUMA fields in vds_dynamic because these information
> > > > are
> > > > from host itself, and NUMA topology may be changed if the host's
> > > > hardware
> > > > make a change.
> > > Can you please elaborate ? Are you thinking about resource (cpu and/or
> > > memory) hot plug on the host ?
> > > [Bruce] It's not about resource hot plug. In ovirt engine, there is a
> > > scheduled task which will refresh hosts' and vms' information
> > > periodically.
> > > Only the dynamic and statistics data will be updated during the refresh.
> > > So
> > > I think the resource information, such as cpu and/or memory, should be in
> > > dynamic and statistics. And in my understanding, the information in
> > > dynamic
> > > class is the changeable information but with a low varying frequency,
> > > like
> > > cpu topology, libvirt/kernel versions, etc. The information in statistics
> > > class is the information with a high varying frequency, like the usage of
> > > cpu/memory, etc. In my opinion, it's reasonable to put host level NUMA
> > > information in vds_dynamic and host level NUMA statistics information in
> > > vds_statistics.
> > > 
> > > Hi Gilad/Roy/Omer,
> > > I don't know if my understanding is correct. But according to this guess,
> > > I
> > > think it's also reasonable to put vm cpuPin information in vm_static.
> > > Because cpuPin is user configured information, it will not vary
> > > automatically. So we don?t need to refresh this information periodically.
> > > Please correct me if there are any mistakes.
> > > 
> > > Hi Eli,
> > > Sorry for the nag. If my understanding above is correct, I think we
> > > should
> > > still put host level NUMA fields in vds_dynamic/vds_statistics and vm
> > > level
> > > NUMA fields in vm_static. Since vm level NUMA fields are configured by
> > > user
> > > and they will not vary automatically.
> > 
> > Sorry, I had understood from Gilad that the NUMA fields in the host level
> > are
> > relatively static and the NUMA fields on the VM level are dynamic.
> > I have no problem of having hybrid static/dynamic fields for Host/VM as
> > long
> > as it has a good reason and fully documented :-)
> > 
> > 
> > > 
> > > 
> > > Thanks & Best Regards
> > > Shi, Xiao-Lei (Bruce)
> > > 
> > > Hewlett-Packard Co., Ltd.
> > > HP Servers Core Platform Software China
> > > Telephone +86 23 65683093
> > > Mobile +86 18696583447
> > > Email xiao-lei.shi at hp.com
> > > 
> > > 
> > > -----Original Message-----
> > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > Sent: Monday, March 31, 2014 9:31 PM
> > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Roy Golan; Omer Frenkel
> > > Cc: Eli Mesika; Roy Golan; Liao, Chuan (Jason Liao,
> > > HPservers-Core-OE-PSC);
> > > Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > > HPservers-Core-OE-PSC); Yaniv Dary; engine-devel at ovirt.org
> > > Subject: Re: Please help us to review our database schema design with
> > > NUMA
> > > feature on ovirt
> > > 
> > > adding Roy & Omer.
> > > 
> > > why CPU topology is in dynamic?
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > ----- Original Message -----
> > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > > > <rgolan at redhat.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu
> > > > Vinod"
> > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > Sent: Monday, March 31, 2014 3:20:33 PM
> > > > Subject: RE: Please help us to review our database schema design with
> > > > NUMA feature on ovirt
> > > > 
> > > > Thanks Eli.
> > > > I will move the vm level NUMA fields to vm_dynamic, and the related
> > > > database schema will be updated accordingly.
> > > > 
> > > > Thanks & Best Regards
> > > > Shi, Xiao-Lei (Bruce)
> > > > 
> > > > Hewlett-Packard Co., Ltd.
> > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > 
> > > > -----Original Message-----
> > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > Sent: Monday, March 31, 2014 5:49 PM
> > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao,
> > > > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun
> > > > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > > > engine-devel at ovirt.org
> > > > Subject: Re: Please help us to review our database schema design with
> > > > NUMA feature on ovirt
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > <xiao-lei.shi at hp.com>
> > > > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
> > > > > <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>
> > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu
> > > > > Vinod"
> > > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > > > HPservers-Core-OE-PSC)"
> > > > > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > > > > engine-devel at ovirt.org
> > > > > Sent: Monday, March 31, 2014 12:38:04 PM
> > > > > Subject: RE: Please help us to review our database schema design
> > > > > with NUMA feature on ovirt
> > > > > 
> > > > > We put host level NUMA fields in vds_dynamic because these
> > > > > information are from host itself, and NUMA topology may be changed
> > > > > if the host's hardware make a change. NUMA information are similar
> > > > > to the host's cpu topology information like cpu_cores and
> > > > > cpu_sockets which are in vds_dynamic, we refer to this.
> > > > > VM level NUMA fields are configured by user, and actually we
> > > > > originally think they should be in vm_dynamic. But we found that the
> > > > > field of another feature cpuPin which is similar as NUMA feature is
> > > > > in vm_static, so we put vm NUMA fields in vm_static.
> > > > > Do you think we need to put VM level NUMA fields in vm_dynamic?
> > > > 
> > > > I think that in this case we should fix cpuPin to be in vm_dynamic and
> > > > put after that the other NUMA fields in vm_dynamic as well
> > > > 
> > > > > 
> > > > > Thanks & Best Regards
> > > > > Shi, Xiao-Lei (Bruce)
> > > > > 
> > > > > Hewlett-Packard Co., Ltd.
> > > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > > > Sent: Monday, March 31, 2014 5:22 PM
> > > > > To: Eli Mesika; Roy Golan
> > > > > Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason
> > > > > Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang,
> > > > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > > > > engine-devel at ovirt.org
> > > > > Subject: Re: Please help us to review our database schema design
> > > > > with NUMA feature on ovirt
> > > > > 
> > > > > +1
> > > > > 
> > > > > IMO: vds data should reside in static VM need to think about it.
> > > > > 
> > > > > Roy?
> > > > > 
> > > > > Thanks,
> > > > > Gilad.
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > <xiao-lei.shi at hp.com>
> > > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Gilad
> > > > > > Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > <chegu_vinod at hp.com>,
> > > > > > "Shang-Chun Liang (David Liang,
> > > > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > > Sent: Monday, March 31, 2014 12:12:50 PM
> > > > > > Subject: Re: Please help us to review our database schema design
> > > > > > with NUMA feature on ovirt
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > <chuan.liao at hp.com>,
> > > > > > > "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > > <chegu_vinod at hp.com>,
> > > > > > > "Shang-Chun Liang (David Liang,
> > > > > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > > > Sent: Monday, March 31, 2014 8:56:20 AM
> > > > > > > Subject: RE: Please help us to review our database schema design
> > > > > > > with NUMA feature on ovirt
> > > > > > > 
> > > > > > > Include the devel group.
> > > > > > > Thanks Eli for the quick responses for our first design and
> > > > > > > sorry for the nag.
> > > > > > > We appreciate any of the comments for our database design and
> > > > > > > will follow the design to do the implementation if no more
> > > > > > > comments.
> > > > > > >  http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > > 
> > > > > > Seems OK for me except an unanswered question I had asked in my
> > > > > > first review
> > > > > > :
> > > > > > 
> > > > > > Why in the Host level NUMA fields are added to vds_dynamic while
> > > > > > in the VM level it is added to vm_static ???
> > > > > > I would expect it to be in both on static or dynamic , can you
> > > > > > please explain ? Thanks
> > > > > > 
> > > > > > > 
> > > > > > > Thanks & Best Regards
> > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > 
> > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > > Sent: Friday, March 28, 2014 1:30 PM
> > > > > > > To: 'Eli Mesika'
> > > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
> > > > > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun (David
> > > > > > > Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > > Subject: RE: Please help us to review our database schema design
> > > > > > > with NUMA feature on ovirt
> > > > > > > 
> > > > > > > Hi Eli,
> > > > > > > 
> > > > > > > After the UX design meeting, we did some modification for the
> > > > > > > database schema, and merged some update according to your last
> > > > > > > review
> > > > > > > comments.
> > > > > > > Now the document has been posted on ovirt wikipage, could you
> > > > > > > help to review the database design again:
> > > > > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > > > 
> > > > > > > 
> > > > > > > Thanks & Best Regards
> > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > 
> > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > 65683093 Mobile
> > > > > > > +86
> > > > > > > 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > 
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > > Sent: Monday, March 24, 2014 6:24 PM
> > > > > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
> > > > > > > Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun (David
> > > > > > > Liang, HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > > Subject: Re: Please help us to review our database schema design
> > > > > > > with NUMA feature on ovirt
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason
> > > > > > > > Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > > <shangchun.liang at hp.com>
> > > > > > > > Sent: Monday, March 24, 2014 11:23:39 AM
> > > > > > > > Subject: RE: Please help us to review our database schema
> > > > > > > > design with NUMA feature on ovirt
> > > > > > > > 
> > > > > > > > Hi Eli,
> > > > > > > > 
> > > > > > > > Thanks for your comments.
> > > > > > > > I have updated the document according to your comments except
> > > > > > > > the below
> > > > > > > > one:
> > > > > > > > Missing from here are 2 issues:
> > > > > > > > 
> > > > > > > > 1) Impact on the search engine, which new columns are
> > > > > > > > search-able and which changes are planned in the search engine
> > > > > > > > code to enable that
> > > > > > > > 
> > > > > > > > 2) Impact on engine-reports, are those changed planned to be
> > > > > > > > exposed to the engine data warehouse and required new/modified
> > > > > > > > reports?
> > > > > > > > 
> > > > > > > > Could you tell us more detailed information about the modules
> > > > > > > > you mentioned above? I mean "search engine" and
> > > > > > > > "engine-reports". I think we missed these two parts in our
> > > > > > > > previous
> > > > > > > > investigation.
> > > > > > > > I just find org.ovirt.engine.core.bll.SearchQuery, is that the
> > > > > > > > right object for search engine?
> > > > > > > 
> > > > > > > Yes, actually when you are opening the admin UI, there are TABs
> > > > > > > for each entity , i.e. Data Center, Cluster, Host etc.
> > > > > > > In each, you can see a text-box in which you can search for by
> > > > > > > writing a search expression My question is
> > > > > > >    1) What is the impact of your work on the search on the Fost
> > > > > > >    and
> > > > > > >    VM
> > > > > > >    TABs
> > > > > > >       a) Are there any fields that are supported now in the
> > > > > > >       search
> > > > > > >       expression
> > > > > > >       and should pop-up when you write the expression by the
> > > > > > >       auto-completion
> > > > > > >       mechanism ?
> > > > > > >       b) Are there any added columns displayed in the result of
> > > > > > >       such
> > > > > > >       a
> > > > > > >       search
> > > > > > >       in the grid ?
> > > > > > > 
> > > > > > > > How about the engine-reports, could you give us some hints,
> > > > > > > > like the code location and any more detailed information that
> > > > > > > > we can start more investigation?
> > > > > > > 
> > > > > > > CCing Yaniv D who is in charge of the reports/dwh module Yaniv,
> > > > > > > any planned work for adding Numa features to Host/VM in the
> > > > > > > reports side ?
> > > > > > > 
> > > > > > > Thanks
> > > > > > > 
> > > > > > > > 
> > > > > > > > Thanks & Best Regards
> > > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > > 
> > > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > > 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > > > Sent: Sunday, March 23, 2014 4:44 PM
> > > > > > > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > > > > > > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang,
> > > > > > > > Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei
> > > > > > > > (Bruce, HP
> > > > > > > > Servers-PSC-CQ)
> > > > > > > > Subject: Re: Please help us to review our database schema
> > > > > > > > design with NUMA feature on ovirt
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > > > <chuan.liao at hp.com>
> > > > > > > > > To: emesika at redhat.com
> > > > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP
> > > > > > > > > Servers-PSC-CQ)"
> > > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > > > > > > > Subject: Please help us to review our database schema design
> > > > > > > > > with NUMA feature on ovirt
> > > > > > > > > 
> > > > > > > > > Hi Eli,
> > > > > > > > > 
> > > > > > > > > Please help us to review our database schema design with
> > > > > > > > > NUMA feature on ovirt
> > > > > > > > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWA
> > > > > > > > > cyQo_IST
> > > > > > > > > Y8
> > > > > > > > > ykDr0I6VY/edit?usp=sharing
> > > > > > > > > 
> > > > > > > > > Feel free to take comments on document at anywhere
> > > > > > > > 
> > > > > > > > Done, had commented on the document.
> > > > > > > > Eli
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Especially, 5.4 The used interface between engine core and
> > > > > > > > > database(schema)
> > > > > > > > > 
> > > > > > > > > Your approve and your comments with this section will be
> > > > > > > > > much more appreciate for us.
> > > > > > > > > 
> > > > > > > > > Best Regards,
> > > > > > > > > Jason Liao
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> >
> 


From gchaplik at redhat.com  Thu Apr  3 14:11:36 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Thu, 3 Apr 2014 10:11:36 -0400 (EDT)
Subject: [Engine-devel] NUMA support action items
In-Reply-To: <4168C988EBDF2141B4E0B6475B6A73D11F54E1F9@G6W2484.americas.hpqcorp.net>
References: <B63C858E777679458338A30A991BB5240155F681@G1W3780.americas.hpqcorp.net>
	<4168C988EBDF2141B4E0B6475B6A73D11F544A1A@G6W2504.americas.hpqcorp.net>
	<93937981.3066150.1395942141978.JavaMail.zimbra@redhat.com>
	<5336570C.3050000@hp.com>
	<1155122576.3916140.1396480160698.JavaMail.zimbra@redhat.com>
	<4168C988EBDF2141B4E0B6475B6A73D11F546F48@G6W2504.americas.hpqcorp.net>
	<08AA403C8399104A89AF710307FA78AE243DD5AB@G5W2743.americas.hpqcorp.net>
	<4168C988EBDF2141B4E0B6475B6A73D11F54E1F9@G6W2484.americas.hpqcorp.net>
Message-ID: <730051156.4688323.1396534296942.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Chegu Vinod" <chegu_vinod at hp.com>
> To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> Cc: "Einav Cohen" <ecohen at redhat.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> <shangchun.liang at hp.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, msivak at redhat.com,
> "Da-huai Tang (Gary, MCXS-CQ)" <da-huai.tang at hp.com>, "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim"
> <ehildesh at redhat.com>, "Doron Fediuck" <dfediuck at redhat.com>, sherold at redhat.com, "Alexander Wels"
> <awels at redhat.com>, "Gilad Chaplik" <gchaplik at redhat.com>
> Sent: Thursday, April 3, 2014 3:28:03 PM
> Subject: RE: NUMA support action items
> 
> Hi Bruce,
> 
> The virtual NUMA layout in the guest is a very simple one (not multi-level
> etc). It is generated by qemu+seabios... and there is no relationship with
> the host NUMA node distances etc.  Let us not worry about gathering Virtual
> NUMA node distances for now.
> 
> Vinod
> 

CC'ing devel list as well.

Having said that, I don't see a reason why not to prepare an infrastructure for that (if it's free) for future versions (guest agent will collect vNuma data in some point in time).

Thanks, 
Gilad.

> 
> -----Original Message-----
> From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> Sent: Thursday, April 03, 2014 12:41 AM
> To: Vinod, Chegu
> Cc: Einav Cohen; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
> Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); msivak at redhat.com; Tang,
> Da-huai (Gary, MCXS-CQ); Malini Rao; Eldan Hildesheim; Doron Fediuck;
> sherold at redhat.com; Alexander Wels; Gilad Chaplik
> Subject: RE: NUMA support action items
> 
> Hi Vinod,
> 
> Is it meaningful for us to collect the distance information of vm numa node
> (maybe in future, not now)?
> In my understanding, vm numa topology is a simulation of numa topology, since
> the vcpus are just threads, I don't know how the vm numa node distances are
> calculated in vm. Is there any relationship between the vNode distances and
> host node distances?
> 
> Thanks & Best Regards
> Shi, Xiao-Lei (Bruce)
> 
> Hewlett-Packard Co., Ltd.
> HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile +86
> 18696583447 Email xiao-lei.shi at hp.com
> 
> 
> -----Original Message-----
> From: Vinod, Chegu
> Sent: Thursday, April 03, 2014 7:18 AM
> To: Gilad Chaplik
> Cc: Einav Cohen; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
> Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); msivak at redhat.com; Shi,
> Xiao-Lei (Bruce, HP Servers-PSC-CQ); Tang, Da-huai (Gary, MCXS-CQ); Malini
> Rao; Eldan Hildesheim; Doron Fediuck; sherold at redhat.com; Alexander Wels
> Subject: RE: NUMA support action items
> 
> Not sure what the correct way to do this is....but here is a suggestion.
> 
> Let a given host server diagram shown be very generic...i.e. show the N
> sockets/nodes numbered from 0 thru N-1.  Show the amount of memory and the
> list of CPUs in each of those sockets/nodes.
> Draw a generic Interconnect fabric [box] in between which all the sockets
> connect to....
> 
> Ideally ... Under that host diagram we could show the NUMA node distances in
> text format (as you know this is derived from the "numactl -H" and then
> conveyed from VDSM-> oVIrt engine etc).
> That distance info. will tell the user what the distance between a pair of
> sockets/nodes are (and they can then do what they wish after that :)).
> 
> Vinod
> 
> -----Original Message-----
> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> Sent: Wednesday, April 02, 2014 4:09 PM
> To: Vinod, Chegu
> Cc: Einav Cohen; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
> Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); msivak at redhat.com; Shi,
> Xiao-Lei (Bruce, HP Servers-PSC-CQ); Tang, Da-huai (Gary, MCXS-CQ); Malini
> Rao; Eldan Hildesheim; Doron Fediuck; sherold at redhat.com; Alexander Wels
> Subject: Re: NUMA support action items
> 
> Thank you Vinod for the much elaborate explanation.
> GUI-wise, do you want to show those numbers? maybe for first phase, enough to
> show them via API?
> 
> A thought, According to your example there could be up to 2 distances, so
> maybe the 'closer' nodes can be on the same column or sth; I mean to try an
> illustrate it graphically rather than with numbers (we have enough of those
> :)).
> 
> Thanks,
> Gilad.
> 
> ----- Original Message -----
> > From: "Chegu Vinod" <chegu_vinod at hp.com>
> > To: "Einav Cohen" <ecohen at redhat.com>
> > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Shang-Chun Liang (David Liang,
> > HPservers-Core-OE-PSC)"
> > <shangchun.liang at hp.com>, "Chuan Liao (Jason Liao,
> > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, msivak at redhat.com, "Xiao-Lei
> > Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Da-huai Tang
> > (Gary, MCXS-CQ)"
> > <da-huai.tang at hp.com>, "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim"
> > <ehildesh at redhat.com>, "Doron Fediuck"
> > <dfediuck at redhat.com>, sherold at redhat.com, "Alexander Wels"
> > <awels at redhat.com>
> > Sent: Saturday, March 29, 2014 8:15:56 AM
> > Subject: Re: NUMA support action items
> > 
> > On 3/27/2014 10:42 AM, Einav Cohen wrote:
> > > Hi Vinod, thank you very much for that extra information.
> > >
> > > unfortunately, we are not familiar with what are levels of NUMA
> > > (local socket/node, buddy socket/node, remote socket/
> > > node) and/or what "distance" is - I assume that these are
> > > definitions that are related to the physical layout of the
> > > sockets/cores/nodes/RAM and/or to their physical proximity to each
> > > other, but we will need more detailed explanations if this would
> > > need to be incorporated into the UX design.
> > >
> > > Will you be able to explain it to us / refer us to some material on
> > > that?
> > 
> > Sorry for the delay in response (I was in a conference).
> > 
> > Not sure if the following hi-level explanation would help (I will look
> > for some references in the mean time..or perhaps you can ask someone
> > like Joe Mario in Shak's performance group to explain it to you).
> > 
> > In the smaller NUMA servers each socket is directly connected (i.e.
> > single "hop" away) to any other socket in the server.. This is typical
> > of all 2 socket Intel servers and a vast majority of 4 socket Intel
> > servers.
> > 
> > In some larger NUMA servers a socket could either be directly
> > connected (single "hop" away) to another socket (or) may have to go
> > through an interconnect fabric (like a crossbar fabric agent chip.
> > etc). to get to another socket in the system (i.e. several "hops"
> > away).  The sockets that are directly connected (i.e. single "hop"
> > away) are the buddy sockets...and those that aren't are the remote
> > sockets.  Some call this type of a server as having a multi-level NUMA
> > topology...
> > 
> > The way to decipher all of this is by looking at the NUMA node
> > distance table (I had included a sample of that in the slides that I sent
> > earlier).
> > 
> > For e.g. in the example 4 socket server..where all sockets are just
> > one hop away the node distances are as follows
> > 
> > node distances:
> > node   0   1   2   3
> >    0:  10  21  21  21
> >    1:  21  10  21  21
> >    2:  21  21  10  21
> >    3:  21  21  21  10
> > 
> > Going from node0 to nodes[1-3] (or for that matter any pair of nodes)
> > the node distance is the same. i.e. 2.1x latency
> > 
> > In another example of a different (larger 8 socket server) the node
> > distances looked something like this :
> > 
> > node distances:
> > node   0   1   2   3     4    5    6    7
> >    0:   10  16  30  30  30  30  30  30
> >    1:   16  10  30  30  30  30  30  30
> >    2:   30  30  10  16  30  30  30  30
> >    3:   30  30  16  10  30  30  30  30
> >    4:   30  30  30  30  10  16  30  30
> >    5:   30  30  30  30  16  10  30  30
> >    6:   30  30  30  30  30  30  10  16
> >    7:   30  30  30  30  30  30  16  10
> > 
> > Going from node 0 to node 1 (buddy)  which is just one hop away had a
> > node distance of 1.6x... but going from node 0 to nodes 3-7 meant
> > going through the interconnect fabric and it was expensive i.e. 3x.
> > The nodes
> > 3-7 are the remote nodes for node 0.
> > 
> > HTH
> > Vinod
> > 
> > > Many thanks in advance.
> > >
> > > ----
> > > Regards,
> > > Einav
> > >
> > >
> > > ----- Original Message -----
> > >> From: "Chegu Vinod" <chegu_vinod at hp.com>
> > >> To: "Gilad Chaplik" <gchaplik at redhat.com>, "Shang-Chun Liang (David
> > >> Liang, HPservers-Core-OE-PSC)"
> > >> <shangchun.liang at hp.com>, "Chuan Liao (Jason Liao,
> > >> HPservers-Core-OE-PSC)"
> > >> <chuan.liao at hp.com>, msivak at redhat.com, "Xiao-Lei Shi (Bruce, HP
> > >> Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Da-huai Tang (Gary,
> > >> MCXS-CQ)"
> > >> <da-huai.tang at hp.com>, "Malini Rao" <mrao at redhat.com>, "Eldan
> > >> Hildesheim"
> > >> <ehildesh at redhat.com>
> > >> Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Einav Cohen"
> > >> <ecohen at redhat.com>, sherold at redhat.com, "Alexander Wels"
> > >> <awels at redhat.com>
> > >> Sent: Thursday, March 27, 2014 12:00:51 AM
> > >> Subject: RE: NUMA support action items
> > >>
> > >> Thanks for sharing the UX info.
> > >>
> > >> There is one thing that I forgot to mention in today's morning
> > >> meeting...
> > >>
> > >> There are hosts that will  have one level of NUMA (i.e.   local
> > >> socket/node
> > >> and then  remote socket/node). Most  <= 4 socket hosts belong to
> > >> this category.  (I consider this as the sweet spot servers)
> > >>
> > >> When it comes to larger hosts with 8 sockets and more...there can
> > >> be some hosts with multiple levels of NUMA  (i.e. local
> > >> socket/node,  buddy socket/node, and then remote socket/node).
> > >>
> > >> Pl. see attached.... (the 8 socket prototype system is a HP
> > >> platform...and its actually only showing half of the system...the
> > >> actual system is 16 sockets but has a similar NUMA topology). The
> > >> NUMA  node distances of a given host will provide information about the
> > >> # of levels of NUMA ...
> > >>
> > >> Something to keep in mind when you  folks choose to display the
> > >> host NUMA toplogy in the UX.
> > >>
> > >> Thanks
> > >> Vinod
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > >> Sent: Wednesday, March 26, 2014 9:26 AM
> > >> To: Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Liao,
> > >> Chuan (Jason Liao, HPservers-Core-OE-PSC); msivak at redhat.com; Shi,
> > >> Xiao-Lei (Bruce, HP Servers-PSC-CQ); Vinod, Chegu; Tang, Da-huai
> > >> (Gary, MCXS-CQ); Malini Rao; Eldan Hildesheim
> > >> Cc: Doron Fediuck; Einav Cohen; sherold at redhat.com; Alexander Wels
> > >> Subject: NUMA support action items
> > >>
> > >> Hi All,
> > >>
> > >> First of all I'd like to thank Malini and Eldan for their great
> > >> work, I'm sure we'll have a cool UI thanks to them, and Vinod for great
> > >> insights.
> > >>
> > >> Keep on with the great work :-)
> > >>
> > >> Action items (as I see it) for next couple of weeks (in parasitism
> > >> the
> > >> owner):
> > >>
> > >> 0) Resolve community design comments, and finish design phase
> > >> including sketches (All).
> > >> 1) Finish UX design and sketches (Malini and Eldan, all to assist).
> > >> * focus on VM dialog (biggest gap as I see it).
> > >> * 'default host' topology view, where we don't pin a host.
> > >> * NUMA in cluster level.
> > >> 2) Engine Core API, merge BE patch [1], and prepare patches for
> > >> other APIs (commands (VdcActionType), queries (VdcQueryType),
> > >> including parameter classes).
> > >> note that the actual implementation can be mock-ups of fake NUMA
> > >> entities, in order to start GUI/RESTful development in parallel (HP
> > >> development team).
> > >> 3) Test VDSM API (vdcClient) including very basic benchmarks and
> > >> publish a report (HP development team).
> > >> 4) VDSM - engine core integration (HP development team, Martin and
> > >> Gilad to assist).
> > >> 5) DB scripts and store proc - post maintainer (Eli M) acking the
> > >> design (HP development team, Gilad to assist).
> > >> 6) RESTful API impl - post maintainer (Juan H) acking the design
> > >> (HP development team, Gilad to assist).
> > >> 7) GUI programmatic design and starting implementation - in order
> > >> to start it ASAP, the engine's API should be available ASAP see
> > >> action item #2 (Gilad, assistance from Einav's UX team).
> > >> 8) MOM and KSM integration, continue current thread and reach
> > >> conclusions (HP development team, Martin to assist).
> > >>
> > >> You are more than welcome to comment :-) nothing's carved in stone.
> > >> if I forgot someone, please reply to all and CC him.
> > >>
> > >> Thanks,
> > >> Gilad.
> > >>
> > >> [1] http://gerrit.ovirt.org/#/c/23702/
> > >>
> > > .
> > >
> > 
> > 
> 


From gchaplik at redhat.com  Thu Apr  3 14:13:58 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Thu, 3 Apr 2014 10:13:58 -0400 (EDT)
Subject: [Engine-devel] vds_dynamic refactor
In-Reply-To: <CAJ3aYLeGCBXYU9KZ5VAXtUt2LxEdYFaW-r43UcEStWif2+j97Q@mail.gmail.com>
References: <2022363066.4485973.1396522676638.JavaMail.zimbra@redhat.com>
	<1938493531.4486794.1396522818946.JavaMail.zimbra@redhat.com>
	<CAJ3aYLdmuzTs-70N8SXVtB-drwuQAKdrJ-W8YrOVzSU1FT2EAA@mail.gmail.com>
	<1876116111.12394720.1396523579127.JavaMail.zimbra@redhat.com>
	<2064308866.4626560.1396530025984.JavaMail.zimbra@redhat.com>
	<649598522.7118059.1396532014718.JavaMail.zimbra@redhat.com>
	<CAJ3aYLeGCBXYU9KZ5VAXtUt2LxEdYFaW-r43UcEStWif2+j97Q@mail.gmail.com>
Message-ID: <754141813.4689998.1396534438712.JavaMail.zimbra@redhat.com>

----- 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
> >
> 


From liran.zelkha at gmail.com  Thu Apr  3 14:16:51 2014
From: liran.zelkha at gmail.com (Liran Zelkha)
Date: Thu, 3 Apr 2014 17:16:51 +0300
Subject: [Engine-devel] vds_dynamic refactor
In-Reply-To: <754141813.4689998.1396534438712.JavaMail.zimbra@redhat.com>
References: <2022363066.4485973.1396522676638.JavaMail.zimbra@redhat.com>
	<1938493531.4486794.1396522818946.JavaMail.zimbra@redhat.com>
	<CAJ3aYLdmuzTs-70N8SXVtB-drwuQAKdrJ-W8YrOVzSU1FT2EAA@mail.gmail.com>
	<1876116111.12394720.1396523579127.JavaMail.zimbra@redhat.com>
	<2064308866.4626560.1396530025984.JavaMail.zimbra@redhat.com>
	<649598522.7118059.1396532014718.JavaMail.zimbra@redhat.com>
	<CAJ3aYLeGCBXYU9KZ5VAXtUt2LxEdYFaW-r43UcEStWif2+j97Q@mail.gmail.com>
	<754141813.4689998.1396534438712.JavaMail.zimbra@redhat.com>
Message-ID: <CAJ3aYLe0+V3uC+Zw6WwiWRSQ9bGU9HOD+D8gYNSTnz1S6-jhuA@mail.gmail.com>

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" <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/20140403/156ab178/attachment.html>

From gchaplik at redhat.com  Thu Apr  3 14:18:56 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Thu, 3 Apr 2014 10:18:56 -0400 (EDT)
Subject: [Engine-devel] vds_dynamic refactor
In-Reply-To: <CAJ3aYLe0+V3uC+Zw6WwiWRSQ9bGU9HOD+D8gYNSTnz1S6-jhuA@mail.gmail.com>
References: <2022363066.4485973.1396522676638.JavaMail.zimbra@redhat.com>
	<CAJ3aYLdmuzTs-70N8SXVtB-drwuQAKdrJ-W8YrOVzSU1FT2EAA@mail.gmail.com>
	<1876116111.12394720.1396523579127.JavaMail.zimbra@redhat.com>
	<2064308866.4626560.1396530025984.JavaMail.zimbra@redhat.com>
	<649598522.7118059.1396532014718.JavaMail.zimbra@redhat.com>
	<CAJ3aYLeGCBXYU9KZ5VAXtUt2LxEdYFaW-r43UcEStWif2+j97Q@mail.gmail.com>
	<754141813.4689998.1396534438712.JavaMail.zimbra@redhat.com>
	<CAJ3aYLe0+V3uC+Zw6WwiWRSQ9bGU9HOD+D8gYNSTnz1S6-jhuA@mail.gmail.com>
Message-ID: <233947313.4695035.1396534736194.JavaMail.zimbra@redhat.com>

----- 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
> > > >
> > >
> >
> 


From chegu_vinod at hp.com  Thu Apr  3 14:21:49 2014
From: chegu_vinod at hp.com (Chegu Vinod)
Date: Thu, 03 Apr 2014 07:21:49 -0700
Subject: [Engine-devel] NUMA support action items
In-Reply-To: <730051156.4688323.1396534296942.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB5240155F681@G1W3780.americas.hpqcorp.net>
	<4168C988EBDF2141B4E0B6475B6A73D11F544A1A@G6W2504.americas.hpqcorp.net>
	<93937981.3066150.1395942141978.JavaMail.zimbra@redhat.com>
	<5336570C.3050000@hp.com>
	<1155122576.3916140.1396480160698.JavaMail.zimbra@redhat.com>
	<4168C988EBDF2141B4E0B6475B6A73D11F546F48@G6W2504.americas.hpqcorp.net>
	<08AA403C8399104A89AF710307FA78AE243DD5AB@G5W2743.americas.hpqcorp.net>
	<4168C988EBDF2141B4E0B6475B6A73D11F54E1F9@G6W2484.americas.hpqcorp.net>
	<730051156.4688323.1396534296942.JavaMail.zimbra@redhat.com>
Message-ID: <533D6E7D.3020508@hp.com>

On 4/3/2014 7:11 AM, Gilad Chaplik wrote:
> ----- Original Message -----
>> From: "Chegu Vinod" <chegu_vinod at hp.com>
>> To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
>> Cc: "Einav Cohen" <ecohen at redhat.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
>> <shangchun.liang at hp.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, msivak at redhat.com,
>> "Da-huai Tang (Gary, MCXS-CQ)" <da-huai.tang at hp.com>, "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim"
>> <ehildesh at redhat.com>, "Doron Fediuck" <dfediuck at redhat.com>, sherold at redhat.com, "Alexander Wels"
>> <awels at redhat.com>, "Gilad Chaplik" <gchaplik at redhat.com>
>> Sent: Thursday, April 3, 2014 3:28:03 PM
>> Subject: RE: NUMA support action items
>>
>> Hi Bruce,
>>
>> The virtual NUMA layout in the guest is a very simple one (not multi-level
>> etc). It is generated by qemu+seabios... and there is no relationship with
>> the host NUMA node distances etc.  Let us not worry about gathering Virtual
>> NUMA node distances for now.
>>
>> Vinod
>>
> CC'ing devel list as well.
>
> Having said that, I don't see a reason why not to prepare an infrastructure for that (if it's free) for future versions (guest agent will collect vNuma data in some point in time).

If you think having this Virtual NUMA topology (along with the virtual 
numa node *distance* info.) really helps some future use cases then pl. 
go ahead...

Vinod



>
> Thanks,
> Gilad.
>
>> -----Original Message-----
>> From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
>> Sent: Thursday, April 03, 2014 12:41 AM
>> To: Vinod, Chegu
>> Cc: Einav Cohen; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
>> Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); msivak at redhat.com; Tang,
>> Da-huai (Gary, MCXS-CQ); Malini Rao; Eldan Hildesheim; Doron Fediuck;
>> sherold at redhat.com; Alexander Wels; Gilad Chaplik
>> Subject: RE: NUMA support action items
>>
>> Hi Vinod,
>>
>> Is it meaningful for us to collect the distance information of vm numa node
>> (maybe in future, not now)?
>> In my understanding, vm numa topology is a simulation of numa topology, since
>> the vcpus are just threads, I don't know how the vm numa node distances are
>> calculated in vm. Is there any relationship between the vNode distances and
>> host node distances?
>>
>> Thanks & Best Regards
>> Shi, Xiao-Lei (Bruce)
>>
>> Hewlett-Packard Co., Ltd.
>> HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile +86
>> 18696583447 Email xiao-lei.shi at hp.com
>>
>>
>> -----Original Message-----
>> From: Vinod, Chegu
>> Sent: Thursday, April 03, 2014 7:18 AM
>> To: Gilad Chaplik
>> Cc: Einav Cohen; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
>> Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); msivak at redhat.com; Shi,
>> Xiao-Lei (Bruce, HP Servers-PSC-CQ); Tang, Da-huai (Gary, MCXS-CQ); Malini
>> Rao; Eldan Hildesheim; Doron Fediuck; sherold at redhat.com; Alexander Wels
>> Subject: RE: NUMA support action items
>>
>> Not sure what the correct way to do this is....but here is a suggestion.
>>
>> Let a given host server diagram shown be very generic...i.e. show the N
>> sockets/nodes numbered from 0 thru N-1.  Show the amount of memory and the
>> list of CPUs in each of those sockets/nodes.
>> Draw a generic Interconnect fabric [box] in between which all the sockets
>> connect to....
>>
>> Ideally ... Under that host diagram we could show the NUMA node distances in
>> text format (as you know this is derived from the "numactl -H" and then
>> conveyed from VDSM-> oVIrt engine etc).
>> That distance info. will tell the user what the distance between a pair of
>> sockets/nodes are (and they can then do what they wish after that :)).
>>
>> Vinod
>>
>> -----Original Message-----
>> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
>> Sent: Wednesday, April 02, 2014 4:09 PM
>> To: Vinod, Chegu
>> Cc: Einav Cohen; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
>> Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); msivak at redhat.com; Shi,
>> Xiao-Lei (Bruce, HP Servers-PSC-CQ); Tang, Da-huai (Gary, MCXS-CQ); Malini
>> Rao; Eldan Hildesheim; Doron Fediuck; sherold at redhat.com; Alexander Wels
>> Subject: Re: NUMA support action items
>>
>> Thank you Vinod for the much elaborate explanation.
>> GUI-wise, do you want to show those numbers? maybe for first phase, enough to
>> show them via API?
>>
>> A thought, According to your example there could be up to 2 distances, so
>> maybe the 'closer' nodes can be on the same column or sth; I mean to try an
>> illustrate it graphically rather than with numbers (we have enough of those
>> :)).
>>
>> Thanks,
>> Gilad.
>>
>> ----- Original Message -----
>>> From: "Chegu Vinod" <chegu_vinod at hp.com>
>>> To: "Einav Cohen" <ecohen at redhat.com>
>>> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Shang-Chun Liang (David Liang,
>>> HPservers-Core-OE-PSC)"
>>> <shangchun.liang at hp.com>, "Chuan Liao (Jason Liao,
>>> HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, msivak at redhat.com, "Xiao-Lei
>>> Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Da-huai Tang
>>> (Gary, MCXS-CQ)"
>>> <da-huai.tang at hp.com>, "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim"
>>> <ehildesh at redhat.com>, "Doron Fediuck"
>>> <dfediuck at redhat.com>, sherold at redhat.com, "Alexander Wels"
>>> <awels at redhat.com>
>>> Sent: Saturday, March 29, 2014 8:15:56 AM
>>> Subject: Re: NUMA support action items
>>>
>>> On 3/27/2014 10:42 AM, Einav Cohen wrote:
>>>> Hi Vinod, thank you very much for that extra information.
>>>>
>>>> unfortunately, we are not familiar with what are levels of NUMA
>>>> (local socket/node, buddy socket/node, remote socket/
>>>> node) and/or what "distance" is - I assume that these are
>>>> definitions that are related to the physical layout of the
>>>> sockets/cores/nodes/RAM and/or to their physical proximity to each
>>>> other, but we will need more detailed explanations if this would
>>>> need to be incorporated into the UX design.
>>>>
>>>> Will you be able to explain it to us / refer us to some material on
>>>> that?
>>> Sorry for the delay in response (I was in a conference).
>>>
>>> Not sure if the following hi-level explanation would help (I will look
>>> for some references in the mean time..or perhaps you can ask someone
>>> like Joe Mario in Shak's performance group to explain it to you).
>>>
>>> In the smaller NUMA servers each socket is directly connected (i.e.
>>> single "hop" away) to any other socket in the server.. This is typical
>>> of all 2 socket Intel servers and a vast majority of 4 socket Intel
>>> servers.
>>>
>>> In some larger NUMA servers a socket could either be directly
>>> connected (single "hop" away) to another socket (or) may have to go
>>> through an interconnect fabric (like a crossbar fabric agent chip.
>>> etc). to get to another socket in the system (i.e. several "hops"
>>> away).  The sockets that are directly connected (i.e. single "hop"
>>> away) are the buddy sockets...and those that aren't are the remote
>>> sockets.  Some call this type of a server as having a multi-level NUMA
>>> topology...
>>>
>>> The way to decipher all of this is by looking at the NUMA node
>>> distance table (I had included a sample of that in the slides that I sent
>>> earlier).
>>>
>>> For e.g. in the example 4 socket server..where all sockets are just
>>> one hop away the node distances are as follows
>>>
>>> node distances:
>>> node   0   1   2   3
>>>     0:  10  21  21  21
>>>     1:  21  10  21  21
>>>     2:  21  21  10  21
>>>     3:  21  21  21  10
>>>
>>> Going from node0 to nodes[1-3] (or for that matter any pair of nodes)
>>> the node distance is the same. i.e. 2.1x latency
>>>
>>> In another example of a different (larger 8 socket server) the node
>>> distances looked something like this :
>>>
>>> node distances:
>>> node   0   1   2   3     4    5    6    7
>>>     0:   10  16  30  30  30  30  30  30
>>>     1:   16  10  30  30  30  30  30  30
>>>     2:   30  30  10  16  30  30  30  30
>>>     3:   30  30  16  10  30  30  30  30
>>>     4:   30  30  30  30  10  16  30  30
>>>     5:   30  30  30  30  16  10  30  30
>>>     6:   30  30  30  30  30  30  10  16
>>>     7:   30  30  30  30  30  30  16  10
>>>
>>> Going from node 0 to node 1 (buddy)  which is just one hop away had a
>>> node distance of 1.6x... but going from node 0 to nodes 3-7 meant
>>> going through the interconnect fabric and it was expensive i.e. 3x.
>>> The nodes
>>> 3-7 are the remote nodes for node 0.
>>>
>>> HTH
>>> Vinod
>>>
>>>> Many thanks in advance.
>>>>
>>>> ----
>>>> Regards,
>>>> Einav
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Chegu Vinod" <chegu_vinod at hp.com>
>>>>> To: "Gilad Chaplik" <gchaplik at redhat.com>, "Shang-Chun Liang (David
>>>>> Liang, HPservers-Core-OE-PSC)"
>>>>> <shangchun.liang at hp.com>, "Chuan Liao (Jason Liao,
>>>>> HPservers-Core-OE-PSC)"
>>>>> <chuan.liao at hp.com>, msivak at redhat.com, "Xiao-Lei Shi (Bruce, HP
>>>>> Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Da-huai Tang (Gary,
>>>>> MCXS-CQ)"
>>>>> <da-huai.tang at hp.com>, "Malini Rao" <mrao at redhat.com>, "Eldan
>>>>> Hildesheim"
>>>>> <ehildesh at redhat.com>
>>>>> Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Einav Cohen"
>>>>> <ecohen at redhat.com>, sherold at redhat.com, "Alexander Wels"
>>>>> <awels at redhat.com>
>>>>> Sent: Thursday, March 27, 2014 12:00:51 AM
>>>>> Subject: RE: NUMA support action items
>>>>>
>>>>> Thanks for sharing the UX info.
>>>>>
>>>>> There is one thing that I forgot to mention in today's morning
>>>>> meeting...
>>>>>
>>>>> There are hosts that will  have one level of NUMA (i.e.   local
>>>>> socket/node
>>>>> and then  remote socket/node). Most  <= 4 socket hosts belong to
>>>>> this category.  (I consider this as the sweet spot servers)
>>>>>
>>>>> When it comes to larger hosts with 8 sockets and more...there can
>>>>> be some hosts with multiple levels of NUMA  (i.e. local
>>>>> socket/node,  buddy socket/node, and then remote socket/node).
>>>>>
>>>>> Pl. see attached.... (the 8 socket prototype system is a HP
>>>>> platform...and its actually only showing half of the system...the
>>>>> actual system is 16 sockets but has a similar NUMA topology). The
>>>>> NUMA  node distances of a given host will provide information about the
>>>>> # of levels of NUMA ...
>>>>>
>>>>> Something to keep in mind when you  folks choose to display the
>>>>> host NUMA toplogy in the UX.
>>>>>
>>>>> Thanks
>>>>> Vinod
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
>>>>> Sent: Wednesday, March 26, 2014 9:26 AM
>>>>> To: Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Liao,
>>>>> Chuan (Jason Liao, HPservers-Core-OE-PSC); msivak at redhat.com; Shi,
>>>>> Xiao-Lei (Bruce, HP Servers-PSC-CQ); Vinod, Chegu; Tang, Da-huai
>>>>> (Gary, MCXS-CQ); Malini Rao; Eldan Hildesheim
>>>>> Cc: Doron Fediuck; Einav Cohen; sherold at redhat.com; Alexander Wels
>>>>> Subject: NUMA support action items
>>>>>
>>>>> Hi All,
>>>>>
>>>>> First of all I'd like to thank Malini and Eldan for their great
>>>>> work, I'm sure we'll have a cool UI thanks to them, and Vinod for great
>>>>> insights.
>>>>>
>>>>> Keep on with the great work :-)
>>>>>
>>>>> Action items (as I see it) for next couple of weeks (in parasitism
>>>>> the
>>>>> owner):
>>>>>
>>>>> 0) Resolve community design comments, and finish design phase
>>>>> including sketches (All).
>>>>> 1) Finish UX design and sketches (Malini and Eldan, all to assist).
>>>>> * focus on VM dialog (biggest gap as I see it).
>>>>> * 'default host' topology view, where we don't pin a host.
>>>>> * NUMA in cluster level.
>>>>> 2) Engine Core API, merge BE patch [1], and prepare patches for
>>>>> other APIs (commands (VdcActionType), queries (VdcQueryType),
>>>>> including parameter classes).
>>>>> note that the actual implementation can be mock-ups of fake NUMA
>>>>> entities, in order to start GUI/RESTful development in parallel (HP
>>>>> development team).
>>>>> 3) Test VDSM API (vdcClient) including very basic benchmarks and
>>>>> publish a report (HP development team).
>>>>> 4) VDSM - engine core integration (HP development team, Martin and
>>>>> Gilad to assist).
>>>>> 5) DB scripts and store proc - post maintainer (Eli M) acking the
>>>>> design (HP development team, Gilad to assist).
>>>>> 6) RESTful API impl - post maintainer (Juan H) acking the design
>>>>> (HP development team, Gilad to assist).
>>>>> 7) GUI programmatic design and starting implementation - in order
>>>>> to start it ASAP, the engine's API should be available ASAP see
>>>>> action item #2 (Gilad, assistance from Einav's UX team).
>>>>> 8) MOM and KSM integration, continue current thread and reach
>>>>> conclusions (HP development team, Martin to assist).
>>>>>
>>>>> You are more than welcome to comment :-) nothing's carved in stone.
>>>>> if I forgot someone, please reply to all and CC him.
>>>>>
>>>>> Thanks,
>>>>> Gilad.
>>>>>
>>>>> [1] http://gerrit.ovirt.org/#/c/23702/
>>>>>
>>>> .
>>>>
>>>
> .
>



From ofrenkel at redhat.com  Thu Apr  3 13:45:49 2014
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Thu, 3 Apr 2014 09:45:49 -0400 (EDT)
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <1690885238.11367.1396272677929.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<08AA403C8399104A89AF710307FA78AE243DD026@G5W2743.americas.hpqcorp.net>
	<1718882238.5076978.1396257170731.JavaMail.zimbra@redhat.com>
	<182238414.11560689.1396257704986.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD11A@G5W2743.americas.hpqcorp.net>
	<1087291412.5091657.1396259332718.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD16D@G5W2743.americas.hpqcorp.net>
	<1690885238.11367.1396272677929.JavaMail.zimbra@redhat.com>
Message-ID: <1509425597.6826361.1396532749098.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Roy Golan" <rgolan at redhat.com>, "Omer Frenkel"
> <ofrenkel at redhat.com>
> Cc: "Eli Mesika" <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>, "Chuan Liao (Jason Liao,
> HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> <ydary at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, March 31, 2014 4:31:17 PM
> Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt
> 
> adding Roy & Omer.
> 
> why CPU topology is in dynamic?
> 

the guideline we (try to) follow today is (i know you can find exceptions to this, but this is how it suppose to be):
vm/vds static - user configurable information (whatever you have in add/edit)
vm dynamic - information related to a running instance, the is changed in a somewhat small frequency
vds dynamic - host capabilities, information from the host that doesn't change while the host is up.
statistics - all the rest, mostly statistics, and other fast changing information.

> Thanks,
> Gilad.
> 
> ----- Original Message -----
> > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > To: "Eli Mesika" <emesika at redhat.com>
> > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan" <rgolan at redhat.com>,
> > "Chuan Liao (Jason Liao,
> > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck"
> > <dfediuck at redhat.com>, "Chegu Vinod"
> > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > <ydary at redhat.com>, engine-devel at ovirt.org
> > Sent: Monday, March 31, 2014 3:20:33 PM
> > Subject: RE: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > Thanks Eli.
> > I will move the vm level NUMA fields to vm_dynamic, and the related
> > database
> > schema will be updated accordingly.
> > 
> > Thanks & Best Regards
> > Shi, Xiao-Lei (Bruce)
> > 
> > Hewlett-Packard Co., Ltd.
> > HP Servers Core Platform Software China
> > Telephone +86 23 65683093
> > Mobile +86 18696583447
> > Email xiao-lei.shi at hp.com
> > 
> > -----Original Message-----
> > From: Eli Mesika [mailto:emesika at redhat.com]
> > Sent: Monday, March 31, 2014 5:49 PM
> > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao,
> > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun
> > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; engine-devel at ovirt.org
> > Subject: Re: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
> > > <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>
> > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu Vinod"
> > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > HPservers-Core-OE-PSC)"
> > > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > > engine-devel at ovirt.org
> > > Sent: Monday, March 31, 2014 12:38:04 PM
> > > Subject: RE: Please help us to review our database schema design with
> > > NUMA feature on ovirt
> > > 
> > > We put host level NUMA fields in vds_dynamic because these information
> > > are from host itself, and NUMA topology may be changed if the host's
> > > hardware make a change. NUMA information are similar to the host's cpu
> > > topology information like cpu_cores and cpu_sockets which are in
> > > vds_dynamic, we refer to this.
> > > VM level NUMA fields are configured by user, and actually we
> > > originally think they should be in vm_dynamic. But we found that the
> > > field of another feature cpuPin which is similar as NUMA feature is in
> > > vm_static, so we put vm NUMA fields in vm_static.
> > > Do you think we need to put VM level NUMA fields in vm_dynamic?
> > 
> > I think that in this case we should fix cpuPin to be in vm_dynamic and put
> > after that the other NUMA fields in vm_dynamic as well
> > 
> > > 
> > > Thanks & Best Regards
> > > Shi, Xiao-Lei (Bruce)
> > > 
> > > Hewlett-Packard Co., Ltd.
> > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > 
> > > 
> > > -----Original Message-----
> > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > Sent: Monday, March 31, 2014 5:22 PM
> > > To: Eli Mesika; Roy Golan
> > > Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason Liao,
> > > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun
> > > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; engine-devel at ovirt.org
> > > Subject: Re: Please help us to review our database schema design with
> > > NUMA
> > > feature on ovirt
> > > 
> > > +1
> > > 
> > > IMO: vds data should reside in static
> > > VM need to think about it.
> > > 
> > > Roy?
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > <chuan.liao at hp.com>,
> > > > "Doron Fediuck" <dfediuck at redhat.com>,
> > > > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > > <chegu_vinod at hp.com>,
> > > > "Shang-Chun Liang (David Liang,
> > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > Sent: Monday, March 31, 2014 12:12:50 PM
> > > > Subject: Re: Please help us to review our database schema design with
> > > > NUMA
> > > > feature on ovirt
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > <chuan.liao at hp.com>,
> > > > > "Doron Fediuck" <dfediuck at redhat.com>,
> > > > > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > <chegu_vinod at hp.com>,
> > > > > "Shang-Chun Liang (David Liang,
> > > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > Sent: Monday, March 31, 2014 8:56:20 AM
> > > > > Subject: RE: Please help us to review our database schema design with
> > > > > NUMA
> > > > > feature on ovirt
> > > > > 
> > > > > Include the devel group.
> > > > > Thanks Eli for the quick responses for our first design and sorry for
> > > > > the
> > > > > nag.
> > > > > We appreciate any of the comments for our database design and will
> > > > > follow
> > > > > the
> > > > > design to do the implementation if no more comments.
> > > > >  http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > 
> > > > Seems OK for me except an unanswered question I had asked in my first
> > > > review
> > > > :
> > > > 
> > > > Why in the Host level NUMA fields are added to vds_dynamic while in the
> > > > VM
> > > > level it is added to vm_static ???
> > > > I would expect it to be in both on static or dynamic , can you please
> > > > explain
> > > > ? Thanks
> > > > 
> > > > > 
> > > > > Thanks & Best Regards
> > > > > Shi, Xiao-Lei (Bruce)
> > > > > 
> > > > > Hewlett-Packard Co., Ltd.
> > > > > HP Servers Core Platform Software China
> > > > > Telephone +86 23 65683093
> > > > > Mobile +86 18696583447
> > > > > Email xiao-lei.shi at hp.com
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > Sent: Friday, March 28, 2014 1:30 PM
> > > > > To: 'Eli Mesika'
> > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck;
> > > > > Gilad
> > > > > Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > > > > HPservers-Core-OE-PSC); Yaniv Dary
> > > > > Subject: RE: Please help us to review our database schema design with
> > > > > NUMA
> > > > > feature on ovirt
> > > > > 
> > > > > Hi Eli,
> > > > > 
> > > > > After the UX design meeting, we did some modification for the
> > > > > database
> > > > > schema, and merged some update according to your last review
> > > > > comments.
> > > > > Now the document has been posted on ovirt wikipage, could you help to
> > > > > review
> > > > > the database design again:
> > > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > 
> > > > > 
> > > > > Thanks & Best Regards
> > > > > Shi, Xiao-Lei (Bruce)
> > > > > 
> > > > > Hewlett-Packard Co., Ltd.
> > > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > > Mobile
> > > > > +86
> > > > > 18696583447 Email xiao-lei.shi at hp.com
> > > > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > Sent: Monday, March 24, 2014 6:24 PM
> > > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck;
> > > > > Gilad
> > > > > Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > > > > HPservers-Core-OE-PSC); Yaniv Dary
> > > > > Subject: Re: Please help us to review our database schema design with
> > > > > NUMA
> > > > > feature on ovirt
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > <xiao-lei.shi at hp.com>
> > > > > > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason Liao,
> > > > > > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > "Shang-Chun
> > > > > > Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > <shangchun.liang at hp.com>
> > > > > > Sent: Monday, March 24, 2014 11:23:39 AM
> > > > > > Subject: RE: Please help us to review our database schema design
> > > > > > with
> > > > > > NUMA feature on ovirt
> > > > > > 
> > > > > > Hi Eli,
> > > > > > 
> > > > > > Thanks for your comments.
> > > > > > I have updated the document according to your comments except the
> > > > > > below
> > > > > > one:
> > > > > > Missing from here are 2 issues:
> > > > > > 
> > > > > > 1) Impact on the search engine, which new columns are search-able
> > > > > > and
> > > > > > which changes are planned in the search engine code to enable that
> > > > > > 
> > > > > > 2) Impact on engine-reports, are those changed planned to be
> > > > > > exposed
> > > > > > to the engine data warehouse and required new/modified reports?
> > > > > > 
> > > > > > Could you tell us more detailed information about the modules you
> > > > > > mentioned above? I mean "search engine" and "engine-reports". I
> > > > > > think
> > > > > > we missed these two parts in our previous investigation.
> > > > > > I just find org.ovirt.engine.core.bll.SearchQuery, is that the
> > > > > > right
> > > > > > object for search engine?
> > > > > 
> > > > > Yes, actually when you are opening the admin UI, there are TABs for
> > > > > each
> > > > > entity , i.e. Data Center, Cluster, Host etc.
> > > > > In each, you can see a text-box in which you can search for by
> > > > > writing
> > > > > a
> > > > > search expression My question is
> > > > >    1) What is the impact of your work on the search on the Fost and
> > > > >    VM
> > > > >    TABs
> > > > >       a) Are there any fields that are supported now in the search
> > > > >       expression
> > > > >       and should pop-up when you write the expression by the
> > > > >       auto-completion
> > > > >       mechanism ?
> > > > >       b) Are there any added columns displayed in the result of such
> > > > >       a
> > > > >       search
> > > > >       in the grid ?
> > > > > 
> > > > > > How about the engine-reports, could you give us some hints, like
> > > > > > the
> > > > > > code location and any more detailed information that we can start
> > > > > > more
> > > > > > investigation?
> > > > > 
> > > > > CCing Yaniv D who is in charge of the reports/dwh module Yaniv, any
> > > > > planned
> > > > > work for adding Numa features to Host/VM in the reports side ?
> > > > > 
> > > > > Thanks
> > > > > 
> > > > > > 
> > > > > > Thanks & Best Regards
> > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > 
> > > > > > Hewlett-Packard Co., Ltd.
> > > > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > Sent: Sunday, March 23, 2014 4:44 PM
> > > > > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > > > > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun
> > > > > > (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP
> > > > > > Servers-PSC-CQ)
> > > > > > Subject: Re: Please help us to review our database schema design
> > > > > > with
> > > > > > NUMA feature on ovirt
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > <chuan.liao at hp.com>
> > > > > > > To: emesika at redhat.com
> > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP
> > > > > > > Servers-PSC-CQ)"
> > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > > > > > Subject: Please help us to review our database schema design with
> > > > > > > NUMA feature on ovirt
> > > > > > > 
> > > > > > > Hi Eli,
> > > > > > > 
> > > > > > > Please help us to review our database schema design with NUMA
> > > > > > > feature on ovirt
> > > > > > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_IST
> > > > > > > Y8
> > > > > > > ykDr0I6VY/edit?usp=sharing
> > > > > > > 
> > > > > > > Feel free to take comments on document at anywhere
> > > > > > 
> > > > > > Done, had commented on the document.
> > > > > > Eli
> > > > > > 
> > > > > > > 
> > > > > > > Especially, 5.4 The used interface between engine core and
> > > > > > > database(schema)
> > > > > > > 
> > > > > > > Your approve and your comments with this section will be much
> > > > > > > more
> > > > > > > appreciate for us.
> > > > > > > 
> > > > > > > Best Regards,
> > > > > > > Jason Liao
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From gchaplik at redhat.com  Thu Apr  3 14:23:42 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Thu, 3 Apr 2014 10:23:42 -0400 (EDT)
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <958066730.7128865.1396533098982.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<182238414.11560689.1396257704986.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD11A@G5W2743.americas.hpqcorp.net>
	<1087291412.5091657.1396259332718.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD16D@G5W2743.americas.hpqcorp.net>
	<1690885238.11367.1396272677929.JavaMail.zimbra@redhat.com>
	<1509425597.6826361.1396532749098.JavaMail.zimbra@redhat.com>
	<958066730.7128865.1396533098982.JavaMail.zimbra@redhat.com>
Message-ID: <1953687202.4699783.1396535022319.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Omer Frenkel" <ofrenkel at redhat.com>
> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Roy
> Golan" <rgolan at redhat.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck"
> <dfediuck at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>, engine-devel at ovirt.org
> Sent: Thursday, April 3, 2014 4:51:38 PM
> Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt
> 
> 
> 
> ----- Original Message -----
> > From: "Omer Frenkel" <ofrenkel at redhat.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > Cc: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Roy
> > Golan" <rgolan at redhat.com>, "Eli Mesika"
> > <emesika at redhat.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > <chuan.liao at hp.com>, "Doron Fediuck"
> > <dfediuck at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun
> > Liang (David Liang, HPservers-Core-OE-PSC)"
> > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > engine-devel at ovirt.org
> > Sent: Thursday, April 3, 2014 4:45:49 PM
> > Subject: Re: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Roy
> > > Golan" <rgolan at redhat.com>, "Omer Frenkel"
> > > <ofrenkel at redhat.com>
> > > Cc: "Eli Mesika" <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>,
> > > "Chuan Liao (Jason Liao,
> > > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck"
> > > <dfediuck at redhat.com>, "Chegu Vinod"
> > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > Sent: Monday, March 31, 2014 4:31:17 PM
> > > Subject: Re: Please help us to review our database schema design with
> > > NUMA
> > > feature on ovirt
> > > 
> > > adding Roy & Omer.
> > > 
> > > why CPU topology is in dynamic?
> > > 
> > 
> > the guideline we (try to) follow today is (i know you can find exceptions
> > to
> > this, but this is how it suppose to be):
> > vm/vds static - user configurable information (whatever you have in
> > add/edit)
> > vm dynamic - information related to a running instance, the is changed in a
> > somewhat small frequency
> > vds dynamic - host capabilities, information from the host that doesn't
> > change while the host is up.
> > statistics - all the rest, mostly statistics, and other fast changing
> > information.
> 
> IMO it is a little more complicated and the terms static/dynamic does not
> reflect today the meaning of those terms rather, if engine knows the values
> by itself , this is considered "static" and if it has to ask the VDSM for
> the value then this is considered "dynamic".
> For example "cpu_cores" is a static information but it is stored in
> vds_dynamic since we get the value from VDSM.
> I found those terms very confusing and a good candidate for a serious
> refactoring in future
> 

+1, I've opened another thread about it in devel list, and cc'ed Omer.

> 
> > 
> > > Thanks,
> > > Gilad.
> > > 
> > > ----- Original Message -----
> > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > > > <rgolan at redhat.com>,
> > > > "Chuan Liao (Jason Liao,
> > > > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck"
> > > > <dfediuck at redhat.com>, "Chegu Vinod"
> > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > Sent: Monday, March 31, 2014 3:20:33 PM
> > > > Subject: RE: Please help us to review our database schema design with
> > > > NUMA
> > > > feature on ovirt
> > > > 
> > > > Thanks Eli.
> > > > I will move the vm level NUMA fields to vm_dynamic, and the related
> > > > database
> > > > schema will be updated accordingly.
> > > > 
> > > > Thanks & Best Regards
> > > > Shi, Xiao-Lei (Bruce)
> > > > 
> > > > Hewlett-Packard Co., Ltd.
> > > > HP Servers Core Platform Software China
> > > > Telephone +86 23 65683093
> > > > Mobile +86 18696583447
> > > > Email xiao-lei.shi at hp.com
> > > > 
> > > > -----Original Message-----
> > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > Sent: Monday, March 31, 2014 5:49 PM
> > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao,
> > > > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun
> > > > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > > > engine-devel at ovirt.org
> > > > Subject: Re: Please help us to review our database schema design with
> > > > NUMA
> > > > feature on ovirt
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
> > > > > <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>
> > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu
> > > > > Vinod"
> > > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > > > HPservers-Core-OE-PSC)"
> > > > > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > > > > engine-devel at ovirt.org
> > > > > Sent: Monday, March 31, 2014 12:38:04 PM
> > > > > Subject: RE: Please help us to review our database schema design with
> > > > > NUMA feature on ovirt
> > > > > 
> > > > > We put host level NUMA fields in vds_dynamic because these
> > > > > information
> > > > > are from host itself, and NUMA topology may be changed if the host's
> > > > > hardware make a change. NUMA information are similar to the host's
> > > > > cpu
> > > > > topology information like cpu_cores and cpu_sockets which are in
> > > > > vds_dynamic, we refer to this.
> > > > > VM level NUMA fields are configured by user, and actually we
> > > > > originally think they should be in vm_dynamic. But we found that the
> > > > > field of another feature cpuPin which is similar as NUMA feature is
> > > > > in
> > > > > vm_static, so we put vm NUMA fields in vm_static.
> > > > > Do you think we need to put VM level NUMA fields in vm_dynamic?
> > > > 
> > > > I think that in this case we should fix cpuPin to be in vm_dynamic and
> > > > put
> > > > after that the other NUMA fields in vm_dynamic as well
> > > > 
> > > > > 
> > > > > Thanks & Best Regards
> > > > > Shi, Xiao-Lei (Bruce)
> > > > > 
> > > > > Hewlett-Packard Co., Ltd.
> > > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > > > Sent: Monday, March 31, 2014 5:22 PM
> > > > > To: Eli Mesika; Roy Golan
> > > > > Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason
> > > > > Liao,
> > > > > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang,
> > > > > Shang-Chun
> > > > > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > > > > engine-devel at ovirt.org
> > > > > Subject: Re: Please help us to review our database schema design with
> > > > > NUMA
> > > > > feature on ovirt
> > > > > 
> > > > > +1
> > > > > 
> > > > > IMO: vds data should reside in static
> > > > > VM need to think about it.
> > > > > 
> > > > > Roy?
> > > > > 
> > > > > Thanks,
> > > > > Gilad.
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > <chuan.liao at hp.com>,
> > > > > > "Doron Fediuck" <dfediuck at redhat.com>,
> > > > > > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > <chegu_vinod at hp.com>,
> > > > > > "Shang-Chun Liang (David Liang,
> > > > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > > Sent: Monday, March 31, 2014 12:12:50 PM
> > > > > > Subject: Re: Please help us to review our database schema design
> > > > > > with
> > > > > > NUMA
> > > > > > feature on ovirt
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > <chuan.liao at hp.com>,
> > > > > > > "Doron Fediuck" <dfediuck at redhat.com>,
> > > > > > > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > > <chegu_vinod at hp.com>,
> > > > > > > "Shang-Chun Liang (David Liang,
> > > > > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > > > Sent: Monday, March 31, 2014 8:56:20 AM
> > > > > > > Subject: RE: Please help us to review our database schema design
> > > > > > > with
> > > > > > > NUMA
> > > > > > > feature on ovirt
> > > > > > > 
> > > > > > > Include the devel group.
> > > > > > > Thanks Eli for the quick responses for our first design and sorry
> > > > > > > for
> > > > > > > the
> > > > > > > nag.
> > > > > > > We appreciate any of the comments for our database design and
> > > > > > > will
> > > > > > > follow
> > > > > > > the
> > > > > > > design to do the implementation if no more comments.
> > > > > > >  http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > > 
> > > > > > Seems OK for me except an unanswered question I had asked in my
> > > > > > first
> > > > > > review
> > > > > > :
> > > > > > 
> > > > > > Why in the Host level NUMA fields are added to vds_dynamic while in
> > > > > > the
> > > > > > VM
> > > > > > level it is added to vm_static ???
> > > > > > I would expect it to be in both on static or dynamic , can you
> > > > > > please
> > > > > > explain
> > > > > > ? Thanks
> > > > > > 
> > > > > > > 
> > > > > > > Thanks & Best Regards
> > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > 
> > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > HP Servers Core Platform Software China
> > > > > > > Telephone +86 23 65683093
> > > > > > > Mobile +86 18696583447
> > > > > > > Email xiao-lei.shi at hp.com
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > > Sent: Friday, March 28, 2014 1:30 PM
> > > > > > > To: 'Eli Mesika'
> > > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
> > > > > > > Fediuck;
> > > > > > > Gilad
> > > > > > > Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > > > > > > HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > > Subject: RE: Please help us to review our database schema design
> > > > > > > with
> > > > > > > NUMA
> > > > > > > feature on ovirt
> > > > > > > 
> > > > > > > Hi Eli,
> > > > > > > 
> > > > > > > After the UX design meeting, we did some modification for the
> > > > > > > database
> > > > > > > schema, and merged some update according to your last review
> > > > > > > comments.
> > > > > > > Now the document has been posted on ovirt wikipage, could you
> > > > > > > help
> > > > > > > to
> > > > > > > review
> > > > > > > the database design again:
> > > > > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > > > 
> > > > > > > 
> > > > > > > Thanks & Best Regards
> > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > 
> > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > > > > Mobile
> > > > > > > +86
> > > > > > > 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > 
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > > Sent: Monday, March 24, 2014 6:24 PM
> > > > > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
> > > > > > > Fediuck;
> > > > > > > Gilad
> > > > > > > Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > > > > > > HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > > Subject: Re: Please help us to review our database schema design
> > > > > > > with
> > > > > > > NUMA
> > > > > > > feature on ovirt
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason Liao,
> > > > > > > > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > > > "Shang-Chun
> > > > > > > > Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > > <shangchun.liang at hp.com>
> > > > > > > > Sent: Monday, March 24, 2014 11:23:39 AM
> > > > > > > > Subject: RE: Please help us to review our database schema
> > > > > > > > design
> > > > > > > > with
> > > > > > > > NUMA feature on ovirt
> > > > > > > > 
> > > > > > > > Hi Eli,
> > > > > > > > 
> > > > > > > > Thanks for your comments.
> > > > > > > > I have updated the document according to your comments except
> > > > > > > > the
> > > > > > > > below
> > > > > > > > one:
> > > > > > > > Missing from here are 2 issues:
> > > > > > > > 
> > > > > > > > 1) Impact on the search engine, which new columns are
> > > > > > > > search-able
> > > > > > > > and
> > > > > > > > which changes are planned in the search engine code to enable
> > > > > > > > that
> > > > > > > > 
> > > > > > > > 2) Impact on engine-reports, are those changed planned to be
> > > > > > > > exposed
> > > > > > > > to the engine data warehouse and required new/modified reports?
> > > > > > > > 
> > > > > > > > Could you tell us more detailed information about the modules
> > > > > > > > you
> > > > > > > > mentioned above? I mean "search engine" and "engine-reports". I
> > > > > > > > think
> > > > > > > > we missed these two parts in our previous investigation.
> > > > > > > > I just find org.ovirt.engine.core.bll.SearchQuery, is that the
> > > > > > > > right
> > > > > > > > object for search engine?
> > > > > > > 
> > > > > > > Yes, actually when you are opening the admin UI, there are TABs
> > > > > > > for
> > > > > > > each
> > > > > > > entity , i.e. Data Center, Cluster, Host etc.
> > > > > > > In each, you can see a text-box in which you can search for by
> > > > > > > writing
> > > > > > > a
> > > > > > > search expression My question is
> > > > > > >    1) What is the impact of your work on the search on the Fost
> > > > > > >    and
> > > > > > >    VM
> > > > > > >    TABs
> > > > > > >       a) Are there any fields that are supported now in the
> > > > > > >       search
> > > > > > >       expression
> > > > > > >       and should pop-up when you write the expression by the
> > > > > > >       auto-completion
> > > > > > >       mechanism ?
> > > > > > >       b) Are there any added columns displayed in the result of
> > > > > > >       such
> > > > > > >       a
> > > > > > >       search
> > > > > > >       in the grid ?
> > > > > > > 
> > > > > > > > How about the engine-reports, could you give us some hints,
> > > > > > > > like
> > > > > > > > the
> > > > > > > > code location and any more detailed information that we can
> > > > > > > > start
> > > > > > > > more
> > > > > > > > investigation?
> > > > > > > 
> > > > > > > CCing Yaniv D who is in charge of the reports/dwh module Yaniv,
> > > > > > > any
> > > > > > > planned
> > > > > > > work for adding Numa features to Host/VM in the reports side ?
> > > > > > > 
> > > > > > > Thanks
> > > > > > > 
> > > > > > > > 
> > > > > > > > Thanks & Best Regards
> > > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > > 
> > > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > > HP Servers Core Platform Software China Telephone +86 23
> > > > > > > > 65683093
> > > > > > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > > > Sent: Sunday, March 23, 2014 4:44 PM
> > > > > > > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > > > > > > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang,
> > > > > > > > Shang-Chun
> > > > > > > > (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP
> > > > > > > > Servers-PSC-CQ)
> > > > > > > > Subject: Re: Please help us to review our database schema
> > > > > > > > design
> > > > > > > > with
> > > > > > > > NUMA feature on ovirt
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > > > <chuan.liao at hp.com>
> > > > > > > > > To: emesika at redhat.com
> > > > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP
> > > > > > > > > Servers-PSC-CQ)"
> > > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > > > > > > > Subject: Please help us to review our database schema design
> > > > > > > > > with
> > > > > > > > > NUMA feature on ovirt
> > > > > > > > > 
> > > > > > > > > Hi Eli,
> > > > > > > > > 
> > > > > > > > > Please help us to review our database schema design with NUMA
> > > > > > > > > feature on ovirt
> > > > > > > > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_IST
> > > > > > > > > Y8
> > > > > > > > > ykDr0I6VY/edit?usp=sharing
> > > > > > > > > 
> > > > > > > > > Feel free to take comments on document at anywhere
> > > > > > > > 
> > > > > > > > Done, had commented on the document.
> > > > > > > > Eli
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Especially, 5.4 The used interface between engine core and
> > > > > > > > > database(schema)
> > > > > > > > > 
> > > > > > > > > Your approve and your comments with this section will be much
> > > > > > > > > more
> > > > > > > > > appreciate for us.
> > > > > > > > > 
> > > > > > > > > Best Regards,
> > > > > > > > > Jason Liao
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From emesika at redhat.com  Thu Apr  3 13:51:38 2014
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 3 Apr 2014 09:51:38 -0400 (EDT)
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <1509425597.6826361.1396532749098.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<1718882238.5076978.1396257170731.JavaMail.zimbra@redhat.com>
	<182238414.11560689.1396257704986.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD11A@G5W2743.americas.hpqcorp.net>
	<1087291412.5091657.1396259332718.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD16D@G5W2743.americas.hpqcorp.net>
	<1690885238.11367.1396272677929.JavaMail.zimbra@redhat.com>
	<1509425597.6826361.1396532749098.JavaMail.zimbra@redhat.com>
Message-ID: <958066730.7128865.1396533098982.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Omer Frenkel" <ofrenkel at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Roy Golan" <rgolan at redhat.com>, "Eli Mesika"
> <emesika at redhat.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck"
> <dfediuck at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>, engine-devel at ovirt.org
> Sent: Thursday, April 3, 2014 4:45:49 PM
> Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt
> 
> 
> 
> ----- Original Message -----
> > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Roy
> > Golan" <rgolan at redhat.com>, "Omer Frenkel"
> > <ofrenkel at redhat.com>
> > Cc: "Eli Mesika" <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>,
> > "Chuan Liao (Jason Liao,
> > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck"
> > <dfediuck at redhat.com>, "Chegu Vinod"
> > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > <ydary at redhat.com>, engine-devel at ovirt.org
> > Sent: Monday, March 31, 2014 4:31:17 PM
> > Subject: Re: Please help us to review our database schema design with NUMA
> > feature on ovirt
> > 
> > adding Roy & Omer.
> > 
> > why CPU topology is in dynamic?
> > 
> 
> the guideline we (try to) follow today is (i know you can find exceptions to
> this, but this is how it suppose to be):
> vm/vds static - user configurable information (whatever you have in add/edit)
> vm dynamic - information related to a running instance, the is changed in a
> somewhat small frequency
> vds dynamic - host capabilities, information from the host that doesn't
> change while the host is up.
> statistics - all the rest, mostly statistics, and other fast changing
> information.

IMO it is a little more complicated and the terms static/dynamic does not reflect today the meaning of those terms rather, if engine knows the values by itself , this is considered "static" and if it has to ask the VDSM for the value then this is considered "dynamic".
For example "cpu_cores" is a static information but it is stored in vds_dynamic since we get the value from VDSM.
I found those terms very confusing and a good candidate for a serious refactoring in future 


> 
> > Thanks,
> > Gilad.
> > 
> > ----- Original Message -----
> > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > To: "Eli Mesika" <emesika at redhat.com>
> > > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
> > > <rgolan at redhat.com>,
> > > "Chuan Liao (Jason Liao,
> > > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck"
> > > <dfediuck at redhat.com>, "Chegu Vinod"
> > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > Sent: Monday, March 31, 2014 3:20:33 PM
> > > Subject: RE: Please help us to review our database schema design with
> > > NUMA
> > > feature on ovirt
> > > 
> > > Thanks Eli.
> > > I will move the vm level NUMA fields to vm_dynamic, and the related
> > > database
> > > schema will be updated accordingly.
> > > 
> > > Thanks & Best Regards
> > > Shi, Xiao-Lei (Bruce)
> > > 
> > > Hewlett-Packard Co., Ltd.
> > > HP Servers Core Platform Software China
> > > Telephone +86 23 65683093
> > > Mobile +86 18696583447
> > > Email xiao-lei.shi at hp.com
> > > 
> > > -----Original Message-----
> > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > Sent: Monday, March 31, 2014 5:49 PM
> > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao,
> > > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun
> > > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; engine-devel at ovirt.org
> > > Subject: Re: Please help us to review our database schema design with
> > > NUMA
> > > feature on ovirt
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
> > > > <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>
> > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu
> > > > Vinod"
> > > > <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
> > > > HPservers-Core-OE-PSC)"
> > > > <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
> > > > engine-devel at ovirt.org
> > > > Sent: Monday, March 31, 2014 12:38:04 PM
> > > > Subject: RE: Please help us to review our database schema design with
> > > > NUMA feature on ovirt
> > > > 
> > > > We put host level NUMA fields in vds_dynamic because these information
> > > > are from host itself, and NUMA topology may be changed if the host's
> > > > hardware make a change. NUMA information are similar to the host's cpu
> > > > topology information like cpu_cores and cpu_sockets which are in
> > > > vds_dynamic, we refer to this.
> > > > VM level NUMA fields are configured by user, and actually we
> > > > originally think they should be in vm_dynamic. But we found that the
> > > > field of another feature cpuPin which is similar as NUMA feature is in
> > > > vm_static, so we put vm NUMA fields in vm_static.
> > > > Do you think we need to put VM level NUMA fields in vm_dynamic?
> > > 
> > > I think that in this case we should fix cpuPin to be in vm_dynamic and
> > > put
> > > after that the other NUMA fields in vm_dynamic as well
> > > 
> > > > 
> > > > Thanks & Best Regards
> > > > Shi, Xiao-Lei (Bruce)
> > > > 
> > > > Hewlett-Packard Co., Ltd.
> > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> > > > Sent: Monday, March 31, 2014 5:22 PM
> > > > To: Eli Mesika; Roy Golan
> > > > Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason Liao,
> > > > HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun
> > > > (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
> > > > engine-devel at ovirt.org
> > > > Subject: Re: Please help us to review our database schema design with
> > > > NUMA
> > > > feature on ovirt
> > > > 
> > > > +1
> > > > 
> > > > IMO: vds data should reside in static
> > > > VM need to think about it.
> > > > 
> > > > Roy?
> > > > 
> > > > Thanks,
> > > > Gilad.
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > <chuan.liao at hp.com>,
> > > > > "Doron Fediuck" <dfediuck at redhat.com>,
> > > > > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > <chegu_vinod at hp.com>,
> > > > > "Shang-Chun Liang (David Liang,
> > > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > Sent: Monday, March 31, 2014 12:12:50 PM
> > > > > Subject: Re: Please help us to review our database schema design with
> > > > > NUMA
> > > > > feature on ovirt
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > <xiao-lei.shi at hp.com>
> > > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > > Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > <chuan.liao at hp.com>,
> > > > > > "Doron Fediuck" <dfediuck at redhat.com>,
> > > > > > "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
> > > > > > <chegu_vinod at hp.com>,
> > > > > > "Shang-Chun Liang (David Liang,
> > > > > > HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
> > > > > > <ydary at redhat.com>, engine-devel at ovirt.org
> > > > > > Sent: Monday, March 31, 2014 8:56:20 AM
> > > > > > Subject: RE: Please help us to review our database schema design
> > > > > > with
> > > > > > NUMA
> > > > > > feature on ovirt
> > > > > > 
> > > > > > Include the devel group.
> > > > > > Thanks Eli for the quick responses for our first design and sorry
> > > > > > for
> > > > > > the
> > > > > > nag.
> > > > > > We appreciate any of the comments for our database design and will
> > > > > > follow
> > > > > > the
> > > > > > design to do the implementation if no more comments.
> > > > > >  http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > 
> > > > > Seems OK for me except an unanswered question I had asked in my first
> > > > > review
> > > > > :
> > > > > 
> > > > > Why in the Host level NUMA fields are added to vds_dynamic while in
> > > > > the
> > > > > VM
> > > > > level it is added to vm_static ???
> > > > > I would expect it to be in both on static or dynamic , can you please
> > > > > explain
> > > > > ? Thanks
> > > > > 
> > > > > > 
> > > > > > Thanks & Best Regards
> > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > 
> > > > > > Hewlett-Packard Co., Ltd.
> > > > > > HP Servers Core Platform Software China
> > > > > > Telephone +86 23 65683093
> > > > > > Mobile +86 18696583447
> > > > > > Email xiao-lei.shi at hp.com
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > Sent: Friday, March 28, 2014 1:30 PM
> > > > > > To: 'Eli Mesika'
> > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck;
> > > > > > Gilad
> > > > > > Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > > > > > HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > Subject: RE: Please help us to review our database schema design
> > > > > > with
> > > > > > NUMA
> > > > > > feature on ovirt
> > > > > > 
> > > > > > Hi Eli,
> > > > > > 
> > > > > > After the UX design meeting, we did some modification for the
> > > > > > database
> > > > > > schema, and merged some update according to your last review
> > > > > > comments.
> > > > > > Now the document has been posted on ovirt wikipage, could you help
> > > > > > to
> > > > > > review
> > > > > > the database design again:
> > > > > > http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
> > > > > > 
> > > > > > 
> > > > > > Thanks & Best Regards
> > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > 
> > > > > > Hewlett-Packard Co., Ltd.
> > > > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > > > Mobile
> > > > > > +86
> > > > > > 18696583447 Email xiao-lei.shi at hp.com
> > > > > > 
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > Sent: Monday, March 24, 2014 6:24 PM
> > > > > > To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> > > > > > Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck;
> > > > > > Gilad
> > > > > > Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
> > > > > > HPservers-Core-OE-PSC); Yaniv Dary
> > > > > > Subject: Re: Please help us to review our database schema design
> > > > > > with
> > > > > > NUMA
> > > > > > feature on ovirt
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
> > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason Liao,
> > > > > > > HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > > "Shang-Chun
> > > > > > > Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > <shangchun.liang at hp.com>
> > > > > > > Sent: Monday, March 24, 2014 11:23:39 AM
> > > > > > > Subject: RE: Please help us to review our database schema design
> > > > > > > with
> > > > > > > NUMA feature on ovirt
> > > > > > > 
> > > > > > > Hi Eli,
> > > > > > > 
> > > > > > > Thanks for your comments.
> > > > > > > I have updated the document according to your comments except the
> > > > > > > below
> > > > > > > one:
> > > > > > > Missing from here are 2 issues:
> > > > > > > 
> > > > > > > 1) Impact on the search engine, which new columns are search-able
> > > > > > > and
> > > > > > > which changes are planned in the search engine code to enable
> > > > > > > that
> > > > > > > 
> > > > > > > 2) Impact on engine-reports, are those changed planned to be
> > > > > > > exposed
> > > > > > > to the engine data warehouse and required new/modified reports?
> > > > > > > 
> > > > > > > Could you tell us more detailed information about the modules you
> > > > > > > mentioned above? I mean "search engine" and "engine-reports". I
> > > > > > > think
> > > > > > > we missed these two parts in our previous investigation.
> > > > > > > I just find org.ovirt.engine.core.bll.SearchQuery, is that the
> > > > > > > right
> > > > > > > object for search engine?
> > > > > > 
> > > > > > Yes, actually when you are opening the admin UI, there are TABs for
> > > > > > each
> > > > > > entity , i.e. Data Center, Cluster, Host etc.
> > > > > > In each, you can see a text-box in which you can search for by
> > > > > > writing
> > > > > > a
> > > > > > search expression My question is
> > > > > >    1) What is the impact of your work on the search on the Fost and
> > > > > >    VM
> > > > > >    TABs
> > > > > >       a) Are there any fields that are supported now in the search
> > > > > >       expression
> > > > > >       and should pop-up when you write the expression by the
> > > > > >       auto-completion
> > > > > >       mechanism ?
> > > > > >       b) Are there any added columns displayed in the result of
> > > > > >       such
> > > > > >       a
> > > > > >       search
> > > > > >       in the grid ?
> > > > > > 
> > > > > > > How about the engine-reports, could you give us some hints, like
> > > > > > > the
> > > > > > > code location and any more detailed information that we can start
> > > > > > > more
> > > > > > > investigation?
> > > > > > 
> > > > > > CCing Yaniv D who is in charge of the reports/dwh module Yaniv, any
> > > > > > planned
> > > > > > work for adding Numa features to Host/VM in the reports side ?
> > > > > > 
> > > > > > Thanks
> > > > > > 
> > > > > > > 
> > > > > > > Thanks & Best Regards
> > > > > > > Shi, Xiao-Lei (Bruce)
> > > > > > > 
> > > > > > > Hewlett-Packard Co., Ltd.
> > > > > > > HP Servers Core Platform Software China Telephone +86 23 65683093
> > > > > > > Mobile +86 18696583447 Email xiao-lei.shi at hp.com
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Eli Mesika [mailto:emesika at redhat.com]
> > > > > > > Sent: Sunday, March 23, 2014 4:44 PM
> > > > > > > To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
> > > > > > > Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun
> > > > > > > (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP
> > > > > > > Servers-PSC-CQ)
> > > > > > > Subject: Re: Please help us to review our database schema design
> > > > > > > with
> > > > > > > NUMA feature on ovirt
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> > > > > > > > <chuan.liao at hp.com>
> > > > > > > > To: emesika at redhat.com
> > > > > > > > Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
> > > > > > > > <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
> > > > > > > > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
> > > > > > > > <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP
> > > > > > > > Servers-PSC-CQ)"
> > > > > > > > <xiao-lei.shi at hp.com>
> > > > > > > > Sent: Friday, March 21, 2014 10:42:33 AM
> > > > > > > > Subject: Please help us to review our database schema design
> > > > > > > > with
> > > > > > > > NUMA feature on ovirt
> > > > > > > > 
> > > > > > > > Hi Eli,
> > > > > > > > 
> > > > > > > > Please help us to review our database schema design with NUMA
> > > > > > > > feature on ovirt
> > > > > > > > https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_IST
> > > > > > > > Y8
> > > > > > > > ykDr0I6VY/edit?usp=sharing
> > > > > > > > 
> > > > > > > > Feel free to take comments on document at anywhere
> > > > > > > 
> > > > > > > Done, had commented on the document.
> > > > > > > Eli
> > > > > > > 
> > > > > > > > 
> > > > > > > > Especially, 5.4 The used interface between engine core and
> > > > > > > > database(schema)
> > > > > > > > 
> > > > > > > > Your approve and your comments with this section will be much
> > > > > > > > more
> > > > > > > > appreciate for us.
> > > > > > > > 
> > > > > > > > Best Regards,
> > > > > > > > Jason Liao
> > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From liran.zelkha at gmail.com  Thu Apr  3 14:27:56 2014
From: liran.zelkha at gmail.com (Liran Zelkha)
Date: Thu, 3 Apr 2014 17:27:56 +0300
Subject: [Engine-devel] vds_dynamic refactor
In-Reply-To: <233947313.4695035.1396534736194.JavaMail.zimbra@redhat.com>
References: <2022363066.4485973.1396522676638.JavaMail.zimbra@redhat.com>
	<CAJ3aYLdmuzTs-70N8SXVtB-drwuQAKdrJ-W8YrOVzSU1FT2EAA@mail.gmail.com>
	<1876116111.12394720.1396523579127.JavaMail.zimbra@redhat.com>
	<2064308866.4626560.1396530025984.JavaMail.zimbra@redhat.com>
	<649598522.7118059.1396532014718.JavaMail.zimbra@redhat.com>
	<CAJ3aYLeGCBXYU9KZ5VAXtUt2LxEdYFaW-r43UcEStWif2+j97Q@mail.gmail.com>
	<754141813.4689998.1396534438712.JavaMail.zimbra@redhat.com>
	<CAJ3aYLe0+V3uC+Zw6WwiWRSQ9bGU9HOD+D8gYNSTnz1S6-jhuA@mail.gmail.com>
	<233947313.4695035.1396534736194.JavaMail.zimbra@redhat.com>
Message-ID: <CAJ3aYLf0pB=fOSzzRjJu+ijJT8Hb5QSM+Ydn4U11eSrNFh+CNA@mail.gmail.com>

True but that's no reason to have a bad schema
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/20140403/2886e259/attachment.html>

From gchaplik at redhat.com  Thu Apr  3 14:32:38 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Thu, 3 Apr 2014 10:32:38 -0400 (EDT)
Subject: [Engine-devel] NUMA support action items
In-Reply-To: <533D6E7D.3020508@hp.com>
References: <B63C858E777679458338A30A991BB5240155F681@G1W3780.americas.hpqcorp.net>
	<5336570C.3050000@hp.com>
	<1155122576.3916140.1396480160698.JavaMail.zimbra@redhat.com>
	<4168C988EBDF2141B4E0B6475B6A73D11F546F48@G6W2504.americas.hpqcorp.net>
	<08AA403C8399104A89AF710307FA78AE243DD5AB@G5W2743.americas.hpqcorp.net>
	<4168C988EBDF2141B4E0B6475B6A73D11F54E1F9@G6W2484.americas.hpqcorp.net>
	<730051156.4688323.1396534296942.JavaMail.zimbra@redhat.com>
	<533D6E7D.3020508@hp.com>
Message-ID: <302247413.4705606.1396535558811.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Chegu Vinod" <chegu_vinod at hp.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Einav Cohen" <ecohen at redhat.com>, "Shang-Chun
> Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Chuan Liao (Jason Liao,
> HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, msivak at redhat.com, "Da-huai Tang (Gary, MCXS-CQ)"
> <da-huai.tang at hp.com>, "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim" <ehildesh at redhat.com>, "Doron Fediuck"
> <dfediuck at redhat.com>, sherold at redhat.com, "Alexander Wels" <awels at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>
> Sent: Thursday, April 3, 2014 5:21:49 PM
> Subject: Re: NUMA support action items
> 
> On 4/3/2014 7:11 AM, Gilad Chaplik wrote:
> > ----- Original Message -----
> >> From: "Chegu Vinod" <chegu_vinod at hp.com>
> >> To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
> >> Cc: "Einav Cohen" <ecohen at redhat.com>, "Shang-Chun Liang (David Liang,
> >> HPservers-Core-OE-PSC)"
> >> <shangchun.liang at hp.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
> >> <chuan.liao at hp.com>, msivak at redhat.com,
> >> "Da-huai Tang (Gary, MCXS-CQ)" <da-huai.tang at hp.com>, "Malini Rao"
> >> <mrao at redhat.com>, "Eldan Hildesheim"
> >> <ehildesh at redhat.com>, "Doron Fediuck" <dfediuck at redhat.com>,
> >> sherold at redhat.com, "Alexander Wels"
> >> <awels at redhat.com>, "Gilad Chaplik" <gchaplik at redhat.com>
> >> Sent: Thursday, April 3, 2014 3:28:03 PM
> >> Subject: RE: NUMA support action items
> >>
> >> Hi Bruce,
> >>
> >> The virtual NUMA layout in the guest is a very simple one (not multi-level
> >> etc). It is generated by qemu+seabios... and there is no relationship with
> >> the host NUMA node distances etc.  Let us not worry about gathering
> >> Virtual
> >> NUMA node distances for now.
> >>
> >> Vinod
> >>
> > CC'ing devel list as well.
> >
> > Having said that, I don't see a reason why not to prepare an infrastructure
> > for that (if it's free) for future versions (guest agent will collect
> > vNuma data in some point in time).
> 
> If you think having this Virtual NUMA topology (along with the virtual
> numa node *distance* info.) really helps some future use cases then pl.
> go ahead...
> 
> Vinod
> 
> 

I really don't know. but IMO, me as a user that gets some machine (transparent to the fact it's VM or bare metal), it would be very nice to see the NUMA stats outside of the machine.

Thanks, 
Gilad.
> 
> >
> > Thanks,
> > Gilad.
> >
> >> -----Original Message-----
> >> From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
> >> Sent: Thursday, April 03, 2014 12:41 AM
> >> To: Vinod, Chegu
> >> Cc: Einav Cohen; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
> >> Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); msivak at redhat.com; Tang,
> >> Da-huai (Gary, MCXS-CQ); Malini Rao; Eldan Hildesheim; Doron Fediuck;
> >> sherold at redhat.com; Alexander Wels; Gilad Chaplik
> >> Subject: RE: NUMA support action items
> >>
> >> Hi Vinod,
> >>
> >> Is it meaningful for us to collect the distance information of vm numa
> >> node
> >> (maybe in future, not now)?
> >> In my understanding, vm numa topology is a simulation of numa topology,
> >> since
> >> the vcpus are just threads, I don't know how the vm numa node distances
> >> are
> >> calculated in vm. Is there any relationship between the vNode distances
> >> and
> >> host node distances?
> >>
> >> Thanks & Best Regards
> >> Shi, Xiao-Lei (Bruce)
> >>
> >> Hewlett-Packard Co., Ltd.
> >> HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile
> >> +86
> >> 18696583447 Email xiao-lei.shi at hp.com
> >>
> >>
> >> -----Original Message-----
> >> From: Vinod, Chegu
> >> Sent: Thursday, April 03, 2014 7:18 AM
> >> To: Gilad Chaplik
> >> Cc: Einav Cohen; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
> >> Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); msivak at redhat.com; Shi,
> >> Xiao-Lei (Bruce, HP Servers-PSC-CQ); Tang, Da-huai (Gary, MCXS-CQ); Malini
> >> Rao; Eldan Hildesheim; Doron Fediuck; sherold at redhat.com; Alexander Wels
> >> Subject: RE: NUMA support action items
> >>
> >> Not sure what the correct way to do this is....but here is a suggestion.
> >>
> >> Let a given host server diagram shown be very generic...i.e. show the N
> >> sockets/nodes numbered from 0 thru N-1.  Show the amount of memory and the
> >> list of CPUs in each of those sockets/nodes.
> >> Draw a generic Interconnect fabric [box] in between which all the sockets
> >> connect to....
> >>
> >> Ideally ... Under that host diagram we could show the NUMA node distances
> >> in
> >> text format (as you know this is derived from the "numactl -H" and then
> >> conveyed from VDSM-> oVIrt engine etc).
> >> That distance info. will tell the user what the distance between a pair of
> >> sockets/nodes are (and they can then do what they wish after that :)).
> >>
> >> Vinod
> >>
> >> -----Original Message-----
> >> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> >> Sent: Wednesday, April 02, 2014 4:09 PM
> >> To: Vinod, Chegu
> >> Cc: Einav Cohen; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
> >> Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); msivak at redhat.com; Shi,
> >> Xiao-Lei (Bruce, HP Servers-PSC-CQ); Tang, Da-huai (Gary, MCXS-CQ); Malini
> >> Rao; Eldan Hildesheim; Doron Fediuck; sherold at redhat.com; Alexander Wels
> >> Subject: Re: NUMA support action items
> >>
> >> Thank you Vinod for the much elaborate explanation.
> >> GUI-wise, do you want to show those numbers? maybe for first phase, enough
> >> to
> >> show them via API?
> >>
> >> A thought, According to your example there could be up to 2 distances, so
> >> maybe the 'closer' nodes can be on the same column or sth; I mean to try
> >> an
> >> illustrate it graphically rather than with numbers (we have enough of
> >> those
> >> :)).
> >>
> >> Thanks,
> >> Gilad.
> >>
> >> ----- Original Message -----
> >>> From: "Chegu Vinod" <chegu_vinod at hp.com>
> >>> To: "Einav Cohen" <ecohen at redhat.com>
> >>> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Shang-Chun Liang (David
> >>> Liang,
> >>> HPservers-Core-OE-PSC)"
> >>> <shangchun.liang at hp.com>, "Chuan Liao (Jason Liao,
> >>> HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, msivak at redhat.com, "Xiao-Lei
> >>> Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Da-huai Tang
> >>> (Gary, MCXS-CQ)"
> >>> <da-huai.tang at hp.com>, "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim"
> >>> <ehildesh at redhat.com>, "Doron Fediuck"
> >>> <dfediuck at redhat.com>, sherold at redhat.com, "Alexander Wels"
> >>> <awels at redhat.com>
> >>> Sent: Saturday, March 29, 2014 8:15:56 AM
> >>> Subject: Re: NUMA support action items
> >>>
> >>> On 3/27/2014 10:42 AM, Einav Cohen wrote:
> >>>> Hi Vinod, thank you very much for that extra information.
> >>>>
> >>>> unfortunately, we are not familiar with what are levels of NUMA
> >>>> (local socket/node, buddy socket/node, remote socket/
> >>>> node) and/or what "distance" is - I assume that these are
> >>>> definitions that are related to the physical layout of the
> >>>> sockets/cores/nodes/RAM and/or to their physical proximity to each
> >>>> other, but we will need more detailed explanations if this would
> >>>> need to be incorporated into the UX design.
> >>>>
> >>>> Will you be able to explain it to us / refer us to some material on
> >>>> that?
> >>> Sorry for the delay in response (I was in a conference).
> >>>
> >>> Not sure if the following hi-level explanation would help (I will look
> >>> for some references in the mean time..or perhaps you can ask someone
> >>> like Joe Mario in Shak's performance group to explain it to you).
> >>>
> >>> In the smaller NUMA servers each socket is directly connected (i.e.
> >>> single "hop" away) to any other socket in the server.. This is typical
> >>> of all 2 socket Intel servers and a vast majority of 4 socket Intel
> >>> servers.
> >>>
> >>> In some larger NUMA servers a socket could either be directly
> >>> connected (single "hop" away) to another socket (or) may have to go
> >>> through an interconnect fabric (like a crossbar fabric agent chip.
> >>> etc). to get to another socket in the system (i.e. several "hops"
> >>> away).  The sockets that are directly connected (i.e. single "hop"
> >>> away) are the buddy sockets...and those that aren't are the remote
> >>> sockets.  Some call this type of a server as having a multi-level NUMA
> >>> topology...
> >>>
> >>> The way to decipher all of this is by looking at the NUMA node
> >>> distance table (I had included a sample of that in the slides that I sent
> >>> earlier).
> >>>
> >>> For e.g. in the example 4 socket server..where all sockets are just
> >>> one hop away the node distances are as follows
> >>>
> >>> node distances:
> >>> node   0   1   2   3
> >>>     0:  10  21  21  21
> >>>     1:  21  10  21  21
> >>>     2:  21  21  10  21
> >>>     3:  21  21  21  10
> >>>
> >>> Going from node0 to nodes[1-3] (or for that matter any pair of nodes)
> >>> the node distance is the same. i.e. 2.1x latency
> >>>
> >>> In another example of a different (larger 8 socket server) the node
> >>> distances looked something like this :
> >>>
> >>> node distances:
> >>> node   0   1   2   3     4    5    6    7
> >>>     0:   10  16  30  30  30  30  30  30
> >>>     1:   16  10  30  30  30  30  30  30
> >>>     2:   30  30  10  16  30  30  30  30
> >>>     3:   30  30  16  10  30  30  30  30
> >>>     4:   30  30  30  30  10  16  30  30
> >>>     5:   30  30  30  30  16  10  30  30
> >>>     6:   30  30  30  30  30  30  10  16
> >>>     7:   30  30  30  30  30  30  16  10
> >>>
> >>> Going from node 0 to node 1 (buddy)  which is just one hop away had a
> >>> node distance of 1.6x... but going from node 0 to nodes 3-7 meant
> >>> going through the interconnect fabric and it was expensive i.e. 3x.
> >>> The nodes
> >>> 3-7 are the remote nodes for node 0.
> >>>
> >>> HTH
> >>> Vinod
> >>>
> >>>> Many thanks in advance.
> >>>>
> >>>> ----
> >>>> Regards,
> >>>> Einav
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Chegu Vinod" <chegu_vinod at hp.com>
> >>>>> To: "Gilad Chaplik" <gchaplik at redhat.com>, "Shang-Chun Liang (David
> >>>>> Liang, HPservers-Core-OE-PSC)"
> >>>>> <shangchun.liang at hp.com>, "Chuan Liao (Jason Liao,
> >>>>> HPservers-Core-OE-PSC)"
> >>>>> <chuan.liao at hp.com>, msivak at redhat.com, "Xiao-Lei Shi (Bruce, HP
> >>>>> Servers-PSC-CQ)" <xiao-lei.shi at hp.com>, "Da-huai Tang (Gary,
> >>>>> MCXS-CQ)"
> >>>>> <da-huai.tang at hp.com>, "Malini Rao" <mrao at redhat.com>, "Eldan
> >>>>> Hildesheim"
> >>>>> <ehildesh at redhat.com>
> >>>>> Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Einav Cohen"
> >>>>> <ecohen at redhat.com>, sherold at redhat.com, "Alexander Wels"
> >>>>> <awels at redhat.com>
> >>>>> Sent: Thursday, March 27, 2014 12:00:51 AM
> >>>>> Subject: RE: NUMA support action items
> >>>>>
> >>>>> Thanks for sharing the UX info.
> >>>>>
> >>>>> There is one thing that I forgot to mention in today's morning
> >>>>> meeting...
> >>>>>
> >>>>> There are hosts that will  have one level of NUMA (i.e.   local
> >>>>> socket/node
> >>>>> and then  remote socket/node). Most  <= 4 socket hosts belong to
> >>>>> this category.  (I consider this as the sweet spot servers)
> >>>>>
> >>>>> When it comes to larger hosts with 8 sockets and more...there can
> >>>>> be some hosts with multiple levels of NUMA  (i.e. local
> >>>>> socket/node,  buddy socket/node, and then remote socket/node).
> >>>>>
> >>>>> Pl. see attached.... (the 8 socket prototype system is a HP
> >>>>> platform...and its actually only showing half of the system...the
> >>>>> actual system is 16 sockets but has a similar NUMA topology). The
> >>>>> NUMA  node distances of a given host will provide information about the
> >>>>> # of levels of NUMA ...
> >>>>>
> >>>>> Something to keep in mind when you  folks choose to display the
> >>>>> host NUMA toplogy in the UX.
> >>>>>
> >>>>> Thanks
> >>>>> Vinod
> >>>>>
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
> >>>>> Sent: Wednesday, March 26, 2014 9:26 AM
> >>>>> To: Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Liao,
> >>>>> Chuan (Jason Liao, HPservers-Core-OE-PSC); msivak at redhat.com; Shi,
> >>>>> Xiao-Lei (Bruce, HP Servers-PSC-CQ); Vinod, Chegu; Tang, Da-huai
> >>>>> (Gary, MCXS-CQ); Malini Rao; Eldan Hildesheim
> >>>>> Cc: Doron Fediuck; Einav Cohen; sherold at redhat.com; Alexander Wels
> >>>>> Subject: NUMA support action items
> >>>>>
> >>>>> Hi All,
> >>>>>
> >>>>> First of all I'd like to thank Malini and Eldan for their great
> >>>>> work, I'm sure we'll have a cool UI thanks to them, and Vinod for great
> >>>>> insights.
> >>>>>
> >>>>> Keep on with the great work :-)
> >>>>>
> >>>>> Action items (as I see it) for next couple of weeks (in parasitism
> >>>>> the
> >>>>> owner):
> >>>>>
> >>>>> 0) Resolve community design comments, and finish design phase
> >>>>> including sketches (All).
> >>>>> 1) Finish UX design and sketches (Malini and Eldan, all to assist).
> >>>>> * focus on VM dialog (biggest gap as I see it).
> >>>>> * 'default host' topology view, where we don't pin a host.
> >>>>> * NUMA in cluster level.
> >>>>> 2) Engine Core API, merge BE patch [1], and prepare patches for
> >>>>> other APIs (commands (VdcActionType), queries (VdcQueryType),
> >>>>> including parameter classes).
> >>>>> note that the actual implementation can be mock-ups of fake NUMA
> >>>>> entities, in order to start GUI/RESTful development in parallel (HP
> >>>>> development team).
> >>>>> 3) Test VDSM API (vdcClient) including very basic benchmarks and
> >>>>> publish a report (HP development team).
> >>>>> 4) VDSM - engine core integration (HP development team, Martin and
> >>>>> Gilad to assist).
> >>>>> 5) DB scripts and store proc - post maintainer (Eli M) acking the
> >>>>> design (HP development team, Gilad to assist).
> >>>>> 6) RESTful API impl - post maintainer (Juan H) acking the design
> >>>>> (HP development team, Gilad to assist).
> >>>>> 7) GUI programmatic design and starting implementation - in order
> >>>>> to start it ASAP, the engine's API should be available ASAP see
> >>>>> action item #2 (Gilad, assistance from Einav's UX team).
> >>>>> 8) MOM and KSM integration, continue current thread and reach
> >>>>> conclusions (HP development team, Martin to assist).
> >>>>>
> >>>>> You are more than welcome to comment :-) nothing's carved in stone.
> >>>>> if I forgot someone, please reply to all and CC him.
> >>>>>
> >>>>> Thanks,
> >>>>> Gilad.
> >>>>>
> >>>>> [1] http://gerrit.ovirt.org/#/c/23702/
> >>>>>
> >>>> .
> >>>>
> >>>
> > .
> >
> 
> 


From gchaplik at redhat.com  Thu Apr  3 14:33:57 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Thu, 3 Apr 2014 10:33:57 -0400 (EDT)
Subject: [Engine-devel] vds_dynamic refactor
In-Reply-To: <CAJ3aYLf0pB=fOSzzRjJu+ijJT8Hb5QSM+Ydn4U11eSrNFh+CNA@mail.gmail.com>
References: <2022363066.4485973.1396522676638.JavaMail.zimbra@redhat.com>
	<2064308866.4626560.1396530025984.JavaMail.zimbra@redhat.com>
	<649598522.7118059.1396532014718.JavaMail.zimbra@redhat.com>
	<CAJ3aYLeGCBXYU9KZ5VAXtUt2LxEdYFaW-r43UcEStWif2+j97Q@mail.gmail.com>
	<754141813.4689998.1396534438712.JavaMail.zimbra@redhat.com>
	<CAJ3aYLe0+V3uC+Zw6WwiWRSQ9bGU9HOD+D8gYNSTnz1S6-jhuA@mail.gmail.com>
	<233947313.4695035.1396534736194.JavaMail.zimbra@redhat.com>
	<CAJ3aYLf0pB=fOSzzRjJu+ijJT8Hb5QSM+Ydn4U11eSrNFh+CNA@mail.gmail.com>
Message-ID: <1232334338.4708502.1396535637653.JavaMail.zimbra@redhat.com>

> 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? 

> 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/20140403/5e21b559/attachment.html>

From chegu_vinod at hp.com  Thu Apr  3 15:41:02 2014
From: chegu_vinod at hp.com (Chegu Vinod)
Date: Thu, 03 Apr 2014 08:41:02 -0700
Subject: [Engine-devel] Please help us to review our database schema
 design with NUMA feature on ovirt
In-Reply-To: <1922469868.4436271.1396521992628.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015EB9D9@G1W3780.americas.hpqcorp.net>
	<08AA403C8399104A89AF710307FA78AE243DD16D@G5W2743.americas.hpqcorp.net>
	<1690885238.11367.1396272677929.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD232@G5W2743.americas.hpqcorp.net>
	<434209250.5741543.1396336237695.JavaMail.zimbra@redhat.com>
	<509028518.3947921.1396487095509.JavaMail.zimbra@redhat.com>
	<08AA403C8399104A89AF710307FA78AE243DD55D@G5W2743.americas.hpqcorp.net>
	<134006885.6976322.1396511694070.JavaMail.zimbra@redhat.com>
	<1922469868.4436271.1396521992628.JavaMail.zimbra@redhat.com>
Message-ID: <533D810E.3060905@hp.com>

On 4/3/2014 3:46 AM, Gilad Chaplik wrote:
> ----- Original Message -----
>> From: "Eli Mesika" <emesika at redhat.com>
>> To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
>> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan" <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>,
>> "Chegu Vinod" <chegu_vinod at hp.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron
>> Fediuck" <dfediuck at redhat.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>,
>> "Yaniv Dary" <ydary at redhat.com>, engine-devel at ovirt.org
>> Sent: Thursday, April 3, 2014 10:54:54 AM
>> Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt
>>
>>
>>
>> ----- Original Message -----
>>> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
>>> To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
>>> <emesika at redhat.com>
>>> Cc: "Roy Golan" <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>,
>>> "Chegu Vinod" <chegu_vinod at hp.com>, "Chuan
>>> Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron
>>> Fediuck" <dfediuck at redhat.com>, "Shang-Chun
>>> Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>,
>>> "Yaniv Dary" <ydary at redhat.com>,
>>> engine-devel at ovirt.org
>>> Sent: Thursday, April 3, 2014 7:25:11 AM
>>> Subject: RE: Please help us to review our database schema design with NUMA
>>> feature on ovirt
>>>
>>> Hi all,
>>> Please see my comments in line.
>>>
>>> Thanks & Best Regards
>>> Shi, Xiao-Lei (Bruce)
>>>
>>> Hewlett-Packard Co., Ltd.
>>> HP Servers Core Platform Software China
>>> Telephone +86 23 65683093
>>> Mobile +86 18696583447
>>> Email xiao-lei.shi at hp.com
>>>
>>> -----Original Message-----
>>> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
>>> Sent: Thursday, April 03, 2014 9:05 AM
>>> To: Eli Mesika
>>> Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Roy Golan; Omer Frenkel;
>>> Vinod,
>>> Chegu; Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck;
>>> Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
>>> engine-devel at ovirt.org
>>> Subject: Re: Please help us to review our database schema design with NUMA
>>> feature on ovirt
>>>
>>> Hi all,
>>> Sorry for joining-in late.
>>>
>>> My comments (according to the db diagram section in
>>> https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_ISTY8ykDr0I6VY):
>>> 1) Join vm_numa_node and vds_numa_node to a single table (almost
>>> identical),
>>> one of the FKs can be null.
>>> [Bruce] I prefer two tables. Actually host level NUMA node and vm level
>>> NUMA
>>> node are different objects. In my understanding, vm level NUMA node is just
>>> a simulation of host level NUMA node, and host level NUMA node has more
>>> features that not in vm NUMA (like several levels of host NUMA topology
>>> mentioned by Vinod). We need to consider the extensions of host NUMA in the
>>> future.
What future extension are you referring to ?

----
Not sure how relevant this is to the discussion but a little bit of 
background info. here :

A VM's Virtual NUMA node topology is generated by qemu+seabios and is 
based on options specified at the qemu command line (libvirt translates 
the information in the VM's xml file and invokes the qemu command line 
with the correct options)..

Today there is no support in qemu+seabios for generating multiple levels 
of Virtual NUMA. A vast majority of the hosts out there (i.e. 2 socket 
and 4 socket hosts) have only single level of NUMA topology...so this is 
fine for now. (Multi-level NUMA support in the qemu+seabios is a 
slightly different topic...and may (or may not) be pursued as a 
potential future enhancement for qemu.... so for now let us not worry 
about such things & over-engineer in oVirt infrastructure etc. for 
multi-level virtual NUMA nodes etc.)

The values for the node distances in the virtual NUMA topology are 
auto-generated defaults (by qemu+seabios) and has no relation with the 
node distances in the host NUMA topology (which is extracted from the 
ACPI SLIT tables and are supposed to be representative of the underlying 
system fabric's inter node latency capabilities etc).

All the guest OS needs to know is that there are multiple [virtual] NUMA 
nodes and these virtual nodes are a single hop away.... This helps the 
guest to do the right thing with per node data structure 
allocations/locking etc and helps it scale/perform better.

----

As I mentioned in another email thread : If it makes sense for some 
[current/future] use cases to store this virtual NUMA topology info. 
(along with the node distances) somewhere in the oVirt 
infrastructure...then please feel free to do so.




> Let's open the discussion and consider them right now. vNode and Node are the same.


Not really sure what I can say here...

A VM's virtual NUMA node should be sized (i.e. cpu count in the node) no 
larger than the host NUMA node. (Ideally they should be of the same size).

Vinod

> Vinod?
>
>> I agree with Bruce, we have no problem with more tables and constrains should
>> work as expected and remove entries when a Host or VM is removed.
>> I do not like tables that have 2 UUIDs when one of them is null , this is
>> against simple DB normalization
>>
> We are going to maintain and develop this feature. there is a huge overhead in 6 table design in compare to 4.
>
>>>     
>>> 2) No templates reference in the design, need to check it out (it might be
>>> inherently designed already :-) ); vNode can be linked to a template.
>>> [Bruce] IMO, we can consider template as a special vm, our current design
>>> supports to create vNodes in a template just like what it does in a vm.
>> We also store today templates in the VM* tables as special entities defined
>> by the entity_type column
> +1, just need to see that this is taken care of.
>
>>> 3) The reason I want host's NUMA data to be in static is because it updates
>>> only once (on boot). "engineerically" speaking, dynamic table has a lot of
>>> traffic and that's not the case for NUMA info. Its feels to me like 'a
>>> hybrid' of static and dynamic, 3 suggestions comes to mind:
>>>   - leave it in dynamic (maybe in a separate process).
>>>   - have a separate flow that updates static.
>>>   - come up with a third 'vds_on_boot' table (my favorite ;-P ).
>>> I will get back to you on that.
>>> [Bruce] From the onTimer codes in vdsManager (IMO it's the scheduled vds
>>> refresh action), when vds is in normal running status (up status), only
>>> statistics data will be refreshed, so I think maybe dynamic table doesn't
>>> have so much traffic, and the varied data (I mean the data varied through a
>>> power reload, like cpu topology, numa topology, ...etc) can be refreshed
>>> meanwhile.
>>>
> I beg to differ, dynamic table contains a lot of dynamic data:
> host status, used memory and pending resources (maybe more).
> still need to think about it, and get back to you.
>
>>> 4) vm_vds_numa_node_map is connected to vds_numa_node_statistics, why to
>>> split the tables (vds_numa_node & vds_numa_node_statistics), going back to
>>> comment #1, don't we want vNode stats as well, it can be nice to show it
>>> :-)
>>> (have a vNUMA overview of the VM using guest-agent or sth, in a future
>>> phase).
>>> [Bruce] Split the tables is referring to vds_interface
>>> (vds_interface_statistics) and vm_interface (vm_interface_statistics), the
>>> statistics table will be refreshed with a high frequency.
>>> I will update the design to add the vNuma statistics for the future phase,
>>> and according to my feedback in comment #1, vNuma statistics will also in
>>> an
>>> independent table since I think there will be more statistics fields for
>>> host NUMA than for vNuma.
>> Agree with Bruce
> I disagree with both:
> a) don't compare interface to NUMA; interface is a key element in the system.
> b) if you care about high frequency, you can separate the update flows to the same table.
> c) see my comment about 1, overhead.
> d) vNuma = Numa, as I said we can open it now for discussion.
>
>>> 5) IMO vds_cpu_statistics shouldn't include any reference to NUMA, I gave
>>> that comment in the BE patch as well (remove vds_numa_node_id FK in
>>> vds_cpu_statistics), for that you should extract cpu_list to a connection
>>> table (anyway I don't like lists as a text/strings/etc.)
>>> [Bruce] Yes, I agree with you to remove the reference between
>>> vds_cpu_statistics and NUMA. Actually cpu_list is enough for current
>>> requirements. I think the connection table is needed when we consider to
>>> collect more cpu related information and do more cpu related actions in the
>>> future.
> fine, can be done in a later phase. Please document with a bug/RFE enhancement and mark infra in whiteboard.
>
>>> 6) vm_numatune_nodeset can be removed - the vNode should hold it's pinning
>>> info; I think that vNode (node according to comment #1) should be connected
>>> to a connection table that points to vdsNode (also Node table) itself
>>> (kinda
>>> complicated but does the trick - nested link).
>>> [Bruce] Yes, I will remove vm_numatune_nodeset, but according to my
>>> feedback
>>> in comment #1, vm_vds_numa_node_map table will be retained to hold the
>>> references between host nodes and vNode, since they are "m:n" relations.
> repeating my later comment:
>
> correction: no need for another connection table, use vm_vds_numa_node_map with a flag (is_pinned)
>
>>> 7) Please add delete-cascade info all over, i.e. what happens when we
>>> remove
>>> a host/vm/node.
>>> [Bruce] Yes, I will update the design.
> :-) thanks!
>
>>> 8) Is it possible to put a db constraint that mapping between vNode and
>>> Node
>>> will be deleted once the VM isn't UP?
>>> [Bruce] I have a question here. IMO, the mapping between vNode and Node is
>>> a
>>> user configuration, why it is related with the vm status? If the mapping is
>>> deleted, that means the user configuration is deleted. I don't think it's
>>> reasonable.
> see comment #6 (including the correction). there is actual real-life NUMA mapping retrieved by the host, and there is pinning info.
> when a VM is down, the actual real-life mapping can be removed.
>
>>> Thanks,
>>> Gilad.
>>>
>>> ----- Original Message -----
>>>> From: "Eli Mesika" <emesika at redhat.com>
>>>> To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi at hp.com>
>>>> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
>>>> <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>, "Chegu
>>>> Vinod" <chegu_vinod at hp.com>, "Chuan Liao (Jason Liao,
>>>> HPservers-Core-OE-PSC)" <chuan.liao at hp.com>, "Doron Fediuck"
>>>> <dfediuck at redhat.com>, "Shang-Chun Liang (David Liang,
>>>> HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
>>>> <ydary at redhat.com>, engine-devel at ovirt.org
>>>> Sent: Tuesday, April 1, 2014 10:10:37 AM
>>>> Subject: Re: Please help us to review our database schema design with
>>>> NUMA feature on ovirt
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
>>>>> <xiao-lei.shi at hp.com>
>>>>> To: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
>>>>> <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>, "Eli
>>>>> Mesika" <emesika at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>
>>>>> Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
>>>>> <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
>>>>> "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
>>>>> <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
>>>>> engine-devel at ovirt.org
>>>>> Sent: Tuesday, April 1, 2014 5:13:34 AM
>>>>> Subject: RE: Please help us to review our database schema design
>>>>> with NUMA feature on ovirt
>>>>>
>>>>> Assemble the related discussions in this mail session.
>>>>>
>>>>> Hi Vinod,
>>>>> On 3/31/2014 2:38 AM, Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) wrote:
>>>>>> We put host level NUMA fields in vds_dynamic because these
>>>>>> information are from host itself, and NUMA topology may be changed
>>>>>> if the host's hardware make a change.
>>>>> Can you please elaborate ? Are you thinking about resource (cpu
>>>>> and/or
>>>>> memory) hot plug on the host ?
>>>>> [Bruce] It's not about resource hot plug. In ovirt engine, there is
>>>>> a scheduled task which will refresh hosts' and vms' information
>>>>> periodically.
>>>>> Only the dynamic and statistics data will be updated during the
>>>>> refresh. So I think the resource information, such as cpu and/or
>>>>> memory, should be in dynamic and statistics. And in my
>>>>> understanding, the information in dynamic class is the changeable
>>>>> information but with a low varying frequency, like cpu topology,
>>>>> libvirt/kernel versions, etc. The information in statistics class is
>>>>> the information with a high varying frequency, like the usage of
>>>>> cpu/memory, etc. In my opinion, it's reasonable to put host level
>>>>> NUMA information in vds_dynamic and host level NUMA statistics
>>>>> information in vds_statistics.
>>>>>
>>>>> Hi Gilad/Roy/Omer,
>>>>> I don't know if my understanding is correct. But according to this
>>>>> guess, I think it's also reasonable to put vm cpuPin information in
>>>>> vm_static.
>>>>> Because cpuPin is user configured information, it will not vary
>>>>> automatically. So we don?t need to refresh this information
>>>>> periodically.
>>>>> Please correct me if there are any mistakes.
>>>>>
>>>>> Hi Eli,
>>>>> Sorry for the nag. If my understanding above is correct, I think we
>>>>> should still put host level NUMA fields in
>>>>> vds_dynamic/vds_statistics and vm level NUMA fields in vm_static.
>>>>> Since vm level NUMA fields are configured by user and they will not
>>>>> vary
>>>>> automatically.
>>>> Sorry, I had understood from Gilad that the NUMA fields in the host
>>>> level are relatively static and the NUMA fields on the VM level are
>>>> dynamic.
>>>> I have no problem of having hybrid static/dynamic fields for Host/VM
>>>> as long as it has a good reason and fully documented :-)
>>>>
>>>>
>>>>>
>>>>> Thanks & Best Regards
>>>>> Shi, Xiao-Lei (Bruce)
>>>>>
>>>>> Hewlett-Packard Co., Ltd.
>>>>> HP Servers Core Platform Software China Telephone +86 23 65683093
>>>>> Mobile +86 18696583447 Email xiao-lei.shi at hp.com
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
>>>>> Sent: Monday, March 31, 2014 9:31 PM
>>>>> To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Roy Golan; Omer
>>>>> Frenkel
>>>>> Cc: Eli Mesika; Roy Golan; Liao, Chuan (Jason Liao,
>>>>> HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang,
>>>>> Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
>>>>> engine-devel at ovirt.org
>>>>> Subject: Re: Please help us to review our database schema design
>>>>> with NUMA feature on ovirt
>>>>>
>>>>> adding Roy & Omer.
>>>>>
>>>>> why CPU topology is in dynamic?
>>>>>
>>>>> Thanks,
>>>>> Gilad.
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
>>>>>> <xiao-lei.shi at hp.com>
>>>>>> To: "Eli Mesika" <emesika at redhat.com>
>>>>>> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "Roy Golan"
>>>>>> <rgolan at redhat.com>, "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
>>>>>> <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>, "Chegu
>>>>>> Vinod"
>>>>>> <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
>>>>>> HPservers-Core-OE-PSC)" <shangchun.liang at hp.com>, "Yaniv Dary"
>>>>>> <ydary at redhat.com>, engine-devel at ovirt.org
>>>>>> Sent: Monday, March 31, 2014 3:20:33 PM
>>>>>> Subject: RE: Please help us to review our database schema design
>>>>>> with NUMA feature on ovirt
>>>>>>
>>>>>> Thanks Eli.
>>>>>> I will move the vm level NUMA fields to vm_dynamic, and the
>>>>>> related database schema will be updated accordingly.
>>>>>>
>>>>>> Thanks & Best Regards
>>>>>> Shi, Xiao-Lei (Bruce)
>>>>>>
>>>>>> Hewlett-Packard Co., Ltd.
>>>>>> HP Servers Core Platform Software China Telephone +86 23 65683093
>>>>>> Mobile +86 18696583447 Email xiao-lei.shi at hp.com
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Eli Mesika [mailto:emesika at redhat.com]
>>>>>> Sent: Monday, March 31, 2014 5:49 PM
>>>>>> To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
>>>>>> Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao,
>>>>>> HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang,
>>>>>> Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
>>>>>> engine-devel at ovirt.org
>>>>>> Subject: Re: Please help us to review our database schema design
>>>>>> with NUMA feature on ovirt
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
>>>>>>> <xiao-lei.shi at hp.com>
>>>>>>> To: "Gilad Chaplik" <gchaplik at redhat.com>, "Eli Mesika"
>>>>>>> <emesika at redhat.com>, "Roy Golan" <rgolan at redhat.com>
>>>>>>> Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
>>>>>>> <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
>>>>>>> "Chegu Vinod"
>>>>>>> <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
>>>>>>> HPservers-Core-OE-PSC)"
>>>>>>> <shangchun.liang at hp.com>, "Yaniv Dary" <ydary at redhat.com>,
>>>>>>> engine-devel at ovirt.org
>>>>>>> Sent: Monday, March 31, 2014 12:38:04 PM
>>>>>>> Subject: RE: Please help us to review our database schema design
>>>>>>> with NUMA feature on ovirt
>>>>>>>
>>>>>>> We put host level NUMA fields in vds_dynamic because these
>>>>>>> information are from host itself, and NUMA topology may be
>>>>>>> changed if the host's hardware make a change. NUMA information
>>>>>>> are similar to the host's cpu topology information like
>>>>>>> cpu_cores and cpu_sockets which are in vds_dynamic, we refer to
>>>>>>> this.
>>>>>>> VM level NUMA fields are configured by user, and actually we
>>>>>>> originally think they should be in vm_dynamic. But we found that
>>>>>>> the field of another feature cpuPin which is similar as NUMA
>>>>>>> feature is in vm_static, so we put vm NUMA fields in vm_static.
>>>>>>> Do you think we need to put VM level NUMA fields in vm_dynamic?
>>>>>> I think that in this case we should fix cpuPin to be in vm_dynamic
>>>>>> and put after that the other NUMA fields in vm_dynamic as well
>>>>>>
>>>>>>> Thanks & Best Regards
>>>>>>> Shi, Xiao-Lei (Bruce)
>>>>>>>
>>>>>>> Hewlett-Packard Co., Ltd.
>>>>>>> HP Servers Core Platform Software China Telephone +86 23
>>>>>>> 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Gilad Chaplik [mailto:gchaplik at redhat.com]
>>>>>>> Sent: Monday, March 31, 2014 5:22 PM
>>>>>>> To: Eli Mesika; Roy Golan
>>>>>>> Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason
>>>>>>> Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu;
>>>>>>> Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv
>>>>>>> Dary; engine-devel at ovirt.org
>>>>>>> Subject: Re: Please help us to review our database schema design
>>>>>>> with NUMA feature on ovirt
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> IMO: vds data should reside in static VM need to think about it.
>>>>>>>
>>>>>>> Roy?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Gilad.
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Eli Mesika" <emesika at redhat.com>
>>>>>>>> To: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
>>>>>>>> <xiao-lei.shi at hp.com>
>>>>>>>> Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
>>>>>>>> <chuan.liao at hp.com>, "Doron Fediuck" <dfediuck at redhat.com>,
>>>>>>>> "Gilad Chaplik" <gchaplik at redhat.com>, "Chegu Vinod"
>>>>>>>> <chegu_vinod at hp.com>,
>>>>>>>> "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
>>>>>>>> <shangchun.liang at hp.com>, "Yaniv Dary"
>>>>>>>> <ydary at redhat.com>, engine-devel at ovirt.org
>>>>>>>> Sent: Monday, March 31, 2014 12:12:50 PM
>>>>>>>> Subject: Re: Please help us to review our database schema
>>>>>>>> design with NUMA feature on ovirt
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
>>>>>>>>> <xiao-lei.shi at hp.com>
>>>>>>>>> To: "Eli Mesika" <emesika at redhat.com>
>>>>>>>>> Cc: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
>>>>>>>>> <chuan.liao at hp.com>,
>>>>>>>>> "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
>>>>>>>>> <gchaplik at redhat.com>, "Chegu Vinod"
>>>>>>>>> <chegu_vinod at hp.com>,
>>>>>>>>> "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
>>>>>>>>> <shangchun.liang at hp.com>, "Yaniv Dary"
>>>>>>>>> <ydary at redhat.com>, engine-devel at ovirt.org
>>>>>>>>> Sent: Monday, March 31, 2014 8:56:20 AM
>>>>>>>>> Subject: RE: Please help us to review our database schema
>>>>>>>>> design with NUMA feature on ovirt
>>>>>>>>>
>>>>>>>>> Include the devel group.
>>>>>>>>> Thanks Eli for the quick responses for our first design and
>>>>>>>>> sorry for the nag.
>>>>>>>>> We appreciate any of the comments for our database design
>>>>>>>>> and will follow the design to do the implementation if no
>>>>>>>>> more comments.
>>>>>>>>>   
>>>>>>>>> http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
>>>>>>>> Seems OK for me except an unanswered question I had asked in
>>>>>>>> my first review
>>>>>>>> :
>>>>>>>>
>>>>>>>> Why in the Host level NUMA fields are added to vds_dynamic
>>>>>>>> while in the VM level it is added to vm_static ???
>>>>>>>> I would expect it to be in both on static or dynamic , can you
>>>>>>>> please explain ? Thanks
>>>>>>>>
>>>>>>>>> Thanks & Best Regards
>>>>>>>>> Shi, Xiao-Lei (Bruce)
>>>>>>>>>
>>>>>>>>> Hewlett-Packard Co., Ltd.
>>>>>>>>> HP Servers Core Platform Software China Telephone +86 23
>>>>>>>>> 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
>>>>>>>>> Sent: Friday, March 28, 2014 1:30 PM
>>>>>>>>> To: 'Eli Mesika'
>>>>>>>>> Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
>>>>>>>>> Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun
>>>>>>>>> (David Liang, HPservers-Core-OE-PSC); Yaniv Dary
>>>>>>>>> Subject: RE: Please help us to review our database schema
>>>>>>>>> design with NUMA feature on ovirt
>>>>>>>>>
>>>>>>>>> Hi Eli,
>>>>>>>>>
>>>>>>>>> After the UX design meeting, we did some modification for
>>>>>>>>> the database schema, and merged some update according to
>>>>>>>>> your last review comments.
>>>>>>>>> Now the document has been posted on ovirt wikipage, could
>>>>>>>>> you help to review the database design again:
>>>>>>>>> http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks & Best Regards
>>>>>>>>> Shi, Xiao-Lei (Bruce)
>>>>>>>>>
>>>>>>>>> Hewlett-Packard Co., Ltd.
>>>>>>>>> HP Servers Core Platform Software China Telephone +86 23
>>>>>>>>> 65683093 Mobile
>>>>>>>>> +86
>>>>>>>>> 18696583447 Email xiao-lei.shi at hp.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Eli Mesika [mailto:emesika at redhat.com]
>>>>>>>>> Sent: Monday, March 24, 2014 6:24 PM
>>>>>>>>> To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
>>>>>>>>> Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron
>>>>>>>>> Fediuck; Gilad Chaplik; Vinod, Chegu; Liang, Shang-Chun
>>>>>>>>> (David Liang, HPservers-Core-OE-PSC); Yaniv Dary
>>>>>>>>> Subject: Re: Please help us to review our database schema
>>>>>>>>> design with NUMA feature on ovirt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)"
>>>>>>>>>> <xiao-lei.shi at hp.com>
>>>>>>>>>> To: "Eli Mesika" <emesika at redhat.com>, "Chuan Liao (Jason
>>>>>>>>>> Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
>>>>>>>>>> Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
>>>>>>>>>> <gchaplik at redhat.com>, "Chegu Vinod" <chegu_vinod at hp.com>,
>>>>>>>>>> "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)"
>>>>>>>>>> <shangchun.liang at hp.com>
>>>>>>>>>> Sent: Monday, March 24, 2014 11:23:39 AM
>>>>>>>>>> Subject: RE: Please help us to review our database schema
>>>>>>>>>> design with NUMA feature on ovirt
>>>>>>>>>>
>>>>>>>>>> Hi Eli,
>>>>>>>>>>
>>>>>>>>>> Thanks for your comments.
>>>>>>>>>> I have updated the document according to your comments
>>>>>>>>>> except the below
>>>>>>>>>> one:
>>>>>>>>>> Missing from here are 2 issues:
>>>>>>>>>>
>>>>>>>>>> 1) Impact on the search engine, which new columns are
>>>>>>>>>> search-able and which changes are planned in the search
>>>>>>>>>> engine code to enable that
>>>>>>>>>>
>>>>>>>>>> 2) Impact on engine-reports, are those changed planned to
>>>>>>>>>> be exposed to the engine data warehouse and required
>>>>>>>>>> new/modified reports?
>>>>>>>>>>
>>>>>>>>>> Could you tell us more detailed information about the
>>>>>>>>>> modules you mentioned above? I mean "search engine" and
>>>>>>>>>> "engine-reports". I think we missed these two parts in our
>>>>>>>>>> previous investigation.
>>>>>>>>>> I just find org.ovirt.engine.core.bll.SearchQuery, is that
>>>>>>>>>> the right object for search engine?
>>>>>>>>> Yes, actually when you are opening the admin UI, there are
>>>>>>>>> TABs for each entity , i.e. Data Center, Cluster, Host etc.
>>>>>>>>> In each, you can see a text-box in which you can search for
>>>>>>>>> by writing a search expression My question is
>>>>>>>>>     1) What is the impact of your work on the search on the Fost
>>>>>>>>>     and
>>>>>>>>>     VM
>>>>>>>>>     TABs
>>>>>>>>>        a) Are there any fields that are supported now in the
>>>>>>>>>        search
>>>>>>>>>        expression
>>>>>>>>>        and should pop-up when you write the expression by the
>>>>>>>>>        auto-completion
>>>>>>>>>        mechanism ?
>>>>>>>>>        b) Are there any added columns displayed in the result of
>>>>>>>>>        such
>>>>>>>>>        a
>>>>>>>>>        search
>>>>>>>>>        in the grid ?
>>>>>>>>>
>>>>>>>>>> How about the engine-reports, could you give us some
>>>>>>>>>> hints, like the code location and any more detailed
>>>>>>>>>> information that we can start more investigation?
>>>>>>>>> CCing Yaniv D who is in charge of the reports/dwh module
>>>>>>>>> Yaniv, any planned work for adding Numa features to Host/VM
>>>>>>>>> in the reports side ?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>>> Thanks & Best Regards
>>>>>>>>>> Shi, Xiao-Lei (Bruce)
>>>>>>>>>>
>>>>>>>>>> Hewlett-Packard Co., Ltd.
>>>>>>>>>> HP Servers Core Platform Software China Telephone +86 23
>>>>>>>>>> 65683093 Mobile +86 18696583447 Email xiao-lei.shi at hp.com
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Eli Mesika [mailto:emesika at redhat.com]
>>>>>>>>>> Sent: Sunday, March 23, 2014 4:44 PM
>>>>>>>>>> To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
>>>>>>>>>> Cc: Doron Fediuck; Gilad Chaplik; Vinod, Chegu; Liang,
>>>>>>>>>> Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi,
>>>>>>>>>> Xiao-Lei (Bruce, HP
>>>>>>>>>> Servers-PSC-CQ)
>>>>>>>>>> Subject: Re: Please help us to review our database schema
>>>>>>>>>> design with NUMA feature on ovirt
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)"
>>>>>>>>>>> <chuan.liao at hp.com>
>>>>>>>>>>> To: emesika at redhat.com
>>>>>>>>>>> Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Gilad Chaplik"
>>>>>>>>>>> <gchaplik at redhat.com>, "Chegu Vinod"
>>>>>>>>>>> <chegu_vinod at hp.com>, "Shang-Chun Liang (David Liang,
>>>>>>>>>>> HPservers-Core-OE-PSC)"
>>>>>>>>>>> <shangchun.liang at hp.com>, "Xiao-Lei Shi (Bruce, HP
>>>>>>>>>>> Servers-PSC-CQ)"
>>>>>>>>>>> <xiao-lei.shi at hp.com>
>>>>>>>>>>> Sent: Friday, March 21, 2014 10:42:33 AM
>>>>>>>>>>> Subject: Please help us to review our database schema
>>>>>>>>>>> design with NUMA feature on ovirt
>>>>>>>>>>>
>>>>>>>>>>> Hi Eli,
>>>>>>>>>>>
>>>>>>>>>>> Please help us to review our database schema design with
>>>>>>>>>>> NUMA feature on ovirt
>>>>>>>>>>> https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcm
>>>>>>>>>>> bGWA
>>>>>>>>>>> cyQo_IST
>>>>>>>>>>> Y8
>>>>>>>>>>> ykDr0I6VY/edit?usp=sharing
>>>>>>>>>>>
>>>>>>>>>>> Feel free to take comments on document at anywhere
>>>>>>>>>> Done, had commented on the document.
>>>>>>>>>> Eli
>>>>>>>>>>
>>>>>>>>>>> Especially, 5.4 The used interface between engine core
>>>>>>>>>>> and
>>>>>>>>>>> database(schema)
>>>>>>>>>>>
>>>>>>>>>>> Your approve and your comments with this section will be
>>>>>>>>>>> much more appreciate for us.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Jason Liao
>>>>>>>>>>>
>>>>>>>>>>>
> .
>



From liran.zelkha at gmail.com  Thu Apr  3 16:51:39 2014
From: liran.zelkha at gmail.com (Liran Zelkha)
Date: Thu, 3 Apr 2014 19:51:39 +0300
Subject: [Engine-devel] vds_dynamic refactor
In-Reply-To: <1232334338.4708502.1396535637653.JavaMail.zimbra@redhat.com>
References: <2022363066.4485973.1396522676638.JavaMail.zimbra@redhat.com>
	<2064308866.4626560.1396530025984.JavaMail.zimbra@redhat.com>
	<649598522.7118059.1396532014718.JavaMail.zimbra@redhat.com>
	<CAJ3aYLeGCBXYU9KZ5VAXtUt2LxEdYFaW-r43UcEStWif2+j97Q@mail.gmail.com>
	<754141813.4689998.1396534438712.JavaMail.zimbra@redhat.com>
	<CAJ3aYLe0+V3uC+Zw6WwiWRSQ9bGU9HOD+D8gYNSTnz1S6-jhuA@mail.gmail.com>
	<233947313.4695035.1396534736194.JavaMail.zimbra@redhat.com>
	<CAJ3aYLf0pB=fOSzzRjJu+ijJT8Hb5QSM+Ydn4U11eSrNFh+CNA@mail.gmail.com>
	<1232334338.4708502.1396535637653.JavaMail.zimbra@redhat.com>
Message-ID: <CAJ3aYLdLorX0wsjU1f0kspg2NEjRojwpF-zuy84ALzdBkq53pQ@mail.gmail.com>

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.
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" <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/20140403/a46a0f5a/attachment.html>

From gchaplik at redhat.com  Thu Apr  3 17:40:08 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Thu, 3 Apr 2014 13:40:08 -0400 (EDT)
Subject: [Engine-devel] vds_dynamic refactor
In-Reply-To: <CAJ3aYLdLorX0wsjU1f0kspg2NEjRojwpF-zuy84ALzdBkq53pQ@mail.gmail.com>
References: <2022363066.4485973.1396522676638.JavaMail.zimbra@redhat.com>
	<CAJ3aYLeGCBXYU9KZ5VAXtUt2LxEdYFaW-r43UcEStWif2+j97Q@mail.gmail.com>
	<754141813.4689998.1396534438712.JavaMail.zimbra@redhat.com>
	<CAJ3aYLe0+V3uC+Zw6WwiWRSQ9bGU9HOD+D8gYNSTnz1S6-jhuA@mail.gmail.com>
	<233947313.4695035.1396534736194.JavaMail.zimbra@redhat.com>
	<CAJ3aYLf0pB=fOSzzRjJu+ijJT8Hb5QSM+Ydn4U11eSrNFh+CNA@mail.gmail.com>
	<1232334338.4708502.1396535637653.JavaMail.zimbra@redhat.com>
	<CAJ3aYLdLorX0wsjU1f0kspg2NEjRojwpF-zuy84ALzdBkq53pQ@mail.gmail.com>
Message-ID: <2144788015.4892008.1396546808902.JavaMail.zimbra@redhat.com>

----- 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
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
> 


From liran.zelkha at gmail.com  Fri Apr  4 01:30:35 2014
From: liran.zelkha at gmail.com (Liran Zelkha)
Date: Fri, 4 Apr 2014 04:30:35 +0300
Subject: [Engine-devel] vds_dynamic refactor
In-Reply-To: <2144788015.4892008.1396546808902.JavaMail.zimbra@redhat.com>
References: <2022363066.4485973.1396522676638.JavaMail.zimbra@redhat.com>
	<CAJ3aYLeGCBXYU9KZ5VAXtUt2LxEdYFaW-r43UcEStWif2+j97Q@mail.gmail.com>
	<754141813.4689998.1396534438712.JavaMail.zimbra@redhat.com>
	<CAJ3aYLe0+V3uC+Zw6WwiWRSQ9bGU9HOD+D8gYNSTnz1S6-jhuA@mail.gmail.com>
	<233947313.4695035.1396534736194.JavaMail.zimbra@redhat.com>
	<CAJ3aYLf0pB=fOSzzRjJu+ijJT8Hb5QSM+Ydn4U11eSrNFh+CNA@mail.gmail.com>
	<1232334338.4708502.1396535637653.JavaMail.zimbra@redhat.com>
	<CAJ3aYLdLorX0wsjU1f0kspg2NEjRojwpF-zuy84ALzdBkq53pQ@mail.gmail.com>
	<2144788015.4892008.1396546808902.JavaMail.zimbra@redhat.com>
Message-ID: <CAJ3aYLcSCaDbRrFnAic0C5sxe0hwiNiH2btQOLQQJ2Ggi3GvhA@mail.gmail.com>

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>

From iheim at redhat.com  Fri Apr  4 12:15:02 2014
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 04 Apr 2014 15:15:02 +0300
Subject: [Engine-devel] [Devel]  vds_dynamic refactor
In-Reply-To: <CAJ3aYLcSCaDbRrFnAic0C5sxe0hwiNiH2btQOLQQJ2Ggi3GvhA@mail.gmail.com>
References: <2022363066.4485973.1396522676638.JavaMail.zimbra@redhat.com>	<CAJ3aYLeGCBXYU9KZ5VAXtUt2LxEdYFaW-r43UcEStWif2+j97Q@mail.gmail.com>	<754141813.4689998.1396534438712.JavaMail.zimbra@redhat.com>	<CAJ3aYLe0+V3uC+Zw6WwiWRSQ9bGU9HOD+D8gYNSTnz1S6-jhuA@mail.gmail.com>	<233947313.4695035.1396534736194.JavaMail.zimbra@redhat.com>	<CAJ3aYLf0pB=fOSzzRjJu+ijJT8Hb5QSM+Ydn4U11eSrNFh+CNA@mail.gmail.com>	<1232334338.4708502.1396535637653.JavaMail.zimbra@redhat.com>	<CAJ3aYLdLorX0wsjU1f0kspg2NEjRojwpF-zuy84ALzdBkq53pQ@mail.gmail.com>	<2144788015.4892008.1396546808902.JavaMail.zimbra@redhat.com>
	<CAJ3aYLcSCaDbRrFnAic0C5sxe0hwiNiH2btQOLQQJ2Ggi3GvhA@mail.gmail.com>
Message-ID: <533EA246.6020605@redhat.com>

On 04/04/2014 04:30 AM, Liran Zelkha wrote:
>
>
>
> On Thu, Apr 3, 2014 at 8:40 PM, Gilad Chaplik <gchaplik at redhat.com
> <mailto:gchaplik at redhat.com>> wrote:
>
>     ----- Original Message -----
>      > From: "Liran Zelkha" <liran.zelkha at gmail.com
>     <mailto:liran.zelkha at gmail.com>>
>      > To: "Gilad Chaplik" <gchaplik at redhat.com
>     <mailto:gchaplik at redhat.com>>
>      > Cc: "Omer Frenkel" <ofrenkel at redhat.com
>     <mailto:ofrenkel at redhat.com>>, "Eli Mesika" <emesika at redhat.com
>     <mailto:emesika at redhat.com>>, "engine-devel" <engine-devel at ovirt.org
>     <mailto:engine-devel at ovirt.org>>,
>      > devel at linode01.ovirt.org <mailto: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 <mailto:gchaplik at redhat.com>> wrote:
>      >
>      > > *From: *"Liran Zelkha" <liran.zelkha at gmail.com
>     <mailto:liran.zelkha at gmail.com>>
>      > > *To: *"Gilad Chaplik" <gchaplik at redhat.com
>     <mailto:gchaplik at redhat.com>>
>      > > *Cc: *"Omer Frenkel" <ofrenkel at redhat.com
>     <mailto:ofrenkel at redhat.com>>, "Eli Mesika" <
>      > > emesika at redhat.com <mailto:emesika at redhat.com>>, "engine-devel"
>     <engine-devel at ovirt.org <mailto: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.

thought the distinction was vds_static is updated by user 
(configuration), where as vds_dyanmic/statistics is reported from vdsm 
(slow/fast updates).

please remember joining them to one table, also means DWH will ETA all 
of data each time. today it will only copy statistics if dynamic did not 
change.



From liran.zelkha at gmail.com  Fri Apr  4 13:19:58 2014
From: liran.zelkha at gmail.com (Liran Zelkha)
Date: Fri, 4 Apr 2014 16:19:58 +0300
Subject: [Engine-devel] [Devel]  vds_dynamic refactor
In-Reply-To: <533EA246.6020605@redhat.com>
References: <2022363066.4485973.1396522676638.JavaMail.zimbra@redhat.com>
	<CAJ3aYLeGCBXYU9KZ5VAXtUt2LxEdYFaW-r43UcEStWif2+j97Q@mail.gmail.com>
	<754141813.4689998.1396534438712.JavaMail.zimbra@redhat.com>
	<CAJ3aYLe0+V3uC+Zw6WwiWRSQ9bGU9HOD+D8gYNSTnz1S6-jhuA@mail.gmail.com>
	<233947313.4695035.1396534736194.JavaMail.zimbra@redhat.com>
	<CAJ3aYLf0pB=fOSzzRjJu+ijJT8Hb5QSM+Ydn4U11eSrNFh+CNA@mail.gmail.com>
	<1232334338.4708502.1396535637653.JavaMail.zimbra@redhat.com>
	<CAJ3aYLdLorX0wsjU1f0kspg2NEjRojwpF-zuy84ALzdBkq53pQ@mail.gmail.com>
	<2144788015.4892008.1396546808902.JavaMail.zimbra@redhat.com>
	<CAJ3aYLcSCaDbRrFnAic0C5sxe0hwiNiH2btQOLQQJ2Ggi3GvhA@mail.gmail.com>
	<533EA246.6020605@redhat.com>
Message-ID: <CAJ3aYLdPherVJFqt8ketuQ6ikvZqYogtigvmk9Zd32nPBnWO=w@mail.gmail.com>

On Fri, Apr 4, 2014 at 3:15 PM, Itamar Heim <iheim at redhat.com> wrote:

> On 04/04/2014 04:30 AM, Liran Zelkha wrote:
>
>>
>>
>>
>> On Thu, Apr 3, 2014 at 8:40 PM, Gilad Chaplik <gchaplik at redhat.com
>> <mailto:gchaplik at redhat.com>> wrote:
>>
>>     ----- Original Message -----
>>      > From: "Liran Zelkha" <liran.zelkha at gmail.com
>>     <mailto:liran.zelkha at gmail.com>>
>>      > To: "Gilad Chaplik" <gchaplik at redhat.com
>>     <mailto:gchaplik at redhat.com>>
>>      > Cc: "Omer Frenkel" <ofrenkel at redhat.com
>>     <mailto:ofrenkel at redhat.com>>, "Eli Mesika" <emesika at redhat.com
>>     <mailto:emesika at redhat.com>>, "engine-devel" <engine-devel at ovirt.org
>>     <mailto:engine-devel at ovirt.org>>,
>>      > devel at linode01.ovirt.org <mailto: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 <mailto:gchaplik at redhat.com>> wrote:
>>      >
>>      > > *From: *"Liran Zelkha" <liran.zelkha at gmail.com
>>     <mailto:liran.zelkha at gmail.com>>
>>
>>      > > *To: *"Gilad Chaplik" <gchaplik at redhat.com
>>     <mailto:gchaplik at redhat.com>>
>>
>>      > > *Cc: *"Omer Frenkel" <ofrenkel at redhat.com
>>     <mailto:ofrenkel at redhat.com>>, "Eli Mesika" <
>>      > > emesika at redhat.com <mailto:emesika at redhat.com>>, "engine-devel"
>>     <engine-devel at ovirt.org <mailto: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.
>>
>
> thought the distinction was vds_static is updated by user (configuration),
> where as vds_dyanmic/statistics is reported from vdsm (slow/fast updates).
>
> True - vds_static hardly change. But vds_dynamic is split-brain - it has
practically static data, but also has the status - which changes rapidly.
And since we have 3 tables, we need to do 3 joins to get VDS (actually we
do much more).


> please remember joining them to one table, also means DWH will ETA all of
> data each time. today it will only copy statistics if dynamic did not
> change.
>
> I'm not saying joining all 3 tables to 1 table, just make them 2 tables.
And since the data is hardly changing - same logic of DWH will stay.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20140404/dba31027/attachment.html>

From iheim at redhat.com  Fri Apr  4 17:43:58 2014
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 04 Apr 2014 20:43:58 +0300
Subject: [Engine-devel] ovirtengine connect node
In-Reply-To: <CALknHWkBHez-W=iTJ4X055kFtMOjtgQBHNiMrkcnVthAxmvs8w@mail.gmail.com>
References: <CALknHWkBHez-W=iTJ4X055kFtMOjtgQBHNiMrkcnVthAxmvs8w@mail.gmail.com>
Message-ID: <533EEF5E.1070704@redhat.com>

On 03/28/2014 09:36 AM, marco lin wrote:
> st node1 is compatible with versions (3.0,3.1,3.2,3.3) and cannot join
> Cluster Default which is set to version 3.4. How to solve?
>

was this resolveD? which OS are you using for node1?



From vszocs at redhat.com  Fri Apr  4 21:03:34 2014
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 4 Apr 2014 17:03:34 -0400 (EDT)
Subject: [Engine-devel] NUMA Support - GUI Technical Session
In-Reply-To: <2503255.bqO8iyxaJI@awels>
References: <1959694781.11106446.1396134419108.JavaMail.zimbra@redhat.com>
	<1703386390.2298741.1396366483396.JavaMail.zimbra@redhat.com>
	<2503255.bqO8iyxaJI@awels>
Message-ID: <1627402733.3180786.1396645414098.JavaMail.zimbra@redhat.com>

Hi Gilad,

to my understanding, we already use _HTML5_ Drag'n'Drop support
(exposed by GWT API since 2.4) in "Setup Host Networks" dialog.

To utilize HTML5 Drag'n'Drop support in GWT widget, just extend
FocusPanel and mark your widget's DOM element as "draggable".

For example, in UnassignedNetworksPanel constructor:

  getElement().setDraggable( ... );
  addBitlessDomHandler(new DragEnterHandler() { ... });
  addBitlessDomHandler(new DragOverHandler() { ... });
  addBitlessDomHandler(new DragLeaveHandler() { ... });
  addBitlessDomHandler(new DropHandler() { ... });

In other words, GWT already exposes API for working with HTML5
Drag'n'Drop spec, so you don't need any 3rd party libraries.
The downside is that HTML5 Drag'n'Drop spec is supported only
in recent browsers (but this isn't an issue for us, AFAIK):

  http://caniuse.com/#feat=dragndrop

So in general we have two alternatives:

  1, use standard HTML5 Drag'n'Drop spec

     pros:
     + no need for 3rd party library
     + compliant with existing code, i.e. "Setup Host Networks"

     cons (not too relevant IMHO):
     - requires browser support of HTML5 Drag'n'Drop spec
     - HTML5 Drag'n'Drop spec deals with dragging data, not widgets
       themselves (no HTML DOM re-parenting after drag finish)

  2, use 3rd party gwt-dnd library

     pros (which I don't think we really need):
     + emulate Drag'n'Drop support in older browsers
     + more advanced functionality, i.e. allows dragging widgets
       so that HTML DOM is dynamically updated

     cons:
     - dependency on 3rd party library
     - this would mean we need to revisit existing code
       (we should do Drag'n'Drop in one consistent way)

It's possible that I might be missing something, but I'd
suggest to try using HTML5 Drag'n'Drop via GWT API as the
first approach.

If we find out that HTML5 Drag'n'Drop doesn't work for us
in given browser(s) or if we need extra functionality, we
can always add gwt-dnd dependency.

Few more comments inline, let me know what you think.

Regards,
Vojtech


----- Original Message -----
> From: "Alexander Wels" <awels at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: ecohen at redhat.com, "Vojtech Szocs" <vszocs at redhat.com>, dfediuck at redhat.com, engine-devel at ovirt.org, "chegu
> vinod" <chegu_vinod at hp.com>, lvernia at redhat.com
> Sent: Tuesday, April 1, 2014 7:24:12 PM
> Subject: Re: NUMA Support - GUI Technical Session
> 
> On Tuesday, April 01, 2014 11:34:43 AM Gilad Chaplik wrote:
> > Hi all,
> > 
> > Here are the resolutions from the meeting:
> > 
> > * option 1
> > 1) Use gwt-dnd lib for oVirt's dnd (drag and drop) infrastructure.
> > 2) Come up with a very simple POC that covers all of NUMA-support UX
> > requirements. 3) Either do a POC, or get UX maintainers approval, that
> > moving already existing dnd features to new infrastructure (setup-networks
> > and scheduling policy dialogs) is feasible and possible.
> > 
> 
> +1 for option 1. None of the drag and drop in the application now looks
> terribly hard. The gwt-dnd library simply makes things easier to control and
> maintain.

Yeah, but the downside is adding 3rd party dependency which predates GWT's
support for (API exposure of) HTML5 Drag'n'Drop spec.

> 
> > * option 2
> > Extract setup network dnd capabilities to a common general infrastructure
> > and use that as an infrastructure. NOTE that setup-networks will not use it
> > in oVirt-3.5.

GWT's HTML5 Drag'n'Drop API works directly on DOM element level, it's just
a thin API overlay on top of HTML5Drag'n'Drop spec.

Do we really need custom DnD infra on top of that? Can't we just use GWT
APIs like Element.setDraggable, Drag*Handler, Drop*Handler?

> > 
> > I will start with option 1, just need UX team approval that [1] will be
> > added to ovirt-3.5, and be used for dnd for now on. In case I fail to
> > deliver option 1 (with the help and guidance of the UX team) in a quick
> > cycle (a week or so), I will peruse option 2, which is trivial.
> > 
> > Moving forward, all new dnd enabled features will use the new
> > infrastructure, and the motivation is to migrate existing ones as well.

I agree, there should be one consistent way to do DnD in oVirt UI.

I'm just saying we should consider existing GWT HTML5 Drag'n'Drop API
before jumping into gwt-dnd 3rd party dependency. If it turns out that
GWT DnD API is too basic (lacks functionality) or has issues with some
browser(s) - we can add gwt-dnd dependency anytime.

> > 
> > Thanks,
> > Gilad.
> > 
> > [1] http://code.google.com/p/gwt-dnd/
> > 
> > ----- Original Message -----
> > 
> > > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > > To: "Einav Cohen" <ecohen at redhat.com>, "Alexander Wels"
> > > <awels at redhat.com>, "Eyal Edri" <eedri at redhat.com>, "Steve Gordon"
> > > <sgordon at redhat.com>, "Eli Mesika" <emesika at redhat.com>, "Otavio Luiz
> > > Ferranti" <otavio.ferranti at eldorado.org.br>, "Sandro Bonazzola"
> > > <sbonazzo at redhat.com>, "Greg Sheremeta" <gshereme at redhat.com>, "Doron
> > > Fediuck" <dfediuck at redhat.com>, "Lior Vernia" <lvernia at redhat.com>,
> > > "engine-devel" <engine-devel at ovirt.org>, "Martin Sivak"
> > > <msivak at redhat.com>, "chuan liao" <chuan.liao at hp.com>, "xiao-lei shi"
> > > <xiao-lei.shi at hp.com>, "chegu vinod" <chegu_vinod at hp.com>, "da-huai tang"
> > > <da-huai.tang at hp.com>
> > > Sent: Sunday, March 30, 2014 2:06:59 AM
> > > Subject: NUMA Support - GUI Technical Session
> > > 
> > > The following meeting has been modified:
> > > 
> > > Subject: NUMA Support - GUI Technical Session [MODIFIED]
> > > Organizer: "Gilad Chaplik" <gchaplik at redhat.com>
> > > 
> > > Time: Tuesday, April 1, 2014, 5:00:00 PM - 6:00:00 PM GMT +02:00
> > > Jerusalem
> > > [MODIFIED]
> > > 
> > > Required: ecohen at redhat.com; awels at redhat.com; eedri at redhat.com;
> > > sgordon at redhat.com; emesika at redhat.com; otavio.ferranti at eldorado.org.br;
> > > sbonazzo at redhat.com; gshereme at redhat.com
> > > Optional: dfediuck at redhat.com; lvernia at redhat.com;
> > > engine-devel at ovirt.org;
> > > msivak at redhat.com; chuan.liao at hp.com; xiao-lei.shi at hp.com;
> > > chegu_vinod at hp.com; da-huai.tang at hp.com
> > > 
> > > *~*~*~*~*~*~*~*~*~*
> > > 
> > > We will discuss on how to implement NUMA support GUI in oVirt for version
> > > 3.5 (see attached sketches).
> > > 
> > > Agenda:
> > > 1) Brainstorming
> > > 2) Resolution
> > > 3) Split work/tasks among volunteers :)
> > > 
> > > GUI maintainers please join-in.
> > > 
> > > Bluejeans (video conference) session to follow [maybe], currently dial
> > > in:
> > > 
> > > https://www.intercallonline.com/listNumbersByCode.action?confCode=71288674
> > > 05
> > > 
> > > conf id: 712 886 7405#
> 
>