[vdsm] Host bios information
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. Thanks. -- Yaniv Bronhaim. RedHat, Israel 09-7692289 054-7744187 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Host bios information
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. -- Adam Litke IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Host bios information
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. -- Yaniv Bronhaim. RedHat, Israel 09-7692289 054-7744187 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Host bios information
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? -- Adam Litke IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
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. Dan. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Host bios information
- Original Message - > From: "Dan Kenigsberg" > To: "Adam Litke" > Cc: "VDSM Project Development" > 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
Re: [vdsm] Host bios information
On Tue, Dec 11, 2012 at 05:44:50AM -0500, Andrew Cathrow wrote: > > > - Original Message - > > From: "Dan Kenigsberg" > > To: "Adam Litke" > > Cc: "VDSM Project Development" > > 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
Re: [vdsm] Host bios information
- Original Message - > From: "Dan Kenigsberg" > To: "Andrew Cathrow" , "Yaniv Bronheim" > > Cc: "VDSM Project Development" , "Adam > Litke" > 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" > > > To: "Adam Litke" > > > Cc: "VDSM Project Development" > > > > > > 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
Re: [vdsm] Host bios information
On Tue, Dec 11, 2012 at 01:56:40PM -0500, Andrew Cathrow wrote: > > > - Original Message - > > From: "Dan Kenigsberg" > > To: "Andrew Cathrow" , "Yaniv Bronheim" > > > > Cc: "VDSM Project Development" , "Adam > > Litke" > > 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" > > > > To: "Adam Litke" > > > > Cc: "VDSM Project Development" > > > > > > > > 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. > > > > > > >
Re: [vdsm] Host bios information
After a quick review of the wiki page, it was stated that dmidecode gave too much informations. Only five fields will be displayed in the hardware tab, "Manufactory", "Version", "Family", "UUID" and "serial number". For "Family", it is mean the CPU core's family. And it confuses me a bit with the "CPU name" and "CPU type" fields in general tab. I think we should chose the best one to characterizethe CPU type. ybronhei: 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. Thanks. -- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shum...@cn.ibm.com or shum...@linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Host bios information
I think that for the new current XML-RPC API it's OK to add it to the getVdsCaps() verb. For the new API I suggest moving it to it's own API. The smaller the APIs the easier they are to deprecate and support. I quite doubt the fields in getBiosInfo() will change half as frequently as whatever getVdsCaps() returns. I also kind of want to throw away getVdsCaps() and split it to better named better encapsulated methods. Also, in the json-rpc base model, calls are not only cheaper, you also have batch calls. This means you can send multiple requests as one message and have VDSM send you the responses as one message once all tasks completed. This makes splitting aggregated methods to smaller methods painless and with minimal overhead. - Original Message - > From: "Shu Ming" > To: "ybronhei" > Cc: "VDSM Project Development" > Sent: Thursday, December 13, 2012 11:04:09 AM > Subject: Re: [vdsm] Host bios information > > After a quick review of the wiki page, it was stated that dmidecode > gave > too much informations. Only five fields will be displayed in the > hardware tab, "Manufactory", "Version", "Family", "UUID" and "serial > number". For "Family", it is mean the CPU core's family. And it > confuses me a bit with the "CPU name" and "CPU type" fields in > general > tab. I think we should chose the best one to characterizethe CPU > type. > > > ybronhei: > > 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. > > > > Thanks. > > > > > -- > --- > 舒明 Shu Ming > Open Virtualization Engineerning; CSTL, IBM Corp. > Tel: 86-10-82451626 Tieline: 9051626 E-mail: shum...@cn.ibm.com or > shum...@linux.vnet.ibm.com > Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian > District, Beijing 100193, PRC > > > ___ > 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
Re: [vdsm] Host bios information
- Original Message - > I think that for the new current XML-RPC API it's OK to add it to the > getVdsCaps() verb. > For the new API I suggest moving it to it's own API. The smaller the > APIs the easier they are to deprecate and support. > I quite doubt the fields in getBiosInfo() will change half as > frequently as whatever getVdsCaps() returns. > I also kind of want to throw away getVdsCaps() and split it to better > named better encapsulated methods. Ack. I just don't understand why not start right now? Any new patch should improve things at least a little. We know getVdsCaps() is wrong so let's put the bios info (and anything in getVdsCaps that makes sense to put with it if relevant) in a separate call. Adding a call in engine to this new method should be a no brainer, I don't think that is a good reason for not doing things properly in vdsm, even if we're talking about the current API. > > Also, in the json-rpc base model, calls are not only cheaper, you > also have batch calls. This means you can send multiple requests as > one message and have VDSM send you the responses as one message once > all tasks completed. This makes splitting aggregated methods to > smaller methods painless and with minimal overhead. > > - Original Message - > > From: "Shu Ming" > > To: "ybronhei" > > Cc: "VDSM Project Development" > > Sent: Thursday, December 13, 2012 11:04:09 AM > > Subject: Re: [vdsm] Host bios information > > > > After a quick review of the wiki page, it was stated that dmidecode > > gave > > too much informations. Only five fields will be displayed in the > > hardware tab, "Manufactory", "Version", "Family", "UUID" and > > "serial > > number". For "Family", it is mean the CPU core's family. And it > > confuses me a bit with the "CPU name" and "CPU type" fields in > > general > > tab. I think we should chose the best one to characterizethe CPU > > type. > > > > > > ybronhei: > > > 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. > > > > > > Thanks. > > > > > > > > > -- > > --- > > 舒明 Shu Ming > > Open Virtualization Engineerning; CSTL, IBM Corp. > > Tel: 86-10-82451626 Tieline: 9051626 E-mail: shum...@cn.ibm.com or > > shum...@linux.vnet.ibm.com > > Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian > > District, Beijing 100193, PRC > > > > > > ___ > > 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 > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Host bios information
- Original Message - > From: "Ayal Baron" > To: "Saggi Mizrahi" > Cc: "VDSM Project Development" , "Shu > Ming" > Sent: Thursday, December 13, 2012 11:30:56 AM > Subject: Re: [vdsm] Host bios information > > > > - Original Message - > > I think that for the new current XML-RPC API it's OK to add it to > > the > > getVdsCaps() verb. > > For the new API I suggest moving it to it's own API. The smaller > > the > > APIs the easier they are to deprecate and support. > > I quite doubt the fields in getBiosInfo() will change half as > > frequently as whatever getVdsCaps() returns. > > I also kind of want to throw away getVdsCaps() and split it to > > better > > named better encapsulated methods. > > Ack. I just don't understand why not start right now? > Any new patch should improve things at least a little. > We know getVdsCaps() is wrong so let's put the bios info (and > anything in getVdsCaps that makes sense to put with it if relevant) > in a separate call. Adding a call in engine to this new method > should be a no brainer, I don't think that is a good reason for not > doing things properly in vdsm, even if we're talking about the > current API. Well, from what I know the current overhead per call is too large to mandate a lot of calls. At least that is what I've been told. If that is not an issue, do it in the XML-RPC API too. > > > > > Also, in the json-rpc base model, calls are not only cheaper, you > > also have batch calls. This means you can send multiple requests as > > one message and have VDSM send you the responses as one message > > once > > all tasks completed. This makes splitting aggregated methods to > > smaller methods painless and with minimal overhead. > > > > - Original Message - > > > From: "Shu Ming" > > > To: "ybronhei" > > > Cc: "VDSM Project Development" > > > > > > Sent: Thursday, December 13, 2012 11:04:09 AM > > > Subject: Re: [vdsm] Host bios information > > > > > > After a quick review of the wiki page, it was stated that > > > dmidecode > > > gave > > > too much informations. Only five fields will be displayed in the > > > hardware tab, "Manufactory", "Version", "Family", "UUID" and > > > "serial > > > number". For "Family", it is mean the CPU core's family. And it > > > confuses me a bit with the "CPU name" and "CPU type" fields in > > > general > > > tab. I think we should chose the best one to characterizethe CPU > > > type. > > > > > > > > > ybronhei: > > > > 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. > > > > > > > > Thanks. > > > > > > > > > > > > > -- > > > --- > > > 舒明 Shu Ming > > > Open Virtualization Engineerning; CSTL, IBM Corp. > > > Tel: 86-10-82451626 Tieline: 9051626 E-mail: shum...@cn.ibm.com > > > or > > > shum...@linux.vnet.ibm.com > > > Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian > > > District, Beijing 100193, PRC > > > > > > > > > ___ > > > 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 > > > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Host bios information
- Original Message - > > > - Original Message - > > From: "Ayal Baron" > > To: "Saggi Mizrahi" > > Cc: "VDSM Project Development" , > > "Shu Ming" > > Sent: Thursday, December 13, 2012 11:30:56 AM > > Subject: Re: [vdsm] Host bios information > > > > > > > > - Original Message - > > > I think that for the new current XML-RPC API it's OK to add it to > > > the > > > getVdsCaps() verb. > > > For the new API I suggest moving it to it's own API. The smaller > > > the > > > APIs the easier they are to deprecate and support. > > > I quite doubt the fields in getBiosInfo() will change half as > > > frequently as whatever getVdsCaps() returns. > > > I also kind of want to throw away getVdsCaps() and split it to > > > better > > > named better encapsulated methods. > > > > Ack. I just don't understand why not start right now? > > Any new patch should improve things at least a little. > > We know getVdsCaps() is wrong so let's put the bios info (and > > anything in getVdsCaps that makes sense to put with it if relevant) > > in a separate call. Adding a call in engine to this new method > > should be a no brainer, I don't think that is a good reason for not > > doing things properly in vdsm, even if we're talking about the > > current API. > Well, from what I know the current overhead per call is too large to > mandate a lot of calls. > At least that is what I've been told. If that is not an issue, do it > in the XML-RPC API too. if you call it every 2 seconds to each host then perhaps, but getVdsCaps is called in initvdsonup which is pretty rare (hours, days or more) so avoiding an extra call there seems wrong to me. > > > > > > > > Also, in the json-rpc base model, calls are not only cheaper, you > > > also have batch calls. This means you can send multiple requests > > > as > > > one message and have VDSM send you the responses as one message > > > once > > > all tasks completed. This makes splitting aggregated methods to > > > smaller methods painless and with minimal overhead. > > > > > > - Original Message - > > > > From: "Shu Ming" > > > > To: "ybronhei" > > > > Cc: "VDSM Project Development" > > > > > > > > Sent: Thursday, December 13, 2012 11:04:09 AM > > > > Subject: Re: [vdsm] Host bios information > > > > > > > > After a quick review of the wiki page, it was stated that > > > > dmidecode > > > > gave > > > > too much informations. Only five fields will be displayed in > > > > the > > > > hardware tab, "Manufactory", "Version", "Family", "UUID" and > > > > "serial > > > > number". For "Family", it is mean the CPU core's family. And > > > > it > > > > confuses me a bit with the "CPU name" and "CPU type" fields in > > > > general > > > > tab. I think we should chose the best one to characterizethe > > > > CPU > > > > type. > > > > > > > > > > > > ybronhei: > > > > > 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. > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > -- > > > > --- > > > > 舒明 Shu Ming > > > > Open Virtualization Engineerning; CSTL, IBM Corp. > > > > Tel: 86-10-82451626 Tieline: 9051626 E-mail: > > > > shum...@cn.ibm.com > > > > or > > > > shum...@linux.vnet.ibm.com > > > > Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian > > > > District, Beijing 100193, PRC > > > > > > > > > > > > ___ > > > > 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 > > > > > > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Host bios information
- Original Message - > From: "Ayal Baron" > To: "Saggi Mizrahi" > Cc: "VDSM Project Development" > Sent: Friday, December 14, 2012 2:07:04 AM > Subject: Re: [vdsm] Host bios information > > > > - Original Message - > > > > > > - Original Message - > > > From: "Ayal Baron" > > > To: "Saggi Mizrahi" > > > Cc: "VDSM Project Development" > > > , > > > "Shu Ming" > > > Sent: Thursday, December 13, 2012 11:30:56 AM > > > Subject: Re: [vdsm] Host bios information > > > > > > > > > > > > - Original Message - > > > > I think that for the new current XML-RPC API it's OK to add it > > > > to > > > > the > > > > getVdsCaps() verb. > > > > For the new API I suggest moving it to it's own API. The > > > > smaller > > > > the > > > > APIs the easier they are to deprecate and support. > > > > I quite doubt the fields in getBiosInfo() will change half as > > > > frequently as whatever getVdsCaps() returns. > > > > I also kind of want to throw away getVdsCaps() and split it to > > > > better > > > > named better encapsulated methods. > > > > > > Ack. I just don't understand why not start right now? > > > Any new patch should improve things at least a little. > > > We know getVdsCaps() is wrong so let's put the bios info (and > > > anything in getVdsCaps that makes sense to put with it if > > > relevant) > > > in a separate call. Adding a call in engine to this new method > > > should be a no brainer, I don't think that is a good reason for > > > not > > > doing things properly in vdsm, even if we're talking about the > > > current API. > > Well, from what I know the current overhead per call is too large > > to > > mandate a lot of calls. > > At least that is what I've been told. If that is not an issue, do > > it > > in the XML-RPC API too. > > if you call it every 2 seconds to each host then perhaps, but > getVdsCaps is called in initvdsonup which is pretty rare (hours, > days or more) so avoiding an extra call there seems wrong to me. I totally agree that in the long run it is correct to add a different API on vdsm, However for the initial 6 bios params: 1. Host Manufacturer - Manufacturer of the host's machine and bios' vendor (e.g LENOVO) 2. Host Version - For each host the manufacturer gives a unique name (e.g. Lenovo T420s) 3. Host Product Name - ID of the product - same for all similar products (e.g 4174BH4) 4. Host UUID - Unique ID for each host (e.g E03DD601-5219-11CB-BB3F-892313086897) 5. Host Family - Type of host's CPU - (e.g Core i5) 6. Host Serial Number - Unique ID for host's chassis (e.g R9M4N4G) As Dan stated below, is o.k. for this specific phase to add them to getVdsCaps So I suggest: 1 Adding the above 6 above params to getVdsCaps 2 Add a new API to vdsm to retrieve host bios information - that will eventually return the entire list (current will retrieve the exact 6 params and will use the same underlying implementation) 3 In the future engine will start using the new API Start using the new API now on the engine side will require much more testing as it might have an influence on the host state machine. Thanks Barak Azulay > > > > > > > > > > > > Also, in the json-rpc base model, calls are not only cheaper, > > > > you > > > > also have batch calls. This means you can send multiple > > > > requests > > > > as > > > > one message and have VDSM send you the responses as one message > > > > once > > > > all tasks completed. This makes splitting aggregated methods to > > > > smaller methods painless and with minimal overhead. > > > > > > > > - Original Message - > > > > > From: "Shu Ming" > > > > > To: "ybronhei" > > > > > Cc: "VDSM Project Development" > > > > > > > > > > Sent: Thursday, December 13, 2012 11:04:09 AM > > > > > Subject: Re: [vdsm] Host bios information > > > > > > > > > > After a quick review of the wiki page, it was stated that > > > > > dmidecode > > > > > gave > > > > > too much informations. Only five fields will be displayed in > > > > > the > > > > > hardware
