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
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.
vdsm-devel mailing list