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


> Dan.
> 
> Dan.
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to