----- 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.

> 
> 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

Reply via email to