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

Reply via email to