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. Dan. Dan. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
