----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Ayal Baron" <aba...@redhat.com>
> > To: "Saggi Mizrahi" <smizr...@redhat.com>
> > Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>,
> > "Shu Ming" <shum...@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" <shum...@linux.vnet.ibm.com>
> > > > To: "ybronhei" <ybron...@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:
> > > > shum...@cn.ibm.com
> > > > or
> > > > shum...@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
> > > 
> > 
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to