On Tue, Dec 11, 2012 at 01:56:40PM -0500, Andrew Cathrow wrote: > > > ----- Original Message ----- > > From: "Dan Kenigsberg" <dan...@redhat.com> > > To: "Andrew Cathrow" <acath...@redhat.com>, "Yaniv Bronheim" > > <ybron...@redhat.com> > > Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>, "Adam > > Litke" <a...@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" <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. > > There's more in the current feature page taht I believe was called out in the > original patch.
Yeah, this is exactly what worried me, and made me restrict my former response on this thread. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
