[Engine-devel] [vdsm] Host bios information

Andrew Cathrow acathrow at redhat.com
Sun Dec 16 17:32:10 UTC 2012 


----- Original Message -----
> From: "ybronhei" <ybronhei at redhat.com>
> To: "Barak Azulay" <bazulay at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>
> Sent: Sunday, December 16, 2012 12:04:32 PM
> Subject: Re: [vdsm] [Engine-devel]  Host bios information
> 
> On 12/16/2012 06:24 PM, Barak Azulay wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Ayal Baron" <abaron at redhat.com>
> >> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> >> Cc: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>
> >> Sent: Friday, December 14, 2012 2:07:04 AM
> >> Subject: Re: [vdsm] Host bios information
> >>
> >>
> >>
> >> ----- Original Message -----
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Ayal Baron" <abaron at redhat.com>
> >>>> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> >>>> Cc: "VDSM Project Development"
> >>>> <vdsm-devel at lists.fedorahosted.org>,
> >>>> "Shu Ming" <shuming at 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.
> >
> >
> > I totally agree that in the long run it is correct to add a
> > different API on vdsm,
> > However for the initial 6 bios params:
> >
> > 1. Host Manufacturer - Manufacturer of the host's machine and bios'
> > vendor (e.g LENOVO)
> > 2. Host Version - For each host the manufacturer gives a unique
> > name (e.g. Lenovo T420s)
> > 3. Host Product Name - ID of the product - same for all similar
> > products (e.g 4174BH4)
> > 4. Host UUID - Unique ID for each host (e.g
> > E03DD601-5219-11CB-BB3F-892313086897)
> > 5. Host Family - Type of host's CPU - (e.g Core i5)
> > 6. Host Serial Number - Unique ID for host's chassis (e.g R9M4N4G)
> >
> > As Dan stated below, is o.k. for this specific phase to add them to
> > getVdsCaps
> >
> > So I suggest:
> > 1 Adding the above 6 above params to getVdsCaps
> > 2 Add a new API to vdsm to retrieve host bios information - that
> > will eventually return the entire list (current will retrieve the
> > exact 6 params and will use the same underlying implementation)
> > 3 In the future engine will start using the new API
> >
> > Start using the new API now on the engine side will require much
> > more testing as it might have an influence on the host state
> > machine.
> >
> > Thanks
> > Barak Azulay
> >
> Agree,
> In vdsm side as Andrew suggested we can add new xml-rpc Api that
> internally calls by getCapabilities until we will define the flow
> changes that we need to do in the engine side to permit split calls
> that
> fill VDS object fields.
> 
> Before we change the engine side to perform 2 calls to fill vds data,
> we
> need to define the flows for retrieving the data, in which table to
> keep
> it, and when to refresh it.
> getCapabilities API call signs for the engine that the host is
> operational. By performing another API call we will get into cases
> that
> we've never checked and we need to define and test.
> 
> This feature can be split to 2 levels, first we have the requirement
> for
> 6 field, and only those fields (as i mentioned in the wiki), those
>  can
> be added as part of host capabilities structure, in declared
> structure
> that defines the bios information, until we define the new api.
> Additionally, we can add vdsm API the returns only this structure for
> future use by the engine.
> 
> Anyhow, when defining new structure for bios information we can add
> more
> values of dmidecode in the future if the users will request for such
> info, and it won't effect the changes we add to the UI as part of
> this
> feature.
> 
> IMPOV, I think we should implement that feature as described now in
> the
> engine side. Using new vdsm API by the engine should be part of
> another
> feature that arranges getCapabilities variables, defines the flows of
> requesting bios variables and in which VDS table engine should store
> this data.
> 
> The engine part patches of this feature are:
> http://gerrit.ovirt.org/#/c/10114/ - Modifying db tables
> http://gerrit.ovirt.org/#/c/9337/ - Adding bios data to backend's
> objects
> http://gerrit.ovirt.org/#/c/10115/ - UI changes to add host subtab
> for
> Bios info

I think we are still missing some information even for the smaller subset - eg asset tag

James can you do a little research with our oem partners and see which makes sense

> 
> vdsm part:
> http://gerrit.ovirt.org/#/c/9258/ - will be modified asap to external
> structure.
> 
> I would appreciate your comments and reviews
> 
> thanks!
> 
> >>
> >>>>
> >>>>>
> >>>>> 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 at linux.vnet.ibm.com>
> >>>>>> To: "ybronhei" <ybronhei at redhat.com>
> >>>>>> Cc: "VDSM Project Development"
> >>>>>> <vdsm-devel at 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 at cn.ibm.com
> >>>>>> or
> >>>>>> shuming at linux.vnet.ibm.com
> >>>>>> Address: 3/F Ring Building, ZhongGuanCun Software Park,
> >>>>>> Haidian
> >>>>>> District, Beijing 100193, PRC
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> vdsm-devel mailing list
> >>>>>> vdsm-devel at lists.fedorahosted.org
> >>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >>>>>>
> >>>>> _______________________________________________
> >>>>> vdsm-devel mailing list
> >>>>> vdsm-devel at lists.fedorahosted.org
> >>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >>>>>
> >>>>
> >>>
> >> _______________________________________________
> >> vdsm-devel mailing list
> >> vdsm-devel at lists.fedorahosted.org
> >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 
> --
> Yaniv Bronhaim.
> RedHat, Israel
> 09-7692289
> 054-7744187
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>

More information about the Devel mailing list