----- Original Message -----
From: "Dan Kenigsberg" danken@redhat.com To: "Andrew Cathrow" acathrow@redhat.com, "Yaniv Bronheim" ybronhei@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "Adam Litke" agl@us.ibm.com Sent: Tuesday, December 11, 2012 1:54:28 PM Subject: Re: [vdsm] Host bios information
On Tue, Dec 11, 2012 at 05:44:50AM -0500, Andrew Cathrow wrote:
----- Original Message -----
From: "Dan Kenigsberg" danken@redhat.com To: "Adam Litke" agl@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?
I am not strictly regecting the idea of a new verb for bios information. I just wondered if the 6 values suggested in http://gerrit.ovirt.org/#/c/9258/5/vdsm/caps.py merit their district API call.
However, if there are any plans to ever expose more of the dmidecode output that is dumped on http://www.ovirt.org/Features/Design/HostBiosInfo - we may well need to reconsider agregating these properties in a more structured manner.
There's more in the current feature page taht I believe was called out in the original patch.
In any case, Yaniv, I'd be happy if you elaborate on why calling another verb just after calling getVdsCaps is complex in Engine (I really did not understand).
Dan.