On Tue, Dec 11, 2012 at 05:44:50AM -0500, Andrew Cathrow wrote: > > > ----- 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?
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. 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. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
