On 12/05/2012 04:32 PM, Adam Litke wrote:
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.
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
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.
vdsm-devel mailing list