----- Original Message ----- > From: "Dan Kenigsberg" <dan...@redhat.com> > To: "Adam Litke" <a...@us.ibm.com> > Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org> > Sent: Tuesday, December 11, 2012 4:35:31 AM > Subject: Re: [vdsm] Host bios information > > On Wed, Dec 05, 2012 at 09:44:21AM -0600, Adam Litke wrote: > > On Wed, Dec 05, 2012 at 05:25:10PM +0200, ybronhei wrote: > > > On 12/05/2012 04:32 PM, Adam Litke wrote: > > > >On Wed, Dec 05, 2012 at 11:05:21AM +0200, ybronhei wrote: > > > >>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. > > > > > > > >Seems good to me but I would like to throw out one suggestion. > > > >getVdsCapabilities is already a huge command that does a lot of > > > >time consuming > > > >things. As part of the vdsm API refactoring, we are going to > > > >start favoring > > > >small and concise APIs over "bag" APIs. Perhaps we should just > > > >add a new verb: > > > >Host.getVdsBiosInfo() that returns only this information. > > > > > > > It leads to modification also in how the engine collects the > > > parameters with the new api request and I'm not sure if we should > > > get into this.. Now we have specific known way of how engine > > > requests for capabilities, when and how it effects the status of > > > the > > > host that is shown via the UI. > > > To simplify this feature I prefer to use the current way of > > > gathering and providing host's information. If we'll decide to > > > split > > > the host's capabilities api, it needs to get rfcs mail of its own > > > because it changes engine's internal flows and it makes this > > > feature > > > to something much more influential. > > > > I don't understand. Why can't you just call both APIs, one after > > the other? > > I understand it as: "this adds more work on Engine side", which is > not > very convincing. > > Adam, I agree that getVdsCaps is bloated as it is. But on the other > hand, host bios info fits into it quite well: it is host related > information, that is not expected to change post boot. (Too bad that > network configuration is there, for sure). > > So I'm a bit reluctant about adding a new verb for getVdsBiosInfo, > and > would not mind the suggested API change. >
Can we do both? Add a new GetBiosInfo call (/me hates having Vds in there) that can be called independently but also extend the getVdsCaps call. That way we can keep the existing flows in place but start building a foundation for if/when we refactor? > Dan. > > Dan. > _______________________________________________ > 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
