----- Original Message ----- > From: "ybronhei" <ybron...@redhat.com> > To: "Barak Azulay" <bazu...@redhat.com> > Cc: "engine-devel" <engine-de...@ovirt.org>, "VDSM Project Development" > <vdsm-devel@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" <aba...@redhat.com> > >> To: "Saggi Mizrahi" <smizr...@redhat.com> > >> Cc: "VDSM Project Development" <vdsm-devel@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" <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. > > > > > > 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" <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 > >> > > _______________________________________________ > > Engine-devel mailing list > > engine-de...@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > -- > Yaniv Bronhaim. > RedHat, Israel > 09-7692289 > 054-7744187 > _______________________________________________ > 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