----- Original Message -----
----- Original Message -----
From: "Ayal Baron" abaron@redhat.com To: "Saggi Mizrahi" smizrahi@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "Shu Ming" shuming@linux.vnet.ibm.com Sent: Thursday, December 13, 2012 11:30:56 AM Subject: Re: [vdsm] Host bios information
----- Original Message -----
I think that for the new current XML-RPC API it's OK to add it to the getVdsCaps() verb. For the new API I suggest moving it to it's own API. The smaller the APIs the easier they are to deprecate and support. I quite doubt the fields in getBiosInfo() will change half as frequently as whatever getVdsCaps() returns. I also kind of want to throw away getVdsCaps() and split it to better named better encapsulated methods.
Ack. I just don't understand why not start right now? Any new patch should improve things at least a little. We know getVdsCaps() is wrong so let's put the bios info (and anything in getVdsCaps that makes sense to put with it if relevant) in a separate call. Adding a call in engine to this new method should be a no brainer, I don't think that is a good reason for not doing things properly in vdsm, even if we're talking about the current API.
Well, from what I know the current overhead per call is too large to mandate a lot of calls. At least that is what I've been told. If that is not an issue, do it in the XML-RPC API too.
if you call it every 2 seconds to each host then perhaps, but getVdsCaps is called in initvdsonup which is pretty rare (hours, days or more) so avoiding an extra call there seems wrong to me.
Also, in the json-rpc base model, calls are not only cheaper, you also have batch calls. This means you can send multiple requests as one message and have VDSM send you the responses as one message once all tasks completed. This makes splitting aggregated methods to smaller methods painless and with minimal overhead.
----- Original Message -----
From: "Shu Ming" shuming@linux.vnet.ibm.com To: "ybronhei" ybronhei@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Thursday, December 13, 2012 11:04:09 AM Subject: Re: [vdsm] Host bios information
After a quick review of the wiki page, it was stated that dmidecode gave too much informations. Only five fields will be displayed in the hardware tab, "Manufactory", "Version", "Family", "UUID" and "serial number". For "Family", it is mean the CPU core's family. And it confuses me a bit with the "CPU name" and "CPU type" fields in general tab. I think we should chose the best one to characterizethe CPU type.
ybronhei:
Today in the Api we display general information about the host that vdsm export by getCapabilities Api.
We decided to add bios information as part of the information that is displayed in UI under host's general sub-tab.
To summaries the feature - We'll modify General tab to Software Information and add another tab for Hardware Information which will include all the bios data that we'll decide to gather from the host and display.
Following this feature page: http://www.ovirt.org/Features/Design/HostBiosInfo for more details. All the parameters that can be displayed are mentioned in the wiki.
I would greatly appreciate your comments and questions.
Thanks.
--
舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming@cn.ibm.com or shuming@linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel